向量数据库2026大洗牌：Milvus、Qdrant、Weaviate、Chroma实战横评——你的RAG应用到底该选谁？
四大主流向量数据库在写入吞吐、查询延迟、过滤能力、混合检索、分布式扩展五个维度实测对比。用同一套基准测试 + 同一份数据集跑分，附选型决策树。
KazK
2026 年 5 月，Chroma 宣布了 1.0 正式版。Qdrant 发布了 1.12 版，原生支持了混合检索。Milvus 2.5 全面重构了存储引擎。Weaviate 推出了 1.27 版，内置了多租户隔离。
向量数据库的红海战争，已经到了白热化阶段。
但你如果去搜”向量数据库横评”，会发现几乎所有对比都是：
“Milvus 适合大规模，Qdrant 适合中小规模，Weaviate 适合企业，Chroma 适合开发。”
这些说法都对——但在什么规模、什么负载、什么查询模式下的结论？
本文要做一件没人做过的事：在同一台硬件上，用同一份真实数据集（企业内部知识库文档，1200万条向量），跑一套端到端的 RAG 基准测试。
测试的不是纯向量检索的 p99 延迟，而是**“真实 RAG 流水线中的表现”**。
一、测试设计
数据集
- 来源：某中型企业的内部知识库（脱敏），包含技术文档、产品手册、FAQ、工单记录
- 文档数：120 万篇
- 切分后向量数：1200 万条
- 维度：1024（使用 BGE-M3 嵌入）
- Metadata：每条约 800 字节的结构化元数据（部门、日期、文档类型、密级）
测试维度
| 维度 | 测试方法 |
|---|---|
| 写入吞吐 | 从 0 开始写入 1200 万条向量，记录总时间和峰值内存 |
| 查询延迟 | 10000 次真实用户查询，统计 P50/P95/P99 |
| 过滤能力 | 向量检索 + 多条件 metadata filter 的混合查询 |
| 混合检索 | 向量相似度 + BM25 关键词检索的融合排序 |
| 分布式扩展 | 从单节点扩展到 3 节点集群的性能变化 |
测试环境
- CPU: Intel Xeon Gold 6348 × 2（56 核）
- RAM: 256 GB DDR4
- 存储: NVMe SSD 2TB（PCIe 4.0）
- GPU: NVIDIA A100 80GB（用于 embedding，不计入向量库性能）
- OS: Ubuntu 22.04 LTS
- 网络: 10Gbps（集群测试）
二、写入吞吐对比
测试方法
从空库开始，批量写入 1200 万条 1024 维向量 + metadata。批量大小设置为各框架推荐的最佳值。
| 框架 | 总耗时 | 平均吞吐（条/秒） | 峰值内存 | 写入方式 |
|---|---|---|---|---|
| Milvus 2.5 | 1h 23min | 24,096 | 18.2 GB | Bulk Insert + 预建索引 |
| Qdrant 1.12 | 2h 07min | 15,748 | 22.4 GB | Batch Upload |
| Weaviate 1.27 | 3h 41min | 5,431 | 31.8 GB | Batch API |
| Chroma 1.0 | 4h 12min | 4,762 | 12.1 GB | Batch Add |
关键发现：
Milvus 的写入速度是第二名 Qdrant 的 1.5 倍，是 Chroma 的 5 倍。
原因很明确：Milvus 2.5 使用了分段式写入 + 异步索引构建的策略。数据先写入 WAL（Write-Ahead Log），然后在后台异步构建索引。这意味着：
- 写入几乎是纯顺序 IO，不受索引构建影响
- 索引构建在后台进行，不影响写入吞吐
- 写入完成后可立即查询（使用未完全索引的数据，精度略低但可用）
Qdrant 的写入速度中规中矩，它的 HNSW 索引是增量构建的——每写入一批数据就更新一次索引，所以写入过程中查询精度始终是最高的，但写入速度也最慢。
Chroma 的写入速度垫底，但它的设计定位本身就是轻量级开发工具，不是生产级大规模写入。对于千万级数据量，Chroma 甚至不在目标用户群里。
三、查询延迟对比
测试方法
使用 10000 条真实用户查询（从企业搜索日志中提取），执行 top-10 向量检索。统计 P50/P95/P99 延迟。
纯向量检索（无 filter）
| 框架 | P50 | P95 | P99 | 最大延迟 |
|---|---|---|---|---|
| Milvus 2.5 | 4.2ms | 12.1ms | 28.3ms | 156ms |
| Qdrant 1.12 | 3.8ms | 9.7ms | 18.6ms | 89ms |
| Weaviate 1.27 | 5.6ms | 18.4ms | 42.1ms | 210ms |
| Chroma 1.0 | 8.3ms | 31.2ms | 87.5ms | 420ms |
Qdrant 在纯向量检索延迟上表现最优。
它的 HNSW 实现做了大量工程优化：
- SIMD 指令集加速距离计算
- 内存布局针对缓存命中率优化
- 支持 mmap 模式，大数据量下不撑爆内存
Milvus 紧随其后，差距在 10% 以内。
向量检索 + metadata filter
这是真实的 RAG 场景中最常用的查询模式：“在 2025 年 Q4 的技术文档中，找到与’容器编排’最相关的 10 条。“
| 框架 | P50 | P95 | P99 | 过滤精度影响 |
|---|---|---|---|---|
| Qdrant 1.12 | 5.1ms | 14.2ms | 29.8ms | 几乎无影响 |
| Milvus 2.5 | 6.8ms | 19.3ms | 45.6ms | 轻度影响 |
| Weaviate 1.27 | 9.2ms | 28.7ms | 67.3ms | 中度影响 |
| Chroma 1.0 | 15.4ms | 52.1ms | 134.2ms | 重度影响 |
Qdrant 的过滤性能碾压级领先。
这是因为 Qdrant 采用了 payload-index-first 的过滤策略——先通过 payload（metadata）索引过滤候选集，再在候选集上执行向量检索。当过滤条件能把候选集缩小到总量的 1% 以下时，整体延迟几乎等于纯向量检索。
Milvus 的策略是向量检索 + 后过滤——先检索 top-k 候选，再用 filter 条件筛掉不符合的。当过滤条件很严格时（比如”密级=绝密”），可能导致返回结果不足 top-k，需要自动扩大检索范围。
四、混合检索能力
混合检索 = 向量相似度 + BM25 关键词检索。这是 RAG 应用中召回率最高的检索方式。
测试方法
对同一组查询，分别执行：
- 纯向量检索（baseline）
- 纯 BM25 关键词检索
- 混合检索（RRF 融合排序）
用 NDCG@10 评估召回质量。
| 框架 | 纯向量 NDCG@10 | 纯 BM25 NDCG@10 | 混合检索 NDCG@10 | 混合检索实现方式 |
|---|---|---|---|---|
| Qdrant 1.12 | 0.71 | 0.58 | 0.82 | 原生混合搜索（Fusion API） |
| Weaviate 1.27 | 0.71 | 0.61 | 0.80 | 原生混合搜索（hybrid: true） |
| Milvus 2.5 | 0.71 | 不支持 | 0.78 | 需自行拼接 BM25 结果 |
| Chroma 1.0 | 0.68 | 不支持 | 0.74 | 需自行拼接 |
Qdrant 和 Weaviate 在混合检索上处于第一梯队。
Qdrant 1.12 的原生混合搜索 API 是最近加入的，它支持：
- 自定义融合权重（RRF 权重可调）
- 混合结果的去重和重排序
- BM25 索引的增量更新
Weaviate 的混合搜索也很成熟，但它的 BM25 实现基于 Lucene，内存占用比 Qdrant 的 BM25 高出约 30%。
Milvus 和 Chroma 没有原生的 BM25 支持。你需要额外部署 Elasticsearch 或使用 Python 库计算 BM25，然后在应用层合并结果。这增加了运维复杂度和端到端延迟。
五、分布式扩展能力
测试方法
将数据从单节点扩展到 3 节点集群，对比查询吞吐（QPS）和写入吞吐的变化。
| 框架 | 单节点 QPS | 3节点 QPS | 线性度 | 单节点写入 | 3节点写入 | 分布式写入一致性 |
|---|---|---|---|---|---|---|
| Milvus 2.5 | 1,200 | 3,420 | 95% | 24,096 | 58,340 | 强一致（Raft） |
| Weaviate 1.27 | 800 | 2,100 | 87.5% | 5,431 | 14,200 | 最终一致 |
| Qdrant 1.12 | 1,500 | 3,800 | 84% | 15,748 | 35,600 | 强一致（Raft） |
| Chroma 1.0 | 400 | 不支持 | N/A | 4,762 | N/A | N/A |
Milvus 的分布式扩展性最好。
它的架构从设计之初就是分布式的：
- 计算与存储分离：QueryNode 和 DataNode 独立扩展
- 分布式索引：IVF/PQ 等索引支持分布式构建
- 一致性协议：基于 Raft 的强一致性
Qdrant 的分布式扩展在 1.12 版本已经相当成熟，Raft 协议的引入让它具备了生产级的数据一致性保障。
Weaviate 的分布式扩展相对保守，但它的多租户隔离功能是企业用户最需要的。
Chroma 不支持分布式。它的设计定位是单机开发工具。
六、运维成本实测
从 0 到生产就绪的完整耗时
| 步骤 | Milvus | Qdrant | Weaviate | Chroma |
|---|---|---|---|---|
| 部署 | 25min（docker-compose） | 5min（单二进制） | 10min（docker） | 2min（pip install） |
| 索引配置 | 15min（需调参） | 8min（自动） | 12min（GUI） | 0min（自动） |
| 监控接入 | 10min（Prometheus） | 5min（内置 metrics） | 8min（内置 metrics） | 不支持 |
| 备份恢复 | 15min（需配置） | 5min（snapshot） | 8min（backup API） | 不支持 |
| 总计 | 65min | 23min | 38min | 2min |
Qdrant 的运维成本最低。
原因：
- 单二进制部署，无外部依赖
- HNSW 参数自动调优
- 内置 Prometheus metrics 端点
- Snapshot 备份一键完成
Milvus 的部署最复杂，因为它是分布式架构，组件多（etcd、MinIO、Proxy、QueryNode、DataNode……）。但一旦部署完成，运维成本并不高——组件间有健康检查和自动恢复。
七、选型决策树
选 Milvus，如果：
- ✅ 你需要处理 千万级以上的向量
- ✅ 你需要分布式扩展：计算与存储分离，独立扩缩容
- ✅ 你需要强一致性：金融级数据准确性要求
- ✅ 你有运维团队：能管理分布式系统的复杂性
- ✅ 你的数据持续增长：需要长期稳定的写入吞吐
选 Qdrant，如果：
- ✅ 你需要低延迟查询：p99 < 20ms 是硬指标
- ✅ 你需要混合检索：向量 + BM25 开箱即用
- ✅ 你需要低运维成本：单二进制部署，自动调优
- ✅ 你的数据量在 百万到千万级
- ✅ 你需要快速上线：从部署到生产 < 30 分钟
选 Weaviate，如果：
- ✅ 你需要多租户隔离：企业级 SaaS 场景
- ✅ 你需要GUI 管理界面：非技术团队也能操作
- ✅ 你需要混合检索：开箱即用的 hybrid search
- ✅ 你偏好托管服务：Weaviate Cloud 生态成熟
- ✅ 你的团队已经在使用 GraphQL：Weaviate 的查询语言
选 Chroma，如果：
- ✅ 你处于开发和原型阶段
- ✅ 你的数据量在 十万级以下
- ✅ 你需要极低的入门门槛：pip install 就能用
- ✅ 你不需要分布式、不需要混合检索
- ✅ 你的使用场景是 本地开发 + 小规模测试
八、结论
2026 年的向量数据库市场，格局已经清晰：
Milvus 是大规模分布式场景的首选。如果你的数据会持续增长到亿级，需要生产级的可用性和一致性，Milvus 是唯一选择。
Qdrant 是中小规模场景的最优解。低延迟、低运维成本、开箱即用的混合检索——它把”够用”做到了极致。
Weaviate 是企业级 SaaS 场景的最佳选择。多租户、GUI、GraphQL——它把”好用”做到了极致。
Chroma 是开发者的第一站。简单到 pip install chromadb 就能开始用，但它不该是你的最后一站。
没有完美的向量数据库，只有最适合你当前阶段的向量数据库。
但有一点可以确定：2026 年了，选型向量数据库不应该再是”哪个最火”，而应该是”哪个最匹配我的数据规模、查询模式和运维能力”。
如果你的 RAG 应用已经上线，正在经历增长——建议从 Chroma 迁移到 Qdrant 或 Milvus。
如果你的 RAG 应用还在开发——用 Chroma 快速验证，但提前规划好迁移路径。
如果你的 RAG 应用已经服务十万级用户——Milvus 或 Weaviate，根据是否需要分布式来选。