NVIDIA leva NVFP4 ao DeepSeek V4.1-Flash: custo por GPU

A NVIDIA publicou em 30 de outubro de 2026 uma variante NVFP4 do DeepSeek-V4.1-Flash-1017, MoE com 552 bilhões de parâmetros no backbone e contexto de até 1 milhão de tokens. O card compara checkpoints de aproximadamente 400 e 475 GiB. No GPQA Diamond, o cálculo editorial aponta +0,16 ponto percentual. Menos armazenamento não garante economia em GPU.

O checkpoint é o conjunto de dados que registra os pesos e outros componentes do modelo. A diferença entre os tamanhos equivale a aproximadamente 16% do checkpoint de origem. O card publica os dois totais e não decompõe essa diferença nem a atribui à conversão dos especialistas. Capacidade liberada só tem valor operacional quando há carga compatível e espaço dentro do limite de latência. No GPQA Diamond, o card informa 92,77% para a origem e 92,93% para a variante; a diferença é um cálculo editorial, sem conclusão de significância estatística.

Antes de alterar uma rota de produção, a operação precisa medir a qualidade das respostas e o custo de manter a engine compatível.

O que a NVIDIA publicou sobre NVFP4 em 30 de outubro?

A NVIDIA publicou uma versão quantizada do DeepSeek-V4.1-Flash-1017 que usa NVFP4, um formato numérico de baixa precisão, nos especialistas roteados, e a preparou com o Model Optimizer da NVIDIA. A conversão não foi uniforme: o card descreve caminhos de conversão diferentes para componentes diferentes.

O card usa a palavra quantização para duas operações distintas. As tabelas Engram perderam largura em bits, de FP8 para MXFP4. Os especialistas trocaram um formato de 4 bits por outro de 4 bits com escala mais fina, de MXFP4 para NVFP4. Só a primeira remove bits.

Na mistura de especialistas, ou MoE, a execução seleciona especialistas, mas os demais pesos continuam no checkpoint. Segundo o card, os 384 especialistas roteados por camada nas 40 camadas passaram de MXFP4 para NVFP4, com pesos e ativações W4A4 e grupos de quantização de 16 valores.

As tabelas Engram passaram de FP8 para MXFP4; outros componentes mantiveram a precisão de origem. Segundo o card, os pesos dos especialistas preservaram valores desquantizados, com canonicalização do zero com sinal. A conversão Engram teve perda; a preservação dos pesos não garante respostas idênticas.

A autoria também tem fronteiras claras. O model card de origem é da DeepSeek AI, e a NVIDIA afirma que não desenvolveu nem detém o modelo. A NVIDIA publicou a variante quantizada, construída para requisitos de um terceiro, e declara licença MIT e uso comercial e não comercial.

Quanto espaço o checkpoint ocupa e por que isso afeta o custo por GPU?

Consultado em 2 de novembro de 2026, o card da NVIDIA compara cerca de 400 GiB no checkpoint quantizado com 475 GiB na origem. A diferença de aproximadamente 75 GiB equivale a cerca de 16% do tamanho de origem e pode reduzir despesas se a implantação usar menos hardware pago. O tamanho em disco não prova economia.

O card publica os dois totais e não publica a decomposição dos 75 GiB. A conta que fizemos mostra por que a conversão dos especialistas não pode explicar essa diferença: MXFP4 e NVFP4 são formatos de 4 bits com o mesmo elemento E2M1, e o NVFP4 usa escala FP8 E4M3 a cada 16 elementos, contra escala E8M0 a cada 32 no MXFP4. Essa escala mais frequente custa 4,5 bits por elemento no NVFP4 contra 4,25 no MXFP4, ou cerca de 6% mais por elemento (4,5 dividido por 4,25), e não menos. Aplicada aos 552 bilhões de parâmetros do backbone, a mesma conta dá cerca de 293 GB em MXFP4 contra cerca de 310 GB em NVFP4, ou seja aproximadamente 17 GB a mais nos especialistas, e nunca 75 GiB a menos. Esses volumes estão em GB decimais; os tamanhos de checkpoint publicados no card estão em GiB.

A única conversão que remove bits é a das tabelas Engram, de FP8 para MXFP4, e é também a que o card declara com perda. Essa é a explicação plausível para a redução publicada.

O total de parâmetros explica o tamanho do arquivo. O card declara 552 bilhões de parâmetros no backbone, 8 bilhões ativados no prefill, 16 bilhões no decode e 196 bilhões em memória condicional Engram. O tráfego de pesos por token segue os especialistas roteados ativados; a memória residente segue o total mais o cache. Por isso 552 bilhões de parâmetros a 4,5 bits por elemento ocupam cerca de 289 GiB, e os 196 bilhões da Engram em MXFP4 somam cerca de 97 GiB, valores coerentes com os aproximadamente 400 GiB publicados. Na média do arquivo, isso dá cerca de 0,78 byte por parâmetro do backbone, na nossa conta.

A comparação separa tamanho de checkpoint de preço por token: os cards consultados não publicam custo por milhão de tokens, e o tamanho não determina o hardware necessário.

A tabela reúne os formatos e tamanhos declarados nos cards, além da janela de contexto do modelo de origem; ela não informa consumo em execução nem preço contratado.

Outra medida é a memória de GPU em execução. Além dos componentes do modelo carregados no dispositivo, a engine reserva espaço para cache, buffers e estruturas necessárias às requisições; distribuição dos pesos, cópias e deslocamento para a CPU alteram a conta. Por isso, dividir o tamanho do checkpoint pela memória nominal de uma GPU não determina uma configuração de produção.

Para a despesa, o limite de capacidade importa. Quando a implantação medida consegue usar menos hardware reservado, há uma possibilidade de redução de custo; quando mantém o mesmo conjunto de GPUs, o espaço liberado pode servir outras cargas ou aumentar a concorrência, desde que a configuração suporte o uso e a latência exigida. Se não houver uso para essa capacidade, a redução em disco não se converte necessariamente em economia.

Mesmo quando a carga não aproveita toda a memória disponível, o hardware reservado compõe a despesa. A comparação precisa incluir o tempo de processamento e as tarefas concluídas com qualidade; o card não quantifica economia para uma operação específica.

A acurácia se manteve nos benchmarks?

Os números do card da NVIDIA foram reportados pelo publicador em seis avaliações e não demonstram equivalência estatística, pois faltam margens de erro para determinar a relevância das diferenças. Os resultados dos checkpoints de origem e quantizado são próximos, mas não foram apresentados como medição independente.

Fonte: model card da NVIDIA, consultado em 2 de novembro de 2026. Resultados sobem ou caem. Os testes cobrem ciência, contexto longo, código, instruções, visão e tarefas de terminal, sem substituir a validação da aplicação.

A metodologia varia. O card informa quantidades distintas de repetições e configuração separada para o Terminal-Bench 2.1; não há suporte para atribuir a mesma variabilidade aos testes.

O card também informa que 24 de 46.080 entradas de projeção usaram escalas de ativação de fallback. A conversão precisou de escala de fallback em entradas de projeção reais, e são exatamente essas entradas que impedem tratar o resultado como cópia fiel da origem.

A equipe precisa testar as duas variantes em tarefas representativas. Os critérios de aceitação precisam ser iguais. Correções humanas ou novas chamadas alteram o custo por tarefa; o publicador não mede esse efeito.

Qual é o custo operacional do build corrigido do vLLM?

O card indica um build do vLLM com as alterações do pull request de suporte para carregar as tabelas Engram em MXFP4. A operação precisa testar o build, acompanhar atualizações e planejar correções de segurança. O publicador não quantifica esse trabalho, e o requisito documentado não antecipa o suporte de versões futuras.

Manter esse build requer trabalho. Os resultados reportados usam a imagem vllm/vllm-openai:v0.31.0 com o pull request aplicado, e o checkpoint vem em 48 shards; o pull request estava aberto e não mesclado em 2 de novembro de 2026. A equipe precisa obter ou construir uma imagem compatível, registrar dependências, testar atualizações e definir como receber correções de segurança; também precisa de uma rota de retorno se uma atualização impedir a inicialização do checkpoint ou mudar o comportamento da aplicação. O card não atribui um valor financeiro a essas atividades.

A referência publicada usa quatro GPUs NVIDIA GB300 Blackwell, vLLM com atenção esparsa MLA do FlashInfer e deslocamento das tabelas Engram para a CPU. Essa é a configuração dos resultados reportados, não uma recomendação universal de capacidade. Ela tampouco permite atribuir todo o tamanho do checkpoint à memória das GPUs.

O card declara compatibilidade de microarquitetura com NVIDIA Blackwell e não declara suporte a nenhuma outra. Fora dela, a comparação não se aplica sem troca de hardware; o card não descreve comportamento em outras arquiteturas, e esta matéria não infere nenhum.

O SGLang, outra engine citada no card, não foi validado com o checkpoint. Isso não prova incompatibilidade, mas exige que o operador verifique carregamento, resposta sob carga e recuperação de falhas antes de assumir suporte.

O que muda no roteamento de inferência?

Um checkpoint menor só muda o custo para o comprador se a implantação ou as condições do serviço converterem essa redução em uma vantagem mensurável. Para o operador das GPUs, a comparação inclui recursos reservados, uso efetivo e manutenção. Para quem contrata inferência, ela depende da cobrança e das chamadas necessárias para concluir a tarefa.

A restrição de hardware vem antes da conta de memória. O card declara suporte apenas a NVIDIA Blackwell, então uma frota de geração anterior, como Hopper ou Ada, só aproveita esta variante depois de decidir sobre renovação de hardware, não de trocar o checkpoint.

O repasse não é automático.

Uma rota com custo menor por chamada pode exigir mais tentativas ou correções para entregar o mesmo resultado. Nesse caso, o custo por tarefa aceita pode subir, apesar do tamanho menor do checkpoint. Se a qualidade se mantiver e a operação aproveitar capacidade liberada, a equipe tem um motivo para reavaliar a distribuição do tráfego, respeitando os limites de latência.

A comparação de produção exige registros para as duas variantes:

1. Medir memória de GPU e CPU, tempo de execução e utilização sob a mesma carga.
2. Avaliar respostas com os mesmos critérios e registrar falhas, repetições e correções necessárias.
3. Dividir o custo de servir ou contratar as chamadas pelo número de tarefas aceitas, incluindo a manutenção do build quando a operação controla a engine.

Leitura complementar: lançamento do DeepSeek-V4.1-Flash-1017; DeepInfer. A comparação é o custo de recursos por tarefa aceita.

A comparação entre rotas exige custo por tarefa aceita, qualidade e latência medidos sob a mesma carga. A disponibilidade desta variante e seu preço devem ser confirmados com o provedor. Nenhuma economia para o cliente está demonstrada.

Perguntas frequentes

O que é NVFP4?

NVFP4 é um formato numérico de baixa precisão usado nos pesos e ativações dos especialistas roteados da variante publicada pela NVIDIA. A conversão não abrangeu todos os componentes do modelo; o card descreve formatos diferentes para as tabelas Engram e os demais componentes.

Os 400 GiB são a memória necessária para rodar o modelo?

Não. Os aproximadamente 400 GiB correspondem ao tamanho do checkpoint declarado no card da NVIDIA, consultado em 2 de novembro de 2026. A memória em execução inclui outras reservas, como cache e buffers, e depende da distribuição dos componentes entre GPU e CPU.

A redução de 16% garante economia na mesma proporção?

Não. Os cerca de 16% derivam dos tamanhos aproximados de 400 GiB contra 475 GiB para os checkpoints, não de uma medição de custo. Hardware reservado, utilização, cobrança, qualidade das tarefas e manutenção do build influenciam o resultado financeiro em produção.

A variante funciona com qualquer instalação do vLLM?

O card diz que imagens padrão do vLLM não carregam as tabelas Engram em MXFP4 desse checkpoint e indica um build com suporte específico. A equipe deve validar a instalação escolhida; essa declaração não permite antecipar o suporte de versões futuras.

Como confirmar a disponibilidade e o preço da variante?

A disponibilidade e o preço desta variante devem ser confirmados com o provedor. Antes de incluí-la em uma política de roteamento, o comprador precisa verificar se existe uma rota disponível, quais são as condições comerciais correspondentes e o custo por tarefa aceita.

Referências e Leitura Complementar

O repositório do NVIDIA Model Optimizer documenta a ferramenta usada na quantização. Os cards vinculados no início da matéria descrevem, respectivamente, a variante publicada pela NVIDIA e o modelo de origem da DeepSeek AI; a consulta para esta matéria ocorreu em 2 de novembro de 2026.

Os cards não substituem testes próprios. A configuração e o requisito de build devem ser avaliados sob a carga e os critérios de aceitação da aplicação.

Onde a economia em GPU encontra o custo de CPU?

Na configuração de referência descrita no card da NVIDIA, as tabelas Engram são deslocadas para a CPU. A fatura não termina na GPU. Assim, para quem paga pela capacidade de GPU, uma redução nessa despesa pode ser compensada pelo custo da capacidade de CPU necessária à inferência, conforme a contratação e a carga.

Se a redução de 16% vem da conversão Engram, ela se realiza em memória de host e em disco. O card demonstra um checkpoint menor; não demonstra uma conta de HBM menor. E a conta que sobra começa na arquitetura: segundo o card, sem Blackwell esse checkpoint não entra.