Realizamos o benchmark do Qwen3-32B em 4 níveis de precisão (BF16, FP8, GPTQ-Int8, GPTQ-Int4) em uma única NVIDIA H100 80GB GPU. Cada configuração foi avaliada em 2 benchmarks (~12,2 mil perguntas) cobrindo conhecimento e geração de código, além de mais de 2.000 execuções de inferência para medir a vazão. O Int4 é 2,7x mais rápido que o BF16 enquanto perde menos de 2 pontos no MMLU-Pro, mas a geração de código (HumanEval) cai 8 pontos.
Resultados do benchmark de quantização
O MMLU-Pro testa raciocínio amplo em 14 domínios (~12 mil perguntas, 5-shot). Esta é a versão mais difícil do MMLU com perguntas de 10 opções em vez de 4.
O HumanEval testa geração de código (164 problemas, pass@1). O modelo escreve funções Python que são executadas contra testes unitários. Este é o único benchmark onde a saída é executada, não apenas pontuada.
A Vazão é tokens de saída por segundo com tamanho de lote 1.
O Tamanho do modelo é a memória GPU consumida apenas pelos pesos, medida após o carregamento.
Detalhamento do MMLU-Pro por categoria
Engenharia e direito mostram as maiores quedas no Int4. Matemática permanece estável em todas as precisões.
Capacidade de memória e concorrência
Ferramentas de monitoramento de GPU como nvidia-smi relatam utilização quase total independentemente do tamanho do modelo porque o vLLM pré-aloca toda a memória disponível. A verdadeira questão é como essa memória é dividida entre pesos do modelo e cache KV, porque o cache KV determina quantos usuários você pode atender simultaneamente.
O número máximo de usuários é o limite limitado por memória antes da OOM: capacidade total de tokens dividida pelo comprimento de contexto por usuário. Este é o máximo teórico. Na prática, a sobrecarga de agendamento reduz ligeiramente.
Isso tem implicações diretas para modelos de raciocínio. DeepSeek-R1 e Qwen-QwQ geram milhares de tokens internos de "pensamento" (frequentemente 2K-5K) antes de produzir uma resposta final. No BF16, uma única solicitação de raciocínio poderia consumir toda a capacidade de 17K tokens, bloqueando um segundo usuário. No Int4, a capacidade de 193K cabe múltiplas sessões de raciocínio concorrentes.
Principais descobertas
FP8 não perde precisão mensurável
O FP8 pontua 69,64% no MMLU-Pro vs 70,24% para o BF16, uma diferença de 0,6 ponto em 12.000 perguntas. No HumanEval, tanto FP8 quanto BF16 pontuam identicamente em 39,02%. O FP8 oferece 1,5x de vazão e corta o tamanho do modelo pela metade por um custo de 0,6 ponto.
O GPTQ-Int8 pontua 70,32% no MMLU-Pro mas cai 1,8 pontos no HumanEval (37,20%). Se a geração de código importa, o FP8 é a escolha mais segura.
O Int4 degrada mais a geração de código do que o conhecimento
O MMLU-Pro cai 1,6 pontos no Int4 (70,24% para 68,66%). O HumanEval cai 8 pontos (39,02% para 31,10%). A geração de código requer previsões precisas de tokens onde pequenos erros de peso se acumulam através dos corpos de função.
A verdadeira vitória é a concorrência, não a velocidade
O Int4 é 2,7x mais rápido que o BF16. Mas o efeito maior está na memória. O BF16 deixa apenas 4,4 GB para o cache KV, suficiente para cerca de 4 usuários concorrentes com contexto de 4K. O Int4 libera 47,3 GB, suficiente para 47 usuários, um aumento de 12x na capacidade de atendimento da mesma GPU.
Pontuações de matemática mantêm-se em todas as precisões
Pontuações de matemática mal se movem: 81,87% no BF16, 81,87% no FP8, 81,87% no Int8, 80,24% no Int4. Engenharia (49,64% para 43,45%) e direito (43,05% para 40,60%) são mais sensíveis.
Custo por token
Usando preços SXM H100 no RunPod ($2,69/hora) com tamanho de lote 1:
Esses números refletem geração em tempo real para um único usuário. O processamento em lote reduz ainda mais o custo.
Adicionar como fonte preferencialLLM metodologia de benchmark de quantização
Ambiente
- GPU: Única NVIDIA H100 80GB HBM3 (SXM) via RunPod ($2,69/hr)
- Software: vLLM 0.17.0, lm-evaluation-harness 0.4.11, PyTorch 2.8.0, CUDA 12.8, Python 3.11
- Modelo: Qwen3-32B (pós-treinado/ajustado por instrução) do HuggingFace. Nenhum fine-tuning aplicado.
Avaliação de precisão
- Todas as avaliações são executadas via
lm-evaluation-harnesscombatch_size="auto". - Cada tarefa é executada em um subprocesso separado. Modelo carregado fresco a cada vez, GPU totalmente limpa entre tarefas. Isso previne OOM por fragmentação de memória.
- HumanEval é executado com
HF_ALLOW_CODE_EVAL=1(execução de código habilitada). - Resultados do MMLU-Pro incluem detalhamento por categoria (biologia, matemática, física, direito, etc.).
- O modo de pensamento do Qwen3 não estava ativo durante as avaliações. lm-evaluation-harness envia prompts formatados brutos sem aplicar o template de chat do modelo (
apply_chat_template=Falsepor padrão), então o token<think>nunca é injetado.
Avaliação de desempenho
- 5 prompts rotativos em domínios (ciência, codificação, conhecimento geral)
- 10 iterações de aquecimento (não medidas), depois 500 iterações medidas
- Saída fixa:
max_tokens=256, temperature=0.7, top_p=0.9, batch_size=1 - Métricas: vazão (tokens/sec), uso de memória GPU (GB)
Configuração vLLM por precisão
Todas as precisões usam gpu_memory_utilization=0.90, max_model_len=4096.
Arquitetura de processo dividido
Cada benchmark é executado como dois processos separados para prevenir OOM:
- Passo 1: Carregar modelo, aquecer, benchmarkar vazão, salvar em arquivo temporário, sair.
- Limpeza: Forçar término de processos vLLM e Ray, aguardar 10 segundos.
- Passo 2: Carregar modelo fresco, executar cada tarefa de avaliação em um subprocesso separado, mesclar com métricas do passo 1, salvar JSON final.
Variáveis controladas
Para eliminar fatores externos, os seguintes parâmetros foram fixos em todas as execuções:
Prompts de teste
Os 5 prompts de teste:
- "Explique a teoria da relatividade em termos simples." (Ciência/Abstrato)
- "Escreva uma função Python para encontrar a substring palíndroma mais longa." (Codificação)
- "Quais são as principais causas das mudanças climáticas e seus efeitos?" (Raciocínio Complexo)
- "Descreva o processo de fotossíntese passo a passo." (Descrição de Processo)
- "Como uma rede neural aprende com dados?" (Explicação Técnica)
Verificação de dados: telemetria de tempo de execução vLLM
As figuras de memória e concorrência neste artigo foram derivadas diretamente dos logs de inicialização do motor vLLM durante a execução do benchmark.
Inicialização BF16:
Inicialização GPTQ-Int4:
Limitações
Todos os testes usam tamanho de lote 1. Em cenários de alta vazão, a lacuna de desempenho entre Int4 e BF16 aumenta porque a saturação de largura de banda de memória se torna o gargalo dominante.
Os resultados são específicos para o H100 SXM. GPUs mais antigas (A100, A10) não possuem suporte nativo a FP8. GPUs de consumidor (RTX 4090) têm características de largura de banda de memória diferentes.
Os modelos GPTQ (JunHowie) são quantizações fornecidas pela comunidade. Lançamentos oficiais podem usar conjuntos de dados de calibração ou parâmetros diferentes, o que pode afetar a precisão.
Testamos apenas GPTQ. Outros métodos de quantização (AWQ, BitsAndBytes NF4, GGUF, HQQ) podem oferecer trade-offs diferentes.
Conclusão
Para Qwen3-32B em uma H100, o FP8 é a escolha padrão. Você obtém 1,5x a vazão, metade da pegada de memória e um custo de precisão de 0,6 ponto.
O Int4 faz sentido quando você precisa de vazão máxima ou concorrência: 2,7x de velocidade, 12x de concorrência, ao custo de 1,6 pontos no MMLU-Pro e 8 pontos no HumanEval.
O Int8 fica no meio e não oferece uma vantagem clara sobre o FP8 nesta configuração. O ganho de vazão sobre o FP8 é pequeno (43,3 vs 37,9 tok/s) e a precisão é comparável. O FP8 é mais simples porque é oficialmente fornecido pelos autores do modelo e não requer um checkpoint quantizado de terceiros.
O maior impacto prático da quantização não é a velocidade, é a concorrência. O BF16 pode atender 4 usuários com contexto de 4K em uma única H100. O Int4 pode atender 47. A $2,69/hr, isso traz o custo por 1 milhão de tokens de $28,73 para $10,69.
Cite esta pesquisa
Escolha o formato adequado ao local onde você vai publicar. Colar a versão com link no seu CMS preserva o backlink.
@misc{sar2026,
author = {Sarı, Ekrem and Ermut, Sıla},
title = {{LLM Quantização: BF16 vs FP8 vs INT4}},
year = {2026},
month = mar,
howpublished = {\url{https://aimultiple.com/llm-quantization}},
note = {AIMultiple. Acessado em 17 Março 2026}
}
Seja o primeiro a comentar
Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios. Os comentários são deixados em seu idioma original.