Der KV-Cache: der versteckte Engpass, der lokale KI ausbremst

Alle reden davon, große Sprachmodelle auf Laptops zu betreiben. Kaum jemand redet darüber, warum diesen Modellen mitten in einem langen Gespräch der Speicher ausgeht. An den Modellgewichten liegt es nicht, sondern am KV-Cache, und ein Paper, das diese Woche auf der ICLR 2026 vorgestellt wird, könnte das Problem gerade gelöst haben.

Die Mixture-of-Experts-Revolution hat lokale Inferenz auf eine Weise realistisch gemacht, die vor einem Jahr undenkbar war. Qwen3.5-35B-A3B packt 35 Milliarden Parameter in ein Modell, das pro Token nur 3 Milliarden aktiviert. Auf 4 Bit quantisiert passen die Gewichte in 20 GB. Aus der Community kommen Berichte über mehr als 100 Token pro Sekunde auf einer RTX 3090. Ein MacBook mit 24 GB Unified Memory kommt damit bequem zurecht. Zum ersten Mal ist Reasoning auf Frontier-Niveau mit Consumer-Hardware erreichbar.

Aber geben Sie diesem Modell einmal ein Kontextfenster von 100.000 Token und sehen Sie, was passiert. Ihrem 24-GB-Rechner geht nicht die Rechenleistung aus, sondern der Speicher. Nicht wegen des Modells, sondern wegen des Caches.

Was der KV-Cache eigentlich ist

Jedes Transformer-basierte Sprachmodell speichert beim Generieren von Text die Key- und Value-Vektoren aller bisherigen Token im sogenannten KV-Cache. So „erinnert“ sich das Modell an das Gespräch. Für jedes neue Token muss das Modell Attention auf alle bisherigen Token richten, also jedes gespeicherte Key-Value-Paar lesen. Der Cache wächst linear mit der Sequenzlänge und skaliert mit der Modelltiefe.

Bei einem Modell wie Qwen3.5-35B-A3B ist die Architektur ungewöhnlich effizient. Es setzt auf ein hybrides 3:1-Design: Auf drei Gated-DeltaNet-Layer (lineare Attention mit einem State fester Größe, der nicht mit der Sequenzlänge wächst) kommt jeweils ein Full-Attention-Layer mit GQA und nur 2 KV-Heads. Weil die DeltaNet-Layer gar keine KV-Paare pro Token speichern, tragen nur 25 % der Layer des Modells zum KV-Cache bei. Dadurch fällt der Cache-Footprint drastisch kleiner aus als bei einem Standard-Transformer vergleichbarer Größe. Trotzdem belegt selbst dieser reduzierte Cache bei 256K Token Kontext in FP16 mehrere Gigabyte. Bei dichteren Architekturen, also Modellen mit Full Attention in jedem Layer, sehen die Zahlen weit schlechter aus. Ein dichtes Modell mit 35 Milliarden Parametern und Standard-Multi-Head-Attention kann bei 32K Kontext 7 bis 8 GB KV-Cache verbrauchen und bei 128K über 30 GB.

An diesem Engpass entscheidet sich, ob Ihr lokales Modell eine ganze Codebase lesen kann oder nur eine einzelne Datei. An ihm entscheidet sich auch, ob Sie mehrere gleichzeitige Nutzer auf einer einzigen GPU bedienen können. Und bisher waren die Lösungen unbefriedigend. Entweder Sie kürzen den Kontext (und verlieren Information), Sie prunen Token heuristisch (und hoffen, die richtigen erwischt zu haben), oder Sie wenden eine grobe Quantisierung pro Kanal an, ohne theoretische Garantien dafür, was dabei verloren geht.

TurboQuant: nahezu optimale Kompression ohne Kalibrierung

TurboQuant, für die ICLR 2026 angenommen und diese Woche vorgestellt, stammt von einem Team unter der Leitung von Amir Zandieh und Vahab Mirrokni bei Google Research, in Zusammenarbeit mit Majid Daliri (NYU), Majid Hadian (Google DeepMind) und Forschenden am KAIST. Das Paper schlägt ein Vektorquantisierungsverfahren für den KV-Cache vor, das 16-Bit-Werte auf 3,5 oder 2,5 Bit pro Kanal komprimiert und dabei die geometrische Struktur der Vektoren erhält. Die zentrale Behauptung: Bei 3,5 Bit erreichen die Autoren „absolute Qualitätsneutralität“ gegenüber dem Modell mit voller Genauigkeit. Bei 2,5 Bit ist die Verschlechterung marginal. Das ergibt Kompressionsfaktoren von 4,5× bei 3,5 Bit und über 6× bei 2,5 Bit.

Zu mehr als einer schrittweisen Verbesserung wird das durch die Kombination dreier Eigenschaften. Erstens ist die Verzerrungsrate beweisbar nahezu optimal: Sie liegt höchstens etwa um den Faktor 2,7 über der informationstheoretischen unteren Schranke, die Shannons Quellcodierungstheorie festlegt. Bei einer Bitbreite von 1 schrumpft der Abstand auf den Faktor 1,45. Das ist keine Heuristik, die zufällig auf den getesteten Benchmarks funktioniert, sondern eine Methode mit formalen Garantien, die im Worst Case für jeden Eingabevektor gelten.

Zweitens arbeitet der Algorithmus online und datenunabhängig. Er braucht keine Kalibrierungsdaten, kein Preprocessing und kein Lernen von Codebooks. Sie können ihn während der autoregressiven Generierung auf jeden KV-Vektor anwenden, sobald er eintrifft. Für das praktische Deployment ist das enorm wichtig. Offline-Quantisierungsmethoden, die einen repräsentativen Kalibrierungsdatensatz brauchen, sind für den KV-Cache unbrauchbar, denn der Cache füllt sich dynamisch während der Inferenz, und sein Inhalt hängt vollständig vom Prompt des Nutzers ab.

Drittens ist der Rechenaufwand vernachlässigbar. Die Kernoperation ist eine zufällige Rotation, gefolgt von skalarer Quantisierung gegen vorab berechnete Codebooks. Es gibt keine iterative Optimierung und keine Nächste-Nachbarn-Suche gegen gelernte Zentroide. Die Indexierungszeit in ihren Experimenten zur Nächste-Nachbarn-Suche beschreiben die Autoren als „praktisch null“.

So funktioniert es

Die Grundidee ist elegant. Nehmen Sie einen d-dimensionalen Vektor auf der Einheitskugel und multiplizieren Sie ihn mit einer zufälligen Rotationsmatrix. Nach der Rotation folgt jede Koordinate einer Betaverteilung (die in hohen Dimensionen gegen eine Gaußverteilung konvergiert), und verschiedene Koordinaten werden nahezu unabhängig. Auf diese nahezu vollständige Unabhängigkeit kommt es an: Sie können jede Koordinate für sich mit einem optimalen skalaren Quantisierer quantisieren, ohne sich um Korrelationen zwischen den Dimensionen zu kümmern, und erreichen trotzdem nahezu optimale Verzerrung für den gesamten Vektor.

Den optimalen skalaren Quantisierer für jede Koordinate findet man, indem man mit dem Lloyd-Max-Algorithmus ein eindimensionales kontinuierliches k-Means-Problem löst. Die resultierenden Codebooks werden einmal vorab berechnet und gespeichert. Die Quantisierung heißt dann nur noch: rotieren, pro Koordinate den nächsten Zentroid finden, den Index speichern. Die Dequantisierung läuft umgekehrt: Zentroide nachschlagen, zurückrotieren.

Damit ist der MSE abgedeckt. Für Attention in Transformern müssen aber vor allem die Skalarprodukte erhalten bleiben, denn das Skalarprodukt zwischen Query- und Key-Vektoren treibt den Attention-Mechanismus an. Das Paper zeigt, dass MSE-optimale Quantisierer einen Bias in die Schätzung der Skalarprodukte einführen. Bei 1 Bit beträgt der multiplikative Bias 2/π, und das ist erheblich. Die Lösung der Autoren ist zweistufig: Sie wenden den MSE-Quantisierer mit einem Bit weniger als dem Zielbudget an und danach auf das Residuum eine 1-Bit-Quantised-Johnson-Lindenstrauss-Transformation (QJL). Das Ergebnis ist ein erwartungstreuer Schätzer für Skalarprodukte mit beweisbar geringer Verzerrung.

Was das für lokale Inferenz bedeutet

Konkret wird das an den Modellen, die Leute tatsächlich lokal betreiben.

Qwen3.5-35B-A3B braucht bei 4-Bit-Quantisierung etwa 20 GB für die Gewichte. Auf einer 24-GB-GPU bleiben damit 4 GB für KV-Cache und Overhead. Dank der hybriden Architektur, bei der nur 25 % der Layer Full Attention nutzen, ist der KV-Cache dieses Modells weit kleiner als bei einem dichten Transformer ähnlicher Größe. Vernachlässigbar ist er aber nicht. Bei 256K Kontext reizt selbst der reduzierte Cache das Speicherbudget von Consumer-Hardware aus, weshalb die Model Card empfiehlt, die Kontextlänge bei OOM-Fehlern auf 32K zu reduzieren.

Wenden Sie TurboQuant mit 3,5 Bit auf die Attention-Layer an, die tatsächlich KV-Paare speichern, schrumpft dieser Cache ungefähr um den Faktor 4,5. Ein Modell, das auf Ihrer 24-GB-GPU bisher bei 32K Token an die Wand fuhr, gewinnt spürbar Spielraum, je nach Overhead-Budget womöglich genug für 64K oder mehr. Bei dichten Architekturen wie Llama-3.1, in denen jeder Layer KV-Paare speichert, fallen die Gewinne noch drastischer aus: Kontextfenster könnten auf identischer Hardware auf das 3- bis 4-Fache wachsen.

Bei Qwen3-Coder-Next, dem MoE mit 80 Milliarden Parametern, das für agentisches Coding mit 256K Kontext ausgelegt ist, ist das Budget für die Gewichte noch knapper. Allein die 4-Bit-Gewichte brauchen etwa 46 GB. Wer es auf einem 64-GB-Mac betreibt, ist beim Speicher ohnehin schon eingeschränkt, und wie Qwen3.5-35B-A3B nutzt es dasselbe hybride 3:1-Design aus DeltaNet und Attention, das begrenzt, wie viele Layer KV-Paare speichern. Trotzdem steht jedes beim KV-Cache eingesparte Gigabyte für längeren Kontext oder mehr gleichzeitige Sessions zur Verfügung.

Das Paper validiert diese Aussagen an Llama-3.1-8B-Instruct, Ministral-7B-Instruct, Gemma und Mistral-Modellen, allerdings nicht speziell an den MoE-Modellen von Qwen, was man erwähnen sollte. Die Benchmark-Abdeckung ist umfangreich: LongBench, Needle-in-a-Haystack, ZeroSCROLLS, RULER und L-Eval. Beim Needle-in-a-Haystack-Benchmark, bei dem das Modell einen bestimmten Satz in einem Dokument mit bis zu 104K Token finden muss, erreichte TurboQuant bei 4-facher Kompression exakt die Leistung voller Genauigkeit. Bei LongBench kam die 3,5-Bit-Variante auf 50,06, der vollständige Cache ebenfalls auf 50,06. Identisch. Die 2,5-Bit-Variante kam auf 49,74, ein Abstand, der so klein ist, dass er im Rauschen liegt.

Die ICLR-Fassung des Papers enthält außerdem Speedup-Benchmarks, die im früheren arXiv-Preprint fehlten: Bei 4-Bit-Genauigkeit ist die Berechnung der Attention-Logits auf NVIDIA-H100-GPUs bis zu 8-mal schneller als die unquantisierte 32-Bit-Baseline. Das betrifft ausdrücklich die Attention-Berechnung, nicht den Durchsatz der gesamten Inferenz. Attention ist bei langen Sequenzen aber der dominierende Kostenfaktor, und genau dort zählt die KV-Cache-Kompression am meisten.

Was das von bestehenden Ansätzen unterscheidet

Das Feld der KV-Cache-Kompression ist unübersichtlich. KIVI quantisiert skalar pro Kanal, ohne theoretische Garantien, und zeigt bei aggressiven Kompressionsraten spürbare Verschlechterungen. SnapKV und PyramidKV prunen Token, statt sie zu quantisieren, und das ist ein grundlegend anderer Trade-off: Sie verwerfen Information, statt sie zu komprimieren. Die in Vektordatenbanken eingesetzten Product-Quantisation-Methoden brauchen ein Training der Codebooks, was für den Online-Einsatz im KV-Cache nicht infrage kommt. TurboQuant selbst baut auf PolarQuant auf (wird auf der AISTATS 2026 vorgestellt, teils von denselben Autoren), das Stufe 1 übernimmt: die zufällige Rotation und die Quantisierung pro Koordinate. Der Beitrag von TurboQuant ist die QJL-Korrektur des Residuums, die den Bias bei den Skalarprodukten beseitigt und das gesamte zweistufige System für die Attention-Berechnung tauglich macht.

Der Vorteil von TurboQuant ist, dass es theoretische Optimalität mit praktischer Einsetzbarkeit verbindet. Es braucht kein Tuning. Es braucht keine repräsentativen Daten. Es muss keine Token unkomprimiert lassen. Und es kommt mit einem formalen Beweis, dass viel Besseres nicht möglich ist: Die informationstheoretische untere Schranke sagt es.

Erwähnenswert ist NVIDIAs KVTC, ebenfalls für die ICLR 2026 angenommen, das mit einem Transform-Coding-Ansatz im Stil von JPEG bis zu 20× Kompression verspricht. Diese Kompressionsrate stellt die 6× von TurboQuant weit in den Schatten. KVTC braucht aber einen Kalibrierungsschritt und zielt auf Offline-Speicherung und Wiederverwendung des Caches. Für die Online-Quantisierung in Echtzeit während der autoregressiven Generierung, die lokale Inferenz verlangt, taugt es deshalb nicht. Die beiden Methoden ergänzen einander, statt zu konkurrieren: verschiedene Werkzeuge für verschiedene Deployment-Szenarien.

Bei den Experimenten zur Nächste-Nachbarn-Suche sind die praktischen Folgen ebenso deutlich. TurboQuant schlug Product Quantisation beim Recall auf jedem getesteten Datensatz (GloVe mit 200 Dimensionen, OpenAI-Embeddings mit 1536 und 3072 Dimensionen) und drückte die Indexierungszeit von Hunderten Sekunden auf praktisch nichts. PQ brauchte 239 Sekunden, um 100K Vektoren der Dimension 1536 zu indexieren. TurboQuant brauchte 0,0013 Sekunden.

Das größere Bild

Die Entwicklungen laufen unübersehbar zusammen. MoE-Architekturen haben das Gewichtsproblem gelöst: Sie bekommen ein Modell auf Frontier-Niveau auf eine Consumer-GPU, indem Sie nur die Experten laden, die Sie brauchen. Flash Attention und ihre Nachfolger haben das Rechenproblem gelöst: Attention ist in der Praxis nicht mehr quadratisch. Übrig bleibt das Speicherproblem, und das wird bei langen Kontexten vom KV-Cache dominiert.

TurboQuant ist nicht der einzige Lösungsansatz, aber der erste, der nahezu optimale Garantien ohne Overhead bietet. Wenn KV-Cache-Quantisierung mit 3,5 Bit zum Standard wird, und die Ergebnisse sprechen dafür, wachsen die auf lokaler Hardware praktisch erreichbaren Kontextlängen deutlich. Bei dichten Architekturen könnte das eine Steigerung auf das 3- bis 4-Fache bedeuten. Das ist der Unterschied zwischen einem lokalen Coding-Agenten, der eine Datei sieht, und einem, der Ihr ganzes Projekt sieht.

Das Ökosystem bewegt sich schon

Google veröffentlichte seinen offiziellen Research-Blogpost am 24. März, und die ICLR-Poster-Session von TurboQuant findet am 25. April statt, aber die Community hat nicht gewartet. Wenige Tage nach dem Blogpost hatten unabhängige Entwickler allein aus der Mathematik des Papers funktionierende Implementierungen gebaut. Eine PyTorch-Implementierung mit eigenen Triton-Kernels wurde auf Gemma 3 4B getestet und soll bei 2-Bit-Genauigkeit eine Ausgabe liefern, die Zeichen für Zeichen mit der unkomprimierten Baseline übereinstimmt. Ein pip install turboquant-Paket liegt bereits auf PyPI und bietet KV-Cache-Kompression für HuggingFace-Modelle als Drop-in. Es gibt einen llama.cpp-Fork mit TurboQuant-KV-Cache-Typen (--cache-type-k turbo3), der auf Apple Silicon mit Metal-GPU-Kernels läuft und bei 4,9-facher Kompression Geschwindigkeitsparität mit q8_0 für sich beansprucht. Und für vLLM ist ein Feature Request für eine Integration offen, ein Implementierungsentwurf ist bereits skizziert.

Nichts davon kommt von Google. Google hat keinen offiziellen Code veröffentlicht. Das sind Leute, die ein Paper lesen und auf Basis der Mathematik eigene Implementierungen schreiben, und das spricht dafür, dass der Algorithmus so sauber und implementierbar ist, wie die Autoren behaupten. Offen ist, ob er als Flag in llama.cpp, als Backend in vLLM oder als eingebaute Option in Ollama landet. Das Tempo der Community spricht dafür, dass es nicht lange dauern wird.

Für alle, die lokal laufende Agenten-Infrastruktur bauen, und das sind immer mehr Entwickler, ist das kein Paper, das man nur im Auge behält. Es passiert bereits.

Aus dem Englischen übersetzt: zum Originalbeitrag