Amazon SageMaker HyperPod Inference Gateway reduz latência do primeiro token em até 82%

O problema: roteamento ingênuo desperdiça GPU

Rodar modelos de linguagem em escala em clusters de GPU já é caro — e o balanceador de carga padrão do Kubernetes piora a situação. Os algoritmos round-robin e least-connections não enxergam nada do que acontece dentro das GPUs: quais pods estão com cache KV saturado, quais estão no meio de gerações longas, ou quais já têm o adaptador LoRA que a sua requisição precisa carregado em memória.

O resultado é previsível: requisições se empilham atrás de pods ocupados enquanto capacidade ociosa fica parada, a latência do primeiro token dispara para mais de 4 segundos nos picos, e o time superprovisiona para compensar. É dinheiro queimado em GPU que não está produzindo.

A solução: SageMaker HyperPod Inference Gateway

A Amazon anuncia hoje (18/set/2026) o SageMaker HyperPod Inference Gateway, um sistema de roteamento Kubernetes-nativo e ciente de GPU, instalado como um addon gerenciado do EKS sobre a sua infraestrutura HyperPod existente. Ele usa sinais em tempo real das GPUs para colocar cada requisição de inferência no pod mais adequado — sem nenhuma mudança nos seus servidores de modelo nem nas aplicações cliente.

“Um usuário de chatbot que esperava 4,4 segundos pelo primeiro token agora o vê em menos de 800 ms.”

Arquitetura em duas camadas

Camada 1 — Gateway por cluster (disponível hoje)

Instalada como addon amazon-sagemaker-hyperpod-inference, é composta por três componentes construídos sobre o Gateway API Inference Extension (open source):

• Envoy Gateway: proxy L7 que termina o HTTPS e expõe um único endpoint privado por cluster.
• Body-Based Router (BBR): inspeciona o corpo da requisição OpenAI-compatível, extrai o campo model e roteia para o pool correto — um gateway, vários modelos.
• Endpoint Picker (EPP): a camada de inteligência. Consome métricas Prometheus de cada pod e usa um algoritmo de pontuação ponderada considerando utilização de cache KV, profundidade de fila, residência de adaptadores LoRA, taxa de acerto de cache de prefixo e requisições em andamento.

Camada 2 — Global Inference Router (em breve)

Adiciona coordenação entre múltiplos clusters e regiões, com failover entre clusters, rate limiting global e modelagem de tráfego ciente de custo.

Instalação em 5 minutos

Sem sidecars, sem service mesh, sem mudança de código. Três passos: instalar o addon, rotular os pods de modelo e aplicar um recurso InferenceGatewayConfig declarativo.

# 1. Instalar o addon no cluster
aws eks create-addon \
  --cluster-name my-hyperpod-cluster \
  --addon-name amazon-sagemaker-hyperpod-inference \
  --addon-version v2.0.0-eksbuild.1 \
  --configuration-values '{"inferenceGateway": {"enabled": true}, "inferenceOperator": {"enabled": true}}'

Depois, o endpoint continua sendo OpenAI-compatível: o seu código cliente funciona sem alteração, com HTTPS padrão e sem assinatura SigV4 para o tráfego de inferência.

Ganhos medidos

A AWS comparou contra um baseline round-robin do Kubernetes nos mesmos modelos (8B a 235B parâmetros), usando a configuração padrão do gateway, em três cenários reais:

O padrão é consistente: quanto mais a frota diverge de um estado uniforme — hardware misto, demanda em rajada, prefixos compartilhados — maior o ganho. Em frota uniforme com tráfego estável, o desempenho fica empatado com o round-robin, como esperado.

Por que Kubernetes-nativo importa

O Inference Gateway não é uma plataforma paralela: é Kubernetes. Conforme ao Gateway API oficial, com um único CRD declarativo, sem lock-in (funciona com vLLM, SGLang, TGI e qualquer servidor OpenAI-compatível) e integrado ao ciclo de vida do EKS addon.