DeepSeek libera stack de inferência capaz de 155 trilhões de tokens por dia com margem de até 80%

A DeepSeek publicou, no dia 20 de outubro de 2026 (coincidindo com o primeiro dia da PyTorch Conf), o DeepInfer: o motor de inferência que roda em produção por trás do modelo V4.1 Flash. Junto veio um relatório de engenharia detalhado, traduzido e analisado pela newsletter Latent Space, com números de throughput e custo que a empresa raramente divulga com esse nível de detalhe.

O pacote é uma customização de vLLM, com créditos explícitos a SGLang e TensorRT-LLM↳LLMs48 conteúdosConsiderações básicas de hardware para modelos de linguagem em código aberto: Memória, Desempenho e ViabilidadeMarketing Tech · out 2025Modelos de linguagem sob ataque: o lado obscuro da IA generativaDevSecOps · mai 2025Criando um LLM – modelo de linguagem de grande escala – do zero com TransformersAI · abr 2024Ver tudo em AI →, liberada sob licença Apache 2.0. Veio acompanhado do deepseek-recipe, componente que trata tokenização, decodificação e compatibilidade com as APIs Chat Completions, Responses e Messages.

O que foi aberto, e o que ficou de fora

A própria DeepSeek chama o release de open source↳Open source71 conteúdosComo o Open Source Está Liberando o Poder da Automação para TodosDev (Back & Front) · out 2025Código aberto: programadores criam software da NASA sem saberDev (Back & Front) · abr 2021N8N: O que é a ferramenta open source que está revolucionando a automação em TI?Dev (Back & Front) · dez 2025Ver tudo em Dev (Back & Front) → completo, mas o relatório técnico admite o contrário em pelo menos dois pontos centrais. O gerenciamento de KV cache e o balanceamento de carga entre workers, as peças que a comunidade já apelidou de "joias da coroa", continuam fora do repositório porque estão acopladas à infraestrutura interna da empresa.

Isso muda o que o release realmente representa. Não é o serviço de produção da DeepSeek rodando fora de casa: é o motor de execução, sem o sistema de cache persistente e sem o orquestrador que distribui carga entre centenas de GPUs. Quem clonar o repositório ganha uma base sólida sobre vLLM, não uma cópia 1:1 da economia anunciada.

Os números por trás da manchete

O relatório traz uma combinação de throughput e preço que, somada, chega à cifra de referência: cerca de $22 milhões por dia de receita por cluster, calculados a partir de 155 trilhões de tokens/dia e do preço vigente de $0,15/$0,60 por milhão de tokens de entrada/saída. Outros números do mesmo relatório:

• 96% de acerto no cache de tokens de entrada
• 400 ms de tempo médio até o primeiro token
• 230 tokens/s de geração, chegando a 300 tokens/s em tarefas de código
• $38 de receita por acelerador-hora em horário de baixa demanda

A partir desses números, a comunidade técnica tentou reconstruir a margem de lucro, e aqui a conta fica instável conforme a premissa de custo de GPU:

A primeira estimativa partiu de um cenário ideal que projetava cerca de $49 por hora de receita; quando confrontada com o número real divulgado pela DeepSeek ($38/hora), a conta foi revisada para 84,2% a 96,1% de margem. Em nenhum dos casos entram custos de armazenamento SSD do cache, rede, capacidade ociosa, engenharia e suporte: são margens de contribuição sobre hardware, não margem líquida do negócio.

Separar prefill, decode e cache muda o desenho do cluster

A arquitetura divulgada separa codificação visual, prefill e decode em estágios que escalam de forma independente. A recomendação de deploy é usar máquinas comuns de oito aceleradores para prefill e supernós de 64 a 128 aceleradores para decode, com paralelismo de especialistas (expert parallelism) distribuindo os blocos MoE em lotes grandes.

Alguns detalhes de escalonamento explicam por que comparar "tokens por lote" entre engines diferentes costuma enganar:

1. O escalonamento de prefill estima o custo computacional da atenção, não o tamanho bruto da requisição, e varia o tamanho do chunk para caber num orçamento de tempo.
2. O roteamento de prefill não exige afinidade de cache: como os prefixos ficam num armazenamento compartilhado, qualquer worker disponível pode atender a requisição.
3. O roteamento de decode balanceia tanto o número de requisições em execução quanto o tamanho acumulado do KV cache.
4. Experts populares são replicados periodicamente para reduzir espera entre dispositivos causada por desbalanceamento de roteamento.

Um detalhe chamou atenção de engenheiros de inferência: a configuração divulgada para Blackwell aparentemente não usa paralelismo de tensores, algo incomum nas receitas padrão de vLLM e SGLang. A leitura da comunidade liga isso às restrições de interconexão da era H800 do V3, mas é uma interpretação de configuração específica, não uma recomendação geral contra paralelismo de tensores.

O cache é a peça que sustenta os 155 trilhões

O KV cache persistente vive num cluster de armazenamento separado (3FS), com cerca de 100 PiB em SSD. A retenção é de três dias para tráfego de agentes e sete dias para tráfego de chatbot, e qualquer worker de prefill pode buscar um prefixo em cache, desacoplando localidade de cache da posição física de computação.

Isso é relevante para quem constrói agentes que reenviam repetidamente um histórico crescente de instruções, conteúdo de repositório e saídas de ferramentas. Também significa que os 155 trilhões de tokens servidos por dia não são 155 trilhões de tokens recém-computados: boa parte é cache hit, e os 96% de acerto citados acima são o dado que torna o número de throughput compreensível.

Uma técnica chamada SWA Bounded Replay reconstrói estado de atenção de janela deslizante usando só os últimos 128 tokens, em vez de refazer o cálculo sobre todo o histórico anterior. A DeepSeek reporta que isso quase reduz à metade o cálculo total de prefill, uma aproximação que funciona para a arquitetura deles, não uma garantia de portabilidade para qualquer modelo.

O timing do anúncio também convida a uma comparação direta: a OpenAI havia acabado de anunciar cache de prompt de 12 horas (ante um padrão de 30 minutos), enquanto o DeepInfer sustenta janelas de até 72 horas de cache. São produtos e arquiteturas diferentes, mas ambos miram o mesmo problema: agentes que reutilizam contexto depois de longos intervalos.

O que o vLLM já provou, sem precisar da peça que falta

A resposta mais concreta à pergunta "isso só a DeepSeek consegue fazer?" veio do próprio time do vLLM. Depois de lembrar que o DeepInfer foi construído originalmente sobre o vLLM, com crédito explícito e licença Apache 2.0, o projeto publicou resultados mostrando throughput de decode dentro de 6% dos números divulgados pela DeepSeek, em GB200, sob configuração equivalente.

É um resultado importante, mas limitado: paridade no estágio de decode não é reprodução do serviço inteiro. Não há, nos testes do vLLM, operação equivalente aos 100 PiB de cache, à mesma política de retenção, ao mesmo roteamento ou à mesma disponibilidade sob o tráfego real da DeepSeek. O próprio Woosuk Kwon, criador do vLLM, descreveu a DeepSeek como uma adotante e contribuidora antiga do projeto, o que reposiciona o DeepInfer: é conhecimento de produção fluindo de volta para um ecossistema que já existia, não um substituto completo dele.

NVIDIA, Ascend e o fosso de hardware que continua aberto

O DeepInfer roda tanto em NVIDIA (Blackwell/SM100) quanto em Huawei Ascend, mas uma análise posterior de hardware comparou a eficiência de decode entre GB200 e Ascend 950DT: com restrição de 100 tokens/s e contexto de 131K, a diferença fica em torno de 25,5 mil contra 5 mil tokens/s por dispositivo; a 230 tokens/s, a razão sobe de cerca de 5x para 7,4x a favor da NVIDIA. Compatibilidade com Ascend não é sinônimo de eficiência equivalente em produção.

Para dimensionar o tamanho do investimento necessário, uma estimativa da comunidade (de Teortaxes, com ressalva explícita de que é um cenário proposto, não uma reprodução comprovada) calcula que igualar o throughput do cluster da DeepSeek exigiria algo entre 3.000 e 4.000 GB200s.

O que muda pra quem roda inferência fora da escala da DeepSeek

Para times que operam modelos próprios ou hospedam inferência em escala menor, o valor prático do release está nos padrões arquiteturais, não nos números de margem. Separar prefill e decode em pools com perfis de hardware diferentes, rotear por carga computacional estimada em vez de contagem bruta de tokens, e usar decodificação especulativa adaptativa (o DSpark da DeepSeek reporta 6% de ganho de throughput sobre sempre verificar cinco tokens de rascunho) são ideias portáveis mesmo sem um cluster de milhares de GPUs.

Como o vLLM já reproduz boa parte do comportamento de decode do DeepInfer e é Apache 2.0, esse é o caminho mais realista para a maioria dos times: adaptar as mesmas ideias de escalonamento dentro de um motor que já sustenta comunidade e manutenção, em vez de tentar reconstruir a parte que a DeepSeek escolheu não abrir.

Os 80% de margem e os 81 dias de payback dependem de volume de tráfego, taxa de acerto de cache e investimento em cluster que poucas operações fora da DeepSeek vão alcançar; tentar replicar o número sem a escala correspondente é o jeito mais rápido de queimar orçamento de GPU em vez de economizá-lo.

Fonte: Latent Space