Vektorsuche: HotKV vs. Redis 8 Vector Sets, von 1 bis 100 Clients

Die Vektorsuche steckt hinter vielen KI-Funktionen: Retrieval für RAG, semantisches Caching, Agentenspeicher. Redis 8 liefert Vector Sets, einen Datentyp im Beta-Stadium, direkt im Server mit, daher ist es der naheliegende Vergleich. Wir haben dieselben OpenAI-Embeddings in HotKV und in Redis 8.10.2 geladen, gegen beide dieselben 1.000 Abfragen mit 1 bis 100 gleichzeitigen Client-Verbindungen ausgeführt und gemessen, wie genau die Antworten waren, wie viele Abfragen pro Sekunde jede Engine bediente und wie lange jede Abfrage dauerte.

Kurz gesagt. Bei 999.000 Vektoren und einem Recall von mindestens 95 % bediente HotKV mit einem Client das 1,4-Fache der Abfragen pro Sekunde von Redis und mit 100 Clients das 7,9-Fache (51.146 gegenüber 6.510). Bei 99 % Recall betrugen die Verhältnisse 1,8 und 5,4. Die mediane Latenz von HotKV war bei jeder Client-Anzahl niedriger. Der Durchsatz von Redis hatte sich bei 32 Clients bereits abgeflacht, während der von HotKV bis 100 weiter wuchs. HotKV lud die Vektoren etwa 5-mal schneller, und sein Recall war bei jeder Suchtiefe höher. Das ist ein Datensatz auf einer Maschine, der HotKV-Build ist ein unveröffentlichter Entwicklungs-Build, und wir haben weder die Query Engine von Redis noch dessen 8-Bit-Modus gemessen. Lesen Sie es daher als Messung, nicht als Rangliste.

Was wir getestet haben

Daten

Die ersten 999.000 Zeilen von dbpedia-entities-openai-1M von Kumar Shivendu und Nirant Kasliwal (MIT-Lizenz) und, für einen kleineren Index, die ersten 100.000 Zeilen. Die Zeilen sind DBpedia-Entitäten, eingebettet mit OpenAI text-embedding-ada-002, 1.536 Dimensionen. Die letzten 1.000 Zeilen sind die Abfragen, sodass keine Zeile in beiden Mengen vorkommt. Der Lösungsschlüssel besteht aus den exakten 10 nächsten Nachbarn jeder Abfrage, per Brute Force in 64-Bit-Gleitkommazahlen unabhängig von beiden Engines berechnet, sodass beide an derselben Ground Truth gemessen werden.

Engines und Einstellungen

• Engines. HotKV-Commit c8dafd37 (VSIM.CREATEINDEX, VSIM.SET, VSIM.SEARCH), ein unveröffentlichter Entwicklungs-Build, kompiliert mit den Standard-Release-Flags, nicht mit -march=native. Redis 8.10.2, aus seinem Release-Tag mit einem unveränderten make gebaut (VADD, VSIM). Beide bauen HNSW-Graphen.
• Index-Einstellungen. Kosinus-Ähnlichkeit, HNSW mit M=16 und ef_construction=200 bei beiden, ausdrücklich gesetzt. Es sind zugleich die Standardwerte jeder Engine.
• Genauigkeit. Vektoren in voller Genauigkeit (float32) bei beiden. Redis verwendet standardmäßig 8-Bit-Quantisierung, daher lief es mit NOQUANT.
• Maschine. Eine Azure Standard_D160alds_v7 (AMD EPYC 9V45, 160 vCPUs). Beide Server waren an dieselben 128 vCPUs gebunden, die Lastgeneratoren an die übrigen 32, alles über Loopback. HotKV lief mit 128 Threads und Redis mit seinen standardmäßigen I/O-Threads. Wir haben 1, 4, 8 und 16 ausprobiert, und die Einstellung machte keinen konsistenten Unterschied.
• Lastgenerator. Ein Prozess pro Client-Verbindung, jeder mit einer offenen Anfrage, wobei die Anfragen vor dem zeitgemessenen Teil aufgebaut wurden. Der am stärksten ausgelastete Lastgenerator-Prozess nutzte in jedem Lauf höchstens 8 % einer CPU, der Client hat die Grenze also nie bestimmt.

Vorgehen

Bei Suchtiefen (ef) von 40, 80, 150 und 300 sowie, beim größeren Index, 500 haben wir die 1.000 Abfragen wiederholt mit 1, 2, 4, 8, 16, 32, 50 und 100 Clients ausgeführt: eine Sekunde Aufwärmphase, dann vier Sekunden gezählt, jeweils dreimal, wobei die Reihenfolge der beiden Engines abwechselte. Wir geben den Median an. Der Recall wurde separat über eine Verbindung gemessen. HotKV wurde in jedem Lauf über 32 Verbindungen geladen. Die Redis-Indizes wurden einmal über 32 Verbindungen mit VADD ... CAS aufgebaut, gespeichert und für die Messungen geladen. Die Skripte und jeder einzelne Lauf stehen im Benchmark-Repository.

Ergebnisse

Vergleich bei gleichem Recall-Ziel

Die beiden Engines erreichen bei gleichem ef nicht denselben Recall, daher vergleichen wir den Durchsatz bei gemeinsamen Mindest-Recall-Zielen: Für jedes Ziel wird die schnellste gemessene Suchtiefe herangezogen, die es erreicht. Die Suchtiefen und die erreichten Recall-Werte stehen in den Tabellen, weil sie sich leicht unterscheiden. Dabei werden gemessene Suchtiefen verwendet, keine Interpolation. Abfragen pro Sekunde bei 999.000 Vektoren:

Die mediane Latenz ist als HotKV / Redis angegeben. Dasselbe Muster galt für ein Ziel von 90 %: 90.003 gegenüber 7.973 Abfragen pro Sekunde bei 100 Clients (das 11,3-Fache), beide bei ef 40.

Jede Suchtiefe

Abfragen pro Sekunde bei 999.000 Vektoren. Bei 100.000 Vektoren ist das Muster dasselbe. Bei 95 % Recall bediente HotKV mit einem Client das 1,5-Fache der Abfragen pro Sekunde von Redis (1.816 gegenüber 1.214) und mit 100 das 8,9-Fache (63.247 gegenüber 7.119).

Wie viel davon Rauschen ist

Jede Zelle ist der Median aus drei Läufen. Bei der Hälfte der Zellen betrug die Streuung zwischen niedrigstem und höchstem Lauf höchstens 1,3 % des Medians, bei neun von zehn höchstens 7 %, und die größte lag bei 26 % (Redis, 100.000 Vektoren, ef 300, 50 Clients). Der Bericht führt jeden Lauf auf.

Der Recall wurde einmal pro Indexaufbau gemessen. Drei unabhängige Indexaufbauten jeder Engine mit 100.000 Vektoren unterschieden sich bei gleicher Suchtiefe um bis zu 0,013, daher ist der höhere Recall von HotKV bis ef 300 eindeutig und liegt bei ef 500 auf dem kleineren Index innerhalb der Streuung von Aufbau zu Aufbau.

Laden und Speicher

Beim Laden über jeweils 32 Verbindungen brauchte HotKV für die 999.000 Vektoren 188 Sekunden (5.325 pro Sekunde) und Redis 935 Sekunden (1.069 pro Sekunde), einschließlich der Zeit, die der Lastgenerator mit dem Formatieren jedes Vektors verbrachte. Bei 100.000 Vektoren waren es 15 Sekunden gegenüber 57. Redis lud in einer Prüfung mit 20.000 Vektoren mit CAS schneller als ohne (2.279 gegenüber 1.488 Vektoren pro Sekunde), deshalb haben wir es verwendet. Der Redis-Ladevorgang lief in einem früheren Schritt mit Redis auf vier vCPUs festgelegt, während andere Prüfungen auf der Maschine liefen; HotKV lud allein auf 128 vCPUs. Die Redis-Ladezeit ist daher eine Untergrenze seiner Geschwindigkeit und kein direkter Vergleich.

Nach dem Laden von 999.000 Vektoren belegte der HotKV-Prozess 6,77 GB und der Redis-Prozess 7,01 GB.

Was Redis 8.10.2 hier begrenzt

Redis Vector Sets führen jede Suche auf einem eigenen Thread aus, aber der HNSW-Code hat eine feste Anzahl von Thread-Slots (32, beim Kompilieren von Redis festgelegt), und Vektoren werden auf dem Haupt-Thread hinzugefügt. In unseren Läufen hielt Redis ab 32 Clients zwischen 6 und 30 der vCPUs der Maschine ausgelastet, und sein Durchsatz hatte sich abgeflacht. HotKV hielt bei 100 Clients mit ef 80 etwa 92 vCPUs ausgelastet, und sein Durchsatz wuchs weiter. So verhält sich jede Engine auf dieser Maschine; es war nicht durch den Benchmark konfiguriert.

Einschränkungen

Dies sind Messungen von HotKV Ltd für die oben genannten Versionen und die Konfiguration, keine Aussage über jede Redis-Bereitstellung.

Der Testaufbau

• Ein Entwicklungs-Build. Commit c8dafd37 ist ein Entwicklungs-Build, kein Release.
• Ein Datensatz, eine Maschine. OpenAI-Embeddings mit 1.536 Dimensionen, nur die Top 10, float32, Kosinus. Andere Dimensionen, Daten oder Hardware können andere Verhältnisse ergeben.
• Der Client teilt sich die Maschine. Die Lastgeneratoren liefen auf getrennten vCPUs, teilten sich aber das Speichersystem und den Last-Level-Cache mit den Servern.
• Persistenz aus. Keiner der beiden Server schrieb Snapshots oder eine Append-only-Datei.

Was nicht gemessen wurde

• Der 8-Bit-Modus von Redis. Redis speichert standardmäßig 8-Bit-quantisierte Vektoren, was weniger Speicher belegt. Wir haben float32 mit float32 verglichen.
• Die Redis Query Engine. Redis bietet Vektorsuche auch über FT.CREATE und FT.SEARCH an. Wir haben nur Vector Sets getestet, daher sagen die Ergebnisse nichts über die Query Engine aus.
• Redis-Laden und Neuladen. Die Redis-Indizes wurden in einem früheren Lauf mit Redis auf vier vCPUs festgelegt aufgebaut, gespeichert und für die Messungen neu geladen. Die Redis-Ladezeiten sind daher eine Untergrenze und nicht direkt mit HotKV vergleichbar. Die Suche auf einem neu geladenen Index war in einer Prüfung mit 20.000 Vektoren etwa 10 Prozent langsamer als auf einem frisch aufgebauten, sodass die Redis-Abfragewerte um etwa so viel zu niedrig sein können.

Probieren Sie es selbst aus

Die Vektorsuche ist im selben Server integriert wie der Prompt-Cache von HotKV, und derselbe Vektorindex bildet die Grundlage für den semantischen Cache und den Agentenspeicher. Die Vektorsuche ist in jedem HotKV-Cloud-Tarif enthalten. Prompt-Cache, semantischer Cache und Agentenspeicher gibt es ab dem Performance-Tarif. Starten Sie auf HotKV Cloud oder sprechen Sie mit dem Vertrieb, um sie anhand Ihrer eigenen Embeddings zu benchmarken.