Resumen

Primero, pongámonos al día. Elasticsearch se consolidó como una poderosa base de datos vectorial, que ofrece un amplio conjunto de características y un sólido rendimiento para la búsqueda de similitudes a gran escala. Con capacidades como la cuantificación escalar, Better Binary Quantization (BBQ), operaciones vectoriales SIMD y algoritmos más eficientes en disco como DiskBBQ, ya ofrece opciones eficientes y flexibles para gestionar cargas de trabajo vectoriales.

Al integrar NVIDIA cuVS como un módulo invocable para tareas de búsqueda vectorial, nuestro objetivo es ofrecer beneficios significativos en el rendimiento y la eficiencia de la indexación vectorial para soportar mejor las cargas de trabajo vectoriales a gran escala.

El desafío

Uno de los mayores desafíos al construir una base de datos vectorial de alto rendimiento es construir el índice vectorial: el grafo HNSW. La construcción de índices se ve dominada con rapidez por millones o incluso miles de millones de operaciones aritméticas a medida que cada vector se compara con muchos otros. Además, las operaciones del ciclo de vida del índice, como la compactación y las fusiones, pueden aumentar aún más la sobrecarga total de cálculo de la indexación. A medida que los volúmenes de datos y las incrustaciones vectoriales asociadas crecen de manera exponencial, las GPU de cómputo acelerado, diseñadas para el paralelismo masivo y las matemáticas de alto rendimiento, se posicionan idealmente para manejar estas cargas de trabajo.

Ingresa al plugin Elasticsearch-GPU

NVIDIA cuVS es una biblioteca open source de CUDA-X para la búsqueda vectorial acelerada por GPU y la agrupación de datos, que permite una rápida construcción de índices y recuperación de incrustaciones para cargas de trabajo de AI y de sistemas de recomendación.

Elasticsearch utiliza cuVS a través de cuvs-java, una biblioteca open source desarrollada por la comunidad y que mantiene NVIDIA. La biblioteca cuvs-java es ligera, se basa en la API C de cuVS y usa la función externa del Proyecto Panamá para exponer las características de cuVS de una manera idiomática en Java, al tiempo que es moderna y presenta un alto rendimiento.

La biblioteca cuvs-java está integrada en un nuevo plugin de Elasticsearch; por lo tanto, la indexación vectorial en la GPU puede ocurrir en el mismo nodo y proceso de Elasticsearch, sin la necesidad de provisionar ningún código o hardware externo. Durante la construcción del índice, si se instala la biblioteca cuVS y hay una GPU presente y configurada, Elasticsearch usará la GPU para acelerar el proceso de indexación vectorial. Los vectores se asignan a la GPU, que construye un grafo CAGRA. Este grafo se convierte entonces al formato HNSW, y hace que esté disponible de inmediato para la búsqueda vectorial en la CPU. El formato final del grafo construido es el mismo que el que se construiría en la CPU; esto permite a Elasticsearch aprovechar las GPU para indexar vectores de alto rendimiento cuando el hardware subyacente lo admite, al tiempo que libera poder de la CPU para otras tareas (búsqueda simultánea, procesamiento de datos, etc.).

Aceleración en la generación de índices

Como parte de la integración de la aceleración de GPU en Elasticsearch, se realizaron varias mejoras en cuvs-java, centradas en la entrada/salida eficiente de datos y la invocación de funciones. Una mejora clave es el uso de cuVSMatrix para modelar vectores de forma transparente, ya sea que residan en la memoria heap de Java, fuera de la memoria heap o en la memoria de la GPU. Esto permite que los datos se muevan de manera eficiente entre la memoria y la GPU, lo que evita copias innecesarias de potencialmente miles de millones de vectores.

Gracias a esta abstracción subyacente de copia cero, tanto la transferencia a la memoria de la GPU como la recuperación del grafo se pueden realizar directamente. Durante la indexación, los vectores se almacenan primero en búfer en la memoria heap de Java, y luego se envían a la GPU para construir el grafo CAGRA. Después, el grafo se recupera de la GPU, se convierte al formato HNSW y se mantiene en el disco.

En el momento de la fusión, los vectores ya están almacenados en disco, sin pasar por la memoria heap de Java. Los archivos de índice se mapean en memoria, y los datos se transfieren directamente a la memoria de la GPU. El diseño también se adapta fácilmente a diferentes anchos de bits, como float32 o int8, y se extiende de forma natural a otros esquemas de cuantificación.

Redoble de tambores… entonces, ¿cómo se funciona?

Antes de entrar en los números, un poco de contexto es útil. La fusión de segmentos en Elasticsearch suele ejecutarse automáticamente en segundo plano durante la indexación, lo que dificulta hacer benchmarks de forma aislada. Para obtener resultados reproducibles, utilizamos la fusión forzosa para activar explícitamente la combinación de segmentos en un experimento controlado. Dado que la fusión forzosa hace las mismas operaciones de fusión subyacentes que la fusión en segundo plano, su rendimiento sirve como un indicador útil de las mejoras esperadas, aunque las ganancias exactas pueden diferir en las cargas de trabajo de indexación del mundo real.

Ahora, veamos los números.

Nuestros resultados iniciales de evaluaciones comparativas son muy prometedores. Ejecutamos la evaluación comparativa en una instancia de AWS g6.4xlarge con almacenamiento NVMe conectado a nivel local. Se configuró un único nodo de Elasticsearch para que use el número predeterminado y óptimo de subprocesos de indexación (8, uno por cada núcleo físico) y deshabilite la limitación de la fusión (que es menos aplicable con discos NVMe rápidos).

Para el conjunto de datos, utilizamos 2,6 millones de vectores con 1536 dimensiones del vector de pista de Rally de OpenAI, codificados como cadenas de texto base64 e indexados como float32 hnsw. En todos los escenarios, los grafos construidos alcanzan niveles de recuperación de hasta el 95 %. A continuación, presentamos nuestros hallazgos:

• Rendimiento de indexación: al trasladar la construcción de grafos a la GPU durante los vaciados de búferes en memoria, aumentamos el rendimiento en aproximadamente 12 veces.

• Fusión forzada: una vez que finaliza la indexación, la GPU continúa acelerando la fusión de segmentos, lo que acelera la fase de fusión forzada en alrededor de 7 veces.

• Uso de la CPU: descargar la construcción de grafos a la GPU reduce de manera significativa el uso promedio y máximo de la CPU. Los grafos a continuación ilustran el uso de la CPU durante la indexación y la fusión, y permiten ver cuánto menor es cuando estas operaciones se ejecutan en la GPU. Un menor uso de la CPU durante la indexación por GPU libera ciclos de CPU que pueden redirigirse para mejorar el rendimiento de la búsqueda.

• Recuperación: la precisión se mantiene prácticamente igual entre las ejecuciones de CPU y GPU, y el grafo construido por la GPU alcanza una recuperación un poco mayor.

Comparación en otra dimensión: el precio

La comparación anterior utilizaba intencionalmente hardware idéntico, y la única diferencia era si se usaba la GPU durante la indexación o no. Esa configuración es útil para aislar los efectos de la computación en bruto, pero también podemos analizar la comparación desde una perspectiva de costos.

A un precio horario similar al de la configuración acelerada por GPU, se puede provisionar una configuración de solo CPU con aproximadamente el doble de recursos comparables de CPU y memoria: 32 vCPUs (AMD EPYC) y 64 GB de RAM, lo que permite duplicar el número de hilos de indexación a 16.

Para mantener la comparación justa y consistente, ejecutamos este experimento solo de CPU en una instancia AWS g6.8xlarge, con la GPU explícitamente desactivada. Esto nos permitió mantener constantes todas las demás características del hardware mientras evaluábamos la compensación entre costo y rendimiento de la aceleración de GPU frente al indexado solo con CPU.

Como era de esperar, la instancia de CPU más potente sí muestra un mejor rendimiento en comparación con las evaluaciones comparativas de la sección anterior. Sin embargo, cuando comparamos esta instancia de CPU más potente con los resultados acelerados por GPU originales, la GPU aún ofrece beneficios sustanciales en cuanto al rendimiento: ~ 5 veces de mejora en el rendimiento de indexación y ~ 6 veces en la fusión forzada, todo ello mientras se construyen grafos que alcanzan niveles de recuperación de hasta un 95 %.

Conclusión

En escenarios completos, la aceleración por GPU con NVIDIA cuVS ofrece una mejora de casi 12 veces en el rendimiento de la indexación y una disminución de 7 veces en la latencia de fusión forzada, con un uso de CPU significativamente menor. Esto demuestra que la indexación vectorial y las cargas de trabajo de fusión se benefician de manera significativa de la aceleración por GPU. En una comparación ajustada por costos, la aceleración por GPU continúa mostrando beneficios sustanciales en cuanto al rendimiento, con alrededor de 5 veces más rendimiento de indexación y 6 veces más rapidez en las operaciones de fusión forzada.

La indexación vectorial acelerada por GPU tiene planificada hoy en día una vista previa técnica en Elasticsearch 9.3, cuyo lanzamiento está programado para principios de 2026.

Mantente atento a lo que viene.

Como parte de nuestra misión de no dejar atrás la eficiencia, estamos explorando oportunidades de aceleramiento con estos curiosos chips de computadora, de los que quizás oíste hablar: ¡las GPU NVIDIA! (En serio, ¿no es así?).

Cuando nos obsesionamos con el rendimiento, tenemos varios espacios problemáticos para explorar: cómo indexar exponencialmente más datos, cómo recuperar información de ellos y cómo hacerlo cuando sus modelos de ML están involucrados. Debería poder obtener hasta el último beneficio disponible cuando tenga GPU.

En esta publicación, nos sumergimos en nuestra colaboración con el equipo de búsqueda vectorial de NVIDIA mientras exploramos la búsqueda vectorial acelerada por GPU en Elasticsearch. Este trabajo allana el camino para casos de uso en los que los desarrolladores podrían usar una combinación de GPU y CPU para aplicaciones con tecnología de Elasticsearch del mundo real. ¡Tiempos emocionantes!

GPU de Elasticsearch

Nos complace compartir que el equipo de ingeniería de Elasticsearch está ayudando a crear la experiencia de la API de Java cuVS de código abierto para desarrolladores, que expone enlaces para algoritmos de búsqueda vectorial. Este trabajo aprovecha nuestra experiencia previa con Panama FFI. Elasticsearch y Apache Lucene emplean la API NVIDIA cuVS para crear el gráfico durante la indexación. Bien, estamos saltando hacia adelante; Rebobinemos un poco.

NVIDIA cuVS, una biblioteca de C++ de código abierto, está en el corazón de esta colaboración. Su objetivo es llevar el aceleramiento de GPU a la búsqueda vectorial al proporcionar un mayor rendimiento, menor latencia y tiempos de compilación de índices más rápidos. Pero Elasticsearch y Apache Lucene están escritos en Java; ¿Cómo funcionará esto?

Ingrese lucene-cuvs y la colaboración Elastic-NVIDIA-SearchScale para llevarlo al ecosistema de Lucene para explorar la búsqueda vectorial acelerada por GPU en Elasticsearch. En la reciente versión 25.02 de NVIDIA cuVS, agregamos una API de Java para cuVS. La nueva API es experimental y seguirá evolucionando, pero actualmente está disponible para su uso. Puede surgir la pregunta: ¿no son lentas las llamadas de Java a funciones nativas? ¡Ya no! Estamos usando la nueva FFI (interfaz de funciones externas) de Panamá para los enlaces, que tiene una sobrecarga mínima para Java a las llamadas descendentes nativas.

Estuvimos usando Panama FFI en Elasticsearch y Lucene desde hace un tiempo. ¡Es asombroso! Pero... Siempre hay un "pero", ¿no? FFI tiene desafíos de disponibilidad en todas las versiones de Java. Superamos esto compilando la API de cuVS en Java 21 y encapsulando la implementación dentro de un jar de varias versiones dirigido a Java 22. Esto permite el uso de cuVS Java directamente en Lucene y Elasticsearch.

Ok, ahora que tenemos la API de Java de cuVS, ¿qué más necesitaríamos?

Una historia de dos algoritmos para CPU

Elasticsearch admite el algoritmo HNSW para una búsqueda KNN aproximada escalable. Sin embargo, para sacar el máximo provecho de la GPU, empleamos un algoritmo diferente, CAGRA [CUDA ANN GRAph], que fue diseñado específicamente para los altos niveles de paralelismo que ofrece la GPU.

Antes de entrar en cómo buscamos agregar soporte para CAGRA, veamos cómo Elasticsearch y Lucene acceden a los datos del índice a través de un "formato de códec". Consiste en

1. la representación en disco,

2. las interfaces para leer y escribir datos,

3. y la maquinaria para lidiar con la arquitectura basada en segmentos de Lucene.

Estamos implementando un nuevo formato vectorial KNN (k-vecinos más cercanos) que emplea internamente la API de Java de cuVS para indexar y buscar en la GPU. A partir de aquí, "sondeamos" este tipo de códec a través de las asignaciones de Elasticsearch a un tipo de campo en el índice. Como resultado, las consultas KNN existentes siguen funcionando independientemente de si el índice de respaldo emplea un gráfico CAGRA o HNSW. Por supuesto, esto pasa por alto muchos detalles, que planeamos cubrir en un blog futuro. La siguiente es la arquitectura de alto nivel para un Elasticsearch acelerado por GPU.

Este nuevo formato de códec tiene como valor predeterminado CAGRA. Sin embargo, también admite la conversión de un gráfico CAGRA en un gráfico HNSW para la búsqueda en la CPU.

Indexación y búsqueda en la GPU: Tomar algunas decisiones "básicas"

Con la arquitectura sin estado de Elasticsearch Serverless, que separa la indexación y la búsqueda, ahora hay una clara delimitación de responsabilidades. Elegimos el mejor perfil de hardware para cumplir con cada una de estas responsabilidades independientes.

Anticipamos que los usuarios considerarán dos estrategias de implementación principales:

1. Indexación y búsqueda en la GPU: durante la indexación, cree un gráfico CAGRA y empléelo durante la búsqueda, ideal cuando se requiere una búsqueda de latencia extremadamente baja.

2. Indexar en GPU y buscar en CPU: durante la indexación, cree un gráfico CAGRA y conviértalo en un gráfico HNSW. El gráfico HNSW se almacena en el índice, que luego se puede usar en la CPU para la búsqueda.

Esta flexibilidad proporciona diferentes modelos de implementación, ofreciendo compensaciones entre costo y rendimiento. Por ejemplo, un servicio de indexación podría usar GPU para compilar y combinar gráficos de manera eficiente de manera oportuna mientras usa una CPU de menor potencia para la búsqueda.

Así que aquí está el plan para la búsqueda vectorial acelerada por GPU en Elasticsearch

Esperamos brindar ganancias de rendimiento y flexibilidad con estrategias de implementación a los usuarios, ofreciendo varias perillas para equilibrar el costo y el rendimiento. Aquí está la sesión de NVIDIA GTC 2025 donde se presentó este trabajo en detalle.

Nos gustaría agradecer a los equipos de ingeniería de NVIDIA y SearchScale por su fantástica colaboración. En un próximo blog, exploraremos los detalles de implementación y el análisis de rendimiento con mayor profundidad. ¡Agárrate a tus sombreros de 🎩 curiosidad!