向量数据库做RAG，用Qdrant还是Milvus？生产环境哪个更稳？

我们组之前调研过一轮，最后选了Qdrant。主要是运维省心，etcd那套真不是小团队玩的，Milvus光排障就够喝一壶。但你这数据量，Qdrant记得提前规划好分片，768维下内存占用会比想象高，最好压测下实际吞吐再定节点数。

Milvus胜在功能全，比如批量过滤和复杂索引策略，如果后续要上混合检索可能更顺。不过延迟这块，两者在500ms内都问题不大，关键看你的过滤条件多不多，Qdrant在简单向量检索上反而更利索。

我们线上跑了几百万向量，Qdrant的HNSW索引构建时间还可以接受，但内存是真吃紧，建议上32G起步的机器。你最好拿自己的数据跑个benchmark，别光看文档。

我们团队也纠结过这个，最后选了Qdrant。几百万条768维向量其实不算大，Qdrant扛得住，内存控制比Milvus好不少，我们16C32G的机器跑得挺稳。Milvus那套etcd加对象存储，小团队运维确实费劲，光排障就要多花时间。延迟方面Qdrant实测p99能压在200ms内，索引构建也快，分片按payload直接路由就行，不用像Milvus那样得提前规划好集群拓扑。

我们团队Qdrant跑了一年了，几百万向量很稳，内存别抠搜就行，运维省心太多。

这需求Milvus有点杀鸡用牛刀了，Qdrant单机扛几百万向量问题不大，运维省心太多。

我们之前也纠结过，最后上了Qdrant，500ms延迟稳得很，分片策略记得按文档ID哈希就行。

我们组之前在类似项目上对比过这两个，最后留了Qdrant。Milvus功能确实全，但你们小团队运维的话，etcd加对象存储那套配置和监控就够喝一壶的，尤其版本升级时各种依赖兼容问题特别耗时间。Qdrant单机部署起步，Rust的内存管理在同样数据量下比Milvus省不少，我们当时测300万条768维数据，Qdrant内存峰值大概在8GB左右，索引构建速度也快一倍多。延迟方面，Qdrant在500ms内完全没问题，前提是别把分片数设太多，我们踩过坑，分片超过4个后查询抖动明显。不过要说稳，Milvus在数据一致性上更成熟，Qdrant某些极端情况下写入后立即查询会有短暂不一致，如果你们的文档更新频繁，这点得做补偿逻辑。另外提醒下，Qdrant的过滤条件如果带复杂metadata查询，性能下降比Milvus快，建议把常用过滤字段提前冗余到payload里。你们这个量级，我倾向Qdrant，先跑半年看监控，真要扩容再上集群也不迟。

我们团队去年从faiss迁到Qdrant，跑了快一年，几百万量级真没遇到瓶颈，Rust那套资源占用确实香，单机就能扛住。Milvus我们当时也测过，功能确实全，但etcd和对象存储那套依赖对两三个人的运维组来说太折腾了，光是调优就得花不少精力。延迟这块Qdrant在500ms内很稳，索引构建用HNSW的话内存得给够，但比Milvus省心多了。分片策略其实不用太早纠结，先单节点跑起来，后面数据涨了再开分片也不迟，我们就是这么干的。

我们组之前在K8s上跑过Milvus，etcd和对象存储确实费运维精力，但胜在分片和索引策略可控，几百万向量小case。Qdrant单机部署很爽，内存控制比Milvus好，但分布式要自己搭，官方文档案例不多。延迟500ms内两个都行，关键看你们后续要不要做复杂过滤或混合检索，Milvus的filter能力更强。建议先拿真实数据各压测一轮，看索引构建速度和内存峰值，别光看官网benchmark。

我们生产环境用的Qdrant，团队就俩人，实在没精力伺候etcd那套。几百万768维向量，16G内存跑得挺稳，索引构建比Milvus快不少。不过我们数据增长慢，分片策略基本没动过。你要是担心扩展，可以关注下Qdrant的集群方案，现在也成熟了。Milvus功能确实全，但小团队真不建议碰，光调参就够喝一壶。

说实话你这数据量两个都够用，重点看运维成本和查询复杂度。我朋友在Qdrant上跑过类似项目，延迟很稳，但后来要加标量过滤就有点吃力，得自己搞payload索引。Milvus虽然重，但自带etcd和对象存储，出了问题社区资料多。你们要是没人专门维护基础设施，我倾向Qd

我们团队用Qdrant跑过类似量级，内存控制确实好，但分片后延迟波动明显，建议先压测再上。

Milvus部署重是重，但etcd和对象存储反而让扩展省心，小团队运维其实能接受。

小团队就别硬上Milvus了，etcd和对象存储够你喝一壶的，Qdrant单机扛几百万向量稳稳的。

我们线上Qdrant跑过800万条768维，内存控制在20G内，500ms绰绰有余，分片用默认就行。

几百万条768维Qdrant完全够用，运维也省心；Milvus那堆依赖小团队真扛不住，除非你们有专职运维。

几百万条768维这个量级其实两家都能扛，关键看你们运维人手。Milvus功能确实全，但etcd加MinIO那套依赖在小团队里出过问题排查起来挺头疼的，我们之前就吃过亏。Qdrant单机部署是真省心，内存映射做得不错，索引构建比想象中快，不过分片和水平扩展得提前想清楚。真要图稳，建议先拿Qdrant跑个POC，压测一下你们真实查询的P99延迟再决定。

几百万条768维，Qdrant单机绰绰有余，Milvus那套etcd加对象存储小团队真养不起。

我们线上用Qdrant跑了快一年，数据量跟你们差不多，单节点内存占了大概30G，索引构建几百万条大概十几分钟。Milvus确实重，etcd和MinIO那套小团队维护起来挺烦的，但你要是以后想上分布式和存算分离，它扩展性更好。Qdrant的HNSW参数调好了延迟很稳，500ms绰绰有余，不过分片这块它比Milvus弱一些，提前规划好collection设计就行。

我们线上跑的Qdrant，数据量跟你差不多，也是768维几百万级别，延迟基本稳在几十毫秒，比500ms的预算宽裕很多。它单机部署确实省心，不用额外维护etcd那套，小团队上手快。不过内存这块得注意，Qdrant默认会把向量尽量放内存里，几百万条768维大概要几十G，你要是想省内存得开on-disk或者量化，但量化会牺牲一点召回。Milvus功能确实更全，分片和水平扩展做得成熟，可它那套依赖真不是小团队随便玩的，etcd、MinIO、Pulsar一堆组件，出问题排查链路长。我的建议是QPS不高就先上Qdrant，等真到瓶颈再考虑迁移，别一上来给自己找运维负担。索引构建Qdrant用HNSW也还行，几百万条几十分钟能搞定，具体看你参数调优。

我们线上用Qdrant跑了小半年，数据量跟你差不多，单节点内存占用比Milvus友好不少，索引构建几百万条大概十几分钟能搞定，延迟也稳。Milvus功能确实全，但那套etcd加对象存储的依赖，小团队维护起来真挺折腾的，没专职运维慎碰。不过Qdrant分片和横向扩展相对弱一些，你们要是预期数据量还会猛涨，可以先用Qdrant顶着，等真到瓶颈再迁移也不迟。