Quantização de LLM: quanto de qualidade você perde e como testar

Quantização de LLM: quanto de qualidade você perde e como testar

Quantização de LLM é a técnica de guardar os pesos de um modelo com menos bits para que ele ocupe menos memória e rode em hardware mais modesto. A perda de qualidade existe, mas varia conforme o nível de compressão, o modelo e a tarefa: em tarefas simples, níveis moderados costumam ser difíceis de distinguir do original, enquanto níveis agressivos tendem a falhar primeiro em raciocínio, formato estruturado e idiomas menos representados. A forma confiável de saber é medir com as suas próprias tarefas, não com a média de benchmarks públicos.

Principais pontos

• Quantizar reduz a precisão numérica dos pesos do modelo, trocando um pouco de fidelidade por menos memória e, em muitos casos, mais velocidade.
• GGUF é um formato de arquivo usado no ecossistema llama.cpp e em ferramentas como o Ollama. O nome do arquivo (Q8_0, Q5_K_M, Q4_K_M) indica o nível de compressão.
• A perda não é uniforme: tarefas de classificação simples sofrem menos do que extração estruturada, cálculo, código e textos longos em português.
• Um bom teste usa exemplos reais da sua operação, um nível de referência, critérios de nota definidos antes e revisão humana dos casos de divergência.
• A decisão final é do negócio: aceitar uma queda pequena de qualidade só faz sentido se a economia de hardware ou a privacidade compensar e se o erro tiver custo baixo.

O que é quantização e por que ela existe

Um modelo de linguagem é, em essência, um conjunto enorme de números chamados pesos. No treinamento, esses números costumam ser guardados com alta precisão. Quantizar é representá-los com menos bits, arredondando valores. O arquivo fica menor, a memória exigida cai e o modelo passa a caber em máquinas que, de outra forma, não o carregariam.

O motivo prático é simples: memória é o limite mais comum para rodar um modelo por conta própria. Um servidor ou notebook com pouca memória de vídeo ou de RAM não carrega um modelo grande sem compressão. Quantizar permite escolher entre três caminhos: usar um modelo maior comprimido, usar um modelo menor com mais precisão, ou pagar por mais hardware.

Vale separar dois conceitos que se misturam. Os pesos são o que a quantização comprime. Já o cache de contexto, que cresce com o tamanho da conversa, também consome memória e pode ter sua própria configuração. Se você trabalha com documentos longos, leia também sobre a janela de contexto em IA, porque um modelo que cabe na máquina com pouco contexto pode deixar de caber com muito.

O que é GGUF e como ler o nome de um arquivo

GGUF é um formato de arquivo que guarda os pesos do modelo junto com metadados, como informações do tokenizador e da arquitetura, em um único arquivo. Ele foi pensado para carregamento eficiente no llama.cpp e é a base de muitos modelos distribuídos para uso local. A documentação do Hugging Face sobre GGUF descreve o formato e como ele aparece nos repositórios de modelos.

O nome do arquivo costuma trazer o nível de quantização. Uma leitura geral, que você deve confirmar na página de cada modelo:

• Q8_0: cerca de oito bits por peso, o nível mais conservador entre os comuns. Serve bem como referência para comparar com os demais.
• Q6_K e Q5_K_M: níveis intermediários, que buscam um equilíbrio entre tamanho e fidelidade.
• Q4_K_M: quatro bits em média, muito usado como ponto de partida por ser compacto e, em geral, aceitável para muitas tarefas.
• Q3_K e Q2_K: compressão agressiva, com risco maior de respostas erradas ou incoerentes.
• Variantes IQ: usam uma calibração com dados para preservar melhor o que importa em poucos bits.

O número indica aproximadamente os bits por peso. O K indica a família de quantização por blocos. As letras S, M e L (pequeno, médio, grande) indicam como o arquivo mistura precisões em diferentes partes do modelo. Existem ainda outros métodos, como GPTQ e AWQ, mais ligados a execução em GPU. O princípio é o mesmo: menos bits, menos memória, algum custo de fidelidade.

Quanto de qualidade se perde, na prática?

Não existe um número universal, e desconfie de quem oferece um. A perda depende do modelo, do método de quantização, da calibração e, principalmente, do que você pede. Por isso este texto separa três tipos de afirmação.

• Documentação oficial: GGUF e os níveis Q são formatos documentados, e a redução de bits implica perda de precisão por definição.
• Experiência de implementação: em avaliações de modelos locais, a diferença entre níveis costuma ser pequena em tarefas curtas e fechadas, e maior em tarefas abertas e longas. Trate isso como padrão a verificar, não como regra.
• Hipótese: modelos maiores toleram mais compressão do que modelos pequenos, e idiomas com menos dados de treino, como o português em alguns modelos, podem degradar antes do inglês. Teste antes de assumir.

Uma consequência útil: a comparação justa raramente é quantizado contra original. Ela costuma ser modelo maior quantizado contra modelo menor com mais precisão, ambos ocupando memória parecida. Quem decide é o seu teste. Se quiser entender quando um modelo menor já resolve, veja o texto sobre modelos pequenos de IA na empresa.

Onde a perda aparece primeiro

A degradação raramente é um declínio suave em tudo. Ela aparece em pontos específicos, e é neles que o teste deve se concentrar.

• Formato estruturado: JSON com campos obrigatórios, listas fechadas e esquemas rígidos passam a falhar com mais frequência, por exemplo com uma chave faltando ou uma vírgula fora do lugar.
• Raciocínio em várias etapas: contas, comparações de condições e regras encadeadas são mais sensíveis do que reescrever um texto.
• Código: o modelo pode produzir algo plausível que não compila ou não faz o que foi pedido.
• Português e termos locais: nomes de produtos, siglas do setor, formas de tratamento e expressões regionais podem ser tratados com menos cuidado.
• Instruções longas: regras no meio de um prompt extenso tendem a ser esquecidas mais cedo.
• Recusas e limites: um modelo comprimido pode obedecer a restrições de forma menos consistente, o que importa se houver dados sensíveis ou políticas de atendimento.

Nota prática: a falha mais perigosa não é a resposta absurda, que alguém percebe, e sim a resposta plausível e errada. Por isso o teste precisa de gabarito, não de impressão geral.

Como testar um modelo quantizado com as suas tarefas

Testar não exige uma plataforma sofisticada. Exige disciplina para comparar as mesmas entradas em condições iguais. As guias de avaliação da OpenAI e da Anthropic descrevem a lógica: definir tarefas, critérios e notas antes de olhar os resultados. O plano abaixo aplica essa lógica à quantização.

• Passo 1: escolha uma tarefa por vez. Por exemplo, classificar a intenção de uma mensagem ou extrair os dados de um pedido. Misturar tarefas esconde onde o modelo falha.
• Passo 2: monte um conjunto de exemplos reais, com variedade. Inclua casos fáceis, casos ambíguos e casos raros que já causaram problema. Remova ou mascare dados pessoais antes de usar, conforme a LGPD.
• Passo 3: escreva o gabarito e os critérios de nota antes de rodar. Defina o que é acerto, erro tolerável e erro grave.
• Passo 4: escolha a referência. Use o nível mais alto que couber na sua máquina, ou o modelo de nuvem que você usaria como alternativa.
• Passo 5: rode os mesmos exemplos nos níveis candidatos, com o mesmo prompt, a mesma temperatura e a mesma semente quando possível.
• Passo 6: compare por categoria de erro, não só pela nota geral. Veja onde cada nível diverge da referência.
• Passo 7: revise manualmente as divergências com quem conhece a operação. Muitas vezes a diferença é de estilo, não de correção.
• Passo 8: meça também velocidade e uso de memória na máquina real, com o tamanho de contexto que você vai usar de fato.
• Passo 9: repita com um conjunto novo antes de decidir, para não escolher um nível que só funcionou nos exemplos que você já conhecia.

Cenário ilustrativo: triagem de mensagens com modelo local

Imagine, como exemplo, uma empresa de serviços que recebe mensagens por WhatsApp e quer classificar cada uma em categorias (orçamento, reclamação, agendamento, outro) e extrair nome e endereço, tudo em um servidor próprio por causa de dados de clientes. O responsável baixa o mesmo modelo em três níveis: Q8_0 como referência, Q5_K_M e Q4_K_M.

O conjunto de teste reúne mensagens anonimizadas, com áudios já transcritos, abreviações e erros de digitação. Na classificação, os três níveis coincidem na maioria dos casos fáceis, e as diferenças se concentram nas mensagens ambíguas. Na extração em JSON, o nível mais comprimido erra o formato em alguns casos, o que quebraria a automação seguinte. A decisão ilustrativa: adotar o nível intermediário, manter uma validação automática do JSON e encaminhar para uma pessoa as mensagens em que a confiança for baixa. Os resultados deste cenário são inventados para mostrar o raciocínio e não representam medição real.

Para a parte operacional de rodar o modelo localmente, o texto sobre Ollama na empresa detalha cuidados de instalação e acesso.

Como decidir o nível de quantização

Um guia de decisão simples, em ordem de prioridade:

• Se o erro tem custo alto (financeiro, jurídico, saúde, decisão sobre pessoas), parta do nível mais alto que o hardware permitir e mantenha revisão humana.
• Se a tarefa exige JSON ou campos rígidos, teste primeiro a taxa de respostas válidas e use validação automática independentemente do nível.
• Se a tarefa é classificação curta ou resumo de rascunho, níveis intermediários costumam merecer teste, com Q4_K_M como candidato inicial.
• Se o hardware não comporta o nível desejado, compare um modelo menor com mais precisão antes de descer para Q3 ou Q2.
• Se o contexto é longo, meça a memória com o contexto real, pois os pesos não são o único consumo.
• Se a diferença entre dois níveis for pequena no seu teste, fique com o menor e mais barato de operar, e registre a decisão.

Se a alternativa for enviar dados a um provedor no exterior, lembre que a escolha por rodar localmente também tem um componente legal. O texto sobre transferência internacional de dados com IA e LGPD ajuda a avaliar esse ponto.

Como isso se encaixa no método de adoção

O método segue quatro movimentos. Mapear: descrever o processo atual, quem faz, com que dados e qual é a linha de base de qualidade. Limitar: definir quais dados o modelo vê e quais ações ele pode executar, de modo que um erro de modelo comprimido não gere dano grande. Pilotar: rodar um fluxo real, com registros das decisões e uma métrica de sucesso combinada, comparando os níveis de quantização no mesmo fluxo. Transferir: entregar a configuração, o conjunto de testes e o critério para reavaliar, e decidir se expande, ajusta ou para.

O conjunto de testes é o ativo mais duradouro. Quando sair um modelo novo ou outra quantização, você repete o teste em vez de recomeçar a discussão. Para a governança mais ampla de risco, o framework de gestão de riscos de IA do NIST é uma referência de apoio.

Perguntas frequentes

Q4_K_M é suficiente para uso em empresa? Pode ser, dependendo da tarefa. É um ponto de partida comum por equilibrar tamanho e fidelidade, mas a resposta só vem do teste com seus exemplos, principalmente se houver saída estruturada ou raciocínio em várias etapas.

Quantizar é a mesma coisa que treinar um modelo menor? Não. Quantizar mantém a arquitetura e comprime a precisão dos pesos de um modelo já treinado. Um modelo menor tem menos parâmetros desde o treino, e pode ser mais preciso do que um maior muito comprimido, o que vale comparar.

Preciso de um conjunto grande de testes? Não necessariamente. Importa mais a variedade e a representatividade do que o volume: inclua casos comuns, ambíguos e raros da sua operação. Se os resultados dos níveis estiverem muito próximos, aumente o conjunto antes de decidir.

A quantização afeta a privacidade dos dados? Quantizar em si não muda o tratamento de dados, mas viabilizar um modelo local pode reduzir o envio de informações a terceiros. Isso não dispensa as obrigações da LGPD sobre finalidade, minimização e segurança, nem o cuidado ao montar o conjunto de testes com dados reais.

Fontes

• Hugging Face: documentação sobre o formato GGUF
• OpenAI: guia de avaliações (evals)
• Anthropic: Demystifying evals for AI agents
• NIST: AI Risk Management Framework