NVMe-oE向量搜索: 7K到72K QPS

梯形图转SCL | AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

我们最近通过两条200Gb/s以太网链路，使用专有的NVMe-over-Ethernet（NVMe-oE）技术，实现了1170万次4KiB随机读取IOPS。AI应用能否真正有效地利用如此多的小I/O性能？

近似最近邻（ANN）向量搜索是许多RAG管道、语义搜索服务和推荐系统背后的检索层，是一个自然的测试场景。大型图索引可以驻留在存储上，并在搜索遍历图时生成高度随机、依赖于数据的读取。我们没有运行另一个合成基准测试，而是使用BigANN/SIFT数据集和Recall@10验证，用真实的ANN引擎测试了NVMe-oE。

对于单个服务器，本地NVMe仍然是最简单的选项。然而，在更大的AI部署中，将每个向量索引保留在执行搜索的同一服务器上会产生扩展问题。添加、替换或重新分配GPU服务器可能还需要复制大型索引，而一台服务器上未使用的存储无法轻松为另一台服务器上的工作负载提供服务。NVMe-oF和我们精简的NVMe-oE方法将计算与存储分离：多个租户、RAG服务和ANN工作者可以访问共享的向量索引池，同时计算和存储容量独立扩展。这实现了集中的数据放置、更高的存储利用率和更快的检索工作负载重新分配，而无需放弃熟悉的块设备模型。

1、从CPU搜索到GPU辅助搜索

我们在相同的双链路NVMe-oE平台上进行了一系列Recall验证的ANN基准测试，使用BigANN/SIFT查询和top-10搜索。每个引擎都独立调整以最大化Recall验证的存储吞吐量，因此结果展示了每个CPU或GPU辅助架构可以生成多少有用的I/O，而不是严格的算法到算法的加速比较。

QPS和IOPS不会按相同比例上升，因为IOPS ≈ QPS × 每次查询的读取次数。这些测试选择了通过Recall要求的最高IOPS配置；它们没有对每次查询施加固定的存储预算。DiskANN选择的高负载配置每次查询执行约353次读取，而GustANN需要约101次。因此，9.7倍的QPS增长结合了2.77倍更高的IOPS和约3.49倍更少的每次查询读取次数。这是一个调整后的系统比较，而不是孤立的GPU加速。

通过将我们的NVMe-oE存储路径与GPU辅助向量搜索相结合，我们从7,463 QPS提升到72,212 QPS，增加了9.7倍，Recall@10约为99.8%。与CPU PipeANN配置相比，双GPU结果提供了6.1倍更高的QPS。双GPU运行产生了729.9万次4KiB读取/秒，对应约239 Gb/s的有效存储负载。

2、测试环境

我们使用了通过两条独立的200Gb/s以太网链路连接的两台主机。发起端主机是一台双路Supermicro SYS740GP-TNRT，具有32个物理CPU核心（每个插槽16个核心），禁用SMT，256 GiB DRAM，两块48 GiB RTX A6000 GPU和两条200Gb/s ConnectX-6 Dx以太网链路。24核Supermicro AS5014ATT目标主机导出了两个64 GiB易失性稀疏RAM命名空间，每个命名空间使用24个队列，队列深度512。RAM后端故意移除了物理介质和持久性限制，因此此阶段测量的是ANN应用程序、主机路径和传输。

基准测试使用BigANN-10M、L2距离和top-10搜索，以及针对特定引擎的索引和执行调优。选择的GustANN配置是R128/L200/PQ32，L100/B1536/T13/C1；这些参数控制图构建、压缩、搜索宽度、批处理和并发性。详细的定义和调优指南可在DiskANN论文、PipeANN论文和演示以及GustANN项目指南中找到。

3、仍有余量

有趣的是，NVMe-oE尚未饱和。我们验证的图页面服务上限是1178万IOPS，而双GPU ANN工作负载达到了730万IOPS，约为该上限的62%。

运行时遥测有助于解释剩余的余量。在双GPU运行期间，分配给GustANN搜索工作者的CPU核心平均忙碌98.4%，而两个GPU平均只有52.3%的计算利用率。因此，当前客户端在GPU或NVMe-oE链路饱和之前，就耗尽了CPU容量来准备和提交搜索工作。更多或更快的CPU核心，加上改进的批处理和调度，可以使GPU更忙碌并驱动更高的IOPS和QPS。

纯CPU引擎在饱和NVMe-oE之前就达到了计算限制。DiskANN和PipeANN分别产生了263.4万和370.5万IOPS，而它们的ANN搜索工作者已经高度利用；在选定的PipeANN候选中，搜索核心平均忙碌95.8%。GPU辅助的GustANN将更多的并行向量搜索工作从CPU上移走，使应用程序能够产生729.9万IOPS。

应用程序通过普通的Linux块设备使用O_DIRECT和io_uring访问NVMe-oE；不需要GPUDirect Storage或SPDK发起端。

NVIDIA GPUDirect Storage（GDS）不一定是此工作负载的最佳下一步。当GPU直接消费存储数据时，GDS最有效，但GustANN的小型、依赖数据的读取仍由CPU工作者调度。由于CPU请求处理（而非数据复制）是明显的瓶颈，仅GDS不太可能显著增加IOPS。因此，我们下一个优化重点是CPU调度和I/O批处理，而GDS仍是未来评估的一个选项。

4、下一步是什么？

下一步是与标准NVMe-oF进行受控比较：通过NVMe/RDMA（RoCE）和NVMe/TCP的Linux nvmet和SPDK目标。

目标很明确：确定当AI向量搜索每秒需要数百万次小型随机读取时，精简的NVMe-oE存储路径可以提供多少优势。这与多租户、共享存储环境特别相关，因为许多ANN工作者和GPU主机同时访问池化的向量索引。更高的小I/O效率可以提高租户密度、存储利用率和性能可预测性，同时允许计算和存储容量独立扩展。我们的初步存储测试表明，在我们的测试环境中，潜在的IOPS和吞吐量优势接近传统nvmet/SPDK路径的2倍。下一阶段将确定该原始存储优势是否能延续到Recall验证的ANN和更广泛的AI工作负载。敬请期待。

原文链接：From 7K to 72K QPS: Scaling Vector Search for RAG and AI Workloads with NVMe-oE

汇智网翻译整理，转载请标明出处