AWS lanserar SageMaker HyperPod Inference Gateway för GPU‑medveten routing

Amazon Web Services meddelade Amazon SageMaker HyperPod Inference Gateway den 18 september 2026, ett Kubernetes‑native, GPU‑medvetet routningssystem för inferens av stora språkmodeller som distribueras som ett enda hanterat tillägg för Amazon EKS på befintlig HyperPod‑infrastruktur. AWS sade att gatewayen kan minska första-tokenlatens med upp till 82 %.

Routningsproblemet bakom gatewayen

Enligt AWS har standard Kubernetes-lastbalanseringsalgoritmer såsom round‑robin och least‑connections ingen insyn i GPU‑tillståndet: vilka pods som har mättade KV‑cachar, vilka som är halvvägs genom långa kontextgenereringar, och vilka som redan har LoRA‑adaptern som en begäran kräver laddad i minnet. Företaget sade att förfrågningar hopar sig bakom upptagna pods medan overksam kapacitet förblir outnyttjad, första-token‑latensen skjuter i höjden över fyra sekunder under trafiktoppar, utnyttjandet blir ojämnt och oförutsägbart, och operatörer överprovisionerar för att kompensera. AWS beskrev ett scenario där en chatbot‑användare som väntar 4,4 sekunder på en första token istället ser den på under 800 millisekunder.

Tvånivåarkitektur

Gatewayen använder en tvånivådesign byggd på Kubernetes‑native primitiv. AWS sade att den använder realtids‑GPU‑signaler för att placera varje inferensförfrågan på den mest lämpade podden. Nivå 1 installeras direkt på varje HyperPod eller EKS‑kluster som tillägget amazon-sagemaker-hyperpod-inference och består av tre komponenter, alla byggda på den öppna källkods‑Gateway‑API‑Inference‑Extension. Envoy Gateway, en lager‑7‑proxy, avslutar inkommande HTTPS‑trafik och exponerar en enda privat endpoint per kluster. Body‑Based Router inspekterar varje inkommande OpenAI‑kompatibel förfrågningskropp, extraherar modellfältet och dirigerar förfrågan till rätt modellpool, så att en gateway kan betjäna flera modeller.

Endpoint Picker konsumerar realtids‑Prometheus‑metrik från varje modell‑servande pod och tillämpar en viktad poängsättningsalgoritm över poängsättare som täcker KV‑cache‑utnyttjande, ködjup, LoRA‑adapter‑residens, prefix‑cache‑träfffrekvens och pågående förfrågningar. Varje poängsättare har en konfigurerbar vikt, vilket möjliggör att routningsbeteendet kan justeras för en specifik arbetsbelastning, såsom latenskänslig chatt jämfört med genomströmningsoptimerad batch.

Nivå 2, Global Inference Router, är listad som kommande. AWS sade att den kommer att lägga till flotta‑omfattande samordning över flera kluster och regioner, med cross‑cluster‑failover, global hastighetsbegränsning och kostnads‑medveten trafikformning. Nivå 2 bygger på nivå 1, medan varje klusters per‑kluster‑gateway fortsätter att hantera lokal routing.

Distribution, felhantering och observerbarhet

Distribution består av ett enda aws eks create-addon‑kommando och en deklarativ InferenceGatewayConfig‑anpassad resurs som definierar modeller och routningsbeteende, med befintliga modellserver‑distributioner upptäckta via pod‑etiketter. AWS sade att installationen inte kräver sidecars, service‑mesh eller ändringar i applikationskod. Gatewayen exponerar en standard OpenAI‑kompatibel endpoint över HTTP; enligt AWS fungerar befintlig klientkod oförändrad, utan SDK‑ändringar och utan SigV4‑signering för inferenstrafik.

För arbetsbelastningar som levererar finjusterade LoRA‑adaptrar på en gemensam basmodell, dirigerar Endpoint Picker:s LoRA Affinity Scorer adapter‑förfrågningar till pods som redan har den begärda adaptern resident i GPU-minnet; om ingen pod har den laddad går förfrågan till podden med mest tillgänglig kapacitet. AWS sade att detta eliminerar adapter‑swap‑latens.

Dokumenterade felbeteenden omfattar pod‑fel, pool‑utarmning, klusterfel och regionfel. Vid pod‑fel exkluderar Endpoint Picker pods med föråldrade metrik och dirigerar till friska pods, återhämtar sig automatiskt när metrik återupptas. Vid pool‑utarmning returnerar gatewayen HTTP 429 med en Retry‑After‑header medan autoskalning lägger till kapacitet. Vid klusterfel upptäcker Global Inference Router ett föråldrat hjärtslag och omdirigerar trafiken inom 35 sekunder, med gradvis upptrappning när klustret återinförs. Vid regionfel aktiveras cross‑region‑routing automatiskt, vilket AWS sade medför högre latens men ingen tillgänglighetspåverkan.

Gatewayen sänder ut metrik på pod‑, pool‑, kluster‑ och flottnivå: KV‑cache‑utnyttjande, ködjup, pågående förfrågningar och adapter‑residens via Prometheus på pod‑nivå; förfrågningssumma, varaktighets‑histogram och token‑antal via Prometheus och Grafana på pool‑nivå; genomsnittlig KV‑cache, felrate och P99‑latens via Amazon CloudWatch på kluster‑nivå; samt routningsbeslut, failover‑händelser och hastighetsgräns‑träffar via CloudWatch på flottnivå.

AWS‑rapporterade benchmarkresultat

AWS sade att de benchmarkade fyra modeller med 8 B till 235 B parametrar på p5.48xlarge‑instanser med H100‑GPU:er och g5‑instanser med A10G‑GPU:er. All trafik dirigerades genom interna Application Load Balancers, vilket matchade den väg en produktionsförfrågan tar, med en dedikerad klientnodgrupp som genererade kontrollerad belastning och modellservrar isolerade på en separat servernodgrupp. Varje resultat använder gatewayens standard‑routningskonfiguration utan finjustering och mäts mot en Kubernetes round‑robin‑baslinje på samma modell‑repliker, enligt AWS.

I de rapporterade resultaten minskade en GPU-flotta med blandade generationer tiden till första token (P95‑ och P99‑latens) med 97 % för Llama‑3.1‑8B, med en genomströmningökning på 8 %, och med 98 % respektive 97 % för Qwen3‑32B, med en genomströmningökning på 50 %. Vid burstig trafik redde Llama‑3.1‑70B P95‑ och P99‑reduktioner på 94 % respektive 98 % med 12 % högre genomströmning, medan Qwen3‑235B visade jämförbar P95‑latens och en 89 % lägre P99. Med delade prompt‑prefix föll Llama‑3.1‑8B:s P95‑ och P99‑latens med 26 % respektive 43 %.

AWS uppgav att gatewayen på en helt enhetlig flotta under stabil trafik presterar i nivå med round‑robin, och definierade jämförbara resultat som skillnader inom kör‑till‑kör‑varians. Företaget sade att förbättringarna är störst där round‑robin har svårast: blandad hårdvara, burstig efterfrågan och delade prompt‑prefix.

Tillgänglighet och färdplan

AWS beskriver gatewayen som kompatibel med Kubernetes Gateway API och dess Inference‑Extension, konfigurerad via en enda anpassad resursdefinition, och kompatibel med alla OpenAI‑kompatibla modellservrar, inklusive vLLM, SGLang och TGI. Hantering sker via kubectl, GitOps, Helm och ArgoCD, med installation, uppgraderingar och återställning hanterade genom EKS‑tilläggens livscykel.

Tier 1‑routing per kluster är tillgänglig från och med 18 september 2026 i de regioner där inference‑tillägget finns. Utöver Global Inference Router omfattar AWS:s namngivna färdplanspunkter kanariefördelning av trafik, som kommer att dirigera en procentandel av trafiken till nya modellversioner med hjälp av anpassade resurser av typen InferenceModelRewrite, samt flödeskontroll som klassificerar förfrågningar som Kritisk, Standard eller Avslagsbar med åtkomstkontroll per band.