GGUF, GPTQ, AWQ e EXL2: guia dos formatos de quantização de modelos de linguagem

Por que entender quantização agora

Rodar um modelo de linguagem grande (LLM) na própria máquina deixou de ser privilégio de data center. Com formatos de quantização como GGUF, GPTQ, AWQ e EXL2, um modelo de 70 bilhões de parâmetros — que em precisão total ocuparia cerca de 140 GB — cabe em menos de 40 GB de VRAM e roda numa única GPU de consumo. Para quem trabalha com IA no Brasil, onde hardware de ponta custa caro e a nuvem é cobrada em dólar, escolher o formato certo é a diferença entre rodar o modelo localmente ou ficar refém de uma API.

O problema é que a terminologia confunde. Este guia separa o que é container do que é método de quantização e mostra qual formato usar em cada cenário.

Primeiro, separe duas ideias: container vs. método

A maior fonte de confusão é misturar duas camadas que, na prática, são coisas diferentes:

• Container define como os tensores (os pesos do modelo) são armazenados em disco. Exemplos: safetensors, GGUF e o pickle do PyTorch (.bin / .pt).
• Método de quantização define como os pesos são comprimidos em menos bits. Exemplos: GPTQ, AWQ, o NF4 do bitsandbytes e os K-quants/I-quants do llama.cpp.
• Os dois ao mesmo tempo: EXL2 e EXL3 são, simultaneamente, um método e um layout de armazenamento atrelado a uma biblioteca de inferência específica.

Regra de bolso para memória

A memória ocupada pelos pesos segue a conta: pesos ≈ parâmetros × bits-por-peso ÷ 8.

1. Precisão total: safetensors e .bin

Modelos sem quantização costumam vir em 16 bits, em pytorch_model.bin ou model.safetensors. Os arquivos .bin/.pt usam pickle do Python, que pode executar código arbitrário ao carregar — um risco de segurança com checkpoints não confiáveis.

O safetensors, criado na Hugging Face, elimina esse risco: é um cabeçalho JSON pequeno seguido de buffers de tensores crus, sem nada executável dentro. Permite memory-mapping e carregar tensor por tensor sem ler o arquivo inteiro. Hoje é projeto da PyTorch Foundation. Uma nuance importante: a maioria dos modelos GPTQ, AWQ, EXL2 e MLX também é armazenada em .safetensors — a quantização vive no conteúdo dos tensores e num arquivo de configuração, não num container novo.

2. GGUF (llama.cpp)

O GGUF é o formato binário do GGML e de executores como o llama.cpp, criado por Georgi Gerganov e lançado em 21 de agosto de 2023 como substituto do antigo GGML. O GGML anterior não dizia a arquitetura do modelo — adicionar um hiperparâmetro quebrava todos os arquivos existentes. O GGUF trocou isso por metadados chave-valor tipados, permitindo adicionar campos novos sem quebrar arquivos antigos.

Ele carrega, num único arquivo, o tokenizer, os tokens especiais e o template de chat Jinja junto com os pesos — algo que formatos só-de-tensores não fazem.

Lendo os nomes de quant

O sufixo em Q4_K_M.gguf indica o esquema. Os tipos legados são Q4_0/Q4_1 e Q8_0; os K-quants vão de Q2_K (2,625 bits/peso) até Q6_K (6,5625), passando pelo Q4_K (4,5). Os I-quants (IQ4_XS, IQ3_XXS, IQ2_XXS, IQ1_S) usam matriz de importância e chegam a 1,56 bits/peso.

Os sufixos _S, _M e _L não são tipos novos — são misturas: o Q4_K_M usa Q6_K em metade dos tensores de atenção e Q4_K no resto, por isso a média fica acima de 4,5 bits por peso.

Qualidade vs. tamanho

O GGUF pode usar dados de calibração via matriz de importância (llama-imatrix + llama-quantize --imatrix), o que melhora a qualidade, sobretudo em misturas de 1-2 bits. Ele roda nativamente no llama.cpp, Ollama, LM Studio e GPT4All; no vLLM o suporte é experimental, via vllm-gguf-plugin.

3. GPTQ

O GPTQ (arXiv em 31/10/2022; ICLR 2023) é de Elias Frantar, Saleh Ashkboos, Torsten Hoefler e Dan Alistarh. É um método de quantização de pesos pós-treinamento em uma única passada (one-shot), que usa informação aproximada de segunda ordem (Hessiana) para decidir como arredondar os pesos. Quantizou modelos de 175B em cerca de 4 horas de GPU, a 3-4 bits por peso, com perda de precisão relatada como desprezível e speedups de ~3,25x em A100 (4,5x em A6000). Precisa de um pequeno conjunto de calibração, mas não de retreinamento.

Nos nomes, 4bit-128g indica tamanho de grupo (uma escala a cada 128 pesos — grupos menores melhoram a precisão, com leve aumento de tamanho) e desc_act a ordem de ativação. Em ferramentas: o AutoGPTQ não é mais mantido — use GPTQModel ou llm-compressor.

4. AWQ

O AWQ (Activation-aware Weight Quantization), do grupo de Song Han no MIT, é de 1/06/2023 e venceu o prêmio de melhor artigo do MLSys 2024. A ideia central: nem todos os pesos importam igual — proteger cerca de 1% dos canais “salientes” reduz drasticamente o erro de quantização. O truque: o AWQ encontra esses canais olhando para as magnitudes das ativações, não dos pesos, e os escala por uma transformação matematicamente equivalente — em vez de armazená-los em mais bits — mantendo um formato uniforme e amigável ao hardware. Sem backpropagation, há menos risco de overfit ao conjunto de calibração.

O runtime TinyChat do paper foi mais de 3x mais rápido que FP16 em GPUs de desktop e mobile. A calibração de um modelo 8B leva ~10 minutos numa A100 — metade do GPTQ. O AutoAWQ está deprecado; use llm-compressor (o caminho recomendado pelo vLLM).

5. EXL2 e EXL3 (ExLlama)

O EXL2 é o formato nativo do ExLlamaV2 (turboderp), voltado a GPUs de consumo. Usa o mesmo método de otimização do GPTQ e permite qualquer bitrate médio de 2 a 8 bits, com mistura por coluna (colunas mais importantes de uma camada recebem mais bits) e alocação automática que mede o erro contra dados de calibração. Por isso os arquivos têm nomes como 4.65bpw, em vez de “4-bit”. Roda via TabbyAPI.

O EXL3, sucessor, é baseado no QTIP (Cornell RelaxML, NeurIPS 2024), com quantização trellis-coded. Converte com Hessianas calculadas em tempo real, em minutos (modelos pequenos) a poucas horas (70B+ numa RTX 4090) — para comparação, o README cita ~720 horas de A100 para o AQLM num 70B. Mantém um Llama-3.1-70B coerente a 1,6 bits por peso, em menos de 16 GB de VRAM. Exige CUDA 12.4 ou superior.

6. bitsandbytes e MLX

O bitsandbytes (NF4/INT8) quantiza na hora do carregamento, sem pré-quantização. O modo 4-bit vem do QLoRA: o NF4 para pesos normalmente distribuídos + dupla quantização. É o caminho padrão de fine-tuning econômico (QLoRA via PEFT) — um modelo de 65B afinado numa única GPU de 48 GB. Não garante speedup de inferência.

Já o MLX-LM é o caminho da Apple Silicon: safetensors com pesos quantizados específicos do MLX, via mlx_lm.convert -q. Num Mac, tanto GGUF (via llama.cpp) quanto MLX são opções fortes.

Qual formato escolher

• Mac, CPU-only ou modelo maior que sua VRAM: GGUF, começando em Q4_K_M (suba para Q5_K_M/Q6_K se sobrar memória).
• Servir muitos usuários em GPUs de data center: AWQ ou GPTQ no vLLM/SGLang, ou FP8 em hardware Hopper/Blackwell.
• Um usuário, GPU NVIDIA de consumo, máximo de tokens/segundo: EXL3 via TabbyAPI.
• Fine-tuning com orçamento apertado: bitsandbytes NF4 + QLoRA.
• Apple Silicon com workflow Python ou fine-tuning: MLX.

Resumo

• Formato de arquivo (GGUF, safetensors) não é a mesma coisa que método de quantização (GPTQ, AWQ).
• GGUF é o padrão para inferência local em CPU, Apple Silicon e misto CPU+GPU.
• GPTQ e AWQ são os cavalos de batalha de 4 bits para servir em GPU.
• EXL2/EXL3 miram inferência rápida de usuário único em GPU de consumo.
• AutoGPTQ e AutoAWQ não são mais mantidos — use GPTQModel ou llm-compressor.