Die KV-Cache und das Gewicht der Aufmerksamkeit: drei Wege, ein Problem

Llama-3.1-70B, ausgeführt in BF16-Präzision, sammelt etwa 0,31 Megabyte KV-Cache für jeden einzelnen verarbeiteten Token an. Bei einem Kontext von 128.000 Token steigt die Rechnung auf 40 Gigabyte, eine bereits ungemütliche Zahl. Bei einer Million Token, dem Standard, auf den die neuesten Modelle zusteuern, werden mehr als 300 Gigabyte überschritten: mehr als die 140 Gigabyte, die von den Gewichten des Modells selbst belegt werden. Es ist ein Detail, das eine weit verbreitete Intuition umkehrt, nämlich dass der kritische Speicher in einem großen Sprachmodell der seiner Parameter sei. Das ist nicht mehr so, oder zumindest nicht immer. Der Speicher, der diejenigen, die Inferenzsysteme mit langem Kontext entwerfen, wirklich erschreckt, ist der der KV-Cache, das Archiv, in dem das Modell die Key- und Value-Repräsentationen jedes bereits gesehenen Tokens aufbewahrt, um nicht für jedes neue generierte Wort alles von Grund auf neu berechnen zu müssen.

Das Problem ist nicht nur die Größe. Jeder dekodierte Token muss die gesamte Cache vom Hochbandbreitenspeicher bis zu den Recheneinheiten passieren, was die Dekodierungsphase eher zu einem Flaschenhals der Bandbreite als der Rechenleistung macht. Es ist ein wenig so, als hätte man ein geräumiges Lagerhaus, aber zu schmale Korridore, um die Aktenordner hineinzubringen: Es spielt keine Rolle, wie viel Platz vorhanden ist, wenn man es nicht schnell genug fließen lassen kann, gerät das System trotzdem ins Stocken.

In den letzten Jahren hat die Forschung auf dieses Problem entlang fünf Hauptrichtungen geantwortet. Die erste ist die Token-Eviktion (eviction), von der H2O und SnapKV die am häufigsten zitierten Beispiele sind: Es wird entschieden, welche Token weniger wichtig sind, und deren Cache wird entfernt. Die zweite ist die Quantisierung, bei der KIVI und GEAR den Weg geebnet haben, indem sie die Anzahl der Bits reduzierten, die zur Darstellung jedes Wertes verwendet werden. Die dritte ist die Low-Rank-Projektion, mit Palu als Vorreiter, die die in den internen Dimensionen der Key- und Value-Vektoren verborgene Redundanz angreift, anstatt die Anzahl der Token oder die Bits pro Wert. Die vierte ist die Fusion, KVMerger, die mehrere Cache-Einträge in einer gemeinsamen Darstellung kombiniert. Die fünfte ist das architektonische Teilen, von dem die Multi-head Latent Attention von DeepSeek-V2 das bekannteste Beispiel ist, mit einer Reduzierung der KV-Cache um 93,3 %, die direkt beim Training in das Design des Modells eingebaut wurde.

In den letzten Monaten haben drei Ansätze besondere Aufmerksamkeit erregt und verdienen es, nicht als drei Konkurrenten erzählt zu werden, die um den Thron streiten, sondern als drei Antworten auf leicht unterschiedliche Fragen, die an dasselbe Problem gestellt werden.

TurboQuant, die Vorgeschichte

Über TurboQuant hatten wir bereits in einem eigenen Artikel gesprochen, daher genügt hier ein Rückruf. Die Methode, die von Forschern von Google Research und der New York University unterzeichnet und auf der ICLR 2026 angenommen wurde, wendet eine Zufallsrotation auf die Key- und Value-Vektoren an, bevor sie quantisiert werden. Die Rotation verändert nicht die Länge des Vektors, verteilt aber seine Komponenten in einer statistisch bekannten und vorhersagbaren Form neu, wodurch die Notwendigkeit entfällt, den Quantisierer auf spezifische Daten zu kalibrieren. Hinzu kommt eine zweite Stufe, die auf der QJL-Technik (Quantized Johnson-Lindenstrauss) aufbaut und den Quantisierungsrest mit einem einzigen zusätzlichen Bit korrigiert, um sicherzustellen, dass die Schätzungen der Skalarprodukte – genau die Berechnungen, die der Aufmerksamkeitsmechanismus ständig ausführt – nicht systematisch verzerrt sind.

Das erklärte Ergebnis ist eine mehr als fünffache Kompression bei qualitativer Neutralität bei 3,5 Bit pro Kanal und eine Beschleunigung der Aufmerksamkeit um bis zu das Achtfache auf H100-GPUs. Wie wir bereits angemerkt hatten, ist die Methode solide, aber nicht frei von Grauzonen: Der Vergleich mit dem vorherigen RabbitQ löste in der Review-Phase Kontroversen aus, und die strengsten Benchmarks auf LongBench zeigen, dass der reale Vorteil gegenüber Methoden wie KIVI in der Größenordnung von einem Bit liegt, nicht bei einer Revolution. Für Details zu Zufallsrotation, Residualbit und offenen Fragen zur Übertragbarkeit auf größere Modelle sei auf den Originalartikel verwiesen.

OSCAR und die Rotation, die auf die Aufmerksamkeit hört

Während TurboQuant auf Allgemeingültigkeit setzt, auf die Fähigkeit, zu funktionieren, ohne etwas über die Datenverteilung zu wissen, entstand OSCAR von Together AI aus einer fast gegenteiligen Beobachtung: Das Ignorieren der Aufmerksamkeit hat einen Preis, und bei 2 Bit wird dieser Preis untragbar.

Der Ausgangspunkt ist eine subtile, aber entscheidende Unterscheidung. Eine Rotation wie die von Hadamard, die von vielen früheren Methoden verwendet wurde, ist effektiv, weil sie Ausreißer auf mehrere Kanäle verteilt, was die Verteilung gleichmäßiger und damit einfacher zu quantisieren macht. Aber es ist eine blinde Rotation: Sie behandelt alle Richtungen des Vektorraums als gleichwertig, während die Aufmerksamkeit dies nicht tut. Einige Richtungen zählen viel mehr als andere für die endgültige Berechnung der Aufmerksamkeits-Scores und für den daraus resultierenden Output. Die Minimierung des Rekonstruktionsfehlers des Key- oder Value-Vektors – das implizite Ziel vieler Quantisierungstechniken – ist nicht gleichbedeutend mit der Minimierung des Fehlers, der tatsächlich den Output des Modells erreicht.

Das Team von Together AI hat daher ein System in zwei Phasen aufgebaut. In der Offline-Phase wird während einer kurzen Kalibrierung auf einem kleinen Datensatz die Kovarianz der Queries und die der Aufmerksamkeits-Scores geschätzt. Daraus werden zwei verschiedene Rotationen abgeleitet, eine für die Keys und eine für die Values, die spezifisch darauf ausgelegt sind, sich an den Richtungen auszurichten, die die Aufmerksamkeit wirklich konsumiert. Diese Rotationen werden dann mit einer Hadamard-Transformation und einer Permutation zusammengesetzt, um das Beste aus beiden Welten zu erhalten: die Aufmerksamkeit für die Geometrie des Problems und die Fähigkeit, verbleibende Exzesse weiter zu verteilen. In der Online-Phase wendet das System diese festen Transformationen während des Serving des Modells an, wobei nur ein kleines Fenster aktueller Token und die allerersten Token der Sequenz – die als Anker für die Aufmerksamkeit dienen – in hoher Präzision gehalten werden, während der gesamte Rest des Konversationsverlaufs auf 2 Bit komprimiert wird.

Der Vorteil dieser Wahl besteht darin, dass die Transformation fest ist, nur einmal in der Kalibrierungsphase berechnet wird und keine Eingriffe während der eigentlichen Inferenz erfordert. Dies macht sie kompatibel mit bereits bestehenden Serving-Architekturen, insbesondere mit dem Paged-Attention-Layout, das von Frameworks wie SGLang und vLLM verwendet wird, bei denen Cache-Blöcke als unabhängige Speicherseiten verwaltet werden. OSCAR wurde direkt in den SGLang-Stack mit einem speziellen Triton-Kernel für 2-Bit-Aufmerksamkeit integriert.

Die Zahlen sprechen eine deutliche Sprache über das Ausmaß des Problems, das OSCAR löst. Auf Qwen3-4B-Thinking bricht die naive INT2-Quantisierung ohne Rotation auf dem Mathematik-Benchmark AIME25 praktisch auf Null Genauigkeit ein. Mit der bloßen Hadamard-Rotation, ohne die Attention-aware-Vorsorge, bleibt der Score unter 1,5. OSCAR erreicht bei derselben Aufgabe und derselben Bitmenge eine Genauigkeit, die mit der des unkomprimierten Modells vergleichbar ist. Auf Qwen3-8B reduziert sich der Abstand zur vollen BF16-Präzision auf 1,42 Punkte, während der Speicherbedarf des Caches um etwa das Achtfache sinkt und der Durchsatz (throughput) bei großen Batches auf das Siebenfache steigt, immer bei gleichem Speicherbudget. Selbst auf deutlich größeren Modellen wie Qwen3-32B und dem 358 Milliarden Parameter starken GLM-4.7 behält OSCAR eine Genauigkeit nahe BF16 bis zu Kontexten von 128.000 Token in RULER-NIAH-Tests bei, wo die naive Rotation hingegen zusammenbricht.

Es muss gesagt werden, dass sich das Feld selbst mit einer Geschwindigkeit bewegt, die es schwierig macht, einen festen Punkt zu setzen: Fast zeitgleich mit OSCAR tauchte auch eine Methode mit fast identischem Namen, aber anderem Kern auf, OScaR (Omni-Scaled Canalized Rotation), die das Norm-Ungleichgewicht zwischen Token als Hauptursache für die Verschlechterung bei niedriger Präzision angreift und eine leichtere Lösung, aber mit ähnlichen Zielen vorschlägt. Ein Signal dafür, wie heiß derzeit die Front der Attention-aware-Rotation ist. Bild aus dem offiziellen Paper auf arxiv.org übernommen

EpiCache, das Problem, auf das niemand schaute

Während TurboQuant und OSCAR auf demselben Terrain konkurrieren, nämlich dem der effizientesten numerischen Darstellung jedes einzelnen Vektors, verschiebt Apples EpiCache den Fokus woandershin: nicht, wie viele Bit benötigt werden, um einen Token darzustellen, sondern welche Token es wert sind, aufbewahrt zu werden, wenn sich die Konversation über Tage oder Wochen hinzieht.

Das Problem, das EpiCache angeht, ist spezifisch für langandauernde Konversationen, bei denen ein Assistent Sitzung für Sitzung des Dialogs mit demselben Benutzer ansammelt. In diesem Szenario kann die KV-Cache eines relativ kleinen Modells wie LLaMA3.2-3B nach nur dreißig Sitzungen 7 Gigabyte überschreiten, was mehr ist als der von den Gewichten des Modells belegte Platz. Die offensichtlichste Antwort, die Eviktion nach der Verarbeitung des gesamten Kontextes anzuwenden, hat jedoch einen strukturellen Fehler: Die Speicherspitze wächst trotzdem linear mit der Eingabelänge, da man vor dem Verwerfen von etwas erst alles verarbeiten muss. Es ist so, als würde man erst entscheiden, welche Bücher man wegwirft, nachdem man bereits jedes Regal im Haus gefüllt hat.

EpiCache löst dies mit einer Block-Eviktion: Der Kontext wird in Segmenten fester Größe verarbeitet, und nach jedem Segment werden die am wenigsten relevanten Token sofort verworfen, wodurch das Speicherbudget unabhängig von der Länge der gesamten Konversation konstant bleibt. Das Problem ist, dass die elementare Anwendung dieser Strategie die Genauigkeit stark beeinträchtigt, da die ausgefeilteren Techniken zur Auswahl relevanter Token – jene, die auf einem zusätzlichen Prompt basieren, der misst, wie viel Aufmerksamkeit jeder Token von einer Query erhält – im Voraus wissen müssen, was der Benutzer fragen wird. Und in einer realen Konversation ist diese zukünftige Frage zum Zeitpunkt der Kompression nicht verfügbar.

Die vorgeschlagene Lösung ist in ihrer konzeptionellen Einfachheit elegant. Anstatt die zukünftige Frage zu erraten, nähert EpiCache sie mithilfe der Vergangenheit an: Es gruppiert den Konversationsverlauf durch Clustering in thematisch kohärente Episoden, identifiziert für jede Episode das repräsentativste Segment – jenes, dessen semantische Darstellung dem Zentrum des Clusters am nächsten liegt – und verwendet dieses Segment als Leit-Prompt, um zu entscheiden, welche Token in der spezifischen Cache dieser Episode aufzubewahren sind. Wenn eine neue Benutzerfrage eintrifft, vergleicht das System sie mit den Zentroiden aller gespeicherten Episoden und ruft die Cache der am nächsten liegenden Episode ab. So baut es eine Antwort auf, die auf dem wirklich relevanten Kontext basiert, auch wenn dieser Teil der Konversation Tage zurückliegt.

Hinzu kommt ein zweiter Kniff, der vielleicht weniger auffällig, aber ebenso nützlich ist: Nicht alle Schichten eines Transformers reagieren gleich auf die Block-Eviktion. Durch Messung, wie stark die Zustände der Keys zwischen der vollständigen und der Block-Verarbeitung abweichen, entdeckten die Autoren, dass die Empfindlichkeit von Schicht zu Schicht stark variiert, konsistent bei wechselndem Input, aber unterschiedlich von Modell zu Modell. EpiCache verteilt daher das Speicherbudget, indem es den empfindlicheren Schichten mehr Platz zuweist und denen weniger, die die Kompression besser tolerieren, anstatt einen gleichmäßigen Schnitt über das gesamte Netzwerk anzuwenden.

Die Ergebnisse, gemessen auf drei Benchmarks für langandauernde Konversationen (LongMemEval, Realtalk und LoCoMo), zeigen eine Genauigkeitsverbesserung von bis zu 30 % gegenüber früheren Kompressionstechniken, die im selben Block-Szenario angewendet wurden, mit Leistungen, die denen der vollen Cache nahekommen, selbst bei einer vier- oder sechsfachen Kompression. An der Effizienzfront reduziert das System die Dekodierungslatenz um das bis zu 2,4-fache und die Speicherspitze um das bis zu 3,7-fache im Vergleich zur unkomprimierten Cache. Bild aus dem offiziellen Paper auf arxiv.org übernommen

Drei Philosophien im Vergleich

Nebeneinander gestellt offenbaren die drei Methoden mehr Komplementarität als Wettbewerb, da sie in Wirklichkeit auf drei verschiedene Fragen antworten. TurboQuant fragt: Wie komprimiere ich einen beliebigen Vektor, ohne etwas über das Modell oder die Aufgabe zu wissen, mit soliden theoretischen Garantien? OSCAR fragt: Da ich das Modell kenne und mir eine kurze Kalibrierung leisten kann, wie richte ich die Kompression an dem aus, was die Aufmerksamkeit tatsächlich nutzt? EpiCache fragt hingegen etwas völlig anderes: In einer Konversation, die Wochen dauert, welche Teile des Verlaufs ist es wert, griffbereit zu halten, unabhängig davon, wie viele Bit pro Token man verwendet?

Dies bedeutet, dass man im Prinzip nicht gezwungen ist, einen Ansatz zu wählen und die anderen aufzugeben. EpiCache entscheidet, welche Token in der Cache überleben; OSCAR oder TurboQuant entscheiden, mit welcher Präzision diese überlebenden Token dargestellt werden. Ein Produktionssystem, das für einen langandauernden Konversationsassistenten konzipiert ist, könnte theoretisch beide Logiken nacheinander anwenden, obwohl keines der drei Paper diese Kombination explizit diskutiert und die praktische Integration eine in der Praxis zu verifizierende Übung bleibt.

Auf praktischer Ebene zählen die Unterschiede je nach Szenario jedoch sehr wohl. Für diejenigen, die ein generisches Modell in Produktion bedienen müssen, ohne sich eine spezifische Kalibrierungsphase für jedes Modell und jede Hardware leisten zu können, bleibt der Data-oblivious-Ansatz von TurboQuant attraktiv, auch wenn die strengsten Benchmarks einen bescheideneren realen Vorteil suggerieren, als die Kommunikation vermuten ließ. Für diejenigen, die mit einem einzigen festen Modell arbeiten und die Kompression ohne drastische Qualitätseinbußen bis an das Limit von 2 Bit treiben wollen – insbesondere bei Aufgaben des logischen Denkens oder beim Programmieren, wo sich jeder Aufmerksamkeitsfehler fortpflanzt und in den folgenden Schritten verstärkt –, bietet die Attention-aware-Kalibrierung von OSCAR eine Sicherheitsmarge, die blinde Rotationen nicht garantieren. Und für diejenigen, die Assistenten bauen, die den Benutzer über die Zeit begleiten, wo das Problem weniger die Präzision Bit für Bit als vielmehr die Fähigkeit ist, sich zur richtigen Zeit an das Richtige zu erinnern, geht EpiCache einen Flaschenhals an, den die anderen beiden nicht einmal berühren.

Zudem gibt es eine Unterscheidung bei den Betriebskosten, die hervorzuheben ist. TurboQuant erfordert keinerlei Kalibrierung, was es sofort auf jedes vortrainierte Modell anwendbar macht. OSCAR erfordert eine leichte Offline-Kalibrierung in der Größenordnung von wenigen tausend Token, um die notwendigen Kovarianzen zu schätzen, bleibt dann aber fest und verursacht keine zusätzlichen Kosten während der Inferenz. EpiCache führt schließlich wiederkehrende Rechenkosten ein, da jedes Mal, wenn die Konversation ein bestimmtes Budget überschreitet, das Clustering wiederholt und die episodischen Caches neu aufgebaut werden müssen – eine Operation, die ihren Preis hat, sich aber durch eine viel höhere Genauigkeit genau in dem Szenario auszahlt, für das sie konzipiert wurde.

Für diejenigen, die tiefer einsteigen oder selbst experimentieren möchten, haben die Autoren von OSCAR sowohl den Code als auch eine Sammlung vorkalkulierter Rotationen auf Hugging Face zur Verfügung gestellt, während für diejenigen, die eher auf der Seite der Low-Rank-Projektion arbeiten, Palu ein vollständiges Repository mit Evaluierungsskripten und speziellen GPU-Kerneln bereitstellt – eine Bestätigung dafür, dass in diesem Bereich die Theorie, so elegant sie auch sein mag, nur in dem Maße wertvoll ist, in dem sie in ausführbaren Code auf realer Hardware übersetzt wird.

Wer gewinnt, wer wartet

Es bleibt eine grundlegende Frage, die keines der drei Paper allein löst: Ist die Kompression der KV-Cache wirklich die Haupteinschränkung der Inferenz mit langem Kontext, oder gibt es andere Faktoren – die Speicherbandbreite, die Zugriffslatenz, die Parallelisierung der Aufmerksamkeitsberechnung –, die ebenso schwer oder schwerer wiegen? Die in diesem Artikel zitierten Zahlen sind alle real und überprüfbar, müssen aber in dem spezifischen Kontext gelesen werden, in dem sie gemessen wurden: Modelle der Qwen3- und GLM-Familie für OSCAR, LLaMA für EpiCache, Llama-2-7B für TurboQuant. Die Übertragbarkeit auf verschiedene Modellfamilien, auf Architekturen mit Grouped- oder Multi-query-Attention, bei denen die Dimensionen der Key- und Value-Vektoren bereits von vornherein reduziert sind, bleibt weitgehend in der Praxis zu verifizieren – nicht aus mangelndem Vertrauen in die zugrunde liegende Theorie, sondern weil jede Architektur Eigenheiten mit sich bringt, die veröffentlichte Benchmarks selten erschöpfen.

Schließlich gibt es eine Überlegung, die es wert ist, laut ausgesprochen zu werden. Die Geschwindigkeit, mit der innerhalb weniger Wochen drei verschiedene Ansätze auftauchten und fast zeitgleich eine vierte Methode mit einem fast identischen Namen zu einer der drei erschien, zeugt weniger von einem kompetitiven Wettlauf als vielmehr vom Reifen eines Problems, das die Industrie endlich aufgehört hat, als zweitrangig zu betrachten. Jahrelang konzentrierte sich die öffentliche Debatte über die Effizienz großer Sprachmodelle fast ausschließlich auf die Größe der Gewichte, die Quantisierung des Modells und die Destillation. Die KV-Cache blieb die meiste Zeit ein Implementierungsdetail. Die einleitenden Zahlen dieses Artikels sollten genügen, um zu erklären, warum dieses Detail de facto zur wahren Grenze der Systeme geworden ist, von denen wir uns wünschen, dass sie fähig sind, sich an alles für immer zu erinnern, ohne den Preis in Gigabyte dafür zu zahlen.

Technischer Hinweis: Die zitierten Benchmarks stammen aus den Original-Papern und wurden von dieser Redaktion nicht unabhängig reproduziert; wie immer in diesem Bereich garantieren Laborzahlen nicht automatisch die gleiche Leistung in Produktionsszenarien mit realen Arbeitslasten.