AWS lanserer SageMaker HyperPod Inference Gateway for GPU-bevisst ruting

Amazon Web Services kunngjorde Amazon SageMaker HyperPod Inference Gateway den 18. september 2026, et Kubernetes‑native, GPU‑bevisst rutingsystem for inferens av store språkmodeller som distribueres som et enkelt administrert tillegg for Amazon EKS på eksisterende HyperPod‑infrastruktur. AWS oppga at portalen kan redusere første‑token‑latens med opptil 82 %.

Ruteringsproblemet bak gatewayen

Ifølge AWS har standard Kubernetes-lastbalanseringsalgoritmer som round-robin og least-connections ingen innsikt i GPU‑status: hvilke pods som har mettet KV‑cache, hvilke som er midt i lange‑kontekst‑genereringer, og hvilke som allerede har LoRA‑adapteren en forespørsel trenger lastet i minnet. Selskapet sa at forespørsler hoper seg opp bak travle pods mens ledig kapasitet forblir ubrukt, første‑token‑latensen spisser seg over fire sekunder under trafikkspisser, utnyttelsen blir ujevn og uforutsigbar, og operatører over‑provisjonerer for å kompensere. AWS beskrev et scenario der en chatbot‑bruker som ventet 4,4 sekunder på en første token i stedet får den på under 800 millisekunder.

To‑nivå‑arkitektur

Gatewayen bruker en to‑nivå‑design bygget på Kubernetes‑native primitive. AWS oppga at den bruker sanntids‑GPU‑signaler for å plassere hver inferens‑forespørsel på den best egnede podden. Tier 1 installeres direkte på hver HyperPod eller EKS‑klynge som tillegget amazon-sagemaker-hyperpod-inference og består av tre komponenter, alle bygget på den åpne kildekode‑utvidelsen Gateway API Inference Extension. Envoy Gateway, en lag‑7‑proxy, terminerer innkommende HTTPS‑trafikk og eksponerer ett privat endepunkt per klynge. Body‑Based Router inspiserer hver innkommende OpenAI‑kompatibel forespørselskropp, trekker ut modell‑feltet, og ruter forespørselen til riktig modell‑pool, slik at én gateway kan betjene flere modeller.

Endpoint Picker bruker sanntids‑Prometheus‑metrikk fra hver modell‑betjente pod og anvender en vektet poeng‑algoritme på tvers av scorer‑komponenter som dekker KV‑cache‑utnyttelse, kødybde, LoRA‑adapter‑residens, prefiks‑cache‑treffrate og pågående forespørsler. Hver scorer har en konfigurerbar vekt, noe som gjør det mulig å finjustere ruteringsadferden for en spesifikk arbeidsbelastning, for eksempel latens‑sensitiv chat versus gjennomstrømnings‑optimalisert batch.

Tier 2, den globale inferens‑routeren, er oppført som kommende. AWS oppga at den vil legge til flåte‑omfattende koordinering på tvers av flere klynger og regioner, med kryss‑klynge‑failover, global hastighetsbegrensning og kostnads‑bevisst trafikk‑forming. Tier 2 bygger på Tier 1, mens hver klynges per‑klynge‑gateway fortsetter å håndtere lokal ruting.

Distribusjon, feilbehandling og observabilitet

Distribusjon består av en enkelt aws eks create-addon‑kommando og én deklarativ InferenceGatewayConfig‑tilpasset ressurs som definerer modeller og ruteringsadferd, med eksisterende modell‑server‑distribusjoner oppdaget via pod‑etiketter. AWS oppga at installasjonen ikke krever side‑cars, ingen service‑mesh, og ingen endringer i applikasjonskode. Gatewayen eksponerer et standard OpenAI‑kompatibelt endepunkt over HTTP; ifølge AWS fungerer eksisterende klientkode uendret, uten SDK‑endringer og uten SigV4‑signering for inferens‑trafikk.

For arbeidsbelastninger som betjener finjusterte LoRA‑adaptere på en delt basis‑modell, ruter Endpoint Picker sin LoRA‑affinitets‑scorer adapter‑forespørsler til pods som allerede har den forespurte adapteren resident i GPU‑minne; hvis ingen pod har den lastet, går forespørselen til podden med mest tilgjengelig kapasitet. AWS oppga at dette eliminerer latency ved adapter‑bytte.

Dokumenterte feiladferder dekker pod‑feil, pool‑utarming, klynge‑feil og regional feil. Ved pod‑feil ekskluderer Endpoint Picker pods med utdaterte målinger og ruter til sunne pods, og gjenoppretter automatisk når målingene gjenopptas. Ved pool‑utarming returnerer gatewayen HTTP 429 med en Retry‑After‑header mens autoskalering legger til kapasitet. Ved klynge‑feil oppdager den globale inferens‑routeren et utdødt hjerte‑slag og omdirigerer trafikk innen 35 sekunder, med gradvis opptrapping når klyngen tas i bruk igjen. Ved regional feil aktiveres kryss‑region‑ruting automatisk, noe AWS oppga medfører høyere latens men ingen påvirkning på tilgjengelighet.

Gatewayen sender ut metrikk på pod‑, pool‑, klynge‑ og flåtenivå: KV‑cache‑utnyttelse, kødybde, pågående forespørsler og adapter‑residens via Prometheus på podnivå; forespørsels‑totaler, varighets‑histogrammer og token‑tellinger via Prometheus og Grafana på poolnivå; gjennomsnittlig KV‑cache, feilrate og P99‑latens via Amazon CloudWatch på klyngenivå; samt ruteringsbeslutninger, failover‑hendelser og hastighets‑begrensnings‑treff via CloudWatch på flåtenivå.

AWS‑rapporterte benchmark‑resultater

AWS oppga at de benchmarket fire modeller med mellom 8 milliarder og 235 milliarder parametere på p5.48xlarge‑instanser med H100‑GPUer og g5‑instanser med A10G‑GPUer. All trafikk ble rutet gjennom interne Application Load Balancers, som følger den banen en produksjonsforespørsel tar, med en dedikert klient‑node‑gruppe som genererer kontrollert belastning og modell‑servere isolert på en separat server‑node‑gruppe. Hvert resultat bruker gatewayens standard ruteringskonfigurasjon uten finjustering og måles mot en Kubernetes round‑robin‑baseline på de samme modell‑replikene, ifølge AWS.

I de rapporterte resultatene reduserte en GPU-flåte med blandet generasjon tid‑til‑første‑token (P95‑ og P99‑latens) med 97 % for både Llama‑3.1‑8B, med en gjennomstrømningsøkning på 8 %, og med 98 % og 97 % for Qwen3‑32B, med en gjennomstrømningsøkning på 50 %. Under burst‑trafikk oppnådde Llama‑3.1‑70B P95‑ og P99‑reduksjoner på 94 % og 98 % med 12 % høyere gjennomstrømning, mens Qwen3‑235B viste tilsvarende P95‑latens og en 89 % lavere P99. Med delte prompt‑prefikser falt Llama‑3.1‑8B sin P95‑ og P99‑latens med henholdsvis 26 % og 43 %.

AWS oppga at gatewayen på en helt ensartet flåte under jevn trafikk presterer på nivå med round‑robin, og de definerte sammenlignbare resultater som forskjeller innenfor varians mellom kjøringer. Selskapet sa at forbedringene er størst der round‑robin har mest problemer: blandet maskinvare, burst‑etterspørsel og delte prompt‑prefikser.

Tilgjengelighet og veikart

AWS beskriver gatewayen som i samsvar med Kubernetes Gateway API og dens Inference‑utvidelse, konfigurert via én tilpasset ressursdefinisjon, og kompatibel med enhver OpenAI‑kompatibel modellserver, inkludert vLLM, SGLang og TGI. Administrasjon skjer gjennom kubectl, GitOps, Helm og ArgoCD, med installasjon, oppgraderinger og tilbakeføring håndtert via EKS‑tilleggets livssyklus.

Tier 1‑ruting per klynge er tilgjengelig fra 18. september 2026 i regioner hvor inferens‑tillegget er tilgjengelig. Utover den globale inferens‑routeren inkluderer AWS sine navngitte veikart‑elementer kanarietrafikksplitting, som vil rute en prosentandel av trafikken til nye modellversjoner ved bruk av InferenceModelRewrite‑tilpassede ressurser, samt flytkontroll som klassifiserer forespørsler som Kritisk, Standard eller Avlastbar med adgangskontroll per bånd.