LLM quantization: como escolher GGUF, AWQ, GPTQ e FP8

Escolha a maior precisão que comporte sua carga de trabalho e passe nas suas próprias verificações de qualidade. Um download menor só ajuda se o modelo continuar respondendo corretamente e ainda sobrar memória para a conversa.

A documentação e as informações de compatibilidade foram verificadas nas páginas oficiais dos projetos em 20 de outubro de 2026. Os valores de memória são cálculos baseados na contagem de parâmetros documentada do Qwen2.5-7B-Instruct, e não medições de uso da GPU ou resultados de benchmarks.

LLM quantization: menos precisão, a mesma estrutura do modelo

A quantização armazena os números aprendidos pelo modelo usando menos bits. Um grande modelo de linguagem, ou LLM, gera texto a partir de parâmetros numéricos aprendidos, chamados pesos. Reduzir a precisão desses valores diminui o custo de armazená-los e movimentá-los, mas introduz um erro de aproximação. A visão geral de quantização da Hugging Face explica essa relação entre economia de memória e exatidão.

Imagine uma planta arquitetônica com medidas registradas em alta precisão. Arredondar essas medidas deixa o registro mais compacto, mas altera um pouco algumas dimensões. O prédio continua com os mesmos cômodos. Da mesma forma, a quantização comum de pesos não transforma um modelo grande em outro com menos camadas ou menos parâmetros aprendidos; ela muda a precisão com que os pesos são representados.

A analogia tem um limite: quantizar envolve mais cuidado do que simplesmente apagar casas decimais. Os valores podem ser agrupados, receber um fator de escala e ser mapeados para um conjunto menor de valores representáveis. A escala ajuda o ambiente de execução a recuperar uma aproximação na hora de calcular. Partes importantes podem permanecer em uma precisão maior. A explicação da IBM sobre quantização aborda esses mapeamentos e o erro resultante.

Antes de escolher o que baixar, separe três elementos:

• Pesos: os valores aprendidos que ficam armazenados no modelo.
• Ativações: os valores intermediários produzidos durante o processamento da entrada.
• Cache KV: os dados de atenção salvos do contexto já processado, que ocupam mais memória à medida que a conversa cresce.

Um esquema de quantização apenas dos pesos reduz a primeira categoria. As outras duas não diminuem automaticamente. É por isso que um modelo pode carregar normalmente e ainda assim ficar sem memória durante uma solicitação longa. A documentação de memória e cache do Ollama trata a capacidade de contexto e a precisão do cache separadamente.

Quantização pós-treinamento ou treinamento com reconhecimento de quantização?

Para quem vai baixar um modelo, a quantização pós-treinamento costuma ser o ponto de partida mais relevante. A quantização pós-treinamento, ou PTQ, converte um checkpoint já treinado. Alguns métodos usam dados de calibração: entradas representativas que ajudam a definir como aproximar os pesos. Já o treinamento com reconhecimento de quantização, ou QAT, leva em conta os efeitos da baixa precisão durante o treinamento ou o ajuste fino. A IBM descreve as duas abordagens.

Você não precisa treinar um modelo para usar um checkpoint quantizado já publicado. Precisa, porém, saber de qual modelo original ele veio, qual procedimento de quantização foi usado e qual ambiente de execução consegue carregá-lo. O nome do arquivo, sozinho, diz pouco sobre isso.

GGUF, AWQ, GPTQ e FP8: qual usar em cada ambiente de execução?

Esses nomes se referem a camadas diferentes do sistema, portanto não são alternativas equivalentes. GGUF é um contêiner. AWQ e GPTQ são métodos de quantização. FP8 é um formato numérico. Um checkpoint é o artefato salvo do modelo que reúne os pesos e as informações necessárias para carregá-los.

A Hugging Face, plataforma de hospedagem de modelos e desenvolvedora do Transformers, documenta tanto os formatos de arquivo quanto os métodos de carregamento. A tabela combina essa documentação com as orientações dos próprios ambientes de execução. Ela serve como um mapa prático de escolha, sem pressupor que toda arquitetura de modelo funcione em todos os caminhos listados.

A extensão .safetensors também não resolve a dúvida sobre precisão. Ela identifica um formato de armazenamento de tensores. Leia a configuração de quantização e a ficha do modelo, ou model card, para entender como esses tensores são representados e qual carregador deve ser usado. A documentação de GGUF da Hugging Face distingue os metadados do contêiner dos dados dos tensores, enquanto o guia de AWQ mostra os campos relevantes de quantization_config.

O que significa Q4_K_M?

Trate Q4_K_M como uma predefinição de precisão mista, não como uma garantia de que cada parâmetro ocupa exatamente quatro bits. Q4 identifica a família nominal de quatro bits, K indica o esquema de blocos K-quant e M indica a predefinição média. Alguns tensores podem usar mais precisão, conforme a arquitetura do modelo e as regras do quantizador. A implementação de quantização do llama.cpp explicita essas escolhas.

Até um bloco Q4_K simples inclui dados auxiliares: a tabela de codificação de tensores do projeto informa 4.5 bits por peso quando são incluídas as informações de escala e de valor mínimo. Esse número se refere ao bloco, não à média de qualquer modelo Q4_K_M.

Em uma máquina local com pouca memória, vale avaliar Q4_K_M como candidato. Se uma variante de maior precisão couber junto com o contexto que você pretende usar, compare as duas. Não abra mão da qualidade das respostas só porque existe um arquivo menor.

Como estimar a memória: o exemplo do Qwen2.5-7B-Instruct

Calcule o espaço de todos os parâmetros e depois some a memória necessária para executar o modelo. O Qwen2.5-7B-Instruct, modelo da Qwen ajustado para seguir instruções e usado aqui como exemplo concreto, tem 7.61 bilhões de parâmetros no total. A ficha do modelo informa separadamente 6.53 bilhões de parâmetros fora dos embeddings; usar esse número menor deixaria de fora parte do modelo armazenado. Ficha do modelo Qwen.

O cálculo idealizado é:

Bytes dos pesos ≈ número de parâmetros × bits por parâmetro ÷ 8

Em 16 bits, o cálculo é 7,610,000,000 × 16 ÷ 8 = 15,220,000,000 bytes. Repetindo a conta para as outras precisões:

Esses são cálculos nossos a partir da contagem arredondada de parâmetros da ficha do modelo, supondo que todos os parâmetros usem a quantidade de bits indicada. Para obter GB decimais, divide-se o total de bytes por 1,000,000,000; para GiB, por 1,073,741,824. A diferença de unidade muda o número exibido, mas não a quantidade de memória.

A tabela deixa de fora, de propósito, escalas de quantização, tensores de maior precisão, metadados do arquivo, cache, ativações, buffers temporários de trabalho e reservas do ambiente de execução. Um arquivo Q4_K_M não terá o tamanho ideal indicado na linha de quatro bits. Essa linha também não comprova que o modelo funcionará em uma GPU hipotética de 4 GB.

Por isso, uma conversa curta não basta para testar a capacidade de um assistente de programação local. O teste útil inclui os arquivos de código-fonte, as instruções e o tamanho de resposta que você espera usar. Em um servidor, acrescente solicitações simultâneas. O Ollama documenta explicitamente o efeito das solicitações paralelas e da alocação de contexto sobre a memória.

Veja no guia de cache KV o cálculo separado da memória de contexto. Quantizar pesos e quantizar o cache são controles diferentes; o vLLM também documenta a quantização do cache KV como um recurso próprio.

Escolha o formato a partir do ambiente de execução

Defina como o modelo será executado antes de escolher a precisão. A compatibilidade é um requisito obrigatório. Com isso resolvido, decida pela memória disponível, pela qualidade das respostas e pela latência medida na sua carga de trabalho.

llama.cpp: comece com um GGUF compatível

O llama.cpp, um motor de inferência local, oferece um caminho direto para GGUF quando você quer controlar o artefato e a distribuição entre dispositivos. A documentação do projeto lista execução em CPU, suporte a Apple silicon e execução combinada em CPU/GPU. Isso é útil quando os pesos do modelo não cabem inteiros em uma GPU dedicada. Documentação do projeto llama.cpp.

A limitação é que carregar o modelo com sucesso não garante uma velocidade útil. Dividir a execução entre CPU e GPU muda as condições; ainda é necessário medir o desempenho com seus prompts e respostas reais. Escolha primeiro a arquitetura do modelo, depois um GGUF compatível e, por fim, a predefinição de quantização.

Use o guia dos melhores LLMs locais do site para selecionar o modelo-base. A quantização não fará um modelo inadequado compreender uma tarefa que ele já executa mal em maior precisão.

Ollama: importe a versão quantizada que você pretende usar

O Ollama, que executa modelos localmente, pode importar um GGUF pronto, mas a importação não faz a quantização. O guia de importação atual orienta a preparar primeiro o arquivo quantizado. Isso importa quando se espera que um comando de importação transforme automaticamente um modelo de maior precisão em Q4_K_M. Documentação de importação do Ollama.

Com o Ollama instalado e um arquivo compatível, já quantizado, salvo como model.gguf no diretório atual, o fluxo documentado fica assim:

printf 'FROM ./model.gguf\n' > Modelfile
ollama create quant-check
ollama run quant-check

Execute ollama ps em outro terminal para conferir como o modelo carregado foi distribuído entre CPU e GPU. Isso verifica o que foi carregado; não é um benchmark de qualidade. Perguntas frequentes do Ollama.

A limitação do Ollama continua sendo a memória exigida pela carga de trabalho. A praticidade de um comando não elimina a necessidade de reservar memória para contexto e solicitações simultâneas. A comparação entre Ollama e llama.cpp ajuda a escolher o nível de controle sobre o artefato e o ambiente de execução.

vLLM: alinhe checkpoint, kernel e GPU

O vLLM, um motor de inferência e disponibilização de modelos, exige um checkpoint quantizado compatível com um caminho de execução suportado. Comece pelo artefato AWQ, GPTQ ou FP8 com suporte de quem publicou o modelo e depois confira sua GPU na matriz de hardware do vLLM. Um kernel é a implementação de cálculo de baixo nível que permite executar um formato com eficiência naquele hardware.

Para novos trabalhos de quantização AWQ, a documentação atual indica o LLM Compressor. O AutoAWQ está obsoleto; AWQ, como método e família de checkpoints, continua existindo. Para GPTQ no Transformers, o backend mantido é o GPTQModel, e a compatibilidade pode depender das configurações do checkpoint. Orientações de AWQ do vLLM, orientações de GPTQ da Hugging Face.

FP8 exige mais uma distinção. W8A8 significa pesos e ativações em oito bits; W8A16 significa pesos em oito bits com ativações em dezesseis bits. O vLLM documenta FP8 W8A8 nativo para NVIDIA Ada, Hopper e Blackwell, enquanto Turing e Ampere podem usar o caminho W8A16, que reduz apenas a precisão dos pesos, por meio do Marlin. Portanto, ler “suporte a FP8” não basta para saber qual caminho de cálculo será usado. Documentação de FP8 do vLLM.

Não adote GGUF como artefato padrão para implantação no vLLM só porque ele funcionou localmente. A documentação atual encaminha o uso de GGUF pelo vllm-gguf-plugin e ainda o descreve como experimental e pouco otimizado, com possíveis incompatibilidades de recursos. Isso impõe uma restrição à migração, mas não comprova que o GGUF em si seja inferior. Documentação de GGUF do vLLM.

API hospedada: escolha entre as opções que o endpoint oferece

Se uma API hospedada não oferece uma configuração de precisão, não há uma escolha local de quantização a fazer. Leia as especificações do endpoint. Se ele oferece variantes de precisão identificadas, avalie a variante escolhida; caso contrário, avalie as respostas e a latência do serviço sem tentar adivinhar sua representação interna.

O mesmo nome de modelo não basta para presumir a mesma quantização, o mesmo ambiente de execução ou os mesmos resultados entre provedores. Peça um checkpoint documentado ou uma garantia de precisão apenas quando a aplicação precisar disso. Enviar e disponibilizar seus próprios pesos é outra decisão de implantação, que traz de volta a necessidade de verificar a compatibilidade entre o ambiente de execução e o hardware.

O que muda com a quantização: memória, velocidade e qualidade

Representações menores economizam memória; velocidade e qualidade precisam ser avaliadas separadamente. Manter menos dados na memória pode reduzir o trabalho de movimentar os pesos. Mas o ambiente de execução também pode precisar desempacotar ou converter esses valores antes de usá-los nos cálculos. A documentação de GPTQ da Hugging Face explica como um kernel fundido pode restaurar pesos de poucos bits para os cálculos sem expandir o modelo inteiro na memória global da GPU.

Isso explica tanto o potencial quanto o limite. Um kernel compatível pode aproveitar os pesos compactos. Um caminho de execução inadequado pode anular a vantagem. Meça o tempo até o primeiro token, a velocidade de geração e a vazão no nível de simultaneidade pretendido, em vez de tratar o tamanho do arquivo como um benchmark de velocidade.

A qualidade também depende da tarefa. Em um assistente de programação, compare se a alteração proposta passa nos testes relevantes. Na extração de documentos, confira os campos obrigatórios e a validade da saída estruturada. Em um assistente multilíngue, inclua os idiomas que serão atendidos. Uma resposta fluente não é evidência suficiente de que a quantização preservou o comportamento necessário para a tarefa.

A comparação útil coloca o mesmo checkpoint original em maior precisão e na quantização candidata, com os mesmos prompts, template de chat e configurações de geração. Se você também comparar modelos diferentes ao mesmo tempo, não conseguirá isolar o que mudou por causa da quantização.

Quando a quantização não compensa e quais promessas são exageradas

Mantenha a maior precisão quando ela já cabe na memória e a variante quantizada não oferece nenhum benefício operacional medido. Comprimir mais significa ter outro artefato e outro comportamento para validar. Isso precisa resolver um problema real do seu projeto.

Não adote uma variante de menor precisão se ela falhar em verificações importantes da tarefa, se o caminho de execução tiver pouco suporte ou se sua carga de trabalho com contexto longo continuar excedendo a memória. Nesse último caso, examine o contexto e a simultaneidade antes de continuar reduzindo os pesos.

Também não trate uma versão quantizada para inferência como um checkpoint universal de treinamento. O bitsandbytes documenta suporte ao treinamento em poucos bits para parâmetros adicionais, como os pesos de adaptadores. Trata-se de um fluxo específico de ajuste fino, não de uma indicação de que qualquer modelo quantizado baixado aceita o treinamento convencional de todos os pesos. Documentação do bitsandbytes na Hugging Face.

Estas são as promessas exageradas mais comuns:

• “Quatro bits significa que a aplicação inteira usa um quarto da memória.” Essa proporção descreve a relação ideal entre a largura dos pesos em quatro e dezesseis bits. A memória usada na execução inclui outros componentes.
• “Oito bits é um formato só.” FP8, INT8 e Q8_0 são representações e caminhos de execução diferentes.
• “Menos bits sempre significa mais velocidade.” Checkpoint, kernel, hardware e carga de trabalho determinam se a redução de memória melhora a latência ou a vazão.
• “Um modelo maior quantizado sempre supera um modelo menor de alta precisão.” A quantidade de parâmetros e o número de bits, sozinhos, não determinam a qualidade na tarefa. Avalie os dois candidatos se ambos couberem na memória.

Para selecionar modelos voltados à programação, consulte o guia dos melhores modelos locais de IA para programar. Depois, compare as variantes de quantização do checkpoint escolhido nas tarefas que você pretende executar.

Quantização de LLMs: como dar o próximo passo no projeto

Comece com um artefato compatível e uma avaliação pequena e reproduzível. Mantenha o mesmo modelo original até entender o efeito da precisão.

Perguntas frequentes

Para receber guias práticos sobre como executar e colocar sistemas de IA em produção, assine a newsletter.