AWS lanceert SageMaker HyperPod Inference Gateway voor GPU-bewuste routering

Amazon Web Services kondigde Amazon SageMaker HyperPod Inference Gateway aan op 18 september 2026, een Kubernetes-native, GPU-bewuste routeringssysteem voor inferentie van grote taalmodellen dat wordt ingezet als een enkele beheerde add-on voor Amazon EKS op bestaande HyperPod-infrastructuur. AWS zei dat de gateway de latency van het eerste token met tot wel 82 % kan verminderen.

Het routeringsprobleem achter de gateway

Volgens AWS hebben standaard Kubernetes-loadbalancing-algoritmen zoals round-robin en least-connections geen zicht op de GPU-status: welke pods verzadigde KV-caches hebben, welke halverwege lange-contextgeneraties zitten, en welke al de LoRA-adapter die een verzoek nodig heeft in het geheugen hebben geladen. Het bedrijf zei dat verzoeken zich ophopen achter drukbezette pods terwijl idle capaciteit ongebruikt blijft, de latency van het eerste token boven vier seconden stijgt tijdens verkeerspieken, de benutting ongelijkmatig en onvoorspelbaar wordt, en operators overprovisioneren om te compenseren. AWS beschreef een scenario waarin een chatbotgebruiker die 4,4 seconden wacht op een eerste token deze in minder dan 800 milliseconden ziet.

Twee-laags architectuur

De gateway maakt gebruik van een twee-laags ontwerp gebouwd op Kubernetes-native primitive. AWS zei dat het realtime GPU-signalen gebruikt om elk inferentieverzoek op de best geschikte pod te plaatsen. Tier 1 wordt direct op elke HyperPod of EKS-cluster geïnstalleerd als de amazon-sagemaker-hyperpod-inference add-on en bestaat uit drie componenten, allemaal gebouwd op de open‑source Gateway API Inference Extension. Envoy Gateway, een layer‑7 proxy, beëindigt inkomend HTTPS‑verkeer en stelt één privé‑endpoint per cluster beschikbaar. De Body‑Based Router inspecteert elk inkomend OpenAI‑compatibel verzoek‑body, haalt het model‑veld eruit en routeert het verzoek naar de juiste model‑pool, zodat één gateway meerdere modellen kan bedienen.

De Endpoint Picker gebruikt realtime Prometheus‑metriek van elke model‑serving pod en past een gewogen score‑algoritme toe over scorers die KV‑cache‑benutting, wachtrijdiepte, LoRA‑adapter‑residentie, prefix‑cache‑hit‑rate en lopende verzoeken dekken. Elke scorer heeft een configureerbaar gewicht, waardoor het routeringsgedrag kan worden afgestemd op een specifieke workload, zoals latentie‑gevoelige chat versus doorvoer‑geoptimaliseerde batch.

Tier 2, de Global Inference Router, staat vermeld als binnenkort beschikbaar. AWS zei dat het fleet‑brede coördinatie over meerdere clusters en regio’s zal toevoegen, met cross‑cluster failover, wereldwijde rate limiting en kosten‑bewuste traffic shaping. Tier 2 bouwt voort op Tier 1, terwijl de per‑cluster gateway van elk cluster de lokale routering blijft afhandelen.

Implementatie, foutafhandeling en observatie

Implementatie bestaat uit één aws eks create-addon‑opdracht en één declaratieve InferenceGatewayConfig‑custom resource die modellen en routeringsgedrag definieert, waarbij bestaande model‑server‑implementaties worden ontdekt via pod‑labels. AWS zei dat de installatie geen sidecars, geen service‑mesh en geen wijzigingen in applicatiecode vereist. De gateway stelt een standaard OpenAI‑compatibel endpoint beschikbaar via HTTP; volgens AWS werkt bestaande clientcode ongewijzigd, zonder SDK‑wijzigingen en zonder SigV4‑ondertekening voor inferentieverkeer.

Voor workloads die fijn-afgestelde LoRA‑adapters bedienen op een gedeeld basismodel, routeert de LoRA Affinity Scorer van de Endpoint Picker adapter‑verzoeken naar pods die de gevraagde adapter al resident hebben in GPU-geheugen; als geen enkele pod deze geladen heeft, gaat het verzoek naar de pod met de meeste beschikbare capaciteit. AWS zei dat dit de swap‑latency van adapters elimineert.

Documenteerde foutgedragingen omvatten pod‑fout, pool‑uitputting, cluster‑fout en regionale fout. Bij pod‑fout sluit de Endpoint Picker pods met verouderde metriek uit en routeert naar gezonde pods, waarbij automatisch wordt hersteld zodra de metriek weer beschikbaar is. Bij pool‑uitputting retourneert de gateway HTTP 429 met een Retry‑After‑header terwijl autoscaling capaciteit toevoegt. Bij cluster‑fout detecteert de Global Inference Router een verouderde heartbeat en leidt het verkeer binnen 35 seconden om, met geleidelijke opschaling wanneer het cluster opnieuw wordt geïntroduceerd. Bij regionale fout wordt cross‑region routing automatisch geactiveerd, wat volgens AWS een hogere latency met zich meebrengt maar geen impact op beschikbaarheid heeft.

De gateway geeft metriek af op pod‑, pool‑, cluster‑ en fleet‑niveau: KV‑cache‑benutting, wachtrijdiepte, lopende verzoeken en adapter‑residentie via Prometheus op pod‑niveau; totaal aantal verzoeken, duur‑histogrammen en token‑aantallen via Prometheus en Grafana op pool‑niveau; gemiddelde KV‑cache, foutpercentage en P99‑latency via Amazon CloudWatch op cluster‑niveau; en routeringsbeslissingen, failover‑gebeurtenissen en rate‑limit‑hits via CloudWatch op fleet‑niveau.

AWS‑gerapporteerde benchmarkresultaten

AWS zei dat het vier modellen met 8 B tot 235 B parameters heeft gebenchmarkt op p5.48xlarge‑instances met H100‑GPU’s en g5‑instances met A10G‑GPU’s. Al het verkeer werd gerouteerd via interne Application Load Balancers, overeenkomstig het pad dat een productie‑verzoek aflegt, met een toegewijde client‑node‑groep die gecontroleerde belasting genereert en model‑servers die geïsoleerd zijn op een aparte server‑node‑groep. Elk resultaat maakt gebruik van de standaard routeringsconfiguratie van de gateway zonder afstemming en wordt gemeten ten opzichte van een Kubernetes round‑robin‑baseline op dezelfde model‑replicaties, volgens AWS.

In de gerapporteerde resultaten heeft een GPU‑vloot met gemengde generaties de time-to-first-token P95‑ en P99‑latentie met elk 97 % verlaagd voor Llama-3.1-8B, met een doorvoerstijging van 8 %, en met 98 % en 97 % voor Qwen3-32B, met een doorvoerstijging van 50 %. Bij burstverkeer noteerde Llama-3.1-70B P95‑ en P99‑reducties van respectievelijk 94 % en 98 % met 12 % hogere doorvoer, terwijl Qwen3-235B een vergelijkbare P95‑latentie en een 89 % lagere P99 liet zien. Met gedeelde promptprefixen daalde de P95‑ en P99‑latentie van Llama-3.1-8B met 26 % en 43 %.

AWS zei dat de gateway op een volledig uniforme vloot onder gelijkmatig verkeer even goed presteert als round-robin, en dat het vergelijkbare resultaten definieert als verschillen binnen de run‑to‑run‑variantie. Het bedrijf stelde dat de verbeteringen het grootst zijn waar round-robin het moeilijkst heeft: gemengde hardware, burstverkeer en gedeelde promptprefixen.

Beschikbaarheid en routekaart

AWS beschrijft de gateway als conformant met de Kubernetes Gateway API en de bijbehorende Inference Extension, geconfigureerd via één enkele custom resource definition, en compatibel met elke OpenAI‑compatibele modelserver, waaronder vLLM, SGLang en TGI. Beheer gebeurt via kubectl, GitOps, Helm en ArgoCD, waarbij installatie, upgrades en rollback worden afgehandeld via de levenscyclus van de EKS‑add‑on.

Tier‑1 per‑cluster routing is beschikbaar vanaf 18 september 2026 in regio’s waar de inference‑add‑on beschikbaar is. Naast de Global Inference Router omvatten de benoemde roadmap‑items van AWS canary‑traffic‑splitting, waarmee een percentage van het verkeer naar nieuwe modelversies wordt geleid via InferenceModelRewrite‑custom resources, en flow‑control die verzoeken classificeert als Critical, Standard of Sheddable met per‑band toelatingscontrole.