Realizamos testes de desempenho com o algoritmo Qwen3-32B em 4 níveis de precisão (BF16, FP8, GPTQ-Int8, GPTQ-Int4) em uma única GPU NVIDIA H100 de 80 GB. Cada configuração foi avaliada em 2 benchmarks (~12.200 questões) abrangendo geração de conhecimento e código, além de mais de 2.000 execuções de inferência para medir o desempenho. O índice Int4 é 2,7 vezes mais rápido que o BF16, com uma perda de menos de 2 pontos no MMLU-Pro, mas a geração de código (HumanEval) apresenta uma queda de 8 pontos.
Resultados do teste de quantização
O MMLU-Pro testa o raciocínio abrangente em 14 domínios (aproximadamente 12 mil questões, com 5 tentativas). Esta é a versão mais difícil do MMLU, com questões de 10 alternativas em vez de 4.
O HumanEval testa a geração de código (164 problemas, aprovado com 1 ponto). O modelo escreve funções em Python que são executadas em testes unitários. Este é o único benchmark em que a saída é executada, e não apenas pontuada.
A taxa de transferência é a quantidade de tokens de saída por segundo com um tamanho de lote de 1.
O tamanho do modelo é a memória da GPU consumida apenas pelos pesos, medida após o carregamento.
Análise do MMLU-Pro por categoria
Engenharia e direito apresentam as maiores quedas na precisão Int4. Matemática permanece estável em todas as precisões.
Capacidade de memória e concorrência
Ferramentas de monitoramento de GPU, como o nvidia-smi, reportam 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 os pesos do modelo e o cache KV, já que o cache KV determina quantos usuários podem ser atendidos simultaneamente.
O número máximo de usuários é o limite de memória antes da falta de memória (OOM): capacidade total de tokens dividida pelo comprimento do contexto por usuário. Este é o máximo teórico. Na prática, a sobrecarga de agendamento o reduz ligeiramente.
Isso tem implicações diretas para os modelos de raciocínio. DeepSeek-R1 e Qwen-QwQ geram milhares de tokens internos de "pensamento" (frequentemente de 2K a 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 comporta múltiplas sessões de raciocínio simultâneas.
Principais conclusões
O FP8 não apresenta perda mensurável de precisão.
O FP8 obteve 69,64% no MMLU-Pro contra 70,24% do BF16, uma diferença de 0,6 ponto percentual em 12.000 questões. No HumanEval, ambos os modelos, FP8 e BF16, obtiveram o mesmo resultado, com 39,02%. O FP8 proporciona um aumento de 1,5 vezes na produtividade e reduz o tamanho do modelo pela metade, com um custo de apenas 0,6 ponto percentual.
O GPTQ-Int8 obteve 70,32% no MMLU-Pro, mas perdeu 1,8 pontos no HumanEval (37,20%). Se a geração de código for importante, o FP8 é a escolha mais segura.
O Int4 degrada a geração de código mais do que o conhecimento.
O MMLU-Pro perde 1,6 pontos no Int4 (de 70,24% para 68,66%). O HumanEval perde 8 pontos (de 39,02% para 31,10%). A geração de código exige previsões precisas de tokens, onde pequenos erros de ponderação se acumulam ao longo dos corpos das funções.
A verdadeira vantagem está na simultaneidade, não na velocidade.
O Int4 é 2,7 vezes mais rápido que o BF16. Mas o maior impacto é na memória. O BF16 deixa apenas 4,4 GB para o cache KV, o suficiente para cerca de 4 usuários simultâneos em um contexto de 4K. O Int4 libera 47,3 GB, o suficiente para 47 usuários, um aumento de 12 vezes na capacidade de atendimento da mesma GPU.
Os resultados em matemática são mantidos em todas as precisões.
As notas em matemática praticamente não mudaram: 81,87% no BF16, 81,87% no FP8, 81,87% no Int8 e 80,24% no Int4. Engenharia (de 49,64% para 43,45%) e direito (de 43,05% para 40,60%) são mais sensíveis.
Custo por ficha
Utilizando o preço H100 SXM no RunPod (US$ 2,69/hora) com tamanho de lote 1:
Esses números refletem a geração em tempo real para um único usuário. O processamento em lote reduz ainda mais o custo.
Metodologia de benchmark de quantização LLM
Ambiente
- GPU: Única NVIDIA H100 80GB HBM3 (SXM) via RunPod (US$ 2,69/hora)
- 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ções) da HuggingFace. Nenhum ajuste fino 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 . O modelo é carregado do zero a cada vez e a GPU é completamente limpa entre as tarefas. Isso evita erros de falta de memória (OOM) causados pela fragmentação da memória.
- O HumanEval é executado com
HF_ALLOW_CODE_EVAL=1(execução de código habilitada). - Os resultados do MMLU-Pro incluem a análise por categoria (biologia, matemática, física, direito, etc.).
- O modo de raciocínio de Qwen3 não estava ativo durante as avaliações. O lm-evaluation-harness envia prompts formatados brutos sem aplicar o modelo de chat (
apply_chat_template=Falsepor padrão), portanto o token<think>nunca é injetado.
Avaliação de desempenho
- 5 perguntas rotativas em diferentes áreas (ciência, programação, conhecimentos gerais)
- 10 iterações de aquecimento (não medidas), seguidas de 500 iterações medidas.
- Saída fixa:
max_tokens=256, temperature=0.7, top_p=0.9, batch_size=1 - Métricas: taxa de transferência (tokens/seg), uso de memória da 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 evitar falta de memória (OOM):
- Etapa 1: Carregar o modelo, aquecer, medir a taxa de transferência, salvar em um arquivo temporário e sair.
- Limpeza: Force o encerramento dos processos vLLM e Ray e aguarde 10 segundos.
- Etapa 2: Carregue o modelo novamente, execute cada tarefa de avaliação em um subprocesso separado, combine com as métricas da etapa 1 e salve o JSON final.
Variáveis controladas
Para eliminar fatores externos, os seguintes parâmetros foram fixados em todas as execuções:
Instruções para o teste
Os 5 tópicos do teste:
- Explique a teoria da relatividade em termos simples. (Ciência/Resumo)
- Escreva uma função em Python para encontrar a substring palindrômica mais longa. (Programaçã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 do Processo)
- “Como uma rede neural aprende com os dados?” (Explicação técnica)
Verificação de dados: telemetria de tempo de execução do vLLM
Os dados de memória e concorrência apresentados neste artigo foram obtidos diretamente dos registros de inicialização do mecanismo vLLM durante a execução do benchmark.
Inicialização do BF16:
Inicialização do GPTQ-Int4:
Limitações
Todos os testes usam tamanho de lote 1. Em cenários de alto rendimento , a diferença de desempenho entre Int4 e BF16 aumenta porque a saturação da largura de banda da memória se torna o principal gargalo.
Os resultados são específicos para a H100 SXM. GPUs mais antigas (A100, A10) não possuem suporte nativo a FP8. GPUs para consumidores (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. Versões oficiais podem usar conjuntos de dados ou parâmetros de calibração diferentes, o que pode afetar a precisão.
Testamos apenas o GPTQ. Outros métodos de quantização (AWQ, BitsAndBytes NF4, GGUF, HQQ) podem apresentar vantagens e desvantagens diferentes.
Conclusão
Para Qwen3-32B em um H100, FP8 é a escolha padrão. Você obtém 1,5 vezes mais taxa de transferência, metade da ocupação de memória e um custo de precisão de 0,6 ponto.
A função Int4 faz sentido quando você precisa de taxa de transferência ou concorrência máxima: velocidade 2,7 vezes maior, concorrência 12 vezes maior, ao custo de 1,6 pontos no MMLU-Pro e 8 pontos no HumanEval.
O Int8 fica em uma posição intermediária e não oferece uma vantagem clara sobre o FP8 nesta configuração. O ganho de desempenho em relação ao FP8 é pequeno (43,3 vs 37,9 tok/s) e a precisão é comparável. O FP8 é mais simples porque é fornecido oficialmente pelos autores do modelo e não requer um ponto de verificação quantizado de terceiros.
O maior impacto prático da quantização não é a velocidade, mas sim a concorrência. O BF16 pode atender 4 usuários com 4K de contexto em um único H100. O Int4 pode atender 47. A US$ 2,69/hora, isso reduz o custo por 1 milhão de tokens de US$ 28,73 para US$ 10,69.
A seguir, leia
Análise comparativa dos 13 melhores programas de mestrado em Direito (LLM) da Agentic: comparação entre os 13 melhores.
Mecanismos de inferência LLM: vLLM vs LMDeploy vs SGLang
O panorama da avaliação do LLM com suas respectivas estruturas
Seja o primeiro a comentar
Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios.