3 倍于 VectorDBBench 榜首,火山 Milvus 如何把向量检索拉到新高度

大模型持续推高内存存储需求与硬件成本,硬件成本正成为制约向量检索规模化的最大瓶颈之一;海量向量场景下,如何在固定预算内平衡 "吞吐、延迟、召回率与数据导入效率" 等各项性能指标成为业务扩张核心难题。

火山 Milvus 上线之初即集成业界先进的 DiskANN + RaBitQ 算法。依托该能力,其性能版较开源版本性能提升 30% 以上,磁盘版性能更是领先开源版本 5 倍以上,详情可参考 5 倍性能优于开源版,火山 Milvus 集成 DiskANN + RaBitQ

本次,火山 Milvus 通过进一步优化向量检索算法与在线查询链路,再次刷新了性能上限:在固定成本下,延续上次相比开源 Milvus 实现超过 5 倍性能提升外,本次更是达到了 VectorDBBench 榜首近 3 倍,让向量数据库在真实在线场景中的性价比持续领先。

超越 VectorDBBench 榜首的高性能

作为向量数据库、云向量服务权威基准评测工具,VectorDBBench 是覆盖写入、检索、过滤检索等真实业务场景,是业内衡量向量库性能与性价比的通用标准。所有评测统一限定每月 1000 美元固定成本(按 2025 年均汇率 7.1429 折算,约 7142.9 元 / 月)横向对比。

在这一严格且统一的成本前提下,作为外部验证,火山 Milvus 与开源 VectorDBBench 工具 相同测试场景下已有的第三方测试结果进行了对比。截止至 2026 年 6 月 17 日,火山 Milvus 在保持高 Recall 的前提下,QPS 达到当前 VectorDBBench 榜首成绩的近 3 倍。换言之,在相同资源投入下,火山 Milvus 能够释放更高检索吞吐,将单位资源的向量检索产出提升至接近 3 倍。 硬件涨价周期下可大幅降低部署成本。对于需要持续扩容 RAG、推荐或多模态检索服务的业务来说,这类单位成本吞吐能力,会直接影响整体基础设施投入。

注:图中 Milvus-VolcanoEngine-force_merge-v20260615 表示火山 Milvus 当前版本,其余均为开源 VectorDBBench 工具已有结果

真正的性价比,来自这些指标在同一套资源约束下同时成立。

如上图所示,本次测试中 QPS、召回率、导入耗时与查询延迟结果:火山 Milvus 在线查询链路使用 59C 资源,取得 Recall 93.9%、QPS 20420、p99 延迟 2.7ms、平均延迟 2.5ms、导入时间约 4515s 的结果。

对在线服务而言,QPS 决定单位资源能够承载多少请求,p99 决定用户体验和系统稳定性,Recall 决定检索质量,导入效率则影响大规模数据更新和业务迭代成本。

算法再突破:

RaBitQ + DiskANN 提升检索效率

内存版 DiskANN:释放高性能图搜索能力

很多人会认为 DiskANN 是一种低查询性能的"磁盘型索引",但事实并非如此,开源 DiskANN 3 支持两种模式:追求极致检索性能的的内存模式,以及适配超大规模、低内存占用场景的磁盘模式。

在火山 Milvus 的实现中,DiskANN 同样支持内存版和磁盘版两种形态:

  • 内存版 DiskANN:将检索所需数据加载到内存中,图搜索过程中直接从内存读取,更适合对吞吐和延迟要求较高的性能场景。我们本次性能测试使用的也是高性能内存版 DiskANN。
  • 磁盘版 DiskANN:延续经典 DiskANN 的 On-Disk 设计,以更低内存占用支撑更大规模数据,图搜索过程中按需从磁盘读取。

这一区分非常重要。DiskANN 的核心价值并不只是"把数据放到磁盘上",而是通过图索引结构、候选扩展策略和数据布局设计,在不同资源约束下实现高效近似最近邻搜索。对于在线高性能场景,内存版 DiskANN 可以充分利用 CPU 与内存访问能力,将图搜索效率释放到更高水平。

Extended-RaBitQ:在压缩率与召回精度之间取得平衡

RaBitQ 是当前先进的向量搜索量化算法之一,火山 Milvus 上线初期便完成工程落地,并搭配 DiskANN,用于提升大规模向量检索场景下的性能与成本效率。

随后,RaBitQ 作者推出 Extended-RaBitQ 算法 1,作为 RaBitQ 多比特量化扩展方案。相比 1-bit RaBitQ 追求极致压缩,Extended-RaBitQ 允许每一维使用更丰富的量化表示,在保持低存储成本的同时,进一步提升向量距离估计的精度。

它的核心价值,是延续 RaBitQ 基于高维几何的量化思想,让压缩后的向量表示更贴近原始向量的方向与距离关系,从而在召回精度、存储成本和查询性能之间取得更好的平衡。

也就是说,Extended-RaBitQ 将 RaBitQ 从原先的 1-bit 二值量化扩展到 2-bit、3-bit、4-bit 等多 bit 场景,并在查询阶段保持与标量量化相近的计算形式。

在工程实现上,火山 Milvus 通过将 Extended-RaBitQ 与 DiskANN 相结合,使系统可以根据不同阶段的检索需求选择更合适的压缩粒度:

  • 在粗召回阶段,优先追求极致压缩与高速计算。
  • 在候选 refine 阶段,使用更高精度的量化表示,提升距离估计质量。

这样一来,系统无需完全依赖原始 float 向量,也能在较低存储成本下获得更稳定的召回效果和更好的 TopK 精度。

In-Memory Layout:让图搜索更贴近 CPU 访问模式

In-Memory 高性能向量检索场景下,火山 Milvus 进一步结合 RaBitQ 的紧凑量化表示,对内存版 DiskANN 的图搜索路径做了系统性优化。

内存版 DiskANN 在查询时会持续展开图邻居,并对候选点进行批量距离估计。这个过程中的热点并不只是距离计算本身,还包括从候选 id 到量化表示、候选元信息、邻接信息的整条访问路径。

基于这一特点,火山 Milvus 对 RaBitQ 表示、候选点信息和图遍历访问模式进行了协同优化,使查询线程在展开邻居和批量计算候选距离时,尽量访问连续、紧凑、CPU cache 友好的数据。

系统会优先读取轻量化的 RaBitQ 表示,并通过更适合批量计算的内存布局和计算路径,减少随机访存和无效数据加载。

这类优化并不改变 DiskANN + RaBitQ 的召回语义,但显著改善了数据到达 CPU 的方式。最终,在同样的 CPU 和内存预算下,查询链路可以把更多时间用于有效距离计算和图搜索推进,而不是等待内存访问,从而进一步提升内存版 DiskANN 的查询效率。

工程再优化:让高性能检索触手可及

查询链路瘦身:降低单次请求基础延迟

火山 Milvus 通过性能分析和链路追踪,对查询过程中的热点路径进行了精细梳理。除了关注整体吞吐,也重点分析单次查询在主链路上的耗时分布,定位可能拉长基础延迟的关键环节。

对于在线向量检索系统来说,吞吐能力固然重要,但单次查询延迟是否足够低,同样决定了系统服务质量。尤其是在固定资源预算下,如果每一次查询都包含额外的内存分配、数据拷贝或冗余计算,这些成本最终都会反映到延迟和单位资源吞吐上。

因此,本轮工程优化首先从查询链路本身入手,围绕 Search 关键路径减少不必要的内存分配、中间对象生成和冗余消耗,让一次查询以更短、更轻的路径完成。这样做的价值并不只是降低某个局部函数耗时,而是压低每一次请求的基础开销,为系统承载更高并发和更复杂负载留出空间。

这也是工程优化的核心价值之一:把算法能力稳定转化为线上服务能力,不只依赖更高的并发压测结果,更依赖每一次查询都足够轻、足够稳。

内存与运行时优化:提升图搜索的硬件利用效率

在高性能向量检索场景中,图搜索不仅是计算密集型任务,也高度依赖内存访问效率。随着数据规模和并发压力提升,邻接关系、量化后的向量表示以及候选集信息会在查询过程中被频繁访问,访存效率会直接影响 CPU 的有效工作时间。

围绕这类特点,火山 Milvus 对热点大段连续内存进行了更精细的运行时管理,使图遍历和批量距离估计过程中访问最频繁的数据能够以更稳定、更高效的方式被 CPU 使用。对于邻接表、量化表示等核心数据结构,这类优化可以提升访存效率,降低页表查询带来的额外开销,让高并发查询下的尾延迟更加可控。

同时,火山 Milvus 也针对图遍历过程中的访存方式做了优化。查询线程在扩展候选点时,会更主动地为后续访问路径做好准备,减少 CPU 等待数据到达的时间。对于向量检索这种"图遍历 + 距离计算"交织的链路,这类优化能够让硬件能力更充分地释放出来。

这些工作不像算法升级那样容易被单独感知,但它们决定了性能上限能否稳定落到线上。在不改变检索语义的前提下,火山 Milvus 通过更轻的查询链路、更高效的内存访问和更稳定的图遍历执行,让同样的资源预算承载更高吞吐、更低尾延迟和更稳定的在线检索服务。

总结

火山 Milvus 这次在 VectorDBBench 性价比测试中的表现,是算法优化与系统工程能力共同作用的结果。从 RaBitQ 混合量化,到邻接表内存布局、定向大页、内存分配优化、Search 链路 copy 清理,再到编译工具链升级,所有优化都指向同一个目标:减少查询链路中的无效消耗,把同样的 CPU、内存和云资源转化为更高的业务吞吐。

这次结果换算到成本视角会更直观:在 AI 时代内存与磁盘持续涨价的大背景下,火山 Milvus 用 59C、约 7105 元/月的在线查询链路就实现了 QPS 20420,达到榜首近 3 倍。若要用榜单上其他方案达到同等 QPS 水平,往往需要成倍的内存与计算资源投入 ------ 这意味着在保持相同吞吐与召回的前提下,火山 Milvus 可将向量检索的资源与成本压缩至原来的约 1/3。当数据规模迈向百亿、千亿级,这一性价比差距会被进一步放大为每月数万乃至数十万元的真实成本节省。

榜单结果是一种外部验证,真正值得关注的是背后的成本效率提升路径。面对持续增长的向量数据规模,高吞吐、低延迟、高召回、高导入效率和高性价比,才是向量数据库在真实在线场景中的长期竞争力。

附录:测试与复现

测试配置

  • 数据集:1000 万 Cohere 数据集
  • 向量维度:768
  • 相似度度量:COSINE
  • TopK:100
  • Recall:93.9%
  • 客户端并发数:250
  • 客户端部署环境:火山引擎 ECS ecs.g4al.16xlarge
  • 资源约束:Milvus 在线查询链路总核数 59C,包月费用约 7105 元/月

集群规格

包月价格:7105 月/元

  • proxy:8C8G × 1
  • mixcoord:1C2G × 1
  • querynode:48C48G × 1
  • datanode:2C4G × 1
  • indexnode:池化,按需付费

测试结果

  • QPS:20420,在固定资源预算下显著提升单位资源吞吐
  • Latency:p99 延迟 2.7ms,平均延迟 2.5ms
  • 导入时间:约 4515s
  • Recall:93.9%
  • 综合开源 VectorDBBench 结果:QPS 排名第一,导入时间排名第二,p99 延迟并列第三,Recall 排名第四

复现说明

参考 Milvus 向量检索性能测试操作手册 。在固定数据集、固定 Recall 和固定延迟约束下,火山 Milvus 将 QPS 提升至 20420,同时将 p99 延迟稳定保持在 2.7ms。

这里复现的不只是一组榜单成绩,更是一条可量化的成本效率提升路径:用同样的在线资源承载更多查询,同时不牺牲召回质量和尾延迟稳定性。

参考资料

1 Jianyang Gao, Yutong Gou, Yuexuan Xu, Yongyi Yang, Cheng Long, Raymond Chi-Wing Wong, "Practical and Asymptotically Optimal Quantization of High-Dimensional Vectors in Euclidean Space for Approximate Nearest Neighbor Search", SIGMOD 2025, available at arxiv.org/abs/2409.09...

2 dev.to/gaoj0017/ex...

3 github.com/microsoft/D...

相关推荐
Sirius Wu1 小时前
OpenClaw 四层 Langfuse 全链路追踪完整详解
人工智能·ai·aigc
xywww1685 小时前
大模型 API 选型实战:GPT、Gemini、Claude 接入时该看哪些指标?
运维·服务器·人工智能·python·gpt·langchain
私人珍藏库10 小时前
[Android] PeakFinder AR v4.8.89 (山峰全景识别+增强现实山峰查看器)
android·人工智能·智能手机·ar·工具·软件
CS创新实验室10 小时前
算法、齿轮与硅基大脑:数值计算发展简史
人工智能·算法·数值计算
能有时光10 小时前
PyTorch KernelAgent 源码解读 ---(4)--- ExtractorAgent
人工智能·pytorch·python
fthux11 小时前
GitZip Pro 源码解析:一个 GitHub 文件/文件夹下载扩展是如何工作的(一)整体架构与扩展入口
人工智能·ai·开源·github·open source
aqi0011 小时前
15天学会AI应用开发(十七)使用LangGraph实现会话记忆功能
人工智能·python·大模型·ai编程·ai应用
xixixi7777712 小时前
三大 AI 安全里程碑:Akamai 高危风险预警、智能体水印强制落地、PQC 量子安全全产业链统一
大数据·人工智能·安全·ai·大模型·智能体·政策
AI小码12 小时前
LLM 应用的缓存工程:当每次 API 调用都在燃烧成本
java·人工智能·spring·计算机·llm·编程·api