Mehrstufiger KV-Cache für große LLMs auf Amazon SageMaker HyperPod mit Curvine
Amazon Web Services
Meta
DeepSeek
vLLM
In diesem Beitrag wird eine mehrstufige KV-Cache-Architektur auf Amazon SageMaker HyperPod beschrieben, die die Cache-Hierarchie von der GPU über die CPU bis zu einem gemeinsamen NVMe-Pool mithilfe von Curvine, einem verteilten Cache-Dateisystem, erweitert. Dies ermöglicht die Wiederverwendung von KV-Caches über Replikate hinweg, was eine Cache-Trefferquote über Pods von bis zu 100 Prozent und eine bis zu 2,7-fache Verbesserung der Time-to-First-Token (TTFT) erreicht. Die Lösung senkt die Infrastrukturkosten, da Workloads auf günstigeren G6e-Instanzen anstelle von P5 ausgeführt werden können.
Der Betrieb von Inferenz für große Sprachmodelle (LLMs) im großen Maßstab erzwingt in der Regel einen Kompromiss beim KV-Cache: Entweder man zahlt für überdimensionierte GPU-Instanzen, um einen wachsenden KV-Cache aufzunehmen, oder man akzeptiert eine langsame Zeit bis zum ersten Token (TTFT), da identische Prompts bei jeder Anfrage neu berechnet werden. Für Teams, die einen breiten Katalog öffentlich verfügbarer Foundation-Modelle (FMs) wie Qwen, Llama, DeepSeek und anderen über Endpunkte pro Geschäftsbereich, Pipelines zur Retrieval-Augmented Generation (RAG) oder Anwendungen mit mehreren Dialogrunden bereitstellen, führt dieser Kompromiss direkt zu höheren Infrastrukturkosten und einer schlechteren Benutzererfahrung. Die Ursache liegt darin, dass vLLM während der Generierung die Attention-Keys und -Values für jedes Token in einem KV-Cache speichert und Prefix-Caching diesen Cache über Anfragen mit gemeinsamen führenden Token hinweg wiederverwendet. Auf kosteneffizienten Instanzen wie ml.g6e.4xlarge (48 GB pro GPU) ist der für Prefix-Caching verfügbare Speicher begrenzt, die Cache-Trefferquote bei langen Prompts sinkt, identische System-Prompts werden bei jeder Anfrage neu mit Präfix versehen, und horizontal skalierte vLLM-Replikate unterhalten jeweils isolierte Caches. Die Lösung baut eine dreistufige Cache-Hierarchie auf: L0 (GPU-Prefix-Cache), L1 (Auslagerung auf CPU-Speicher) und L2 (gemeinsamer verteilter NVMe-Pool über Curvine). L0 ist die native Paged-Attention-Schicht von vLLM, L1 nutzt LMCache, um entfernte GPU-Blöcke auf den Host-Arbeitsspeicher auszulagern, und L2 bündelt lokale NVMe-Laufwerke über Curvine in einem gemeinsamen Namespace, der als ReadWriteMany-PVC in jedes Inferenz-Pod eingebunden wird. Das intelligente Routing von HyperPod leitet Anfragen an Replikate weiter, die wahrscheinlich relevante KV-Blöcke haben, mit Strategien wie präfixbewusst, kv-bewusst und Round-Robin. Der Nettoeffekt: Nur bei einem vollständigen Fehlschlag wird das System von Grund auf neu präfixiert, was die TTFT für Arbeitslasten mit mittlerer bis hoher Prompt-Überlappung erheblich reduziert. In einer Testbereitstellung wurden damit eine Cache-Trefferquote über Pods hinweg von bis zu 100 %, eine TTFT-Verbesserung um bis zu 2,7-fach und eine L2-Lese-Latenz über Knoten hinweg von etwa 56 ms für einen Prompt mit etwa 1.900 Token erreicht. Mit dieser Architektur können Arbeitslasten, die zuvor P5-Instanzen erforderten, auf kostengünstigeren G6e-Instanzen laufen, was die Kosten pro Endpunkt senkt. Die Implementierung erfordert SageMaker HyperPod mit aktiviertem Tiered Storage, einen EKS-Cluster und die Installation des Inference-Operators und von Curvine. Der Beitrag führt durch fünf Phasen: Aktivieren von Tiered Storage, Installieren des Inference-Operators und der Abhängigkeiten, Installieren von Curvine, Patchen des Inference-Operators für dateisystemgestützten L2-Speicher und Benchmarking.
Quelle: AWS ML blog —
Original