As mesmas 16 GPUs, o dobro de usuários: roteamento com reconhecimento de inferência para clusters de LLM

Resumo: As mesmas 16 GPUs, o dobro de usuários. Sua conta de GPU permanece estável enquanto a capacidade dobra. Um cluster que lidava com 20 usuários simultâneos agora lida com 200. O agendador de inferência do llm-d possibilita esses números. Ele foi criado para rotear todas as solicitações em um cluster distribuído com visibilidade de cada nó, fila e cache. As solicitações aos Large Language Model (LLM) são lentas, não uniformes e caras. O agendador de inferência foi criado exatamente para isso.

O padrão que funciona em qualquer outro ambiente

Cada hora de GPU tem um preço. A questão é quanto trabalho você está realizando com elas.

O Kubernetes é a forma como os serviços distribuídos são criados, implantados e operados em escala. Em uma configuração padrão do Kubernetes, você define uma implantação, define uma contagem de réplicas e um serviço do Kubernetes oferece uma porta de entrada com balanceamento de carga round robin em todos os seus pods. Para APIs REST, serviços web e microsserviços, esse padrão é essencialmente perfeito. As solicitações são rápidas e uniformes, e cada uma leva aproximadamente o mesmo tempo de menos de um segundo para ser concluída.

Mas, no momento em que você começa a disponibilizar grandes modelos generativos em escala, como Llama, Mistral ou modelos open source de classe GPT, essa suposição deixa de ser válida.

Onde o round robin atinge seus limites

As solicitações de inferência de LLM não são como solicitações HTTP normais, e as diferenças são o que interrompem o balanceamento de carga padrão:

• Variabilidade de tempo: uma solicitação pode levar menos de um segundo ou mais de um minuto, dependendo do que for solicitado ao modelo. O round robin distribui solicitações, não trabalho. Se uma réplica recebe uma sequência de solicitações longas e caras, ela se torna um gargalo enquanto a outra fica ociosa.
• Variabilidade de formato: prompts curtos com respostas longas e geradas se comportam de maneira diferente de prompts longos com respostas curtas. O perfil de computação, a pressão de memória e o tempo de conclusão são todos diferentes.
• Variabilidade de fase: toda solicitação de inferência tem duas fases internas: prefill, que processa todo o prompt de entrada em uma varredura paralela, e decode, que gera um token de resposta por vez. Essas duas fases têm perfis de recursos, durações e sensibilidade à carga diferentes. Um sistema que não consegue diferenciá-los não pode otimizar nenhum dos dois.

O round robin foi criado para cargas de trabalho onde as solicitações são de curta duração, uniformes e baratas. Um agendador que não consegue ver o conteúdo da solicitação as trata da mesma forma.

Figura 1: O round robin distribui a contagem de solicitações, não o trabalho. As mesmas cinco solicitações (com tamanhos e custos de computação variados) chegam de maneira desigual aos pods. Um pod fica sobrecarregado com duas solicitações longas, enquanto outro fica praticamente ocioso. O roteamento com reconhecimento de inferência identifica formato, tamanho e carga, equilibrando o trabalho real.

Um cache hit no pod errado é um cache miss

O vLLM é o mecanismo de inferência padrão para LLMs. Todos os principais aceleradores de hardware são otimizados para ele, e novos modelos são lançados com suporte vLLM Day 0. Ele lida excepcionalmente bem com a mecânica de inferência em um único nó.

O vLLM introduziu o prefix caching para lidar com uma das partes mais caras da inferência: reprocessar os mesmos prefixos de prompt repetidamente. Quando várias solicitações compartilham um prefixo comum (um prompt do sistema, um documento ou um histórico de conversação), o vLLM pode armazenar em cache o estado Key-Value (KV) do primeiro cálculo e reutilizá-lo em solicitações subsequentes. Em um cache hit, a etapa de prefill é totalmente ignorada: o time to first token (TTFT) diminui proporcionalmente à parte do prompt que já estava no cache, mas apenas se a solicitação chegar à réplica específica que contém esse cache.

Uma solicitação que seria quase gratuita em uma réplica é roteada para outra onde começa do zero. A otimização existe, mas o roteamento round robin a ignora.

Com pouco tráfego, isso é uma oportunidade perdida. Em escala, você paga o dobro pela mesma computação.

Leve do nó ao cluster

Cada pod enxerga apenas a si mesmo, embora cada pod do vLLM lide bem com sua parcela de solicitações, gerenciando a memória, criando lotes com eficiência e fornecendo tokens na velocidade permitida pelo hardware. Ele não sabe o que seus pares estão processando, quais réplicas estão sob carga ou onde o estado do prefix cache reside no cluster. 

O problema de coordenação está acima do nó, e o Kubernetes é a plataforma preferida para infraestrutura distribuída e orquestração em escala. Por isso, o llm-d foi criado para ser nativo do Kubernetes desde o início para resolver exatamente esse problema. 

O Inference Gateway (IGW) é como isso aparece na prática: uma camada de tráfego baseada no Envoy e na Kubernetes Gateway API que entende cargas de trabalho de LLM, não apenas HTTP. Por trás dele, o Inference Scheduler monitora cada pod no InferencePool em tempo real (profundidade da fila, estado do cache KV, carga) e encaminha cada solicitação para a instância certa, em vez de para a próxima na rotação.

Figura 2: O Inference Gateway (IGW) recebe cada solicitação e consulta o Inference Scheduler (EPP) via ext proc. O agendador pontua todos os pods no InferencePool com base em dois sinais em tempo real (estado do cache KV e carga), retorna o endpoint selecionado para o IGW e o IGW encaminha a solicitação. Em um cache hit, a parte do prefill armazenada em cache é reutilizada e o decode começa imediatamente. Em um cache miss, o prefill é executado integralmente.

Agendamento de inferência em escala: mesmo hardware, o dobro de capacidade

O agendador de inferência (Inference Scheduler do llm-d ou EPP) é o que torna a coordenação no nível do cluster concreta. Em vez de tratar todos os pods como intercambiáveis, ele encaminha cada solicitação com base em sinais em tempo real: Estado do cache KV, profundidade da fila e carga. Toda solicitação vai para a instância certa, sempre.

Os resultados do benchmark do llm-d v0.5 mostram o que isso entrega na prática.

Agendamento de inferência (Qwen3-32B, 8 pods de vLLM, 16 NVIDIA H100):

• Taxa de transferência até 109% maior em comparação com um serviço básico do Kubernetes. As mesmas 16 GPUs atendem a aproximadamente o dobro de usuários simultâneos em seu objetivo de nível de serviço (SLO).
• Redução de até 99% no time to first token (TTFT) sob carga equivalente. O benchmark mostra o TTFT de linha de base subindo para penosos ~80 segundos sob alta carga. O agendamento inteligente o mantém em ~150 ms. Essa é a diferença entre um produto que parece problemático e um que parece instantâneo.
  • O benchmark sustenta ~11.000 tokens de saída/s em 16 GPUs. Considerando cerca de 1.000 tokens por resposta e cerca de três solicitações por minuto por usuário ativo, isso se traduz em aproximadamente 200 usuários simultâneos no SLO, em um hardware no qual o serviço básico do Kubernetes deixa de ser utilizável após 20 usuários.

Cada resultado tem controle de versão e está vinculado a um guia reproduzível específico.

Figura 3: Agendamento de inferência do llm-d em comparação com o Kubernetes básico — TTFT médio e taxa de transferência total em relação a QPS. Topologia: 8× vLLM pods, 16× NVIDIA H100 (TP=2). Carga de trabalho: prefixo compartilhado sintético, 150 grupos × cinco prompts, comprimento de sistema/pergunta/saída de 6k/1,2k/1k. Resultados: P50 TTFT 136–157 ms, 4,5–11k tok/s de saída, taxa de transferência até 109% maior e TTFT 99% menor em comparação com a linha de base. Fonte: llm-d v0.5.

O vLLM otimiza o nó, o llm-d otimiza o cluster

O vLLM e o llm-d foram projetados para trabalhar juntos, e a diferença de desempenho entre executar um sem o outro é mensurável: O dobro de usuários no mesmo hardware, latência 99% melhor sob carga e um cluster que se mantém com 250 usuários simultâneos tão bem quanto com 20.

Se você estiver executando duas ou mais réplicas, o agendamento de inferência inteligente se aplica à sua carga de trabalho hoje. A diferença de desempenho não é incremental: é a diferença entre um cluster que escala e um que apresenta dificuldades. 

É aqui que a inferência distribuída começa.

Experimente a escala por conta própria

Os guias do llm-d e as configurações de benchmark por trás de cada número nesta postagem do blog são públicos e reproduzíveis. Um bom ponto de partida é o lançamento do llm-d v0.5.

O Red Hat AI Enterprise inclui uma versão do llm-d com suporte empresarial e uma avaliação gratuita de 60 dias do Red Hat AI Enterprise. Este é um bom lugar para começar se você quiser executar isso em sua própria infraestrutura.

Se você quiser ver o agendador em ação primeiro, a Introdução à demonstração interativa do llm-d explica como as solicitações são roteadas.

Nota do autor: Dados de benchmark extraídos do lançamento do llm-d v0.5. Todos os resultados são reproduzíveis utilizando configurações com controle de versão publicadas nos guias do llm-d.