Búsqueda vectorial: HotKV frente a los vector sets de Redis 8, de 1 a 100 clientes

La búsqueda vectorial está en la base de muchas funciones de IA: la recuperación para RAG, la caché semántica, la memoria de agentes. Redis 8 incluye los vector sets, un tipo de datos en beta, integrados en el servidor, así que es la comparación obvia. Cargamos los mismos embeddings de OpenAI en HotKV y en Redis 8.10.2, ejecutamos las mismas 1000 consultas contra cada uno con entre 1 y 100 conexiones de cliente concurrentes, y medimos lo precisas que eran las respuestas, cuántas consultas por segundo atendió cada motor y cuánto tardó cada consulta.

En resumen. Con 999.000 vectores y un recall mínimo del 95 %, HotKV atendió 1,4 veces las consultas por segundo de Redis con un cliente y 7,9 veces con 100 clientes (51.146 frente a 6510). Con un recall del 99 %, las relaciones fueron de 1,8 y 5,4. La latencia mediana de HotKV fue menor con cada número de clientes. El throughput de Redis ya se había estabilizado con 32 clientes, mientras que el de HotKV siguió creciendo hasta 100. HotKV cargó los vectores unas 5 veces más rápido, y su recall fue mayor en todas las profundidades de búsqueda. Es un solo conjunto de datos en una sola máquina, la compilación de HotKV es una compilación de desarrollo sin publicar, y no medimos el Query Engine de Redis ni su modo de 8 bits, así que léelo como una medición, no como un ranking.

Qué probamos

Datos

Las primeras 999.000 filas de dbpedia-entities-openai-1M de Kumar Shivendu y Nirant Kasliwal (licencia MIT) y, para un índice más pequeño, las primeras 100.000 filas. Las filas son entidades de DBpedia con embeddings generados por text-embedding-ada-002 de OpenAI, de 1536 dimensiones. Las últimas 1000 filas son las consultas, por lo que ninguna fila aparece en los dos conjuntos. La clave de respuestas son los 10 vecinos más cercanos exactos de cada consulta, calculados por fuerza bruta en coma flotante de 64 bits con independencia de ambos motores, de modo que los dos se evalúan frente a la misma verdad de referencia (ground truth).

Motores y ajustes

• Motores. HotKV, commit c8dafd37 (VSIM.CREATEINDEX, VSIM.SET, VSIM.SEARCH), una compilación de desarrollo sin publicar, compilada con las opciones de versión por defecto, no con -march=native. Redis 8.10.2 compilado desde su etiqueta de versión con un make estándar (VADD, VSIM). Ambos construyen grafos HNSW.
• Ajustes del índice. Similitud del coseno, HNSW con M=16 y ef_construction=200 en ambos, establecidos de forma explícita. También son los valores por defecto de cada motor.
• Precisión. Vectores float32 de precisión completa en ambos. Redis usa por defecto la cuantización de 8 bits, por lo que se ejecutó con NOQUANT.
• Máquina. Una Azure Standard_D160alds_v7 (AMD EPYC 9V45, 160 vCPUs). Ambos servidores se fijaron a las mismas 128 vCPUs y los generadores de carga a las otras 32, todo a través de loopback. HotKV ejecutó 128 hilos y Redis sus hilos de E/S por defecto. Probamos con 1, 4, 8 y 16 y el ajuste no produjo ninguna diferencia consistente.
• Generador de carga. Un proceso por conexión de cliente, cada uno con una solicitud pendiente a la vez, con las solicitudes construidas antes de la parte cronometrada. El proceso generador de carga más ocupado usó el 8 % de una CPU en cualquier ejecución, por lo que el cliente nunca fijó el límite.

Procedimiento

Para profundidades de búsqueda (ef) de 40, 80, 150 y 300, y de 500 en el índice más grande, ejecutamos las 1000 consultas de forma repetida con 1, 2, 4, 8, 16, 32, 50 y 100 clientes: un segundo de calentamiento y después cuatro segundos contabilizados, tres veces cada una, alternando el orden de los dos motores. Indicamos la mediana. El recall se midió por separado, a través de una sola conexión. HotKV se cargó a través de 32 conexiones en cada ejecución. Los índices de Redis se construyeron una vez, a través de 32 conexiones con VADD ... CAS, se guardaron y se cargaron para las mediciones. Los scripts y cada ejecución están en el repositorio del benchmark.

Resultados

Objetivos de recall equiparados

Los dos motores no alcanzan el mismo recall con el mismo ef, así que comparamos el throughput con objetivos de recall mínimo compartidos: para cada objetivo, la profundidad de búsqueda medida más rápida que lo alcanza. Las profundidades y los recalls alcanzados están en las tablas, porque difieren un poco. Se usan profundidades medidas, no interpolación. Consultas por segundo con 999.000 vectores:

La latencia mediana se indica como HotKV / Redis. El mismo patrón se mantuvo con un objetivo del 90 %: 90.003 frente a 7973 consultas por segundo con 100 clientes (11,3 veces), ambos con ef 40.

Todas las profundidades de búsqueda

Consultas por segundo con 999.000 vectores. Con 100.000 vectores el patrón es el mismo. Con un recall del 95 %, HotKV atendió 1,5 veces las consultas por segundo de Redis con un cliente (1816 frente a 1214) y 8,9 veces con 100 (63.247 frente a 7119).

Cuánto de esto es ruido

Cada celda es la mediana de tres ejecuciones. La mitad de las celdas tuvo una dispersión entre su ejecución más baja y la más alta del 1,3 % de la mediana o menos, nueve de cada diez del 7 % o menos, y la más amplia fue del 26 % (Redis, 100.000 vectores, ef 300, 50 clientes). El informe enumera todas las ejecuciones.

El recall se midió una vez por cada construcción del índice. Tres construcciones independientes del índice de cada motor con 100.000 vectores difirieron hasta en 0,013 con la misma profundidad, por lo que el mayor recall de HotKV es claro hasta ef 300 y queda dentro de la variación entre construcciones con ef 500 en el índice más pequeño.

Carga y memoria

Cargados a través de 32 conexiones cada uno, HotKV tardó 188 segundos en cargar los 999.000 vectores (5325 por segundo) y Redis 935 segundos (1069 por segundo), incluido el tiempo que el generador de carga dedicó a dar formato a cada vector. Con 100.000 vectores fueron 15 segundos frente a 57. En una comprobación con 20.000 vectores, Redis cargó más rápido con CAS que sin él (2279 frente a 1488 vectores por segundo), así que lo usamos. La carga de Redis se hizo en un paso anterior con Redis fijado a cuatro vCPU mientras otras comprobaciones corrían en la máquina; HotKV cargó solo en 128 vCPU. El tiempo de carga de Redis es por tanto un límite inferior de su velocidad, no una comparación en igualdad de condiciones.

Tras cargar 999.000 vectores, el proceso de HotKV ocupaba 6,77 GB y el de Redis 7,01 GB.

Qué limita a Redis 8.10.2 aquí

Los vector sets de Redis ejecutan cada búsqueda en su propio hilo, pero el código de HNSW tiene un número fijo de ranuras de hilos (32, establecido cuando se compila Redis), y los vectores se añaden en el hilo principal. En nuestras ejecuciones, a partir de 32 clientes, Redis mantuvo ocupadas entre 6 y 30 de las vCPUs de la máquina y su throughput se había estabilizado. HotKV mantuvo ocupadas unas 92 vCPUs con 100 clientes y ef 80 y su throughput seguía creciendo. Así se comporta cada motor en esta máquina; no es algo que el benchmark configurara.

Limitaciones

Estas son mediciones de HotKV Ltd de las versiones y la configuración anteriores, no una afirmación sobre cualquier despliegue de Redis.

La configuración de la prueba

• Una compilación de desarrollo. El commit c8dafd37 es una compilación de desarrollo, no una versión publicada.
• Un conjunto de datos, una máquina. Embeddings de OpenAI de 1536 dimensiones, solo el top 10, float32, coseno. Otras dimensiones, otros datos u otro hardware pueden dar relaciones distintas.
• El cliente comparte la máquina. Los generadores de carga se ejecutaron en vCPUs separadas, pero compartieron con los servidores el sistema de memoria y la caché de último nivel.
• Persistencia desactivada. Ningún servidor escribió snapshots ni un archivo append-only.

Qué no se midió

• El modo de 8 bits de Redis. Redis almacena por defecto vectores cuantizados a 8 bits, lo que usa menos memoria. Comparamos float32 con float32.
• El Query Engine de Redis. Redis también ofrece búsqueda vectorial mediante FT.CREATE y FT.SEARCH. Probamos solo los vector sets, por lo que los resultados no dicen nada sobre el Query Engine.
• Carga y recarga de Redis. Los índices de Redis se construyeron en una ejecución anterior con Redis fijado a cuatro vCPU, se guardaron y se recargaron para las mediciones, así que los tiempos de carga de Redis son un límite inferior y no son comparables en igualdad de condiciones con los de HotKV. Buscar en un índice recargado fue alrededor de un 10 por ciento más lento que en uno recién construido en una comprobación con 20.000 vectores, por lo que las cifras de consultas de Redis pueden ser bajas en una proporción similar.

Pruébalo tú mismo

La búsqueda vectorial está integrada en el mismo servidor que la caché de prompts de HotKV, y el mismo índice vectorial respalda su caché semántica y la memoria de agentes. La búsqueda vectorial está incluida en todos los planes de HotKV Cloud. La caché de prompts, la caché semántica y la memoria de agentes vienen con el plan Performance y superiores. Empieza en HotKV Cloud, o habla con ventas para medirla con tus propios embeddings.