ES与Milvus二进制量化性能深度对比实测分析报告

做产品，讲究天时、地利、人和。放到技术圈里，也是一样的道理。你得顺应大势（天时），选对技术方向（地利），还得有把想法落地的执行力（人和）。在向量搜索这个领域，最近 Elasticsearch 就干了一件漂亮事，它没有随大流去堆硬件，而是快速落地了一个叫 BBQ 的算法，用技术和速度，上演了一场教科书式的“弯道超车”。

一、 内存暴涨5倍！为什么说 BBQ 是向量搜索的“救星”？

Agent 应用火得一塌糊涂，但搞开发的兄弟们心里都清楚一个尴尬的现实：向量搜索好用是好用，但真的太贵了。

向量搜索的“破产”边缘：内存与硬件的博弈

从 Facebook 开源 Faiss 开始，向量搜索技术已经演进好几年了。一直以来，大家主要都是基于 Faiss 的各种实现来干活。但大模型时代，数据量级蹭蹭往上涨，以前那种“堆硬件”的暴力美学，开始有点玩不转了。

挑战一：距离计算的算力黑洞

在高维向量搜索里，距离计算占了超过 90% 的开销。向量维度越高（比如 768 维、1536 维甚至更高），计算量就线性增长。要想提升 QPS 和吞吐量，首要任务就是把这个计算过程变得更快、更轻。

挑战二：令人咋舌的“内存税”

拿 OpenAI 的 text-embedding-3-small 模型来说，它输出的是 1536 维向量。存 100 万条数据：

• 每个向量由 1536 个 32 位浮点数构成。
• 光存这些原始向量，就得吃掉大约 6GB 内存。
• 再加上为了实现毫秒级检索，还得构建庞大的 HNSW 图索引。经验告诉我们，当数据量到了 1000 万，你得准备至少 40GB 内存，才能保证性能。

挑战三：硬件成本的“背刺”

更扎心的是，硬件环境也在变。这几年受 AI 算力挤兑影响，高性能服务器硬件成本涨得厉害。

• 内存价格倒挂：DDR5 从 2023 年底开始涨个不停，更离谱的是，本该退市的 DDR4 因为产能缩减，涨幅甚至一度超过 DDR5。
• 算力通胀：CPU 和 GPU 的价格也跟着全面上扬。

在当下的生产环境里，想全量跑 HNSW + Float32，几乎成了奢侈品。很多技术团队发现，为了支撑向量搜索，服务器成本远远超过了业务本身的收益，这显然是不可持续的。

二、 从 RaBitQ 到 Elastic BBQ

为了打破这个“性能与成本”的死锁，学术界一直在探索极致的量化方案。2024 年 5 月，南洋理工大学的团队在数据库顶会 SIGMOD 上发了一篇重磅论文，提出了一种叫 RaBitQ 的新型二值量化方法。它的核心思想就四个字：极限压缩。

RaBitQ 的技术魔力在哪里？

32 倍的极致压缩比： 它把 32 位的浮点数，直接压缩成 1 位的二进制数（0 或 1）。这意味着，内存占用直接缩减到原来的 1/32。

黑科技般的高精度： 通常来说，二值化会严重损失精度。但 RaBitQ 通过组合随机旋转、残差量化以及无偏估计器等数学策略，很好地保留了向量在高维空间里的相对位置关系。测试下来，它的精度甚至可以媲美压缩比低得多的 PQ 量化。

极佳的架构兼容性：

• 适配图索引： RaBitQ 能完美嵌入 HNSW 结构。Elasticsearch 的 BBQ 正是基于此，在 HNSW 索引上实现了 RaBitQ 算法。
• 适配倒排索引： RaBitQ 同样可以结合 IVF（倒排文件），Faiss 的 IVF RaBitQ 实现就是这一路线的代表。

三、 天下武功，唯快不破：Elasticsearch 的工程化奇迹

在软件工业界，从一篇论文到成为工业级产品特性，通常需要好几年。但 Elasticsearch 团队这次展现了他们一向高效的工程执行力。

Elastic BBQ 的诞生时间线：

• 2024.05：SIGMOD 论文发表，Elasticsearch 向量搜索团队第一时间关注并研读。
• 2024.06：内部开启原型验证，确认理论在 Lucene 架构下的可行性。
• 2024.08-09：进行复杂的工程化改造。不仅仅是算法实现，还涉及 SIMD 指令集优化、内存布局调整等底层工作。
• 2024.10：代码贡献合并入核心引擎 Apache Lucene。
• 2024.11：产品正式上线！Elasticsearch 8.16 版本正式推出 BBQ（Better Binary Quantization）。

这一连串动作，只用了不到半年时间。作为对比，Faiss 直到 2025 年 4 月才推出 IVF RaBitQ，Milvus 5 月才推出，比 Elastic 团队慢了整整半年。

在实现路径上，也有不同：

• Faiss： 倾向于 IVF + RaBitQ。IVF 结构简单，构建速度快，但在高召回率要求下，由于受限于聚类中心的划分，往往需要扫描更多的簇，性能衰减明显。
• Elasticsearch BBQ： 选择了 HNSW + BBQ。这是一个“强强联合”的方案：HNSW 提供了目前业界最强的导航能力和召回率稳定性；而 BBQ 把 HNSW 最被人诟病的内存占用问题解决了 95%。最关键的是，利用 Hamming 距离进行位运算，在现代 CPU 上比浮点数乘加运算快得多。

四、 实测数据：BBQ 到底有多猛？

我们直接拿了 Milvus 团队开发的 VectorDB Benchmark 来跑个分。虽然这个 Benchmark 局限性不小，很难反映现在普遍采用的混合搜索场景，但做纯向量性能的基础参考，还是够用的。

测试环境与方法论：

• 硬件环境： AWS 虚拟机，选了老中新三代机型：M6a（Zen3 + DDR4，不支持 A VX512）、M7a（Zen4 + DDR5，支持半血 A VX512）、M8a（最新的 Zen5，满血 A VX512）。统一采用 4xlarge 规格，16 vCPU，64GB 内存。
• 软件环境： Ubuntu Server 24.04 LTS，Docker 启动单节点 ES 9.2.4，Docker Compose 启动 Milvus 2.6.9。
• 压测软件： vectordbbench，修改了 Elastic Cloud 代码适配自建 ES。
• 数据集： Cohere 100 万条 768 维向量，这是目前 RAG 场景中非常典型的中高维数据。
• 核心指标： QPS（每秒查询数）与 Recall（召回率）曲线。

一个需要注意的技术细节：Segment 数量对齐

这是目前网上做向量性能测试经常忽略的一个细节，容易造成不公平的对比。在默认配置下，Elasticsearch 导入 100 万数据后生成的 Segment 数量远高于 Milvus。每个 Segment 本质上都是一个独立的 HNSW 小图，查询时需要遍历所有小图并合并结果。而 Milvus 通常会生成较大的 Segment。为了保证测试的严谨性，我们调整了 ES 的 Force Merge 策略，把 Elasticsearch 的 Segment 强制合并为 6 个，与 Milvus 的 Segment 数量保持一致。

测试结果：

测试 1：M6a 4xlarge 单节点对比

在老的 M6a 平台（缺乏 A VX512 指令）上，BBQ 比 Milvus IVF RaBitQ 最好性能高出 75%～85%。

测试 2：M7a 4xlarge 单节点对比

在主流硬件平台 M7a 上，BBQ 比 Milvus IVF RaBitQ 最好性能高出 45%～50%。

结合上面两个平台，可以发现 BBQ 对老硬件，特别是那些不支持 A VX512 指令的 CPU，更加友好。用较弱的硬件都能跑出不错的成绩，而 Milvus 则更依赖硬件算力。

测试 3：M6a、M7a、M8a 三平台对比

结合三代平台一起看，BBQ 几乎是“越级碾压”。旧平台（M7a）上的 BBQ 性能，就能超越 Milvus 在新平台（M8a）上的 IVF RaBitQ 性能。更夸张的是，BBQ 在 M6a 平台上的性能，甚至可以超越 Milvus IVF RaBitQ 在 M7a 平台上的性能 15%～25%。

测试 4：M6a、M7a、M8a 三平台，BBQ 与 Milvus HNSW Float32 对比

ES BBQ 的性能也大幅度超越 Milvus HNSW FP32，而且节省了大量内存。从图中可以看出，Milvus 对算力依赖非常严重，老平台 M6a 因为缺乏 A VX512 指令，性能低得可怜，BBQ 的性能几乎是它的 3-4 倍。

五、 总结

Elasticsearch BBQ 的出现，标志着向量搜索从“暴力堆硬件”的时代，正式迈入了“算法换成本”的精细化运营时代。

• 如果你正为每个月高昂的云主机账单发愁；
• 如果你受限于老旧的硬件环境，没有 DDR5 内存，无法支持 A VX512 指令；
• 或者你只是单纯想体验“榨干 CPU 每一个比特”的技术快感；

那么，Elasticsearch 8.16 的 BBQ 算法，就是你目前能找到的最优解。这不仅是一次算法的升级，更是 Elastic 团队对技术趋势精准预判和超强执行力的完美注脚。

详细测试数据可访问这个在线文档【腾讯文档】ES BBQ vs Milvus IVF RabitQ and HNSW FP32