AWS führt SageMaker HyperPod Inference Gateway für GPU‑bewusstes Routing ein

Amazon Web Services kündigte Amazon SageMaker HyperPod Inference Gateway am 18. September 2026 an, ein Kubernetes‑nativer, GPU‑bewusster Routing‑Mechanismus für Inferenz großer Sprachmodelle, der als einzelnes verwaltetes Add‑On für Amazon EKS auf bestehender HyperPod‑Infrastruktur bereitgestellt wird. AWS erklärte, dass das Gateway die Latenz des ersten Tokens um bis zu 82 % reduzieren kann.

Das Routing‑Problem hinter dem Gateway

Nach Angaben von AWS haben Standard‑Kubernetes‑Lastverteilungsalgorithmen wie Round‑Robin und Least‑Connections keinerlei Einsicht in den GPU‑Zustand: welche Pods KV‑Caches gesättigt haben, welche sich mitten in langen Kontext‑Generierungen befinden und welche bereits den für die Anfrage benötigten LoRA‑Adapter im Speicher geladen haben. Das Unternehmen sagte, dass Anfragen sich hinter stark ausgelasteten Pods ansammeln, während ungenutzte Kapazitäten unbeschäftigt bleiben, die Latenz des ersten Tokens bei Verkehrsspitzen über vier Sekunden ansteigt, die Auslastung ungleichmäßig und unvorhersehbar wird und Betreiber zur Kompensation überprovisionieren. AWS beschrieb ein Szenario, in dem ein Chatbot‑Nutzer, der 4,4 Sekunden auf das erste Token wartet, es stattdessen in weniger als 800 Millisekunden erhält.

Zweistufige Architektur

Das Gateway verwendet ein zweistufiges Design, das auf Kubernetes‑nativen Primitive aufgebaut ist. AWS erklärte, dass es Echtzeit‑GPU‑Signale nutzt, um jede Inferenz‑Anfrage dem am besten geeigneten Pod zuzuweisen. Stufe 1 wird direkt auf jedem HyperPod oder EKS‑Cluster als das amazon-sagemaker-hyperpod-inference‑Add‑On installiert und besteht aus drei Komponenten, die alle auf der Open‑Source‑Erweiterung Gateway API Inference Extension basieren. Envoy Gateway, ein Layer‑7‑Proxy, beendet eingehenden HTTPS‑Verkehr und stellt pro Cluster einen einzigen privaten Endpunkt bereit. Der Body‑Based‑Router prüft den Körper jeder eingehenden OpenAI‑kompatiblen Anfrage, extrahiert das Modell‑Feld und leitet die Anfrage an den richtigen Modell‑Pool weiter, sodass ein Gateway mehrere Modelle bedienen kann.

Der Endpoint Picker nutzt Echtzeit‑Prometheus‑Metriken jedes Modell‑Serving‑Pods und wendet einen gewichteten Bewertungs‑Algorithmus auf verschiedene Scorer an, die die KV‑Cache‑Auslastung, die Warteschlangentiefe, die LoRA‑Adapter‑Residenz, die Trefferquote des Präfix‑Caches und laufende Anfragen berücksichtigen. Jeder Scorer besitzt ein konfigurierbares Gewicht, sodass das Routing‑Verhalten für eine bestimmte Arbeitslast, etwa latenz‑sensitiven Chat gegenüber durchsatz‑optimiertem Batch, feinabgestimmt werden kann.

Stufe 2, der Global Inference Router, ist als bald verfügbar gekennzeichnet. AWS erklärte, dass er eine flächenweite Koordination über mehrere Cluster und Regionen hinzufügen wird, mit Cross‑Cluster‑Failover, globaler Drosselung und kosten‑bewusster Verkehrsgestaltung. Stufe 2 baut auf Stufe 1 auf, während das pro‑Cluster‑Gateway jedes Clusters weiterhin das lokale Routing übernimmt.

Bereitstellung, Fehlerbehandlung und Beobachtbarkeit

Die Bereitstellung besteht aus einem einzigen aws eks create-addon-Befehl und einer deklarativen InferenceGatewayConfig‑Custom‑Resource, die Modelle und Routing‑Verhalten definiert, wobei vorhandene Modell‑Server‑Deployments über Pod‑Labels entdeckt werden. AWS erklärte, dass die Installation keine Sidecars, kein Service‑Mesh und keine Änderungen am Anwendungscode erfordert. Das Gateway stellt über HTTP einen standardisierten OpenAI‑kompatiblen Endpunkt bereit; laut AWS funktioniert bestehender Client‑Code unverändert, ohne SDK‑Änderungen und ohne SigV4‑Signatur für Inferenz‑Verkehr.

Für Workloads, die feinabgestimmte LoRA‑Adapter auf einem gemeinsam genutzten Basismodell bereitstellen, leitet der LoRA‑Affinity‑Scorer des Endpoint Pickers Adapter‑Anfragen an Pods weiter, die den angeforderten Adapter bereits im GPU‑Speicher resident haben; ist kein Pod geladen, wird die Anfrage an den Pod mit der größten verfügbaren Kapazität gesendet. AWS erklärte, dass dies die Latenz beim Adapter‑Swap eliminiert.

Dokumentierte Fehlverhalten umfassen Pod‑Ausfall, Pool‑Erschöpfung, Cluster‑Ausfall und regionalen Ausfall. Bei einem Pod‑Ausfall schließt der Endpoint Picker Pods mit veralteten Metriken aus und leitet Anfragen zu gesunden Pods weiter, wobei er sich automatisch erholt, sobald die Metriken wieder verfügbar sind. Bei Pool‑Erschöpfung gibt das Gateway HTTP 429 mit einem Retry‑After‑Header zurück, während das Autoscaling Kapazität hinzufügt. Bei einem Cluster‑Ausfall erkennt der Global Inference Router ein veraltetes Heartbeat‑Signal und leitet den Verkehr innerhalb von 35 Sekunden um, mit einer schrittweisen Wiederaufnahme, wenn der Cluster wieder eingebunden wird. Bei regionalem Ausfall aktiviert sich das Cross‑Region‑Routing automatisch, was AWS zufolge höhere Latenz, aber keine Verfügbarkeitsbeeinträchtigung mit sich bringt.

Das Gateway gibt Metriken auf Pod‑-, Pool‑, Cluster‑ und Flotten‑Ebene aus: KV‑Cache‑Auslastung, Warteschlangentiefe, laufende Anfragen und Adapter‑Residenz über Prometheus auf Pod‑Ebene; Anfragen‑Gesamtzahlen, Dauerschichten‑Histogramme und Token‑Zahlen über Prometheus und Grafana auf Pool‑Ebene; durchschnittlicher KV‑Cache, Fehlerrate und P99‑Latenz über Amazon CloudWatch auf Cluster‑Ebene; sowie Routing‑Entscheidungen, Failover‑Ereignisse und Rate‑Limit‑Treffer über CloudWatch auf Flotten‑Ebene.

Von AWS gemeldete Benchmark‑Ergebnisse

AWS erklärte, dass es vier Modelle mit 8 B bis 235 B Parametern auf p5.48xlarge‑Instanzen mit H100‑GPUs und g5‑Instanzen mit A10G‑GPUs benchmarkte. Der gesamte Verkehr wurde über interne Application Load Balancer geleitet, die dem Pfad einer Produktionsanfrage entsprechen, wobei eine dedizierte Client‑Node‑Gruppe kontrollierte Last erzeugt und Modell‑Server in einer separaten Server‑Node‑Gruppe isoliert sind. Jeder Test verwendet die Standard‑Routing‑Konfiguration des Gateways ohne Feinabstimmung und wird gegenüber einer Kubernetes‑Round‑Robin‑Baseline auf denselben Modell‑Replikaten gemessen, so AWS.

In den berichteten Ergebnissen reduzierte ein gemischtes GPU‑Flotten‑Setup die Zeit‑bis‑zum‑ersten‑Token‑Latenz (P95 und P99) um jeweils 97 % für Llama‑3.1‑8B bei einer Durchsatzsteigerung von 8 % und um 98 % bzw. 97 % für Qwen3‑32B bei einer Durchsatzsteigerung von 50 %. Bei burstigem Datenverkehr erzielte Llama‑3.1‑70B P95‑ und P99‑Reduktionen von 94 % bzw. 98 % bei 12 % höherem Durchsatz, während Qwen3‑235B eine vergleichbare P95‑Latenz und ein um 89 % niedrigeres P99 zeigte. Bei gemeinsam genutzten Prompt‑Präfixen fiel die P95‑ bzw. P99‑Latenz von Llama‑3.1‑8B um 26 % bzw. 43 %.

AWS erklärte, dass das Gateway bei einer vollständig einheitlichen Flotte unter gleichmäßigem Datenverkehr genauso gut wie Round‑Robin abschneidet und dass vergleichbare Ergebnisse als Unterschiede innerhalb der Lauf‑zu‑Lauf‑Varianz definiert werden. Das Unternehmen sagte, die Verbesserungen seien am größten dort, wo Round‑Robin am stärksten Schwierigkeiten hat: gemischte Hardware, burstige Nachfrage und gemeinsam genutzte Prompt‑Präfixe.

Verfügbarkeit und Fahrplan

AWS beschreibt das Gateway als konform zur Kubernetes Gateway API und deren Inference‑Extension, konfiguriert über eine einzige Custom‑Resource‑Definition, und kompatibel mit jedem OpenAI‑kompatiblen Model‑Server, einschließlich vLLM, SGLang und TGI. Die Verwaltung erfolgt über kubectl, GitOps, Helm und ArgoCD, wobei Installation, Updates und Rollbacks über den Lebenszyklus des EKS‑Add‑Ons abgewickelt werden.

Tier‑1‑Routing pro Cluster ist seit dem 18. September 2026 in Regionen verfügbar, in denen das Inference‑Add‑On bereitsteht. Neben dem Global Inference Router umfassen die von AWS benannten Roadmap‑Punkte Canary‑Traffic‑Splitting, das einen Prozentsatz des Datenverkehrs zu neuen Modellversionen mittels InferenceModelRewrite‑Custom‑Resources leitet, sowie Flow‑Control, das Anfragen als Critical, Standard oder Sheddable klassifiziert und eine band‑spezifische Zulassungskontrolle ermöglicht.