Otimização de Inferência de LLMs — Decoding Especulativo, KV Cache e Quantização na Prática

Por que isso importa agora

A maioria das equipes de engenharia já passou da fase de "rodar um LLM localmente" para a fase de "servir um LLM em produção com custo controlado". E a constatação é unânime: inferência é onde o dinheiro realmente vai embora. O custo de servir um modelo com bilhões de parâmetros em volume não-trivial facilmente supera o custo de treino em poucos meses.

A boa notícia: em 2026, o ecossistema de otimização de inferência amadureceu o suficiente para que a maioria das técnicas seja aplicável sem rewrite profundo da aplicação.

Quantização — a técnica com melhor ROI

Quantização reduz a precisão numérica dos pesos do modelo (de FP16 para INT8, INT4 ou até INT3), cortando uso de memória e acelerando computação com perda mínima de qualidade.

Principais abordagens

• GPTQ: quantização one-shot pós-treino, amplamente suportada. Bom para modelos que você não vai retreinar. Perceptível perda de qualidade abaixo de 4 bits em tarefas complexas.
• AWQ: protege canais importantes do modelo (activations salientes), mantendo qualidade superior ao GPTQ em 4 bits com custo semelhante de implantação.
• bitsandbytes (NF4): integração direta com Hugging Face, carregamento dinâmico, ideal para prototipagem. Um pouco mais lento que GPTQ/AWQ em throughput bruto.

Quando usar

python# Exemplo com bitsandbytes — carregamento em 4 bits
from transformers import AutoModelForCausalLM, BitsAndBytesConfig

quantization_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_compute_dtype=torch.bfloat16,
    bnb_4bit_use_double_quant=True
)

model = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Llama-3-70B",
    quantization_config=quantization_config,
    device_map="auto"
)

Para a maioria dos casos de produção, AWQ em 4 bits oferece o melhor equilíbrio entre qualidade e performance. Reserve GPTQ para quando você precisa do máximo de velocidade e pode tolerar uma leve degradação.

KV Cache — o gargalo que todo mundo ignora

A KV cache armazena os key-value vectors de atenção para tokens anteriores, evitando recomputação. O problema: em modelos grandes e contextos longos, ela consome mais memória que os pesos do modelo.

Estratégias de otimização

• PagedAttention (vLLM): gerencia a KV cache como páginas de memória virtual, eliminando fragmentação e permitindo batch size efetivamente maior. Redução típica de 2-4x no uso de memória vs alocação contígua.
• Windowed attention: limita o contexto de atenção a uma janela deslizante. Apropriado quando informações relevantes estão concentradas no final do prompt. Perda de qualidade em tarefas que dependem de recall longo.
• KV cache compression: técnicas como H2O (Heavy Hitter Oracle) descartam entradas menos relevantes da cache. Útil para contextos muito longos (>16K tokens).

Configuração prática com vLLM

pythonfrom vllm import LLM

llm = LLM(
    model="meta-llama/Llama-3-70B-AWQ",
    tensor_parallel_size=4,
    gpu_memory_utilization=0.92,
    max_model_len=8192,
    kv_cache_dtype="fp8_e5m2"  # compressão adicional da KV cache
)

Continuous Batching — servindo múltiplos usuários eficientemente

Batching estático (esperar N requests para processar juntos) é simples mas introduz latência. Continuous batching (dynamic batching) processa requests conforme chegam, adicionando e removendo do batch em tempo real.

Frameworks como vLLM e TGI implementam isso nativamente. O ganho é significativo: sem continuous batching, throughput cai 3-5x quando o tráfego é variável. Em 2026, não há motivo para usar batching estático em produção.

Speculative Decoding — inferência mais rápida sem redução de qualidade

Speculative decoding usa um modelo menor (draft model) para gerar múltiplos tokens candidatos, que são validados em paralelo pelo modelo grande (target model). Tokens corretos são mantidos; incorretos são descartados e regenerados.

Quando vale a pena:

• Quando você tem um modelo grande servindo em produção e pode rodar um modelo menor no mesmo hardware
• Latência por token individual não muda muito, mas latência por batch melhora significativamente
• O modelo draft ideal é 10-20% do tamanho do modelo target, da mesma família

Quando não vale:

• Se o seu bottleneck é memory-bound (modelo já cabe na GPU)
• Se workload é primariamente single-user
• Se o custo da inferência do draft model supera o ganho de throughput

Framework para decisão

Qual é o seu principal problema?
├── Custo de GPU muito alto
│   └── Comece com quantização AWQ 4-bit + continuous batching (vLLM)
├── Latência por request alta
│   └── KV cache optimization (PagedAttention) + speculative decoding
├── Não consigo servir número suficiente de usuários
│   └── Continuous batching + quantização para liberar memória
└── Qualidade degradou com quantização
    └── AWQ em vez de GPTQ, ou mantenha 8 bits para tarefas sensíveis

A maioria das equipes resolve 60-80% do problema com quantização + continuous batching. As técnicas restantes (speculative decoding, KV cache compression) entram quando há necessidade específica ou quando a escala exige.

Próximos passos

1. Meça antes de otimizar: baseline de latency P50/P99, throughput (tokens/s), e custo por 1M tokens com a configuração atual
2. Implemente quantização primeiro: é a mudança com melhor custo-benefício e menor risco
3. Adicione continuous batching: se usa vLLM ou TGI, já está disponível — basta configurar
4. Avalie speculative decoding apenas se houver necessidade de redução de latency com qualidade preservada

Precisa otimizar inferência de LLMs em produção? Fale com a Imperialis sobre otimização de inferência e reduza custo e latência com base em dados.