heise+ | Googles TurboQuant-Verfahren: Praxistest auf einer AMD-GPU

Was geschehen ist: Googles TurboQuant im Praxistest

Das von Google entwickelte TurboQuant-Verfahren zielt darauf ab, den sogenannten Key-Value-Cache (KV-Cache) großer Sprachmodelle (LLMs) massiv zu verkleinern. In einem detaillierten Praxistest, durchgeführt von Kai Bennett für das iX-Magazin, wurde untersucht, wie sich diese Technologie auf einer AMD-Grafikkarte schlägt. Die Kernbotschaft des Verfahrens ist die Kompression des Speichers auf 3 Bit, was eine deutlich effizientere Nutzung des Grafikspeichers (VRAM) ermöglichen soll. Während die Modellgewichte bereits seit Längerem erfolgreich komprimiert werden, stellt der KV-Cache bei langen Kontexten eine erhebliche Herausforderung für die Hardware dar. Der Test zeigt, dass das Versprechen einer speicherschonenden Verarbeitung bei gleichbleibender Qualität zwar in der Theorie Bestand hat, in der praktischen Anwendung auf AMD-Hardware jedoch spezifische Anpassungen und eine sorgfältige Abwägung zwischen Präzision und Performance erfordert. Damit adressiert Google ein zentrales Problem der aktuellen KI-Entwicklung: den enormen Speicherbedarf bei der Verarbeitung langer Texteingaben, die das System sonst schnell an seine physischen Grenzen bringen.

Die Einzelheiten: Zahlen, Fakten und technische Parameter

Der Test wurde mit dem Modell Gemma-4-31B durchgeführt. Auf einer GPU mit 32 Gigabyte VRAM belegt dieses Modell in der gängigen Q4-Quantisierung etwa 17 Gigabyte, was zunächst ausreichend erscheint. Problematisch wird es jedoch, sobald der Kontext hinzukommt. Ein Sprachmodell arbeitet in zwei Phasen: dem Prefill, dem anfänglichen Einlesen des Prompts, und dem Decode, bei dem Token für Token generiert wird. Um nicht jeden Schritt neu berechnen zu müssen, speichert das Modell Key- und Value-Vektoren im KV-Cache. Bei einer Konfiguration von 256.000 Token belegt ein unkomprimierter Cache mit 16-Bit-Fließkommazahlen (f16) rund 40 Gigabyte. Da dies den verfügbaren VRAM übersteigt, lagert das System Daten in den geteilten GPU-Speicher aus, also in das System-RAM. Der Zugriff über den PCIe-Bus ist mit etwa 60 Gigabyte pro Sekunde deutlich langsamer als die 640 Gigabyte pro Sekunde des lokalen Grafikspeichers. TurboQuant reduziert den Cache auf 3 Bit, wodurch das Modell Gemma-4-31B nur noch 23,4 Gigabyte belegt. Der Test ergab, dass die Konfiguration 'q8_0/turbo4' die höchste Treue bietet, während 'turbo3' zwar einen 256K-Kontext ermöglicht, aber einen hohen Per-Token-Drift aufweist.

Hintergrund: Die Herausforderung des KV-Cache

Warum ist der KV-Cache ein solcher Flaschenhals? Sprachmodelle wie Gemma-4-31B müssen bei der Generierung von Antworten auf die gesamte Historie des Gesprächs zurückgreifen. Diese Historie wird in den Key- und Value-Vektoren abgelegt. Je länger der Kontext ist, den ein Anwender dem Modell vorgibt, desto größer wird dieser Cache. In der Vergangenheit war die Quantisierung von Modellgewichten ein Standardverfahren, um LLMs auf Consumer-Hardware lauffähig zu machen. Die Quantisierung des KV-Cache ist jedoch ein neuerer Ansatz. Bisherige Methoden in Frameworks wie llama.cpp erlaubten bereits eine Kompression auf 4 Bit, wobei Keys und Values getrennt voneinander behandelt werden konnten. Googles TurboQuant geht einen Schritt weiter und drückt die Daten auf 3 Bit. Die Notwendigkeit für solche Verfahren ergibt sich aus der Diskrepanz zwischen der wachsenden Kontextlänge moderner Modelle und der begrenzten Kapazität des Grafikspeichers. Ohne diese Kompression würden viele Workloads auf lokaler Hardware schlichtweg scheitern oder durch das Auslagern in den langsamen Arbeitsspeicher so langsam werden, dass sie für den produktiven Einsatz unbrauchbar wären.

Die Beteiligten: Akteure und technologische Akzente

Die Entwicklung von TurboQuant stammt aus dem Hause Google, einem der führenden Akteure im Bereich der Künstlichen Intelligenz. Die praktische Umsetzung und Evaluierung auf AMD-Hardware wurde von Kai Bennett vorgenommen, der als AI Software Architect bei adesso tätig ist und zudem Mitgründer des Start-ups securesight.ai. Seine Arbeit konzentriert sich auf produktive GenAI-Systeme und lokale LLM-Stacks. Die technische Basis für den Test bildete das Framework llama.cpp, das durch die Integration von TurboQuant-Funktionalitäten erweitert wurde. Die im Test verwendete Hardware, eine AMD-GPU, verdeutlicht den Anspruch, KI-Technologien nicht nur auf dem Marktführer-Ökosystem von Nvidia, sondern auch auf alternativen Plattformen lauffähig zu machen. Die Notwendigkeit eines Patches, der mittlerweile in die Version 'llama-cpp-turboquant' eingeflossen ist, unterstreicht die enge Zusammenarbeit zwischen der Open-Source-Community und den Entwicklern bei der Implementierung solcher spezialisierten Verfahren.

Einordnung: Was TurboQuant für die Praxis bedeutet

Einzuordnen ist das Verfahren als ein notwendiger Kompromiss zwischen Speicherplatz und Rechengenauigkeit. Den Berichten zufolge ist TurboQuant ein mächtiges Werkzeug, um die Grenzen des lokal Machbaren zu verschieben. Die Möglichkeit, einen 256.000-Token-Kontext auf einer 32-Gigabyte-Karte zu halten, ist ein signifikanter Fortschritt. Allerdings zeigt der Test auch, dass '3 Bit' kein magischer Wert ohne Konsequenzen ist. Die Wahl zwischen hoher Treue und maximalem Kontext ist eine bewusste Entscheidung, die der Anwender treffen muss. Während 'turbo4' nahezu fehlerfreies Retrieval bei 128.000 Token bietet, erkauft man sich die Verdopplung des Kontextes auf 256.000 Token mit dem 'turbo3'-Verfahren durch einen spürbaren Drift in der Qualität der generierten Token. Es ist also kein 'One-Size-Fits-All'-Ansatz, sondern eine spezialisierte Lösung für Anwendungsfälle, bei denen die Kontextlänge wichtiger ist als die absolute Präzision der Antwort. Die Einordnung zeigt, dass Hardware-Limitierungen durch intelligente Software-Kompression zwar umgangen, aber physikalische Gesetze der Informationsdichte nicht vollständig aufgehoben werden können.

Offene Fragen: Was der Quelltext nicht klärt

Der Quelltext bietet eine detaillierte technische Analyse, lässt jedoch einige Fragen offen, die für Anwender von Bedeutung sein könnten. So wird beispielsweise nicht explizit darauf eingegangen, wie sich TurboQuant im Vergleich zu anderen modernen Kompressionsmethoden verhält, die über 3 Bit hinausgehen oder andere mathematische Ansätze zur Reduktion der Vektoren verwenden. Auch bleibt unklar, wie hoch der zusätzliche Rechenaufwand (Overhead) für die De-Quantisierung während der Inferenz genau ist. Zwar wird die Geschwindigkeit bei der Nutzung des System-RAMs thematisiert, doch eine detaillierte Aufschlüsselung der Latenzzeiten bei der Nutzung von TurboQuant auf unterschiedlichen GPU-Architekturen innerhalb des AMD-Portfolios fehlt. Ebenso wird nicht näher beleuchtet, ob das Verfahren auf anderen Modellarchitekturen als Gemma-4-31B ähnliche Ergebnisse liefert oder ob die Effektivität der 3-Bit-Kompression stark vom Training des jeweiligen Modells abhängt. Diese Lücken zeigen, dass die Anwendung von TurboQuant derzeit noch ein Feld für Experten ist, die bereit sind, durch Experimente die optimale Konfiguration für ihr spezifisches Modell zu finden.

Wie es weitergeht: Ausblick auf die Entwicklung

Die Integration des notwendigen Patches in 'llama-cpp-turboquant' markiert einen wichtigen Meilenstein für die Verfügbarkeit der Technologie. Die Entwicklung ist jedoch nicht abgeschlossen. Da die Community und Entwickler wie Kai Bennett kontinuierlich an der Optimierung der HIP-Graphen und der Speicherverwaltung arbeiten, ist davon auszugehen, dass die Stabilität und Benutzerfreundlichkeit bei künftigen Updates weiter zunehmen werden. Die Entscheidung für oder gegen den Einsatz von TurboQuant wird in den kommenden Monaten maßgeblich davon abhängen, wie schnell sich die Unterstützung für solche Quantisierungsverfahren in Standard-Frameworks verbreitet. Anwender, die auf lokale LLM-Stacks setzen, sollten die Entwicklung der 'llama-cpp'-Repositories genau beobachten, da dort die Weichen für die breite Adaption der 3-Bit-Technologie gestellt werden. Zukünftige Iterationen könnten zudem die Wahlmöglichkeiten zwischen verschiedenen Bit-Stufen verfeinern, um den schmalen Grat zwischen Kontextlänge und Antwortqualität noch präziser zu steuern, als es mit den derzeitigen 'turbo3' und 'turbo4' Profilen möglich ist.