Rodando LLM em NVFP4 na Blackwell: como o novo formato de 4 bits promete 25% mais throughput sem sacrificar precisão

Resumo: O NVIDIA Technical Blog vem publicando ao longo do trimestre uma série de textos sobre NVFP4, o formato de 4 bits em ponto flutuante exclusivo da arquitetura Blackwell. A promessa é agressiva: até 25% mais throughput no processamento de prompts e redução de ~1,8× na memória versus FP8, com perda de acurácia frequentemente abaixo de 1%. Este texto explica o que muda, quando usar, e como colocar em produção com TensorRT-LLM, vLLM e SGLang — inclusive nos primeiros racks Vera Rubin VR200 que já chegam ao Brasil via provedores de nuvem.

Contexto técnico, em bom português

Reduzir a precisão numérica de um LLM (de FP16 para FP8, e agora FP4) é um dos caminhos mais eficientes para servir mais tokens por segundo com menos GPU. O problema histórico do FP4 clássico é a queda de qualidade — o intervalo dinâmico do formato é pequeno demais para representar bem os pesos. O NVFP4 resolve isso com um esquema de escalamento em dois níveis: cada micro-bloco de pesos tem um fator local, e cada tile de micro-blocos tem um fator global; combinados, garantem aproveitamento próximo do FP8 com menos bits armazenados. Em hardware, o suporte é nativo nos Tensor Cores de quinta geração da Blackwell e da Blackwell Ultra, o que dá o ganho real.

Além disso, a NVIDIA lançou o DFlash — um modelo aberto de difusão para decoding especulativo — que combinado com NVFP4 empurra a barra ainda mais: benchmarks divulgados indicam até 15× mais throughput para gpt-oss-120b e até 5,8× para Gemma 4 31B. TensorRT-LLM, vLLM e SGLang têm kernels otimizados para NVFP4 e para a arquitetura dual-die da Blackwell Ultra.

Por que importa — e o status no Brasil

No mercado brasileiro, o custo por milhão de tokens tem sido o principal gatilho de decisão em POCs corporativas. Startups de agentes, integradores e departamentos de dados de bancos e varejo têm balancinho apertado entre “usar Claude/GPT via API” e “hospedar modelo próprio”. A chegada dos primeiros racks Vera Rubin VR200 (em uso por Oracle Cloud e a nova região do Google Cloud no Brasil) torna viável, pela primeira vez, hospedar Qwen 3.6, Llama 4, IBM Granite 4.1 ou Kimi K2 com custo de inferência competitivo. NVFP4 é o que faz essa conta fechar sem sacrificar UX.

Para times de MLOps no Brasil, isso significa três mudanças imediatas: (1) pipelines de fine-tuning precisam gerar checkpoints que podem ser quantizados para NVFP4 sem perda relevante; (2) monitoramento de qualidade precisa ser reforçado, porque a diferença de acurácia é sutil e aparece em cauda; (3) contratos com hyperscalers precisam contemplar SLA por modelo/precisão, não só por hora de GPU.

Passo a passo prático (versão curta)

1. Escolha um modelo compatível. Comece com um checkpoint bem testado — Llama 4 8B, Qwen 3.6 32B ou gpt-oss 20B são bons pontos de partida.
2. Quantize com TensorRT-LLM Model Optimizer. Utilize o preset nvfp4. O comando padrão gera pesos e tabelas de escala em um único artefato.
3. Sirva via TensorRT-LLM ou vLLM 0.10+. No vLLM, defina quantization=nvfp4 e valide com um smoke test em prompts representativos.
4. Compare com FP8. Rode 200 a 500 prompts do seu domínio e compare respostas — atenção a tarefas de matemática e código.
5. Monitore em produção. Configure telemetria de latência p50/p95, taxa de token, e uma avaliação semanal automatizada de qualidade (LLM-as-judge com um modelo maior).

Riscos e limitações

NVFP4 não é bala de prata. Modelos muito pequenos (menos de 2 B) podem sofrer perda perceptível de qualidade — o formato foi calibrado para redes maiores. Cargas com contexto muito longo (>200k tokens) ainda dependem de otimizações de KV cache específicas, e não basta quantizar pesos. Além disso, apenas Blackwell e Blackwell Ultra aceleram NVFP4 em hardware: se você roda em Hopper (H100/H200), o formato até funciona por emulação, mas não entrega o ganho prometido. Recomenda-se sempre validar acurácia no seu domínio (jurídico, saúde, financeiro) antes de virar 100% do tráfego para o modelo quantizado — e, em setores regulados, procure profissionais especializados para revisão de compliance.

Cenário: o que esperar até dezembro

Espere convergência rápida. É provável que Meta, Google, Alibaba e IBM passem a distribuir checkpoints “NVFP4-ready” oficialmente, evitando o retrabalho de quantização em cada empresa. O ecossistema de serving vai se consolidar em torno de TensorRT-LLM, vLLM e SGLang; frameworks menores tendem a ser absorvidos ou virar plugins. E, na frente de hardware, a NVIDIA já sinalizou que a próxima geração pós-Blackwell terá suporte a MXFP4 e a formatos ainda menores em micro-blocos — a curva de compressão de LLM está longe do fim.

Conclusão prática: o que muda e como usar

Se você paga conta de inferência hoje, coloque um piloto de NVFP4 na fila de MLOps ainda em julho. Ganhos de 20% a 40% em throughput representam economia real e melhor UX simultaneamente. Se você constrói produto — copiloto, RAG, agente — o novo ponto de partida deve ser “quantizar por padrão, avaliar exceção”. E para o time de arquitetura corporativa: use este momento para negociar SLA e preços com sua nuvem preferida; a janela de vantagem competitiva do NVFP4 em produção é dos próximos 12 meses.

Fonte original: NVIDIA Technical Blog (referências específicas: Introducing NVFP4 e DFlash speculative decoding).