Quantização GGUF: qual nível usar? // mrsaynothing

Escolha Q4_K_M por default; vá de Q6_K ou Q8_0 quando sobrar VRAM e faltar só o último ponto percentual de qualidade. A quantização GGUF encolhe os pesos de um modelo de 16 bits para menos — o Q4_K_M guarda cerca de 4.85 bits por peso, então um modelo 7B cai de ~14 GB para ~4.1 GB com perplexidade tipicamente menos de 1% pior que a original. A pergunta “qual quantização gguf usar” tem uma resposta estável a ponto de entediar, que a maior parte do drama online esconde. Abaixo: o que a quantização realmente faz com os pesos, quanta qualidade cada nível custa, como fazer a conta de tamanho sozinho e um comando para medir o dano no seu próprio hardware em vez de confiar no benchmark de um desconhecido.

O que a quantização GGUF realmente faz?

Um modelo é treinado em ponto flutuante de 16 bits (FP16 ou BF16): cada um dos seus bilhões de pesos é um número de 2 bytes. Quantização comprime cada peso em menos bits. O jeito ingênuo — arredondar todo peso para um inteiro de 4 bits — destrói valores pequenos mas importantes, então o GGUF usa dois truques:

Escalonamento por blocos. Os pesos são agrupados em blocos (geralmente 32), e cada bloco ganha seu próprio fator de escala. Os valores de 4 bits são offsets dentro do bloco, então uma faixa ampla de magnitudes sobrevive.
K-quants conscientes de importância. O “K” em Q4_K_M significa super-blocos de escalas, além de tratar as camadas de attention e feed-forward de forma diferente entre si, porque toleram compressão de maneira desigual.

A família “I” (IQ4_XS e companhia) vai além com codebooks de teoria da informação emprestados da compressão de imagem. Mesma ideia, encoding mais sofisticado: menos bits por peso com qualidade parecida, ao custo de inferência um pouco mais lenta em alguns backends.

Um esclarecimento que evita a maior parte da confusão: a quantização muda apenas os pesos armazenados. Arquitetura, tokenizer e tratamento de contexto ficam intactos. Um arquivo Q4 e um Q8 do mesmo modelo são o mesmo modelo usando casacos diferentes.

Q4 vs Q8: quantização mais alta é melhor?

Tecnicamente sim; perceptualmente não. Usando as rodadas de perplexidade do próprio llama.cpp em modelos Llama como referência: o Q8_0 fica a ~0.02% do FP16 — para qualquer propósito prático, lossless. O Q6_K é quase indistinguível. O Q4_K_M ganha cerca de 1–2% de perplexidade, o Q4_0 um pouco mais, e o Q2_K é onde respostas coerentes começam a desmoronar em modelos pequenos.

Duas regras que os números implicam:

Tamanho do modelo compra folga de quantização. Um modelo 70B sobrevive a Q2/Q3 muito melhor que um 7B, porque modelos maiores são mais redundantes. Quantizar um 7B para Q2 é amputação; quantizar um 70B para Q3 é alfaiataria.
O piso de qualidade se move com a tarefa. Chat tolera Q4. Geração exata de código, matemática e RAG sobre documentos precisos expõem o ruído de quantização mais cedo. Se um modelo Q4 vive escrevendo código sutilmente errado, teste o mesmo modelo em Q6_K antes de culpar o modelo.

Nível	Bits/peso	Tamanho vs FP16	Perda de qualidade	Use quando
Q2_K	~3.4	~21%	Severa abaixo de 13B	Nada mais cabe, só modelos grandes
Q3_K_M	~3.9	~25%	Perceptível	VRAM apertada, modelos ≥14B
Q4_K_S	~4.6	~29%	Pequena	Q4_K_M não cabe e está perto
Q4_K_M	~4.85	~30%	~1% de perplexidade	O default. Melhor troca qualidade/tamanho
Q5_K_M	~5.7	~35%	~0.5%	VRAM disponível, tarefas críticas de qualidade
Q6_K	~6.6	~41%	Quase nula	Código/matemática, ainda cabe confortavelmente
Q8_0	~8.5	~53%	Efetivamente nenhuma	Rodadas de referência, bases de fine-tune
IQ4_XS	~4.3	~27%	≈Q4_K_M	Q4_K_M um pouco grande demais, backend suporta i-quants

De quanta VRAM cada nível precisa?

Faça a conta de tamanho em vez de decorar tabelas — é uma linha:

size_GB ≈ (bits_per_weight × params) / 8
# modelo 8B @ Q4_K_M: 4.85 × 8 / 8 ≈ 4.9 GB
# modelo 8B @ Q8_0:   8.50 × 8 / 8 ≈ 8.5 GB

Depois some as partes que a fórmula deixa de fora: o KV cache (cresce com o tamanho do contexto — de algumas centenas de MB a vários GB), as ativações e os buffers de computação. Margem prática: um modelo “de 4.9 GB” quer uma placa de 6 GB em contexto 4k, e flash-attention com quantização de KV cache para continuar lá em 16k. Os pesos são a manchete, não a conta inteira.

Qual quantização GGUF você deve usar?

Ordem de decisão, sem exceções que valham decorar:

Calcule seu orçamento de contexto + KV primeiro, depois os pesos. Contexto que não cabe é pior que qualidade que você não consegue medir.
Fique no Q4_K_M por default. É o default da comunidade por um motivo — cerca de 1% de perplexidade por 70% do tamanho. Todo registry, incluindo o do Ollama, o entrega como baseline.
Suba para Q6_K quando a tarefa pune ruído: código, matemática, extração, qualquer coisa que você alimenta a um pipeline sem supervisão.
Use Q8_0 só para referência — testes A/B, medição de dano de quantização ou base de fine-tune. Como máquina do dia a dia, ele principalmente compra calor nos seus sensores de VRAM.
Desça abaixo de Q4 só sob coação, e só em modelos grandes. Teste com um prompt conhecidamente difícil antes de confiar.

Se você está escolhendo qual arquivo baixar no Hugging Face, prefira um Q4_K_M.gguf único a splits fragmentados, a menos que quem subiu só tenha publicado estes — menos peças móveis. E se está escolhendo onde rodar, a escolha de engine é outro eixo: veja llama.cpp vs Ollama para esse lado.

Como medir o dano da quantização você mesmo?

Benchmarks diferem; seu prompt é constante. Compile o llama.cpp uma vez, baixe dois níveis do mesmo modelo e meça perplexidade (menor é melhor) e tokens/segundo:

git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build && cmake --build build --config Release -j

huggingface-cli download bartowski/Meta-Llama-3.1-8B-Instruct-GGUF 
  Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf Meta-Llama-3.1-8B-Instruct-Q8_0.gguf 
  --local-dir models

# perplexidade num trecho de wiki-text (menor = mais perto do modelo original)
./build/bin/llama-perplexity -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99
./build/bin/llama-perplexity -m models/Meta-Llama-3.1-8B-Instruct-Q8_0.gguf  -ngl 99

# e velocidade no mesmo hardware
./build/bin/llama-bench -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99

O número do Q4_K_M será alguns centésimos de ponto pior que o do Q8_0, e o arquivo será ~40% menor. Se sua tarefa downstream não nota a diferença — e para a maioria, não nota — você tem a resposta sem ler leaderboard de ninguém.

A quantização prejudica privacidade ou o discurso de local-only?

Não — é aritmética sobre pesos, inteiramente offline, e o arquivo quantizado é só um contêiner menor dos mesmos parâmetros. Rodar um Q4_K_M localmente vaza exatamente tanto (ou tão pouco) quanto rodar o modelo em precisão total localmente: nada sai da máquina. A variável relevante para privacidade é onde a inferência roda, não a largura em bits. As ressalvas de sempre sobre proveniência de modelo valem igualmente para cada nível de quant: um fine-tune “uncensored” de base roubada em Q8 não é mais seguro que os mesmos pesos em Q4. Para o lado do formato de arquivo, veja como rodar modelos GGUF localmente.

Qual nível escolher?

Q4_K_M, e pare de ler fórum sobre isso. Suba para Q6_K em trabalho que exige precisão se a VRAM permitir, mantenha um Q8_0 por perto para comparações A/B, e trate tudo abaixo de Q4 como ração de emergência, só para modelos grandes. O único erro que vale evitar é simétrico: se preocupar com Q4-vs-Q5 enquanto ignora o tamanho do contexto, que quebra mais setups locais do que qualquer quant já quebrou.

Quantização GGUF: qual nível usar?