A AWS anunciou em 18 de setembro de 2026 o Amazon SageMaker HyperPod Inference Gateway, um add-on gerenciado do Amazon EKS que faz roteamento de requisições de inferência com consciência do estado real das GPUs. Segundo a empresa, o recurso reduz a latência do primeiro token em até 82% e não exige qualquer alteração nos servidores de modelo nem nas aplicações cliente já em produção.
O anúncio foi publicado no blog de machine learning da AWS. Ele mira um problema conhecido de quem opera modelos de linguagem em cluster: o desperdício de GPU provocado por balanceadores de carga genéricos.
Roteamento cego desperdiça o recurso mais caro
Balanceadores padrão do Kubernetes usam algoritmos como round-robin e least-connections. Esses algoritmos não enxergam o que acontece dentro das GPUs.
Eles não sabem quais pods têm o cache KV saturado, quais estão no meio de gerações de contexto longo ou quais já têm em memória o adaptador LoRA exigido pela requisição. O resultado, descreve a AWS, é fila acumulada atrás de pods ocupados enquanto capacidade ociosa permanece parada.
Em picos de tráfego, a latência do primeiro token passa de 4 segundos. A utilização das GPUs fica desigual e imprevisível.
A saída encontrada pelas equipes costuma ser superprovisionar hardware, gastando com GPUs que não produzem trabalho útil.
Dois níveis, três componentes
A arquitetura em dois níveis (Figura 1) é construída sobre primitivas nativas do Kubernetes e sobre a extensão open source Gateway API Inference Extension.
O primeiro nível é instalado em cada cluster HyperPod/EKS como o add-on amazon-sagemaker-hyperpod-inference. Ele reúne três peças.
O Envoy Gateway atua como proxy L7 de alta performance, encerra o tráfego HTTPS e expõe um único endpoint privado por cluster. O Body-Based Router (BBR) inspeciona o corpo de cada requisição compatível com a API da OpenAI, extrai o campo do modelo e encaminha para o pool correto, o que permite servir vários modelos em um mesmo gateway.
O Endpoint Picker (EPP) é a camada de inteligência. Ele consome métricas em tempo real do Prometheus publicadas por cada pod de serving e aplica um algoritmo de pontuação ponderada.
Os critérios considerados são cinco: utilização do cache KV, para evitar pods com memória chave-valor quase cheia; profundidade da fila, que afasta backlogs longos; residência do adaptador LoRA, que privilegia pods que já carregaram o adaptador pedido; taxa de acerto do cache de prefixo, que favorece pods capazes de servir a partir de prefixos já armazenados; e número de requisições em execução, para equilibrar o trabalho ativo.
Cada critério tem peso configurável, o que permite calibrar o comportamento para cargas sensíveis a latência, como chat, ou para lotes otimizados por vazão.
O segundo nível, chamado Global Inference Router (GIR), ainda não está disponível e foi apresentado como próximo passo. Ele deve adicionar coordenação entre clusters e regiões, failover entre clusters, limitação de taxa global e modelagem de tráfego orientada a custo.
Ele opera por cima do nível 1, que continua responsável pelo roteamento inteligente local.
Ganho de latência e primeiros passos
O número que a AWS coloca no centro da divulgação é a latência do primeiro token. Um usuário de chatbot que esperava 4,4 segundos para ver a primeira resposta agora a recebe em menos de 800 milissegundos, segundo a empresa.
A instalação é feita em poucos passos, sem sidecars, sem service mesh e sem tocar no código das aplicações. O add-on é aplicado na versão v2.0.0-eksbuild.1, com parâmetros que habilitam o inferenceGateway e o inferenceOperator.
Em seguida, os pods de modelo existentes recebem um rótulo, com o exemplo app: vllm-llama no material, para que o gateway os descubra. Uma única configuração declarativa, o recurso InferenceGatewayConfig, define os modelos e o comportamento de roteamento, com campos como modelName: "llama-3.1-70b".
A partir daí, o endpoint exposto é compatível com a API da OpenAI. Uma chamada a /v1/chat/completions com o modelo llama-3.1-70b funciona com o cliente que a equipe já utilizava.
O que isso significa
Na prática, o anúncio ataca uma conta que cresce junto com a adoção de LLMs: clusters de GPU caros operando com utilização desigual. Ao trocar a lógica de balanceamento por decisões baseadas em cache KV, fila, prefixo e adaptadores, a AWS tenta reduzir a necessidade de superprovisionamento sem obrigar as equipes a reescrever aplicações.
A dependência do ecossistema de métricas do Prometheus e da extensão open source da Gateway API também indica que a disputa pela camada de roteamento de inferência passa a ser travada dentro do próprio Kubernetes, e não apenas nos servidores de modelo.
Resta saber como os pesos configuráveis se comportarão em cargas reais mistas, quando chat sensível a latência e processamento em lote dividem a mesma frota.
