Qdrant还是Milvus？内存压力会改变吞吐领先者

为RAG或语义搜索选开源向量数据库，如果单机内存足以容纳主要检索工作集，可以优先评估Qdrant；当内存成为硬约束，Milvus的压缩索引配置值得纳入测试。部署预计跨越单机容量时，还要考虑扩展方式和维护负担。这里的选择指向具体配置与业务负载，并非两款产品有固定的速度排名。

在VECTOR-ADIS单机基准中，同硬件的内存充裕档由Qdrant取得约1.5倍吞吐优势，接近内存上限时优势约为4.6倍且P95延迟约低14倍；超内存档则由Milvus IVF_SQ8达到407.8请求/秒，超过Qdrant mmap HNSW的144.1请求/秒，约为其2.8倍；另行汇总的常规内存测试中，两者Precision@10同为96.67%。最后一项精度数字不代表三个内存档位各自的召回率，已公布的三档摘要也无法组成一张同时列出每档吞吐、P95和Recall@K的完整表。

内存三档为什么会改变结果

内存充裕时，向量与索引较容易由内存服务，磁盘读取对查询的影响较小。在上述单机实验的这一档，Qdrant处理请求更快。数据接近内存限制后，双方仍由Qdrant领先，且尾部请求的延迟差距扩大；对交互式检索，P95能显示一部分平均值掩盖的慢请求。

超内存档的对手是Milvus IVF_SQ8与Qdrant mmap HNSW两套配置。IVF_SQ8使用量化后的向量表示；mmap HNSW通过内存映射访问落盘数据。向量表示、索引组织和访盘方式同时发生变化，因此吞吐反转只能归于这组配置在这一负载下的表现。换一批嵌入向量、调整搜索参数或改变存储设备，结果都可能不同。

容量判断也不能只看原始向量文件。索引、元数据、进程本身和操作系统缓存都会占用内存；名义上小于物理内存的数据集，运行时仍可能频繁触盘。对于持续写入的知识库，还要为新增向量、索引更新和后台整理留下余量。若只按向量维度乘以记录数估算，原本预计处于充裕档的服务，可能在上线后落入临界档。

三档摘要对P95和检索质量的披露范围并不相同：临界档提供P95的相对差距，常规内存测试提供Precision@10，而超内存档突出吞吐结果。Precision@10衡量前列结果的精度，Recall@K衡量目标近邻被找回的比例，两者不能互换。单凭超内存档的请求数，也无法判断两套索引在同一召回门槛下谁更合适。

架构差异对应哪些运维工作

Qdrant官方概览将系统描述为客户端—服务器架构：客户端经HTTP或gRPC访问服务，集合保存带向量和可选元数据的点，数据由段组织，分布式部署时集合再划分为分片。这让单机项目可以先围绕集合、索引和过滤字段规划，容量增长后再考虑分片与副本。Qdrant也提供把向量或HNSW索引放到磁盘上的选项，但索引遍历触盘时，存储速度会直接影响查询表现。

Milvus架构文档描述了分离的计算与存储层，以及访问代理、协调服务、流式节点、查询节点和数据节点；etcd承担元数据及服务注册工作，对象存储保存索引等文件，写前日志支持持久化。查询与写入任务可以交给不同角色处理，分布式部署因而具有分别扩展资源的空间。自建时，相应的服务、存储和故障路径也进入监控、备份与排障范围。

这两种组织方式影响的是项目长期要管理什么，不能直接换算成单机跑分。小型RAG服务若主要运行在一台机器上，组件数量、索引重建和备份恢复可能比集群扩容能力更早成为日常工作。已有对象存储与集群运维能力的团队，则更容易承接Milvus的分层部署。两款数据库都能用于单机检索；分布式架构的扩展潜力，不等于某个单机查询必然更快。

带过滤条件的检索如何比较

企业知识库中的相似度通常只是查询的一部分。租户、访问权限、文档类别或时间范围会先限定可返回的内容；过滤后剩下多少候选，决定了索引要完成的工作。只看没有过滤条件的吞吐数字，无法估计权限谓词加入后的P95，也看不出小范围筛选时召回是否变化。

Qdrant可为常用元数据字段建立payload索引，并将过滤条件纳入HNSW检索过程。字段是否建索引、索引何时建立，以及条件选择性，都会影响搜索路径和资源占用。若一个项目的大多数查询都带相同的租户或文档类型条件，这些字段应进入选型时的实际查询集合，而不是留到无过滤跑分结束后再讨论。

Milvus标量索引说明指出，标量布尔表达式会形成过滤执行计划，在数据段内产生位图，再以位图缩小向量检索范围；标量字段索引可加快过滤。两款产品都有结合属性与向量的办法，差别需要放在同一组权限规则、字段基数和命中比例中观察。大量租户各占很少记录，与少量租户各占大部分记录，会产生不同的候选规模；这是负载差异，不能据此预先指定赢家。

过滤也会改变质量指标的含义。如果正确答案所在的文档因权限规则被排除，检索系统本就不应返回它；评估用的正确答案集合必须遵守同样的过滤条件。否则，召回率下降可能只是测试口径不一致。对RAG项目，合适的比较对象是过滤后的候选、实际返回深度和用户能接受的尾延迟。

吞吐领先是否意味着回答更可靠

多数据集实证研究覆盖六个数据集、超过400万条向量；其默认配置测试中，Qdrant在SIFT1M取得数据库系统中领先的216 QPS，而Milvus在高维GIST1M取得0.971的Recall@100；SIFT1M上的浅层Recall@10难以显示较深候选列表出现的质量差异。该测试采用另一套硬件、数据和默认配置，并且没有把属性过滤纳入比较，不能与前述内存压力实验的数值拼接为统一排名。

RAG的返回深度取决于后续流程。直接把少量片段交给生成模型，与先取较多候选再重排，关心的Recall@K并不相同。目标文档没有进入候选列表，后续重排也无法将其找回；反过来，盲目扩大候选列表又可能增加检索及后处理时间。因此，吞吐、P95与召回率应在同一个K值和同一套过滤规则下并列观察。

索引参数同样参与这笔权衡。提高搜索范围可能改善近邻召回，却要支付更多计算或访盘成本；采用量化可以压缩表示，是否仍满足答案质量要求则取决于数据与查询。比较Qdrant和Milvus时，应固定嵌入模型、距离度量、语料版本及硬件内存上限，再分别调到业务可接受的召回门槛。此后比较速度，才不会把较低质量的结果误读为纯粹的性能收益。

按项目条件作出选择

数据规模可控、以单机服务为主，且查询经常依据文档属性过滤时，Qdrant是有依据的评估起点：上述实验在内存充裕和临界档显示出吞吐优势，其集合与payload索引也与这类负载直接相关。选择之前仍需核算索引和运行时余量，并用真实过滤条件观察P95。若服务长期处在内存边缘，初期测到的充裕档表现不能代表增长后的状态。

数据及索引预计超过单机可用内存，或项目已经准备管理分层存储与分布式节点时，Milvus更值得投入验证。超内存档的IVF_SQ8结果说明压缩索引有机会改变吞吐顺序，但上线配置还必须达到同一召回门槛，并承受实际过滤与写入负载。最终选择应记录索引类型、参数、内存限制和数据规模；这些条件一旦变化，比较对象也随之变化。