回顾

先简单回顾一下最新动态。Elasticsearch 现已确立其作为强大向量数据库的地位，在大规模相似性搜索方面提供了丰富的功能和强劲的性能。凭借标量量化、Better Binary Quantization (BBQ)、SIMD 向量运算以及 DiskBBQ 等在磁盘利用方面更高效的算法，Elasticsearch 已经为管理向量工作负载提供了高效而灵活的多种选项。

通过将 NVIDIA cuVS 集成为可调用的向量搜索模块，我们希望大幅提升向量索引的性能和效率，从而更好地支撑大规模向量工作负载。

挑战

构建高性能向量数据库的最大挑战之一，就是构建向量索引，即 HNSW 图。随着每个向量都要与大量其他向量进行比对，索引构建很快就会被数以百万乃至数十亿次的算术运算所主导。此外，压缩、合并等索引生命周期操作还会进一步增加索引的整体计算开销。随着数据量和相关向量嵌入呈指数级增长，专为大规模并行和高吞吐量数值运算而设计的加速计算 GPU 非常适合处理这些工作负载。

进入 Elasticsearch-GPU 插件

NVIDIA cuVS是一个开源的 CUDA-X 库，用于 GPU 加速的向量搜索和数据集群，能够为 AI 和推荐工作负载快速构建索引和嵌入检索。

Elasticsearch 通过 cuvs-java 使用 cuVS，这是一个由社区开发并由 NVIDIA 维护的开源库。cuvs-java 库十分轻量，基于 cuVS C API 构建，并借助 Panama 外部函数接口，以符合 Java 习惯用法的方式暴露 cuVS 功能，同时兼具现代性和高性能。

cuvs-java 库被集成到一个新的 Elasticsearch 插件中；因此，GPU 上的向量索引可在同一 Elasticsearch 节点和同一进程内完成，无需部署任何外部组件或额外硬件。在索引构建过程中，如果已安装 cuVS 库且存在已正确配置的 GPU，Elasticsearch 会利用 GPU 加速向量索引过程。向量会被传递给 GPU，由 GPU 构建 CAGRA 图。随后将该图转换为 HNSW 格式，使其能够立即在 CPU 上用于向量搜索。构建完成的图，其最终格式与在 CPU 上构建的图完全一致；这使得在底层硬件支持的情况下，Elasticsearch 可以利用 GPU 实现高吞吐量的向量索引，同时释放 CPU 算力，用于并发搜索、数据处理等其他任务。

索引构建加速

作为将 GPU 加速集成到 Elasticsearch 的一部分，对 cuvs-java 进行了多项增强，重点是高效的数据输入/输出和函数调用。一项关键增强是使用 cuVSMatrix 对向量进行透明建模，无论它们位于 Java 堆中、堆外还是 GPU 内存中。这使数据可以在内存与 GPU 之间高效传输，避免对可能多达数十亿个向量进行不必要的复制。

由于这种底层的零拷贝抽象，数据传输到 GPU 内存以及从中检索图时都可以直接完成。在索引过程中，向量首先缓存在 Java 堆内存中，然后发送到 GPU，以构建 CAGRA 图。随后，从 GPU 中取回该图，将其转换为 HNSW 格式，并持久化到磁盘。

在合并时，向量已经存储在磁盘上，完全绕过了 Java 堆。索引文件采用内存映射，数据直接传输到 GPU 内存中。该设计还能轻松适应不同的位宽，如 float32 或 int8，并自然扩展到其他量化方案。

话不多说，那它的实际表现如何呢？

在我们探讨数字之前，了解一些背景信息会有所帮助。在索引期间，Elasticsearch 中的分段合并通常在后台自动运行，这会导致在隔离环境中进行基准测试变得十分困难。为了获得可重复的结果，我们使用了强制合并来在受控实验中明确触发分段合并。由于强制合并与后台合并执行相同的底层合并操作，因此其性能可作为预期改进的有用指标，尽管在实际索引工作负载中，具体收获可能会有所不同。

现在让我们来探讨数字。

我们的初步基准测试结果非常令人鼓舞。我们在 AWS g6.4xlarge 实例上运行了基准测试，该实例具有本地连接的 NVMe 存储。我们将单个 Elasticsearch 节点配置为使用默认的最佳索引线程数（8 个，每个物理核心一个），并关闭合并限速功能（在使用快速 NVMe 磁盘时，这一功能的适用性较低）。

对于数据集，我们使用了 OpenAI Rally 向量赛道中的 260 万个、每个具有 1,536 维的向量，将其编码为 base64 字符串，并以 float32 hnsw 结构进行索引。在所有场景中，构建的图都能达到最高约 95% 的召回率。以下是我们的发现：

• 索引吞吐量：通过在内存缓冲区刷新期间将图构建移交给 GPU 处理，我们将吞吐量提高了约 12 倍。

• 强制合并：索引完成后，GPU 继续加速分段合并，将强制合并阶段加快约 7 倍。

• CPU 使用率：将图构建任务分流到 GPU，可显著降低 CPU 的平均和峰值利用率。以下图表展示了索引和合并期间的 CPU 使用情况，凸显了在 GPU 上运行这些操作时 CPU 使用率的显著降低。GPU 索引期间降低 CPU 使用率，可释放 CPU 周期并重新分配，从而提升搜索性能。

• 召回率：在 CPU 与 GPU 的运行结果中，准确性几乎一致，而 GPU 所构建的图在召回率方面略胜一筹。

再从价格这个维度来进行比较

前面的对比特意选用了相同的硬件配置，唯一的区别只是索引时是否启用 GPU。这种设置有助于单独考察计算性能的影响，不过也可以从成本角度来进行对比。

在与 GPU 加速配置大致相同的按小时费用下，可以搭建一套仅使用 CPU 的环境，其 CPU 和内存资源大约是前者的两倍：32 个 vCPU（AMD EPYC）和 64 GB RAM，因而可将索引线程数量增加到 16

为了保持比较的公平和一致性，我们在 AWS g6.8xlarge 实例上运行了这个仅 CPU 的实验，并且明确禁用了 GPU。这使我们能够在评估 GPU 加速与仅 CPU 索引的成本-性能权衡时，保持所有其他硬件特性不变。

正如您所预期的那样，更强大的 CPU 实例与上述部分的基准测试相比，性能确实有所提高。然而，将这一性能更强的 CPU 实例与最初的 GPU 加速结果进行对比后可以看到，GPU 依然带来显著性能提升：索引吞吐量提高约 5 倍，强制合并阶段加速约 6 倍，同时构建的图其召回率最高可达 95%。

结论

在端到端场景中，使用 NVIDIA cuVS 进行的 GPU 加速使索引吞吐量提高了近 12 倍，将强制合并延迟降低到原来的 1/7，同时显著降低了 CPU 利用率。这表明向量索引和合并工作负载从 GPU 加速中受益显著。在成本调整后的对比中，GPU 加速依然带来显著的性能提升：索引吞吐量约提升 5 倍，强制合并操作的速度提升约 6 倍。

GPU 加速的向量索引目前计划在 Elasticsearch 9.3 的技术预览版中推出，该版本计划于 2026 年初发布。

敬请关注更多内容。

作为 "不遗余力地提高效率 "这一使命的一部分，我们正在利用这些奇特的计算机芯片探索加速机会，你可能听说过英伟达™（NVIDIA®）GPU！(说真的，你没听说过吗？）

在执着于性能时，我们有几个问题空间需要探索--如何索引指数级增长的数据，如何从中获取洞察力，以及如何在涉及 ML 模型时做到这一点。有了 GPU，你就能把所有的优势都发挥出来。

在本篇文章中，我们将深入探讨与英伟达™（NVIDIA®）矢量搜索团队的合作，探索 Elasticsearch 中的 GPU 加速矢量搜索。这项工作为开发人员在实际的 Elasticsearch 应用程序中混合使用 GPU 和 CPU 的用例铺平了道路。激动人心的时刻

Elasticsearch GPU

我们很高兴地与大家分享，Elasticsearch 工程团队正在帮助开发人员构建开源的 cuVS Java API 体验，该体验为矢量搜索算法提供了绑定。这项工作利用了我们以前在巴拿马 FFI 方面的经验。Elasticsearch 和 Apache Lucene 在索引过程中使用英伟达 cuVS API 构建图形。好吧，我们跳到前面，让我们倒退一下。

NVIDIA cuVS 是一个开源 C++ 库，是此次合作的核心。它旨在通过提供更高的吞吐量、更低的延迟和更快的索引构建时间，为矢量搜索提供 GPU 加速。但 Elasticsearch 和 Apache Lucene 都是用 Java 编写的，这怎么行呢？

进入lucene-cuvs和 Elastic-NVIDIA-SearchScale 合作，将其引入 Lucene 生态系统，在 Elasticsearch 中探索 GPU 加速的矢量搜索。在最近发布的英伟达 cuVS 25.02 中，我们为 cuVS 添加了 Java API。新的应用程序接口是试验性的，将继续发展，但目前已经可以使用。也许有人会问：Java 对本地函数的调用不是很慢吗？现在不一样了！我们正在使用新的巴拿马 FFI（外来函数接口）进行绑定，它将 Java 与本地向下调用的开销降至最低。

我们 在 Elasticsearch 和 Lucene 中 使用 巴拿马 FFI 已经有一段时间了。太棒了但是......总是有 "但是 "的，不是吗？FFI 在跨 Java 版本的可用性方面存在挑战。我们将 cuVS 应用程序接口编译到 Java 21，并将实现封装在一个针对 Java 22 的多版本 jar 中，从而克服了这一问题。这样就可以直接在 Lucene 和 Elasticsearch 中使用 cuVS Java。

好了，既然我们已经有了 cuVS Java API，还需要什么呢？

两种 CPU 算法的故事

Elasticsearch 支持用于可扩展近似 KNN 搜索的HNSW 算法。不过，为了最大限度地利用 GPU，我们使用了另一种算法 CAGRA [ CUDAANNGRAph] ，它是专门为 GPU 提供的高并行性而设计的。

在了解如何添加对 CAGRA 的支持之前，我们先来看看 Elasticsearch 和 Lucene 是如何通过 "编解码器格式 "访问索引数据的。这包括

1. 磁盘表示法、

2. 读写数据的接口、

3. 以及处理 Lucene 基于段的架构的机制。

我们正在实施一种新的 KNN（k-近邻）向量格式，该格式内部使用 cuVS Java API 在 GPU 上进行索引和搜索。从这里开始，我们通过 Elasticsearch 的映射将此编解码器类型 "剽窃 "到索引中的字段类型。因此，无论后备索引使用的是 CAGRA 还是 HNSW 图形，现有的 KNN 查询都能继续工作。当然，这忽略了许多细节，我们计划在今后的博客中加以介绍。以下是 GPU 加速 Elasticsearch 的高级架构。

这种新的编解码器格式默认为 CAGRA。不过，它也支持将 CAGRA 图形转换为 HNSW 图形，以便在 CPU 上进行搜索。

在 GPU 上进行索引和搜索：做出一些 "核心 "决定

Elasticsearch Serverless 的无状态架构将索引和搜索分离开来，因此现在有了明确的职责划分。我们选择最佳的硬件配置文件来履行这些独立的职责。

我们预计用户会考虑两种主要的部署策略：

1. 在 GPU 上进行索引和搜索：在索引过程中，建立一个 CAGRA 图，并在搜索过程中使用它--这在需要极低延迟的搜索时非常理想。

2. 在 GPU 上索引，在 CPU 上搜索：在索引过程中，构建 CAGRA 图并将其转换为 HNSW 图。HNSW 图形存储在索引中，随后可用于 CPU 的搜索。

这种灵活性提供了不同的部署模式，在成本和性能之间进行了权衡。例如，索引服务可以使用 GPU 及时高效地构建和合并图形，同时使用性能较低的 CPU 进行搜索。

以下是在 Elasticsearch 中使用 GPU 加速矢量搜索的计划

我们期待为用户带来性能提升和部署策略的灵活性，提供各种旋钮来平衡成本和性能。下面是 NVIDIA GTC 2025 会议对这项工作的详细介绍。

我们要感谢 NVIDIA 和 SearchScale 工程团队的出色合作。在下一篇博客中，我们将更深入地探讨实施细节和性能分析。戴上好奇帽🎩 ！