TurboQuant läuft in vLLM und Qdrant – aber in beiden nur abgewandelt

vLLM und Qdrant setzen TurboQuant nur in abgewandelter Form ein

TurboQuant, ein Kompressionsverfahren von Google, läuft produktiv in zwei Systemen: in vLLM für den KV-Cache und in Qdrant für die Vektorsuche. Beide Projekte übernehmen das Verfahren nicht so, wie es im Paper beschrieben ist.

vLLM kombiniert eine Hadamard-Rotation mit einer Lloyd-Max-Skalarquantisierung pro Koordinate für die Keys. Die Values werden gleichmäßig quantisiert. Gewählt wird die Variante über den Parameter `--kv-cache-dtype`. Qdrant hat TurboQuant am 11. Mai 2026 mit Version 1.18 eingeführt. Nach Angaben von Qdrant erreicht die Methode bei doppelter Kompressionsrate wie die Skalarquantisierung einen ähnlichen Recall und eine ähnliche Geschwindigkeit. Ein Artikel auf Towards AI ordnet die Implementierung als MSE-Variante samt Erweiterungen ein, die nicht im Paper stehen.

Mit Version 1.19 kam am 5. August 2026 ein Datentyp hinzu. Er komprimiert Vektoren auf vier Bit und verzichtet darauf, die Originalrepräsentation zu behalten. Qdrant gibt an, dass er bis zu neunmal weniger Speicher benötigt als die TurboQuant-Quantisierung.

Der Towards-AI-Artikel nennt weitere Zahlen. Demnach läge der 4-Bit-Recall bei den meisten von zehn Datensätzen etwa zwei Punkte unter dem der Skalarquantisierung. Der 2-Bit-Recall läge 9 bis 24 Punkte über dem der Binary Quantization. Nachprüfen lässt sich das nicht. Der Blog-Auszug von Qdrant belegt diese Werte nicht. Der Artikel selbst weist aus, größtenteils von Claude geschrieben worden zu sein.

vLLM lässt QJL weg und beziffert den Preis der 3-Bit-Presets

Die vLLM-Dokumentation verzichtet bewusst auf die QJL-Stufe. QJL ist im Paper eine Residualkorrektur. Laut Doku verschlechtert sie die Attention-Qualität, weil sie die Varianz über die Softmax verstärkt. Als Beleg verweist die Doku auf einen „Community-Konsens“ aus mehr als fünf unabhängigen Gruppen. Welche Gruppen das sind, nennt sie nicht.

Vier Presets führt die Doku auf, jeweils mit Kompression und Perplexity-Aufschlag. `turboquant_k8v4` (FP8-Keys, 4-Bit-Values) erreicht die 2,6-fache Kompression bei +1,17 Prozent. `turboquant_4bit_nc` kommt auf das 3,8-Fache bei +2,71 Prozent. `turboquant_k3v4_nc` schafft etwa das 3,5-Fache, kostet aber +10,63 Prozent. `turboquant_3bit_nc` erreicht das 4,9-Fache bei +20,59 Prozent. Die Funktion ist Opt-in. Betreiber sollten die Qualität an ihrem eigenen Modell prüfen, bevor sie eine 3-Bit-Variante einsetzen.

Dem steht eine Community-Implementierung für llama.cpp gegenüber. Dort sank die Perplexity nach der Einführung von QJL. Die Beteiligten sehen in der Kombination aus WHT, QJL und MSE die Lösung. Ein direkter Vergleich mit und ohne QJL liegt nicht vor. Warum sich die beiden Befunde widersprechen, ist offen. Denkbar sind Unterschiede bei der Implementierung, beim Modell oder bei der Messgröße.

Streit um die Neuheit: Rotation plus Skalarquantisierung gilt als älterer Kern

Die vLLM-Doku nennt DRIVE, EDEN, HIGGS und Shutova et al. als Vorarbeiten. Alle erschienen vor dem TurboQuant-Paper. Die vLLM-Variante entspreche mathematisch dem Skalarfall von HIGGS. Eine unabhängige Reproduktion findet denselben Kern aus Zufallsrotation und Skalarquantisierung auch bei RaBitQ. Laut Towards-AI-Artikel bestreiten die Autoren von RaBitQ und EDEN die Zuordnung und den Geschwindigkeitsvergleich. Das stammt jedoch aus zweiter Hand, aus einem überwiegend von einer KI geschriebenen Text.

Das Paper, die Release Notes und die Red-Hat-Studie zu TurboQuant lagen nicht im Wortlaut vor. Die Einordnung stützt sich daher auf Dokumentation, Blogs und Drittrepositories.