AWS lancerer SageMaker HyperPod Inference Gateway til GPU-bevidst routing

Amazon Web Services annoncerede Amazon SageMaker HyperPod Inference Gateway den 18. september 2026, et Kubernetes-native, GPU-bevidst routingsystem til inferens af store sprogmodeller, som implementeres som et enkelt administreret add-on til Amazon EKS på eksisterende HyperPod-infrastruktur. AWS oplyste, at gatewayen kan reducere første‑token‑latens med op til 82 %.

Routningsproblemet bag gatewayen

Ifølge AWS har standard Kubernetes-load‑balanceringalgoritmer som round‑robin og least‑connections ingen indsigt i GPU‑tilstanden: hvilke pods der har mættede KV‑cacher, hvilke der er midt i lange‑kontekst‑genereringer, og hvilke der allerede har den LoRA‑adapter, som en anmodning har brug for, indlæst i hukommelsen. Virksomheden oplyste, at anmodninger hober sig op bag travle pods, mens ubrugt kapacitet forbliver ubrugt, første‑token‑latensen springer over fire sekunder under trafikspidser, udnyttelsen bliver ujævn og uforudsigelig, og operatører over‑provisionerer for at kompensere. AWS beskrev et scenarie, hvor en chatbot‑bruger, der ventede 4,4 sekunder på et første token, i stedet ser det på under 800 millisekunder.

To‑lagers arkitektur

Gatewayen bruger et to‑lagers design bygget på Kubernetes-native primitive. AWS oplyste, at den bruger real‑time GPU‑signaler til at placere hver inferens‑anmodning på den bedst egnede pod. Tier 1 installeres direkte på hver HyperPod eller EKS‑klynge som add‑on’en amazon‑sagemaker‑hyperpod‑inference og består af tre komponenter, alle bygget på den open‑source Gateway API Inference Extension. Envoy Gateway, en layer‑7‑proxy, afslutter indkommende HTTPS‑trafik og eksponerer et enkelt privat endpoint pr. klynge. Body‑Based Router inspicerer hver indkommende OpenAI‑kompatibel anmodnings‑body, udtrækker model‑feltet og router anmodningen til den korrekte model‑pool, så én gateway kan betjene flere modeller.

Endpoint Picker indsamler real‑time Prometheus‑metrics fra hver model‑servende pod og anvender en vægtet scoringsalgoritme på tværs af scorere, der dækker KV‑cache‑udnyttelse, kødybde, LoRA‑adapter‑residens, præfiks‑cache‑hit‑rate og igangværende anmodninger. Hver scorer har en konfigurerbar vægt, hvilket gør det muligt at finjustere routingsadfærden for en specifik arbejdsbelastning, såsom latens‑følsom chat versus gennemløbs‑optimeret batch.

Tier 2, den globale Inference Router, er angivet som kommende snart. AWS oplyste, at den vil tilføje flåde‑omfattende koordinering på tværs af flere klynger og regioner, med cross‑cluster failover, global hastighedsbegrænsning og omkostnings‑bevidst trafik‑formning. Tier 2 bygger oven på Tier 1, mens hver klynges per‑cluster gateway fortsat håndterer lokal routing.

Udrulning, fejlhåndtering og observerbarhed

Implementeringen består af en enkelt aws eks create-addon‑kommando og én deklarativ InferenceGatewayConfig‑custom‑resource, der definerer modeller og routingsadfærd, med eksisterende model‑server‑implementeringer opdaget via pod‑labels. AWS oplyste, at installationen ikke kræver sidecars, ingen service‑mesh og ingen ændringer i applikationskoden. Gatewayen eksponerer et standard OpenAI‑kompatibelt endpoint over HTTP; ifølge AWS fungerer eksisterende klientkode uændret, uden SDK‑ændringer og uden SigV4‑signering for inferens‑trafik.

For arbejdsbelastninger, der betjener fin‑tuned LoRA‑adaptere på en delt grundmodel, router Endpoint Picker’s LoRA Affinity Scorer adapter‑anmodninger til pods, der allerede har den ønskede adapter resident i GPU‑hukommelse; hvis ingen pod har den indlæst, går anmodningen til den pod med mest tilgængelig kapacitet. AWS oplyste, at dette eliminerer adapter‑swap‑latens.

Dokumenterede fejlhåndteringsadfærd dækker pod‑fejl, pool‑udtømning, klynge‑fejl og regional fejl. Ved pod‑fejl ekskluderer Endpoint Picker pods med forældede metrics og router til sunde pods, og genopretter automatisk, når metrics genoptages. Ved pool‑udtømning returnerer gatewayen HTTP 429 med en Retry‑After‑header, mens autoskalering tilføjer kapacitet. Ved klynge‑fejl opdager den globale Inference Router et forældet heartbeat og omdirigerer trafikken inden for 35 sekunder, med gradvis optrapning, når klyngen genindføres. Ved regional fejl aktiveres cross‑region routing automatisk, hvilket AWS oplyste medfører højere latens men ingen påvirkning af tilgængeligheden.

Gatewayen udsender metrics på pod‑, pool‑, klynge‑ og flådeniveau: KV‑cache‑udnyttelse, kødybde, igangværende anmodninger og adapter‑residens via Prometheus på pod‑niveau; anmodningstotaler, varighedshistogrammer og token‑tællinger via Prometheus og Grafana på pool‑niveau; gennemsnitlig KV‑cache, fejlrate og P99‑latens via Amazon CloudWatch på klynge‑niveau; samt routingsbeslutninger, failover‑begivenheder og rate‑limit‑hits via CloudWatch på flådeniveau.

AWS‑rapporterede benchmark‑resultater

AWS oplyste, at de benchmarkede fire modeller med 8 milliarder til 235 milliarder parametre på p5.48xlarge‑instanser med H100‑GPU’er og g5‑instanser med A10G‑GPU’er. Al trafik blev routet gennem interne Application Load Balancers, hvilket matcher den sti, en produktionsanmodning følger, med en dedikeret klient‑node‑gruppe, der genererer kontrolleret belastning, og model‑servere isoleret på en separat server‑node‑gruppe. Hvert resultat bruger gatewayens standard‑routingskonfiguration uden finjustering og måles mod en Kubernetes round‑robin‑baseline på de samme model‑replikater, ifølge AWS.

I de rapporterede resultater reducerede en GPU-flåde med blandede generationer tiden til første token (P95 og P99) med 97 % for hver for Llama-3.1-8B, med en gennemstrømningsstigning på 8 %, og med 98 % og 97 % for Qwen3-32B, med en gennemstrømningsstigning på 50 %. Under burstet trafik viste Llama-3.1-70B P95- og P99-reduktioner på 94 % og 98 % med 12 % højere gennemstrømning, mens Qwen3-235B viste sammenlignelig P95-latens og en 89 % lavere P99. Med delte prompt-præfikser faldt Llama-3.1-8B P95- og P99-latens med 26 % og 43 %.

AWS sagde, at på en fuldstændig ensartet flåde under stabil trafik leverer gatewayen ydeevne på niveau med round-robin, og den definerede sammenlignelige resultater som forskelle inden for kørsel-til-kørsel-varians. Virksomheden sagde, at forbedringerne er størst, hvor round-robin har flest udfordringer: blandet hardware, burstet efterspørgsel og delte prompt-præfikser.

Tilgængelighed og køreplan

AWS beskriver gatewayen som overensstemmende med Kubernetes Gateway API og dens Inference-udvidelse, konfigureret via en enkelt brugerdefineret ressource-definition, og kompatibel med enhver OpenAI-kompatibel modelserver, herunder vLLM, SGLang og TGI. Administration fungerer gennem kubectl, GitOps, Helm og ArgoCD, med installation, opgraderinger og rollback håndteret via EKS-add-on-livscyklussen.

Tier 1 per-cluster-routing er tilgængelig fra den 18. september 2026 i regioner, hvor inference-add-on er tilgængelig. Ud over den globale inference-router omfatter AWS’s navngivne roadmap-elementer kanarietrafik-splittning, som vil dirigere en procentdel af trafikken til nye modelversioner ved hjælp af InferenceModelRewrite-brugerdefinerede ressourcer, samt flow-kontrol, der klassificerer anmodninger som Kritisk, Standard eller Afviselig med per-bånd-adgangskontrol.