Recherche vectorielle : HotKV face aux vector sets de Redis 8, de 1 à 100 clients

La recherche vectorielle est à la base de nombreuses fonctionnalités d’IA : la récupération pour le RAG, le cache sémantique, la mémoire d’agent. Redis 8 intègre des vector sets, un type de données en bêta, directement dans le serveur ; c’est donc la comparaison évidente. Nous avons chargé les mêmes embeddings OpenAI dans HotKV et dans Redis 8.10.2, exécuté les mêmes 1 000 requêtes sur chacun avec 1 à 100 connexions client simultanées, et mesuré la justesse des réponses, le nombre de requêtes par seconde servies par chaque moteur et la durée de chaque requête.

En bref. Sur 999 000 vecteurs, avec un rappel minimal de 95 %, HotKV a servi 1,4 fois le nombre de requêtes par seconde de Redis avec un client et 7,9 fois avec 100 clients (51 146 contre 6 510). À 99 % de rappel, les rapports étaient de 1,8 et 5,4. La latence médiane de HotKV était plus basse pour chaque nombre de clients. Le débit de Redis s’est stabilisé dès 32 clients, tandis que celui de HotKV a continué de croître jusqu’à 100. HotKV a chargé les vecteurs environ 5 fois plus vite, et son rappel était plus élevé à chaque profondeur de recherche. Il s’agit d’un seul jeu de données sur une seule machine, le build HotKV est un build de développement non publié, et nous n’avons mesuré ni le Query Engine de Redis ni son mode 8 bits : lisez ce résultat comme une mesure, pas comme un classement.

Ce que nous avons testé

Données

Les 999 000 premières lignes de dbpedia-entities-openai-1M de Kumar Shivendu et Nirant Kasliwal (licence MIT) et, pour un index plus petit, les 100 000 premières lignes. Ces lignes sont des entités DBpedia dont les embeddings ont été calculés avec OpenAI text-embedding-ada-002, en 1 536 dimensions. Les 1 000 dernières lignes servent de requêtes ; aucune ligne n’apparaît donc dans les deux ensembles. Le corrigé est constitué des 10 plus proches voisins exacts de chaque requête, calculés par recherche exhaustive en virgule flottante 64 bits, indépendamment des deux moteurs ; les deux sont donc évalués par rapport à la même vérité terrain.

Moteurs et réglages

• Moteurs. HotKV au commit c8dafd37 (VSIM.CREATEINDEX, VSIM.SET, VSIM.SEARCH), un build de développement non publié, compilé avec les options de release par défaut et non avec -march=native. Redis 8.10.2 compilé depuis son tag de release avec un make standard (VADD, VSIM). Les deux construisent des graphes HNSW.
• Réglages de l’index. Similarité cosinus, HNSW avec M=16 et ef_construction=200 sur les deux, définis explicitement. Ce sont aussi les valeurs par défaut de chaque moteur.
• Précision. Vecteurs float32 en pleine précision sur les deux. Redis utilise par défaut la quantification 8 bits ; il a donc tourné avec NOQUANT.
• Machine. Une machine Azure Standard_D160alds_v7 (AMD EPYC 9V45, 160 vCPU). Les deux serveurs étaient épinglés sur les mêmes 128 vCPU, les générateurs de charge sur les 32 autres, le tout via loopback. HotKV a utilisé 128 threads et Redis ses threads d’E/S par défaut. Nous avons essayé 1, 4, 8 et 16, et ce réglage n’a produit aucune différence constante.
• Générateur de charge. Un processus par connexion client, chacun gardant une requête en cours, les requêtes étant construites avant la partie chronométrée. Le processus de générateur de charge le plus sollicité a utilisé 8 % d’un CPU dans n’importe quelle exécution ; le client n’a donc jamais fixé la limite.

Procédure

Pour des profondeurs de recherche (ef) de 40, 80, 150 et 300, et de 500 sur l’index le plus grand, nous avons exécuté à répétition les 1 000 requêtes avec 1, 2, 4, 8, 16, 32, 50 et 100 clients : une seconde de préchauffage, puis quatre secondes comptabilisées, trois fois chacune, l’ordre des deux moteurs alternant. Nous indiquons la médiane. Le rappel a été mesuré séparément, sur une seule connexion. HotKV a été chargé sur 32 connexions à chaque exécution. Les index Redis ont été construits une seule fois, sur 32 connexions avec VADD ... CAS, enregistrés, puis chargés pour les mesures. Les scripts et chaque essai se trouvent dans le dépôt du benchmark.

Résultats

Objectifs de rappel équivalents

Les deux moteurs n’atteignent pas le même rappel au même ef ; nous comparons donc le débit à des objectifs de rappel minimal communs : pour chaque objectif, la plus rapide des profondeurs de recherche mesurées qui l’atteint. Les profondeurs et les rappels atteints figurent dans les tableaux, car ils diffèrent légèrement. Cela repose sur des profondeurs mesurées, et non sur une interpolation. Requêtes par seconde sur 999 000 vecteurs :

La latence médiane est indiquée sous la forme HotKV / Redis. Le même schéma valait pour un objectif de 90 % : 90 003 contre 7 973 requêtes par seconde à 100 clients (11,3 fois), les deux à ef 40.

Chaque profondeur de recherche

Requêtes par seconde sur 999 000 vecteurs. Sur 100 000 vecteurs, le schéma est le même. À 95 % de rappel, HotKV a servi 1,5 fois le nombre de requêtes par seconde de Redis avec un client (1 816 contre 1 214) et 8,9 fois avec 100 (63 247 contre 7 119).

Quelle part de ces résultats relève du bruit

Chaque cellule est la médiane de trois essais. La moitié des cellules présentaient un écart entre leur essai le plus bas et le plus haut de 1,3 % de la médiane ou moins, neuf sur dix de 7 % ou moins, et le plus large était de 26 % (Redis, 100 000 vecteurs, ef 300, 50 clients). Le rapport liste chaque essai.

Le rappel a été mesuré une fois par construction d’index. Trois constructions indépendantes de chaque moteur sur 100 000 vecteurs différaient jusqu’à 0,013 à la même profondeur ; le rappel plus élevé de HotKV est donc net jusqu’à ef 300, et il reste dans la variation d’une construction à l’autre à ef 500 sur le plus petit index.

Chargement et mémoire

Chargés chacun sur 32 connexions, HotKV a mis 188 secondes pour les 999 000 vecteurs (5 325 par seconde) et Redis 935 secondes (1 069 par seconde), temps passé par le générateur de charge à formater chaque vecteur compris. Sur 100 000 vecteurs, c’était 15 secondes contre 57. Redis chargeait plus vite avec CAS que sans lors d’une vérification sur 20 000 vecteurs (2 279 contre 1 488 vecteurs par seconde) ; nous l’avons donc utilisé. Le chargement de Redis a eu lieu lors d’une étape antérieure, Redis étant épinglé sur quatre vCPU pendant que d’autres vérifications tournaient sur la machine ; HotKV a chargé seul sur 128 vCPU. Le temps de chargement de Redis est donc une borne inférieure de sa vitesse, pas une comparaison à conditions égales.

Après le chargement de 999 000 vecteurs, le processus HotKV occupait 6,77 GB et le processus Redis 7,01 GB.

Ce qui limite Redis 8.10.2 ici

Les vector sets de Redis exécutent chaque recherche sur son propre thread, mais le code HNSW dispose d’un nombre fixe d’emplacements de threads (32, défini à la compilation de Redis), et les vecteurs sont ajoutés sur le thread principal. Dans nos exécutions, à partir de 32 clients, Redis a occupé entre 6 et 30 des vCPU de la machine et son débit s’était stabilisé. HotKV a occupé environ 92 vCPU avec 100 clients à ef 80 et son débit continuait de croître. C’est le comportement de chaque moteur sur cette machine, et non quelque chose que le benchmark a configuré.

Limites

Ce sont les mesures de HotKV Ltd pour les versions et la configuration ci-dessus, et non une affirmation sur tous les déploiements de Redis.

La configuration du test

• Un build de développement. Le commit c8dafd37 est un build de développement, et non une version publiée.
• Un jeu de données, une machine. Embeddings OpenAI en 1 536 dimensions, top 10 uniquement, float32, cosinus. D’autres dimensions, d’autres données ou un autre matériel peuvent donner des rapports différents.
• Le client partage la machine. Les générateurs de charge tournaient sur des vCPU distincts mais partageaient le système mémoire et le cache de dernier niveau avec les serveurs.
• Persistance désactivée. Aucun des serveurs n’écrivait de snapshots ni de fichier en ajout seul.

Ce qui n’a pas été mesuré

• Le mode 8 bits de Redis. Redis stocke par défaut des vecteurs quantifiés sur 8 bits, ce qui consomme moins de mémoire. Nous avons comparé du float32 à du float32.
• Le Redis Query Engine. Redis propose aussi la recherche vectorielle via FT.CREATE et FT.SEARCH. Nous n’avons testé que les vector sets ; les résultats ne disent donc rien du Query Engine.
• Chargement et rechargement de Redis. Les index Redis ont été construits lors d’une exécution antérieure, Redis étant épinglé sur quatre vCPU, puis sauvegardés et rechargés pour les mesures ; les temps de chargement de Redis sont donc une borne inférieure et ne sont pas comparables à conditions égales avec ceux de HotKV. La recherche sur un index rechargé a été environ 10 pour cent plus lente que sur un index fraîchement construit lors d’une vérification sur 20 000 vecteurs, de sorte que les chiffres de requêtes de Redis peuvent être sous-estimés d’autant.

Essayez par vous-même

La recherche vectorielle est intégrée au même serveur que le cache de prompts de HotKV, et le même index vectoriel alimente son cache sémantique et sa mémoire d’agent. La recherche vectorielle est incluse dans chaque offre HotKV Cloud. Le cache de prompts, le cache sémantique et la mémoire d’agent sont fournis avec l’offre Performance et les offres supérieures. Commencez sur HotKV Cloud, ou contactez les ventes pour la mesurer avec vos propres embeddings.