A estratégia de batching determina o SLO
No que diz respeito à arquitetura de serving de LLMs, o que mais impacta diretamente o SLO é como o batching é estruturado. Não importa quão poderosa seja a GPU, satisfazer simultaneamente as três métricas — TTFT (Time To First Token), ITL (Inter-Token Latency) e throughput agregado — exige projetar a estratégia de batching levando em conta o padrão de chegada de requisições, a distribuição do comprimento de entrada, a distribuição do comprimento de saída e os padrões de ocupação do KV cache. Neste artigo, organizamos as características das cinco técnicas em uso real em 2026 — continuous batching, chunked prefill, PagedAttention, RadixAttention e sorted batching —, seu impacto no SLO e sua combinação com prompt cache.
Continuous Batching
Continuous batching (também chamado de iteration-level scheduling) é uma abordagem que reconstrói a composição do batch a cada step do decode. Enquanto o static batching tradicional "não aceita novas requisições até que todas as requisições do mesmo batch sejam concluídas", o continuous batching "remove imediatamente as requisições concluídas e insere novas no slot liberado". Como resultado, a utilização da GPU é menos afetada pela variação no comprimento das requisições, e o throughput efetivo em cargas de trabalho de chat com grande variância no comprimento de saída melhora de 2 a 4 vezes.
No entanto, apenas o continuous batching deixa um problema: a colisão entre prefill e decode no mesmo step. O prefill de uma requisição com prompt longo (mais de 8K tokens) pode levar centenas de milissegundos ou mais, paralisando o decode das outras requisições durante esse tempo. Esse prefill stall cria a cauda longa na distribuição de ITL.
Chunked Prefill
O chunked prefill divide prompts longos em pequenos chunks (tipicamente 512 a 2.048 tokens) e processa "1 chunk de prefill + decode das demais requisições" simultaneamente em cada iteração. Com isso, a carga de prefill é distribuída por múltiplos steps, e o jitter de ITL reduz drasticamente. É uma funcionalidade indispensável em sistemas que precisam manter o ITL p99 abaixo de 50ms, com suporte nativo no vLLM, SGLang e TensorRT-LLM.
Se o tamanho do chunk for muito pequeno, o overhead de kernel launch domina; se for muito grande, o decode é paralisado. Como regra prática da KGA: em H200, de 4.096 a 8.192 tokens é um ponto de partida razoável; em B200, de 8.192 a 16.384 tokens. Um efeito colateral é que misturar prefill compute-bound com decode memory-bound faz uso simultâneo de compute e memória da GPU, resultando em MFU maior que o processamento isolado.
PagedAttention
PagedAttention é uma abordagem que gerencia o KV cache dividido em páginas de tamanho fixo (tipicamente 16 tokens), sendo o núcleo do vLLM. Reduz drasticamente a fragmentação de memória e permite capacidade efetiva de 2 a 4 vezes com o mesmo uso de memória física. Em 2026, além do vLLM, a maioria do TensorRT-LLM, SGLang e DeepSpeed-Inference também adota mecanismos de paging similares.
O PagedAttention também é importante como base para o "compartilhamento de prefixo": múltiplas requisições usando o mesmo system prompt referem a mesma página, mantendo apenas um KV físico. No entanto, o prefix caching do vLLM original opera em "unidades de prefixo de correspondência exata", e para otimizações de correspondência parcial ou entre tenants, o RadixAttention leva vantagem.
RadixAttention
O RadixAttention, proposto pelo SGLang, gerencia o KV cache em estrutura de radix tree, permitindo compartilhar "fragmentos arbitrários de prefixo". Estruturas compartilhadas aninhadas como system prompt, few-shot examples, definições de tools e context comum de tenants são detectadas automaticamente e o KV físico é consolidado em um único lugar.
Em benchmarks medidos, para chat multi-turn com system prompt compartilhado (média de 8 turnos, 256 sessões simultâneas), o RadixAttention reduz o custo de prefill em 40 a 60% e melhora o TTFT mediano em 30 a 45% em comparação ao prefix caching do vLLM. Em cargas de trabalho de agentes com definições longas de tools, pode haver diferença de 2 a 3 vezes.
Por outro lado, o design da eviction policy é difícil, e aplicar LRU de forma simples faz o TTFT disparar quando tenants quentes e frios se alternam. Na KGA, utilizamos weighted LRU com prioridade por tenant ou hard partitioning com alocação fixa de partições de tenant conforme a situação.
Sorted Batching
Sorted batching é a estratégia de "agrupar no mesmo batch requisições com comprimento de entrada ou comprimento restante de saída similares". O continuous batching ingênuo gera ineficiências de padding e padding mask quando há mistura de comprimentos longos e curtos, e o sorted batching atenua isso. Em 2026, em vez de estar implementado de série nos frameworks de serving, tende a ser uma funcionalidade implementada pelo roteador/scheduler da camada superior.
O design mais simples é separar endpoints dedicados para respostas curtas (classificação, reranking, summarização curta) e endpoints para respostas longas (geração de relatório, geração longa de código), aplicando sorted batching em cada um. Isso resulta em 20 a 35% de melhora no throughput efetivo medido.
Resumo do impacto no SLO
- TTFT: chunked prefill e prefix caching/RadixAttention são dominantes. Com esses dois, o p50 TTFT fica em torno de 100ms e o p99 abaixo de 500ms.
- ITL: continuous batching e chunked prefill são eficazes. Sem chunked prefill, o ITL p99 facilmente ultrapassa 200ms.
- Throughput: maximizado com a tríade — eficiência de memória via PagedAttention, slots compactados com continuous batching e eliminação de desperdício de prefill com RadixAttention.
- Cauda p99: protegida por sorted batching e admission control. Uma admission policy que coloca requisições de baixa prioridade em fila é necessária durante picos de QPS.
Estratégia de Prompt Cache
Quatro eixos ao projetar prompt cache em produção:
Compartilhamento de system prompt. O system prompt comum a todos os tenants deve ser pré-aquecido na inicialização e mantido residente. Com RadixAttention, a prática padrão é enviar uma requisição de `warmup` no script de inicialização para carregá-lo na KV tree.
Particionamento de tenant. Em modo multi-tenant SaaS com tenants misturados, pode haver problemas de segurança/conformidade se o context do tenant A se misturar com o do tenant B. Como RadixAttention não oferece isolamento criptográfico, em domínios rigorosos como finanças e saúde é necessário isolar por processo (ou grupo de GPUs) por tenant, limitando a camada compartilhada apenas ao "system prompt não confidencial".
TTL e eviction. Para agentes de chat com sessões longas, funciona bem um design que armazena os KVs intermediários da conversa multi-turn em cache temporário e os evict após N minutos de interrupção. Em casos de clientes da KGA, definimos TTL de 15 a 30 minutos para equilibrar pressão de memória e custo de re-prefill.
Deduplicação cross-request. Em sistemas de agentes, é comum passar a mesma resposta de tool para múltiplas chamadas de LLM. Fazer dedup dessas respostas por fingerprint e carregá-las na KV tree apenas uma vez pode reduzir o TTFT em mais de 30%.
Exemplo de configuração: vLLM + chunked prefill + prefix caching
```python llm = LLM( model="Qwen/Qwen3-72B-Instruct", tensor_parallel_size=8, kv_cache_dtype="fp8", enable_prefix_caching=True, enable_chunked_prefill=True, max_num_batched_tokens=8192, max_num_seqs=256, gpu_memory_utilization=0.92, block_size=16, preemption_mode="recompute", ) ```
Aumentar demais `max_num_seqs` causa swap frequente por pressão de memória. Na prática, calcule de trás para frente a partir do QPS estimado e do p99 do comprimento de saída. A regra de experiência da KGA é que QPS_peak × p99_output_length / expected_decode_rate é aproximadamente o limite superior.
Conclusão
Em estratégia de batching, a resposta certa de 2026 não é "escolher uma das cinco técnicas individualmente", mas sim "colocar todas e ajustar os parâmetros conforme o SLO". Para proteger TTFT: chunked prefill e RadixAttention. Para proteger ITL: chunked prefill e sorted batching. Para aumentar throughput: continuous batching e PagedAttention. Para proteger o isolamento de tenant: hard partitioning e tenant-aware eviction. Projetando a arquitetura com esses quatro eixos, é plenamente possível alcançar um SLO de throughput agregado de 2.500 tok/s e TTFT p99 abaixo de 400ms mesmo com modelo de 70B em configuração de 8 GPUs H200 SXM.