Phase 17 - Lesson 09
Quantização em Produção — AWQ, GPTQ, GGUF K-quants, FP8, MXFP4/NVFP4
O formato de quantização não é uma escolha universal — ele depende do hardware, do mecanismo de serviço e da carga de trabalho. O GGUF Q4_K_M ou Q5_K_M domina CPU e borda (edge), disponibilizado através do llama.cpp e do Ollama. O GPTQ vence dentro do vLLM quando você precisa de múltiplos LoRAs na mesma base. O AWQ com kernels Marlin-AWQ oferece ~741 tok/s em um modelo de classe 7B com o melhor Pass@1 em INT4 — o padrão em 2026 para produção em datacenters. O FP8 permanece como o meio-termo estável em Hopper, Ada e Blackwell — quase sem perdas e amplamente suportado. O NVFP4 e o MXFP4 (microescalonamento do Blackwell) são agressivos e requerem validação por bloco. Duas armadilhas costumam prejudicar as equipes: o dataset de calibração precisa corresponder ao domínio de implantação, e o KV cache é tratado separadamente da quantização de pesos — a clássica lição do AWQ "meu modelo agora tem 4 GB" esquece o KV cache de 10-30 GB exigido por tamanhos de lote de produção.
Tipo: Learn Idiomas: Python (stdlib, comparação simples de pegada de memória e vazão entre formatos) Pré-requisitos: Phase 10 · 13 (Quantization foundations), Phase 17 · 04 (vLLM Serving Internals) Tempo: ~75 minutos
Objetivos de Aprendizado
- Nomear os seis formatos de quantização em produção e seus cenários ideais em 2026.
- Escolher um formato dado o hardware (CPU vs GPU, Hopper vs Blackwell), mecanismo (vLLM, TRT-LLM, llama.cpp) e carga de trabalho (chat rotineiro, raciocínio, multi-LoRA).
- Calcular a memória de peso salva e o KV cache mantido intacto para o formato escolhido.
- Nomear a armadilha do dataset de calibração que degrada modelos quantizados em tráfego de domínio específico.
O Problema
A quantização reduz o uso de memória e a largura de banda de HBM, que é exatamente o que a etapa de decodificação precisa. Um modelo 70B em FP16 consome 140 GB de pesos. Quantize os pesos para INT4 (AWQ ou GPTQ) e o modelo cai para 35 GB — cabendo em uma única GPU H100 com espaço sobrando para o KV cache. Isso é crucial porque, com 128 sequências concorrentes e contexto de 2k, só o KV cache consome de 20 a 30 GB.
Mas a quantização não vem de graça. A quantização agressiva degrada a qualidade do modelo, especialmente em tarefas que envolvem raciocínio complexo. Diferentes formatos operam com diferentes engines. Hardwares distintos suportam nativamente precisões diferentes. A diversidade de formatos em 2026 é real e você não pode apenas copiar a escolha de terceiros — você precisa selecionar com base na sua stack.
O Conceito
Os seis formatos
| Formato | Bits | Cenário ideal | Mecanismos |
|---|---|---|---|
| GGUF Q4_K_M / Q5_K_M | 4-5 | CPU, borda (edge), laptops | llama.cpp, Ollama |
| GPTQ | 4-8 | Multi-LoRA no vLLM | vLLM, TGI |
| AWQ | 4 | Produção de GPU em datacenters | vLLM (Marlin-AWQ), TGI |
| FP8 | 8 | Datacenters Hopper/Ada/Blackwell | vLLM, TRT-LLM, SGLang |
| MXFP4 | 4 | Blackwell multiusuário | TRT-LLM |
| NVFP4 | 4 | Blackwell multiusuário | TRT-LLM |
GGUF — o padrão para CPU e borda (edge)
O GGUF é um formato de arquivo, não um esquema de quantização em si — ele reúne variantes K-quant (Q2_K, Q3_K_M, Q4_K_M, Q5_K_M, Q6_K, Q8_0) em um único contêiner. O Q4_K_M e o Q5_K_M são os padrões de produção — oferecendo qualidade próxima à BF16 com 4 a 5 bits. É a melhor escolha para serviço em CPU ou na borda porque o llama.cpp é, de longe, o motor de inferência em CPU mais rápido.
Penalidade de throughput no vLLM: ~93 tok/s em modelos 7B — o formato não é otimizado para kernels de GPU. Use GGUF somente quando o alvo de implantação for CPU/borda. Caso contrário, evite.
GPTQ — multi-LoRA no vLLM
GPTQ é um algoritmo de quantização pós-treinamento com uma etapa de calibração. Os kernels Marlin tornam o GPTQ rápido em GPUs (aceleração de 2.6x vs GPTQ sem Marlin). Oferece ~712 tok/s em modelos 7B.
A vantagem única: o GPTQ-Int4 suporta adaptadores LoRA no vLLM. Se você está servindo um modelo base acompanhado de 10 a 50 variantes ajustadas (cada uma como LoRA), o GPTQ é o seu caminho ideal. O NVFP4 ainda não suporta LoRA no início de 2026.
AWQ — o padrão para GPU em datacenters
Quantização de pesos ciente de ativação (Activation-aware Weight Quantization). Protege cerca de 1% dos pesos mais importantes durante a quantização. Kernels Marlin-AWQ: aceleração de 10.9x vs implementação simples. ~741 tok/s em modelos 7B, com o melhor resultado no Pass@1 entre os formatos INT4.
Escolha AWQ para novos serviços de GPU, a menos que você precise de multi-LoRA (GPTQ) ou o agressivo Blackwell FP4 (NVFP4).
FP8 — o meio-termo confiável
Ponto flutuante de 8 bits. Praticamente sem perdas de qualidade. Amplamente suportado. Os Tensor Cores do Hopper aceleram FP8 nativamente, benefício herdado pelo Blackwell. O FP8 é o padrão seguro em 2026 quando a qualidade é inegociável (modelos de raciocínio, área médica, geração de código). A economia de memória é metade da do INT4, mas o risco à qualidade é muito menor.
MXFP4 / NVFP4 — agressivo do Blackwell
FP4 com microescalonamento. Cada bloco de pesos tem seu próprio fator de escala. É agressivo, mas acelerado por hardware nos Tensor Cores do Blackwell. Corta pela metade os bytes por token comparado ao FP8 — o ganho econômico detalhado na Phase 17 · 07.
Limitações:
- Sem suporte a LoRA ainda (início de 2026).
- Queda de qualidade visível em cargas de trabalho com raciocínio complexo.
- Exige validação em seu próprio conjunto de avaliação por modelo.
A armadilha da calibração
O AWQ e o GPTQ exigem um dataset de calibração — tipicamente C4 ou WikiText. Para modelos voltados a domínios específicos (código, medicina, jurídico), calibrar em textos genéricos da web faz com que o algoritmo tome decisões erradas sobre quais pesos proteger. O Pass@1 no HumanEval pode cair vários pontos.
A correção: calibre em dados específicos do seu domínio. Algumas centenas de amostras do domínio geralmente bastam. Teste no conjunto de avaliação antes de colocar em produção.
A armadilha do KV cache
O AWQ encolhe os pesos para 4 bits. O KV cache é tratado à parte e permanece em FP16/FP8. Para um modelo 70B com AWQ:
- Pesos: ~35 GB (INT4 reduzido de 140 GB).
- KV cache com 128 sequências concorrentes × contexto de 2k: ~20 GB.
- Ativações: ~5 GB.
- Total: ~60 GB — cabe em uma GPU H100 de 80GB.
Presumir ingenuamente que "quantizei meu modelo para 4 GB" ignora os outros 30-50 GB adicionais. Projete a necessidade de HBM de forma holística.
Além disso, a quantização do KV cache (FP8 KV ou INT8 KV) é outra escolha com seus próprios trade-offs — ela afeta a precisão da atenção diretamente e não é uma vantagem gratuita.
O AWQ INT4 é arriscado para raciocínio
Chain-of-thought, matemática e geração de código com contextos longos sofrem perda visível sob quantização agressiva. O AWQ INT4 perde cerca de 3 a 5 pontos em MATH. Para cargas com foco em raciocínio, use FP8 ou BF16; aceite o custo de memória.
Guia de seleção para 2026
- Serviço em CPU/borda: GGUF Q4_K_M. Resolvido.
- Serviço em GPU, chat rotineiro, sem LoRA: AWQ.
- Serviço em GPU, multi-LoRA: GPTQ com Marlin.
- Carga de trabalho de raciocínio: FP8.
- Datacenter Blackwell, qualidade validada: NVFP4 + FP8 KV.
- Casos ambíguos: execute uma avaliação com 1.000 amostras em cada formato candidato.
Use-o
O code/main.py calcula a pegada de memória (pesos + KV + ativações) e o throughput relativo entre as seis opções de formato para uma variedade de tamanhos de modelo. Ele exibe onde o KV cache domina, onde a compressão de pesos compensa e quando o FP8 é a escolha ideal e segura.
Entregue-o
Esta lição produz outputs/skill-quantization-picker.md. Dados o hardware, tamanho do modelo, tipo de carga de trabalho e tolerância a perdas de qualidade, seleciona o melhor formato e propõe um plano de calibração/validação.
Exercícios
- Execute
code/main.py. Para um modelo 70B com 128 sequências concorrentes e contexto de 2k, calcule a HBM total necessária para cada formato. Qual formato permite rodar em uma única GPU H100 de 80GB? - Você tem um modelo de codificação de 7B. Selecione um formato e justifique a escolha. Se você estivesse errado quanto à tolerância a perdas de qualidade, qual seria o caminho de recuperação?
- Calcule o tamanho do dataset de calibração necessário para calibrar o AWQ para um modelo de domínio médico. Por que o excesso de dados nem sempre é a melhor escolha?
- Leia o artigo científico ou notas de lançamento do kernel Marlin-AWQ. Explique em três frases por que o AWQ atinge 741 tok/s em modelos 7B enquanto o GPTQ padrão atinge ~712.
- Quando faz sentido combinar pesos em AWQ com KV cache em FP8 em vez de manter o KV em BF16?
Termos-Chave
| Termo | O que as pessoas dizem | O que realmente significa |
|---|---|---|
| GGUF | "formato do llama.cpp" | Formato de arquivo que reúne variantes K-quant; padrão para CPU/borda |
| Q4_K_M | "Q4 K M" | K-quant de 4 bits médio; o padrão GGUF para produção |
| GPTQ | "gee pee tee q" | Quantização INT4 pós-treinamento com calibração; suporta adaptadores LoRA no vLLM |
| AWQ | "a w q" | Quantização INT4 ciente de ativação; utiliza kernels Marlin; melhor Pass@1 em INT4 |
| Kernels Marlin | "kernels rápidos de INT4" | Kernels CUDA sob medida para INT4 em Hopper; aceleração de até 10x |
| FP8 | "ponto flutuante de oito bits" | Padrão seguro de precisão para Hopper/Ada/Blackwell |
| MXFP4 / NVFP4 | "microescalonamento de quatro bits" | Formato FP de 4 bits do Blackwell com fatores de escala por bloco |
| Dataset de calibração | "dados de calibração" | Textos de entrada usados para selecionar parâmetros de quantização; devem refletir o domínio alvo |
| Quantização de KV cache | "KV INT8" | Escolha de formato à parte dos pesos; afeta a precisão de atenção diretamente |
Leituras Adicionais
- VRLA Tech — LLM Quantization 2026 — Benchmarks comparativos.
- Jarvis Labs — vLLM Quantization Complete Guide — Números de throughput divididos por formato.
- PremAI — GGUF vs AWQ vs GPTQ vs bitsandbytes 2026 — Comparativo detalhado para seleção de formatos.
- vLLM docs — Quantization — Flags e formatos suportados.
- Artigo do AWQ (arXiv:2306.00978) — Formulação original do AWQ.
- Artigo do GPTQ (arXiv:2210.17323) — Formulação original do GPTQ.