Deploy de modelos: da GPU certa ao autoscaling que não quebra o orçamento

Treinar ou escolher um modelo é a parte que recebe atenção. Colocá-lo em produção de forma que atenda tráfego real, dentro do orçamento de GPU, é a parte que decide se o projeto sobrevive ao primeiro mês. As ferramentas de deploy de modelo existem justamente para essa distância entre "funciona no notebook" e "aguenta produção".

Ollama: prototipagem e cargas pequenas

Ollama simplifica rodar modelos localmente ou em um único servidor, com setup mínimo. É a ferramenta certa para prototipagem, ambientes internos e cargas de trabalho que não exigem alta concorrência. Não é a escolha para servir milhares de requisições simultâneas — não foi desenhado para isso.

vLLM: o padrão para servir em escala

vLLM resolve o problema central de servir LLMs com eficiência: PagedAttention gerencia a memória do KV cache de forma que múltiplas requisições compartilham GPU sem desperdício, e batching contínuo agrupa requisições dinamicamente em vez de esperar um lote fixo se formar. Para a maioria dos times que precisam servir modelos abertos em produção, é o ponto de partida padrão hoje.

TensorRT-LLM: performance máxima, mais fricção de setup

Quando o volume justifica, TensorRT-LLM da NVIDIA compila o modelo para execução otimizada na GPU específica, extraindo latência menor que soluções mais genéricas. O custo é setup mais complexo e menos flexibilidade para trocar de modelo rapidamente — é uma escolha de quem já validou o modelo e quer espremer performance.

Llama.cpp: inferência sem GPU dedicada

Para cenários onde GPU não é viável — edge, on-premise limitado, ou custo proibitivo — Llama.cpp roda modelos quantizados em CPU com performance surpreendente para o hardware disponível. Não compete com vLLM em throughput, mas resolve casos que vLLM nem endereça.

Triton Inference Server: quando o backend de modelo precisa ser plataforma

Triton entra quando a organização serve múltiplos modelos, de múltiplos frameworks, com necessidades diferentes de batching e hardware. Ele abstrai essa complexidade atrás de uma interface comum — é infraestrutura de plataforma, não a escolha para um time servindo um único modelo.

GPUs e CUDA: a decisão que trava tudo o resto

A GPU errada — memória insuficiente para o modelo e o batch desejado, ou geração antiga sem suporte a otimizações recentes de CUDA — limita todas as escolhas de software acima. Dimensionar memória de GPU para o modelo, o KV cache e a concorrência esperada é o primeiro cálculo, antes de escolher framework de serving.

Batch Inference, Autoscaling e Load Balancer

Batch inference processa grandes volumes de forma assíncrona, sem exigir GPU sempre ligada — ideal para cargas não interativas. Para tráfego interativo, autoscaling baseado em métricas de fila e latência evita pagar por GPU ociosa e evita fila crescendo sem controle. Load balancer na frente de múltiplas instâncias de modelo, com roteamento por saúde e carga, fecha o ciclo de alta disponibilidade.

O ponto de partida

Antes de escolher framework de serving, vale dimensionar a carga esperada e o orçamento de GPU disponível. vLLM cobre a maioria dos casos de produção; TensorRT-LLM e Triton entram quando o volume e a diversidade de modelos justificam a complexidade adicional. É a infraestrutura que transforma um modelo validado em um serviço confiável.