Unified KV Pooling to Accelerate Long-Context LLM Serving

Dieses Paper schlägt „Unified KV Pooling“ vor, ein System, das mehrere Host-Speichermodule und SSDs zu einem einzigen logischen Pool aggregiert und einen User-Space-„KV-Passthrough“-Mechanismus verwendet, um den Kernel-Dateisystem-Overhead zu umgehen, wodurch die Latenz beim Serving von LLMs mit langem Kontext um bis zu 4,1-fach reduziert wird und strikte Time-To-First-Token-Anforderungen erfüllt werden.

Das Wesentliche

Stellen Sie sich vor, Sie leiten eine riesige, Hochgeschwindigkeitsbibliothek, in der ein sehr kluger Bibliothekar (die KI) versucht, eine lange Geschichte basierend auf einem riesigen Stapel Referenzbücher (dem „Kontext“) zu schreiben.

Um die Geschichte zu schreiben, muss der Bibliothekar ständig zu früheren Seiten zurückblättern, um sich zu erinnern, was zuvor gesagt wurde. In der Welt der KI werden diese „Seiten“ als KV-Caches bezeichnet.

Das Problem: Die Bibliothek ist zu groß

Das Paper erklärt, dass wenn die Geschichte sehr lang wird (wie etwa 128.000 Wörter), der Schreibtisch des Bibliothekars (der schnelle GPU-Speicher des Computers) zu voll wird, um alle Referenzseiten aufzunehmen. Daher muss er die zusätzlichen Seiten in ein Lagerzimmer im Flur (Host-Speicher) oder sogar in ein riesiges Lagerhaus im Keller (SSD/Flash-Laufwerke) bringen.

Das aktuelle System weist zwei Hauptengpässe auf, die den Bibliothekar unglaublich langsam machen:

1. Die einspurige Autobahn: Selbst wenn die Bibliothek viele Lager- und Lagerhäuser besitzt, zwingt das aktuelle System den Bibliothekar dazu, nur eine einzige Tür zu benutzen, um Bücher hinein- und herauszubewegen. Es ist, als hätte man eine Flotte von 10 Lieferwagen, aber nur eine winzige Laderampe. Die Lastwagen stehen still, während die einzelne Rampe verstopft ist. Dies führt dazu, dass der Bibliothekar eine sehr lange Zeit (bis zu 30 Sekunden!) warten muss, nur um das erste Wort der Geschichte zu erhalten.
2. Der bürokratische Kontrollpunkt: Wenn der Bibliothekar ein Buch aus dem Lagerhaus im Keller benötigt, nimmt er es nicht einfach heraus. Er muss ein komplexes Formular ausfüllen, durch einen Sicherheitskontrolleur gehen, einen Aktenschrank prüfen und einen Stempel vom „Dateisystem“-Büro einholen, bevor er das Buch überhaupt berühren darf. Das Paper stellte fest, dass 84 % der Zeit, die für das Holen eines Buches aufgewendet wird, für diesen Papierkram verschwendet werden, nicht für den eigentlichen Transport des Buches.

Die Lösung: Unified KV Pooling

Die Autoren schlagen ein neues System namens Unified KV Pooling vor. Betrachten Sie dies als eine komplette Überholung der Bibliothek mit zwei wesentlichen Änderungen:

1. Die „Super-Team“-Strategie (Parallelität)
Anstatt eine einzige Tür zu benutzen, behandelt das neue System alle Lager- und Lagerhäuser als einen riesigen, gemeinsamen Pool.

• Die Analogie: Stellen Sie sich vor, der Bibliothekar hat nun ein Team von 10 Läufern. Anstatt dass eine Person alle Bücher trägt, teilt der Bibliothekar den Stapel auf und gibt Läufer A 10 %, Läufer B 20 % (weil dieser schneller ist) und so weiter. Alle 10 Läufer sprinten gleichzeitig zu ihren jeweiligen Lagerbereichen.
• Das Ergebnis: Der Bibliothekar bekommt die Bücher viel schneller zurück, weil die Arbeit parallel stattfindet und nicht in einer einzelnen Schlange.

2. Der „VIP-Pass“ (Dateisystem-Umgehung)
Das neue System gibt dem Bibliothekar einen speziellen „VIP-Pass“ für das Lagerhaus im Keller.

• Die Analogie: Anstatt Formulare auszufüllen und am Sicherheitskontrolleur zu warten, weiß der Bibliothekar genau, in welchem Regal das Buch steht. Er geht direkt am „Dateisystem“-Büro vorbei, geht direkt zum Regal, schnappt sich das Buch und rennt zurück.
• Das Ergebnis: Er spart die 84 % der Zeit, die durch den Papierkram verloren gegangen wären.

Die Ergebnisse

Das Paper testete dieses neue System auf verschiedenen KI-Modellen (wie LLaMA und Qwen) mit sehr langen Geschichten. Dies geschah:

• Geschwindigkeit: Die Zeit, die es dauerte, um das erste Wort der Geschichte zu erhalten (genannt TTFT), sank um etwa das 4-fache. Anstatt 30 Sekunden zu warten, war der Bibliothekar in weniger als 10 Sekunden bereit.
• Effizienz: Die Zeit, die der Bibliothekar allein mit dem Warten auf Bücher verbrachte (blockierte I/O-Zeit), sank massiv um das 23-fache.
• Overhead: Das neue System fügt eine winzige Menge an zusätzlicher Arbeit hinzu, um die Läufer zu managen, aber dieser Aufwand ist so gering (weniger als 1 % der Gesamtzeit), dass er nichts verlangsamt.

Zusammenfassung

Kurz gesagt, das Paper sagt: „Aktuelle KI-Systeme sind bei langen Geschichten langsam, weil sie nur eine einzige Lagertür nutzen und zu viel Zeit mit Papierkram verschwenden. Indem wir alle Türen gleichzeitig öffnen und den Papierkram abschaffen, können wir das Serving von Long-Context-KI viermal schneller machen.“

Technische Zusammenfassung

Technische Zusammenfassung: Unified KV Pooling zur Beschleunigung des Long-Context LLM Serving

Problemstellung
Die Arbeit adressiert die schwerwiegenden Ineffizienzen beim Serving von Large Language Models (LLMs) mit langen Kontexten (über 16K Token). Mit zunehmender Kontextlänge wächst der für Attention-Mechanismen benötigte Key-Value (KV)-Cache linear an und übersteigt oft die Kapazität des GPU-Speichers. Infolgedessen müssen moderne Systeme KV-Caches in den Host-Speicher und auf SSDs auslagern. Die Autoren identifizieren jedoch zwei kritische Engpässe in bestehenden Offloading-Mechanismen, die die Serving-Latenz (Time-To-First-Token oder TTFT) inakzeptabel ansteigen lassen (erreicht ~30,7s bei 128K Kontext, was weit über der typischen Anforderung von 10s liegt):

1. Serialisierter I/O-Pfad: Bestehende Engines serialisieren KV-Abrufanfragen durch Host-Speicher und SSDs. Dieses Design versäumt es, die aggregierte Bandbreite mehrerer verfügbarer Speichermodule und SSDs zu nutzen, wodurch viele Geräte unterausgelastet bleiben, während andere zum Flaschenhals werden. Profiling zeigt, dass mit zunehmender Kontextlänge die SSD-Anfragewarteschlangen signifikant anwachsen (bis zu ~132×), was zu massiven „Blocked I/O Times“ führt, bei denen die GPU auf Daten warten muss.
2. Dateisystem-Overhead: Der abrufbasierte Zugriff auf SSDs verursacht erheblichen Overhead durch das Kernel-Dateisystem. Das Profiling der Autoren zeigt, dass 84 % der Zeit, die für den Abruf von KV-Caches aus SSDs aufgewendet wird, durch die Dateisystemverarbeitung (Metadatenverwaltung, Blockverwaltung) konsumiert wird, statt durch den eigentlichen Gerätezugriff. Dies ist ineffizient, da die Serving-Engine bereits über die Ziel-KV-Objekte und deren Positionen verfügt, wodurch allgemeine Dateisystemoperationen unnötig werden.

Methodik: Unified KV Pooling
Um diese Probleme zu lösen, schlägt die Arbeit Unified KV Pooling vor, eine Systemarchitektur, die mehrere Host-Speichermodule und SSDs zu einem einzigen logischen Pool aggregiert und den Dateisystem-Overhead eliminiert. Das Design besteht aus zwei primären Komponenten:

1. KV Orchestrator (Bandbreitenbewusste Verteilung):

   • Global Lookup Table (GLT): Verwaltet den Standort jedes ausgelagerten KV-Cache-Eintrags, indem sie den Device-Index, den Gerätetyp (MEM oder SSD) und den spezifischen Speicherort (Pointer für Speicher, Logical Block Address (LBA) für SSD) speichert.
   • Pool Organizer: Berechnet ein Platzierungsverhältnis ($p_i$) für jedes Pool-Device basierend auf dessen gemessener Bandbreite ($b_i$). Dies stellt sicher, dass schnellere Geräte einen proportional größeren Anteil am KV-Verkehr erhalten.
   • Bandwidth-Aware KV Allocator: Verteilt den Satz der auszulagernden KV-Caches ($K(t)$) über die Pool-Devices gemäß den berechneten Verhältnissen. Er partitioniert die Daten in pro-Device-Sets und führt parallele Schreib-/Leseoperationen an allen Geräten gleichzeitig aus, anstatt den Verkehr durch einen einzelnen Pfad zu serialisieren.

2. KV-passthrough (Filesystem Bypass):

   • Entwickelt, um den Kernel-Dateisystem-Overhead für den SSD-Zugriff zu eliminieren.
   • Nutzt SPDK (Storage Performance Development Kit), um NVMe-Befehle direkt aus dem User-Space auszuführen.
   • Implementiert zwei Primitiven: SSD_Direct_Store (asynchrone Schreibvorgänge zu zusammenhängenden LBA-Bereichen) und SSD_Direct_Retrieve (asynchrone Lesezugriffe basierend auf vorbekannten LBAs).
   • Durch das Umgehen des Kernel-Dateisystems vermeidet das System die Kosten der allgemeinen Dateisystemabstraktion und greift direkt auf die SSD-residenten KV-Caches zu.

Wesentliche Beiträge

• Problemidentifikation: Die Arbeit zeigt auf, dass das aktuelle KV-Cache-Offloading unter hoher Latenz leidet, die durch serialisierte I/O-Pfade verursacht wird, welche die verfügbare Hardware unterauslasten, sowie durch signifikanten Dateisystem-Overhead, der die SSD-Abrufzeiten dominiert.
• Systemdesign: Es führt Unified KV Pooling ein, welches die bandbreitenbewusste Verteilung über einen logischen Pool heterogener Geräte mit einem User-Space-Zugriffsmechanismus kombiniert, der das Dateisystem umgeht.
• Leistungssteigerung: Das Design erzielt signifikante Reduktionen der Serving-Latenz und der Blocked I/O Time über verschiedene Modelle und Kontextlängen hinweg.

Evaluationsergebnisse
Die Autoren evaluierten das System mit den Modellen LLaMA 3.1-8B, GPT-OSS-20B und Qwen3-30B-A3B unter Verwendung des Long Doc QA Benchmarks mit Kontextlängen von bis zu 128K Token. Sie verglichen ihren Ansatz mit State-of-the-Art (SOTA)-Techniken, einschließlich Standard-LMCache, LMCache mit Layerwise Pipelining sowie LMCache mit Pipelining plus asynchronem Laden.

• TTFT-Reduktion: Unified KV Pooling reduzierte die TTFT im Vergleich zum besten SOTA-Baseline (LMCache+LP+AsyncKV) in Long-Context-Szenarien um etwa das 4,1-Fache. Beispielsweise sank die TTFT bei GPT-OSS-20B bei 128K Kontext von ~17,3s (Baseline) auf 5,2s, wodurch alle evaluierten Modelle unter die 10s-Anforderung gebracht wurden.
• Blocked I/O Time: Das System reduzierte die Blocked I/O Time um bis zu das 23,2-Fache im Vergleich zu den Baselines. Bei GPT-OSS-20B wurde die Blocked Time von mehreren Sekunden auf Millisekunden reduziert, was den durch I/O verursachten GPU-Stall effektiv eliminierte.
• Ablationsstudie: Experimente bestätigten, dass beide Komponenten notwendig sind. Die Verwendung nur des Orchestrators (mit Filesystem) oder nur des Passthroughs (ohne Verteilung) führte zu einer signifikant höheren TTFT (jeweils 1,8× bzw. 2,3× schlechter) als das vollständige Unified KV Pooling Design.
• Overhead: Der Management-Overhead des KV-Orchestrators wurde als vernachlässigbar gemessen und lag selbst bei 128K Kontext unter 84 ms (ca. 0,8 % der TTFT).

Bedeutung und Ansprüche
Die Arbeit behauptet, dass Unified KV Pooling das effiziente Serving von Long-Context LLMs grundlegend verändert, indem es Speicherressourcen als einen vereinheitlichten, parallelisierbaren Pool statt als einen serialisierten Flaschenhals behandelt. Durch die Abstimmung der Datenverteilung auf die Device-Bandbreite und das Entfernen des Kernel-Dateisystems aus dem kritischen I/O-Pfad erreicht das System eine nahezu lineare Skalierung der Retrieval-Performance mit den verfügbaren Hardware-Ressourcen. Die Autoren positionieren diese Arbeit als orthogonal zu bestehender Forschung über KV-Cache-Kompression oder selektives Laden, da sie die zugrunde liegenden Infrastruktur-Engpässe der Retrieval- und Zugriffsmechanismen adressiert. Die Studie kommt zu dem Schluss, dass diese Optimierungen essenziell sind, um Long-Context-Inferenz für Echtzeit-Anwendungen praktikabel zu machen.