RunPod compara 4 métodos de quantização: de FP16 a INT4, a memória cai 4 vezes

A RunPod, provedora de GPUs em nuvem, lançou um panorama de quatro formas de comprimir modelos antes do deploy: quantização post-training (PTQ), quantization-aware training (QAT), precisão mista e quantização dinâmica. O material não traz benchmarks próprios; é uma comparação de referência sobre os trade-offs de cada método. Ainda assim, o tema influencia diretamente a conta de inferência. Os pesos de um modelo de 70 bilhões de parâmetros ocupam cerca de 140 GB em FP16, cerca de 70 GB em INT8 e cerca de 35 GB em INT4. A diferença entre "são necessários dois aceleradores de 80 GB" e "um só basta" sai justamente desses números.

Quatro formas de perder um pouco de precisão

O PTQ pega um modelo já treinado, passa por ele um pequeno conjunto de dados de calibração e converte os pesos, e às vezes também as ativações, para INT8 ou INT4. Não há retreinamento, e o processo leva de minutos a horas. É assim que funcionam os populares GPTQ e AWQ. O custo é uma queda de qualidade, sobretudo em 4 bits e em modelos pequenos.

O QAT segue outro caminho. A quantização é emulada durante o treinamento ou o fine-tuning, e o modelo aprende a funcionar com pesos mais "grosseiros". O resultado costuma ficar mais próximo da precisão original, mas exige dados, tempo e horas de GPU, o que pesa bastante no orçamento de um modelo grande.

A precisão mista mantém a maioria das operações em FP16 ou BF16 e deixa em precisão mais alta os pontos sensíveis, como acumuladores, normalização e softmax. A quantização dinâmica armazena os pesos em números inteiros e calcula os intervalos das ativações em tempo real, durante a execução. Ela é a mais simples de aplicar a um modelo pronto e se encaixa bem na inferência em CPU, mas o custo extra de calcular esses intervalos consome parte do ganho.

Referências por nível de precisão

Velocidade e memória melhoram à medida que a precisão cai, mas não na mesma proporção. Alguns valores de referência ajudam a fazer estimativas:

• FP16/BF16: 2 bytes por parâmetro, precisão de base; um modelo de 70B exige cerca de 140 GB só para os pesos.
• INT8: 1 byte por parâmetro, metade da memória; a perda de qualidade na maioria das tarefas costuma ser pequena.
• INT4: 0,5 byte por parâmetro, cerca de 35 GB para 70B; há risco claro de degradação em raciocínio e código.
• Overhead: o KV-cache e as ativações não entram nesses números e crescem com o tamanho do contexto e o número de requisições paralelas.
• Suporte de hardware: só acelera o que os tensor cores sabem calcular nativamente. Na H100, isso significa FP8 e INT8; para INT4, muitas vezes são necessários kernels especiais.

Onde está a pegadinha

A principal armadilha é que comprimir os pesos não equivale a acelerar o modelo. A inferência de modelos grandes costuma esbarrar na largura de banda da memória, por isso pesos menores de fato aceleram a geração de tokens. Já se o runtime faz desquantização constante, sem kernels otimizados, o ganho desaparece. O segundo problema é que métricas médias, como a perplexity, escondem falhas em tarefas específicas: aritmética, contexto longo, idiomas raros, geração de código.

Daí vem uma ordem prática de ação. Na primeira tentativa, use PTQ em INT8, ou no formato de 8 bits que o seu hardware suporta, e compare com o FP16 nos seus próprios dados, não em testes públicos. Se a qualidade se mantiver, experimente INT4 e olhe para os piores casos, não para a média.

Se a queda for crítica e houver orçamento para fine-tuning, passe para o QAT. A quantização dinâmica serve quando não há GPU ou quando é preciso testar uma hipótese rapidamente. Calcule o KV-cache à parte: um modelo INT8 de 70 GB numa placa de 80 GB deixa apenas cerca de 10 GB para contexto e requisições paralelas, e nesse ponto o INT4 ganha pela memória livre, e não pela velocidade.