Latência p99 do vLLM dispara em produção: como chunked prefill e priority scheduling salvam seu SLA

Por que a latência p99 do vLLM explode em produção — e como o chunked prefill resolve

Se você serve modelos de linguagem em produção com vLLM, já deve ter notado que a latência no percentil 99 (p99) pode ser 10 a 20 vezes maior que a mediana. Um tutorial da DigitalOcean explica por que isso acontece e como as técnicas de chunked prefill e políticas de scheduling resolvem o problema na raiz.

O problema: PagedAttention não é suficiente

O vLLM ficou famoso pelo PagedAttention, que gerencia o cache KV como páginas de memória virtual. Isso resolve o desperdício de memória, mas não resolve o problema de tempo de preenchimento (prefill). Quando um prompt longo chega — digamos, 8.000 tokens de contexto — o modelo precisa processar todos esses tokens de uma vez antes de começar a gerar. Isso cria um “head-of-line blocking”: um request longo bloqueia todos os outros na fila.

O resultado é que, enquanto a latência mediana (p50) fica em centenas de milissegundos, o p99 pode disparar para 5 a 15 segundos. Para aplicações como chatbots, agentes autônomos e APIs, isso é inaceitável.

Chunked prefill: a solução elegante

Em vez de processar o prompt inteiro de uma vez, o chunked prefill divide o prefill em pedaços (chunks) e os intercala com tokens de decodificação de outros requests. Isso transforma um request de prefill de 8.000 tokens em vários mini-prefills que compartilham o GPU com requests em fase de geração.

O trade-off é que o tempo total até o primeiro token (TTFT) aumenta um pouco — afinal, o prefill foi fatiado. Mas a latência p99 e a vazão geral melhoram drasticamente. É a diferença entre “rápido para a maioria, péssimo para alguns” e “consistente para todos”.

Política de scheduling: FCFS vs. priority

O vLLM oferece duas políticas principais de agendamento:

• FCFS (First-Come, First-Served): simples, mas vulnerável ao head-of-line blocking. Um request longo na frente da fila atrasa todos os outros.
• Priority-based: permite definir prioridades por request, garantindo que requests de baixa latência (chat ao vivo) não sejam bloqueados por requests em lote.

Em tráfego real, a DigitalOcean mostra que o chunked prefill combinado com priority scheduling reduz o p99 de 8-12 segundos para 1-2 segundos, mantendo o p50 abaixo de 300ms.

Como diagnosticar seu gargalo

O tutorial sugere três métricas para identificar o que está limitando seu sistema:

1. GPU utilization: se abaixo de 90%, você tem um gargalo de scheduling, não de computação.
2. KV cache usage: se próximo de 100%, você está limitado por memória — reduza o max_model_len ou use quantização.
3. Queue time vs. inference time: se o tempo de fila domina o p99, o chunked prefill é a solução certa. Se o tempo de inferência domina, você precisa de mais GPUs ou um modelo menor.

Por que isso importa para times brasileiros

Com a popularização de modelos open-source como Llama e Mistral rodando em infraestrutura local, mais times de engenharia no Brasil estão colocando vLLM em produção. O chunked prefill já está disponível no vLLM via flag --enable-chunked-prefill e é suportado em GPUs NVIDIA a partir da série A100. Para times que servem chatbots, agentes ou APIs de embeddings, é uma otimização de alto impacto com esforço mínimo de configuração — literalmente uma flag.