Você abre o Hugging Face para rodar um LLM local e o mesmo modelo traz uma parede de arquivos—Q4_K_M, Q5_K_S, GPTQ, AWQ, IQ3_M… e você congela. É a primeira barreira em que a maioria das pessoas esbarra. Este artigo responde, na prática, "qual arquivo quantizado eu baixo para conseguir rodar?" Deixamos o que é quantização (o conceito) para outro artigo e focamos aqui em escolher o formato.

Vamos cobrir por que o formato é definido pelo runtime, o esquema de nomes do GGUF (Q4_K_M), os 4 formatos comparados, como escolher a profundidade de bits e como encontrar arquivos. Os pontos-chave logo de cara. ① O formato é decidido principalmente por "em qual engine você vai rodar" (GGUF = llama.cpp/Ollama; GPTQ/AWQ = engines de GPU como o vLLM). Q4_K_M significa "4-bit, K-quant, tamanho M"—o ponto ideal comum na maioria dos casos. ③ Na dúvida, comece com Q4_K_M; suba para Q5/Q6 se tiver VRAM.

FORMATOS DE QUANTIZAÇÃO

O formato é definido pelo runtime

— decida a engine primeiro, e a escolha do arquivo se estreita rápido

GGUF llama.cpp / Ollama / LM Studio = CPU, Mac, GPU parcial também (o único amigável à CPU)
GPTQ vLLM / TGI / ExLlama = GPU (precisa de calibração)
AWQ vLLM / TGI = GPU (protege pesos importantes via ativações)
EXL2 ExLlamaV2 = GPU (largura de bits granular)

Então a primeira pergunta é "em qual engine vou rodar?" Local em CPU/Mac → GGUF. Servidor GPU para velocidade → GPTQ/AWQ.

1. Por que os arquivos quantizados confundem

Quantizar significa arredondar os pesos de um modelo para menos bits, cortando tamanho e memória (veja o que é quantização). O detalhe é que existem vários métodos (formatos) para esse arredondamento, e cada um tem muitas variações de profundidade de bits e granularidade. O resultado: mais de 20 arquivos sob um único modelo no Hugging Face.

Mas fique tranquilo—a escolha fica fácil ao dividi-la em dois passos: ① qual formato (= em qual engine você vai rodar) e depois ② qual arquivo de profundidade de bits dentro dele. Pense nessa ordem.

2. A regra central: o formato é definido pelo runtime

O fato mais importante: um arquivo quantizado só roda em engines que suportam seu formato. Portanto, decida a engine primeiro e o formato é quase automático.

FormatoPrincipais enginesHardwareCalibração
GGUFllama.cpp / Ollama / LM Studio / KoboldCppCPU, Mac, GPU parcial (misto)Opcional (imatrix)
GPTQGPTQModel (antes AutoGPTQ) / vLLM / TGI / ExLlamaGPUObrigatória
AWQAutoAWQ / vLLM / TGIGPUObrigatória
EXL2 / EXL3ExLlamaV2 / ExLlamaV3GPUObrigatória
bitsandbytes (NF4/INT8)Transformers (quantiza no carregamento)GPUNenhuma (sem dados)

Lembre-se de uma coisa: GGUF é o único formato "faz-tudo local" que roda em CPU / Mac / GPU parcial; os demais (GPTQ/AWQ/EXL2) são basicamente só para GPU. Então—

  • Rodando no seu próprio PC / Mac / CPU (Ollama ou LM Studio) → GGUF, sem discussão.
  • Alto throughput num servidor GPU (vLLM/TGI atendendo muitas requisições) → GPTQ ou AWQ.
  • Ajustar a largura de bits com precisão numa única GPUEXL2/EXL3.
  • Teste rápido no Transformers (sem arquivo pré-quantizado) → bitsandbytes (NF4).

3. Decifrando os nomes GGUF (Q4_K_M)

O GGUF, com que você mais vai lidar no uso local, é inofensivo assim que você consegue ler a "cifra" no nome do arquivo. Q4_K_M é composto de três partes.

Q4_K_M
Q4
Profundidade de bits (nominal) = 4-bit. Número maior = mais qualidade, arquivo maior.
K
K-quant (quantização inteligente sobre super-blocos). Sem sufixo / _0 / _1 são legados.
M
S/M/L = small/medium/large. Quanto alguns tensores importantes são "promovidos" para mais bits.

Então Q4_K_M = "K-quant de 4-bit, tamanho M (alguns tensores promovidos para proteger a qualidade)." Os bits efetivos ficam um pouco acima do rótulo (ex.: Q4_K ≈ 4.5 bpw).

Mais dois termos evitam que você se perca.

  • A família IQ (IQ2_XS, IQ3_M, etc.) = I-quants: uma linha mais nova, baseada em codebook, que pode ir ainda menor na mesma profundidade de bits. Mas a inferência é mais pesada, e elas praticamente exigem o imatrix descrito abaixo. Uma carta na manga para "preciso mesmo caber isso na VRAM."
  • imatrix (matriz de importância): passa um texto de calibração pelo modelo para medir quais pesos importam e então protege esses primeiro em baixa profundidade de bits. Opcional para K-quants, praticamente obrigatório para I-quants. GGUFs construídos com imatrix aguentam melhor em bits baixos.

4. Os 4 formatos comparados (GGUF/GPTQ/AWQ/EXL2)

Aqui está o caráter de cada formato principal, incluindo os de GPU.

GGUF

O único formato que roda em CPU/Mac/misto. O padrão do llama.cpp. Flexível com K-quant/I-quant/imatrix. Primeira escolha para uso pessoal local.

GPTQ

O padrão de 4-bit para GPU. Minimiza o erro camada a camada via calibração. Rápido em vLLM/TGI. Agora sucedido pelo GPTQModel.

AWQ

Protege os "pesos importantes" olhando as ativações (activation-aware). GPU, 4-bit apenas nos pesos. Muito usado em vLLM/TGI.

EXL2 / EXL3

Define a largura de bits como uma fração (ex.: 4.5 bpw). Só ExLlama, GPU. EXL3 é uma linha mais nova baseada em QTIP, ainda amadurecendo.

💡 GPTQ vs AWQ (em resumo): O GPTQ "minimiza o erro de reconstrução camada a camada," enquanto o AWQ "olha a distribuição das ativações para proteger cerca de 1% dos pesos mais importantes." Qual vence depende do modelo, da largura de bits e da implementação, então nenhum é universalmente melhor. Escolha simplesmente o que a sua engine suportar.

5. Qual arquivo / profundidade de bits escolher

Uma vez definido o formato, o próximo passo é a profundidade de bits. Usando o GGUF como exemplo, aqui está uma escada prática para "na dúvida, escolha isto" (os números são aproximados e variam conforme o modelo e o build).

ArquivoPapelQuando escolher
Q4_K_MO ponto ideal comum (padrão do Ollama para muitos modelos)Na dúvida. Em geral, o melhor equilíbrio tamanho/qualidade
Q5_K_M / Q6_KMais perto da qualidade plenaVocê tem VRAM sobrando e quer subir mais um degrau
Q8_0Quase sem perdas, mas não recomendadoRaramente necessário (muito mais RAM/mais lento por um ganho ínfimo de qualidade)
IQ2 / IQ3 (I-quant)Espremer com bits bem baixosSó quando você precisa caber um modelo grande na VRAM

Como regra prática, costuma-se dizer que cerca de 4.5–5 bits por peso (Q4_K–Q5_K) é a faixa "saborosa" (uma heurística). Acima de Q6 os ganhos de qualidade desaceleram, e Q8_0 ou FP16 custam muito em memória e velocidade por pouca diferença—esse é o consenso prático. Comece rodando Q4_K_M, suba para Q5/Q6 se parecer insuficiente, desça para IQ se não couber, e ajuste no caminho. Para estimar a VRAM necessária, veja requisitos de hardware para LLM local.

6. Encontrando arquivos no Hugging Face e no Ollama

No Hugging Face, filtre GGUF com library=gguf ou vá até o repositório de um reempacotador de quantizações. No momento da escrita, bartowski e mradermacher publicam GGUFs ativamente (incluindo builds com imatrix)—mas a atividade dos reempacotadores muda, então confira a data de upload mais recente. (Os repositórios do TheBloke, antes referência, ainda existem, mas novos uploads praticamente pararam.) Para converter os seus próprios, o Space oficial gguf-my-repo funciona.

No Ollama, as tags seguem model:size-variant-quant.

# Sem tag = o padrão (Q4_K_M para muitos modelos)
ollama pull llama3.1

# Escolha o quant explicitamente
ollama pull llama3.1:8b-instruct-q5_K_M
ollama pull qwen2.5-coder:7b-instruct-q8_0

# Veja as tags disponíveis em ollama.com/library/<model>/tags

Então o fluxo de trabalho real são três movimentos: decida a engine → estreite para o formato dela → escolha o arquivo de profundidade de bits que caiba na sua VRAM. Domine isso e a parede de 20 arquivos deixa de te intimidar. Para de fato rodar um, veja como rodar um LLM local e o guia do Ollama.

Resumo

Escolher um formato de quantização são dois passos. Primeiro ① em qual engine você vai rodar—CPU/Mac local → GGUF; servidor GPU para velocidade → GPTQ/AWQ; largura de bits ajustada numa única GPU → EXL2; teste rápido no Transformers → bitsandbytes. A regra principal: um formato só roda em engines que o suportam.

Depois ② a profundidade de bits. O Q4_K_M do GGUF significa "4-bit, K-quant, tamanho M"—o padrão comum. Na dúvida, Q4_K_M → (se tiver espaço) Q5/Q6 → (se não couber) IQ. Ancore na heurística da faixa "saborosa" de ~4.5–5 bpw e ajuste enquanto roda. Builds com imatrix aguentam melhor em bits baixos. Relacionados: o que é quantização, como rodar um LLM local, requisitos de hardware, melhores modelos locais, guia do Ollama.

FAQ

Q. Afinal, qual arquivo eu devo escolher?
A. Primeiro decida "em qual engine você vai rodar." Seu próprio PC ou Mac (Ollama/LM Studio) → GGUF; um servidor GPU (vLLM/TGI) → GPTQ ou AWQ. Depois, para a profundidade de bits, na dúvida, Q4_K_M (bom equilíbrio tamanho/qualidade e o padrão do Ollama para muitos modelos). Com VRAM sobrando, Q5_K_M/Q6_K; só quando você precisa caber um modelo grande, considere IQ2/IQ3.

Q. O que significa Q4_K_M?
A. Três partes. Q4 = ~4-bit (número maior = mais qualidade, arquivo maior), K = K-quant (quantização inteligente sobre super-blocos; sem sufixo ou _0/_1 são legados) e M = tamanho médio (S/M/L é quanto alguns tensores importantes são promovidos para mais bits). Os bits efetivos ficam um pouco acima do rótulo (Q4_K ≈ 4.5 bpw).

Q. Como GGUF e GPTQ/AWQ diferem?
A. Pelo runtime (hardware) que suportam. O GGUF é o único formato "faz-tudo local" que roda em CPU, Mac e GPU parcial, para llama.cpp/Ollama. GPTQ e AWQ são focados em GPU e se prestam a alto throughput em vLLM/TGI. Também diferem no método (GPTQ minimiza o erro camada a camada; AWQ protege pesos importantes via ativações), mas nenhum é universalmente melhor. Escolha simplesmente o que a sua engine suportar.

Q. Como o IQ (I-quant) difere de um Q4 normal?
A. Ele pode ir ainda menor na mesma profundidade de bits (um método mais novo, baseado em codebook). Em troca, a inferência é um pouco mais pesada, e ele praticamente exige um imatrix para segurar a qualidade. Seu uso é uma carta na manga para "preciso caber um modelo grande na VRAM." Se couber normalmente, um K-quant como Q4_K_M é mais fácil de lidar.

Q. Q8_0 ou FP16 não têm mais qualidade? Por que "não recomendado"?
A. Eles são de fato quase sem perdas, mas consomem muito mais memória e rodam mais devagar por apenas um ganho ínfimo de qualidade em relação a Q5/Q6. Até a comunidade do llama.cpp não os recomenda para uso normal. Na prática, cerca de 4.5–5 bpw (Q4_K–Q5_K) é a faixa "saborosa", e você sobe ou desce a partir daí conforme a necessidade (os números são aproximados e variam conforme o modelo/build).