TurboQuant: Der Durchbruch bei der KV-Cache-Komprimierung im Detail

Lesezeit: 10 Min. | Wie Googles 3-Bit-Komprimierung Long-Context-LLMs günstiger macht – und was sie über die nächsten 18 Monate der KI-Inferenz verrät

In jedem langen Gespräch mit einem großen Sprachmodell steckt ein stilles Problem, und es ist der Grund, warum solche Gespräche teuer werden. Es heißt KV-Cache und kann bei großen Kontextlängen mehr Speicher belegen als das Modell selbst. Am 24. März hat ein Team von Google Research TurboQuantveröffentlicht – ein Verfahren, das diesen Cache auf drei Bit pro Wert komprimiert, ohne messbaren Genauigkeitsverlust und ohne Feinabstimmung. Sechsmal weniger Speicher. Bis zu achtmal schnellere Attention auf einer H100. Es lohnt sich, das genauer zu verstehen, denn die Komprimierung des KV-Cache ist derzeit eines der wirkungsvollsten Probleme produktiver KI – und TurboQuant ist das bislang deutlichste öffentliche Signal dafür, dass das Feld einen Wendepunkt erreicht hat.

Ich leite Kentino. Dazu gehört unter anderem, Arbeiten wie diese sorgfältig zu lesen, damit unsere Kunden – Miner, Systembauer, neugierige Europäer, die den KI- und Krypto-Stack verfolgen – es nicht selbst tun müssen. Dieser Text ist mein Versuch zu erklären, was TurboQuant tatsächlich leistet, wie es sich in die breitere Forschungswelle zur KV-Cache-Komprimierung 2025–2026 einordnet und was ein nüchterner Beobachter von den nächsten achtzehn Monaten erwarten darf.

Das KV-Cache-Problem, ehrlich formuliert

Wenn ein Transformer Text erzeugt, bezieht sich jedes neue Token auf alle vorangegangenen Token. Damit die Key- und Value-Tensoren dieser früheren Token nicht bei jedem einzelnen Schritt neu berechnet werden müssen, speichert das Modell sie. Dieser Speicher ist der KV-Cache.

Der Cache wächst linear mit der Kontextlänge. Doppelt so langes Gespräch, doppelt so großer Cache. Bei einem mittelgroßen 8B-Modell mit 128k-Token-Kontext in FP16kann der KV-Cache für eine einzige Sitzung leicht mehrere Dutzend Gigabyte erreichen. Die Gewichte belegen vielleicht sechzehn. Der Cache stellt sie in den Schatten.

Daraus folgen drei praktische Konsequenzen.

Erstens ist Long-Context-Inferenz speicherbegrenzt, bevor sie rechenbegrenzt ist. Der VRAM geht Ihnen lange vor den FLOPs aus.

Zweitens skalieren die Betriebskosten schlecht. Jeder gleichzeitige Nutzer braucht seinen eigenen Cache. Eine GPU, die sonst fünfzig kurze Gespräche bündeln könnte, schafft womöglich nur fünf lange.

Drittens bleiben Inferenz auf dem Gerät und am Netzwerkrand für genau jene Modelle unerreichbar, die dort wirklich nützlich wären – weil nicht die Gewichte, sondern der Cache sich weigert hineinzupassen.

Den KV-Cache gut zu komprimieren – also aggressiv, günstig und ohne Qualitätsverlust bei der Ausgabe – ist deshalb keine Nebensächlichkeit. Es entscheidet darüber, welche Workloads tragfähig sind und welche nicht. Genau dieses Problem geht TurboQuant an.

Was TurboQuant tatsächlich tut

TurboQuant ist ein zweistufiger Algorithmus. Beide Stufen kommen ohne Training aus und sind datenunabhängig: keine Feinabstimmung, kein Kalibrierungsdatensatz, keine modellspezifische Anpassung. Sie wenden es an, und es funktioniert. Das wiegt ehrlich gesagt schwerer als das Kompressionsverhältnis, denn es erlaubt, das Verfahren reibungslos in einen bestehenden Inferenz-Stack einzusetzen.

Stufe eins: PolarQuant

Die erste Stufe ist PolarQuant, eine eigene Arbeit derselben Gruppe (Zandieh, Mirrokni et al., AISTATS 2026). Der Ansatz ist eher strukturell als statistisch.

Hochdimensionale Vektoren in kartesischen Koordinaten zu quantisieren, ist unhandlich. Der naheliegende Schritt – auf die Einheitskugel normieren und dann die Richtung quantisieren – erweist sich als teuer, denn die Norm jedes Vektors zu berechnen ist genau der Engpass, dem Sie entkommen wollten. Frühere Verfahren zahlten diesen Preis und verloren bei niedrigen Bitbreiten trotzdem an Genauigkeit.

PolarQuant umgeht die Falle mit zwei Kniffen. Zuerst wendet es eine zufällige Rotation an, was die Geometrie der Vektorverteilung – etwas kontraintuitiv – vorhersagbarer und handhabbarer macht. Anschließend rechnet es in Polarkoordinaten um – ein Radius für den Betrag, ein Winkel für die Richtung – und bildet diese auf ein kreisförmiges Gitter ab, das sich ohne Normierungsschritt quantisieren lässt. Das Ergebnis ist eine saubere Darstellung jedes Vektors mit wenigen Bit, die seine wesentliche Geometrie bewahrt.

Stufe zwei: QJL

PolarQuant allein hinterlässt einen Restfehler. Stufe zwei, Quantized Johnson-Lindenstrauss (QJL), behebt ihn mit einem einzigen zusätzlichen Bit pro Wert.

Die Johnson-Lindenstrauss-Transformation ist ein klassisches Resultat: Man kann hochdimensionale Vektoren mit einer zufälligen linearen Abbildung in einen sehr viel niedrigdimensionaleren Raum projizieren und die paarweisen Abstände näherungsweise erhalten. QJL geht einen Schritt weiter und behält von jeder projizierten Koordinate nur das Vorzeichenbit – plus eins, minus eins, sonst nichts. Über dieses eine Bit hinaus entsteht kein Speicheraufwand.

Mathematisch liefert QJL einen erwartungstreuen Schätzer der Attention-Scores. Es korrigiert den Rest aus PolarQuant, ohne die Verzerrung wieder einzuführen, an der naive Niedrigbit-Verfahren leiden. Das ist der Trick: Ein sorgfältig gewähltes Vorzeichenbit genügt, um den Fehler der ersten Stufe aufzuräumen.

Die Zahlen

Zusammen landen beide Stufen bei drei Bit pro Wert – sechsmal kleiner als die FP16 -Referenz. Auf einer NVIDIA H100 läuft die Berechnung der Attention-Logits mit 4 Bit statt 32 Bit bis zu achtmal schneller. Google hat Gemma, Mistral und Llama-3.1-8B-Instruct über LongBench, Needle In A Haystack, ZeroSCROLLS, RULER und L-Eval getestet. Die Genauigkeit blieb über alle fünf Long-Context-Benchmarks erhalten. Ein begleitender Vektorsuchtest auf GloVe-200 zeigte zudem einen besseren 1@k-Recall gegenüber den PQ- und RabbiQ-Referenzen, was darauf hindeutet, dass sich das Verfahren über KV-Caches hinaus verallgemeinern lässt.

Die vollständige Darstellung finden Sie im Blog von Google Research. TurboQuant wird auf der ICLR 2026 in Rio de Janeiro vorgestellt.

Die größere Welle

TurboQuant steht nicht allein. Es ist der prominenteste jüngere Beitrag in einem schnelllebigen Forschungsfeld, und wer es ohne diesen Kontext liest, überschätzt seine Neuartigkeit. Mehrere weitere Verfahren aus Ende 2025 und Anfang 2026 greifen denselben Engpass aus anderen Richtungen an.

Jedes zielt auf eine andere Nische. KVTC ist für die Offline-Wiederverwendung gedacht – einen Cache aus einem Gespräch zu speichern und in ein anderes zu laden, wo man sich aufwendigere Codierung gegen deutlich höhere Komprimierung leisten kann. ChunkKV ist für Fälle da, in denen aggressiv komprimiert, aber die Bedeutung bewahrt werden muss – wichtig bei Aufgaben, bei denen der Verlust eines Tokens schwerer wiegt als eine Nachkommastelle Genauigkeit. PM-KVQ ist auf die langen Chain-of-Thought-Workloads von Reasoning-Modellen abgestimmt. KVPress ist die Infrastruktur, mit der wir alle anderen ehrlich vergleichen können.

Der besondere Beitrag von TurboQuant ist die Kombination aus trainingsfreiem Betrieb, Eignung für Online-Inferenz und einem beweisbar erwartungstreuen Schätzer. Es ist das Verfahren, das am ehesten zuerst in Produktions-Frameworks landet – gerade weil es vom Modellbetreiber nichts verlangt.

Was das ermöglicht

Mit etwas Abstand von der Arbeit und mit Blick darauf, wohin das führt: Die praktischen Effekte lassen sich leichter benennen als beziffern.

Long-Context-Inferenz wird spürbar günstiger. Ist Ihr KV-Cache sechsmal kleiner, können Sie mehr Nutzer auf derselben GPU bündeln oder längere Kontexte im selben Budget bedienen – oder beides. Wer einen Inferenzdienst betreibt, sieht das binnen eines Quartals nach der Integration in seiner Marge.

Edge-Betrieb wird für Modellklassen möglich, die bislang außer Reichweite lagen. Ein 8B-Modell mit langem Kontext auf einer Workstation-GPU oder ein 3B-Modell auf einem Notebook rückt von „gerade so machbar" zu „Alltag", wenn der Cache um diesen Faktor schrumpft. Für Unternehmen, die keine Daten an Cloud-APIs schicken dürfen – Recht, Medizin, industrielle Telemetrie –, gilt das für den On-Premise-Betrieb genauso.

Die Hardware-Seite folgt unmittelbar, und hier wird es konkret. Komprimierung wie TurboQuant ändert nichts daran, welche GPUs es gibt; sie ändert, welche Workloads hineinpassen – und die Workloads, die man derzeit tatsächlich On-Premise fahren will, sind die chinesischen Open-Weights-Spitzenmodelle, die im ersten Quartal 2026 still und leise den SOTA-Thron übernommen haben.

Das aktuelle Feld sei ausdrücklich genannt, denn genau danach fragen unsere Kunden. Kimi K2.5 von Moonshot AI – 1T Parameter insgesamt, 32B aktiv, MoE, 256K Kontext, MIT-Lizenz – erschienen am 27. Januar und führend bei Code- und Mathematik-Benchmarks unter den offenen Gewichten. GLM-5 von Z.ai – 744B gesamt / 40B aktiv, 204K Kontext, MIT-lizenziert – derzeit an der Spitze des Intelligence Index für offene Gewichte und bei SWE-bench Verified. MiniMax M2.5 – 229B gesamt / 10B aktiv, 200K Kontext – erschienen am 12. Februar, aggressiv bepreist, über 80 % bei SWE-bench. Qwen3-Coder-Next von Alibaba – 80B gesamt / 3B aktiv, 256K Kontext nativ, erweiterbar auf 1M mit YaRN – dazu die breitere Qwen3-Familie von dichten 0.8B–27B bis zur 397B-A17B -MoE. Alles offene Gewichte. Alles heute einsetzbar.

Wir bauen bei Kentino Maschinen speziell für diesen Workload, deshalb hier die Rechnung im Detail. Unser Flaggschiff für Inferenz ist ein Aufbau mit 4× NVIDIA RTX 4090 – 96 GB gebündeltem VRAM, AMD EPYC 7542 auf einem ASRock Rack ROMED8-2T, 256 GB an DDR4-2666 ECC RDIMM, 2 TB NVMe, zwei 2-kW-Netzteile, im 24U-Rack. Darüber bauen wir Konfigurationen mit 4× RTX 5090 und 8× RTX 5090 (128 GB und 256 GB gebündelter VRAM) sowie Rechenzentrumsvarianten mit 4× L40 / L40S (192 GB gebündelt, ECC) für Dauerlast auf Enterprise-Niveau und den Produktivbetrieb rund um die Uhr.

Was TurboQuant an diesem Bild ändert, ist der KV-Cache-Term. Moderne MoE-Modelle nutzen bereits komprimierte Attention (latente Attention imMLA-Stil bei Kimi, GQA bei Qwen3), ihr KV-Cache je Token ist also von vornherein kleiner als bei älteren Modellen der Llama-Klasse. Legen Sie TurboQuant darüber, kommen weitere rund6×hinzu. Praktisch heißt das: Das Kontextfenster, das eine gegebene Maschine tatsächlich bedienen kann – und nicht nur bewirbt –, wächst spürbar. Die Gewichte haben sich nicht verändert. Der Engpass schon.

Zwei ehrliche Einschränkungen. Erstens sprengen Kimi K2.5 und GLM-5 in vollem FP8 (1T bzw. 744B gesamt an Gewichten) weiterhin das, was diese Maschinen fassen – dafür brauchen Sie einen Cluster oder müssen eine aggressive INT4 -Quantisierung in Kauf nehmen. Zweitens hängen die exakten Token-Grenzen von der Batchgröße, der konkreten Attention-Konfiguration des Modells und vom Framework ab (vLLM, SGLangund TensorRT-LLM setzen Niedrigbit-KV jeweils unterschiedlich um). Entscheidend ist aber die Richtung: Eine Maschine mit 4× RTX 4090 , die vor einem Jahr für dichte 13B-Modelle sinnvoll war, ist heute die richtige Antwort für Qwen3-Coder-Next mit vollem 256K Kontext. Ein Aufbau mit 4× RTX 5090 bewältigt das Coding-Modell der Klasse 80B aktivbequem und hat noch Luft für gleichzeitige Nutzer. Mit 8× RTX 5090 oder 4× L40S erschließen Sie MiniMax M2.5 und die größeren Qwen3-MoE-Varianten im Produktivmaßstab. Die Hardware ist nicht größer geworden; der Workload ist kleiner geworden.

Und jeder Inferenz-Workload, der dauerhaft auf Betriebstelemetrie läuft, profitiert im gleichen Maß. Die Optimierung von Mining-Flotten ist ein reales Beispiel: Betreiber wie OneMiners fahren KI-gesteuerte Effizienzsysteme über Tausende von ASICs, und die darunterliegende Inferenzschicht skaliert unmittelbar damit, wie viel Kontext jedes Modell günstig halten kann. Diese Forschungsrichtung verwandelt solche Workloads nicht über Nacht, aber sie verschiebt die Kurve dessen, was bezahlbar ist.

Die ehrliche Prognose lautet: schrittweise. Eine 6× -Speicherreduktion an einem Engpass erschafft keine neue Welt. Sie erschafft eine etwas günstigere, etwas kontextstärkere, etwas besser betreibbare Version der Welt, die wir schon haben. Über die gesamte Branche summiert, ist das dennoch sehr viel gespartes Geld und sehr viel gesparte Entwicklungsarbeit.

Worauf man 2026–2027 achten sollte

Ein paar konkrete Punkte, grob nach Wahrscheinlichkeit geordnet.

Framework-Integration. vLLM, TensorRT-LLMund SGLang werden Verfahren im Stil von TurboQuant binnen Monaten aufnehmen, vermutlich mit KVPress als Benchmarking-Schicht. Die quelloffene Triton-Implementierung, die das Google-Team veröffentlicht hat, macht das beinahe zur Routine.

Unterstützung auf Hardware-Ebene. NVIDIA hat über KVTC und KVPress Interesse an Niedrigbit-Attention-Primitiven signalisiert. Rechnen Sie damit, dass Werkzeuge der Blackwell-Generation 3- bis 4-Bit-KV-Formate als vollwertig und nicht als experimentell behandeln.

Konsolidierung der Verfahren. Die fünf Ansätze oben lösen überlappende Probleme. Ein vereinheitlichter Stack – geometrische Komprimierung im PolarQuant-Stil für die Online-Attention, Entropiecodierung im KVTC-Stil für die Offline-Speicherung, semantische Gruppierung im ChunkKV-Stil als Vorstufe – ist der wahrscheinliche Endpunkt. Dorthin gelangt keine einzelne Arbeit; der Stack entsteht über ein Jahr Integrationsarbeit.

Echte Kostensenkungen im Betrieb. Bis Ende 2026 sollten die Betriebskosten für Long-Context-Inferenz sichtbar niedriger liegen als heute, wobei der Großteil des Gewinns aus Komprimierung und nicht aus neuem Silizium kommt. Das ist der sauberste Maßstab dafür, ob diese Forschungsrichtung Erfolg hatte.

Fazit

TurboQuant ist ein echter Fortschritt an einem echten Engpass, und es kam mitten in einer Forschungswelle, die das Problem gleich aus mehreren Richtungen angeht. Die Schlagzeilenzahlen sind für sich genommen beeindruckend – drei Bit, sechsmal, achtmal –, doch die wichtigere Eigenschaft ist, dass das Verfahren vom Modellbetreiber nichts verlangt. Trainingsfreie, datenunabhängige Methoden sind die, die tatsächlich in den Betrieb gelangen.

Wenn Sie Long-Context-Inferenz in irgendeinem Maßstab betreiben, lohnt sich die Beobachtung. Wenn nicht, lohnt sich das Verständnis trotzdem – denn die Ökonomie der Modelle, die Sie irgendwann nutzen werden, wird gerade still und leise von Arbeiten wie dieser festgelegt.