O motor de inferência da DeepSeek: 5 mitos, testados

Quando a DeepSeek publicou seu motor de inferência de LLM em produção no GitHub sob licença Apache 2.0, o repositório chegou a milhares de estrelas em poucas horas. Não surpreende. O que é surpreendente é o que existe por dentro. O DeepInfer não é um brinquedo de pesquisa nem uma demo simplificada. É o motor que, segundo a própria DeepSeek, serve o DeepSeek-V4.1-Flash numa escala declarada de 155 trilhões de tokens por dia por cluster, com receita de cerca de US$ 38 por hora de GPU em preço fora de pico. Esses números, mesmo que só aproximadamente corretos, vêm de decisões de engenharia que a maior parte da indústria trata como folclore. Então vamos fazer o que eu faria com qualquer sistema de produção recém-aberto: ler o README com ceticismo e testar as crenças comuns sobre motores de inferência contra ele.

Mito 1: Um motor de inferência é só um forward pass rápido

O modelo mental ingênuo é mais ou menos este: o modelo é o modelo, o motor é um wrapper fino que chama os kernels, e a performance vem de comprar GPUs mais rápidas. A lista de funcionalidades do próprio DeepInfer derruba essa ideia. Veja o que ele considera digno de ser lançado: agendamento assíncrono com um “agendador de lotes de overhead zero”, decodificação especulativa com verificação guiada por confiança, replay limitado para atenção com janela deslizante, inferência invariante ao lote, amostragem determinística e saídas estruturadas restritas a regexes, esquemas JSON ou gramáticas EBNF. Isso é um agendador, um gerenciador de memória, um sistema de verificação e um compilador de restrições. Os kernels são quase um detalhe na lista.

Isso bate com o que os praticantes continuam reaprendendo. O forward pass é a parte fácil; ele está essencialmente resolvido desde o FlashAttention e as boas bibliotecas de GEMM. O trabalho difícil é manter a GPU alimentada. Cada milissegundo em que os SMs ficam ociosos enquanto a CPU decide quais requisições admitir, quais blocos de KV despejar ou quais tokens rascunhados verificar é dinheiro escorrendo pelo ralo. O agendador assíncrono do DeepInfer existe justamente para sobrepor o agendamento na CPU com a execução no dispositivo, para que a GPU nunca espere pelo Python. Se sua pilha de serving ainda agenda de forma síncrona, essa única mudança provavelmente vale mais do que qualquer troca de kernel que você planejava.

Há também uma admissão reveladora no README: um serviço de inferência completo ainda precisa de um sistema de cache KV, de separação entre prefill e decode e de balanceamento de carga entre réplicas de paralelismo de dados. Nada disso está incluído. Em outras palavras, nem o motor é mais que uma camada do sistema real. Inferência em produção é um problema de sistemas distribuídos vestido de fantasia de machine learning. Já fizemos esse ponto sobre agentes de LLM que se parecem muito com sistemas distribuídos, e ele vale igualmente uma camada mais abaixo na pilha.

Mito 2: Lotes maiores são sempre melhores

O batching contínuo, que é admitir novas requisições no lote assim que outras terminam em vez de esperar o lote inteiro, hoje é requisito básico, e o DeepInfer obviamente o faz. Mas a crença mais interessante para testar é a versão descuidada: “a vazão escala com o tamanho do lote, então maximize o lote”. O DeepInfer traz dois recursos que existem justamente porque isso está errado.

Primeiro, inferência invariante ao lote (DEEPINFER_BATCH_INVARIANT=1). Normalmente, a saída de uma requisição pode variar conforme o que mais está no seu lote, porque a ordem de redução nos kernels muda com a composição do lote, e a soma de ponto flutuante não é associativa. A DeepSeek considerou que valia o esforço de engenharia para fazer os resultados serem idênticos independentemente da composição do lote. Por quê? Porque, ao servir em escala, você descobre que clientes e pipelines de avaliação percebem quando o mesmo prompt devolve tokens diferentes em dias diferentes. Se maximizar o tamanho do lote significasse aceitar não determinismo, a DeepSeek escolheu gastar vazão para recuperar o determinismo. Isso mostra que a função objetivo real não é tokens por segundo brutos. É tokens por segundo confiáveis.

Segundo, verificação guiada por confiança para decodificação especulativa. O motor rascunha tokens (comprimento máximo padrão de rascunho 5) e usa estimativas de confiança para decidir quanto trabalho de verificação agendar. A abordagem ingênua verifica um rascunho de tamanho fixo a cada passo; a abordagem inteligente reconhece que a quantidade ótima de trabalho especulativo varia por requisição e por passo. Colocar especulação demais no lote, além do que a confiança justifica, desperdiça computação em tokens que serão descartados. Colocar de menos deixa speedup na mesa. O agendador está resolvendo um problema de otimização a cada passo, não apenas empilhando requisições.

• O tamanho do lote aumenta a vazão, mas também a latência: o tempo até o primeiro token piora conforme os lotes de prefill crescem.
• A composição do lote muda a numérica: a menos que você pague por kernels invariantes ao lote, as saídas variam.
• O trabalho especulativo tem retornos decrescentes: a taxa de aceitação dos rascunhos cai com o comprimento do rascunho, então cronogramas fixos desperdiçam FLOPs.
• O cache KV é o verdadeiro teto: o lote não pode crescer além do que a memória comporta, por isso o layout da memória importa mais que a política de lotes.

Mito 3: O gerenciamento de cache KV é um problema resolvido

O PagedAttention popularizou a abordagem no estilo de sistema operacional: alocar o cache KV em páginas de tamanho fixo, distribuí-las como memória virtual e parar de fragmentar. O vLLM provou que funciona, e o DeepInfer foi, pelos próprios agradecimentos, originalmente construído principalmente sobre o vLLM. Então o cache KV paginado já deve estar resolvido, certo? Não exatamente. O README do DeepInfer menciona de passagem algo bem mais agressivo: um objetivo de design do sistema de produção era reter o cache KV por mais de 72 horas.

Pense no que isso implica. A HBM, mesmo nas maiores GPUs, é medida em centenas de gigabytes; um cache de 72 horas num cluster movimentado são petabytes de estado. Você não consegue manter isso no dispositivo. Precisa de um sistema KV em camadas (HBM, DRAM do host, NVMe, possivelmente armazenamento remoto), com políticas de despejo e pré-busca inteligentes o bastante para que trazer de volta um prefixo antigo não estrague seu SLO de latência. É por isso que o README lista “um sistema de cache KV” como algo não incluído na versão: é uma peça separada e séria de infraestrutura. Se você trata o cache KV como um problema de paginação dentro da GPU, a fronteira já se deslocou para tratá-lo como um sistema de armazenamento. Cobrimos a versão em menor escala dessa dor em o que fazer quando sua GPU fica sem VRAM, mas aqui é esse problema em escala de datacenter.

Há também um truque de KV mais sutil que vale copiar: replay limitado para SWA. Para as camadas de atenção com janela deslizante do decoder, você não precisa reprocessar o prompt inteiro durante o prefill, apenas um sufixo limitado que cubra a janela de atenção mais o comprimento máximo de retrocesso (padrão: manter 140 tokens). Isso reduz diretamente a computação de prefill em contextos longos, e é o tipo de otimização que você só descobre ao perfilar onde os FLOPs do prefill realmente vão. Motores genéricos não conseguem fazer isso com segurança; exige conhecer a arquitetura de atenção do modelo intimamente. Motores específicos para modelos vencem de novo.

Mito 4: Decodificação especulativa é vazão de graça

A decodificação especulativa tem um argumento de venda quase mágico: gerar vários tokens por forward pass usando um rascunho barato, verificá-los em paralelo e manter o que bate. Os benchmarks adoram isso. Mas a crença de que é “de graça” desmorona assim que você lê como o DeepInfer realmente a implanta. As flags contam a história: DEEPINFER_ENABLE_MTP_VARLEN=1 para ativá-la, DEEPINFER_USE_NEXTN_DECODE para limitar o comprimento do rascunho, e uma camada separada de agendamento por confiança por cima. Se fosse de graça, você não precisaria de nada disso. Bastaria sempre rascunhar.

A economia funciona assim. Rascunhar e verificar custa FLOPs extras a cada passo. Você só lucra quando a taxa de aceitação é alta o bastante para que o ganho de tokens por passo supere o overhead. As taxas de aceitação dependem do mecanismo de rascunho, do domínio (código rascunha muito bem; prosa divagante, menos) e, o mais importante, da carga do lote. Com lotes grandes, a GPU já está limitada por computação, então os FLOPs extras de verificação atrapalham diretamente o trabalho útil. A decodificação especulativa brilha no regime limitado por latência e pode realmente prejudicar no regime limitado por vazão. Um motor de produção que atende os dois regimes precisa agendá-la de forma adaptativa, e é exatamente isso que a verificação guiada por confiança faz.

Minha opinião, depois de ver times enxertarem decodificação especulativa em pilhas de serving: trate-a como recurso de latência, não de vazão. Se seu gargalo é tokens por dólar com alta utilização, conserte primeiro o agendador e o layout do KV. Se seu gargalo é a latência p99 para usuários interativos com carga moderada, a decodificação especulativa é uma das melhores ferramentas disponíveis, e o DeepInfer oferece uma referência testada em batalha de como controlá-la.

Mito 5: Você precisa da bênção da NVIDIA (e de mais nada) para servir em escala

O DeepInfer suporta exatamente dois alvos de hardware: GPUs NVIDIA SM100 e NPUs Huawei Ascend 950. Ele mantém arquivos de requisitos separados por plataforma (requirements-nvidia.txt, requirements-ascend.txt) e libera recursos conforme a plataforma. A inferência invariante ao lote é exclusiva da NVIDIA, por exemplo. É uma declaração discreta, mas significativa. Um motor de produção de primeira linha trata um acelerador não-NVIDIA como cidadão de primeira classe, com o mesmo modelo, o mesmo agendador e a mesma arquitetura de serving.

Para ser claro sobre o que isso significa e o que não significa: não quer dizer que o caminho Ascend esteja maduro, nem que o fosso do CUDA desapareça da noite para o dia. Os recursos exclusivos de CUDA no mesmo README provam que a lacuna do ecossistema é real. O que significa é que o problema de software mais difícil na portabilidade de inferência (o motor, o agendador, a estratégia de paralelismo) agora está aberto, com licença Apache e arquitetado para dois alvos desde o início. Para laboratórios menores e fabricantes de hardware, isso é uma base sobre a qual construir, não um muro a ser copiado. Quem acompanha o segmento de modelos flash sabe o quanto a economia depende disso. Já defendemos que modelos flash são a verdadeira história de eficiência de inferência, e a pluralidade de hardware amplifica isso.

O design de paralelismo também merece menção: paralelismo de dados para atenção com paralelismo de contexto balanceado, mais paralelismo de especialistas para as camadas MoE com um balanceador de carga de especialistas. Essa combinação é ajustada exatamente para o tipo de implantação que a DeepSeek descreve, com um punhado de GPUs para prefill e dezenas para decode, separados. A separação com decode intensivo está virando a arquitetura padrão para grandes frotas de serving, e a razão é aritmética simples: o prefill é limitado por computação e o decode é limitado por largura de banda de memória. Colocá-los juntos obriga você a comprar hardware que não é ótimo para nenhum dos dois.

Mito 6: Basta pegar isso e rodar

Mais uma crença para desmontar, direcionada a todos que deram estrela no repositório planejando integrá-lo à pilha neste fim de semana. O DeepInfer atualmente serve exatamente uma família de modelos: DeepSeek-V4.1-Flash. Exige Linux, GCC 13+, Python 3.12, CUDA 13 e hardware SM100, ou seja, da geração Blackwell, que a maioria de nós não tem sobrando. Os benchmarks foram medidos com 4 GPUs para prefill e 64 para decode dentro de um mesmo domínio de scale-up. E as três coisas necessárias para um serviço de verdade (o sistema de cache KV, a infraestrutura de separação e o balanceamento de carga entre réplicas) estão explicitamente fora do escopo. Isso é o motor, não o carro.

Mas descartá-lo como inutilizável perde o ponto, e aqui vou ser opinativo. A versão vale menos como software para implantar e mais como uma especificação do que significa ser de qualidade de produção. Inferência invariante ao lote como flag de primeira classe. Amostragem determinística com um seq_seed fixo para reprodutibilidade. Saídas estruturadas compiladas dentro do amostrador, em vez de acopladas com retentativas. Especulação guiada por confiança. Agendamento assíncrono como padrão, não como experimento. Se você está construindo ou comprando uma pilha de inferência, este README é uma checklist. Se você roda modelos grandes por conta própria, e temos um guia prático para rodar LLMs no seu próprio hardware para a ponta menor, as mesmas prioridades valem, só que em outra escala: agendador primeiro, layout de memória em segundo, kernels em terceiro.

O forward pass é a parte fácil. Inferência em produção é um agendador, um gerenciador de memória e um sistema de verificação que, por acaso, chamam kernels.

O momento geopolítico, chegando horas depois de uma ordem de exclusão do governo federal dos EUA e com comentários chamando-a de tudo, de presente a sabotagem, vai dominar as manchetes. Tudo bem. Mas, tirando o drama, o veredito de engenharia se sustenta sozinho: boa parte do que acreditávamos sobre motores de inferência estava uma geração defasada. O trabalho interessante já não está nos kernels. Está em tudo ao redor deles.