AI Engineer Paris 2026 — Palco principal: Google DeepMind, ElevenLabs, Hugging Face e Stripe | Dia 2

Ver no idioma original →

Autoria: AI Engineer · Assistir no YouTube

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: AI Engineer Paris 2026 Main Stage: Google DeepMind, ElevenLabs, Hugging Face & Stripe | Day 2 · Canal: AI Engineer · 8:42:48 · Assistir no YouTube

Tópicos: Agentes de IA, Aplicações empresariais de IA, Inferência e otimização de modelos, Modelos multimodais, Robótica e sistemas autônomos

Resumo

No segundo dia do AI Engineer Paris 2026, palestrantes exploram como adaptar modelos de mídia generativa para controlar robôs, criar identidades visuais para vozes e executar modelos do Transformers com eficiência no vLLM. As apresentações também abordam o impacto da IA nos negócios, a infraestrutura de inference, modelos locais, diarização em tempo real e agentes de programação para grandes bases de código. Entre os temas recorrentes estão otimização de latência e custos, segurança, escalabilidade e formas de integrar IA aos produtos. O evento termina com iniciativas de educação em IA para crianças e uma apresentação sobre armazenamento para cargas de trabalho de IA.

Pontos-chave

• A Black Forest Labs adapta o Flux com prompt upsampling, configurações de moderação e fine-tuning para prever ações e controlar robôs.
• A ElevenLabs construiu um sistema que associa características de voz a orbs visuais, com geração, revisão e distribuição em grande escala.
• O backend de modelagem do Transformers no vLLM combina definições de modelos do Hugging Face Transformers com módulos de execução e otimização do vLLM.
• Segundo os dados apresentados pela Stripe, empresas de IA estão lançando produtos mais rápido, vendendo globalmente desde o início e adotando modelos de preços híbridos.
• A diarização em tempo real exige estratégias diferentes do processamento em lote; a apresentação da Piano AI descreve um sistema com latência de cerca de 400 milissegundos.
• A otimização de inference de baixa latência começa pela compreensão da carga de trabalho e do hardware, antes de avançar para técnicas como speculative decoding e quantização.
• Modelos pequenos e hardware acessível permitem executar IA na edge, com possíveis vantagens de privacidade, personalização e resposta rápida.
• O agentic map reduce divide tarefas amplas de análise de bases de código em seletores determinísticos, subagents paralelos e uma etapa de consolidação.
• Revisões automatizadas, verificações determinísticas e retrospectivas podem ajudar equipes a lidar com o aumento do volume de pull requests.
• As apresentações sobre Gemma 4 e Gradium destacam eficiência de modelos, geração de fala rápida e os desafios de escalar IA conversacional.

Capítulos

Início	Capítulo	Resumo
16:15	Abertura e apresentação da Black Forest Labs	O mestre de cerimônias abre o segundo dia e apresenta a palestra sobre adaptar modelos de mídia generativa para robótica.
18:18	Personalização do Flux: prompts e moderação	Jakob aborda prompt upsampling para atender requisitos de design e explica opções para configurar ou incorporar moderação.
35:37	Flux Action e controle de robôs	A palestra mostra como o Flux foi adaptado para prever ações e controlar um braço robótico em tarefas de pegar e posicionar objetos.
44:00	Orbs visuais para vozes na ElevenLabs	Dorian Lods explica como a empresa desenvolveu identidades visuais dinâmicas para representar vozes em diferentes produtos.
1:09:15	Como o Transformers é executado no vLLM	Harry Miller detalha a integração do backend de modelagem do Transformers com os módulos otimizados do vLLM.
2:18:56	IA e novos modelos de negócio	Ariel Lubai apresenta dados da Stripe sobre crescimento, expansão global, preços baseados em uso, canais de venda e fraude.
2:50:01	Diarização de fala em tempo real	A palestra explica segmentação, identificação de falantes, latência e os desafios de transformar diarização em lote em streaming.
4:50:11	Infraestrutura de IA: Mistral e NVIDIA	Yan Leger e Adolf Hall discutem GPUs, CPUs, infraestrutura em escala de rack, custos de inference e expansão de data centers na Europa.
5:17:45	Otimização de inference com Modal	Charles Fry apresenta técnicas para reduzir latência e custos, incluindo speculative decoding, quantização e roteamento atento ao KV cache.
5:43:42	Modelos de IA na edge	Dominic Payak explora dispositivos locais, modelos pequenos, robótica e aplicações que combinam inference na edge e na nuvem.
6:07:19	Agentic map reduce para bases de código	Cognition descreve como dividir análises amplas de segurança e outras tarefas de código entre subagents e uma etapa de consolidação.
7:14:50	Como reduzir o gargalo de revisão de PRs	Matt Pocock propõe combinar verificações automatizadas, revisão por agents e revisão humana para melhorar a qualidade e o fluxo de pull requests.
7:40:21	Eficiência e arquitetura do Gemma 4	Martin apresenta técnicas para reduzir memória e latência, além de explicar modelos de difusão e suas aplicações em classificação e decisão.
8:07:41	A camada que falta na IA conversacional	Olivia Tubul explica arquiteturas de fala, modelos speech-to-speech e desafios de latência, distribuição e inference em dispositivos.
8:31:24	Oficinas de IA para crianças e encerramento	Cassandra Chin relata oficinas em que crianças criaram jogos com IA; o evento termina com agradecimentos e uma apresentação da Backblaze.

Citações

Personalizações eficazes são tão específicas quanto necessário e tão gerais quanto possível. — 41:50

Construa, venda e itere ao mesmo tempo. — 2:30:23

A diarização em lote e a diarização em tempo real são, na verdade, dois problemas diferentes de machine learning. — 3:10:25

A revisão automatizada deve fazer commits: ela deve corrigir o que encontrar. — 7:33:05

A IA funciona com GPUs. As GPUs precisam de dados. — 8:40:14

Conceitos e entidades

• Flux (modelo): Família de modelos de imagem e vídeo da Black Forest Labs, apresentada também como base para prever ações e controlar robôs.
• Black Forest Labs (empresa): Laboratório de pesquisa alemão que desenvolve modelos de imagem e vídeo e apresentou adaptações do Flux.
• ElevenLabs (empresa): Empresa de IA de voz que apresentou um sistema de identidades visuais dinâmicas para vozes.
• Hugging Face (empresa): Empresa e comunidade de IA cujo Transformers pode ser integrado ao vLLM por meio de um backend de modelagem.
• vLLM (ferramenta): Mecanismo open source de inference de LLM apresentado como responsável pela execução otimizada de modelos.
• Stripe (empresa): Empresa de pagamentos que compartilhou dados sobre crescimento, preços, expansão internacional e fraude em negócios de IA.
• Piano AI (empresa): Empresa que apresentou técnicas de diarização em lote e em tempo real para identificar quem fala em conversas.
• Modal (empresa): Plataforma de infraestrutura que apresentou estratégias para otimizar inference de baixa latência e processamento de grandes volumes.
• Cognition (empresa): Laboratório de pesquisa aplicada em IA que apresentou o agentic map reduce para tarefas em grandes bases de código.
• Gemma 4 (modelo): Família de modelos apresentada com técnicas de eficiência, incluindo per-layer embeddings, quantização e speculative decoding.

Tradução completa (pt-BR)

16:15 Senhoras e senhores, por favor, deem as boas-vindas ao palco ao mestre de cerimônias do AI Engineer Paris 2026, engenheiro de relações com desenvolvedores na Replit, Rou Chevrey. Bom dia. Testando o microfone. Bom dia a todos. Como vão? Ei, isso está com cara de energia de segundo dia, então precisamos animar um pouco. Certo. Como vão

16:46 todos? >> É. Legal, legal, legal. Bom, bem-vindos ao segundo dia do AI Engineer Paris. Certo. Quem esteve conosco ontem? Levantem a mão. Certo, a maioria de vocês. Que ótimo. Ontem, falamos sobre como pensar na evolução da tecnologia e pensar na IA hoje. Depois, conversamos sobre o futuro da IA: o futuro das fábricas de software e também o futuro dos modelos de fronteira. Mas estou particularmente

17:17 animado com hoje. Hoje vamos falar sobre mídia generativa e, de novo, sobre fábricas de software. Vamos falar sobre RAGs em grafo e abordar muito mais. Então, com isso, quero que pensem no que gostariam de ver. Prestem atenção a tudo o que será dito aqui. Nossos palestrantes vão ficar por aqui. Então, aproveitem também para ir à exposição e conversar com todo mundo, para aprender o máximo possível. Certo.

17:47 Então, vocês já conhecem o procedimento, se estavam aqui, certo? Este evento não seria possível sem a Mrol. Então, gostaria de pedir uma salva de palmas para eles. Vamos aplaudir a M. Obrigado por organizar o evento. E vamos aplaudir nossos patrocinadores: nosso patrocinador platina, Nvidia. Isso, por favor. Continuem. E também todos os nossos patrocinadores ouro, prata, bronze e os patrocinadores de apoio. Vamos aplaudi-los mais uma vez. Isso, obrigado. Certo. Então, sem mais

18:18 delongas, nosso próximo palestrante é da Black Forest Labs e tem uma certa mania: adora ir ao dentista. Não sei por quê. Talvez possamos perguntar depois. Mas ele vai falar sobre como passaram da geração de imagens para a robótica. Então, por favor, deem as boas-vindas ao palco a Yakob Porchman. Muito obrigado. É muito bom conhecer

18:50 vocês todos. Só preciso dos meus slides, talvez aqui. Ótimo. É muito bom conhecer todos vocês. Meu nome é Jakob. Lidero a equipe de soluções de IA. Ela é a equipe de engenharia de implantação e a equipe de engenharia de soluções da Black Forest Labs. E gostaria de começar com uma pergunta que espero que seja simples. Levantem a mão rapidamente: quem já gerou uma imagem ou um vídeo usando IA? Só levantem a mão rapidamente. Essa deve ser fácil. Vamos lá. Isso é

19:22 quase todo mundo, espero. E, se já geraram uma imagem ou um vídeo, espero que tenham tido contato com o Flux ou com a Black Forest Labs, porque somos um laboratório de pesquisa sediado na Alemanha e desenvolvemos modelos fundamentais de imagem e vídeo para geração de imagens. Vocês podem ver aqui atrás algumas amostras, vídeos e imagens gerados com nosso modelo recente, Flux 3. Agora, a segunda pergunta que tenho para

19:52 vocês é: quem acreditaria em mim se eu dissesse que dá para usar esse mesmo modelo de vídeo para também controlar robôs e jogar videogames? Certo, algumas pessoas, mas não todo mundo. Bem, é uma pergunta meio retórica, obviamente. Caso contrário, eu não estaria falando disso, porque é exatamente esse o ponto com que vou concluir hoje: como vamos personalizar o Flux para não só gerar mídia, imagens e vídeos, e também editá-los, mas vamos falar

20:25 sobre como controlar videogames e robôs com ele. Aqui vocês podem ver duas amostras diferentes, que também foram geradas com Flux. À esquerda, o Flux está jogando um videogame. Então, não é apenas um vídeo gerado: o Flux está efetivamente assumindo o controle e gerando os quadros que aparecem. À direita, vocês veem um Lero realizando tarefas de pegar e posicionar objetos, com o Flux — nosso modelo de vídeo Flux 3 — como base de inteligência. E o que há entre a geração de vídeo e o uso do Flux como base para um robô é exatamente o que vamos discutir hoje, porque o que fica entre essas duas coisas, o que basicamente faz a ponte entre elas, é a personalização desse modelo Flux. Temos um modelo muito poderoso que pré-treinamos e treinamos em etapas intermediárias para, essencialmente, compreender o mundo visual e entender como os objetos se comportam nele. Pegamos esse modelo e o personalizamos para determinados casos de uso.

20:55 E é exatamente isso que também fazemos na nossa equipe de soluções de IA. É sobre isso que quero falar com vocês, dividindo o assunto em algumas etapas. Antes de chegarmos aos robôs, que serão a parte final da nossa conversa, quero falar um pouco sobre a anatomia do pipeline de inference, porque isso também vai dar uma visão geral das formas de personalização que temos ao trabalhar com Flux e conversar com clientes corporativos que querem usá-lo para casos de uso muito

21:27 específicos. Isso se divide em aproximadamente seis etapas. Primeiro, claro, há uma entrada do usuário que pode ser otimizada. Geralmente, é um prompt de texto, um prompt de imagem ou um prompt de vídeo, algo bem simples, certo? A segunda etapa é a expansão do prompt. Isso significa, essencialmente, que há um LLM ou VLM entre o prompt enviado pelo usuário e o modelo Flux. Tentamos entender a intenção. Tentamos entender o que o usuário realmente quer fazer e melhorar o prompt

21:58 para que o modelo gere algo mais próximo do que o usuário realmente pretende. Depois, há a moderação. Talvez vocês se surpreendam ao ver a moderação quando falamos de personalização de um modelo. Na verdade, a moderação é uma das superfícies de produto mais importantes, porque basicamente decide o que vocês vão ver e o que não vão ver. Na maioria das vezes, ela não faz parte do modelo, mas faz parte da experiência do usuário. Vamos falar um pouco sobre como a personalizamos e também sobre como incorporamos a moderação aos pesos do modelo. Em quarto lugar, há

22:30 o modelo, é claro. Temos os pesos do modelo, que podemos ajustar com fine-tuning. Podemos executar LoRAs nele. Podemos fazer fine-tuning para estilos, personagens e produtos. Também podemos fazer fine-tuning para comportamentos e, usando fine-tuning, adicionar modalidades inteiramente novas. Foi exatamente isso que fizemos com o Flux Flux 3 Action, sobre o qual vou falar no fim da minha apresentação. Depois, há uma etapa de pós-processamento. Claro, isso é meio arbitrário. Pode haver aumento de resolução, restauração ou moderação adicional, certo? Há inúmeras possibilidades de personalização aqui. E, por fim, também

23:02 trabalhamos bastante em como disponibilizar o modelo, como fazer o deploy, como otimizá-lo, como destilá-lo etc., etc. O que quero fazer nos próximos 20 minutos, mais ou menos, é passar pelo conjunto de ferramentas dos engenheiros de implantação e, pelo menos, dar uma ideia geral de como personalizamos o Flux no nosso dia a dia. Para começar, quero me concentrar nessa primeira personalização importante: a etapa de expansão do prompt. Como já mencionei, a expansão do prompt significa que há um VLM ou

23:35 um LLM entre o usuário e o modelo. Na prática, é mais ou menos assim. À esquerda, vocês têm um prompt do usuário, que pode ser bem, bem simples: “uma cabana na floresta”. Se enviarem isso diretamente ao modelo Flux para gerar uma imagem, verão algo como a imagem à esquerda. É uma cabana simples na floresta, certo? Tarefa concluída. No entanto, talvez isso não esteja otimizado para a intenção do usuário nem para as preferências dele. Claro, depende muito do que o usuário quer

24:07 um LLM que fica entre o usuário e o modelo. Na prática, isso se parece com o seguinte. À esquerda, temos um prompt do usuário. Pode ser algo muito, muito simples: “uma cabana na floresta”. Se você enviar isso diretamente para o modelo flux e gerar uma imagem, verá algo como a imagem à esquerda. É uma cabana simples na floresta, certo? Missão cumprida. No entanto, talvez ela não esteja otimizada para a intenção do usuário. Talvez não esteja otimizada para as preferências do usuário. Isso depende muito, é claro, do que o usuário quer.

24:37 aqui. Neste caso, o prompt é bem simples, mas demonstra muito bem a finalidade. Então, basicamente, pegamos a cabana na floresta e ampliamos o prompt. Neste caso, o upsampler padrão apenas otimiza para a preferência do usuário. Ele amplia o prompt do usuário, “a cabana na floresta”, para algo como “chaminé de pedra em ângulo reto hiper-realista, luz dourada suave” etc. E então vemos o resultado final à direita. Se você prefere a imagem da esquerda ou a da direita, isso fica para discussão, é claro. Mas o ponto

25:09 aqui é que a etapa de upsampling do prompt nos dá uma ferramenta incrivelmente poderosa para direcionar a intenção do usuário e a geração na direção que quisermos. Então, vamos ver um caso concreto. Este foi um caso real de um cliente. O cliente veio até nós e disse: “Na verdade, queremos ilustrar certas conversas que os usuários têm no nosso aplicativo com imagens do Flux. Queremos criar ilustrações para diferentes tópicos.” Esses tópicos podem ser completamente

25:41 aleatórios e são gerados por máquina. Portanto, não são criados por humanos e também não são prompts de imagem. Por exemplo, podem ser destinos de viagem para toda a família ou drenar a água da minha lava-louças. Certo? Tópicos completamente aleatórios, não formulados como prompts de imagem, gerados por máquina. Pode haver uma enorme variedade de tópicos. Nossa tarefa é gerar uma ilustração, ilustrar isso de alguma forma e de maneira agradável. Mas o detalhe é que, é claro, precisamos atender a certos requisitos de design. Por exemplo, neste caso específico, o assunto deve

26:12 ficar à direita. A imagem deve ser bem limpa. Deve haver bastante espaço à esquerda para uma sobreposição de texto. E também se aplicam algumas regras de design. Por exemplo, não incluir pessoas nem pontos turísticos, entre outras. Então, no fim das contas, o modelo de imagem já não é mais o gargalo, porque, tecnicamente, ele consegue gerar todas essas coisas diferentes, certo? Sem problema. O gargalo acaba sendo mesmo os requisitos de design. É aí que entra a montagem do prompt:

26:44 combinar e conciliar o prompt do usuário com os requisitos de design e alinhar esses requisitos à distribuição de treinamento do Flux. Ou seja, encontrar o ponto exato que precisamos enviar ao modelo, dentro da distribuição de treinamento, para gerar a imagem exata que atende aos requisitos de design. Para dar dois exemplos dos tópicos que vocês já viram,

27:15 primeiro, destinos de viagem para toda a família. Se você enviar isso ao Flux como um prompt bruto, sem nenhum ajuste, vai ver algo completamente sem sentido, imagens realmente péssimas. Por exemplo, há esse estilo de cartão-postal. A variação entre diferentes sementes também é extremamente alta quando você envia o prompt sem nenhum ajuste. Se usarmos nosso upsampler padrão, que é otimizado apenas para a preferência geral dos usuários, veremos algo como a imagem do meio, provavelmente

27:46 um pouco mais próximo de uma ilustração, mas ainda sem atender aos requisitos de design. Mas, se personalizarmos a etapa de upsampling e incluirmos diretamente os requisitos de design no upsampling do prompt, veremos algo como a imagem à direita. O assunto fica à direita. É uma imagem bem limpa, com um aspecto meio brilhante. Há bastante espaço à esquerda para sobrepor texto. Assim, os requisitos de design são atendidos exatamente. O mesmo vale para o segundo exemplo: drenar a água da lava-louças sem o upsampling do prompt resulta numa imagem completamente aleatória. Fica

28:16 um pouco melhor, parece algum tipo de vídeo instrucional, mas ainda não é o que queremos no segundo caso. Mas, se personalizarmos esse upsampler, que é basicamente o system prompt que analisa a intenção e tenta alinhá-la à distribuição de treinamento, levando em conta os requisitos de design, teremos uma imagem muito bonita e limpa, com o assunto à direita e bastante espaço à esquerda para sobrepor texto. E esse é, basicamente, um truque bem simples. O grande exemplo, e o que aprendemos com isso, é que a

28:48 grande vantagem é que é muito rápido iterar, certo? Basicamente, basta iterar sobre um system prompt. Não é necessário treinar. E há máxima flexibilidade para diferentes casos de uso. Essa etapa também é necessária porque aprendemos, especialmente conversando com clientes corporativos, que os usuários são simplesmente preguiçosos. Os usuários não necessariamente querem saber exatamente como é a nossa distribuição de treinamento, nem como criar o prompt perfeito para o Flux. Em muitos casos, é aí que entramos: personalizamos o upsampling do prompt para alinhar exatamente a intenção do usuário, os requisitos de design

29:21 e a distribuição de treinamento, encontrando o ponto ideal. Sim, o upsampling do prompt parece muito simples, mas é uma ferramenta incrivelmente poderosa, justamente porque é muito simples iterar sobre ele e não exige treinamento. Passando para a próxima etapa: moderação e segurança. Talvez vocês se surpreendam novamente ao ver isso entre as possibilidades de personalização, mas a moderação é uma das superfícies de produto mais importantes que temos, especialmente ao oferecer um modelo pela API, porque

29:52 a moderação determina o que o usuário vê e o que não vê, quais prompts permitimos e quais não. Portanto, é uma parte incrivelmente importante da experiência do usuário que oferecemos. Se vocês já experimentaram alguns modelos de vídeo de ponta, talvez conheçam bem mensagens de erro como esta: você envia uma imagem sua e quer animar a si mesmo, mas recebe algo como “as imagens dos vídeos podem conter semelhanças com pessoas reais” etc. Isso obviamente não é uma limitação do modelo. É apenas o serviço de moderação, certo? Ele não permite gerar

30:23 algo. E, ao conversar com clientes maiores que querem fazer coisas muito específicas, fica claro que isso é um grande problema, e precisamos personalizar e resolver essa questão. Quero falar sobre duas maneiras de lidar com a moderação. A primeira é a mais simples e consiste basicamente nas configurações. Temos uma estrutura modular para personalizar as configurações. Há um parâmetro de segurança bem direto que permite defini-lo pela API. E, ao personalizar

30:55 a moderação para clientes específicos, temos uma configuração bem granular que nos permite definir a tolerância de segurança, além de permitir ou bloquear categorias específicas: violência, prompts sexuais, automutilação, propriedade intelectual e semelhança com pessoas. Também combinamos isso com certas listas de bloqueio e de permissão, que podemos definir especificamente para cada cliente. Pensem, por exemplo, numa plataforma infantil sendo muito mais rigorosa, bloqueando violência, conteúdo sexual, automutilação, propriedade intelectual e semelhança com pessoas, obviamente, e ainda tendo

31:25 uma lista de bloqueio específica. Uma varejista de moda pode ser um pouco mais permissiva, talvez permitindo prompts com um pouco mais de conotação sexual, mas bloqueando marcas concorrentes em particular e permitindo apenas o próprio portfólio, basicamente tentando gerar somente os produtos da própria empresa, é claro. E pode haver um estúdio de mídia ou de cinema que seja muito mais flexível, permita até certo nível de violência e queira permitir especificamente certos personagens licenciados, mesmo que sejam protegidos por propriedade intelectual,

31:56 e bloquear todos os outros personagens para os quais não tenha licença. Isso é bem direto. Basta definir as configurações: é supermodular e supersimples. No entanto, isso não funciona em todos os casos, porque também implantamos nossos modelos diretamente na infraestrutura dos clientes. Nesses casos, não fornecemos toda a pilha de moderação. Precisamos encontrar uma maneira de incorporar a moderação e a segurança diretamente nos pesos do modelo. É aí que entra, por exemplo, uma lei de escala, a próxima ferramenta no nosso conjunto de ferramentas de

32:28 FTEEs. Uma slider LoRA tenta aprender um conceito abstrato, ou seja, o conceito abstrato específico que estamos tentando bloquear, e então tenta inverter os pesos que aprendeu para bloquear especificamente esse conceito. Vamos usar como exemplo uma slider LoRA de dessexualização, simplificada aqui no slide. Basicamente, tentamos ajustar o modelo, ajustar a matriz de adaptação de baixa ordem, levando os pesos na direção do conceito puro de sexualização. Como fazemos isso?

32:59 Temos um conjunto de dados genérico de imagens — por exemplo, de pessoas; neste caso, uma imagem de uma mulher com um vestido preto — e alimentamos isso em cada ciclo de treinamento, uma vez com uma legenda modesta e outra com uma legenda sexualizada. Então, basicamente, treinamos o modelo. Esta é a imagem, e vocês veem que ele faz uma tentativa com a legenda modesta e outra com a sexualizada. O que resta nos pesos é, essencialmente, a diferença entre os dois aprendizados. E a diferença entre os dois aprendizados é…

33:29 …que ambas as legendas contêm basicamente “há uma mulher”, “cabelo preto”, “vestido preto” e assim por diante. Mas a diferença entre elas é, essencialmente, o conceito de sexualização, porque a legenda sexualizada contém isso, mas a legenda modesta não. Ela é muito mais descritiva. Então, acabamos com uma matriz LoRA, uma matriz de adaptação que descreve essencialmente o conceito de sexualização, certo? E, na inferência, podemos aplicar isso aos pesos do nosso modelo com um alfa negativo. Assim, invertemos os pesos…

34:01 …exatamente na direção oposta. Neste caso específico, isso resultou em 20 detecções a menos de nudez e em imagens avaliadas como 68% menos sexualizadas, enquanto a qualidade geral das imagens ficou empatada, porque literalmente só invertemos o conceito de sexualização. Então, esse é um bom ajuste para incorporar a moderação diretamente nos pesos, e também é algo que vocês podem entregar diretamente ao cliente, que pode fazer o deploy na própria infraestrutura para ter um modelo muito mais seguro…

34:34 …sem nenhuma moderação determinística em torno dele. O que aprendemos com a parte de moderação é, antes de mais nada, que segurança é uma superfície de produto extremamente importante. Em certo sentido, é basicamente a primeira coisa com que os usuários interagem. Ela decide o que os usuários veem e o que não veem, e pode ser uma USP. Em certos casos, pode até ser um modelo de negócios. A modularidade vence. Incorporar a moderação aos pesos do modelo é legal. É divertido. É um bom conceito para criar alguns sliders. No entanto, é…

35:06 …caro treinar. É estático; é preciso atualizá-lo de alguma forma. Então, em muitos casos — ou na maioria deles —, usamos apenas configurações personalizadas simples, porque são modulares. São fáceis. São escaláveis, certo? E são bem mais baratas de configurar. E, como já mencionei, é possível incorporar a moderação aos pesos. No entanto, isso é caro e estático. Certo, vamos em frente. Já vimos o fine-tune que muda o comportamento na direção da moderação, mas eu prometi mostrar robôs…

35:37 …e prometi mostrar como controlar algumas coisas com o Flux. Então, finalmente, vamos ver a personalização dos pesos do modelo e como fazer fine-tune do Flux especificamente para previsão de ações. Só para dar uma visão geral: em geral, quando fazemos fine-tune de um modelo, costumamos ter um objetivo específico em mente. No caso de modelos de vídeo ou de imagem, fazemos fine-tune para obter um estilo específico, para apresentar um objeto específico ou um conjunto de objetos. Fazemos fine-tune para exibir um personagem específico com extrema precisão ou para obter um comportamento específico.

36:08 Também temos alguns modelos que treinamos, por exemplo, para outpainting, edição local específica e dessexualização, certo? Todos esses são fine-tunes comportamentais. E, indo ainda mais longe, dá até para pensar em fazer fine-tune para adicionar certas modalidades, se avançarmos um pouco para o mid-training e o post-training. Mais uma vez, foi exatamente isso que fizemos com o Flux action. O Flux action é uma nova versão do backbone do Flux, que continuamos a treinar com mid-training e post-training e para a qual fizemos fine-tune…

36:40 …especificamente para previsão de ações. Ele foi lançado como pesos abertos ontem à noite. Então, confiram. É novíssimo. Está no Hugging Face. Vocês podem experimentar, baixar os pesos e controlar seu próprio robô de braço com ele. Mas, só para explicar brevemente como funciona: temos um modelo de imagem que prevê quadros, ou seja, quadros de vídeo, com base principalmente em uma entrada de texto, certo? O Flux action funciona assim: recebe condicionamento de texto e condicionamento de vídeo. Neste caso específico, trabalhamos com um robô LeRobot que realiza uma tarefa de pegar…

37:12 …e colocar. Neste caso, o robô tem dois conjuntos de câmeras. Uma fica na mão do agarrador; a outra fica acima, essencialmente como câmera superior. Ao mesmo tempo, também fizemos fine-tune do Flux action para a configuração física do braço robótico LeRobot SL101, especificamente. Então, ensinamos ao Flux que esse robô específico tem seis eixos e que o movimento desses eixos é representado por um vetor que, em cada…

37:42 …quadro, define a direção em que cada eixo precisa se mover. Então, basicamente, estamos tentando prever um vetor simplificado de seis dimensões. Agora, alimentamos o modelo com o vetor; o conhecimento sobre a configuração física já está incorporado nos pesos do modelo. Alimentamos os quadros de vídeo e o condicionamento de texto, que define a tarefa, e a saída é, essencialmente, um vídeo que dá continuidade a esses quadros, além do vetor real que define…

38:13 …a direção em que o robô precisa se mover para concluir a tarefa. À direita, vocês podem ver como o robô LeRobot é controlado pelo Flux. Quer dizer, vocês vão ter que confiar em mim que ele é mesmo controlado pelo Flux, mas podem conferir por conta própria. E ele realmente conclui exatamente a tarefa que deveria. Dá para ver os prompts de texto ali. Mas isso é bem legal. Vamos dar uma olhada em como funciona por trás. Vamos olhar um pouco para a arquitetura. Temos…

38:45 …um modelo de vídeo. Tradicionalmente, ele recebe certos quadros e os passa por um autoencoder variacional. O autoencoder projeta meus quadros, do espaço de pixels para um espaço latente, que é uma representação abstrata desses quadros exatos. Em seguida, passamos por esse processo de remoção de ruído, que reduz gradualmente o ruído e tenta prever os próximos quadros do vídeo. Geralmente, quando prevemos uma imagem ou um vídeo, também temos um decodificador, que pega essas representações latentes…

39:15 …abstratas e as traz de volta para o espaço de pixels. O Flux action é um modelo de mundo e ação. Isso significa que nem sequer enviamos mais esses vetores de ação pelo autoencoder variacional até o espaço latente; apenas os normalizamos para a dimensionalidade do espaço latente e removemos diretamente o ruído do vetor de ação. Isso é um grande exemplo porque, essencialmente, removemos o ruído de ambos no mesmo transformer. No final…

39:47 …no caso das ações, nem sequer usamos o decodificador para a parte dos quadros e do vídeo. Só desnormalizamos a parte da ação. Depois, fazemos o robô aplicá-la. E é assim que concluímos a tarefa. O vídeo precisa de encoder e decodificador. As ações já são um vetor. Então, podemos alimentá-las naturalmente pelo modelo, que passou por mid-training e fine-tuning para resolver exatamente essas tarefas. Então, Flux action, Flux 3 action…

40:18 Vocês podem conferir a pesquisa. Podem baixar os pesos aqui. O modelo foi lançado literalmente ontem à noite. Neste momento, está no topo dos placares e é estado da arte justamente nesse espaço de previsão de ações. Então, confiram. É uma pesquisa bem empolgante. Estamos muito animados para explorar esse domínio como uma nova modalidade. E é aqui que eu gostaria de encerrar. Basicamente, vimos como personalizar o Flux para certos casos de uso.

40:48 Analisamos o aumento de prompts e como isso pode ser um método incrivelmente eficiente para alinhar a intenção do usuário aos requisitos de design na distribuição de treinamento do flux e, assim, gerar uma imagem que, em escala, atenda a determinados requisitos de design. Também analisamos a moderação. Vimos uma moderação estática, determinística ou mais ou menos determinística, incorporada de forma modular à configuração. Também analisamos como incorporar diretamente nos pesos do modelo as preferências de moderação

41:20 usando um controle deslizante. E, por fim, analisamos como adicionar uma nova modalidade ao flux, especificamente com o flux action, e como ajustar o flux para controlar um robô e prever a próxima ação. Se quiser guardar uma única coisa sobre todos esses métodos — e isso, obviamente, é só a ponta do iceberg —, se quiser guardar uma única coisa sobre boas personalizações de modelos de IA em geral e também do flux, é que ótimas personalizações

41:50 em todos esses casos são tão específicas quanto necessário e tão gerais quanto possível. Ou seja, resolvem um problema específico exatamente na medida necessária, mas também generalizam para talvez resolver um domínio inteiro e podem ser uma solução que você consiga implementar em outros lugares. Com isso, vou encerrar. Tenho aqui mais um anúncio: estamos contratando engenheiros de produto e engenheiros de soluções. Se tiver interesse, dê uma olhada. Você também pode me encontrar, me encontrar em

42:20 na conferência ou online. E, sim, muito obrigado por terem vindo. [aplausos] Obrigado, Yak. Muito bom. Certo. Vamos aplaudir mais uma vez o Yaku, por favor. [aplausos] Obrigado, pessoal. Estou muito animado com a Black Forest Labs. Outra coisa legal sobre eles é que são daqui da

42:51 Europa. São da Alemanha. E estão na linha de frente de tudo que envolve mídia generativa. E agora também estão trabalhando com robótica, o que é muito legal. Mas vocês sabem que outra empresa europeia também está na fronteira da IA? A 11 Labs. Nosso próximo palestrante vai falar sobre identidade generativa em escala com orbes. E, basicamente, quem aqui já usou o modo de voz do ChatGPT ou a 11 Labs? Então vocês já viram aquele círculo, aquele

43:22 orbe. Se usaram isso, provavelmente usaram algo que nosso próximo palestrante criou. Por favor, recebam no palco o engenheiro de experiência criativa da 11 Labs, Dorian Lods.

44:00 Parece que a internet não está funcionando. Ótimo começo. Oi, pessoal. Sou Dorian. Sou engenheiro criativo na 11 Labs, mas atualmente moro em Paris. Se quiserem saber mais

44:31 sobre o que fazemos na 11 Labs ou tiverem alguma pergunta depois, anotem minhas redes sociais. Hoje estou aqui para falar sobre como, do ponto de vista criativo, as coisas mudaram um pouco nos últimos anos e sobre como lidamos com todas essas novas ferramentas de IA que surgiram, e assim por diante. Então, vamos dar um passo atrás e

45:03 contar como eu costumava criar as coisas e como agora crio a coisa que cria as coisas, o que é uma mudança e tanto. Vim de um setor em que costumávamos criar experiências criativas imersivas: sites baseados principalmente em WebGL, instalações imersivas e coisas do tipo. Tudo era pensado para provocar uma sensação, refinada ao longo de milhares de horas. Cada projeto tinha um ofício e um propósito específicos. Durante esse percurso, explorei bastante como agilizar processos com um sistema, como produzir mais ou simplesmente ampliar suas capacidades com novas ferramentas, por exemplo, o comfy UI, que é uma ferramenta incrível que ajudou a criar sistemas de IA imersivos, novos e mais profundos, mas ainda voltados para um único resultado. E vocês vão ver que isso é importante. Todo esse histórico me levou a um projeto específico em que trabalhei, que é este aqui.

45:37 É o orbe de voz da OpenAI, a cara da OpenAI quando lançaram o modelo de voz. Algumas observações: foi o primeiro orbe icônico que precisei criar. Tudo foi feito à mão, precisava seguir a identidade da marca, e o objetivo era encontrar uma maneira de representar visualmente a voz com que você conversa, ao mesmo tempo que representava a marca. Então, era praticamente a mesma estrutura de antes. Foi ajustado manualmente, era determinístico, e tudo o que vocês veem na

46:07 tela foi feito com um shader. Na prática, a matemática gera os elementos visuais; todas as entradas, todas as cores e todo o comportamento da coisa foram cuidadosamente ajustados. Mas era algo feito para um único propósito. Passei algumas semanas criando uma esfera. Depois, precisei criar para 40 milhões de vozes, o que, na minha opinião, representa uma grande mudança de escala. Então, entrei na 11 Labs. Para quem não nos conhece, a 11 Labs é uma

46:38 empresa europeia. Estamos na vanguarda: temos nossa própria equipe de pesquisa de fronteira, dedicada a tudo relacionado a voz — qualquer interface de voz, interação por voz, música e, sinceramente, qualquer tipo de som. Mas fazemos muito mais do que isso. Temos nossa própria plataforma criativa, onde você pode dublar, criar um clone da sua voz, usar um prompt para outra voz e assim por diante. Muitos criadores já usam a plataforma. Temos a

47:10 versão para web, temos o aplicativo e agora também temos a 11 agents. Cuidamos do atendimento ao cliente, fazemos nossa própria orquestração e muitas, muitas outras coisas. Aqui estão alguns números importantes, porque todo mundo adora números, certo? Oferecemos suporte a mais de 90 idiomas. Já temos milhões de empresas, desenvolvedores e criadores na plataforma. Ultrapassamos 600 milhões de RR no fim de junho. A avaliação atual é de 11 bilhões, em

47:42 fevereiro, e agora expandimos a equipe para mais de 700 pessoas em 50 países. Temos mais de 10 milhões de agents na plataforma. Eu sei, são muitos números. Mas aqui vão alguns divertidos. Todos os dias, geramos mais de 34 anos de áudio com nosso modelo de speech-to-text. A escala é, sem dúvida, enorme. E criamos 25 milhões de faixas com nossos modelos de música

48:13 e com diferentes pontos de contato musicais. E um número de que gosto muito, muito — acho que é meu favorito aqui — é que, até agora, ajudamos a restaurar mais de 11 mil vozes de pessoas que as perderam devido a doenças ou lesões. Estamos muito comprometidos com esse objetivo. Nossa equipe de impacto está fazendo um trabalho extraordinário para devolver recursos de voz gratuitamente às pessoas que realmente precisam deles. Mais especificamente, entrei para a equipe de design da 11 Labs. A equipe de design é

48:43 praticamente toda nós aqui. Tentamos expandir as fronteiras da marca, do produto e da maneira como as pessoas interagem com a IA e com tudo o que temos na plataforma, além de encontrar formas de agilizar isso. Meu primeiro desafio foi explorar como as vozes, que são nossa principal forma de interação, poderiam ter uma identidade visual e como essa identidade poderia funcionar em todo o produto. Como dar mais alma visual às nossas vozes e como essas

49:14 almas deveriam refletir a marca. Aqui está o que temos preparado nos últimos meses.

49:46 Não caia primeiro. É.

50:17 Ei. Ei.

50:58 >> [música] >> Talvez eu tenha revelado algumas coisas com

51:56 esse vídeo. A ideia era simples, mas não tanto assim. Acreditamos que cada voz é um rosto. E temos 40 milhões de vozes na plataforma. Os usuários podem usar um prompt para criar vozes, clonar a própria voz; oferecemos muitos tipos diferentes de vozes. E todas elas agora representam mais de 40 milhões de vozes. Como criar algo

52:27 icônico o suficiente para traduzir as características da voz e, ao mesmo tempo, mantê-las dentro de um único sistema visual, em que cada voz precisa transmitir a identidade da 11 Labs e ainda parecer algo da 11 Labs? É tudo uma questão de sensação e de desenvolver isso em escala. Antes de tudo, foi preciso reformular a abordagem. Já não bastava que eu criasse os resultados; eu precisava criar o sistema que gera os resultados. É bem parecido com o que ouvimos

52:58 que seja icônico o suficiente para ainda transmitir as características da voz, mas que mantenha tudo em um único sistema visual; cada voz precisa trazer a identidade da 11 labs e ainda precisa parecer 11 Labs. Então, tudo se resume à sensação e a desenvolver isso em escala. Primeiro, foi preciso reformular a abordagem. Eu não podia mais simplesmente criar os resultados. Eu precisava criar o sistema que gera um resultado. Muito parecido com o que ouvimos em

53:28 Basicamente, o passado, ontem e hoje de manhã, com code factories e assim por diante. Mas aqui vamos falar mais do lado do design. O conceito central do orb é, na verdade, uma pilha de duas camadas: há a camada da imagem, que carrega as características da marca, a voz, que está ligada à voz; e, no topo, há a camada em tempo real, que dá vida a isso na interatividade, acrescentando a parte viva ao que está lá atrás. Então, um

54:00 pouco diferente em comparação com o primeiro em que trabalhei na OpenAI. E esse ponto de contato se difunde por toda parte. Vamos nos concentrar primeiro na camada da imagem. No essencial, ela está ligada à voz. Então, uma voz equivale a um rosto. Se você cria uma nova voz, cria um novo orb. Então, precisamos… fomos até a origem e analisamos a saída de voz

54:30 de cada voz, como a saída de áudio de cada voz. Extraímos métricas-chave, números importantes que depois se enquadram em diferentes categorias de tom, energia e expressividade, que orientam o restante do pipeline. No centro, tudo isso está muito ligado à voz. No começo, queríamos usar embeddings diretamente, mas o Canary acabou complicando um pouco as coisas. Para trabalhar e projetar o processo, e para

55:01 realmente explorar de quanta variedade precisávamos. Extraímos um conjunto de 200.000 vozes, as mais populares da plataforma. E percebemos, por exemplo, que elas não se distribuem uniformemente. Há muito mais vozes graves, principalmente para narração. Então, tivemos que nos concentrar bastante nessas categorias, enquanto as outras talvez se enquadrem em nichos, como vozes superagudas e superenergéticas, talvez em estilo de desenho animado. Mas isso realmente nos ajudou a

55:32 explorar as coisas em escala durante o processo. Primeiro, queríamos que as vozes transmitissem a marca. Então, precisávamos ensinar um modelo a falar como a ElevenLabs. Cada voz é única. O objetivo é gerar uma nova voz para cada novo visual, para cada novo orb, por voz. Então, precisávamos encontrar uma maneira de fazer o modelo aprender nossa linguagem de design e como ela se traduz. Os chefs de

56:02 outras empresas não conhecem realmente a sua marca. Então, criamos um conjunto de dados sintéticos para treinar uma LoRA específica por cima. E há algo bem divertido que exploramos: orientamos a inference com a legenda. Além das palavras de ação, selecionamos manualmente vários tipos de cores e características que queríamos atribuir a diferentes tipos de voz. Por exemplo, tom agudo, tom intermediário, tom médio. E então

56:34 incluímos isso na legenda. Assim, durante o treinamento, o modelo podia ser um pouco orientado e desenvolver um pouco mais de variedade. Todas essas palavras-chave foram adicionadas de volta ao inventário. Então, na etapa de inference, quando você reconstrói o prompt, o modelo pode escolher exatamente as mesmas palavras-chave, como subpalavras-chave, que estavam nos dados de treinamento. Foi muito divertido. Exploramos diferentes tipos de modelo, um deles dos nossos amigos.

57:04 É uma boa deixa, na verdade. Exploramos diferentes tipos de modelos open weight. O objetivo era encontrar um bom equilíbrio entre o custo de inference e o desenvolvimento em grande escala, sem deixar de manter a qualidade. Depois da inference, quando você gera a imagem-base, a ideia é desfocá-la e recortá-la dentro da imagem-base. Assim, cada variação, cada orb, fica com uma variação muito, muito boa.

57:35 É isso que chamamos de pós-inference. E isso prepara tudo para o restante do shader. Agora vamos nos concentrar na camada em tempo real desses orbs. Durante a fase de design, usamos código como meio central de design. Ele existe como um shader. Recebe a imagem ao fundo e tem várias camadas por cima. Tudo foi feito por meio de uma

58:05 interface em que toda a equipe de design podia ajustar as coisas e ver como poderíamos fazer com que elas fossem percebidas. Alguns parâmetros são ajustados com o próprio som, com o retorno de áudio e assim por diante. WebGL é a experiência interativa na plataforma, no site de marketing, mas convertemos isso para oferecer suporte a OpenGL na renderização no servidor, para muitas prévias e outros pontos de contato que não conseguem executar o shader por conta própria.

58:36 O shader em si é composto basicamente por seis camadas empilhadas. Há uma simulação de fluido em tempo real, com o efeito de ondulação ligado ao áudio. Isso traz uma qualidade orgânica. Talvez eu tenha pulado essa parte, mas o objetivo era enraizar os orbs na natureza. A natureza é a principal característica dos orbs. Queríamos que eles parecessem orgânicos. Depois, há várias camadas de ruído por cima para dar vida a eles, FBM e

59:06 assim por diante. E temos uma onda sonora adicional, ligada à que tínhamos antes, e o grão da marca que usamos em muitos dos nossos pontos de contato. Tudo isso levou ao playground do shader. Como eu disse antes, era o lugar onde a maior parte do trabalho artesanal acontecia no início. Mas, além disso, desenvolvemos uma ferramenta de revisão para depurar tudo em escala. Uma voz equivale a uma saída. Isso também

59:38 significa que não dá para escolher a saída, e cada saída precisa estar certa. Então, percebemos rapidamente que, para conseguir manter a qualidade em todos os casos, precisávamos refazer tudo em escala. Isso foi um fator decisivo, porque você pode acabar com versões de depuração muito bonitas, mas, assim que executa tudo em escala, elas acabam falhando. Criar ferramentas internas para revisar as coisas em escala fez uma diferença enorme. Essa é a parte menos divertida. Então, eu tinha…

1:00:12 Tínhamos um processo operacional incrível e workflows incríveis. Depois, fui falar com o pessoal de finanças. Eles disseram: “Tudo bem, o design é muito bom, mas, a 10 centavos por unidade, multiplicado por milhões, fica caro demais”. Então, precisávamos encontrar uma maneira de reduzir tanto a latência quanto o custo. Voltamos ao gráfico que mostrei antes, com toda a distribuição das vozes na plataforma, e usamos isso como fonte principal.

1:00:45 Então, em vez de gerar uma nova imagem toda vez, geramos de uma vez um atlas gigantesco. A partir desse atlas, recortamos cada imagem de forma um pouco mais profunda. Isso nos ajudou a não precisar gerar tudo de novo sempre que criamos uma voz, mantendo a singularidade. Cada voz é única porque giramos a imagem, fazemos recortes diferentes, mudamos um pouco o U e assim por diante. E elas continuam muito bem vinculadas às características do áudio.

1:01:15 Isso ajudou a economizar mais de 3,6 milhões. Muito bom. O processo ficou de 10 a 15 vezes mais rápido, e levamos menos de três segundos por voz para gerar o visual. Isso acontece em segundo plano assim que você cria uma nova voz e ela passa por todo o processamento de áudio. A tarefa é iniciada na infraestrutura e, então, o orb é gerado. Portanto, levar menos de três segundos faz com que isso não fique visível para o usuário. Aqui está um resumo do pipeline

1:01:48 das vozes. Primeiro, há a análise da voz, que associa métricas-chave a elementos visuais, como tom médio, nível de energia, textura e assim por diante. Depois, temos todo o pipeline generativo que acabei de mostrar, que prepara os recursos, a base do shader, a textura, a prévia, a miniatura, o MP4 animado, tudo isso distribuído por uma CDN e assim por diante. E, no fim, temos mais de 40 milhões de saídas que atendem

1:02:19 praticamente em todos os lugares, como vocês vão ver daqui a pouco. O desenvolvimento da qualidade foi realmente muito, muito importante. O conceito, o conceito central de design era legal, mas queríamos que ele parecesse vivo em todos os lugares, que acompanhasse todos os fluxos dos orbs que temos na plataforma. Aqui, à esquerda, vocês veem a interface de clonagem de voz. Os orbs mudam de acordo com a sua voz. Nós

1:02:52 queríamos manter a qualidade no iOS e no Android — é o que vocês veem no meio. Todos os shaders tinham que parecer iguais. Isso era superimportante para a marca. E precisávamos revisar tudo em escala. À direita, vocês têm a interface de administração, onde é possível revisar todas as vozes que temos. Tudo isso começou a crescer. Criamos um serviço dedicado. Então, temos um serviço de nuvem dedicado para criar os visuais dos nossos orbs.

1:03:24 Agora ele se chama Picasso, porque é pintor e eu sou francês. É uma API compartilhada por todos os nossos pontos de contato. Levamos esses orbs para todos os lugares: para o app principal, o site de marketing, os apps para iOS e Android e o 11 music, que é a nossa marca de música, e eles se expandiram para a própria marca central. Então, criamos ferramentas de marca, designs de movimento — agora tudo usa orbs: a marca que carrega a voz e a marca que carrega o rosto.

1:03:54 Era compatível com versões anteriores, porque já tínhamos tipos anteriores de orbs na plataforma. Então, conseguimos executar um backfill de 40 milhões de vozes. Esse backfill levou alguns dias. Foi um momento realmente estressante, mas deu certo no fim. E agora eles estão por toda parte. Não conseguimos mais contê-los. Eles fazem parte da nossa página inicial. A primeira coisa que vocês veem na página inicial são os orbs. Eles também fazem parte

1:04:27 do próprio app. Por exemplo, aqui, as vozes mais graves tendem a ser um pouco mais escuras. Se tiverem mais energia, terão toques de azul, e assim por diante. Então, convido vocês a explorar a plataforma e experimentar filtrar as vozes, para ver como cada característica da voz se traduz em elementos visuais. Mais imagens renderizadas, e elas literalmente saíram da tela, o que é muito, muito legal e algo de que tenho muito orgulho. Nós os usamos

1:05:00 como elementos centrais da marca em tudo o que fazemos. À esquerda, está uma campanha de automóveis que fizemos em Char, na França, em que era possível ver orbs com base na identidade visual de alguns dos nossos clientes. Aqui está a Alan, por exemplo. À direita, vocês têm Londres, onde ocupamos uma das principais praças da cidade com o DNA das cores das linhas de trem, e assim por diante. Então, mais uma vez,

1:05:30 outro cliente nosso. Os orbs, por si só, não carregam uma identidade, mas mudam de forma; então, também podemos usá-los para expressar, para ilustrar as necessidades dos nossos clientes em relação ao que fazemos. E aqui está outro exemplo no metrô de Paris. Foi muito divertido ir trabalhar e ver isso no metrô. Então, aqui está o que aprendemos durante esse pequeno processo. Usar

1:06:01 machine learning como meio criativo central muda a maneira como você projeta. Muda a maneira como você pensa. Você não pensa apenas nos resultados; precisa pensar em como criá-los. As ferramentas de IA e machine learning são basicamente superpoderes, mas precisam ser usadas com cuidado. Se você não prestar atenção a cada decisão de design que toma, agora o custo de criar algo ficou tão menor que tendemos a lançar as coisas cada vez mais rápido. E acreditamos, como equipe de design, que a vantagem competitiva será

1:06:32 a qualidade, que vai fazer você querer mais reconhecimento de marca, mais qualidade de marca e assim por diante. Então, você precisa ser dono do pipeline. Precisa assumir a responsabilidade por todos os resultados, como se fossem seus. O foco mudou para os dados e as regras. É assim que tentamos manter sob controle todas as coisas de IA que temos e garantir que sigam regras de identidade visual, de sensação e assim por diante. Cada etapa precisava preservar a visão da marca.

1:07:03 Como eu disse, a identidade da marca está se tornando cada vez mais importante. E os padrões revelaram que um único resultado ruim significa que precisamos depurar em escala. Se você estiver criando um pipeline, um processo que será executado 40 milhões de vezes, por exemplo, precisará depurá-lo em escala. Então, não hesite em fazer várias rodadas de geração em menor escala para garantir que consiga assumir a responsabilidade por cada resultado individual.

1:07:33 Então, como eu disse, ainda me importo com cada resultado. Tenho orgulho de todos eles. Não há nenhum de que eu não goste. Mas, em vez de projetá-los, agora projeto as condições que os produzem, e isso é realmente muito importante. É algo que vimos no lado do código e que também vemos agora no lado do design. É basicamente isso. Obrigado pela atenção e, se tiverem alguma pergunta, não hesitem em entrar em contato. Acessem nosso site ou

1:08:03 apps, ou qualquer outra coisa, e muito obrigado. [aplausos] Certo, muito obrigado, Dorian. Vamos aplaudir Dorian mais uma vez, por favor. Obrigado. [aplausos] Certo. Então, levantem a mão: quem aqui já usou modelos de pesos abertos? Legal. Se usaram, provavelmente já utilizaram as ferramentas da empresa do nosso próximo palestrante. A seguir, alguém da Hugging Face. Ele vai explicar em detalhes

1:08:36 como um modelo transformers é carregado no VLM. Então, preparem-se, pessoal. Vai ser bem aprofundado. Por favor, deem as boas-vindas ao engenheiro de machine learning da Hugging Face, Harry Miller. Certo.

1:09:15 Certo. Olá a todos. Sou Harry e, como acabaram de ouvir, sou engenheiro de machine learning na Hugging Face e também sou mantenedor do VLM. Na palestra de hoje, vou falar sobre como um modelo transformers da Hugging Face pode ser carregado diretamente no VLM e por que, graças ao que fazemos com ele, o modelo é executado tão rapidamente quanto se tivesse uma implementação dedicada no próprio VLM. Mas, primeiro, um pouco de contexto, caso ainda não conheçam o VLM.

1:09:45 O VLM é um mecanismo de inference de LLM open source. Ele surgiu no Skylab da UC Berkeley e agora é um projeto da PyTorch Foundation. Entre os principais recursos estão a atenção paginada, que permite usar o cache KV com eficiência; o batching contínuo, que permite processar uma solicitação assim que ela chega, em vez de esperar o início do próximo lote; kernels rápidos; escalabilidade em várias dimensões de paralelismo;

1:10:17 portabilidade, funcionando em qualquer hardware e em qualquer ambiente; e amplo suporte a centenas de modelos, tanto por meio de implementações dedicadas quanto pelo backend de modelagem do transformers, sobre o qual vocês vão ouvir mais daqui a pouco. O backend de modelagem do transformers, só para dar mais contexto, é o que permite pegar esse código de modelagem do Hugging Face transformers e executá-lo diretamente no VLM. Então, a definição do modelo, a configuração e os pesos vêm do transformers,

1:10:48 enquanto o runtime e todos os módulos críticos para o desempenho vêm do VLM. Assim, você acaba tendo o melhor dos dois. Então, por que você usaria o backend de modelagem do transformers? Há três motivos principais. Um deles pode ser que você já esteja usando o ecossistema do transformers e, portanto, não queira reimplementar seu modelo para cada mecanismo de inference que talvez queira usar. Com backends como este para o VLM e também o SG lang, você pode pegar o código

1:11:18 que escreveu uma vez para o seu loop de treinamento do transformers e executá-lo diretamente no VLM ou no SG lang. Você também pode estar usando isso para RL; nesse caso, tradicionalmente, talvez usasse o transformers para o treinamento e, depois, o VLM para os rollouts — com implementações de modelagem diferentes, porque antes era necessário fazer assim. Mas agora, com isso, você pode usar o mesmo código para treinamento e inference durante o seu RL.

1:11:50 loops. Isso significa que não há possibilidade de divergência entre as duas implementações, e o treinamento deve funcionar um pouco melhor. E, por fim, talvez seja simplesmente a única maneira de seu modelo ter suporte no VLM. Hoje, há 14 arquiteturas com suporte oficial apenas pelo backend de modelagem do transformers. E essa lista só cresce com o passar do tempo. Então, agora vamos entrar nos detalhes e falar sobre como chegamos

1:12:21 ao backend de modelagem do transformers e o que ele faz. Obviamente, primeiro iniciamos um mecanismo do VLM. Aqui temos uma série de argumentos de linha de comando. Um deles força o backend de modelagem do transformers, porque, para esse modelo Qwen3-VL que estamos analisando, há uma implementação dedicada do VLM. Então, precisamos dizer ao VLM que queremos usar o transformers. E usamos um esquema de paralelismo que não é recomendado, mas é possível, no qual usamos o máximo que conseguimos

1:12:51 em oito GPUs. Estamos usando paralelismo de tensor, de pipeline, de dados e de experts, tudo ao mesmo tempo. Por fim, habilitamos o torch.compile no codificador multimodal, algo que nem todos os modelos VLM fazem por padrão. Mas, devido à generalidade do backend de modelagem do transformers, se o código do transformers tiver um codificador multimodal compilável, basta habilitar essa opção e, se seu modelo funcionar, ele também deverá funcionar pelo VLM.

1:13:23 Então, primeiro cruzamos a fronteira entre o VLM e o transformers examinando a configuração: que modelo é esse, qual é sua forma e quais são seus outros recursos, como o esquema de quantização que ele usa. Depois de escolher o backend de modelagem do transformers, examinamos a configuração e precisamos escolher em qual classe do backend de modelagem do transformers carregar nosso modelo. À direita, vocês podem ver as classes disponíveis.

1:13:56 E selecionamos a classe examinando a configuração e identificando as características do modelo que determinam qual é a classe correta. Como vocês podem ver, todas começam com transformers. Em seguida, detectamos que este modelo é multimodal, porque tem configurações de texto e de visão no JSON de configuração que vocês viram no slide anterior. Isso acontece porque ele tem mais de zero experts

1:14:28 e, então, ForCausalLM é o padrão se o modelo for causal ou se você não especificar que quer executar uma tarefa de pooling com seu modelo causal. Por isso, escolhemos a classe Transformers multimodal ForCausalLM. E do que são feitas essas classes? Há muitas delas, e vocês poderiam pensar que, se não fizéssemos nada inteligente, acabaríamos com muito código duplicado e muita divergência, o que seria muito difícil de manter. Mas todas são feitas

1:14:59 de mixins que habilitam cada recurso individualmente. Para esta classe, começamos pelo mixin MoE, que fornece todos os protocolos necessários para paralelismo de experts e balanceamento de carga de paralelismo de experts. Depois temos o mixin multimodal, que cuida de toda a codificação da visão, do cache da codificação da visão e do mRoPE, caso o modelo tenha esse recurso, como é o caso deste. E, depois, da combinação dos embeddings de visão com os embeddings de texto

1:15:30 antes de passá-los ao transformers. Em seguida, vem o mixin causal, que cuida do LM head e do cálculo dos logits. Por fim, temos a classe base, que faz a maior parte do trabalho pesado. Na verdade, todos os mixins herdam dela, que fica no fim da hierarquia de herança. Ela cuida do carregamento dos pesos, do mapeamento dos pesos e de todas as modificações que permitem que isso seja executado rapidamente, tão rápido quanto um modelo do VLM. E também há toda uma série

1:16:02 de protocolos que dão suporte a várias coisas, como quantização, LoRA, paralelismo de pipeline, Eagle e Eagle 3. Agora vamos ver como a classe do transformers é instanciada e o que fazemos com ela durante a instanciação. Tudo parece meio apagado agora, porque ainda não foi instanciada. Antes de fazer qualquer outra coisa, registramos dois shims de attention no

1:16:32 registro de attention do transformers: os métodos forward de attention do VLM e de attention MLA do VLM. Depois, ajustamos a configuração para que, quando ocorrer o forward pass do modelo do transformers, um desses shims — dependendo de qual é o correto para o seu modelo — seja selecionado, em vez de flash attention, flex attention ou qualquer outra opção que o modelo diga que pode usar.

1:17:04 Depois, decoramos o modelo de linguagem para que sempre use torch.compile, do ponto de vista do LM. E, por causa daquele argumento de linha de comando que mencionei antes, também decoramos a torre de visão. Isso informa ao VLM que ele pode compilar os dois como grafos completos e independentes, antes que o torch.compile tenha a chance de tentar descobrir por conta própria como fazer isso. Agora instanciamos o modelo usando o método automodel from config

1:17:36 no dispositivo meta. O automodel é um pouco diferente do AutoModelForCausalLM, uma classe com a qual talvez vocês estejam mais familiarizados se usam o ecossistema do transformers. O automodel simplesmente carrega o que o transformers chama de classe base, que consiste apenas no backbone de linguagem e na torre de visão, sem o language modeling head.

1:18:10 Talvez eu precise voltar para o laptop. Parece que isso parou de funcionar. Depois, criamos o mapeador de HF para VLLM, que é como especificamos a tradução dos pesos do checkpoint para a forma que eles assumem na classe Python criada. O transformers já tem alguns mapeadores desse tipo para os casos em que houve uma migração do estilo antigo e ingênuo de mixture of experts para um estilo de mixture of experts fundido. Neste ponto, então, este é um

1:18:43 mapeador bem básico, mas vamos contribuir para ele ao longo desse processo, conforme modificamos o modelo. Depois, excluímos todas as camadas que o estágio atual do pipeline não está usando. Neste exemplo, estamos no rank zero. Então, excluímos a segunda metade da pilha de camadas e a última layer norm. Agora começamos a substituição recursiva, que é onde acontece a maior parte do trabalho para obter o desempenho e acesso a todos

1:19:14 os recursos que o VLM oferece. Para modelos MoE, isso acontece em duas passagens, porque o DeepSeek é um pouco especial e há duas maneiras diferentes de fazer isso. Para este modelo, ele usa o método interno de roteamento, o que significa que, usando o torch FX, detectamos a estrutura do bloco esparso. Se determinarmos que ele pode ser totalmente representado pelo runner do VLM, substituímos o bloco inteiro. Então, substituímos os

1:19:44 experts por este runner MoE. Ele contém os experts roteados, e o roteador é substituído por uma camada linear de gate, que é passada para o runner. Isso cuida de tudo. Assim, podemos fazer coisas como usar kernels monolíticos para roteamento e experts. Se houvesse experts compartilhados neste modelo, isso nos permitiria executar cálculos assíncronos para os experts compartilhados. Tudo isso é gerenciado pelo runner do DeepSeek.

1:20:15 Depois disso, fazemos a segunda passagem, em que a classe base percorre em profundidade todos os filhos do modelo base. Primeiro, percorremos o modelo de visão, substituindo todas as camadas para as quais sabemos como fazer isso, a fim de dar suporte

1:20:55 aos recursos. Todo o paralelismo do VLM está incorporado às suas camadas. Então, ao usar as camadas lineares e as camadas de experts do VLM, temos acesso a paralelismo de tensor, paralelismo de experts e assim por diante. Depois, substituímos a camada de embedding com paralelismo de vocabulário, trocando cirurgicamente apenas o módulo torch.nn.Embedding. Assim, se você tiver um modelo como o Gemma, que aplica uma escala durante o embedding dos tokens,

1:21:27 isso tudo continua preservado, e não precisamos tratar esse caso de forma especial no VLM. Agora usamos o próximo fusor, o fusor QKV, que também usa FX para detectar as projeções QKV e de saída e substituí-las por uma camada linear paralela QKV do VLM e uma camada linear paralela por linhas correspondente. Então, tudo isso usa o torch FX para detectar o que precisamos substituir

1:22:00 mas então ele usa o módulo as do Python para fazer as modificações de fato. Portanto, ainda não compilamos nada com torch.compile, e tudo isso fica para etapas posteriores no vLLM. Da mesma forma, substituímos a RMSNorm, que é surpreendentemente difícil, apesar de ser tão simples, mas fazemos isso porque o vLLM usa algumas passagens globais de torch.compile para detectar onde pode fundir camadas e

1:22:32 faz isso detectando os próprios módulos. Então, há algumas passagens de RMSNorm, ou algumas passagens de compilação que envolvem a RMSNorm, que só serão detectadas se usarmos a classe do vLLM. Em seguida, criamos as instâncias de atenção do vLLM e, como antes, isso nos dá acesso ao restante do vLLM. E o principal recurso a que isso nos dá acesso é o cache KV do vLLM. Assim, não precisamos usar nenhum mecanismo de cache KV implementado em

1:23:03 Transformers. E o vLLM pode fazer todas as coisas inteligentes que sabe fazer com o cache KV, como descarregamento, prefill desagregado entre nós, reutilização do cache KV e todas essas coisas legais. Depois, garantimos que tudo o que ainda não havíamos alterado esteja no dispositivo. Então, as únicas coisas que mudaram foram aquelas duas normas no modelo de visão. Por fim, garantimos que tudo o que Transformers exige que fique em FP32

1:23:34 permaneça em FP32, mesmo que o restante do modelo esteja em FP8. Então, construímos o modelo, e agora uma solicitação foi recebida. Ela foi agendada pelo vLLM e chegamos ao método forward da classe base. Esse é o primeiro retorno a Transformers. Então, simplesmente chamamos o método forward da classe original do modelo Qwen3-VL-MoE

1:24:04 e passamos os IDs de entrada ou os embeddings de entrada. Neste caso, são os embeddings de entrada, porque é um modelo multimodal, e o vLLM pré-calcula os embeddings da parte visual do prompt, insere-os nos embeddings de texto e passa tudo de uma vez, em vez de deixar que o próprio modelo faça isso. Desativamos explicitamente o cache KV do Transformers, porque o vLLM é responsável por ele por meio desses módulos de atenção. E

1:24:35 então simplesmente encaminhamos os IDs de posição, com uma pequena modificação para os modelos MRO, que acontece no mixin multimodal para esse tipo específico de modelo. Enquanto percorremos o forward pass do modelo Transformers, há dois pontos de integração em que voltamos ao vLLM de maneiras importantes para o desempenho. O primeiro, e mais interessante, é o módulo de atenção. Do lado do Transformers,

1:25:08 começamos novamente na classe nativa do Transformers. Ela percorre o registro para escolher qual método de atenção usar, que registramos previamente como o adaptador de atenção do vLLM, e então o selecionamos modificando a configuração. Em seguida, entramos nele e voltamos ao vLLM, onde o vLLM faz algumas pequenas manipulações de formato, obtém o kernel de atenção a ser usado — qualquer kernel de atenção compatível com o seu dispositivo para esse modelo específico —

1:25:38 no vLLM, obtém o cache KV usando o contexto de atenção e, então, chama a atenção e devolve o resultado ao Transformers para continuar com o restante do modelo. O segundo ponto é o roteamento interno. Como mencionei, o vLLM tem um caso especial: se conseguirmos detectar um bloco esparso totalmente representável, podemos substituí-lo por completo

1:26:11 e, na verdade, o método forward que usamos é simplesmente o forward dos especialistas, e tudo acontece dentro dessa classe executora. Então, vamos direto para o lado do vLLM. Aplicamos o gate aos estados ocultos. Obtemos os IDs e logits dos top K. Fazemos o cálculo dos especialistas roteados e devolvemos os resultados ao Transformers. Depois desse ponto, o modelo Transformers terminou. Ele forneceu todas as

1:26:43 informações sobre o grafo do modelo e todos os cálculos — ou melhor, todo o percurso pelos cálculos —, porque, como vimos, os módulos são todos módulos do vLLM. Depois disso, os cálculos lógicos e a avaliação do LM head são feitos inteiramente pelo vLLM, e a amostragem também é responsabilidade do vLLM. Há alguns recursos que não usamos com esse modelo e sobre os quais quero falar. O primeiro é o roteamento

1:27:14 externo. Se o seu bloco não for igual a algo que previmos, isso não significa que não vai funcionar. Significa apenas que vamos substituir somente os próprios especialistas. Isso oferece um ganho crucial de desempenho, porque é ali que acontece a maior parte do trabalho, mas dá a você flexibilidade para fazer o que quiser no roteamento ou em qualquer parte ao redor dele. Também há especialistas compartilhados, que

1:27:45 mencionei antes. Se eles existissem e fossem detectados no roteamento interno, também seriam incluídos no executor de MoE. E, dependendo da configuração do vLLM, o cálculo seria feito de uma maneira mais eficiente do que seria possível com o roteamento externo. Depois, temos LoRA, Eagle e Eagle 3, que simplesmente não abordamos porque esses recursos são determinados pelo checkpoint usado e pelas solicitações que você envia.

1:28:17 Depois, há vários tipos diferentes de atenção. Há a atenção exclusiva de encoder, usada por modelos como BERT, ou a atenção de janela deslizante, que você pode encontrar em modelos Gemma. Para encoder, damos suporte a modelos somente de encoder, mas não a modelos de encoder-decoder. Já a atenção de janela deslizante pode ser intercalada, de forma semelhante ao que começaram a fazer com Gemma, alternando entre atenção completa e atenção de janela deslizante. E também

1:28:49 há a atenção MLA, que passa por um fuser separado e nos dá os benefícios de compressão do cache KV que não tínhamos antes, quando apenas preenchíamos até a atenção completa ao carregar um modelo com atenção MLA. Por fim, há tarefas de pooling e classificação, que seriam usadas automaticamente se tivéssemos usado um modelo de pooling. Ou poderíamos ter

1:29:20 selecionado isso manualmente, e o vLLM teria criado uma cabeça de classificação usando o LM head, ou poderia ter retornado os embeddings brutos no final do modelo, se era isso que você queria. Para recapitular, analisamos a configuração, determinamos qual era a arquitetura do Hugging Face e, em seguida, qual classe de backend de modelagem do Transformers deveríamos usar. Carregamos o modelo nessa classe genérica do vLLM

1:29:52 e o manipulamos para que todos os recursos avançados do vLLM ficassem disponíveis, junto com todo o desempenho que eles oferecem. Depois, percorremos o forward pass do modelo base, com dois pontos de integração importantes em que voltamos ao vLLM e fazemos um trabalho não trivial. Em seguida, retornamos ao vLLM para fazer os cálculos lógicos e a amostragem

1:30:23 E essa foi a minha palestra. Os slides estão disponíveis pelo código QR ali, caso alguém queira consultá-los novamente. Obrigado. [aplausos]

1:30:59 Desculpem. É o que acontece. Certo, acho que agora temos um intervalo. Muito obrigado a todos. Então, acho que vamos fazer uma pequena pausa e voltamos daqui a meia hora, creio eu. Certo, muito obrigado.

2:18:56 Olá, bem-vindos de volta. Certo, vamos começar para vocês. Até agora, falamos sobre a economia da IA: conversamos sobre harnesses, fábricas de software, mídia generativa e todas essas ferramentas que vocês podem usar para criar agents e aplicações que usam IA. Quem aqui já criou algo com IA? Certo. Sim, a maioria de vocês, não é?

2:19:27 E o objetivo disso é criar valor para as pessoas, certo? Seja qual for o agent que você esteja criando, seja qual for a ferramenta que esteja desenvolvendo, no fim das contas, é para agregar valor aos seus usuários. Nossa próxima palestrante está bastante envolvida com dados e trabalha na Stripe. O que eles estão vendo é que toda a economia está mudando graças à IA, e ela vai vir nos contar e compartilhar

2:19:57 algumas informações sobre o que os dados da Stripe estão revelando sobre a IA. Então, sem mais delongas, por favor, recebam no palco a chefe de produto de IA e startups, Ariel Lubai.

2:20:28 Oi, pessoal. Obrigado. Muito obrigado por estarem aqui. Estou muito feliz por estar aqui e espero que em algum momento eu consiga ver alguns slides na tela. [risos] Podem colocar os slides, por favor? Certo, perfeito. Certo, vamos voltar para lá. Certo, perfeito. Então, sim, estou muito…

2:20:59 …feliz por estar aqui. Na Stripe, trabalhamos com as empresas de IA que mais crescem. Temos essa sorte, e muitas delas estão, na verdade, nesta sala. Então, fico muito feliz por estar aqui, e temos um lugar privilegiado para ver o que está funcionando, o que não está e como as melhores empresas estão crescendo hoje neste novo mundo da IA. Hoje, quero compartilhar algumas dessas ideias com vocês e falar um pouco sobre o playbook, porque ele foi completamente reescrito nos…

2:21:31 …últimos anos e até meses. Então, primeiro, vamos começar com os números. Desculpem. Primeiro, processamos 1,6% do PIB global na Stripe, e isso realmente nos coloca em uma posição privilegiada para observar os cinco padrões que estamos vendo. Quando as principais empresas de IA desenvolvem mais rápido — acho que todos estamos sentindo isso. Dois: elas vendem…

2:22:02 …globalmente por padrão. Quando você desenvolve algo hoje, seu mercado desde o primeiro dia é o mundo inteiro. Três: os preços estão mudando completamente. Aliás, hoje há muitos workshops sobre preços, porque a forma como você define os preços mudou completamente nos últimos anos. Quatro: elas também adaptam suas estratégias de entrada no mercado. As vendas por canais, por exemplo, estão se tornando cada vez mais importantes. Vamos explorar isso depois. E cinco: elas monitoram fraudes…

2:22:33 …desde cedo e com frequência. Por quê? O que está criando um potencial crescimento viral com agents também está criando um terreno completamente novo para ataques de fraude contra o seu negócio. Vamos explorar isso, claro, mas primeiro vamos olhar para o panorama geral do que está acontecendo no mundo. Vimos as principais empresas de IA crescerem 145% em 2025, o que já foi impressionante, mas, em 2026, esse número…

2:23:05 …cresceu 195%. Ou seja, triplicou em um único ano. Esse crescimento não está desacelerando; na verdade, está acelerando. E os números das principais empresas são ainda mais impressionantes. A Lovable, por exemplo, divulgou que chegou a 100 milhões em oito meses. Oito meses depois, já estava em 400 milhões. A Anthropic, que todos conhecem, começou em janeiro de 2023 com zero e chegou a…

2:23:36 …1 bilhão em apenas dois anos, e agora está em 30 bilhões. Isso é completamente impressionante. E isso não acontece só no B2B: vimos nos nossos dados de links que a adoção por consumidores também está aumentando muito. Ela dobrou em apenas um ano, passando de 6 milhões para mais de 14 milhões. Os consumidores também estão gastando mais. O interessante é que estão gastando mais com ferramentas de IA. Hoje, estamos em torno de US$ 360…

2:24:09 …por pessoa por mês em IA, basicamente o dobro do que era há três meses, quando estava em torno de US$ 180. Isso equivale mais ou menos ao que um europeu médio gasta com telefone, internet e serviços de streaming combinados. Hoje, as pessoas não tratam a IA como um serviço de streaming que podem cancelar, mas como um serviço essencial de que precisam muito.

2:24:41 O que está por trás de tudo isso? Vamos analisar em profundidade esses diferentes padrões, começando pela velocidade. Assim como você já não precisa de meses de trabalho de engenharia para fazer vibe coding e aceitar pagamentos, agora também não precisa de meses de trabalho de engenharia para lançar software. O interessante é que este gráfico mostra quando isso começou a fazer sentido. Se você olhar para os lançamentos de apps para iOS, eles estavam diminuindo no fim de 2024, e então…

2:25:13 …chegaram as ferramentas de programação com agents. Foi aí que vimos os lançamentos de apps para iOS voltarem a crescer — e não foi um crescimento pequeno: 24% mês a mês. Agora, com os pagamentos integrados a plataformas para desenvolvedores como Lovable, Riplet, Versal etc., ficou ainda mais rápido ir da ideia à primeira cobrança.

2:25:45 Como vocês podem ver aqui, leva menos de seis semanas, desde a primeira ideia e o sandbox até a primeira cobrança. Só seis semanas. É realmente incrível. E essa estratégia é mais rápida para quem tem conhecimento técnico. Testei um pouco um prompt para mostrar como é desenvolver com cloud e Stripe hoje. Trabalhamos muito para garantir uma experiência de desenvolvimento com agents que…

2:26:17 …permita desenvolver sem precisar sair do lugar onde você está trabalhando e acessar o painel da Stripe para fazer as coisas. Então, digamos que você seja um desenvolvedor e tenha criado um app, e agora esteja pronto para configurar os pagamentos. Vamos abrir o cloud e ver como funciona. Aqui está meu prompt, em que pedi para configurar os pagamentos. Quero faturamento e assinaturas, então…

2:26:48 …certo. Aqui vocês podem ver que Claude recomenda corretamente a Stripe, que é claro o que queremos, e que a integração será mais poderosa porque está conectada ao MCP da Stripe e às skills que criamos para isso. Claude usa a ferramenta MCP de recomendação de integração da Stripe junto com essas skills para saber o que usar e o que perguntar ao usuário. Então, pergunta onde estão os clientes. O…

2:27:18 …motivo dessa pergunta é que Claude sabe agora que precisa dessa resposta para fornecer a melhor recomendação de integração. O interessante é que recomenda o Checkout, uma integração da Stripe, e não, por exemplo, o elemento do cloud, porque sabe que, para uma integração de assinaturas melhor, precisamos do Checkout. Isso mostra novamente que sabe qual é a opção certa.

2:27:48 Então, respondi que meus clientes estão divididos entre os EUA e a UE, com uma concentração específica na Irlanda. O interessante agora é que recebo informações sobre o que preciso saber sobre impostos. Basicamente, preciso saber que as assinaturas digitais são tributáveis aqui. E é interessante porque ele me recomenda usar o Stripe Tax, já que não quero ter que conhecer todas as regras tributárias regionais de todos os…

2:28:18 …países em que vou lançar. O Stripe Tax vai me ajudar sem que eu precise conhecer essas regras. Vejo que está provisionando um sandbox da Stripe para mim. O interessante é que não preciso sair do fluxo para conseguir um sandbox. O agent usa o novo comando CLI para criar o sandbox sem precisar de credenciais da Stripe, o que antes não era possível.

2:28:49 O comando também busca as chaves da API e as armazena com segurança. Assim, não preciso interromper meu fluxo e posso criar minha integração sem precisar sair daqui. Com as chaves prontas, vejo que Claude está verificando todas as skills que a Stripe oferece para garantir que está criando a coisa certa. Então, diz que tem tudo…

2:29:20 …de que precisa e me pergunta se quero prosseguir com o MCP da Stripe para criar o produto e se quero continuar e criar meu Checkout. Então, estou clicando em sim aqui, e vamos avançar para ver o Checkout. É assim que fica. Vou testar se o Checkout funciona corretamente e, sim, é assim que ficaria.

2:29:51 Certo, está pronto. A Stripe e Claude basicamente estão facilitando para você e para todos os desenvolvedores criarem, configurarem pagamentos e começarem a monetizar sem sair da interface em que estão desenvolvendo. O que isso significa para vocês? Muitos provavelmente já fazem isso, mas quero enfatizar de novo que, no playbook de hoje, é muito importante se dedicar ao máximo à produtividade dos desenvolvedores. As melhores…

2:30:23 Hoje, as empresas estão realmente trabalhando para ganhar velocidade e garantir que os tempos de build sejam completamente reduzidos. Segundo: fazer o build, vender e iterar ao mesmo tempo. O playbook linear que tínhamos antes — primeiro você cria seu produto e depois vai atrás dos clientes — simplesmente não funciona mais, porque muitas pessoas estão criando ao mesmo tempo. Então, basicamente, você precisa fazer as três coisas ao mesmo tempo, em paralelo.

2:30:53 E, quanto à questão de build versus buy, estamos bastante convencidos, pelo que temos observado, de que as melhores empresas fazem as duas coisas: criam aquilo que as diferencia e também compram a infraestrutura e os blocos de construção de que precisam para seus produtos. Então, uma coisa é chegar ao mercado, mas também há a grande questão de onde vou vender e como vou

2:31:23 conseguir esses clientes no exterior. Os dados confirmam isso completamente. Há alguns anos, as empresas de SaaS que mais cresciam chegavam a 25 países no primeiro ano e a 51 até o terceiro. Hoje, as principais empresas de IA já estão em 42 países no primeiro ano e em 120 países no terceiro. Então, isso é o que eu estava dizendo sobre o mercado desde o primeiro dia: basicamente,

2:31:54 o mundo todo. Não se trata de ter presença nesses países. Trata-se de gerar receita nesses países desde o primeiro dia. A Gamma é um ótimo exemplo. Vocês provavelmente a conhecem. Ela tem sede em São Francisco. É uma ferramenta com IA para criar apresentações de slides e sites. Ela informou uma receita de 100 milhões no primeiro ano, e a maior parte dessa receita vem de fora dos EUA. Então, isso mostra claramente para onde essa tendência

2:32:27 está indo. E hoje, se olharmos para todas as principais empresas de IA, 48% da receita delas vem de fora do mercado doméstico. Quase metade de cada dólar ou euro que recebem vem de um país estrangeiro. E esse número era de 33% há alguns meses. Então, vamos ver quais mercados estão gastando bastante com ferramentas de IA.

2:32:58 Sem surpresa, podemos ver aqui países com alto crescimento do PIB. Temos França, Reino Unido e Coreia do Sul. Mas também há países emergentes que estão gastando bastante com IA. Por exemplo, Suíça, Polônia e Turquia. E há demanda. Então, agora, enquanto constroem sua empresa, vocês precisam pensar: como vou alcançar essa demanda? Como vou conseguir esses clientes?

2:33:29 E o que estamos vendo é que vocês realmente precisam atender às expectativas dos compradores e encontrá-los onde estão. A forma de fazer isso é oferecer moedas locais e métodos de pagamento locais. Isso parece fácil — e, na verdade, é fácil de fazer com a St. Mas, basicamente, trata-se mesmo de encontrar os clientes onde estão e respeitar seus hábitos. Por exemplo, preços localizados parecem algo completamente simples, mas aumentam em 18%

2:34:02 a receita internacional — o impacto disso é absurdo. E, basicamente, quando você adiciona apenas um método de pagamento local para um país, a conversão nesse país aumenta pelo menos 7%. Então, três verificações para testar a prontidão global da sua empresa de IA hoje. Primeiro, localize seus preços e métodos de pagamento. Segundo, automatize a cobrança de impostos, porque ninguém quer se meter em encrenca

2:34:34 também. E, terceiro, acompanhe o desempenho por país, incluindo a conversão, e se dedique a otimizá-los. Agora, vamos falar de preços, porque os modelos antigos não estão mais funcionando. Temos que pensar em novos modelos de preços. O interessante é que o valor é elástico. Vocês provavelmente sabem disso, se já estudaram um pouco sobre preços. Então, todos podem estar usando a mesma ferramenta de IA,

2:35:05 mas talvez não a usem da mesma maneira. Então, pensem em dois usuários. Um é engenheiro. Ele vai dormir. No dia seguinte, tem uma revisão de código. E o resultado é um trabalho de engenharia. O outro usuário é uma pessoa comum. Ele substitui o Safari pelo GPT, e o resultado é apenas uma experiência de busca aprimorada. Então, nesse caso, o custo não é o mesmo, o valor não é o mesmo e,

2:35:36 portanto, o preço definitivamente não deveria ser o mesmo. Essa mudança no valor não é novidade. Já vimos isso em todas as mudanças tecnológicas que aconteceram. Por exemplo, houve uma época em que hospedávamos tudo localmente. Era normal baixar o software com uma licença anual. Depois, veio a computação em nuvem, e passamos a ter atualizações automáticas dos softwares. Então, foi natural migrar para assinaturas. E hoje, com a IA, o que temos?

2:36:09 É basicamente nesse ponto que vocês esperariam que eu dissesse qual é a melhor resposta. Então, boas notícias e más notícias. Primeiro, as más notícias: ainda é cedo. Não temos um padrão-ouro que mostre o que todas as empresas estão fazendo e o que é, sem dúvida, o melhor. Mas a boa notícia é que estamos vendo claramente um padrão emergir. Por exemplo, a Poke to our MC hoje,

2:36:40 uma empresa de ferramentas para desenvolvedores que vocês provavelmente conhecem, que existe há cerca de uma década. Quando as ferramentas de IA chegaram, ela mudou seu produto e começou a adicionar ferramentas e recursos de IA ao produto. Também começou a adaptar os preços, adicionando créditos e coisas do tipo. Então, começou com assinaturas fixas, que é como se mantém a fidelidade e se cria um relacionamento com o usuário, e depois adicionou créditos, à medida que a IA

2:37:12 se tornou essencial para o valor do produto. O resultado é que hoje a empresa tem como meta alcançar 1 bilhão em ARR este ano, e não é a única a fazer isso. Esse é apenas um dos exemplos do que estamos vendo. Hoje, duas em cada três empresas da lista Forbes AI50 usam preços baseados no uso. Então, a maioria dessas empresas está usando um modelo

2:37:43 híbrido. Elas ainda usam assinaturas para manter a fidelidade no relacionamento, mas acrescentam bastante cobrança baseada no uso para garantir que o valor se reflita nos preços. Então, é bom saber que você precisa usar algum tipo de cobrança baseada no uso, mas acertar isso é outra história. Na nossa visão, há três coisas que você precisa acrescentar ao seu playbook de preços.

2:38:14 Primeiro, defina os preços na linguagem dos seus clientes. Desenvolvedores pensam em tokens; empresas, na maioria das vezes, pensam em assentos. Você precisa pensar em quem são seus clientes e garantir que os preços correspondam à maneira como eles percebem o valor do seu produto. Segundo, você quer oferecer visibilidade do que estão consumindo o mais próxima possível do tempo real, porque isso não é algo meramente desejável, e é

2:38:45 basicamente assim que uma empresa evita a perda de clientes. Isso significa encontrar maneiras de garantir que eles vejam, em tempo real, o que estão consumindo. E, terceiro, realmente vemos vantagem em vender créditos, não custos, porque, em determinado momento, seus clientes trocarão dinheiro por créditos. Mas, depois, a forma como interagirão com seus produtos não será por cada euro ou cada centavo. Será por créditos, e isso estará relacionado principalmente ao valor, não aos custos.

2:39:18 Agora, vamos falar das mudanças nas estratégias de go-to-market, que também são uma parte importante, embora muita gente acabe deixando esse aspecto de lado. Mas essa também é uma grande mudança. Na verdade, estão surgindo estratégias totalmente novas. Talvez vocês já tenham percebido isso, e a maior delas é a venda por canais. Isso significa pensar em onde e como seu produto será vendido. E, hoje, nas estratégias de go-to-market de IA,

2:39:49 por exemplo, muitas empresas estão comprando OpenAI ou Anthropic por meio de seus provedores de nuvem. Então, vocês precisam pensar nesses diferentes canais de venda que estão surgindo. Muitas empresas de IA também estão criando seus próprios marketplaces, onde vocês poderão aparecer como opção e também ser comprados. E, claro, a pergunta de um bilhão — ou talvez de um trilhão — de dólares: como vender seus produtos ao seu comprador mais novo?

2:40:21 Ou seja, o agente. Passamos décadas pensando em qual é a melhor maneira de entender a psicologia humana. Vou cobrar 9,99 pelo meu produto, e não 10 euros. Mas os agentes simplesmente não se importam com nada disso. E hoje acho que este gráfico é um dos sinais mais claros de que preciso pensar no meu agente como um comprador. Por exemplo, estes são os documentos da Stripe: a linha rosa…

2:40:52 …mostra como os agentes os leem, e a linha roxa, como os humanos os leem. Como vocês podem ver, no verão de 2026 as duas linhas se cruzaram, o que significa que hoje nossos documentos públicos são mais lidos por agentes do que por humanos. Vivemos isso todos os dias na Stripe: precisamos pensar em como nosso produto e nossa documentação são lidos e compreendidos pelos agentes. Então, é preciso…

2:41:22 …mudar a maneira como vocês fazem as coisas. É preciso mudar a forma como vão apresentar seus produtos e torná-los descobertos pelos agentes. E o go to market é só a ponta do iceberg, porque, se vocês pensarem em mudar os canais e as estratégias de vendas, também vão precisar adaptar o produto a isso e garantir que o onboarding reflita essa nova estratégia. Os preços e a receita também terão de refletir isso, assim como a organização.

2:41:54 Por exemplo, se vocês têm vendas empresariais, vão precisar adaptá-las também às novas estratégias de go to market. É assim que eu pensaria nesse plano de ação. Basicamente, hoje os produtos e os clientes são independentes do canal. Os clientes não se importam muito com onde compram. Então, podem começar usando o produto por conta própria e, em algum momento, passar para o segmento empresarial; depois, podem pedir a um agente que implemente um produto novo. Portanto, vocês precisam…

2:42:25 …pensar em toda essa jornada do produto. Tenham um caminho claro de progressão, do crescimento liderado pelo produto ao crescimento liderado por vendas. Depois, garantam que tenham um sistema unificado: um único catálogo de produtos, um único objeto de cliente, um único modelo de dados, sem seguir em todas as direções. E, em terceiro lugar, como eu dizia, projetem pensando na prontidão para agentes. Garantam…

2:42:56 …que o produto esteja pronto para ser descoberto e comprado por agentes sem a participação de uma pessoa. Certo. Último padrão: fraude. Isso é algo muito importante em que vocês precisam pensar. Monitorem fraudes e riscos desde cedo e com frequência. O que torna isso difícil é que a fraude não aparece em um único lugar. Em todas as etapas do ciclo de vida do produto, pode haver uma tentativa de ataque. Então, se vocês pensarem…

2:43:29 …na criação de contas, na adição de um método de pagamento, no processamento de pagamentos e, depois, no uso do produto, todos esses são pontos em que pode haver fraude. Vamos começar pelo cadastro, no topo do funil. O problema é que alguém mal-intencionado pode se cadastrar várias vezes e, basicamente, roubar de uma só vez todos os créditos dos usuários. Para dar uma ideia, um em cada seis cadastros…

2:44:01 …hoje envolve abuso de múltiplas contas. Basicamente, essas pessoas acumulam períodos de avaliação gratuita sem que vocês recebam um centavo. E o problema é que a IA tornou muito difícil identificar contas falsas, porque elas parecem reais. O interessante é que o abuso de múltiplas contas costuma ser exatamente a forma como o abuso de períodos de avaliação gratuita acontece em grande escala. Então…

2:44:32 …vocês podem ver que isso aumenta drasticamente. É assim que o problema se acelerou na rede da Stripe. Em 2026, houve esse aumento absurdo de abusos de períodos de avaliação gratuita, porque, quando vocês fazem sucesso, também se tornam um alvo atraente na internet. Mas a boa notícia é que esse problema pode ser resolvido. Assim como dá para ver um crescimento exponencial dos ataques, também dá para ver uma queda muito acentuada…

2:45:04 …dos ataques, se vocês tiverem a solução certa. Em apenas quatro meses, bloqueamos três milhões de ataques desse tipo relacionados a períodos de avaliação gratuita. Isso é, sem dúvida, uma prioridade para nós. E, claro, há outro vetor que talvez vocês conheçam: os preços conforme o uso. Junto com eles, vem o abuso desse modelo. O que acontece é que um consumidor pode usar, digamos, mil ou…

2:45:36 …milhares de dólares em tokens em um mês e, no fim, quando vocês tentam receber o pagamento, o cartão é inválido. É meio como um restaurante com estrela Michelin, como dizemos em francês, mas para tokens, certo? Quando vocês percebem, o processamento já foi feito e não conseguem cobrar nada desse usuário. O modelo de cobrança conforme o uso é uma ferramenta incrível para definir preços, mas é preciso pensar em como lidar com a fraude nesse caso. As empresas que lidam…

2:46:06 …bem com isso monitoram os sinais de uso em tempo real e garantem que conseguem observar todos os diferentes sinais e impedir que isso aconteça. Certo. Então, o que fazer? De novo, três coisas. Monitorem isso em todas as etapas do ciclo de vida, desde a criação da conta até o uso posterior. Protejam seus clientes em todas essas etapas. Depois, recomendo reduzir o intervalo entre o uso e a cobrança. Vocês não querem esperar um…

2:46:38 …mês para cobrar. É importante reduzir esse intervalo o máximo possível. E incluam a prevenção de fraudes no plano de lançamento. Talvez não seja a parte mais empolgante do desenvolvimento, mas é extremamente importante. Em cada etapa do produto, vocês precisam pensar: se eu fosse uma pessoa mal-intencionada tentando me aproveitar dele, como seria o ataque? Então, na minha opinião, se vocês ainda não pensaram nisso ou ainda não têm uma resposta…

2:47:09 …não estão prontos para lançar. O plano de ação está sendo reescrito. Todos sabemos disso. Mas o que mudou foi a forma como vocês desenvolvem, se expandem globalmente, definem preços, adaptam suas estratégias de go to market e gerenciam fraudes. Não são apenas as ferramentas: mudou todo o ponto de partida para criar uma empresa. E vocês sabem que podem desenvolver algo em horas e estar presentes em 42 países desde o primeiro dia. Como podemos ver, vocês…

2:47:41 …podem definir preços com base no valor. Na nossa opinião, este é o momento mais divertido e talvez mais maluco para criar uma empresa no mundo. Esperamos que estas ideias deem a vocês uma noção de como fazer isso. E nosso trabalho na Stripe é estar ao lado de vocês e ajudar na expansão. Estou muito animado para ver o que vocês vão criar. E saibam que estamos aqui para ajudar vocês a crescer também. Mandem uma…

2:48:12 …mensagem se quiserem conversar mais. Obrigado. [aplausos] >> Certo. Obrigado, Ariel. Vamos aplaudir Ariel mais uma vez, por favor. [aplausos] Certo. Acho que o fato — ou a informação — que ficou comigo depois desta apresentação é que precisamos projetar para humanos, mas também para agentes, porque eles talvez também comprem nossos produtos, o que acho incrível. Perguntei…

2:48:45 …antes quantas pessoas aqui desenvolvem produtos. Muitos de vocês levantaram a mão, não foi? Sim, a maioria de vocês desenvolve produtos. Talvez vocês conversem com agentes. Pela minha experiência, meio que parei de digitar para o meu agente. Agora, converso com ele principalmente por voz e acho que é uma forma mais natural de interagir com um agente. Leio mais rápido do que escuto. Mas também falo muito mais rápido do que digito. Eu não…

2:49:17 Quero saber se alguém aqui compartilha dessa experiência. Quem conversa com o próprio agent? Sim. Certo. Então, é um bom número de pessoas. Bem, nosso próximo palestrante veio falar conosco justamente sobre IA de voz em tempo real. Então, sem mais delongas, peço que me ajudem a receber no palco o cientista-chefe e cofundador da pyannoteAI, Hervé Bredin.

2:50:01 Certo, deixa eu experimentar isto. Sim, está funcionando. Oi, pessoal. Obrigado, Rau, pela apresentação. É a primeira vez que um mestre de cerimônias me anuncia no palco. Estou me sentindo um pouco como Celine Dion em Paris esta noite — ou hoje, pelo menos. Não se preocupem, não vou cantar nada, mas vou falar com vocês sobre IA de voz e, em particular, sobre diarização de falantes. Então, uma rápida

2:50:32 apresentação sobre mim. Sou cofundador e diretor científico da pyannoteAI. Fui pesquisador acadêmico durante a maior parte da minha carreira, até dois anos atrás, quando criamos esta empresa. Tenho me concentrado principalmente em diarização de falantes nos últimos 15 anos, e parece que as pessoas acham que sei algumas coisas sobre o assunto. Espero que hoje eu consiga explicar a vocês o que é diarização de falantes e que vocês

2:51:02 aprendam um pouco sobre como ela funciona e, pelo menos, tirem algo desta palestra. Então, o que é diarização de falantes? Basicamente, diarização de falantes é a tarefa de receber uma gravação de uma conversa entre várias pessoas e gerar alguns metadados sobre ela. A partir de uma conversa, você pode primeiro fazer a detecção de atividade de voz, identificando os trechos em que alguém está falando e aqueles em que ninguém está falando. Isso é detecção de atividade de voz. A segunda etapa que você pode fazer é dividir essas regiões muito longas de turnos de fala em regiões de um único falante. Essa tarefa se chama segmentação. Ela inclui tanto a detecção de mudanças de falante quanto a detecção de fala sobreposta. Neste exemplo, no meio, dá para ver que parece haver pelo menos dois falantes, porque

2:51:33 alguém interrompe outra pessoa ou começa a falar depois que o turno de fala dela termina. Um pouco mais adiante na conversa, há um turno de fala bem curto que se sobrepõe ao outro. Geralmente, chamamos esses casos de falas de acompanhamento, como “aham”, “certo”, “sim”, que você diz quando está concordando com alguém que está falando com você. Esses eventos são muito importantes para que os agents de IA de voz compreendam realmente o cerne da conversa. As palavras, geralmente, não bastam: saber quando alguém está

2:52:03 interrompendo outra pessoa ou concordando com o que ela diz dá muito mais informação sobre a conversa. A próxima etapa, que chamamos de diarização de falantes, é atribuir cada turno de fala ao falante correto, depois que a conversa foi segmentada em turnos de fala. Isso é feito sem saber de antemão quantos falantes há. Isso torna a tarefa mais difícil do que as tarefas habituais de aprendizado de máquina supervisionado. Também não sabemos a identidade dos falantes. Basicamente, precisamos

2:52:35 generalizar para qualquer falante, inclusive os que não fazem parte de nenhum conjunto de treinamento. É isso que torna a diarização de falantes difícil. Há muitas tarefas em que ela pode ser útil, e muitas delas se enquadram na ideia de que saber quem disse o quê é tão importante quanto saber o que foi dito. Por exemplo, em aplicações de dublagem de vídeo, quando você quer partir de um vídeo em francês, por exemplo, e

2:53:06 quer colocá-lo na internet para alcançar um público maior, internacional, pode usar ferramentas de dublagem de vídeo para traduzi-lo do francês para outros idiomas, garantindo que a conversa continue natural. Então, é preciso atribuir a voz clonada correta ao falante certo. Para isso, é necessário saber exatamente quem fala e quando no áudio original. Outras aplicações óbvias são os assistentes de anotações de reuniões, especialmente em

2:53:36 reuniões híbridas, em que algumas pessoas participam da mesma sala de reunião. Quando há vários fluxos de áudio, a diarização de falantes não é necessariamente útil, mas, quando as pessoas estão na mesma sala, ela é realmente útil. Isso permite criar bons resumos da conversa e, por exemplo, identificar quem deve fazer o quê depois da reunião. Há também outras aplicações, como inteligência para podcasts, em que você quer acompanhar um falante específico em vários podcasts ou acompanhar o apresentador de um podcast ao longo dos episódios.

2:54:07 Temos um toolkit open source chamado pyannote.audio que permite transformar uma gravação de áudio bruta em uma diarização de falantes propriamente dita. Ele se tornou muito popular ao longo dos anos. Aqui estão algumas métricas para nos gabarmos, graças aos nossos amigos da Hugging Face. O toolkit também tem bastante visibilidade por lá. Em média, são 10 milhões de downloads por mês. E, com poucas linhas de código, você pode transformar o áudio em

2:54:38 uma diarização de falantes propriamente dita. Neste exemplo, no primeiro bloco de código, baixamos o modelo community-1, o modelo open source da comunidade, da Hugging Face. No código Python, você obtém este objeto chamado community-1 e, em seguida, simplesmente aplica este pipeline a uma gravação de uma conversa. Você obtém a previsão, que pode percorrer para descobrir exatamente o horário de início, o horário de término e o falante correspondente. E tudo isso em três linhas de

2:55:09 código. O que descrevi foi um processamento em lote, no sentido de que todo o processamento aconteceu depois que a conversa terminou. Então, por que fazer isso em tempo real? Há muitos motivos para querer fazer isso em tempo real. Para um agent de voz, isso não é tão óbvio, porque geralmente há uma pessoa falando com um agent, e você não se importa muito com a diarização de falantes, já que há apenas um falante. Mas, muito em breve

2:55:39 — e isso já está acontecendo — o agent vai ouvir a conversa enquanto estamos numa reunião, por exemplo. Um caso de uso seria sinalizar quando um falante interrompe outro com muita frequência ou quando alguém fala demais. Para fazer isso, é necessário agir em tempo real. O próximo passo é que em breve teremos robôs em casa. Para responder a uma criança ou a um adulto da casa, o robô precisará

2:56:11 saber quem é quem. E é justamente aí que a diarização de falantes em tempo real é útil. Agora que sabemos que ela é útil, como nós, da pyannoteAI, conseguimos fazê-la em tempo real? Primeiro, preciso voltar um pouco e explicar como funciona internamente o processamento em lote da diarização de falantes que descrevi antes, com três linhas de código, usando o community-1. Vou passar um pouco mais de tempo neste slide. Basicamente,

2:56:43 dada, digamos, uma gravação de uma conversa de uma hora, o funcionamento atual do community-1 é o seguinte: começamos dividindo a conversa em partes, digamos, de 20 ou 30 segundos. Cada retângulo verde neste slide representa 30 segundos de fala. Como vocês podem ver, eles se sobrepõem um pouco. Então, avançamos com uma janela deslizante e aplicamos a primeira rede neural, que realiza a diarização de falantes em cada trecho separadamente.

2:57:15 Por que fazemos isso? Por que processamos a conversa em partes, em vez de tentar fazer isso globalmente? Porque trabalhar com trechos permite limitar o número de falantes na saída. Assim, a tarefa de aprendizado de máquina fica mais fácil e mais segura de resolver. Basicamente, o modelo é treinado para receber 30 segundos de áudio como entrada e retornar uma matriz de…

2:57:46 uma rede que basicamente faz a diarização de cada trecho separadamente. Então, por que fazemos isso? Por que processamos a conversa trecho por trecho, em vez de tentar fazer isso globalmente? É porque trabalhar com trechos permite limitar o número de falantes na saída. Assim, a tarefa de machine learning fica mais fácil e mais segura de resolver. Basicamente, o modelo é treinado para receber 30 segundos de áudio como entrada e retornar, essencialmente, uma matriz de, digamos

2:58:18 digamos, o tempo e o número de speakers, e ele vai gerar zero e um para indicar se cada speaker está ativo ao longo do tempo. O problema com essa primeira abordagem é que, nesse ponto, o mesmo speaker no primeiro trecho pode receber um rótulo diferente do mesmo speaker em outro trecho. Então, precisamos recorrer a uma segunda etapa, em que cada speaker de cada trecho, aqui representado por símbolos — os triângulos, os círculos e as estrelas —, é projetado em

2:58:51 um espaço de alta dimensão usando embeddings de speaker. Tenho quase certeza de que todos vocês sabem o que são embeddings, mas, basicamente, são representações de alta dimensão de algo. Aqui, esse algo é um turno de fala. Então, cada turno de fala é projetado nesse espaço. Aqui está representado em 3D, mas, na prática, é… Opa. Na prática, está… está voltando. Está? Está. Eu provavelmente deveria ficar aqui. E esse

2:59:25 modelo de identificação de speakers também é uma rede neural. Ele é treinado para aproximar dois turnos de fala do mesmo speaker e afastar dois turnos de fala de speakers diferentes. Dessa forma, conseguimos encontrar agrupamentos nesse espaço. E foi assim que, basicamente, conseguimos reconciliar todos os trechos e, por fim, juntar todos aqueles pequenos turnos de fala para obter os resultados finais. Esse é o ponto de partida da diarização de speakers

2:59:58 em lote. Então, a questão é: como passamos dessa diarização em lote para uma implementação em tempo real? A primeira coisa em que trabalhamos foi a parte de agrupamento que acabei de mencionar, tornando-a incremental em vez de global. Essa animação vai explicar tudo. Basicamente, começando com uma conversa entre dois speakers, na diarização em lote começamos por

3:00:31 extrair embeddings de speaker de todos esses turnos de fala. Esses pontos são os embeddings de speaker, e basta agrupá-los. Mas, no processamento em fluxo, você não tem acesso ao futuro, porque a conversa ainda não aconteceu. A ideia é que o algoritmo de agrupamento precise funcionar de forma incremental, o que torna o trabalho muito mais difícil, porque você só tem uma visão limitada da conversa. Aqui, neste exemplo fictício, dá para ver que o algoritmo de agrupamento leva algum tempo para perceber que, na verdade, há dois speakers.

3:01:01 E é por isso que é bem difícil passar do processamento em lote para o tempo real se mantivermos a abordagem por trechos que acabei de mencionar. No fim, ele ainda conseguiu encontrar o agrupamento correto, mas vocês viram que, durante a conversa, cometeu alguns erros. Essa abordagem está implementada no toolkit de código aberto diart, criado pelo nosso CTO, Juan Manuel Ka, e conseguimos obter uma taxa de erro de diarização um pouco maior, com uma latência de cerca de 5 segundos, porque os trechos têm aproximadamente 5 segundos de duração — ou, pelo menos, o intervalo entre eles é de 5 segundos.

3:01:34 Então, dissemos: “Certo, ótimo, mas o próximo passo seria conseguir reduzir essa taxa de erro de diarização, pelo menos até ficar tão boa quanto a diarização de speakers em lote. Além disso, essa latência de 5 segundos talvez seja

3:02:05 um pouco alta demais.” O que fizemos em seguida foi transformar essa segmentação por trechos em algo um pouco mais próximo do processamento em fluxo, que chamamos de segmentação causal. Em vez de esperar que o trecho inteiro esteja disponível para processá-lo, fazemos o processamento em fluxo. Isso traz várias outras dificuldades. Então, vamos nos concentrar, por exemplo, na detecção de mudança de speaker. No modo em lote, normalmente temos acesso à conversa inteira. Assim, a detecção de mudança de speaker pode ser feita desta maneira: deslizamos uma janela ao longo da conversa, comparamos o que acontece à esquerda do segmento com o que acontece à direita, calculamos a diferença e obtemos um pico bem definido onde ocorre uma mudança de speaker.

3:02:35 Mas, no processamento em fluxo, o problema é que você não tem acesso ao futuro. Então, o modelo leva algum tempo para alcançar confiança suficiente para tomar uma decisão. Esse pequeno intervalo de tempo no futuro de que ele precisa para decidir se houve ou não uma mudança de speaker

3:03:05 é o que chamamos de look ahead. É uma latência da qual não conseguimos nos livrar, porque, em um determinado ponto da conversa, se você precisa decidir se houve uma mudança de speaker, a menos que tenha uma modelagem muito robusta do processo ou algo assim, realmente precisa esperar para ver se outra pessoa começa a falar antes de tomar a decisão. Isso gera essa latência

3:03:37 irredutível, que é acrescentada ao processo. Então, seguimos em frente e implementamos isso. Com bastante pesquisa da equipe de pesquisa nesse modelo de segmentação em fluxo, conseguimos usar um modelo muito maior do que o usado na abordagem por trechos, além de implementar algumas funções de perda. Não vou entrar em detalhes.

3:04:07 Terei prazer em conversar sobre isso depois. Mas conseguimos alcançar basicamente o mesmo nível de precisão da diarização de speakers em lote, com uma latência muito baixa, de 400 milissegundos. E esses 400 milissegundos incluem várias coisas. Incluem também a viagem de ida e volta do cliente aos servidores e de volta. Então, gostaria de dedicar algum tempo à latência real de 400 milissegundos. O que está incluído nesses 400 milissegundos de latência?

3:04:38 Começamos com um cliente tendo uma conversa localmente. A primeira latência que temos é porque a conversa é dividida em blocos de 100 milissegundos. Então, já é preciso esperar 100 milissegundos. Digamos que, no instante t, você precise esperar 100 milissegundos para formar esse bloco. Portanto, no instante t, já temos uma latência de 100 milissegundos. Essa latência que indiquei aqui faz parte dos 400 milissegundos e muitas vezes não é

3:05:10 incluída nos números que vocês veem por aí. Mas também é algo importante a considerar. Em seguida, usamos a tecnologia Durable Objects da Cloudflare para enviar esse bloco ao servidor da Cloudflare mais próximo. Em média, isso leva 20 milissegundos, mas depende bastante de onde está o cliente e de quão bem a Cloudflare funciona. E

3:05:40 nesse servidor, recebemos vários fluxos e os agrupamos. Reunimos muitos blocos de 100 milissegundos para poder processar vários fluxos em paralelo. Isso é muito rápido. Depois de formar esses lotes, nós os enviamos ao modelo, onde fica a carga de trabalho da GPU. Então, para segmentar esses blocos de 100 milissegundos, digamos que o tamanho do lote seja de 32 fluxos — é só um exemplo —, a inferência leva cerca de 50 milissegundos.

3:06:11 Também é preciso considerar os 200 milissegundos de look ahead que mencionei antes. Basicamente, quando chegamos ao instante t, a rede neural prevê o que aconteceu 200 milissegundos antes. Isso se soma à latência. Em paralelo, encontramos uma maneira de executar a extração de embeddings e o agrupamento de forma totalmente assíncrona. Isso não atrasa em nada a previsão. Por isso, indiquei zero milissegundos aqui. Depois, temos mais cinco milissegundos para a viagem de volta. Em seguida, usando o estado armazenado na Cloudflare, juntamos as partes e as serializamos para enviá-las ao cliente.

3:06:42 No total, chegamos a esses 400 milissegundos de latência. E, se entrarmos em mais detalhes, então…

3:07:12 Basicamente, não existe apenas uma latência; há várias latências aqui. Há a latência de rede, que depende bastante do cliente: da distância entre o cliente e as redes e da velocidade da conexão. Isso representa, em média, cerca de 50 milissegundos, mas pode variar. Depois, há a latência de inferência que mencionei, de 50 milissegundos. Essa latência de inferência pode ser ajustada um pouco.

3:07:44 Obviamente, se você usar um lote maior, vai levar mais tempo, mas o custo será menor, porque você poderá processar mais fluxos com a mesma GPU. Mas, se quiser ser mais rápido, terá que reduzir o tamanho do lote, e o custo vai aumentar. Então, é nessa latência de inferência que você controla a relação entre custo e latência. E depois há a latência algorítmica, que representa basicamente

3:08:15 a maior parte da latência aqui, e ela também determina uma relação de compromisso. É uma relação entre precisão e latência. Quanto mais você puder esperar nessa etapa de antecipação, melhor será a previsão que poderá fazer. Então, como eu disse, é uma relação de compromisso entre as duas coisas. Uma maneira fácil de reduzir a latência seria reduzir o tamanho do bloco. Obviamente, aqui ele é de 100 milissegundos, mas isso repercute na latência de inferência, porque você passa a ter muito mais blocos

3:08:48 que precisa processar e, então, fica um pouco mais difícil alcançar esse equilíbrio geral. Então, agora cheguei ao ponto em que acho que seria bom fazer uma demonstração. Vou chamar meu cofundador, Vanson, para subir ao palco, só para conversarmos rapidamente. Você pode pegar um microfone aqui, e eu vou passar para uma demonstração, para que vocês entendam de verdade o que 400 milissegundos significam na prática. Só para explicar a configuração…

3:09:22 Embora tenhamos dois microfones aqui, é realmente o meu laptop que capta a conversa. Então… >> Quer dizer que você está lendo a transcrição e vê tudo. >> Isso. >> Oi, pessoal. Prazer em conhecer vocês. >> Então, como foi a minha palestra? >> Foi muito boa. Espero que você compartilhe e que as pessoas tenham aprendido coisas sobre o que fazemos. Sempre me surpreende como isso é difícil. Parece fácil quando você usa, mas… >> É, mas também conseguimos falar ao mesmo tempo. Com certeza. É o que costumamos fazer. >> Normalmente, 20% da fala acontece ao mesmo tempo, o que é meio absurdo de detectar.

3:09:52 >> É. Ele continua me interpretando em todas as reuniões que temos. É um efeito ideal. >> Por algum motivo, Ralph diz alguma coisa lá nos bastidores, porque encontramos o speaker 02 aqui. >> Por favor, não faça comentários de fundo, Raul. [risos] >> Certo. Vou deixar vocês por aqui. Obrigado. >> Então, vocês já têm uma ideia de como são 400 milissegundos. E, sim, estou quase no fim da minha palestra. Espero que tenham aprendido algumas coisas com ela. E, pelo menos, as…

3:10:25 três coisas que acho interessantes nesta palestra — vocês vão me dizer o que acham — são estas: tentei convencer vocês de que o processamento em lote e a diarização em tempo real são, na verdade, dois problemas diferentes de aprendizado de máquina. Eles têm restrições muito diferentes. Embora a entrada e a saída sejam as mesmas, resolvê-los exige abordagens diferentes. Também quis destacar que latência não é apenas um número. Ela depende de muitas coisas. Quer dizer, vocês já sabiam disso, mas, em particular, no caso da diarização, dá para ver que a principal latência vem da…

3:10:56 parte algorítmica, por causa da maneira como essa tarefa de diarização é estruturada. E tenho muito orgulho do trabalho que a equipe de pesquisa e tecnologia fez para lidar com isso. Há muitas maneiras de equilibrar latência, precisão e custo. Muito obrigado; essa é a minha palestra. E ficarei feliz em conversar depois, se vocês quiserem. [aplausos]

3:11:27 Obrigado. Muito obrigado, Alve. Vamos aplaudir Alve mais uma vez, por favor. Muito bem. Certo. Este é um bom momento, porque esta foi a última palestra desta manhã. Então, podem ir à área de exposição. Temos um almoço patrocinado pela Sierra. Um salve para a Sierra, por favor. [aplausos] Obrigado por nos oferecerem um pouco de combustível para seguirmos com este evento e voltarmos com mais energia à tarde,

3:11:58 porque ainda temos muita coisa para conversar. Voltaremos aqui às 14h. Teremos uma conversa descontraída entre Mistral e Nvidia. Não podem perder. Vejo vocês aqui às 14h. Certo, aproveitem o almoço.

4:50:11 Senhoras e senhores, recebam no palco o mestre de cerimônias do AI Engineer Paris 2026, engenheiro de relações com desenvolvedores na Replit, Raul Chevrey. >> Certo, voltamos. Parabéns a todos nós, não é? Vocês estão chegando à reta final da conferência de hoje, o segundo dia do AI Engineer Paris. Obrigado

4:50:43 por voltarem. Temos um ótimo painel para começar daqui a pouco. Como vocês estão? >> É, não. Certo. Vocês já sabem como funciona. Vamos lá. Estamos fazendo isso desde ontem. Precisamos aumentar a energia. Então, temos dois senhores que vão subir ao palco. Por favor, recebam comigo o vice-presidente de computação da Mistral, Yan Leger,

4:51:15 e também o gerente sênior de arquitetura de soluções da Nvidia, Adolf Hall. Vamos aplaudi-los, por favor. [aplausos] Certo. E quase me esqueci de dizer: vamos falar sobre a construção da infraestrutura por trás da próxima geração de IA. Então, teremos uma visão um pouco futurista

4:51:46 do que é necessário para construir a próxima geração de IA. Muito obrigado por estarem aqui, Adolf e Yan. Jan, você esteve aqui no AI Engineer no ano passado. Lembra? Parece que foi há uns 10 anos. >> Foi um ano e tanto; nossa empresa foi adquirida nesse meio-tempo. >> Muita coisa aconteceu. >> No ano passado, organizamos esta conferência juntos. E agora estamos fazendo isso de novo.

4:52:16 >> Sim, exatamente. Mas realmente parece… É. Um ano no tempo da IA parece uma eternidade. >> Eu queria ter estado aqui também. >> Você está convidado para o ano que vem. [risos] >> Que bom. Jan, quando você esteve aqui, subiu ao palco e falou sobre construir para o futuro da era dos agents. Pode nos explicar o que você acha que mudou nesse intervalo? >> Nos últimos dois anos, falei sobre…

4:52:49 infraestrutura para IA. Na verdade, já faz mais do que isso. No ano passado, o foco foi especificamente em sandboxes e em como isso está criando uma nova categoria de infraestrutura. E estamos vendo isso em ação agora. Acho que foi isso que aconteceu neste último ano: estávamos no início desse movimento da era dos agents e da adoção começando a decolar; agora, uma…

4:53:21 grande parte do software é escrita por agents, e os workflows com agents já têm uma penetração enorme. Mas as GPUs ainda são a essência de tudo. Além da infraestrutura de GPU, agora temos CPUs que também entram nessa combinação. Acho que essa é uma diferença importante em relação aos anos anteriores. Então, continuamos avançando na mesma direção.

4:53:52 Por exemplo, treinar modelos grandes não parou na ML; ainda estávamos treinando modelos de ponta. Por outro lado, estamos fazendo inferência em larga escala, e o agent no KA está, na verdade, impulsionando ainda mais o consumo de inferência, acho eu, o que significa que a stack é ainda mais complexa do que antes. >> Então você está dizendo que… Sim, você estava falando sobre sandboxes e viu o crescimento desse tipo de infraestrutura. Então você está vendo, tipo…

4:54:23 o progresso na carga, e acho que não há dúvida de que isso faz parte deste novo mundo. O que você acha que está entre nós e a próxima geração de IA, do ponto de vista do hardware e do ponto de vista da Nvidia?

4:54:53 >> Quando você está há mais tempo nesse ramo, costuma falar de computação, redes e armazenamento. E, na verdade, como essa carga de trabalho agentic é tão dominante, onde ela vai ser executada? Acho que, muitas vezes, hoje em dia, nessa equação, esquecem para onde vai a carga de trabalho dos agents — e essa é uma questão de CPU. E isso, eu diria, é bastante…

4:55:23 óbvio quando falamos de desenvolvimento de modelos. Temos certas arquiteturas estabelecidas, e elas têm necessidades específicas que, basicamente, determinam como a infraestrutura e os chips são projetados para o próximo ciclo de inovação. Isso certamente é influenciado por mixture of experts e suas demandas específicas de comunicação. Se olharmos para novas modalidades, eu diria que a sociedade e a…

4:55:55 indústria fizeram um ótimo uso dos dados. Acho que treinamos com todos os livros do mundo. Provavelmente, em breve, vamos treinar com todos os filmes e todos os dados multimodais. Mas o jogo não acaba aí. Acho que há outras coisas por vir que precisam ser testadas. Por exemplo, se entrarmos no domínio da robótica, ela precisa receber feedback. Dar esse feedback é uma questão de simulação. Então, acho que isso…

4:56:26 vai trazer novos desafios. Ainda não chegamos lá; é uma jornada muito empolgante. Quero só voltar a algo que você mencionou: mixture of experts é uma forma de termos modelos muito, muito grandes, mas que possam ser usados com eficiência no momento da inference, certo? >> Sim. >> Certo. Tudo bem. Se os senhores quiserem me acompanhar, gostaria de falar um pouco sobre hardware de silício.

4:56:56 E sabemos que Rubin, a geração mais recente de chips de liderança, está agora em plena produção, certo? Algumas das afirmações são que Rubin é 10 vezes mais eficiente e exige quatro vezes menos GPUs. À medida que a IA evolui, estamos obtendo sistemas mais eficientes para treinar um modelo de mixture of experts. Como as equipes…

4:57:29 — como esses engenheiros devem desenvolver produtos de IA, pensando na próxima geração de arquitetura, considerando esse ritmo e essa escala? >> Eu diria para tentarem acompanhar da melhor forma possível, porque, em toda a indústria, estamos em um ciclo de aprendizado. Quando entrei na Nvidia, havia uma arquitetura chamada Pascal e Volta; talvez vocês não conheçam essa última. Mas, se falarmos de economia e eficiência de data centers…

4:57:59 — e também do que você destacou: mais tokens, tokens mais baratos etc. — começamos um caminho tecnológico naquela geração, há sete ou oito anos, e ele continua. Precisamos trabalhar com isso, e o software segue esses paradigmas. Software e hardware andam juntos. Para tirar proveito deles, você precisa usá-los por meio do software. Portanto, há algumas dependências quando você diz: “Quero aproveitar a…

4:58:29 inovação mais recente”. Para quem oferece inference em escala, obviamente há argumentos econômicos, e é preciso aproveitá-los da melhor maneira possível. No geral, precisamos otimizar todas as camadas da stack. O que temos visto recentemente é que costumávamos pensar em infraestrutura para treinamento e inference separadamente, mas acho que isso está convergindo um pouco, também por uma questão econômica, porque, se…

4:59:00 você cria um pool, ele é estático, então há algum desperdício em cada pool. >> E acho que isso é algo que vai desaparecer. Espero que as infraestruturas para os dois domínios passem a convergir e a funcionar mais em conjunto. >> Interessante. Certo. >> Sim, concordo com tudo isso sobre o uso de inference. Na verdade, há dois…

4:59:30 tipos. No passado, se você olhar para algumas das palestras que dei, há dois anos eu já falava sobre diferentes tipos de infraestrutura para diferentes finalidades. Você usa clusters de treinamento que não têm os mesmos requisitos físicos. Eles precisam do máximo desempenho no treinamento. As cargas de trabalho de inference são um pouco mais tolerantes, então não precisam necessariamente da geração mais recente de hardware. Vemos isso na prática: para treinamento…

5:00:03 podemos usar a geração mais recente de hardware. Para inference, podemos usar gerações mais antigas. Isso também significa que, ao projetar a infraestrutura do ponto de vista físico, precisamos ter em mente que o uso desse tipo de infraestrutura vai evoluir com o tempo. Você pode implantar um cluster e, normalmente, usá-lo nos dois primeiros anos para uma finalidade e, nos três ou quatro anos…

5:00:33 seguintes, para outra finalidade, como o Adolf mencionou, em termos de flexibilidade. Idealmente, você pode ir ainda mais longe e fazer com que as cargas de trabalho de treinamento — ou a infraestrutura de treinamento — sejam reutilizadas dinamicamente para inference. No fim das contas, isso depende bastante do software, em termos de orquestração, para poder realocar as cargas de trabalho de forma dinâmica. >> Certo, muito interessante. Então, eventualmente, vamos precisar de dois tipos diferentes de infraestrutura para inference e…

5:01:06 para treinamento, mais adiante, se entendi corretamente, porque as necessidades são diferentes e não precisamos necessariamente do tipo mais recente de hardware. Então, na verdade, estamos convergindo mais. Talvez tenhamos, de um lado, infraestrutura especializada para inference que, se for construída especificamente para inference, pode tolerar hardware que não seja da geração mais recente. Isso também depende dos tipos de modelos que você está treinando. Como sabemos, os modelos agora têm…

5:01:36 tamanhos e formatos diferentes. Se você treina um modelo com 1 trilhão de parâmetros, não é a mesma coisa que treinar um modelo com 8 bilhões de parâmetros, certo? Você não precisa da mesma infraestrutura de treinamento nos dois casos. Na verdade, acho que, no longo prazo, estamos convergindo mais, de certa forma. Ou seja, teremos um pool global que poderá ser realocado entre diferentes tipos de treinamento e inference. >> Certo. Interessante. A próxima pergunta é para você, Adolf. Vou falar sobre NVL72, mas antes de entrar nisso, você poderia explicar ao público o que é NVL72, talvez para quem não esteja familiarizado? >> Caso não conheçam, a IA, hoje em dia — vamos colocar assim: quando comecei, acho que meu custo inicial para entrar na IA foi de US$ 150 por uma GPU. Eu tinha a bancada de trabalho e podia participar. Agora, tudo cresceu em um ritmo fascinante. Eu diria que o menor problema que a Mistral tem provavelmente já não cabe mais em um único servidor, e…

5:02:08 vou falar sobre o NVL72, mas, antes de entrar nisso, você poderia explicar ao público, talvez a quem não esteja familiarizado, o que é o NVL72? >> Caso você não conheça, enquanto isso, a IA… Vamos colocar assim: quando comecei, acho que meu custo de entrada na IA foi de US$ 150 por uma GPU. Eu tinha a bancada de trabalho e podia participar. Agora, tudo cresceu a uma velocidade fascinante. Então, eu diria que o menor problema que a Mistral tem, acho que não vai

5:02:41 ao mesmo tempo, o hardware leva em conta o que o software solicita. Portanto, vários componentes precisam trabalhar juntos da forma mais econômica e eficiente possível. Eficiência significa que a comunicação precisa ser muito, muito rápida. Para isso, projetamos o NVL72, que é um sistema em um rack. A diferença em relação a um sistema clássico é que o NVL72 é um…

5:03:14 interconexão entre eles muito mais próxima do que qualquer coisa de TCP/IP. E isso é necessário se você quiser executar as cargas de trabalho modernas. Bem, eu diria que, neste momento, é a maneira mais econômica de lidar com treinamentos altamente paralelos. >> Certo. Então, sim. O NV72 é um sistema de rack e, bem, o que isso significa para o restante da pilha? Isso significa que…

5:03:44 sim, estamos caminhando para o rack ser como o novo servidor? >> Bem, há uma frase da Nvidia que diz que o data center é o computador. Então, pensando ainda maior, quando você considera as cargas de trabalho, precisa agendar vários trabalhos nas unidades. Qual é a maneira mais econômica de fazer isso? O NVL72, por si só, é uma unidade de atribuição e, do ponto de vista econômico, não há necessidade de dizer: “Vou…”

5:04:14 dividi-lo no meio. Você pode fazer isso, mas definitivamente estará deixando de aproveitar o ponto ideal desse sistema. Então, em termos de… eu diria que sua síntese está certa: o computador passa, basicamente, de um sistema individual para a escala de um rack. >> Sim, vai ser simplesmente um sistema maior para atender às nossas necessidades daqui para frente. Certo. Então, tenho uma pergunta para você, Yan.

5:04:46 Como você está no nível de computação, atende muita inferência. O que você acha que vai precisar daqui para frente, talvez dos chips ou do hardware, para atender melhor seus clientes, digamos, no futuro próximo? É… acho que é… [risos] bem…

5:05:17 É uma pergunta complicada. Nós consumimos hardware de uma forma específica: usamos a geração mais recente de hardware para treinar modelos de fronteira. É disso que precisamos em geral. Eles proporcionam ganhos significativos de eficiência e, para estar na fronteira, você ainda precisa — ainda quer — mais potência. Em geral, temos essa combinação, e não implantamos apenas sistemas NVL72.

5:05:49 Na verdade, temos uma combinação de sistemas: alguns com essa interconexão de alto desempenho para treinamento, mas também fazemos algumas implantações dedicadas à inferência, que talvez não sejam equipadas exatamente com o mesmo sistema. Acho que a realidade do campo é que a diversidade da infraestrutura está aumentando, porque a onda da IA começou há vários anos.

5:06:20 Então, estamos começando a ter diferentes gerações e, na verdade, chegando a um ciclo de infraestrutura que talvez se pareça, de certa forma, com o dos CPUs. Os designs são completamente diferentes, mas há uma rotação de hardware de longo prazo, e é preciso lidar com esse hardware heterogêneo. Então, acho que, em geral, os fabricantes de chips e a Nvidia estão projetando o que vem…

5:06:50 a seguir, e vamos aproveitar isso para treinar modelos ainda mais eficientes. >> Certo. Sim. Acho que quero avançar. Já que estamos falando de inferência, gostaria de conversar um pouco sobre a economia da inferência, se estiver tudo bem para vocês. Certo. Então, quando a Nvidia fala sobre fábricas de IA, a métrica é sempre tokens por segundo, por dólar, por watt, certo? Nós…

5:07:21 queremos oferecer inferência da maneira mais rápida, pelo menor custo e com o menor consumo de energia possível, certo? Mas você mencionou que a infraestrutura para treinamento e inferência é diferente. Em que momento você acha que vamos conseguir justificar a receita da inferência, em vez de simplesmente dizer que estamos construindo, basicamente, sobretudo para treinamento? Quando vamos conseguir…

5:07:51 justificar a receita da inferência e dizer que toda essa expansão vai se concretizar em algum momento? Olhando… >> Você está olhando para mim. [risos] >> Sim, estou olhando para você. Desculpe, era uma pergunta… caso ninguém tenha entendido, mas, sim, é uma pergunta relacionada à Nvidia. >> Bem, tudo o que você usa para produzir e ganhar dinheiro precisa ter algum retorno. A economia não vai mudar…

5:08:22 nesse caso. No passado, talvez o padrão fosse usar sistemas de treinamento e, quando a próxima geração estivesse disponível, usar a geração anterior para inferência, em cargas de trabalho menos exigentes. Mas ainda é preciso levar a economia em consideração. E eu diria que as cargas de trabalho de inferência estão disparando. Há muito mais demanda. Eu…

5:08:54 mesmo uso isso. Adoro usar. Uso o tempo todo. Já não faço pesquisas da maneira tradicional, assim como provavelmente muitos de vocês. >> E não quero ficar sem isso. Então, estou deixando um rastro de uso. A inferência também é muito importante para nós, porque dedicamos muitos ciclos de engenharia a melhorar continuamente o software. Então, ela é uma carga de trabalho de ponta e eu diria que, nos…

5:09:26 dias de hoje, é preciso levá-la em conta desde o primeiro dia. >> Certo. >> Sim. Acho que, seguindo esse caminho, havia antes um risco, uma preocupação de que o lado da inferência não se concretizasse em escala. E acho que, no último ano, com o surgimento de workflows e cargas de trabalho agênticos, vimos a inferência decolar. Uma das coisas que se discute é…

5:09:57 quanto se gasta, por exemplo, com ferramentas de IA para acelerar o trabalho de engenharia de software. >> E, claro, há discussões sobre maximização de tokens ou algo assim, nesse sentido. Mas também há a realidade de que, hoje em dia, essas ferramentas são usadas diariamente por qualquer pessoa que trabalhe com engenharia de software. E vemos a geração de receita como resultado dos investimentos anteriores…

5:10:27 começando a dar retorno. >> Sim, então a inferência está decolando e vamos ver isso continuar aumentando daqui para frente. Toda essa expansão vai acabar sendo usada, em algum momento, para inferência, mesmo que por enquanto seja para treinamento. Mas você falou sobre maximização de tokens e, sim, eu diria que não acreditamos tanto em maximizar tokens; acreditamos mais em maximizar resultados.

5:10:58 Queremos oferecer valor ao cliente, e acho que isso leva bem à minha próxima pergunta. Apesar de quantificarmos custos e coisas assim, como estávamos falando, em algum momento não se trata apenas de custo, mas do valor para as pessoas que usam isso, certo? Então, como vocês quantificam isso? Quer dizer, para além de commodities brutas e…

5:11:28 da economia, neste caso. Como quantificamos a inteligência? >> A pergunta é para mim ou para…? >> Esta pergunta é para você. >> Como quantificamos a inteligência? Acho que é uma questão difícil. Tem mais a ver com os resultados para os negócios. E isso varia muito. Com poucos tokens, é possível gerar um valor enorme se você aplicar a IA da maneira certa. Acho que…

5:12:00 É uma das coisas que estamos fazendo na Mistro. Não se trata apenas de volume: há algumas atividades que consomem muitos tokens proporcionalmente, e há uma questão de eficiência e de todo o conhecimento que ainda precisamos aplicar para otimizar esses processos, porque algumas cargas de trabalho podem usar uma quantidade anormal de tokens para o resultado obtido. Então, acho que…

5:12:34 …é aí que todo o ecossistema pode agregar muito valor. Se olharmos para a situação, não se trata apenas do M, nem apenas de treinamento; trata-se do harness completo e de como aproveitar os tokens adequadamente para obter uma relação entre custo em tokens e valor. Na camada de infraestrutura, estamos apenas otimizando cada camada. Mas estamos apenas fornecendo os tokens. O valor está mesmo nos níveis mais altos da pilha, acho. >> Certo. Bem, já que estamos falando do consumo de tokens, do consumo cada vez maior de tokens e de harnesses etc., acho que isso é uma boa deixa para minha próxima pergunta, sobre raciocínio, para Adolf. Então, uma maneira de aumentar o número de tokens que consumimos é usar raciocínio, mas também é uma boa maneira de obter um resultado melhor, certo? Qual parte da pilha você acha que está…

5:13:05 …talvez menos preparada para todos esses tokens gerados por agents de raciocínio? Eu diria que adoro isso. Tem um custo: consumimos mais tokens. Isso significa que, para quem fornece infraestrutura, preciso de memória para manter os contextos longos e preciso de…

5:13:36 …caching para aproveitar ao máximo a reutilização dessas conversas. Então, imagino que ainda não implantamos em todos os lugares as tecnologias mais recentes, ou tudo o que é possível. Vejo que estamos basicamente numa fase em que o caching está se tornando mais importante, o caching em sistemas distribuídos. Há sinais claros de que estamos avançando para o serving distribuído, e esse paradigma de caching é importante para isso. Bem, acho que, se estivermos aqui no ano que vem, vamos rever o valor do caching nessa equação. >> Ah, muito interessante. Certo. Tenho uma última pergunta para vocês dois. Bom, dissemos que vamos voltar no ano que vem. Vocês estão convidados, segundo o Yan, mas provavelmente vamos voltar…

5:14:07 …daqui a cinco anos, espero. Então, vocês acham que haverá algum modelo de fronteira treinado em uma fábrica de IA europeia? Essa pergunta é para você. Pode começar, Yan. >> Sim, acho que sim. Estamos trabalhando nisso na Mistro: vamos disponibilizar 200 megawatts de capacidade no ano que vem e 1 gigawatt até 2030. E muito disso fica na Europa. Estamos treinando nessa infraestrutura, e os modelos MR atuais já são treinados na nossa infraestrutura. Então, daqui a cinco anos, com certeza teremos modelos de fronteira. >> Já estamos anunciando! [risos] >> Certo, ótimo. Então, qual é a tendência de infraestrutura mais superestimada em 2026? >> Essa é a minha paixão. Essa é para você também.

5:14:38 Do nada: tudo se autorreparando. O quê? Certo. E qual é a mais subestimada? Acho que, em infraestrutura, depende da camada que estamos analisando. É uma pergunta complicada, mas, em termos de software…

5:15:08 …de certa forma. Quer dizer, se olharmos apenas para o nível da infraestrutura, infraestrutura como software provavelmente é uma das tendências subestimadas: software que viabiliza a infraestrutura. >> Certo, boa resposta. Estou satisfeito. Então, muito obrigado, senhores. É isso para esta conversa. Obrigado, Adolf, e obrigado, Yan. Vamos aplaudir Adolf e Yan, por favor. [aplausos] Opa.

5:15:39 Certo. >> O público também fará parte do exercício de mortalidade daqui a cinco anos, né? >> Com certeza. Sim. Vamos todos voltar daqui a cinco anos. Muito obrigado. >> Certo. Vamos aplaudir Yan e Adolf mais uma vez, por favor. [aplausos] Certo. Com isso, estamos prontos para nosso próximo palestrante. Nosso próximo palestrante vem da Modal. Senhoras e senhores, por favor, recebam no palco Charles Fry. Certo.

5:16:10 Como vão? Certo. A música de entrada foi ótima. Estou empolgadíssimo. Estou pronto para fazer algum tipo de exercício de jazz. E é preciso muita energia para inference de baixa latência. Não só potência, mas…

5:16:42 …também garra. Então, é um começo apropriado. Sou Charles. Trabalho com engenharia de inference na Modal. Somos uma plataforma de infraestrutura. Hoje, vou apresentar o nosso manual, desenvolvido para otimizar a inference de LLM de baixa latência. Mas, antes de explicar como torná-la boa, quero falar sobre o que é inference de baixa latência e por que ela é tão importante.

5:17:13 Recentemente, foi lançado algo chamado Jev. Provavelmente ninguém mencionou isso a cada cinco minutos hoje. Jev é um decision model, um classificador genérico de zero-shot que funciona muito rápido. As pessoas ficaram muito empolgadas com ele. Criaram demonstrações bem legais. Uma das minhas favoritas no Twitter é aquela em que você digita uma palavra e recebe uma paleta de cores associada a ela. A pessoa que criou essa demonstração, Matt Deloreier, disse: “Isso é muito barato e rápido. Parece um salto à frente na criação de novos paradigmas de UX e UI.”

5:17:45 E a reação de muita gente que trabalha há bastante tempo na área de machine learning e processamento de linguagem natural foi bem diferente. Foi algo como: “Estou surpreso que todo mundo esteja tão empolgado com isso.” A resposta básica é que eles tornaram essa inteligência, que sempre esteve presente, mais barata e mais rápida ao mesmo tempo. De repente, isso abriu novas possibilidades de uso, caso você não…

5:18:15 …fique preocupado com a possibilidade de atingir um limite de uso, de gastar mil dólares só para fazer um ícone girar ou de esperar 30 minutos para o ícone começar a girar. De repente, surgem mais possibilidades. Ah, esqueci da declaração de patrocínio corporativo: este é um aplicativo da Jeff e da Typesafe, desenvolvido sobre nossa plataforma de nuvem. Esse é o tipo de coisa que eu gostaria de ajudar vocês a descobrir como construir por conta própria.

5:18:48 E Jev se encaixa em uma de três categorias básicas do que as pessoas criam usando inference de modelos de linguagem, ou inference de sequência. Minha visão de infraestrutura, pensando no backend, é que devemos dividir essas categorias de acordo com a métrica principal de desempenho. O desempenho é fundamental aqui. É o que viabiliza os paradigmas de UI e UX que algo como Jev, ou a versão original do ChatGPT, conseguiu simplesmente abrir, paradigmas que antes não existiam.

5:19:19 Esse desempenho é extremamente importante. Para chatbots, a métrica principal é quantos tokens por segundo você consegue devolver a um usuário: tokens por segundo por usuário. Para um decision model ou um modelo zero-shot, a métrica é outra. E a categoria final, a de inference de alta latência, inclui esses processadores de dados que talvez operem…

5:19:51 se preocupar com a possibilidade de atingir um limite de uso ou de gastar US$ 1.000 só tentando fazer um ícone girar. E você não vai esperar 30 minutos para esse ícone começar a girar. Aí, de repente, mais oportunidades ficam disponíveis para você. Ah, esqueci meu aviso de patrocínio corporativo. Sim, este é o aplicativo Jeff e Typesafe, desenvolvido sobre nossa plataforma de nuvem. Então, esse é o tipo de coisa que eu gostaria de ajudar você a descobrir

5:20:21 como construir por conta própria. E o Jev se encaixa, mais ou menos, em uma de três categorias básicas do tipo de coisa que as pessoas constroem com inferência de modelos de linguagem, com inferência de sequência. Minha visão sobre a infraestrutura de backend é que você provavelmente quer dividir essas categorias de acordo com o principal indicador de desempenho de cada uma. O desempenho é muito importante aqui. É o que viabiliza esses paradigmas de UI/UX

5:20:52 que algo como o Jev, no lançamento original do ChatGPT, conseguiu simplesmente abrir — algo que não existia antes. Então, esse desempenho é extremamente importante e, para chatbots, o principal indicador é quantos tokens por segundo você consegue entregar a um usuário. Portanto, tokens por segundo por usuário para um decision model ou um zero. E, então, a categoria final, a categoria de inferência de alta latência: esses processadores de dados que talvez operem

5:21:23 em um monte de dados do seu backend ou, no caso da Reduct, pode consumir milhares, milhões de PDFs, sabe? Eles têm outro tipo de métrica de desempenho, outra meta de performance: a quantidade de milhões de tokens que você consegue processar por dólar, ou talvez bilhões de tokens. Então, essa é uma inferência de latência mais alta, por isso não vamos falar sobre ela. Vamos nos concentrar na inferência de baixa latência. Na categoria de agents, temos trabalhado para servir os modelos Kimmy, da Moonshot AI, e os

5:21:56 como a diferença entre o que você obtém com algo pronto para uso — por exemplo, pegar a descrição no cookbook do SG Lang ou no cookbook do VLM e servi-la — e o que você consegue se analisar a carga de trabalho e otimizá-la, fazendo muitos ajustes de configuração e um pouco de engenharia de performance. No nosso caso, conseguimos cerca de cinco vezes e meia mais eficiência, em tokens por minuto por GPU, mas também uma velocidade cerca de três vezes maior por usuário. Então,

5:22:29 cerca de 400 tokens por segundo por usuário, em vez de pouco mais de 130. Isso nos permitiu servir em grande escala por meio de várias plataformas, como a OpenRouter, e em parceria com nossos clientes. E, no lado da baixa latência, obviamente você mencionou que o Jev está rodando no Modal, mas também escrevemos sobre como trabalhamos com a Decagon para alcançar a menor latência possível

5:22:59 para os procedimentos operacionais dos agents deles, que fazem esse trabalho de decisão dentro dos pipelines dos voice agents. Então, vamos falar sobre como isso é feito na prática. Esse é o tipo de manual de estratégias que desenvolvemos. O primeiro passo é entender a carga de trabalho que você está servindo e o hardware em que ela é executada. Depois que você tiver uma visão clara disso, pode começar a otimizar a performance. A

5:23:29 carga de trabalho diz o que você precisa fazer, e o hardware é o que faz isso para você. Ele indica: “Isto será fácil. Isto será difícil. Isto será dez vezes mais rápido do que aquilo.” Para entender a carga de trabalho e garantir que estamos na mesma página: acho que muita gente tem consumido IA principalmente por meio de APIs, sem necessariamente pensar no que acontece por dentro. Então, só para garantir que todos estamos alinhados: você envia algo como “Não criarás” para um servidor de inferência de modelo de linguagem.

5:24:02 A representação interna do modelo é calculada com base nessa entrada durante a fase de prefill. Isso gera alguns tokens, e depois você repete o processo várias vezes na fase de decode para gerar as saídas e completar o mandamento da Bíblia católica laranja: “Não criarás uma máquina à semelhança da mente humana”. Ao longo do processo, você armazena essas representações internas em algo chamado KV cache, para poder recuperá-las

5:24:32 mais tarde, em vez de ter que recalculá-las. E isso é uma parte muito importante, especialmente se você quiser servir inferência de agents com baixa latência. Se você estiver servindo algo um pouco mais parecido com o Jev, isso é menos importante por causa da estrutura da carga de trabalho e das solicitações que você vai receber. Com um agent, você vê algo assim: chega a primeira entrada do usuário, o LM responde e, depois, você recebe outra solicitação do mesmo usuário, que inclui aquela

5:25:04 resposta do LM e a primeira entrada dele. Depois, talvez você receba uma chamada de ferramenta do LM e, quando essa chamada retorna, ela também vai incluir todo o contexto anterior. Assim, a sequência de entrada é construída iterativamente, turno após turno. Algumas coisas desse campo e da forma como os LMs e a inteligência artificial funcionam são passageiras. Mas isso parece algo bastante fundamental e que deve continuar por bastante tempo.

5:25:35 Essencialmente, o usuário, o modelo e os sistemas externos que ele acessa constroem esse contexto de forma iterativa, criando algo de valor cada vez maior ao longo do tempo. Portanto, devemos esperar que esse tipo de construção interativa faça parte do funcionamento desses modelos de sequência. Mesmo quando se tornarem algo dentro de um robô andando pela sua casa, ou quando começarem a receber vídeos e produzir vídeos, provavelmente ainda vão se parecer bastante

5:26:05 com isso. Agora, uma observação um pouco mais específica e pontual. A boa notícia é que, no momento, se você está focado em alta interatividade e inferência de baixa latência, geralmente consegue operar com no máximo oito GPUs de data center. Se você consultar o excelente trabalho de benchmarking da SemiAnalysis e os benchmarks Inference X ou Inference Max, isso talvez esteja um pouco difícil de enxergar, porque são gráficos muito densos. Esta é a versão menos

5:26:36 densa que consegui encontrar. Você pode ver que, se quiser o maior throughput por chip, vai querer essas máquinas enormes, em escala de megawatts — não chegam a um megawatt, mas são máquinas realmente gigantes — com um monte de GPUs bem próximas umas das outras, dentro de um domínio NVLink. Você precisa, como diz aqui, de 40 dessas GPUs, 64 dessas GPUs. Mas, se quiser servir com a maior interatividade, se quiser o maior número de tokens por segundo por usuário, na verdade vai querer estar bem aqui embaixo. E, se olhar para

5:27:07 os pontos que estão aqui embaixo, vai ver que eles têm quatro ou oito GPUs. Então, você não precisa dessas máquinas sofisticadas, o que é uma enorme vantagem operacional. Certo. Já entendemos a carga de trabalho que estamos considerando e o hardware em que queremos executá-la. Agora, vamos pensar em como otimizar a performance. Em linhas gerais, o funcionamento é o seguinte: primeiro, você quer buscar várias melhorias grandes. Speculative decoding é uma das principais. Você pode obter

5:27:37 um aumento de velocidade de cinco vezes ou mais. Quantization, ou seja, reduzir a precisão, é outra grande melhoria de velocidade, mas tem implicações para a qualidade. Depois de conseguir essas grandes melhorias, há uma série de tarefas de porte médio no lado do host, como as tarefas comuns de engenharia de performance em sistemas de CPU. Com elas, você consegue ganhos de 50%, talvez até de 2x. Quanto mais incomum for o que você está fazendo, mais provável é que os ganhos estejam no lado do host. E só então você dedica

5:28:07 seu tempo a trabalhar em kernels de GPU e nesse tipo de coisa que deixa todo mundo mais empolgado. Então, vamos passar rapidamente por todos esses tópicos, em alto nível: como são e quando devemos usá-los? Primeiro, as grandes melhorias. Speculative decoding pega o processo de decode de que falamos, em que você gera uma frase de saída — por exemplo, o LM vai gerar: “O Modal é uma plataforma de computação serverless”. Em vez de executar esse processo

5:28:38 uma etapa de cada vez, você usa algo muito mais barato de executar, gera os tokens de saída e tenta adivinhar quais eles podem ser. Você faz uma especulação, e a ideia é a mesma da execução especulativa dentro dos processadores. Se houver alguma folga no sistema — como acontece quando você executa LLMs um token de cada vez —, você pode usar parte dessa folga para fazer um trabalho que talvez não seja aceito. Então, execute

5:29:08 instruções que talvez nem estejam no caminho de execução durante a execução especulativa, ou processar tokens que talvez não apareçam na saída, como a palavra “empresa” aqui. Mas é uma grande vantagem poder executar essas coisas em paralelo, especialmente quando se busca alta interatividade. Isso costuma trazer um ganho enorme. E o ganho é mais ou menos linear em relação à quantidade de tokens que você consegue fazer o especulador prever. Este trecho é de uma das nossas publicações no blog sobre especuladores. Basicamente, conforme você aumenta o número de tokens

5:29:39 aceitos em média, o aumento de velocidade também cresce. E são números inteiros, como 4 vezes mais rápido, 8 vezes mais rápido. Se você trabalha com desempenho, está acostumado a se esforçar para conseguir 5% ou 10%, mas aqui estamos falando de 500%. E uma das minhas coisas favoritas nisso, como alguém que trabalha com treinamento de machine learning desde o começo, é que a diferença entre um ponto como este, com um par de especulador e modelo, e outro como este é que você personaliza o

5:30:12 especulador ou o modelo-alvo para a carga de trabalho específica em que você quer que ele opere. Você treina o especulador para saber como aquele modelo se comporta com aqueles dados e, de repente, passa de seis vezes mais rápido para três vezes mais rápido e, depois, para cinco vezes mais rápido. E isso é a lição amarga do machine learning aplicada à engenharia de desempenho, o que é empolgante. As pessoas costumam perguntar: “Espere, como um modelo menos inteligente consegue prever o que um modelo mais inteligente vai dizer?” Há alguns motivos para isso funcionar. O principal é que

5:30:44 há muita estrutura nas saídas. Então, se você pegar algo das sessões do seu agente de programação, como o trecho acima, e traduzir para o formato que o modelo vê, isso fica ainda mais claro. A formatação do chat tem todos esses tokens especiais, que costumam ser bastante previsíveis. E isto aqui é uma citação do usuário, que provavelmente aparece antes na transcrição. Então é fácil de prever. Há apenas algumas chamadas de ferramentas, e só algumas delas são algo que você faria depois de dizer que ia ler aquele arquivo. Por isso, é bem fácil prever.

5:31:14 Mas o que o modelo-alvo está fazendo é processar esses tokens e criar uma representação interna rica, que será usada em muitos tokens futuros. Então, ao conseguir prever esses valores específicos com uma boa taxa de acerto, você consegue paralelizar a construção dessa representação. O que é bem legal. E essa representação, na verdade, é reutilizada nos modelos especuladores atuais. Eles não precisam ser um modelo de Markov, um especulador engram ou outro modelo de linguagem criado do zero. Eles pegam essas representações internas ricas do modelo-alvo e usam o que está acontecendo dentro do modelo.

5:31:46 Assim, conseguem, de certa forma, partir disso. A arquitetura específica é a Dlash. É o tipo de arquitetura de especulador que descobrimos funcionar melhor, aquela em que mais investimos e que nos proporciona grandes aumentos de velocidade em comparação tanto com a decodificação especulativa integrada a certos modelos quanto, é claro, com a

5:32:16 linha de base. Depois da decodificação especulativa, e de fazê-la funcionar bem, o próximo grande ganho vem da quantização. Com a quantização, você reduz a largura em bits da representação de ponto flutuante dos pesos ou das ativações do modelo. Ela passa de 16 bits para 8 bits e talvez até para 4 bits. Isso reduz linearmente a demanda por largura de banda de memória e aumenta linearmente o número de operações de ponto flutuante por segundo, porque os bits — ou os números — ficam menores.

5:32:47 Por isso digo que isso exige coordenação de toda a stack: você precisa descer até a camada de hardware e perguntar: “Certo, estou usando uma GPU que consegue aproveitar isso? Tenho uma H100 ou posterior para FP8? Tenho uma B200 ou posterior para FP4?” Mas isso também muda o comportamento do modelo. A vantagem da decodificação especulativa é que ela não altera em nada a distribuição de probabilidade das saídas do modelo. Já a quantização altera, então você precisa voltar até a camada da aplicação e perguntar: “A inteligência ainda é suficiente? As capacidades ainda são as de que preciso se eu quantizar o modelo?”

5:33:18 Com a quantização, há um visualizador bem legal no nosso LM Engineers Almanac que mostra o efeito da quantização. Neste caso, a quantização de 4 bits nesta imagem de um papagaio, em comparação com a original. Acho que talvez seja uma demonstração de quando a quantização funciona. Acho que as pessoas na primeira fila conseguem ver que a imagem está um pouco estranha, mas quem está no fundo da sala, ou talvez olhando para o celular com os olhos semicerrados,

5:33:49 talvez nem perceba que ela foi quantizada. E esse é o efeito com que você pode contar. Isso depende um pouco do que você está fazendo. Esses são grandes ganhos. Vamos falar da otimização do desempenho no host. O ponto principal é que a GPU faz todo o trabalho, mas a CPU pode atrapalhar. A CPU coordena todo o trabalho que acontece na GPU. Você quer garantir que o trabalho executado pela CPU não bloqueie o trabalho da GPU. Por exemplo: “Isso terminou. Agora preciso fazer algum trabalho para decidir o que fazer em seguida. Ah,”

5:34:20 “vou começar a executar coisas na GPU de novo.” Isso é muito ruim. É um intervalo ocioso, ou uma espera. Se você já trabalhou com um loop de eventos, conhece essa ideia: não bloqueie o componente rápido. Uma técnica importante para isso se chama captura de grafo CUDA. Ela permite que, em vez de iniciar um kernel de GPU por vez, você registre todos os kernels executados em uma ocasião e depois os inicie todos de uma vez. É uma maneira bastante eficaz de eliminar boa parte desse trabalho no host. Uma ferramenta para acompanhar

5:34:51 isso — e a minha favorita — é simplesmente observar o consumo de energia e a temperatura das GPUs. Se elas não estiverem perto de 100% da potência, provavelmente você não está usando a GPU inteira. Elas ficam bastante limitadas pela potência quando estão atingindo o desempenho máximo. Neste caso, conseguimos perceber visualmente que o consumo de energia dessa GPU estava bem abaixo do total, mesmo comparando esta, que está bem acima de 2.000 watts, com esta outra, que está abaixo disso ou meio que limitada a esse valor.

5:35:22 Isso não diz qual é o problema. Você precisa usar algo como um profiler para investigar. Você precisa dessas traces. É uma disciplina muito empírica. Então, o Nsight Systems ou o torch profiler — as ferramentas da Nvidia para isso — são as opções mais indicadas. Ao examinar esse caso específico, conseguimos determinar que uma dessas GPUs estava ficando para trás. Todas estas estão fazendo a mesma coisa. Os blocos destacados estão todos executando este deep gem. E estas três

5:35:53 GPUs estão todas esperando por esta, que está lenta. Descobrimos que o problema era algo relacionado ao reconhecimento de regiões NUMA. Isso fazia com que uma delas fosse sempre um pouco mais lenta, porque estava no soquete errado. Há muitas coisas que você pode investigar no nível do host com o py-spy, já que os processos estão rodando em Python. Assim, você pode observar o que está acontecendo no Python e descobrir bastante coisa. Temos uma publicação no blog que fala de um caso específico em que transformamos uma alocação repetida em um simples cache, um dicionário Python. Mas eu

5:36:24 Acho que você pode chamar isso de cache de handles de pool CUDA IPC, se for coisa de GPU de IA. Mas era só um dicionário Python que mantinha os handles desses itens e, de repente, isso fez a coisa rodar 10% mais rápido. Isso estava focado principalmente em uma única réplica, com algumas GPUs por vez. Quando você tenta escalar, vai encontrar problemas de roteamento. Então, você pode prever o desempenho antes de escalar, mas isso simplesmente não acontece quando você escala. Uma coisa específica que

5:36:55 pode acontecer é você acabar com latências de cauda muito maiores do que espera, que parecem surgir aleatoriamente. E a resposta é que elas são meio aleatórias mesmo. Elas vêm da maneira como você faz o roteamento. Isso é especialmente importante para cargas de trabalho de agent por causa do KV cache. Se você não fizer o roteamento com cuidado em relação ao KV cache, a diferença entre um acerto e uma falha de cache pode ser de 30 segundos contra 500 milissegundos. Medimos isso em uma de nossas

5:37:26 implantações e determinamos que havia vários motivos para, em vez das quatro ou cinco solicitações simultâneas que estávamos tentando atingir, vermos essa enorme dispersão excessiva de solicitações. A solução foi simplesmente tornar o roteador mais inteligente. Ele precisou se tornar muito mais stateful e ciente do aplicativo, de coisas como a carga e o estado do KV cache. Mas isso conseguiu reduzir essa dispersão excessiva e eliminar enormemente esses picos, melhorando muito o desempenho.

5:37:56 Só então você pode pensar no desempenho da GPU e em otimizar coisas nas GPUs. Em geral, os kernels são relativamente padronizados. Estão próximos da velocidade da luz. As arquiteturas não estão mudando tanto. E há kernels muito bons da Nvidia, do grupo Treehouse e de outros. Então, há apenas alguns pontos percentuais a ganhar aí. Isso importa bastante em escala, mas não é algo com que se preocupar no início, quando você está começando a servir sua própria inference. A ferramenta específica para isso, o Nsight Compute,

5:38:28 permite descer até o nível do assembler e descobrir de onde vêm os problemas de desempenho. Mas, antes de abrir o Nsight Compute, eu sugiro pegar um marcador e um quadro branco. Se você olhar o blog de Tri Dao e da Together sobre o trabalho com o kernel FlashAttention, verá que a maneira como decidiram no que trabalhar, como decidiram quais problemas importavam, foi simplesmente anotar os dados e as velocidades: quanta informação está entrando, quantas operações precisam acontecer com ela e com que rapidez conseguimos enviá-la de volta. E isso é

5:39:01 algo que você pode fazer com base nos primeiros princípios, antes mesmo de começar, e isso se aplica a toda a stack. Se você entender essas coisas sobre o hardware com que está trabalhando, poderá avançar muito mais sem se confundir nem desperdiçar dinheiro. Ótimo. Eu disse que não íamos falar sobre alta vazão, mas, na verdade, menti. Há um pequeno trabalho que está sendo lançado hoje e que eu queria compartilhar com as pessoas aqui

5:39:32 no AI Engineer Paris. Na Modal, temos pensado bastante em inference de baixa latência, por causa de quanto as pessoas adoram coding agents e coisas como Jev. Mas há bastante demanda por inference de alta vazão para coisas bem diferentes. O exemplo típico disso, sobre o qual vamos falar, é AI SQL. Isso não é o mesmo que a IA escrever SQL — pelo que entendo, agora a IA escreve todo o SQL do

5:40:03 mundo. Eu certamente escrevi este aqui, mas não é algo que eu execute em produção. Mas, sim, isso não é a IA escrevendo SQL. Na verdade, é o sentido oposto: usar SQL para escrever prompts para IA. A ideia é que você tem todas essas informações sobre seus clientes e seus produtos. Já quis simplesmente perguntar ao ChatGPT quais dos seus clientes poderiam comprar quais dos seus produtos? Isso pode ser expresso

5:40:36 como um join relacional, o tipo clássico de coisa que você normalmente faria no seu banco de dados transacional ou analítico. Mas o problema é que este prompt aqui vai levar você à falência se estiver usando uma API proprietária. Executá-lo no seu banco de dados pode gerar 8 milhões de consultas de uma só vez. Aí você dispara todas elas e lá se vai seu orçamento de tokens. Sim, essa é uma maneira de estourar o limite de tokens, mas acho que agora

5:41:07 todos concordamos que é uma má ideia. O principal que torna isso um problema de otimização totalmente diferente da inference de baixa latência é a enorme quantidade de estrutura. Este é um plano de consulta para uma consulta um pouco mais complicada, com alguns joins. O plano de consulta diz quais são todos os documentos que vou usar para construir prompts. É assim que eles vão interagir uns com os outros. E são todos os 8 milhões, 10 milhões ou sei lá quantos prompts que vou

5:41:37 gerar e enviar para o mecanismo de inference. Os mecanismos de inference existentes não sabem nada sobre SQL. Eles só conhecem, por assim dizer, a semântica de solicitação e resposta, talvez de solicitações em lote. Então, e se você aproveitasse uma ideia dos bancos de dados e fizesse planejamento de consultas, combinando-o com o mecanismo de inference? Fizemos isso em parceria com Treya Shankar, da CMU, e obtivemos uma aceleração de cerca de 14 vezes em relação ao VLM de referência, naquela consulta específica que acabei de mostrar,

5:42:09 além de alcançar mais de um bilhão de tokens por minuto em uma única H100 e executar essa consulta por apenas US$ 2, em vez de quase US$ 30 com um VLM, e por bem mais com algo como os menores modelos da OpenAI. Isso é open source. Acabamos de lançá-lo hoje. Este é o primeiro anúncio. Você pode encontrá-lo no site da Full Stack Data Labs e no GitHub deles. E você

5:42:41 pode ler sobre isso no nosso blog. Confira aqui. Todas as informações que compartilhei hoje estão explicadas em mais detalhes no nosso blog, junto com vários recursos sobre como executar sua própria inference na modal.com. Vou ser retirado do palco em cerca de 30 segundos. Então, vou apenas dizer que estou contando tudo isso porque quero que as pessoas executem sua própria inference e porque acho que a plataforma de infraestrutura serverless que construímos na Modal é o melhor lugar para executar essas coisas. Então, quando você tentar executar

5:43:12 sua própria inference, acho que vai perceber que a Modal é o lugar certo para fazer isso, seja executando o código você mesmo, seja aproveitando os Modal Auto Endpoints, nosso sistema automatizado para produzir implantações de inference personalizadas para os usuários. Certo, muito obrigado. [aplausos] Muito obrigado, Charles. Certo, vamos aplaudir Charles mais uma vez. Certo. [aplausos] É, eu definitivamente não quero executar

5:43:42 essa consulta e levar a mim mesmo à falência. Isso é certo. Nosso próximo palestrante vai falar justamente sobre o oposto: como executar modelos em dispositivos menores. Ele vai falar sobre edge. Nosso próximo palestrante é Dominic Payak, diretor sênior na ARM. Por favor, recebam no palco o diretor sênior da ARM, Dominic Payak.

5:44:13 Certo. Certo. Oi, pessoal. Meu nome é Dominic Pike. Estou na ARM e hoje vamos falar

5:44:44 sobre o que acontece quando você executa inference na borda. Então, há três coisas acontecendo agora que, na minha opinião, vão abrir oportunidades incríveis. Uma delas é simplesmente a velocidade com que modelos capazes, pequenos e openweight estão se tornando disponíveis. Combine isso com o fato de que há muito hardware acessível no qual você pode instalar essas coisas, e surge o potencial para dispositivos um pouco mais inteligentes, um pouco mais atentos à intenção do usuário e capazes de oferecer experiências que nunca

5:45:14 foram vistas antes em todo tipo de ambiente. Então, sim, sou da ARM. Um pouco sobre a ARM: a ARM é a plataforma de computação que está no centro dos dispositivos à sua volta, em todos os lugares, desde a infraestrutura altamente eficiente de data centers. Há IA física em aplicações automotivas e robótica, com aplicações de tempo real rígido e críticas para a segurança, até praticamente todo smartphone que você já teve, computação para clientes, IoT industrial e dispositivos emergentes. E é nisso que eu e minha equipe temos

5:45:45 trabalhado: viabilizar a criação e a chegada ao mercado de novas classes de dispositivos. Sou um geek da história da computação. Aliás, adoro o fato de que esta Station F fica na praça Alan Turing. Não sei se pronunciei “parvis” corretamente, mas é fascinante olhar para a história da computação e para onde ela está nos levando hoje. Se olharmos para os últimos 80 anos de interação entre as pessoas e as máquinas, começando lá nos primeiros dias, talvez

5:46:16 há 80 anos ou mais, com cartões perfurados e fitas, depois teclados, mouses e ponteiros, e telas sensíveis ao toque, cada geração tornou a computação mais fácil de acessar e de usar. Mas, em todos os casos, ainda cabe ao usuário dedicar atenção àquele dispositivo e enfrentar o atrito mental de converter o que quer fazer em etapas que a máquina entenda, em um formato que possa ser inserido naquele dispositivo. E o

5:46:49 mais incrível da era da IA é que ela inverte essa relação. De repente, as máquinas nos entendem. Não estou dizendo de forma consciente, mas elas conseguem entender a linguagem natural e converter nossa intenção em ações e chamadas de ferramentas para realizar tarefas. Então, de certa forma, estamos falando de inference na borda, mas isso não é algo novo. Há muitos anos, já existem detecção de objetos e CNNs rodando em dispositivos de borda. Então, imaginem aplicações

5:47:20 em inspeção de fábricas, monitoramento de vagas de estacionamento e todo esse tipo de coisa. Mais recentemente, surgiram embeddings, LLMs e, depois, aplicações agênticas, que, suponho, são LLMs capazes de raciocinar bem o suficiente para chamar ferramentas e lidar com contexto por tempo suficiente para agir de forma autônoma em nome dos usuários. Isso está se tornando possível agora. Acho bom dar um passo atrás e observar o quão rápido isso aconteceu. Então, fiz este gráfico e, na verdade, ele mostra, mais ou menos, como era…

5:47:50 com o GPT3.5. Foi a primeira vez que realmente experimentei o que era um LLM, e foi uma experiência impressionante. Mas, se observarmos a rapidez com que essa capacidade foi sendo comprimida em modelos com cada vez menos parâmetros, até os dias de hoje, agora ela cabe em cerca de um bilhão de parâmetros e pode rodar em um smartphone ou em um Raspberry Pi na palma da sua mão. Isso é fenomenal. E, aliás, sei que benchmarks não são perfeitos, e um LLM provavelmente é ainda menos.

5:48:22 Mas isso indica uma tendência que vai continuar. Se eu estiver aqui no ano que vem, esse número terá caído ainda mais. E não se trata apenas de responder a perguntas de conhecimento geral; também envolve raciocínio. Aqui estamos vendo o limite do que se consegue fazer com quatro bilhões de parâmetros ativos, ou seja, o tipo de capacidade computacional dos dispositivos de borda atuais. E, de novo, com a chegada dos mixture of experts, isso passou a superar o que

5:48:54 o Claude Sonnet 3.5 fazia quando foi lançado, em sua pontuação de fronteira no GPQA Diamond. Acho que isso foi há um ano e meio. Essas coisas estão avançando a uma velocidade fenomenal. E, claro, não se trata apenas de capacidade. Quando falamos de interação com usuários, também importa a latência. E agora há modelos que podem rodar tranquilamente no dispositivo e fazem conversão de fala em texto com uma latência útil para criar uma interface de voz, sem precisar enviar essa

5:49:25 inference para a nuvem. E acho muito interessante considerar o que determina esses requisitos de latência. No fim das contas, devemos projetar essas coisas de acordo com o que as pessoas esperam e com aquilo com que se sentem confortáveis. Acho este gráfico fascinante. É um estudo antropológico sobre a alternância de turnos em conversas humanas e a latência entre os interlocutores. É interessante que isso dependa da cultura e do idioma. O japonês, por exemplo, é muito rápido e eficiente nas respostas. Já o dinamarquês é bem descontraído e muito lento.

5:49:57 Não sei se isso acontece porque o verbo fica no fim da frase, aliás. E o inglês fica mais ou menos no meio. Isso dá uma noção de onde esses sistemas precisam chegar. Então, espero que vocês estejam tão empolgados quanto eu com a possibilidade de executar toda essa inference em dispositivos de borda. Talvez vocês digam: “Bom, já conseguimos fazer isso no data center. Por que levar para a borda?” É uma boa pergunta. Acho que há motivos muito bons para isso. O primeiro é a eficiência. E acho que muitas pessoas já estão analisando o uso de

5:50:28 tokens e pensando em quanto disso poderiam transferir para um dispositivo local ou um dispositivo no local. Também há a possibilidade de personalizar isso. Talvez você queira usar dados pessoais ou dados proprietários da sua organização e mantê-los internamente. E existe ainda a oportunidade de criar dispositivos atentos à intenção, que talvez observem sua fala ou tenham câmeras e estejam constantemente olhando e ouvindo. Muitas pessoas talvez

5:51:00 queiram escolher se esse conteúdo será compartilhado, saindo do dispositivo e indo para um data center, ou não. Então, acho que esses são motivos muito convincentes para executar a inference na borda. E eu disse que há outra coisa acontecendo aqui. Acho que é a combinação entre esse hardware acessível e esses modelos openweight. Juntar essas coisas cria, na minha opinião, uma oportunidade fascinante. Não sei quantas pessoas aqui são fabricantes de hardware ou se interessam por hardware. Tem gente de hardware aqui? Podem levantar a mão?

5:51:32 Ótimo. Que bom ver isso. Há muitos anos, as pessoas vêm criando inovações de hardware incríveis usando módulos combináveis de empresas como Raspberry Pi ou Arduino, talvez inicialmente, e depois criando projetos totalmente novos com base nisso. Acho que essa combinação de inovação em hardware com esses modelos abertos vai abrir possibilidades muito interessantes. Os mais atentos entre vocês talvez tenham notado

5:52:02 que o micro duck está ali no canto. E meu exemplo favorito dessa combinação — porque acho que ela ainda não está acontecendo de forma tão disseminada quanto poderia — é um ótimo exemplo inicial: o Reichi Mini da Hugging Face e da Pollen Robotics. Sei que o Reichi Mini é da França. Fiquei muito feliz por participar do programa de testadores beta do Reichi Mini. No Natal passado, eu e meu filho montamos o Reachi Mini, e fiquei muito feliz em ver isso. Então

5:52:33 Dentro dessa coisa, há uma plataforma Stewart, então ela consegue expressar emoções com a cabeça, e tem vários servos que movem a plataforma da cabeça. Ela tem um ARM Cortex M0 ali dentro. Há atuadores na antena. A versão com Wi-Fi tem um módulo de computação Raspberry Pi Compute Module 4. Com isso, você pode executar alguns aplicativos no próprio dispositivo ou usá-lo para chamar serviços de inference fora do dispositivo. Isso é muito legal. Mas

5:53:03 não é só hardware. Também é um SDK open source e uma comunidade de desenvolvedores criando aplicativos muito legais para essa plataforma. E aqui está um exemplo de aplicativo que eu gostaria de destacar. Este foi feito pelo nosso próprio Marco Domingo, da ARM, e ele criou um app que fica na sua mesa e, se você usa o celular ou começa a ficar rolando a tela sem parar, ou se distrai, ele diz para você parar. E esse app ganhou um prêmio. Isso rendeu a ele um ingresso VIP

5:53:33 para a Nvidia GTC, em San Jose, neste ano, e um DGX Spark. E era o meu Reachy Mini. Tenho que dizer que não estou ressentido com isso, mas parabéns ao Marco. É um app legal e, na verdade, se você acessar a loja de apps, ele já está disponível hoje, no Hugging Face Space onde eles mantêm os apps do Reachy Mini. No projeto desse tipo de aplicativo no dispositivo, existe um desafio de engenharia, porque há limitações, certo? Então, você precisa levar em conta o poder de computação e a memória disponíveis e, muitas vezes, precisa dividir

5:54:04 essa tarefa para aproveitar melhor o hardware disponível. Em um aplicativo de visão, é bastante comum ter, por exemplo, um detector de movimento. Talvez isso acione a detecção de objetos e, se você classificar as coisas que lhe interessam, capture uma região de interesse; talvez gere embeddings de imagem e só então acione um VLM. Essas tarefas podem ser realizadas por diferentes tipos de processadores no dispositivo e, em alguns casos, podem ser enviadas para outros dispositivos ou até mesmo para o data center. E aqui está

5:54:37 outro exemplo. Este é o app que fiz durante o teste beta do Reachy Mini, e ele está rodando inteiramente em um Raspberry Pi 5. O que eu adoro nele é que você diz alguma coisa e o Reachy imediatamente vira a cabeça. Há algo mágico na IA incorporada: um alto-falante inteligente pode apenas emitir um som ou acender o LED, mas ter um personagem virando a cabeça para olhar para você e depois responder é uma experiência muito legal. E acho que, ao fazer isso, eu estava usando um Raspberry Pi, que certamente é capaz de executar vários LLMs, mas

5:55:08 por causa da latência, escolhi usar embeddings, fazer uma correspondência semântica e chamar tools com base nisso. Então, você ainda pode perguntar a ele sobre o tempo ou as horas; ele pode gerar uma resposta usando text-to-speech no próprio dispositivo e responder. E aqui está a demonstração do Marco. A propósito, esqueci de dizer que, na área principal da exposição, lá fora, depois desta palestra, o Marco vai mostrar essa demonstração ao vivo e vocês podem fazer perguntas a ele. Basicamente, o que temos aqui é o DGX Spark dele, então ele tem um dispositivo mais potente, que ganhou como prêmio

5:55:41 e está executando outra demonstração interativa, parecida com um agent. Desta vez, está usando o Mistral Ministral 3 no dispositivo e fazendo speech-to-text. Depois, está criando respostas, sintetizando uma resposta com text-to-speech e reproduzindo-a. Além disso, está fazendo vários tool callings. Então, ele consegue, sabe, você pode perguntar o que ele está dizendo. Ele vai contar para você. Na verdade, talvez eu reproduza o vídeo.

5:56:12 Essa pode ser uma maneira melhor de fazer isso. Deixe-me fazer isso rapidinho. >> Certo. >> Sim. >> Pode cumprimentar o pessoal? Oi, pessoal, sou o Reachy. Prazer em conhecer vocês. >> Tenho aqui um crachá da AI Engineer. Vamos ver se o Reachy consegue fazer alguma coisa com ele. Ei, Reachy. >> Sim. >> Pode conhecer o participante? >> Mostre seu crachá. Sim. Entendi. Me dê um segundo.

5:56:43 Oi, Dominic. Que bom ver você na conferência AI Engineer. Vejo que você é da ARM. Eles são conhecidos por projetar arquiteturas de CPU baseadas em RISC que alimentam tudo, de smartphones a supercomputadores. >> E agora, por fim, pode dançar? >> O que achou? Foi demais? Quer que eu dance de novo? Até mais, pessoal. O Reachy vai recarregar. Tenham um ótimo dia. >> Certo. >> Então, adoro o personagem que ele tem e

5:57:15 a personalidade que o Reachy tem com o Ministral, aliás. “Foi demais?” é uma demonstração muito legal. Se vocês forem lá fora, como eu disse, podem ver se ele consegue ler seu crachá e contar a sua sorte, etc. É muito legal interagir com ele pessoalmente. Esses são alguns exemplos, mas falei no começo sobre intenção. E vocês provavelmente já ouviram falar da economia da intenção. A economia da atenção é quando as pessoas ficam olhando para aplicativos, aparecem anúncios e coisas assim. A economia da intenção é entender

5:57:47 o que as pessoas querem e oferecer soluções sem que elas precisem explicar tudo detalhadamente. Acho que é assim que eu descreveria. E aqui está um pequeno exemplo de interação que poderia ser possível com essa intenção. Por exemplo, se você tiver uma luminária de cabeceira do Reachy, conectada ao seu sistema Home Assistant, se você disser que terminou o dia, talvez ele não consiga interpretar isso. Mas, se entender suas preferências em relação à temperatura do ar-condicionado ou à iluminação, poderá agir de acordo com elas, se tiver contexto do ambiente e se o Reachy estiver, talvez, olhando ou ouvindo e se lembrar do contexto que está recebendo. Ele pode perceber, por exemplo: “Ah, seu parceiro está dormindo.”

5:58:18 Então, talvez o Reachy não diga nada. Apenas acena com a cabeça, diminui um pouco as luzes e vai dormir também. E acho que essa capacidade de oferecer uma UX melhor com menos interações com um dispositivo é realmente o ponto principal disso. Este é apenas um pequeno exemplo, e acho que há

5:58:49 milhares de outros. E isso pressupõe que há um agent rodando aqui. Falamos sobre visão, áudio e fluxos de sensores, e talvez integração com o Home Assistant. Na prática, esses são eventos ou estados que podem ser consultados por um sistema agentic. E, claro, com o agent, há um harness rodando em uma CPU, e essa CPU faz várias coisas para gerenciar o contexto e a memória. E então eu

5:59:19 acho que o ponto principal aqui é quanto da inference pode ser feita fora do dispositivo. Acho que esse é um problema de orquestração no qual grande parte do setor está concentrada hoje. Certamente, o roteamento ciente da tarefa e a capacidade de avaliar se é possível executar uma tarefa no dispositivo são questões fundamentais. Vamos analisar isso daqui a pouco. E, por fim, temos falado bastante sobre aplicativos voltados ao consumidor e como as pessoas interagem com dispositivos. Há muitos

5:59:50 sistemas embarcados por aí com computadores que talvez estejam em ambientes industriais, estufas inteligentes ou todos os tipos de sistemas de edifícios comerciais, onde eles monitoram principalmente sensores ou talvez acionem mecanismos, mas com pouca interação humana. Então, gosto muito de pensar nessa ideia de milhares de sistemas embarcados que existem por aí. Será que há potencial para um sistema embarcado agentic? Não estou dizendo que o agent

6:00:20 executa todas essas tarefas, enquanto o agente assume o papel de supervisor. E, quando algo acontece fora do previsto, ou seja, se houver uma falha que o projetista desse sistema não previu, esses agentes conseguem improvisar e corrigi-la? Acho que um experimento mental muito interessante é o seguinte: também sou fã de exploração espacial, certo? A Voyager 1 é, acho, o objeto feito pelo ser humano mais distante da Terra neste momento, já saiu do nosso sistema solar e está…

6:00:50 Há alguns anos, houve uma falha em um dos chips de memória desse dispositivo, e a NASA conseguiu criar um patch para redirecionar o funcionamento, basicamente, e corrigir o erro. Mas o tempo de ida e volta da comunicação era de cerca de 22 horas e meia, e a comunicação para fazer isso era de algo em torno de 100 bits por segundo. Então, é interessante pensar se agentes poderiam ser usados para preservar esses sistemas, monitorá-los e mantê-los em bom…

6:01:21 estado. E acho que esse é um dos caminhos realmente interessantes para explorar no tema da IA híbrida. Há muitos artigos de pesquisa interessantes nessa área e alguns projetos open source, como Light LLM ou Root LLM, que podem ser aplicados a esse desafio: a inference pode ser executada nesse dispositivo limitado, com um modelo que caiba nele, ou preciso enviá-la externamente, para um equipamento mais potente? Outro dia, eu estava fazendo alguns experimentos e…

6:01:52 vi que há algumas estratégias diferentes. Acho que o kernel de embedding é o mais rápido, porque você não precisa executar o prompt de fato. Você só precisa de algum tipo de conjunto de calibração. Analisa prompts que foram executados com sucesso localmente e os que não foram, e vê qual deles é mais parecido com a sua pergunta. Há outras soluções, como a incerteza calibrada ou até a sondagem do estado do decoder, que são possíveis depois que você já executou a inference. Então, você já elaborou uma resposta ao prompt e talvez precise…

6:02:23 adiar a execução para fora do dispositivo se a confiança for baixa ou se ele classificar algo que teria falhado. Isso é muito interessante, devo dizer. Esses evals realmente analisam conjuntos de evals com um único prompt. Há o PinchBench, o Chlor… é Chloral? Há vários evals que analisam tarefas com várias etapas. Costumo achar que, nesses casos, o melhor a considerar é a sua própria aplicação.

6:02:55 Então, falei bastante sobre o que podemos fazer com essa combinação de modelos realmente eficientes, hardware acessível e a inspiração para criar dispositivos um pouco mais ponderados e menos intrusivos. Acho que isso beneficiaria todo mundo. Mas, é claro, também devo falar sobre o hardware que está por trás de boa parte disso. Mencionei no início que trabalho na ARM, e a ARM tem soluções de processadores que vão desde esses dispositivos de baixo consumo, como wearables ou nós de sensores, com nossos Cortex-M e Ethos, até…

6:03:27 plataformas baseadas em Linux com Cortex-A, que você pode encontrar no Jetson ou no Raspberry Pi, e chegam até a infraestrutura de data centers. Nosso foco é oferecer uma estrutura de software comum. Recentemente, anunciamos um portal de IA com modelos otimizados e também ferramentas de otimização de desempenho. E uma coisa que eu certamente recomendaria a vocês… Vou mostrar…

6:03:58 este código QR no final. Por favor, inscrevam-se para se tornarem clientes de acesso antecipado a esse produto. Queremos receber o feedback de vocês e melhorá-lo para as aplicações que gostariam de desenvolver. E aqui vão alguns exemplos. Incorporamos kernels do Clyde AI ao Llama CPP e ao Onyx Runtime. Quando o Gemma 4 foi lançado, ele funcionava de maneira otimizada com SME2. Mas não são só as novidades. Também levamos em conta modelos e…

6:04:29 hardware já estabelecidos e muito usados. Gosto muito deste exemplo, que acabamos de lançar — ou que será lançado muito em breve —: o Ultralytics YOLO 26, otimizado especificamente para a ISA do Raspberry Pi 5. Ele ficou 1,87 vezes mais rápido na inference. Acho importante destacar que, normalmente, quando se analisam os números de FPS desses modelos, se eles estiverem rodando na CPU, ocupam os quatro núcleos. E, em uma…

6:04:59 aplicação, isso não é ideal. Você quer ter alguma margem para fazer outras coisas. Esse tipo de otimização faz a diferença entre ter dois núcleos livres para executar a sua aplicação e rodar outros tipos de algoritmo sobre essa saída. Acho isso muito interessante. Certo. Se quiserem mais recursos, aqui está de novo o código QR para developer.arm.comai. Inscrevam-se. Há acesso antecipado às nossas ferramentas de otimização, e recomendo que vocês as experimentem. Além disso…

6:05:30 também ficarei feliz em me conectar com vocês pelo LinkedIn ou mais tarde, ali perto do Reachy. E, só para repetir: acho que o Marco Domingo estará lá às 16h. Não será logo depois desta palestra, mas durante o intervalo. Ele estará no palco da expo com o Reachy Mini, caso queiram conversar com ele e interagir com o Reachy. Certo. Muito obrigado. Valeu. [aplausos] Sinto uma conexão com o co…

6:06:48 Como vocês estão se sentindo, pessoal? Bem? Certo. Vocês sabem o que vou fazer, não é? Como vocês estão, pessoal? Tudo bem. Acho que a próxima apresentação vai ser ótima. Muito obrigado, Dominic, pela apresentação. Agora vamos passar ao nosso próximo palestrante, que vai falar sobre produção de mapas agentivos para agentes de programação em grande escala. Estou muito curioso para saber do que se trata. Quero ver o que isso significa. Mas…

6:07:19 por favor, recebam no palco o vice-presidente de engenharia da Cognition, Yanis Sorakis. [música] Certo, vamos ver. Opa. Estou conectado ao…

6:07:52 projetor certo? Clássico. Me deem alguns segundos para resolver isso. Aham. Está bom, está bom. Parece promissor. Preciso ver como estendo minha tela. Ah, apresentação de slides. Excelente.

6:08:23 Muito obrigado pelo convite. É um grande prazer falar na AI Engineer Paris, para esta excelente plateia. Estou muito animado para mostrar a vocês o que preparei hoje: uma abordagem para lidar com problemas muito grandes, que abrangem toda a base de código. Então, vamos começar. Algumas palavras para nos apresentar: somos a Cognition, um laboratório de pesquisa aplicada em IA. Nosso DNA fundador está em pesquisa de IA…

6:08:56 programação competitiva e matemática competitiva. Estamos sediados em São Francisco, mas hoje estamos espalhados pelo mundo, inclusive em Londres. Essa é a nossa base europeia de operações, onde estou baseado, e somos os criadores do Devon. O Devon foi o primeiro agent de programação com IA na nuvem e, desde então, cresceu e se tornou uma plataforma, tanto em termos de diferentes formatos — locais e para desktop — quanto em profundidade…

6:09:29 no que diz respeito às diferentes integrações e personas de agents que oferecemos ao longo do SDLC. Implantamos o Devon nas organizações mais sofisticadas do mundo. Elas vão desde bancos sistemicamente críticos, como Goldman, Citi e Santander, até o Exército dos EUA, grandes empresas de tecnologia e startups menores, nativas de tecnologia e de rápido crescimento…

6:10:00 E adoramos enfrentar tarefas de programação realmente difíceis. Quero refletir sobre nossas experiências com as classes de problemas que alguém pode encontrar. Vamos começar pensando em duas categorias, certo? Vamos chamá-las de cargas de trabalho agentivas localizadas, que são basicamente como uma sessão mediana com um agent. Quero implementar um…

6:10:30 recurso ou uma área específica da base de código em que quero, por assim dizer, escrever alguns testes ou ampliar a cobertura de testes existente; dada uma parte específica do meu proxy de banco de dados, quero otimizar consultas e assim por diante. Isso diz respeito a um trabalho que é, por assim dizer, um problema delimitado. É um conjunto de arquivos relevantes na base de código, certo, que basicamente modularizam toda a lógica e

6:11:01 igualmente importante: se eu dissesse a um agent o que fazer, eu apontaria explicitamente os arquivos ou, se não fizesse isso, ele poderia facilmente encontrar a área relevante da base de código para realizar a tarefa. Agora, vamos considerar o que eu chamaria simplesmente de tarefa que abrange toda a base de código. E, aliás, abranger toda a base de código não significa apenas um único repo. Pode haver

6:11:32 vários repos. Vamos considerar, por exemplo, um caso ao qual voltaremos várias vezes hoje: a análise de segurança. Qual é o perfil de segurança da minha aplicação? Sabemos que existem níveis de qualidade de segurança individuais dos diferentes módulos da base de código. Mas o que é igualmente importante são as diferentes maneiras como eles interagem e como essas coisas podem evoluir no mundo real, como podem se conectar para revelar

6:12:03 vulnerabilidades. Algo semelhante é a extração de lógica comum. Trabalhamos com clientes que têm bases de código muito, muito grandes. Eles querem padronizar a maneira como tratam operações aritméticas, fórmulas financeiras ou até mesmo as formas de interagir com o banco de dados na infraestrutura. Antes de mais nada, isso é um problema de busca, mas também é um problema de compreensão e de encontrar todas as diferentes nuances

6:12:35 às quais uma biblioteca comum precisa se adequar e assim por diante. Há uma interação complexa entre os componentes. Tomemos o exemplo da segurança: a qualidade de segurança dos meus microservices individuais pode ser aceitável. Digamos que, se eu os analisasse isoladamente, encontraria vulnerabilidades de baixa prioridade que poderiam ficar na lista de pendências, mas, quando encadeadas

6:13:05 juntas, elas podem dar origem a uma exploração crítica. Portanto, para essas tarefas, o resultado é confiável quando se considera a totalidade da base de código, da aplicação implantada ou dos conjuntos de aplicações. Certo. E, claro, alguém pode dizer: “É por isso que temos testes de ponta a ponta. É por isso que, no nosso SDLC, temos os diferentes controles de qualidade e assim por diante.” Sem dúvida. Nosso objetivo é sempre antecipar, certo, para detectar essas coisas e estar cientes delas o mais cedo possível. Agora, se eu pudesse examinar um pouco mais de perto os desafios que um agent poderia enfrentar nessas tarefas que abrangem toda a base de código: estou dizendo “você pode, por favor, encontrar…” Quero encontrar ocorrências de uma fórmula específica, de uma lógica específica, que aparece em diferentes variações pela minha base de código, porque quero extraí-la para uma biblioteca comum. Certo, há um

6:13:39 desafio de encontrar o trabalho em primeiro lugar. Certo, é um problema de busca. Certo, os agents vão passar muito tempo procurando e voltando atrás, consumindo tokens. Segundo: poluir o contexto. Vai se acumular uma quantidade enorme de informações, competindo por atenção. O contexto será muito variável e diversificado. E, terceiro, qual é, na prática, nosso critério para parar? Certo. Mais uma vez, para apresentar esse argumento da forma mais sólida possível,

6:14:10 alguém diria: “Sim, é claro que não vamos resolver esses problemas grandes em uma única sessão. Haverá algum tipo de orquestração de agents. Haverá algum tipo de ciclo externo do agent. Vamos decompor o problema em tarefas diferentes. Vamos definir um DAG que indique como essas tarefas precisam ser concluídas e

6:14:41 depois teremos algum tipo de ciclo interno e o agent. Precisamos construir tudo isso, certo? Porque, obviamente, ninguém vai resolver tudo de uma vez com um prompt do tipo: ‘Ei, por favor, corrija as vulnerabilidades de segurança’. Sem dúvida. Meu argumento hoje é apresentar a vocês uma estrutura para pensar sobre o problema, que ofereça os melhores resultados em termos de desempenho e custo, e fazer disso um conceito de primeira classe no nosso produto.

6:15:12 Mencionei isso antes: o raciocínio de um único agent. Não vou me alongar muito nesse ponto. O tempo gasto procurando, a poluição do contexto e assim por diante significam que o problema de um único agent não resolve tarefas muito grandes que abrangem toda a base de código. Como abordamos isso? Propomos uma variação ou extensão da estrutura MapReduce, uma ideia dos sistemas distribuídos. Quantas pessoas aqui já trabalharam com MapReduce? Ótimo. Um exemplo bem rápido: o MapReduce, introduzido pelo Google, era uma forma de analisar conjuntos de dados muito, muito grandes, distribuídos e armazenados em um sistema de arquivos distribuído. Certo. O exemplo clássico é: temos um enorme corpus textual no sistema de arquivos distribuído, com diferentes

6:15:44 arquivos, e precisamos fazer uma análise lexicográfica. Vou simplificar: contar o número de palavras de cada livro. Isso seria feito por uma série de funções de mapeamento. São funções simples, sem estado, ou seja, funções puras, que contam as palavras de cada livro e podem ser executadas em paralelo. Depois, há uma etapa de redução que consolida os resultados. De maneira muito semelhante, com uma adaptação, queremos trazer isso para

6:16:17 o mundo da programação com agents. Em vez de conjuntos de dados enormes, considerem bases de código enormes. Certo, uma visão geral de como isso funcionaria. Primeiro, introduzimos duas etapas no início. Há um agent principal que cria um plano. O plano recebe seu prompt, inclui skills e conhecimento existente do repo — tudo o que você fornecer —, realiza uma análise e, com base em todas

6:16:48 essas considerações, cria uma série de seletores. Os seletores são áreas, certo, funções determinísticas. Quando são executados, criam um catálogo da sua base de código com áreas candidatas para investigação. Terceiro, para cada uma dessas áreas candidatas, iniciamos uma série de subagents em paralelo. Eles analisam essas áreas, e somente essas áreas, e

6:17:20 realizam a análise. Essa é a etapa de mapeamento. Depois, vem a etapa de redução. O agent principal considera novamente os resultados: os resultados combinados e resumidos de todos os subagents. Certo. E faz alguma conciliação, consolidação e análise. Isso pode envolver deduplicação, priorização ou uma análise mais aprofundada dos resultados combinados. Vamos examinar esses conceitos um pouco mais de perto.

6:17:52 Vou usar a segurança como exemplo motivador. Tenho essa base de código grande. Qual é a qualidade de segurança, o nível de segurança dessa base de código? Vou fornecer o modelo de ameaças. Vou fornecer qualquer contexto adicional sobre a base de código. O que a etapa de preparação vai fazer é definir uma função de busca determinística que identifique áreas da base de código relevantes para a segurança. Vocês podem imaginar limites de API, onde tokens são gerados e repassados, pontos de entrada de SQL e assim por diante. O resultado será a criação desses seletores determinísticos. Eles serão executados e produzirão uma série de lotes ou fragmentos da

6:18:23 base de código, nos quais poderemos executar cada um desses subagents. Esses subagents terão um contexto bem definido e delimitado para realizar investigações, produzir relatórios e assim por diante, gerando um resultado delimitado para aquela área específica da base de código. Depois, os resultados voltam para o agent principal, onde fazemos um raciocínio holístico sobre todas as diferentes descobertas.

6:18:54 esses conceitos. Certo. E vou usar segurança como exemplo para motivar a discussão. Certo. Tenho essa grande base de código. E qual é a qualidade de segurança, o nível de segurança dessa base de código? Certo. Vou fornecer o threat model. Vou fornecer qualquer contexto adicional sobre a base de código. Certo. O que a etapa de preparação vai fazer é: certo, vamos escrever essa

6:19:25 função determinística de busca que vai identificar áreas da base de código relevantes no contexto de segurança. Vocês podem imaginar limites de API, onde tokens são criados e repassados, pontos de entrada de SQL, pontos de entrada de código e assim por diante. O resultado será a produção desses seletores determinísticos. Eles vão ser executados e vão produzir uma série de lotes, certo, ou uma série de fragmentos da

6:19:56 base de código, nos quais podemos então executar cada um desses subagents. Esses agentes terão um contexto bem delimitado e organizado, no qual poderão fazer as investigações, elaborar relatórios e assim por diante, produzindo um resultado delimitado para aquela área específica da base de código. Em seguida, os resultados voltam para o agent principal, onde fazemos um raciocínio holístico sobre todas as descobertas

6:20:26 de novo, no contexto de segurança, para deixar isso um pouco mais concreto. Provavelmente vamos duplicar o número um. Número dois: há uma priorização das vulnerabilidades mais críticas e uma classificação delas. Número três — e isso é crucial, novamente no contexto de tarefas que abrangem toda a base de código —, a presença de vulnerabilidades encadeadas. Lembrem-se: os agentes individuais podem dizer que a parte específica e limitada da base de código deles tem uma descoberta de baixa criticidade. Mas o passo de redução pode

6:20:56 avaliar combinações dessas descobertas de baixa criticidade. Elas podem produzir algo muito mais sério? E, novamente, com o harness certo, o Devon pode executar, testar de fato e tentar simular esses caminhos de ataque. Para mostrar isso de um jeito um pouco mais visual, tratamos a

6:21:27 base de código como um grafo. Há todas essas referências entre as diferentes partes da base de código. Os seletores procuram áreas fora do caminho, pontos de entrada da API, pontos de entrada de dados e SQL. Então, a partir desses seletores, que foram executados de forma barata e determinística na base de código, implantamos Devons individuais, agentes individuais, que fazem uma análise de segurança desse caminho específico e delimitado da base de código

6:21:58 e, então, na etapa de redução, o Devon produz algo assim. Ele faz a triagem, em primeiro lugar; em segundo, identifica duplicatas; e, em terceiro, executa testes e tenta reproduzir essas vulnerabilidades, inclusive os falsos positivos. Então, sim, mencionei a reprodução porque, obviamente, no fim das contas, você não quer abrir tickets, já que sabemos que, sempre que temos um lançamento, executamos uma segunda

6:22:30 verificação de vulnerabilidades com ferramentas e há muitas, muitas coisas para analisar. Queremos enviar PRs legítimos para vulnerabilidades conhecidas, então reproduzi-las é extremamente importante. Agora estamos enviando os PRs e quero comentar um pouco sobre a relação entre custo e desempenho. É claro que você pode executar agents muito caros. Pode executá-los em bases de código realmente grandes.

6:23:03 Como mencionei antes, o que é extremamente importante é pensar bem e encontrar as melhores maneiras possíveis de reduzir o custo da busca. A busca é um problema enorme em bases de código grandes, assim como a poluição e o estouro do contexto. Isso é resolvido pelo Devon e pelo agent principal no map-reduce agentic, escrevendo esses seletores determinísticos e criando muitos contextos delimitados, que acabam sendo muito mais baratos e oferecendo um perfil de

6:23:35 recuperação melhor em comparação com modelos concorrentes. Executamos isso em 50 conjuntos de dados, com 50 vulnerabilidades do GitHub, abrangendo várias linguagens, como Golang, Python, Java e outras. Outra coisa que devemos considerar: falei bastante sobre map-reduce agentic no contexto da detecção e correção de vulnerabilidades. Pensem nisso como um conceito que pode ser

6:24:06 generalizado para todos os tipos de tarefas que abrangem toda a base de código. Remoção de código morto; mencionei bastante a extração de lógica comum para uma biblioteca centralizada a partir de uma base de código muito grande. Detecção de código morto e assim por diante. E isso é algo que, novamente, com base na nossa pesquisa, levamos para a área de segurança e estamos elevando à categoria de funcionalidade de primeira classe no nosso produto. Como mencionei

6:24:38 antes, somos um laboratório de pesquisa em IA aplicada. Trabalhamos em áreas como map-reduce agentic, desenvolvemos nossos próprios modelos de programação 2.0, fazemos pesquisa em harnesses de modelos, como dev infusion, e em infraestrutura agentic. Acessem nosso blog de pesquisa. Se tiverem perguntas, este é meu e-mail. Estou ansioso para receber seus comentários. Vejo vocês pela conferência. Obrigado.

6:25:11 Muito obrigado. [aplausos] Muito obrigado. Vamos aplaudir Janice mais uma vez, por favor. [aplausos] Certo. Muito bem. Todos nós merecemos uma pausa agora. Sei que foi um dia longo para todo mundo, mas ainda temos uma ótima programação de palestrantes. Voltaremos aqui às 16h30, por favor. Aproveitem a pausa. Até daqui a pouco.

7:14:50 Calor. Ei, calor. Calor. Calor.

7:15:38 Senhoras e senhores, recebam no palco o mestre de cerimônias do AI Engineer Paris 2026, engenheiro de relações com desenvolvedores na Replit, Rahul Chevrey. Certo. Tudo bem. Como vocês estão? Ei, estamos na reta final. É aqui que precisamos reunir toda a

7:16:09 energia e seguir em frente para a reta final deste AI Engineer em Paris. Estou muito animado com nosso próximo palestrante. Na verdade, nem preciso apresentá-lo. Ele era conhecido como o mago do TypeScript e, depois, também ficou conhecido pelo trabalho na Vercel, antes de começar a falar sobre skills. Aí descobrimos que ele tem opiniões muito fortes — e boas — sobre IA. Nosso próximo palestrante vai

7:16:39 falar sobre como resolver os gargalos dos seus PRs. Meu Deus, me identifico muito com isso. Alguém mais se identifica? Sério, quem está recebendo tantos PRs que não consegue revisar nenhum deles? Então, sem mais delongas, recebam no palco Matt Pocock. [aplausos] Certo. Olá, pessoal. Estão curtindo a conferência

7:17:10 até agora? Estão curtindo a conferência até agora? Ótimo. Estou aqui para falar sobre como resolver o gargalo dos PRs. É um título grandioso para tentar resolver algo com que a maioria das organizações tem dificuldade, na minha opinião, e com que historicamente já tinha dificuldade antes da IA. Sempre tivemos um grande número de PRs parados, sem que ninguém se desse ao trabalho de revisá-los. Agora, isso aumentou muito por causa das novas pressões sobre nós, com a IA impondo todas essas

7:17:41 restrições estranhas. Para isso, vou usar como referência minhas skills, das quais vocês já ouviram falar e talvez até tenham usado. Tenho algumas skills novas para anunciar que, espero, vão melhorar a maneira como vocês lidam com PRs, melhorar a maneira como — ou a velocidade com que — vocês conseguem revisá-los e criá-los. Velocidade. Agora estão nos pressionando a fazer mais com menos, essencialmente: mais PRs, mais trabalho, mais coisas. E essa é a promessa central

7:18:11 da IA: poderemos usar esses agents para ampliar nossa capacidade e fazer mais trabalho. Isso resultou na fábrica de software, provavelmente a maior palavra da moda do dia. Todo mundo com quem converso está falando de fábrica de software. Para mim, uma fábrica de software é, sobretudo, algo em que, em vez de o ser humano iniciar todo esse trabalho, vamos deixar que parte dessa iniciativa seja feita por agents. E imagino que eles

7:19:04 talvez, a partir daí, acionem um classificador como Jev. Certo. Certo. Vamos transformar isso numa correção ou numa reprodução, ou talvez eu avise as pessoas imediatamente. E talvez haja outras coisas. Talvez o PlanetScale esteja integrado e forneça relatórios de consultas lentas no seu banco de dados. Isso talvez acione outro processo na sua fábrica de software. Nada disso é acionado por humanos. É código determinístico que aciona essas coisas, certo? Isso acelera sua fábrica de software. Faz passar mais código por ela. Mas aí você precisa de freios, certo? Se houver aceleração constante empurrando coisas pela sua fábrica, você vai acabar com um canhão de porcaria, certo? Vai acabar com um monte de PRs ruins e cheios de código de baixa qualidade, que você não vai conseguir tocar, revisar nem sequer olhar. Então, precisa de freios. São mecanismos que desaceleram o processo, aumentam a qualidade e garantem que sua base de código não vire um pesadelo de entropia de software, porque o código é o ambiente em que seu agent opera. E, se houver código ruim na sua base de código, isso vai gerar ainda mais código ruim.

7:19:37 aceleração, empurrando coisas pela sua fábrica, você vai acabar com um canhão de porcaria, certo? Vai acabar com uma tonelada de PRs ruins e cheios de porcaria, que você não vai conseguir tocar, revisar nem sequer olhar. Então, você precisa de pausas. São mecanismos que desaceleram, aumentam a qualidade e garantem que sua base de código não se transforme num pesadelo de entropia de software, porque o código é o ambiente em que seu agent opera. E, se houver código ruim na sua base de código, isso vai gerar mais código ruim.

7:20:07 Então, vou falar sobre essas três rupturas nesta palestra e sobre como podemos usá-las para, contraintuitivamente, avançar mais rápido. Primeiro, as verificações automatizadas: são as verificações determinísticas no seu repo, que existem há milhares de anos — ou, sabe, desde os anos 50. Verificações determinísticas que incluem linting, testes, verificação de tipos e métricas de qualidade do código. Todas essas coisas funcionam em conjunto e sempre funcionam da mesma maneira. Sobre essa camada, temos a revisão automatizada. Então,

7:20:37 temos agents que analisam nosso código e dizem: “Certo, estas são as coisas que os testes não detectaram” ou “Isto analisa a estrutura geral da base de código”. E, sobre essa camada, a terceira e última camada é a revisão humana. Ou seja, pessoas analisando o PR. Essas três camadas formam uma espécie de bolo ao qual chegamos quando fazemos a revisão humana. E, claro, mais velocidade significa mais PRs. Então, o objetivo aqui é acelerar a revisão humana apoiando-nos nessas duas primeiras etapas.

7:21:09 E precisamos acabar com o código porcaria. Esse é o primeiro princípio: se você elevar a qualidade do código que está entregando, vai acabar precisando de menos revisão humana, porque o trabalho simplesmente vai ser melhor. E, assim, vai precisar fazer menos intervenções. Então, verificações automatizadas. Verificações automatizadas são baratas. Essa é a parte legal: elas não custam tokens, ao contrário da revisão automatizada. Não exigem esforço humano. Custam apenas ciclos de CPU. Por exemplo, você executa seus testes a cada alteração no código. Talvez esses testes consumam alguns tokens, porque, digamos, um agent cria um bug e os testes o detectam; nesse caso, você precisa gastar alguns tokens para corrigi-lo, mas, na minha opinião, esses tokens são muito bem gastos.

7:21:41 Então, as verificações são baratas. Isso significa que você pode adicionar muitas, muitas, muitas delas aos seus repos. Provavelmente você não está usando o suficiente, ou não está sendo criativo o suficiente ao usá-las. Mas as verificações podem mentir. Uma CI verde significa que o código está pronto para ser integrado? Não. E, por isso, sempre precisamos, além dessas

7:22:12 verificações, de uma camada extra para descobrir se há algo catastroficamente errado com o código antes de entregá-lo. Então, todas as outras etapas — a revisão humana e a revisão automatizada — são detectores de mentiras. Servem para encontrar mentiras nas verificações automatizadas. Primeiro, quero mostrar algumas dessas mentiras, porque isso nos ajuda, quando pensamos no código e nas verificações automatizadas, a perceber o quão ruim isso pode ser e até que ponto as coisas podem piorar. A primeira são os testes tautológicos: um teste que apenas reafirma a implementação. O Opus 5 ficou

7:22:44 viciado neles. Não entendo muito bem por que, mas, por exemplo, havia x post character limit equals 280. Alguém consegue adivinhar qual teste foi escrito para testar esse comportamento? Certo? Provavelmente vocês já viram isso mil vezes. Este é um código real de agents ou algo que encontrei meus agents fazendo. Ele dizia: “espera-se que o limite de caracteres de uma publicação no X seja 280”. Então, a implementação era assim, e o teste basicamente reafirmava a implementação. Isso é um teste tautológico. E testes tautológicos são ruins

7:23:16 porque são extremamente sensíveis à estrutura. São muito sensíveis ao funcionamento interno do sistema. Isso significa que não posso alterar essa constante sem que um teste falhe. Mas não posso renomear essa constante sem que um teste falhe. O que faço fica muito amarrado à estrutura do meu sistema. E encontrei outro exemplo que, eu diria, é ainda mais absurdo. Este teste é incrível. O que ele faz é basicamente verificar se dois

7:23:47 elementos da interface aparecem na ordem certa. Ele verifica se a página de detalhes do pitch — ou melhor, a seção de vídeos — vem depois do plano de conteúdo. O que ele faz é não renderizar a página na tela. Apenas lê o arquivo, o módulo de verdade, para a própria memória e então encontra os elementos certos. Então, encontra o plano de conteúdo, encontra os vídeos e espera que os vídeos apareçam depois dele no material de origem. Isso é loucura, se você pensar bem, porque posso simplesmente mudar a aparência do material de origem

7:24:18 e esse teste vai falhar. Ele é sensível demais à estrutura da minha base de código. Então, essa é outra forma de as verificações automatizadas falharem. E também — quer dizer, as verificações automatizadas podem mentir. Há também testes que literalmente não podem falhar. Isso vai parecer familiar se você já abusou de mocks ou de várias outras coisas. Por exemplo, temos aqui uma função use audio boost. Internamente, essa função usa a API de contexto de áudio no DOM. Não se preocupe se

7:24:48 você não sabe o que é isso, mas o que estamos fazendo aqui é simplesmente substituir tudo por métodos falsos. E acontece que o contexto de áudio tem modos de erro complicados e falha se for usado em condições estranhas. Então, fazer isso significa que nossos testes não podem falhar nesses modos, e vamos encontrar erros estranhos em produção que nossos testes não conseguem corrigir. A pergunta, então, é: dá para trapacear nas verificações automatizadas? Se você souber como — e até de maneiras bem-intencionadas. A IA

7:25:19 não está tentando escrever testes ruins aqui. Ela está apenas seguindo nossas instruções e escrevendo testes muito amarrados à estrutura, em vez de realmente executar o código. Então, como podemos tornar mais difícil trapacear nas verificações automatizadas? Se conseguirmos, podemos elevar a qualidade dessas verificações, o que aumenta nosso padrão de qualidade. E a primeira coisa de que gosto muito é o design da base de código. Na verdade, dá para projetar a base de código de modo a evitar essas verificações ruins. Então, como é um bom design da base de código?

7:25:49 Já falei sobre isso em palestras anteriores de AI Engineer que dei: são os módulos profundos. São módulos que escondem comportamentos complexos atrás de interfaces simples. Essa é uma ideia de John Ousterhout, da filosofia de design de software. Se olharmos para esses dois módulos, temos o A, que esconde uma implementação grande atrás de uma interface bem pequena no topo. Certo? E depois temos o B, que tem uma interface grande, com muitas funções que você pode chamar, mas cada uma dessas funções, individualmente, não faz muita coisa. Faz sentido? Sim. Então, se você tiver um módulo profundo como o A,

7:26:23 vai ter menos testes sensíveis à estrutura, porque está escondendo mais da implementação atrás daquela interface. Se o teste verifica apenas essa interface, os testes vão ser melhores. Então, seu trabalho aqui é forçar o agent a usar essa interface pequena, em vez de acessar diretamente a implementação para testar esses detalhes esquisitos. Tenho uma skill para isso. Você pode ter a base de código vibe-coded mais estranha, a pior base de código que

7:26:54 você já viu, e executar essa skill nela para melhorá-la. O que ela faz é basicamente apontar oportunidades para aprofundar módulos, e mais ou menos se parece com isto. Levantem a mão se já usaram essa skill. A propósito, não sei quantas pessoas da minha equipe estão nesta sala. Sim. Certo. Ela é muito, muito boa. Basicamente, gera um documento HTML. Vou sair da frente aqui. Ele mostra todas as diferentes oportunidades possíveis que identifica. Então, podemos ver aqui um antes e um depois, em que reduzimos a duplicação. Criamos um módulo profundo, fácil de testar, e depois você pode implementá-lo.

7:27:24 E, junto com isso, também há uma espécie de linguagem que criei para descrever módulos. Porque, se você tentar ler sobre como estruturar uma base de código, vai encontrar 20 abordagens diferentes, e todas vão ser chamadas de DDD. O que você precisa é de uma linguagem consistente que possa usar com sua equipe para falar sobre essas coisas. Então, tenho uma pequena skill de design da base de código que define o que é localidade, o que é alavancagem e o que é uma seam. Eu estava usando

7:27:55 costuras antes de elas ficarem na moda. E o que localidade significa é, mais ou menos, o quão bem localizado em conjunto está todo o código. Como você pode fazer uma pequena alteração em um módulo e propagá-la para o restante? E alavancagem é o que você obtém quando tem um módulo profundo, porque quem chama — a pessoa que de fato chama esse módulo — obtém muito valor ao chamar uma função simples. Acontece que ambas as coisas são muito boas em bases de código e também para agents. Mas eu estou meio que

7:28:27 descrevendo todos esses padrões de programação destacados. Mas como garantimos que o agent os siga corretamente? Como garantir que o agent crie módulos profundos e bons testes, e que não escreva testes tautológicos ruins ou sensíveis à estrutura? Bem, acho que a maioria das pessoas erra nisso. E meu primeiro conselho é: não coloque padrões de programação no seu agent de implementação. Certo, deixe-me explicar. Se você

7:28:59 imaginar que o agent de implementação se parece mais ou menos com isto, tudo isso são as coisas que o agent precisa conseguir fazer dentro de uma única context window. Ele precisa conseguir explorar, procurar o código que vai alterar. Depois, precisa realmente alterá-lo. Ou seja, fazer atualizações nos arquivos em verde. E então precisa reservar algum orçamento para depurar de fato a coisa. Para executar essas verificações automatizadas, para conferir e verificar se funciona. Acontece que isso dá bastante trabalho. E, se você também tentar impor seus

7:29:29 padrões de programação a ele, o desempenho será pior. A implementação fica sobrecarregada. Esse é o modelo mental que quero que vocês tenham. Então, será que podemos encontrar uma maneira de impor esses padrões de programação sem sobrecarregá-la tanto? Bem, esta é a minha tentativa. Esta é minha skill de revisão de código. Ela recebe um diff e lê um arquivo dentro do repo chamado coding standards, que você pode criar e personalizar; depois, verifica se o código segue esses padrões.

7:30:01 E, como vemos aqui, o agent revisor também é executado, de forma crucial, em um subagent. Assim, ele tem sua própria context window para lidar com isso. Tem seu próprio orçamento. Neste caso, precisa fazer alguma exploração, certo? Porque, claro, ele recebe o diff, então sabe exatamente onde o código está, mas provavelmente deve explorar um pouco para ter um contexto mais amplo e entender o código. Porém, não precisa implementar nada nem depurar. Então, enquanto a implementação fica sobrecarregada,

7:30:31 a revisão, na verdade, fica subcarregada. Ela não tem tantas tarefas para fazer. Isso significa que você pode incluir nela um monte de padrões de programação, e ela fará um trabalho muito melhor do que se você tentasse fazer isso com o agent de implementação. Então, penso nisso — e é desconfortável, certo? Porque todos nós queremos conseguir obter um bom código logo de primeira — como um processo em duas partes para escrever bom código: implementação, você faz funcionar; depois, revisão de código, você realmente o torna bom. Você impõe seus padrões de programação. E, para os desenvolvedores mais experientes entre nós, isso é essencialmente uma abordagem de vermelho, verde e refatoração.

7:31:04 Usamos uma context window para deixá-lo aceitável. Fazemos o ciclo vermelho-verde e, depois, usamos outra context window para refatorá-lo. Pelo menos é assim que funciona na minha cabeça, e tem sido muito bem-sucedido para mim. Isso significa que, quando você tem padrões de programação, não os coloca no escopo global. Não os coloca em agents.mmd, porque assim eles acabam abafando o agent de implementação. Ele pode lê-los ou não. Você os coloca em coding standards.mmd e, desse modo, só o agent de revisão de código faz

7:31:34 isso. Agora, tenho outra ideia aqui. Conversei com muita gente hoje. Muita gente disse: “Sabe, tenho falado sobre revisão e aumento da revisão automatizada, sobre resolver o gargalo dos PRs. Muita gente diz: ‘Ah, sim, a gente simplesmente usa um serviço de terceiros. Usamos um bot de bugs do Cursor. Usamos CodeRabbit ou algo assim.’” Acho que já tentei bastante, no passado, criar uma skill genérica de revisão de código que encontrasse todos os bugs, fizesse revisão de segurança e coisas desse tipo. Acontece que é muito,

7:32:05 muito difícil, porque ou você a torna genérica demais e ela aponta falsos positivos que não são relevantes para o seu caso de uso, ou a torna específica demais. Você diz: “Certo, encontre tudo que tenha a ver com TypeScript”, e aí quem usa Rust não pode utilizá-la. Então, eu diria para não terceirizar a revisão automatizada. Criem a sua própria. Desenvolvam seus próprios padrões de programação ao longo do tempo. Compartilhem-nos com a equipe. E, se tiverem a oportunidade de impor padrões de programação, se tiverem documentos por aí que ninguém lê, é aqui que vocês devem colocá-los. E

7:32:35 também, quando você tem esse revisor automatizado, é muito natural que muita gente diga: “Ah, sim, o que meu agent de revisão de código faz é ler o código e depois comentar no PR.” Então, [suspira e inspira fundo], nesse caso, o que o agent de revisão de código está fazendo é dar mais trabalho ao revisor humano. O revisor humano precisa ler todos esses comentários prolixos e decidir: certo, implementamos isto? Implementamos aquilo? O revisor deve fazer commits. Deve corrigir as coisas. Ou seja, deve realmente alterar o que

7:33:05 encontrar, porque assim, quando a pessoa chegar para revisar, estará avaliando um resultado muito bom. Se encontrar algo sobre o qual tenha alguma dúvida, é claro que pode comentar, mas o padrão deve ser fazer commits. Parem de tentar produzir código bom de uma só vez. Parem de tentar fazer do agent de implementação a única coisa que vocês usam e dizer: “Certo, vou obrigá-lo a ser incrível.” É preciso pensar um pouco para sair desse jeito de pensar, mas, quando você entende isso, é fantástico. Certo, com todo esse processo, nós

7:33:36 executamos nossas verificações automatizadas. Agora também executamos nossa revisão automatizada para garantir que as verificações automatizadas não estejam mentindo. Como então maximizamos a qualidade do PR no que diz respeito à revisão humana? Como fazemos com que ele funcione da melhor maneira possível? Precisamos de um PR fácil para uma pessoa revisar. E esta é uma nova skill que está chegando ao repo e ainda está em desenvolvimento, mas vou lançá-la em breve: a skill de PR. É algo sobre o qual venho refletindo há muito, muito tempo. Ainda não descobri exatamente qual é o estado da arte. E percebi que a melhor maneira de criar uma skill de PR é simplesmente

7:34:07 roubar todas as melhores ideias que as pessoas tiveram. E isso é muito bom. Então, como deve ser o texto de um bom PR? Como você recriaria essa skill por conta própria? Bem, o primeiro princípio é que algumas revisões são mais importantes do que outras. Nem toda revisão é essencial, certo? E, quando você entende isso, percebe: certo, isso significa que posso concentrar minha energia nas revisões realmente importantes. Mas como classificá-las? Bem, é preciso pensar no PR usando esta

7:34:39 terminologia da AWS: ele é uma porta de mão única ou uma porta de mão dupla? A maioria dos PRs que vocês têm será de mão dupla. Vocês podem fazer merge do PR e depois revertê-lo. Essa é a grande vantagem de ser engenheiro de software em vez de engenheiro civil. Certo? Em geral, quando você é engenheiro civil, trata-se de uma porta de mão única, certo? Se fizer algo errado, a ponte vai desabar. Mas, se for uma porta de mão dupla, significa que você pode reverter a alteração com facilidade. Agora, isso pode ser um pouco

7:35:10 mais complexo do que você imagina. Uma alteração muito simples pode, por acidente, disparar um e-mail para 60.000 pessoas ou algo assim; nesse caso, é uma porta de mão única. Você vai querer revisar isso com muito, muito cuidado. Se envolver migrações caras ou perda de dados, é uma porta de mão única. Revise esse PR com todo o cuidado. Mas, além disso, precisamos entender o raio de impacto desse PR. O que pode dar errado? E, se der errado, quão grave será? E isso significa que acabo incluindo um pequeno resumo bem no fim de todos os meus PRs, que é o

7:35:41 perigo de merge. Consigo ver que esta é uma decisão reversível. O raio de impacto é localizado. Então consigo ver: fantástico. Não preciso prestar tanta atenção a isso. Vou só dar uma olhada rápida. Isso é muito importante. Em seguida, precisamos entender o que a PR está fazendo, afinal, certo? Já tentei várias maneiras diferentes de descobrir isso, e a melhor que encontrei foi usar pseudocódigo. Agora, um enorme agradecimento à skill show me do repo human layer skills

7:36:11 de Dex Holley. É uma skill fenomenal que basicamente dispensa a maior parte do texto e mostra as coisas em imagens e diagramas. Isso torna muito mais fácil entender o que está mudando de fato e por que está mudando. Assim, você recebe o conjunto mais ou menos padrão de diagramas Mermaid e UML para mostrar, por exemplo, uma sequência de coisas que aconteceram. Você também recebe esses diagramas simples e adoráveis, como este, por exemplo. Podemos olhar para ele e dizer: certo, estamos trabalhando em uma CLI. Vemos que foi adicionado um novo comando e temos

7:36:42 duas coisas novas, pequenas flags aqui em cima. São só resumos curtos como este. Isso realmente faz uma diferença enorme. É difícil exagerar o quanto. A ideia é tentar tornar a compreensão do motivo o mais rápida possível. E acho que um terceiro princípio que você deve considerar sempre que fizer uma revisão humana é o seguinte: como nossos processos agora estão tão

7:37:13 simplificados e todos colaboramos em torno desses mesmos arquivos de skill, desses mesmos arquivos de direcionamento, estamos todos construindo juntos um ambiente para nossos agents operarem. Você deve considerar o processo que produz seu código tão importante quanto o próprio código. Em outras palavras, quando faz uma revisão humana, você não está revisando apenas o código, mas também o sistema que o cria. E a teoria aqui é que você nunca deve escrever o mesmo comentário duas vezes, certo? Você nunca deve flagrar o agent fazendo a mesma coisa em duas PRs. Então, qual é o mecanismo que permite que sua revisão humana faça diferença? Bem, esta é uma nova skill. Ela se chama retro. Retro, de retrospectiva. Basicamente, você pega uma sessão que realizou. Pode ser uma única sessão de agent, uma PR mais a sessão, ou você pode simplesmente pedir que ele analise todas as PRs que fizemos na última semana, reúna todas as revisões e faça uma retrospectiva delas. Aí ele sugere verificações automatizadas e padrões de codificação para melhorar a próxima.

7:37:46 um mecanismo pelo qual você pode fazer a revisão humana valer a pena? Bem, esta é uma nova skill, chamada retro. Retro, de retrospectiva. Basicamente, você pega uma sessão que realizou. Pode ser uma única sessão de agent, ou uma PR junto com a sessão, ou você pode simplesmente pedir que ele analise todas as PRs que fizemos na última semana e todas as revisões, reúna tudo e faça uma retrospectiva. Ele vai sugerir verificações automatizadas e padrões de código para melhorar a próxima.

7:38:17 Esse é o efeito cumulativo: ao fazer uma revisão humana, você aumenta a qualidade da próxima revisão humana e acaba tendo menos trabalho para fazer na próxima vez. E retro é uma skill muito inteligente. Ela acrescenta várias coisas. Obviamente, sugere verificações automatizadas. Sugere atualizações para coding standards.mmd. Também faz outras coisas inteligentes. Por exemplo, analisa os indicadores de navegação. Com que facilidade o agent encontrou as informações? Podemos incluir uma indicação em agents.mmd para ajudar na próxima vez? Ela também analisa a economia de ferramentas. Existem

7:38:49 ferramentas diferentes que usamos na sessão e que poderiam ser mais eficientes em tokens? É impressionante quantas coisas ela detecta, na verdade, porque muitas vezes são muito difíceis de depurar de fora. Ela também verifica o excesso de conteúdo. Há arquivos de direcionamento inchados? Há skills inchadas que contribuem para esses resultados ruins? Podemos organizá-las melhor? O objetivo, então, é tornar a revisão humana mais rápida. Fazemos isso acumulando verificações automatizadas. Acumulamos revisões automatizadas. E tornamos a revisão humana tão indolor, simples e, de certa forma, opcional quanto for necessário.

7:39:20 Você realmente não precisa revisar cada decisão reversível. Toda decisão irreversível, sim. Estas são minhas skills: AI her.dev/skills. Vou lançar a versão 1.3 esta semana. Foi maravilhoso passar esse tempo com vocês. Esta conferência foi muito boa. Vou ficar lá fora, no saguão, se alguém quiser conversar. Muito obrigado pelo convite. Obrigado, Paris. [aplausos]

7:39:50 [gritos de comemoração] [aplausos] >> Muito obrigado. >> Certo, vamos aplaudir Matt mais uma vez. [aplausos] Adorei essa skill retro. Acho que vou usá-la muito em breve. Certo. Bom, a seguir temos alguém da Deep Mind U. Martin vai falar conosco sobre Gemma. Ele vai falar sobre alguns fundamentos arquitetônicos, mas também

7:40:21 sobre o que torna Gemma tão rápida e única. Então, por favor, vamos aplaudir M, o Martin.

7:41:18 Não, não estou vendo nada.

7:41:50 Oba, está funcionando. Hoje vou falar sobre algo que considero um componente central do lançamento de modelos open source: a eficiência. Porque, a partir do momento em que você lança um modelo no mundo e as pessoas podem realmente usá-lo, ele passa a ter restrições. Restrições porque, como vocês sabem, os modelos são executados em dispositivos móveis e laptops, e posso presumir que não há data centers executando esses modelos. Por isso, a eficiência

7:42:21 se torna uma parte muito importante. Quero abordar alguns aspectos da eficiência: conhecimento, tamanho, velocidade, complexidade da arquitetura e também a própria arquitetura. Quero explorar alguns desses componentes a fundo e ver o que podemos aprender com eles. Um deles são os embeddings por camada. Isso é muito importante nos modelos menores do Gemma 4. Há os modelos de dois bilhões e quatro bilhões de parâmetros, e eles usam bastante embeddings por camada.

7:42:52 Eles explicam, basicamente, o que significa esse E em E2B e E4B. Sabemos que o A, nos modelos de mixture of experts, significa active. Mas o que significa o E? Bem, vou mostrar. Esta é a arquitetura que o Gemma 4 geralmente usa, certo? Ela tem atenção local, atenção global, atenção de consulta agrupada, algumas normalizações aqui e ali. E, bem no final, nos modelos menores, aparecem de repente os embeddings por camada. E, como o

7:43:25 nome indica, são embeddings por token, mas também por camada. São muito parecidos com os embeddings de tokens que todos conhecemos tão bem, mas, desta vez, são adicionados a cada camada. Isso significa que o token “oi” tem um embedding muito diferente na camada 1 do que, por exemplo, na camada 4 ou na camada 10. É uma forma de adicionar conhecimento ao modelo sem precisar armazená-lo na memória. Durante esse processamento, o modelo pode

7:43:56 inclusive ponderar como esses tokens estão sendo usados. Para um determinado contexto, o modelo pode dizer: “Certo, quero me concentrar um pouco mais neste aspecto do embedding do que naquele.” E o ótimo de usar algo assim é que se trata de uma tabela de consulta com informações sobre os tokens. E, quando se tem uma tabela de consulta, não é preciso armazená-la na VRAM. Não é preciso armazená-la na RAM. Basta armazená-la em qualquer tipo de armazenamento disponível. O que acontece aqui é um comportamento tipo rackl, porque, durante a inference, só precisamos carregar

7:44:27 os tokens que são realmente necessários. E isso explica que o E significa, na verdade, “effective”, porque essas tabelas de consulta de embeddings por camada contêm bilhões de parâmetros, certo? Mas eles não são usados durante a inference. De certa forma, podemos separar parte do conhecimento das capacidades reais do modelo, e essa ideia de separá-los está se tornando cada vez mais marcante no campo dos modelos open source. Então, temos o conhecimento, que pode ser tratado com eficiência. E quanto ao tamanho, por

7:44:58 exemplo? Você pode criar um modelo muito pequeno, mas ainda assim querer que ele tenha muitas capacidades. Para isso, pode fazer treinamento ciente da quantização: reduzir a precisão para algo menor, tentando manter o máximo possível das capacidades. É uma ótima maneira de abordar isso. Mas podemos ir além com os mobile quants. Esse é um esquema bem específico, desenvolvido para esses dois modelos menores, porque, quando se têm modelos menores e se vai quantizá-los

7:45:29 Para chegar a um tamanho ainda menor, é preciso garantir que você não perca desempenho demais. Então, temos um esquema bem específico, que se parece um pouco com isto. Temos a camada de embedding dos tokens, certo? Na verdade, dá para reduzi-la até dois bits e ainda manter muitas das capacidades do modelo. E o motivo disso eu explicarei um pouco mais adiante. Para a atenção global, usamos quatro bits; 4bit é o que geralmente usamos, certo? É um bom equilíbrio entre o tamanho do modelo e suas capacidades.

7:46:00 Mas, para a atenção local, que se concentra naquilo que queremos conhecer melhor, ajuda ter uma precisão um pouco maior, especialmente com o KV cache. A rede feed-forward usa quatro bits, mas os embeddings por camada de que acabamos de falar usam dois bits, porque, de certa forma, também compensam a posição mais baixa dos embeddings dos tokens. Assim, ao combinar tudo isso, temos um bom esquema para um modelo específico. E o que vemos é que garantir a eficiência também

7:46:33 significa fazer muitas personalizações nesses modelos, especialmente em tamanhos como dois bilhões ou quatro bilhões de parâmetros. Com tudo isso, temos conhecimento e eficiência em tamanho. E quanto à velocidade? Para aumentar a velocidade, usamos algo que, felizmente, está se tornando cada vez mais popular: speculative decoding com multi-token prediction. Funciona usando um modelo relativamente pequeno para sugerir tokens que o modelo maior — o modelo

7:47:04 que você quer realmente executar — pode usar, porque isso permite que o modelo maior apenas valide todos os tokens que vê, sem precisar processar todos esses tokens de uma vez. Então temos um modelo-alvo, certo? É um modelo grande. Pode ter qualquer arquitetura que você tenha, e há um modelo de rascunho, menor. Com o Gemma 4, nosso objetivo é compartilhar parte do KV cache. Por quê? Porque isso simplifica muito mais o processo para o modelo menor, o modelo candidato ou

7:47:35 o modelo de rascunho. O que acontece é que o modelo-alvo recebe uma consulta, faz uma única rodada de processamento, uma única passagem, gera seu KV cache e, em seguida, compartilha-o com o modelo menor. O modelo menor pode então usar essa saída, continuar o processamento e gerar tokens. Ele recebe a entrada e gera um, dois, três, talvez oito tokens para o modelo maior validar. E então o modelo maior

7:48:06 só precisa analisar todos esses tokens de uma vez e decidir: “Certo, gosto destes tokens, mas não gosto muito destes outros. Então, vou aceitar apenas os dois primeiros, por exemplo.” Mas continua sendo uma única passagem, certo? Portanto, tudo o que ele precisa fazer é adicionar mais um token, porque já fez os cálculos para a sequência inteira; então, gera três tokens quase pelo custo de um só, o que acelera muito as coisas.

7:48:38 É claro que nada vem de graça, certo? Então, um método como esse tem vantagens e desvantagens. Você adiciona um modelo; é um modelo bem pequeno, mas ainda assim o adiciona. O ganho de velocidade obtido também varia bastante conforme o caso de uso. O fato é que alguns tokens são muito fáceis de prever, especialmente em tarefas estruturadas, como programação, por exemplo. Mas, em tarefas criativas, é muito difícil para o modelo menor descobrir

7:49:08 que tipo de tokens deve sugerir. Então, mais desses tokens serão rejeitados. Felizmente, há cada vez mais tarefas de programação e tarefas estruturadas por aí. Para esses casos de uso, a multi-token prediction funciona excepcionalmente bem. E então temos eficiência em conhecimento, tamanho e velocidade. E quanto à complexidade? Ah, eu mostrei isto aqui? Deixe-me remover esse

7:49:39 servidor. E então temos a complexidade, porque isso também importa, certo? Se o modelo não for open, a complexidade não importa tanto para o usuário final. Mas, quando você lança um modelo para as pessoas usarem, vamos garantir que ele não seja difícil demais de entender, usar e processar. Como consequência disso, foi lançado um modelo chamado modelo sem encoder. Esse modelo sem encoder analisou os encoders usados, por exemplo, para processar essas

7:50:12 entradas multimodais e disse: “Dá muito trabalho. E se os removermos?” Em muitos desses modelos da linha Gemma 4, há um tokenizador de áudio, um encoder de áudio e o mesmo para imagens. Isso é ótimo e funciona muito bem. É algo padrão na área ter esses encoders para diferentes tipos de dados multimodais, mas eles ainda ocupam um espaço considerável. Isso reduz o tempo até o primeiro token e é algo a considerar, por exemplo, ao fazer fine-tuning do seu modelo

7:50:44 com o modelo sem encoder. A ideia é simplesmente removê-los por completo e transferir grande parte do trabalho de processamento dessas entradas multimodais para o modelo, em vez de deixá-lo com esses encoders. Para áudio, funciona mais ou menos assim: temos uma entrada, uma sequência de valores de amplitude, e a única coisa que acontece é que ela é dividida em partes, formando uma sequência de tokens de áudio, e depois projetada na dimensionalidade do próprio modelo.

7:51:14 E é só isso. Portanto, os únicos parâmetros ficam, de certa forma, na projeção linear. É basicamente isso. Todo o processamento contextual que antes acontecia no encoder de áudio agora é feito pelo próprio LLM. Ou seja, estamos transferindo todos esses parâmetros do encoder para o LLM. O mesmo pode ser feito com o encoder de imagens. O problema é que, no caso das imagens, há informações tridimensionais. Não podemos simplesmente dividi-las

7:51:45 em partes, transformá-las em uma sequência e esperar que o modelo as processe bem, porque não vai. Garanto isso. Para isso, precisamos de informações posicionais. Então, em vez de fazer uma projeção direta dos recortes para o modelo, pegamos esses recortes e acrescentamos informações posicionais. Assim, ele sabe que, digamos, o recorte quatro — aquele pequeno token de imagem — tem um significado, porque dá para imaginar que, em uma imagem muito larga, a posição quatro

7:52:17 significa algo bem diferente do que em uma imagem muito alta. Então, o que acontece é que usamos os embeddings posicionais projetados e, mais uma vez, temos um encoder totalmente removido. O bom de algo assim é que reduz o tempo até o primeiro token, o que ajuda bastante. Você transfere todas as capacidades para o modelo e reduz uma grande parte dos parâmetros, especialmente em modelos menores.

7:52:48 Algo como 300 milhões ou 500 milhões de parâmetros não parece muito quando falamos de modelos com centenas de bilhões de parâmetros, mas, em tamanhos de dois bilhões ou 12 bilhões, isso faz uma diferença enorme, especialmente se você puder usar isso para as capacidades do modelo. Assim, temos conhecimento, tamanho, velocidade e complexidade: diferentes maneiras de focar na eficiência. E havia uma última coisa em que

7:53:18 eu realmente queria me concentrar e explicar um pouco melhor o que significa e como funciona: a arquitetura. Os modelos comuns, os LLMs comuns, são todos limitados pela memória, e isso tem vantagens e desvantagens. Eles são ótimos e usados para muitas finalidades e em muitas áreas diferentes. E se, em vez disso, fossem limitados pela computação? E se invertêssemos completamente essa lógica e tentássemos abordá-la

7:53:49 de uma perspectiva bem diferente? O resultado não é autoregressão; é algo completamente diferente: diffusion. Podemos usar diffusion para LLMs e ainda assim fazer com que seja útil? Podemos usá-la de um jeito que muitas pessoas ainda consigam aproveitar, mas para casos de uso bem diferentes? Agora, vou explicar um pouco o que diffusion significa em modelos de linguagem grandes, especialmente porque chegaremos a um assunto que muita gente provavelmente viu nas últimas semanas.

7:54:22 Você começa com uma entrada, certo? Temos uma consulta, uma entrada que está sendo processada. Normalmente, um modelo faria isso, e agora é mais ou menos o mesmo modelo que faz isso. Mas, na fusão, temos algo chamado encoder. E o encoder do Diffusion Gemma, pelo menos, ainda é apenas um decoder com atenção causal. É um modelo Gemma 4 com fine-tuning. Nada de arquitetura muito diferente ou algo do tipo. É, sabe, um dos modelos que vocês viram antes. Mas o motivo de ser chamado de encoder

7:54:53 é que ele foi feito para processar o prompt e, assim, gera um KV cache com o contexto sobre o qual precisamos construir e, aos poucos, fazer inference com mais segurança. Então começamos com o KV cache, mas, para fazer o processamento propriamente dito e gerar tokens no Diffusion Gemma, você não começa do zero. Você não simplesmente pega um token, depois o segundo e depois o terceiro. Em vez disso, começa com uma tela ruidosa. Ela geralmente tem cerca de 256

7:55:24 tokens, e então a tarefa do denoiser é processá-la e preenchê-la iterativamente com tokens dos quais ele tem muita confiança. Ainda assim, é exatamente o mesmo modelo. Ele usa os mesmos pesos compartilhados do modelo Gemma 4 26B. Mas há uma diferença. Se você tem uma tela grande e quer atualizar os tokens simultaneamente, tanto no início quanto no fim, precisa de um tipo diferente de atenção. Então, quando está no modo

7:55:55 denoiser, ele usa atenção bidirecional. Assim, consegue atender às duas direções. Depois disso, ele recebe o KV cache do encoder, porque, mais uma vez, o encoder foi feito para processar o estado e deixá-lo pronto para o denoiser fazer seu trabalho. Então o denoiser pode prever ou sugerir quais tokens devem ocupar posições específicas, porque temos essa tela inicial de tokens e tudo o que ele precisa fazer é atualizá-los nos lugares apropriados. Então há essa

7:56:26 tela prevista, mas, sabe, ele não faz tudo perfeitamente de uma só vez. Por isso, precisa de algumas etapas para fazer isso. Há tokens dos quais ele tem muita confiança, obviamente, e outros nem tanto. Então, o que você obtém é a chamada tela aceita: alguns tokens são aceitos e outros, não. Os tokens que não são aceitos são submetidos a uma nova adição de ruído, porque o objetivo desse modelo é remover o ruído da tela original e encontrar os

7:56:58 tokens que realmente deveriam estar ali. E assim acabamos com uma tela com ruído novamente, e ele pode seguir para a segunda etapa. Nessa segunda etapa, ele usa o KV cache outra vez e pode usá-lo para fazer um processamento semelhante. Mas descobrimos que fazer só isso não é uma abordagem perfeita. Porque, na primeira etapa, ele já tinha uma ideia inicial do que queria fazer. Mesmo que alguns tokens não tenham sido aceitos, ele

7:57:30 ainda tinha uma direção que queria seguir. Então, há ali uma espécie de conexão residual, um condicionamento próprio: você pega os logits da etapa anterior e os fornece como entrada para a segunda etapa. E então pode repetir esse processo várias vezes, geralmente por oito etapas ou algo assim, atualizando essa tela. E, nessas oito etapas — às vezes menos, às vezes mais —, você obtém 256 tokens. Isso faz o modelo funcionar incrivelmente rápido quando é servido a um único

7:58:01 usuário em uma GPU maior. Eficiência tem um significado bem diferente quando você compara um cenário limitado por computação a um limitado por memória. Mas ainda há muitos casos de uso para isso. Um que não esperávamos que fosse ganhar tanta popularidade na última semana ou algo assim é, obviamente, o Gemma. Porque o Gemma, sendo um decision model fundacional, sabe, essencialmente um classificador fundacional usado para tomar decisões, acaba funcionando

7:58:32 muito bem com diffusion. E funciona mais ou menos assim. Digamos que você tenha uma situação: a impressora está pegando fogo. Algo que exija que você tome uma ação. Você descreve o estado, a situação ou o que quer que seja; novamente, usa aquele encoder e processa a entrada para criar um KV cache. O que acontece em seguida é que, em vez de ter uma tela totalmente ruidosa, você preenche previamente alguns desses tokens. E os tokens preenchidos previamente são

7:59:04 relacionados às ações sobre as quais você quer que o modelo dê uma sugestão. Certo, a impressora está pegando fogo e suas opções são decidir se deve evacuar ou ligar para alguém. Esses tokens não mudam, mas os outros continuam ruidosos. São eles que precisam ser preenchidos. E o que acontece é que, assim, ele pode fazer uma previsão apenas para esses dois tokens e, usando o que vimos antes, calcular a probabilidade de que ele deva

7:59:35 fazer algo ou não. Basta uma etapa de remoção de ruído. Tecnicamente, ele pode fazer mais, mas, se você quiser tomar decisões rápidas, é só isso que basta para criar o que, aparentemente, agora se chama Diffusion Gemma. Mas isso funciona extremamente bem porque ninguém fez fine-tuning nesse modelo; a única coisa que acontece é que ele é limitado de certa maneira. Mas isso também demonstra esse conceito de eficiência, porque não há problema em limitar certas coisas de certas maneiras, já que

8:00:07 isso abre caminho para garantir que ele possa ser usado para coisas que não imaginávamos antes. Quando juntamos tudo isso, uma coisa que torna tudo isso possível é que tudo gira em torno da comunidade, certo? Eficiência não é para nós, é para vocês. É para as pessoas que realmente usam esses modelos. E não importa se é em um celular, em um laptop ou em uma GPU maior. Quando você disponibiliza esses modelos open source — e vocês já ouviram várias palestras hoje

8:00:38 falando sobre isso —, eles precisam ser úteis para vocês. Esse é o principal objetivo de contribuir com a comunidade. Mas, da mesma forma, quando você faz isso, vê a comunidade retribuindo, porque um decision model baseado em um modelo que não foi necessariamente pensado para isso… Bem, é muito legal ver isso. Isso traz muita inovação de uma área que, sabe, não foi desenvolvida por nós. Mas, ao dar às pessoas a opção e a

8:01:10 oportunidade de brincar com esses modelos, de abri-los para ver o que acontece dentro deles, de ajustá-los e modificá-los, você obtém esses modelos divertidos e interessantes — e ninguém sabe aonde isso vai chegar. Não faço ideia. Agora há muita empolgação em torno disso. Acho que por um bom motivo, mas, com empolgações assim, vamos ver até onde isso chega. E, quando se fala de eficiência, há todos esses campos e perspectivas diferentes nos quais você pode se concentrar. E eu poderia ficar aqui

8:01:40 falando por horas e horas sobre o que eficiência significa em conjunto com desempenho. E não é algo fácil de fazer, certo? Há muitos modelos open source incríveis por aí que tentam se concentrar nessas coisas, porque não se trata apenas de desempenho, mas também de saber se você consegue realmente executar o modelo. Não importa o quanto um modelo seja bom: se você não consegue executá-lo, ele não tem utilidade. Por isso, diferentes grupos estão dando muita atenção a isso, e há muita coisa acontecendo em dispositivos Gemma

8:02:14 e espero que isso ajude vocês a entender o que significa se concentrar nesses modelos menores. É uma narrativa bem diferente da de ficar aumentando cada vez mais. Isso também é interessante. Traz muitos recursos muito legais. Mas esses modelos open source, esses modelos pequenos, especialmente quando estão no dispositivo, na edge, nos seus dispositivos menores, precisam ser capazes e rápidos. E a eficiência, sob muitas perspectivas diferentes, é uma parte muito importante

8:02:44 disso. Muito obrigado. Todos — [aplausos] — certo. Opa. Certo.

8:03:30 Certo. Obrigado, pessoal. Vamos aplaudir Martin mais uma vez. [aplausos] Certo. Nosso próximo palestrante vai chegar em alguns minutos. Enquanto isso, tenho tantas perguntas para vocês. Então, eu só queria saber qual foi a parte favorita de vocês nesta conferência. Alguém quer compartilhar?

8:04:04 Certo, talvez duas perguntas abertas não funcionem com uma multidão tão grande como esta. Certo. Então, vocês foram à expo, viram os brindes, deram uma olhada? Mas eu só quero saber, por exemplo, o que eu mais gosto é ver as pessoas na expo conversando e fazendo novas amizades. Acho que é algo bastante óbvio de dizer, né? Sempre que vamos a um lugar novo, sempre que vamos a um evento, é para conhecer pessoas. Mas eu gosto muito de como isso realmente se transforma em

8:04:35 uma família. Já participo do AI Engineer há bastante tempo, em vários lugares do mundo: em San Francisco, Nova York, Londres e aqui. É muito legal poder ver que, às vezes, vemos os mesmos rostos várias vezes e depois fazemos novas conexões. Então, meu conselho para vocês, para ser sincera, sei que não temos muito tempo, mas garantam que vão se conectar e colaborar, porque acho que, por meio desta

8:05:05 comunidade, muita coisa pode acontecer, e nunca se sabe: não precisa acontecer agora, pode acontecer no futuro. Outro momento legal que vi foi tanta gente fazendo fila para conversar com nossos palestrantes. Muita gente veio falar comigo e também me perguntou sobre alguns dos nossos palestrantes. Pelo visto, P.A.I. fez bastante sucesso. ARM também é bastante popular. Então, é bom ver que nosso público é bastante diverso. Ninguém

8:05:36 quer compartilhar qual foi seu momento favorito. A comida. Certo. É, acho que sim. É, acho que sim. Obrigada novamente, Sarah, por patrocinar a comida. Pelo visto, acertamos em cheio. Certo. Alguma palestra favorita? Gemma 4 foi ótima. Certo. Uau. Legal. O que mais? Certo, foi Gemma 4 e só.

8:06:07 Tipo, devíamos ter ficado só com Gemma 4 durante toda a conferência e pronto. O pessoal do Kidsa foi hilário, e eu adoro a Kitza. É isso aí, KZA. Mas, sim, ele é hilário. Concordo com isso. Certo. Bom, chega de falar de mim, mas esta é nossa última apresentação do dia. Então, muito obrigada por continuarem aqui. Mas, antes de começarmos, gostaria de apresentar

8:06:37 Olivia Tibu, da Gradium, que vai falar sobre a camada que falta na IA conversacional. Vamos aplaudir Olivia. Certo. Tudo bem.

8:07:11 Você está exagerando. Ah, não foi isso que eu quis dizer. Também não foi isso que eu quis dizer. Certo. Devíamos começar. Deixa eu ver se isso

8:07:41 está funcionando. Está funcionando. Legal. Certo. Posso começar? Sim. Certo. Então, vamos começar. Oi, pessoal. Meu nome é Olivia Tubul. Sou CTO e cofundadora da Gradium e hoje vou falar sobre as camadas que faltam na IA conversacional. É um título misterioso. Então, vamos ver o que isso significa. Talvez, antes disso, eu possa apresentar a vocês quem somos na Gradium. Somos uma startup de um ano

8:08:14 dedicada a treinar modelos de voz. Talvez vocês já tenham visto essas siglas. Se não viram: ST significa speech-to-text, TTS significa text-to-speech e S2S significa speech-to-speech. Treinamos e disponibilizamos na Gradium modelos de todos esses tipos. Mas, antes disso, se eu voltar à origem da Gradium, ela é a Kyutai. Então,

8:08:44 talvez vocês já tenham ouvido falar. Não sei. Sim, alguns de vocês. Ótimo. A Kyutai é um laboratório de ciência aberta com sede em Paris, fundado em 2023, com bastante dinheiro e muita liberdade. E, com essa liberdade, eles fizeram alguns grandes avanços científicos. O Moshi é provavelmente o mais famoso, e vou voltar a falar dele um pouco mais adiante na apresentação. Há também alguns outros, mas eu diria que o sucesso desses modelos de voz foi tão

8:09:15 grande que, de alguma forma, pensamos que, para levar nossas ideias de pesquisa a um público maior, deveríamos transformá-las em produtos. Então, o objetivo da Gradium era realmente preencher essa lacuna entre pesquisa e produto. E aqui estamos, um ano depois. Então, IA conversacional, certo? Como chegamos a isso? Na verdade, hoje ela está praticamente em toda parte. Vocês já ouviram falar de voice agents em jogos, transmissões ao vivo,

8:09:46 assistentes, robótica: em qualquer lugar onde se queira falar com uma máquina, há um voice agent envolvido. E hoje eu gostaria de explicar um pouco da história, mas não toda. Se eu voltar ao que, provocativamente, poderia chamar de era pré-histórica dos voice agents, ou seja, antes dos LLMs, vocês provavelmente se lembram, né? Acho que aquilo foi o mais perto

8:10:18 de uma impressão de AGI naquela época, eu diria. Realmente parecia AGI, né? Era o iPhone e a Siri. E a Siri não era exatamente AGI; era um produto muito bom, um produto de engenharia composto por diferentes camadas — muitas camadas, seis delas, desculpem. A primeira era o reconhecimento de fala, o speech-to-text. Depois que o áudio era transformado em texto, ele era convertido em

8:10:50 classificadores que tentavam identificar qual era a intenção, o objeto, o sujeito, o complemento e coisas desse tipo. Havia um gerenciador de diálogo, algumas chamadas a APIs — por exemplo, para consultar o clima ou a agenda no telefone. Provavelmente, a parte que mais dependia de templates e expressões regulares era gerar o texto que a Siri falaria em voz alta. Depois, o TTS

8:11:20 falava o texto em voz alta, certo? Depois vieram os LLMs, e talvez não precisemos de tudo aquilo, certo? Toda aquela compreensão de linguagem natural, aqueles templates, tudo isso desapareceu. Com os LLMs, há uma pequena ressalva, certo? Ainda existe um gerenciador de diálogo nos voice agents modernos. E esses LLMs ficaram mais poderosos, certo? Agora conseguem se conectar ao mundo externo. Eles podem interagir. Podem

8:11:53 conversar com um banco de dados, fazer uma busca na web, usar MCPs, fazer chamadas a ferramentas, usar recuperação de informações e RAG. E se tornaram voice agents. O que vocês estão vendo aqui é, na verdade, como eu diria que 99% dos voice agents funcionam. Isso se chama modelo em cascata: ASR, ou STT, LLM e TTS. Eles não são treinados em conjunto. São três módulos de IA que conectamos um ao outro.

8:12:26 Há uma extensão disso: talvez não precisemos de três partes. Talvez possamos usar apenas um modelo grande. É isso que chamamos de speech-to-speech. E, nesse caso, não é preciso levar em conta a alternância de turnos. O próprio modelo sabe quando falar e quando ouvir. Isso dá uma visão geral do que é IA conversacional. Também posso mostrar um pouco do que fazemos e depois falar sobre os aspectos de engenharia e de IA

8:12:58 por trás disso. O que fazemos na Gradium? Basicamente, tudo isso, certo? Fazemos text-to-speech, speech-to-text e text-to-speech no dispositivo. Também fazemos tradução de fala para fala. Fazemos design de voz porque, quando queremos dizer algo em voz alta, queremos dizê-lo com uma determinada voz. Pode ser, por exemplo, uma voz com sotaque francês, ou uma voz feminina, mais aguda, mais grave, seja como for. E, em breve, teremos speech-to-

8:13:30 speech. Esta palestra se chama “A camada que falta na IA de voz”. Então, o que está faltando, afinal? Parece que está completa, certo? E algumas pessoas vão tentar convencer vocês de que esta imagem está completa, mas não está. Estes são apenas alguns exemplos, não são todos. Vamos falar mais sobre isso. Então, se colocarmos a IA de voz no mundo real, é bem provável que ela saia do controle, certo? Porque a maioria das aplicações

8:14:02 Há mais pessoas no telefone, um interlocutor, sabe, um computador conversando com outro. Mas, quando você leva isso para a vida real, há muitas pessoas falando. Isso confunde o agent. Os ruídos confundem o agent; em sessões longas, você perde o contexto, e também há a questão da escala global de verdade. E o que quero dizer com escala global de verdade não é a capacidade de qualquer pessoa acessar seu serviço, mas algo como o que a Siri fazia: qualquer pessoa, no próprio telefone, pode falar com ela

8:14:34 em vez de digitar. Por trás desses problemas, há alguns desafios, e vou escolher dois deles para explicar e aprofundar como fazemos isso e quais são os desafios. Se você quiser criar modelos de voz, precisa fazer várias coisas. Basicamente, você quer algo rápido e que possa ser disponibilizado em escala. Então, você precisa

8:15:04 pensar nessa rapidez e nessa escala, em tempo real e em escala, desde o início. Isso significa projetar um modelo que consiga escalar e ser disponibilizado rapidamente, otimizar a inference e ter uma infraestrutura de serving que dê suporte a ele. Vou falar do primeiro e do último ponto. Então, como funciona um modelo desses? Quando você quer projetar um modelo novo, basicamente, não começa do zero

8:15:36 certo? Você começa com algo parecido e tenta adaptar. Então, o que você realmente precisa, e estou falando de um sistema de fala para fala, é de algo que receba a fala à medida que ela chega, que consiga receber cada vez mais fala conforme a conversa avança e que consiga começar a responder falando o mais rápido possível, certo? E, claro, um dos requisitos é receber fala e produzir fala, certo? Então, mesmo

8:16:10 que não tenhamos esses modelos, há uma família de modelos muito parecida com isso e que atende a dois desses três requisitos: os LLMs. Com os LLMs, você insere texto e recebe texto. Como eles funcionam? Você tem um contexto. No começo, é o prompt, mas depois passa a ser um contexto. São palavras, e o LLM é treinado para prever o que vem a seguir. Certo. Então, nessa situação, Gradium é uma empresa de modelos de IA com sede

8:16:41 O que vem a seguir? É “in”, “of”, “at”, “blue”, “bird”; sabe, o modelo atribui uma probabilidade a cada uma delas. Então, claro, “in” parece ser uma boa candidata. Se você representar isso desse jeito, na linha de baixo está o contexto; na linha de cima, a previsão. O interessante — e é por isso que são chamados de modelos autorregressivos — é que a próxima previsão passa a fazer parte do contexto na rodada seguinte. Então você diz: “Opa, desculpe, Gradium é…” — previsão

8:17:14 IA se torna parte do contexto e agora o modelo pode trazer uma palavra nova, e outra, e outra. Dessa forma, ao longo do processo, você prevê e gera uma frase inteira. Então, isso pode funcionar com áudio? Parece a mesma coisa, certo? Áudio é uma sequência, sequência para sequência. Por que não funcionaria? Bem, há um problema de dimensionalidade aqui. O problema com o áudio é que este texto, “Gradium é uma empresa de IA com sede em Paris”, tem nove palavras. Ou seja, umas oito palavras no contexto e uma

8:17:45 que você vai prever. Falado em voz alta, isso dura 3 segundos. Mas 3 segundos de áudio, se você representar isso em um computador com qualidade normal, terão cerca de 24.000 amostras por segundo. Essas oito palavras se tornam 72.000 valores de amostra. Então, a sequência fica muito mais longa. Você tem 10.000 vezes mais valores de sequência para prever e, como a arquitetura Transformer

8:18:17 na qual o LLM se baseia usa autoatenção, que é quadrática, sua matriz de atenção fica 100 milhões de vezes maior. Então, isso não é viável. O primeiro truque é transformar o áudio em tokens. Esse é o codec neural. E, na verdade, descobrimos que dá para fazer isso. Você pode treinar um modelo para comprimir o áudio em tokens, de 24

8:18:47 kHz para 12,5 Hz. Então, você divide por 2.000 e obtém uma quantidade viável de tokens em sequência; pode começar a fazer previsões porque, no final, vai decodificá-los de volta para áudio. Então, se você quisesse treinar um sistema de diálogo assim, poderia dizer: eu sou o LLM, certo? Sou o cinza. Temos uma sequência: eu falando, eu falando, eu falando, você falando, você falando, eu falando, blá, blá, blá.

8:19:18 Essa é uma sequência, e vamos prever os próximos tokens de áudio, certo? Mas isso, desculpe, desculpe, desculpe, desculpe, não funciona bem assim, porque numa conversa não é como se eu falasse ou você falasse. Podemos estar falando ao mesmo tempo. Caso contrário, seria só uma conversa por walkie-talkie, o que é bem sem graça. Então, na prática, você precisa inventar algo novo que não temos nos LLMs: Transformers hierárquicos multistream. Assim, você não tem uma única linha

8:19:48 do tempo para o contexto. Você tem duas: uma para mim falando e outra para você falando. Essas duas coisas prestam atenção uma à outra para poder prever o que vem a seguir. E esses modelos conseguem ouvir e falar ao mesmo tempo. Vou dar um exemplo. Desculpe, claro.

8:20:23 Então, o planeta é Sirius 22. Você pode traçar uma rota até lá, por favor? >> Sim, senhor. >> Certo. Quanto tempo vamos levar para chegar lá? >> Já tracei a rota. Leva aproximadamente 5 meses para chegar lá. Certo, isso não é tão ruim. Você acha que temos tudo de que precisamos a bordo da nave para iniciar a missão? >> Sim, senhor. Temos tudo de que precisamos. >> Certo. >> Hoje, >> certo, vou pular o segundo. Então, dá para ver que é muito natural: o modelo é treinado para ouvir e falar ao mesmo tempo. Portanto, não há latência nenhuma. E aquele era Alex, nosso diretor científico, em 2024.

8:20:57 Agora, há algo que não contei: em 2024, tínhamos essa tecnologia na QI, mas não a vendíamos. Então, o que está faltando aqui? Bem, há uma questão: esse é apenas um modelo, capaz de ouvir, falar e processar linguagem. É muita coisa para um modelo muito pequeno. Então, quando você conversa com ele, em algum momento pensa: certo, ele não é tão bom quanto, sabe…

8:21:29 A limitação é ainda pior: esse modelo é meio isolado; não conversa com o mundo externo. Se não conversa com o mundo, se não consegue, por exemplo, fazer uma reserva, então, em produção, é só um brinquedo. Portanto, o grande desafio da fala para fala hoje é conseguir uma integração perfeita com tool calling. Se você fizer isso, terá a mesma experiência e, ao mesmo tempo, poderá fazer o que um agent de voz deve fazer. Certo,

8:22:00 isso foi, mais ou menos, como construímos um modelo; não foi a receita completa. Agora, digamos que você tenha o modelo e queira escalá-lo e disponibilizá-lo para o mundo. Como fazer isso? Aqui, temos o problema da latência. Há uma pessoa com o computador. Vou usar o exemplo de texto para fala: ela envia um texto para o nosso servidor, e nós temos que devolver áudio. E, se você quiser integrar

8:22:31 isso a um agent de voz, precisa ser rápido, precisa ser em tempo real. E, por tempo real, queremos dizer menos de 300 milissegundos. Esse é o orçamento de latência para o processo inteiro. Caso contrário, será uma conversa estranha, em que você espera um tempo até receber uma resposta e fica entediado. Então, precisa ser rápido. E, durante esse percurso, há três camadas pelas quais você precisa passar. Uma é a camada de transporte,

8:23:02 certo? Camada de rede. A informação precisa viajar do ponto A ao ponto B. Depois, você tem a camada de produto, porque alguém me envia uma solicitação. Devo verificar se ela é legítima. Essa pessoa tem permissão e créditos? Ela quer esta voz. Temos essa voz? Onde ela está? E assim por diante. Então, você precisa aprimorar a solicitação ou negá-la. E então há a computação.

8:23:33 Então, como fazemos isso rápido? O primeiro problema que você precisa resolver é o de latência. Digamos que eu tenha colocado meu servidor em algum lugar da Europa e meu cliente esteja em algum lugar dos EUA. Bem, só de fazer a viagem de ida e volta pelo Oceano Atlântico, estou desperdiçando cerca de 100 milissegundos, um terço do meu orçamento, apenas para transportar a informação. Então, como resolvo isso? Certo, fácil. Vou colocar servidores em todos os lugares, certo? É mais

8:24:05 caro no início, mas vou reduzir o trajeto entre o cliente e o servidor. Mas agora tenho novos problemas, certo? Porque antes eu tinha um sistema sem replicação nem distribuição. Agora tenho sistemas distribuídos, nos quais as informações precisam ser sincronizadas. Claro, se você quer velocidade, usa caches, certo? Então, tenho um banco de dados e um cache do meu banco de dados. Isso, por si só, já é um problema, sabe, por causa de toda a invalidação de cache. Mas agora você tem muitos caches que precisam ser sincronizados uns com os outros.

8:24:36 Caso contrário, você cria uma API key e vai para a Califórnia. O sistema não sabe da API key. Estranho. Certo. Então, você troca latência por complexidade, por complexidade de engenharia. Podemos lidar com isso, mas ainda é importante estar ciente. Depois, a segunda coisa, que acho muito, muito nova. Sabe, quando começamos, há um ano, pensávamos: não tem como, se eu precisar de uma nova GPU para atender à minha solicitação, pedir uma GPU ao meu provedor de nuvem. Ele me dá uma GPU, ou ela me dá uma GPU.

8:25:07 A GPU fica pronta, eu baixo os pesos e a imagem do Docker. Aqueço a GPU, e isso vai acontecer em 300 milissegundos. Impossível, certo? Quer dizer, se você tentar, talvez consiga fazer isso em minutos, certo? O que está acontecendo hoje? Bem, nunca consideramos isso uma opção. Você precisa prever a demanda e estar preparado para ela, mas

8:25:38 agora, o que é ainda pior é que a escassez de GPUs é tão séria que talvez você nem consiga uma para o dia seguinte. Então, talvez você queira mais uma GPU, mas não consiga, porque não há nenhuma disponível na sua região. Um dos provedores de nuvem pode dizer: “Desculpe, todo mundo quer uma GPU. Não temos nenhuma.” Então, como lidar com isso? De novo, você vai compensar esse risco com mais complexidade, e há duas coisas que você

8:26:09 pode fazer. A primeira é recorrer a diferentes provedores; assim, aumentam as chances de encontrar uma GPU. Ou vou tentar fazer meu modelo funcionar em diferentes arquiteturas, em diferentes modelos, com chips de diferentes provedores, certo? Não apenas Nvidia, nem apenas H100 ou algo assim. Isso aumenta as chances de encontrar uma GPU. Então, mais uma vez, para mitigar esse risco, estou aumentando a complexidade do meu sistema.

8:26:40 E como lidar com picos de demanda, certo? Porque às vezes todo mundo quer ser atendido ao mesmo tempo, certo? Há diferentes estratégias que você pode adotar, e nós escolhemos duas opções. A primeira é dizer: “Agora, vamos aproveitar todos esses clusters e redirecionar o tráfego de um para outro, para o mais próximo.” Ou também é possível alterar o tamanho do batch do seu modelo. Talvez você possa trocar um pouco de latência por um batch maior, certo,

8:27:12 durante o período em que a onda chega. Você aumenta o tamanho do batch e depois o reduz. Na prática, se você juntar tudo isso, obtém um bom modelo, com inference rápida e atendimento rápido. Então, esta semana, estamos desenvolvendo um novo modelo beta de texto para fala e fizemos uma corrida: clicamos de alguma forma ao mesmo tempo, mas medimos quanto tempo demorava para o áudio voltar para nós e

8:27:44 para alguns provedores. E foi isso que obtivemos. >> Oi, sou o mais novo modelo da Gradium e sou o modelo de texto para fala mais rápido que já desenvolvemos. Primeiro áudio mais rápido, conversas mais naturais, sem espera e velocidade garantida. Experimente hoje. >> Sim. Estamos felizes por estarmos, sabe, ampliando os limites da latência. Sabe, os melhores modelos ficavam em torno de 150 milissegundos, e nós o tornamos três vezes mais rápido. Então, em algum

8:28:16 momento, não há limite, certo? Nunca vai ser, sabe, zero milissegundos, mas estamos felizes por conseguir juntar tudo isso para fazer acontecer. Agora, para encerrar esta palestra, vou falar sobre se podemos ir além. Na verdade, eu disse que não podemos chegar a zero milissegundos, e isso é verdade. Mas podemos chegar a zero milissegundos de deslocamento? Podemos chegar a zero milissegundos na camada de produto e ainda ter algo rápido, que escale ainda

8:28:47 mais? Essa é a ideia de mover a computação diretamente do servidor para o cliente. Para isso, você precisa ter modelos muito pequenos, que possam funcionar no seu dispositivo, no seu celular, no seu irmão, numa Raspberry Pi, seja lá o que for. Também lançamos o Grad Phone, que é o menor — não exatamente o menor, mas um dos menores —, com um número muito baixo de parâmetros: 100 milhões, apenas, e

8:29:20 com uma precisão muito boa. Você também pode experimentar. Entre em contato se quiser testar esses modelos. Vou dar alguns exemplos de como eles soam. >> Apenas 100 milhões de parâmetros, e posso falar com qualquer voz que você me der. >> E aqui está um exemplo com uma voz totalmente nova, clonada a partir de uma amostra de 10 segundos. >> Certo, vamos pular. >> Essa voz não existia há um minuto. Eu a gerei a partir de uma única gravação de 10 segundos.

8:29:51 >> Mesmo modelo, voz completamente diferente. >> Clonada na hora a partir de um clipe curto. >> Certo, então é basicamente isso que eu queria contar a vocês. Sabe, o que há por baixo do capô da IA de voz, como criamos agentes conversacionais, como treinamos esses modelos, como os servimos e como, sabe, combinando boa pesquisa com boa engenharia, podemos realmente ampliar os limites da IA conversacional. Obrigado.

8:30:23 Obrigado. [aplausos] [aplausos] >> Muito obrigado, Olivier. Vamos aplaudir Olivia e a Gradium. Legal. [vivas] Ah, certo. >> Certo. Então, se vocês acessarem o QR code que foi compartilhado com vocês, poderão receber créditos para experimentar a Gradium. Certo. Obrigado. Bom, ainda temos algumas

8:30:54 coisas para vocês. Então, não vão embora ainda. Na verdade, trabalho com IA há bastante tempo. Não posso dizer que tenha sido muito tempo, mas parece que sim. E uma das perguntas que mais me fazem é: o que você acha que vai acontecer com a próxima geração? É uma pergunta difícil, certo? Porque as coisas estão mudando muito rápido, e já é bastante difícil para nós, adultos, entender o impacto de toda essa mudança tecnológica. Mas, para nossa sorte, há pessoas fazendo

8:31:24 algo a respeito. E eu gostaria de dar as boas-vindas a Cassandra Chin, que vai contar mais sobre isso. Então, por favor, vamos aplaudir Cassandra. >> Oi. Meu nome é Cassandra Chin e sou uma das instrutoras das oficinas infantis do AI Engineer Paris. Neste fim de semana, realizamos um evento para crianças, no qual as educamos e as ajudamos a aprender sobre

8:31:55 tecnologia para prepará-los para este mundo da IA. Mas, antes de entrar muito nesse assunto, quero falar um pouco sobre mim e por que sou tão apaixonada por ensinar tecnologia às crianças. Na verdade, comecei a ensinar crianças quando eu mesma ainda era criança. Eu tinha 13 anos na época e dava oficinas para crianças nos fins de semana, oficinas de Raspberry Pi em que elas podiam experimentar diferentes tecnologias. Mas, mesmo antes de eu começar a dar aulas na minha

8:32:26 casa, já havia muita tecnologia. Tínhamos impressoras 3D e muitas tecnologias diferentes. Lembro de montar meus próprios computadores. Acredito muito em inspirar as crianças a gostar de tecnologia, em vez de pressioná-las. Porque, se você mostrar às crianças que tecnologia é algo muito divertido, e não apenas o papai ou a mamãe no computador — mostrar a elas o que a tecnologia pode realmente fazer —, é isso que tentamos fazer nessas oficinas para crianças.

8:32:57 E, nas oficinas para crianças deste fim de semana, dei uma oficina ensinando as crianças a programar com IA. Elas usaram Mistral Vibe para criar seus próprios jogos. Fiquei muito surpresa com o que conseguiram fazer, porque temos ideias preconcebidas sobre como programar e sobre o que dá ou não para fazer. Mas as crianças simplesmente têm ideias. Algumas delas são, por exemplo, criar um jogo de RPG, um jogo de plataforma,

8:33:28 um jogo de banana. Muitas ideias criativas das crianças, mas elas só escrevem prompts e a IA pode criar o jogo para elas. E, com a ajuda da organização AI Tinkers, que trouxe muitas crianças de comunidades carentes para a oficina, essas crianças conseguiram aprender muito bem. Não importava a origem delas. E acho ótimo que também tenham trazido muitas meninas. Outro problema com a tecnologia é

8:34:00 haver muitos preconceitos de gênero. À medida que as crianças crescem, começam a pensar que tecnologia é coisa de menino, porque veem mais pessoas do setor. Mas, se você alcançar as crianças quando ainda são bem pequenas, elas não têm essa ideia de que tecnologia é coisa de menino. E muitas meninas podem se sentir inspiradas a entrar na área de tecnologia, como aconteceu comigo. Então, acho que essas oficinas para crianças são ótimas para elas. Na oficina que dei, as crianças criaram os jogos e nós os

8:34:30 conectamos a um repo do GitHub que tinha muitos recursos gráficos e um arquivo AGENTS.md. Isso criou uma forma mais segura para as crianças usarem IA, porque uma grande preocupação é: como é seguro deixar crianças usarem IA? Mas, com esse arquivo AGENTS.md, conseguimos instruir a IA a ser mais amigável, usar menos jargão técnico e ser mais prestativa, executando comandos em vez de pedir que você os execute. Muitas

8:35:01 instruções que tornam as oficinas mais adequadas para crianças. Temos este vídeo que produzimos sobre a oficina para crianças. Então, se puderem assistir, acho que vão gostar. >> [aplausos] >> Estamos aqui no AI Engineer Kids Day, em Paris, ensinando às crianças da região sobre tecnologia de IA, sobre modelos e redes neurais. Esta é uma ótima maneira de apresentar a IA às crianças de forma divertida e acessível, algo que adoramos fazer na NeoForge, porque estamos ajudando a

8:35:33 formar a próxima geração de engenheiros de IA. Há crianças de muitos contextos diferentes aqui. Algumas já são programadoras especialistas aos 8 anos, e outras estão na adolescência e precisam de um pouco mais de ajuda. Mas é isso que me empolga: estamos colocando todas elas na mesma sala. Há aprendizado entre pares. Elas ensinam umas às outras e se ajudam, para que, quando crescerem e começarem a trabalhar no setor, tenham controle sobre suas próprias vidas, suas próprias carreiras, suas próprias

8:36:04 ideias. Na minha oficina, as crianças usaram Mistral Vibe, um agent de programação que permite criar os próprios jogos. É muito interessante ver que tipo de jogos elas criam. Algumas escolhem criar um jogo de RPG. Outras fazem jogos de plataforma. Uma criança fez um jogo de estourar balões. E o interessante é que não há barreira linguística. Embora

8:36:35 as crianças falem principalmente francês, elas podem escrever em francês para o agent, que entende perfeitamente a língua e ainda programa os jogos para elas. Então, acho que foi uma experiência muito boa para as crianças, porque puderam criar seus próprios jogos, cada um único. Minha organização, AI Tinkers, organiza muitos eventos, e realizar um evento que reúna as crianças e seus

8:37:07 familiares — nossos membros habituais da comunidade, que podem ser um dos pais ou um irmão mais velho ou uma irmã mais velha. Isso pareceu muito empolgante, para que pudessem criar juntos, e acredito que isso faz parte da construção de uma comunidade. E há uma razão para estarmos tão empolgados em fazer isso.

8:37:40 [aplausos] Estamos realizando essas oficinas para crianças como parte da série de conferências AI Engineer. Vamos realizar a próxima oficina no AI Engineer New York e também no AI Engineer Code, em San Francisco, e no ano que vem vamos realizá-la em Londres. Então, se vocês forem a esses eventos, tragam seus filhos. Serão muito bem-vindos, e vamos ensiná-los.

8:38:10 [aplausos] >> Obrigado. É. Obrigado, Cassandra. Vamos aplaudi-la mais uma vez. Foi incrível. É. Obrigado, Cassandra. Obrigado à NeoForge por fazer um trabalho tão bom. Sou pai e me identifico com isso. Este é um trabalho muito importante. Então, obrigado mais uma vez. E vamos ouvir vocês também. Obrigado. Vocês conseguiram. Ei, vocês chegaram até aqui, não é? Sei que alguém me disse mais cedo: “Ei, você aplaude demais. Minhas

8:38:41 mãos estão doendo.” E eu falei: “Cara.” Temos que encontrar um… Ah, você está aí. Você se reconheceu. Legal. É, mas muito obrigado por estarem conosco. E gostaria de agradecer a todos que nos ajudaram a organizar este evento. Gostaria de… desculpem, gostaria de agradecer aos nossos patrocinadores: primeiro, à Mrol, por organizar o evento, e depois à Nvidia, como nossa patrocinadora platinum, mas também a todos os nossos patrocinadores gold e

8:39:11 bronze e silver. Então, vamos aplaudi-los, por favor. >> [aplausos] >> E também acho que vocês deveriam se orgulhar. Ouvi dizer que muitos de vocês viajaram de longe para chegar aqui, vindos de diferentes lugares. Ouvimos falar de alguém da Polinésia Francesa e também da Austrália, de Lyon e de diferentes partes da Europa. Acho incrível que pessoas venham de diferentes partes do mundo para estar aqui conosco, e agradecemos muito por isso. Então, é. Vamos ouvir vocês

8:39:42 também. Vamos aplaudi-los. Acho que vocês fizeram um bom trabalho. Certo, antes de encerrarmos, primeiro, espero ver vocês no ano que vem, mas ainda temos mais uma coisa do Patrick e do nosso patrocinador, Backblaze. Então, vamos ouvir o Patrick. Certo. >> Certo, pessoal. A primeira coisa que prometo é que isso vai durar exatamente dois minutos. E vamos aplaudi-lo por aplaudir tanto. Porque vocês precisam aplaudir mais uma vez. Conseguem

8:40:14 fazer isso? Certo. Sou Patrick, da Backblaze. É um prazer conhecer todos vocês. Vou pagar bebidas para vocês hoje à noite. Sou contratualmente obrigado a explicar o que é a Backblaze. Vou fazer isso da forma mais simples possível. Vou dar uma frase para vocês lembrarem: a IA funciona com GPUs. As GPUs precisam de dados. A Backblaze é a melhor opção de armazenamento de grande capacidade para dados de IA. Então, se forem lembrar de alguma coisa, lembrem-se disso. Dois exemplos. A Decart, construtora de modelos de mundo. Quando estavam começando,

8:40:44 Dean me ligou e disse: “Ei, tenho 15 petabytes e estou transferindo tudo em questão de dias, e ainda não consegui derrubar vocês. Vocês são incríveis.” E eu respondi: “Que legal. Quem é você? O que está fazendo? Não faço ideia.” Mas escolheram a Backblaze porque não cobramos pela saída de dados e temos uma capacidade de transferência realmente impressionante. Assim, puderam alternar entre diferentes clusters de GPUs e criar execuções de treinamento de IA incrivelmente eficientes. Outro cliente, a CoreWeave, usa nosso armazenamento de objetos

8:41:16 categoria. Eles nos escolheram porque fizeram uma prova de conceito muito abrangente e descobriram que, a partir de exabytes, nossa economia e nosso desempenho não mudavam. Por isso, nos escolheram: acreditavam que poderíamos crescer junto com eles para sempre. Então, seja trabalhando com terabytes ou exabytes, somos uma ótima solução para garantir que seus dados fiquem em um lugar que você controla, que possa usá-los como quiser, com quem quiser, e, como uma camada de armazenamento compatível com S3,

8:41:46 que custa um quarto do preço do S3 e não cobra pela saída de dados, você vai pagar bem menos. Como eu disse, nossa missão — que cumprimos para muitas empresas de IA generativa, neoclouds, empresas que extraem dados e empresas de IA física — é permitir que você use seus dados como quiser, onde quiser e com quem quiser. Vamos nos concentrar apenas no armazenamento e garantir que cada byte esteja disponível tão rápido quanto você precisar. E nosso principal

8:42:17 objetivo é que você gaste o mínimo possível com armazenamento, porque, depois de ouvir todas as palestras aqui nos últimos dias, o que vocês estão fazendo é muito interessante, e o armazenamento deveria ser a menor das suas preocupações. Então, não deixe de conferir nosso trabalho. Vou estar lá em cima. Temos um coquetel exclusivo, o Lebe Blaze. Muito original. Experimente um e venha conversar comigo. E, se sua startup está em estágio inicial, também temos um programa para startups em que oferecemos até US$ 100 mil em

8:42:48 créditos de armazenamento. Se fizer as contas, como custamos um quarto do preço do S3, esses créditos vão durar bastante, dependendo da rapidez com que sua empresa cresce. Então, obrigado a todos. Agradeço novamente à AI Engineer, à Mistral e a todos os patrocinadores, e agradeço especialmente a vocês. Voei de Minnesota para cá há duas noites. Volto amanhã de manhã. Estou exausto. Preciso ir cuidar dos meus filhos. Sei como isso é difícil, mas acho que valeu muito a pena. Obrigado, e nos vemos lá em cima.

Transcrição original

[16:15] Ladies and gentlemen, please join me in welcoming to the stage your MC for the AI engineer Paris 2026, developer relations engineer [music] at Replet, Rou Chevrey. Good morning. M check. Good morning everybody. How’s it going? Hey, this feels like day two energy, so we need to bring it up. Okay. How’s it

[16:46] going everybody? >> Yeah. Nice, nice, nice. Well, welcome to AI Engineer Paris day two. All righty. So, who was with us yesterday? Show hands. Okay, most of you guys. That’s awesome. So yesterday was all about how to think about the evolution of technology to think about AI today and then we talked about the future of AI right the future of AI um software factories um and also uh the the future of frontier models but I’m particularly

[17:17] excited about today today we’re going to talk about generative media about software factories again we’re going to talk about uh graph rags and we’re and we’re going to cover so much more so So with that, I want you to uh think about what you want to see. Please pay attention to everything that is going to be said here. Our speakers are going to be hanging out. So also take the time and go to the expo and talk to everybody to learn as much as you can. All right.

[17:47] So you know the drill by now if you were here, right? This event wouldn’t be possible without Mrol. So I would like to give give it up for them. So please let’s give it up for M. Thanks for organizing and let’s give it up for our sponsors, our platinum sponsor, Nvidia. Yes, please. Yeah, keep it going. So, to for all our uh gold sponsors, silver sponsors, bronze sponsors, and also our supporting sponsors. Let’s give it up one more time. Yeah, thank you. Okay. All right. So, without further

[18:18] ado, our next speaker is from Black Forest Labs, and he’s got some tendency. He loves going to the dentist. I don’t know why. Maybe we can ask him later. But he’s going to talk to us about um about how they went from image generation to robotics. So, please join me in welcoming to the stage Yakob Porchman. Thank you very much. Super nice to meet

[18:50] you everyone. Just need my slides maybe in here. Awesome. Nice to meet you everyone. My name is Jakob. I lead the AI solutions team. Um that’s the four deployed engineering team and solutions engineering team at Black Forest Labs. And I would like to start in with a hopefully trivial question. So give me a brief show of hands of who has generated an image or a video before using AI. Just give me a brief show of hands. This should be trivial. Come on. This is

[19:22] almost everyone hopefully. Um and um then hopefully if you generate an image or video before um you hopefully were in contact with Flux uh or Blackfire Labs before because Blackfire Labs at Blackfire Labs we are a research lab based in Germany and we build foundational image and video models for image generation. Um and you can see some of the samples um videos and images that were generated with our recent model flux 3 in the back uh back here. Now the second question that I have for

[19:52] you is who of you would believe me um if I would tell you that you can use that same video model to also control robots and play video games. Okay, that’s a few people, not really everyone. Um well, it’s kind of a it’s kind of a rhetorical question obviously. um otherwise I wouldn’t talk about it because that’s exactly the final thing that I’m going to close with today is how we’re going to customize Flux um to not just generate media, generate images, generate videos and and edit um edit both um but we’re going to talk

[20:25] about how to steer video games and steer robots with it. So you can see two different samples here that were also on the left generated with Flux. On the left you have Flux actually playing a video game. Um so this is not just a video of a generated but it’s actually flux taking the control and and generating the frames that are happening. And on the right you have a Lero that is completing pick and place tasks um with Flux the video our video model flux 3 as a

[20:55] intelligence backbone and what is in between video generation and using flux as a backbone for a robot that’s exactly what we’re going to talk about today because the part that is in between that’s basically bridging that gap is customization of this flux model right there is a super powerful model that we pre-trained trained mid-trained on essentially understanding the visual world having having an understanding for um how objects are behaving in the visual world and we are taking this model and customizing it for certain use

[21:27] cases and that’s exactly what we do in our AI solutions team as well and this is what I want to talk to you about um in a couple different steps to break this down a little bit before we go into robots that’s going to be the final stage of what we’re going to talk about um I want to talk a little bit about the anatomy of the inference pipeline because this is also going to give you an overview of sort of the customization vectors that we have when we walk work with flux and we talk to enterprise customers that want to use flux for very

[21:58] specific use cases. Um this breaks down in approximately six steps. First of course there is a user input uh that can be optimized. Um this is usually a text prompt, an image prompt, a video prompt, fairly straightforward, right? Um second step is the prompt upsampling. Prompt upsampling essentially means that we have an LLM or a VLM that sits between the user prompt that is sent to us and the flux model. And we essentially try to understand the intent. We try to understand what the user actually wants to do and we try to improve the prompt

[22:30] that the model generates something that’s closer to what the user is actually intending to do. Then there’s moderation. And you might be surprised in seeing moderation when it when it comes to when it comes to customization of a model. Well, actually moderation is one of the most important product surfaces. Um because moderation essentially decides what you’re going to see or what you’re not going to see. It’s not part of mostly not part of the model. Um but it is part of the user experience and we’re going to talk a little bit about how we customize it and also how we actually embed moderation into the model weights. Fourth, there’s

[23:02] of course the model. There are the model weights which we can fine-tune. We can run laws on it. We can fine-tune for style, for characters, for products. And we can fine-tune also for behavior and using fine-tunes, we can also add whole new modalities. And that’s exactly what we did with flux flux 3 action, which I’m going to talk about in the end of my presentation. Then there’s a post-processing step. Of course, this is kind of arbitrary. There can be upscaling, there can be restoration, there can be further moderation, right? Um, endless customization opportunities here. And then finally there is um we

[23:35] also work a lot about how we actually serve the model, how we deploy it, how we optimize it, how we distill it um etc etc. And what I want to do in the next 20-ish minutes is I want to go through essentially the four deployed engineers toolbox at least scratch the surface a little bit um of how we customize flux um in our day-to-day. So starting uh with the first major customization I want to focus on this prompt upsampling step. As I already mentioned prompt upsambling means that there is a VLM or

[24:07] an LLM that sits between the user and the model. Um that looks in practice something like this. Um so on the left here you have a user prompt. So this might be super super straightforward. a cabin in the forest. And if you send that straight to the flux model, generate an image, you’ll see something like the image on the left. It’s a plain um cabin in the forest, right? The mission completed. However, it might not be optimized for user intent. It might not be optimized for user preferences. Um it highly depends, of course, what the user wants

[24:37] here. In this case, the prompt is fairly simple. Um but it demonstrates the purpose quite well. So essentially we take the cabin in the forest and we essentially extend the prompt. In this case the default upsampler just optimizes for user preference. Extends the prompt the user the cabin in the forest to something like a hyperrealistic right angle stone chimney softarm golden light etc etc. And then you see the final result um um on the right. Whether you like the left or the right better, that’s up for up for discussion, of course. But the point

[25:09] being here is that the prompt upsling step gives us an incredibly powerful tool to actually steer the user intent and the generation that we’re taking into any direction possible. So let’s take a look at a concrete um concrete case. So this specific this was a real customer case. The customer essentially came to us and told us well actually we want to illustrate certain conversations that a user having and users are having in our application with flux images. So they want to create illustrations for topics. These topics could be completely

[25:41] random and they’re machine generated. So they’re not hunt created and they’re also not image prompts. So for example this could be familyfriendly travel destinations or draining water for my dishwasher. Right? Completely random topics not in the form of an image prompt machine generated. uh this could be a vast variety of topics. Now our task is to generate an illustration somehow illustrate this nicely. But the trick to this is that of course there are certain design requirements that we need to meet. So for example um in this specific case the subject is supposed to

[26:12] be on the right. It’s supposed to be a very clean image. There’s supposed to be a lot of space on the left for a text overlay. And there are certain design rules that also apply. For example, no people involved, no landmarks, and a couple others. So what we essentially do or what this actually comes down to is that the model the image model is actually not the bottleneck anymore because the model technically can generate all of these all of these different different things, right? No problem. But really the design requirements end up being the bottleneck and where prompt assembling comes in is

[26:44] matching and bridging the user prompt with the design requirements and matching these design requirements to the training distribution of flux. So finding the exact right spot that we need to send to the model um from the training distribution to generate the the exact image um that um slides are gone um here we go um to generate the exact image that actually follows the design requirements. So to give you two examples from the the

[27:15] topics that you already saw, um first they’re familyfriendly travel destinations. Um if you send that as a raw prompt to flux, completely unseampled, you’re going to see complete gibberish, complete uh trash trash images essentially. For example, there’s this this postcard style. The v variety between different seats also is extremely high when you just send this completely unupled. If we use our default upsampler, which is just optimized for general user user preference, then you you’ll see something like in the middle, probably a

[27:46] little bit closer to somewhat of an illustration, but not at all matching the design requirements. But if we actually customize the upsampling step, and we embed the design requirements directly in the prompt upsampling, you’ll see something on the right. So the subject is on the right. It’s a very clean image, very sort of glossy. There’s a lot of space on the left for text overlay. So meeting exactly the design requirements. Same goes for the second example. So draining water in a dishwasher without propped up sampling complete complete random image. Um

[28:16] getting a little bit better some sort of instruction video but still not at all what we want in the second case. But if we actually customize this upsampler which is essentially the system prompt that looks at the intent and tries to match that into the training distribution knowing the design requirements. we’ll get a very nice, very clean image, subject on the right, a lot of space on the left, text overlay possible. Um, and this is essentially a pretty simple trick. Um, because the um the massive example and what we essentially learned from this um the

[28:48] massive advantage is that it’s super quickly to iterate, right? You essentially just iterate over a system prompt. There’s no training needed. Um, and you have maximum use case flexibility. And this is sort of necessary as well to include the step because what we learn especially with when talking with enterprise customers is that users are just lazy. Users don’t necessarily want to know exactly how our training distribution looks like right how to perfectly um perfectly prompt flux. That’s in a lot of cases where we come in and we customize prompt upsampling to match exactly user intent

[29:21] design requirements and training distribution to find exactly the right sweet spot here. Um yeah, front up sling seems super simple but it’s an incredibly powerful tool and because it is so simple to to iterate over and it doesn’t need any training. Moving on to the next stop is moderation and safety. And you might be again a little bit surprised to see this in the customization surface here, but moderation is actually one of the most important product surfaces that we have um especially when offering a model to

[29:52] the through the API because essentially moderation decides on what the user sees and what not, what which prompts we allow and which not. Um so this is an incredibly important piece of the user experience that we offer. If you have tried some video models um state-of-the-art video models in the past, you might be very aware of error messages like this. You put in an image of yourself and you want to animate yourself, but you’re getting something like the images of videos might find likenesses of real people, etc. This is obviously not a model limitation. This is purely moderation service, right? That doesn’t allow you to generate

[30:23] something. And when talking to larger customers that want to do very specific thing thinks this is a massive issue and we need to customize and solve for this. Um, so two ways that I would like to talk about moderation. First is the most simple way and it is essentially in the configs. Um we have a modular setup to essentially customize configs. There is a fairly straightforward safety parameter here um that allows you to set that via API. And when customizing uh

[30:55] when customizing moderation for specific customers, we have a very fine grained confict setup that essentially allows us to set safety tolerance but also allow or block certain um certain categories specifically. So violence, sexual prompts, self harm, IP and likeness. And we also combine that with certain block lists and allow lists that we can set specifically for every customer. So think about, for example, a kids platform being much more strict, blocking violent, sexual, self harm, IP likeness, obviously, and then having

[31:25] even a specific block list. Uh fashion retailer being a little bit more a little bit more open, maybe allowing a little bit more of sexual leaning prompts. Um but blocking specifically competitor brands and allowing the own portfolio essentially only trying to generate their own their own stuff, of course, right? And then there might be a media or a movie studio that uh is much more flexible, allows even some violence and specifically wants to allow certain licensed characters even if they’re AP

[31:56] protected and wants to block every other character that is not that they don’t have a license for. So this is fairly straightforward. We just set the config super modular, super simple. However, this doesn’t work for every case um because we also deploy our models directly on customers infrastructure. So in these cases, we don’t ship the entire moderation stack. we somehow need to find a way to actually embed the moderation and the safety into the model rates. And this is where for example um a slider law comes in which is the next sort of tool in the toolbox of um our

[32:28] FTEEs. A slider law tries to learn an abstract concept or tries to learn the specific abstract con concept that we’re trying to block and tries to then turn around the rates that it learned to block that specifically. So let’s take the example of a desexualization slider lower um which you have essentially simplified here on the slide. Essentially you try to tweak the model tweak the lower adaptation matrix you try to tweak that into the d the rates into the direction of the of the

[32:59] pure concept of sexualization. How we do this is that you have a generic data set of images for example of people in this case one image of a woman in a black dress and you feed that to every um training loop tries once with a modest caption and once with a sexualized caption. So then you essentially train the model. This is the image and you see it tries one once modest and once sexualized and what what what is left in the rates is essentially the delta between [clears throat] both learnings. And the delta between both learnings is

[33:29] both both captions essentially contain there’s a woman, black hair, black death, whatever. But the delta between those is essentially the concept of sexualization because the sexualized caption contains that but the modest caption doesn’t. It’s much more descriptive. So you end up with a law matrix with an adaptation matrix that essentially describes the concept of sexualization, right? Um and in inference we can now go ahead and apply that to our model weights with a negative alpha. So we turn the weights

[34:01] exactly around to go in exactly the opposite direction which then turned out in this specific case for uh for minus 20 nudity detections and um 68% judged less less sexualized image quality. while at the same time the image quality generally is a complete tie because we literally only turned around the concept of sexualization. Um so this is a nice tweak to really bake in moderation into the weights and this is something that you can also ship directly to customer they can deploy it on their own infrastructure um to have a much safer

[34:34] model without any deterministic uh moderation around it. So what we learned from the moderation piece is that first of all safety is an extreme extremely important product product surface. Um it’s essentially the first thing that users interact with in some sense. It decides what users see what users don’t see and it can be a USB. It can even be a business model in certain certain cases. Modularity wins. Baking in moderation into model rates is cool. It’s fun. It’s a nice concept to build some sliders. However, it’s

[35:06] expensive to train. it’s static, you need to update it somehow. So in many cases or in most cases, we just go with simple confict config customizations because it’s just modular. It’s easy. It’s scalable, right? Um it’s it’s much cheaper to actually set up. Um and yeah, as as I already mentioned, motivation and weights is possible. However, it is expensive and static. All right, let’s move on. So, we already looked at the fine tune that changes behavior in the moderation direction, but I promised you

[35:37] some robots and I promised you some um flux controlling some things. So, finally, we’re going to look at customization of model weights um and how to fine-tune flux for specifically action prediction. Um just to give you an overview, generally if you fine-tune a model, usually we come with a certain goal in mind. If we’re talking about video models or or image models, we either fine-tune for a certain style, we fine-tune for a certain object that we want to present or a set of objects. We fine tune for a certain character that needs to be um extremely accurately um

[36:08] displayed or we fine tune for behavior. We also have some models that we find in for example outpainting, specific local editing, desexualization, right? All of these are behavioral finetunes. And then if you go even further, you can even think about fine-tuning for certain to to add certain modalities if we even go a little bit into mid-training and post- training. Again, that’s exactly what we did with Flux action. Flux action is a new um version of Flux uh Flux Backbone that we um continued mid-training and postrained and fine-tuned for

[36:40] specifically action prediction. This was actually released into open weights yesterday night. So check it out. It’s brand new. It’s in hugging phase. You can try it out. pull the rates and control your own layer robot with it. But just to give you a brief rundown on how it works. So we have an image model that essentially predicts frames um predicts video frames based on um based on a text input mostly, right? Um so how flux action works is that it has a text conditioning and it has a video conditioning. In this specific case, we work with a LE robot that completes pick

[37:12] and place task. The robot in this case has two camera sets. one is at the uh grabber hand, one is above um the top camera essentially. At the same time, we also fine-tuned flux action for the um for the embodiment of of the SL101, the Lobot robot arm specifically. So we actually teach flux that this specific robot has six axes and this the the the movement of these axes essentially represented by a vector that in every

[37:42] frame defines the direction that every axis needs to move into. So essentially is simplified a sixdimensional vector that we’re trying to predict here. Now [snorts] we feed the the the vector the the embodiment knowledge is already embedded in the model rates. We feed in the video frames and the text conditioning which defines the task and the output essentially is a video of the continuation of these video frames and also um the actual vector that defines

[38:13] the direction that the robot needs to move in to actually complete the task. And then you can on the right see how the layer robot um is actually controlled by flux. I mean you’ll have to trust me that it’s actually controlled by flux but you can check that out yourself. Um, and it actually completes exactly the task that it’s uh supposed to. You actually can see the the text bombs there. But um, so that is pretty fun. How that works in the background. Um, let’s take a little look at the architecture. Um, is that we have

[38:45] um a video model. Traditionally, it takes certain frames and it feeds them through a variable autoenccoder. um the autoenccoder projects my frames, my pixel space into a latent space which is an abstract representation um of of these exact frames and then we go through this den noising process that gradually reduces noise and tries to predict these next video frames. Um usually when we just predict an image or a video we then have a a decoder as well that then takes these latent these

[39:15] abstract representation and brings them back into the pixel space. Um now flux action is a world action model. Um that means that we don’t even send these action vectors um through the viral autoenccoder into the latent space anymore but we just normalize them into the dimensionality of the um of the latent space and we directly dise the uh directly dise essentially the action vector. Um that is a huge example because we essentially dise both in the same transformer. Um in the end

[39:47] for the action case we actually don’t even use the um decoder for the um for the frames and video part. We only denormalize the action part. Uh we have the robot actually apply it. Um and that’s how we complete the task. Essentially the video needs encoder and decoder. Actions are already a vector. So we can actually naturally feed them through the through the model that has been mittrained and fine-tuned on exactly solving these tasks. So flux flux to action uh flux 3 action

[40:18] um you can check out the research. You can download the rates here. It has dropped literally last night. It’s right now topping the leaderboards and being being state-of-the-art in exactly um this action prediction space. So check it out. It’s pretty exciting research. Um and we’re pretty excited about venturing in this in this domain uh as a new modality. Um and this is also already where I’d like to wrap up. Um what we basically looked at is customizing flux for certain use cases.

[40:48] We looked at prompt upsampling and how prompt upsampling can be an incredibly efficient method to actually match user intent with the design requirements into the training distribution of flux to actually get out an image that at scale uh conforms certain design requirements. We also looked at moderation. We looked at sort of static deterministic or more or less deterministic moderation uh that modularly um is embedded in config. Um we also looked at how to embed moderation preferences into model

[41:20] weights directly using a using a slider law. And then finally finally we looked at how to um add a new modality to flux specifically looking at flux action and how to tweak flux to actually control a robot and predict the next action. If you want to take away one single thing across all these methods and this is obviously just scratching the surface. If if you want to take away one single thing um about good customizations of AI models in general and also flux specifically it is that great custom

[41:50] customizations in all of these cases are as specific as needed and as general as possible. So they solve one specific problem to exactly the extent that it needs to solve them. But it also generalizes to actually maybe solve an entire domain, maybe be a solution that you can also roll out further. So with that, I’ll wrap it up. I have another advertising block here. We are hiring for the product engineers, solution engineers. Um if you want, check that out. You can also find me um find me at

[42:20] the conference, find me online. And yeah, thank you very much for attending. [applause] Thank you, Yak. Good job. All right. Okay. Yeah. Let’s give it up once more for Yaku, please. [applause] Thank you guys. I’m so excited for Black Forest Labs. And uh the nice thing about them as well is that they’re based in

[42:51] Europe. They’re based in Germany. And they’re the at the front of everything generative media related. and now they do robotics which is so cool. But you know another company that is European based and also at the the frontier of AI is 11 Labs. So our next speaker is actually is going to talk to you about generative identity at scale with orbs and basically uh who who here has used the chat GPT voice mode or 11 labs. So you’ve seen that little circle, that

[43:22] orb. If you use that, you probably have used something that our next speaker has built. So please join me in welcoming to the stage creative experience engineer at 11 Labs, Dorian Lods.

[44:00] Seems that internet’s not working. That’s a good start. All right. Hi everyone. I’m Dorian. I’m a creative engineer at 11 Labs but currently based in Paris. Um if you want to know more

[44:31] about what we do at 11 Labs or if you have any questions later uh please feel free to note the my socials. So I’m here today to talk to you about our how in a creative per perspective things have changed a little bit in the past few years and how how we deal with all these new tools set of tools AI tools enabled and so on. So uh just let’s take uh let’s let me just take a take a step back and

[45:03] tell you how I used to make the thing and now how I make the thing that makes the thing which is a bit of a change. So I came from an industry where used to make immersive creative experience websites are mainly based in WebGL or immersive installation or whatnot. They were all designed around a feeling uh refined over thousands of hours. Each one has a specific craft and and purpose. Um [snorts] during that journey um I interacted a lot with uh how you can streamline stuff

[45:37] with a system, how you can produce more or just expand your capabilities um with new tools for example comfy UI which is an amazing tool that helped creative new immersive like new deeper uh AI systems but still made for a single outcome and you will see that’s important for And all of this background led me to a specific project I work on which is this guy.

[46:07] Um it’s the OpenAI voice the face of OpenAI when they released the voice model. Um few notes but it’s was the first iconic orbs that I had to do. uh everything was handcrafted, had to fit on brand and was the goal was to to find uh a way to visually represent the voice that you talk to uh while representing the brand. So pretty much the same stack than before. It was hand tuned, deterministic, everything you see on

[46:38] screen is made with a shader. Um so math actually makes the visuals, all the inputs, all the colors, all the way the thing behaves were carefully tuned. But it was just made for a single purpose. And I spent few weeks designing one sphere. Then I had to design for 40 million voices which is a big change of scale if you ask me. So I joined 11 Labs. Uh for the one who don’t know us, 11 Labs is a

[47:10] European firstbased company. Uh we are leading the way on we have our own frontier in the research team dedicated to any voice surface any voice interaction music any sounds to be honest but we do much more than that. We have our own creative platform where you can um dub make new clone your voice prompt another voice um and so on. So many of our or many many creators uh already use the platform. We have the

[47:42] web one, we have the app, we also have uh 11 agents now. So we handle our customer support call, we do our own orchestration, many many many things. Um here are some key numbers because everyone loves numbers, right? Uh we support over 90 languages. Uh we already have millions of business developers, creators on the platform. Uh we crossed 600 millions of RR by end of June. uh current valuation is at 11 billion as of

[48:13] February and now we actually expanded the team to over 700 people across 50 countries. We have more than 10 million agent on the platform. It’s a lot of numbers I know. Uh but some here are some fun ones. So every day we generate more than 34 years of audio with our speech to text model. Um so the scale factor is definitely here and uh one that uh we we made 25 million tracks with our music our music models

[48:43] and different music touch points and one that I really really u that I really love I think it’s my favorite number here is that we so far helped to restore more than 11,000 voices for people who have lost them due to illness or injury. We’re super committed towards that goal. Our impact team is doing an exterior job uh to bring voice capabilities back to the people who actually need it for free. Um but more specifically I joined 11 Labs design. So the design team is

[49:14] pretty much all us here. Um we try to push the frontier of both the brand, the product, the way you interact with AI with all our stuff that we have on the platform and how we can streamline that. Um I join with my first uh challenge actually uh was to explore how voices which is our main interaction uh could have a visual identity and how that identity could work across the product. So how you bring more soul visual souls to our voices and how those

[49:46] souls should reflect the brand. Uh here’s what we’ve been cooking in the past few months.

[50:17] Do not first down. Yeah.

[50:58] Hey. Hey.

[51:56] >> [music] >> I might have spoiled a few things with

[52:27] that video. Uh so um the pitch was simple but yet not so much. We believe that every voice is every face. Um and then we had 40 million voices on the platform. So uh users they can prom voice, they can clone their voice, you have we serve many type of different voices and so they all uh they all represent now more than 40 million voices. And how do you design something

[52:58] that is iconic enough that still translate the voice characteristic but keep it in one visual system that each voice needs to bring the identity of 11 labs and it still need to feel like 11 Labs. So it’s all about feeling and developing it at scale. Uh first thing first it needed a reframe. So it could not just be me making the outputs anymore. It was me making the system that makes an output. very close to what we’ve been hearing in

[53:28] the past yesterday basically and today this morning uh with code factories and so on but here more on the design side uh the core concept of the or is it’s actually a stack of two layers you have the image layer that carries the brand characteristic the voice that it’s actually linked to the voice and then you have the realtime layer on the top which brings that to life at the interactivity had the living piece to to the one in the back. So, a

[54:00] bit of a change compared to the first one I worked on at OpenAI. Uh, and that touch point then is diffuse everywhere across the board. Let’s focus first on the image layer. Um, it’s as it core it’s linked to the voice. So, one voice equals one face. If you make a new voice, you make a new a new or So we need to we went down to the source and we we analyze the voice

[54:30] output for air like the audio output for every voice. We extract key metrics, key numbers um that that then fall under different category of pitch, energy, expressiveness that that drive the rest of the pipeline where at this core it’s very much linked to the voice. Uh in the first place we wanted to use embeddings directly but canary became a bit complicated later. Um to work to design the process and to

[55:01] really uh expand or to explore how much range do we need to work with. We extracted a set of 200,000 voices the most popular we have on the platform. And we realized for example that they are not distributed evenly. you have much more deep voices mainly for narration purposes. So we really had to focus in those kind of categories where the other ones might fall under like niche where it’s super high super energetic like maybe cartoonish style of voices. But uh that really helped us a

[55:32] lot during the process to to explore the thing at scale. Uh first thing first we wanted to um the voices to feel like the brand. So we needed to teach a model to speak 11 laps. Each voice is unique. The goal is to create a generate new voice per new visual new or per voice. So we needed to find a way so a model can actually learn our design language and how that translate. Uh so of the chef

[56:02] they don’t really know your brand. Um so we built a synthetic data set to train a specific lura on the top and actually there’s pretty fun thing that we explored is that we steer the inference uh with the caption. So on top of the of the action words we hand selected multiple type of colors and things that we wanted to attribute to different kind of voices. Let’s say high pitch, mid pitch, medium pitch. Um and then we we

[56:34] put that in the caption. So during the training um the model could actually steer a bit and like develop a bit more uh the varity and all those keywords were actually were put back into inventory. So at inference level when you rebuild the prompt the model can choose exactly the same keywords like sub keyword that has been in the training data. That was really fun. Um we explore different type of model uh one from our friends.

[57:04] So it’s a good segue actually. Um so we we try to yeah we explored different kind of open weight model. The goal was to f to find a good sweet spot between uh between like inferencing cost and development at large scale while still maintaining the quality. um post inference after you generate the base image the idea is that basically you blur it and you crop it inside the inside the base image. So each variation each or has a really really good

[57:35] variation into it. Um that’s what we call post inference. Um and that prepares for the rest of the shader. So let’s now focus on the real time layer of those orbs. Um during the design phase we we actually used code as a core design medium. So it lives as a shader. Uh it takes the image in the back and has multiple layers on top of it. Everything was uh made through an

[58:05] interface where all the design team was able to tweak and like see how we can feel things. Uh some parameters are tweaked with the sound itself with the audio feedback and so on. Um, WebJ is the interactive experience on the platform on the on the marketing website but uh uh but we converted this to OpenGL support for server server side rendering for many previews or other touch points that cannot actually run the shader themsel.

[58:36] Uh the shader itself is composed of basically six six stacks together. You have a realtime fleet simulation that has um the reaper effect that’s linked to the audio. It’s really bring the organicness into it. The goal I might have skipped that but the goal was to anchor the orbs into nature. Nature is the main characteristics of the orbs. You wanted to fill them to feel organic. Then you have multiple phase of of noise on the top to bring it to life. FBM and

[59:06] so on. And we have a a further sound wave that is actually a link with the one we had before and the the the brand grain that we put on many of our of our touch points. Um so all of that led to the shader playground like I said before it was the place where most of the craft was happening early on. Um but behind that we actually developed a reviewing tool to debug everything at scale. So one voice equal one output. So you also

[59:38] mean that you cannot choose the output and every output had to be right. So we quickly realized that in order to be able to maintain quality across the board, we needed to redo it at scale. Uh and that was really a key factor because you might end up with your debug ones that are super nice and then as soon as you run it at scale, it’s actually fall down. So building internal tools to review things at scale really really make the make a change. Um that’s the less fun part. Uh so I had

[1:00:12] an we had an amazing an amazing op process and amazing workflows. Uh and then I run through uh finance. Then they told me that okay D is super nice but for millions times 10 cents it’s way too much. uh so you need to find a way to reduce both latency and the cost. So we went back to the uh to the chart that I shared before where we have all the distribution of voices in the platform and we actually um took this as the core

[1:00:45] source. So instead of generating a new image every time, we generated a gigantic atlas at once. And then from this atlas, we actually crop a bit deeper in each of the image. And so uh that help us to not generate every time we we make a new voices but still maintaining a uniqueness. So every voices is unique because we rotate it, we crop it differently, we change a bit to U and so on. uh and they are still really much um locked into the audio

[1:01:15] characteristics. That helped to save more than 3.6 million. So pretty good. Uh run it 10 to 15 times faster and have less than three seconds per voice to generate the visual. So it have it’s happening on the back as soon as you as you make a new voice and then it run through all the the process audio process. It spin up it spin up the task on the infra and then generate the one. So less than 3 seconds actually make it not visible for the user. Um and so here’s a recap of the pipeline

[1:01:48] for the voices. You have the voice analysis in the first place that maps that map key metrics to uh visual mapping like a medium pen and energy level texture and so on. Then we have the entire generative pipeline I just showed you that prepared the assets, prepared the shader base, um the texture, the preview, the thumbnail, animated MP4, all of these diffused CDN and so on. And at the end you have 40 million plus outputs uh that serve

[1:02:19] pretty much everywhere as you can as you’re going to see in a few. Um quality development was really really important. Uh the concept the core design concept was was cool but we wanted it to feel alive everywhere to have to to to follow all the pipelines of the orbs that we have on the platform. Uh here you see on the left you have the the voice cloning um the voice cloning interface. So the orbs change depending on your voice. Uh we

[1:02:52] wanted to maintain quality across iOS, Android, uh it’s the one you see in the middle. Every shader had to look the same. Super important for the brand. Uh and we needed to review it at scale. So on the right side, you have like the admin interface where you can review every voice that we have. Um all of that started to grow. Uh we made a dedicated uh service. So we have a dedicated um cloud service for making our orb

[1:03:24] visuals. Now it’s called Picasso because it’s painter and and I’m French. Uh it’s a shared API across all our touch points. We we push those orbs everywhere. So in the core app the marketing website iOS and Android app uh 11 music which are which is our music brand branding and expanded into the brand core itself. So we made brand tools motion designs everything now used orbs the carrier brand the carrier of

[1:03:54] voice and the carrier of face. Uh it was backward compatible because we had already previous type of orbs in the platform. So we were able to run a back field of 40 million voices. Uh that back that back field run for a few days. Um really stressful moment but it worked at the end. Uh and now they are everywhere. They we cannot hold them anymore. They they are part of our um homepage. Uh the home page the first thing you see on the homepage is the orbs. Um they are part

[1:04:27] of the app itself. So you see for example here you have deeper voices has a tendency to be a bit darker. if they have more energy, they will have like blue hints on and so on. So, I really invite you to play with the platform and to try to filter voices um to to see how each characteristic of voice translate into visuals. Uh more renders and they actually came out of the screen which is really really cool and something I’m super proud of. uh we use

[1:05:00] them as a core brand uh elements toward everything we do. So on the left here it’s a autoome campaign we made in char uh in France uh where you could have spot orbs based on the on the on the branding of some of our clients. Here is Alan for example or on the right side you have London uh where we took over um one of the main square of London with train line color DNA and so on. So once again

[1:05:30] another clients of us and then we the orbs as itself doesn’t carry identity but it’s a shape shifter so we can also use it for expressing um so illustrating the the needs of our clients towards the thing we do. And here another example in the Paris metro. It was really fun to go to work and then see that on the metro. [snorts] Um so here is what we’ve learned uh during this little process. Uh using

[1:06:01] machine learning as a core creative medium change how you design. It changed the way you think. You don’t think about only the outputs but you need to think about how you create that. um machine learning AI tools are basically superpowers but they need to be used carefully uh if every design thing that you do don’t overlook it now the cost of making the thing has become so much lower that we have tendency to ship fast and fast and fast and we believe as a design team that the the edge is like

[1:06:32] the quality edge is going to make you actually um want more of brand awareness brand quality and so on So uh you need to own the pipeline. You need to own all the outputs like if they were your own. Uh the crash shifted into the data and rules. Uh this is how you trying to maintain all the AI stuff that we have and to be sure that they follow a branding rule, a feeling rule and so on. Uh every stage had to preserve the brand

[1:07:03] vision. Like I said, branding is getting more and more key. Um and the patterns revealed what a single output hit means that we need to debug at scale. If you’re making a if you’re making a a pipeline a process that it’s meant to to be deployed 40 million times you need for example to to debug it at scale. So don’t you don’t hesitate to run multiple run of of generation at a smaller scale to be sure that every you can own every single output.

[1:07:33] So I still care about every output like I said. Um they are all my they are all I’m all proud of them. There is not any one that I don’t like. Uh but instead of designing them now I designed the condition that produce it and that’s really really important and it’s something that we’ve seen on the code side and we also see it now on the design side. That’s pretty much it for me. Uh thank you for your attention and if you have any questions please don’t hesitate to reach out. uh check out our website or

[1:08:03] apps or everything and uh thank you very much. [applause] All right, thank you so much, Dorian. Let’s give it up one more time for Dorian, please. Thank you. [applause] All right. Okay, so show of hands. Who’s here has uh used open weights models before? Okay, cool. So if you did, you probably have used the tools from our next speaker company. So up next is someone from hugging face. He’s going to dive

[1:08:36] deep into how a transformers model loads in VLM. So yeah, hold on to your seats guys. That’s going it’s going to go deep. So please join me in welcoming to machine learning engineer at Hogenface, Harry Miller. All right.

[1:09:15] Okay. So, hello everyone. I’m Harry and as you just heard I’m a machine learning engineer at HuggingFace and I’m also a maintainer of VLM and in today’s talk I’m going to talk to you about how a hugging face transformers model can be loaded directly into VLM and why because of what we do to it will run just as fast as if the model had been dedicated had a dedicated implementation in VLM itself. But first a little bit of context in case you haven’t heard of VLM before.

[1:09:45] Uh, VLM is an open-source LLM inference engine. It came from the UC Berkeley Skylab and is now a PyTorch Foundation project. Um, and the key things that it brings is page detention which allows you to KV cache efficiently. Um, continuous batching which allows you to process a request as soon as it arrives rather than waiting for the next batch to begin. Fast kernels scale out through many different axes of parallelism,

[1:10:17] portability by running on any hardware um in any environment and then support broad support for hundreds of models both through dedicated implementations and the transformers modeling back end which you’ll hear more about imminently. And so then the transformers modeling back end um just again more context uh is what lets you take this transformers modeling code from hugging face transformers and run it directly in VLM. So the model definition the config and the weights all come from transformers

[1:10:48] and then the runtime and the all the performance critical modules come from VLM. So you kind of get a best of both. And so why might you end up using the transformers modeling back end? Well, there are three main reasons. One of them might be that you’re already using the transformers ecosystem. And so you don’t want to reimplement your model again for each inference engine that you might want to support. So through backends like this one for VLM and then also SG lang um you can take this code

[1:11:18] that you wrote once for your transformers training loop and run it straight in VLM or SG lang. uh you might be using it for RL in which case you would be using traditionally uh potentially transformers for your training and then for rollouts you would use VLM uh both with different modeling implementations because previously that was what you had to do. Uh but now with this you can use the same code for training and inference during your RL

[1:11:50] loops. uh meaning that there’s no potential drift in the two implementations and the the training should go a little better. And then finally, it might just be the only way that your model is supported in VLM. So today there are 14 architectures which only which are officially supported via the transformers modeling back end. Um and that list is only growing as time goes on. So now we start getting into the into the weeds and talking about how we get

[1:12:21] into the transformers modeling back end and what it does. Uh so obviously first we start with starting up a VLM engine. Um and here we have a whole load of uh command line arguments. One of them is to force the transformers modeling back end because for this uh quen 3VL model that we’re looking at uh there is a dedicated BLM implementation. So we have to tell BLLM that transformers is what we want. Um and then we’ve used a a not recommended but possible uh parallelism scheme where we’re using as many as we

[1:12:51] can across eight GPUs. We’ve got tensor pipeline data and expert parallel all at once. Um and then finally we’ve enabled torch compile on the multimodel encoder which not all um VLM models will do by default but because of the generality of the transformers modeling back end. If the transformers code uh has a compilable multimodel encoder you can just enable this flag and if your model works it should also work via VLM.

[1:13:23] So we first cross the boundary into transformers from VLM by looking into the config where we’re looking at what is this model, what shape is it and then any other features like what quantization scheme is it using and we then once we’ve chosen the transformers modeling back end had a look inside the config we need to choose which transformers modeling backend class to load our transformers model into. Uh and on the right you can see the selection of classes available. Um

[1:13:56] and the way that we select them is by looking into the config and establishing which characteristics the model has which will determine the correct class to use. So first they all start with transformers as you can see. Um and then we detect this one is multimodal because it has both a text and a vision config uh in that uh config JSON you saw on the previous slide. It’s because it has more than zero experts

[1:14:28] and then forcal lm is the default uh if your model is a causal model or if you don’t specify that you want to do a pooling task with your causal model. And so we choose the transformers multimodal for cos lm class. Uh and what are these classes made of? Because there were quite a lot of them and you’d think that if we didn’t do anything clever, we would end up with lots of duplicated code um and lots of drift and it would be really hard to maintain. Um but all of these are made

[1:14:59] of mixins which enable each individual uh capability. So for this one we first start with the MOE mixin which provides uh all of the necessary protocols for expert parallel and expert parallel load balancing. Then we have the multimodal mixin which handles all of the vision encoding the encoding the vision encoding caching um mrop if your model has it which this one does. Um and then merging the vision embeddings into the text embeddings

[1:15:30] before passing it over to transformers. Then the causal mixin which is for the lm head and the logics computation and then finally the base class which does most of the heavy lifting and all of the mixins actually now uh inherit this and it ends up at the bottom of the inheritance stack here. Um and that handles the the weight loading, the weight mapping, um all of the modifications that enable this to run quickly um just as fast as a BLM model would. Um and then there is a whole host

[1:16:02] of supports this supports that uh protocols for things like quantization, Laura, pipeline parallel, eagle and eagle 3. So now we’re going to look at how the transformers class is instantiated and what we do to it uh during instantiation. So it all looks a bit faint now, but that’s because it has not yet been instantiated. Um first we actually before doing any of that we register two attention shins with

[1:16:32] transformers attention registry. Um and that is the VLM attention and VLM MLA attention forward methods. Um then we patch the config so that when the forward pass of the transformers model happens uh one of those shims depending on which is correct for your model is what is actually selected rather than uh flash attention flex attention or or whichever other options the model uh claims that it can use.

[1:17:04] Then we decorate uh the language model always for torch compile from the LM’s perspective. Um, and then because of that command line argument I mentioned earlier, we also decorate the vision tower. Um, which tells VLM that you can compile both of these as whole graphs independently of each other before uh before torch compile gets a chance to kind of wing it and figure out on its own. And now we instantiate the model uh using the automodel from config

[1:17:36] method on the meta device. Um and for automodel is slightly different to um auto mode for cos lm which might be a class you’re more familiar with if you use the transformers ecosystem. Uh and the auto model just loads what transformers refers to as the base class which is just the language backbone and the vision tower but without the language modeling head.

[1:18:10] I might have to step back to the laptop. This appears to have stopped working. Um, then we create the HF to VLLM mapper which is how we specify how checkpoint weights might be translated into how they now look in the Python class that gets created. uh Transformers has a few of these uh built in if they have moved from an old style naive mixture of experts to a fused mixture of experts style. Um so at this stage this is a

[1:18:43] pretty minimal mapper but as we move through this process we’ll be contributing to it as we modify the model. So after that we then delete all of the layers that the current pipeline stage is not using. And in this example, we’re on rank zero. So we delete the second half of the layer stack and the final layer norm. And now we begin recursive replace which is where the bulk of the work happens to bring the performance and access to all

[1:19:14] the features that BLM has. Um fore models it happens in two passes because thee is a little bit special and there are two different ways which we can do it. Uh for this model it uses the internal routting method which means that we by using torch FX uh detect the structure of the sparsee block. Um and if we determine that it is entirely representable by VLM’s runner um then we replace it wholesale. So we replace the

[1:19:44] experts with this MOE runner. Um and that contains the rooted experts and then the routter gets replaced with a gate linear and that gets passed into the runner. Um and that handles everything. And so that lets us do uh things like use monolithic kernels for routing and experts. Uh if there were shared experts in this model, it would allow us to do asynchronous shared expert computation. Um and all of that is managed by thee runner.

[1:20:15] And then once that is done, we go to the second pass which is the base class doing a depth first search through all of the children of the base model. So first we walk through the vision model replacing all of the layers that we know how. Um

[1:20:55] to its features. So all of VLM’s parallelization is built into its layers. So by using VLM’s linear layers and VLM’s experts layers, that’s how we gain access to tensor parallel expert parallel etc. Then we do the vocab parallel embedding swap um by surgically replacing just the torch nn embeddings module. So if you have a model like Gemma where you do some scaling during your token embedding

[1:21:27] um that is all still preserved and we don’t have to special case it on the VLM side. Now the next fuser uh is used which is the QKV fuser which again uses um FX to detect the QKV and output projections um and swap in BLM’s QKV parallel linear and a corresponding row parallel linear um using a so so this is all it’s using torch FX to detect what we need to swap

[1:22:00] but then it’s using Python’s as module to actually make the modifications. So we are yet to torch compile anything and all of that is still left up to later stages in BLM. Then similarly we replace the RMS norm which is deceptively difficult for how simple uh it is but we do it because VLM uses um some global torch compile passes to detect where it can fuse layers and

[1:22:32] it does it by detecting its own modules. Um and so there are some um RMS norm passes or some compilation passes that the RMS norm is involved in that will only be detected if we’re using VLM’s class. Then we create VLM’s attention instances and as before this gives us access to the rest of VLM. Uh and the key thing that this gives us access to is VLM’s KB cache. Um so we don’t need to use any KB caching that has been implemented on

[1:23:03] transformers. Um, and VLM gets to do all of the clever stuff that it can do with the KB cache like offloading, um, disagregated prefill between nodes, um, KB cache reuse or all of that fun stuff. Then anything that we haven’t touched yet, we make sure that it is on the device. Uh, so the only thing that changed there was those two norms in the vision model. And then lastly, we just make sure that anything that Transformers insists should be in FP32

[1:23:34] stays in FP32 even if the rest of the model is FP8. So we’ve built the model um and now a request has been received. We have had it scheduled through VLN and we’ve reached the base classes forward method. Um and this is the first hop back into transformers. Uh so we simply call the forward method on the original Quen 3VLOE model class

[1:24:04] um and pass in the input ids or the input embeds um in this case it’s the inputs embeds because it’s a multimodal model and VLM pre-mbbeds the vision part uh of the prompt and inserts it into the text embeddings and passes that all in one go rather than relying on the model itself to to do that we explicitly disable transformers is um KV cache because VM owns it through those attention modules. Um and

[1:24:35] then we just forward through the position ids with a slight modification for MRO models um which happens in the multimodal mixin for this particular type of model. And so while we’re going through the forward pass of the transformers model, there are two seams where we return back to VLM um in kind of performance critical ways. Uh and so the first and most interesting one is the attention module. Um so on the transformers side,

[1:25:08] we’re starting again in the the transformers native class. It goes through its registry to choose which attention method to use which we pre-registered earlier as the VLM um attention shim and then selected it by modifying the config and then we enter that and transition back to VLM where VLM does some minor shape manipulation um gets the attention kernel to use which is any attention kernel supported

[1:25:38] by your device for this particular model in VLM it gets the KV cache using uh the attention context and then it actually calls the attention and passes the result back to transformers to continue with the rest of the model and the second is thee through internal routting. Um so as I mentioned thee has a special case where if we’re able to detect an entirely representable sparsee block then we can replace it entirely

[1:26:11] and actually the forward method that we use is just experts forward and everything happens inside that runner class. So we go straight into the VLM side. We gate the hidden states. We get the top K ids and logits. Perform the rooted experts for computation and pass the results back to transformers. And after this point the transformers model is done. It has provided all of

[1:26:43] the information about what the graph of the model is and all the computation for well and all the journey through the computation rather because as we saw the modules are all VLM modules um and then after that the logic computation and LM head evaluation is all done by VLM um and the sampling is also handled by VLM. So there are a few features that we haven’t used with this model that I want to talk about. The first is external

[1:27:14] routting. Uh so if your block isn’t the same as something that we’ve anticipated, uh that doesn’t mean that it won’t work. It just means that we will only replace the experts themselves. Um so that gives you the crucial performance because that’s where most of the work is done. Um, but it gives you the flexibility to do whatever you might come up with in the routing or anything around it. And there’s also shared experts, which I

[1:27:45] alluded to earlier. If they had existed and they were detected in the internal routing, they would also have been included in the MOE runner. And depending on your configuration of BLM, um, it would be computed in a way that is more efficient than could be done with external routting. Then there’s Laura and Eagle and Eagle 3, which we just didn’t touch on because these are kind of determined by the checkpoint you use and then the requests that you pass.

[1:28:17] Then there’s a a whole load of different attention flavors. So there’s encoder only attention which would be used by models like BERT or sliding window attention that you might find in Gemma models. Um and for encoder we support encoder only models um not no encoder decoder models but for sliding window attention it can be interled um similar to how they started doing it with Gemma where you would alternate between full and sliding attention. Um and then also

[1:28:49] MLA attention which comes through a separate um fuser and that actually gives us the KB cache compression benefits that we didn’t used to get when we used the we just used to pad to full attention when you loaded a a MLA attention model. Um and then finally pooling and classification tasks um which would have been automatically used had we used a uh a pooling model. Um or we could have

[1:29:20] manually selected it and BLM would have created a classification head using the uh the LM head or it could have given you back the the raw embeddings out the end of the model if that is what you were after. And so to recap, we looked into the config, determined which hugging face architecture it was and then which transformers modeling backend class we should use. Um we loaded it into this generic class in BLM

[1:29:52] and we manipulated it such that all of the advanced features of VLM became accessible. Um and all of the performance that comes with them came with them. Um then we went through the forward pass of the base model with two important seams um where we go back into VLM and do some non-trivial um work and then we pass back to VLM to do the logic computation and the sampling

[1:30:23] and that was my talk and the slides are available on the QR code there um if anyone wants to look at them again Thank you. [applause]

[1:30:59] Sorry. That’s what happens. All right, I think we’re on a break now. Thank you so much everybody. So, I think we were going to take a little break and we’re back in half an hour, I believe. All right, thank you so much.

[2:18:56] Hello, welcome back. All right, let’s get it for you guys. Okay. So um so far we have spoken about you know the AI economy like we talked about harnesses, software factories, we talked about generative media and all those tools are for you guys to build agents to build applications that use AI. Who who here built actually with AI? Okay. Yeah, most of you guys do, right?

[2:19:27] And the purpose of that is to create value to for people, right? Whatever agent you’re building, whatever tool you’re making, ultimately is to bring value to your users. Our next speaker is actually deep into uh the the the data and um she works at Stripe and what they see is that the entire economy is changing thanks to AI and uh she’s going to come to to tell us about and give us

[2:19:57] some insights about what Stripe uh what stripes data is revealing about AI. So without further ado, please join me in welcoming to the stage the head of product of AI and startups, Ariel Lubai.

[2:20:28] Hi everyone. Thank you. Thank you so much for being here. Um, I’m super happy to be here and I hope I will get some slides at some point on the screen. [laughter] Uh, can I get the slides in the please? Okay, perfect. Okay, let’s come back there. Okay, perfect. So yeah uh really

[2:20:59] happy to be here. Uh so at Stripe we work with the fastest AI growing companies. We we have this luck and many of them are actually in this room. So really happy to be here and we have a front seat of what’s working, what’s not and like how the best companies scale today in this new world of AI. So today I want to share some of those insights with you guys and you know have some thoughts on the playbook because this has been completely rewritten in the

[2:21:31] past few years and even months. So first like let’s start with uh figures sorry um first we are working with um 1.6% six% uh of uh of the GDP globally that is processed by Stripe and that is really something that puts us in that front row seat at the five patterns that we’re seeing. When the top AI companies build faster, I think this is something we’re all feeling. Two, they sell

[2:22:02] globally by default. When you’re building today, your day one market is now the whole world. Um, three, pricing is evolving completely. Like there are a lot of workshops on pricing today by the way because how you price has completely changed in the past few years. Um, and four they adapt their go to market motions as well. We have like channel sales that are becoming increasingly important. Uh, we’ll dig into that afterwards. And five, they monitor fraud

[2:22:33] early and often. Why? is like what’s creating potentially viral growth with agents is also creating just a whole new ground for fraud attacks for your business. So we’ll dig into it of course but first let’s look at like big picture what’s happening um in the world on that. Um we saw the top AI companies grow by 145% in 2025 which was already impressive but like in 26 this number

[2:23:05] grew by 195%. So tripling in a single year. Uh that growth isn’t slowing down it’s actually accelerating today. And the top ones that you know are even more mind-blowing of course like lovable they reported 100 million in eight months. uh eight months later they were actually at 400 million. Anthropic that you all know started in January 23 with zero and went to um to 1

[2:23:36] billion in in just two years and now they’re at 30 billion. So that’s just completely mind-blowing. And this isn’t just B2B like we saw this in in our link data like consumer adoption is also increasing a lot. like it doubled just from 6 million to over 14 million just in one year. Consumers are also spending more. What’s actually interesting is that they’re spending more on AI tools. Like today, we’re around like $360

[2:24:09] uh per person per month on AI, which is basically double what it was three months ago. It was around $180. And this is basically like basically what the average European spends for like phone service um uh internet and streaming services combined. Like people aren’t treating AI today like some streaming service that you can cancel uh but they’re treating that like a critical utility that they absolutely need.

[2:24:41] So what’s behind all this? We’re going to deep dive into these different patterns starting with speed. So just like you no longer need months of engineering to uh you know v code and accept the payments now you no longer uh need month of engineering to ship software. So what’s actually interesting is that this chart shows when it clicked. Like if you take a look at iOS app releases, they were actually declining at the end of uh 24 and then

[2:25:13] the agent codic tools hit. And so this is where we saw the iOS app launches just grow again and not like small grow by 24% month over month. And so now even like now that we embed payments into developer platforms like Lovable, Riplet, Versal, etc. Um it’s actually even faster to go from your idea to first charge like even faster.

[2:25:45] So what you can see here is that it’s actually taking less than six weeks from first idea and like sandbox to your first charge. Like only six weeks. That’s really crazy. And that strategy is faster for technical folks. So I I’ve played a bit with a prompt to show you how it looks like today to build with cloud and stripe. Uh because we’ve we’ve made a lot of work to make sure that we have an agentic developer experience that

[2:26:17] enables you to build without having uh to leave where you’re building and having to go on Stripe dashboard and and build stuff. So um let’s say you are a developer today and that you’ve built an app and now you’re ready to set to set up payments. So let’s jump into cloud and see what it looks like. So I have my prompt here where I’ve asked you know to set up payments. I want um invoicing and subscription and so

[2:26:48] yeah. Okay. So here you can see that Claude correctly recommends Stripe which is of course what we want and that they will be more powerful because they are connecting to Stripe MCP and the skills that we created with this. So Claude uses the Stripe integration recommener um MCP tool along with those skills uh to know what to use and what to ask to the user. So it’s basically asking like where are your customers located? The

[2:27:18] reason it’s asking is because like cloud knows now that they need to have this answer to provide the best recommendation for the integration. Um what’s interesting is that they recommend checkout which is a stripe integration and not like cloud element for example because it knows that um for for a better subscription integration we need checkout. So that’s again like showing that uh it knows the right thing.

[2:27:48] So then I responded like my customers are split between the US and the EU uh with a particular concentration in Ireland. So what’s interesting now is that I get feedback on the type of tax knowledge I need to have. So basically uh I need to know that digital subscriptions um are taxable here. And it’s actually interesting because it it recommends me to use stripe tax um because I don’t want to have to know all the regional tax rules for all the

[2:28:18] countries that I’m going to launch to. And so Stripe Tax is going to help me without uh without having to know those rules. Um I can see that it’s provisioning a Stripe sandbox for me. Um, what’s actually interesting is that you don’t have to, you know, go outside of the flow here to to get a sandbox. Um, the agent uses the new CLI command to create the sandbox without needing any stripe credentials, which was not the case

[2:28:49] before. Ed the command also fetches the API keys and securely stores them. And that way I basically don’t have to break my flow and I can build my integration like without having to to go away. And so with the key sorted I can see that now Claude is checking all the different skills um that we stripe provide to make sure that they’re um it’s building the right thing. So, it’s saying that it has everything

[2:29:20] it needs and it’s asking me like just do you want to proceed with MCP Stripe create product and and if I want to continue with that and create my checkout. So, I’m pressing yes here and we’re going to fast forward and try to see the checkout. Um, so this is what it looks like. Um I’m going to test if the checkout works properly and so yeah that’s how uh it would look like.

[2:29:51] Okay so it’s done like strap and claude are basically making it easy for you to for you and like all the developers to build set up payments and start monetizing without going away uh from your uh building interface. So what does this mean for you? Like many of you are probably already doing this but I want to reemphasize that you know in the playbook today it’s really important to obsess over developer productivity like the best

[2:30:23] companies today are really working on speed and just making sure that they completely collapse build times. Second like build, sell and iterate at the same time. the linear playbook that we had before like you build your product then you go find your customers isn’t just working anymore because of of the fact that too many people are building at the same time. So you basically need to do all three at the same time um in parallel.

[2:30:53] And then on the build build versus buy question, we’re actually quite convinced from what we’re seeing that the best companies do both like they built what’s making them differentiated and they actually also buy you know the infrastructure and building blocks that they need for their products. So two like getting to market is one thing but it is also a big question of like where am I going to sell and how am

[2:31:23] I going to get those customers abroad. So the data confirms it completely. Um a few years ago the fastest growing SAS companies were basically reaching 25 countries in year one and 51 by year three. Um and today the top AI companies they’re already at 42 countries in year one and at 120 countries in year three. So this is like what I was saying about like day one market is basically the

[2:31:54] whole world like it’s not about having a presence in in those countries. It’s actually getting revenue uh from these countries from day one. So Gamma is a great example. you probably know them. Like they’re based in SF. It’s an AI powered like slides and website builder. Um and they reported 100 million in revenue in year um in year one and the majority of their revenue comes from outside the US. So that’s definitely showing how um the the

[2:32:27] trend is going. And today if you take a look at overall like all the top AI companies 48% of their revenue comes from outside their home market. Like nearly half of a dollar that you get or a euro is actually from a foreign country. And this figure was actually 33% um a few months ago. So let’s take a look at which markets are actually spending a lot on AI tools.

[2:32:58] Um so not surprisingly we can see that the countries with the high GDP growth are here. So you can see France, the UK, South Korea. Um but we also have like new emerging uh countries that are spending a lot on AI. So for example, Switzerland, Poland, Turkey and the demand is there. So now um as you’re building your company, you need to think about like how am I going to get that demand? how am I going to get those customers?

[2:33:29] And like what we’re saying what we’re seeing is that you really need to meet buyers expectations and meet them where they are. So the way we’re doing this is that you offer local currencies and local payment methods. That sounds easy and that is actually easy uh to do with St. But like basically it’s really meeting them where they are and with their habits. So localized pricing for example its own sounds like completely simple but basically it increases 18%

[2:34:02] higher crossber revenue like it’s crazy the impact that it has. Uh and basically when you add one just one local payment method for a country you have at least 7% conversion uplift uh in this country. So, three checks to pressure test your global readiness as an AI company today. First, you localize your prices and your payment methods. Two, automate tax collection because like no one wants to get in trouble

[2:34:34] either. And three, track performance by country like performance um conversion and obsess over optimizing those. So now pricing um because the old models are are not working anymore. Uh now we have to think about like new pricing models. The interesting thing is that like value is elastic. You probably know that if you’ve taken a look a bit at pricing and so everyone might be using the same AI

[2:35:05] tool, but they might not using the same way. Um, so take two users. One is an engineer. They’re going to bed. Next day they’re having a code review. Um, and the output is really engineering output. The other user is just an everyday user. They replace uh Safari but GPT and the output is just an upgraded search experience. So for this like the cost is not the same, the value is not the same and so

[2:35:36] the pricing should definitely not be the same. So this change in value isn’t new. We had this with all the technology shifts that happened like for example we had local host hosting at a time. So it was normal to download the software for a yearly license. Then cloud computing arrived and so we had auto updates of softwares. So it was actually uh normal to move to subscriptions and today like what do we have with AI

[2:36:09] so that’s basically where you’d expect me to tell you what the the the best answer is. Um so good news bad news bad news first we it’s still early like we don’t have a gold standard of what all companies are doing and it is absolutely the best but good news is that we’re clearly seeing um emerging a pattern um take for example poke to our MC today

[2:36:40] um a developer tools company that you probably know that’s been around for around a decade basically and when AI tools arrived they pivoted their product they started adding AI um AI tools AI features in the product and they also started to adapt the pricing like layering credits etc. So they started with flat subscriptions which is how you stick and create the relationship with the user and then added credits as AI

[2:37:12] became core to the value of the product. So the result is that today they’re targeting 1 billion ARR uh this year and they’re not the only ones to do this. This is just one of the examples of what we can see. So today we have like two out of three companies of the Forbes AI50 um listing that are using usage based pricing. So a majority of these companies are actually using a hybrid

[2:37:43] model. They’re using subscriptions still for the the stickiness of the relationship, but they’re adding a lot of usage based pricing to make sure that the value is actually reflected in the pricing. So it’s good to know that you have to do some form of usage based pricing but getting it right is actually another story. So in our view there are three things you need to do to add uh to your playbook for pricing.

[2:38:14] First price in your customers language like developer think in tokens enterprises most of the time think in seats like you have to think about these uh like who are your customers and make sure that you match their pricing with the way that they experience value in your product. Second, you want to show like as close as real-time visibility on what they’re consuming because like you know this is this is not a nice to have and this is

[2:38:45] basically how you prevent churn as a company. Like this means finding ways to make sure they’re seeing real time what they’re consuming. And three, we really see that it’s it’s strong to sell credits and not costs because like at one point your customers will exchange money for credits, but then the way they will interact with your products will not be with like each euro or each cent. It will be with credits and it will be related to value mostly, not costs.

[2:39:18] So now we’re going into go to market motions changing uh which is also a big part even if like a lot of people are actually taking that bit of the side um but that’s actually a big motion changing as well. Um actually entirely new motions are emerging. You might have seen that and the biggest one is channel sales like it means where your product is going to be to be sold and how. And like today in the AI go to market motion

[2:39:49] for example a lot of um companies are actually buying open AI or anthropic via their cloud provider. So you need to think about these different channel sales that are arriving and a lot of AI companies are actually building their own marketplaces where you are going to be able to be a reference and to be to be bought as well. And of course like the billion or maybe trillion dollar question like how do you sell your products to your newest buyer

[2:40:21] which is you know the agent like we’ve spent decades thinking about what is the best way you know human psychology I will price my product 999 and not€10 but like agents absolutely don’t care about any of this and today I think this chart is one of the clearest signal of like I need to think about my agent as a buyer because like for example this is trade docks uh so our public documentation the pink

[2:40:52] line is uh how it’s read by agent and the purple line is by humans and as you can see like this very summer in 26 we had the two lines crossed which means that our public documentation today is more read by agents than by humans. So we we live it every day at ripe like we have to think about okay how is my product how is my documentation read and understood by agents. So you have to

[2:41:22] change the way you you do things. You have to change the way you are going to showcase your products and make them discoverable by agents. And go to market is like the tip of the iceberg because if you think about like changing uh channel motions then you also think about like adapting your product to that making sure that your onboarding is going to reflect that new uh onboarding motion. Pricing and revenue of course is going to have to reflect that as well your organization.

[2:41:54] Um so for example if you have enterprise sales you are going to have to adapt this to the new uh new go to mac and motions as well. So this is how I would think about the playbook. Like basically today the products are channel agnostic and the customers themselves are channel agnostic. They don’t really care about where they buy. So they may be self-s served at some at some point graduate to enterprise and then like have an agent implement a new product. So you need to

[2:42:25] think about all of this journey uh for your product. So have a clear graduation project pro progress from productled growth to salesled growth. Uh then make sure that you have unified system you have like one product catalog that you have one customer object um one data model and that you don’t go away in all directions. And third, like as I was saying, please design for agent readiness. Like make

[2:42:56] sure that your product is ready to be discovered and bought by agents without a human in the loop. Okay. So last pattern, fraud. Um this is actually something very important that you need to think about. Monitor fraud um and risk like early and often. So what makes it hard basically is that like it doesn’t show up in one place like at all at all time of your product life cycle they’re going to be a potential for an attack. So if you think

[2:43:29] about account creation, payment method added, payment processing and then after that like post usage all of these places are potential um places for fraud. So let’s take first like sign up top of the funnel. The thing is, you’re going to have someone that like a bad actor that signs up again and again, and so they’re basically just stealing all of your user credits um at at once. One in six signups, to give you an idea,

[2:44:01] today uh involves multi- accounts abuse. So, they’re basically farming you free trial um without your evering a dollar from them. And the problem also is that JI today has made it very hard to, you know, find fake accounts because they actually look real. And what’s interesting is that multi- account abuse is often like exactly how free trial um abuse happens at scale. So

[2:44:32] you can see that it increases dramatically like this is how it accelerated in the straight network. So you can see that in 2026 we have this crazy increase of free trial views because like if you’re having success like you’re actually also an attractive target on the internet. Um what’s good news though is that it’s a solvable problem. Like just as you can see an exponential growth of the attacks, you can also see a very strong

[2:45:04] and steep decline of the attacks if you have the right uh solution. Like just in four months we blocked like three million attacks like this for free trial. So that’s definitely part of top of mind for us. And then like of course there’s another vector you you might be familiar with pay as you go pricing. So pay as you go abuse goes with that. So what happens is that a consumer would basically consume let’s say a thou a

[2:45:36] thousand or thousands of dollars of tokens in a month and then at the end you try to get the money and the card is just invalid. So it’s kind of like you know Michelin start like we say in French uh but for tokens right. So by the time you know the compute is gone and you can’t charge anything to that user. So pay as you go is an amazing tool for pricing but you have to think about how to manage fraud in that case. So the companies handling

[2:46:06] that well are monitoring usage signals in real time and make sure that they see all the different signals uh and and avoid that from happening. Okay. So what do you do about this like three things again? uh please monitor this at every stage of the life cycle from account creation to post usage. Um so defend all of this for your customers. Then I would recommend to close the gap between usage and billing. Like you don’t want to wait a

[2:46:38] month to bill. You want to make sure that you close that gap as much as possible. And then like please build fraud into your launch plan. like it’s not necessarily the best or more most exciting part about building but that’s actually incredibly important like at every step of your product you need to think about okay if I am a back actor now and that I want to take advantage what does the attack looks like and so in my view if you haven’t thought about this or you don’t have the answer yet

[2:47:09] like you’re not ready to ship it so the playbook is being rewritten We all know that. But like how you build, how you go global, how you price, how you adapt your go to market motions and how you manage fraud, that’s what’s changed. Not just the tools, but actually the whole starting line of building a company. And you you know that you can build in hours, you can be present in 42 countries on day one. As we can see, you

[2:47:41] can price for value. Um, so that’s actually in our view, you know, the funniest and maybe craziest time of like building uh for for building a company in the world. Um, so we we hope that these insights give you some some idea of like how to build this and yeah, like our job at Stripe is to be there with you to help you scale. So um I’m really excited to see what you build. Uh and just please know that we are there if you need to scale as well. and drop me a

[2:48:12] message if you want to chat more. Thank you. [applause] >> All right. Thank you, Ariel. Let’s give it up for Ariel once again, please. [applause] All right. Okay. I think what uh the fact that um or the information the piece of information that uh stayed with me through this presentation is that you need to design for humans but you also need to design your products for agents because they might you know be purchasing your products as well which is I think is awesome. Um I asked

[2:48:45] earlier a question. I said how many people are builders here? And many of you raised their hands, right? Like yeah, most of you are builders, right? Like you’re building products. Um and you’re uh maybe chatting with agents. Um my personal experience is that I kind of stopped uh typing to my agent. Um so I only chat mostly with voice and I find it like a a more natural way to interact with agent. I read faster than I than I hear. But I also I I talk a lot faster than I than I than I type. Uh I don’t

[2:49:17] know if anybody shares that experience here. Who talks to their agent? Yeah. Okay. So it’s a actually a good number. Well, our next speaker is here to talk to us actually about voice AI and real time. Um so without further ado, please join me in welcoming to the stage chief scientist and co-founder of Piano AI, Erve Ba.

[2:50:01] Okay, let me try this thing. Yeah, it’s working. Um, hi everyone. Uh, thank you Rau for the introduction. Uh uh it’s the first time I’ve been ever announced on a stage by an MC. I feel like a bit like Celindio in Paris uh tonight uh or today at least. Don’t worry, I won’t sing anything but I will talk to you about Voice AI and in particular about uh speaker dization. Um so uh quick

[2:50:32] introduction about myself. So I’m the co-founder and chief science officer at Pianoai. I’ve been an academic researcher most of my career up until two years ago when we uh created this company and um so yeah I’ve been mostly focusing on speakerization for the last 15 years and uh it looks like people think that uh uh I know a few things about speakerization and I hope today that uh I’ll tell you what speakerization here is and that you’ll

[2:51:02] learn a bit about how that works and uh yeah that at least you you take something out of this talk. So what is speakerization? So speakerization u basically uh is the task of taking a recording of a conversation between multiple speakers uh and outputting some metadata about it. What you can do starting from a conversation is basically do voice activity detection first where you would uh detect uh the parts where uh someone

[2:51:33] is speaking and when nobody’s speaking. That’s voice activity detection. The second step that you can do on top of that is uh splitting those uh very long uh speech turn regions into uh single speaker regions. Uh that’s this task is called segmentation. So it includes both uh speaker change detection as well as overlapping speech detection. So in this example here uh in in the middle you see that there are it looks like there might be uh u at least two speakers because uh

[2:52:03] there’s a uh someone interrupting um uh another one or starting speaking after the end of the another speech turn and a bit later in the conversation there is a very small speech turn that overlap with the other one. This these are usually what we call back channels like mhm okay yes that you say when you are nodding at someone uh uh talking to you and those events are very important to uh uh for voice AI agents to uh basically understand really the core of the conversation the words are usually not enough knowing that when someone is

[2:52:35] interrupting someone else or nodding at what they are saying it gives a lot more information about the the conversation and the next step really what we call speakerization is then once the the conversation is segmented into speech turn is to actually assign each speech turn to the right speaker and this is done without knowing in advance the number of speakers. So that makes the task more difficult than usual uh supervised machine learning task and we don’t know the identity as well of the speaker. We have to uh basically

[2:53:06] generalize to any speaker even those that are not part of any training sets. So that’s what makes speakerization difficult and so there are many tasks uh where speakerization can be useful uh and lots of those task can fall actually under the knowing who said what is just as important as what was said. So for instance uh for video dubbing application when you want to start from a a video in French for instance and you

[2:53:36] want uh basically to put it on the internet and reach a larger audience an international audience uh then you can do use video dubbing uh tools to uh basically translate from French to other languages and making sure that the you know the conversation remains natural. So you have to put the right uh uh speaker clone uh voice to on the right speaker and for that you need to know exactly who speaks when in the original audio. Other task uh obvious task are meeting note takers uh especially in

[2:54:07] hybrid meetings where uh some people are joining from the same meeting room. when there are multiple streams, speakerization not necessarily uh is useful, but when people are in the same room, that’s where it’s it’s really useful. And this allows to to make some nice uh uh summaries of the conversation of who’s supposed to do what after the meeting, for instance. And other applications like podcast intelligence where you want to track one particular speaker in multiple podcasts or track the host of a podcast across episodes.

[2:54:38] And um so we have this uh open source toolkit called uh piano to audio uh that uh allows you actually to get from raw audio recording to uh uh an actual speaker deration. So it’s it’s become very popular over the years. Uh I have some vanity metrics here uh uh thanks to our friends at hugging face. It’s also very visible there. Uh it has uh on average 10 million downloads every every month. And basically in a few lines of code you can get from the audio to the

[2:55:09] actual speakerization. So here in this example we start for the first block of the code as basically downloading uh the community one model the open source community one model from hugging phase. You get this uh object called community one here in the P Python code and then you simply apply uh this uh uh pipeline on a recording of a conversation and you get the prediction that you can then iterate over to know exactly start time, end time and the actual speaker time and this really uh in in three lines of

[2:55:39] code. Um yeah so this uh that I described was batch in the sense that uh the whole processing happened after the conversation took place. So why uh go real time? So there are many uh reasons why we we would want to go real time. Uh for voice agent it’s not that obvious because usually there’s one person talking on an or to an agent and uh you you don’t really care about uh speakerization because there’s only one speaker. But very soon

[2:56:11] and it’s already there actually the agent will listen to to the conversation while we’re having a meeting for instance and to a use case would be to flag some speakers interrupting another speaker too often or to flag a speaker talking too much. Uh and doing that in real time is is necessary. And uh the next step is also that we soon are going to have robots in our house. And uh to basically answer to uh a child or to the adult in the in the household, you would uh basically need

[2:56:43] to know who’s who. And this is really where uh real time voice darization speakerization is useful. So now that we know that it’s actually useful, how uh did we at PenAI uh manage to go real time? Uh I need first to take a step back to explain how the batch speakerization that I just described earlier in three lines of code called community one works internally. So uh I’m going to spend some time on this slide a bit more. So um basically

[2:57:15] given a let’s say a 1 hour conversation uh a recording of a 1 hour conversation how it works how community one works today is we start by splitting the conversation into pieces let’s say 20 seconds or 30 seconds pieces. So each uh green rectangle here in in this slide uh actually uh represent 30 seconds of speech let’s say you see that they are overlapping a bit. So we we move that in a in a sliding uh manner uh uh in a sliding window manner and then we apply the first uh neural

[2:57:46] network that basically performs uh speakerization on each chunk separately. So why do we do that? Why why do we uh process the conversation pieces by pieces rather than uh trying to do that globally? It’s because uh working on chunks allows to uh have a limited number of speakers as output. So the the the machine learning task is actually easier and safer to to solve like that. So basically the model is trained to take 30 seconds of audio as input and returns uh basically a matrix of let’s

[2:58:18] say uh the time and the number of speakers uh and um it will output zero and once whether each speaker is active over time. And the problem with this kind of a first approach is that at that point uh the same speaker on the first chunk might have a different uh label on the same for the in a different chunk. So we need to rely on a second step uh where each speaker in each chunk here represented by symbols the triangles the circles and the stars are projected into

[2:58:51] a highdimensional space using speaker embeddings. I’m pretty sure you’re all familiar with what embeddings are, but basically those are uh highdimensional representation of a thing. Here the thing is a speech turn. So each speech turn is uh projected in into the space. Uh here it’s represented as 3D but in practice it’s uh Oops. Uh in practice it’s um it’s coming back. Is it? It is. I should probably stay here. Um and uh this

[2:59:25] speakering model, it’s a neural network as well. It’s trained to have two uh speech turns of the same speaker close to each other and two speech turns from two different speakers far away from each other. And this way we can actually find uh clusters in this space. And this is how basically we managed to reconcile all the uh the chunks finally and be able to basically stitch uh uh all those small speech turn together and and get the final results. So that’s the starting point of um um of speaker

[2:59:58] dization in a batch manner. So the question is how did we get from uh this uh batch diorization to an actual uh realtime implementation. So the first thing that we uh worked on is basically the clustering part that I just mentioned and instead of having it uh global having it incremental. So uh this uh um animation will will say it all. So uh so basically starting with a conversation uh between two speakers here in batch dorization we start by

[3:00:31] extracting speaker embeddings from all those speech turns. So you get them all those points are actually speaker embeddings and you simply do uh clustering uh into that. But if you turn to streaming you don’t have access to the future because the conversation did not happen yet. So the idea is that uh the clustering algorithm needs to work incrementally and that makes its job way harder because you only have a limited view of the conversation. So uh you see here uh this is a fake example but it takes some time for the clustering

[3:01:01] algorithm to realize that there is actually two speakers and that’s why it makes um you know switching from batch to real time quite difficult if we if we were to stay with the you know chunk wise approach that I just mentioned. it still managed in the end uh to find the right clustering but you saw that during uh the actual uh conversation it made some mistakes and so with this kind of approach uh this is actually implemented in the dieart open source toolkit which is uh a

[3:01:34] creation of our CTO Juan Manuel Ka and we managed to uh basically get slightly uh higher diorization error rate uh at around 5-second latency because the chunks are around 5 seconds long or at least the steps between the chunks are 5 seconds. So we said okay uh that’s great but the next step would be to manage to lower this diation error rate at least to be as good as a batch speaker derization and also this 5-second latency might be

[3:02:05] a bit too much. So um what we worked on next is basically uh turning this uh chunk wise segmentation into something a bit more streaming that we call causal segmentation where instead of waiting for the whole chunk to be available to process it basically pro processing in in streaming. So that that brings uh a lot more uh of other difficulties. So uh let’s focus for instance on speaker chain detection uh in batch mode. uh what we you we

[3:02:35] usually have access to the whole conversation. So speaker chain detection can be done like that. You slide a window uh around the course of the conversation. You compare what happens to the left of the the segment and to the right and you compute the difference and you get some nice peak where there is a speaker change. But in streaming uh the problem is that you don’t have access to the future. So it takes some time for the model to actually reach uh you know confidence enough uh to um enough confidence to basically take a decision and this uh small amount of

[3:03:05] time uh that it needs in the future to to decide whether there was a speaker change or not. We call that the look ahead and that’s basically a a a latency that we can’t get rid of because if we at one particular point of time in the conversation you need to decide whether there is a speaker change uh unless you have a very strong modeling of the pro or something like that. You really have to wait whether someone else is starting speaking to to actually take the decision. So that brings this uh

[3:03:37] incompressible uh latency that is added to the to the thing. And uh so we we went ahead and uh and implemented that and we uh with with basically lots of research on the on the research team on this particular segmentation streaming model uh we managed to actually using much larger model than the chunk wise one and also some uh some uh implementation of loss function. I won’t go into the detail.

[3:04:07] I’m happy to discuss that after that. But we managed to basically reach the same level of accuracy as the batch speaker deration with a a very low latency of 400 milliseconds. And this 400 milliseconds actually um involves many things. It it involves also uh round trip from uh uh the client to the servers and back. So I’d like to spend some time on the actual 40 400 millconds latency. So what’s in those 400 millisecond latency?

[3:04:38] So um we start by a client uh having a conversation locally. The the first latency that you get is basically that the conversation is split into 100 millisecond blocks. So you already have to wait 100 millisecond. Uh let’s say at time t you have to wait 100 milliseconds to build this block. So already at time t we already have 100 millcond latency. This latency that I put here uh is part of the 400 millisecond latency and it’s not something that is often uh counted

[3:05:10] in the numbers that you can see here and there. But it’s actually also something uh that is important to take into account. Then uh the next step basically is we are relying on the Cloudflare um durable object uh uh technology to basically send this block size to the uh closest uh Cloudflare server. So this on average takes 20 millisecond but it really depends on where the client is and uh how good cloudflare is basically. Um and

[3:05:40] on this server what we do is we receive many streams and we batch them. So we batch lots of 100 millisecond blocks so that uh we can process multiple streams in parallel. So this is very fast and then once we’ve uh built those batches we send them to model where uh the GPU horsework lives. So basically for segmenting those 100 millisecond latency uh a batch size let’s say of 32 32 streams let’s say that’s just an example here but it takes

[3:06:11] around uh 50 milliseconds just for the inference and also you have to take into account this 200 milliseconds look ahead that I mentioned earlier. So basically when you reach time t what the model the neural network does it predicts what happened 200 milliseconds in the past. So this is uh this adds up and then in parallel uh we we find this trick of actually running the embedding extraction and the clustering in a totally async manner. So this does not delay the prediction whatsoever. So

[3:06:42] that’s why I I put it uh zero millisecond here and then we do the the run trip back uh so five more milliseconds here. Then uh we basically uh using the state that is stored in the in the cloudfare we basically stitch the pieces together and ser serialize it to send it to the client. So in total you get those f four u uh 400 uh milliseconds latency and if we go into more details so

[3:07:12] basically there are just not just one latency basically there are many latencies here. There is the network latency that basically really depends on the client how close uh the client is to the networks how fast their connection is. So that accounts for like 50 millconds on average but this can be moving parts. Uh then there’s the um uh inference latency that I mentioned the 50 millisecond. So same uh this inference latency you can tweak it a

[3:07:44] bit. Obviously if you make a a higher batch a larger batch it will take more time but then uh your cost will be lower because you can process more [snorts] streams uh with the same u with the same GPU but if you want to be faster then you have to uh lower uh the the b the batch size and uh uh your cost will go up. So really this inference latency this is where you control a cost uh latency trade-off and then there is this algorithmic latency that takes basically

[3:08:15] most of the uh uh the latency here and same uh it controls a new trade-off. This is a trade-off between accuracy and latency. The more you can uh wait in this look ahead the better the prediction you can make. So this is really uh like a as I say a a trade-off between the two and an easy way for to to to reduce the latency would be to reduce the block size obviously uh here it’s 100 millisecond but that has repercussion on basically the inference latency because you get way more blocks

[3:08:48] that you need to process and uh so um yeah that makes the the the whole uh trade-off a bit more difficult to uh to achieve. Uh so um yeah now I’ve now reached the point where I think it would be good to make a a demo. So uh I’m going to ask my co-founder Vanson to to join uh stage just so that we have a chat quickly and you can take a mic here and uh I’ll switch uh to a demo so that you you get really what 400 millconds really means in practice. Um so just about the setup

[3:09:22] uh even though we have two microphones here it’s really my laptop that captures uh uh that captures the uh the conversation. So um >> so you you’re reing the tricks you see everything. >> Yeah. >> Hi everyone. Nice to meet you. >> Uh so how did my talk go? >> Quite good. I hope you share and people have been learning things about what we do. I’m always amazed how difficult it is. It sounds easy when you use it but uh >> yeah but we can even uh do overlapping speed. Absolutely. That’s what we usually do. >> 20% of the speech usually is

[3:09:52] overlapping, which is kind of crazy to detect. >> Yeah, he keeps interpreting me in every meeting we have. It’s an ideal effect. >> For some reason, Ralph says something in the in in the backside because we found speaker 02 here. >> Please don’t back channel, please, Raul. [laughter] >> Okay. Uh I leave you there. Thanks. >> H So, so you you get the idea of what uh basically 400 millconds feels like. And uh yeah, so I’m I I’ve reached uh almost the end of my talk. I would like I hope you you you learned a few things in this uh in this talk. And uh at least the

[3:10:25] three things that are I think interesting you’ll tell me about this talk is that uh I I try to convince you that uh batch and real time derization are actually two different machine learning problems. They have very different constraints. Even though the input and the output are the same uh solving it uh uh needs different approaches. Uh wanted to highlight as well that latency is just not one number. It really depends on many things. I mean you all all knew about that but in particular that for speakerization you see that the main latency is coming from

[3:10:56] the algorithmic part because because of the way this speakerization task is uh is set up and uh yeah very proud of the work that uh the research and tech team did for to to handle this and uh yeah there are many ways of trading uh between latency accuracy and cost and uh yeah so uh thank you very much that’s the end of my talk And um yeah, happy to have a chat after if if you want. [applause]

[3:11:27] Thank you. Thank you so much, Alve. Let’s give it up one more time for Alve, please. Nice. [applause] All right. Okay. So, this is a good moment because this is this was the last talk of this morning. Okay. Uh so, please uh you can go to the expo. We have a launch that is uh being sponsored by Sierra. So, shout out for to Sierra, please. [applause] Yeah, thank you for offering us some fuel, you know, to uh to to get going with this uh with with this event and to come back stronger in

[3:11:58] the afternoon because we still have so many things to talk about. We’re going to be back here at 2 p.m. We’re going to have a fireside chat between Mistrol and Nvidia. You should not miss this at all. Uh so, I’ll see you here at 2 p.m. All right, enjoy your lunch.

[4:50:11] Ladies and gentlemen, Please join me in welcoming to the stage your MC for the AI engineer Paris 2026, developer [music] relations engineer at Replet, Raul Chevrey. >> All right, and we’re back. Okay. Well, congratulations to to to us all, right? You guys are making it for the final stretch of today’s conference, day two of AI engineering Paris. Thank

[4:50:43] you so much for coming back here. Uh we actually have a great great panel that we’re going to uh we’re going to start in a second. But how are you feeling? >> Yeah. No, no. Okay. You you know the drill by now. Come on. We’ve been doing it since yesterday. So, we got to bring up the energy. Okay. So uh we have two gentlemen here that um are going to come uh on stage. So please I would like you to uh join me in welcoming to the stage uh VP of compute at Mistral Yan Leger

[4:51:15] and also uh senior manager solution architect at Nvidia Adolf Hall. So please let’s give it up for them. [applause] All right. And I kind of forgot to say that. Um, yeah, we’re going to be addressing like building the infrastructure behind the next generation of AI. So, we’re going to have like a little bit of a futuristic

[4:51:46] view of uh what what’s needed and uh to to build the next generation of u of AI. So, thank you so much for being here, Adolf uh Yan. Um Jan, you were here last year at AI engineer. Do you remember? It feels like it’s been uh 10 years ago. >> Kind of a big year went by like our company was acquired in between. >> A lot has happened. >> Organizing like this conference together last year. Um and now we’re making it again.

[4:52:16] >> Yeah, exactly. But it really feels like Yeah. One year in a in AI time. It’s uh feels like ages ago. >> I wish I would have been here as well. >> Yeah. you invited next year. [laughter] >> Yeah, that’s nice. So, Jan, when you were here, you were here on stage, you were talking about building for the future of agentic era. So, can you can you walk us through what do you think has changed in in the like in the interim? >> Yeah, I think like over the last two years I I’ve uh spoke about

[4:52:49] infrastructure for AI. I mean, and over actually like the more more than this now. um last year was specifically a focus on sandboxes and how basically it’s creating a new category of infrastructure. Um and um we’re seeing it in action now. I think that’s what happened like the the one year we were in the beginning of this like motion of the agentic era and like uh the adoption kicking off uh and now um a

[4:53:21] lot of the software uh is written by agents uh and we have a huge penetration of the agentic workflows overall. Um the but the GPUs are still like the the essence uh after all like I mean like we we have in addition to the GPU infrastructure we have CPUs which play into the mix now. Um that’s a key difference before between um the previous years and and now I think um so we’re still going in the same direction

[4:53:52] like training large models it didn’t stop uh at ML was still training like state-of-the-art uh models on one side uh we’re doing large scale inferencing and the agent in KA is actually like kicking off even more the inference consumptions uh I think and which means the stack is even more complex. than before. >> So you’re saying yeah we were you were talking about send boxes and you’ve seen the rise of that type of instru infrastructure. So you’re seeing like

[4:54:23] the progress in the load and I I think there’s no doubt in this in this new world. What do you think um is standing between us and the next generation of AI from a hardware perspective and from Nvidia’s

[4:54:53] perspective >> when you are longer in this business and then you used to speak with compute with networking and storage and actually since this agentic workload is so dominant well where where where is it going to uh be executed and um I think often these days in this equation it’s forgotten where does the agenda workload go and that’s a CPU question um and um that is um that is I would say pretty

[4:55:23] obvious if we speak in um model development so we have certain established architectures they have particular needs which drives basically the how the infrastructure and the the chips are designed for the for the next innovation cycle and uh they are certainly um it’s influenced by mixture of experts um and with its unique unique demands um of uh of communication. If we look into new modalities, I would say um we have I think the society and the

[4:55:55] industry has made very good use of data. We I think we we we trained on every book in the world. We likely we soon train on every movie and every multimodel. But that’s not the end of the uh the game. I think there are other things uh um coming um which need to be tried out from uh um let’s say if if we go into this robotic domain um it needs to have feedback. So giving this feedback is a question of uh of simulation. So I think that would that

[4:56:26] will pose new challenges. So we’re not there with it’s a very exciting uh journey. So I I just want to yeah double click on something you mentioned mixer of experts and it’s just a way for us to have very very large models but who can be efficiently uh being used at inference time right >> yes >> okay um all right okay um if gentlemen if you’d like to follow me I would like to talk a little bit about silicon hardware

[4:56:56] um and um so yeah we know about Reuben the the latest generation of in leaderships and it’s now in full production, right? Um so yeah, some of the claims are are like that Reuben is 10 times um more efficient and it’s uh yeah, four times fewer GPUs also. So as uh as AI is evolving like we’re getting more efficient systems um yeah to train a model of experts. So how should teams

[4:57:29] you know how should these engineers be building AI products thinking about the next generation of architecture given this cadence and this scale >> I would say try to follow as best because we on a the entire industry I would say is on a on a learning cycle so when I when I joined Nvidia there was an architecture called uh Pascal and Voltaar maybe you don’t know about that one but uh um if uh if we talk about data center economics and efficiency

[4:57:59] what you also stress with uh more more tokens cheaper tokens etc. Then um we started a technological path uh in that generation and that is now uh seven or eight years ago and that continues. So um we need to work with that and the software follows these paradigms. So software and hardware goes hand in hand and uh in order to be of use you want to use it by means of the software and uh um so there are some dependencies when you say I want to uh make use of the

[4:58:29] latest innovation for someone who um provides inference at scale obviously those are economic arguments and they need to be leveraged uh at best overall um we need to optimize um all layers of the of the stack. Um what we see recently is that uh um we used to think in in infrastructure for trading and inference and I would say that is that is going a bit more together also for an economic reason because uh um if you if

[4:59:00] you make a pool it’s it’s static so in each pool you have some some waste >> and uh so that is that is I I think something which is uh uh go away and the the infrastructures for both domains um I expect um goes more together hand in hand. >> Interesting. Okay. >> Yeah, I do agree with with it all on like the the use the usage on on of the inference like there is actually two

[4:59:30] kind of I mean in the past if you look at some of the talks I I did like two years ago I was already speaking about different kind of infrastructure for different purpose. um you leverage like uh training clusters don’t have the the same uh physical requirements. Uh they need the highest performance uh on the training side. Um and inference are workloads are a bit more tolerant. So they don’t necessarily need the latest generation of hardware. Um and we see this um in practice where for training

[5:00:03] we might use the latest generation of hardware. For inference, we can use older generation of hardware. Um, which also means that like um when we design infrastructure uh on the physical side, we need to u keep in mind that like the usage on this kind of infrastructure is going to evolve over the time. uh you might like deploy a cluster uh typically and get the two first years used for one purpose and the three four year years

[5:00:33] used for another purpose as Adolf mentioned like in terms of flexibility and ideally you can even go be more dynamic and and get your uh training workloads to be uh your training infrastructure to be reused dynamically for inference and so this is something which is a lot of software at the end in terms of orchestration to be able to reallocate dynamically the walkers. >> Okay, very interesting. So, we’ll need eventually two different types of infrastructure for um for inference and

[5:01:06] for training down the line if I understand it correctly because the needs are different because we don’t need necessarily the latest type of hardware. So we I mean we actually were more converging maybe I mean we have specialized inference in infrastructure on one hand which uh if you build it like just for inference uh you can like tolerate like having not the latest generation of hardware it also depends on the kind of models you’re training like models now are as we know are old

[5:01:36] of um different sizes and shapes. If you uh train a 1 trillion parameter model, it’s not the same as like an 8 billion billion parameter model, right? You don’t need the same training infrastructure in both cases. Um and actually we’re more I think like converging on the long term in a way. I mean on having a global pool that we reallocate uh between the kind of trainings uh and inferencing. >> Okay. Interesting. Um okay. So the next question is to for you Adolf. Um, I’m

[5:02:08] going to talk about uh NVL72, but before I I dive into that, can you please explain what NVL72 is to the audience maybe who are not familiar with? >> In case you’re not familiar, um, AI is in the meantime, when let’s put it this way, when I started, my entry cost to AI was, I think, $150 with a GPU, I had the workbench, I could participate. Now, everything grew. Um, fascinating speed. So uh I would say that the smallest problem what Mistral has I think it’s it’s it’s not going to

[5:02:41] fit on a single server anymore and uh um so at the same time uh the hardware pays attention to what is requested by the software and so uh multiple components need to work together in a most um economic and efficient way. Efficient means communication needs to be very very fast. And for that purpose um we designed NVL72 which is a a system in Iraq. And u um the the difference to a classic system is um that NVL72 is an

[5:03:14] interconnect between them much closer than than anything of TCP IP. And this is uh necessary if you want to run the modern workloads. Um well and uh um I would say it’s the most economic way to address uh highly parallel uh trainings at this point. >> Okay. So yeah. So uh Nv72 is is a rack system and um so yeah, what does that mean for the rest of the stack? Does it mean that uh

[5:03:44] yeah, we’re headed towards the rack being like the new server? >> Well, there’s a saying from Nvidia that the data center is the computer. So but uh thinking even bigger um uh but uh when you think about the workload you have to schedule various uh jobs on the units then um what is the most economic way of doing it and the NVL72 in itself is a unit of assignment and um so u economically there’s no need to say I’m

[5:04:14] cut it in the in the in the middle you can do that um but you’re definitely leaving the sweet spot um of that uh of that system so in terms of I I would uh assign your your um your summary that it the computer lifts basically from a single system to a rack scale. >> Yes, it’s it’s going to be just uh like yeah just a bigger systems to serve our needs moving forward. Um, okay. So, yeah, I have a question for you, Yan.

[5:04:46] Uh, since I mean like you’re you’re at the compute level, so you serve a lot of uh inference. And what do you think um that you will need moving forward from maybe from the chips or from a hardware perspective in order to maybe better serve your customers in let’s say in the near yeah in the near future? It’s uh I [laughter] think it’s well

[5:05:17] it’s a it’s a tricky question like uh we I mean we have a way of consuming hardware which is like we take the latest generation of hardware for training frontier models. So which is like that’s uh what we need in general they they provide significant gain of efficiency and like to be at the frontier you actually still need it’s still like uh you still want more power. Um so in general we have this this mix and and we don’t only deploy NVL72

[5:05:49] systems actually we do have a mix of both um system which is which with this high performance interconnect for training uh but we do also some deployments dedicated to inference and they might not be equipped uh with exactly the same system. Um so I think like we have um the the reality of the field is like our the diversity of infra infrastructure is increasing because um the AI wave has started like several

[5:06:20] years ago. So we are starting to have like different generation and getting to actually a cycle of infrastructure which might actually resemble CPU in a way. Um the designs are completely different. uh but you do have a long-term like rotation in terms of hardware and you need to deal with this heterogeneous hardware. So um yeah I think in general like u um the chip manufacturers and Nvidia are designing what is like coming

[5:06:50] next and uh we’re going to leverage this to to to train even more performant models. >> Okay. Yeah. Um okay I think uh I want to move on since we’re talking about inference I would like to talk a little bit about inference economics if uh if that’s okay with you guys. Okay. So, um, uh, yes. So, when Nvidia basically talks about, you know, AI factories, you always measure with tokens per second, per dollar, per watt, right? Like we

[5:07:21] want the fastest way to serve inference. We want it at the cheapest cost and the lowest energy possible, right? Um, but yeah, you mentioned it’s different infrastructure for uh, yeah, for training and inference. But what do you think at what point we’re going to be able to justify the the the revenue of inference rather than just saying like um so we’re building basically for for training mostly. But when when are we going to uh

[5:07:51] to be able to justify the the revenue for inference and say that yeah all that build out is not going to is going to materialize at some point. looking >> you’re looking at me. [laughter] >> Yes, I’m looking at you. Yes. Sorry, it was a question for if [snorts] uh nobody understood, but yes, it’s an Nvidia related question and >> well, everything what you what you what you use for for producing and making money that there needs to be some some it the economics will not change for

[5:08:22] this one. So um it might have been uh a pattern in the past that you say I’m using training uh systems and uh when once the next generation is available I’m using that one for for inference for a less demanding workload. Um but still um the economics must be taken into account. Um and uh um now um I would say the inferencing workloads with the um it’s going through the roof. Um and um there is there is much more demand. I

[5:08:54] myself I’m using it. I love to use it. I use it all the time. It it I don’t I don’t search in a classic way anymore likely many of you don’t do this. >> Um and I don’t want to miss it. Uh and so I’m leaving a trace um of this one and uh um so inferencing is uh um is also very important uh for us because we spend a lot of uh engineering cycles in making the software better all the time. Um so it has a um it is really at a top workload and so I would say um these

[5:09:26] days um you need to take it into account um right from the first day. >> Okay. >> Yeah. And so if you go in this root like I think there was a risk which was before which was um a fear because the inference side didn’t materialize at scale and I think in the last year with the emergence of actually actually agentic workflows >> uh and workloads um we see inference taking off like I think like one one of the the thing which is discussed is like

[5:09:57] how much like for instance if you look at software engineering how much do you spend on like AI tools to accelerate your software engineering efforts >> and so obviously there are discussion around token maxing or whatever like to to on this angle but um there is also just a reality that it’s a daily tool uh for anybody who is doing software engineering these days so um and we see the the revenue uh generation like uh from the the result of the previous

[5:10:27] investments are paying off now >> yeah so basically the inference is is taking off and we’re going to see it’s just going to be uh increasing moving forward. So all this buildout is actually going to be used at some point by inference even though if it’s for for training at any time but uh yeah you spoke about token maxing uh and um yeah I reflect like we we don’t believe so much at uh at token maxing but we believe more um about um outcome maxing.

[5:10:58] So we want to provide value for the customer and I think this is a good segue for my next question actually because yeah despite or when you quantify you know the the uh like we were talking about cost etc but at some point it’s not just a matter of cost it’s a matter of value to to the people who use it right so h how do you guys actually quantify that so I mean beyond just raw bruter commodities ities and you

[5:11:28] know economics in this case. So how do we quantify intelligence? Uh >> so is a question for me or is it for >> this is a question for you? >> How do we intelligence? I think it’s a tough one like how do you quantify intelligence is more about yeah it’s about business outcome. So it’s uh and it’s highly viable. you can have like um with a low amount of token you can generate tremendous amount of of value if you apply AI right I think I mean

[5:12:00] it’s one of the thing that we are doing at Mistro it’s not only about volume there are some activities which are um consuming a lot of tokens uh proportionally and there is a question there is all the efficiency and all the actually knowledge we still knew to to apply to optimize this processes because some of the workloads might be actually like using an abnormal amount of tokens uh for the outcome. Um and so I think

[5:12:34] that’s where um all of the ecosystem can deliver a lot of value. If we look at like the the situation and like it’s not only about the M it’s not only about training it’s about like the complete harness and how do you actually like leverage the tokens properly uh to have a ratio of like token cost versus uh value. Then on the infrastructure layer, we’re just optimizing each layer. Uh but we are just providing like the tokens. Uh the value is really in the uh it’s

[5:13:05] captured by the higher levels of the stack I think. >> Okay. Um well since I think since you are talking about you know uh the consumption of tokens and the ever rising the the consumption of tokens and harnesses etc. So I think like um it’s a good segue for me for my next question for Adolf about reasoning. So um yeah, one way to increase the number of tokens that we consume is reasoning, but it’s also a good way also to to have a better uh a better outcome, right? So which part you think of the stack that is

[5:13:36] maybe the least prepared uh for all that uh you know tokens and that is generated by by reasoning agents. I would say I love it. It comes at a price. price is um we we consume more tokens. Um that means for everyone who provides infrastructure um I need the uh the memory to keep uh the the long contexts uh and I I need uh the

[5:14:07] caching um to take the best out of uh reuse of these conversations and uh um so I could imagine that uh um we haven’t uh um deployed the latest uh or the out of possible everywhere. Um I see we are basically in in a phase where uh where caching um gets gets more important caching across um um in in a distributed systems um there are clear uh clear

[5:14:38] signs that uh it goes into u um distributed serving um and this caching paradigm is important to this one and um well I think uh um we if we sit here next year I think uh we will we will review um the value of caching in that equation. >> Ah, super interesting. Okay. Um, I have one final question for the two of you. Okay. Uh, we said, yeah, we’re coming back next year. You’re invited according to to Yan, but we’ll probably be come

[5:15:08] back coming back hopefully in five years from now. And, uh, um, so yeah. Do you think that we’re going to have any frontier models going that are going to be trained in uh, European AI factory? This is you. You can start with this one. uh Yan and uh >> yeah yeah I think I mean we’re acting on it at Mistro like we’re bringing up like 200 megawatt of capacity next year and 1 gawatt uh until 2030 so and um um and a

[5:15:39] lot of it is in Europe so um and we are training on this infrastructure and actually like the current uh MR models are already trained on our infrastructure so I think in five years for sure we’ll have frontier models Uh, >> we’re announcing already. [laughter] >> Okay, great. Okay, so what’s the most overrated infrastructure trend in 2026? >> That’s my love. That’s for you. That’s for you as well.

[5:16:10] Out of the blue, self-healing everything. What? Okay. And what’s the most underrated one? I think like uh in in infrastructure like it depends on which uh which uh layer we’re we’re looking at. It’s a a tricky question but like software

[5:16:42] uh in a way. Um yeah I mean if you look at the purely infrastructure level uh infrastructure is software is probably like the the one of the underrated one uh software enabling infrastructure. >> All right that’s a good answer. I’m happy with that. So with this thank you so much gentlemen. Uh this is it for for for this chat and uh yeah thanks Adolf and thanks Yan. Please let’s give it up for Adolf and Yan. [applause] Oops.

[5:17:13] All right. >> Well, the audience is part of the five years so mortal exercise, right? >> Absolutely. Yes. We’re all going to be coming back in five years. Thank you so much. >> All right. Let’s give it up for Yan and head off once more, please. [applause] Okay. And with that, we’re ready for our next speaker. Our next speaker comes from Moto. Please, ladies and gentlemen, please welcome to the stage Charles Fry. All right.

[5:17:45] How’s it going? All right. Um, that was great intro music. I’m very pumped. I’m ready to do like a jazzer size or something. Um, and you need a lot of energy for low latency inference. Um, not just wattage, but

[5:18:15] also uh grit. So, it’s an appropriate start. Um, so I’m Charles. I work on inference engineering at Modal. We’re a infrastructure platform. Um, and what I’m gonna tell you about today is our playbook that we’ve developed for optimizing uh low latency LLM inference. Um, so but before telling you how to make it good, uh, I want to talk about like what low latency inf low latency inference is and why it’s so important.

[5:18:48] Um, so there’s this thing that got released recently called Jev. Um, that probably hasn’t been brought up every five minutes uh, today. Um, so, uh, Jev is a decision model, a a generic zeroot classifier that works really fast. Um, and people have gotten very excited about it. People have built these really cool demos. One of my favorite from Twitter is you like type a word and you get a pallet associated with it. Um, and the um, the person who created this demo, Matt Deloreier, said, “Oh, this is very cheap and fast. It feels like a

[5:19:19] leap forward for creating new UX and UI paradigms.” Um, and the response, I think, for a lot of people who’ve been in this field in machine learning and natural language processing for a long time was actually kind of different. It was like, “Oh, I’m surprised that everyone’s so excited about this.” Um, and the sort of like basic answer here is that they made this intelligence that was always there cheaper and faster at the same time. and all of a sudden that unlocked new use cases if you aren’t

[5:19:51] sweating that like you might run up to a usage limit or you might like spend $1,000 just trying to make an icon spin um and you won’t wait 30 minutes for that icon to start spinning then like all of a sudden there are more opportunities available to you um so um oh I forgot my corporate sponsorship statement yeah this is uh application uh Jeff and Typesafe building on top of our cloud platform So this is the kind of thing u that I’d like to help you figure

[5:20:21] out how to build yourself. Um and so Jev sort of sits in like one of three basic categories for the kinds of things that people build with uh with language model inference with sequence inference. Um and my sort of like infrared take thinking on the back end here um is that you kind of want to divide these out into what is the kind of like figure of merit for their performance. The performance is so critical here. It’s what unlocks these UI UX u paradigms

[5:20:52] that something like you know Jev for the original release of chat GPT was able to just like open up that was not there before. Um so this performance is super critical and for chat bots the sort of figure of merit is how many tokens per second can you get back to a user. So tokens per second per user um for a decision model or a zero. Um, and then the sort of final category, the sort of high latency inference category, these like data processors that might operate

[5:21:23] on a whole bunch of data from your backend or might consume in Reduct’s case like you know thousands, millions of PDFs, they have a different sort of figure of merit, a different performance target, the number of millions of tokens that you can that you can process for a dollar or maybe billions of tokens. Um, so this is higher latency inference, so we won’t talk about it. Um we’re going to focus on the low latency inference. Um so in the sort of agent category um we’ve been working on serving the uh Kimmy models from Moonshot AI and the

[5:21:56] like the difference between what you get from a sort of like offtheshelf let me take the description in SG Lang’s cookbook or VLM’s cookbook and serve it versus what you can get if you sit down and look at the workload and optimize um do a lot of configuration tuning do a little bit of uh um uh like performance engineering you can get um in our case we were able to get about you know five and a half times more uh efficiency tokens per minute per GPU but also three about three times faster per user. So um

[5:22:29] about like 400 tokens per second per user instead of a little over uh like 130 or so. Um and this has allowed us to like serve this at large scale through a variety of platforms like open router and in partnership with our customers. Um and then on the low latency side, obviously you mentioned that Jev is running on modal, but also um we’ve uh written about um uh how we worked with Decagon to get the like lowest possible

[5:22:59] latency for their like uh for their agent operating procedures that sort of do um this decision work um inside of their voice agent pipelines. Um so let’s talk about how that’s actually done. Um so the sort of like playbook we’ve developed. Um so the first step is that you need to understand the workload that you are serving and the hardware that it runs on. Uh and then once you have a clear picture what that is then you can start optimizing the performance. The

[5:23:29] workload tells you what you have to do and the hardware is what sort of does it for you and it it says this thing will be easy. This thing will be hard. This thing will be 10 times as fast as this other thing. So in understanding the workload just to make sure we like I think a lot of people have been substantively consuming AI through APIs and not necessarily thinking about what’s going on inside. So just to make sure we’re all on the same page. Um we like you send in something like this thou shalt not create uh into a language model

[5:24:02] inference server. Um this uh the uh internal representation of the model is calculated on this input in the prefill phase. Um that generates a few tokens and then you iterate that over and over again in the decode phase to generate the outputs and complete the commandment uh from the orange Catholic Bible that thou shalt not create a machine in the likeness of a human mind. And along the way, you store those internal representations in something called the KV cache so that you can uh retrieve it

[5:24:32] later instead of having to recalculate it. Um, and that’s [clears throat] a pretty important piece especially if you want to serve low latency agent inference. If you’re serving something that looks a little bit more like Jev, this is less important because of the sort of structure of the workload, the structure of the requests that you’re going to receive. Uh so with an agent you see something like this where you have the the first user input comes in the LM responds and then later you get another request from the same user that has that

[5:25:04] LM response and their first input in it and then you get another maybe a tool call from the LM and once that tool call comes back that also is going to have the whole prior context in it and so you have this iterative construction of the input sequence turn after turn. Um so some things about this um like this field and about the way LM and artificial intelligence work are kind of like flash in the pan. Um but this actually kind of feels very deep and seems like something that’ll stick

[5:25:35] around for a while. Essentially the user, the model um and the external systems that it’s accessing are iteratively constructing this context and they’re creating something of increasing value over time. And so we should expect these kinds of interactive um like constructions to be part of how these sequence models end up working. Even once they become, you know, something inside of a robot moving around your house or uh once they start taking in videos and outputting videos, they’ll still probably look quite a bit

[5:26:05] like this. Um yeah, now for a little something that’s a little bit more narrow in scope or momentary. Uh the good news is that right now um if you’re focused on high interactivity, low latency inference, you actually can usually run on no more than eight data center GPUs. So if you check out the really excellent benchmarking work from semi analysis and their inference X or inference max benchmarks, um this is maybe a little hard to see um because they’re very dense charts. This is like the least

[5:26:36] dense version I could pull out. Um, you can see that if you want the highest throughput per chip, you want these big like megawatt scale, not quite a megawatt, these really huge [snorts] machines that have a bunch of GPUs in a in a tight domain with each other, an envy link domain. U, you need like what it says here, 40 of those GPUs, 64 of those GPUs. Um, but if you want to serve at the highest interactivity, if you want the highest tokens per second per user, you actually want to be all the way down here. Um, and if you look at

[5:27:07] the points that are down here, you can see that they have four or eight GPUs. Um, so you don’t need um these fancy things, which is a huge operational win. Um, okay. So, we’ve understood like the workload that we’re thinking about and the hardware that we want to run on. Now, let’s think about how we’re going to optimize the performance. Um, so roughly the way that things work, um, is you want to target a bunch of big wins first. So speculative decoding is one of the biggest ones. Um you can get

[5:27:37] a five time speed up or more. Uh quantization reducing the precision is another big speed up has quality implications. Um once you get those big wins out of the way, there’s like kind of a grind of mediumsiz tasks on the host side. Um like sort of regular CPU systems performance engineering stuff you got to do. Um that you wins 50% maybe as large as 2x. um the weirder the thing you’re doing is the more wins they’re probably going to be on the host side. Um and then only then do you spend

[5:28:07] your time you know working on uh GPU kernels and the sort of thing that like everybody gets most excited about. Um so let’s go through that real quick at a high level like what do all these things look like and and when should you use them? So big wins first. Speculative decoding takes that decode process that we talked about where you generate um uh an output sentence like the LM is going to generate from modal is a to modal is a serverless computing platform. The thing you do instead of running this guy

[5:28:38] one step at a time is you take something much cheaper to run and you run it um and generate the output tokens and you take a guess at what those output tokens might be. you speculate and the idea here is the same as speculative execution inside processors. If you have some like slack in a system um which is what happens when you run looms one token at a time uh then you can uh sort of use some of that slack to do work that might not be accepted. So run

[5:29:08] instructions that might not actually be on the code path in speculative execution or process tokens that might not show up in the output like the word company here. Um, but you like it’s such a big win to be able to run these things in parallel, especially when you’re targeting high interactivity that this um is like very frequently a humongous win. Um, and it’s sort of linear in how many tokens you can get the speculator to guess. This is from one of our blog posts about speculators. Um, basically as you increase the number of tokens

[5:29:39] that are accepted on average, your speed up goes up as well. And these are these are integral numbers like 4x faster, 8x faster. If you’re you know do performance work, you’re used to like you know sweating over 5% or 10% but these are like 500%. Um, and then one of my favorite things about this as somebody who worked on machine learning training from the beginning is that the difference between a point like this and as a speculator and model pair like this and one like this is that you um you customize to the

[5:30:12] specific workload that you want the the the speculator uh or the target model to work on. you train the speculator to know how that model behaves on that data and all of a sudden you go from six times faster with it three times faster to five times faster. Um and this is you the bitter lesson of machine learning but apply to performance engineering which is exciting. Um people often ask like wait how can some dumber model guess what the smarter model is going to say? There’s a couple reasons why this works. Um the biggest one is that

[5:30:44] there’s a lot of structure in outputs. Um, and so if you take something from your coding agent sessions like the uh the thing above and then you translate it into what the model sees, this becomes even more obvious. You have chat templating that has all these special tokens which are usually very predictable. And then this right here is a quote from the user which probably appears earlier in the transcript. So that’s easy to guess. There are only so many tool calls. um there’s only a few of them that are something you would say

[5:31:14] you would do after saying you were going to read that file. And so this is like pretty easy to predict. Um but what the model the target model is doing is actually like processing these tokens and creating this rich internal representation that is going to be used for many tokens in the future. Um so you by being able to like guess what those specific values are with a good rate, you’re able to parallelize that um construction of their representation. Um which is pretty cool. Um, and that representation actually gets reused inside of current speculator models. They don’t just have to they’re not like

[5:31:46] a marov model, an engram speculator or another language model from scratch. They take those rich internal representations from the target model and they uh they use that they use what’s what’s going on inside the model. So they’re able to kind of like uh bootstrap from that. So the specific architecture there was Dlash. um that’s the the sort of speculator architecture that we’ve found uh works best um and the one that we’ve invested the most in and gives us like large speed ups over both built-in speculative decoding in certain models and of course over the

[5:32:16] baseline. Um after uh speculative decoding and getting that right, the next big win is quantization. So with quantization, you take the floatingoint representation of the weights or activations of the model and you decrease the bit width. So it goes from 16 bits to 8 bits to maybe even four bits. Um so this is a linear reduction in memory bandwidth demand and a linear increase in floatingoint operations per second because the the the bits are smaller or the the the

[5:32:47] numbers are smaller. Um so this I say this requires full stack coordination because you have to go down to the hardware layer and be like okay am I running on a GPU that can actually make use of these things? Do I have a H100 or later for FP8? do I have a B200 or later for uh FP4? Um but it also changes model behavior. The magic of spec of decoding is that it changes nothing about the probability distribution of the model’s outputs. Um but quantization does and so you kind of have to go all the way back up to the application layer and ask is this still sufficient intelligence? Is

[5:33:18] this are the capabilities still what I need if I quantize the model? Um, so with quantization, there’s this nice little visualizer on our LM engineers almanac that shows you like the effect of quantization. In this case, 4bit quantization on this uh image of a parrot here versus the original. I think maybe as a demo of when quantization does work. I think the people in the front row can probably see that this is a little bit um a little jank, but the people in the back row and maybe um you know people squinting at their phones

[5:33:49] like maybe can’t see that that’s um that that’s been quantized. And so that’s the effect that you can rely on. Um sort of depends on what you’re doing. So those are big wins. Let’s talk about the host performance grind. So the key thing here is that the GPU does all the work, but the CPU can get in the way. the CPU is coordinating all the work that’s going on in the GPU. And you want to make sure that the CPU work that is going on does not block the GPU work. Like this is finished. Oh, now I need to do some work to decide what to do next. And then oh,

[5:34:20] I’m going to start running GPU stuff again. That’s really bad. It’s a bubble or a stall. Um if you’ve worked with an event loop, then you’re familiar with this idea like don’t block the fast thing. Um there’s a key technique for this called CUDA graph capture that allows you to take like instead of launching like one GPU kernel at a time, you can just record all the kernels that you ran one time and then just launch them all at once. Um which is a pretty effective way to like cut a lot of this host work out. Um one tool for keeping

[5:34:51] track of this is actually my my favorite is to just look at the power usage and the temperature of the GPUs. if you aren’t close to 100% power, you probably aren’t using the whole GPU. They’re very much power limited uh when they’re achieving peak performance. Uh and so in this case, we were able like just by eye noticing that this thing was way below its total GPU power usage even at this uh uh between this one which is at well over 2,000 watts and this one which is uh below it or kind of capped at it. Um

[5:35:22] that doesn’t tell you what the problem is. You want to use something like a profiler to get in there. You want these traces. It’s a very empirical discipline. Um, and so the endsite systems or torch profiler, the tools that come from Nvidia for this are kind of your uh your go-to. And if you taking a look at that specific case, we’re able to determine that one of these GPUs is actually falling behind. All these guys here are all doing the same thing. The the highlighted blocks, they’re all running this deep gem. And these three

[5:35:53] GPUs are all waiting on this one that’s slow. turned out to be like a NUMO region awareness thing. Um that was causing one of them to always be a little slower because it was on the wrong socket. Um there’s a lot of host level things that you can use PI Spy like the things are running in Python. So you could look at what’s going on in Python and figure things out pretty well. Um we have a blog post that talks about one case in particular where we took this like repeated sort of allocation and turned it into just a cache, a Python dictionary. Um, but I

[5:36:24] guess you get to call it a CUDA IPC pool handle cache if it’s uh AIG GPU stuff. Um, but a Python dictionary that just held on to handles for these and suddenly that made the thing run 10% faster. Um, so this was mostly focused on like a one single replica like a couple of GPUs at a time. When you go to scale up, um, you’re going to run into routing problems. So you might predict performance before scaling that that just doesn’t uh happen once you scale up. Um, so one particular thing that

[5:36:55] might happen is you might uh end up with like tail latencies that are much higher than you expect and that kind of show up seemingly at random. Um, and the answer is that they are kind of at random. They come from the way that you do your routing. Um, and this is especially important for agent workloads because of the KV cache. If you’re not routing carefully like with respect to the KV cache, then the difference between like a cache hit and a cache missed is maybe 30 seconds versus 500 milliseconds. Um, and so uh measured this in one of our

[5:37:26] deployments and determined that there was variety of reasons causing instead of the you know four or five uh concurrent requests we were trying to aim for, we we saw this major overd dispersion of requests and the solution was just to make the router smarter. had to become much more stateful um and aware application aware of things like the load and the KV cache state but that was able to sort of pull in this uh overd dispersion and uh massively you know get rid of these uh spikes and massively improve performance.

[5:37:56] Um so then and only then are you allowed to think about you know GPU performance and optimizing things on GPUs. In general kernels are relatively standard. They’re close to the speed of light. architectures are not changing that much. Um, and so there are really good kernels out there from Nvidia and from like treehouse group and others. So there’s only a few percentage points to gain there. Um, so that matters a lot at scale, but it’s not something to worry about at the like, you know, at the beginning of serving your own inference. Um, the specific tool for this endsite

[5:38:28] compute allows you to like go all the way down to the assembler level and figure out where performance problems are coming from. Um, but before you pull out insight compute, I’d suggest you pull out um a marker and a whiteboard. Um, if you look at uh Tree Dow’s uh and together’s blog about their flash tension for kernel work. Um, the sort of the way they decided what to work on, the way they decided what problems mattered was just to write down the feeds and speeds like how much data is coming in, how many operations need to come uh happen on it and how quickly can we move it back out. And uh that is

[5:39:01] something that you can do you know before um you know from first principles and this sort of applies across the stack. If you understand these things about the like hardware that you’re operating with then uh you can really um you can get a lot further um without confusing yourself and wasting money. Um great. So I said that we weren’t going to talk about high about high throughput but I actually lied. Um there’s a little piece of work that actually is just coming out today and that I wanted to share with folks here

[5:39:32] at AI Engineer Paris. Um we’ve been thinking a lot about low latency inference at Modal because of how much people, you know, love coding agents, how much they love things like Jev. Um but there’s actually quite a bit of demand for high latency inference for things that look very different. Um, so the sort of prototypical example of this and that we’re going to talk about is AI SQL. So this is not the same as AI writing SQL, which my understanding is AI now writes all of the SQL in the

[5:40:03] world. Um, certainly I wrote this um, but you know, this is this is not something I run in production. Um, but yeah, so this is not AI writing SQL. It’s actual it’s actually the other like direction, the opposite. It’s using SQL to write prompts for AI. Um, so the idea is, you know, you have all this information about your customers and about your products. Have you ever wanted to just ask Chad GBT like which of my customers might buy which of my products? Um, and that can be expressed

[5:40:36] as like a relational join, the classic kind of thing that you would normally do in your database or your and in your transactional or analytic database. Um, but the problem here is that this guy here, this prompt is going to like bankrupt you if you’re running against like um a proprietary API. So like running this on your database might produce like 8 million queries all at once. Um, and then you know fire them all off and there goes your token budget. Um, yeah, that’s one way to achieve token maxing, but I think we now

[5:41:07] all agree that that’s a bad idea. Um so uh the key thing that makes this a totally different optimization problem from the low latency inference is that you have this tremendous amount of structure. So this is a query plan for a little bit more complicated of a query that has a couple of joins in it. Um and this query plan says these are all the sort of documents I’m going to use to construct prompts. This is how I’m going to have them interact with each other. Um, and this is all the 8 million or 10 million or whatever prompts I’m gonna

[5:41:37] I’m gonna generate and send to the inference engine. And the existing inference engines have no idea about SQL. Um, they like they only know sort of like request response maybe batch request kind of semantics. Um, so what if you took the sort of uh page out of the database book and you did like query planning and combine that with the inference engine. So we did that with um partnered with Treya Shankar at CMU uh to get about a 14 times speed up over the like baseline VLM on that specific

[5:42:09] query that I just showed you and achieve like over a billion tokens per minute on a single H100 and finish this query at just like $2 to execute instead of like uh almost $30 with VLM and like uh quite a bit more with um something like uh even the smallest OpenAI models. Um, so this is actually open source. We just released it today. Um, this is the first announcement of it. Um, you can find it at the full stack data labs website and their GitHub. Um, and you

[5:42:41] can read about it on our blog on uh, yeah, check it out here. Uh, all the information that I shared today is in greater detail on our blog and a bunch of resources about running your own inference on modal.com. Um, I’ll I’m gonna get pulled off the stage in about 30 seconds. So, I’ll just say the reason why I’m telling you all about this is both because I want people to run their own inference and because I think the contain the uh um serverless infrastructure platform that we’ve built at Bodal is the best place to run this stuff. So, when you go to try and run

[5:43:12] your own inference, I think you’ll realize that modal is the right place to do it. um whether that’s uh by running code yourself or by taking advantage of modal auto endpoints um our automated system for producing custom inference deployments for uh for users. All right, thank you very much. [applause] Thank you so much, Charles. All right, let’s give it up for Charles once more. All right. [applause] Yeah, I totally didn’t don’t want to run

[5:43:42] that query and bankrupt myself. That’s for sure. Um yeah, our next speaker is actually going to talk to us about the exact opposite. Uh he’s going to talk to us about how to run models in uh and in uh in smaller devices. And so he’s going to talk to us about edi. Our next speaker is Dominic Payak uh and uh he’s a senior director at ARM. So please join me in welcoming to the stage senior director at ARM, Dominic Payak.

[5:44:13] All right. All right. Hi everyone. So yeah, my name is Dominic Pike. time at ARM and today we’re going to talk

[5:44:44] about what happens when you run inference at the edge. So there’s there’s three things going on right now which I think are going to unlock some incredible opportunities. One is just the speed that small openweight capable models are becoming available. You combine that with the fact there’s tons of accessible hardware you can then put these things on and there’s this potential for devices that are a little bit more intelligent, a little bit more um aware of the intention of the user and deliver experiences that have not

[5:45:14] been seen before in all kinds of different environments. And so yeah, I’m I’m from ARM. And so a little bit about ARM. ARM is the compute platform at the heart of uh devices all around you everywhere from highly efficient data center infrastructure. There’s physical AI with automotive and robotics, so hard real time safety critical applications all the way down to pretty much every smartphone you’ve ever owned, client computing and industrial IoT and emerging devices. And that’s the the stuff that me and my team have been

[5:45:45] working on enabling new classes of devices to be created and come to market. And so I am a computer history geek. I love the fact by the way that this uh station F is on Parve Allen Turing. I don’t know if I pronounced PV correctly, but um it’s it’s fascinating to look at the history of computing and where it’s taking us today. So if we look back the past 80 years of how people have interfaced with machines starting in the very first days, you know, maybe

[5:46:16] starting 80 or more years ago with punch cards and tape and then keyboards and then mice and pointers and touchcreens. Each generation has made computing easier for people to access and interact with. But irrespective every time it’s still the case that the user is having to give their attention to that device and have the mental friction of converting the thing they want to get done into steps that the machine understands in a form that it can be inputed into that device. And the

[5:46:49] you know the amazing thing about the AI era is it inverts this relationship. Suddenly the machines understand us. Not I’m not saying in a conscious way but you know they can understand natural language and they can convert our intent into actions and tool calls to get things done. And so um in some ways you know we’re talking about edge inference in some ways this isn’t new. So there’s been object detection and CNN’s running on edge devices for for many years. So you know envision applications in

[5:47:20] factory inspection or parking bay monitoring and all this kind of stuff. Um more recently embeddings LLMs and then agentic applications which I guess is LLMs that can reason strongly enough call tools and you know deal with context long enough to act autonomously on behalf of the users. These are just becoming possible today. I I think it’s good to step back a little bit and just look how fast this has happened. And so I, you know, I graphed this out and really this is kind of, you know, look

[5:47:50] at um GPT3.5 and, you know, that was the first time I really experienced um what an LLM was and it was, you know, a mind-blowing experience. But if you look how quickly this capability is then being compressed into models with fewer and fewer parameters um up until the present day, you know, this can now fit in a billion parameters roundabout and then run on a smartphone or run on a Raspberry Pi in your hand. This is phenomenal. And I by the way, I know that benchmarks are not perfect and then an LU probably less so.

[5:48:22] But it’s indicative of a trend which is going to continue. You know, if I’m here next year, this is going to have gone down even further. And it’s it’s not just general knowledge question answering, it’s reasoning too. Um and so here we’re looking at a frontier of you know what can you do with four billion active parameters. So the kind of compute on uh today’s edge devices and again you know this has gone uh from especially with mixture of experts coming into the picture gone from something which is now um exceeding what

[5:48:54] uh Claude Sonnet 3.5 was doing when it was first released with its frontier GPQA diamond score. I think this was like a year and a half ago. Um this stuff is just moving phenomenally fast. And of course, it’s not just about capability. It’s about latency when we’re talking about human user interaction. Um, and there are also models now which can run comfortably on device which do uh speech to text in a latency which are useful for creating voice UI without any need to send this

[5:49:25] inference to the cloud. And I think it’s very interesting to consider what drives you know these latency requirements. And it’s really, you know, it’s what people expect, what they’re comfortable with is the way we should be designing these things. I find this graph really fascinating. So this is an anthropological study of human conversation turntaking and the latency between speakers. And it’s interesting that it’s culturally dependent and language dependent. So, uh, Japanese is very quick and efficient in responding. Danish is very laid-back and very slow.

[5:49:57] I don’t know if that’s because the verb is at the end of the sentence, by the way. Um, and then English is kind of in the middle. And so that gives you a kind of gauge of of where these things need to land. And so, yeah, so I hope you’re as excited as as I am about all of this inference being possible on edge devices. You may say, well, you know, we could do this on the data center already. Why, you know, why put it at the edge? And it’s it’s a good question. I think there’s some, you know, very very good reasons for this. Number one is efficiency. And so you know I think many people are already looking at their

[5:50:28] token usage and thinking how how much of this could I offload onto a local device or a device on prem. Um there’s the fact that you can customize this. So maybe you want to use personal data or proprietary data to your organization and you would like to keep this uh inhouse. Um, and then there’s kind of this opportunity for attent a uh sorry, yeah, intentionaware devices where maybe they’re observing your speech or have cameras um and are constantly looking and listening. And a lot of people may

[5:51:00] want to choose whether that stuff is shared off the device onto a data center or not. So I think these are some really compelling reasons why we would want to put the inference at the edge. And so I did say, you know, there’s something else going on here. And I think it’s this combination of you’ve got this accessible hardware. Um you’ve got these openw weight models putting this together I think is is a fascinating opportunity. And so I don’t know how many people are like hardware makers or into hardware here. Are there hardware people here? Can I have a show of hands?

[5:51:32] Good. Okay. I’m glad to see that. And so, you know, it’s been notable that for many years now, people have been building pretty amazing um hardware innovations using these composable modules from like Raspberry Pi or Arduino maybe in the first instance and then uh creating totally new designs based on this stuff. And I think that combination of hardware innovation plus these open models is going to open up some really interesting potential. Um, I think the observant among you may notice

[5:52:02] that the micro duck is in the corner there. And you know, my my favorite example of this combination because I don’t think it’s really uh as widely um, you know, it’s not happening yet as widely as it could do, but a really nice early example of this is the hugging face robotics. Oh, sorry, hugging face pollen robotics, Reichi Mini. And so I know Reichi Mini is from France. Um, I was very happy to be on the beta uh, tester program for Reichi Mini. So last Christmas with my son, I built Reachi Mini and I was really happy to see. So

[5:52:33] inside of this thing, it has a Stewart platform so it can express emotions with its head and it’s got a bunch of servos that um move the head platform. So this has ARM Cortex M0 in there. They have actuators on the antenna. They have a Raspberry Pi compute module 4 for the Wi-Fi version. And so with that you can either run some applications on the device itself or you can use that to then call inference services off device. Um and so that’s super cool. But it’s

[5:53:03] not just hardware. It’s also an SDK which is open source and it’s a community of developers creating really cool applications for this platform. And here’s one application example I would like to highlight. So this is um by our very own Marco Domingo at ARM and he created an app which basically it sits on your desk and if you use your phone or like start doom scrolling or getting distracted it tells you not to. And this this won a prize. So this won him a VIP

[5:53:33] ticket to Nvidia GTC in uh San Jose this year and a DGX Spark. Um and it was my Reichi Mini. I have to say I’m not bitter about that but well done Marco. It’s a cool app and actually if you go on the app store it is there today on the it’s a hugging face space where they keep reaching many apps. So in the design of these types of ondevice applications you know there’s a engineering challenge because you have constraints right so you have to think about the available compute and memory and oftent times you’ll have to divide

[5:54:04] up this task to make best a use of the available hardware. So for a vision application, it’s quite common to maybe have like a motion gate. Uh maybe this triggers object detection and if you classify things you’re interested in, you grab a region of interest, maybe you do image uh embeddings and maybe only then do you go and then fire off a VLM. And so these tasks may be carried out by different types of processor on device and in some cases may then go off to um other devices entirely or even to the data center to be run. Um and here’s

[5:54:37] another example. So this is the app I made during the beta test of reachi many and this is running entirely on a Raspberry Pi 5. What I love about this is you you know you say something and reach will immediately turn his head and there’s something magical about embodied AI in the way that you know a smart speaker may just bong or the LED lights up but having a character turn its head to face you and then respond is a really cool experience. And um I think in doing this, you know, I was using a Raspberry Pi which is definitely capable of running a bunch of different LLMs, but

[5:55:08] just because of the latency constraint, I chose to use embeddings and then do a semantic match and call tools against this. So you could still ask it the weather or the time and it could generate using text to speech on device also and reply. And here’s Marco’s demo. And by the way, I forgot to say, so in the main expo outside after this talk, Marco will be showing this um demo live and you can ask him questions about it. Fundamentally, what we have here is he has his DJX Spark, so he’s got a more capable device uh from his prize winning

[5:55:41] um and he’s running um another interactive agent like demo. Um this time he’s using Mistral Minstrol 3 on device and he’s doing speech to text. Um, and then he’s uh creating responses, synthesizing a response using text to speech and playing it back. In addition to that, he’s doing a bunch of tool calling. And so he has this ability to, you know, you can ask it what it’s saying. It’ll tell you, you know, actually, maybe I’ll play the video.

[5:56:12] That could be a better way of doing this. Let me just do that really quickly. >> Okay. >> Yes. >> Can you greet the room? Hi everyone, I’m Reachi. Nice to meet you all. >> I’ve got a badge here for AI engineer and let’s see if Reachi can do anything with it. Hey Ree. >> Yes. >> Can you meet the attendee? >> Show me your badge. Yes. Got it. Give me a second.

[5:56:43] Hi Dominic. Good to see you at the AI engineer conference. I see you’re from ARM. They’re known for designing risk based CPU architectures powering everything from smartphones to supercomputers. >> Now finally, can you dance? >> How was that? Too much? Want me to dance again? See you later, everyone. Reachi’s off to recharge. Have a great day. >> All right. >> So, I love the character that um and

[5:57:15] personality that Reachi has through minstrel by the way. too much is a really cool uh demo. If you go outside, like I said, you can actually go and see if it can read your badge and tell your fortune, etc. It’s really cool to actually interact with it in person. So, those are a couple of examples, but I did talk at the beginning about intent. And so, you probably heard about the intention economy, and you know, the attention economy is, you know, you get people looking at apps and there’s adverts and and stuff like that. The intention economy is understanding

[5:57:47] um what people want and providing solutions to it without them having to spell out everything. I think that’s the way I would describe it. And here’s a little example of an interaction that could be possible through this intent. So you know if you have for example reaches a bed light bed night lamp there um that’s also connected to your home assistant system for example um if you ask it you know you tell it you’re done for the day it may not be able to interpret that right if it understands your preferences in terms of uh you know

[5:58:18] AC temperature or lighting it can go and act on it if it’s got ambient context and if reachi is maybe looking or listening and remembering has memory um about the context it’s it’s receiving. It can maybe see, oh, your partner’s asleep. And so maybe Reichi doesn’t say anything. It just nods and it kind of dims the lights and it goes to sleep itself. And I think, you know, this ability to deliver a better UX with fewer interactions with a device is really the key to this thing. This is just one small example and I think there

[5:58:49] are thousands of others. And inherent in this is the fact that you know there there is an agent running here. So we talked about vision and audio and sensor streams and maybe integration with with home assistant. These are effectively events or maybe state that can be uh queried from an agentic system. And of course, you know, with with the agent, there’s a harness which is running on a CPU and that CPU is doing a bunch of work managing that context and and the memory. And then I

[5:59:19] think the uh key thing here is how much of the inference can be done off or off of the device. And I think this is like a an orchestration problem which a lot of the industry are focusing on today. Certainly, you know, task aware routting and being able to judge whether a task is possible to run on a device is is a really key one. We’ll look at that in a second. And finally, you know, we’ve been talking a lot about consumerbased applications and how people interact with devices. There are a ton of

[5:59:50] embedded systems out there that have computers that actually, you know, maybe they’re in industry or smart green houses or, you know, all kinds of commercial building systems where um they’re mainly monitoring sensors or maybe doing actuation but with limited uh interaction from a person. And so I really like to think about this idea of of those thousands of embedded systems that are out there. Is there a potential for, you know, an agentic embedded system? So I’m not saying that the agent

[6:00:20] carries out all of these tasks more that the agent takes the role of a supervisor and when things happen out of band in otherwise in other words you know if there’s a fault that the designer of this system hadn’t anticipated can these agents improvise to go and fix them and the kind of thought experiment uh I think is really interesting is you know I I’m also a space geek right so Voyager one is like I think it’s the furthest man-made object from the earth right now and it’s left our solar system and it’s

[6:00:50] um you know there was a fault a couple of years ago with one of the memory chips on this device and NASA were able to create a patch to re you know reroute this basically and and fix the error but they had a roundtrip delay of around 22 and a half hours and it was like something like a in the region of 100 bits per second communication to do this and so you know it’s interesting to consider could agents be used to preserve these systems systems and monitor them um and keep them in good

[6:01:21] health and I think this is one of the really interesting avenues for exploration on the tip on the topic of hybrid AI um so you know there are a ton of interesting uh research papers in this area and there’s some open source projects you know um light LLM or root LLM um that you can apply to this challenge of you know can inference run on this constrained device in a model that fits there do I need to send it externally internally to a more capable piece of hardware. And so I was running some experiments the other day that you

[6:01:52] know there’s a couple of different strategies. I think that the embedding kernel is the the quickest because you don’t actually have to run the prompt. You’re really just uh you know you have some kind of calibration set. You look at prompts that successfully ran locally and ones that didn’t and you see which one is more similar to your you know prompting question. There’s other solutions out there like calibrated uncertainty or even decoder state probing which are possible once you’ve actually run inference. So you’ve already drafted uh a response to the prompt and it maybe then you need to

[6:02:23] kind of defer this off device to be run um if the confidence is low or if it classifies as something which would would have failed. This is super interesting stuff I have to say. You know these evals are really just looking at single um single prompt uh eval sets. there are, you know, there’s pinch bench uh chlor is it chloral? There’s a bunch of evals looking at multi-step tasks. Um I tend to think, you know, it’s really your own application which is the best thing to consider in these cases.

[6:02:55] So, I’ve talked a lot about what we can do with this combination of really efficient models and accessible hardware and just like the inspiration of creating devices that are a little bit more I think you know a more more uh considered and less obtrusive. I think this is something that would benefit everyone. Um but of course you know I should also talk about the hardware beneath a lot of this stuff. And I mentioned at the beginning I work for ARM and ARM has uh processor solutions that span from these really low power um

[6:03:27] wearable or you know sensor node type devices with our CortexM and ethos up to Linux-based platforms with Cortex A which you might find in um in Jetson or in Raspberry Pi right the way up to data center infrastructure and our focus is providing a common software framework and uh we’ve recently announced an AI portal which has optimized models and also performance optimization tools. And one thing, you know, I would definitely encourage you um you know, I’ll show

[6:03:58] this QR code at the end. Uh please register uh become an early access customer to this thing. We’re interested to get your feedback and improve this for the applications you’d like to develop. And uh just a couple of examples. So you know, we’ve upstreamed uh kernels for Clyde AI into Llama CPP into Onyx runtime. So when Gemma 4 came out, it ran optimally on SME2. Um, but it’s not only the new stuff. There’s also consideration for uh really widely used kind of established models and

[6:04:29] hardware. So I really like this example which we have just released or due to release very shortly um which is Ultralytics YOLO 26 kind of optimized specifically for the Raspberry Pi 5 um ISA. And so they got 1.87 eight, seven times faster inference. I think the key thing to point out here is, you know, typically when you look at the FPS numbers for some of these models, they’re occupying, if they’re running on CPU, all four cores. And really in an

[6:04:59] application that is not ideal. You would like some headroom to do other stuff. And this kind of optimization is the difference between, you know, having two cores free to run your application, run other kinds of algorithm on that output. So this is really interesting stuff, I think. Okay. So, if you would like to get more resources, there’s that QR code again for developer.arm.comai. Please sign up. Uh, yeah, there’s early access to our optimization tools which I would encourage you to get into. Um,

[6:05:30] also I’m really happy to connect with you either on LinkedIn or I’ll be out by reachy later on. And so, yeah, just to say again, so Marco Domingo, I think he’ll be there at 400 pm. So, not directly after this, but at the break. uh he’ll be on the the expo stage with Richi Mini if you’d like to go and chat with him and interact with Richi. All right. Thank you very much. Cheers. [applause] I feel connected to co

[6:06:48] How you feeling everybody? Yeah. Good. Yeah. Okay. You know what I’m going to do, right? How you feeling guys? Okay. I think the next one is going to be great. Yeah. Well, thank you so much uh uh thank you so much do Dominic for the presentation. Now we’re gonna move on to our next speaker who’s going to talk to us about agentic map produce for large scale coding agents. I’m I’m super curious about this one. I want to see what what this means. But

[6:07:19] please join me in welcoming to the stage VP of engineering at Cognition Yanis Sorakis. [music] Okay, let’s see. Oops. Am I connecting to the

[6:07:52] right projector? Classic. Please give me a few seconds to sort it out. Uhhuh. That’s good. That’s good. It’s promising. And I need to see how I extend my screen. Ah, slideshow. Excellent.

[6:08:23] Thank you very much for having me here. It’s such a great pleasure to be speaking to AI engineering in Paris, this great audience. Um, very excited about what I have to show you today. Um, an approach on tackling very large codebasewide problems. And uh, yeah, let’s get going. Um, a few words of intro for us. We are Cognition. We’re an apply AI research lab. Our founding DNA is in um AI research,

[6:08:56] competitive programming, competitive maths. We’re based in San Francisco, but um we are now all around the world um including London. This is our European base of operations where I’m based and we are the makers of Devon. um few so Devon Devon is the first um AI coding agent in the cloud um which now has grown as a platform both in terms of kind of like different form factors um both local and desktop and also in depth

[6:09:29] in terms of the different integrations and agentic personas across the SDLC that we provide. Um we deploy Devon across the most like sophisticated um organizations in the world. They range from um systemically critical banks, Goldman City, Santandere all the way to the US Army, big tech um smaller like a fastmoving technative startups

[6:10:00] and uh we love tackling like a really really like difficult uh coding tasks and I want to reflect on our experiences on sort of like the classes of problems that one uh can See let us consider let’s start by think two categories okay let’s call them kind of like localized um agentic workloads which are basically kind of like take your median session with an agent I want to implement a a

[6:10:30] feature or given a particular area of the codebase I want to kind of like write some tests or augment the existing test coverage um given a particular like slice of my DB proxy I want to optimize queries and so on and so forth this concerns work that’s kind like a like a bounded problem it is like a set of relevant files in the codebase okay that basically modularize the whole logic and

[6:11:01] equally importantly if I were to tell an agent what what to do I will either point them explicitly to the files or if I don’t do they can trivial go and find the relevant area neighborhood of the codebase to carry out the task. Now let us consider what I would kind of like simply call codebase wide task. And by the way codebase wide doesn’t only mean like a single repo. You can have

[6:11:32] multiple repos. Let’s take for example a case that we’re going to revisit again again today like security scanning. what is the security profile of my application? We know that there are like the individual security kind of like a quality levels of different modules of the codebase. But what is equally important is the different kind of like the ways are interplay and how those things can evolve in the real world, how they can connect in order to reveal

[6:12:03] vulnerabilities. similar in a similar vein extracting common logic. Um we work with clients that have like really really large code bases. They want to commonize ways they treat arithmetic um financial formulas or even kind of like infrastructure ways of interacting with the database. Um they’re all sort of like first of all it is a search problem but it’s also a problem of sort of like understanding and finding all the different nuances

[6:12:35] okay by which you need to a common library needs to be extracted need to conform to and so on and so forth um there’s a complex interplay between the components take the security example the security quality of my individual let’s say microservices is okay could be kind of like a you know okay I I have like if I were to look at them in isolation low um priority vulnerabilities they can be in the backlog but when chained

[6:13:05] together they can give rise to a critical exploit and then therefore like for those tasks the result is trustworthy when you consider the totality of the codebase or the totality of the deployed application or sets of applications. All right. And of course, one can say kind of like, yeah, that’s why we have end to end tests. Okay. That’s why kind of like in our SDLC, we have the different quality gates and so on and so forth. Absolutely. Our goal is always to to

[6:13:39] shift left, right, to to catch those things and be aware of those things as um as soon as possible. Now if if I were to double click a little bit on sort of like uh what the challenges an agent could face in those codebase wide tasks I’m telling can you please find I want to find instances of a particular formula of a particular logic that appears in different variations across my codebase because I want to extract to a common library. Okay, there is a

[6:14:10] challenge of finding the work in the first place. Okay, it is a search problem. Okay, agents will spend a lot of time searching and backtracking like burning tokens. Okay, number two, polluting the context. There is a great greedy amount that’s going to build up that is going to be competing for attention. Very very variable and diverse type of context. And number three, what is effectively our stopping criteria? Okay. Again, to make this as strong argument

[6:14:41] as possible, one will say, “Yeah, of course, we’re not going to solve those big problems, okay, in a kind of like in a single session. There will be some notion of agent orchestration. Okay, there will be some notion of okay, we’re going to have kind of like an the agent outer loop. We’re going to break down the problem into different tasks. Okay, we’re going to define a dag how those things need to be completed and

[6:15:12] then we’re going to have some notion of inner loop and the agent. We have to build all that stuff. Okay, because obviously no nobody is going to oneshot prompt hey kind of like please fix security vulnerabilities. Absolutely. My argument is to today is to present to you a framework okay how we think about the problem that gives the best um both in terms of outcome performance and cost and we make this okay as a first class notion in our product

[6:15:44] um I touched upon this before kind of like single agent reasoning I’m not going to labor too much on this point okay both in terms of kind of like time spent searching context pollution and so on and so forth single agent problem does not solve very very large codebasewide tasks. How we approach this? Okay. So um we propose okay a variation or an augmentation of the map reduce framework an idea from um distributed systems. How

[6:16:17] many people here have worked with map reduce? Awesome. So super super quick example map reduce introduced by Google was a way to solve to perform analysis on like a really really large data sets that they are distributed that they live on a distributed file system. Okay. So you if the classic example that we give hey we have a huge textual corpus on the distributed file system um different

[6:16:48] files and we need to do some lexographic analysis I’ll keep it simple count the number of words on each book okay will be a series of map functions these are simple stateless as in pure functions that they kind of like we count each book they can run in parallel and there’s a reducer step that consolidates the results. In a very similar vein with a adaptation, we want to port this into

[6:17:20] the agentic coding world. Okay, where instead of like huge data sets, consider huge code bases. Okay, an overview of how this thing would work. Okay, firstly, there are two steps that we introduce at the beginning. There is a main agent that creates a plan. The plan is takes your prompt or takes including taking skills, taking existing knowledge from the repo. Okay, whatever you provide and performs an anal and those

[6:17:52] all those considerations in order to create a series of selectors. Selectors are areas, okay, are deterministic functions, okay, when when you run them, okay, it will create a catalog of your codebase with candidate areas for investigation. Number three, for each of those candidate areas, we spin a series of parallel sub aents where they look these areas and only these areas and they

[6:18:23] perform and then the analysis. This is the map step and then there is the reduce step. The main agent again considers the results the combined results the distilled results from all the different sub aents. Okay. And performs some reconciliation some consolidation analysis. This this can be duplication prioritization or some more richer analysis on the combined result. Let’s kind of like double click a bit on

[6:18:54] those concepts. Okay. And I’m going to use I’m going to use security. Okay. As kind of like a motivating example. Okay. I have this large code base. And what is the security kind of like the security quality security level of this codebase. Okay. I will provide the threat model. I will provide any additional context on the codebase. Okay. What the pre-work step is going to do is okay, we’re going to write this

[6:19:25] determin a deterministic search function that will identify areas of the codebase of interest in the context of security. You folks can imagine API boundaries um where tokens are being minted and be passed around um SQL entry uh code entry points and so on and so forth. The outcome of that is to produce basically those deterministic selectors. They’re going to run and they’re going to produce like a series of batches, okay, or a series of shards of the

[6:19:56] codebase where we can then run each one of those sub agents. Okay, those habages then they have a very nice clean and bounded context which they can perform the investigations and reports and so on and so forth and produce kind of like a bounded outcome for that particular area of the codebase and then the results go back to the main agent where we do kind of like a holistic reasoning across all the different findings

[6:20:26] in the again in the context of security to make it like a little bit more concrete. probably we’re going to duplicate number one. Number two, there is a prioritization okay of which vulnerabilities are the most critical and there is a ranking of them. Number three, but this is crucial again in the context of codebasewide tasks. Um presence of chained vulnerabilities. Remember individual agents may tell you that their individual narrow part of the

[6:20:56] codebase has some low um um criticality finding. But what the reducer step can do is can assess combinations of those low vulnerabil low criticality findings. Can they produce something much more serious? And again with the right hardness, okay, um Devon can run, okay, can actually test, okay, and try to simulate those attack paths. And to do it kind of like a little bit more visually, we treat the

[6:21:27] tend to treat of code bases as basically a graph. Okay, all there’s all those references between um the different parts of the codebase. selectors look for off areas, look for API entry points, uh data SQL entry points and then from those selectors that they have run cheaply and deterministic in the codebase, we deploy okay individual devons, individual agents that perform security analysis for this particular narrow bounded path of the codebase

[6:21:58] and then on the reduce step Devon will produce something like this. Okay, where it will sort of like number one triage, number two the duplicate, number three run and test and try to recreate those vulnerabilities including kind of like false positives as well. Um so yeah mention about reproducing because obviously at the end of the day you don’t want to ship kind of like tickets because we know whenever we have a release you know we run second

[6:22:30] vulnerability from tools there are like tons and tons of things to turn through we want to be shipping kind of like legit PRs against a known vulnerability so recreating is extremely extremely important now we’re pushing the PRs and just want to comment Okay, a little bit on kind of like the relationship between cost and performance. Okay, of course kind of like you can run very kind of like expensive agents. You can run them against really large code bases. Okay,

[6:23:03] it’s what is extremely extremely important as I mentioned earlier is to think hard and have the best possible ways okay to mitigate the cost of searching. Searching is a huge problem in large code bases and context pollution and context overflow. This is solved by the Devon and the main agent in the agentic map reduce writing those deterministic selectors and creating lots and lots of banded context which end up being much cheaper and end up having a better

[6:23:35] recall profile rather uh compared to competing models. Okay. And we’ve run this on 50 data sets, 50 vulnerabilities from kind of like a GitHub and they run across like a multitude of languages, Golang, Python, Java and so on and so forth. Um, another thing that we should think about, I talked a lot about security agentic map reduce in the context of vulnerability detection and remediation. Um, think about it about it can be a

[6:24:06] generalized concept across all different codebasewide workloads. Okay, dead code removal I mention a lot extracting common common logic into some centralized library from a very large code base. Um, dead code detection and so on and so forth. Okay. And this is something that again we from our research we have kind of like moved it to security and we elevating it into a first class feature um in our product. Um we are as I mentioned kind of like

[6:24:38] earlier we are um applied AI research lab we doing work on areas like aentic map reduce building our own coding models 2.0 know research on model harnesses like dev infusion um agentic infrastructure um please check out our research blog and if you have any questions um this is my email I’m looking forward to uh your comments and see you around in the conference thank

[6:25:11] you very much [applause] thank you so much let’s give it up for Janice once more please [applause] all All right. Okay. So, we all deserve a break right now. I know that it’s been a long day for everybody, but we have a great line of of speakers still. Okay. So, we’re going to be back here at 4:30, please. And uh enjoy your break. All right. See you in a bit.

[7:14:50] Heat. Hey, Heat. Heat. Heat.

[7:15:38] Ladies and gentlemen, please join me in welcoming to the stage your MC for the AI engineer Paris 2026 developer relations [music] engineer at Replet. Rahul Chevrey. Okay. All good. How’s it going, guys? Hey, this is the last stretch. Okay. So, this is where we need to gather all the

[7:16:09] energy and we get going for the last stretch of this AI engineer uh at Paris. And uh I’m so excited about our next speaker. So our next speaker actually you don’t need me. He doesn’t need any introduction. He was known as the Typescript wizard and then uh you know he was also known for his work at Verscell before he started talking about skills and then it turns out that he has really strong opinions and good opinions about AI. So our next speaker is going

[7:16:39] to talk to you about how to fix your PI bottlenecks. And my god, I relate to that so much. Anybody relates to that? Seriously, like who’s who’s having like so many PRs coming their way and then they they can’t review any of them. So, um, well, without further ado, please join me in welcoming to the stage Matt PCO. [applause] All right. Hello, folks. Having a good conference

[7:17:10] so far? having a good conference so far. Okay, good. So, I’m here to talk about fixing the PR bottleneck. And this is kind of a grand title for trying to fix the thing that most organizations struggle with, I think, and have kind of historically struggled with before AI. You know, we have always had huge numbers of PRs just laying around that no one’s bothered to review. And this has now increased massively because of the new strains on us because of AI imposing all these

[7:17:41] weird constraints. And to do this, I’m going to use the rubric of my skills, which is you’ve kind of heard about, maybe you’ve used them. And I have a couple of new skills to announce that are going to hopefully improve the way that you do PRs, improve the way that or improve the speed at which you can review them and do them. Speed. Now we’re being pushed to do more with less essentially or more PRs, more work, more stuff. And this is kind of the central

[7:18:11] promise of AI that we’re going to be able to use these agents to scale ourselves up to do more work. And this has resulted in the software factory, probably the biggest buzzword of the day. Everyone’s talking about software factory that I chat to. And I think of a software factory as primarily something where instead of the human initiating all of this work, we’re going to pass some of that initiation, some of the initiation is going to be done by agents. And I think of their

[7:19:04] maybe from there you have a classifier like Jev come in and Okay. Okay. Let’s turn that into a fix or turn that into a reproduction or maybe I ping people straight away. And maybe you have other things. Maybe you have planet scale hooked up. So it gives you query reports on the slow queries on your database. Maybe that then triggers a different um thing of your software factory. All of this is not humans triggering it. It’s uh deterministic code triggering it. Right? And so these accelerate your software factory. They push more code through it. But then you need breaks, right? If you just have permanent

[7:19:37] acceleration pushing stuff through your factory, you’re going to end up with a slop cannon, right? You’re just going to end up with a ton of slop crappy PRs that you’re not going to be able to touch or review or even freaking look at. So, you need breaks. These are mechanisms that slow down, that increase quality, that make sure that your codebase doesn’t turn into a software entropy nightmare because code is the environment your agent operates in. And if you have bad code in your codebase, that is going to beget more bad code.

[7:20:07] And so I’m going to talk about these three breaks in this talk and talk about how we can use them to counterintuitively go faster. So automated checks, these are the deterministic checks in your repo that we’ve had for thousands of years or you know since the 50s. Deterministic checks where we have linting and tests and type checking and code quality metrics. All of these things going together and they all work the same every time. Layered on top of that we have automated review. So

[7:20:37] we have agents who look at our code and say okay you know these are for the things that the tests didn’t catch or this is looking at the structure of the codebase in general. And then on top of that the third layer the final layer is human review. So people looking at the PR. And these three layers form this kind of cake that we end up with when we get to human review. And so more speed of course means more PRs. And so the goal here is to make human review faster by leaning on those first two phases.

[7:21:09] And we got to stop the slop. That’s the first principle here, which is if you raise the quality of the code that you’re shipping, you’re going to end up doing less human review because it’s just going to be better work. And so you’re going to end up needing to u make fewer interventions. So automated checks. Now automated checks are cheap. That’s the cool thing about them is that they don’t cost tokens like automated review does. They don’t cost human effort. They just cost CPU cycles. So these are for instance, you know, you run your tests on every code change. Maybe those tests do incur

[7:21:41] some tokens because let’s say an agent uh creates a bug and the tests catch it, then you need to spend some tokens to go and fix it, but those are tokens pretty well spent in my opinion. So checks are cheap. That means you can layer on loads and loads and loads of them on your repos. you’re probably not using enough of them or not being creative enough with your use. But checks can lie. Does a green CI mean that the code is ready for merge? No, it does not. And so we’ve always needed on top of these

[7:22:12] checks some extra layer to figure out if there’s anything catastrophically wrong with the code before we ship it. And so all of the other phases, the human review and automated review, these are lie detectors. These are for finding lies in the automated checks. Now, I want to show you some of these lies first of all because this helps when we’re thinking about code and thinking about automated checks to see how bad it is and how bad things can get. The first is tortological tests. A test that just reasserts the implementation. Opus 5 got

[7:22:44] addicted to these. I don’t quite understand why it would have for instance x post character limit equals 280. Can anyone guess the test that was written to test this behavior? Right? You’ve probably seen this a thousand times. This is real code from agents or from stuff that I found my agents doing. It said expect x post character limit to be 280. So the implementation looked like that and the test essentially reasserted the implementation. That is a tortological test. And tological tests are bad

[7:23:16] because they’re extremely structure sensitive. They’re very sensitive to the actual internal workings of the system. So it means I cannot change that constant without a test failing. But I cannot rename that constant without a test failing. Like I have to do is so tied into the structure of my system. And I found another one which is even more egregious I would say. This is incredible uh test. What it’s doing here is it’s essentially testing whether two

[7:23:47] things in the UI appear in the right order. So it’s checking that the pitch detail page uh or rather the video section comes after the content plan. What it does is it doesn’t render it to a screen. It just reads the actual file the module into its own memory and then it’s finds the right thing. So, finds content plan, finds videos, and then it expects the videos to be after it in the source material, which is crazy if you think about it because I can just like change the way the source material looks

[7:24:18] and this test will fail. It’s too sensitive to the structure of my codebase. So, that’s another way that automated checks can fail. And there are also or sorry, automated checks can lie. There are also tests that literally cannot fail. And this will feel familiar to you if you’ve abused mocking in the past or abused various things. For instance, here we have a use audio boost function. And this use audio boost function uh its internals use the audio context API in the DOM. Don’t worry if

[7:24:48] you don’t know any of this, but what we’re doing here is we’re just stubbing it out with some fake methods. And it turns out that audio context has some complicated error modes and it will fail if you use it under strange conditions. And so just doing this means our tests cannot fail using those modes and we’re going to hit strange errors in production that our tests can’t fix. And so the question is then if you can cheat on automated checks if you know and even in good faith ways as well. The the AI

[7:25:19] isn’t trying to write bad tests here. It’s just taking our instructions and writing tests that are too tied into the structure instead of actually executing code. So how do we make automated checks harder to cheat? If we can do that, then we can increase the quality of those checks, which means which increases our quality bar. And the first thing I really like about this is codebased design. So you can actually design your way out of these bad checks. So what does good codebased

[7:25:49] design look like? I’ve talked about this before in previous AI engineer talks I’ve given, which are deep modules. These are modules that hide complex behavior behind simple interfaces. This is a John Asterout idea from the philosophy of software design. If we look at these two modules, we’ve got A which has a large implementation hiding behind a tiny little interface at the top. Okay? And then B is a large interface, lots of functions you can call and those functions individually don’t do very much. Does that make sense? Yeah. Now, if you have a deep

[7:26:23] module like a here, you’re going to have fewer structure sensitive tests because you’re hiding more of the implementation behind that interface. If it’s just testing at that interface, you’re going to get better tests. And so, your job here is to force the agent to use that little interface instead of reaching into the implementation to test these weird implementation details. So, I’ve got a skill for this. You can have like the weirdest vibecoded like codebase, the crappiest codebase that

[7:26:54] you’ve ever set your eyes on and you can run this skill on it and it will make it better. What this does is essentially gives you opportunities for deepening modules and kind of looks like this. Raise your hands if you’ve used this skill. By the way, not sure how many of my folks are in this room. Yeah. Okay. It’s really freaking nice. Essentially gives you a HTML document. I’ll get out of the way here of all of the different um potential opportunities. it sees. So we can see here we have a before and we have an after where we’re sort of like reducing duplication. We’re creating a

[7:27:24] nice deep testable module and then you can go ahead and implement that. And attached to this, there’s also this kind of language that I’ve put together for describing modules. Because like if you ever try and read up about how to structure a codebase, you’re going to find 20 different approaches and they’re all going to be called DDD. And like what you need is a consistent language that you can use in your team to talk about this stuff. And so I have a little codebased design skill that defines what locality is, defines what leverage is, defines what a seam is. I was using

[7:27:55] seams before they were cool. And what locality means is kind of how uh well located together all of the code is. How can you change like a small change in one module and have it ripple out? And also leverage is what you get when you have a deep module because the caller, the person who’s actually calling that module gets a lot of value of calling a simple function. Both of those are very good in code bases and good for agents too, it turns out. But I’m sort of

[7:28:27] describing all of these highluting coding standards. But how do we actually make sure the agent does them right? How do you make sure the agent creates deep modules and creates good tests and doesn’t write these crap tological ones or structure sensitive tests? Well, I do think most people get this wrong. And my first piece of advice is don’t put coding standards in your implement agent. Okay, let me explain this. If you

[7:28:59] imagine the implement agent kind of looks like this where this is all of the things the agent needs to be able to do in its single context window. It needs to be able to explore like to look for the code that it’s going to change. It then needs to actually change it. So make the updates to the files in the green and then it needs some budget for actually debugging the thing. So for running those uh automated checks, for actually checking and verifying that it works. Now this is quite a lot of work it turns out. And if you try to impose your

[7:29:29] coding standards on it as well, it’s going to perform worse. So implementation is overloaded. That’s the mental model I want you to have. And so can we find a way to impose those coding standards in a way that isn’t so overloaded? Well, this is my effort. This is my code review skill. And it receives a diff and it reads a file inside the repository called coding standards which you can write, you can customize and then it checks if the code follows those standards.

[7:30:01] And so if we look at the reviewer agent here, it also crucially runs it in a sub agent. So it’s got its own context window to kind of handle here. It’s got its own budget. This one it needs to do some exploration, right? Because sure it receives the diff so it knows exactly where it’s located where the code is but it should probably do a bit of exploration just so it has the wider context understands the code but it doesn’t need to do any implementation doesn’t need to do any debugging. So while implementation is overloaded

[7:30:31] review is actually underloaded. So it doesn’t have that many jobs to do. This means you can pile in a bunch of coding standards to it and it will do a much better job than if you try to do it with implement. So, I think of this, and this is uncomfortable, right? Because we we all want to be able to just get good code out the first time, but I think of this as the twopart process for writing good code, which is implement, you make it work, and then code review, you actually make it good. You impose your coding standards. And for, you know, the retro

[7:31:04] developers among us, this is essentially a red green refactor approach. We use one context window to make it okay. Do the red green and then we do another context window to refactor it. That’s at least how it works in my head and it’s been very successful for me. This means that when you have coding standards, you don’t put them in global scope. You don’t put them in agents.mmd because then they sort of drown out your implement. It may read them, it may not. You put them in coding standards.mmd and that way just the code review agent does

[7:31:34] it. Now, I’ve got another idea here, which is I’ve been talking to lots of people today. Lots of people saying, you know, I’ve been talking about review and automated review increased, you know, fixing the PR bottleneck. So many folks say, “Oh, yeah, we just use a third party service. We use a cursor bug bot. We use code rabbit or something like that.” I think that I’ve I’ve really tried to make a generic code review skill in the past that finds all the bugs and does security review and that kind of thing. It turns out it’s really

[7:32:05] really hard because you either make it too general and it just gives you false positives that aren’t actually relevant to your use case or you make it too specific. You say, “Okay, find all the TypeScript stuff and then Rust people can’t use it.” So, I would say don’t outsource automated review. Build your own. Build up your own coding standards over time. Share them across your team. And if you have an opportunity to impose coding standards, if you’ve got some docs sitting around that no one reads, this is the place to put them in. And

[7:32:35] also when you have this automated reviewer, a really natural inclination for lots of people is to say, “Oh yeah, my code review agent, what it does is it reads the code and then it comments on the PR.” So [sighs and gasps] what your code review agent is doing in that case is it’s providing more work for the human reviewer. The human reviewer then has to read all of these verbose comments and figure out, okay, do we implement this? Do we implement that? The reviewer should commit. It should make fixes. So, it should actually change the things

[7:33:05] that it finds because then when the human comes around, you’re reviewing a really nice artifact. If it finds anything that it has any questions over, then of course it can comment, but the default should be commits. Stop trying to oneshot good code. Stop trying to make the implementer agent the only thing that you do and go, “Okay, I’m going to force it to be amazing.” It takes a little bit of, you know, thinking your way out of there, but once you realize it, it is fabulous. So, okay, with all of that process, we’ve

[7:33:36] run our automated checks. We’ve now run our automated review to make sure the automated checks aren’t lying. How do we then maximize the PR’s quality in terms of human review? How do we get it like working the best it can? So, we need a human friendly PR. And this is a new skill uh coming into the repo which is currently in progress, but I’ll be releasing it soon, which is the PR skill. This is one I’ve been mulling over for a long, long time. I haven’t quite figured out what the state-of-the-art is. And I realized the best way to make a PR skill is just to

[7:34:07] steal all the best ideas that everyone’s got. And it’s very nice. Now, what does a good PR body look like? How would you recreate this skill on your own? Well, the first principle is some reviews are more important than others. Not every review is essential, right? And once you understand this, you realize, okay, that means I can focus my energy on the really important reviews. But how do we categorize that? Well, you got to think about the PR as using this

[7:34:39] AWS terminology, which is is it a one-way door or is it a two-way door? Now, most PRs that you have will be two-way doors. You can merge the PR and then always pull it back later. It’s the glorious benefit of being a software engineer as opposed to a civil engineer. Right? Mostly when you’re a civil engineer, it’s a it’s a one-way door, right? If you get something wrong, that bridge is going down. But if you have a two-way door, it means that you can easily revert the change. Now, that might be more um

[7:35:10] bit more nuanced than you might expect. It might be that a very simple change accidentally blasts out an email to 60,000 people or something in which case that is a one-way door. You want to review that very very carefully. Involves expensive migrations or data loss. That is a one-way door. Review the hell out of that PR. But also tied on to that we need to understand the blast radius of this PR. What can go wrong? And if things do go wrong, how bad is it? And this means I end up with a nice little sort of summary right at the bottom of all of my PRs, which is the

[7:35:41] merge danger. I can see this one is a two-way door. It blast radius is localized. And so I can see, fantastic. I don’t need to pay that much attention to this. I’m just going to sort of review it a little. That’s really important. Next, we need to understand what the PR is even doing, right? And I’ve tried lots of different ways of figuring this out, and the best thing I’ve come up with is using pseudo code. Now, a huge um point of gratitude here to the show me skill from the human layer skills

[7:36:11] repo by Dex Holley. This is a phenomenal skill that just essentially dispenses with most text and shows things to you in images and diagrams instead. This makes it a lot easier to grasp actually what’s changing and why it’s changing. So you get the kind of standard sort of set of like mermaid diagrams and UML for you know this is a sort of sequence of things that happened. You also just get these lovely simple ones like this for instance. We can look at this and go okay we’re working in a CLI. We can see a new command has been added and we’ve

[7:36:42] got two new things little flags up the top here. Just little summaries like this. It really does make a massive difference. It’s hard to overstate. So you’re trying to like make understanding the why as fast as possible. And I think a third principle here is something you should be thinking about whenever you do human review because because we’re not doing like um because our processes now are so sort

[7:37:13] of streamlined and all we’re all collaborating around these same skill files, these same steering files. We’re all building an environment for our agents to operate in together. You should think of the process that produces your code as just as important as the code itself. In other words, when you do a human review, you’re not just reviewing the code, you’re reviewing the system that creates it. And the theory here is that you never want to write the same comment twice, right? You never want to catch the agent doing the same thing over two PRs. And so what’s the

[7:37:46] mechanism by which you can make your human review matter? Well, this is a new skill. This is called retro. Retro for retrospective. You essentially take a session that you’ve done. It can either be like a single um agent session or it can be a PR plus the session or you can just get it to look at okay look at all of the PRs that we’ve done over the last week all of the reviews pull them all in let’s do a retrospective on them and it will suggest automated checks and coding standards to make the next one better.

[7:38:17] So this is the compounding effect where you essentially by doing human review you’re making the quality of the next human review higher and you’re sort of saving less work from yourself next time. And retro is a really smart skill. It adds a bunch of stuff. So obviously it suggests automated checks. It suggests updates to coding standards.mmd. It does other smart stuff too. So it looks at navigation pointers. How easily did the agent find its information? Can we provide a pointer inside agents.mmd to help it out next time? It looks at tool economy. Are

[7:38:49] there different tools that we’re using in the session that can, you know, could be made more token efficient? It’s amazing how many things this catches actually because those are often really hard to debug from the outside. It just looks at bloat as well. So, are there bloated steering files? Are there bloated skills that contribute to these bad results? Can we make them more organized? So that’s the goal is to make human review faster. We do that by layering up automated checks. We’re layering up automated review. And we make the human

[7:39:20] review as painless, as simple, and as kind of optional as we need it to. You really don’t need to review every single two-way door. Every single one-way door you do. And so these are my skills. AI her.dev/skills. I’m going to be shipping version 1.3 this week. It has been glorious hanging out with you. It’s been a really nice conference. I’m going to be outside in the lobby if anyone wants to have a chat. Uh thank you so much for having me. Thank you, Paris. [applause]

[7:39:50] [cheering] [applause] >> Thank you so much. >> All right, let’s give it up for Matt once again. [applause] I love that retro skill. I think I’m going to use it very very soon. All right. Okay, so up next is somebody from Deep Mind U. So we have Martin who’s going to talk to us about Gemma. He’s going to talk to us about some architectural fundamentals, but also

[7:40:21] what makes uh Gemma so fast and unique. So please let’s give it up for M for Martin.

[7:41:18] No, I’m not seeing anything.

[7:41:50] Yay, it works. Today I get to talk about something that I think is a very central component of releasing open models and that’s about efficiency. Because the moment you release a model out into the wild and people can actually use them, uh that’s the moment that they become constrained. Constrained because you know they’re being run on your mobile devices on your laptops and I can kind of assume that there are not data centers that are running these models. So efficiency

[7:42:21] becomes a very big part of it. And I would like to focus on a couple of perspectives on efficiency. knowledge, size, speed, the complexity of the architecture, but also the architecture in itself. And I want to dive deep into some of these components and see what we can learn from it. One part is per layer embeddings. It’s a very big thing in the smaller models of Gemma 4. There’s these two billion and four billion parameter models and they use per layer embeddings

[7:42:52] heavily. Now they essentially explain what that E actually means in E2B and E4B. We know the A right in mix of experts models they stand for active. But what does the E then stand for? Well, let me show you. And this is the architecture that Gemma 4 generally uses, right? It has local tension, has global tension, group query tension, there’s some normalizations here and there. And then right at the end with the smaller models there are suddenly per layer embeddings there. And as the

[7:43:25] name implies these are embeddings per tokens but even per layer. So they’re much like the token embeddings that you know we all know so well but this time they’re being added with every layer. That means that the token high has a very different embedding on layer 1 than it has for instance on layer four or layer 10. It’s a way to add knowledge to the model without having to, you know, store them in memory. During this processing, the model can

[7:43:56] actually weigh how these tokens uh are being used. So for a given context, the model might say, “Okay, I want to focus a little bit more on this aspect of the embedding rather than that aspect.” And now the great thing about using something like this is that it’s a lookup table of information about the tokens. And when you have a lookup table, you don’t need to store it in VRAM. You don’t need to store it in RAM. You can just store it on whatever storage you have. It’s a rackl like behavior that’s happening here because during inference, we only need to load

[7:44:27] in the tokens that are actually needed. And so that explains that the E actually stands for effective because that per layer embedding lookup tables, billions of parameters, right? But they’re not being used during inference. we can separate in a way part of the knowledge from actual model capabilities and this this this idea of separating them is becoming more and more pronounced in the field of open models. So we have knowledge you can do knowledge efficiently. What about size for

[7:44:58] instance uh you can create a very small model but you still want to have a lot of capabilities. So what you can do is you can do quantization aware training. you reduce the precision to something smaller while trying to maintain the capabilities as much as you possibly can. And that’s a very nice way to approach this. But we can actually take it a step further with mobile quants. And that’s a very specific schema that was developed for these two smaller models because when you have smaller models and you’re going to quantize them

[7:45:29] to even a smaller size, you have to make sure that you don’t lose too much performance. So a very specific schema and looks a little bit like this. So we have the token embedding layer right you can actually reduce that all the way to two bits and retain a lot of the capabilities of the model still uh and now the reason I will come into a little bit later for global attention four bits 4bit is what we generally use right it’s a it’s a nice balance between the size of the model and capabilities

[7:46:00] but for local attention which you know zooms in on the thing that we want to know more about it helps to have a little bit of a higher precision Especially with the KV cache feed forward network is four bits but then the per layer embeddings that we just talked about those are two bits because they kind of compensate for the lower position of the token embeddings as well. And so when you combine all of this you have a nice schema for a specific model. And what you see is that making sure that it’s efficient also

[7:46:33] means doing a lot of customizations to these models especially at sizes like two billion four billion parameters. And with all of that you have knowledge, you have efficiency in size. What about speeds? Well, with speeds we use something that’s becoming more and more popular fortunately these days speculative decoding with multi-token prediction. And it works by using a rather small model to kind of suggest tokens that the bigger model, the model

[7:47:04] you want to actually run, can use because that allows the bigger model to then only have to validate all of the tokens that it sees without having to process all of those tokens themselves at once. So we have a target model, right? It’s a big one. It can be whatever architecture that you have and a draft model, a smaller one. And with Gemma 4, what we aim to do is do some KVK cache sharing. Why? Because that simplifies the process for the smaller model, the candidate model or

[7:47:35] the draft model much, much more. Because what happens is that the target model takes in and query, does a single round of processing, one single pass, generates its KV cache, and then shares it with the smaller model. And the smaller model can then use the output of that and continue on processing and generating tokens. It will take the input, generate one, two, three, perhaps eight tokens for the larger model then to validate. And so the larger model

[7:48:06] only has to look at all of these tokens at once and decide, okay, I like these tokens, but I don’t like so much these tokens. So I’m only going to accept these first two, for instance. But it’s still a single pass, right? So all it needs to do is then add another token because it can it did the computation for the entire sequence anyway and then it generates three tokens almost at the cost of a single one and that speeds things up tremendously.

[7:48:38] Now obviously nothing is a free lunch right? So there are pros and cons to a method like this. You add a model it’s a very small model but you add it anyway. It also differs greatly on the use case, the speed up that you get from something like this. The thing is some tokens are super easy to predict, especially in structured tasks like code for instance. But in creative tasks, it’s very hard for the smaller model to really figure

[7:49:08] out okay, what kind of tokens am I going to suggest? So more of these tokens will then be rejected. Well fortunately there are more and more coding task more and more structured task that we see out there. So for those use cases multi-token prediction works exceptionally well and then you have efficiency on let’s see knowledge size speed uh what about complexity? Oh did I see this one here? Let me remove that

[7:49:39] server. And then we have complexity because that’s also a thing, right? If you have a model that’s not open, it really doesn’t matter that much how complex it is for the end user. But when you release a model out into the wild for folks to use, uh, let’s make sure it’s not too difficult to actually, you know, understand, use, uh, and process. And so, as a consequence of that, there was this model that was released called an encoderree model. And the encoder free model kind of looked at the encoders for you know processing these

[7:50:12] multimodal inputs and said that’s a lot of work. What if we remove them? For many of these models in the Gemma 4 line you have an audio tokenizer an audio encoder and the same for images. And that’s great. That works really well. It’s a staple in the field right to have these encoders for different multimodal entities but they still take up a reasonable size. It reduces time to first token and it’s something else to consider when for example fine-tuning your model

[7:50:44] with the encoder free model. They try to just remove them entirely and put a lot of the burden of processing these multimodal inputs onto the model rather than these encoders. For audio, it works a little bit like this. You have an input, a sequence of amplitude values and the the only thing that happens is they cut it up into pieces, make it a sequence of well audio tokens and then project it onto the dimensionality of the model

[7:51:14] itself and that’s it. So the only parameters that you have are kind of in the linear projection, but that’s about it. And then all of the contextual stuff that was happening in the audio encoder before is now being handled by the LLM itself. So you’re kind of shifting all of these parameters from the encoder to the LLM. The same can be done with the image encoder. The one problem though is with images is 3D information. We can’t just cut it up

[7:51:45] into pieces, make a sequence out of it, and just hope the model processes it well because it doesn’t. I I can promise you that. So what we need for that are positional information. So instead of doing a a direct projection from the patches onto the model, we take those patches and provide it with additional positional information. So it knows that well let’s say patch four that small image token um has actually some meaning to it because you can imagine if you have a very wide image position four

[7:52:17] means something very differently than if you have very tall image. And so what happens is you just use the positional embeddings uh projected and what you have again is an encoder that’s entirely removed. What’s so nice about something like this is that it reduces time to first token that very much helps. you put all of the capabilities onto the model and you reduce uh a big portion of the parameters because especially at smaller

[7:52:48] sizes something like 300 million parameters or 500 million parameters it doesn’t sound large when we’re talking about hundreds of billions of mod of parameters for some of these models but at two billion sizes or 12 billion this makes a big big difference especially if you can use it for the capabilities of the And so we have knowledge, we have size, we have speed, we have complexity, all different ways to focus on efficiency. And there was one last thing that I

[7:53:18] really wanted to focus on and you know explain a little bit more about what it means and how it works and that’s architecture. Regular models, regular LLMs are all memory bound and those have advantages and disadvantages and they’re great. They’re used for many different purposes and and many different fields. What if we make them computebound instead? What if we flip the narrative 180 degrees and try to approach it from

[7:53:49] a very different perspective? And so what you get is not auto regression, it’s something entirely different. Diffusion. Can we use diffusion for LLMs and still have it being meaningful? have it used in a way that you know a lot of people can still use it but for very different use cases. Now let me go through a little bit about about what diffusion means in large language models uh especially because we will come to a subject that I think a lot of folks will have seen in the last couple of weeks.

[7:54:22] You start with an input, right? We have a query, an input that’s being processed. And normally one model would do that and now kind of the same model does it. But what happens in the fusion, we have something called an encoder. And the encoder in the fusion gemma at least is still just a decoder with causal attention. It’s a fine-tuned Gemma 4 model. No crazy different architecture or what have you. It’s, you know, one of the models you saw before. The reason why it’s called an encoder though

[7:54:53] because it’s meant for processing the prompt and so it generates a KV cache the context that we need to then build upon and slowly and more surely do inference. So we start with the KV cache but do to do the actual processing to actually generate tokens in the fusion you don’t start from scratch. You don’t just you know here’s one token and here’s the second and here’s the third. Now you start with a noisy con canvas. It’s typically sized around 256

[7:55:24] tokens and then the job of the den noiser will be to actually process that and iteratively fill it up with tokens that it’s very confident about. It is the exact same model though. It uses the exact same tight weights gem for 26B model. There’s one difference though. If you have a large canvas and you want to update the tokens simultaneously at the beginning and at the end, you kind of need a different type of attention. So when it’s in the

[7:55:55] denoiser mode, it uses birectional attention instead. So it can lock both directions. What happens after that is it gets the KV cache of the encoder because again it was meant to process the state and get it ready for the deninoiser to do its work. And then the deninoiser can well predict or suggest what tokens should go at which specific places because we have this initial canvas of tokens and all it needs to do is update them at the appropriate places. So there’s this

[7:56:26] predicted canvas that it then has but you know it doesn’t do stuff in uh perfectly at once. So it needs a couple of steps to do that. There are some tokens it’s very confident about obviously and some not so much. So what you then get is in so-called accepted canvas some tokens are accepted and some tokens are not. The tokens that are not accepted though those are renoised because the entire purpose of this model is to dn noiseise it to remove the noise from the original canvas and find the

[7:56:58] actual tokens that should be there. And so we end up with a renoised canvas and it go can go ahead and do its second step. And now in the second step it again uses the KV cache and it can use this KV cache to again do a similar processing. But what we found if if you were to do just this, it’s not a perfect way to approach this. Because in the very first step, it had an initial idea of what it wanted to do. Even though some of the tokens weren’t accepted, it

[7:57:30] still had a direction it wanted to go into. And so there’s kind of a skip connection there, a self conditioning where you take the logit from the previous one and feed it to the input of the second step. And then you can do this process over and over again, typically eight steps or something where it updates this canvas. And then in those eight steps, sometimes less, sometimes more, you get 256 tokens. And it makes your model go incredibly fast when served for a single

[7:58:01] user on a larger GPU. Efficiency takes a very different meaning than when you compare computebound to memory bound. But there’s still many use cases for that. One we didn’t quite expect would blow up in the last week or so, which is obviously Jeff. because Jeff being a a a foundational decision model, you know, essentially a foundational classifier that’s being used to make decisions happens to work

[7:58:32] quite well with diffusion. And it works a little bit like this. So let’s say you have a situation, the printer is on fire. anything that requires you to want to take an action. You describe the state, the situation, what have you, you again take that encoder and you process it for the purpose of creating a KV cache. What then happens is instead of having a fully noisy canvas, you kind of prefill some of these tokens and the prefill are

[7:59:04] then related to the actions that you want the model to make a suggestion on. Okay, the printer is on fire and your options are to either, you know, decide if I should evacuate or call it. Those tokens don’t change, but the others are still noisy. That’s the one it needs to fill in. And what happens is that when you do that, it can make a prediction for only those two tokens and using the things that we saw before, make a probability of whether it should

[7:59:35] do something or shouldn’t do something. just one den noising step. Technically it can do more but if you want to make fast quick decisions uh this is all it takes to create well apparently it’s called diffusion gemma Jeff now but that works extremely well because nobody fine-tuned that model the only thing that happens is just limit it in a way but that showcases also this concept of efficiency because it’s okay to limit certain things in certain ways because

[8:00:07] it opens up the way to make sure it can be use for things we didn’t imagine before. When you combine all of that together, one thing that makes all of this happen is that it’s all about the community, right? Efficiency is not for us, it’s for you. It’s for the folks that use actually these models. And whether that’s on mobile, on a laptop, on bigger GPU, that doesn’t matter. when you release these open models and you’ve seen a bunch of talks already today

[8:00:38] talking about that it needs to be useful for you. That’s the main purpose of trying to give back to the community. But in the same way when you do that you can see the community giving back to you because a decision model based on a model that wasn’t necessarily intended for that. Well, that’s very cool to see that gives a lot of innovation from a field uh that you know we didn’t do but by giving people the option and the

[8:01:10] opportunity to play around with these models to open them up to see what’s happening inside them to tweak it to change it you get these fun cool models that who knows where it’s going. I have no clue. uh it’s now a big hype. I think for a good reason, but the thing is with hypes, we’ll see how far it gets. And when you then talk about efficiency, there’s all these different types of fields and perspectives that you can focus on. And I could stand here and

[8:01:40] talk for hours upon hours on what efficiency means alongside performance. And that’s not an easy thing to do, right? There’s so many of of these incredible open models out there that try to focus on these things because it’s not just about performance but also of on whether you can actually run the model because it doesn’t matter how good a model is if you can’t run it it’s meaningless and so a lot of attention from different parties and you see a lot happening in Jama

[8:02:14] devices and hopefully this helps you get an idea of what it means to focus focus on these on these smaller models. It’s a very different narrative than going bigger and bigger and bigger. That’s also interesting. Gives a lot of very cool capabilities. But these open models, these small models, especially when they’re on device, on edge, your small devices, they need to be capable and they need to be quick. And efficiency from many different perspectives is a very big

[8:02:44] part of that. Thank you very much. All >> [applause] >> right. Oops. Okay.

[8:03:30] All right. Thank you guys. Let’s give it up one more time for Martin. [applause] All right. So our next speaker is going to come in a few minutes. In the meantime, I have so many questions for you guys. So um I just would like to know what was your favorite part of this conference? Like does anybody want to share?

[8:04:04] Okay, maybe two open-ended questions don’t work in a crowd big crowd like this. Okay. So, um uh you guys I I don’t know if you guys went to uh to the expo, you checked the swag, you checked like uh but but I like I just want to know for example for me what I like the most is uh seeing people at the expo discussing and and and making new friends. I think it’s something that is uh quite obvious to say right like every time we go to a new place, every time we go to an event is to meet people. But I really like that it really becomes like

[8:04:35] a family. I’ve been um uh attending AI engineer for quite a while now uh around the world. So in San Francisco, in New York, London, and here. And it’s so cool to be able to see like sometimes we see the same faces over and over and then we make new connections. So my my advice to be honest with you guys I know we we don’t have a lot of time left but yeah just make sure that you connect make make sure that uh you you collaborate because I think that the through this

[8:05:05] community like a lot can happen and you never know it doesn’t have to happen now it can happen in the future. Um, another nice moment that I saw is uh so many people lining up for to talk to uh to our speakers like yeah so many people come to me and they ask me also about um some some of our speakers apparently like yeah um P.A.I. was quite popular. Uh ARM also is quite popular. So it’s good to see that uh our audience is uh is quite diverse. Nobody

[8:05:36] wants to share what their favorite moment was. the food. All right. Yeah, I I guess so. Yeah, I guess so. Yeah, thank you Sarah again [laughter] for sponsoring for the food. So, apparently we nailed that. Okay. Any any talk favorite talk? Gemma 4 was great. Okay. Wow. Nice. What else? Okay, that was Gemma 4 and that’s it.

[8:06:07] Like we should have just have gym four for the entire conference and that’s it. The kids that was hilarious and I love Kitza. Yeah, shout out to KZA. But but yeah, he’s uh he’s hilarious. Yeah, I agree agree with that one. Um all right. Okay, so enough of me, but this is our last presentation of the day. Okay, so thank you so much for hanging in there. Um but before we get started I would like to introduce introduce uh

[8:06:37] Olivia Tibu from Gradium who is going to talk about the missing layer of conversational [music] AI. Let’s give it up for Olivia. Okay. All right.

[8:07:11] You’re extra. Oh, it’s not what I meant. It’s not what I meant either. All right. should get started. Let me see if that

[8:07:41] is working. That is working. Cool. All right. Should I get started? Yes. All right. So, let’s get started. Hi everyone. My name is Olivia Tubul. Uh I’m a CTO and co-founder at Gradium and today I’m going to talk about the missing layers of conversational AI. It’s a mysterous title. So, we’ll see what that mean. Uh maybe before we do, let me introduce you uh to who we are at Gradium. So we are a one-year-old startup

[8:08:14] uh focused on training uh voice models. So those acronyms you might have seen if you don’t did not ST means speech to text, TTS text to speech and S2S speech to speech. So all these kind of flavors of models uh we train and serve at Gradium. Maybe before that if I go back to to the genesis of um of Gradium is QAI. So

[8:08:44] maybe you’ve heard of it. I don’t know. Yes, some of you. Great. So CQA is a a Paris-based open science lab that was founded in 2023 with quite some money and a lot of freedom and out of this freedom they you know made some great scientific breakthrough. uh Moshi is probably the most famous and I’ll go back to that a bit later in the presentation uh and of obviously some others but that um I would say the success of those voice models were so

[8:09:15] big that somehow we thought in order to get the you know bigger reach of our research idea we should turn that into products. So the goal of Gradium was really to bridge this gap from research to product and and here we are one year later. So, conversational AI, right? Uh where where do we got that? Actually, today pretty much everywhere you’ve heard about voice agents, whether it’s in gaming, live

[8:09:46] streaming, assistance, robotics, wherever you want to talk to a machine, there is a voice agent involved. And I would like to explain you a bit of the history uh today, not only but part of it. And if I go back to well what I could call provocatively the prehistoric time of voice agents meaning before LLMs uh you probably remember that right I think that was the closest

[8:10:18] um I would say glance at AGI back in the days right it really felt like AGI right that was the iPhone and Siri and Siri was nothing really agi was A very nice uh product, engineering product made of different layers, lots of layers, six of them, sorry. First one is P uh the speech to text the speech recognition. After the audio is turned into text, it was turned into you

[8:10:50] know classification classifiers trying to say what is the intent, what is the object, what is the subject, what is the complement, stuff like that. a dialog manager, uh, some calls to APIs like, you know, check the weather, check the calendar on the phone, stuff like that. Um, [snorts] probably the most, you know, I would imagine template and regex’s intensive part was to generate some text uh for Siri to be spoken out and then the TTS

[8:11:20] would speak it out loud, right? Then what came after was LLMs and I say maybe we don’t need all of that, right? This natural language understanding, those templates all gone. LLM, there’s a bit of a lion here, right? There is still a dialogue manager in modern uh voice agents. And those LLMs, they become stronger, right? And they are now able to connect to the external world. They can interact. They

[8:11:53] can talk to a database, a web search, MCPs, tool calls, retrieval, rag and they became voice agents and that’s what you’re seeing here is actually how I would say 99% of voice agent are working. It’s called the cascaded model ASR or TT ST LLM TTS right they are not trained jointly. Those are three pieces of AI modules that we plug one into the other.

[8:12:26] There is a an extension of this which is okay maybe we don’t need three pieces. Maybe you can just one big model and that’s we call speech to speech and then [snorts] there is no turn taking to take into account. The model itself knows where to speak and when to listen. So this is to give you an overview of what is convers conversational AI. Uh so I can also give you a glimpse of what we do and then I’ll talk about the engineering aspect and the AI aspect of

[8:12:58] what’s under the hood. So what do we do at Gradium? We basically do all of this, right? We do the text to speech, the speech to text, we do the text to speech on device. Uh we do some speechtoech translation. We do some voice design because when you want to say something out loud, you want to say it in some voice. Can be a French accent voice for example or it can be a female voice, high pitch, low pitch, whatever. And coming soon is actually the speech to

[8:13:30] speech. So this talk is called uh the missing layer of voice AI. So what is actually missing? It feels like it’s it’s complete, right? And some people will try to convince you this picture is complete but it’s not. And those are just some examples. It’s not everything. Uh but we’re going to talk more about that. So if you put you know voice AI in the wild, well most likely it’s going to go wild, right? Because most of the um the applications

[8:14:02] do there are more on the phone, one speaker uh you know one computer talking to one another. But put that in real life you get like many speakers. it confuses the agent. Noises confusing the agent long sessions you leave the lose the context and also the real global scale. Uh and what I mean real global scale is like not the ability for anyone to reach your your service but like the ability as that was Siri was doing like everyone on his phone can talk to it

[8:14:34] instead of typing. So underlying those issues are some challenges and I’m going to pick two of them to explain to dig into how how we do and what’s the challenge. So if you want to do um voice models you need to several things. Uh basically you want something that’s fast uh and something you can serve at scale. And so you have

[8:15:04] to think about this fast and at scale this real time at a scale from from the ground up. So it means like designing a model that will be able to scale and that will be able to be to serve fast optimizing the inference and having a serving infrastructure that will support it. I’m going to talk about the first one and the last one. So how do those how does model work? Um, so when you want to design a new model, you don’t start from scratch

[8:15:36] basically, right? You start from something that’s similar and try to adapt. So what you really need for and I’m talking about the speechtoech uh system you need something that will take the speech as it comes and that will be able to take more and more speech as the conversation keep going and that will be able to as soon as possible start speaking in return right and of course there is a one of the requirements that it’s speech in speech out right so even

[8:16:10] if we don’t those models. There are a family of models that is really similar to this and that satisfies two out of those three requirements which are LMS. LMS you take a text in and a text out. So how do they work? You have a context. At the beginning it’s the prompt but then it’s a context. Those are words and the LLM is trained to predict what’s next. Okay. So in that situation gradient is an AI model company based

[8:16:41] what’s next is it in off at blue bird you know it gives a probability to all of them so of course you know in seems to be a good candidate so if you represent it that way at the bottom line this is the context on the top line this is the prediction what’s interesting is that and that’s why it’s called auto reggressive models the next prediction is going to be part of the context at the next round. So you say oop sorry um gradium is unpredicted

[8:17:14] AI AI becomes part of the context and now it can bring a new one and another one and another one and this way on the go you will uh predict and generate a full sentence. So can it work on audio? Feels like it’s the same right? Audio is a sequence sequence to sequence. Why could not it work? Well, there is a dimensionality issue here. Um, the problem with audio is that this text, Grandom is an IMO company based in Paris. It’s nine words. So, like eight words for the context one

[8:17:45] you’re going to predict. It’s 3 seconds when it’s spoken out loud. But 3 seconds of audio, if you represent it on a computer on a normal quality, it will be like 24,000 samples per second. those eight words becomes seven 72,000 sample uh values. So it’s much longer of a sequence. So you have 10,000 times more sequ uh values to predict and since the transformer architecture

[8:18:17] which what’s the LLM is relying upon is relying on self attention which is quadratic. then your uh attention matrix is 100 million times bigger. So it’s not tractable. So the first trick is to turn the audio into tokens. And that’s the neural codec. And actually it turns out you can do that. You can train a model to compress the audio in tokens from 24

[8:18:47] kHz to 12 hertz 12.5. So you divide by 2,00 then you have a tractable number of tokens that’s a sequence and you can start predicting because at the end of the story will decode them into back to audio. So if you wanted to do that to train a dialogue system you could say me I’m the I’m the LLM okay I’m the gray one. So, we have a sequence of me talking, me talking, me talking, you talking, you talking, me talking, blah, blah, blah.

[8:19:18] That’s a sequence and we’re going to predict the next audio tokens, right? But this, sorry, sorry, sorry, sorry. This doesn’t really work like this because in a conversation, it’s not like I talk or you talk. We might be talking at the same time. Otherwise, it’s just like walkie-talkie uh conversation, which which is lame. So in practice you have to invent something new that we don’t have in LLMs is multiream hierarchical transformers. So like now you don’t have a single line

[8:19:48] of time for the context. You have two you have me speaking and you speaking and those two things will attend to to be able to predict what’s next. And so those models they can listen and talk at the same time. Give you an example. Sorry, of course.

[8:20:23] So, the planet is Sirius 22. Can you plot a trajectory course to it, please? >> Yes, sir. >> Okay. How long is it going to take us to get there? >> I’ve mapped it out. It’s approximately 5 months to get there. Okay, that’s that’s not too bad. Uh, do you think we have all we need on board the ship to start the mission? >> Yes, sir. We have everything we need. >> Okay. >> Today, >> okay, I’m going to skip the second one. So, you see like it’s very natural that the model is trained to listen and talk at the same time. So, there is no latency whatsoever. And that was Alex, our chief scientific officer in 2024.

[8:20:57] So now you’re there is something I didn’t tell you is that in 2024 we had this technology at QI but we’re not selling it. So what’s the missing layer here? Well, [snorts] there is something here is that this one model is just one model and it’s capable of um listening, speaking and you know processing language. That’s a lot of things for a very small model. So when you talk to it at some point you will think okay it’s not as good as you know

[8:21:29] the limitation is even worse is that this model is kind of airgapped it doesn’t talk to the external world. So if it doesn’t talk to the world if you cannot act on you know booking an appointment or something in production it’s it’s just a gadget. So the big challenge for speech to speech today is to be able to do seamless integration with tool calling. And if you do that, then you have the same experience while being able to do what a voice agent should do. Okay,

[8:22:00] so that was about how we build a model roughly, not all the recipe. Um, and now let’s say you have the model, you want to scale it and serve it to the world. How do you do that? So here we got the latency problem. So you have one person with his computer. I’m going to take the text to speech example here sending some text to our server and we have to answer some audio back and if you want to plug

[8:22:31] that into a voice agent it has to be fast has to be real time and by real time we mean less than 300 milliseconds. So that’s the latency budget that you have for the whole thing. If you don’t, then it it’s going to be like a weird conversation where you wait for a while before getting an answer and you’re going to be bored. So, it has to be fast. And during that trip, you have actually three layers that you have to go through. One is a transport layer,

[8:23:02] right? Network layer. The information has to travel from point A to point B. Then you have the product layer because like someone sends me a request. I should check this is that legitimate. Does this person uh does this person have the permission the credits? He wants this voice. Do we have this voice? Where is it? And so on and so forth. So you have to enhance the request or deny the request. And then there is a compute.

[8:23:33] So how do we do that fast? So first problem you have to solve is a latency problem. So let’s say I’ve put my server somewhere in Europe and my client is somewhere in the US. Well, just by going round trip through the Atlantic Ocean, I kind of I’m wasting 100 milliseconds, onethird of my budget for just transporting the information. So how do I fix it? Okay, easy. I’m going to put servers everywhere, right? It’s more

[8:24:05] expensive first, but I’m going to reduce the trip from the client to the server. But now I got new issues, right? Because I had the system with no replication and no distribution. Now I have a distributed systems where the information has to be synchronized. Of course, if you want to go fast, you put caches, right? So I put I have a database. I have cache of my database. It’s already an issue per se for you know all the cache invalidation. But now you have many caches that has all to be synchronized alto together.

[8:24:36] Otherwise, you create an API key and you’re going to California. It doesn’t know about the API key. That’s weird. Okay. So, you’re trading latency for complexity, engineering complexity. We can handle it, but still it’s it’s important to be aware of it. Then the second thing which I think is very very new. You know when we started a year ago, we were thinking there is no way if I need a new GPU to handle my request. There is

[8:25:07] no way I can ask my cloud provider for a GPU. He gives me a GPU or she give me a GPU. Uh the GPU is ready and I pull the weights. I pull the Docker image. I warm up the GPU and this going to happen in 300 millconds. Impossible, right? like if you try you you you can maybe make it minutes right today what’s happening so we we never put that as a as an option you have to predict and to be ready for the load but

[8:25:38] now what’s even worse is that the GPU scarcity is so important that you may not be able to have it even like in next day so maybe you want one more GPU but you don’t have this GPU because there is no GPU available in your region because one of the cloud provider are saying sorry there is everyone wants a GPU we don’t have it so how do you handle that so again you’re going to trade you’re going to mitigate this risk with more complexity and there are two things you

[8:26:09] can do the first thing is I’m going to go to different providers there is more the odds the odds to find the GPU is is better or I’m going to try to uh have my model run on different architecture on different models on different chip providers, right? Not only Nvidia or not only H100 or stuff like that. So that I increases the odds of finding a GPU. So again to mitigate that risk, I’m increasing the complexity of my system.

[8:26:40] And how do you handle like burst, right? Because you can uh sometimes everybody wants at the same time uh to be served, right? And there are different strategies you can do and we take two options. First one is to say now let’s take advantage of all those clusters and reroute the traffic from one to the other the closest one. Or you can also do change the batch size of your model. Maybe you can trade a little bit of latency with a bigger batch size right

[8:27:12] for the time where you hit the wave. You increase the batch size and then you decrease it. In practice, if you put all that one after the other, a good model, fast inference, fastly served, that’s what you get. So, we did um we’re building this week a new beta model for text to speech and we did that race where we click somehow at the same time, but we measure the time for uh how much it takes to get the audio back for us and

[8:27:44] some providers. And this is what we we got. >> Hi, I’m Gradium’s newest model and I’m the fastest text to speech we’ve ever built. Faster first audio, more natural conversations, no waiting, and guaranteed speed. Try it today. >> Yeah. So, we’re happy that we’re, you know, pushing the boundaries of of latency. you know, the best models were about like 150 millconds and we made it like three times faster. So, at some

[8:28:16] point there is no there is no limit, right? It’s not never going to be, you know, one zero milliseconds, but we’re happy that we’re able to put all that together uh to make it happen. Now, to close this talk, I’m going to take talk about can we go further? Actually, I’m telling I told you we cannot go zero millisecond and that’s true. But can we go zero milliseconds of travel? Can we go zero milliseconds of product and still have something fast that would scale even

[8:28:47] more? And that’s the idea of moving the compute from the server to the client directly. And for this you have to have very tiny models that can run on your device on your phone on your brother on a raspberry whatever. Uh so we also released like grad phon which is the smallest it’s not exactly the smallest one of the smallest but with a very low u number of parameter 100 million parameter um only uh and a

[8:29:20] very good accuracy and this you can also try feel free to reach out if you want to try those models I’m going to give you a little bit of examples of what it sounds >> only 100 million parameters and I can speak in any voice you give me. >> And here’s an example with a brand new voice cloned from a 10-second sample. >> Okay, we’re going to skip. >> This voice didn’t exist a minute ago. I generated it from a single 10-second recording.

[8:29:51] >> Same model, completely different voice. >> Cloned on the fly from a short clip. >> All right, so that’s that’s pretty much all I wanted to uh tell you about. you know what’s below the hood in in the voice uh AI how we build conversational agents how we train those model how we serve those models and how if we you know put together nice research and nice engineering we can really uh push the boundaries of of conversational AI thank

[8:30:23] you [applause] [applause] >> thank you so much Olivier let’s give it up for Olivia for and Gradium Nice. [cheering] Oh, all right. >> Okay. So, if you follow the QR code that was uh that was shared with you guys, then you can have uh credits, right, to to try out Gradium. All right. Thank you. Okay. So, uh we still have a few

[8:30:54] more things for you guys. So, don’t don’t go don’t leave just yet. Um actually I’ve been working in AI for uh quite some time now. I can’t say that it was a long time but it feels like a long time. And one of the questions that I get the most is what do you think is going to happen to the next generation? And it’s a tough question right because things are moving so fast and it’s already quite hard for us as adults to understand the impact of all this technological change. Um, but luckily for us, there are people that are doing

[8:31:24] something about it. And uh, I I would like to welcome Cassandra Chin, who’s going to tell you more about it. So, please let’s give it up for Cassandra. >> Hi. So, my name is Cassandra Chin and I am one of the kids workshop instructors for AI Engineer Paris. This weekend we ran a kids event where we educated kids and helped teach them to learn about

[8:31:55] technology to prepare them for this AI world. But before I get too much into it, I want to talk a little bit about myself and why I’m so passionate about teaching kids technology. I actually started teaching kids when I was a kid myself. I was 13 years old at the time and I would teach kids workshops over the weekend, Raspberry Pi workshops where kids would get to tinker with different technologies. But even before I started teaching in my

[8:32:26] household, there was lots of technology. We had 3D printers, a lot of different technology. I remember building my own computers. I really believe in inspiring kids to enjoy technology rather than pushing them. Because if you show kids that technology is this very fun thing, not just dad or mom at the computer, like show the kids what technology can actually do. That’s what we really tried to do in these kids workshops.

[8:32:57] And for the kids workshops this weekend, I taught a workshop teaching kids how to code with AI. The kids used Mistral Vibe to build their own games. And I was really surprised at what the kids could do because we have these preconceived notions about how to code, what you can or can’t do, but the kids, they just have ideas. Some ideas they have are like building an RPG game, a platformer,

[8:33:28] a banana game. a lot of creative ideas from kids but they just prompt and the AI could build it for them and with the we had an organization called AI tinkers they brought in a lot of underprivileged kids for uh to the workshop and these kids they they could learn really well like it didn’t matter what background they have and I think it was really great that they also brought in a lot of girls another issue with technology is

[8:34:00] there’s a lot of gender biases. As kids get older and older, they start thinking that technology is a guy’s thing because they see more of the industry. But if you catch kids when they’re very young, they don’t have this idea that technology is a guys thing. And a lot of girls can be inspired to join technology like I have. So I think these kids workshops are really great for kids. The workshop which I taught, we had the kids build the games and we actually

[8:34:30] connected it to a GitHub repo which had a lot of art assets and a agents.mmd file. So this created a more kids safe way with AI because a huge concern is how is it safe to let kids use AI? But with this agents.mmd file, we were able to instruct the AI to act more friendly, use less tech jargon, and be more helpful, run commands rather than asking you to run commands. A lot of

[8:35:01] instructions which make the workshops more kids friendlies. We have this video which we produced about the kids workshop. So if you would please watch it, I think it’s really nice. >> [applause] >> We’re here at AI Engineer Kids Day in Paris teaching the local kids about AI technology, about models, about neural networks. This is a great way to expose kids to AI in a fun way, in an approachable way, and something we love doing at Neo Forj because we’re helping

[8:35:33] train the next generation of AI engineers. There’s a whole mix of kids here uh from a bunch of different backgrounds. Uh some of them are already expert coders at 8 years old and some of them are in their teens and they need a little bit extra help. But that’s kind of what excites me is we’re putting them all in one room. There’s peer-to-peer learning. They’re teaching each other and they’re helping each other so that when they grow up and they start working in the industry, they’ll have a handle on their own lives, their own careers, their own

[8:36:04] ideas. For my workshop, the kids use Mistro Libe and it is a coding agent which lets them create their own games. It’s really interesting what kind of games the kids build. Some of them choose to build an RPG game. Some do platformers. Another kid did a balloon popping game. And what’s interesting is the there’s no language barrier. Even so

[8:36:35] the kids mainly speak French. They can type French to the agent and it fully understands French and still codes the games for them. So I think this was a really good experience for the kids because they got to build their own unique games. So my organization AI tinkers organizes a lot of events and having an event that will bring together the kids and their

[8:37:07] family members. So our usual community members that could be the parent or [music] the big brother or big sister. That sounded really exciting so that they can build together and I believe that’s part of community building. And there’s a reason why we were really excited about doing this.

[8:37:40] [applause] We are running these kids workshops as a part of the AI engineer conference series. So we will be running the next workshop at AI engineer uh New York and also AI engineer code in San Francisco and next year we’ll be running it at London. So if you’re at those events, please bring your kids. We’ll welcome your kids and teach them.

[8:38:10] [applause] >> Thank you. Yeah. Thank you, Cassandra. Let’s give it up one more time. That was awesome. Yeah. Thank you, Cassandra. Thank you, Neil Forj, uh for doing yeah, such a great job. Uh I’m a father myself and I can relate. This is super important work. Um yeah, so thank you one one more time. And uh let’s hear it from you guys as well. Thank you. You you made it. Hey, you made it all the way here, right? I know somebody somebody told me earlier is like, “Hey, you clap too much. My

[8:38:41] hands are hurting.” I’m like, “Hey, dude.” Like we gotta find a Oh, you’re there. You [laughter] recognize yourself. Nice. Yeah. Um, but thank you so much for being with us and I would like to uh thank everybody that helped us organize this event, right? Um, I would like to uh sorry, I would like to thank our sponsors, Mrol first for organizing the event and then Nvidia as our uh platinum sponsor, but also all our gold and uh

[8:39:11] bronze and and silver sponsors. So, let’s give it up for them, please. >> [applause] >> And also I think you should be proud of yourselves. So I I heard that many of you have traveled all the way here from different places. We heard somebody from French, Polynia and then Australia to live and different parts of Europe as well. I think this is so cool that people come from different parts of the world to come and and and be with us here and uh we really appreciate it. So um yeah. So let’s let’s hear it from

[8:39:42] you. Let’s give it up for you. I think you did a good job. Okay, so before we close it out, I uh first of all, I hope I see you next year, but we have one more thing from Patrick and our sponsor, Back Blaze. So, yeah, let’s hear it for Patrick. All right. >> All right, guys. The first thing I’m going to promise you is this will be exactly two minutes. Um, and let’s give it up for how much he claps. Um, because you got to clap one more time. Can you

[8:40:14] do it? All right. So, uh, I’m Patrick from Back Blaze. Great to meet you all. I am buying you drinks tonight. Uh, so I am contractually obligated to explain to you what is Back Blaze. I’m going to do it as simply as I can. Um, I’ll give you one sentence to remember. AI runs on GPUs. GPUs need data. Back Blaze is the best capacity storage tier for AI data. So, if you remember anything, remember that. Two examples. uh Decart uh the

[8:40:44] world model builder. Um when they were getting their start, they uh Dean called me up and he’s like, “Hey, I’ve got 15 pabytes and I’m moving it in days and I haven’t broken you guys yet. You’re awesome.” And I was like, “Awesome. Who are you? What are you doing? I have no idea.” Um but they chose Back Blaze because we don’t charge egress and we have really incredible throughput. So they were able to race different GPU clusters and create incredibly efficient AI training runs. Uh another customer, Cororeweave, we are their object storage

[8:41:16] tier. They chose us because they ran a very exhaustive PC and what they found was that um from exabytes upward um our economics and our performance did not change and so they selected us because they believed we could scale with them forever. So whether you’re working with terabytes or exabytes um we are a great solution uh to ensure that your data is someplace where you control it you can use it how you want to you can use it with who you want to um and uh as an S3

[8:41:46] compatible storage layer that is a quarter the cost of S3 and has free egress you’re going to pay a lot less to do it um like I said our mission which we execute for lots of genai companies and neo clouds and data scrapers and physical AI companies um is use your data however you want, wherever you want, with whoever you want. We are only going to focus on storage and we’re going to make sure every bite is there as fast as you need it. And our primary

[8:42:17] goal is that you spend as little money as possible on storage because after listening to all the talks here for the last couple of days, what you guys are doing is so interesting and storage should be the last of your concerns. So definitely check us out. I will be upstairs. We have a signature uh cocktail, Lebe Blaze. Very original. Um try one, talk to me. And if you are early stage, we also have a startup program where we offer up to $100,000 in

[8:42:48] storage credits, which if you can do the math, we’re a quarter of the cost of S3 is going to last uh a good amount of time depending on how fast you’re growing. So, thank you everyone. Thank you again to AI Engineer and Mistl and all of the sponsors and especially thanks to you guys. I flew here from Minnesota two nights ago. I’m flying back tomorrow morning. I’m exhausted. I have to go take care of my kids. I know how hard this is, but I think it was totally worth it. So, thank you, and we’ll see you upstairs.