AWS lança SageMaker HyperPod Inference Gateway para roteamento consciente de GPU

Amazon Web Services anunciou Amazon SageMaker HyperPod Inference Gateway em 18 de setembro de 2026, um sistema nativo de Kubernetes, consciente de GPU, para roteamento de inferência de grandes modelos de linguagem que é implantado como um único complemento gerenciado para Amazon EKS na infraestrutura HyperPod existente. A AWS disse que o gateway pode reduzir a latência do primeiro token em até 82%.

O Problema de Roteamento por Trás do Gateway

De acordo com a AWS, os algoritmos padrão de balanceamento de carga do Kubernetes, como round-robin e least-connections, não têm visibilidade do estado da GPU: quais pods têm caches KV saturados, quais estão no meio de gerações de longo contexto e quais já têm o adaptador LoRA que uma solicitação precisa carregado na memória. A empresa afirmou que as solicitações se acumulam atrás de pods ocupados enquanto a capacidade ociosa permanece inutilizada, a latência do primeiro token dispara acima de quatro segundos durante picos de tráfego, a utilização torna‑se desigual e imprevisível, e os operadores provisionam em excesso para compensar. A AWS descreveu um cenário em que um usuário de chatbot que esperava 4,4 segundos pelo primeiro token o recebe em menos de 800 milissegundos.

Arquitetura de Dois Níveis

O gateway utiliza um design de dois níveis construído sobre primitivas nativas do Kubernetes. A AWS disse que usa sinais de GPU em tempo real para direcionar cada solicitação de inferência ao pod mais adequado. O Tier 1 instala‑se diretamente em cada HyperPod ou cluster EKS como o complemento amazon-sagemaker-hyperpod-inference e consiste em três componentes, todos baseados na extensão de inferência da API Gateway de código aberto. O Envoy Gateway, um proxy de camada 7, encerra o tráfego HTTPS de entrada e expõe um único endpoint privado por cluster. O Body‑Based Router inspeciona cada corpo de solicitação compatível com OpenAI, extrai o campo model e encaminha a solicitação para o pool de modelo correto, permitindo que um único gateway atenda a vários modelos.

O Endpoint Picker consome métricas em tempo real do Prometheus de cada pod que serve modelos e aplica um algoritmo de pontuação ponderada entre avaliadores que consideram a utilização do cache KV, a profundidade da fila, a residência do adaptador LoRA, a taxa de acerto do cache de prefixos e as solicitações em execução. Cada avaliador possui um peso configurável, permitindo ajustar o comportamento de roteamento para uma carga de trabalho específica, como chat sensível à latência versus lote otimizado para taxa de transferência.

O Tier 2, o Global Inference Router, está anunciado como próximo lançamento. A AWS afirmou que adicionará coordenação em toda a frota entre múltiplos clusters e regiões, com failover entre clusters, limitação de taxa global e modelagem de tráfego consciente de custos. O Tier 2 baseia‑se no Tier 1, enquanto o gateway por cluster de cada cluster continua a gerenciar o roteamento local.

Implantação, Tratamento de Falhas e Observabilidade

A implantação consiste em um único comando aws eks create-addon e um recurso personalizado declarativo InferenceGatewayConfig que define modelos e comportamento de roteamento, com implantações de servidores de modelo existentes descobertas por meio de rótulos de pod. A AWS informou que a instalação não requer sidecars, mesh de serviço ou alterações no código da aplicação. O gateway expõe um endpoint padrão compatível com OpenAI via HTTP; segundo a AWS, o código cliente existente funciona sem alterações, sem mudanças no SDK e sem assinatura SigV4 para o tráfego de inferência.

Para cargas de trabalho que servem adaptadores LoRA ajustados em um modelo base compartilhado, o LoRA Affinity Scorer do Endpoint Picker encaminha solicitações de adaptador para pods que já têm o adaptador solicitado residente na memória de GPU; se nenhum pod o tiver carregado, a solicitação é enviada ao pod com maior capacidade disponível. A AWS disse que isso elimina a latência de troca de adaptador.

Os comportamentos de falha documentados abrangem falha de pod, exaustão de pool, falha de cluster e falha regional. Em caso de falha de pod, o Endpoint Picker exclui pods com métricas desatualizadas e encaminha para pods saudáveis, recuperando‑se automaticamente quando as métricas retornam. Na exaustão de pool, o gateway devolve HTTP 429 com um cabeçalho Retry-After enquanto o autoscaling adiciona capacidade. Em falha de cluster, o Global Inference Router detecta um heartbeat desatualizado e redireciona o tráfego em até 35 segundos, com aumento gradual quando o cluster é reintegrado. Em falha regional, o roteamento entre regiões é ativado automaticamente, o que a AWS disse que gera maior latência, mas sem impacto na disponibilidade.

O gateway gera métricas nos níveis de pod, pool, cluster e frota: utilização do cache KV, profundidade da fila, solicitações em execução e residência de adaptadores via Prometheus no nível de pod; totais de solicitações, histogramas de duração e contagem de tokens via Prometheus e Grafana no nível de pool; média do cache KV, taxa de erro e latência P99 via Amazon CloudWatch no nível de cluster; e decisões de roteamento, eventos de failover e ocorrências de limitação de taxa via CloudWatch no nível de frota.

Resultados de Benchmark Reportados pela AWS

A AWS afirmou que avaliou quatro modelos, com parâmetros entre 8 B e 235 B, em instâncias p5.48xlarge com GPUs H100 e instâncias g5 com GPUs A10G. Todo o tráfego foi roteado por meio de Application Load Balancers internos, reproduzindo o caminho percorrido por uma solicitação de produção, com um grupo de nós cliente dedicado gerando carga controlada e servidores de modelo isolados em um grupo de nós servidor separado. Cada resultado utiliza a configuração padrão de roteamento do gateway sem ajustes e é medido em comparação a uma linha de base round‑robin do Kubernetes nas mesmas réplicas de modelo, segundo a AWS.

Nos resultados relatados, uma frota de GPUs de gerações misturadas reduziu a latência time-to-first-token P95 e P99 em 97 % cada para Llama-3.1-8B, com aumento de 8 % no throughput, e em 98 % e 97 % para Qwen3-32B, com aumento de 50 % no throughput. Sob tráfego intermitente, Llama-3.1-70B apresentou reduções de P95 e P99 de 94 % e 98 % com 12 % de maior throughput, enquanto Qwen3-235B mostrou latência P95 comparável e um P99 89 % menor. Com prefixos de prompt compartilhados, a latência P95 e P99 do Llama-3.1-8B caiu 26 % e 43 %.

A AWS afirmou que, em uma frota totalmente uniforme sob tráfego constante, o gateway tem desempenho equivalente ao round-robin, e definiu resultados comparáveis como diferenças dentro da variância entre execuções. A empresa disse que as melhorias são maiores onde o round-robin tem mais dificuldades: hardware misto, demanda intermitente e prefixos de prompt compartilhados.

Disponibilidade e Roteiro

A AWS descreve o gateway como compatível com a Kubernetes Gateway API e sua Extensão de Inferência, configurado por meio de uma única definição de recurso personalizado, e compatível com qualquer servidor de modelo compatível com OpenAI, incluindo vLLM, SGLang e TGI. O gerenciamento funciona através do kubectl, GitOps, Helm e ArgoCD, com instalação, atualizações e reversões tratadas pelo ciclo de vida do add‑on EKS.

O roteamento de nível 1 por cluster está disponível a partir de 18 de setembro de 2026, nas regiões onde o add‑on de inferência está disponível. Além do Global Inference Router, os itens de roteiro nomeados da AWS incluem divisão de tráfego canário, que encaminhará uma porcentagem do tráfego para novas versões de modelo usando recursos personalizados InferenceModelRewrite, e controle de fluxo que classifica as solicitações como Crítica, Padrão ou Descarregável, com controle de admissão por banda.