O que é o DeepInfer? O mecanismo de inferência da DeepSeek e as partes que ela não lançou

O DeepInfer é o framework de inferência que a DeepSeek publicou em 16 de outubro de 2026 sob Apache-2.0, e ele serve exatamente um modelo: DeepSeek-V4.1-Flash, com DeepSeek-V4.1-Flash-1017 como checkpoint padrão. Esse escopo de modelo único é a primeira coisa a entender, porque explica quase todo o resto do repositório. Este não é um framework de serviço genérico que por acaso inclui uma configuração da DeepSeek. É o caminho de código que a DeepSeek executa em produção, reduzido às partes que se generalizam, e é honesto quanto ao corte: a própria lista do README daquilo que um serviço de inferência completo precisa e daquilo que esta versão não inclui nomeia um sistema de cache KV, desagregação VE/Prefill/Decode e balanceamento de carga entre réplicas de paralelismo de dados. O que você recebe é o caminho de computação — kernels, paralelismo, decodificação especulativa, agendamento, saída estruturada. O que você não recebe é a camada de armazenamento e roteamento que torna o caminho de computação barato de operar em escala. A DeepSeek explica o motivo: esses componentes são fortemente acoplados à infraestrutura interna, então o design é descrito em um artigo publicado enquanto o código permanece interno.

O que está realmente no repositório

A lista de recursos publicada parece um passeio pelos gargalos de servir um modelo de mistura de especialistas de grande porte. Estão lá as bibliotecas de kernels que a DeepSeek já lançou antes — FlashMLA para atenção, DeepGEMM para as multiplicações de matrizes, DeepEP para comunicação em paralelismo de especialistas, além de TileKernels e DeepSelect. Está lá o esquema de paralelismo: a atenção roda como paralelismo de dados com paralelismo de contexto balanceado, e a metade do MoE roda como paralelismo de especialistas com um balanceador de carga de paralelismo de especialistas. Está lá o DSpark, a pilha de decodificação especulativa, com comprimentos de verificação que são agendados em vez de fixos. Está lá o SWA bounded replay, o mecanismo que impede que um cache de atenção de janela deslizante force uma recomputação completa a cada falta de cache. Está lá o agendamento assíncrono de lotes, a inferência invariante a lote com amostragem determinística e a saída estruturada restringida por regex, esquema JSON ou EBNF.

O ponto de entrada é deliberadamente pequeno. Depois de definir DEEPINFER_ACCELERATOR como nvidia ou o equivalente Ascend e executar build.sh, o repositório inclui examples/offline_inference.py, que executa o checkpoint padrão de ponta a ponta. DEEPINFER_HF_MODEL_DIR aponta para um diretório de pesos diferente. Os benchmarks publicados foram medidos em quatro GPUs SM100 para prefill e 64 GPUs SM100 para decode, que é o formato da implantação para a qual o motor foi escrito e não uma demonstração pensada para laptop.

O README também informa de onde o código veio, o que vale a pena saber antes de lê-lo. O motor foi originalmente construído principalmente sobre o vLLM, com inspiração de design proveniente do SGLang e do TensorRT-LLM. Essa linhagem aparece na estrutura — o agendador, a interface de atenção paginada e o caminho de amostragem serão familiares para qualquer pessoa que tenha lido esses projetos — e explica por que o lançamento é um fork de uma stack de serving em vez de uma arquitetura escrita do zero. O que a DeepSeek acrescentou é a parte específica do seu próprio modelo: a implantação desagregada, o paralelismo amplo de especialistas com seu balanceador, o replay de janela deslizante e o DSpark.

O que ele não contém, e por que isso importa mais

As três peças ausentes não são pequenas omissões. Cada uma é um sistema que precisa existir antes de o motor atender tráfego de produção, e cada uma é dispendiosa de uma forma diferente.

• O sistema de cache KV. A reutilização de prefixos é onde está a maior parte da economia em uma carga de trabalho de chat, porque um acerto de cache substitui um prefill. Sem um armazenamento de cache, cada requisição recalcula seu prompt. O próprio texto do DeepSeek descreve o armazenamento que utiliza: um cluster 3FS dedicado em vez da memória local do host, precisamente para que qualquer máquina de prefill possa acessar qualquer prefixo e a capacidade de cache possa ser escalada independentemente da computação.

• Desagregação de VE/Prefill/Decode. O README observa que a maior parte da funcionalidade do lado do mecanismo já existe na versão; o que falta é a implantação. Desagregar o codificador visual, o prefill e o decode permite dimensionar cada estágio de acordo com seu próprio gargalo e controlar o tempo até o primeiro token separadamente do tempo entre tokens. Isso é uma decisão de infraestrutura, não uma flag.

• Balanceamento de carga entre réplicas de paralelismo de dados. A DeepSeek executa quatro balanceadores — prefill, decode, codificador de visão e expert-parallel — e descreve todos os quatro no relatório. Nenhuma parte da lógica de roteamento é fornecida. Sem ela, um conjunto de réplicas só é tão bom quanto o roteador que você colocar na frente dele, e um roteador round-robin ingênuo destruirá a taxa de acertos de cache que o armazenamento foi criado para proteger.

Lidos em conjunto, a omissão indica que tipo de artefato é este. O DeepInfer é uma implementação de referência do caminho de computação, publicada para que o trabalho de kernel e escalonamento possa ser inspecionado e reutilizado, e não uma distribuição que você instala e para a qual direciona tráfego.

O gate de hardware é o filtro de verdade

O DeepInfer tem como alvo NVIDIA SM100 e Huawei Ascend 950. Não há caminho para Ampere nem para Hopper, o que exclui a maioria das GPUs na maioria dos clusters atuais. O restante do toolchain é igualmente específico: somente Linux, GCC 13 ou mais recente, Python 3.12, CUDA 13 para NVIDIA ou CANN 9.2 para Ascend. E não há releases nenhum — o repositório tinha zero releases publicados quando foi consultado em 21 de outubro de 2026, então não há nada para baixar e nada para fixar. Você o clona e o compila com seu próprio toolchain.

Essa combinação é incomum para um lançamento de código aberto com tanta atenção, e é melhor interpretá-la como uma declaração precisa de escopo do que como um descuido. Os kernels no repositório foram escritos para um conjunto de instruções específico e uma interconexão específica; os números no README vêm desse hardware. Portar o caminho de computação para uma geração anterior é exatamente o tipo de trabalho que uma comunidade faz rapidamente e que uma organização de engenharia não pode prometer. Dias após o lançamento, um porte de terceiros voltado para componentes NVIDIA mais antigos apareceu no GitHub, o que é um sinal útil sobre a demanda e nenhum sinal sobre se os números de throughput publicados sobrevivem ao porte.

O formato de implantação que a DeepSeek realmente executa

O documento de arquitetura é onde as premissas do repositório se tornam legíveis. O sistema é desagregado em um codificador de visão, prefill e decode, além de nós de armazenamento dedicados. O prefill usa paralelismo de especialistas de 2 a 8 com paralelismo de dados correspondente, escolhendo a menor configuração que a HBM permite. O decode segue o caminho oposto: paralelismo de especialistas e paralelismo de dados de 64 a 128, que a DeepSeek chama de Wide-EP, usando a maior configuração que as GPUs disponíveis permitem. Paralelismo de tensores e paralelismo de contexto não são usados de forma alguma. O codificador de visão executa uma GPU por instância, com recomendação de GPUs mais baratas, porque o codificador não é onde o dinheiro vai.

A menor implantação que faz sentido decorre desses números. Uma GPU de prefill e uma GPU de decode serão executadas e, na prática, a proporção entre os dois pools é de aproximadamente um para um. Mas, como o decode quer 64 GPUs ou mais para obter o benefício do paralelismo de especialistas, a menor unidade eficiente é 64 GPUs de prefill mais 64 GPUs de decode. Esse é o número a reter ao ler qualquer afirmação sobre a eficiência do DeepInfer: os números descrevem uma implantação de 128 GPUs, e metade dela é um estágio.

Dividir o prefill e o decode entre centros de dados é tecnicamente possível porque o DeepSeek-V4.1-Flash comprime substancialmente a sua cache KV, e a própria implementação da DeepSeek coloca nós de inferência em centros de dados diferentes mas adjacentes. O orçamento é de cerca de 400 Gbps de interligação por cada oito GPUs, e o documento é franco quanto ao custo de fiabilidade — a fibra entre edifícios é fácil de cortar.

Por que o decode está tão espalhado?

O paralelismo amplo de especialistas é a decisão isolada de maior impacto no design, e é fácil interpretá-lo erroneamente como um truque de escalabilidade. Em uma camada de mistura de especialistas, cada token aciona um pequeno número de especialistas, então o custo de uma etapa de decodificação é dominado pela movimentação de pesos dos especialistas e ativações, e não pela intensidade aritmética. Distribuir os especialistas por 64 ou 128 GPUs reduz o tráfego de memória por etapa que cada GPU contribui, o que aumenta os tokens por segundo se — e esta é a condição — a carga entre os especialistas permanecer uniforme. É para isso que serve o balanceador de carga do paralelismo de especialistas.

As configurações do DeepSeek são específicas o suficiente para serem copiadas. Para o prefill, cada GPU mantém quatro especialistas redundantes além dos que já possui, as estatísticas são coletadas em uma janela de 100 etapas e os especialistas são redistribuídos a cada 1.000 etapas, com os pesos embaralhados dentro do grupo pela memória compartilhada NVLink. O desequilíbrio medido — rank mais lento dividido pela média — ficou em 1,074 para uma configuração EP4/DP4 e 1,045 para EP2/DP2. Para o decode, as configurações se estendem: um especialista redundante por GPU, uma janela de estatísticas de 1.000 etapas, redistribuição a cada 10.000 etapas e um desequilíbrio medido de 1,090. A diferença entre os dois é justamente o ponto. O prefill lida com trabalho em rajadas e heterogêneo e precisa de rebalanceamento rápido; o decode lida com um fluxo constante e pode se dar ao luxo de uma janela longa, então rebalanceia raramente e paga quase nada por esse privilégio.

O lado de roteamento tem a mesma característica. As solicitações de prefill são agrupadas pelo comprimento total do contexto em quatro faixas — abaixo de 16K, de 16 a 64K, de 64 a 256K e 256K ou mais — e as engines são atribuídas às faixas de acordo com a participação de cada faixa na demanda computacional da rodada anterior. Dentro de uma GPU, o tamanho do chunk para cada etapa de prefill não é fixo: um modelo de custo quadrático ajustado prevê quanto tempo uma etapa levará, dado o número de tokens da sequência e o prefixo já computado, e o agendador determina o maior chunk que cabe em um orçamento de 32.768 tokens dentro do tempo restante. O balanceador de decode equilibra duas dimensões ao mesmo tempo, a contagem de solicitações e o comprimento total do cache KV, enviando solicitações curtas para GPUs com baixa concorrência e cache longo, e solicitações longas para GPUs com cache pequeno. O próprio resumo da DeepSeek sobre quanto tudo isso rende: aproximadamente 80 por cento de um benchmark offline perfeitamente balanceado.

O cache, e a questão dos três dias

O cache KV fica em um cluster 3FS dedicado, não na memória local do host, e essa decisão orienta o restante do design de armazenamento. Os dados são armazenados com codificação de apagamento 10+2, de modo que cada grupo de codificação sobrevive a duas falhas simultâneas de nós; uma leitura envia solicitações a todos os 11 nós do grupo e quaisquer 10 respostas bastam para decodificar. Um worker de coleta de lixo é executado em cada nó de armazenamento e remove entradas segundo o LRU após um limite predefinido. O servidor recomendado tem 20 unidades de estado sólido de 30,73 TB cada e sustenta pelo menos 40 GB/s de leitura e 5 GB/s de gravação, dimensionado para retter aproximadamente 24 horas de dados por servidor. Na prática, o cluster opera com cerca de 14,4 TB de cache lógico por GPU online, com capacidade física maior que isso.

A residência é onde o trade-off se torna visível. Não há lógica de expiração no lado do cache; o TTL é definido no lado do armazenamento em três dias para tráfego de agentes e sete dias para tráfego de chatbots, em um cluster com cerca de 100 petabytes de armazenamento em estado sólido. A divisão existe porque o tráfego de chatbots tem uma cauda longa de acertos muito mais pesada — uma pequena quantidade de cache é lida repetidas vezes, de modo que perdê-la custa mais à taxa de acerto geral do que o volume sugere. O custo medido pela DeepSeek de reduzir a retenção de chatbots para três dias é de 0,5 a 1 por cento da taxa de acerto do cache. Esse é um número pequeno que, por acaso, representa uma grande quantidade de prefill recalculado.

A atenção de janela deslizante recebe um cache separado com regras diferentes. O cache SWA não entra nos blocos paginados; cada sequência ocupa um slot de tamanho fixo na memória do host e, para o DeepSeek-V4.1-Flash, as camadas armazenadas são as 20 primeiras. Apenas essa região persiste — 20 camadas por 134 tokens por 528 bytes, o que dá 1.415.040 bytes por sequência em um formato MXFP8. Nada vai para o cluster de armazenamento; permanece na memória da máquina que o produziu, com um diretório em memória registrando qual máquina contém o quê, e um acerto entre máquinas o traz de volta por uma VLAN de 400 Gbps.

Os dois mecanismos que produzem os números de destaque

O replay limitado é o mais interessante dos dois porque pega um custo ilimitado e o torna constante. Normalmente, um cache miss de janela deslizante significa recalcular a janela desde o início, e o custo cresce com o comprimento do contexto e o número de camadas. Em vez disso, o DeepSeek recalcula apenas os 128 tokens mais recentes e trunca a janela de atenção para esse segmento, produzindo um cache SWA aproximado a um preço fixo. No lado do encoder, isso desacopla completamente o comprimento de acerto do cache de prefixo do cache SWA: se o cache SWA estiver ausente, os últimos 128 tokens do prefixo com acerto são reproduzidos, enquanto o cache de blocos é reutilizado sem alterações.

É no lado do decodificador que a economia é grande. Nesta arquitetura, o cache de blocos das camadas do decodificador é projetado a partir do estado oculto da última camada do codificador, de modo que apenas o cache SWA do decodificador precisa ser computado por camada — e reconstruí-lo exatamente significaria passar os últimos 2.560 tokens por 20 camadas do decodificador em cada prefill. Reprocessar 128 tokens em vez disso, e usar o resultado apenas para decodificação em vez de deixá-lo entrar no cache de prefixo, quase reduz pela metade a computação total de prefill. Essa única mudança vale mais do que a maioria das otimizações de kernel, e é o tipo de coisa que só uma equipe que controla a arquitetura do modelo consegue fazer.

A contribuição do DSpark é menor e mais convencional. Os tokens de rascunho têm probabilidades de aceitação diferentes conforme a requisição e a posição, então verificar cinco rascunhos fixos por etapa desperdiça computação com tokens que serão rejeitados. Uma cabeça de confiança prevê a taxa de aceitação de cada token de rascunho, e o escalonador ordena os rascunhos pelo retorno esperado e verifica apenas o prefixo que maximiza a vazão. Em produção, o modelo de rascunho ainda gera cinco tokens por etapa; o número verificado cai de 5,00 para entre 3,2 e 4,4, uma redução de cerca de 30%, enquanto o comprimento aceito quase não muda — 3,29 contra 3,20. Lendo os dados de benchmark EP64/DP64, isso resulta em 4 a 7% mais vazão com cerca de 60 sequências simultâneas por rank. Em exatamente 60, a vazão por rank passa de 13.730 para 14.466 tokens por segundo. Abaixo de cerca de 16 sequências simultâneas, a técnica é uma pequena perda líquida, o que vale saber antes de adotá-la em uma implantação de baixo tráfego.

O que significa o número de 155 trilhões

O número mais citado associado a este lançamento é um único cluster que processa 155 trilhões de tokens por dia, com receita total de 38 dólares americanos por hora de GPU a preços de vale. As duas metades são informadas pelo fornecedor e nenhuma delas é um benchmark que você possa reproduzir, o que não as torna desinteressantes — um valor de receita por hora de GPU é um tipo de alegação genuinamente diferente de um número de throughput, porque condensa utilização, precificação e taxa de acerto de cache em uma única linha. É também o número mais provável de ser citado sem seus qualificadores, então os qualificadores merecem ser registrados: um cluster, preços de vale, receita em vez de custo, e agregado entre pré-preenchimento, decodificação e codificador de visão.

Duas divulgações menores são mais diretamente úteis. O kernel de decodificação FlashMLA no repositório público carece de uma otimização em assembly ajustada manualmente que a versão interna possui, o que o torna de 5 a 10 por cento mais lento isoladamente; a DeepSeek afirma que o desempenho ponta a ponta difere no máximo em 5 por cento. E o modelo de rascunho interno para decodificação especulativa é mais novo que o publicado, com a diferença de desempenho descrita como pequena. Ambas as afirmações estabelecem uma expectativa sobre quanto do desempenho publicado um terceiro pode alcançar copiando o código, e a resposta é: a maior parte dele, desde que o hardware corresponda.

O repositório, como está

A captura acima foi feita em 21 de outubro de 2026 e mostra a página exibindo 16,3 mil estrelas. A API do GitHub, consultada no mesmo dia, retornou 16.590 estrelas, 1.649 forks e 176 issues abertas, com as issues desativadas e as discussões redirecionadas para o GitHub Discussions. A contagem de estrelas continuou subindo desde então, então leia cada número aqui como um indicador temporal, e não como uma propriedade do código. Um tráfego desse tamanho em menos de uma semana diz mais sobre o interesse na stack de serving da DeepSeek do que sobre a prontidão do código, e a contagem de zero releases diz o resto.

Se você está pensando em executá-lo por conta própria

O resumo honesto é que o DeepInfer vale a pena ser lido com atenção e é difícil de operar. Quatro perguntas dirão se ele é adequado.

• Você tem SM100 ou Ascend 950? Todo o resto na cadeia de ferramentas decorre desta. Sem o acelerador certo, os números publicados não se transferem, e os ports da comunidade não são validados em escala de produção.

• Você consegue executar 64 GPUs de decodificação em um único domínio de comunicação? O paralelismo amplo de especialistas não é uma otimização que você possa pular; é a configuração em torno da qual o caminho de decodificação foi projetado. Abaixo dessa escala, você está executando um sistema diferente com o mesmo nome.

• Você já possui um cache de prefixo? Se não, você está comparando o caminho de computação do DeepInfer com uma stack concorrente que já vem com um, e a comparação parecerá pior do que o design merece.

• Você tem condições de escrever a camada de roteamento? O bucketing de prefill, o balanceamento de decode e a reatribuição de especialistas estão descritos bem o suficiente para serem reimplementados, e reimplementá-los dá semanas de trabalho que o repositório não faz por você.

Se preferir não possuir nenhum dos itens acima

Para a maioria das equipes, a questão prática não é como implantar o DeepSeek-V4.1-Flash, mas onde chamá-lo. O modelo está disponível por meio de uma API compatível sem construir um cluster de 128 GPUs ou reimplementar um balanceador de carga, e é o mesmo modelo cuja arquitetura este artigo vem descrevendo — mesmo tratamento de contexto, mesmo comportamento de saída estruturada, sem o trabalho de desagregação.

A comparação a fazer não é qual mecanismo é mais rápido em abstrato, porque os números publicados são medições relatadas pelo fornecedor em hardware que a maioria dos leitores não possui. É saber se a carga de trabalho é uma em que um TTL de cache de 3 dias e um pool de decodificação de 64 GPUs mudam o preço, ou uma em que uma requisição a cada poucos segundos por meio de uma API é simplesmente mais barata do que qualquer uma das operações descritas acima. Para o segundo caso — que é a maioria dos casos —, a quantidade certa de DeepInfer a usar é nenhuma, e a quantidade certa a ler é toda ela. Comece em a página do modelo DeepSeek V4.1 Flash se quiser o endpoint; comece pelo README do repositório se quiser saber o que o endpoint está fazendo.