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

#Quantização: o que você troca por memória

Um modelo é um conjunto de bilhões de números, os pesos. Em FP16, cada um ocupa 16 bits: um modelo com 8 bilhões de parâmetros pesa aproximadamente 16 GB. A quantificação armazena cada peso em menos bits. De acordo com a documentação da ferramenta llama-quantize, esse processo reduz o tamanho do modelo e pode acelerar a inferência, ao custo de uma perda de precisão medida em perplexidade ou em divergência de Kullback-Leibler. O formato GGUF usado por llama.cpp, Ollama e LM Studio reúne essas variantes. A escolha correta depende de três quantidades: a memória da sua placa ou do seu Mac, o tamanho do modelo e o contexto que você pretende usar. Q4_K_M oferece o melhor equilíbrio na maioria dos casos, porque a perda de qualidade permanece baixa enquanto o tamanho cai para cerca de 30% do FP16.

#Decodificar os nomes: Q4_K_M, Q5_K_S, Q8_0, IQ3_XXS

O número (Q2 a Q8)

O número nominal de bits por peso. O valor real é maior, pois tensores sensíveis permanecem em precisão superior: Q4_K_M mede 4,89 bits por peso.

_0 e _1

Formatos antigos, com precisão uniforme. O Q8_0 continua sendo usado por sua quase ausência de perda, mas os Q4_0 e Q5_0 foram substituídos pelas variantes K.

_K

Os K-quants, mais recentes, distribuem os bits de acordo com a importância dos tensores.

S, M, L

Small, Medium, Large: para o mesmo número de bits, M mantém mais bits nos tensores importantes do que S, então ocupa um pouco mais de espaço e perde um pouco menos.

IQ

Os I-quants, com matriz de importância: para um mesmo tamanho, preservam melhor a qualidade com quantizações de pouquíssimos bits (abaixo de 4 bits) e exigem um pouco mais de processamento na decodificação. Eles se baseiam em um arquivo imatrix.

#Tabela de decisão: tamanhos e perdas medidos

O README do llama-quantize publica, para Llama 3.1 8B, o número de bits por peso e o tamanho de cada formato. A biblioteca Ollama exibe, para o mesmo modelo, o tamanho dos arquivos distribuídos. Os dados das duas fontes coincidem aproximadamente e fornecem uma ordem de grandeza aplicável a outros modelos da mesma família.

Uma ressalva sobre a última coluna: as perdas de perplexidade vêm de uma discussão no repositório llama.cpp que reproduz a tabela de ajuda da ferramenta, elaborada em 2023 com um modelo de 7 bilhões de parâmetros. Elas mostram a ordem dos formatos, não o comportamento exato dos modelos atuais, alguns dos quais são mais sensíveis.

#Calcular a memória de um modelo em alguns segundos

O tamanho de um arquivo GGUF é calculado pela seguinte fórmula: parâmetros em bilhões multiplicados pelos bits por peso, divididos por oito, dão gigabytes. Para um 70B em Q4_K_M: 70 × 4,89 ÷ 8 ≈ 42,8 GB, como confirma a tabela do llama.cpp para Llama 3.1 70B (43,1 GB). Adicione, em seguida, o cache KV, que cresce com o contexto, e uma margem para o sistema.

taille du fichier (Go) ≈ paramètres (milliards) × bits par poids ÷ 8

Exemple : 32 milliards en Q5_K_M
32 × 5,70 ÷ 8 ≈ 22,8 Go
+ cache KV (selon le contexte) + 1 à 2 Go de marge

#Como a quantização realmente afeta a qualidade

As medidas de perplexidade classificam os formatos de maneira consistente: mais bits, menos perda. Mas a perplexidade não prevê bem capacidades específicas. Um estudo publicado no arXiv em janeiro de 2026 comparou os formatos do llama.cpp no Llama-3.1-8B-Instruct, com testes de raciocínio, conhecimento e cumprimento de instruções: a perplexidade no WikiText-2 varia de 7,32 para FP16 a 8,96 para Q3_K_S, e os autores observam que a perplexidade não é um preditor completo do comportamento nas tarefas subsequentes. A pontuação média do Q5_0 chega até a superar ligeiramente a do FP16 (69,92% contra 69,47%), o que se deve a ruído de medição, e não a um modelo melhorado.

O resultado útil refere-se ao raciocínio matemático: no GSM8K, a pontuação passa de 77,63 em FP16 para 68,31 em Q3_K_S. Os autores recomendam evitar quantizações agressivas de 3 bits e preferir Q4_K_S ou Q5_0 quando a carga envolve raciocínio em várias etapas. As tarefas que primeiro penalizam a quantização são, portanto, os cálculos, o código e as longas cadeias de raciocínio, não a conversa cotidiana.

De Q8 para Q6

Diferença não mensurável na prática nas tabelas publicadas.

De Q6 para Q4_K_M

Perda baixa, visível principalmente em tarefas de raciocínio longo, código e línguas pouco representadas.

Abaixo de 4 bits

Queda acentuada no desempenho de raciocínio: evitar, a menos que seja necessário por limitações de memória.

#Por que um arquivo menor também gera mais rápido

As medições do README do llama.cpp, feitas em Llama 3.1 8B, ilustram um ponto que os guias omitem: a geração de texto lê a totalidade dos pesos ativos em cada token, portanto depende principalmente da quantidade de bytes a serem lidos. Na tabela, a taxa de geração passa de cerca de 51 tokens por segundo em Q8_0 para cerca de 72 em Q4_K_M e 90 em Q2_K_S. A leitura do prompt, por outro lado, permanece estável em torno de 800 tokens por segundo, pois é limitada pelo cálculo e não pela memória. Esses números provêm de um hardware específico do repositório e não são os da sua máquina; lembre-se da tendência: menos bits, geração mais rápida.

Duas consequências práticas. Primeiro, passar de Q4_K_M para Q8_0 para obter um ganho imperceptível de qualidade reduz a velocidade de geração em cerca de 30% nessas medições. Segundo, a quantização dos pesos e a do cache KV são dois ajustes distintos: a segunda reduz a memória necessária para contextos longos e é tratada em um guia próprio.

#Escolher com base em três regras

1. 01
   Parta da sua memória disponível

   VRAM de uma placa NVIDIA ou AMD, ou memória unificada de um Mac descontando cerca de 25% para o sistema. Se o modelo ultrapassar a memória disponível, parte do processamento passa para a CPU e a velocidade cai, muitas vezes ficando várias vezes menor.
2. 02
   Use o maior modelo que caiba em Q4_K_M

   Com a mesma memória, um modelo maior em 4 bits geralmente é melhor que um menor em 8 bits. É uma regra empírica amplamente compartilhada, que deve ser verificada em suas próprias tarefas, especialmente nas tarefas de programação.
3. 03
   Aumente em seguida a precisão com a margem restante

   Se ainda houver VRAM após reservar o contexto, passe para Q5_K_M e depois para Q6_K. O ganho é menor do que passar de um tamanho de modelo para o seguinte.

ollama run llama3.1:8b-instruct-q5_K_M

As etiquetas da biblioteca Ollama indicam o formato e o tamanho de cada variante; quando você omite o sufixo, o Ollama aplica a etiqueta padrão do modelo. No Hugging Face, os nomes dos arquivos GGUF incluem o nome da quantização.

#Os I-quants e formatos abaixo de 4 bits

A tabela do llama.cpp permite medir a economia real. No Llama 3.1 8B, o IQ4_XS ocupa 4,17 GiB contra 4,58 GiB para o Q4_K_M, ou seja, cerca de 9 % a menos; o IQ3_XXS ocupa 3,04 GiB; o IQ2_XXS, 2,23 GiB. Nas medições do repositório, as taxas de geração desses formatos permanecem próximas às dos K-quants, com uma diferença de apenas alguns tokens por segundo: o custo adicional de decodificação é, portanto, modesto. Os I-quants, por outro lado, dependem da qualidade da imatrix e do modelo: só fazem sentido quando o Q4_K_M não cabe na memória.

IQ4_XS

Tamanho próximo ao de Q4_K_M, mas cerca de 9% menor. Útil quando a VRAM está no limite.

IQ3_XXS e IQ3_S

Um modelo de 13B com aproximadamente 5 GB de pesos, com uma perda perceptível no raciocínio.

IQ2 e IQ1

Apenas para modelos gigantes, quando nenhuma outra opção couber na memória. Em quantizações desse tipo, a fidelidade é mensurável: ver o exemplo de Kimi K3, em que a quantização dinâmica de 1 bit tem apenas 78,9% de concordância com o original.

#Modelos publicados diretamente em 4 bits

Alguns modelos recentes não são mais treinados em 16 bits e depois comprimidos: seus pesos são gerados em 4 bits com um treinamento que leva a quantização em conta. Kimi K3 é um exemplo: sua ficha indica pesos MXFP4 e ativações MXFP8, com quantization-aware training. Para esses modelos, o arquivo nativo já é a referência, e uma quantização adicional para um formato de menor precisão causa mais degradação do que a quantização de um modelo em 16 bits. Leia sempre a ficha do modelo antes de convertê-lo.

#O que escolher de acordo com sua memória

#Para se aprofundar

• Q4_K_M, Q5_K_M e Q6_K na prática
• Compreender a janela de contexto
• Quantizar o cache KV: economizar VRAM
• GGUF, safetensors: entender os formatos
• Calculadora de VRAM

• Fonte: README do llama-quantize (llama.cpp)
• Fonte: estudo no arXiv sobre quantização no llama.cpp (2026)
• Fonte: tags do Llama 3.1 no Ollama
• Fonte: discussão no llama.cpp sobre métodos de quantização