Jenseits der TurboQuant-RaBitQ-Debatte: Warum Vektorquantisierung für KI-Infrastrukturkosten wichtig ist

Googles TurboQuant-Papier (ICLR 2026) meldete eine 6-fache KV-Cache-Komprimierung mit einem Genauigkeitsverlust von nahezu Null - Ergebnisse, die auffällig genug waren, um Speicherchip-Aktien an einem einzigen Tag um 90 Milliarden Dollar zu drücken. SK Hynix fiel um 12 %. Samsung fiel um 7 %.

Die Arbeit wurde schnell unter die Lupe genommen. Jianyang Gao, Erstautor von RaBitQ (SIGMOD 2024), warf Fragen über die Beziehung zwischen der Methodik von TurboQuant und seiner früheren Arbeit über Vektorquantisierung auf. (Wir werden demnächst ein Gespräch mit Dr. Gao veröffentlichen - folgen Sie uns, wenn Sie daran interessiert sind).

In diesem Artikel geht es nicht darum, in dieser Diskussion Partei zu ergreifen. Was uns auffällt, ist etwas Größeres: Die Tatsache, dass ein einziges Papier zur Vektorquantisierung einen Marktwert von 90 Milliarden Dollar bewegen konnte, zeigt, wie wichtig diese Technologie für die KI-Infrastruktur geworden ist. Ob es sich um die Komprimierung von KV-Cache in Inferenzmaschinen oder um die Komprimierung von Indizes in Vektordatenbanken handelt, die Fähigkeit, hochdimensionale Daten unter Beibehaltung der Qualität zu schrumpfen, hat enorme Auswirkungen auf die Kosten - und es ist ein Problem, an dem wir gearbeitet haben, indem wir RaBitQ in die Vektordatenbank Milvus integriert und in eine Produktionsinfrastruktur überführt haben.

Im Folgenden erfahren Sie, warum die Vektorquantisierung derzeit so wichtig ist, wie TurboQuant und RaBitQ im Vergleich zueinander abschneiden, was RaBitQ ist und wie es funktioniert, welche technische Arbeit hinter der Integration in die Milvus-Datenbank steckt und wie die Speicheroptimierung für KI-Infrastrukturen im Allgemeinen aussieht.

Warum ist die Vektorquantisierung für die Infrastrukturkosten von Bedeutung?

Vektorquantisierung ist nicht neu. Neu ist nur, wie dringend die Branche sie braucht. In den letzten zwei Jahren sind die LLM-Parameter in die Höhe geschossen, die Kontextfenster haben sich von 4K auf 128K+ Token ausgedehnt, und unstrukturierte Daten - Text, Bilder, Audio, Video - sind zu einem erstklassigen Input für KI-Systeme geworden. Jeder dieser Trends führt zu mehr hochdimensionalen Vektoren, die gespeichert, indiziert und durchsucht werden müssen. Mehr Vektoren, mehr Speicher, mehr Kosten.

Wenn Sie Vektorsuche in großem Maßstab betreiben - RAG-Pipelines, Empfehlungsmaschinen, multimodales Retrieval - sind die Speicherkosten wahrscheinlich eines Ihrer größten Infrastrukturprobleme.

Während der Modellbereitstellung verlässt sich jeder größere LLM-Inferenzstapel auf den KV-Cache, der zuvor berechnete Schlüssel-Wert-Paare speichert, damit der Aufmerksamkeitsmechanismus sie nicht für jedes neue Token neu berechnen muss. Das macht O(n)-Inferenz statt O(n²) möglich. Jedes Framework von vLLM bis TensorRT-LLM hängt davon ab. Aber der KV-Cache kann mehr GPU-Speicher verbrauchen als die Modellgewichte selbst. Längere Kontexte, mehr gleichzeitige Benutzer, und die Spirale dreht sich schnell.

Der gleiche Druck trifft Vektordatenbanken - Milliarden von hochdimensionalen Vektoren, die im Speicher liegen, jeder ein 32-Bit-Float pro Dimension. Die Vektorquantisierung komprimiert diese Vektoren von 32-Bit-Fließkommazahlen auf 4-Bit-, 2-Bit- oder sogar 1-Bit-Darstellungen, wodurch der Speicher um 90 % oder mehr schrumpft. Ob KV-Cache in Ihrer Inferenzmaschine oder Indizes in Ihrer Vektordatenbank, die zugrunde liegende Mathematik ist dieselbe, und die Kosteneinsparungen sind real. Aus diesem Grund hat ein einziger Bericht über einen Durchbruch in diesem Bereich einen Börsenwert von 90 Milliarden Dollar erreicht.

TurboQuant vs. RaBitQ: Was ist der Unterschied?

Sowohl TurboQuant als auch RaBitQ beruhen auf derselben grundlegenden Technik: der Anwendung einer Zufallsrotation(Johnson-Lindenstrauss-Transformation) auf Eingangsvektoren vor der Quantisierung. Durch diese Rotation werden unregelmäßig verteilte Daten in eine vorhersagbare gleichmäßige Verteilung umgewandelt, was die Quantisierung mit geringen Fehlern erleichtert.

Abgesehen von dieser gemeinsamen Grundlage zielen die beiden Verfahren auf unterschiedliche Probleme ab und verfolgen unterschiedliche Ansätze:

	TurboQuant	RaBitQ
Ziel	KV-Cache in LLM-Inferenz (ephemere, anfragebezogene Daten)	Persistente Vektorindizes in Datenbanken (gespeicherte Daten)
Ansatz	Zweistufig: PolarQuant (Lloyd-Max skalarer Quantisierer pro Koordinate) + QJL (1-Bit-Restkorrektur)	Einstufig: Hypercube-Projektion + unverzerrter Abstandsschätzer
Bitbreite	3-Bit-Schlüssel, 2-Bit-Werte (gemischte Präzision)	1-Bit pro Dimension (auch Mehr-Bit-Varianten möglich)
Theoretischer Anspruch	Nahezu optimaler MSE-Verzerrungsgrad	Asymptotisch optimaler Schätzfehler für das innere Produkt (entspricht den unteren Schranken von Alon-Klartag)
Stand der Produktion	Gemeinschaftsimplementierungen; keine offizielle Freigabe von Google	Ausgeliefert in Milvus 2.6, übernommen von Faiss, VSAG, Elasticsearch

Der Hauptunterschied für Praktiker: TurboQuant optimiert den transienten KV-Cache innerhalb einer Inferenzmaschine, während RaBitQ auf die persistenten Indizes abzielt, die eine Vektordatenbank aufbaut, verteilt und über Milliarden von Vektoren abfragt. Im weiteren Verlauf dieses Artikels werden wir uns auf RaBitQ konzentrieren - den Algorithmus, den wir in Milvus integriert haben und in der Produktion einsetzen.

Was ist RaBitQ und was leistet es?

Zunächst das Fazit: Bei einem 10-Millionen-Vektor-Datensatz mit 768 Dimensionen komprimiert RaBitQ jeden Vektor auf 1/32 seiner ursprünglichen Größe, während die Wiedererkennungsrate bei über 94 % liegt. In Milvus bedeutet das einen 3,6-fach höheren Abfragedurchsatz als bei einem Index mit voller Genauigkeit. Dabei handelt es sich nicht um eine theoretische Hochrechnung, sondern um ein Benchmark-Ergebnis aus Milvus 2.6.

Und nun, wie es dazu kommt.

Die herkömmliche binäre Quantisierung komprimiert FP32-Vektoren auf 1 Bit pro Dimension - eine 32-fache Komprimierung. Der Nachteil: Die Wiedererkennungsrate sinkt, weil zu viele Informationen weggeworfen werden. RaBitQ (Gao & Long, SIGMOD 2024) behält die gleiche 32-fache Komprimierung bei, bewahrt aber die Informationen, die für die Suche wirklich wichtig sind. Eine erweiterte Version (Gao & Long, SIGMOD 2025) beweist, dass dies asymptotisch optimal ist und den theoretischen unteren Grenzen von Alon & Klartag (FOCS 2017) entspricht.

Warum spielen Winkel in hohen Dimensionen eine größere Rolle als Koordinaten?

Die wichtigste Erkenntnis: In hohen Dimensionen sind die Winkel zwischen Vektoren stabiler und informativer als einzelne Koordinatenwerte. Dies ist eine Folge der Messwertkonzentration - dasselbe Phänomen, das die Johnson-Lindenstrauss-Zufallsprojektionen funktionieren lässt.

In der Praxis bedeutet das: Sie können die genauen Koordinatenwerte eines hochdimensionalen Vektors verwerfen und nur seine Richtung relativ zum Datensatz behalten. Die Winkelbeziehungen - von denen die Suche nach den nächsten Nachbarn eigentlich abhängt - bleiben bei der Komprimierung erhalten.

Wie funktioniert RaBitQ?

RaBitQ setzt diese geometrische Erkenntnis in drei Schritten um:

Schritt 1: Normalisieren. Jeder Vektor wird in Bezug auf den Schwerpunkt des Datensatzes zentriert und auf eine Einheitslänge skaliert. Dadurch wird das Problem in eine Schätzung des inneren Produkts zwischen Einheitsvektoren umgewandelt, die leichter zu analysieren und zu begrenzen ist.

Schritt 2: Zufällige Rotation + Hyperkubusprojektion. Wenden Sie eine zufällige orthogonale Matrix (eine Rotation vom Typ Johnson-Lindenstrauss) an, um Verzerrungen in Richtung einer Achse zu entfernen. Projizieren Sie jeden gedrehten Vektor auf den nächstgelegenen Scheitelpunkt eines {±1/√D}^D-Hyperwürfels. Jede Dimension kollabiert auf ein einziges Bit. Das Ergebnis: ein D-Bit-Binärcode pro Vektor.

Schritt 3: Unverzerrte Abstandsschätzung. Konstruieren Sie einen Schätzer für das innere Produkt zwischen einer Abfrage und dem ursprünglichen (unquantisierten) Vektor. Der Schätzer ist nachweislich unverzerrt mit einem durch O(1/√D) begrenzten Fehler. Für 768-dimensionale Vektoren liegt die Wiederfindungsrate bei über 94 %.

Die Abstandsberechnung zwischen binären Vektoren reduziert sich auf bitweise UND + popcount - Operationen, die moderne CPUs in einem einzigen Zyklus ausführen. Das macht RaBitQ schnell, nicht nur klein.

Warum ist RaBitQ praktisch, nicht nur theoretisch?

• Keine Ausbildung erforderlich. Drehung anwenden, Vorzeichen prüfen. Keine iterative Optimierung, kein Lernen des Codebuchs. Die Indizierungszeit ist vergleichbar mit der Produktquantisierung.
• Hardware-freundlich. Abstandsberechnung ist bitweise AND + popcount. Moderne CPUs (Intel IceLake+, AMD Zen 4+) haben dedizierte AVX512VPOPCNTDQ-Anweisungen. Die Ein-Vektor-Schätzung läuft 3x schneller als PQ-Lookup-Tabellen.
• Mehrbit-Flexibilität. Die RaBitQ-Bibliothek unterstützt Varianten über 1-Bit hinaus: 4-Bit erreicht ~90% Recall, 5-Bit ~95%, 7-Bit ~99% - alle ohne Reranking.
• Kompatibel. Lässt sich in bestehende Indexstrukturen wie IVF-Indizes und HNSW-Graphen einfügen und arbeitet mit FastScan für Batch-Abstandsberechnungen.

Vom Papier zur Produktion: Was wir für die Auslieferung von RaBitQ in Milvus entwickelt haben

Der ursprüngliche RaBitQ-Code ist ein Forschungsprototyp für eine Maschine. Damit er in einem verteilten Cluster mit Sharding, Failover und Echtzeit-Ingestion funktioniert, mussten vier technische Probleme gelöst werden. Bei Zilliz ging es nicht nur um die Implementierung des Algorithmus, sondern auch um die Integration der Engine, die Hardware-Beschleunigung, die Optimierung des Index und die Abstimmung der Laufzeit, um RaBitQ zu einer industrietauglichen Funktion in Milvus zu machen. Weitere Details finden Sie auch in diesem Blog: Vektorkomprimierung auf die Spitze treiben: Wie Milvus mit RaBitQ 3× mehr Abfragen bedient

RaBitQ verteilungsfähig machen

Wir haben RaBitQ direkt in Knowhere, die Kernsuchmaschine von Milvus, integriert - nicht als Plugin, sondern als nativer Indextyp mit einheitlichen Schnittstellen. Er arbeitet mit der gesamten verteilten Architektur von Milvus: Sharding, Partitionierung, dynamische Skalierung und Sammlungsmanagement.

Die größte Herausforderung besteht darin, das Quantisierungscodebuch (Rotationsmatrix, Schwerpunktvektoren, Skalierungsparameter) segmentorientiert zu gestalten, so dass jeder Shard seinen eigenen Quantisierungsstatus erstellt und speichert. Indexerstellung, Verdichtung und Lastausgleich verstehen den neuen Indextyp von Haus aus.

Jeden Zyklus aus Popcount herausquetschen

Die Geschwindigkeit von RaBitQ beruht auf Popcount - dem Zählen der gesetzten Bits in binären Vektoren. Der Algorithmus ist von Natur aus schnell, aber wie viel Durchsatz Sie erzielen, hängt davon ab, wie gut Sie die Hardware nutzen. Wir haben spezielle SIMD-Codepfade für die beiden vorherrschenden Serverarchitekturen entwickelt:

• x86 (Intel IceLake+ / AMD Zen 4+): Der VPOPCNTDQ-Befehl von AVX-512 berechnet Popcount parallel über mehrere 512-Bit-Register. Die inneren Schleifen von Knowhere werden umstrukturiert, um binäre Abstandsberechnungen in SIMD-Breite-Chunks zu bündeln und so den Durchsatz zu maximieren.
• ARM (Graviton, Ampere): SVE-Anweisungen (Scalable Vector Extension) für das gleiche parallele Popcount-Muster - entscheidend, da ARM-Instanzen in kostenoptimierten Cloud-Bereitstellungen immer häufiger verwendet werden.

Eliminierung von Laufzeit-Overhead

RaBitQ benötigt zur Abfragezeit zusätzliche Fließkommaparameter: den Datensatzschwerpunkt, Normen pro Vektor und das innere Produkt zwischen jedem quantisierten Vektor und seinem Original (das vom Distanzschätzer verwendet wird). Die Berechnung dieser Parameter pro Abfrage erhöht die Latenzzeit. Die Speicherung der vollständigen Originalvektoren macht den Zweck der Komprimierung zunichte.

Unsere Lösung: Vorberechnung und Speicherung dieser Parameter während des Indexaufbaus, wobei sie zusammen mit den Binärcodes zwischengespeichert werden. Der Speicher-Overhead ist gering (ein paar Floats pro Vektor), aber die Berechnung pro Abfrage entfällt und die Latenz bleibt auch bei hoher Parallelität stabil.

IVF_RABITQ: Der Index, den Sie tatsächlich einsetzen

Ab Milvus 2.6 liefern wir IVF_RABITQ - Inverted File Index + RaBitQ Quantisierung. Die Suche erfolgt in zwei Stufen:

1. Grobsuche (IVF). K-means partitioniert den Vektorraum in Cluster. Zur Abfragezeit werden nur die nprobe nächstgelegenen Cluster gescannt.
2. Feines Scoring (RaBitQ). Innerhalb jedes Clusters werden die Entfernungen mithilfe von 1-Bit-Codes und dem unbiased estimator geschätzt. Popcount erledigt die schwere Arbeit.

Die Ergebnisse auf einem 768-dimensionalen, 10 Millionen Vektoren umfassenden Datensatz:

Metrik	IVF_FLAT (Grundlinie)	IVF_RABITQ	IVF_RABITQ + SQ8 verfeinern
Wiedererkennung	95.2%	94.7%	~95%
QPS	236	864	-
Speicherplatzbedarf	32 Bits/Abbildung	1 Bit/Dim (~3% des Originals)	~25% des Originals

Für Workloads, die nicht einmal eine 0,5%ige Recall-Lücke tolerieren können, fügt der Parameter refine_type einen zweiten Scoring-Durchgang hinzu: SQ6, SQ8, FP16, BF16 oder FP32. SQ8 ist die übliche Wahl - sie stellt den Abruf auf IVF_FLAT-Niveau mit etwa 1/4 des ursprünglichen Speichers wieder her. Sie können die Skalarquantisierung auch unabhängig auf die Abfrageseite (SQ1-SQ8) anwenden, so dass Sie zwei Regler haben, um den Kompromiss zwischen Latenz und Abrufkosten pro Arbeitslast einzustellen.

Wie Milvus den Speicher über die Quantisierung hinaus optimiert

RaBitQ ist der wirkungsvollste Komprimierungshebel, aber er ist nur eine Ebene in einem breiteren Speicheroptimierungsstapel:

Strategie	Was es tut	Auswirkung
Vollständige Quantisierung	SQ8, PQ, RaBitQ mit unterschiedlichen Kompromissen zwischen Präzision und Kosten	4x bis 32x Speicherreduzierung
Optimierung der Indexstruktur	HNSW-Graphverdichtung, DiskANN-SSD-Offloading, OOM-sichere Indexerstellung	Weniger DRAM pro Index, größere Datensätze pro Knoten
Memory-mapped I/O (mmap)	Abbildung von Vektordateien auf der Festplatte, Laden von Seiten bei Bedarf über den OS-Seiten-Cache	TB-große Datensätze, ohne alles in den RAM zu laden
Tiered Storage	Trennung von heißen/warmen/kalten Daten mit automatischer Planung	Bezahlen Sie den Speicherpreis nur für Daten, auf die häufig zugegriffen wird
Cloud-native Skalierung(Zilliz Cloud, verwaltete Milvus)	Elastische Speicherzuweisung, automatische Freigabe von ungenutzten Ressourcen	Zahlen Sie nur für das, was Sie nutzen

Full-Stack-Quantisierung

Die extreme 1-Bit-Kompression von RaBitQ ist nicht für jede Arbeitslast geeignet. Milvus bietet eine vollständige Quantisierungsmatrix: SQ8 und Produktquantisierung (PQ) für Workloads, die einen ausgewogenen Kompromiss zwischen Präzision und Kosten erfordern, RaBitQ für maximale Komprimierung bei sehr großen Datensätzen und Hybridkonfigurationen, die mehrere Methoden für eine feinkörnige Steuerung kombinieren.

Optimierung der Indexstruktur

Neben der Quantisierung optimiert Milvus kontinuierlich den Speicher-Overhead in seinen Kern-Indexstrukturen. Für HNSW haben wir die Redundanz der Adjazenzlisten reduziert, um die Speichernutzung pro Graph zu verringern. DiskANN verlagert sowohl die Vektordaten als auch die Indexstrukturen auf die SSD, wodurch die DRAM-Abhängigkeit bei großen Datensätzen drastisch reduziert wird. Außerdem haben wir die Zuweisung von Zwischenspeicher während der Indexerstellung optimiert, um OOM-Fehler zu vermeiden, wenn Indizes über Datensätze erstellt werden, die sich den Speichergrenzen der Knoten nähern.

Intelligentes Laden von Speicher

Die mmap-Unterstützung (memory-mapped I/O) von Milvus ordnet Vektordaten den Festplattendateien zu und verlässt sich dabei auf den Seitencache des Betriebssystems für das bedarfsgesteuerte Laden - es müssen nicht alle Daten beim Start in den Speicher geladen werden. In Kombination mit Lazy-Loading- und segmentierten Ladestrategien, die plötzliche Speicherspitzen verhindern, ermöglicht dies einen reibungslosen Betrieb mit TB-großen Vektordatensätzen zu einem Bruchteil der Speicherkosten.

Mehrschichtige Speicherung

Die dreistufige Speicherarchitektur von Milvus umfasst Arbeitsspeicher, SSD und Objektspeicher: Warme Daten verbleiben im Arbeitsspeicher, um eine niedrige Latenzzeit zu erreichen, warme Daten werden auf SSD zwischengespeichert, um ein ausgewogenes Verhältnis zwischen Leistung und Kosten zu erreichen, und kalte Daten werden im Objektspeicher abgelegt, um den Overhead zu minimieren. Das System verwaltet die Datenplanung automatisch - Änderungen auf der Anwendungsebene sind nicht erforderlich.

Cloud-native Skalierung

Im Rahmen der verteilten Architektur von Milvus verhindern Data Sharding und Load Balancing eine Überlastung des Speichers auf einem einzelnen Knoten. Speicherpooling reduziert die Fragmentierung und verbessert die Auslastung. Zilliz Cloud (vollständig verwaltetes Milvus) geht noch einen Schritt weiter und bietet elastisches Scheduling für die bedarfsgerechte Skalierung des Speichers - im Serverless-Modus werden ungenutzte Ressourcen automatisch freigegeben, was die Gesamtbetriebskosten weiter reduziert.

Wie sich diese Ebenen zusammensetzen

Diese Optimierungen sind keine Alternativen - sie sind aufeinander aufbauend. RaBitQ verkleinert die Vektoren. DiskANN behält den Index auf der SSD. Mmap vermeidet das Laden kalter Daten in den Speicher. Tiered Storage verlagert archivierte Daten in den Objektspeicher. Das Ergebnis: Ein Einsatz, der Milliarden von Vektoren bedient, benötigt nicht Milliarden von Vektoren an RAM.

Beginnen Sie

Da die KI-Datenmengen weiter wachsen, werden die Effizienz und die Kosten von Vektordatenbanken direkt bestimmen, wie weit KI-Anwendungen skaliert werden können. Wir werden weiterhin in eine leistungsstarke und kostengünstige Vektorinfrastruktur investieren, damit mehr KI-Anwendungen vom Prototyp zur Produktion übergehen können.

Milvus ist quelloffen. Um IVF_RABITQ auszuprobieren:

• In der IVF_RABITQ-Dokumentation finden Sie Anleitungen zur Konfiguration und Einstellung.
• Lesen Sie den vollständigen Blogbeitrag zur RaBitQ-Integration, um mehr über Benchmarks und Implementierungsdetails zu erfahren.
• Treten Sie der Milvus-Slack-Community bei, um Fragen zu stellen und von anderen Entwicklern zu lernen.
• Buchen Sie eine kostenlose Milvus-Sprechstunde, um Ihren Anwendungsfall durchzugehen.

Wenn Sie die Einrichtung der Infrastruktur lieber überspringen möchten, bietet Zilliz Cloud (vollständig verwaltetes Milvus) ein kostenloses Tier mit IVF_RABITQ-Support.

Wir führen demnächst ein Interview mit Professor Cheng Long (NTU, VectorDB@NTU) und Dr. Jianyang Gao (ETH Zürich), dem Erstautor von RaBitQ, in dem wir die Theorie der Vektorquantisierung und die nächsten Schritte näher erläutern werden. Stellen Sie Ihre Fragen in den Kommentaren.

Häufig gestellte Fragen

Was sind TurboQuant und RaBitQ?

TurboQuant (Google, ICLR 2026) und RaBitQ (Gao & Long, SIGMOD 2024) sind beides Vektorquantisierungsmethoden, die zufällige Rotation zur Kompression hochdimensionaler Vektoren verwenden. TurboQuant zielt auf KV-Cache-Kompression in LLM-Inferenz, während RaBitQ auf persistente Vektorindizes in Datenbanken abzielt. Beide haben zur aktuellen Welle des Interesses an Vektorquantisierung beigetragen, obwohl sie unterschiedliche Probleme für unterschiedliche Systeme lösen.

Wie erreicht RaBitQ eine 1-Bit-Quantisierung, ohne die Wiedererkennung zu zerstören?

RaBitQ nutzt die Konzentration von Maßen in hochdimensionalen Räumen: Die Winkel zwischen Vektoren sind bei zunehmender Dimensionalität stabiler als einzelne Koordinatenwerte. Es normalisiert die Vektoren in Bezug auf den Schwerpunkt des Datensatzes und projiziert dann jeden Vektor auf den nächstgelegenen Scheitelpunkt eines Hyperwürfels (wobei jede Dimension auf ein einziges Bit reduziert wird). Ein unvoreingenommener Abstandsschätzer mit einer nachweisbaren Fehlergrenze sorgt dafür, dass die Suche trotz der Kompression genau bleibt.

Was ist IVF_RABITQ und wann sollte ich es verwenden?

IVF_RABITQ ist ein Vektorindex-Typ in Milvus (verfügbar seit Version 2.6), der invertiertes Datei-Clustering mit RaBitQ 1-Bit-Quantisierung kombiniert. Er erreicht 94,7 % Recall bei 3,6-fachem Durchsatz im Vergleich zu IVF_FLAT, bei einem Speicherverbrauch von etwa 1/32 der ursprünglichen Vektoren. Verwenden Sie diese Methode, wenn Sie eine umfangreiche Vektorsuche durchführen müssen (Millionen bis Milliarden von Vektoren) und die Speicherkosten ein Hauptanliegen sind - häufig bei RAG-, Empfehlungs- und multimodalen Suchvorgängen.

Wie hängt die Vektorquantisierung mit der KV-Cache-Kompression in LLMs zusammen?

Bei beiden Problemen geht es um die Komprimierung hochdimensionaler Gleitkomma-Vektoren. Der KV-Cache speichert Schlüssel-Wert-Paare aus dem Transformer-Attention-Mechanismus; bei großen Kontextlängen kann er die Modellgewichte in der Speichernutzung übersteigen. Vektorquantisierungsverfahren wie RaBitQ reduzieren diese Vektoren auf Darstellungen mit niedrigeren Bits. Die gleichen mathematischen Prinzipien - Messkonzentration, zufällige Rotation, unverzerrte Abstandsschätzung - gelten sowohl für die Komprimierung von Vektoren in einem Datenbankindex als auch im KV-Cache einer Inferenzmaschine.