Kapitel 8 — KV-Cache-Management der nächsten Generation
Achter Beitrag im Kapitel-für-Kapitel-Walkthrough zu LLM Primer VI: KI-Systeme skalieren. Das Kapitel überträgt die Paging-Einsicht der Betriebssysteme in die Inferenz-Engine — und verwandelt den KV-Cache von einem reservierten Byte-Slab in eine geteilte, evictable, präfix-cachable Ressource.
Warum es dieses Kapitel gibt
Kapitel 7 hat Continuous Batching mit Schulden zurückgelassen. Sequenzen kommen und gehen bei jeder Iteration; ein naives Layout gibt jedem Slot seinen eigenen maximaldimensionierten Slab, von dem der Großteil verschwendet wird; der Batching-Durchsatzgewinn wird teilweise wieder abgegeben. Die Schulden heißen interne Fragmentierung, genau das Versagen, das Betriebssysteme in den 1960er-Jahren mit Paging gelöst haben. Kapitel 8 handelt davon, diese Lösung auf LLM-Serving anzuwenden: den KV-Cache in kleine physische Blöcke zerlegen, sie von logischen Token-Positionen durch eine Seitentabelle entkoppeln und Eviction- und Caching-Policies Blöcke über Sequenzen hinweg zurückgewinnen oder teilen lassen. PagedAttention ist der Grundzug; H2O und InfiniGen sind die Eviction-Policies; Präfix-Caching ist die Technik, die es einem Produktions-Cluster erlaubt, Millionen agentischer Anfragen auf einem Dutzend GPUs zu bedienen.
8.1 PagedAttention ist virtueller Speicher für den KV-Cache
Das PagedAttention-Paper von vLLM (2023) hebt die OS-Einsicht direkt in die Engine. Der KV-Cache wird in feste Blöcke geteilt — typisch 16 Tokens pro Block —, gehalten in einem flachen physischen Pool. Eine Sequenz wird durch eine Block-Tabelle repräsentiert: ein Array von Zeigern, die logische Positionen auf physische Block-IDs abbilden. Der Attention-Kernel nimmt die Block-Tabelle als zusätzliche Eingabe und sammelt Keys und Values durch Indirektion statt durch zusammenhängendes Slicing; auf Hopper absorbiert der L2 das Zufallszugriffsmuster gut genug, dass der Kernel innerhalb weniger Prozent der Slab-Version bleibt. Die Gewinne sind groß. Interne Fragmentierung sinkt von 60–80 Prozent auf etwa 4 Prozent (ein Teilblock am Ende pro Sequenz), was die verfügbare Nebenläufigkeit auf das 2- bis 4-Fache anhebt. Referenzgezähltes Block-Teilen macht komplexes Sampling nahezu kostenlos — Best-of-8 auf einem 2.000-Token-Prompt fällt von 16.800 auf 2.800 Token-Blöcke — und ist das Substrat, auf dem Präfix-Caching aufbaut.
8.2 H2O und InfiniGen evikieren die Tokens, die nicht zählen
PagedAttention löst Fragmentierung, aber nicht Kontexte, die bei jedem Layout aus dem VRAM wachsen. Ein 200.000-Token-Kontext von Llama-3-70B benötigt 60 GB KV neben den Gewichten. H2O („Heavy Hitter Oracle") beobachtet, dass sich Attention-Gewichte während der Dekodierung auf eine kleine Menge Quellpositionen konzentrieren — jüngste Tokens, Attention-Sink-Tokens ganz am Anfang und eine dünne Menge inhaltsrelevanter Treffer —, während die meisten historischen Positionen im Wesentlichen null Gewicht bekommen. Die Engine führt einen akkumulierten Attention-Score pro Position; wenn das KV-Budget der Sequenz an seinen Deckel gerät, evikiert sie die niedrigstbewerteten Positionen mit Ausnahme eines garantiert behaltenen Fensters aus jüngsten und Sink-Tokens. Die Ersparnis ist groß; die Kosten sind Endgültigkeit — braucht eine spätere Abfrage eine evikierte Position, kann die Engine sie nicht mehr zurückholen. InfiniGen verfeinert den Handel mit dynamischer, wiederherstellbarer Auswahl: statt Tokens komplett zu verwerfen, lagert es ihren KV in den CPU-Speicher aus und paged sie zurück, wenn sich die Aufmerksamkeit wieder auf sie zu konzentrieren beginnt. Die richtige Eviction-Policy hängt davon ab, wie stark eine Arbeitslast ihre eigene lange Historie neu abfragt; agentische Arbeitslasten bestrafen endgültiges Evikieren und belohnen die InfiniGen-artige Wiederherstellung.
8.3 Präfix-Caching ist der wirkungsvollste Hebel, den PagedAttention freischaltet
Im realen Traffic sind die ersten paar tausend Tokens der meisten Prompts über Anfragen hinweg identisch. Ein Chat-Dienst wiederverwendet denselben System-Prompt in jedem Gespräch. Ein RAG-Dienst klebt dieselben abgerufenen Passagen für jeden Nutzer in den Prompt, der dieselbe Suche gestellt hat. Ein Agent injiziert dieselben Tool-Beschreibungen und Reasoning-Gerüste bei jedem Schritt. PagedAttention macht das Teilen mechanisch: den Prompt in blockgroßen Stücken hashen; ist der Hash im globalen Cache berechneter Blöcke, zeigt die Block-Tabelle der neuen Anfrage auf den gecachten Block und der Prefill dieses Präfixes wird übersprungen; ist er es nicht, läuft Prefill und der resultierende Block wird registriert. Die Trefferraten in Produktion sind dramatisch — über 99 Prozent für den System-Prompt eines Chat-Dienstes, 30–60 Prozent für retrieval-abhängige RAG-Präfixe, nahe 1,0 für ein agentisches Gerüst. SGLangs RadixAttention treibt die Idee mit einem Radix-Baum weiter, der geteilte Präfixe beliebiger Länge indexiert, nicht nur blockbündige. Präfix-Caching ist die einzelne Technik, die überschrittene Serving-Cluster-Budgets am häufigsten in unterlaufene verwandelt.
Was Kapitel 8 vorbereitet
Paging, Eviction und Präfix-Caching haben den KV-Fußabdruck pro Token geschrumpft und das Speicherverhalten der Engine bei hoher Nebenläufigkeit beherrschbar gemacht. Was keines davon angeht, ist die fundamentale sequenzielle Abhängigkeit der Dekodierung: ein Ausgabe-Token pro Iteration und Sequenz, egal wie viele Slots aktiv sind. Kapitel 9 greift diese Beschränkung mit spekulativem Dekodieren an — der Familie von Techniken, die mit einem günstigen Entwurf mehrere Tokens vorausraten und die Vermutung in einem einzigen teuren Forward-Pass verifizieren, was den Ein-Token-pro-Schritt-Boden für genau jene Sequenzen aufbricht, die für die nutzerspürbare Latenz am meisten zählen.
Als Nächstes — Kapitel 9: Spekulatives Dekodieren. Entwurf, Verifikation und die Arithmetik, wann Spekulation sich lohnt.
