AWS zeigt auf SageMaker HyperPod einen interessanten nächsten Schritt für LLM-Inferenz: KV-Cache bleibt nicht mehr auf einen vLLM-Pod beschränkt. Eine dreistufige Architektur aus GPU-Speicher, Host-RAM und einem gemeinsam genutzten NVMe-Pool soll Prefix-Caches zwischen Replikas wiederverwendbar machen.
Das ist keine neue Managed-Option zum Anklicken, sondern eine detailliert beschriebene Referenzimplementierung mit Curvine, LMCache und dem SageMaker HyperPod Inference Operator. Gerade deshalb ist sie für Teams interessant, die vLLM unter hoher Parallelität betreiben: Sie macht sichtbar, wo der nächste Infrastrukturhebel nach Prefix Caching im einzelnen Pod liegt.
Das Problem: Ein warmer Cache endet heute meist am Pod
vLLM hält berechnete Key-Value-Blöcke zunächst im GPU-Speicher. Werden sie verdrängt, kann LMCache sie in den lokalen Arbeitsspeicher auslagern. In einem replizierten Endpoint bleibt diese Wiederverwendung jedoch üblicherweise lokal: Trifft eine Anfrage auf Replica B, kann sie nicht von einem passenden Cache-Eintrag auf Replica A profitieren.
AWS erweitert diese Kette um eine gemeinsame L2-Schicht. Curvine bündelt lokale NVMe-Laufwerke mehrerer G6e- oder P5-Knoten zu einem verteilten Dateisystem. Dieses wird per FUSE als ReadWriteMany-PVC in die Inferenz-Pods gemountet; LMCache schreibt und liest über seinen fs://-Connector. Ergänzend routet der Inference Operator Anfragen Prefix- beziehungsweise KV-cache-aware an Replikas, bei denen ein Treffer wahrscheinlich ist.
| Ebene | Ort | Rolle |
|---|---|---|
| L0 | GPU-HBM | Heißeste KV-Blöcke mit niedrigster Latenz |
| L1 | Host-RAM im Pod | Lokales Offload-Ziel über LMCache |
| L2 | Geteilter NVMe-Pool über Curvine | KV-Blöcke zwischen Pods wiederverwenden |
Was die Messwerte aussagen – und was nicht
Im AWS-Test erreichte die Architektur nach Angaben des Herstellers bis zu 100 % Cross-Pod-Cache-Hits, eine bis zu 2,7-fache Verbesserung der Time to First Token und rund 56 ms L2-Lesezeit für einen Prompt mit ungefähr 1.900 Tokens. Das sind Ergebnisse eines konkreten Testaufbaus, keine allgemeine Leistungszusage.
Der Mechanismus passt vor allem zu Workloads mit echter Präfix-Überlappung: RAG-Anwendungen mit gemeinsamen Systemprompts und Dokumentkontexten, Multi-Turn-Assistants oder viele Anfragen gegen denselben langen Grundkontext. Bei individuellen One-shot-Prompts ohne Wiederverwendung bezahlt ein gemeinsamer Cache dagegen Komplexität ohne entsprechenden Hit-Rate-Gewinn.
Der operative Haken: noch kein „one-click“ L2-Backend
AWS dokumentiert selbst, dass der Curvine-Pfad im gezeigten Stand nicht als sauberer, dedizierter CRD-Wert konfiguriert wird. Für den Dateisystem-gestützten L2-Zugriff wird die Umgebungsvariable LMCACHE_REMOTE_URL am vom Operator erzeugten Deployment gepatcht. Dazu kommen Curvine-Worker auf dem node-lokalen NVMe, ein FUSE-Mount und cache-aware Routing.
Das macht die Anleitung wertvoll als Blaupause, aber nicht als Ersatz für Betriebsdisziplin. Wer sie nachbaut, sollte insbesondere messen:
- Prefix-Hit-Rate je Replica: Der Effekt steht und fällt mit wiederkehrenden Präfixen.
- TTFT nach Cache-Ebene: Ein L2-Hit ist günstiger als Prefill, aber nicht so schnell wie HBM oder RAM.
- Cache-Evictions und NVMe-Druck: Gemeinsamer Speicher verschiebt den Engpass, er beseitigt ihn nicht.
- Routing-Skew: Cache-Affinität darf nicht einzelne Replikas überlasten.
Warum das relevant ist
Die eigentliche These ist größer als Curvine: KV-Cache wird zur geteilten Infrastrukturkomponente. Sobald Modellgewichte den verfügbaren HBM-Anteil drücken und Endpoints horizontal skalieren, ist nicht nur die GPU-Auslastung entscheidend, sondern auch, ob bereits bezahlte Prefill-Arbeit über Replikagrenzen hinweg erhalten bleibt.
AWS verweist darauf, dass bestimmte Workloads dadurch auf günstigeren G6e- statt P5-Instanzen laufen könnten. Das sollte man als Hypothese für einen eigenen Lasttest lesen: Modellgröße, Traffic-Profil, Prompt-Ähnlichkeit und die Kosten des zusätzlichen Storage-Stacks bestimmen, ob daraus tatsächlich ein günstigerer Endpoint wird.
Fazit: Das ist keine Produktmeldung über einen neuen Schalter, sondern ein brauchbares Architekturpattern. Für Teams mit vLLM, langen wiederkehrenden Kontexten und mehreren Replikas lohnt es sich, Shared KV Cache jetzt als messbaren Entwurfspunkt auf die Inferenz-Roadmap zu setzen.
Quelle: AWS Machine Learning: „Tiered KV cache for large LLMs on Amazon SageMaker HyperPod with Curvine“, veröffentlicht am 12. August 2026.
Leave a Reply