Qdrant testet, wie stark sich EmbeddingGemma-2-Vektoren schrumpfen lassen

Das Speicherproblem hinter dem Modell

Laut Qdrant ist Googles EmbeddingGemma 2 klein genug, um auf einem Smartphone zu laufen, die erzeugten Vektoren brauchen aber deutlich mehr Platz. Bei 10 Millionen Dokumenten belegen allein die Float32-Vektoren in voller Größe 30,7 GB RAM.

Qdrant testete zwei Wege, diese Kosten zu senken: kürzere Vektoren und weniger Bits pro Dimension. Die Ergebnisse verglich das Unternehmen auf fünf Textretrieval-Datensätzen mit der exakten Suche über Float32-Vektoren in voller Größe. Die Qualität wird als Prozentanteil des nDCG@10 der Referenz angegeben, einer Kennzahl dafür, wie gut die Top 10 Ergebnisse relevante Dokumente ranken.

Qdrant weist darauf hin, dass die Angaben zum Vektor-RAM weder Graph-Indizes noch Payloads noch die für das Rescoring gespeicherten Originalvektoren enthalten. Die Ergebnisse gelten nur für Textretrieval, und das Rescoring nutzt 4-faches Oversampling.

Zu EmbeddingGemma 2

EmbeddingGemma 2 ist ein offenes Embedding-Modell auf Basis von Gemma 4. Es bildet Text, Code, Bilder, Video und Audio in einem einzigen 768-dimensionalen Raum ab. Der reine Textpfad hat 270 Mio. Parameter. Google nennt gegenüber dem ersten EmbeddingGemma ein Plus von 14 % beim Code-Retrieval sowie ein Kontextfenster von 8K Token.

Das Modell unterstützt Matryoshka Representation Learning. Damit lassen sich die ersten 512, 256 oder 128 Dimensionen behalten, ohne die Daten neu einbetten zu müssen. Diese vorderen Dimensionen bleiben für sich genommen nutzbar. Die Quantisierung ist der zweite Hebel: Sie speichert jede Dimension in weniger Bits.

Erst volle Größe, dann 1 Bit

Qdrant empfiehlt als Ausgangspunkt, alle 768 Dimensionen zu behalten, 1-Bit-TurboQuant zu verwenden und das Rescoring auszulassen. Jeder Vektor belegt dann 104 statt 3.072 Bytes, womit die Vektoren für 10 Millionen Dokumente auf rund 1 GB RAM kommen. Ohne Rescoring entfällt zudem das Lesen der Originalvektoren während der Suche.

Bei den 523.000 Dokumenten von Quora brauchte dieses Setup weniger als die Hälfte der Abfragezeit der Float32-Suche und behielt 99,0 % von deren Suchqualität. Qdrant warnt, dass hohe Relevanz nicht identische Ergebnisse bedeutet: Ohne Rescoring stimmten etwa 74 % der Top 10 Ergebnisse mit der exakten Suche überein. Teams, die genau dieselben Nachbarn zurückbekommen wollen, können es mit Rescoring versuchen.

Außerdem verglich Qdrant das Kürzen von Dimensionen mit dem Kürzen von Bits. Bei 72 Bytes pro Vektor behielten 512 Dimensionen mit 1 Bit 97,3 % der Referenz. Bei ähnlichem Speicherbudget kam ein Setup mit 128 Dimensionen und 4 Bit auf 84,0 %. Der Rat lautet daher, zuerst mehr Dimensionen zu behalten und jede einzelne stärker zu komprimieren.

Bis zu 77-mal weniger Vektor-RAM

Wer jedes Byte zählt, dem empfiehlt Qdrant 256 Dimensionen mit 1-Bit-TurboQuant bei 40 Bytes pro Vektor im RAM. Mit Rescoring behielt dieses Setup 94,5 % der Referenz und erreichte 77-mal weniger Vektor-RAM. Ohne Rescoring sank der Wert auf 88,1 %.

Qdrant betont, dass Relevanzverlust und Rescoring-Zeit am Bedarf der jeweiligen Anwendung gemessen werden sollten. Zudem erlauben die Vektordatentypen, Originale als Float16 oder turbo4 zu speichern, um Festplattenplatz zu sparen. Diese Optionen hat das Unternehmen bislang aber nicht getestet.

Was das für Anwender bedeutet

Qdrant empfiehlt, mit der schlichten Konfiguration zu beginnen: Vektoren in voller Größe, 1-Bit-TurboQuant, Rescoring aus. Anwender sollten Relevanz und Latenz mit einer unquantisierten Collection anhand eigener Abfragen vergleichen, bei Bedarf Rescoring für eine bessere Nachbarwiedererkennung hinzufügen und die Vektoren nur dann kürzen, wenn sie weiter Speicher sparen müssen. Die Zahlen stammen aus Qdrants eigenen Tests auf fünf Textretrieval-Datensätzen, bei anderen Daten können die Ergebnisse abweichen.