A infraestrutura por trás da inteligência de fronteira | Runway AI Summit SF 2026

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: The infrastructure behind frontier intelligence | Runway AI Summit SF 2026 · Canal: Runway · 25:15 · Assistir no YouTube

Tópicos: Inferência e otimização de modelos, Infraestrutura e hardware de IA, Modelos de IA

Resumo

O painel discute como a infraestrutura de IA está mudando à medida que inference se torna uma carga de trabalho dominante e os modelos são incorporados a mais produtos e agentes. Os participantes destacam que operar em escala exige integrar software, hardware, rede e sistemas físicos, além de lidar com falhas em diferentes camadas. Também abordam como combinar workloads e tipos de hardware para aproveitar melhor a capacidade disponível. Para o futuro, apontam limites de energia e de oferta de componentes, bem como a necessidade de sistemas mais compreensíveis e previsíveis.

Pontos-chave

Inference cresce em importância e pode ser distribuída para a edge para reduzir latência e aproveitar fontes de energia disponíveis.
O aumento da adoção dos modelos expande a demanda por compute, mesmo quando os modelos se tornam mais eficientes.
A execução em clusters exige coordenar tarefas, dados e recuperação de falhas; Ray busca simplificar esse trabalho para aplicações em Python.
Falhas podem surgir em qualquer camada, desde hardware e Kubernetes até frameworks e aplicações, e podem incluir corrupção numérica silenciosa.
O desempenho depende da integração entre software, hardware, rede, armazenamento, resfriamento e infraestrutura física.
A eficiência de custos exige coordenar workloads: trabalhos elásticos podem ocupar capacidade que ficaria ociosa.
Workloads diferentes podem se beneficiar de aceleradores distintos, mas sua divisão exige coordenação entre as etapas.
A escassez de energia, componentes e capacidade de construção favorece soluções distribuídas e infraestrutura mais simples.
Em sistemas de grande escala, a compreensibilidade e a previsibilidade são essenciais para depurar problemas continuamente.

Capítulos

Início	Capítulo	Resumo
00:00	A mudança da infraestrutura de IA	Os participantes apresentam como o crescimento de inference e de agentes está mudando as prioridades de infraestrutura.
04:39	Modelos em produção e escala distribuída	O painel aborda arquiteturas com vários modelos, demanda por compute e os desafios de executar aplicações em clusters.
07:45	Falhas em todas as camadas	Robert Nishihara explica como detectar e mitigar falhas, inclusive casos de corrupção numérica que não são percebidos por verificações convencionais.
11:21	Otimização de ponta a ponta	Joanna Rencinch e Robert Nishihara discutem por que otimizar uma parte isolada não basta e como aproveitar capacidade ociosa entre workloads.
16:33	O que falta à infraestrutura atual	A conversa passa às necessidades futuras, incluindo hardware heterogêneo, energia disponível e limitações de fornecimento.
20:09	Energia, componentes e infraestrutura física	Joanna Rencinch descreve os gargalos de energia, equipamentos e construção e defende soluções adaptadas às restrições existentes.
23:14	O principal limite: sistemas compreensíveis	Robert Nishihara destaca a importância de entender e prever o comportamento dos sistemas durante a depuração em escala.
24:44	A adoção global de LLMs	Joanna Rencinch compara o uso de LLMs a uma máquina caça-níqueis e prevê que a adoção mundial da tecnologia ainda vai crescer.

Citações

Os modelos ficam mais eficientes, nós os colocamos em mais coisas e acabamos gastando ainda mais do que antes. — 05:11

Em escala, tudo quebra. — 08:15

Uma das coisas mais importantes para otimizar custos não é o interior do workload, mas a priorização entre workloads. — 14:59

IA não é um banco de dados. — 22:12

Precisamos projetar esses sistemas tendo a compreensibilidade e a previsibilidade como prioridades. — 24:44

Conceitos e entidades

inference (conceito): Execução de modelos para gerar respostas ou realizar tarefas, cuja demanda cresce com a adoção de IA.
edge inference (conceito): Execução de inference mais próxima do local onde os resultados são consumidos, favorecendo aplicações sensíveis à latência.
Ray (ferramenta): Framework open source para criar aplicações Python distribuídas e escaláveis.
Anyscale (empresa): Empresa cofundada por Robert Nishihara, associada no painel ao desenvolvimento e uso de Ray.
Runway (empresa): Empresa representada no painel por sua cofundadora Joanna Rencinch.
CoreWeave (empresa): Empresa mencionada como empregadora de Richard Alfons, que não pôde participar do painel.
AWS (empresa): Empresa representada pela moderadora Cherieus Abuashi.
Robert Nishihara (pessoa): Cofundador de Anyscale e um dos criadores de Ray.
Joanna Rencinch (pessoa): Cofundadora de Runway e participante do painel sobre infraestrutura de IA.
Cherieus Abuashi (pessoa): Managing Director da Amazon Web Services e moderadora do painel.
Richard Alfons (pessoa): SVP de Physical AI na CoreWeave, citado na apresentação como ausente do painel.
heterogeneidade de hardware (conceito): Uso de diferentes tipos de hardware para atender às necessidades específicas de cada etapa de um workload.
falha silenciosa de precisão numérica (conceito): Corrupção de dados durante a execução que pode ocorrer sem sinais evidentes de erro.
preemption (conceito): Interrupção ou reordenação de workloads para priorizar trabalhos mais importantes e usar melhor a capacidade.
prefill (conceito): Etapa de processamento de entrada que pode ter características de uso de compute diferentes das etapas seguintes.
decode (conceito): Etapa de geração de tokens que pode ter requisitos de hardware distintos dos de prefill.
reinforcement learning (conceito): Tipo de workload que pode combinar treinamento, inference, simulações e processamento de resultados.

Tradução completa (pt-BR)

00:00 Por favor, recebam no palco o cofundador da Anyscale, Robert Nishihara; o vice-presidente sênior de Physical AI da CoreWeave, Richard Alfons; a cofundadora da Runway, Joanna Rencinch; e a diretora-geral da AWS, Cherieus Abuashi. >> [música] >> Boa tarde. Sou Cherieus Abuashi. Sou diretora-geral da Amazon Web Services. Lidero nossa equipe de arquitetura de soluções da América do Norte.

00:31 Os grandes modelos ganham as manchetes. Mas hoje vamos olhar o que há por trás deles. O que é preciso para treinar, servir e escalar modelos? Tenho o prazer de moderar este painel. Gostaria de apresentar os participantes. Joanna Rencinch. Ela é cofundadora da Runway e vai nos dar a perspectiva dela sobre inference

01:02 e inference. Robert Nishihara é cofundador da Anyscale e também um dos criadores do Ray. Ele vai nos dar a perspectiva dele sobre orquestração. Infelizmente, Richard Alfons, da CoreWeave, não pôde estar conosco hoje. Então, esperamos que esteja tudo bem com ele. Certo. Vamos começar. Minha primeira pergunta é: vocês poderiam compartilhar conosco o que mais mudou

01:32 na infraestrutura de IA nos últimos dois anos, mais ou menos? Vou começar com você, Joanna. >> Claro. No início, a infraestrutura de IA era toda voltada para treinamento, certo? Ter os maiores clusters para treinar os maiores e melhores modelos. E, claro, isso continua: todo mundo ainda quer grandes clusters para treinar modelos. Mas agora, inference está se tornando a carga de trabalho dominante. E, quanto mais amplamente os modelos são adotados e mais passamos de uma pessoa fazendo algo para um enxame de agents iniciado por outro

02:04 agent que faz algo, o volume cresce exponencialmente. Isso significa que estamos chegando aos limites do que a infraestrutura consegue acomodar. Por isso estamos vendo todo mundo tentando construir data centers. Todos os data centers também estão sendo cancelados e colocados sob moratória. Então, agora há uma mudança em direção à distribuição de inference na borda. Isso é útil por dois motivos. Primeiro, modelos de mundo e modelos de robótica realmente se beneficiam de baixa latência e de inference na borda. Eles precisam estar perto de onde são

02:34 realmente consumidos. E, segundo, há muita energia disponível em muitos lugares. Então, às vezes é mais fácil levar a inference para onde a energia já está e aproximá-la do usuário do que construir esses clusters enormes, que exigem muitos recursos concentrados em um só lugar. >> Sim, isso é bem interessante. Obrigada pela sua perspectiva. Robert, e você, como vê isso? >> Com o Ray e a Anyscale, olhamos para o mundo pela perspectiva de

03:05 treinar modelos, sabe, fazer deploy de modelos, executar inference, executar cargas de trabalho de preparação de dados, executar aprendizado por reforço, esse tipo de carga de trabalho de IA. E, como a escala e os custos dessas cargas de trabalho cresceram imensamente, uma das coisas que mais mudou foi a importância, de certa forma, da integração vertical. Estamos acostumados a pensar numa separação clara entre as diferentes camadas da pilha de infraestrutura, desde as camadas de

03:36 software até o hardware. Mas, cada vez mais, o desenvolvedor de aplicações que está executando e construindo uma carga de trabalho de aprendizado por reforço vai precisar considerar falhas de hardware. Vai precisar estar ciente de como os diferentes processos que está gerenciando são mapeados para diferentes topologias de cluster e coisas do tipo, para obter o melhor desempenho e construir aplicações confiáveis. Então, temos visto uma tendência crescente em direção a

04:08 desenvolver essas aplicações, de certa forma, com uma abordagem de pilha completa. >> Hum. Certo, entendi. Então, desenvolver aplicações com uma abordagem de pilha completa é uma tendência que estamos vendo. Criar na borda em termos de energia e computação foi o que a Joanna compartilhou conosco. Isso é ótimo. Então, quero passar para você agora. Quando um modelo chega a um produto de verdade, certo? Quando conseguimos colocá-lo em produção, o que costuma surpreender mais as equipes em relação à velocidade e ao custo de servi-lo?

04:39 >> Sim, acho que saímos do paradigma de um grande modelo e passamos a ter uma arquitetura de modelos, certo? Há tarefas que são executadas por um modelo menor. Há também, sabe, agents que executam tipos de modelos muito específicos, e depois há modelos mais inteligentes que as pessoas usam para programação e coisas assim. Eles terão diferentes context windows. Então, estamos vendo as coisas seguirem para um workflow ou pipeline real

05:11 que precisa ser orquestrado. Todos esses workflows precisam ser distribuídos. Mas, no fim das contas, tudo acaba gerando mais demanda por computação. Acho que havia a expectativa de que os modelos ficariam mais eficientes e, então, usaríamos menos computação. O que está acontecendo é que os modelos ficam mais eficientes, nós os colocamos em mais coisas e acabamos gastando ainda mais do que antes, além de precisar de ainda mais computação. Então, acho que estamos começando a lidar com a realidade de que

05:42 isso não vai desaparecer. Precisamos resolver esse problema. >> Sim, interessante. E entendo o que você quer dizer: agora conseguimos fazer mais. Então, sim, vou continuar fazendo mais e vou precisar de mais computação. Certo. Robert, o que muda quando esse trabalho precisa ser escalado entre muitas máquinas e cargas de trabalho também? Gostaria de ouvir sua perspectiva. >> Sim. Na verdade, isso tem a ver com o motivo pelo qual criamos o Ray. >> Sim. >> Pensem no Ray. Se vocês ainda não

06:12 ouviram falar do Ray, ele é um framework de Python open source para basicamente construir aplicações distribuídas e escaláveis em Python. >> Aham. >> Certo? Estávamos fazendo pesquisa em Berkeley e precisávamos escalar nossas cargas de trabalho de IA, treinamento e assim por diante, entre clusters. Estávamos na mesma situação que muitas pessoas: sabíamos escrever programas em Python no nosso laptop, sabíamos que tipo de algoritmos queríamos expressar. Mas, quando você pega esse algoritmo e tenta executar a mesma coisa em grande escala, em um cluster,

06:44 acaba tendo que resolver uma série de novos desafios, certo? O mais básico é: como divido o trabalho entre as diferentes máquinas? Como posiciono o trabalho? Como movo dados com eficiência do ponto A ao ponto B? E se uma das máquinas travar? Como faço… Como minha aplicação lida com isso? Há todo tipo de questão relacionada à resiliência, eficiência e escalabilidade. Escrever programas para clusters acaba sendo muito mais complexo do que escrever um programa no seu

07:14 laptop. Começamos o Ray para tentar, basicamente, resolver alguns desses desafios para você. Se você é um desenvolvedor e sabe escrever um programa em Python, isso é tudo que precisa saber para executar a mesma coisa em um cluster, certo? Isso não é bem verdade. Estou exagerando, mas esse é o objetivo e é isso que estamos tentando alcançar. >> Entendi, entendi. Certo, ótimo. E o que eu gostaria de abordar agora é: o que acontece quando as coisas dão errado?

07:45 E vou continuar com você, Robert, se não se importar. Você poderia compartilhar com o público um exemplo concreto de algo que dá errado em escala? Também gostaríamos de saber como é a experiência do usuário ou do desenvolvedor. >> Sim. Essa é uma pergunta fascinante. Na verdade, tudo dá errado em escala. E não só…

08:15 E isso nos leva de volta ao meu ponto sobre integração vertical. É preciso pensar na detecção e no tratamento de falhas em todas as camadas da pilha, certo? Na camada de hardware, claro, podem ocorrer falhas de hardware. Às vezes, isso se manifesta como algum tipo de exceção do CUDA, uma exceção que você recebe na sua aplicação Python. >> Sim. >> Às vezes, pode se manifestar apenas como uma corrupção numérica silenciosa. Certo? Você está executando sua aplicação,

08:45 Não há sinal de nada, mas, na verdade, os dados estão sendo corrompidos. >> Sim. >> Ou isso pode resultar em um processo atrasado, certo? Podem ocorrer erros na camada do Kubernetes, em que os pods não são agendados ou demoram muito para iniciar. Você pode ter erros na camada do Ray, do PyTorch ou do vLLM. Pode haver erros na sua aplicação, certo? Pode haver erros na forma como tudo se integra. >> Um grande desafio é… quero dizer, há detecção de erros, como a localização do erro, e

09:17 simplesmente descobrir onde ocorreu o erro e, depois, é claro, fazer a mitigação. >> Sim. >> Do lado da detecção, claro, você tem verificações passivas de integridade em cada nó, mas uma das coisas mais interessantes de que falamos quando tratamos da integração vertical é que as pessoas também fazem muitas verificações de integridade no nível da aplicação. Por exemplo, mencionei que pode haver corrupção numérica silenciosa se algo der errado na sua GPU. Às vezes, na

09:48 sua aplicação, digamos que você esteja fazendo treinamento, pode haver vários momentos em que você recalcula o mesmo valor, certo? Talvez você tenha algumas ativações que está calculando na passagem forward. Sim. >> Essas ativações são descartadas e, na passagem backward, você as recalcula para evitar ter que armazená-las na memória. Para economizar memória da GPU. Se você calcular hashes dessas ativações e desses vetores e depois comparar os hashes quando os recalcular, poderá detectar se

10:19 houve uma possível corrupção, certo? E, assim, a própria aplicação pode ser quem percebe que algo está dando errado, mesmo que, sabe, todas as ferramentas de verificação de integridade da Nvidia não tenham detectado nada, certo? Portanto, há diferentes camadas da stack responsáveis pela detecção. Diferentes camadas da stack podem ser responsáveis por resolver o problema, certo? Talvez a primeira coisa que você deva tentar seja reiniciar a máquina ou, na verdade, encerrar a

10:50 aplicação e simplesmente mover a computação para outra GPU, algo que você pode fazer no nível da aplicação. Em parte, o que estou tentando mostrar aqui é que é muito difícil resolver apenas uma única camada da stack. >> Entendi. Entendi. Faz sentido. E, na verdade, dando continuidade a esse assunto, quero perguntar: ao observar onde as camadas se encontram, como eu chamo isso, seja na inference, na orquestração ou na escala, onde otimizar uma parte do sistema não funciona porque o que mais importa é o sistema inteiro? Vou passar essa pergunta para você, Yuana: onde otimizar uma parte do sistema falha porque o sistema inteiro é o que mais importa, certo?

11:21 >> Sim, acho que há tantas maneiras de otimizar a inference atualmente, e isso tem sido um objetivo tão perseguido que algumas das melhores pessoas do setor estão trabalhando nisso e fazendo avanços incríveis. >> Sim. >> Mas, no fim das contas, há um limite para o que se consegue com software. Se você não entender cada camada, como o software funciona no hardware, como o hardware se conecta entre si, como funciona a camada de rede subjacente e como sua arquitetura se conecta ao armazenamento e à rede desde o início, não conseguirá otimizar as coisas ao máximo. E, em determinado momento, mesmo que você otimize tudo o que puder, vai precisar ampliar o sistema. Acho que o ponto do Robert é que, em escala, tudo quebra. Como atendemos aplicações, servimos modelos para aplicações com milhões de usuários. Desde o início, processávamos bilhões de solicitações. Acho que encontramos todos os bugs e problemas imagináveis

11:52 que existem em todas as ferramentas que usamos. Então, em cada situação, era como: “Ah, nunca vimos isso acontecer.” E aí… >> Sim. >> [risos] >> E, mesmo quando você desce para camadas inferiores, começa a encontrar problemas com o firmware. Então, desde o início, otimizamos tudo, do BIOS ao kernel, na stack de inference. Mas depois fomos ainda mais fundo e dissemos: “Certo, basicamente, a forma como a GPU se comunica com a CPU: precisamos que a CPU tenha mais desempenho, porque o desempenho da CPU está

12:24 basicamente limitando a GPU. Precisamos que o sistema de resfriamento seja mais eficiente, porque a GPU fica entrando em proteção térmica. Você paga muito dinheiro por essas GPUs e quer mantê-las operando com a maior capacidade de processamento possível.” Foi assim que fomos descendo cada vez mais nas camadas, até acabar projetando nossos próprios servidores e nossos próprios data centers. Agora estamos expandindo nossos data centers modulares. Quando começamos, isso parecia absolutamente louco. Ninguém achava que fosse uma boa ideia para nós, mas, desde então, o que aconteceu foi que, mais uma vez,

12:55 o mundo da inference cresceu tanto que agora isso é meio que a solução perfeita, na hora perfeita, para expandir a inference na borda. Mas foi preciso muita convicção e confiança para chegar até aí. Mais uma vez: o sistema físico também fazia parte do que precisávamos expandir, não apenas o software. >> Entendi. Entendi. Certo, ótimo. Robert, e você? Adoraria ouvir sua opinião. >> Quero dizer, uma área em que vemos isso — otimizar a coisa errada ou não acompanhar

13:26 o panorama completo — é quando pensamos que há dois tipos distintos de problemas. Um é: o que preciso fazer para otimizar uma carga de trabalho individual, certo? Sou um único desenvolvedor tentando executar um único trabalho de treinamento em um único cluster. Há um conjunto de problemas que preciso resolver para tornar eficiente essa execução de treinamento. >> Sim. >> Agora, imagine que sou uma equipe tentando executar centenas ou milhares de trabalhos em muitos clusters.

13:57 >> Sim. >> Certo? E há um conjunto diferente de desafios, ou um conjunto complementar de desafios, que precisam ser resolvidos nesse caso. Você pode gastar toda a energia do mundo tentando reduzir o custo do seu trabalho de inference em lote ou do seu trabalho de treinamento ou da sua execução de RL. E aí talvez você realmente otimize seu trabalho de treinamento. Mas o trabalho termina e a capacidade de computação fica ociosa, certo? Por isso, uma das coisas mais importantes a configurar do ponto de vista da otimização de custos não são os aspectos internos da carga de trabalho.

14:27 Na verdade, são a priorização entre cargas de trabalho, a preempção e coisas assim. É muito natural, por exemplo, ter um trabalho de treinamento de alta prioridade que precisa ser agendado em conjunto com uma grande quantidade de recursos computacionais, tudo de uma vez, e executado com prioridade sobre todo o resto. Mas você também quer algum tipo de trabalhos de inference elásticos em segundo plano, ou outros tipos de trabalho, que possam simplesmente aproveitar toda a capacidade computacional não utilizada. E, se… E

14:59 se expandam para preencher tudo o que não estiver sendo usado, para que nunca haja ociosidade. Nada fica ocioso. Então, combinar essas duas coisas é extremamente importante. >> Entendi. >> Quero acrescentar algo a isso. Quando as pessoas obtêm infraestrutura de IA conosco, especialmente agora, muitos dos GPUs mais avançados têm um prazo de espera. Então, é preciso esperar meses para recebê-los. Quando estão encomendando um sistema totalmente novo, as pessoas tendem a comprar clusters de treinamento porque querem ter a possibilidade de fazer as duas coisas. Estão se comprometendo com esse cluster por 3 a 4

15:31 anos. Pensam: “Certo, quero… Sabe, posso fazer inference em um cluster de treinamento, mas não posso — sempre farei treinamento em um cluster dedicado à inference.” Então, a forma como pensam nisso é que terão um núcleo dedicado ao treinamento e depois acrescentarão inference por cima. Mas, essencialmente, o cluster será usado para as duas coisas. Não planejam que ele fique dedicado apenas ao treinamento, 24 horas por dia, 7 dias por semana, durante 3 a 4 anos. Então, acho muito importante pensar nisso como um sistema. E, até mesmo ao criar as ferramentas ou considerar as ferramentas, pensar: “Eu posso…

16:01 anos. Eles dizem: “Certo, quero… sabe, posso fazer inference em um cluster de treinamento, mas não posso… sempre vou fazer treinamento em um cluster exclusivo para inference.” Então, a forma como estão pensando nisso é que vão ter um núcleo de treinamento e depois meio que adicionar inference por cima. Mas, essencialmente, ele será usado para as duas coisas. Quer dizer, eles nunca planejaram simplesmente dizer: “Este cluster será usado apenas para treinamento, 24 horas por dia, 7 dias por semana, durante 3 a 4 anos.” Então, acho muito importante pensar nisso como um sistema. E, tipo, até mesmo desenvolver as ferramentas ou considerar as ferramentas de que eu posso

16:33 até revender essa capacidade quando ela estiver disponível, se eu não a usar. Hoje existem muitas soluções para isso. Estamos criando soluções para isso para nossos clientes, para que possam perguntar: “Vocês têm capacidade computacional?” Temos um produto sob demanda. >> Sim, faz muito sentido. >> Faz. Faz mesmo. E, na verdade, é preciso olhar para o sistema como um todo e não otimizar uma coisa de cada vez. Certo, isso foi muito esclarecedor. Agora, gostaria de passar ao que está faltando. Certo, olhando para o futuro, seja daqui a 1 a 3 anos. Três

17:04 anos é uma eternidade, então digamos de 1 a 2 anos. De que capacidade as equipes vão precisar mais, sabe, nesse período? O que, basicamente, a infraestrutura de hoje ainda faz mal? Então, olhando para o futuro, do que precisamos? O que está faltando? Do que precisamos? Vou começar com você, Robert. >> Sim. Bem, acho que já estamos vendo algumas tendências que serão muito mais

17:34 comuns daqui a um ou dois anos. Uma delas é a importância da heterogeneidade de hardware. Certo, hoje isso é um pouco mais acadêmico: vemos pessoas fazendo benchmarks que mostram, por exemplo, que, se eu dividir minha inferência em etapas de pré-preenchimento e decodificação, certo?, então posso notar que cada uma dessas etapas tem características de sistema diferentes, certo? A etapa de pré-preenchimento pode ser limitada pela computação, e minha etapa de inferência, ou de decodificação, pode ser mais limitada pela largura de banda da memória.

18:06 E assim posso esco— escolher tipos diferentes de aceleradores para etapas diferentes, para atender às características de desempenho e aos requisitos. Acho que veremos muito mais desagregação das cargas de trabalho em várias partes diferentes e, depois, a otimização do uso de diferentes tipos de recursos computacionais para partes diferentes da sua >> carga de trabalho, certo? >> E isso acontece, claro, no aprendizado por reforço, porque você >> Quer dizer, o aprendizado por reforço é

18:36 na verdade, um ótimo exemplo porque combina treinamento e inferência. >> Sim. >> Certo? E, muitas vezes, você executa sandboxes em larga escala em máquinas com CPU, e sua inferência pode ser dividida em pré-preenchimento e decodificação. Você também pode ter modelos de recompensa, nos quais a parte de inferência talvez exija uma taxa de transferência mais constante, mas os modelos de recompensa podem exigir uma demanda mais irregular e precisar de elasticidade. >> Uhum. >> E o treinamento pode ter características diferentes.

19:07 Então, todas essas coisas têm requisitos de hardware diferentes, estratégias diferentes para lidar com falhas e técnicas diferentes de otimização. É muito natural separá-las e gerenciá-las individualmente. Mas, é claro, há muita coordenação entre todas essas partes, certo? Elas não estão simplesmente funcionando isoladas. Você está constantemente sincronizando os pesos do treinamento para a inferência, trazendo as trajetórias de volta, empacotando-as em sequências, e há muito desse tipo de coisa que acho que vai se tornar cada vez mais complexa.

19:38 Entendi. Muito bom. Sabe, heterogeneidade de hardware: era nisso que eu estava pensando. Posso dizer essa palavra? Mas é isso mesmo. Aceleradores diferentes, considerando a carga de trabalho e qual parte dela talvez precise de um tipo diferente de computação. Você quer… E quanto à sua perspectiva sobre inferência? >> Também quero acrescentar algo que acho muito relevante, mas complementar a isso: também lidamos mais com os limites físicos. Então,

20:09 falei um pouco sobre isso no começo, mas um dos problemas é que não vão surgir usinas elétricas do nada daqui a dois anos, certo? Essas coisas levam de 5 a 10 anos para serem construídas. Então, vai ser preciso mudar a forma de pensar. Na verdade, essa mudança já está acontecendo: precisamos voltar a ir para onde há energia. Além disso, precisamos construir a infraestrutura para IA de outra maneira. Para tudo que você puder imaginar que um data center usa, há uma enorme

20:40 lista de espera. Geradores a diesel: anos. Transformadores: anos. Tudo. Componentes, tudo, sabe? Antes, era só memória. Havia escassez de memória; agora há escassez de praticamente tudo. Tudo é comprado com antecedência. Ainda não sentimos tanto essas escassezes, embora já tenhamos começado a senti-las no aumento dos preços do setor. Os preços da capacidade computacional dispararam. E acho que a realidade é que não haverá alívio de verdade num futuro próximo, porque esses são problemas que

21:11 levam anos para resolver, como construir uma fábrica de memória. De novo, é algo que leva uns 10 anos. Então, acho que a computação heterogênea é uma coisa, assim como distribuir outras plataformas e produzi-las em lugares diferentes. >> Sim. >> Mas, novamente, é preciso pensar no que já está disponível para usarmos. Sabe, podemos usar locais com capacidade de 5 megawatts, onde não preciso trocar o transformador? Podemos operar com um sistema mais simples, que não use água? Assim, não precisamos conectá-lo à

21:42 rede de água. Só precisamos de energia e internet, e pronto. Podemos essencialmente construir uma estrutura menor, para não precisarmos passar dois anos só com licenças e pedidos de autorização de planejamento? Começamos a pensar em todas essas restrições e montamos uma solução que, desde o início, não depende delas. E o que estamos descobrindo é que até empresas muito grandes >> Sim. >> estão compreendendo muito rapidamente que essa é a

22:12 nova realidade. >> Entendi. >> E a IA também não é um banco de dados. Sabe, as coisas que construímos para a geração dos bancos de dados, em que tudo precisa estar em conformidade com o nível três ou cinco, não necessariamente se aplicam ao mundo da IA. É interessante ver essa mudança: a infraestrutura deixa de ser um exercício de marcar itens numa lista, em que, se você não cumpre todos os padrões, a resposta é não. >> Uhum. >> E as pessoas passam a perguntar: como podemos fazer isso funcionar? >> Sim. >> [risos] >> Como podemos fazer isso funcionar? E, de novo,

22:43 pensávamos assim desde o início. É um ótimo momento, mas é interessante ver que tudo está se alinhando e que o problema é real. >> Entendi. Entendi. Muito legal. Certo, então, pensando no que está faltando, do que precisamos? Vou fazer minha última pergunta: talvez em uma frase, qual será o fator limitante daqui para a frente? Precisamos disso, mas qual será o fator limitante nos próximos três anos, na sua perspectiva? Vou começar com você,

23:14 Robert. >> Sim, bem, mencionei a tendência à integração vertical e à otimização de tudo em conjunto, e acho que isso é cada vez mais importante à medida que a escala e os custos aumentam. Uma das lições que aprendemos com Ray ao longo do tempo é que, normalmente, se você está desenvolvendo algum software ou software para sistemas distribuídos, como Ray, talvez pense que a importância do desempenho é óbvia, certo? A

23:44 importância da confiabilidade é óbvia. Mas uma coisa que talvez não tenhamos compreendido plenamente no início, e que hoje valorizamos muito, é a importância de o sistema ser compreensível. Tanto que, na verdade, damos a isso mais prioridade do que a qualquer outra coisa, inclusive desempenho e confiabilidade. Quer dizer, a confiabilidade também é essencial. Mas o motivo é que, para essas cargas de trabalho de grande escala,

24:14 mencionei que as coisas podem dar errado em todas as camadas da pilha, certo? Se você está fazendo treinamento de modelos grandes, inferência ou qualquer outra coisa, está num estado constante de depuração. >> Sim. >> Certo? E, se você está constantemente depurando e tentando descobrir o que deu errado em cada camada da pilha, >> Sim. >> precisa entender cada componente. >> Sim. >> E, se uma parte importante dessa pilha for uma caixa-preta, que você não entende de verdade, cujo comportamento é imprevisível e que você não sabe como funciona, >> Sim. >>

24:44 Em algum momento, isso simplesmente não vai funcionar para você, certo? E isso vai ser um fator limitante, certo? Então, ao projetarmos esses sistemas, nós realmente os projetamos tendo a compreensibilidade e a previsibilidade como prioridades máximas. >> Entendi. Obrigado. Se não se importar, você poderia responder talvez em uma frase? >> Uma resposta rápida. Mencionei antes que uma das minhas amigas fez uma observação interessante. Ela disse que os LLMs transformaram o trabalho em uma máquina caça-níqueis. Sabe, você insere um prompt, o trabalho aparece e, às vezes,

25:15 você ganha e, às vezes, não, e pode tentar de novo. Então, acho que isso está acontecendo agora com pessoas como nós aqui, sabe, pessoas do Sul, pessoas das grandes cidades, pessoas da área de tecnologia, mas acho que a adoção mundial ainda está por vir, e acho que ainda estamos prestes a vivenciar a intensidade com que essa onda vai chegar. >> [fungada] >> Incrível. Yuwana, Robert, muito obrigado pelas ideias e contribuições. Ao público, obrigado por nos ouvir. Vamos aplaudi-los bastante. Muito obrigado. >> Obrigado.

Transcrição original

[00:00] Please welcome to the stage Anyscale co-founder, Robert Nishihara, CoreWeave SVP of Physical AI, Richard Alfons, Runway co-founder, Joanna Rencinch, and AWS Managing Director, Cherieus Abuashi. >> [music] >> Good afternoon. I’m Cherieus Abuashi. I am a Managing Director at Amazon Web Services. I lead our North America Solutions Architecture team.

[00:31] Great models get the headlines. But today, we are going to look underneath them. What does it take to train, serve, and scale models? Uh I have the pleasure to moderate this panel here. I’d like to introduce the panelists for you. Joanna uh uh Rencinch. Uh she’s the co-founder of Runway, and she’s going to give us uh her perspective from an inference

[01:02] perspective. Robert Nishihara is the co-founder of Anyscale, and also one of the creators of Ray. Uh he’s going to give us his perspective from an orchestration. Unfortunately, uh Richard Alfons from uh CoreWeave couldn’t be with us today. So, uh uh we hope everything is good with him. All right. So, let’s get started. Uh my first question is if you could share with us what changed

[01:32] most about AI infrastructure in the past 2 years or so. Let me start with you, Joanna. >> Sure. So, AI infrastructure initially was all about training, right? Having the biggest clusters to train the biggest and best models. And of course, this is still like everybody still wants big clusters to train models. But now, inference is becoming the dominant workload. Um and also, the more widely adopted the models are, and the more we go from one person doing something to a swarm of agents um initiated by another

[02:04] agent uh does something, the volume is growing exponentially. This means that we’re hitting the limits of what the infrastructure can accommodate. That’s why we’re seeing like everybody’s trying to build data centers. All the data centers are also getting canceled and getting under moratorium. So now there’s a shift towards distributing inference on the edge. And this is useful for two reasons. One, uh world models, robotics models, they really benefit for a look from low latency and edge inference. They need to be close to where they’re

[02:34] actually consumed. Um and two, there’s actually a lot of power in a lot of places. So it’s sometimes the easier to kind of take the inference where the power already is and take it closer to the user than kind of build from these massive massive clusters that require a lot of resources in one place. >> Yeah, that’s pretty interesting. Thank you for your perspective. Uh Robert, how about you from your side? >> So with Ray and Anyscale, we really um look at the world through the lens of

[03:05] training models, you know, deploying models, running inference, running data preparation workloads, running reinforcement learning, um these types of AI workloads. And as the scale and costs of these workloads has just grown immensely, um one of the things that’s changed the most is this the importance of vertical integration in some sense. So um you are or we’re used to thinking of a clean separation of different layers of the um infrastructure stack from

[03:36] software layers to the hardware. But um increasingly, you know, the application developer who’s running building a reinforcement learning workload is going to have to reason about um hardware failures. They’re going to have to be aware of how they’re, you know, the different processes that they’re managing are mapping on to um different cluster topologies and things like that to get the most performance um and to and to build reliable applications. And so, we’ve seen um a increasing trend toward

[04:08] the um you know, kind of developing these applications in a full stack way. >> Mm. Okay. Got it. So, developing the applications from a full stack is where where we’re seeing it being creative on edge in terms of power and compute is is what Dayana shared with us. That’s awesome. So, you want to I’m going to go to you uh next, which is when a model moves into a real product, right? When we’re able to put it into production and

[04:39] what tends to surprise teams most about serving it in terms of speed and cost? >> Yeah, I think we’ve moved from this paradigm of one large model to there is an architecture of models, right? There is some tasks that are handled by a smaller model. Um there is a you know, again, agents that run like some very specific model types and then there is like more intelligent models that people use for coding and so on. They’ll have different context windows. So, we’re seeing um things go to a real workflow or pipeline

[05:11] that actually needs to be orchestrated. All those workflows need to be distributed. But, ultimately everything just generates more demand for compute. I think there was an assumption that oh, the models will get more efficient and then we will use less compute. What is happening is the models get more efficient, we put them into more things and then you spend even more than you did before and you need even more compute. So, I think we’re now starting to grapple with the reality of like oh,

[05:42] this is really not going anywhere. We need to solve this problem. >> Yeah, that’s interesting. Uh and I hear you, right? Uh, yes, uh, we can uh, do more now. So, yes, I’ll I’ll keep doing and and need more compute. All right. So, Robert, uh, what changes when that work has to scale across many machines and workloads as well? Would love to hear your perspective. >> Yeah. I mean, this actually gets at why we created Ray in the first place. >> Yeah. >> You can think of Ray, so if you haven’t

[06:12] heard of Ray, Ray is a open-source uh, Python framework for basically building, you know, scalable distributed Python applications. >> Mhm. >> Right? And so, we were doing research at Berkeley, needed to scale our AI workloads, training, and so forth across clusters. And we were in the situation a lot of people were where we knew how to write Python programs on our laptop, like we knew what kind of algorithms we wanted to express. But then when you take that algorithm and you try to run the same thing across at a large scale, across a cluster, you

[06:44] end up needing to solve a ton of new challenges, right? Like, the most basic is just how do I divide up the work across the different machines? How do I place the work? How do I move data efficiently from, you know, point A to point B? Um, what if one of the machines crashes? How do I How does my application deal with that? Um, all sorts of questions around resilience and efficiency and scalability. Um, and so, programming writing programs for clusters just ends up being way more complex than writing a program on your

[07:14] laptop. And we started Ray to try to um, basically solve some of those challenges for you. So, if you are um, if you’re a developer, you know how to write a Python program, you can that’s all you need to know in order to run the same thing on a cluster, right? That’s not quite true. It’s it’s I’m exaggerating, but um, that’s the goal and those are the kinds of that that’s what we’re trying to achieve. >> I see. I see. Okay, great. And so, what I’d like to move to next is, like, okay, so when things break, okay?

[07:45] And I’m going to stay with you, Robert, if you don’t mind. So, if you can share with the audience here a concrete example of something that breaks at scale. Uh in in we’d like to see like what is the user or developer experience, you know, as well. >> Yeah. Um that is a It’s a fascinating question. Um truly everything breaks at scale. And not just

[08:15] um And this gets back to my point about vertical integration. You have to think about failure detection and failure handling at every layer of the stack, right? So, at the hardware layer, um you can have, of course, uh um you can have hardware failures. You can Sometimes that manifests itself in in some kind of CUDA, you know, exception an exception you get in your Python application. >> Yeah. >> Sometimes it could manifest itself just in um silent numerical corruption. Right? You’re running your application,

[08:45] there’s no sign of anything, um but actually the data’s getting corrupted. >> Yes. >> Or could result in a straggler. Right? You have errors that can happen at the like Kubernetes layer, where um pods are not getting scheduled or taking too long at startup. You can You can have errors at the kind of like Ray or or PyTorch or vLLM layer. You can have errors in your application. Right? You can have errors in how everything comes together. >> Um >> A big challenge is um I mean, there’s error detection, like, error

[09:17] localization, and just figuring out where the error was, and then, of course, the actual uh mitigation. >> Yeah. >> On the um detection side, you want to like, of course, there are passive health checks you do on every node, but one of the most interesting things we talk about vertical integration, um there’s a lot of application level health checking that people do as well. For example, I mentioned you can have silent numerical corruption um if something’s going wrong on your GPU. Sometimes in

[09:48] your application, say you’re doing training, um there might be multiple times when you uh recompute the same value, right? You might have some activations in that you’re computing your forward pass. Yeah. >> That um you then throw away and then on your backwards pass you actually recompute those activations um to avoid having to store them in memory. To save GPU memory. And if you compute hashes of those activations and those vectors and then compare the hashes when you recompute them, um you can detect if

[10:19] potentially if something was corrupted, right? And and so the application may actually be the one that notices um that something’s going wrong, even though they’re like, you know, all the Nvidia health checking uh tools you have didn’t didn’t catch anything, right? And so there’s different layers of the stack that are responsible for detection. There’s different layers of the stack that may be responsible for addressing the issue, right? Maybe the issue is like the first thing you should try is rebooting the machine or maybe um it’s actually uh like terminating the

[10:50] application and and just use moving the compute to a different GPU, which you can do at the application level. Um Part of the what I’m trying to depict here is that um it’s really hard to solve just a a single layer of the stack. >> I see. I see. It makes sense. And actually continuing on that uh thread uh is I want to as I look at the where the layers meet, I call it, right? Whether it’s it’s on the inference or or or the orchestration or the scaling, where does optimizing, I’m going to go

[11:21] to you with this uh Yuana, where does optimizing one part of the system fail because the whole system matters most, right? >> Yeah, I I think um everybody there’s so many ways to optimize the inference right now and it’s been such a pursuit that some of the best people in the industry are working on this making some incredible strides. >> Yeah. >> But ultimately there’s only so much that you can get from software. Like if you don’t understand every layer, how the software works on the hardware, how the hardware connects to each other, how like the underneath

[11:52] layer of networking, how your architecture to the storage and the networking is in the first place. You will not really be able to optimize things to their highest extent and to at some point even so you’ll optimize the most that you can, you’ll just need to extend the system. I think Robert’s point at scale everything breaks. So we were running at because we serve application we survey models for applications with millions of users. We were running like billions of requests from the beginning. I think we hit every bug and managed imaginable

[12:24] [clears throat] in every tool we used. So every situation we had was like, oh we never see this. It’s like, well. >> Yeah. >> [laughter] >> Um like so and even when you go below that you start to hit issues with like firmware. So we from the beginning optimize from like the BIOS to the kernel on the inference stack but then we went even lower and said, okay, basically the way that the GPU talks to the to the CPU we need the CPU to be higher performance because the performance of the CPU is

[12:55] basically inhibiting the the GPU. We need the cooling system to be more efficient because the GPU keeps getting put in thermal protection. You pay a lot of money for these GPUs you want to keep them performing at the highest throughput possible. So that’s kind of how we went lower and lower ended up designing our own servers, ended up designing our own data centers and now we’re scaling our modular data centers. Which when we started to do it seemed absolutely crazy. Like nobody really thought this was a good idea for us but since then what’s happened is that again

[13:26] the world of inference has grown so much that now it’s kind of the perfect thing at the perfect time for scaling edge inference. But it took a lot of conviction and belief to get there. That again, that the physical system was also part of what we needed to scale, not just the software. >> I see. I see. Okay, great. Robert, how about I’d love to hear your >> I mean, one area where we see this, you know, optimizing the the wrong thing or not keeping track

[13:57] of the whole picture is when you think about there are two distinct types of problems that we think about. One is what do I need to do to optimize an individual workload, right? I’m one one developer trying to run one training job on one cluster. There’s a set of problems I have to solve to make that one training run efficient. >> Yeah. >> And then imagine now I’m a team of people trying to run hundreds or thousands of jobs across you know, many clusters.

[14:27] >> Yeah. >> Right? And there’s a different set of challenges or complementary set of challenges that need to be solved there. And you can spend all the energy in the world trying to reduce cost for your, you know, your batch inference job [clears throat] or your training job or your RL run. And then, you know, maybe you really optimize your training job. But then the job finishes and the compute sitting idle, right? And so one of the most important things to set up from a cost optimization perspective is not the inside of the workload stuff.

[14:59] It’s actually the cross workload prioritization and preemption and things like that. And so it’s very natural to you know, maybe you have your high priority training run that needs to get gang scheduled with a large amount of compute all at once and run and you know, have priority over everything else. Um but then you also want some sort of background elastic um inference jobs or other types of jobs that can just soak up all the unused compute. And if And

[15:31] just expand to fill whatever’s not being used, so that you’re never idle. Nothing’s ever idle. So, the getting mixing those two is super important. >> I see. >> I want to add something to that. We see So, when people get AI infra from us, especially now that a lot of the top-of-the-line GPUs, there’s a wait time for them. So, you have to wait months to get them. When you’re ordering a completely new system, people tend to buy training clusters because they want to have the possibility to do both. They’re committing to this cluster for 3 to 4

[16:01] years. They’re like, “Okay, I want I just you know, I can do inference on a training cluster, but I can’t do I will always do training on a pure inference cluster.” So, the way they’re thinking about it is they’re going to get a core of training and then kind of add inference on top of that. But, essentially, what it will be used for is both. Like, they’re never planned to just be like, “This cluster will just be training 24/7 for 3 to 4 years.” So, I I think it’s very important thinking of it as a system. And like, even building the tools or considering the tools of I can

[16:33] even resell this capacity when it is available if I don’t use it. There’s so many solutions for that now. We’re building solutions for that now for our clients to be like, “Do you have compute?” Like, we have an on-demand product. >> Yeah, that makes a lot of sense. >> It does. It does. And and really look at the whole overall system and just don’t optimize one thing at a time. Okay, so very insightful. Um I would like to move now into what’s missing. Okay, as we look ahead, um whether it’s 1 to 3 years from now. 3

[17:04] years is a lifetime, so let’s say 1 to 2 years. What capability will teams need more, you know, from that What What basically still have our today’s infrastructure handles poorly. So, as we look ahead, what do we need? What’s missing? What do we need? So, I’ll start with you, Robert, on that. >> Yeah. Well, I think there’s some trends we’re seeing already today that will be um far more

[17:34] prevalent, you know, in a year or two. Um one is just the importance of hardware heterogeneity. Okay, so today it’s a little more academic where you’ll see uh people do benchmarks showing that um for example, if I split my inference into um prefill and decode stages, right? Then I might uh there are different sort of systems characteristics of each of these stages, right? My prefill part might be more compute bound and my inference part or my decode part might be more like memory

[18:06] bandwidth bound. And so, I can opti- like choose different accelerator types for different stages to uh match the the performance charac- the requirements. Um I think you’re going to see far more uh disaggregation of workloads into multiple different pieces and then optimization of like usage of different um types of compute for different parts of your >> parts of that workload, okay. >> Um and you see this for for reinforcement learning, of course, because you >> I mean, it it reinforcement learning is

[18:36] actually a great example because it mixes training um and inference, >> Yeah. >> right? And um you know, you’ve often run large-scale sandboxes on uh CPU machines and your inference might be split into prefill and decode. You might also have reward models, which are you know, the inference part might be more um consistent throughput, but then your reward models might require be more bursty and and want some elasticity. >> Mhm. >> Um and then like training might uh you know, has different characteristics. And

[19:07] so, um all of these different things have different uh hardware requirements, different like failure handling strategies, different, you know, optimization techniques, and it’s very natural to split them out and and manage them separately. But then, of course, there’s a ton of coordination between all of these pieces, right? They’re not just running in isolation. They’re you’re constantly doing weight sync from your training to your inference, you’re moving rollouts uh back, you’re packing the rollouts into sequences, and there’s a um

[19:38] a lot of uh that type of stuff that I think is just going to become more and more uh complex. >> I see. Very good. You know, hardware heterogeneity, that’s what I was thinking. Can I say that word? But that’s what it is. Different accelerators looking at the workload and what part of that workload needs maybe a different type of compute for it. Uh you want to How about the from your perspective from an inference >> So, it’s also add something that I think is very relevant, but something complementary to that is we deal also more with the physical limits. So, I

[20:09] spoke a bit about um this in the beginning, but one of the issues is there’s not going to be more power plants magically in 2 years, right? These things like take 5 to 10 years to build. Um so, there’s going to have to be a change in the Actually, there’s this active change of thinking right now that we have to again go on the edge where the power is. But additionally, um we have to build the infrastructure for AI differently. For everything that you can imagine that a data center uses, there’s a massive

[20:40] waitlist. That like diesel generators years, transformers years, like everything. Um components like everything, you know, for It used to be just memories. Like the memory shortage, now there’s a shortage for pretty much anything. Um everything gets bought out in advance. We don’t really feel these shortages as as much yet, though we have started to in the increase in pricing in the industry. Prices have grown like crazy for compute. And I think the reality is that no real relief coming in the immediate future because these are problems that

[21:11] take years to solve like building a memory factory. Again, it’s like a 10-year thing. So, I think heterogeneous compute is one thing like distribution of other platforms and producing these in different places. >> Yeah. >> But again, looking at what can we use that is already there? You know, again, can we use sites that are like 5 megawatts that where I don’t need to upgrade the transformer? Can we operate with a system that is more simplified that doesn’t use water? Um And then we don’t need to connect it to

[21:42] the water mains. We just have power and internet and that’s it. Um can we essentially build with a smaller structure so we don’t need to do 2 years of just permitting and planning applications. We kind of started with thinking about all of these restrictions and we put together you know, a solution that from the beginning doesn’t doesn’t need them. And what we’re finding is that even very large enterprise >> Yeah. >> um enterprises are very rapidly coming to grips with the fact that this is the

[22:12] new reality. >> I see. >> Um and this and also AI is not a database. You know, like the things that we built for the database generation where everything has to be like, you know, tier three or tier five does not necessarily need to apply in the AI world. It’s interesting to see this shift from infrastructure being a box-ticking exercise or if you’re not compliant with every single standard, it’s a no. >> Mhm. >> To kind of people moving towards how can we get this to work? >> Yes. >> [laughter] >> How can we get this to work? And again,

[22:43] we were thinking like that from the beginning. It’s a great moment, but it’s interesting to see that everything is following and the problem is real. >> I see. I see. Very cool. All right, so this is looking at say what’s missing, what do we need? I’m going to go to my last question, which is maybe in one phrase what’s going to be the limiting factor as you look ahead? Like this is what we need, but what’s the limiting factor in in in the next 3 years that you you see on your horizon? I’ll start with you,

[23:14] Robert. >> Yeah, um well, you know, I mentioned the trend toward vertical integration and just optimizing everything together, and I think that’s increasingly important as scale and cost just grow. Um one of the lessons we’ve learned with Ray over time is that normally if you’re if you’re building some um software or some distributed system software like Ray, you might think about it’s obvious the importance of performance is obvious, right? The

[23:44] importance of reliability is obvious. Um but one thing that we maybe didn’t fully appreciate early on and that we very much appreciate is the importance of understandability of the system. And so much so that we actually put a premium on that above everything else, you know, including performance and reliability I mean well reliability is is is essential as well. But um the reason is that for these large

[24:14] workloads, um I mentioned things can go wrong at every layer of the stack, right? If you’re doing large model training or inference or anything, you are in a you are in a constant state of debugging. >> Yes. >> Right? And if you’re in a constant state of debugging and trying to figure out what went wrong at which layer of the stack, >> Yeah. >> you need to understand every single component. >> Yeah. >> And if there’s a component, a big part of that stack that is um a black box and you don’t really understand, it’s not predictable, you don’t understand how it behaves, >> Yes. >> um

[24:44] at some point, uh that’s just not going to work for you, right? And that’s going to be a a limiting factor, right? And so as we design these systems, it’s we really design them with understandability and predictability as like the higher order bit. >> Got it. Thank you. You want to maybe in in one phrase if you don’t mind. >> A quick answer. I mentioned earlier one of my friends did something interesting. She said that LLMs have turned work into a slot machine. You know, like put prompt in, work jumps out and sometimes

[25:15] you win and sometimes you don’t and you get to try again. So, I think this is just now being done by like us here, you know, people in the South, people in big cities, people in tech, but I think the worldwide adoption is still fully coming and I think the level at which this wave will hit is still >> [snorts] >> like about to be experienced. >> Awesome. Yuwana, Robert, thank you so much for your insights. For the audience, thank you for listening to us. Let’s give them a big round of applause. Thank you so much. >> Thank you.