Quantização e inferência rápida no seu próprio hardware

A primeira reação de muitos engenheiros ao olharem para os requisitos de hardware de um modelo de linguagem de grande escala de última geração é de choque com os preços. Um modelo de 70 mil milhões de parâmetros no seu formato FP32 nativo precisaria de aproximadamente 280 GB de memória GPU — mais do que a maioria das organizações tem num único servidor e muito mais do que quer aprovisionar apenas para responder a consultas de colaboradores. A quantização é a técnica que torna estes números tratáveis, e compreendê-la é essencial para qualquer pessoa que projete uma infraestrutura de IA on-premise.

O que a quantização realmente faz

Uma rede neuronal é em última análise uma coleção muito grande de números — os pesos aprendidos durante o treino. Por defeito, esses pesos são armazenados como valores de vírgula flutuante de 32 bits (FP32), cada um consumindo 4 bytes de memória. A quantização substitui números de alta precisão por representações de menor precisão: floats de 16 bits (FP16 ou BF16), inteiros de 8 bits (INT8) ou até inteiros de 4 bits (INT4). A pegada de memória encolhe proporcionalmente e, em hardware com suporte nativo para aritmética de menor precisão, a inferência também fica mais rápida.

• FP16 / BF16 — floats de meia precisão. Virtualmente sem perdas para a maioria das tarefas; a escolha preferida para implementações de produção onde a precisão é crítica. Poupança de memória: 2x em relação ao FP32.
• INT8 — inteiros de 8 bits, tipicamente produzidos por métodos de quantização pós-treino (PTQ) como GPTQ ou llm.int8(). Degradação de qualidade modesta no raciocínio complexo; significativa na maioria das tarefas práticas. Poupança de memória: 4x em relação ao FP32.
• INT4 — inteiros de 4 bits, a fronteira da quantização agressiva. Ferramentas como GGUF Q4_K_M e AWQ entregam qualidade surpreendentemente boa para o seu tamanho. Poupança de memória: 8x em relação ao FP32, com degradação aceitável para cargas de trabalho de chat e sumarização.

O compromisso qualidade-tamanho

A quantização não é gratuita. Cada bit que se remove é informação descartada e, a partir de certo ponto, isso manifesta-se como saída degradada — alucinações, erros de raciocínio ou perda de nuance. A descoberta prática das implementações Privonis é que o compromisso é surpreendentemente favorável para a maioria das tarefas empresariais. Um modelo de 70 mil milhões quantizado para INT4 tipicamente supera um modelo de 13 mil milhões em FP16, mesmo que ambos caibam em memória GPU semelhante. Em caso de dúvida, use o maior modelo que cabe na maior precisão que o seu hardware suporta.

Escolher a quantização certa tem menos a ver com o número de bits e mais com adequar a capacidade do modelo à tarefa: um INT4 de 70 mil milhões bem escolhido supera sempre um FP16 de 13 mil milhões descuidado.

Servidores de inferência: de onde vem o rendimento

Executar um modelo quantizado é apenas metade da história. Servi-lo eficientemente sob carga simultânea requer um servidor de inferência que compreenda a estrutura da atenção dos transformers. A opção dominante de código aberto hoje é o vLLM, que introduziu a PagedAttention — uma técnica de gestão de memória emprestada da memória virtual do sistema operativo que permite ao servidor intercalar muitos pedidos simultaneamente sem desperdiçar memória GPU em blocos de cache KV pré-alocados. O efeito prático é uma melhoria de rendimento de 10–30x em relação a um ciclo ingénuo de pedido único.

Outras opções notáveis incluem o llama.cpp (favorável à CPU, excelente para modelos menores em hardware de commodity), o Ollama (invólucro amigável para desenvolvedores em torno do llama.cpp), o TGI da Hugging Face (forte suporte para formatos de modelos Hugging Face) e o TensorRT-LLM da NVIDIA (maior rendimento em hardware NVIDIA, ao custo de um pipeline de compilação mais complexo). A Privonis avalia e faz benchmark de todos estes para cada configuração de cliente.

Lotes e rendimento

As GPUs atingem eficiência de pico ao processar muitas operações simultaneamente — é para isso que foram projetadas. O agrupamento contínuo (também chamado de agrupamento dinâmico ou agendamento ao nível da iteração) permite que um servidor de inferência agrupe tokens de múltiplos pedidos simultâneos numa única chamada de kernel GPU, melhorando dramaticamente a utilização. Sem agrupamento, um único pedido de utilizador pode usar 5 % da capacidade da GPU; com agrupamento contínuo, pode empurrar a utilização para 70–80 % sob padrões de tráfego do mundo real. Para uma empresa com dezenas de utilizadores simultâneos, a diferença entre um servidor consciente do agrupamento e um ingénuo pode significar a diferença entre precisar de um servidor GPU ou quatro.

Escolher a quantização certa para a sua GPU

A árvore de decisão é mais simples do que parece. Comece com o seu orçamento de memória GPU, subtraia a margem para o SO e o servidor de inferência (tipicamente 4–8 GB), depois encontre o maior modelo que cabe ao nível de precisão mais alto. Alguns pontos de referência práticos:

• 24 GB VRAM (p. ex. RTX 4090, A5000) — corre confortavelmente um modelo de 13 mil milhões em FP16, ou um de 34 mil milhões em INT4.
• 48 GB VRAM (p. ex. RTX 6000 Ada, A6000) — corre um modelo de 34 mil milhões em FP16, ou um de 70 mil milhões em INT4.
• 2 × 80 GB (p. ex. par A100 via NVLink) — corre um modelo de 70 mil milhões em FP16, ou um de 140 mil milhões em INT4 com paralelismo tensorial.
• Apenas CPU (sem GPU) — o llama.cpp com um modelo Q4_K_M de 7 ou 13 mil milhões é viável para ferramentas de desenvolvimento de baixa simultaneidade; espere 5–15 tokens/s.

Pondo tudo junto com a Privonis

Selecionar um formato de quantização e um servidor de inferência é trabalho de engenharia que requer criação de perfis no seu hardware específico com a sua carga de trabalho específica. A Privonis trata desse benchmarking como parte de cada implementação: executamos testes de rendimento, medimos a qualidade da saída numa amostra representativa dos seus prompts reais e entregamos uma configuração que maximiza o desempenho dentro do seu orçamento de hardware. O resultado é uma infraestrutura de inferência de produção que a sua equipa pode operar sem um engenheiro de ML especialista de plantão. Se estiver pronto para explorar o que se adequa ao seu ambiente, a nossa equipa tem todo o prazer em fazer os cálculos consigo.