Turbopuffer vs Qdrant：RAG 混合检索、自部署与成本怎么选

Turbopuffer 和 Qdrant 都能把语义检索与关键词信号结合。区别在于控制权与运维方式：Turbopuffer 面向商业托管、对象存储原生的大规模检索；Qdrant 可自管，也可用 Cloud，并提供可组合的 Query API。不要把 Qdrant 写成“只能向量搜索”，它的 dense、sparse 和 RRF 混合查询有正式文档。

简短结论

需要自己控制部署、测试开源技术栈，或在已有基础设施中细调索引与查询时，先试 Qdrant。要让大量租户的检索数据增长，同时愿意接受托管商业服务和每月最低用量，试 Turbopuffer。任何一方都应通过相同查询集验证答案质量、权限和尾延迟。

混合检索路径

Turbopuffer 可对同一 namespace 跑向量与 BM25 查询，再用 RRF 融合候选，或者在应用侧自定义排序。官方强调它是第一阶段检索层，后续重排由应用负责。Qdrant Query API 可通过 prefetch 先抓 dense 与 sparse 候选，再用 RRF 或 DBSF 融合；也能串联多阶段查询。两者的共同点是先扩大召回，再控制最终排序，而不是把 embedding 相似度当成最终答案。

Turbopuffer 的长处与取舍

对象存储原生设计和 namespace 更适合验证大量租户及海量文档的成本曲线。官方提供托管多租户，企业方案可以询问单租户或 BYOC。需要注意的是，它目前没有免费档或开源版，Launch 每月最低用量 16 美元。写入提交和偶发冷查询是设计取舍；高频交互场景必须测试 p99。

Turbopuffer 不内建逐文档 RBAC。团队必须在服务端以认证信息生成过滤条件，并保证向量和 BM25 两条分支一致应用过滤。把权限当作 LLM 提示语是不够的。

Qdrant 的长处与取舍

Qdrant 适合需要本地开发、私有部署或开源路线的团队，也有托管 Cloud。Query API 的 prefetch 与 RRF 让 dense 和 sparse 信号在同一次查询中融合。自管时要负责磁盘容量、备份、高可用、升级及警报；这部分成本不能被“软件免费”四个字抹掉。若目标只是快速试点，先确认云服务或单机部署哪条路更省时间。

费用和性能如何比

对 Turbopuffer，按最低用量、存储、读写、查询和附加功能估算；对 Qdrant，自管方案按服务器、运维人力和备份算，Cloud 按当前官网计划及集群配置算。相同查询数量不等于相同成本，因为分块大小、索引设置、过滤复杂度和租户数量都会影响资源消耗。

试点检查表

1. 保持同一批文档、切块与 embedding 模型，只替换检索后端。
2. 准备包含术语、型号、模糊提问和越权尝试的真实问题集。
3. 比较纯 dense、纯 BM25/sparse、混合融合的 Recall@10 和 NDCG；找出每种方法漏掉的标准答案。
4. 在热缓存和冷缓存下分开测 p95/p99，模拟集中写入后的可见时间。
5. 计算满足答案质量与权限要求的每千次有效查询成本，再决定使用托管、Cloud 或自管路线。

资料：Turbopuffer 混合检索、Turbopuffer 权限、Turbopuffer 价格、Qdrant Hybrid Queries。