DeepInfer: o motor de inferência aberto pela DeepSeek

O DeepInfer é o motor de inferência que a DeepSeek anunciou em 20 de outubro de 2026 sob Apache 2.0, e ele roda um único modelo, o DeepSeek-V4.1-Flash. O pacote entrega kernels e paralelismo. Não entrega a camada que transforma motor em serviço.

O repositório oficial, lido em 22/10/2026 e criado em 16 de outubro, distribui o motor sob Apache 2.0, com o deepseek-recipe, repositório separado, sob MIT, e lista sob o título "Required for a complete inference service (not included in this release)" três itens: KV cache, a desagregação entre vision encoder, prefill e decode, e o balanceamento entre réplicas data-parallel.

O que veio é o motor. O que ficou de fora é a especificação de uma camada de serving.

O que o DeepInfer entrega

O DeepInfer entrega o motor em kernel e paralelismo: FlashMLA, DeepGEMM, DeepEP, TileKernels, DeepSelect, atenção em DP com CP balanceado, MoE em EP com EPLB, DSpark e saídas estruturadas em regex, JSON schema e EBNF. É o framework de inferência, não o serviço.

Uma cláusula evita confusão: atenção em DP com CP balanceado é recurso do motor, mas o Q&A diz que, no serviço que a DeepSeek opera com o V4.1-Flash, "TP and CP are not used for now". O release habilita o que a produção dela não usa.

O escopo é estreito. O README lista o DeepSeek-V4.1-Flash como único modelo, com o checkpoint DeepSeek-V4.1-Flash-1017. A janela de 1M e o max_tokens de pelo menos 256K vêm do model card.

O protocolo se completa com o deepseek-recipe, em Rust com bindings Python e licença MIT, criado em 10/09/2026: traduz Messages, Chat Completions e Responses para o formato da DeepSeek e devolve resposta completa ou streaming.

O compromisso publicado é curto: o código de inferência dos modelos seguintes continua aberto no DeepInfer. O motor que veio é próximo do interno, não idêntico: o kernel de decode interno da FlashMLA é de 5% a 10% mais rápido, com no máximo 5% ponta a ponta.

O README declara que o DeepInfer foi construído principalmente sobre o vLLM, o que muda a conta do fork.

O que não vem no pacote

O README do DeepInfer reserva três parágrafos ao que falta, e o Q&A de deployment repete a lista: KV cache, a desagregação entre vision encoder, prefill e decode e o balanceamento entre réplicas. Nada disso está no repositório.

O subsistema de cache ocupa cerca de 100 PiB de SSD, com TTL de 3 dias para agente e 7 para chatbot.

A ressalva está no README: a desagregação entre vision encoder, prefill e decode não vem, e o README acrescenta que "most required engine functionality is already implemented". Falta sobretudo a camada de implantação.

O EPLB vem incluído no pacote e faz colocação de especialistas, não admissão de requisição entre réplicas. O Expert-Parallel Load Balancer que o Q&A lista entre os quatro balanceadores internos é o balanceador de réplica que falta: com #DP = #EP, a réplica EP é também a réplica que recebe requisição. Tratar por que failover não é load balancer e admissão entre réplicas como a mesma função é o mesmo erro de categoria.

O Q&A nomeia cinco componentes internos: Prefill Load Balancer, Decode Load Balancer, Vision Encoder Load Balancer, Expert-Parallel Load Balancer e KVCache Storage. E nomeia um sexto, o Entrypoint, que faz match de prefixo por hash-chain sobre metadados contra o kvcache-store local antes do roteamento.

A transferência de KV cache entre modelos e agentes é o problema que esse cluster resolve. É plano de dados.

O número que dimensiona a lacuna é uma frase do Q&A: "we reach roughly 80% of a perfectly balanced offline benchmark". É a DeepSeek medindo o próprio serviço contra o gráfico offline que publica, com os balanceadores dela no hardware dela. Não é piso de terceiro nem algo que um gateway recupera.

Imagem: DeepSeek, Documentacao do DeepInfer (github.com/deepseek-ai/DeepInfer)

Offline não é serving

O README do DeepInfer descreve o release como "offline inference with the core features needed for serving at scale", e o código confirma: os exemplos são scripts de inferência, benchmark e varredura de concorrência. O único módulo com "server" no nome expõe /profile. Ele não atende requisição.

O Q&A tira a ambiguidade: prefill é dimensionado por tokens não cacheados, decode por requisições em execução. Um engine de decode recebe aviso de desligamento e tem 1 minuto para repassar requisições e KV cache, e a implantação mantém cota redundante e proíbe redução quando a utilização passa de 0,8.

"1P + 1D is deployable", com razão de aproximadamente 1:1 e decode recomendado em EP64 ou acima; a menor unidade eficiente é 64 GPUs de prefill mais 64 de decode. O benchmark usa 4 GPUs SM100 para prefill e 64 para decode: a distância entre os dois é a distância entre um gráfico e uma fatura. Uma GPU com falha torna a instância inteira inutilizável, e a escolha de pesos abertos contra modelos hospedados muda com isso.

Os números que a DeepSeek publicou, e o que eles medem

Nenhum número de desempenho desta peça foi medido por terceiro. Os de vazão do motor são auto-relatados pela DeepSeek e vivem nos gráficos de Pareto do repositório, transcritos pelo MarkTechPost em 20/10/2026: acima de 25.000 tokens de saída por segundo por GPU, em EP64DP64, nextn=3, 75% de aceitação e 256 requisições por rank. Os 80% e os 155 trilhões vêm do Q&A, não dos gráficos.

Sem esse recorte, o número não existe: ele vale para 64 GPUs de decode e 131.072 tokens de contexto, com perto de 100 tokens por segundo por usuário e 300 com 8 requisições. Em Ascend não há medição: os benchmarks são em SM100.

A única cifra em dólar é de outra natureza: um cluster serve 155 trilhões de tokens por dia, com receita de US$ 38 por GPU-hora a preço fora de pico, o "valley pricing" do Q&A lido em 22/10/2026. Receita não é custo. Preço fora de pico não é preço de tabela, e framework aberto não tem preço por token. Quem quer reduzir custo de inferência precisa da própria carga medida.

Duas máquinas, dois conjuntos de recursos

O DeepInfer cobre duas plataformas e nenhuma terceira: NVIDIA SM100 e Huawei Ascend 950 NPU, com build em Linux, GCC 13 ou superior, Python 3.12, CUDA 13 num caminho e CANN 9.2 no outro. Gerações anteriores da NVIDIA, incluindo Hopper, ficam fora.

A paridade para no build. Inferência batch-invariant e amostragem determinística vêm marcadas como "(NVIDIA only)", com variáveis de ambiente e seed fixa próprias. No caminho Ascend nenhuma das duas existe, e paridade de produção é afirmação que a fonte não sustenta.

O número também existe de um lado só: 25.000 tokens por GPU e 80% do benchmark são de SM100, e o caminho Ascend entrega build, não curva. Paridade de dia um ali é rodar o V4.1-Flash.

O que o operador ainda tem de construir ou comprar

O DeepInfer precisa de três planos, não dois: modelo, cluster e gateway. Um gateway de LLM cobre escolha de modelo, provedor e endpoint, failover, teto de gasto, trace e a escolha da réplica com menos trabalho em voo. Não cobre storage de 100 PiB, tecido P/D, admissão dentro do engine nem drain com repasse de cache.

O trade-off fecha o argumento. O Q&A escreve que "since any engine can hit any prefix, there is no prefix-affinity routing", porque o tier 3FS torna qualquer prefixo alcançável. Afinidade sem tier compartilhado é acordo pior que o pull por cota.

Cinco peças, com dono e custo:

1. Tier de KV cache: cluster 3FS, TTL de 3 e 7 dias. Dono: plataforma e storage. Errar custa prefill repetido.
2. Tecido P/D: move KV entre estágios a 400 Gbps por 8 GPUs. Dono: plataforma e rede. Errar junta os estágios na mesma máquina.
3. Admissão entre réplicas: lê a fila real do engine. Dono: serving. Errar custa GPU ociosa.
4. Drain: aviso de 1 minuto com repasse de KV. Dono: plataforma. Errar custa requisição perdida.
5. Cota e EP size: capacidade redundante e EP redefinido após falha. Dono: SRE. Errar custa a instância inteira.

O Nexforce Router entra aqui como categoria: plano de controle, roteia entre modelos e provedores, e não guarda o cache do engine, não separa prefill de decode nem executa o DeepInfer. O custo operacional de um gateway de IA em produção é a conta do que ele cobre.

O critério de decisão antes do primeiro clone

Quatro respostas decidem se baixar o repositório do DeepInfer economiza trabalho: o piso de hardware na sua carga, quem guarda o KV cache, quem admite requisição entre réplicas e o custo real de manter um fork. Nenhuma das quatro está no README.

1. Piso de hardware: não são 4 GPUs, e sim a unidade de 64 mais 64, ou uma fração em 1P+1D.
2. Dono do KV cache: se é o seu cluster, o trabalho é o tier de 100 PiB; se é o provedor, você consome endpoint.
3. Admissão entre réplicas: o release não traz; se ninguém no time já construiu uma, é ela que define o prazo.
4. Custo do fork: Apache 2.0 permite fechar, e a conta chega na primeira atualização a portar.

Perguntas frequentes

O que é o DeepInfer?

DeepInfer é o motor de inferência que a DeepSeek anunciou em 20 de outubro de 2026 sob Apache 2.0, com kernels, paralelismo, decodificação especulativa e saídas estruturadas para o DeepSeek-V4.1-Flash. É o framework de inferência, não o serviço: os exemplos do repositório são scripts offline, e a camada de serving, com KV cache, a desagregação entre vision encoder, prefill e decode e o balanceamento, ficou fora.

O DeepInfer substitui a API da DeepSeek?

Não. O DeepInfer entrega o código que roda o modelo no hardware do operador; a API da DeepSeek entrega inferência como serviço, com o cluster, o KV cache e os balanceadores que o release não inclui. Rodar o motor significa assumir storage, rede e admissão de requisição, além do drain que o próprio Q&A descreve. Os US$ 38 por GPU-hora são receita, não custo.

O que falta para rodar em produção?

O DeepInfer chega sem três itens que o README lista como necessários a um serviço completo: KV cache, a desagregação entre vision encoder, prefill e decode e o balanceamento entre réplicas data-parallel. O Q&A de deployment acrescenta autoscaling, cota redundante, drain com repasse de KV e o Entrypoint que casa prefixo por hash-chain. Engine, paralelismo e EPLB já estão no pacote; o que falta é a camada de operação.

Qual é a licença e dá para usar comercialmente?

O DeepInfer usa Apache 2.0, confirmada no README e no campo de licença do GitHub, e o deepseek-recipe, repositório separado, usa MIT, confirmado no LICENSE. As duas permitem uso comercial e modificação, sem obrigação de publicar o que se constrói em cima. O que a licença não entrega é o código que falta: os balanceadores e o KVCache Storage ficaram na infraestrutura da DeepSeek.

Referências

Fontes lidas em 22/10/2026.

• Repositório oficial do DeepInfer, README e doc/inference_deployment_qa.md, https://github.com/deepseek-ai/DeepInfer, 20/10/2026.
• deepseek-ai/deepseek-recipe, LICENSE (MIT), criado em 10/09/2026.
• Model card do DeepSeek-V4.1-Flash-1017, huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash-1017.
• DeepSeek, documento sobre a abertura do motor de inferência, abril de 2025.
• Post da DeepSeek no X, 20/10/2026, via The New Stack.
• MarkTechPost, DeepSeek Open-Sources DeepInfer, 20/10/2026.
• The New Stack, DeepSeek open-sources the inference engine behind its API, 20/10/2026.

Próximo passo

O teste custa menos que o fork. Rodar o mesmo prompt em mais de um modelo, medir o que muda em qualidade, latência e custo por tarefa e escolher onde cada requisição cai responde em uma tarde o que o repositório não responde. O Nexforce Router existe para essa etapa, com uma API, uma key e teto de gasto por key.