AWS zielt mit SageMaker Inference auf Verzögerungen durch HyperPod-Model-Caching und Prefix-Routing

AWS fügt zwei Infrastruktur-Funktionen hinzu, die auf getrennte, aber miteinander verbundene Engpässe beim Serving großer Sprachmodelle abzielen: Model-Caching für Amazon SageMaker HyperPod und prefixbewusstes Routing für SageMaker Inference. Die erste soll die Zeit verkürzen, die benötigt wird, um neue Inference-Pods online zu bringen; die zweite soll die Antwortlatenz verringern, indem häufig wiederverwendete Prompt-Berechnung auf derselben Instanz gehalten wird.

Die Änderungen sind vor allem für Teams relevant, die große Modelle unter wechselndem Traffic betreiben. Ohne Caching kann ein Scale-out-Ereignis neue Nodes dazu zwingen, mehrere Gigabyte große Container-Images und Modellgewichte herunterzuladen, bevor sie Anfragen bedienen können. Ohne Routing, das den Prompt-Inhalt berücksichtigt, kann der Prefix-Cache eines Serving-Frameworks unterausgelastet bleiben, weil identische Prompt-Abschnitte über einen gesamten Cluster verteilt werden.

Beide Ankündigungen stammen aus dem AWS Machine Learning Blog; die Leistungszahlen und operativen Aussagen sind also von AWS berichtet und nicht unabhängig verifiziert. Zusammen skizzieren sie einen stärker koordinierten Ansatz, um sowohl Inference-Cold-Starts als auch die Zeit bis zum ersten Token im laufenden Betrieb zu reduzieren.

HyperPod-Caching schließt die Scale-out-Lücke

AWS sagt, dass die Modellbereitstellung auf SageMaker HyperPod durch zwei aufeinanderfolgende Downloads verzögert werden kann. Kubernetes zieht zuerst ein Inference-Server-Image aus dem Amazon Elastic Container Registry, danach lädt der Server Modellgewichte aus einer Quelle wie Amazon S3, Amazon FSx for Lustre, Hugging Face Hub oder JumpStart herunter.

Bei kleineren Modellen kann dieser Prozess Minuten dauern. AWS nennt als Beispiel ein 145-GB-Modell, dessen Gewichts-Download aus Amazon S3 je nach Netzwerkbedingungen mehr als 20 Minuten dauern kann. Für ein Modell wie DeepSeek-R1, das AWS im zitierten Szenario als mehr als 600 GB schwer beschreibt, kann der Prozess 30 Minuten oder länger dauern. Allein das Ziehen des Container-Images wird von AWS bei typischen mehrgigabytegroßen Inference-Images auf fünf bis sieben Minuten geschätzt.

Diese Verzögerung erzeugt eine Diskrepanz zwischen Autoscaling und tatsächlicher Kapazität. Ein HorizontalPodAutoscaler kann schnell zusätzliche Pods anfordern, aber diese Pods können keinen Traffic annehmen, bis ihre Images und Gewichte verfügbar sind. Ein plötzlicher Anfrageschub kann daher eine operative Reaktion auslösen, die erst Dutzende Minuten später eintrifft.

Die neue Model-Caching-Funktion lädt Gewichte vorab auf lokalen NVMe-Speicher auf den Ziel-Nodes. AWS sagt, der HyperPod Inference Operator lade die Gewichte im Voraus herunter, markiere Nodes als cache-bereit und warte, bis die Ziel-Nodes den Vorgang abgeschlossen haben, bevor er die Inference-Bereitstellung erstellt. Sobald ein Pod auf einem vorbereiteten Node startet, kann er lokal mit ungefähr 7 GB pro Sekunde lesen, statt das Modell über das Netzwerk herunterzuladen.

AWS bietet außerdem einen unabhängigen Image-Cache an. Ein DaemonSet zieht das Inference-Container-Image vorab auf die Nodes, sodass spätere Pods den Download aus dem Amazon Elastic Container Registry überspringen können. Mehrere Deployments, die dasselbe Image verwenden, können diesen Cache gemeinsam nutzen, während der Operator Referenzen und Bereinigung verwaltet.

Wie sich die beiden Caching-Systeme in der Produktion verhalten

Gewichts- und Image-Caching haben nicht dieselbe Deployment-Semantik. AWS sagt, dass das Caching der Gewichte die Erstellung der Inference-Bereitstellung verzögern kann, bis alle Ziel-Nodes bereit sind, während Image-Caching die Erstellung der Bereitstellung nicht blockiert. Ein Pod kann daher starten, bevor ein Image-Cache auf einem bestimmten Node fertig ist, und auf einen normalen Image-Pull zurückfallen.

Beide Mechanismen verwenden bevorzugte statt zwingender Platzierung. Pods werden nach Möglichkeit zu Nodes mit warmen Daten geleitet, aber sie werden nicht daran gehindert, anderswo zu laufen. Wenn ein schnelles Scale-out die Zahl der vorbereiteten Nodes übersteigt, kann ein Pod die ursprüngliche Modellquelle nutzen und sein Image normal ziehen. Der Kompromiss ist ein langsamerer Start, nicht ein fehlgeschlagenes Deployment.

Der Operator verwaltet zwei zugrunde liegende Custom Resources: ModelDataCacheConfig für Modellgewichte und ModelImageCache für Container-Images. Nutzer aktivieren das Caching über modelCacheConfig in einer InferenceEndpointConfig- oder JumpStartModel-Ressource, statt diese Lifecycle-Objekte direkt zu verwalten.

AWS sagt außerdem, dass Cache-Updates behandelt werden, wenn sich eine Modellquelle oder ein Image ändert. Der Operator erstellt einen neuen Cache, rollt das aktualisierte Deployment aus und entfernt dann den alten Cache. Das soll veraltete Gewichte verhindern und gleichzeitig Übergänge ohne Ausfallzeit unterstützen, auch wenn das praktische Ergebnis weiterhin von verfügbarem Node-Speicher und der Zeit abhängt, die zum Befüllen des Ersatz-Caches erforderlich ist.

Prefixbewusstes Routing hält LLM-Prompt-Caches nutzbar

Die zweite SageMaker-Änderung zielt auf eine andere Ebene des Serving-Stacks. Viele LLM-Anfragen enthalten ein langes, wiederholtes Präfix – etwa Systemanweisungen, abgerufene Dokumente, Gesprächsverlauf oder Quellcode – gefolgt von einem kurzen, nutzerspezifischen Suffix. Frameworks wie vLLM und TensorRT-LLM können den berechneten Key-Value- oder KV-Cache für dieses wiederholte Präfix erneut verwenden.

Eine zufällige Verteilung der Anfragen schwächt diesen Vorteil bei einem Multi-Instanz-Endpoint. Wenn aufeinanderfolgende Anfragen mit demselben Präfix auf verschiedenen Maschinen landen, muss jede Instanz den gemeinsamen Kontext möglicherweise erneut berechnen. Die neue prefixbewusste Routing-Strategie von SageMaker Inference prüft den Anfang einer Anfrage und sendet passende Präfixe konsistent an dieselbe Instanz.

AWS sagt, dass die Funktion den Cluster auch vor einem übermäßig beliebten Präfix schützen kann. Wenn die bevorzugte Instanz ihr konfigurieren Concurrent-Limit erreicht, kann die Anfrage an eine weniger ausgelastete Instanz umgeleitet werden. Das mag für eine Anfrage einen Cache-Hit opfern, verhindert aber, dass sich der Traffic auf einer einzelnen Maschine konzentriert. AWS sagt außerdem, dass das Hinzufügen oder Entfernen von Instanzen nur einen begrenzten Teil des Traffics verschieben sollte, was dazu beiträgt, die Cache-Lokalität während des Skalierens zu bewahren.

Die Strategie wird pro Production-Variant konfiguriert und kann über die Endpoint-Konfiguration geändert werden, ohne das Modell neu bereitzustellen. AWS bietet weiterhin zufälliges Routing als Standard an, ebenso wie Routing nach den wenigsten ausstehenden Anfragen für Workloads mit variierenden Anfragedauern. Prefixbewusstes Routing ist speziell auf LLM-Workloads mit gemeinsam genutztem führenden Kontext und aktiviertem Prefix-Cache ausgerichtet.

Belege, Benchmarks und Grenzen

AWS benchmarkte prefixbewusstes Routing gegen zufälliges Routing mit Llama 3.1 70B Instruct auf sieben ml.p5.48xlarge-Instanzen mit aktiviertem vLLM und Prefix-Caching. Über 16 Testkonfigurationen mit unterschiedlichen Endpoint- und API-Anordnungen hinweg berichtet AWS von einer Reduzierung der mittleren Zeit bis zum ersten Token um bis zu 77 %, einem Durchsatzplus von bis zu 16 % und einem Anstieg der KV-Cache-Hit-Rate von etwa 25 % auf mehr als 80 %.

Das sind vom Anbieter berichtete Benchmark-Ergebnisse, keine unabhängige Auswertung. AWS sagt, der Traffic sei in den Tests ausgewogen geblieben, wobei jede Instanz zwischen 13,3 % und 15,4 % der Anfragen erhalten habe. Außerdem berichtet AWS von zusätzlichen Routing-Kosten von 1,3 bis 1,9 Millisekunden pro Anfrage, verglichen mit Modell-Zeiten bis zum ersten Token von 63 bis 280 Millisekunden in den getesteten Konfigurationen.

Der Nutzen hängt stark von der Workload-Struktur ab. AWS sagt, dass längere gemeinsame Präfixe größere Gewinne bringen, weil mehr Berechnung übersprungen werden kann. Zu den Anwendungsfällen, die AWS nennt, gehören RAG-Systeme, die wiederholt dasselbe Dokument abfragen, mehrstufige Gespräche, Vorlagen-Assistenten und Code-Vervollständigung. Workloads mit kurzen oder überwiegend einzigartigen Prompts sollten weniger Nutzen sehen.

Auch die HyperPod-Aussagen hängen von Bedingungen ab, die in der Quelle nicht vollständig spezifiziert sind, darunter Node-Verfügbarkeit, Cache-Befüllungszeit, Speicherkapazität, Modellformat und Netzwerkleistung während der anfänglichen Vorbefüllung. Der genannte Wechsel von Dutzenden Minuten auf Sekunden gilt, wenn ein Pod auf einem Node landet, auf dem die relevanten Daten bereits zwischengespeichert sind; ein unvorbereiteter Node folgt dem normalen Download-Pfad.

Was die Änderungen für Teams der KI-Infrastruktur bedeuten

Für Entwickler und Enterprise-Plattform-Teams trennen die Ankündigungen zwei Entscheidungen, die oft als ein Latenzproblem behandelt werden. Model-Caching verbessert die Elastizität: Neue Kapazität wird bei steigender Last schneller nutzbar. Prefixbewusstes Routing verbessert die Anfragedisziplin: Es kann wiederholte Prefill-Arbeit reduzieren, nachdem die Kapazität bereits online ist.

Die Kombination könnte für RAG-Anwendungen und Assistenten nützlich sein, die sowohl sprunghaften Traffic als auch große, wiederholte Kontexte haben. Ein Team könnte HyperPod-Caching einsetzen, um Nodes für das Scale-out vorzubereiten, und gleichzeitig prefixbewusstes Routing nutzen, um Dokument- oder Gesprächspräfixe über die aktive Flotte warm zu halten. Das ersetzt jedoch nicht die Notwendigkeit, die lokale NVMe-Kapazität zu dimensionieren, Concurrent-Limits zu konfigurieren oder Cache-Hit-Raten unter realem Traffic zu messen.

Es gibt auch Kosten- und Zuverlässigkeitsfragen, die Käufer testen sollten. Gewichte auf jedem Ziel-Node zu halten verbraucht lokalen Speicher und kann die Vorbereitungszeit erhöhen, bevor ein Deployment bereit ist. Präfix-Affinität kann die Latenz verbessern, bringt aber ein inhaltsabhängiges Routing-Verhalten mit sich, das Teams zusammen mit Warteschlangentiefe, Instanz-Auslastung, Cache-Belegung und Tail-Latenz beobachten sollten. Auch Datenschutz- und Data-Governance-Prüfungen können wichtig sein, weil Routing-Entscheidungen den Anfang von Anfrage-Payloads inspizieren, auch wenn AWS das Routing automatisch übernimmt.

Worauf als Nächstes zu achten ist

Teams, die die Funktionen evaluieren, sollten nach unabhängig reproduzierten Ergebnissen auf Modellen, Hardware und Prompt-Verteilungen suchen, die über den AWS-Test mit Llama 3.1 70B hinausgehen. Die nützlichsten Messwerte werden p95- und p99-Zeit bis zum ersten Token, Cache-Hit-Raten während des Scale-outs und den Anteil der Anfragen umfassen, die auf unvorbereiteten Nodes landen.

Auch operative Leitlinien zu lokaler NVMe-Dimensionierung, Cache-Warm-up-Orchestrierung und Multi-Modell-Clustern werden wichtig sein. Käufer sollten prüfen, wie sich die Cache-Vorbereitung auf Deployment-Rollouts, Node-Austausch, Spot- oder Unterbrechungsszenarien und schnelles Skalieren über die vorab geladene Flotte hinaus auswirkt.

Schließlich könnten AWS-Routing-Steuerungen auf Endpoint-Ebene an Bedeutung gewinnen, da gehostete Serving-Plattformen eher mit vorhersehbarer Latenz als nur mit Modellzugang konkurrieren. Das entscheidende Signal wird sein, ob Kunden diese Steuerungen verwenden können, ohne erhebliche Scheduling-Komplexität hinzuzufügen oder eine ausgewogene GPU-Auslastung zu opfern.

Creati.ai-Perspektive

AWS behebt zwei praktische Schwächen im LLM-Betrieb, statt eine neue Modellfähigkeit einzuführen. Das HyperPod-Model-Caching reduziert die Strafe für zusätzliches Kapazitätswachstum, während prefixbewusstes Routing eine bestehende Serving-Optimierung – die Wiederverwendung des KV-Caches – über mehrere Instanzen hinweg zuverlässiger macht.

Der stärkste Anwendungsfall sind vorhersehbare, kontextwiederholende Workloads mit genügend Traffic, um das Vorladen großer Modelle zu rechtfertigen. Für Teams mit überwiegend einzigartigen Prompts oder seltenen Deployments könnten Speicher- und Vorbereitungsaufwand die Gewinne überwiegen. Die Benchmark-Zahlen von AWS sind ermutigend, aber Infrastrukturkäufer sollten sie gegen ihre eigenen Prompt-Überschneidungen, Skalierungsmuster und Latenzziele validieren, bevor sie Caching als garantierte Verbesserung betrachten.