Quantização de LLM explicada: Q4_K_M vs Q4_0 vs Q8_0 (2026)

A quantização converte os pesos do modelo de 16 bits (FP16) para inteiros de 4 ou 8 bits, reduzindo a RAM em 50–75% com apenas 1–3% de perda de qualidade no Q4_K_M. Um modelo de linguagem grande armazena seu conhecimento aprendido como bilhões de pesos numéricos. Por padrão, eles são armazenados como números de ponto flutuante de 16 bits (FP16) — dois bytes por peso. Um modelo 7B tem 7 bilhões de pesos, portanto o tamanho do arquivo FP16 é de aproximadamente 14 GB.

A quantização substitui esses floats de 16 bits por inteiros de menor precisão. Na quantização de 4 bits, cada peso usa 0,5 bytes em vez de 2 — reduzindo a memória para ~3,5 GB apenas para os pesos. Com overhead de metadados, um modelo 7B quantizado para Q4_K_M tem aproximadamente 4,5 GB.

Isso importa para inferência local porque o hardware de consumo tem RAM limitada. Sem quantização, um modelo 7B requer 16 GB de RAM para ser executado. Com quantização Q4_K_M, o mesmo modelo roda com 6 GB de RAM, tornando-o acessível na maioria dos laptops modernos.

Q4_K_M é um formato de quantização GGUF de 4 bits usado no llama.cpp e Ollama. O "K" significa que usa K-quants (precisão mista), e "M" = medium — equilíbrio entre tamanho do modelo, velocidade e perda de qualidade. Q4_K_M armazena a maioria dos pesos em 4 bits, mas usa 6 bits para as camadas mais sensíveis, dando-lhe uma melhor relação qualidade/tamanho do que o Q4_0 puro de 4 bits.

Q4_K_M em 4 bits é a recomendação padrão — aproximadamente 4,5 GB de RAM para um modelo 7B com apenas 1–3% de perda de qualidade em relação ao FP16. Os nomes de quantização seguem um padrão: Q{bits}_{variante}. O número de bits é a precisão dos pesos; a variante afeta como a quantização é aplicada:

Use esta calculadora para calcular os requisitos exatos de VRAM para qualquer combinação de modelo, quantização, contexto e tamanho de lote. Selecione sua configuração e veja quais GPUs são compatíveis.

Q8_0 é um formato de quantização GGUF de 8 bits efetivamente sem perdas — menos de 0,5% de degradação de qualidade em relação ao FP16 — com cerca de metade do tamanho do arquivo. Cada peso é armazenado em 8 bits mais uma pequena escala por bloco, então um modelo 7B fica com ~7,7 GB em vez de ~14 GB em FP16. Diferentemente dos K-quants (Q4_K_M, Q5_K_M), o Q8_0 usa precisão uniforme de 8 bits para todos os pesos — não há variante "K" de precisão mista porque 8 bits já preservam quase toda a informação.

Escolha Q4_K_M em vez de Q4_0. Ambos têm média de 4 bits por peso, mas Q4_K_M é um K-quant que armazena as camadas mais sensíveis em 6 bits, recuperando 5–8% de qualidade com a mesma pegada de ~4,5 GB para um modelo 7B. Q4_0 é o formato uniforme de 4 bits original do llama.cpp inicial e existe hoje apenas por compatibilidade legada. Não há razão de tamanho ou velocidade para escolher Q4_0 quando Q4_K_M está disponível.

Q4_K_M é o K-quant padrão de 4 bits do llama.cpp. Q4_K_XL não é um tipo padrão: é uma variante GGUF "Dynamic" da Unsloth que mantém a base de 4 bits mas eleva para maior precisão as camadas mais sensíveis (embeddings, attention e saída). O tamanho do arquivo e a qualidade ficam entre Q4_K_M e Q5_K_M — o mesmo princípio que Q8_K_XL aplica sobre Q8_0, só que sobre uma base de 4 bits.

Os tamanhos exatos do Q4_K_XL variam conforme o modelo e conforme quantas camadas a Unsloth eleva, então confira o tamanho exibido no LM Studio ou no Hugging Face antes de baixar, em vez de contar com um número fixo. Regra prática: se Q5_K_M couber na sua VRAM, escolha Q5_K_M — é um formato padrão com suporte mais amplo nas ferramentas. Q4_K_XL é o passo intermediário para quando Q4_K_M cabe mas Q5_K_M fica de fora por pouco.

Q4_K_M e Q4_K_S são ambos K-quants de 4 bits; a diferença é quantas camadas permanecem em precisão mais alta. Q4_K_M (Médio) mantém mais camadas sensíveis em 6 bits, enquanto Q4_K_S (Pequeno) empurra mais pesos para 4 bits para economizar ~0,3–0,4 GB em um modelo 7B. Medido no llama.cpp, Q4_K_S adiciona cerca de +0,11 de perplexidade em 7B contra +0,05 do Q4_K_M — aproximadamente 3–5% a mais de perda de qualidade. Escolha Q4_K_S apenas quando esses poucos megabytes decidem se o modelo cabe na VRAM.

Para a maioria das tarefas de chat e escrita, Q4_K_M é o melhor compromisso — usa ~4,5 GB para um modelo 7B contra ~7,7 GB do Q8_0, com apenas 1–3% a mais de perda de qualidade. Escolha Q8_0 (precisa de 16+ GB de VRAM) quando você precisa de máxima fidelidade para código, matemática ou uso de ferramentas por agentes, onde pequenos erros se acumulam. Q8_0 perde menos de 0,5% em relação ao FP16; Q4_K_M perde 1–3%. A diferença é imperceptível no uso diário, mas pode importar em raciocínio numérico preciso.

Q8_0 é o quant de 8 bits padrão do llama.cpp — cada peso em 8 bits, ~7,7 GB para um modelo 7B, menos de 0,5% de perda em relação ao FP16. Q8_K_XL não é um tipo nativo do llama.cpp: é uma variante GGUF "Dynamic" da Unsloth que mantém uma base de 8 bits mas faz upcast das camadas mais sensíveis (embeddings, atenção e saída) para 16 bits (BF16/F16), aproximando a qualidade do FP16 completo com um tamanho de arquivo ligeiramente maior. Q8_K_XL é voltado para usuários que querem a última fração de percentual de precisão e têm VRAM de sobra.

Os tamanhos exatos do arquivo Q8_K_XL variam por modelo e por quantas camadas a Unsloth faz upcast, então verifique o tamanho mostrado na sua ferramenta (LM Studio ou Hugging Face) antes de baixar. Para um modelo 7B–8B, espere que fique ligeiramente acima do Q8_0; em modelos muito grandes, a diferença é maior. Como o Q8_0 já é efetivamente sem perdas para a maioria dos usuários, o Q8_K_XL só vale a pena quando você precisa especificamente de máxima fidelidade e a VRAM extra é gratuita.

GGUF (GPT-Generated Unified Format) é o padrão de arquivo único para pesos de LLM quantizados, contendo pesos do modelo, metadados e tokenizador — usado pelo Ollama, LM Studio e llama.cpp. Foi criado pelo projeto llama.cpp e substitui o formato GGML mais antigo.

Um arquivo GGUF contém: os pesos quantizados do modelo, todos os metadados do modelo (arquitetura, tokenizador, comprimento de contexto) e um número de versão do formato. Esse design autocontido significa que um único arquivo `.gguf` é tudo que é necessário para executar o modelo — sem arquivos de tokenizador separados, sem JSON de configuração.

A partir de agosto de 2026, GGUF é o formato padrão para Ollama, LM Studio, Jan AI e GPT4All. O nível de quantização faz parte do nome do arquivo: `Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf` é um GGUF quantizado Q4_K_M do Llama 3.1 8B.

Q4_K_M perde 1–3% nos benchmarks MMLU vs FP16 — imperceptível na maioria das tarefas práticas. Q3_K_S perde 5–10% e é perceptível em matemática e raciocínio. A perda de qualidade da quantização é medida comparando pontuações de benchmarks entre versões de precisão total e quantizadas. A partir de agosto de 2026, os resultados estabelecidos são:

A quantização reduz o uso de memória, mas pode degradar a qualidade das respostas. Prompts bem elaborados compensam isso: técnicas como exemplos few-shot e restrições explícitas de saída ajudam os modelos quantizados a manter a precisão. Veja técnicas de prompt engineering para métodos que funcionam em qualquer nível de quantização.

Escolha com base na VRAM disponível, não apenas no tamanho do modelo.

LM Studio (aplicativo desktop) mostra variantes de quantização disponíveis para cada download de modelo. Ao pesquisar um modelo, você verá várias opções GGUF: Q2_K, Q3_K_S, Q4_K_M, Q5_K_M, Q6_K, Q8_0.

Passo 1: Abra o LM Studio → Navegue até a aba "Local Models". Pesquise um modelo (ex.: "Llama 3.1 8B"). Passo 2: Cada modelo mostra quantizações disponíveis. Olhe para o tamanho do arquivo para estimar o uso de VRAM. Q4_K_M para um modelo 7B geralmente está listado como ~4,5 GB. Passo 3: Clique no ícone de download ao lado da quantização escolhida.

Padrões recomendados para o LM Studio:

• Se sua GPU tem 6-8 GB de VRAM (RTX 4060, RTX 3060 Ti, RTX 4060 Ti): Baixe a variante Q4_K_M (menor arquivo com qualidade aceitável).

• Se sua GPU tem 12-16 GB de VRAM (RTX 4070, RTX 4080): Baixe Q5_K_M ou Q6_K (melhor qualidade, ainda dentro da VRAM).

• Se sua GPU tem 24+ GB de VRAM (RTX 4090, RTX 5090): Baixe Q8_0 ou FP16 (qualidade máxima, penalidade de velocidade mínima).

Recurso "GPU offload" do LM Studio: Ative o alternador "Use GPU" na interface de chat. O LM Studio moverá automaticamente o máximo possível de camadas do modelo para a GPU, transferindo o restante para a RAM da CPU. Se a RAM do sistema for suficiente, isso permite executar modelos ligeiramente maiores que sua VRAM (ex.: Llama 3.3 70B Q4_K_M em uma RTX 4090 com 64+ GB de RAM do sistema).

Quando a VRAM está cheia, os modelos podem fazer offloading (mover) camadas para a RAM do sistema. O offloading troca velocidade por capacidade.

Cenário: Executar modelo 70B Q4 na RTX 4090 (24 GB). O modelo precisa de 35 GB. Com offloading, execute a ~5-10 tokens/s (80% para RAM).

O offloading é último recurso — torna a inferência impraticável. Use apenas para processamento em batch offline ou experimentação.

Motores de inferência modernos (vLLM, llama.cpp) podem dividir um modelo entre múltiplas GPUs automaticamente. Saiba mais sobre LLMs locais multi-GPU para configurações avançadas.

Exemplo: modelo 70B com 2× RTX 4090:

• Sem splitting: Impossível (precisa de 40+ GB de VRAM em uma GPU).

• Com splitting: Metade dos pesos do modelo em cada GPU. Velocidade de inferência: ~100 tokens/s (overhead de comunicação mínimo).

O layer splitting é prático para deploys em produção e é transparente para o usuário.

A quantização de KV Cache reduz a memória necessária para armazenar pares chave-valor de atenção durante a inferência, especialmente importante ao processar contextos longos (32K+ tokens).

• Ollama: Automático em modelos compatíveis; nenhuma configuração de usuário necessária.

• LM Studio: Marque "KV cache quantization" nas Configurações (se disponível na sua versão).

• llama.cpp: Inicie o servidor com `--cache-type-k q8_0 --cache-type-v q8_0` (forma curta: `-ctk q8_0 -ctv q8_0`). Use `q4_0` no lugar de `q8_0` para reduzir o cache KV pela metade novamente.

Trade-offs: A quantização de KV Cache tem impacto mínimo na qualidade (<1% de degradação mesmo com quantização agressiva) porque os padrões de atenção são mais robustos a precisões menores do que os pesos do modelo. Recomendado para modelos que processam contextos de 16K+ em hardware limitado.

Os melhores resultados vêm da combinação das três técnicas.

Cenário 1: 70B em uma única RTX 4090 (24 GB)

• Quantize para Q4 (35 GB → 18 GB)

• Use offloading para os 6 GB restantes (para RAM do sistema)

• Resultado: ~8-10 tokens/s (lento, mas funciona)

Cenário 2: 70B em 2× RTX 4090

• Quantize para Q5 (43,75 GB)

• Use layer splitting entre 2 GPUs (22 GB cada)

• Resultado: ~100 tokens/s (prático)

Cada técnica troca redução de VRAM por penalidades de velocidade. A quantização tem impacto mínimo; o offloading causa lentidão de 5–10×; o layer splitting adiciona ~5% de overhead.

O Mac Studio com M5 Ultra (a partir de $5.499, 96 GB de memória unificada de série, até 512 GB) executa Llama 3.3 70B em Q4 nativamente — sem offloading, sem layer splitting necessário.

A Apple renovou a linha Mac Studio em 25 de agosto de 2026 com dois chips: M5 Max ($2.499, até 128 GB de memória unificada, até 614 GB/s de largura de banda segundo as especificações publicadas pela Apple) e M5 Ultra ($5.499 a partir de 96 GB, até 512 GB, até 1.2 TB/s de largura de banda segundo a Apple). Ambos substituem a geração anterior M2 Ultra (192 GB máx., ~800 GB/s). O offloading de RAM DDR5 do sistema continua limitado a ~90 GB/s -- essa diferença de largura de banda é o motivo pelo qual a memória unificada supera o offloading em modelos na escala de 70B.

Ainda não existem benchmarks de desempenho independentes para o M5 Max e o M5 Ultra. As configurações padrão chegam às lojas em 22 de setembro de 2026, e a configuração de 512 GB do M5 Ultra chega no final de outubro de 2026. A PromptQuorum não testou esse hardware -- por isso, os números de tokens por segundo são omitidos para os chips novos até que existam medições independentes.