AIREITER

Suporte do DeepInfer a H100: o que a lista oficial realmente significa

Última Atualização: 2026-10-21 06:07:56

A resposta curta para equipes com H100 e RTX

O suporte do DeepInfer a H100 não foi anunciado nem documentado oficialmente. O mesmo vale para GPUs RTX. A versão atual é voltada ao DeepSeek-V4.1-Flash e lista hardware NVIDIA SM100 com CUDA 13 ou Ascend 950 com CANN 9.2. O repositório também exige Linux, GCC 13 ou mais recente e Python 3.12 (repositório oficial do DeepInfer).

Quando um hardware “não está listado”, isso deve ser entendido como uma decisão de suporte para compras e planejamento de produção — não como prova de que um patch experimental jamais poderá ser compilado.

O que o DeepInfer suporta oficialmente hoje

O limite de suporte é mais específico do que simplesmente dizer “GPU NVIDIA” ou “modelo DeepSeek”. Ele combina uma geração de acelerador, uma pilha de software e um caminho de execução determinados.

ComponenteSuporte documentado
ModeloDeepSeek-V4.1-Flash
Checkpoint padrãodeepseek-ai/DeepSeek-V4.1-Flash-1017
Acelerador NVIDIASM100, associado às GPUs Blackwell para data centers
Toolchain NVIDIACUDA 13
Acelerador HuaweiNPU Ascend 950
Toolchain HuaweiCANN 9.2
Requisitos do hostLinux, GCC 13+ e Python 3.12
Modo de inferênciaInferência offline no próprio processo

O FAQ de implantação do DeepSeek apresenta topologias de benchmark com 4 GPUs SM100 para prefill e 64 GPUs SM100 para decode em um domínio de scale-up. Essas medições foram feitas em SM100, não são estimativas de capacidade para H100.

Por que SM100 não significa automaticamente H100 ou RTX

A lista oficial do DeepInfer não menciona H100, SM90 nem nenhum modelo RTX. A compatibilidade com CUDA, sozinha, não comprova a compatibilidade com o DeepInfer.

O repositório integra componentes sensíveis à arquitetura, como FlashMLA, DeepGEMM, DeepEP e operações do TileLang (documentação do projeto). Mesmo quando uma GPU é reconhecida como alvo, ainda pode haver falhas em tempo de execução, resultados incorretos ou perda do desempenho que motivou a migração.

Por isso, é importante separar três afirmações:

  1. O código compila para uma determinada arquitetura.
  2. O modelo executa com resultados corretos e comportamento distribuído estável.
  3. A implantação entrega latência e throughput úteis em produção.

Apenas a primeira afirmação pode ser comprovada por um build bem-sucedido. Os materiais públicos do DeepInfer não trazem benchmark para H100 ou RTX, receita oficial de build para SM90 nem uma configuração validada para RTX de consumo.

Caminhos de migração para a infraestrutura existente

Se o seu cluster usa H100 ou outro sistema Hopper

Não substitua uma infraestrutura de serving em H100 que já funciona apenas para testar o DeepInfer. Encare o trabalho como um projeto experimental de portabilidade, e não como uma implantação suportada.

Um plano de migração sensato inclui:

  1. Manter o servidor de modelos de produção sem alterações.
  2. Criar uma branch isolada com versões fixadas do DeepInfer, CUDA, driver, compilador e modelo.
  3. Mapear as dependências específicas da arquitetura antes da compilação.
  4. Executar testes de comparação numérica com um runtime já validado.
  5. Medir latência de prefill, latência de decode, concorrência, uso de memória e recuperação após falhas.
  6. Promover a portabilidade somente se ela melhorar o workload que realmente importa para a equipe.

A alternativa prática é avaliar um runtime de serving que documente explicitamente a configuração com H100, como vLLM, SGLang ou TensorRT-LLM. A escolha deve considerar o checkpoint exato do DeepSeek, a quantização, os recursos de API e a topologia distribuída necessários — não os números de SM100 do DeepInfer.

Se a equipe usa workstations ou servidores RTX

A lista oficial do DeepInfer não menciona nenhum modelo RTX. Como a topologia de benchmark documentada é voltada a inferência em larga escala, uma única placa RTX ou um pequeno pool de RTX não deve ser tratado como substituto barato das configurações com 4 GPUs para prefill ou 64 GPUs para decode.

Se o objetivo for desenvolvimento, avaliação ou um endpoint self-hosted menor, use um runtime geral de inferência local. Mantenha o DeepInfer no radar para uma futura portabilidade específica de arquitetura, mas não faça orçamento com base em uma issue ainda não integrada ou em uma afirmação de fórum.

Se você tem acesso a SM100 ou Ascend 950

Esse é o único caminho alinhado à matriz oficial atual. Ainda assim, o DeepInfer não é um serviço de API online completo: as notas oficiais de implantação mencionam componentes de produção ausentes, como cache KV persistente, orquestração de prefill/decode e balanceamento de carga entre réplicas.

Isso torna o DeepInfer mais adequado para equipes que querem estudar ou avaliar o mecanismo, têm a topologia de aceleradores exigida e estão preparadas para construir o restante da plataforma. Ele não é automaticamente a melhor escolha para um gateway de API com vários modelos.

Restrições de implantação que vão além da GPU

O suporte de hardware é apenas uma das barreiras da migração. A versão pública é descrita como uma solução de inferência offline, não como um servidor OpenAI-compatible pronto. Os componentes ausentes influenciam diretamente as decisões de arquitetura:

Recurso ausenteConsequência operacional
Cache KV persistente ou distribuídoA reutilização em conversas online com várias interações precisa ser fornecida por outro componente
Desagregação de prefill/decodeO operador precisa cuidar da orquestração e da alocação das etapas
Balanceamento de carga entre réplicasO roteamento e o balanceamento orientado por filas continuam externos
HTTP, autenticação e ferramentasAinda são necessários um gateway de API e uma camada de agentes

O projeto separado deepseek-recipe converte os formatos Messages, Chat Completions e Responses, mas não executa a inferência nem oferece o serviço de produção completo.

Checklist de verificação antes de trocar o hardware

Antes de aprovar uma migração para o DeepInfer, exija evidências para cada item:

  1. Suporte oficial à arquitetura e ao build: A GPU exata está listada? Uma máquina limpa consegue reproduzir o ambiente com as versões fixadas?
  2. Cobertura de kernels e correção: Os kernels de atenção, GEMM e paralelismo entre especialistas produzem resultados equivalentes, respostas estruturadas e comportamento estável com contexto longo?
  3. Desempenho distribuído: A quantidade de GPUs e a topologia de interconexão pretendidas permanecem estáveis nos níveis de concorrência e memória definidos?
  4. Completude do serviço: De onde virão o cache KV, o roteamento, a autenticação, o transporte HTTP e o balanceamento entre réplicas?

Se a resposta para a primeira pergunta for “não”, classifique o projeto como experimental. Se as respostas sobre o serviço forem “externo”, inclua esse trabalho de engenharia no custo da migração.

FAQ sobre o suporte do DeepInfer a H100

O DeepInfer pode rodar em uma NVIDIA H100?

O suporte a H100 não está documentado oficialmente. A entrada atual para NVIDIA é SM100. Uma portabilidade experimental pode ser possível, mas os materiais citados não oferecem uma receita oficial de build nem um benchmark validado em H100.

O DeepInfer suporta RTX 4090, 5090 ou outras placas RTX?

O suporte a RTX não está listado oficialmente. Os materiais oficiais citados não apresentam nenhuma configuração RTX validada. Considere a implantação em RTX sem suporte até que o projeto upstream documente a arquitetura e valide seus kernels.

O que uma equipe com H100 deve usar?

Mantenha ou avalie um runtime com suporte explícito a H100 e compare os resultados usando o seu próprio checkpoint e padrão de tráfego. vLLM, SGLang e TensorRT-LLM são pontos de partida práticos, enquanto o DeepInfer deve ser tratado como um alvo futuro de portabilidade ou como um motivo para avaliar uma infraestrutura SM100.

Considere uma portabilidade para H100 ou RTX experimental até que a arquitetura exata, os kernels, a camada de serviço e os resultados no workload estejam documentados.