Quantização e poda: os 5 métodos para deixar seu LLM mais enxuto

Um time passa três semanas ajustando um modelo, atinge as métricas que queria — e só então tenta colocá-lo em produção. O checkpoint sozinho tem 140 GB. Esse único número elimina quase toda GPU que uma empresa comum tem no rack, força uma reescrita do plano de deploy e transforma o que deveria ser uma semana de lançamento em uma correria atrás de quatro A100 que ninguém orçou.

Esse momento é mais comum do que deveria — e quase sempre evitável. O modelo não precisava ser entregue em precisão total, com cada parâmetro intacto. Precisava ser entregue na versão mais enxuta que ainda faz o trabalho. As duas técnicas que levam você até lá — quantização e poda (pruning) — não são exóticas nem novas. Só são subutilizadas por times que assumem que “deixar menor” significa “deixar pior”.

O que quantização e poda realmente são

As duas são constantemente agrupadas, mas resolvem problemas diferentes de formas diferentes.

Quantização reduz a precisão dos números que compõem o modelo. Um peso armazenado em 16 bits, algo como 0,0023847, é arredondado e re-representado com menos bits — um inteiro de 8 ou 4 bits. O número de parâmetros não muda: cada peso que existia continua existindo. Só ocupa menos espaço e computa mais rápido — como uma foto em alta resolução salva com menor profundidade de bits, que ainda mostra todos os objetos do enquadramento, mas com menos precisão no sombreamento.

Poda remove pesos — ou estruturas inteiras — de vez. Uma conexão entre dois neurônios, uma cabeça de atenção, às vezes uma camada inteira é apagada porque o modelo não precisa dela. A contagem de parâmetros cai de fato. É como editar um documento longo cortando frases que não acrescentavam nada, em vez de apenas escrever tudo com fonte menor.

As duas encolhem o modelo, só que ao longo de eixos diferentes — e, como você verá, elas se empilham bem uma sobre a outra.

Por que isso importa agora

Um modelo de 70 bilhões de parâmetros em FP16 precisa de cerca de 140 GB de VRAM só para carregar — o que na prática significa quatro GPUs A100 antes de servir uma única requisição, algo em torno de US$ 80 mil a US$ 100 mil em hardware parado. Comprimir o mesmo modelo para 4 bits usando AWQ ou GPTQ o derruba para algo como 35 a 40 GB — pequeno o bastante para caber em uma única placa de workstation de ponta em vez de um pequeno cluster.

Isso está moldando como os grandes laboratórios entregam modelos em 2026. O Gemma 3, do Google, levou sua variante de 27B de 54 GB para cerca de 14 GB em 4 bits, cortando a perda de qualidade pela metade em relação à quantização pós-treino simples. O Gemma 4 foi além, entregando checkpoints já quantizados que levam a variante de 2B a ~1 GB — pequena o bastante para rodar inteira em um celular. Os modelos on-device da Apple usam o mesmo truque, comprimindo pesos para 2 bits via treino com consciência de quantização.

O que acontece se você pular — ou fizer mal feito

Pular a compressão e o fracasso é simples e caro: modelo grande demais para o hardware que você tem, uma conta de inferência que inviabiliza o produto, ou latência alta o suficiente para quebrar qualquer caso de uso que exige resposta rápida.

O fracasso oposto é mais silencioso e mais perigoso. Quantize de forma agressiva demais, sem um dataset de calibração adequado, ou ignore os poucos pesos atípicos que carregam uma fatia desproporcional da capacidade do modelo — e a acurácia degrada de formas que não aparecem em um teste rápido. Um estudo da Red Hat com mais de 500 mil avaliações de modelos quantizados mostrou que a perda de qualidade varia muito por modelo, tarefa e método. E, no lado da poda, o Wanda documentou que a poda por magnitude pura falha dramaticamente em LLMs mesmo em níveis modestos de esparsidade.

Os cinco métodos em resumo

Método 1: bitsandbytes (NF4)

É o método que a maioria dos times deveria buscar primeiro. Ele usa o tipo de dado NF4 (NormalFloat4), projetado em torno do fato de que os pesos de redes neurais tendem a seguir uma distribuição aproximadamente normal — então os 16 valores disponíveis em 4 bits são posicionados onde os pesos de fato se agrupam. É também o único método da lista que suporta QLoRA, permitindo carregar o modelo em 4 bits e ainda fazer fine-tuning treinando pequenos adaptadores de baixa ordem por cima.

Método 2: GPTQ

Um dos primeiros métodos de 4 bits que se sustentou em modelos grandes (Frantar et al., 2022). Ele quantiza camada por camada e usa informação de segunda ordem — uma aproximação da matriz Hessiana — para corrigir o erro introduzido ao arredondar um peso, ajustando os pesos vizinhos. Exige um dataset de calibração (algumas centenas de amostras). Uma limitação honesta: um benchmark de janeiro de 2026 mostrou o GPTQ ficando atrás em tarefas de geração de código (~46% no HumanEval, contra ~51,8% de AWQ e GGUF), por causa da propagação de erro coluna a coluna em matrizes longas.

Método 3: AWQ

Introduzido em 2023, observa as ativações durante uma passada curta de calibração e identifica um pequeno percentual de canais de peso “salientes” — os que produzem as maiores magnitudes de ativação. Esses pesos são protegidos com um truque de escala, enquanto o resto é quantizado de forma agressiva. É o padrão atual para serving GPU em produção: com o kernel Marlin, roda ~1,6x mais rápido que o FP16 original retendo ~92% da acurácia em código.

Método 4: SparseGPT (poda estruturada one-shot)

Foi o método que provou que LLMs podiam ser podados agressivamente sem retreino. A chave prática é o padrão de esparsidade: a esparsidade 2:4 estruturada da NVIDIA (dois zeros em cada grupo de quatro pesos) é o que os Sparse Tensor Cores das GPUs Ampere/Hopper/Blackwell conseguem explorar — gerando ganho real de velocidade, e não apenas um arquivo menor em disco.

Método 5: Wanda (poda por pesos e ativações)

Simplifica o SparseGPT: em vez de resolver um problema de reconstrução com inversão de Hessiana, pontua cada peso usando o produto de sua magnitude pela norma L2 da ativação de entrada correspondente — calculável em um único forward pass. Sem etapa de atualização de pesos. O paper original reporta que é cerca de 300x mais rápido de computar que o SparseGPT. Em modelos menores (~7B), o SparseGPT tende a vencer; em modelos grandes, o Wanda se mantém melhor.

Empilhando poda e quantização

Os métodos não são um menu de escolha única. Pode-se podar um modelo de 70B primeiro (SparseGPT ou Wanda, 50% de esparsidade 2:4) e depois quantizar o que sobrou (AWQ ou GPTQ): um modelo que precisava de 140 GB em FP16 pode cair para 17–18 GB — o bastante para rodar em uma GPU de consumo de ponta. A ordem importa: podar primeiro e quantizar depois funciona porque a quantização calibra contra a distribuição real final de pesos.

Como escolher

• Vai fazer fine-tuning? bitsandbytes + QLoRA é o único construído para isso.
• Serving em escala (vLLM)? AWQ + kernel Marlin é o padrão atual.
• Já tem um checkpoint GPTQ funcionando? Raramente vale migrar só por migrar — mas projeto novo deve começar com AWQ.
• Laptop, edge device, Ollama ou LM Studio? Esse mundo roda no formato GGUF, voltado para inferência eficiente em CPU.

Nenhum dos cinco métodos deixa o modelo pior, feito corretamente. Eles o deixam honesto. A maioria dos modelos grandes sai com mais precisão e mais parâmetros do que a tarefa exige. Quantização e poda são o caminho para descobrir o que um modelo realmente precisa — e cortar o resto.