Continuous batching: mais capacidade para servir LLMs

Continuous batching, ou batching contínuo, permite que uma GPU compartilhada receba novas requisições entre as etapas de geração. Assim, a capacidade liberada por tarefas curtas não fica ociosa à espera das mais longas. O artigo de Yu e colegas sobre o Orca, publicado no OSDI em 2022, apresentou essa mudança no escalonamento. Ela pode aumentar o total de tokens por segundo quando há demanda simultânea, mas um servidor mais ocupado não garante respostas mais rápidas para cada usuário.

Em um servidor de modelos compartilhado, a meta que importa é concluir mais trabalho dentro dos limites de tempo de resposta. Um gráfico de throughput sem uma meta de latência não revela quantos clientes o servidor consegue atender com uma boa experiência.

O suporte e os controles dos servidores descritos a seguir foram conferidos na documentação oficial dos desenvolvedores em 25 de outubro de 2026. O exemplo de escalonamento é ilustrativo; não é um benchmark de hardware.

Como funciona o continuous batching

No batching contínuo, o grupo de requisições ativas muda enquanto a geração ainda está em andamento. Uma requisição concluída sai; outra que aguardava pode entrar, desde que o escalonador tenha capacidade. A técnica também aparece com os nomes in-flight batching e iteration-level batching.

Um modelo de linguagem de grande porte, ou LLM, primeiro processa o prompt na fase de prefill e depois gera a continuação na fase de decode. Na decodificação autorregressiva convencional, cada requisição ativa produz seu próximo token, um fragmento de texto, durante uma etapa de geração. O escalonador decide quais requisições participam da próxima etapa. O guia de inferência de LLMs explica essas fases em mais detalhes.

Pense em uma mesa compartilhada de restaurante. Com grupos fixos, a próxima turma só se senta depois que a atual termina. Com ocupação contínua, um novo cliente usa uma cadeira livre enquanto outro ainda está comendo. A mesa é compartilhada, mas cada um continua com sua própria refeição.

A comparação tem um limite: o escalonador da GPU também precisa encaixar o processamento de prompts e a alocação de memória. Uma cadeira livre não significa que qualquer requisição na fila possa entrar imediatamente.

Qual foi a contribuição do artigo sobre o Orca?

O Orca passou a tomar decisões de escalonamento a cada iteração, em vez de esperar uma requisição inteira terminar. O artigo de Gyeong-In Yu e colegas no OSDI 2022 descreve o acionamento do mecanismo de execução para uma única iteração do modelo, seguido de uma reavaliação do lote.

A técnica complementar, chamada selective batching, agrupa operações específicas do modelo e acomoda os diferentes históricos exigidos pela atenção, a operação que relaciona um token ao contexto anterior. Juntas, essas técnicas permitem que o sistema intercale requisições de comprimentos diferentes. O artigo também considera o tamanho do lote e a memória de chave-valor disponível como restrições para o escalonamento. Leia o artigo sobre o Orca.

A mudança acontece no sistema que serve o modelo. Não é necessário treiná-lo para responder a várias pessoas em uma mesma conversa.

Batching estático, dinâmico e contínuo: o que muda?

A pergunta decisiva é quando uma nova requisição pode entrar no trabalho que já está em execução. Aceitar conexões HTTP simultâneas, por si só, não demonstra que a execução do modelo usa batching contínuo.

A documentação de batching do Triton, da NVIDIA, descreve o batching dinâmico convencional, incluindo controles de tamanho do lote e tempo de espera na fila. Essa decisão de escalonamento é diferente de substituir requisições durante a geração de um LLM.

Batching dinâmico no vLLM: confira quando o lote pode mudar

O vLLM, um mecanismo para servir LLMs, documenta o uso de batching contínuo. “Batching dinâmico” é um rótulo menos preciso. A Hugging Face também usa dynamic scheduling e dynamic batching para descrever a substituição de prompts concluídos durante a geração em sua explicação sobre continuous batching. Verifique se o mecanismo admite novas tarefas entre as etapas de geração, em vez de tirar conclusões apenas pelo nome.

Streaming é outra questão. Um servidor pode transmitir tokens ao cliente enquanto mantém fixas as requisições do lote em execução. O benefício discutido aqui é permitir que novas tarefas usem a capacidade liberada pelas requisições concluídas.

Um exemplo de escalonamento

Uma tarefa curta pode liberar capacidade útil enquanto outra, mais longa, continua rodando. Imagine um servidor com duas posições para decode. A requisição A precisa de mais 2 etapas; B, de 4; e C aguarda na fila com 2 etapas de trabalho. Para este exemplo, desconsidere o prefill, o custo do escalonamento e as variações na duração de cada etapa.

Com um lote fixo, A e B começam juntas. A termina, mas C precisa esperar B concluir para que o próximo grupo comece. Com batching contínuo, C pode ocupar a posição de A assim que ela termina e avançar ao lado de B.

O exemplo demonstra uma entrada antecipada, não um ganho de velocidade medido. Um chatbot de suporte que combina respostas curtas com resumos longos tem a mesma oportunidade de escalonamento; o ganho real depende das requisições, do hardware e da configuração do servidor.

Por que o throughput aumenta e onde o KV cache impõe limites

O batching aproveita a mesma movimentação de pesos do modelo para realizar mais trabalho útil. Os pesos são os parâmetros numéricos aprendidos pelo modelo e usados para calcular uma resposta. Várias requisições ao mesmo modelo podem compartilhar a movimentação desses pesos pela memória da GPU, aproveitando melhor a capacidade de processamento disponível. O escalonamento contínuo ajuda a manter esse lote útil à medida que as requisições terminam. A NVIDIA explica a relação entre batching, movimentação de memória e utilização da GPU.

A GPU pode continuar ocupada mesmo com um lote ineficiente. O que importa é quanto trabalho útil para as requisições essa atividade entrega, não se o gráfico de utilização está no máximo.

Cada requisição ativa, porém, também precisa de memória de trabalho. Seu KV cache, abreviação de key-value cache, armazena o estado de atenção dos tokens já processados. Mais requisições simultâneas e históricos mais longos aumentam a pressão sobre essa memória. A explicação sobre KV cache mostra a diferença entre esse estado e o cache reutilizável de prompts.

PagedAttention aproveita melhor a memória

O batching contínuo decide o que roda; o PagedAttention muda a forma de armazenar o estado de atenção. O artigo de Woosuk Kwon e colegas sobre o vLLM, de 2023, descreve a divisão do estado KV em blocos de tamanho fixo que não precisam ocupar posições contíguas na memória física. Um mapa de blocos preserva a ordem lógica da sequência.

Isso reduz o desperdício de memória causado pela fragmentação e pela duplicação desnecessária. Uma organização mais eficiente permite acomodar os conjuntos de trabalho de mais requisições, dando ao escalonador mais trabalho útil para escolher. O artigo descreve explicitamente essa abordagem de gerenciamento de memória como complementar ao escalonamento do Orca.

O limite continua sendo a capacidade física. Organizar melhor a memória não faz caber um número ilimitado de conversas longas. No vLLM, a falta de espaço para KV pode causar preempção: uma requisição é pausada e seu estado é recalculado depois, o que pode aumentar o tempo até a conclusão. A documentação de otimização explica esse comportamento.

O que acontece com a latência?

O batching contínuo pode reduzir a espera na fila, mas lotes maiores ou mais disputados podem piorar a experiência depois que a requisição entra. Acompanhe cada etapa separadamente:

• Tempo até o primeiro token, ou TTFT: quanto o usuário espera até a resposta começar.
• Latência entre tokens: os intervalos entre tokens depois que o streaming começa.
• Latência de ponta a ponta: quanto tempo a requisição inteira leva.

Uma nova requisição pode deixar de esperar que todo um lote fixo termine. Por outro lado, processar um prompt novo e extenso pode disputar recursos com requisições que já estão em decode. O chunked prefill divide o processamento do prompt em partes menores, permitindo que o escalonador o intercale com a geração em andamento.

O vLLM, por exemplo, documenta uma escolha entre prioridades no orçamento de tokens por iteração: valores menores podem preservar a latência entre tokens, enquanto valores maiores permitem processar mais prefill e melhorar o TTFT. Por isso, esse orçamento deve ser definido conforme a carga de trabalho, e não simplesmente levado ao máximo. Orientações de ajuste do vLLM.

Batching contínuo em LLMs com pouca e muita demanda

Com pouca demanda, pode haver pouco para agrupar; sob sobrecarga persistente, a fila continua existindo. Um desenvolvedor que envia uma requisição por vez não deve esperar o mesmo benefício de um serviço voltado a clientes com requisições simultâneas. No outro extremo, admitir mais trabalho do que a GPU consegue sustentar acaba aumentando os tempos de espera.

Em uma aplicação interativa, acompanhe o p95, o percentil 95, além da mediana. Uma boa média pode esconder uma minoria de sessões lentas. Defina o TTFT e os intervalos de streaming aceitáveis com base na experiência do produto; depois, meça a capacidade dentro desses limites.

Servidores de LLM com batching contínuo: suporte e limites

Os quatro servidores abaixo documentam suporte a continuous batching ou in-flight batching. Essa capacidade em comum não torna equivalentes seus escalonadores, orçamentos de memória ou modelos compatíveis.

Batching contínuo no vLLM

O vLLM combina escalonamento contínuo de requisições com gerenciamento paginado do KV cache. A documentação lista os dois recursos explicitamente. Para quem opera o servidor, os controles úteis são o máximo de sequências e a quantidade de tokens escalonados por iteração, não apenas um número desejado de conexões simultâneas à API.

O limite é a pressão sobre a memória: aumentar o número de requisições simultâneas pode causar preempção e recálculo, em vez de ampliar a capacidade utilizável. Ajuste os controles conforme o perfil do tráfego e a meta de latência, mantendo o modelo e o hardware fixos ao comparar configurações.

SGLang

O SGLang oferece batching contínuo e controles explícitos de admissão. A documentação dos argumentos do servidor define --max-running-requests, --chunked-prefill-size e o orçamento de memória para os pesos do modelo e o pool de KV, controlado por --mem-fraction-static.

Cada controle responde a uma pergunta: quantas requisições podem rodar, quanto processamento de prompt entra em cada bloco e como a memória é alocada. Aumentar o limite de requisições não elimina os demais limites. Para escolher o mecanismo de forma mais ampla, consulte a comparação entre vLLM e SGLang; depois, avalie o modelo exato e o perfil de requisições que você pretende atender.

NVIDIA TensorRT-LLM

O NVIDIA TensorRT-LLM trata explicitamente in-flight batching, continuous batching e iteration-level batching como equivalentes. A documentação do recurso descreve o processamento conjunto de sequências nas fases de contexto e de geração, usando tensores de entrada empacotados na implementação documentada.

O limite de requisições e o orçamento de tokens são restrições distintas. A documentação do escalonador PyTorch também separa a reserva de recursos, incluindo a capacidade de KV, da escolha de quais requisições que cabem nesses recursos serão executadas. Um escalonador in-flight não pode admitir trabalho que ultrapasse essas verificações de capacidade.

Hugging Face Text Generation Inference

O Hugging Face Text Generation Inference oferece batching contínuo, mas seu status de manutenção muda a decisão para uma nova implantação. Segundo a documentação, o projeto agora aceita pequenas correções, melhorias na documentação e manutenção pontual, e recomenda mecanismos como vLLM e SGLang para uso daqui em diante.

Uma instalação existente do TGI não perde o batching por causa desse status. Para uma nova infraestrutura de serviço de modelos, eu começaria avaliando alternativas em desenvolvimento ativo. Se uma implantação consolidada atende às metas, planeje a migração a partir de uma necessidade concreta de suporte ou de recursos.

Onde as promessas passam do ponto

O batching contínuo não oferece um multiplicador de velocidade que se aplique a qualquer cenário. Os artigos sobre Orca e PagedAttention avaliam sistemas e cargas de trabalho específicos. Seus resultados não isolam um ganho universal que possa ser aplicado a qualquer modelo, GPU ou endpoint de um provedor.

A técnica também não elimina a espera. Uma requisição na fila ainda precisa de processamento do prompt, memória e sua vez de executar conforme a política do escalonador. Prompts longos, alta demanda simultânea e pressão sobre o cache continuam sendo limites.

Por fim, uma taxa agregada maior de tokens não prova que um produto de chat melhorou. Se os usuários esperam mais pelo primeiro token ou enfrentam pausas que atrapalham o streaming, o throughput adicional do servidor pode ficar fora da faixa de operação aceitável para o produto.

O que mudar na prática a partir de agora

Quem desenvolve deve avaliar o uso de um servidor compartilhado quando as requisições se sobrepõem; quem opera deve ajustar os controles dentro dos limites de latência; quem avalia provedores deve pedir medições com disputa por recursos. Uma ferramenta individual com requisições ocasionais pode esperar. Já um serviço com clientes na fila e respostas de extensões variadas tem um motivo concreto para agir. A comparação entre Ollama e vLLM aborda a transição do uso local para um servidor compartilhado.

1. 1

   Defina a experiência antes de aumentar a simultaneidade

   Registre os limites aceitáveis de tempo até o primeiro token, intervalos de streaming e tempo de conclusão para o fluxo de trabalho real. Um resumidor que roda em segundo plano e um assistente de suporte ao vivo precisam de critérios de aceitação diferentes.

2. 2

   Reproduza um conjunto representativo de requisições

   Mantenha comparáveis o modelo, o hardware, os comprimentos dos prompts, os limites de saída e as condições de cache. Inclua respostas curtas, prompts longos e gerações longas. Preserve padrões realistas de chegada das requisições para que uma execução tranquila com um único usuário não represente um serviço movimentado.

3. 3

   Registre o throughput junto com a fila e a latência

   Meça os tokens de saída agregados por segundo, as requisições concluídas, as que estão na fila, as falhas, o TTFT e os intervalos entre tokens. O vLLM disponibiliza métricas correspondentes, incluindo vllm:num_requests_waiting, vllm:time_to_first_token_seconds e vllm:inter_token_latency_seconds, em sua documentação de métricas de produção.

4. 4

   Fique com a maior carga que ainda atende às metas

   Altere um controle de escalonamento ou memória por vez. Pare de aumentar o número de requisições simultâneas quando os limites de latência forem ultrapassados ou a pressão sobre a memória causar recálculos repetidos. Peça ao provedor a mesma visão de throughput e latência com o nível de simultaneidade esperado, além de confirmar se a capacidade é compartilhada ou reservada.

O resultado deve ser um limite operacional medido: a carga que seu endpoint consegue sustentar sem comprometer a experiência pretendida para o usuário. É isso que transforma um recurso de batching em uma decisão de implantação.

Para receber explicações práticas sobre infraestrutura de IA e o que mudar na sua stack, assine a newsletter.