Quantização GGUF em 2026: Q4_K_M vs Q5_K_M vs Q6_K em pratique

#Por que este comparativo

A quantização é a arte de compactar os pesos de um modelo de 16 ou 32 bits por parâmetro para 8, 5, 4 ou até 2 bits. Menos bits = menos VRAM, mais velocidade, mas qualidade reduzida. O formato GGUF do llama.cpp oferece cerca de dez variantes, e 90% dos usuários escolhem Q4_K_M por padrão sem saber se é a escolha adequada para o seu modelo ou para o seu caso de uso.

O problema: as recomendações que circulam datam de 2024, não consideram as matrizes de importância (imatrix) que passaram a ser amplamente utilizadas desde então e confundem perplexidade bruta com qualidade real em francês. Refizemos os testes de forma correta em três famílias de 2026: Qwen3-14B, Llama 4 Scout (17B-A2B MoE) e DeepSeek V3.2-Lite (16B). O objetivo: um comparativo honesto e útil entre as quantizações GGUF Q5_K_M e Q4_K_M.

#Lembrete rápido: GGUF e os K-quants

GGUF é o formato de arquivo do llama.cpp. Dentro dele, cada tensor de pesos pode ser quantizado independentemente de acordo com um conjunto de esquemas chamados Q2_K, Q3_K_S, Q3_K_M, Q3_K_L, Q4_K_S, Q4_K_M, Q5_K_S, Q5_K_M, Q6_K, Q8_0 — e as variantes IQ (i-quants) para precisões muito baixas.

O número

Número médio de bits por peso. Q4 ≈ 4 bits, Q5 ≈ 5 bits, Q8 ≈ 8 bits.

_K

Esquema K-quant: pesos agrupados em blocos com ajuste fino de escala. Muito melhor que os antigos Q4_0 / Q4_1.

_S / _M / _L

Small / Medium / Large. Os tensores “importantes” (atenção, embed) recebem maior precisão em M e L. _M é uma opção padrão razoável.

Q6_K

Sem S/M/L: um único esquema. Muito próximo de FP16 em qualidade, com 60% do tamanho.

Q8_0

Quase sem perda. Reservar para modelos muito pequenos (< 3B) ou quando o uso de VRAM não for uma preocupação.

#Protocolo de teste

Quantizamos cada modelo em 7 variantes (Q2_K, Q3_K_M, Q4_K_M, Q5_K_M, Q6_K, Q8_0, FP16 como referência), utilizando uma matriz de importância (imatrix) calibrada com 4 MB de texto misto em francês, inglês e código — Wikipédia em francês, código Python, ficção técnica. As conversões foram feitas com a versão b5500+ do llama.cpp, em uma RTX 4090.

# 1. Calibration imatrix sur un corpus mixte
./llama-imatrix \
  -m qwen3-14b-f16.gguf \
  -f calibration_mixte_fr_en_code.txt \
  -o qwen3-14b.imatrix

# 2. Conversion avec imatrix
./llama-quantize \
  --imatrix qwen3-14b.imatrix \
  qwen3-14b-f16.gguf \
  qwen3-14b-Q5_K_M.gguf \
  Q5_K_M

Para cada variante, foram medidos quatro indicadores: (1) perplexidade no wikitext-103 em inglês e em um corpus em francês com 200 artigos; (2) pontuação em 50 prompts em francês abrangendo raciocínio, tradução, código e síntese, avaliados às cegas por três revisores; (3) velocidade em tokens por segundo com contexto de 4k e 32k; (4) tamanho do arquivo em GB.

#Tabela de perplexidade por quantização

A perplexidade (PPL) mede o quanto o modelo fica «surpreso» com um texto de referência. Quanto menor, melhor. A comparação é feita pelo percentual de degradação em relação ao FP16 — é isso que facilita a interpretação, não o valor bruto.

Resultados com Qwen3-14B (perplexidade wikitext em inglês / corpus FR, diferença em relação ao FP16) :

FP16 (referência)

PPL EN 5.42 / FR 7.18 — baseline, tamanho 28 GB

Q8_0

+0,04% EN / +0,05% FR — tamanho 14,9 GB. Indistinguível de FP16 em texto normal.

Q6_K

+0,15% EN / +0,21% FR — tamanho 11,5 GB. Excelente, já muito difícil de distinguir.

Q5_K_M

+0,48% EN / +0,61% FR — tamanho de 9,9 GB. O ponto ideal de qualidade.

Q4_K_M

+1,12% EN / +1,48% FR — tamanho 8,4 GB. A opção padrão clássica, com degradação visível, mas moderada.

Q3_K_M

+3,85% EN / +5,12% FR — tamanho 6,6 GB. Primeiro patamar de perda significativa de qualidade.

Q2_K

+11,4% EN / +16,7% FR — tamanho 5,3 GB. Evitar, salvo em caso de necessidade urgente de economizar VRAM.

No Llama 4 Scout (17B-A2B MoE), as perdas são mais acentuadas em níveis baixos de quantização: Q4_K_M aumenta a degradação em +1,9% em francês, Q3_K_M em +6,4%. Os MoE toleram menos as quantizações agressivas, porque cada especialista vê apenas uma fração dos tokens e tem menos redundância. Q5_K_M é claramente preferível no Scout.

No DeepSeek V3.2-Lite, o comportamento é clássico: Q4_K_M fica em +1,3% FR, Q5_K_M em +0,5%. O Q6_K quase não tem custo em termos de qualidade.

#Degradação da qualidade em francês

Esse é o aspecto mais frequentemente esquecido nos benchmarks anglo-saxões. Os LLMs têm menos tokens em francês no treinamento, então suas representações em FR são mais vulneráveis à compressão. A regra empírica que confirmamos: a degradação em FR é ~30 a 40% mais acentuada que a degradação em EN com o mesmo nível de quantização.

Notas qualitativas FR sobre 50 prompts (média de 10, três jurados em anonimato), Qwen3-14B :

FP16

8,4 / 10 — a referência

Q8_0

8,4 / 10 — rigorosamente idêntica na prática

Q6_K

8,3 / 10 — diferença imperceptível

Q5_K_M

8,1 / 10 — algumas expressões um pouco menos elegantes, conteúdo inalterado

Q4_K_M

7,7 / 10 — respostas corretas, mas simplificações visíveis nas questões complexas

Q3_K_M

6,9 / 10 — surgem alucinações, vocabulário em francês empobrecido

Q2_K

5,2 / 10 — erros de concordância, erros de interpretação, às vezes mudança involuntária para o inglês

#Velocidade: trade-off entre velocidade e qualidade

Na RTX 4090, com offload completo para a GPU, Qwen3-14B com contexto de 4k:

Q4_K_M

78 tok/s — a mais rápida entre as quantizações K viáveis

Q5_K_M

65 tok/s (-17%) — penalidade real, mas não dramática

Q6_K

54 tok/s (-31%) — a diferença começa a ser perceptível

Q8_0

42 tok/s (-46%) — a VRAM move mais

FP16

26 tok/s (-67%) — não competitivo nessa placa

No Mac M4 Pro 48 GB (memória unificada), o perfil muda: Q4_K_M e Q5_K_M estão quase iguais (32 vs 30 tok/s) porque a limitação é a largura de banda da memória, não o processamento. No Mac, a 'penalidade' do Q5_K_M é desprezível — prefira usá-lo.

Na RTX 3060 de 12 GB, a VRAM passa a ser o fator dominante: o Q5_K_M do Qwen3-14B cabe por muito pouco com contexto de 8k, enquanto o Q4_K_M deixa margem para 16k. Nesse caso, a escolha depende do contexto que você deseja, e não da qualidade.

#imatrix vs static: a diferença é real

Uma quantização "estática" (sem imatrix) distribui a precisão uniformemente. Uma quantização com imatrix usa um corpus de calibração para identificar os pesos importantes e preservar uma precisão maior para eles. Isso se tornou o padrão nas versões de Bartowski e mradermacher e na maioria dos lançamentos sérios no Hugging Face em 2026.

Ganho medido no Qwen3-14B Q4_K_M, em francês:

Estático (sem imatrix)

PPL FR +2,1% vs FP16, avaliação qualitativa 7,4/10

imatrix apenas em inglês

PPL FR +1,6%, nota 7,6/10 — melhor, mas subótimo para o FR

imatrix mista FR/EN/código

PPL FR +1,48%, nota 7,7/10 — a boa prática

A diferença entre imatrix e static é maior nas quantizações baixas (Q2, Q3) do que nas altas (Q6, Q8). Em Q4_K_M, o imatrix proporciona um ganho de qualidade de aproximadamente 0,5–1%; em Q3_K_M, o ganho é de 2–3%. Em Q2_K, é a única forma de obter um resultado utilizável.

#Recomendação por caso de uso

Nenhuma resposta universal. Aqui estão as opções que defendemos, classificadas por perfil:

VRAM com folga (modelo ocupa < 60% da memória da placa)

Use Q6_K. Diferença imperceptível em relação ao FP16, arquivo 40% mais leve. Não há razão para usar uma quantização mais baixa.

VRAM apenas suficiente para o modelo

Q4_K_M continua sendo uma opção padrão sensata. Economize VRAM para o cache KV e contextos longos.

Uso exigente em francês (redação, jurídico, médico)

Use pelo menos Q5_K_M. A perda de qualidade do Q4 em francês é perceptível. Se possível, use Q6_K.

Modelo MoE (Llama 4, DeepSeek, Qwen3-A3B)

Q5_K_M em vez de Q4_K_M. Os modelos MoE sofrem mais com a quantização agressiva.

Modelo pequeno (1B–3B) para edge / CPU

Q8_0 sistematicamente. Os pequenos modelos têm pouca redundância, perder bits faz muito mal a eles.

Modelo de código (Qwen3-Coder, Devstral)

Q5_K_M ou Q6_K. O código não tolera alucinações sutis; a economia de VRAM com Q4 não vale a pena.

VRAM muito limitada (8 GB), desejo de usar um modelo grande

IQ3_M ou IQ3_XS com imatrix. Melhor que Q3_K_M para o mesmo tamanho.

Sem GPU, apenas CPU

Q4_K_M. Os IQ-quants ficam mais lentos ao rodar apenas na CPU, Q5 consome RAM demais, e Q4_K_M oferece o melhor equilíbrio entre taxa de geração e qualidade.

#Armadilhas frequentes

Comparar perplexidade entre famílias de modelos

Não faz sentido. A PPL só é comparável quando se mantém o mesmo modelo, no mesmo corpus. Compare Qwen3 Q4 com Qwen3 Q5, não Qwen3 Q4 com Llama 4 Q4.

Q4_0 ou Q4_1

Esses antigos esquemas não-K já não têm razão de existir. Se você encontrar um GGUF Q4_0 recente, provavelmente é um arquivo publicado por preguiça — siga em frente.

Quantização do cache KV

É outro assunto (parâmetro --cache-type-k q8_0 no llama.cpp). Muitas vezes confundido com a quantização do modelo. Fazer os dois ao mesmo tempo reduz o uso de VRAM, mas acumula as perdas de qualidade.

Tensores críticos em baixa precisão

Algumas ferramentas permitem usar Q8 para embed e output mesmo em um GGUF Q4. É isso que o Q4_K_M faz por padrão. Se você vir Q4_K_S marcado como "Q4 puro" por alguém que fez o upload, tenha cuidado: a qualidade real é inferior.

Acreditar que Q5_K_M consome 25% mais VRAM do que Q4_K_M

Falso. A diferença no tamanho do arquivo real é de ~18%. E uma vez na VRAM, o cache KV (contexto) ocupa a mesma quantidade em ambos os casos.

#Para se aprofundar

Este comparativo assume que você já sabe manipular os GGUF e executar o llama.cpp. Se algum ponto ainda estiver confuso, veja os guias relacionados:

Escolher sua quantização (Q4, Q5, Q8, FP16)

Nosso guia de introdução se você quiser os fundamentos antes desse comparativo avançado

TurboQuant: quantizar modelos grandes

O próximo passo para fazer um modelo de fronteira (>100B) caber em hardware de consumo.

Compilar llama.cpp com CUDA

Indispensável para você mesmo quantizar pesos recém-publicados com imatrix.