Key Takeaways
- A quantização converte os pesos do modelo de 16 bits para 4 ou 8 bits, reduzindo a RAM em 50–75%.
- Q4_K_M é o nível padrão recomendado — melhor equilíbrio entre qualidade e RAM para hardware de consumo.
- Um modelo 7B em FP16 = ~14 GB de RAM. Em Q4_K_M = ~4,5 GB. Em Q8_0 = ~7 GB.
- A perda de qualidade no Q4_K_M é de 1–3% nos benchmarks MMLU em comparação com FP16 — imperceptível na maioria das tarefas práticas.
- GGUF é o formato de arquivo que armazena modelos quantizados para llama.cpp, Ollama e LM Studio.
O que é quantização de LLM e por que importa?
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.
O que é quantização Q4_K_M?
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 usa ~4,5 GB de RAM para um modelo 7B — 70% menos que FP16 — com apenas 1–3% de perda de qualidade
- Os K-quants aplicam precisão diferente a diferentes grupos de pesos de acordo com a sensibilidade (pesos importantes recebem mais bits)
- A variante "M" é a versão padrão recomendada (variantes mais leve "S" e mais pesada "L" também existem)
- Q4_K_M é a escolha padrão para hardware de consumo com 6–16 GB de VRAM
- Funciona com Ollama (`ollama run model:q4_k_m`), LM Studio e llama.cpp
Como Q4_K_M, Q5_K_M, Q8_0 e outros níveis diferem?
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:
| Nível | Bits | RAM (7B) | Perda de qualidade | Quando usar |
|---|---|---|---|---|
| Q2_K | 2 | ~2,7 GB | Alta | RAM < 4 GB, aceite degradação de qualidade |
| Q3_K_S | 3 | ~3,3 GB | Moderada | RAM 4-5 GB |
| Q4_K_M | 4 | ~4,5 GB | Baixa (1-3%) | Padrão para a maioria dos usuários |
| Q5_K_M | 5 | ~5,7 GB | Mínima (<1%) | 16 GB de RAM, melhor qualidade |
| Q6_K | 6 | ~6,6 GB | Quase sem perda | 16 GB de RAM, tarefas de código/matemática |
| Q8_0 | 8 | ~7,7 GB | Insignificante | 16+ GB de RAM, máxima qualidade |
O que é o formato GGUF e como ele se relaciona com a quantização?
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 abril 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.3 8B.
Quanta RAM a quantização economiza para diferentes tamanhos de modelo?
| Tamanho do modelo | FP16 | Q8_0 | Q4_K_M | Q3_K_S |
|---|---|---|---|---|
| 3B | ~6 GB | ~3,8 GB | ~2 GB | ~1,6 GB |
| 7B | ~14 GB | ~7,7 GB | ~4,5 GB | ~3,3 GB |
| 13B | ~26 GB | ~14 GB | ~8,5 GB | ~6 GB |
| 34B | ~68 GB | ~36 GB | ~22 GB | ~16 GB |
| 70B | ~140 GB | ~70 GB | ~40 GB | ~30 GB |
Quanta qualidade você realmente perde com a quantização?
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.
- Q4_K_M vs FP16: Degradação de 1–3% no MMLU. Em um modelo 7B com 73% no FP16, Q4_K_M pontua 71–72%. Em tarefas práticas, essa diferença é imperceptível.
- Q3_K_S vs FP16: Degradação de 5–10%. Perceptível em raciocínio complexo e matemática.
- Q2_K vs FP16: Degradação de 15–25%. Perda de qualidade significativa em todos os tipos de tarefas. Use apenas quando a restrição de RAM for absoluta.
- Q8_0 vs FP16: Menos de 0,5% de degradação — essencialmente idêntico para todos os fins práticos.
- As variantes K_M (K-Quant Medium) usam uma abordagem de precisão mista que preserva a qualidade melhor do que a quantização Q4_0 mais antiga no mesmo número de bits. Sempre prefira Q4_K_M ao Q4_0 quando ambos estiverem disponíveis.
Qual quantização você deve usar? (Árvore de decisão rápida)
Escolha com base na VRAM disponível, não apenas no tamanho do modelo.
| Sua VRAM | Melhor quantização | Tamanho do modelo | Qualidade |
|---|---|---|---|
| 4–6 GB | Q3_K_S ou Q4_K_M | 3B, 7B (Q4) | 7B (Q3) | 5–10% de perda (Q3) | 1–3% (Q4) |
| 6–8 GB | Q4_K_M (recomendado) | 7B nativo | 1–3% de perda (imperceptível) |
| 12–16 GB | Q5_K_M | 7B, 13B nativo | <1% de perda (mínima) |
| 24 GB (RTX 4090) | Q5_K_M ou Q6_K | 13B, 32B nativo | Q4 + offload para 70B | Insignificante <0,5% |
| 32 GB (RTX 5090) | Q5_K_M, Q6_K ou Q8_0 | 70B em Q4 (35 GB), Q5 (43 GB) | 0–2% de perda |
| 48+ GB (2× RTX 4090) | Q5_K_M ou Q8_0 | 70B nativo com layer splitting | Insignificante <0,5% |
LM Studio: Como selecionar a quantização na UI
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.3 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.
Offloading: RAM da CPU como extravasamento
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.
# Ollama: habilitar offloading
export OLLAMA_NUM_GPU=0 # Desabilitar GPU (forçar CPU)
ollama run llama3.3:70b
# vLLM: habilitar offload de CPU (parcial)
vllm serve meta-llama/Llama-3.3-70B-Instruct \
--gpu-memory-utilization 0.7 \
--cpu-offload-gb 10 # Mover 10GB para RAMLayer splitting: distribuir entre múltiplas GPUs
Motores de inferência modernos (vLLM, llama.cpp) podem dividir um modelo entre múltiplas GPUs automaticamente.
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).
# vLLM: paralelismo tensor automático
vllm serve meta-llama/Llama-3.3-70B-Instruct \
--tensor-parallel-size 2 # Dividir entre 2 GPUs
# llama.cpp: suporte multi-GPU
ollama run llama3.3:70b # Detecta e divide automaticamente entre GPUsQuantização de KV Cache: reduzindo o overhead de memória de contexto
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: Use flags `--cache-type-q8_0` ou `--cache-type-f8` ao iniciar o servidor.
Abordagem híbrida: combinando técnicas
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)
Quais são os trade-offs de desempenho?
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.
| Técnica | VRAM economizada | Impacto na velocidade | Impacto na qualidade |
|---|---|---|---|
| Quantização (Q4) | 50% | Nenhum (±5%) | Menor |
| Offloading (RAM CPU) | 60-80% | 5-10× mais lento | Nenhum |
| Layer splitting (2 GPUs) | N/A (permite modelos maiores) | 5-10% mais lento | Nenhum |
| Quantização + Offloading | 75-90% | 3-5× mais lento | Menor |
Mac Studio M2 Ultra: 70B nativo sem offloading
Mac Studio M2 Ultra com 192 GB de memória unificada executa Llama 3.3 70B em Q4 nativamente — sem offloading, sem layer splitting necessário.
Largura de banda de memória unificada: Mac Studio M2 Ultra acessa tanto memória CPU quanto GPU a ~800 GB/s. O offloading de RAM DDR5 do sistema é limitado a ~90 GB/s. Essa vantagem de 9× elimina a penalidade de velocidade que torna o offloading impraticável.
| Setup | Modelo | Velocidade | Complexidade |
|---|---|---|---|
| 1× RTX 4090 + offloading | Llama 3.3 70B Q4 | 5–10 tok/s | Média |
| 2× RTX 4090 layer split | Llama 3.3 70B Q5 | ~100 tok/s | Alta |
| 1× RTX 5090 (32 GB) | Llama 3.3 70B Q4 | 10–12 tok/s | Baixa |
| Mac Studio M2 Ultra | Llama 3.3 70B Q4 | 35 tok/s | Baixa (plug & play) |
Quantização de LLM: Contexto regional
- Brasil (LGPD / ANPD) — A Lei Geral de Proteção de Dados (Lei nº 13.709/2018) e as diretrizes da ANPD exigem tratamento de dados pessoais sensíveis com controles adequados. A quantização Q4_K_M permite que modelos 7B sejam executados em dispositivos de borda de 8 GB, eliminando chamadas à API de nuvem de terceiros. A inferência local on-premises atende aos requisitos da LGPD para processamento de dados de alto risco sem transferências a processadores externos.
- UE (GDPR, Artigo 44) — Transferências internacionais de dados de IA exigem decisões de adequação ou Cláusulas Contratuais Padrão. A quantização Q4_K_M permite que modelos 7B sejam executados em dispositivos de borda de 8 GB, eliminando chamadas à API de nuvem. Os modelos Mistral e Llama quantizados são as escolhas dominantes em deploys empresariais europeus.
- China (Regulamentos de IA Generativa CAC 2023) — A quantização Q4_K_M e Q5_K_M reduz os custos de hardware em 60–70% versus FP16, tornando a conformidade on-premises com a CAC economicamente viável para médias empresas.
Quais são os erros comuns com quantização de LLM?
- Baixar Q4_0 em vez de Q4_K_M — Q4_0 é um método de quantização mais antigo sem melhorias K-Quant. Q4_K_M é 5–8% melhor em qualidade com o mesmo tamanho de RAM. Quando ambos estiverem disponíveis, sempre escolha Q4_K_M.
- Assumir que quantização maior sempre significa pior qualidade — Número Q maior = mais bits = melhor qualidade. Q8_0 é melhor que Q4_K_M. Q5_K_M é melhor que Q4_K_M. Um modelo 70B em Q4_K_M superará um modelo 7B em Q8_0 na maioria das tarefas.
- Não verificar o headroom de RAM antes de carregar um modelo — O tamanho do modelo não é o único consumidor de RAM. SO, navegador e outros aplicativos também usam RAM. Regra: tamanho do arquivo de modelo + 2 GB overhead do SO + 1 GB de headroom = RAM mínima necessária.
Perguntas comuns sobre quantização de LLM
O Ollama usa automaticamente a melhor quantização?
Sim — quando você executa `ollama pull llama3.1:8b`, o Ollama baixa a variante Q4_K_M por padrão. Para baixar uma quantização específica, adicione a tag: `ollama pull llama3.1:8b-instruct-q5_K_M`.
Posso quantizar um modelo eu mesmo?
Sim — llama.cpp inclui um binário `quantize` que converte arquivos GGUF para qualquer nível de quantização suportado. O processo leva 5–30 minutos dependendo do tamanho do modelo. A maioria dos usuários deve baixar arquivos GGUF pré-quantizados do Hugging Face.
A quantização afeta a janela de contexto do modelo?
Não — a quantização afeta apenas a precisão dos pesos do modelo, não o comprimento do contexto. Um modelo Llama 3.3 8B suporta 128K tokens seja em Q4_K_M ou FP16.
Qual é a diferença entre quantização GGUF e GPTQ?
GGUF (formato llama.cpp) e GPTQ são duas abordagens diferentes. GGUF usa K-Quants e roda em CPU e GPU. GPTQ é apenas GPU e requer PyTorch. Para inferência local com Ollama, LM Studio ou Jan AI, GGUF é o formato correto.
Posso executar Llama 3.3 70B em uma única RTX 4090?
Sim, mas lentamente. Quantize para Q4 (35 GB), faça offloading de 11 GB para RAM do sistema. Espere 5-10 tok/s — lento demais para chat em tempo real, bom para processamento em batch. Para inferência prática de 70B: 2× RTX 4090 com layer splitting (~100 tok/s) ou Mac Studio M2 Ultra (35 tok/s nativo).
Fontes
- Documentação de quantização do llama.cpp
- Discussão técnica de K-Quants — PR original de K-Quant
- Especificação do formato GGUF
- Open LLM Leaderboard — benchmarks de quantização