Extreme Vektorquantisierung mit 6-facher Speicherreduktion – und was das für LLMs bedeutet
SerieTensoren verstehen
Teil 3 von 8
Dieser Artikel greift einem Teil der Serie vor. Tensoren, Transformer-Architektur und Hardware-Details werden in den folgenden Teilen ausführlich erklärt – hier geht es um ein konkretes Praxisbeispiel, das zeigt, warum all das relevant ist: wie Google Tensoren im Betrieb so weit komprimiert, dass ein Faktor 6 weniger Speicher ausreicht, ohne dass die Ausgabequalität leidet.
Wer zuerst die Grundlagen lesen möchte, findet sie in den vorherigen Teilen der Serie. Wer direkt ins Konkrete einsteigen will – hier ist ein gutes Beispiel dafür, wohin die Reise geht.
Große Sprachmodelle haben ein Speicherproblem. Je länger der Kontext, desto mehr Zwischendaten müssen im Speicher gehalten werden – der sogenannte Key-Value-Cache wächst mit jeder Token-Position. Google Research hat mit TurboQuant einen Algorithmus veröffentlicht, der diesen Cache auf 3 Bit komprimiert, ohne messbare Genauigkeitsverluste zu erzeugen.
Das ist keine kleine Verbesserung. Es ist ein Faktor 6 weniger Speicher bei gleichwertiger Ausgabequalität.
Warum Quantisierung gerade jetzt so wichtig ist
Noch vor drei Jahren war ein LLM mit 7 Milliarden Parametern für die meisten Unternehmen nicht selbst betreibbar. Die Modelle liefen ausschließlich in der Cloud, weil die Hardware fehlte. Das hat sich geändert – aber der Speicherdruck ist geblieben, nur an anderer Stelle.
Die Modelle sind größer geworden. Kontextfenster sind gewachsen: von 4.000 Tokens (GPT-3) über 128.000 (GPT-4 Turbo) bis zu mehreren Millionen (Gemini 1.5). Und weil der KV-Cache linear mit der Kontextlänge skaliert, sind die Speicheranforderungen beim Betrieb proportional explodiert. Ein Modell mit 128k-Kontext auf einer GPU zu betreiben kostet nicht mehr, was die Gewichte kosten – es kostet auch den Cache, der mit jeder Token-Position wächst.
Das macht Quantisierung zu einer der meistdiskutierten Optimierungsrichtungen in der KI-Forschung. Nicht wegen akademischem Interesse, sondern wegen Betriebskosten.
Was es bisher gab – und warum es nicht gereicht hat
Quantisierung ist nicht neu. Die Grundidee ist einfach: statt 32-Bit-Gleitkommazahlen (float32) für Gewichte und Aktivierungen zu speichern, nimmt man weniger Bits. INT8 (8 Bit Integer) ist mittlerweile Standard. INT4 wird zunehmend eingesetzt. Frameworks wie GPTQ und AWQ haben gezeigt, dass Modellgewichte auf 4 Bit komprimiert werden können, ohne die Ausgabequalität zu zerstören.
Das Problem: Diese Methoden betreffen die Gewichte – also was das Modell gelernt hat. Der KV-Cache ist etwas anderes. Er enthält die Aktivierungen während der Inferenz – die dynamisch berechneten Zwischenwerte für jede Anfrage. Gewichte lassen sich offline quantisieren, aufwendig kalibrieren und einmal speichern. Den KV-Cache muss man für jede Anfrage neu berechnen und dabei in Echtzeit komprimieren.
Das stellt andere Anforderungen: Der Algorithmus muss schnell sein, darf kein Finetuning benötigen und muss trotzdem mathematisch korrekte Ergebnisse liefern. Bisherige Ansätze wie KVQuant oder KIVI gehen in diese Richtung – stoßen aber bei extremer Kompression (unter 4 Bit) schnell an Grenzen bei der Genauigkeit.
TurboQuant ist der Versuch, diesen Engpass zu durchbrechen.
Das Speicherproblem bei Transformer-Modellen
Transformer-Modelle speichern bei jedem Verarbeitungsschritt Key- und Value-Vektoren im Arbeitsspeicher – den KV-Cache. Was Vektoren genau sind und warum Transformer-Modelle so damit arbeiten, erklärt ein späterer Teil dieser Serie ausführlich. Hier reicht das Bild: Stell dir vor, jede Zeile in einem langen Dokument hinterlässt eine Markierung im Speicher. Je länger das Dokument, desto mehr Markierungen – und irgendwann wird der Speicher knapp.
Bei kurzen Anfragen ist das unproblematisch. Bei langen Dokumenten, mehrsprachigen Konversationen oder großen Kontextfenstern wird der KV-Cache zum Engpass: mehr Speicher, langsamere Verarbeitung, höhere Kosten.
Zur Verdeutlichung der Größenordnung: Llama 3.1 mit 70 Milliarden Parametern und einem 128k-Kontext erzeugt einen KV-Cache von mehreren Gigabyte – pro paralleler Anfrage. Wer zehn Anfragen gleichzeitig bearbeitet, multipliziert das. Auf einer H100-GPU mit 80 GB HBM3-Speicher ist dieser Cache einer der größten Kostentreiber beim Betrieb langer Kontexte.
Das gleiche Problem tritt bei Vektorsuche auf: Milliarden von Vektoren in einem Index zu halten und schnell durchsuchen zu können, erfordert entweder teure Hardware oder Kompromisse bei der Genauigkeit. Auch das – wie Vektoroperationen und Hardware zusammenhängen – ist Thema der kommenden Artikel dieser Serie.
TurboQuant adressiert beide Probleme mit demselben mathematischen Ansatz.
Wie TurboQuant funktioniert
Der Algorithmus läuft in zwei Stufen:
Stufe 1 – PolarQuant: Die Eingabevektoren werden zufällig rotiert, dann von kartesischen Koordinaten (x, y, z) in Polarkoordinaten umgewandelt – also Radius (Stärke des Vektors) und Winkel (Richtung/Bedeutung). Der Vorteil: Die Daten liegen auf einem vorhersehbaren Kreisraster. Normalisierungsschritte, die sonst Rechenzeit kosten, entfallen.
Stufe 2 – QJL (Quantized Johnson-Lindenstrauss): Ein mathematisch fundierter Fehlerkorrektur-Schritt. Er reduziert Vektoren auf einzelne Vorzeichenbits (+1 oder -1) und wendet einen speziellen Schätzer an, der den dabei entstehenden Bias gezielt ausgleicht. Das Ergebnis: Extrem komprimierte Daten, deren statistische Eigenschaften erhalten bleiben.
Der entscheidende Punkt: kein zusätzliches Training nötig. TurboQuant funktioniert auf bestehenden Modellen, ohne Finetuning. Das unterscheidet ihn von Ansätzen, die eine erneute Kalibrierungsphase benötigen – und macht ihn für den Betrieb existierender Systeme interessant.
Die Ergebnisse
Die Zahlen aus dem Google-Research-Paper sind bemerkenswert:
- 6-fache Speicherreduktion beim KV-Cache – bei vollständig erhaltener Genauigkeit auf LongBench, Needle In A Haystack, ZeroSCROLLS, RULER und L-Eval
- 3-Bit-Quantisierung des KV-Cache ohne Trainingsverlust
- 8-facher Performance-Gewinn mit 4-Bit-TurboQuant gegenüber 32-Bit auf H100-GPUs
- Bei Vektorsuche: Überlegene Recall-Raten gegenüber Product Quantization und RaBitQ auf GloVe-Datensätzen
Was diese Zahlen besonders belastbar macht: Die Autoren arbeiten nahe an den theoretischen Untergrenzen für verlustbehaftete Kompression. Das sind keine Ergebnisse, die auf einem günstigen Datensatz optimiert wurden – sondern mathematisch abgeleitete Effizienzgrenzen, die mit Beweisen unterlegt sind. Das macht die Methode vertrauenswürdiger für Produktionssysteme als viele heuristische Ansätze.
Was das praktisch bedeutet
Für LLM-Inferenz: Längere Kontextfenster werden günstiger. Wer heute ein 128k-Token-Kontextfenster betreibt, zahlt proportional zur Cache-Größe. Mit 6-facher Kompression könnten die gleichen Ressourcen ein sechsmal längeres Kontext-Fenster ermöglichen – oder die gleichen Anfragen auf einem Sechstel der Hardware.
Für Vektorsuche: Indizes werden kleiner. Systeme wie Retrieval-Augmented Generation (RAG), die Millionen oder Milliarden Vektoren indexieren, könnten mit TurboQuant deutlich weniger Speicher benötigen – bei gleicher oder besserer Suchqualität.
Für On-Device-KI: Kleinere Modelle auf Smartphones oder Edge-Geräten profitieren besonders. Weniger Speicher bedeutet, dass größere Modelle auf schwächerer Hardware laufen können. Apple führt mit Core ML und Private Cloud Compute bereits eigene Optimierungen in diese Richtung. Warum Hardware dabei so eine zentrale Rolle spielt – Tensor-Cores, Speicherlayout, Parallelverarbeitung – ist Thema eines eigenen Teils dieser Serie.
Für Anbieter: Der Effizienzdruck auf API-Anbieter ist hoch. Wer mit komprimiertem KV-Cache mehr Anfragen pro GPU durchführen kann, hat einen direkten Kostenvorteil. Das zieht sich von Hyperscalern bis zu kleineren Inference-Anbietern wie Together AI oder Fireworks.
Einordnung
TurboQuant ist kein fertiges Produkt – es ist ein Forschungsergebnis von Google Research, veröffentlicht von Amir Zandieh und Vahab Mirrokni. Ob und wann es in Google-Produkte oder Open-Source-Tooling (etwa vLLM oder llama.cpp) einfließt, ist offen.
Die Richtung der KI-Infrastruktur-Forschung ist aber klar: Die Lücke zwischen Modellgröße und verfügbarer Hardware wird nicht nur durch bessere Chips geschlossen, sondern durch algorithmetisch fundierte Effizienz. TurboQuant ist ein konkreter Schritt in diese Richtung – mit Zahlen, die im Vergleich zu bestehenden Ansätzen überzeugen.
Für alle, die selbst LLMs betreiben oder RAG-Systeme aufbauen, lohnt ein Blick auf das Paper. Die Methoden sind mathematisch sauber begründet, kommen ohne Training aus und sind auf bestehenden Modellen einsetzbar – das macht sie für den praktischen Einsatz interessanter als viele Alternativen, die eine Finetuning-Phase voraussetzen.