O que há de novo em engenharia de inference — Philip Kiely, Baseten

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: What’s New in Inference Engineering — Philip Kiely, Baseten · Canal: AI Engineer · 18:47 · Assistir no YouTube

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

Resumo

Philip Kiely apresenta novidades em engenharia de inference desde a publicação de seu livro, Inference Engineering, e revisita princípios que orientam a área. Ele compara inference local com inference em data centers e destaca três frentes de otimização: quantização, gerenciamento do KV cache e speculative decoding. Discute as limitações do TurboQuant em workloads de produção, apresenta métodos de compactação do KV cache e explica avanços como DFlash e o retreinamento contínuo de modelos especuladores. Para o futuro, aponta a importância de NVFP4, da comunicação entre partes do sistema e do treinamento voltado à inference.

Pontos-chave

• Inference local prioriza fazer o modelo funcionar no hardware disponível, enquanto inference em data centers busca aumentar o desempenho e reduzir a latência em escala.
• O ciclo entre inference mais rápida e treinamento de modelos melhores torna cada vez menos nítida a separação entre treinamento e inference.
• TurboQuant reduz o KV cache para quatro bits, mas o custo computacional adicional pode reduzir em mais da metade os tokens por segundo em workloads de produção.
• Métodos como roteamento, offloading e compartilhamento do KV cache podem ser alternativas à sua compressão em ambientes de data center.
• STILL usa um gargalo treinável para condensar o KV cache em uma representação compacta que o LLM pode consultar.
• DFlash usa um modelo de difusão para gerar vários tokens especulativos por etapa e pode superar métodos anteriores em aceitação de tokens e tokens por segundo.
• DSpark combina um modelo de difusão com um modelo sequencial, mas ainda não havia resultados de produção disponíveis na apresentação.
• O retreinamento contínuo do modelo especulador com dados do sistema pode melhorar a taxa de aceitação de tokens, embora exija armazenamento, compute e permissões adequadas.
• NVFP4, comunicação entre componentes do sistema e treinamento voltado à inference são tendências que podem ganhar importância.

Capítulos

Início	Capítulo	Resumo
00:12	Princípios e contextos de inference	Philip Kiely apresenta seu livro, distingue inference local de inference em data centers e explica como treinamento e inference estão cada vez mais interligados.
04:50	Quantização e TurboQuant	A palestra revisa a quantização e explica por que o custo computacional do TurboQuant pode limitar seu uso em workloads de data center.
09:28	Compactação do KV cache	Kiely descreve o papel do KV cache e apresenta o método STILL como uma abordagem treinável para compactar essa memória.
12:02	Avanços em speculative decoding	A palestra compara métodos de speculative decoding, detalha DFlash e DSpark e discute os ganhos possíveis com retreinamento contínuo.
16:43	Perspectivas para a engenharia de inference	Kiely prevê maior relevância para NVFP4, comunicação entre componentes do sistema e treinamento voltado à inference.

Citações

Por que escrever um livro sobre algo que está mudando tão rápido? — 01:14

Você obtém inference mais rápida, o que gera mais dados, que você usa para treinar um modelo melhor. — 04:20

Isso é uma troca inaceitável para muitos casos de uso em produção. — 07:26

Você pode observar uma melhora de 20% a até 2x nas taxas de aceitação de tokens. — 16:12

Conceitos e entidades

• Philip Kiely (pessoa): Engenheiro e autor de Inference Engineering, que apresenta as novidades discutidas na palestra.
• Baseten (empresa): Empresa associada à equipe de pesquisa e aos trabalhos de engenharia de inference mencionados na palestra.
• Inference Engineering (conceito): Livro de Philip Kiely que reúne princípios e técnicas de engenharia de inference.
• TurboQuant (conceito): Método de quantização que representa o KV cache com quatro bits, reduzindo seu uso de memória, mas adicionando computação durante a geração.
• KV cache (conceito): Memória que armazena cálculos de atenção já realizados para reutilizar prefixos e acelerar a geração.
• STILL (conceito): Método treinável de compactação do KV cache que produz uma representação comprimida para o LLM consultar.
• DFlash (conceito): Método de speculative decoding baseado em difusão que gera sequências de tokens especulativos.
• DSpark (conceito): Método de speculative decoding que combina um modelo de difusão com um modelo sequencial.
• NVFP4 (conceito): Formato de quantização citado como foco para quantizar pesos e aproveitar o desempenho de sistemas futuros.
• NVIDIA Dynamo (ferramenta): Ferramenta mencionada para movimentar o KV cache entre componentes do sistema e fazer offloading.

Tradução completa (pt-BR)

00:12 Estou aqui para falar sobre as novidades em engenharia de inference. Oi, sou Philip e estou aqui porque escrevi um livro. Este é meu terceiro ano na AI Engineer World’s Fair. Esta é minha conferência favorita no mundo inteiro. É o ponto alto do calendário todos os anos. Foi aqui, em 2024, que comecei de verdade como palestrante e engenheiro. Voltei em 2025 e fiz várias coisas. E estou aqui de novo. Adoro este lugar e sou muito grato aos organizadores por sempre me convidarem. Escrevi este

00:44 livro chamado Inference Engineering. Nós o publicamos há três ou quatro meses e fiquei impressionado com a repercussão. Já tivemos mais de… sim, publiquei o livro em 23 de fevereiro. Até agora, tivemos mais de 11 mil cópias impressas. Estamos chegando a 30 mil cópias digitais, e 24 milhões de pessoas no mundo — ou 24 milhões de contas no Twitter. Vamos ver quantas pessoas isso representa de fato — viram algum conteúdo de Inference Engineering.

01:14 E, com toda essa ótima recepção, houve uma pergunta que as pessoas me fizeram: por que diabos você faria isso? Por que escreveria um livro sobre algo que está mudando tão rápido? Bem, acredito que muitos dos princípios da engenharia de inference já estão bastante consolidados e que há muito que podemos aprender e repetir a cada geração de modelos. Mas hoje estou aqui para falar sobre as novidades em engenharia de inference. Esta é a

01:45 primeira adição pública com todas as informações novas desde o lançamento do livro. Vamos revisar um pouco os princípios da engenharia de inference e depois falar sobre tudo o que aconteceu no mundo de inference desde 23 de fevereiro de 2026. Vamos falar sobre o que aconteceu com TurboQuant. Também vamos falar um pouco sobre compactação de KV. Vamos dedicar bastante tempo ao Deflash e a outras novidades empolgantes em speculative decoding. Depois, vou fazer algumas previsões, falar um pouco sobre o que acho que

02:16 vai acontecer em inference daqui para a frente e sobre o que me entusiasma. Espero poder falar disso na próxima vez que vocês me virem aqui no palco. Legal. Vamos começar. Uma coisa que tenho percebido, depois de inúmeras conversas com pessoas sobre inference, é que há um punhado de princípios em comum. Um dos principais surgiu quando participei de um podcast outro dia. Conversamos sobre inference e sobre dois tipos de engenharia de inference que realmente se destacaram.

02:48 Há a inference local, em que a estratégia predominante é simplesmente fazer o modelo funcionar no hardware que você tem, comprimindo-o com quantização, distillation, pruning, da maneira que puder, e dividindo-o entre as GPUs que tiver em casa. Primeiro, você faz o modelo funcionar e depois tenta deixá-lo menos burro. Você corrige os problemas catastróficos que essa compressão do modelo criou e tenta recuperar a inteligência de referência, executando-o com

03:18 batch size um. E depois há o meu mundo: o mundo do batch size e dos data centers. Nele, você faz o modelo funcionar — simplesmente coloca a build do VLM para rodar no primeiro dia — e depois tenta deixá-lo menos lento, usando coisas como roteamento com reconhecimento de KV, speculative decoding, disaggregation e assim por diante. Acho que esses dois mundos têm muito a aprender um com o outro. Nesta palestra, vou me concentrar nos avanços da engenharia de inference voltada a data centers, porque é o que conheço, mas há muita coisa interessante acontecendo também no mundo da

03:50 inference local. No livro Inference Engineering, em geral, parto do pressuposto de que os pesos são um produto finalizado. Acho importante ter em mente a transição do treinamento para a inference, e essa é uma boa maneira de delimitar o tema. No entanto, tenho percebido cada vez mais que muitas otimizações de inference vêm de um processo de treinamento dedicado. Assim, as fronteiras entre treinamento e inference estão cada vez mais

04:20 difusas. É algo interessante de se ter em mente. Estamos vendo este ciclo: inference mais rápida gera mais dados, que são usados para treinar um modelo melhor; esse modelo permite uma inference mais rápida, que gera mais dados, e assim por diante, até você ficar muito rico. Com o treinamento para inference, temos várias técnicas novas para discutir nas três grandes áreas, como gosto de chamá-las. Vamos falar de algumas novidades em quantização, algumas novidades em caching — especificamente, no mecanismo de KV cache —

04:50 e algumas novidades em speculative decoding. Há muitas outras coisas no mundo de inference, incluindo algumas sobre as quais vou falar no final. Mas, para o trabalho prático do dia a dia, quando a pergunta é “como faço o modelo X ficar mais rápido?”, essas costumam ser as três técnicas que as pessoas adotam. Então, publico um livro em fevereiro e fico muito satisfeito comigo mesmo. Penso: “Nossa, tudo o que você precisa saber sobre inference está reunido em um só lugar.” Aí surgiram novidades no

05:23 mundo da quantização. Só para recapitular rapidamente: quantização é quando usamos um formato numérico menor e menos preciso para economizar largura de banda e computação, melhorar o TTFT e melhorar o TPS. Em geral, depende do hardware e reduz custos, mas pode degradar um pouco a qualidade do modelo. Aliás, se quiser ouvir toda a minha fala sobre quantização, fiz uma palestra na AI Engineer Miami no mês passado

05:53 sobre como a quantização não é necessariamente tão ruim quanto parece e sobre as várias coisas que você pode fazer para preservar a qualidade durante esse processo. Eu estava satisfeito com a forma como tinha abordado a quantização, mas aí 20 milhões de pessoas viram o TurboQuant e, na verdade, isso chegou a causar uma queda momentânea no índice de ações de memória, porque todo mundo pensou: “Ah, a memória vai ficar muito mais eficiente agora; não precisamos de mais memória flash.” Isso estava errado, mas enfim, era uma nova

06:23 abordagem de quantização, popularizada em março deste ano, que usa coordenadas polares para quantizar e permite reduzir o KV cache a quatro bits. Foi um sucesso enorme, e eu pensei: “Nossa, deixei todo esse assunto de fora. Como será que isso vai funcionar?” Então, nossa equipe pesquisou bastante o tema. Se você conhece, um salve para o estagiário da Waterloo no Twitter. Ali, da nossa equipe de desempenho de modelos. Não

06:55 sei se ele ainda é estagiário, na verdade. Mas sim, ele é da Waterloo. Enfim, ele escreveu um ótimo texto sobre a matemática por trás do TurboQuant. Basicamente, a vantagem do TurboQuant é que você pode representar o KV cache com quatro bits em vez de oito. Você usa metade do espaço e metade da largura de banda, e efetivamente dobra a largura de banda ao mover o KV cache pela memória do sistema. Mas a desvantagem do TurboQuant é considerável. Acontece que você precisa fazer computação adicional na passagem forward para

07:26 compensar isso durante a etapa de decode, e o TPS cai mais da metade. Esse é um custo-benefício inaceitável para muitos casos de uso em produção. Analisamos o TurboQuant com bastante atenção, mas não o estamos usando em nenhuma dessas cargas de trabalho reais. Continuamos usando a quantização tradicional NVFP4. Dito isso, na verdade é uma ótima técnica para quem trabalha com inference local. Então, se você estiver executando um modelo, especialmente um modelo de linguagem com contexto longo, no seu computador local, nas suas

07:56 Na Baseten, você tem uma quantidade muito limitada de memória; esse é o principal gargalo. Portanto, qualquer coisa que possa liberar memória do KV cache e permitir armazenar sequências mais longas nele será muito valiosa, e o cálculo adicional da passagem forward será menos desvantajoso. Então, Turboquant ainda é um excelente artigo de pesquisa, uma técnica muito boa que acabou não sendo tão aplicável ao mundo da inference em data centers quanto talvez parecesse à primeira vista.

08:27 Em vez disso, estamos focados no NVFP4, com ênfase em quantizar os pesos, em vez do KV cache. Estamos fazendo o possível para identificar problemas nos pesos quantizados e garantir que não estejamos achatando as distribuições de probabilidade do próprio KV cache. Em vez disso, estamos nos concentrando em roteamento com reconhecimento do KV, transferência do KV para fora da GPU e compartilhamento do KV, usando o NIXL, o Nvidia Dynamo e outras ferramentas para mover o KV cache pelo sistema e, potencialmente,

08:57 transferi-lo para a CPU, para a memória comum etc., em vez de tentar comprimi-lo com Turboquant. Também estamos focados em quantização entre modalidades. Estamos pensando em como aplicar os benefícios do NVFP4 não apenas a modelos de linguagem, mas também a modelos de imagem e vídeo. Ali também escreveu muitas coisas ótimas sobre isso no Twitter, que vocês deveriam conferir. Dito isso, o KV cache ainda é muito importante. Vamos falar dele. Vamos falar sobre

09:28 compactação do KV. Uma revisão rápida: o KV cache. Se você inserir o mesmo prompt com o mesmo prefixo, poderá reutilizar os tokens cujo prefill foi calculado da última vez. Isso torna o sistema inteiro mais rápido e eficiente. Em linhas gerais, o KV cache é uma memória sem perdas. Existem apenas algumas fontes de memória sem perdas. Ao pensar no nosso sistema de inference, temos o conteúdo do prompt, o contexto e o KV cache, que cresce linearmente com a quantidade de dados que você insere. E agora, se você estiver pensando

09:58 em sequências com, digamos, um milhão de tokens, isso se torna bastante substancial. Por isso, muita gente está pensando em como comprimir a memória, em como comprimir o contexto. agent harnesses comprimem o contexto. A busca com RAG e todas essas técnicas sobre as quais falamos há anos são uma forma de comprimir um contexto maior em algo que você pode fornecer a um modelo. Você pode gravar em arquivos. Todas essas coisas crescem de forma sublinear em relação à quantidade de dados que você tem. Mas e se houvesse uma opção intermediária? E se houvesse uma maneira de

10:30 comprimir bastante os dados que você está armazenando, mantendo quase toda a informação? Temos muitas maneiras diferentes de pensar no que manter no cache. Métodos recentes de compactação mostraram que podemos substituir o cache por um muito menor. Temos artigos como Attention Matching e Cartridges, que apresentaram resultados muito promissores, com altas taxas de compressão. Mas os dois são executados durante a inference. Mais uma vez, uma das técnicas sobre as quais

11:00 quero falar, ou um dos temas que quero abordar, é o treinamento para inference. Neste caso, quero apresentar algo chamado STILL, da equipe de pesquisa da Baseten, em que a síntese sobre o cache — na qual mantemos uma representação aprendida da informação, em vez da própria informação ou de uma espécie de subconjunto determinístico dela — é amortizada por meio do treinamento. Charlie e Mudith, da nossa equipe de post-training, fizeram recentemente uma excelente palestra no quadro branco no Kosa Compile.

11:30 Ela está no YouTube. Então, recomendo que assistam se tiverem interesse em aprender sobre compactação do KV. Infelizmente, não tenho tempo nem genialidade para explicar tudo aqui. Mas o mecanismo básico é que STILL é um gargalo perceptual que recebe um conjunto fixo de vetores de consulta aprendidos, faz com que eles prestem atenção cruzada ao KV cache completo e produz um conjunto de chaves e valores compactos em uma única passagem forward. Isso cria uma memória comprimida, rápida e diferenciável, à qual

12:02 o LLM pode prestar atenção como se fosse contexto real. Então, se vocês tiverem interesse em compactação do KV, confiram o trabalho de Charlie e Mudith. Tem sido realmente muito interessante aprender sobre isso. Essas são duas das técnicas. Falamos de quantização. Falamos de caching. A última é especulação. E houve muitas mudanças nessa área. Como revisão: na decodificação especulativa, usamos tokens de rascunho. Vamos verificá-los durante a passagem forward e usá-los para gerar mais de um

12:32 token por passagem forward. Isso ajuda muito com tokens por segundo e é uma otimização totalmente sem perdas, o que é ótimo, porque não precisamos nos preocupar com a qualidade. Na história da especulação, começamos com a decodificação especulativa. Tudo isso está no livro. Temos o Spec, em que usamos um modelo pequeno da mesma família para gerar tokens de rascunho. Acontece que modelos pequenos não são bons geradores de tokens de rascunho. Eles são ótimos como modelos pequenos. Então, como setor, inventamos vários métodos novos, como o Medusa, em que

13:04 talvez você simplesmente acrescente cabeças de decodificação ao modelo, e depois surgiu o Eagle 3, com a ideia de: e se, em vez de pegar um modelo minúsculo da mesma família, treinássemos um modelo de um bilhão de parâmetros com os estados ocultos do modelo-alvo para gerar tokens de rascunho? E isso funcionou muito bem. Então, por volta de fevereiro do ano passado — ou de fevereiro deste ano —, o Eagle 3 era o melhor método de especulação. Agora temos o DFlash. O DFlash é ainda melhor. É difusão para especulação.

13:35 O DFlash cria uma sequência de tokens de rascunho, em vez de um único token. O modelo é um modelo de linguagem de difusão, o que significa que cria uma sequência inteira de tokens, da mesma forma que a geração de imagens ou vídeos cria uma sequência de quadros ou de pixels e vai iterando sobre ela, em vez de gerar tokens de forma autorregressiva. Os modelos DFlash podem ser duas ou quatro vezes mais lentos para executar, mas vão prever oito ou 16 tokens de uma só vez nessa janela, enquanto o Eagle faz apenas

14:06 um por vez. Então, uma única passagem forward do DFlash é mais rápida do que toda a sequência de rascunho do Eagle e prevê mais tokens. Esses tokens conseguem prestar atenção cruzada uns aos outros e, em geral, geram uma taxa de aceitação maior, porque, na especulação, a taxa de aceitação é tudo. Em uso real, estamos vendo uma melhoria de mais de 3x com o DFlash. Isso foi medido com um único B200 e um Qwen3-8B. Podemos compará-lo ao Eagle: há uma melhoria substancial

14:37 tanto na taxa de aceitação de tokens quanto nos tokens por segundo. Esses modelos DFlash são treinados com uma máscara de atenção para geração de rascunhos bidirecional. O modelo-alvo fornece o contexto. Dentro de cada bloco, temos um subconjunto de tokens limpos que são amostrados, e a máscara de atenção impõe consistência causal. Mas ela ainda permite atenção bidirecional, ao contrário de um modelo autorregressivo tradicional,

15:08 em que você só olha para os tokens em uma única direção. É por isso que conseguimos aproveitar essa arquitetura baseada em difusão. E eu achei que tinha terminado, mas, há alguns dias, saiu o DSpark. Já temos o DFlash funcionando em produção. O DSpark é uma pesquisa nova. Então, por enquanto, basicamente só posso dizer: ele existe, é interessante e estamos analisando. A diferença em relação ao DFlash é que ele ainda tem esse modelo de difusão, mas também o combina com um modelo sequencial. A ideia

15:40 é melhorar os pesos de aceitação fazendo esses dois modelos trabalharem juntos, em vez de usar apenas o especulador iterativo, apenas o especulador de difusão ou apenas o especulador autorregressivo. O DSpark é muito empolgante, mas ainda não temos resultados de produção para compartilhar. Tomara que tenhamos esses resultados da próxima vez. Mas temos resultados de produção para o retreinamento contínuo do especulador. Então, voltamos ao DFlash. E a ideia é que

16:12 Como você sabe, a decodificação especulativa depende muito do conteúdo específico dos prompts e das respostas que você está analisando no seu sistema. Então, se você retreinar continuamente com esses prompts e respostas no seu sistema em produção, pode observar uma melhoria de 20% até mesmo a 2x nas taxas de aceitação de tokens. Na verdade, isso é muito difícil de fazer. Exige muito armazenamento, e você precisa garantir que tem permissão para usar os dados que está processando dessa forma. Também exige uma quantidade enorme de computação, e você precisa transferir todas essas informações

16:43 de um lado para outro. E, se mudar o modelo subjacente, também precisa mudar o modelo especulador. Mas, quando penso no futuro, acredito que a especulação contínua será uma otimização que valerá a pena para sistemas de escala muito, muito grande. Então, o que vem a seguir na inference? O que vem a seguir é uma opinião pessoal, especulação e informações públicas; se eu soubesse de algo que realmente estivesse para ser lançado, não poderia falar sobre isso. Então, isso é só

17:14 o que acho que vai acontecer. Já passei por três ciclos de hardware: o lançamento do Ampere, o lançamento do Hopper e o lançamento do Blackwell. E sempre leva tempo desde o envio desses chips até sua instalação nos data centers e até que toda a stack de software consiga realmente aproveitar os recursos deles. Mas algumas coisas que me empolgam são: com o Rubin, parece que o desempenho do NVFP4 vai ser fantástico. Então, quanto mais conseguirmos

17:45 adotar honestamente técnicas de inference local e ganhar confiança ao executar modelos nesse formato de dados NVFP4, mais poderemos aproveitar o excelente desempenho dos próximos sistemas Rubin. Acho que a desagregação e a comunicação em todo o sistema serão cada vez mais importantes. Estamos vendo ganhos iniciais muito bons com a desagregação de PD, e a capacidade de mover informações, como dados do KV cache, pelo sistema será cada vez mais importante. E, como eu disse, o tema do treinamento para inference

18:17 continuará tendo um grande impacto no setor daqui para a frente. Então, muito obrigado a todos por virem à palestra. Estou no Twitter e no LinkedIn, e estou distribuindo livros de graça. Vocês podem baixar um PDF pelo QR code ou vir comigo até o estande da Baseten para pegar uma cópia gratuita de Inference Engineering. Temos vários por lá, talvez o suficiente para todo mundo. Se não, vamos pedir a um colega para trazer mais do escritório. Então, sim, vou estar lá embaixo, no estande da Baseten

18:47 Obrigado a todos e tenham um ótimo dia. [aplausos] >> [música]

Transcrição original

[00:12] Um I am here to talk about what is new in inference engineering. So hi I’m Philip and I’m here because I wrote a book. Uh this is my third year at the AI engineer worlds fair. This is my favorite conference in the entire world. It’s the highlight of the calendar every single year. I really got my start as a speaker and as an engineer here in 2024. I came back in 2025 and did a bunch of stuff. I’m here again. I love it here and I’m very thankful to the organizers for always having me. Um I wrote this

[00:44] book called Inference Engineering. We published it three or four months ago and I’ve just been overwhelmed by the response. Uh we’ve done more than uh I yeah I published it in on February 23rd. Um at this point we’ve done more than 11,000 paper copies. We’re coming up on 30,000 digital copies and 24 million people around the world or 24 million Twitter accounts. So we’ll see how many people that actually is um have seen something out of inference engineering.

[01:14] And with all of this, you know, great reception, there has been one question that people have been asking me. Why in the world would you do this? Like why would you write a book about something that’s changing so fast? Well, you know, I believe that a lot of the principles of inference engineering at this point have been pretty solidified and there’s a lot that we can, you know, learn and and kind of repeat over generation and generation of model. But today I’m here to talk about what’s new in inference engineering. This is the

[01:45] first public addendum of all new information since the book came out. We are going to review the inference engineering principles a little bit and then we’re going to talk about all the stuff that’s happened since February 23rd of 2026 in the inference world. We’re going to talk about what happened to Turboquant. Talk a little bit about KV compaction. We’re going to spend a lot of time on deflash and some other new exciting things in speculative decoding. And then I’m going to do a little bit of prognosticating, a little bit of forecasting of what I think is

[02:16] going to happen in influence coming up here and what I’m excited about. You know, hopefully being able to talk about next time you guys see me up here. Cool. So, let’s get started. So, you know, one thing I’ve been identifying now out of tons and tons of conversations with people about influence is a handful of of shared principles. And one of the big ones I was on this uh podcast the other day with uh so uh we were talking about inference and you know there’s two types of inference engineering that have really emerged.

[02:48] There’s local inference where the overwhelming strategy is just get it working on whatever hardware you have by squishing the model with quantization, distillation, pruning, however you can, you know, splitting it across whatever GPUs you happen to have in your house. And first you get it working and then you make it less dumb. you take away whatever you know catastrophic issues all of this compression of the model has created and you try and get it back to that baseline intelligence running at a

[03:18] batch size of one and then there’s there’s my world which is the batch size and data center world where it’s get it working you know just day zero get the build of VLM up get it working and then make it less slow do stuff like KVAware routing speculation disagregation and you know with within these two worlds I think that we a lot to learn from each other. I am in this talk going to be focused on advances in data center oriented inference engineering because that’s what I know but there’s a lot of really cool stuff happening in the local

[03:50] world as well. So in the book in inference engineering I generally assume that the weights are a finished product and I do think that the handoff from training to inference is an important one to keep in mind and it’s a good way of kind of delimiting the space. However, what I’ve found more and more recently is that many optimizations for inference come from a dedicated training process. And so the lines between training and inference are getting blurriier and blurriier. And

[04:20] that’s an interesting thing to keep in mind. We’re seeing this cycle where you get faster inference, which gives you more data, which you use to train a better model, which gives you faster inference, which gives you more data, and you just kind of like keep doing that until you’re super rich. Uh so with with training for inference uh we have a bunch of new techniques to talk about across what I like to call the big three. So we’re going to talk about some news in quantization, some news in caching, specifically the the KV cache

[04:50] mechanism, and some news in speculation because these are, you know, there’s a lot of other stuff in the world of inference, including some stuff I’m going to talk about at the end. But when it comes to the practical day-to-day of how do I make X model faster usually these are the three techniques that people are reaching for. So first thing I publish a book it’s February I’m feeling awesome about myself. I’m like wow everything you need to know about influence in one place. And then uh we uh we had some news in

[05:23] the quantization world. So just as a quick review, quantization is when we use a smaller, less precise number format in order to save ourselves on bandwidth, save ourselves on compute, make TTFT better, make TPS better. Uh, it’s usually kind of hardware specific, gives you cost savings, but potentially degrades model quality a little bit. And by the way, if you want to hear my whole rant about quantization, I did a talk at AI Engineer Miami last month

[05:53] about how quantization is is not necessarily as evil as it sounds and that there’s many things you can do to preserve quality through that process. So I was feeling good about my treatment of quantization and then 20 million people saw Toboquant and in fact it like made the memory stock macro dip for for a minute just because everyone was like oh memory is going to be so much more efficient now like we don’t need any more flash memory uh which which was wrong but anyway it was this new

[06:23] quantization approach um that was popularized in March of this year that uses polar coordinates for quantization and allows you to quantize the KV cache down to four bits. And it was like super hot and I was like, “Oh man, like there’s this whole thing that that I left out.” And like what what is this going to look like? And so our team did a bunch of research on this. Um this is if you know uh shout out Waterlue intern on Twitter. Um Ali from our model performance team. Um I’m

[06:55] not sure if he’s still an intern actually. Uh but yeah, he is from Waterlue. Um anyway, so he he wrote this great piece about the math behind turboquant. And basically the benefit you get out of turboquant is that you get to represent the KV cache with four bits instead of eight bits. You save half the room and half the band and and you get effectively double the bandwidth when you’re moving KV cache around in your system memory. But the drawback is pretty big um for turboquant. Turns out that you need to do additional computation in the forward pass to

[07:26] account for this during decode and it cuts TPS by more than half and that’s just an unacceptable trade-off for a lot of the production use cases. So we we took a good hard look at toocquant but but are not using it for you know any any of these real workloads. We’re we’re still on the traditional NVFP4 quantization. That said it actually is a great technique for the local inference folks. So if you are running a model especially a long context language model on your local computer on GPUs in your

[07:56] basement um you have a very limited amount of memory that’s the number one bottleneck and so anything that can free up memory from KV cache and allow you to put those longer sequences on there is going to be very valuable and the additional forward pass computation is going to be like less of a a drawback. Um, so still Turboquant is a fantastic research paper, a really great technique that just ended up not being as applicable in the data center inference world as it might have first appeared.

[08:27] Um, you know, instead we’re focused on, you know, NVFP4 with a focus on quantizing the weights versus the KV cache. Um, you know, doing our best to find rough edges in the quantized weights. um make sure that we’re not flattening out of probability distributions for the KV cache itself. Focusing instead on KV aware routing, KV offloading, KV sharing using uh you know nickel and using Nvidia Dynamo and other tools in order to move the KV cache around the system and potentially

[08:57] offload to CPU, ordinary memory, etc. um versus trying to use uh to Turboquant to to compress it. Um and then we’re also focused on quantization across modalities. Um so thinking about how can we apply the benefits of NVFP4 not only to language models but also to you know image and video models. Ali also wrote a lot of great stuff on Twitter about that which you should check out. So that said the KV cache is still very important. Let’s talk about it. Let’s talk about KV

[09:28] compaction. Again quick review. KV cache. If you put in the same prompt with the same prefix, uh you get to reuse the tokens that you calculated prefill on last time. That makes your whole system faster and more efficient. Broadly, KV cache is lossless memory. There’s only a couple sources of lossless memory. When we think about our inference system, we have the content of the prompt, the context, you have the the KV cache, and that’s going to scale linearly with the amount of data you pass in. And now if you’re thinking

[09:58] about you know million token sequence lengths uh that actually gets pretty substantial. So a lot of people are thinking about how do you compress memory? How do you compress context? Agent harnesses will compress context. Rag search all these techniques that we’ve been talking about for years are a sort of compression of a larger context into something that you can give to a model. You can write to files. All of these things scale sublinearly with the amount of data that you have. But what if there was a middle load? What if there was a way where you could get

[10:30] quite a bit of compression in the data that you remembering with near lossless information retention? So we uh you know we have a lot of different ways that we can think of what to keep in the cache. You know recent compaction methods have shown that we can replace the cache with a much shorter one. We’ve got papers like attention matching and cartridges that have given really promising uh outcomes here with uh high compression ratios. But both of these are run at inference time. Again, one of the techniques I

[11:00] want to talk about or one of the themes I want to talk about is training for inference. So in this case I want to introduce something called still by the base 10 research team where the synthesis on top of the cache where we’re keeping a loaned representation of the information rather than a the information directly or a sort of deterministic subset of it is amotized via training. So Charlie and Mudith from our post training team did a fantastic chalk talk at Kosa compile recently. Um

[11:30] it’s up on YouTube. So I would encourage you to take a look at it if you’re interested in learning about KV compaction. Um I do not unfortunately have the time or the genius to explain everything up here. Um but the the basic mechanism is that still is a perceivable bottleneck um that takes a fixed set of loan query vectors crossends it against the full KV cache and produces a set of compact keys and values in a single forward pass. This creates a fast differentiable compressed memory that

[12:02] the LLM can attend to as if it was real context. So if you’re interested in KV compaction, definitely check out Charlie and Mudith’s work. Um it’s been a really fantastic thing to learn about. So that’s two of the techniques. We’ve talked about quantization. We’ve talked about caching. The final one is speculation. And there’s been a lot of change here. Um as a review, uh speculative decoding, we’re going to use draft tokens. We’re going to verify them during the forward pass and we’re going to use that to generate more than one

[12:32] token per forward pass. It helps a lot with tokens per second and it is a fully lossless optimization which is great because we don’t have to worry about quality at all. Now in in the sort of history of speculation we started with speculative decoding. All of these are in the book. Um you have spec where you use a small model from the same family to generate draft tokens. Turns out small models are like not great draft token generators. They’re great small models. So we invented as an industry a bunch of new methods like Medusa where

[13:04] maybe just you add decoder heads to the model and then eventually Eagle 3 which was hey what if instead of taking a tiny model from the same family, we actually train a billion parameter model on the hidden states of the target model to generate draft tokens. And that actually worked really well. And so, you know, as of of maybe February last year of of February of this year, Eagle 3 was the best method in speculation. Now, we got Dlash. Dlash is even better. So, it’s diffusion for speculation. Uh,

[13:35] Dlash creates a sequence of draft tokens instead of a single token. So the model is a diffusion language model which means it creates a whole sequence of tokens in the same way that a video or image generation creates a sequence of frames or a sequence of pixels and iterates over it rather than doing a auto reggressive token generation. Dlash models might be two or four times slower to run, but they’re going to predict eight or 16 tokens at once um in that in that window while Eagle is only doing

[14:06] one at a time. So a single D flash forward pass is faster than the entire eagle draft phrase and predicts more tokens. These tokens are able to cross attend to each other and generally create a higher acceptance rate because in speculation acceptance rate is everything. So in the wild we’re seeing a more than 3x improvement uh from deep flash. Um this is measured with a single B200 quen 38B. Um and we can see it versus Eagle. It’s a substantial

[14:37] improvement in the tokens uh both the token acceptance rate and the tokens per second. These deflash models are trained with a attention mask for birectional drafting. Um so the target model is going to provide the context. Um and within each block we’re going to have a subset of clean tokens that are sampled and the attention mask is going to enforce causal consistency. Uh but it is still going to allow for birectional attention. um where in you know a traditional auto reggressive model

[15:08] you’re only looking at the tokens in a single direction. So that’s why we’re able to you know take advantage of this diffusionbased architecture and then you know I thought I was done and then a couple days ago uh DSpark came out. Now Dlash we do have up and running in production. Uh DSpark is is new research. Um so this one I can basically only say like hey it exists. It’s cool. We’re looking at it. Um the difference versus Dlash, it still has that diffusion model, but it also pairs it with a sequential model. And the idea

[15:40] is that we’re going to improve acceptance weights um by having these two models work together rather than having just the iterative speculator uh just the diffusion speculator or just the auto reggressive speculator. So DSpark very exciting um but we don’t have any production results with it yet to share. Um hopefully you know we’ll have those for next time. Um what we do have production results though on is continuous speculator retraining. So this is we’re back to Dlash here. Um and this is the idea that

[16:12] you know speculative decoding is very dependent on the actual content of the prompts and responses that you’re looking at in your system. And so if you are continuously retraining on those prompts and responses in your live system, you can see a 20% to even 2x improvement in your token acceptance rates. This is actually like really hard to do. Uh it takes a lot of storage and you have to make sure that you have permission to use the data that you’re processing in this way. Uh it takes a ton of compute and you have to move all

[16:43] of this information around. And if you change the underlying model, you also have to change the speculator model. But when I look forward into the future, I do think that continuous speculation for very very large scale systems is going to be a worthwhile optimization. So what is next in inference? Um the following is like personal opinion and speculation and public information and like if I knew anything that was actually coming out, I wouldn’t be able to talk about it. Um so so this is just

[17:14] like what I think is going to happen. You know I’ve been through three hardware cycles um through the Ampio release, the Hopper release, the Blackwell release. Um and it always takes time for you know when these chips get shipped to when they get installed in data centers when the entire software stack really is able to take advantage of their capabilities. But some things that I’m excited about are, you know, with with Reuben, it looks like the NVFP4 performance is going to be fantastic. So the more we can like

[17:45] honestly borrow techniques from local inference and get a lot of confidence running models in this NVFP4 data format, the more we’re going to be able to take advantage of the awesome performance of of the upcoming Ruben systems. I think that like disagregation and systemwide communication is going to be increasingly important. um we’re seeing really excellent early gains from PD disagregation and the ability to you know move information like KV cache data around the system is going to be increasingly important and then like I said the theme of training for inference

[18:17] is going to be something that continues to have a big impact in the industry moving forward so thank you all so much for the talk uh for coming to the talk um I am on Twitter I’m on LinkedIn um and I’m giving out free books um you can download a PDF at the QR code or come down with me to the base 10 booth to get your free copy of Inference Engineering. Uh we’ve got a bunch there, maybe enough for everyone. If not, we will have a CO bring some more from the office. Um so yeah, I’ll be downstairs at the base 10

[18:47] booth. Thank you all so much and have a great day. [applause] >> [music]