HyperPod Gateway: bis −82 % First Token – und wann Round-Robin reicht

4,4 Sekunden. So lange wartet in einem Beispiel aus dem AWS-Blog eine Chatbot-Nutzerin auf das erste Token, und genau dort beginnt die Rechnung, die jede Folie zum neuen HyperPod Inference Gateway begleitet. AWS behauptet, dieselbe Person sehe das erste Token nun in unter 800 Millisekunden. Die Latenz wäre damit gegen die Obergrenze um den Faktor 5,5 gesunken, denn 4,4 geteilt durch 0,8 ergibt 5,5. Klingt eindrucksvoll. Doch der Haken ist die Bedingung, unter der die Zahl entsteht, nicht die Zahl selbst.

Wir bei digital-magazin.de haben die beiden AWS-Veröffentlichungen nebeneinandergelegt, den Launch-Beitrag im AWS Machine Learning Blog vom 18. September 2026 und die What’s-New-Meldung vom 24. September 2026. Beide stammen von AWS. Wir haben nichts davon selbst gemessen, und jede Prozentzahl in diesem Text ist eine AWS-Angabe. Was wir leisten können: sauber rechnen, die Quellen gegeneinander lesen und sagen, was die Folie verschweigt.

Die Rechnung hinter 4,4 Sekunden und 800 Millisekunden

Zuerst die Arithmetik, offen vorgerechnet. 4,4 Sekunden geteilt durch 0,8 Sekunden sind 5,5. Das ist ein Faktor gegen die Obergrenze „unter 800 ms“. Es ist kein von AWS gemessener Endwert von 800,0 Millisekunden, und es ist keine dm-Messung. Der Blog formuliert den Satz sinngemäß so: Eine Chatbot-Nutzerin, die 4,4 Sekunden auf das erste Token wartet, sieht es nun in unter 800 ms. Ein Tabellenwert ist das nicht, sondern ein illustrierendes Beispiel.

Wer „unter 800“ liest, sollte sich merken, dass darunter alles Mögliche liegen kann. Bei 790 Millisekunden wäre der Faktor rund 5,6, bei 500 Millisekunden läge er höher. Der Faktor 5,5 ist also die vorsichtigste Lesart, nicht die genaueste. Ich halte das für einen fairen Umgang mit einer Angabe, die AWS selbst nur als Schranke formuliert.

Was die Rechnung nicht sagt: wie die 4,4 Sekunden zustande kamen. Der Blog beschreibt das Problem als Muster. Round-Robin und Least-Connections sehen laut AWS nicht, welche Pods gesättigte KV-Caches haben, welche mitten in einer Long-Context-Generierung stecken und welche den benötigten LoRA-Adapter schon im Speicher halten. Die Folge laut AWS: Requests stauen sich hinter beschäftigten Pods, während anderswo Kapazität ungenutzt bleibt. Die First-Token-Latenz steige bei Traffic-Bursts auf über vier Sekunden, die GPU-Auslastung werde ungleichmäßig, und man provisioniere zu viel. Das ist die Problemdarstellung von AWS, nicht unser Befund.

Was das HyperPod Inference Gateway technisch ist

Das Produkt ist ein Kubernetes-natives, GPU-bewusstes Routing für Inferenz auf bestehender SageMaker-HyperPod-Infrastruktur. Es wird als einziges EKS Managed Add-on installiert, laut AWS ohne Änderungen an der Anwendung. Es ersetzt, in den Worten der What’s-New-Meldung, „unintelligent round-robin load balancing“ durch Routing, das von Echtzeit-Inferenzsignalen gesteuert wird. Der Blog ergänzt, dass es auf der Open-Source Gateway API Inference Extension aufbaut.

Die Architektur hat zwei Ebenen. Tier 1 ist das Gateway pro Cluster, und nur das gibt es heute. Tier 2, der Global Inference Router (GIR), ist „coming soon“ und setzt auf Tier 1 auf. Diese Trennung ist wichtig, weil sie sich durch den gesamten Text zieht: Vieles, was nach Fleet-Steuerung klingt, gehört zu Tier 2 und ist heute nicht verfügbar.

Die drei Komponenten, zwei Namen

Tier 1 besteht aus drei Bausteinen, und hier weichen die beiden AWS-Texte in der Benennung voneinander ab. Die erste Komponente heißt in der What’s-New-Meldung „Envoy Endpoint“, im Blog „Envoy Gateway“. Gemeint ist ein L7-Proxy, der HTTPS terminiert und pro Cluster einen privaten Endpoint bereitstellt. Ich führe beide Namen auf, weil Sie in der Dokumentation womöglich nach dem einen suchen und auf den anderen stoßen.

Die zweite Komponente ist der Body-Based Router. Er inspiziert den OpenAI-kompatiblen Request-Body, liest das Feld model aus und leitet auf den passenden GPU-Pool. Ein Gateway, viele Modelle, eine Endpoint-URL, keine clientseitigen Änderungen. Die dritte ist der Endpoint Picker, kurz EPP. Er konsumiert Prometheus-Metriken und bewertet jeden Model-Server-Pod per gewichtetem Scoring. Er ist der Teil, an dem sich die Folie entscheidet.

Kompatibel ist das Ganze laut What’s New mit jedem OpenAI-kompatiblen Model Server, genannt werden vLLM und SGLang. Der Blog nennt zusätzlich TGI und „weitere“ und spricht von keinem Lock-in. TGI gehört also nur dem Blog, nicht der Meldung. Bestehende Werkzeuge wie kubectl, GitOps, Helm und ArgoCD sollen weiter funktionieren, der Add-on-Lebenszyklus läuft über CLI oder Konsole.

Sechs Scorer, fünf Scorer: Wo die AWS-Texte auseinanderlaufen

Jetzt wird es konkret. Die What’s-New-Meldung sagt, der Endpoint Picker bewerte jeden Pod in Echtzeit über sechs Signale: KV cache utilization, queue depth, LoRA adapter residency, prefix cache hit rate, predicted latency und running requests. Der Blog zählt an seiner Stelle nur fünf auf: KV cache utilization, queue depth, LoRA adapter residency, prefix cache hit rate und running requests. Predicted latency fehlt dort.

Das ist kein Tippfehler, den wir glätten dürfen. Wir können nicht sagen, ob der Blog das Signal schlicht ausgelassen hat oder ob es in der Praxis anders behandelt wird. Wir sagen nur, was dasteht: Die Meldung nennt sechs, die Blog-Aufzählung fünf. Wer die Zahl sechs zitiert, stützt sich auf What’s New. Wer sie dem Blog zuschreibt, irrt.

Was bedeuten die Signale für den Betrieb? Die KV-Cache-Auslastung zeigt, wie viel Speicher ein Pod für laufende Kontexte schon belegt hat. Die Queue Depth verrät, wie viele Requests vor ihm warten. Running Requests zählt, was gerade bearbeitet wird. Die LoRA-Adapter-Residency sagt, ob der gewünschte Adapter schon im GPU-Speicher liegt. Die Prefix-Cache-Trefferquote beschreibt, wie oft ein gemeinsamer Prompt-Anfang bereits berechnet vorliegt. Predicted Latency schließlich ist eine Vorhersage, die das Gateway selbst bildet.

Laut AWS hat jeder Scorer ein konfigurierbares Gewicht. Routing für latenzsensitiven Chat lasse sich so gegen durchsatzorientierte Batch-Last justieren. Auch das ist ein AWS-Claim. Ich finde die Idee plausibel, weil Chat und Batch tatsächlich gegensätzliche Ziele haben. Ob die Voreinstellung für Ihre Mischung passt, ist eine andere Frage.

Vier Beobachtungsebenen und die Lücke auf Pod-Ebene

Hier verläuft die eigentliche Prüfgrenze. Der Blog beschreibt Observability auf vier Ebenen. Auf Pod-Ebene sind es KV cache utilization, queue depth, running requests und adapter residency, geliefert über Prometheus. In dieser Pod-Liste fehlen prefix cache hit rate und predicted latency. Auf Pool-Ebene stehen Request-Totals, Duration-Histograms und Token-Counts in Prometheus und Grafana. Auf Cluster-Ebene sind es der durchschnittliche KV-Cache, die Error-Rate und die P99-Latenz in Amazon CloudWatch. Auf Fleet-Ebene nennt der Blog Routing-Entscheidungen, Failover-Events und Rate-Limit-Hits, ebenfalls in CloudWatch.

Lesen Sie das ruhig zweimal. Zwei der sechs What’s-New-Scorer tauchen in der Pod-Aufzählung des Blogs nicht auf. Und der Blog sagt nicht, dass CloudWatch predicted latency zeige. Das behaupten wir deshalb auch nicht. Die Fleet-Ebene gehört zudem zum Tier-2-Umfeld, wo es um Failover und Rate Limiting über Cluster hinweg geht.

Was folgt daraus? Wer die sechs Scorer aus der What’s-New-Meldung nicht in den eigenen Dashboards sieht, kann die Folie nicht prüfen. Dann bleibt nur Vertrauen, und das ist bei einer Routing-Entscheidung, die jede Anfrage betrifft, ein dünnes Fundament. Ich würde vor dem Produktivgang klären, welche Signale tatsächlich als Metriken herauskommen und welche nur intern in die Gewichtung einfließen.

Ein Gedanke zur Einordnung: Ein Routing, das Sie nicht beobachten können, verschiebt Fehlersuche an eine Stelle, an der Sie keine Sicht haben. Wenn ein Pod ungewöhnlich wenig Last bekommt, möchten Sie wissen, warum. War der Cache voll, die Queue lang oder die Vorhersage schlecht? Ohne die Zeitreihen dazu raten Sie.

Wer tiefer in Betriebsfragen von HyperPod einsteigen will, findet bei uns einen Beitrag, der Governance und Checkpoints rund um Ray auf HyperPod behandelt. Er ist als Weiterlesen gedacht, nicht als Beleg für die Zahlen dieses Artikels.

Die Benchmark-Tabelle: Sechs Szenarien, sechs Aussagen

Der Blog legt eine Tabelle vor, und der Rahmen ist wichtig. Laut AWS wurden vier Modelle von 8B bis 235B Parametern getestet, auf Instanzen vom Typ p5.48xlarge mit H100 und auf g5 mit A10G. Der Traffic lief über interne Application Load Balancer, mit einer eigenen Client-Node-Group, während die Model-Server isoliert auf einer Server-Node-Group liefen. Es galt die Default-Routing-Konfiguration, ohne Tuning. Als Baseline diente Kubernetes-Round-Robin auf denselben Replicas. Alles davon ist AWS-Angabe.

Die Ergebnisse, jeweils als Reduktion gegenüber Round-Robin. Mixed GPU generations mit Llama-3.1-8B: TTFT P95 minus 97 Prozent, P99 minus 97 Prozent, Durchsatz plus 8 Prozent. Mixed GPU generations mit Qwen3-32B: P95 minus 98 Prozent, P99 minus 97 Prozent, Durchsatz plus 50 Prozent. Bursty Traffic mit Llama-3.1-70B: P95 minus 94 Prozent, P99 minus 98 Prozent, Durchsatz plus 12 Prozent.

Bursty Traffic mit Qwen3-235B sieht anders aus: P95 „Comparable“, P99 minus 89 Prozent, Durchsatz „Comparable“. Shared Prompt Prefix mit Llama-3.1-8B: P95 minus 26 Prozent, P99 minus 43 Prozent, Durchsatz „Comparable“. Und die uniforme Fleet bei steady Traffic mit Qwen3-235B: P95, P99 und Durchsatz jeweils „Comparable“.

„Comparable“ heißt laut Blog, dass die Differenz innerhalb der Run-to-run-Varianz lag. Es heißt nicht null Prozent. Es heißt auch nicht, dass nichts passiert wäre, sondern dass sich ein Effekt von Rauschen nicht trennen ließ. Deshalb taucht „Comparable“ in der folgenden Grafik nicht als Balken auf. Ein Balken würde eine Zahl suggerieren, die AWS nicht genannt hat.

Die Grafik zeigt nur bezifferte Zeilen, also acht von achtzehn Zellen der Tabelle. Der Rest ist entweder „Comparable“ oder betrifft den Durchsatz. Das Muster ist dennoch klar: Die großen Reduktionen stehen bei gemischter Hardware und bei Bursts, die kleineren beim gemeinsamen Prompt-Präfix, und bei der uniformen Fleet steht nichts Bezifferbares.

82 Prozent, 97 bis 98 Prozent: Zwei Zahlen, zwei Bedeutungen

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptPhotorealistic close editorial photo of neatly bundled network cables and a dark metal rack, shallow depth of field, no logos, no readable text, no watermarks, 16:9

Die What’s-New-Meldung nennt zwei Kennzahlen. Erstens reduziere das Gateway die First-Token-Latenz „by up to 82%“. Zweitens gebe es „p99 TTFT reductions of 97–98% in mixed-hardware and burst traffic scenarios“. Die Formulierung „up to 82%“ stand übrigens schon im Deck des Blogs vom 18. September, nicht erst in der Meldung vom 24. September.

Die dritte Grafik bildet genau das ab. Wichtig ist die Lesart: Die Balken 97 und 98 sind die beiden Enden einer einzigen What’s-New-Spanne für beide Szenarien gemeinsam. Sie sind keine zwei getrennt gemessenen Szenarien, und sie sind kein Mittelwert. Es gibt keine Zuordnung „Mixed gleich 97, Burst gleich 98“.

Die Blog-Tabelle ist feiner und widerspricht einer glatten 97-bis-98-Lesart für jeden Burst. Der Burst mit Qwen3-235B liegt bei P99 minus 89 Prozent, und sein P95 ist „Comparable“. Der Shared Prefix liegt mit minus 26 und minus 43 Prozent weit darunter. Die uniforme Fleet ist „Comparable“. Wer „97 bis 98 Prozent“ für jedes Burst-Szenario erwartet, wird von der Tabelle korrigiert.

Warum das wichtig ist: Die 97 bis 98 gelten für die stärksten Zeilen, nicht für das Produkt als Ganzes. Die 82 Prozent sind ein „bis zu“, und wie so oft bei dieser Formulierung sagt sie nur etwas über die Obergrenze. Wie oft ein Betrieb an diese Grenze kommt, verrät sie nicht. Und: Wir rechnen die 82 Prozent nicht aus 4,4 und 0,8 zurück. Das wäre eine andere Rechnung, und sie würde eine AWS-Messung vortäuschen, die es so nicht gibt.

Haben Sie die Seitenzahl der Folie schon gesucht, auf der die uniforme Fleet steht? Ich auch. Sie ist selten dort, wo die Balken sind.

Wann Round-Robin laut AWS reicht

Die vielleicht ehrlichste Zeile der gesamten Veröffentlichung steht im Blog: Auf einer vollständig uniformen Fleet unter steady Traffic halten die Replicas nahezu identische Auslastung. Das Gateway liege dann auf Augenhöhe mit Round-Robin. So die AWS-Deutung, und sie deckt sich mit der Tabellenzeile, in der alle drei Werte „Comparable“ sind.

Das ist logisch. Round-Robin verteilt gleichmäßig, und wenn alle Pods gleich schnell sind und gleich viel Last sehen, gibt es wenig, was ein intelligenteres Verfahren besser machen könnte. AWS formuliert es so, dass der Gewinn mit der Entfernung von der Uniformität steige. Intelligent Routing sei am wertvollsten bei Mixed Hardware, bursty Demand und Shared Prompt Prefixes. Ohne vorheriges Hand-Tuning einschaltbar, behauptet AWS außerdem.

Übersetzt in eine Entscheidungshilfe: Die Folie „bis minus 82 Prozent First Token“ gilt nicht auf einem uniformen Steady-State, dort ist das Gateway laut AWS vergleichbar mit Round-Robin. Unter dem Strich zählt die Folie nur, wenn Ihre Fleet gemischt oder bursty ist und der Observability-Stack die Scorer-Signale überhaupt sieht. Der Haken ist die Bedingung, nicht die Prozentzahl.

Ich persönlich finde diese Bedingung gar nicht unangenehm. Sie ist eine Prüffrage, die man an die eigene Infrastruktur stellen kann, bevor man irgendetwas installiert. Wie viele GPU-Generationen laufen bei Ihnen nebeneinander? Wie schwankt die Last über den Tag? Teilen viele Anfragen einen langen System-Prompt? Drei Fragen, und die Antworten kennen Sie ohnehin.

Eine Randbemerkung zur Rendite, nur als Bild: Verschenkte GPU-Zeit entsteht, wenn freie Pods neben gestauten stehen. Ein Routing, das diese Lücke schließt, bringt Rendite in Form von Latenz, nicht in Form einer Zahl, die wir Ihnen seriös nennen könnten. Geldbeträge rechnen wir ausdrücklich nicht aus.

Wer Inferenz-Setups auf SageMaker prüft, findet in einem weiteren Stück bei uns Hinweise zu Inferenzempfehlungen für Modelle in SageMaker Studio. Auch das ist nur als Anschluss gedacht.

Mehrere Modelle, LoRA-Adapter und Prefix-Caches im Routing

Der Body-Based Router macht aus einem Gateway eine Mehrmodell-Adresse. Laut Blog lässt sich Multi-Model über mehrere Scheduler abbilden, wobei das Routing am Feld model hängt. Clients sprechen weiter denselben OpenAI-kompatiblen Pfad /v1/chat/completions an, und es ist weder SigV4 für den Inference-Traffic noch eine SDK-Änderung nötig, sondern Standard-HTTP.

Bei LoRA wird es spezifischer. Der Blog beschreibt einen LoRA Affinity Scorer: Requests gehen bevorzugt an Pods, die den Adapter bereits im GPU-Speicher haben. Hat ihn kein Pod geladen, geht der Request an den Pod mit der meisten freien Kapazität, damit der Adapter dort schnell geladen wird. Das ist ein AWS-Claim, und eine eigene Messung dazu liegt uns nicht vor. Plausibel klingt es trotzdem, denn das Nachladen eines Adapters kostet sonst genau die Zeit, die das erste Token braucht.

Der Prefix-Cache ist der dritte Fall. Wenn viele Anfragen mit demselben langen Anfang starten, etwa einem System-Prompt, lohnt es sich, sie auf Pods zu schicken, die diesen Anfang schon berechnet haben. Die Benchmark-Zeile mit Shared Prefix zeigt genau diese Konstellation, mit minus 26 Prozent bei P95 und minus 43 Prozent bei P99. Das ist deutlich weniger als bei Mixed Hardware, aber es ist eine echte Reduktion, die nicht mit „Comparable“ abgetan wird.

Der Rest ist Konfiguration. Ein Add-on plus eine InferenceGatewayConfig-CRD reichen laut Blog aus, und die API-Gruppe lautet inference.sagemaker.aws.amazon.com/v1alpha1. Es gibt kein Sidecar und kein Service Mesh. Das Installationsbeispiel nennt das Add-on amazon-sagemaker-hyperpod-inference in der Beispielversion v2.0.0-eksbuild.1. Als Pod-Label erscheint app: vllm-llama, als Scheduler-Name llama-70b, als Modellname llama-3.1-70b, als targetPort 8000 und als Scheduler llm-d. Ich belasse es bei diesen Fakten, denn ein Code-Dump brächte Ihnen nicht mehr als die Dokumentation selbst.

Was heute läuft und was noch aussteht

Kurz und ohne Schnörkel. Verfügbar ist heute Per-Cluster-Routing, und zwar laut What’s New in allen AWS-Regionen, in denen das SageMaker HyperPod Inference Add-on unterstützt wird. Der Blog formuliert ähnlich: Tier 1 sei dort verfügbar, wo das Inference-Add-on verfügbar ist. Die beiden Formulierungen sind nah beieinander, aber nicht wortgleich, und praktisch heißt das: Prüfen Sie Ihre Region gegen die Liste der unterstützten Regionen für das Add-on.

Noch nicht verfügbar ist alles, was über einen einzelnen Cluster hinausgeht. What’s New führt als „coming soon“ auf: Cross-Cluster- und Cross-Region-Routing mit einem zentralen Fleet-Gateway, globales Rate Limiting und Cost-Tier-aware Traffic Shaping. Der Blog spricht beim GIR von fleet-weiter Koordination über Cluster und Regionen, Cross-Cluster-Failover, globalem Rate Limiting und kostenbewusstem Traffic Shaping. Als nächste Schritte nennt er außerdem Canary-Rollouts über InferenceModelRewrite-CRDs und Flow Control mit den Priority Bands Critical, Standard und Sheddable. Nichts davon ist live.

Failure-Verhalten, sauber getrennt

Der Blog beschreibt auch, wie sich das System bei Ausfällen verhalten soll. Ich trenne es nach Ebenen, weil die Zeilen unterschiedlich viel mit der heutigen Funktion zu tun haben.

Bei einem Pod-Fehler schließt der EPP Pods mit veralteten Metriken aus, und die Recovery läuft automatisch, sobald die Metriken zurück sind. Das betrifft Tier 1. Bei Pool-Erschöpfung liefert das Gateway HTTP 429 mit Retry-After, und das Autoscaling soll Kapazität nachlegen. Auch das klingt nach Tier 1, wobei der Blog die Zuordnung nicht ausdrücklich zieht.

Anders liegt es bei Cluster- und Regionsfehlern. Bei einem Cluster-Fehler erkenne der GIR einen veralteten Heartbeat und lenke Traffic innerhalb von 35 Sekunden um, danach folge ein gradueller Ramp-up. Bei einem Regionsfehler greife Cross-Region-Routing, mit höherer Latenz, aber laut AWS ohne Availability-Einbuße. Beides betrifft den noch nicht verfügbaren GIR. Die 35 Sekunden sind deshalb keine heutige Tier-1-Funktion, und wer heute einen Cluster-Ausfall absichern will, kann sich darauf nicht stützen.

Wer solche Umschaltzeiten einplant, sollte sie im eigenen Betrieb erst testen, wenn das Feature überhaupt ausgeliefert ist. Ich würde bis dahin ehrlich nur mit dem planen, was im Add-on steckt.

Eine Prüfliste für Betreibende vor dem Einschalten

Aus alledem lässt sich eine nüchterne Liste ableiten. Sie ist keine AWS-Empfehlung, sondern unsere Lesart der Quellen. Wir bei digital-magazin.de würden vor dem Einschalten vier Dinge klären.

Erstens: Wie uniform ist Ihre Fleet wirklich? Laufen nur H100-Knoten mit identischen Modellen und gleichmäßiger Last, dann spricht die AWS-Deutung für Gleichstand mit Round-Robin. Mischen Sie dagegen GPU-Generationen, wie der Benchmark mit p5.48xlarge und g5 es tut, ändert sich das Bild. Zweitens: Wie bursty ist Ihr Traffic? Steady-State und Burst sind in der Tabelle verschiedene Welten.

Drittens: Gibt es geteilte Prompt-Präfixe? Lange System-Prompts oder wiederkehrende Kontexte sind genau der Fall, in dem der Prefix-Cache-Scorer etwas bewirken kann, und die Tabelle zeigt dort moderate Werte. Viertens, und das ist der Punkt, an dem die meisten Setups scheitern dürften: Sehen Sie die Signale? Prüfen Sie, welche der sechs What’s-New-Scorer in Prometheus und CloudWatch als Metrik ankommen. Die Pod-Liste im Blog nennt vier, nicht sechs.

Dazu kommt ein Vorher-Nachher-Vergleich. Fahren Sie dieselbe Last einmal mit Round-Robin und einmal mit dem Gateway, und vergleichen Sie P95 und P99 des ersten Tokens. Liegt die Differenz innerhalb der Run-to-run-Varianz, haben Sie Ihre eigene „Comparable“-Zeile. Das ist dann kein Scheitern, sondern ein Befund, und er spart Ihnen Komplexität.

Und die Latenz selbst? Wer mit Agenten arbeitet, sammelt Wartezeiten über mehrere Schritte, und das erste Token ist nur ein Teil davon. Zu diesem Thema gibt es bei uns einen Beitrag über Latenz-Reduktion bei Bedrock-Agenten, der sich als Ergänzung lesen lässt. Und wer auf Cluster-Ebene scheduled, sollte außerdem wissen, wie Taints und Scheduling-Overrides in Kubernetes das Bild verändern können.

Was bleibt? Eine Folie mit Bedingung

Der Faktor 5,5 stimmt, solange man ihn als Rechnung gegen eine Obergrenze liest. Die 82 Prozent stimmen als „bis zu“. Die 97 bis 98 Prozent stimmen als Spanne für stark gemischte oder bursty Szenarien und nicht als Wert für jeden Burst. Die Tabelle im Blog ist dabei ehrlicher als die Meldung, weil sie ihre „Comparable“-Zeilen nicht versteckt.

Was mich an der Sache überzeugt, ist die Architektur: Ein Routing, das Cache-Füllstand, Warteschlange, Adapter und laufende Requests kennt, ist für LLM-Inferenz die naheliegende Antwort auf einen Lastverteiler, der von alledem nichts weiß. Was mich skeptisch lässt, ist die Lücke zwischen den sechs Scorern der Meldung und den vier Pod-Metriken des Blogs. Sie ist klein, aber sie sitzt genau dort, wo Betreibende prüfen wollen.

Der Punkt ist: Das Gateway ist kein Versprechen, sondern eine Wette auf Ungleichheit. Je ungleicher Ihre Hardware, Ihre Last und Ihre Prompts, desto besser steht sie. Auf einer gleichförmigen Fleet zahlen Sie mit Komplexität für einen Gewinn, den AWS selbst als vergleichbar bezeichnet. Messen Sie zuerst die eigene Streuung, dann entscheiden Sie.