O Que Há de Novo em Engenharia de Inferência — Philip Kiely, Baseten

AAI Engineer
컴퓨터/소프트웨어AI/미래기술

스크립트

00:00:00Estou aqui para falar sobre as novidades na engenharia de inferência, então, olá, sou o Philip e estou aqui porque
00:00:19escrevi um livro. Este é o meu terceiro ano na AI Engineer World's Fair, e esta é a minha
00:00:24conferência favorita no mundo inteiro. É o ponto alto do calendário todos os anos. Eu realmente
00:00:29comecei como palestrante e engenheiro aqui em 2024, voltei em 2025 e fiz várias coisas.
00:00:36Estou aqui de novo, adoro este lugar e sou muito grato aos organizadores por sempre me receberem. Eu escrevi este
00:00:44livro chamado “Inference Engineering”. Nós o publicamos há três ou quatro meses e eu fiquei
00:00:49impressionado com a resposta. Publicamos no dia 23 de fevereiro e, até o momento,
00:00:57vendemos mais de 11.000 cópias físicas, estamos chegando a 30.000 cópias digitais e 24 milhões
00:01:04de pessoas pelo mundo, ou 24 milhões de contas do Twitter — veremos quantas pessoas realmente
00:01:09viram algo sobre engenharia de inferência. Com toda essa receptividade incrível,
00:01:17há uma pergunta que as pessoas vêm me fazendo: por que diabos você fez isso? Por que
00:01:23escrever um livro sobre algo que muda tão rápido? Bem, eu acredito que muitos dos
00:01:29princípios da engenharia de inferência já estão bem consolidados a esta altura, e há muito que
00:01:34podemos aprender e repetir a cada nova geração de modelos. Mas hoje estou aqui para falar sobre
00:01:42o que há de novo na engenharia de inferência. Este é o primeiro adendo público com todas as novidades desde que o livro
00:01:48foi lançado. Vamos revisar um pouco os princípios da engenharia de inferência e depois falaremos
00:01:54sobre tudo o que aconteceu no mundo da inferência desde 23 de fevereiro de 2026. Falaremos
00:02:00sobre o que aconteceu com o TurboQuant, um pouco sobre compactação de KV, passaremos bastante
00:02:05tempo no dFlash e em algumas outras novidades em decodificação especulativa, e depois farei um
00:02:12pouco de previsão, uma projeção do que acho que vai acontecer na
00:02:17inferência daqui para frente e sobre o que estou animado para, tomara, poder falar na próxima vez
00:02:23que vocês me virem aqui. Legal, então vamos começar. Uma coisa que tenho identificado
00:02:30em várias conversas com pessoas sobre inferência é um conjunto de princípios compartilhados, e um
00:02:38dos principais... Eu estava no podcast da Sarah outro dia conversando sobre inferência e,
00:02:44sabe, há dois tipos de engenharia de inferência que realmente se destacaram: existe a inferência local,
00:02:48onde a estratégia principal é apenas fazê-la funcionar no hardware que você tem, espremendo
00:02:56o modelo com quantização, destilação, poda ou da forma que der, distribuindo-o pelas
00:03:02GPUs que você tiver em casa. Primeiro você faz funcionar e depois deixa o modelo menos burro. Você remove
00:03:09quaisquer problemas catastróficos que toda essa compressão do modelo causou e tenta
00:03:15trazê-lo de volta àquela inteligência de referência executando em um tamanho de lote de 1. E aí existe o meu
00:03:20mundo, que é o mundo dos data centers e lotes maiores, onde a ideia é fazer funcionar no “dia zero”, colocar
00:03:27a build do vLLM no ar, fazer rodar e depois deixar menos lento. Aplicar coisas como roteamento consciente de KV, especulação,
00:03:33desagregação. E, dentro desses dois mundos, acho que temos muito a aprender uns com os outros.
00:03:40Nesta palestra, vou me concentrar nos avanços da engenharia de inferência voltada para data centers porque
00:03:46é o que eu conheço, mas também há muitas coisas legais acontecendo no mundo da inferência local.
00:03:52No livro “Inference Engineering”, eu geralmente assumo que os pesos são um produto final e
00:03:58acho que a transição do treinamento para a inferência é algo importante de manter em mente e uma boa
00:04:03forma de delimitar a área. No entanto, o que tenho percebido cada vez mais recentemente é que muitas
00:04:10otimizações para inferência vêm de um processo de treinamento dedicado. Assim, as fronteiras entre treinamento
00:04:17e inferência estão ficando cada vez mais tênues, e isso é algo interessante de se ter em mente.
00:04:22Estamos vendo esse ciclo em que você obtém uma inferência mais rápida, o que gera mais dados, usados para treinar um
00:04:28modelo melhor, que oferece uma inferência mais rápida, gerando mais dados, e você continua
00:04:33fazendo isso até ficar super-rico. Então, com o treinamento voltado para inferência, temos várias
00:04:39novas técnicas para debater dentro do que gosto de chamar de “os três grandes”. Vamos falar sobre
00:04:45novidades em quantização, novidades em cache — especificamente no mecanismo de KV cache — e
00:04:52novidades em especulação. Porque, embora existam muitas coisas no mundo da inferência,
00:04:57incluindo tópicos dos quais falarei no final, quando se trata da prática do dia a dia de
00:05:02como deixar um modelo X mais rápido, geralmente essas são as três técnicas que as pessoas buscam.
00:05:09Primeira coisa: eu publico um livro em fevereiro e me sinto incrível. Penso: “Uau,
00:05:16tudo o que você precisa saber sobre inferência em um só lugar!”. Mas aí tivemos novidades no
00:05:23mundo da quantização. Para revisar rapidamente: quantização é quando usamos um formato numérico menor e menos preciso
00:05:32para economizar largura de banda, economizar processamento, melhorar o TTFT e o TPS. Ela
00:05:39costuma ser específica para determinado hardware e reduz custos, mas pode degradar um pouco a qualidade do modelo.
00:05:45A propósito, se quiserem ouvir meu desabafo completo sobre quantização, fiz uma palestra no AI Engineer
00:05:51Miami no mês passado mostrando que a quantização não é necessariamente vilã como parece e que
00:05:57há muitas coisas que você pode fazer para preservar a qualidade durante o processo. Eu estava confiante na minha abordagem
00:06:04sobre quantização e, de repente, 20 milhões de pessoas viram o TurboQuant. Isso fez até as ações de memória
00:06:12caírem por um momento, só porque todo mundo pensou: “Nossa, a memória vai ser muito mais eficiente
00:06:16agora, não precisamos de mais memória flash”, o que estava errado. Enfim, era essa nova
00:06:23abordagem de quantização popularizada em março deste ano, que usa coordenadas polares para
00:06:29quantização e permite reduzir o KV cache para 4 bits. Isso virou um supertema e eu pensei:
00:06:36“Caramba, deixei passar tudo isso... Como é que isso vai ser na prática?”.
00:06:43Então, nossa equipe pesquisou bastante sobre isso... Um abraço para o estagiário de Waterloo
00:06:50no Twitter, o Ali, da nossa equipe de desempenho de modelos — não sei se ele ainda é estagiário, na verdade,
00:06:57mas sim, ele é de Waterloo. Enfim, ele escreveu um ótimo artigo sobre a matemática por trás do TurboQuant.
00:07:04Basicamente, a vantagem do TurboQuant é poder representar o KV cache com 4
00:07:09bits em vez de 8. Você economiza metade do espaço, metade da largura de banda e ganha o dobro
00:07:14de velocidade ao mover o KV cache na memória do sistema. Porém, o ponto negativo é bem grande.
00:07:21No TurboQuant, descobriu-se que é preciso realizar computação adicional na etapa de *forward pass* para
00:07:25compensar isso durante a decodificação, reduzindo o TPS pela metade. Esse é um custo inaceitável
00:07:32para muitos cenários de produção. Analisamos o TurboQuant detalhadamente, mas não o estamos usando
00:07:38em nenhuma carga de trabalho real. Continuamos com a quantização NVFP4 tradicional. Dito
00:07:44isso, ela é uma técnica excelente para quem trabalha com inferência local. Se você roda um modelo,
00:07:51especialmente um modelo de linguagem com contexto longo no seu computador ou em GPUs no porão, você tem
00:07:58uma quantidade muito limitada de memória — esse é o gargalo número um. Qualquer coisa que libere memória
00:08:04do KV cache e permita colocar sequências mais longas ali será extremamente valiosa,
00:08:09e o processamento adicional no *forward pass* acaba sendo uma desvantagem menor. Portanto,
00:08:16o TurboQuant continua sendo um artigo científico fantástico e uma técnica incrível que acabou não sendo tão
00:08:22aplicável na inferência em data centers quanto parecia no início. Em vez disso, estamos
00:08:28focados na NVFP4, priorizando a quantização dos pesos em vez do KV cache, fazendo o
00:08:36nosso melhor para ajustar imperfeições nos pesos quantizados e garantindo não achatar as
00:08:41distribuições de probabilidade. Para o KV cache, focamos em roteamento, *offloading* e compartilhamento de KV,
00:08:49usando NCCL, NVIDIA Dynamo e outras ferramentas para movimentar o KV cache pelo
00:08:55sistema e eventualmente transferi-lo para a memória RAM da CPU, em vez de tentar usar o TurboQuant
00:09:04para comprimi-lo. Também estamos focados na quantização entre modalidades, pensando em
00:09:11como aplicar os benefícios da NVFP4 não apenas a modelos de linguagem, mas também a modelos de imagem
00:09:17e vídeo. O Ali também escreveu muito conteúdo excelente sobre isso no Twitter, vale a pena conferir.
00:09:23Posto isso, o KV cache continua muito importante. Vamos falar sobre ele, vamos falar sobre compactação de KV.
00:09:29Revisando rapidamente: se você envia o mesmo prompt com o mesmo prefixo, pode reutilizar os
00:09:35tokens cujo *pre-fill* já foi calculado anteriormente. Isso torna todo o sistema mais rápido e eficiente.
00:09:42De modo geral, o KV cache é uma memória sem perdas. Existem poucas fontes de memória sem perdas quando pensamos
00:09:48no nosso sistema de inferência: temos o conteúdo do prompt, o contexto e o KV cache.
00:09:55Isso vai escalar linearmente com a quantidade de dados inseridos. Pensando em
00:09:59sequências com um milhão de tokens, o tamanho fica bem substancial. Por isso, muitos buscam
00:10:05formas de comprimir a memória e o contexto. Estruturas de agentes comprimem o contexto; buscas com RAG e
00:10:11todas essas técnicas discutidas há anos são formas de comprimir um contexto maior
00:10:17em algo legível pelo modelo ou gravável em arquivos. Todas essas abordagens
00:10:22escalam de forma sublinear com o volume de dados. Mas e se houvesse um meio-termo? E se houvesse um jeito
00:10:28de obter uma compressão significativa dos dados armazenados, mantendo as informações quase sem perdas?
00:10:34Temos muitas abordagens para decidir o que manter no cache. Métodos recentes de compactação
00:10:41demonstraram que podemos substituir o cache por um bem menor. Artigos sobre *attention matching* e *cartridges* mostraram resultados promissores
00:10:47mais curto. Temos artigos como o Attention Matching e Cartridges que trouxeram resultados muito promissores
00:10:53aqui com altas taxas de compressão, mas ambos rodam no momento da inferência. Mais uma vez, uma das técnicas
00:11:00sobre as quais quero falar, ou um dos temas que quero abordar, é o treinamento focado na inferência. Nesse caso,
00:11:05quero apresentar algo chamado STILL, da equipe de pesquisa da Base 10, onde a síntese sobre
00:11:12o cache — em que mantemos uma representação aprendida da informação em vez da informação
00:11:17direta ou de um subconjunto determinístico dela — é amortizada por meio do treinamento. O Charlie e o Mudith,
00:11:25da nossa equipe de pós-treinamento, fizeram uma apresentação incrível no CoSA Compile recentemente. Está no YouTube e eu
00:11:31recomendo bastante que vocês assistam se tiverem interesse em aprender sobre compactação de KV. Eu não
00:11:37tenho, infelizmente, o tempo nem a genialidade para explicar tudo aqui em cima, mas o mecanismo básico é
00:11:46que o STILL é um gargalo do Perceiver que pega um conjunto fixo de vetores de consulta aprendidos, aplica atenção cruzada
00:11:53contra todo o cache KV e gera um conjunto de chaves e valores compactos em uma única passagem direta.
00:11:59Isso cria uma memória comprimida, rápida e diferenciável à qual o LLM pode atentar como se fosse contexto real.
00:12:05Então, se vocês têm interesse em compactação de KV, sem dúvida confiram o trabalho do Charlie e do Mudith.
00:12:09Foi algo realmente fantástico de aprender. Essas são duas das técnicas: falamos sobre
00:12:16quantização e sobre cache. A última é a especulação, e houve muita evolução
00:12:21aqui. Como uma revisão, na decodificação especulativa nós usamos tokens rascunho, os verificamos
00:12:29durante a passagem direta e usamos isso para gerar mais de um token por passagem.
00:12:34Isso ajuda muito na taxa de tokens por segundo e é uma otimização totalmente sem perdas, o que é ótimo porque
00:12:40não precisamos nos preocupar com a qualidade. Na história da especulação, começamos com
00:12:46a decodificação especulativa clássica — todas essas técnicas estão no livro. Tivemos a SpecDec, onde você usa um modelo pequeno
00:12:52da mesma família para gerar tokens rascunho. No fim, viu-se que modelos pequenos não são tão bons gerando rascunhos;
00:12:58eles são ótimos como modelos pequenos. Então inventamos, como indústria, vários métodos novos, como o Medusa, onde
00:13:04você adiciona cabeças de decodificação ao modelo e, eventualmente, o Eagle 3, que trouxe a ideia: “E se,
00:13:09em vez de pegar um modelo minúsculo da mesma família, nós treinássemos um modelo de 1 bilhão de parâmetros nos
00:13:15estados ocultos do modelo alvo para gerar esses tokens?”. E isso funcionou muito bem. Assim,
00:13:21por volta de fevereiro do ano passado ou deste ano, o Eagle 3 era o melhor método de
00:13:27especulação. Agora temos o dFlash, que é ainda melhor. Ele usa difusão para especulação; o dFlash cria
00:13:36uma sequência de tokens rascunho em vez de um único token. O modelo é um modelo de linguagem por difusão,
00:13:43o que significa que ele cria uma sequência inteira de tokens da mesma forma que uma geração de vídeo ou imagem cria
00:13:49uma sequência de quadros ou pixels e itera sobre ela, em vez de fazer uma geração de tokens
00:13:55autorregressiva. Os modelos dFlash podem ser duas ou quatro vezes mais lentos para rodar, mas vão prever oito
00:14:01ou 16 tokens de uma só vez nessa janela, enquanto o Eagle só prevê um por vez. Então, uma única
00:14:08passagem direta do dFlash é mais rápida do que toda a fase de rascunho do Eagle e prevê mais tokens. Esses tokens conseguem
00:14:14fazer atenção cruzada entre si e, no geral, criam uma taxa de aceitação mais alta, e na especulação,
00:14:21a taxa de aceitação é tudo. Na prática, estamos vendo uma melhoria de mais de 3x com o dFlash. Isso foi medido com
00:14:30uma única B200 no Qwen 38B, e em comparação com o Eagle, vemos uma melhoria substancial nos tokens, tanto
00:14:40na taxa de aceitação quanto nos tokens por segundo. Esses modelos dFlash são treinados com uma máscara de atenção para
00:14:47geração de rascunhos bidirecional, para que o modelo alvo forneça o contexto. Dentro de cada bloco,
00:14:54teremos um subconjunto de tokens limpos amostrados, e a máscara de atenção vai impor
00:14:59a consistência causal, mantendo ainda a permissão para atenção bidirecional. Em um modelo
00:15:06autorregressivo tradicional, você só olha os tokens em uma única direção. É por isso que conseguimos
00:15:13tirar proveito dessa arquitetura baseada em difusão. E aí, quando eu achava que tinha
00:15:19terminado, há poucos dias saiu o dSpark. O dFlash nós já temos rodando em produção,
00:15:25mas o dSpark é uma pesquisa nova. Sobre ele, só posso dizer que existe, é bem legal e estamos
00:15:31analisando. A diferença em relação ao dFlash é que ele mantém o modelo de difusão, mas o combina com
00:15:38um modelo sequencial. A ideia é melhorar as taxas de aceitação fazendo esses dois
00:15:45modelos trabalharem juntos, em vez de ter apenas o especulador iterativo, apenas o especulador por
00:15:51difusão ou apenas o especulador autorregressivo. O dSpark é muito empolgante, mas ainda não temos
00:15:57resultados de produção com ele para compartilhar. Com sorte, teremos da próxima vez.
00:16:03No entanto, temos resultados de produção sobre o retreinamento contínuo do especulador. Voltando aqui ao dFlash,
00:16:09a ideia é que a decodificação especulativa depende muito do
00:16:15conteúdo real dos prompts e das respostas no seu sistema. Se você está
00:16:21continuamente retreinando com esses prompts e respostas no sistema em produção, pode ver um ganho de 20% até 2x
00:16:29nas taxas de aceitação de tokens. Isso é bem difícil de fazer: exige muito
00:16:36armazenamento e você precisa garantir a permissão para usar os dados que está processando
00:16:40dessa forma. Exige um poder de computação enorme e você precisa mover toda essa informação. Se você
00:16:46altera o modelo base, também precisa alterar o modelo especulador. Mas olhando para o futuro,
00:16:51acredito que a especulação contínua para sistemas de altíssima escala vai ser uma otimização
00:16:58que vale a pena. O que vem a seguir em inferência? O seguinte é opinião pessoal, especulação
00:17:06e informações públicas. Se eu soubesse de algo que realmente estivesse para sair, não poderia
00:17:11falar a respeito. Então isso é apenas o que acho que vai acontecer. Já passei por
00:17:17três ciclos de hardware: o lançamento da Ampere, da Hopper e da Blackwell. Sempre
00:17:23leva tempo desde o envio dos chips até a instalação nos data centers e a adaptação
00:17:30de toda a pilha de software para aproveitar seus recursos. Mas algumas coisas que me deixam
00:17:36animado... Com a arquitetura Rubin, parece que o desempenho do NVFP4 vai ser fantástico.
00:17:44Quanto mais pudermos aproveitar técnicas de inferência local e ganhar confiança ao rodar
00:17:49modelos nesse formato de dados NVFP4, mais conseguiremos extrair o incrível
00:17:54desempenho dos próximos sistemas Rubin. Acho que a desagregação e a comunicação
00:18:00em todo o sistema serão cada vez mais importantes. Estamos vendo ganhos iniciais excelentes com a
00:18:05desagregação de P/D, e a capacidade de mover informações como dados do cache KV pelo sistema
00:18:12terá uma importância crescente. E, como disse, o tema de treinar para inferência continuará
00:18:17causando um grande impacto na indústria daqui para frente. Muito obrigado a todos
00:18:25por virem à palestra. Estou no Twitter, no LinkedIn e distribuindo livros gratuitos.
00:18:32Vocês podem baixar o PDF pelo QR code ou ir comigo até o estande da Base 10 para pegar sua cópia de
00:18:37“Inference Engineering”. Temos vários lá, talvez o suficiente para todos; se não, pedirei para
00:18:43trazerem mais do escritório. Estarei no andar de baixo, no estande da Base 10. Muito obrigado
00:18:48a todos e tenham um ótimo dia!

설명

TurboQuant reached twenty million people in March, and the memory stock index dipped because everyone assumed the KV cache had just halved. Philip Kiely had published Inference Engineering weeks earlier and watched a technique he had not covered go viral. So his team did the math. Four bit cache instead of eight does double effective bandwidth, but the extra decode computation cuts tokens per second by more than half: unacceptable in a data center, close to ideal on a memory starved machine in your basement. That split runs through the talk. Local inference is get it working, then make it less dumb. Data center inference is get it working, then make it less slow. And the biggest change since February is that data center optimizations increasingly come out of a dedicated training process, blurring the line between training and inference. He walks the big three. Quantization, where the data center answer stayed four bit weights rather than a compressed cache. Caching, where the question is now compaction: a learned bottleneck cross attends fixed query vectors against the full KV cache and emits compact keys and values in one forward pass. And speculation, where the field moved fastest. Small draft models from the same family were never good drafters; training one on the target's hidden states worked far better; then a diffusion drafter arrived that proposes eight or sixteen tokens at once, and in production it more than tripled acceptance over the previous best. Days before the talk, a newer method paired it with a sequential drafter. And retraining the speculator continuously on live prompts lifts acceptance twenty percent to double, if you can afford storage, compute, and permission. Speaker info: - https://x.com/philip_kiely - https://linkedin.com/in/philipkiely - https://baseten.co - https://philipkiely.com Timestamps: 0:00 - Three years at the World's Fair, and a book 2:30 - Two kinds of inference engineering: local and data center 3:52 - Training for inference blurs the handoff 5:20 - What happened to TurboQuant 7:37 - Where four bit quantization actually lands 9:28 - KV compaction and a learned cache 12:11 - Speculation, from small models to trained drafters 13:32 - DFlash: diffusion for drafting 15:11 - DSpark, and continuous speculator retraining 17:04 - What comes next

커뮤니티 글

아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!

이 영상에 대해 글쓰기