Amazon SageMaker Prefix-Aware Routing senkt Latenz, doch wiederholter Kontext ist entscheidend

Das prefix-aware Routing von Amazon SageMaker senkte in AWS-Tests die mediane Zeit bis zum ersten Token um bis zu 77 %, indem es verändert, wohin wiederholte Prompts geleitet werden. Statt jede Anfrage unabhängig von ihrem Inhalt zu verteilen, kann SageMaker nun Anfragen mit übereinstimmenden Anfängen auf derselben Modellinstanz halten. Dadurch ist es wahrscheinlicher, dass zuvor berechneter Kontext verfügbar bleibt.

Das Ergebnis stellt eine grundlegende Annahme über die Skalierung von Endpunkten für große Sprachmodelle infrage. Zusätzliche Instanzen führen nicht automatisch zu effizienter Inferenz, wenn herkömmliches Load Balancing Anfragen von nützlichen gecachten Daten trennt. Eine Flotte kann über reichlich Beschleunigerkapazität verfügen und dennoch dieselben Anweisungen, Dokumente oder Gesprächsverläufe wiederholt verarbeiten.

AWS positioniert Routing daher als Teil des Inferenzoptimierungs-Stacks – neben Modell-Engines, Beschleunigern und Caching-Software. Der unmittelbare Gegenspieler ist cache-blindes Load Balancing, das Arbeit gleichmäßig verteilt, aber ignoriert, was jede Instanz bereits weiß. AWS berichtet von deutlichen Gewinnen, wobei die stärksten Werte jedoch aus einem kontrollierten Benchmark mit langem Kontext und nicht aus unabhängigen Produktionstests stammen.

Amazon SageMaker Prefix-Aware Routing verändert den Standard-Trade-off

AWS verlagert Prompt-Lokalität von einem Workaround auf Anwendungsebene in die Routing-Schicht verwalteter Endpunkte.

AWS kündigte die Funktion am 10. September 2026 für Echtzeit-Inferenzendpunkte von Amazon SageMaker an. Die neue Strategie untersucht den Beginn einer eingehenden Anfrage und leitet übereinstimmende Anfänge konsistent an dieselbe Instanz weiter.

Die zugrunde liegende Idee ist einfach. Viele LLM-Anfragen enthalten einen großen festen Abschnitt, gefolgt von einem deutlich kleineren variablen Abschnitt. Ein Kundenservice-Assistent könnte vor jeder neuen Kundenfrage dasselbe Richtliniendokument und dieselben Betriebsanweisungen erhalten.

Eine Retrieval-Augmented-Generation-Anwendung folgt häufig demselben Muster. Sie platziert ein abgerufenes Dokument vor einer Nutzeranfrage, sodass mehrere Fragen zu diesem Dokument mit identischem Text beginnen. Auch Coding-Assistenten senden Dateien, Imports, Anweisungen und aktuellen Bearbeitungskontext erneut.

Modellserver verfügen bereits über einen Mechanismus, um diese Wiederholung auszunutzen. Ein Key-Value-Cache, üblicherweise KV-Cache genannt, speichert Aufmerksamkeitszustände, die berechnet wurden, während das Modell frühere Tokens verarbeitet. Prefix Caching bewahrt wiederverwendbare Zustände über verwandte Anfragen mit übereinstimmenden Prompt-Anfängen hinweg.

Das Problem tritt auf, wenn ein Endpunkt über mehrere Instanzen skaliert. Zufälliges Routing kann aufeinanderfolgende Anfragen mit demselben Präfix an unterschiedliche Maschinen senden. Jede Maschine verarbeitet dann diesen gemeinsamen Kontext erneut, weil der nützliche Cache-Eintrag irgendwo anders vorhanden ist.

Amazon SageMaker prefix-aware routing versucht, diese Lokalität zu bewahren. Zehn Anfragen mit demselben Präfix sollten normalerweise dieselbe Maschine erreichen, sodass ihr Modellserver die gecachte Berechnung wiederverwenden kann. Anfragen mit anderen Präfixen können weiterhin über die Flotte verteilt werden.

Die Funktion ersetzt nicht das Prefix Caching innerhalb der Serving-Engine. Der Container muss weiterhin Software ausführen, die KV-Zustände speichern und wiederverwenden kann. AWS testete die Strategie mit vLLM und erklärt, dass aktuelle vLLM-Versionen Prefix Caching standardmäßig aktivieren.

Mit der Einführung kommt eine dritte Routing-Option für SageMaker-Echtzeitendpunkte hinzu. Zufälliges Routing bleibt der Standard und verteilt Traffic, ohne Beziehungen zwischen Anfragen zu berücksichtigen. Least-outstanding-requests-Routing bevorzugt die Instanz mit der größten verfügbaren Verarbeitungskapazität.

Prefix-aware routing setzt auf eine andere Annahme. Es akzeptiert eine gewisse Bindung zwischen Inhalt und Instanzen, da die eingesparte Prompt-Berechnung den Wert perfekt austauschbaren Traffics überwiegen kann.

AWS ergänzte einen Überlastungsschutz, um dieses Risiko zu begrenzen. Erreicht die bevorzugte Instanz einen konfigurierten Gleichzeitigkeitsschwellenwert, sendet SageMaker die Anfrage an eine weniger ausgelastete Instanz. Diese Anfrage könnte einen Cache-Hit verlieren, sollte jedoch vermeiden, sich in eine überlastete Warteschlange einzureihen.

Der Dienst soll zudem bei der Skalierung der Flotte den Großteil der Anfragenplatzierung erhalten. Laut AWS verschiebt das Hinzufügen oder Entfernen von Instanzen nur einen Teil des Traffics. Dieses Verhalten reduziert die Cache-Störung, die eine vollständige Neuverteilung verursachen würde.

Die offizielle Routing-Konfiguration bestätigt dieses Überlastungsverhalten. Sie führt zufällige, least-outstanding-requests- und prefix-aware Strategien als unterstützte Optionen auf.

Dies ist mehr als eine praktische Einstellung, da sich dadurch verändert, wer ein dauerhaftes Systemproblem behandelt. Teams mussten bisher Session Affinity schaffen, spezialisierte Router bereitstellen oder eine geringere Cache-Wiederverwendung akzeptieren. SageMaker bietet nun in seiner verwalteten Endpunktschicht inhaltssensitive Platzierung.

Die Unterscheidung grenzt diese Funktion außerdem vom Model Routing ab. Sie wählt nicht zwischen verschiedenen Foundation Models anhand von Preis, Qualität oder Aufgabentyp. Sie bestimmt, welche Instanz derselben bereitgestellten Arbeitslast eine Anfrage erhalten soll.

Dieser engere Umfang ist wichtig. AWS behauptet nicht, dass ein einzelner Schalter jeden Teil des LLM-Servings optimiert. Das Unternehmen adressiert wiederholte Prefill-Arbeit, die besonders teuer wird, wenn Anwendungen jeder Anfrage langen, wiederkehrenden Kontext beifügen.

Das Latenzergebnis von 77 % stammt aus langen gemeinsamen Prompts

AWS erzielte die größte Verbesserung, wenn jede Anfrage ein Präfix mit 8.000 Tokens wiederverwendete – ein Benchmark, der Cache-Lokalität begünstigt.

Das Unternehmen verglich prefix-aware routing mit der standardmäßigen zufälligen Strategie von SageMaker. Der Test nutzte Llama 3.1 70B Instruct, sieben ml.p5.48xlarge-Instanzen und vLLM mit aktiviertem Prefix Caching.

AWS führte 16 Konfigurationen über Single-Model-Endpunkte, Inference-Component-Endpunkte, die native Invoke API und eine OpenAI-kompatible API hinweg aus. Das Unternehmen berichtete, dass alle Tests erfolgreich abgeschlossen wurden.

Die stärksten Ergebnisse kamen aus Workloads mit langem Kontext, die eine Stunde lang aufrechterhalten wurden. Jede Anfrage teilte ein Präfix mit 8.000 Tokens und erzeugte damit einen großen Block wiederholter Berechnung, den der Cache eliminieren konnte.

Unter diesen Bedingungen sank laut AWS die P50-Zeit bis zum ersten Token zwischen 71 % und 77 %. P50 ist der Medianwert; das bedeutet, dass die Hälfte der gemessenen Anfragen schneller und die andere Hälfte langsamer antwortete.

Die P90-Zeit bis zum ersten Token sank zwischen 33 % und 37 %. Dieses Perzentil repräsentiert einen langsameren Teil der Anfrageverteilung und ist daher für Service-Level-Ziele oft wichtiger. Die geringere P90-Verbesserung deutet darauf hin, dass Routing nicht jede Ursache von Tail-Latenz beseitigen kann.

AWS berichtete, dass die KV-Cache-Hit-Raten von ungefähr 25 % auf bis zu 82 % stiegen. Der Durchsatz erhöhte sich um 15 % bis 16 % und zeigt damit, dass übersprungene Prefill-Arbeit auch Verarbeitungskapazität freisetzte.

Diese Werte bilden das zentrale Argument für Amazon SageMaker prefix-aware routing. Der Gewinn bei der medianen Latenz ist bemerkenswert, doch die Veränderung der Cache-Hit-Rate erklärt, warum er entstand. Der Router machte vorhandene gecachte Berechnungen häufiger erreichbar.

Bei kürzeren ShareGPT-artigen Unterhaltungen mit variabler Länge waren die Ergebnisse moderater. Über Läufe von 30 Minuten verbesserte sich die mediane Zeit bis zum ersten Token zwischen 13 % und 16 %. Der Durchsatz stieg lediglich um 1,7 % bis 2 %.

Die P90-Latenz verbesserte sich in diesen kürzeren Tests dennoch zwischen 24 % und 37 %. Laut AWS stiegen die Cache-Hit-Raten von rund 30 % auf 80 %. Jeder erfolgreiche Hit übersprang jedoch weniger Arbeit, weil die wiederverwendbaren Präfixe kürzer waren.

Dieser Kontrast ist das nützlichste Detail im AWS-Benchmark. Prefix-aware Platzierung ist kein fester Multiplikator für jede LLM-Anwendung. Ihr Wert hängt davon ab, wie viel Kontext sich wiederholt und wie aufwendig dessen Verarbeitung ist.

Der gemeldete Routing-Overhead lag zwischen 1,3 und 1,9 Millisekunden pro Anfrage. AWS maß während der Tests Modellzeiten bis zum ersten Token zwischen 63 und 280 Millisekunden. In diesem Bereich beanspruchte die Routing-Berechnung einen relativ kleinen Anteil der Antwortzeit.

Auch der Traffic blieb in den getesteten Szenarien ausgewogen. Jede der sieben Instanzen erhielt zwischen 13,3 % und 15,4 % der Anfragen. Eine ideale Aufteilung würde jeder Instanz etwa 14,3 % zuweisen.

Dieses Ergebnis begegnet dem offensichtlichsten Einwand gegen Präfix-Affinität. Das Zusammenhalten übereinstimmender Anfragen kann Hotspots erzeugen, wenn ein Präfix unverhältnismäßig populär wird. AWS erklärt, sein Überlastungsschwellenwert habe dieses Problem im Benchmark verhindert.

Dennoch müssen die Zahlen sorgfältig eingeordnet werden. AWS erstellte und veröffentlichte die Tests, und keine unabhängige Organisation hat die gemeldeten Gewinne bestätigt. Das Unternehmen präsentierte zudem keine breite Sammlung von Produktions-Traces unabhängiger Kunden.

Der Test mit langem Kontext erzeugt bewusst umfangreiche Wiederverwendung. Das eignet sich, um die beabsichtigte Wirkung der Funktion zu messen, repräsentiert aber nicht jeden Endpunkt. Ein Dienst, der unabhängige, kurze Prompts verarbeitet, würde deutlich weniger wiederverwendbare Arbeit bieten.

Der Benchmark vergleicht die neue Strategie außerdem mit zufälligem Routing. Teams, die bereits einen eigenen cache-bewussten Router, Session Affinity oder einen verteilten KV-Cache nutzen, könnten einen geringeren zusätzlichen Nutzen sehen. Ihre relevante Ausgangsbasis ist nicht zwangsläufig der SageMaker-Standard.

Die klarste Schlussfolgerung ist daher bedingt. Die Funktion kann die Latenz deutlich senken, wenn Anfragen lange Präfixe teilen und die Serving-Engine ihre KV-Zustände bewahrt. Für vielfältigen, cache-resistenten Traffic gibt sie nicht dasselbe Versprechen.

Dieses bedingte Ergebnis spiegelt breitere Forschung zu Prefix Caching wider. Ein NeurIPS-Paper aus dem Jahr 2025 stellte fest, dass intelligentere Cache-Aufbewahrung die Effizienz verbessert, dokumentierte jedoch auch begrenzte Cache-Kapazität und Herausforderungen bei der Verdrängung.

Routing löst einen Teil dieses Systems. Es erhöht die Wahrscheinlichkeit, dass eine Anfrage eine Instanz mit relevantem Zustand erreicht. Es kann nicht garantieren, dass dieser Zustand noch im Speicher vorhanden ist, wenn die Anfrage eintrifft.

Cache-bewusstes Routing setzt herkömmliche Load Balancer unter Druck

Die Einführung legt eine Diskrepanz zwischen konventioneller Anfrageverteilung und dem zustandsbehafteten Verhalten moderner LLM-Inferenz offen.

Traditionelle Webdienste betrachten austauschbare Replikate häufig als wünschenswertes Design. Ein Load Balancer kann jede Anfrage mittels Zufall oder Warteschlangentiefe an jeden fehlerfreien Server senden, um Arbeit zu verteilen. Die Anwendung sollte unabhängig von der Platzierung dasselbe Ergebnis liefern.

LLM-Replikate können gleichwertige Antworten erzeugen, dabei aber sehr unterschiedliche Vorbereitungskosten haben. Eine GPU könnte die Aufmerksamkeitszustände für einen langen Vertrag, eine Codedatei oder eine Unterhaltung bereits vorhalten. Eine andere GPU müsste diese Zustände vor der Erzeugung ihres ersten Tokens erst rekonstruieren.

Cache-blindes Routing ignoriert diesen Unterschied. Es kann die leerste Warteschlange auswählen und dennoch die Maschine mit der meisten duplizierten Prefill-Arbeit wählen. Eine lokal stärker ausgelastete Maschine könnte schneller antworten, weil sie bereits das passende Präfix enthält.

Diese Spannung ist nicht auf AWS beschränkt. Auch Open-Source-Inferenzsysteme behandeln Anfragescheduling und Cache-Standort als miteinander verbundene Probleme. Die Entwicklung umfasst vLLM-basierte Stacks, spezialisierte Kubernetes-Gateways, verteilte Caches und Prefill-Decode-Architekturen.

AWS hat innerhalb von SageMaker HyperPod eine aufwendigere Variante diskutiert. Sein intelligentes Routing unterstützt prefix-aware, KV-aware und Round-Robin-Strategien neben mehrstufigem Caching.

Das HyperPod-Design kann zwischengespeicherte Präfixe nachverfolgen und Speicher über den GPU-Arbeitsspeicher hinaus erweitern. Es nutzt lokalen CPU-Speicher als eine Cache-Stufe und kann eine verteilte zweite Stufe bereitstellen. Dieser Ansatz bedient größere, von Kubernetes verwaltete Infrastrukturen mit umfassenderer operativer Kontrolle.

Die neue Funktion für Echtzeit-Endpunkte erfüllt eine einfachere Rolle. Sie hält Anfragen in der Nähe wahrscheinlicher Cache-Standorte, ohne dass Nutzer einen Inferenzcluster oder einen verteilten Cache betreiben müssen. Dadurch wird die Technik für Teams zugänglich, die standardmäßige verwaltete Endpunkte verwenden.

Die verwaltete Umgebung setzt kundenspezifische Routing-Projekte zudem in spezifischer Weise unter Druck. AWS bietet nicht zwangsläufig jedes Platzierungssignal oder jede Cache-Verwaltungsrichtlinie an, die solche Projekte unterstützen. Es reduziert jedoch den Aufwand, der nötig ist, um einen bedeutenden Teil des Nutzens zu erzielen.

Für Plattformteams kann das die Make-or-Buy-Abwägung verändern. Ein kundenspezifischer Router erfordert Bereitstellung, Upgrades, Telemetrie, Fehlerbehandlung und Abstimmung mit der Autoskalierung. Eine produktionsreife Konfiguration lässt sich leichter übernehmen, wenn ihre Einschränkungen zur Arbeitslast passen.

Der Wettbewerbsdruck erreicht auch andere Anbieter verwalteter Inferenzdienste. Kunden können eine LLM-Plattform zunehmend danach bewerten, wie gut sie Routing, Caching und Skalierung koordiniert – nicht nur nach verfügbaren Modellen oder Beschleunigertypen.

Das ist wichtig, weil die Effizienz der Inferenz zunehmend vom gesamten Serving-Pfad abhängt. Modellquantisierung kann den Speicherverbrauch senken. Kontinuierliches Batching kann aktive Anfragen zusammenfassen. Spekulatives Decoding kann unter geeigneten Bedingungen die Token-Generierung beschleunigen.

Cache-bewusste Platzierung adressiert eine andere Quelle der Verschwendung. Sie verhindert die wiederholte Verarbeitung von Prompts, die das System bereits abgeschlossen hat. Diese Methoden können nebeneinander bestehen, weshalb Infrastrukturanbieter Anreize haben, sie als integrierten Stack anzubieten.

Die Arbeit von AWS mit disaggregated inference veranschaulicht diese Richtung. Die Architektur trennt rechenintensives Prefill von speicherbandbreitenintensivem Decoding und koordiniert KV-Übertragungen zwischen Workern.

Dieses weiterentwickelte Design behandelt Inferenz als Problem verteilter Systeme. Routing-Entscheidungen berücksichtigen Warteschlangendruck, Cache-Standort und spezialisierte Worker-Rollen. Ein generischer Netzwerk-Load-Balancer verfügt nicht über diese Signale auf Anwendungsebene.

Dennoch hat gewöhnliches Routing weiterhin seine Berechtigung. Zufällige Platzierung bleibt geeignet, wenn Anfragen unabhängig sind oder das Modell keinen wirksamen Präfix-Cache besitzt. Least-Outstanding-Requests kann helfen, wenn Verarbeitungszeiten variieren und geteilter Kontext wenig Lokalität bietet.

Präfix-bewusstes Routing ist daher kein universeller Ersatz. Es ist eine arbeitslastspezifische Strategie, die wiederverwendbaren Kontext über eine perfekt gleichmäßige Verteilung von Anfragen stellt. Die Überlastkontrolle von AWS versucht, beide Ziele auszubalancieren.

Die Funktion dürfte Teams interessieren, die Dokumentenassistenten und interne Suchsysteme entwickeln. Solche Anwendungen präsentieren wiederholt dieselben Handbücher, Richtlinien, Spezifikationen oder Projektunterlagen, bevor sich die Frage ändert.

Teams, die eine durchsuchbare Wissensdatenbank aufbauen, sollten dieses Muster erkennen. Die Retrieval-Qualität bestimmt, welcher Kontext in den Prompt gelangt, während das Routing beeinflusst, ob die Verarbeitung dieses Kontexts wiederverwendet werden kann.

Multi-Turn-Agenten sind ein weiterer überzeugender Anwendungsfall. Jede neue Runde enthält häufig frühere Nachrichten, Tool-Anweisungen und den angesammelten Aufgabenstatus. Dieser wachsende gemeinsame Beginn verteuert die Prefill-Phase, schafft jedoch zugleich eine Möglichkeit zur Cache-Wiederverwendung.

Coding-Assistenten weisen ebenfalls ausgeprägte Lokalität auf. Mehrere Anfragen können Repository-Anweisungen, eine geöffnete Datei, benachbarte Symbole und den Gesprächsverlauf teilen. Die abschließende Completion-Anfrage ändert sich, doch ein großer Teil ihres vorangehenden Kontexts bleibt stabil.

Diese Muster erklären, warum Routing jetzt zu einem Wettbewerbsmerkmal geworden ist. Längere Kontextfenster haben Anwendungen dazu veranlasst, bei jedem Aufruf mehr Referenzmaterial mitzusenden. Agent-Workflows wiederholen zudem umfangreiche Anweisungen und Verläufe über viele Schritte hinweg.

Der neue Engpass ist nicht allein die Anzahl generierter Tokens. Es geht auch darum, große, vertraute Eingaben wiederholt vorzubereiten, bevor die Generierung beginnt. Dadurch wird die Zeit bis zum ersten Token zu einem eigenständigen Produktaspekt neben der Geschwindigkeit der Token-Generierung.

Was der Benchmark nicht garantiert

Präfix-bewusstes Routing erhöht die Wahrscheinlichkeit einer Cache-Wiederverwendung, doch Serialisierung, Eviction, Mandantenisolation und ungleich verteilter Traffic können den erwarteten Vorteil zunichtemachen.

Die erste Unsicherheit betrifft die Eignung der Arbeitslast. Ein Endpunkt, der nicht zusammenhängende Prompts bedient, könnte nur wenige nützliche Präfixübereinstimmungen erzeugen. In dieser Umgebung fügt der Router geringe Entscheidungskosten hinzu, ohne viel Modellberechnung einzusparen.

Selbst oberflächlich ähnliche Prompts können nicht übereinstimmen. Die native Invoke API von SageMaker stützt ihr Routing-Präfix auf Bytes aus dem Request-Body. Unterschiede bei JSON-Leerzeichen, Feldreihenfolge oder Formatierung können diese Bytes verändern.

Anwendungen müssen Anfragen daher konsistent serialisieren. Ein stabiler System-Prompt reicht nicht aus, wenn Client-Bibliotheken ihn unterschiedlich verpacken. Teams, die mehrere Dienste oder Programmiersprachen verwenden, sollten testen, ob äquivalente Anfragen identische Routing-Eingaben erzeugen.

Die OpenAI-kompatible API verwendet stattdessen Zeichen, die aus Nachrichtentext extrahiert werden. Das reduziert die Empfindlichkeit gegenüber rohem JSON, obwohl Änderungen innerhalb der Nachrichtenfolge weiterhin das Präfix beeinflussen. Dynamische Metadaten am Anfang eines Prompts können verwandte Anfragen auseinanderstreuen.

Auch die Präfixlänge schafft ein weiteres Abstimmungsproblem. SageMaker akzeptiert einen konfigurierten Bereich von 1.024 bis 65.536. Für die native API steht dieser Wert für Bytes, für die OpenAI-kompatible API für Zeichen.

Eine kurze Auswahl kann zu viele Anfragen um einen generischen Beginn gruppieren. Dadurch steigt das Risiko, übermäßigen Traffic auf eine Instanz zu lenken. Der Concurrency-Schwellenwert löst dann Overflow aus und opfert Cache-Affinität zugunsten der Kapazität.

Eine lange Auswahl erzeugt das gegenteilige Problem. Kleine Unterschiede innerhalb des ausgewählten Bereichs können Anfragen trennen, die ansonsten teuren Kontext teilen. Die Flotte bleibt ausgeglichen, doch die Verbesserung der Cache-Trefferquote schrumpft.

Der richtige Wert hängt von der tatsächlichen Prompt-Struktur ab. Teams müssen wissen, wo gemeinsame Anweisungen enden und einzigartiges Material beginnt. Sie benötigen außerdem genug unterscheidenden Inhalt, um zu verhindern, dass eine häufig verwendete Vorlage zu einem einzigen Routing-Bucket wird.

Die Cache-Eviction liegt weiterhin außerhalb der direkten Kontrolle des Routers. GPU-Speicher ist begrenzt, und Modellserver müssen KV-Blöcke zurückfordern, wenn neue Anfragen eintreffen. Eine Anfrage kann ihre erwartete Instanz erreichen, nachdem der relevante Eintrag bereits verschwunden ist.

Die zuvor zitierte Forschung zum Präfix-Cache ergab, dass die Eviction-Richtlinie die Trefferquoten wesentlich beeinflusst. Das deutet darauf hin, dass Platzierung und Vorhaltung gemeinsam bewertet werden müssen.

Autoskalierung schafft eine weitere Quelle von Cache-Churn. AWS zufolge bleibt der Großteil des Traffics bei Flottenänderungen zugeordnet, doch neue Instanzen beginnen ohne nützliche lokale Präfixe. Scale-out-Ereignisse können die Trefferquoten vorübergehend senken, bis beliebte Kontexte diese Maschinen aufgewärmt haben.

Scale-in-Ereignisse können Maschinen entfernen, die wertvolle Einträge enthalten. Stabiles Remapping begrenzt die Unterbrechung, kann jedoch Cache-Inhalte auf einer verschwindenden Instanz nicht bewahren. Plötzliche Traffic-Änderungen könnten das Benchmark-Ergebnis im stabilen Zustand daher abschwächen.

Beliebte Präfixe schaffen außerdem einen grundlegenden Konflikt. Jede passende Anfrage auf einer Maschine zu halten maximiert die Lokalität, bis diese Maschine gesättigt ist. Den Traffic zu verteilen schützt die Latenz unter Last, dupliziert jedoch zwischengespeicherte Berechnung auf mehr Instanzen.

Der ConcurrencyThreshold von SageMaker macht diesen Zielkonflikt direkt sichtbar. Der zulässige Wert reicht von 1 bis 1.024 gleichzeitig laufenden Anfragen. Ein konservativer Schwellenwert begünstigt die Lastverteilung, während eine höhere Einstellung die Affinität länger schützt.

Es gibt keinen einzigen korrekten Schwellenwert für jedes Modell. Große Prompts, lange Ausgaben, Quantisierungseinstellungen, Tensorparallelismus und Batching-Verhalten beeinflussen allesamt die sichere Parallelität. Betreiber müssen den Wert anhand ihrer eigenen Service-Level-Ziele abstimmen.

Die Mandantentrennung erfordert ähnliche Aufmerksamkeit. Zwei Organisationen könnten identische Systemanweisungen verwenden und dennoch eine unabhängige operative Behandlung benötigen. SageMaker unterstützt eine optionale präfix-bewusste Kennung, um ihre Routing-Gruppen zu trennen.

Nutzer der nativen API können X-Amzn-SageMaker-Prefix-Aware-Id mit bis zu 64 ASCII-Zeichen bereitstellen. OpenAI-kompatible Anfragen können das Feld prompt_cache_key verwenden. AWS kombiniert die Kennung bei der Auswahl einer Instanz mit dem Präfix.

Diese Funktion bietet Routing-Isolation, doch die Ankündigung von AWS sollte nicht als weitreichende Aussage über Datenisolation in jedem Serving-Framework gelesen werden. Teams müssen weiterhin das Container-Verhalten, die Speicherverwaltung, das Logging und ihr vollständiges Sicherheitsmodell bewerten.

Die Funktion benötigt zudem mindestens zwei Instanzen, um einen bedeutenden Routing-Unterschied zu erzeugen. Bei einer Instanz erreicht jede Anfrage ohnehin denselben Ort. Kleine Deployments gewinnen daher nichts durch die Platzierungsaffinität selbst.

AWS sagt, dass auf der Endpunkt-Routing-Ebene keine Änderungen am Modellcontainer erforderlich sind. Das Serving-Framework benötigt jedoch weiterhin funktionierendes Präfix-Caching. Eine inkompatible oder falsch konfigurierte Engine erhält lokalisierten Traffic, ohne die zugrunde liegenden Berechnungen wiederzuverwenden.

Die Kombination aus Llama 3.1 70B und vLLM im Benchmark bestätigt eine wichtige Konfiguration. Sie belegt keine identischen Verbesserungen für jede Architektur, Runtime, Quantisierungsmethode, Adapter-Konfiguration oder Prompt-Verteilung.

Dynamische Low-Rank-Adaptation-Adapter fügen eine weitere Platzierungsebene hinzu. AWS zufolge erfolgt die präfix-bewusste Auswahl innerhalb der Instanzen, die einen angeforderten Adapter bereits enthalten. Diese engere Menge geeigneter Instanzen kann die Ausgleichsoptionen des Routers beschränken.

Schließlich ist die sichtbarste Kennzahl nicht die gesamte Nutzererfahrung. Die Zeit bis zum ersten Token beeinflusst die wahrgenommene Reaktionsfähigkeit, insbesondere bei interaktiven Produkten. Sie beschreibt nicht unmittelbar Ausgabequalität, gesamte Generierungszeit oder Zuverlässigkeit des Abschlusses.

Die Durchsatzverbesserungen waren ebenfalls deutlich kleiner als die Gewinne bei der Medianlatenz. Der Long-Context-Durchsatz stieg in AWS-Tests um bis zu 16 %, während der Short-Context-Durchsatz um nicht mehr als 2 % zunahm. Die Kapazitätsplanung sollte die relevante Kennzahl nutzen und nicht allein die Schlagzeilenlatenz.

Aus diesen Gründen sollte die Zahl von 77 % als Spitzenergebnis aus dem AWS-Benchmark behandelt werden. Sie belegt, dass Lokalität erheblich sein kann, ist jedoch keine Leistungsgarantie für jeden SageMaker-Endpunkt.

Drei Signale werden zeigen, ob die Gewinne in der Produktion bestehen

Der nächste Test besteht darin, ob Kunden die Cache-Treffergewinne von AWS reproduzieren können, ohne instabile Hotspots oder umfangreiche Prompt-Engineering-Arbeit zu verursachen.

Das erste Signal ist Produktions-Telemetrie zum Cache. Teams sollten zufälliges und präfix-bewusstes Routing anhand desselben Traffic-Traces, derselben Flottengröße, Serving-Engine und Autoskalierungsrichtlinie vergleichen. Die Medianlatenz allein wird das Ergebnis nicht erklären.

Die KV-Cache-Trefferquote sollte zusammen mit geringerer Prefill-Latenz steigen. Betreiber sollten außerdem P90- und P99-Zeit bis zum ersten Token, Warteschlangentiefe, Overflow-Häufigkeit und die Traffic-Verteilung auf Instanzebene verfolgen.

Wenn sich Cache-Treffer verbessern und die Tail-Latenz stabil bleibt, wird das Kernargument von AWS stärker. Sinkt die Medianlatenz, während Overflow oder P99-Latenz schlechter werden, benötigt der Nutzen engere Einsatzkriterien.

Der Vergleich sollte Kaltstarts und Skalierungsphasen einschließen. Ein einstündiger Benchmark im stabilen Zustand kann die Aufwärmkosten verbergen, die nach Deployments, Instanzersetzung oder plötzlichem Scale-out auftreten. Reale Dienste durchlaufen diese Übergänge regelmäßig.

Das zweite Signal betrifft breitere Runtime- und Modellevidenz. AWS testete ein großes offenes Modell mit vLLM, doch Kunden betreiben unterschiedliche Architekturen und Container. Ergebnisse bei kleineren Modellen, Mixture-of-Experts-Modellen, quantisierten Modellen und Workloads mit langen Ausgaben werden die Reichweite der Funktion verdeutlichen.

Workloads mit kurzem Kontext verdienen besondere Aufmerksamkeit, da AWS dort bereits geringere Durchsatzgewinne festgestellt hat. Falls unabhängige Tests nur bescheidene Verbesserungen bestätigen, wird prefixbewusstes Routing vor allem für dokumentenintensive und agentische Anwendungen wertvoll bleiben.

Zeigen sich bei unterschiedlichen Modellen und Prompt-Mustern vergleichbare Vorteile, wird Routing-Lokalität wie eine Standardanforderung für Managed Inference wirken. Andere Anbieter werden unter Druck geraten, ähnliche Konfigurations- und Observability-Möglichkeiten bereitzustellen.

Das dritte Signal ist die Entwicklung von heuristischer Präfix-Affinität hin zu explizitem Cache-State-Routing. Präfix-Ähnlichkeit schätzt, wo sich nützlicher Zustand befinden sollte. KV-bewusste Systeme können tatsächliche Blöcke, Eviction-Ereignisse oder Transfers über die gesamte Flotte hinweg verfolgen.

AWS bietet über SageMaker HyperPod bereits umfassendere cachebewusste Optionen. Dessen Echtzeit-Endpunkte könnten letztlich detailliertere Cache-Signale, Unterstützung für verteilte Caches oder adaptivere Richtlinien bereitstellen. Wettbewerber und Open-Source-Projekte verfolgen ähnliche Ansätze.

Falls Managed Endpoints ein präzises Bewusstsein für den Cache-Zustand erhalten, wird die aktuelle Veröffentlichung wie eine zugängliche erste Ebene eines größeren Wandels erscheinen. Falls die Komplexität diese Funktionen auf spezialisierte Cluster beschränkt, könnte prefixbewusstes Routing der praktische Mittelweg bleiben.

Für Entwickler besteht die unmittelbare Maßnahme eher im Messen als in einer Migration auf Grundlage von Annahmen. Identifizieren Sie wiederholte Prompt-Abschnitte, normalisieren Sie die Serialisierung, aktivieren Sie Prefix Caching auf Engine-Ebene und testen Sie mehrere Präfixlängen. Vergleichen Sie Latenzverteilungen, nicht nur Durchschnittswerte.

Unternehmenskunden sollten Anbieter fragen, wo die Routing-Intelligenz liegt und welche Metriken sie offenlegen. Eine Plattform, die Prefix Caching bewirbt, ohne die Lokalität über Replikate hinweg zu bewahren, könnte bei Skalierung enttäuschende Trefferquoten liefern.

Wissensarbeiter werden den Effekt indirekt erleben. Dokumentenassistenten, Coding-Tools und lang laufende Agents sollten früher zu antworten beginnen, wenn sie wiederholt denselben Kontext verwenden. Der Gewinn sollte vor dem ersten generierten Token sichtbar werden, nicht unbedingt während der gesamten Antwort.

Amazon SageMaker prefix-aware routing liefert ein überzeugendes Argument dafür, dass Load Balancing wiederverwendbaren LLM-Kontext verstehen muss. Die Ergebnisse von AWS zeigen, wie kostspielig cache-blinde Platzierung bei einem gemeinsamen Präfix von 8.000 Tokens werden kann.

Die offene Frage ist, wie häufig realer Traffic dieser günstigen Struktur entspricht. Teams sollten ihre eigenen Traces testen, einschließlich Skalierungsereignissen und stark genutzter Präfixe, bevor sie die Schlagzeilenzahl als Betriebsprognose behandeln.

Beobachten Sie die Cache-Trefferquote, die langsamsten Requests und die Häufigkeit von Overflow-Routing. Zusammen zeigen diese Kennzahlen, ob SageMaker nützlichen Kontext bewahrt oder lediglich Traffic neu verteilt.