A AWS anunciou o roteamento sensível a prefixo para o Amazon SageMaker Inference, um recurso de balanceamento de carga que direciona requisições de LLM recebidas para a instância de GPU com maior probabilidade de já conter um prefixo de prompt correspondente em seu cache de chave-valor (KV).
A inferência de modelos de linguagem grandes reprocessa todo o prompt a cada chamada, a menos que o cache de atenção subjacente possa ser reaproveitado. Workloads que repetem um prompt de sistema, exemplos few-shot ou um histórico de conversa crescente — o padrão em chatbots de suporte e copilotos de vendas — se beneficiam enormemente de acertos de cache, já que o modelo só precisa computar os novos tokens em vez do contexto completo a cada vez. O balanceamento de carga tradicional, por round-robin ou menor número de conexões, distribui requisições aleatoriamente entre instâncias, causando falhas frequentes de cache e forçando o recálculo completo.
O roteamento sensível a prefixo rastreia quais instâncias de backend atenderam recentemente a um determinado prefixo de prompt e envia preferencialmente requisições correspondentes para essas instâncias. A AWS relata que isso melhora as taxas de acerto de cache e reduz tanto a latência quanto o custo computacional para workloads multi-turno e de prompts baseados em template, especialmente em volumes mais altos de requisições, onde a disputa por cache costuma ser comum. O recurso está disponível como uma configuração de estratégia de roteamento nos endpoints do SageMaker Inference e não exige alterações no código do modelo ou nas aplicações cliente.
Trata-se de uma otimização na camada de infraestrutura, não de um novo modelo ou API. Ela se aplica especificamente a equipes que hospedam seus próprios modelos ou modelos ajustados no SageMaker, e não a usuários de endpoints de API gerenciados da OpenAI, Anthropic ou dos modelos de fundação hospedados no Bedrock, onde o roteamento é tratado internamente pelo provedor.
Para empresas que de fato rodam inferência no SageMaker — muitas vezes uma escolha deliberada para manter dados de clientes dentro de uma VPC privada, atender a um requisito de residência de dados ou reduzir o custo marginal em alto volume — a atualização atua diretamente sobre duas coisas que importam operacionalmente: a latência de resposta em interações de chat ao vivo e o custo de GPU por conversa. Ferramentas de suporte em que agentes aguardam a resposta de um modelo antes de responder a um cliente, ou ferramentas de vendas outbound que geram mensagens personalizadas em escala, são os workloads com maior probabilidade de apresentar uma diferença mensurável após a ativação da nova estratégia de roteamento.