Quando falamos de inferência de modelos de linguagem, o gargalo não está apenas no modelo — está no agendamento inteligente do trabalho na GPU. É aqui que o batching entra como peça fundamental. Mas nem todo batching é igual: entender a diferença entre static batching e continuous batching pode ser a diferença entre uma aplicação que engasga sob carga e uma que escala com elegância.
Por que o batching é tão importante em LLMs?
GPUs são projetadas para operações massivamente paralelas. Processar uma requisição por vez subutiliza o hardware — a GPU carrega os pesos do modelo, executa as multiplicações de matriz e libera os recursos, mas passa a maior parte do tempo ociosa. Ao agrupar (fazer batch) de múltiplas requisições, os mesmos pesos são reutilizados para várias entradas simultaneamente, amortizando o custo de memória e computação.
Mas inferência de LLMs não é como classificação de imagens. Cada requisição tem duas fases distintas: prefill (processamento do prompt, compute-bound e altamente paralelizável) e decode (geração token a token, memory-bound e sequencial). O desafio está em orquestrar essas fases para manter a GPU ocupada o tempo todo.
Static Batching: o ônibus que espera todo mundo
No static batching, as requisições são agrupadas em lotes fixos. Todas passam pelo prefill e decode juntas, e o lote inteiro precisa esperar a requisição mais lenta terminar antes de liberar a GPU para o próximo grupo.
Isso cria problemas sérios em produção:
- Slots ociosos: quando uma requisição termina, seu slot na GPU fica parado esperando as outras
- Head-of-line blocking: novas requisições ficam na fila até o lote inteiro completar
- Penalidade de comprimento variável: saídas curtas ficam presas atrás de saídas longas
- Latência inflada: o TTFT (Time to First Token) sobe porque cada lote espera encher antes de começar
O static batching funciona razoavelmente bem com tráfego previsível e uniforme — o que raramente acontece em produção com LLMs, onde prompts e saídas têm comprimentos radicalmente diferentes.
Continuous Batching: a GPU nunca descansa
O continuous batching resolve esses problemas com iteration-level scheduling: em vez de travar um lote até que todos terminem, o scheduler atualiza o lote ativo a cada passo de geração. Assim que uma requisição produz seu último token, ela sai do lote e é imediatamente substituída por outra da fila de espera.
Os ganhos são expressivos: 2× a 4× mais throughput em cargas de alta concorrência, latência p95/p99 mais apertada, e GPU utilization consistentemente elevada. O segredo está em manter três filas — waiting (ainda não iniciaram prefill), running (decodificando ativamente) e swapped (KV cache movido para memória do host) — e rebalanceá-las a cada forward pass.
vLLM e PagedAttention: o estado da arte
O vLLM se destaca entre os engines de inferência por combinar continuous batching com PagedAttention, uma técnica de gerenciamento de memória inspirada em paginação de sistemas operacionais. Em vez de alocar um bloco contíguo de memória KV cache por requisição (desperdiçando 60-80% do espaço reservado), o PagedAttention usa alocação baseada em blocos não contíguos, virtualmente eliminando a fragmentação.
O resultado prático: o vLLM consegue manter mais requisições ativas simultaneamente com menos memória, entregando 2-4× mais throughput que sistemas legados como FasterTransformer e Orca, com latência comparável.
TGI vs vLLM: qual escolher?
O Hugging Face TGI (Text Generation Inference) foi pioneiro em muitas funcionalidades de serving e ainda é relevante para times já integrados ao ecossistema Hugging Face. No entanto, a própria Hugging Face agora recomenda vLLM ou SGLang para novos deployments, e o TGI entrou em modo de manutenção.
Para quem está começando um projeto do zero, o vLLM é a escolha mais sólida: continuous batching nativo, PagedAttention, chunked prefill, prefix caching, suporte a quantização e uma comunidade extremamente ativa.
Quando cada abordagem faz sentido
O static batching ainda pode ser adequado para cenários offline, como processamento em lote de datasets onde todas as entradas têm tamanho similar e não há requisitos de latência. Mas para serving em produção — APIs, chatbots, aplicações interativas — o continuous batching é indispensável.
A lição central: em inferência de LLMs, performance não é só sobre o modelo. É sobre quão inteligentemente o servidor agenda o trabalho.
Descubra mais sobre noticiAI
Assine para receber nossas notícias mais recentes por e-mail.
