turbovec: Komprimiere RAG-Embeddings 16x mit TurboQuant in Rust
TurboVec bringt Googles TurboQuant nach Rust und verkleinert RAG-Embedding-Indizes um das 16-Fache ohne Training. Wo es FAISS übertrifft und wann ein anderes Tool besser geeignet ist.
Quellen: turbovec for RAG: A Practical Guide to Faster, Smaller Vector Search
Nehmen wir einen tatsächlich eingesetzten Extraktionspipeline: zehn Millionen Dokumente, jedes mit OpenAI’s text-embedding-3-small in 1536 Dimensionen versehen und als float32 gespeichert. Schon vor dem Hinzufügen eines einzigen Bytes an Metadaten wiegen allein die Vektoren 31 GB. Bei dieser Größe ist die Frage „Wo wird das laufen?“ nicht mehr bloß eine beiläufige Frage – sie bedeutet einen memoryintensiven Cloud-Server, vermutlich bei jemand anderem gehostet, zusammen mit all den damit verbundenen Privatsphäre- und Betriebsproblemen.
Wenn man dieselben Daten über turbovec mit 2 Bit pro Dimension verarbeitet, reduziert sich die Größe auf etwa 4 GB, was problemlos in den RAM eines Laptops passt. Der Rest dieses Artikels erläutert, warum das funktioniert, in welchen Fällen turbovec die richtige Wahl ist und wo ein anderes Tool besser geeignet ist.
Was turbovec ist
turbovec ist ein Rust-Vector-Index mit Python-Bindings, unter der MIT-Lizenz stehend, der zum Zeitpunkt der Erstellung etwa 950 GitHub-Sterne hatte. Er implementiert TurboQuant, einen Vector-Quantisierungsalgorithmus von Forschern bei Google Research und NYU, der bei ICLR 2026 angenommen wurde.
Ein Detail, das man wissen sollte: Google hat niemals Quellcode für seinen eigenen Algorithmus veröffentlicht, weshalb die Community eingriff. Das Projekt RyanCodrai/turbovec konzentriert sich auf die Vektorsuche, also den Einsatzfall der Datenabrufung, während ein separates Projekt, hackimov/turboquant-kv, dieselbe Idee zur Komprimierung des KV-Caches von Sprachmodellen verwendet. Beide sind unabhängige Open-Source-Bemühungen.
Anders ausgedrückt bedeutet die Verwendung von turbovec, dass man eine von der Community implementierte Version eines Algoritms von Google Research nutzt, und bei den von dem FAISS-Team selbst verwendeten Benchmarks übertrifft sie Metas FAISS, das lange Zeit der Standard für Vektorabfragen im Arbeitsspeicher war.
Wie der Algorithmus funktioniert
Sobald man ihn verstanden hat, erweist sich die Methode überraschend als übersichtlich. Sie erfolgt in vier Schritten.
1. Länge von Richtung trennen
Jeder Embedding hat eine Größe (seine L2-Norm) sowie eine Richtung. Die Größe wird herausgezogen und als einzelner Float pro Vektor gespeichert; was übrig bleibt, ist eine Richtung mit Länge eins auf einer hochdimensionalen Kugel. Das mag unbedeutend erscheinen, doch alles Weitere hängt davon ab, denn Vektoren auf der Oberfläche einer Kugel können mit geometrischen Methoden verarbeitet werden.
2. Zufällig drehen
Danach wird jeder Vektor mit derselben zufälligen orthogonalen Matrix multipliziert, die einmalig aus der QR-Zerlegung einer gaussischen Matrix erzeugt wird. Dieser Schritt wirkt beim ersten Lesen wie ein Zaubertrick.
Die Intuition: In hohen Dimensionen macht eine zufällige Rotation die Verteilung jeder Koordinate vorhersagbar. Nach der Rotation folgt jede Koordinate jedes Vektors einer bekannten, stark konzentrierten Beta-Verteilung, die mit zunehmender Dimensionalität einer Gauss’schen Verteilung zustrebt. Die Verteilung bleibt unabhängig von der Eingabe gleich. Rechtsdokumente, Produktbewertungen und medizinische Literatur erscheinen statistisch gesehen alle ähnlich, sodass das Verfahren nicht von den Daten abhängt. Mathematiker bezeichnen diese Konzentration der Maßverteilung auf der Kugel und erklären damit, warum kein Trainingsvorgang erforderlich ist: Die Rotation erledigt die Arbeit, die sonst ein trainierter Codebuch leisten würde.
3. Die besten Kategorien auswählen
Durch das Kennen der Verteilung, der jede Koordinate folgt, lässt sich im Voraus die beste Methode zur Einteilung der Werte ermitteln. Zwei-Bit-Quantisierung führt zu vier Einteilungen pro Koordinate, vier Bit zu sechzehn. Diese Berechnung wird als Lloyd-Max-Skalarquantisierung bezeichnet und beantwortet eine einfache Frage: Bei einer bekannten Verteilung – wo sollten die Trennlinien liegen, um den durchschnittlichen Rundungsfehler so gering wie möglich zu halten? Bei bekannter Verteilung lässt sich die Antwort in geschlossener Form berechnen. Da die Verteilung nach der Rotation für alle Vektoren identisch ist, stammen die Einteilungen aus der Mathematik und nicht aus den Daten.
4. Komprimieren der Bits
Jede Koordinate ist nun eine kleine Ganzzahl: 0 bis 3 bei 2 Bit oder 0 bis 15 bei 4 Bit. Bei kompakter Packung benötigt ein 1536-dimensionaler Vektor, der als float32 6.144 Bytes beansprucht, bei 2 Bit nur 384 Bytes oder bei 4 Bit 768 Bytes. Das entspricht einer Kompression um das 16-fache bzw. 8-fache.
Suchen ohne Entpacken
Die Abfragen dekomprimieren die gespeicherten Daten niemals. Die Abfrage wird einmal in denselben Speicherbereich verschoben und anschließend direkt mit den vorab erstellten Suchtabellen sowie den quantisierten Codes verglichen. Der innere Schleifenprozess nutzt SIMD-Befehle – NEON für ARM, AVX-512BW für moderne x86-Prozessoren sowie AVX2 als Ersatz.
Genau hier zeigt sich der Wert der Bibliothek im Gegensatz zum Algorithmus. Ihre handgeschriebenen SIMD-Kerne sind auf ARM um 12 bis 20 Prozent schneller als FAISSs FastScan und erreichen auf x86 denselben oder sogar besseren Geschwindigkeitswert.
Hinter dieser Methode steht auch ein theoretisches Ergebnis. Die TurboQuant-Publikation belegt, dass die Verzerrung innerhalb eines Faktors von etwa 2,7 gegenüber der informationstheoretischen Untergrenze, Shannons Grenze für die Verzerrungsrate, bleibt. Einfach ausgedrückt: Die Informationstheorie legt fest, wie stark Daten komprimiert werden können, bevor etwas verloren geht, und TurboQuant hält sich ohne jegliches Training innerhalb von 2,7-fach dieses Limits. Niemand kann bei einem gegebenen Bitbudget deutlich besser abschneiden, und die Publikation untermauert dies mit einem formalen Beweis.
Drei Fälle, in denen es sich lohnt
Passende Speichermenge
Zurück zu den anfangs genannten Zahlen: 31 GB im Format float32 im Vergleich zu 4 GB mit turbovec bei 2 Bit. Ein so kleiner Index verändert das Mögliche.
- Er kann neben der Anwendung auf derselben Server instanziiert werden, ohne eine separate Vektordatenbank-Instanz.
- Entwickler können ihn auf Laptops zum lokalen Testen nutzen.
- Günstigere Speicherklassen in Cloud-Instanzen werden praktikabel, was die Kosten deutlich senkt.
- Der gesamte Index bleibt im RAM, es kommt weder zu einer Speicherung auf der Festplatte noch zu einer Aufteilung auf verschiedene Knoten.
Für Sammlungen im Vektorbereich von 100.000 bis 100 Millionen, was den Großteil der Wissensbasen, Dokumentationsseiten, Support-Archive und Produktkataloge umfasst, stellt dies den Unterschied dar zwischen der Notwendigkeit, den Vektorindex gezielt zu gestalten, und der Behandlung als gewöhnliches Python-Objekt.
Privatsphäre und isolierte Setup-Strukturen
Die Abrufpipeline birgt ein durchaus ernstes Privatsphärenproblem. Zwei Angriffe veranschaulichen dies:
- BadRAG erreicht eine Erfolgsrate von 98,2 %, indem es nur 0,04 % eines Korpus mit sorgfältig erstellten feindlichen Dokumenten kontaminiert.
- Vec2Text kann kurze ursprüngliche Texte aus ihren Embeddings wiederherstellen und tut dies zu 92 % genau richtig.
Embeddings verfügen über keine kryptografische Schutzfunktion, sodass jeder, der Zugriff auf einen Vector-Store hat, das Eingebettete wiederherstellen kann. Jeder Aufruf einer Cloud-Vector-Datenbank, jede embed()-Anfrage an OpenAI sowie jede upsert()-Aktion bei Pinecone stellen einen Punkt dar, an dem Daten Ihr System verlassen.
Viele tatsächliche Implementierungen sind bereits vollständig von der Außenwelt abgeschirmt. An der UC San Diego bewältigt Onyx 37.000 Benutzer ohne Internetverbindung, und Ramp, Thales, L3Harris sowie Astranis betreiben ähnliche Systeme. Der Slogan von turbovec – „Kein Managed-Service und keine Daten verlassen Ihr Gerät oder Ihre VPC“ – passt perfekt zu dieser Gruppe. Kombinieren Sie ihn mit einem lokal gehosteten Embedding-Modell wie BGE-M3 oder BGE-large-en-v1.5, sodass bei der Datenabrufung keine externen Netzwerkaufrufe stattfinden.
Kein Codebuch zum Trainieren nötig
Dieser Vorteil ist strukturell bedingt und wird leicht unterschätzt. Die klassische Produktquantisierung, also PQ in IndexPQ und IndexIVFPQ, benötigt ein Codebuch, das anhand repräsentativer Daten trainiert wird. Wenn sich die Daten ändern – beispielsweise durch neue Produktkategorien, neue Sprachen oder neue Dokumenttypen – wird dieses Codebuch veraltet und die Wiedererkennungsfähigkeit leidet.
TurboQuant verfügt überhaupt kein Codebuch. Die zufällige Rotation sorgt dafür, dass die Mathematik unabhängig von der Eingabestruktur funktioniert. In der Praxis bedeutet das:
- Streaming-Einfüge funktionieren reibungslos, ohne dass ein batchbasiertes Neutraining erforderlich ist.
- Der Wechsel von Embedding-Modellen, von OpenAI zu BGE oder Voyage, erfordert kein vollständiges Neubauen des Indexes.
- Mehrfachnutzer-Indexe benötigen keine kalibrierung nach Nutzer.
- Das Problem des „Cold Starts“, bei dem zu wenige Vektoren vorhanden sind, um ein brauchbares Codebuch zu trainieren, verschwindet.
Für Systeme, die schrittweise wachsen oder verschiedene Dokumenttypen umfassen, ist diese Einfachheit ein echter Vorteil in der Betriebspraxis.
Wann etwas anderes verwendet werden sollte
Einige Suchmuster eignen sich besser für andere Ansätze, und es ist am besten, offen darüber zu sprechen.
- Suche mit hoher Trefferquote. HNSW mit Vektoren in voller Präzision bleibt der Goldstandard. turbovec gibt einige Trefferpunkte auf, um eine 16-fach höhere Kompression zu erzielen. Das ist für die meisten RAG-Anwendungen akzeptabel – doch problematisch, wenn ein verpasster Treffer teuer ist.
- Filtern von Metadaten und hybride Suche. turbovec ist lediglich ein Index ohne zugrundeliegende Datenbank. Anfragen wie „Finde Vektoren in der Nähe von X, beschränkt auf Dokumente mit dem Tag ‚Compliance‘, die nach Dezember 2025 bearbeitet wurden“ erfordern eine echte Vektor-Datenbank wie Qdrant, Weaviate, Milvus oder pgvector.
- Niedrigdimensionale Embeddings (256 Dimensionen oder weniger). Laut der eigenen README-Dokumentation liegt turbovec bei d=200 im Vergleich zu FAISS um 3 bis 6 Recall-Punkte hinter GloVe, da die Beta-zu-Gauß-Annäherung bei wenigen Dimensionen lockerer ist und der Vorteil der Theorie abnimmt. Wenn die Infrastruktur ältere oder kleinere Embedding-Modelle verwendet, ist FAISS die sicherere Wahl.
- Skalierung für Milliarden von Vektoren. turbovec durchsucht jeden komprimierten Vektor vollständig. Das funktioniert bis zu etwa 100 Mio. Vektoren gut. Darüber hinaus sind zusätzlich IVF oder graphbasierte Partitionierungsmethoden erforderlich, die turbovec nicht bietet.
- Präferenz für gehostete Dienste. Ein Team, das eine verwaltete Vektordatenbank mit API-Schlüssel benötigt, wird feststellen, dass turbovec das falsche Werkzeug ist – egal wie gut die Ingenieursleistung auch sein mag.
Erste Schritte
Für die Speicherbasierte Abfrage von 100.000 bis 100 Millionen Vektoren mit 384 oder mehr Dimensionen sowie für Teams, die ihre eigene Infrastruktur betreiben möchten, ist hier der praktische Weg. Installieren Sie es über PyPI:
pip install turbovec
Rust-Projekte fügen stattdessen das Crate hinzu:
cargo add turbovec
Die grundlegende Verwendung erfordert einige Zeilen, um einen Index zu erstellen und abzufragen:
from turbovec import TurboQuantIndex
# Build the index
index = TurboQuantIndex(dim=1536, bit_width=4)
index.add(document_embeddings)
# Search
scores, indices = index.search(query_embedding, k=10)
# Persist
index.write("kb.tq")
loaded = TurboQuantIndex.load("kb.tq")
Das ist die gesamte Oberfläche für den einfachen Fall.
Wahl der Bitbreite
Das ist die wichtigste Einstellung, und der Kompromiss ist klar.
- 2-Bit: 16-fache Kompression im Vergleich zu float32, größeres Defizit bei der Wiedererkennung sowie höhere Empfindlichkeit gegenüber der Dimension.
- 4-Bit: 8-fache Kompression, wobei die Wiedererkennung im Wesentlichen mit der von FAISS bei OpenAI’s 1536- und 3072-dimensionalen Embeddings übereinstimmt. Beide erreichen einen Wert von 1,0 bei k zwischen 4 und 8.
Die sinnvolle Standardwert ist 4-Bit. Wechseln Sie nur auf 2-Bit, nachdem Sie den tatsächlichen Speicherbedarf sowie die Auswirkungen auf die Wiedererkennung bei Ihren eigenen Abfragen gemessen haben.
Wahl des Index-Typs
Es gibt zwei Arten. TurboQuantIndex adressiert Vektoren anhand ihrer Position, was die Sache einfach hält und etwas schneller macht, wenn die IDs einfach der Einfügereihenfolge folgen. IdMapIndex ermöglicht es Ihnen, eigene uint64-IDs zu verwenden, und löscht Einträge in konstanter Zeit – daher ist er die richtige Wahl, wenn die Schlüssel aus einer Datenbank stammen oder Dokumente gelöscht werden.
Für die meisten RAG-Systeme ist IdMapIndex die bessere Standardwahl, da die IDs der Anwendungsdatenbank bei Löschungen und Neuerrichtungen erhalten bleiben, ohne dass externe Verweise beeinträchtigt werden.
from turbovec import IdMapIndex
import numpy as np
index = IdMapIndex(dim=1536, bit_width=4)
index.add_with_ids(vectors, np.array([1001, 1002, 1003], dtype=np.uint64))
scores, ids = index.search(query, k=10) # returns your IDs
index.remove(1002) # O(1) by ID
Einbetten von Modellen
Bei einer abgeschotteten Datenabfrage muss das Einbettungsmodell lokal ausgeführt werden, da der Aufruf der OpenAI-API den Datenschutzvorteil zunichtemacht. Zwei Kombinationen wurden gründlich getestet:
- BGE-M3 mit turbovec. Ein leistungsstarkes mehrsprachiges Modell, das lokal läuft und eine gute Standardwahl für internationale Wissensbasen darstellt.
- BGE-large-en-v1.5 mit turbovec. Nur auf Englisch, kleiner und schneller, sowie eine gute Standardwahl für englischsprachige Dokumentationen.
Wo Datenschutz kein strenger Anforderung ist, funktionieren OpenAIs text-embedding-3-small (1536 Dimensionen) oder text-embedding-3-large (3072) gut mit turbovec. Denken Sie daran, dass Datenlecks durch den Cloud-Einbettungsaufruf und nicht durch den Index entstehen.
Integrationen in Frameworks
turbovec bietet erstklassige Integrationen für LangChain, LlamaIndex und Haystack:
pip install turbovec[langchain]
pip install turbovec[llama-index]
pip install turbovec[haystack]
Ein bereits auf einem dieser Systeme aufgebauter Stack sollte diesen Weg wählen, da er den geringsten Widerstand aufweist.
Einzuhaltende Grenzen
- Einzelne Maschine, im Arbeitsspeicher. Es gibt keinen verteilten Modus, sodass horizontales Skalieren bedeutet, dass die Daten in der Anwendungs層 aufgeteilt werden müssen.
- Ausführliche Prüfung. Jeder komprimierte Vektor wird bei jeder Abfrage überprüft. SIMD hält diese Geschwindigkeit bei etwa 100 Mio. Vektoren aufrecht, danach ist ein IVF- oder Graphenlayer erforderlich.
- Hardwareabhängigkeit. Der Vorteil von 12 bis 20 Prozent bei ARM wurde an Apple M-Serie-Chips gemessen. Ältere ARM- oder x86-Chips ohne AVX-512 weisen kleinere Vorteile auf, schneiden aber in den meisten Konfigurationen dennoch besser ab als FAISS.
- Rückrufrate bei niedrigen Dimensionen. Unter etwa 256 Dimensionen gewinnt FAISS mit einem deutlichen Vorsprung. Die Methode ist bei den 768 oder mehr Dimensionen am effektivsten, die aktuelle Embedding-Modelle liefern.
Das größere Muster
turbovec füllt eine spezifische Nische aus: In-Memory-Vektorabfragen, mittelgroße Korpora, eigene Infrastruktur sowie die Dimensionen, die moderne Embedding-Modelle liefern. Es versucht nicht, Qdrant oder Pinecone zu ersetzen. Es handelt sich um einen niedrigeren Baustein für den Bereich, in den sonst FAISS kommen würde – mit besserer Kompression und ohne Trainingsphase.
Die Hintergrundgeschichte ist wohl der interessantere Teil. Ein von vier Autoren verfasstes Google Research-Paper wurde bei ICLR 2026 angenommen; die Autoren veröffentlichten keinen Code, und zwei Entwickler aus der Community entwickelten unabhängig voneinander Implementierungen – eine für die Kompression von KV-Caches und eine für Vektorabfragen. Die Vektorabfragen-Implementierung übertrifft den etablierten Produktanbieter sogar bei dessen eigenen Benchmarks.
Der Weg vom akademischen Algorithmus über die Implementierung in der Community bis hin zu einer für die Produktion geeigneten Bibliothek, die die Standardwerkzeuge übertrifft, wird sich wiederholen, denn die Forschungsergebnisse entstehen schneller, als die Anbieter sie in Produkte umsetzen können. turbovec ist ein konkretes Beispiel. Zu verstehen, wie es funktioniert und wo es einzuordnen ist, ist für alle nützlich, die heute Suchsysteme entwerfen.