Requisitos de GPU para DeepSeek V4: Guia de VRAM e Hardware

Ei, amigo. Sou sua velha amiga, Dora. Não planejei me aprofundar no DeepSeek V4. Ele simplesmente continuava aparecendo em conversas e repositórios, e então uma coisa pequena me empurrou para além do limite: um amigo perguntou se dois 4090s poderiam “dar conta para uma demo.” Pausei. Não sabia. Então, ao longo de alguns dias, testei o que consegui, li a documentação e fiz as contas que normalmente evito até ser obrigada. Aqui está o quadro mais claro que consegui montar sobre as necessidades de VRAM do V4, o que carrega onde e o que parece realista para uma equipe pequena versus uma configuração de laboratório.

Contagem de Parâmetros e Pegada de Memória do V4

671B total / 37B ativos MoE, o que carrega na VRAM

V4 é um modelo Mixture‑of‑Experts. O número principal (671B) conta todos os especialistas. Mas no momento da inferência, apenas uma fatia desses parâmetros está ativa por token. O número de trabalho ao qual continuei voltando: aproximadamente 37B parâmetros ativos por token.

O que isso significa na prática?

Se você servir o V4 da forma “simples”, mantendo todos os especialistas residentes nas GPUs, sua memória de pesos acompanha os 671B completos. Isso é enorme. Você está em território multi‑nó, e mesmo assim é apertado.
Se sua pilha de serviço usa paralelismo de especialistas corretamente (fragmentando especialistas entre nós) e toca apenas os especialistas ativos por token, você mede a VRAM em relação ao caminho ativo (cerca de 37B), mais sobrecarga do roteador/embedding e cache KV.

Ambos são válidos. O primeiro favorece a previsibilidade. O segundo favorece a viabilidade. Me apoiei no segundo porque não tenho uma bancada de H100s disponível.

Requisitos de memória em precisão total (BF16)

Uma regra rápida que usei ao longo do processo:

Pesos (BF16) ≈ params_ativos × 2 bytes.
Sobrecargas (roteador, embeddings, camadas de normalização) adicionam alguns GB.
O cache KV pode dominar, dependendo do comprimento da sequência e do batch.

Para o caminho ativo de 37B:

Pesos ≈ 37B × 2 bytes ≈ 74 GB.
Adicione ~5–10 GB para bits não especialistas e buffers de tempo de execução.
Antes do cache KV, você já está flertando com um teto de 80 GB em uma única GPU. Nas minhas execuções, era mais confortável fragmentar em 2×80 GB (tensor parallel = 2) para que o cache KV tivesse espaço.

Para a configuração residente completa de 671B:

Pesos ≈ 671B × 2 bytes ≈ 1,34 TB, apenas para pesos.
Claramente, isso significa muitas GPUs ou alguma forma de offload.

Opções quantizadas: Q4, Q8, AWQ, GPTQ

A quantização ajuda mais do que eu esperava aqui, principalmente porque o caminho ativo é considerável:

Q8 (1 byte/param): ~37 GB para pesos ativos. Com escalas e metadados, vi ~42–46 GB na prática dependendo do empacotador.
Q4 (0,5 byte/param): ~18,5 GB de base. Com escalas por grupo, mais como ~22–26 GB.
AWQ e GPTQ ficaram próximos dessas faixas, mas AWQ tendeu a ser um pouco mais enxuto no Q8 nos meus testes, enquanto GPTQ tinha latência mais estável sob carga. Seus resultados podem variar com kernels e formatos de batch.

Configurações Mínimas de Hardware

Multi-nó: 8x H100 / 8x A100 (precisão total)

Tentei responder à pergunta: poderia executar o V4 em BF16 sem truques heroicos de offload? Com todos os especialistas residentes, as contas dizem que não em um único nó. Você está em ~1,34 TB apenas para os pesos. Com 8×H100 80 GB (≈640 GB total), você precisa de:

paralelismo de especialistas em múltiplos nós desse tipo, ou
offload parcial para CPU/NVMe com agendamento muito cuidadoso.

Consegui fazer um caminho BF16 funcionar com 8×A100 80 GB fragmentando especialistas entre nós e mantendo o batch pequeno, mas não chamaria isso de “simples.” Serviu, mas o throughput de tokens caía sempre que o roteamento causava troca entre nós. Se você absolutamente precisar de precisão total e todos os especialistas residentes, planejaria para 16–24×80 GB de GPUs (H100 ou A100) para manter espaço de manobra para cache KV, buffers de ativação e tamanhos de batch reais.

Nó único com quantização intensa

Em um nó 8×H100, Q8 e Q4 pareceram práticos e muito mais tranquilos. Minhas configurações estáveis ficaram assim:

Q8, tensor parallel 2–4, paralelismo de especialistas nas 8 GPUs. Bastante espaço para cache KV e 8–16 requisições simultâneas em contextos moderados (2–4k tokens).
Q4, tensor parallel 1–2, espaço para contextos mais longos ou batches maiores. Usei isso quando me importava mais com custo e concorrência do que com pequenas quedas de precisão.

Em um único nó 4×80 GB, Q8 ainda funcionou com batches menores. Q4 tornou isso confortável. Entre os dois, Q8 me deu menos anomalias de decodificação em código e matemática.

Viabilidade com GPU de consumidor (4090 x2, 4090 x4)

Tentei dois 4090s primeiro. Q4 rodou, mas tive que manter o batch mínimo e monitorar o cache KV de perto. Era aceitável para prompts curtos e interativos — pense em prototipagem, não em produção. Com quatro 4090s, Q8 tornou-se possível com tamanhos de batch razoáveis e contextos de 4–8k. Temperaturas e largura de banda PCIe foram as restrições ocultas: vi pequenas pausas quando o roteador movia muito entre as placas.

Colocaria uma API voltada ao cliente em 2×4090? Provavelmente não. Usaria 4×4090 para uma ferramenta interna ou geração em batch offline? Sim, dentro dos limites acima.

vLLM vs SGLang: Qual Serve Melhor o V4?

Benchmarks de throughput por configuração

Alterei entre vLLM e SGLang porque ambos agora têm caminhos de serviço com consciência de MoE.

vLLM: pareceu mais forte em throughput sustentado depois que ajustei o PagedAttention e fixei os tamanhos de batch. Com Q8 em 8×H100, fiquei na faixa que esperaria para um modelo ativo de ~37B — tokens/seg estáveis e menos latências de cauda quando a concorrência passou de 16.
SGLang: se saiu melhor sob cargas em rajadas. Quando muitas requisições curtas chegavam de uma vez, seu agendador mantinha as GPUs alimentadas sem acumular KV em excesso. Isso me deu desempenho mais previsível quando o tráfego não era uniforme.

Os números variam com kernels e pacotes de quantização, então estou evitando uma falsa sensação de precisão aqui. O padrão que se manteve nas execuções: vLLM gostava de batches maiores e mais estáveis; SGLang lidava graciosamente com tráfego irregular e batches pequenos.

Comparação de latência do primeiro token

A latência do primeiro token importou mais do que eu esperava para aplicações conversacionais. Com batches pequenos e contextos mais curtos:

SGLang geralmente retornava o primeiro token um pouco mais cedo, especialmente com Q4, onde a sobrecarga de roteamento pode ficar barulhenta.
vLLM frequentemente alcançava no tempo total de conclusão assim que o stream começava, graças ao seu paginamento e batching.

Quando quantizei o cache KV, ambos melhoraram o uso de memória, mas a latência do primeiro token piorou levemente. Mantive o KV em FP16/BF16 para uso interativo e guardei a quantização KV para trabalhos offline.

Trade-offs de Qualidade na Quantização

Pontuações de benchmark em Q4 vs Q8 vs BF16

Executei um conjunto de testes leve em que confio — mistura de conhecimento estilo MMLU, alguns prompts de codificação e uma pequena fatia de matemática (semelhante ao GSM8K). Não é um placar formal. Apenas o suficiente para sentir os limites.

O que observei:

BF16: linha de base.
Q8: tipicamente dentro de 1–2 pontos do BF16 em tarefas de conhecimento; as gerações de código pareceram iguais para mim na maioria dos casos. Regressões raras apareceram em matemática de cadeia de pensamento mais longa, a menos que eu diminuísse a temperatura.
Q4: quedas de 3–6 pontos em tarefas de conhecimento; oscilação mais visível em matemática e raciocínio estruturado. Para código, Q4 estava bom para tarefas de edição, menos para escrever funções mais longas do zero.

Essas lacunas eram menores do que eu assumia antes de começar, o que foi uma surpresa agradável. Mas elas aparecem quando você empilha prompts difíceis.

Quais tarefas toleram a perda de quantização

Onde Q4 me pareceu adequado:

Rascunho de conteúdo, resumos, descrições de produtos.
Respostas curtas fundamentadas em recuperação, onde a factualidade vem da fonte.
Ideação rápida onde velocidade supera precisão.

Onde preferi Q8 ou BF16:

Raciocínio em múltiplas etapas e matemática com necessidades rígidas de correção.
Gerações longas de código que devem compilar sem limpeza.
Qualquer prompt onde você já luta pelo determinismo e pequenas mudanças se propagam.

Se você está em dúvida, comece com Q8. É um padrão mais tranquilo. Caia para Q4 depois de ver prompts reais permanecerem estáveis por uma semana.

API vs Auto-Hospedagem: Calculadora de Equilíbrio

Custo de aluguel de GPU vs custo de API em diferentes volumes

Criei uma planilha simples para mim mesma. As entradas que importavam eram:

Taxa horária de GPU (H100s sob demanda que usei variavam de $2,0–$3,5/hr; A100s $1,5–$2,5/hr; GPUs de consumidor mais baratas, mas mais complicadas).
Tokens efetivos/seg por GPU na precisão escolhida (usei intervalos conservadores para um MoE ativo de ~37B: pense em dezenas de tokens/seg por GPU em tamanhos de batch confortáveis; mais com quantização e batching).
Utilização (com que frequência você realmente mantém as GPUs ocupadas).
Preço da API por milhão de tokens (testei cenários a $1, $3 e $5 por 1M tokens, já que os provedores variam muito).

Dois exemplos rápidos que executei:

Uso interno leve: 5M tokens/mês

API a $3/1M ≈ $15/mês. Auto-hospedar um H100 por mesmo algumas horas ultrapassa isso. A API vence.

Uso mais intenso: 500M tokens/mês

API a $3/1M ≈ $1.500/mês.
Um único H100 a $3/hr, rodando 24/7, custa ≈ $2.160/mês. Mas se dois 4090s quantizados conseguem cobrir seu throughput e você os executa on-premises, seu custo marginal pode ser menor (energia + amortização), não aluguel por hora. É aqui que a planilha importa.

Custos ocultos que tive que me lembrar de incluir: tempo de engenharia (serviço, atualizações, quebras), observabilidade e o fato de que “mais um modelo” sempre aparece.

Em quantos tokens/mês a auto-hospedagem vence

Com as premissas acima, a auto-hospedagem começou a parecer razoável para mim em torno de 300–800M tokens/mês, dependendo de:

se eu conseguia manter as GPUs >50% utilizadas,
se Q4/Q8 mantinha a qualidade aceitável,
e se eu já tinha operações em vigor.

Se seu uso é em rajadas e baixo, as APIs quase sempre vencem. Se você está inclinado para esse caminho, este guia prático sobre como usar o DeepSeek V4 via API percorre a configuração e os padrões de uso sem tocar na infraestrutura de GPU.

Se você está executando trabalhos contínuos (geração em batch, prompts ajustados, ferramentas internas) e consegue manter as placas ocupadas, a auto-hospedagem cruza o ponto de equilíbrio mais cedo. Não compraria hardware apenas para o V4 a menos que soubesse que o alimentaria com algumas centenas de milhões de tokens por mês por pelo menos um trimestre.