SageMaker reduz latência de LLMs em até 77% com roteamento ciente de prefixo

Quando você constrói uma aplicação sobre um LLM, o prompt costuma ter duas partes: um bloco fixo que monta o contexto (instruções, documentos de referência, histórico) e uma parte variável com a entrada real do usuário. Num bot de atendimento, as instruções no topo podem ter 3.000 tokens; a pergunta do cliente, 50. Isso significa que, em centenas ou milhares de requisições, o modelo processa o mesmo começo de 3.000 tokens repetidamente.

Frameworks como vLLM e TensorRT-LLM resolvem parte disso com prefix caching: reaproveitam os pares chave-valor (KV) já calculados para prefixos conhecidos. O problema aparece quando você escala além de uma única instância — as requisições se espalham pela frota e cada máquina acaba recalculando o prefixo do zero. O roteamento ciente de prefixo que o Amazon SageMaker Inference acaba de lançar ataca exatamente essa lacuna.

Como funciona

A nova estratégia de roteamento olha o início de cada requisição e envia consistentemente requisições com o mesmo começo para a mesma instância. Assim, o cache KV daquela máquina realmente se acumula e é reutilizado — sem que você precise marcar requisições ou gerenciar afinidade manualmente.

Há duas salvaguardas embutidas. A proteção contra sobrecarga desvia a requisição para uma instância menos ocupada quando o alvo está no limite de concorrência configurado. E o comportamento durante escalonamento é estável: ao adicionar ou remover instâncias, a maior parte do tráfego continua indo para a mesma máquina de antes, evitando invalidar os caches a cada mudança.

Os números

Nos benchmarks da AWS com Llama 3.1 70B em 7 instâncias ml.p5.48xlarge com vLLM, comparando com o roteamento aleatório padrão:

• P50 TTFT reduzido em até 77% em cargas de contexto longo (prefixos compartilhados de 8.000 tokens).
• Throughput aumentado em até 16%.
• Taxa de hit do cache KV saltou de ~25% para mais de 80%.

O overhead do roteamento em si é de 1,3 a 1,9 milissegundos por requisição — irrelevante frente ao TTFT de 63 a 280 ms observado nos testes. E a distribuição de tráfego permaneceu equilibrada entre as 7 instâncias, sem pontos quentes. O benefício é proporcional ao tamanho do prefixo: quanto maior o trecho compartilhado, maior a economia.

Onde faz mais diferença

Os casos de uso que mais se beneficiam são: aplicações RAG (vários usuários perguntando sobre o mesmo documento), conversas multi-turno (o histórico compartilhado cresce a cada turno), bots com instruções longas e completação de código (o conteúdo do arquivo é prefixo de toda requisição).

Para habilitar, bastam dois parâmetros na configuração do endpoint: PrefixLength (de 1.024 a 65.536, define quanto da requisição usar no roteamento) e ConcurrencyThreshold (limite de requisições em voo por instância antes do overflow). A estratégia é definida por variante de produção, e dá para alternar entre RANDOM, LEAST_OUTSTANDING_REQUESTS e o novo PREFIX_AWARE sem reimplantar o modelo. Nenhuma mudança no container ou no framework de serving é necessária.

Dois cuidados práticos valem o destaque: o prefix caching precisa estar ligado no seu framework (no vLLM recente, é padrão), e a serialização das requisições precisa ser consistente — para a API nativa, o PrefixLength opera sobre bytes brutos, então espaçamento e ordenação de chaves no JSON afetam o roteamento.