DeepSeek DeepInfer: requisitos para hospedar por conta própria ou usar uma API

O DeepInfer é o framework de inferência de código aberto do DeepSeek. Ele executa um modelo; não é um novo modelo nem uma API hospedada pronta para uso. Para quem está escolhendo como usar o DeepSeek, a primeira questão é se operar o backend de inferência faz parte do trabalho. Se o objetivo é entregar uma aplicação, compare uma API hospedada com todo o serviço que sua equipe teria de construir e manter.

Este guia analisa a documentação oficial consultada em 22 de outubro de 2026. Não implantamos o DeepInfer em aceleradores compatíveis nem reproduzimos seus gráficos de desempenho. As listas de verificação e a planilha de custos abaixo são ferramentas de decisão; o exemplo numérico é deliberadamente hipotético. A Ofox oferece acesso via API e publica este artigo. Por isso, explicamos as condições de cada alternativa sem presumir que um serviço hospedado seja a melhor escolha para todos.

O papel do DeepInfer, do modelo e do deepseek-recipe

Implantar um modelo envolve responsabilidades diferentes. Tratar os nomes desses componentes como sinônimos dificulta tanto a estimativa de custos quanto o diagnóstico de erros.

O README do DeepInfer lista DeepSeek-V4.1-Flash como modelo suportado e usa deepseek-ai/DeepSeek-V4.1-Flash-1017 como checkpoint padrão. Nosso guia da atualização 1017 (em inglês) trata das mudanças da versão do modelo; aqui, o foco é o mecanismo e a decisão de implantação.

O repositório separado deepseek-recipe converte os formatos Chat Completions, Responses e Messages. A aplicação que o chama ainda precisa fornecer a inferência, a execução de ferramentas e o transporte HTTP. Os servidores de exemplo em Python e Rust usam inferência simulada. Receber JSON de uma dessas demonstrações não comprova que um modelo real gerou a resposta.

Isso estabelece três verificações distintas para o desenvolvedor: receber uma resposta HTTP, montar corretamente o prompt e obter uma geração válida do modelo. Passar em uma delas não comprova as outras duas.

Confira o hardware suportado antes de planejar a instalação

O README atual lista GPUs NVIDIA SM100 e NPUs Huawei Ascend 950, com Linux, GCC 13 ou superior e Python 3.12. Os requisitos específicos são CUDA 13 para NVIDIA e CANN 9.2 para Ascend. São as plataformas documentadas na data da consulta, não uma promessa sobre adaptações futuras.

RTX 4090 e H100 não aparecem nessa lista. Essa ausência não significa que modelos DeepSeek nunca possam rodar nessas placas: executá-los por outro mecanismo é uma questão de compatibilidade diferente. Da mesma forma, uma proposta de adaptação em um pull request da comunidade não confirma suporte na versão publicada.

Registre a arquitetura exata do dispositivo, as versões de drivers e ferramentas, o checkpoint e a revisão do mecanismo antes de estimar o esforço de implementação. Se faltar um pré-requisito, comece pela avaliação de compatibilidade. Alugar uma máquina cara apenas para descobrir se uma configuração não suportada talvez compile não é um bom primeiro experimento.

Mantenha separadas três perguntas:

1. Tem suporte? A documentação desta versão do mecanismo inclui sua plataforma?
2. Consegue executar? O modelo cabe na configuração escolhida e a inferência termina corretamente?
3. É eficiente? Atende às metas de vazão e latência na carga esperada?

As perguntas e respostas oficiais sobre implantação descrevem, no projeto de produção recomendado, uma menor unidade eficiente composta por 64 GPUs de prefill e 64 GPUs de decode. Isso não é um mínimo absoluto de GPUs para todo teste off-line. As configurações de benchmark do README também diferem entre prefill e decode. Nenhum desses números deve virar uma lista universal de “hardware mínimo” para compra.

O que falta entre a inferência off-line e uma API on-line

O README público identifica três partes ainda necessárias para um serviço completo: um sistema de cache KV, a separação de VE/Prefill/Decode e o balanceamento entre réplicas com paralelismo de dados. VE é o codificador visual; prefill processa o prompt, e decode gera os tokens seguintes. A documentação também informa que boa parte das funções do mecanismo necessárias à separação já foi implementada. Ter essas funções básicas não equivale a ter um serviço completo montado e operado.

No planejamento, defina um responsável e um teste de aceitação para cada atividade:

Essa tabela propõe uma verificação operacional. Ela não afirma que o DeepInfer já inclui todas as funções da primeira coluna. Operar o próprio hardware, em particular, não resolve automaticamente a privacidade: ainda é preciso controlar acesso às máquinas, aos logs, aos backups e aos prompts em cache.

Faça perguntas equivalentes ao provedor da alternativa hospedada. Um nome de endpoint compatível não garante comportamento idêntico de ferramentas, contabilização do cache ou condições de retenção. Se você quer apenas conectar um cliente de programação, comece pelo guia do Codex (em inglês) ou pelo guia do Claude Code (em inglês) e confirme o suporte atual da rota antes de adicionar infraestrutura.

Compare custos para a mesma carga e o mesmo nível de serviço

Um gráfico de pico de tokens por segundo não revela o custo mensal. Comece com uma carga representativa: distribuição do tamanho das entradas, comprimento das saídas, frequência de prefixos repetidos, uso de imagens quando aplicável, requisições simultâneas e picos diários. Estabeleça metas para requisições concluídas, qualidade, tempo até o primeiro token e velocidade do streaming. Um serviço barato que não atende a essas metas não é uma alternativa equivalente.

Na estimativa da API, separe os preços de entrada sem cache, entrada com cache e saída. Some escrita de cache, armazenamento, plataforma ou outras cobranças somente quando o provedor realmente as aplicar. Valores desconhecidos são pendências, não zero. As quantidades de tokens precisam seguir a definição de cobrança, incluindo tokens de raciocínio quando aplicável. Nosso guia de preços da API DeepSeek (em inglês) explica o tema; obtenha uma cotação atual para a rota exata antes de decidir uma compra.

Uma planilha geral, com quantidades em milhões de tokens cobrados:

Custo mensal da API =
  milhões de tokens de entrada sem cache × tarifa correspondente
  + milhões de tokens de entrada com cache × tarifa correspondente
  + milhões de tokens de saída cobrados × tarifa de saída
  + outras cobranças mensais aplicáveis

Custo mensal da hospedagem própria =
  aluguel de aceleradores OU depreciação alocada do hardware
  + servidor, rede e armazenamento
  + energia ainda não incluída no aluguel
  + trabalho de operação e suporte
  + redundância e capacidade de recuperação
  + custos que variam com a carga

Não contabilize o mesmo acelerador como aluguel e, novamente, como depreciação. Também não acrescente energia se ela já estiver incluída no aluguel. Aloque explicitamente o tempo de equipes compartilhadas. Para cada valor desconhecido, procure uma cotação ou medição e apresente uma faixa, em vez de esconder a incerteza em um total aparentemente preciso.

Exemplo reproduzível, não uma cotação do DeepInfer

Suponha que uma unidade de carga contenha 100 milhões de tokens de entrada e 20 milhões de tokens de saída cobrados, com 60% da entrada contabilizada como acertos de cache. Apenas para ilustrar, use US$ 0,80 por milhão de tokens de entrada sem cache, US$ 0,20 por milhão com cache e US$ 2,00 por milhão de saída. Esses valores foram inventados para o cálculo; não são preços atuais do DeepSeek ou da Ofox, nem uma conversão para reais.

O custo variável da API por unidade é 40 × 0,80 + 60 × 0,20 + 20 × 2,00 = US$ 84. Suponha também uma taxa mensal de plataforma de US$ 16. Para a hospedagem própria, suponha US$ 50.000 de custos fixos por mês e mais US$ 20 de custo variável por unidade. Nenhuma dessas premissas representa uma cotação real de hardware para DeepInfer.

Com essas premissas, a igualdade é 84x + 16 = 50.000 + 20x, ou x = 781 unidades por mês. Essa conta não é uma recomendação de implantação. A configuração fixa precisa suportar esse volume com as metas escolhidas de latência e confiabilidade. Se forem necessários mais clusters para atender 781 unidades, recalcule o custo fixo: o ponto de equilíbrio aparente pode deixar de existir.

Reduzir os acertos de cache de 60% para 20% aumenta, neste exemplo, o custo variável da API de US$ 84 para US$ 108 por unidade. A capacidade e os custos da hospedagem própria também podem mudar quando menos trabalho é reaproveitado. Não mantenha artificialmente um dos lados constante para anunciar uma economia exata. Avalie separadamente meses de baixa demanda, demanda esperada e picos.

Faça um piloto que possa reprovar qualquer uma das opções

Para uma equipe que considera hospedar por conta própria, esta sequência deve anteceder o compromisso com produção:

1. Defina a carga e os critérios de sucesso. Preserve uma amostra representativa com dados sensíveis devidamente removidos. Estabeleça requisitos de qualidade, latência, falhas e tratamento de dados antes de escolher a solução.
2. Resolva a compatibilidade da plataforma. Registre o acelerador, o ambiente de software, o checkpoint e a revisão do código. Consulte os exemplos atuais do repositório, não um comando de instalação sem versão em um blog.
3. Verifique a correção off-line. Execute os exemplos e avaliações oficiais pertinentes nesse ambiente. Registre resultados e falhas. Compilar com sucesso não comprova qualidade de geração nem compatibilidade de protocolo.
4. Teste o caminho real do serviço. Substitua qualquer backend simulado e valide uma requisição completa e outra com streaming. Se precisar de ferramentas, confira os argumentos gerados e a execução pela aplicação separadamente. Teste entrada inválida, timeout, cancelamento pelo cliente e sobrecarga.
5. Meça uma carga realista. Inclua prompts curtos e longos, caches quentes e frios, períodos ociosos e picos de concorrência. Registre trabalho concluído, distribuição de latência, falhas e todos os recursos cobrados.
6. Compare com uma rota hospedada. Mantenha versão do modelo e comportamento das requisições tão comparáveis quanto possível. Documente diferenças que limitem a comparação, como quantização, configuração de raciocínio e funções ausentes.
7. Recalcule e decida. Mantenha uma rota de retorno e um responsável pela operação. Se uma alternativa não cumprir um requisito obrigatório, um custo médio favorável não deve salvá-la.

Se o piloto falhar, classifique o problema antes de gastar mais: erro de compilação pertence ao ambiente de build; falta de memória exige análise do modelo e da capacidade em execução; uma resposta simulada válida é apenas um resultado do ambiente de testes; argumentos de ferramentas malformados exigem investigar o protocolo e o caminho do modelo. Nenhum desses resultados comprova que outra chave de API ou uma máquina maior resolverá tudo.

Escolha uma alternativa que sua equipe consiga operar

Uma API hospedada é uma primeira candidata razoável quando a demanda é incerta, o uso é intermitente, a equipe precisa entregar rápido ou não há responsável pelos aceleradores. Valide limites e condições do provedor, em vez de supor que todas as rotas hospedadas são intercambiáveis.

A hospedagem própria merece um piloto quando há infraestrutura compatível, uma equipe capaz de operar o serviço completo, demanda contínua ou uma exigência concreta que as opções hospedadas disponíveis não atendem. Ter hardware não torna o projeto gratuito: conte o custo de oportunidade e as pessoas que darão suporte.

Antes da decisão, preencha este registro:

Tarefa e versão exata do modelo:
Requisitos obrigatórios de qualidade, latência e dados:
Carga mensal esperada / baixa / de pico:
Comportamento medido do cache e categorias de tokens cobrados:
Plataforma própria e responsável pela operação:
Rota hospedada e dúvidas de contrato ou funções:
Faixa de custo mensal total de cada opção:
Evidência de capacidade que sustenta a estimativa:
Resultado do piloto, rota de retorno e data da decisão:

O DeepInfer é relevante por disponibilizar uma parte substancial da engenharia de inferência. Ainda assim, adotá-lo deve resultar em um serviço operável e em uma estimativa adequada à sua carga. A disponibilidade do código aberto, sozinha, não comprova redução na conta de API nem justifica reconstruir uma aplicação que já funciona em torno de outro backend.