turbovec: ein Rust-Vektorindex auf TurboQuant-Basis

Die Speicherbehauptung am Anfang der README

Die README beginnt mit einem konkreten Vergleich: Ein Korpus mit 10 Millionen Dokumenten benötigt als float32 31 GB RAM, turbovec bringt ihn auf 4 GB und sucht schneller als FAISS. Das ist eine Behauptung des Projekts, die sich allein aus dem Repository nicht unabhängig verifizieren lässt. Die Metadaten des Repositorys zeigen, dass turbovec ein in Rust geschriebener Vektorindex mit Python-Bindings ist, und die README sagt, dass er Google Researchs TurboQuant implementiert, einen datenunabhängigen Quantisierer ohne separate Trainingsphase. Das Repository listet 14.629 Sterne, 1.303 Forks und 63 offene Issues. Diese Zahlen beschreiben Repository-Aktivität, nicht Korrektheit.

Python- und Rust-Einstieg

Beide Schnittstellen sind in der README mit lauffähigen Beispielen dokumentiert. In Python folgt auf `pip install turbovec` die Nutzung von `TurboQuantIndex(dim=1536, bit_width=4)`; `add` akzeptiert nur zweidimensionale float32-Arrays und lehnt andere dtypes ab, daher sollte man mit `np.asarray(x, dtype=np.float32)` konvertieren. `search(query, k)` liefert Scores und Indizes. `IdMapIndex` bietet stabile externe IDs, unterstützt `add_with_ids`, und `remove(id)` wird als O(1) beschrieben. Die Persistierung erfolgt in einer `.tvim`-Datei. In Rust nutzt man `cargo add turbovec` und `TurboQuantIndex::new(1536, 4)`; der Ablauf mit add, search, write und load ist derselbe. Für die vollständige API verweist die README auf `docs/api.md`, listet aber nicht die gesamte Oberfläche selbst auf.

Inkrementelles Speichern und gefilterte Suche

Das Persistenzmodell hat zwei Ebenen. `sync(path)` schreibt nur die Änderungen seit der letzten Synchronisierung, mit einem fsync pro Aufruf, und die README sagt, dass es an jedem Byte absturzsicher ist; Löschungen und kleine Ergänzungen dauern auch bei großen Indizes Millisekunden. `write` und `load` sind für Ganzdatei-Snapshots. Die Suche kann über eine Zulassungsliste externer IDs oder eine Slot-Bitmaske eingeschränkt werden. Der SIMD-Kernel arbeitet in Blöcken von 32 Vektoren; Blöcke ohne zulässige Slots werden vor dem Scoring übersprungen, und nicht zulässige Slots innerhalb bewerteter Blöcke werden beim Heap-Insert verworfen. Die Ergebnislänge ist `min(k, n_allowed)`, wobei `n_allowed` die Anzahl der eindeutigen zulässigen Vektoren ist. Die README listet auch Ersatz für In-Memory-Stores in LangChain, LlamaIndex, Haystack und Agno, installiert über Extras wie `pip install turbovec[langchain]`.

Die Quantisierungspipeline

Die README erklärt den Algorithmus in sechs Schritten. Vektoren werden auf Einheitsrichtungen normiert. Eine gemeinsame Zufallsrotation bewirkt, dass jede Koordinate einer Beta-Verteilung folgt, die in hohen Dimensionen gegen eine Gauß-Verteilung konvergiert. Optionale TQ+-Kalibrierung passt pro Koordinate eine Verschiebung und eine Skalierung an; die README sagt, dass eine Stichprobe von etwa 1024 Zeilen reicht. `calibrate(sample)` übernimmt die Kalibrierung, und spätere add-Aufrufe verwenden sie erneut. Das Lloyd-Max-Codebuch wird aus der Verteilung abgeleitet, nicht aus Daten, und erzeugt 4 Buckets bei 2 Bit und 16 bei 4 Bit. Die Koordinaten werden bitgepackt: Ein 1536-dimensionaler Vektor schrumpft bei 2 Bit von 6144 auf 384 Byte. Längen-renormalisiertes Scoring speichert einen Skalar pro Vektor, um die Abwärtsverzerrung des inneren Produkts zu korrigieren. Bei der Suche wird die Anfrage einmal rotiert und direkt gegen Codebuchwerte bewertet, mit NEON auf ARM und AVX-512BW auf x86, mit Fallback auf AVX2 und Skalar.

Was die Benchmark-Zahlen aussagen

Die README berichtet Vergleiche mit FAISS in mehreren Szenarien. Bei der Suchgeschwindigkeit auf ARM (GCP c4a-standard-8, Google Axion) ist TurboQuant in jeder Konfiguration 19-31% schneller als FAISS FastScan. Auf x86, einem Intel Xeon Platinum 8481C, gewinnt es die 4-Bit-Konfigurationen mit bis zu etwa 5% und liegt bei 2 Bit zurück, am deutlichsten bei d=1536 Single-Thread mit etwa 8%. Beim Recall wird FAISS IndexPQ als Baseline verwendet; bei OpenAI d=1536 und d=3072 liegt TurboQuant bei R@1 um 0,4-3,1 Punkte vorn, und beide erreichen bei k=8 den Wert 1,0. Bei GloVe d=200 beträgt der Vorsprung 1,4 Punkte bei 4 Bit und 0,5 bei 2 Bit. Einfüge-, Entfernungs- und Speicher/Lade-Benchmarks sind ebenfalls dokumentiert, mit verlinkten JSON-Ergebnissen. Diese Zahlen stammen vom Projekt und wurden hier nicht unabhängig verifiziert.

Build, Benchmarks und Lizenz

Python-Builds nutzen maturin; Rust-Builds nutzen `cargo build --release`. Alle x86_64-Builds zielen auf `x86-64-v2` als Basis, wobei AVX-512- und AVX2-Kernel per `#[target_feature]` aktiviert und zur Laufzeit ausgewählt werden; CPUs ohne diese Funktionen erhalten einen Skalar-Fallback. Benchmark-Skripte liegen in `benchmarks/suite/`, Ergebnisse als JSON in `benchmarks/results/`, und Diagramme lassen sich mit `benchmarks/create_diagrams.py` neu erzeugen. Die MIT-Lizenz erlaubt Nutzung, Kopie, Modifikation, Merge, Veröffentlichung, Verbreitung, Unterlizenzierung und Verkauf und stellt die Software 'wie besehen' ohne Gewährleistung bereit. Der Lizenztext sagt nichts über Sicherheitslage, Support oder Produktionsreife aus.

Redaktionelles Fazit

Die README liefert eine konkrete Algorithmus-Erklärung, reproduzierbare Benchmark-Skripte und klare API-Beispiele; die Leistungszahlen sind jedoch die eigenen Angaben des Projekts.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository