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

  1. 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?
  2. 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?
  3. 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?
  4. 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.
  5. 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

0 lifetime access. Curriculum based on AI Engineering from Scratch by Rohit Ghumare (MIT, used under attribution).