Servir LLMs on-premise: GPU, quantização e throughput
Guia técnico para dimensionar GPU, aplicar quantização, batching contínuo e KV cache ao servir modelos de linguagem dentro da empresa.
Em "Nuvem, nuvem privada ou on-premise: onde sua IA roda" tratamos a decisão em nível executivo — custo, controle de dados, latência e dependência de fornecedor. Este artigo é o aprofundamento técnico para times que já decidiram (ou estão avaliando seriamente) rodar modelos de linguagem dentro do próprio ambiente. O foco é dimensionamento de GPU e memória, quantização, batching contínuo, KV cache, o trade-off entre latência p95 e throughput, alta disponibilidade e o modelo híbrido on-premise + nuvem.
Dimensionando GPU e memória
O primeiro erro comum é dimensionar pela contagem de parâmetros do modelo sem considerar o contexto de uso real. A memória necessária para servir um modelo tem três componentes:
| Componente | O que consome memória | Cresce com |
|---|---|---|
| Pesos do modelo | Parâmetros em FP16/BF16 ou quantizados | Tamanho do modelo |
| KV cache | Chaves/valores de atenção por requisição ativa | Tamanho do contexto × número de requisições concorrentes |
| Ativações e overhead | Buffers de execução, batching | Tamanho do batch |
Regra prática: um modelo de 7B parâmetros em FP16 ocupa ~14 GB só de pesos. Sem folga para KV cache e batching, uma GPU de 24 GB atende poucas requisições concorrentes com contexto longo. É comum subestimar o KV cache — em contextos de 32k tokens, ele pode superar o tamanho dos próprios pesos quando há múltiplas sessões simultâneas.
Antes de comprar GPU, meça: tamanho médio e p95 de contexto de entrada, tamanho médio de saída, concorrência esperada no pico. Esses três números, não o "modelo mais avançado do mercado", definem a GPU certa.
Quantização: onde ganha e onde perde
Quantização reduz a precisão dos pesos (e às vezes das ativações) para economizar memória e aumentar throughput. As opções mais usadas em produção:
- INT8: perda de qualidade geralmente baixa, ganho de memória de ~2x sobre FP16, suportado amplamente.
- INT4 (GPTQ, AWQ): ganho de memória de ~4x, mas exige validação cuidadosa por caso de uso — tarefas de raciocínio longo ou extração precisa de dados são mais sensíveis a degradação.
- FP8: em GPUs recentes (Hopper e superiores), oferece bom equilíbrio entre precisão e throughput sem calibração complexa.
A decisão não deve ser genérica. Rode a mesma suíte de avaliação (ver "Instrumentação de custo e qualidade") no modelo em precisão original e na versão quantizada, comparando métricas de qualidade específicas do caso de uso, não apenas perplexidade genérica. Em muitos cenários de suporte e busca interna, INT4 é indistinguível na prática; em geração de código ou análise jurídica, a diferença aparece.
Batching contínuo e KV cache
Servidores de inferência modernos (vLLM, TGI, TensorRT-LLM) implementam batching contínuo: em vez de esperar um lote fechado de requisições, novas requisições entram no batch assim que há espaço, e requisições concluídas saem sem bloquear as demais. Isso aumenta drasticamente o throughput comparado a batching estático, especialmente com tamanhos de saída variáveis — típico em chat e agentes.
O KV cache paginado (PagedAttention e técnicas equivalentes) evita fragmentação de memória ao alocar o cache em blocos, permitindo compartilhar prefixos entre requisições (útil quando o mesmo prompt de sistema é reutilizado). Isso é especialmente relevante em arquiteturas de agentes com prompts de sistema longos e repetidos.
Pontos de atenção operacionais:
- Configure limites de tamanho de contexto por rota de uso; contextos irrestritos destroem a previsibilidade de capacidade.
- Monitore taxa de "cache hit" de prefixo quando disponível — é um indicador direto de eficiência de custo.
- Teste o comportamento sob picos: batching contínuo melhora média, mas cauda de latência ainda depende de quantas requisições longas chegam simultaneamente.
Latência p95 vs. throughput
Esses dois objetivos competem. Aumentar o tamanho médio de batch melhora throughput (mais tokens processados por segundo por GPU) mas pode piorar a latência de requisições individuais, especialmente as que chegam quando o batch já está cheio.
Defina o SLO por tipo de interação antes de tunar o servidor:
| Tipo de interação | Prioridade | Configuração recomendada |
|---|---|---|
| Chat interativo | Latência p95 baixa | Batch menor, prioridade de fila para primeiro token |
| Processamento em lote/backoffice | Throughput | Batch maior, sem exigência de tempo real |
| Agentes com múltiplas chamadas | Latência por chamada + custo total | Cache de prefixo, modelos menores em etapas intermediárias |
Sem essa segmentação, uma única configuração de servidor tenta atender objetivos opostos e não satisfaz nenhum bem.
Alta disponibilidade
GPU é um recurso caro e, sem redundância, um ponto único de falha. Práticas mínimas:
- Pelo menos duas réplicas do serviço de inferência atrás de um load balancer com verificação de saúde real (não apenas "processo vivo", mas "responde corretamente a um prompt de teste").
- Estratégia de atualização sem downtime (rolling update) ao trocar versão de modelo ou de servidor de inferência.
- Plano de degradação: se a capacidade on-premise satura, defina antecipadamente para onde o excedente vai — fila, resposta simplificada, ou fallback para nuvem.
O modelo híbrido
Poucas empresas rodam 100% on-premise ou 100% em nuvem para todos os casos de uso. O padrão mais comum é híbrido: modelos sensíveis a dados ou custo de alto volume ficam on-premise; cargas de pico, modelos de fronteira para tarefas específicas, ou uso experimental vão para APIs de nuvem. Isso exige uma camada de roteamento (gateway) que decida por caso de uso, não por acaso, e que trate as duas rotas com a mesma disciplina de observabilidade e custo.
O que fazer na segunda-feira
- 1.Levante os três números que definem dimensionamento: contexto médio/p95, tamanho de saída, concorrência de pico — para o caso de uso mais crítico.
- 2.Rode um teste A/B de qualidade entre precisão original e quantizada (INT8 ou INT4) usando sua suíte de avaliação, não benchmarks genéricos.
- 3.Verifique se o servidor de inferência atual usa batching contínuo e KV cache paginado; se não, avalie migração para vLLM, TGI ou equivalente.
- 4.Defina SLOs de latência separados por tipo de interação e configure filas/prioridades de acordo.
- 5.Documente o plano de degradação para picos de carga antes que ele seja testado em produção sem aviso.
Leitura complementar
Trilha executiva:
- Nuvem, nuvem privada ou on-premise: onde sua IA deve rodar — a leitura de negócio deste mesmo tema.