Der KV-Cache ist die versteckte Rechnung hinter KI mit langem Kontext

KI-generierte redaktionelle Illustration: Gesprächsbänder füllen getrennte Schubladen eines gemeinsamen Serverschranks. Das Motiv veranschaulicht Kapazität und zeigt weder ein Foto noch einen gemessenen Hardwareaufbau.

Kurzfassung: In einem beispielhaften Decoder mit vollständiger Attention, 32 Schichten, 8 KV-Köpfen, einer Kopfdimension von 128 und 16-Bit-Cache-Elementen benötigen 65.536 gespeicherte Token pro Sequenz 8 GiB reine KV-Nutzdaten. Bei 131.072 Token sind es 16 GiB.^[1][3] Das sind berechnete Speicheranforderungen ohne Gewichte und Laufzeitaufwand; ein verfügbarer langer Kontext und bezahlbare Parallelität sind unterschiedliche Zusagen.

Ein Modell kann auf eine GPU passen und trotzdem einen schlechten Mehrnutzer-Dienst ergeben. Seine Gewichte belegen Speicher, bevor der erste Kunde erscheint. Jedes aktive Gespräch bringt dann zusätzlichen Zustand mit, der mit dem Gespräch wächst. Der wirtschaftliche Fehler besteht darin, die erste Ausgabe zu budgetieren und beim Verkauf die zweite als vernachlässigbar zu behandeln.

Diese Analyse vom 9. November 2026 betrachtet grundlegende Forschung und berichtet keine neue Modellveröffentlichung. Multi-Query Attention wurde am 6. November 2019 veröffentlicht, GQA folgte am 22. Mai 2023, PagedAttention am 12. September 2023 und KIVI am 5. Februar 2024.^[2][1][3][4] Zusammen erklären sie, warum der Speicher hinter einem beworbenen Kontextfenster eine eigene Wirtschaftlichkeitsrechnung verdient.

Die Gleichung: Kontextlänge wird zu laufendem Speicherbestand

Bei einem herkömmlichen Decoder, der Schlüssel und Werte in jeder Schicht mit vollständiger Attention speichert, gilt für die reinen Cache-Bytes: 2 × Schichten × gespeicherte Token × KV-Köpfe × Kopfdimension × Bytes pro Element × unabhängige Sequenzen. Die erste 2 steht für Schlüssel und Werte. Das ist eine Bilanz der gespeicherten Tensoren, kein Durchsatzmodell.^[1][3]

Wir verwenden eine hypothetische Konfiguration: 32 Schichten, 8 KV-Köpfe, Kopfdimension 128 und 2 Bytes je Element. Das ergibt 131.072 Bytes oder 128 KiB pro gespeichertem Token und Sequenz. Bei 4.096 Token entstehen 0,5 GiB Nutzdaten. Bei 16.384 Token sind es 2 GiB, bei 65.536 Token 8 GiB. Ein GiB entspricht 1.073.741.824 Bytes. Die Einheiten sind binär, nicht die dezimalen GB, die im Hardwaremarketing häufig verwendet werden.

Berechneter Speicherbedarf

Die reinen KV-Nutzdaten wachsen mit der gespeicherten Sequenzlänge

Eine unabhängige Sequenz; 32 Schichten mit vollständiger Attention, 8 KV-Köpfe, Kopfdimension 128 und 2 Bytes pro Cache-Element. Die Werte sind berechnet, nicht gemessen.

4.096 gespeicherte Token

0,5 GiB

16.384 gespeicherte Token

2 GiB

65.536 gespeicherte Token

8 GiB

131.072 gespeicherte Token

16 GiB

0 GiBReine KV-Nutzdaten pro Sequenz16 GiB

Tensorgrößenberechnung von LLM Rumors anhand der in GQA und PagedAttention beschriebenen KV-Struktur vollständiger Attention [1,3]. Hypothetische Konfiguration, kein bestimmtes Modell und kein GPU-Benchmark. Ohne Modellgewichte, Aktivierungen, Verwaltungsdaten, Quantisierungsmetadaten, Fragmentierung und sonstigen Laufzeitspeicher. Ohne gemeinsame Präfixe, gleitende Kontextfenster oder latente Cache-Kompression.

Die Zahl umfasst gespeicherte Prompt-Token und den erzeugten Verlauf. Sie entspricht nicht einfach der maximalen Eingabelänge auf einer Modellkarte. Die Cache-Dokumentation von Hugging Face unterscheidet dynamische, statische, quantisierte und ausgelagerte Verfahren, weil eine Laufzeitumgebung Speicher unterschiedlich reservieren und platzieren kann.^[5] Architektur und Implementierung können die einfache Gleichung ebenfalls ungültig machen: Schichten mit gleitendem Kontextfenster, latente Attention und andere Zustandsdarstellungen benötigen eine eigene Bilanz.

Die Architektur: KV-Köpfe statt Query-Köpfe zählen

Ein häufiger Tabellenfehler setzt die Zahl der Query-Köpfe an die Stelle der KV-Köpfe. Bei gewöhnlicher Multi-Head Attention stimmen sie überein. Bei Grouped-Query Attention teilen sich mehrere Query-Köpfe eine kleinere Zahl von Schlüssel- und Wertköpfen. Multi-Query Attention reduziert die gemeinsame Nutzung auf einen einzigen KV-Kopf.^[1][2] Solche Architekturentscheidungen verändern den Zustand, der pro Token gespeichert wird.

Bei unveränderten übrigen hypothetischen Dimensionen und 65.536 Token braucht eine Variante mit 32 KV-Köpfen 32 GiB reine Nutzdaten. Eine Variante mit 8 KV-Köpfen braucht 8 GiB. Eine Variante mit einem KV-Kopf braucht 1 GiB. Die Speicherverhältnisse gegenüber der 32-Kopf-Variante betragen genau 4:1 beziehungsweise 32:1. Das sind Größenberechnungen für hypothetische Architekturen. Sie belegen weder Qualitätserhalt beim Umbau eines vorhandenen Modells noch entsprechende Geschwindigkeitsgewinne.

Die GQA-Arbeit beschreibt das weitere Training eines Checkpoints, keinen universellen Schalter für die Inferenz. Die Autoren untersuchten den Kompromiss zwischen Qualität und Effizienz beim gemeinsamen Nutzen von Attention-Zuständen.^[1] Die unbequeme Wahrheit: „Gleiche Parameterzahl“ reicht als Beschaffungsvergleich nicht aus. Zwei Modelle mit ähnlich großen Gewichten können pro Sitzung sehr unterschiedliche Speicheranforderungen und unterschiedliche Antworten erzeugen, weil sich ihre Zustandsarchitekturen unterscheiden.

Die Speicherzuweisung: Auch leerer Platz verbraucht Kapazität

Selbst eine korrekte Tensorgleichung kann den zugewiesenen Speicher unterschätzen. Gespräche haben unterschiedliche Längen und enden zu verschiedenen Zeiten. Wer für jedes künftig mögliche Token einen großen zusammenhängenden Bereich reserviert, kann Kapazität blockieren. PagedAttention behandelte Fragmentierung und Duplikation als Problem der Speicherverwaltung und nutzte Blöcke fester Größe sowie gemeinsame Zustände, wo dies möglich war.^[3]

Die Informationsnutzdaten verschwinden dadurch nicht. Die physische Zuweisung folgt dem benötigten Zustand genauer. vAttention, erstmals am 7. Mai 2024 eingereicht, untersuchte einen anderen Weg: CUDA-Funktionen zur virtuellen Speicherverwaltung trennen die physische Zuweisung von einer zusammenhängenden virtuellen Adressanordnung.^[7] Die gemeinsame Erkenntnis lautet, belegte und reservierte Bytes getrennt zu betrachten. Keiner der Ansätze macht aus 16 GiB Nutzdaten null Bytes.

Die FlashAttention-Arbeit vom 27. Mai 2022 behandelte exakte Attention mit einer an Speichertransfers angepassten Kachelverarbeitung.^[6] Große temporäre Attention-Zwischenergebnisse zu vermeiden und die KV-Tensoren eines Gesprächs aufzubewahren sind unterschiedliche Speicherfragen. Ein Serving-System kann von effizienten Attention-Kernels profitieren und trotzdem seine dauerhafte Cache-Kapazität ausschöpfen. Produktangaben sollten benennen, welche Speicherkomponente verbessert wurde.

Die Präzision: Weniger Bits brauchen eine Qualitätszusage

Ein reines 2-Bit-Element benötigt ein Achtel der Nutzdatenbits eines 16-Bit-Elements. Diese Rechnung bedeutet keine achtfache Speichereinsparung für das Gesamtsystem. Gewichte, höherpräzise Restzustände, Skalierungswerte, Packformate, Metadaten und temporäre Puffer bleiben bestehen. KIVI untersuchte unterschiedliche Verteilungen von Schlüsseln und Werten und schlug eine kanalweise Quantisierung der Schlüssel sowie eine tokenweise Quantisierung der Werte vor.^[4] Dieser asymmetrische Entwurf ist der wesentliche Beitrag, nicht die Bitzahl allein.

Hugging Face warnt, dass Cache-Quantisierung bei kurzen Kontexten die Latenz verschlechtern kann, wenn bereits ausreichend GPU-Speicher vorhanden ist.^[5] Weniger gespeicherte Daten können zusätzlichen Umwandlungsaufwand verursachen. Die Abnahme braucht deshalb Qualitätsprüfungen für die Aufgabe und Speicheraufzeichnungen mit demselben Modell, denselben Prompts, Dekodiereinstellungen und derselben Parallelität. Dieser Artikel verbindet Geschwindigkeitsangaben zu KIVI, PagedAttention oder Kernels nicht zu einer Rangliste.

Zustand auszulagern schafft einen weiteren Zielkonflikt. CacheGen, erstmals am 11. Oktober 2023 eingereicht, untersuchte komprimierte KV-Übertragung, weil das Laden über das Netzwerk einen erheblichen Teil der Kontextverzögerung ausmachen kann.^[9] Ein Cache, der im Hauptspeicher oder auf entferntem Speicher Platz findet, steht der GPU nicht automatisch für den nächsten Schritt bereit. Kapazität und Verfügbarkeit haben Transportkosten.

Der Geschäftsfall: Parallelität mit einem Latenzbudget verkaufen

Angenommen, ein Dienst hat nach allen anderen Reservierungen ein ausdrücklich hypothetisches Budget von 32 GiB ausschließlich für reine KV-Nutzdaten. Bei 65.536 Token im 8-Kopf-Beispiel erlaubt die Rechnung vier unabhängige Sequenzen mit je 8 GiB. Bei 131.072 Token sind es zwei Sequenzen mit je 16 GiB. Das sind rein speicherbezogene Obergrenzen; Laufzeitaufwand und nötige Reserven senken die praktische Kapazität. Gemeinsame Präfixe können das Ergebnis verändern, erzeugte Token eine Sitzung über ihre anfängliche Reservierung hinauswachsen lassen.

Auch die Einhaltung dieser Speichergrenze belegt noch kein Dienstgüteziel. DistServes Forschung vom 18. Januar 2024 trennte Prefill und Dekodierung, weil Ressourcenbedarf und Latenzziele unterschiedlich sind.^[8] Eine wirtschaftliche Bewertung sollte abgeschlossene Anfragen erfassen, die sowohl die Vorgaben bis zum ersten Token als auch zwischen den Token erfüllen. Hohe Latenzperzentile und Warteschlangen müssen sichtbar bleiben. Die unterstützte Kontextgrenze allein beantwortet diese Frage nicht.

Lassen wir keinen Zweifel: Speicher ist keine Fußnote zur Modellintelligenz. Er bestimmt, wie viel davon ein Produkt gleichzeitig verfügbar halten kann. Ein erfolgreicher Dienst kennt die Kosten eines laufenden Gesprächs so genau wie die Kosten seiner Modellgewichte.

Quellen und Referenzen

Zuletzt aktualisiert: 9. November 2026