31 GB auf 4 GB. Diese Zahl hat im Juni 2026 ein paar Prozent von Microns Aktienkurs abgezogen und die halbe Dev-Twitter-Community in Aufruhr versetzt, ob die RAG-Kosten gerade eingebrochen sind. Die Mathematik dahinter ist solide: Googles TurboQuant (arXiv 2504.19874, angenommen für ICLR 2026) komprimiert den Arbeitsspeicher eines LLMs etwa 6-fach auf rund 3 Bits pro Wert — bei nahezu null Genauigkeitsverlust. Aber die meisten Berichte haben etwas falsch verstanden, und das verändert, wie man die ganze Geschichte lesen sollte.
Die Geschichte rund um Google TurboQuant und KI-Speicherkomprimierung besteht eigentlich aus zwei Erzählungen, die dasselbe Hoodie tragen. Lassen Sie uns das entwirren.
Wichtigste Erkenntnisse
- TurboQuant ist Googles trainingsfreier Komprimierungsalgorithmus: ~6-fache KV-Cache-Reduktion auf ~3 Bits, nahezu null Genauigkeitsverlust (ICLR 2026).
- TurboVec ist eine separate Rust-Bibliothek eines Drittanbieters, die TurboQuant implementiert. Google hat TurboVec nicht veröffentlicht.
- Das virale „31 GB → 4 GB, schlägt FAISS"-Demo gehört TurboVec, nicht dem reinen TurboQuant.
- Der echte Gewinn für Entwickler ist günstigere Long-Context-Inferenz und kleinere RAG-Indizes — Googles offizielle Veröffentlichung ist jedoch ein Paper, kein Produkt.
Was ist Googles TurboQuant, einfach erklärt?
TurboQuant ist Googles trainingsfreier, datenunabhängiger Vektor-Quantisierungsalgorithmus. Er komprimiert den KV-Cache eines LLMs etwa 6-fach, auf grob 3 Bits pro Wert, bei nahezu null Genauigkeitsverlust. Veröffentlicht als arXiv 2504.19874, angenommen für ICLR 2026. „Trainingsfrei" bedeutet: Er funktioniert bei bestehenden Modellen direkt, ohne Fine-Tuning.
Was genau wird komprimiert? Im Wesentlichen zwei Dinge.
Erstens der KV-Cache. Wenn ein Modell eine Konversation verarbeitet, speichert es eine laufende Zusammenfassung des bisherigen Gesprächs — den Key-Value-Cache. Stellen Sie sich das als das Kurzzeitgedächtnis des Modells vor. Je länger das Kontextfenster, desto mehr hält dieser Speicher, und desto mehr GPU-RAM frisst er. Ein 128k-Token-Chat kann den KV-Cache auf mehrere Gigabyte aufblähen. Deshalb wird Long-Context-Serving teuer, und deshalb ist Prompt-Caching zur API-Kostensenkung überhaupt erst ein Thema geworden.
Zweitens Vektorindizes. Die Embeddings, die semantische Suche und RAG antreiben, sind große Arrays von Fließkommazahlen. Speichern Sie Millionen davon in voller Präzision, stehen Sie vor Dutzenden Gigabytes RAM.
TurboQuant verkleinert beides. Das Besondere: Es braucht dafür keine Ihrer Daten. Die meisten Quantisierungsverfahren analysieren eine Stichprobe Ihrer Vektoren, bevor sie ein darauf abgestimmtes Codebuch erstellen. TurboQuant überspringt das. Es ist datenunabhängig — es erreicht sein Kompressionsverhältnis, ohne jemals Ihre Verteilung gesehen zu haben.
Der eigentliche Trick von TurboQuant ist nicht das Kompressionsverhältnis. Es ist, dass dafür null Trainingsdaten nötig sind.
Das ist die echte Neuerung. Sie können es auf ein Modell zeigen, das Sie bereits betreiben, und sofort profitieren.
TurboQuant vs. TurboVec: Die Verwechslung, die alle machen
TurboQuant ist Googles Komprimierungsalgorithmus (arXiv 2504.19874, ICLR 2026). TurboVec ist eine separate Rust- und Python-Bibliothek eines Drittanbieters (RyanCodrai/turbovec), die TurboQuant für die Vektorsuche implementiert. Google hat TurboVec nicht veröffentlicht. Das virale Ergebnis „31 GB → 4 GB, schlägt FAISS" gehört TurboVec, nicht dem nackten TurboQuant-Algorithmus. Wenn Sie aus diesem Beitrag eine Sache mitnehmen, dann diese.
Hier wird es unübersichtlich. Als der 31 GB→4 GB Benchmark Anfang Juni 2026 viral ging, titelten einige Medien (darunter Tech Startups), Google habe „TurboVec veröffentlicht". Das ist nicht passiert. Schauen Sie auf die Quelle: TurboVec liegt bei RyanCodrai/turbovec auf GitHub und PyPI. Es ist eine Open-Source-Bibliothek, entwickelt von einem Entwickler namens Ryan Codrai. MarkTechPost hatte die Einordnung richtig: „ein Rust-Vektorindex mit Python-Bindings, gebaut auf Googles TurboQuant-Algorithmus."
Das Verhältnis ist simpel: Google hat die Mathematik veröffentlicht, und die Community hat Werkzeuge damit gebaut. TurboVec ist das sichtbarste davon.
| TurboQuant | TurboVec | |
|---|---|---|
| Was es ist | Komprimierungsalgorithmus | Vektorindex-Bibliothek (Rust + Python) |
| Wer es gebaut hat | Google Research + DeepMind | Ryan Codrai (Drittanbieter) |
| Wo | arXiv 2504.19874, ICLR 2026 | GitHub RyanCodrai/turbovec, PyPI |
| Schlagzahl | ~6-fache KV-Cache-Reduktion auf ~3 Bits | 31 GB auf ~4 GB für einen 10-M-Dokument-Index |
| Status | Forschungspaper + Algorithmus | Funktionsfähige Open-Source-Bibliothek |
Google hat den Algorithmus gebaut. Ein Entwickler namens Ryan Codrai hat die Bibliothek gebaut, die alle screenshotten. Das ist nicht dasselbe.
Wenn Sie abwägen, wo ein TurboQuant-basierter Index neben Ihrem bestehenden Setup steht, stellt unser Überblick der besten Vektordatenbanken 2026 FAISS, Qdrant und die neueren komprimierten Indizes direkt gegenüber.
Wie komprimiert TurboQuant Speicher, ohne die Genauigkeit zu ruinieren?
TurboQuant verwendet eine Zufallsrotation plus ein Polar-Koordinaten-Quantisierungsschema (PolarQuant) und eine Johnson-Lindenstrauss-Projektion (QJL, Quantized Johnson-Lindenstrauss), um Werte gleichmäßig zu verteilen, bevor quantisiert wird. Diese nahezu optimale Verzerrung ermöglicht es, auf etwa 3 Bits pro Wert zu fallen, während die Genauigkeit nahezu intakt bleibt — ohne Modell-Retraining.
Lassen Sie uns das auseinandernehmen, denn der Fachjargon verbirgt eine ziemlich intuitive Idee.
Quantisieren bedeutet, Zahlen auf weniger Bits zu runden. Das Risiko ist, dass manche Dimensionen eines Vektors weitaus mehr Gewicht tragen als andere, sodass ungeschicktes Runden das Ergebnis ruiniert. TurboQuants Lösung: den Vektor zuerst zufällig rotieren. Stellen Sie sich vor, Sie mischen ein Kartenspiel gleichmäßig, bevor Sie ausgeben, damit kein einzelnes Blatt zu kopflastig wird. Nach der Rotation sind die Werte so verteilt, dass keine Dimension dominiert, und das Runden schadet deutlich weniger.
Das ist der QJL-Teil: eine Zufallsprojektion, die alles durchmischt, während Abstände erhalten bleiben. PolarQuant (präsentiert auf der AISTATS 2026) quantisiert die rotierten Werte dann in Polarkoordinaten, was ihrer Verteilung besser entspricht als einfaches Raster-Runden.
Das Ergebnis ist das, was das Paper nahezu optimale Verzerrung nennt: Es kommt der theoretischen Shannon-Grenze für den minimalen Qualitätsverlust bei einem gegebenen Bit-Budget nahe. Auf Deutsch: Bei 3 Bits pro Wert kann man kaum noch besser machen — und TurboQuant erreicht das, ohne Ihre Daten zu studieren.
Für den vollständigen Mechanismus sind der Google Research Blog und das arXiv-Paper die primären Quellen. InfoQ hat zudem eine saubere entwicklerorientierte Aufschlüsselung des KV-Cache-Aspekts, wenn Sie die Praktiker-Perspektive bevorzugen.
Was bedeuten 31 GB → 4 GB konkret für Ihre RAM-Rechnung?
Ein RAG-Index mit 10 Millionen Vektoren, der bei voller Präzision ~31 GB RAM benötigt, sinkt mit TurboVecs TurboQuant-Komprimierung auf rund ~4 GB — klein genug für eine günstige Standard-Instanz statt einer speicheroptimierten Tier. Beim KV-Cache bedeutet die ~6-fache Reduktion ungefähr 6-mal so viele parallele Long-Context-Sessions auf derselben GPU. Das ist der Teil, der tatsächlich auf einer Rechnung erscheint.
Eine kurze Anmerkung zur Ehrlichkeit: Alles Folgende ist geschätzt und modelliert (Juni 2026) auf Basis öffentlicher Cloud-Preise und der im Paper angegebenen Verhältnisse. Wir haben TurboVec nicht in Produktion betrieben, daher sind das Modellrechnungen, keine von uns physisch gemessenen Benchmarks. Die Preisstufen folgen derselben Grundlage wie in unserem Leitfaden zur Senkung von LLM API-Kosten.
Ein 10-Millionen-Dokument-Embedding-Index, volle Präzision vs. TurboVec-komprimiert, zugeordnet zur Cloud-RAM-Stufe, die man tatsächlich braucht:
| 10-M-Vektor-RAG-Index | Benötigter RAM | Typische Instanzstufe | Grobe monatliche RAM-Kosten |
|---|---|---|---|
| Volle Präzision (float32) | ~31 GB | 32 GB+ speicheroptimiert | höher (speicheroptimierte Stufe) |
| TurboVec-komprimiert | ~4 GB | 8 GB Standard | deutlich niedriger (Standard-Stufe) |
Der Sprung von einer speicheroptimierten Box zu einer kleinen Standard-Instanz ist die ganze Geschichte. Für einen selbst gehosteten Index ist das oft der Unterschied zwischen einer Rechnung, die wehtut, und einer, die kaum auffällt. Wenn Sie die Pipeline aufbauen, die darauf sitzt, behandelt unser Leitfaden zum Aufbau einer RAG-Anwendung, wo dieser Index eingebettet ist.
Jetzt die KV-Cache-Seite, modelliert für eine 24-GB-GPU bei 128k-Kontext-Sessions:
| KV-Cache, 24-GB-GPU @ 128k Kontext | Parallele Sessions (modelliert) |
|---|---|
| Volle Präzision | Basiswert (nenn es ~N) |
| ~3-Bit TurboQuant (~6-fach) | ungefähr 6-fach N |
Eine 6-fache KV-Cache-Reduktion spart nicht nur RAM. Sie kann eine GPU für Long-Context-Serving faktisch zu sechs machen.
Deshalb spielt das für Long-Context-Workloads eine größere Rolle als für alles andere. Wer viele kurze Chats bedient, hatte nie einen KV-Cache-Engpass. Wer 128k-Token-Agenten oder Dokumentanalyse betreibt, ändert seine Pro-GPU-Ökonomie über Nacht. VentureBeat berichtet, dass der Durchsatzgewinn auf einer H100 bis zu 8-fach bei über 50% Kosteneinsparung erreichen kann — das deckt sich mit unserer modellierten Parallelitätsmathematik.
Warum fielen Speicherchip-Aktien, und hat die Börse überreagiert?
Nach TurboQuants Bekanntmachung fielen Aktien von Micron, Western Digital und Seagate — aus Angst, dass radikaler billigerer KI-Speicher die künftige DRAM- und HBM-Nachfrage reduziert, das sogenannte „DeepSeek-Moment"-Framing. Analysten wie Wells Fargo argumentierten das Gegenteil: Günstigerer Speicher steigert den Gesamtverbrauch, nicht umgekehrt, via Jevons' Paradoxon.
Die Erzählung schrieb sich von selbst. KI ist derzeit der größte Käufer von Hochbandbreiten-Speicher, also folgt: Wenn ein Google-Algorithmus den Speicherbedarf 6-fach senkt, fällt die Nachfrage nach Chips — und damit die Chipanbieter. TechCrunch griff sogar zum „Pied Piper"-Vergleich, dem fiktiven Compression-Startup aus HBOs Silicon Valley, das versprach, alle Daten der Welt zu schrumpfen. Die Aktien fielen auf diese Angst hin.
Hier die nüchternere Einschätzung, die der Nachrichtenzyklus weitgehend überging. Wells Fargo verwies auf Jevons' Paradoxon: Wenn etwas günstiger und effizienter wird, konsumieren wir es insgesamt in der Regel mehr, nicht weniger. Günstigerer KI-Speicher bedeutet: Mehr Apps bringen Long-Context-Features auf den Markt, mehr Teams hosten größere RAG-Indizes selbst, und insgesamt findet mehr Inferenz statt. Effizienzgewinne haben historisch die Gesamtnachfrage gesteigert, nicht gedämpft.
Der Markt hat TurboQuant als Nachfragetöter eingepreist. Die Geschichte sagt: Günstigere Rechenleistung führt meist dazu, dass wir einfach mehr davon nutzen.
War der Rückgang eine Überreaktion? Wahrscheinlich, zumindest kurzfristig. Ein Forschungspaper ist kein sofortiger branchenweiter Umbau. Der Markt reagierte auf eine Schlagzeile; die tatsächliche Einführung dauert Quartale, und der Nachfrageinduzierungseffekt dürfte die Einsparungen am Ende übersteigen.
Lässt sich TurboQuant heute schon nutzen?
Ja, teilweise. Googles offizielle TurboQuant-Veröffentlichung ist das Paper und der Algorithmus, kein fertiges Produkt. Aber Community-Implementierungen existieren bereits: TurboVec (RyanCodrai/turbovec, auf PyPI) für Vektorindizes, und AmesianX/TurboQuant für llama.cpp (etwa 5,2-fach, mit Unterstützung für DeepSeek-V2/V3 und GLM-4.7-Flash via MLA). Das Ökosystem ist jung, aber nutzbar.
Wer die Vektorindex-Seite ausprobieren möchte, ist einen pip-Befehl entfernt:
pip install turbovec
# Rust + Python bindings, implementiert Googles TurboQuant für Vektorsuche
# llama.cpp KV-Cache-Impl (DeepSeek/MLA): github.com/AmesianX/TurboQuant
# Python-Referenzimplementierung: github.com/yashkc2025/turboquantFür die KV-Cache-Seite bei lokalen Modellen ist die AmesianX/TurboQuant llama.cpp-Implementierung die interessanteste Option — besonders wenn Sie DeepSeek- oder GLM-Modelle mit Multi-Head-Latent-Attention betreiben. Sie passt gut zu einem lokalen LLM-Setup, da ein kleinerer KV-Cache einen größeren Kontext auf derselben Karte erlaubt. Und wer entscheidet, welches Open-Source-Modell dafür genutzt werden soll, findet in unseren besten Open-Source-LLM-Benchmarks die DeepSeek- und GLM-Familien direkt behandelt.
Der ehrliche Vorbehalt: Hier handelt es sich um bewährte Mathematik, aber ein reifendes Ökosystem. Googles offizielle Lieferung ist Forschung, kein unterstütztes Produkt mit SLA.
Die ehrliche Antwort: TurboQuant ist lieferbares Mathe, kein Download-Button. Noch nicht.
Ist TurboQuant Hype oder echte Substanz? Ein ehrliches Urteil
TurboQuant ist real und genuinen clever. Das trainingsfreie Design ist die eigentliche Neuerung, und der KV-Cache-Gewinn ist besonders relevant für Long-Context-Workloads. Aber es ist keine Magie: Es ist ein Quantisierungsfortschritt unter vielen, die Schlagzeile 31 GB→4 GB gehört TurboVec und nicht Google, und die Aktienpanik hat ein Forschungsergebnis überdehnt.
Aus unserer Erfahrung beim Optimieren von Inferenz und RAM-Kosten für Kunden ist das Reibung, die darüber entscheidet, ob eine Technik wie diese es wert ist, übernommen zu werden. Bei trainingsfreien Ansätzen gewinnt man deutlich, weil kein Fine-Tuning-Zyklus anfällt, kein Codebuch zu warten ist und keine Modell-Chirurgie nötig ist. Man kann es an etwas anhängen, das bereits läuft.
Was sich ändert:
- Günstigere Long-Context-Inferenz, wo Speicherkosten tatsächlich spürbar sind.
- Kleinere selbst gehostete RAG-Indizes, die auf günstigere Hardware passen.
- Eine Komprimierungsoption, die man ohne Retraining übernehmen kann.
Was sich nicht ändert:
- Bei Short-Context-Chats und kleinen Modellen bringt es wenig, da der KV-Cache dort nie der Flaschenhals war.
- Es macht Ihre bestehende Quantisierung nicht über Nacht obsolet; es ist eine Ergänzung, kein Ersatz.
- Googles offizielle Veröffentlichung ist noch immer ein Paper, sodass produktionstaugliches Tooling vorerst der Community überlassen bleibt.
Wenn Sie herausfinden möchten, was das für Ihre eigene Inferenz oder RAM-Rechnung bedeutet, ist das genau die Art von Kostenmodellierung, die wir für Kunden bei Techsy durchführen. Vereinbaren Sie eine kostenlose Beratung, wenn Sie ein zweites Paar Augen dafür möchten.
Über den Autor
Mert Batur Gürbüz ist Mitgründer von Techsy.io, wo das Team KI-Agenten, Automatisierungssysteme und Voice/SDR-Pipelines für B2B-Kunden entwickelt. Er studiert an der University of Birmingham und schreibt über den LLM-Tooling-Stack, den das Techsy-Team tatsächlich in der Produktion einsetzt. Vernetzen Sie sich auf LinkedIn.
Häufig gestellte Fragen
Was ist Google TurboQuant?
TurboQuant ist der trainingsfreie Vektor-Quantisierungsalgorithmus von Google Research, veröffentlicht als arXiv 2504.19874 und angenommen für ICLR 2026. Er komprimiert den KV-Cache eines LLMs etwa 6-fach auf grob 3 Bits pro Wert — bei nahezu null Genauigkeitsverlust. Da er datenunabhängig ist, funktioniert er bei bestehenden Modellen ohne Fine-Tuning oder Retraining.
Hat Google TurboVec wirklich veröffentlicht?
Nein. TurboQuant ist Googles Algorithmus. TurboVec ist eine separate Rust- und Python-Bibliothek eines Drittanbieters (RyanCodrai/turbovec), die von einem unabhängigen Entwickler auf Basis von TurboQuant gebaut wurde. Einige Medien haben Google fälschlicherweise die Veröffentlichung von TurboVec zugeschrieben, als der virale 31 GB→4 GB Benchmark erschien — GitHub zeigt jedoch, dass es ein Community-Projekt ist.
Ist TurboQuant dasselbe wie TurboVec?
Nein. TurboQuant ist der von Google veröffentlichte Komprimierungsalgorithmus. TurboVec ist eine Bibliothek, die diesen Algorithmus für die Vektorsuche implementiert. Eines ist die Mathematik, das andere ein Werkzeug, das mit der Mathematik gebaut wurde. Das bekannte Ergebnis „31 GB → 4 GB, schlägt FAISS" gehört TurboVec, nicht etwas, das Google direkt ausgeliefert hat.
Verliert TurboQuant an Genauigkeit?
Nahezu null Genauigkeitsverlust ist die zentrale Behauptung des Papers, selbst bei etwa 3 Bits pro Wert. Der Algorithmus erreicht nahezu optimale Verzerrung (nahe der Shannon-Grenze), indem er Vektoren vor der Quantisierung zufällig rotiert, sodass keine einzelne Dimension dominiert. In der Praxis ist der Qualitätsverlust für die meisten Workloads so gering, dass er vernachlässigbar ist.
Wie viel RAM spart TurboQuant?
Beim KV-Cache etwa 6-fach, auf rund 3 Bits pro Wert. Auf der Vektorindex-Seite hat TurboVec einen 10-Millionen-Dokument-Index demonstriert, der von 31 GB auf rund 4 GB schrumpft — bis zu 92% Speicherreduktion. Ihre tatsächlichen Einsparungen hängen von Ihrer Präzisions-Baseline ab und davon, ob Sie KV-Cache, Embeddings oder beides komprimieren.
Ist das nur Hype, und warum fielen Speicheraktien?
Es ist ein echter Fortschritt, aber die Panik hat ein Forschungsergebnis überdehnt. Micron, Western Digital und Seagate fielen aus Angst, günstigerer KI-Speicher senke die Chip-Nachfrage. Wells Fargo konterte mit Jevons' Paradoxon: Günstigerer, effizienterer Speicher erhöht den Gesamtverbrauch erfahrungsgemäß. Ein Paper ist zudem kein sofortiger Branchenumbau, also sieht die kurzfristige Reaktion übertrieben aus.
Kann ich TurboQuant heute nutzen?
Teilweise. Googles offizielle Veröffentlichung ist Paper und Algorithmus, kein Produkt. Community-Implementierungen existieren: TurboVec auf PyPI für Vektorindizes, AmesianX/TurboQuant für llama.cpp (DeepSeek-V2/V3 und GLM-4.7-Flash via MLA) und yashkc2025/turboquant als Python-Referenz. Das Ökosystem ist jung, aber bereits nutzbar.
Wie unterscheidet sich TurboQuant von meiner bestehenden Quantisierung?
Die meisten Quantisierungsverfahren analysieren eine Datenstichprobe, um ein abgestimmtes Codebuch zu erstellen. TurboQuant ist trainingsfrei und datenunabhängig — es erreicht sein Verhältnis, ohne jemals Ihre Verteilung gesehen zu haben. Es zielt zudem spezifisch auf KV-Cache und Vektorindizes, mit nahezu optimaler Verzerrung, anstatt nur Modellgewichte zu komprimieren.
Funktioniert TurboQuant mit DeepSeek oder llama.cpp?
Ja, über die AmesianX/TurboQuant llama.cpp-Implementierung, die etwa 5,2-fache Komprimierung und Unterstützung für DeepSeek-V2/V3 und GLM-4.7-Flash via Multi-Head-Latent-Attention (MLA) bietet. Das macht es zu einer praktischen Option, wenn Sie diese Modelle selbst hosten und bei längeren Kontexten auf derselben Hardware einen kleineren KV-Cache wünschen.
Wann hilft TurboQuant am meisten?
Am meisten hilft es bei Long-Context-Inferenz und großen selbst gehosteten RAG-Indizes, wo Speicher der echte Flaschenhals ist. Eine 6-fache KV-Cache-Reduktion bedeutet mehr parallele 128k-Kontext-Sessions pro GPU, und ein komprimierter Embedding-Index passt auf günstigere Instanzen. Am wenigsten hilft es bei Short-Context-Chats und kleinen Modellen, wo der KV-Cache nie der Kostentreiber war.