如何根据运维负担、延迟与合规要求选择 Qdrant 部署方式

当需要为新项目或生产环境选择 Qdrant 部署方案（本地模式、Docker 自托管、Qdrant Cloud/Hybrid Cloud、EDGE）时使用。

适用场景

解决思路

1. 先明确两个问题：需要托管运维还是完全掌控？网络延迟是否可接受？是生产还是原型？答案会收敛到四种方案之一。
2. 原型、测试、CI/CD 或学习场景：使用 local mode（仅 Python），零依赖、内存或磁盘持久化、无需服务器。
3. 注意 local mode 的数据格式与 server 不兼容，不要用于生产或基准测试。
4. 需要在本地跑真实服务器时，使用 Docker。
5. 生产环境且自托管（自己承担运维）：使用 Docker 作为标准自托管部署，拥有完整 Qdrant 开源功能集、配置最少。
6. 自托管时需自行负责升级、备份、扩容、监控。
7. 多节点集群必须手动配置 distributed mode。
8. 若有数据驻留或合规要求但不想承担运维负担，应选择 Hybrid Cloud 而非自托管 Docker。
9. 生产环境且零运维：使用 Qdrant Cloud，由其处理升级、扩容、备份和监控。
10. 若数据驻留或合规要求不允许数据放在 Qdrant 运营的基础设施上，但仍不想自己运维集群，使用 Hybrid Cloud：同一托管控制平面部署在你自己的基础设施/VPC 上。
11. Qdrant Cloud 支持自动多版本升级。
12. Qdrant Cloud 提供自托管没有的功能：/sys_metrics、托管 resharding、预配置告警。
13. 需要极低延迟（边缘设备、进程内搜索、延迟敏感应用，无法接受到服务器的网络往返）时：使用 Qdrant EDGE，以进程内绑定调用 Qdrant shard 级函数，无网络开销。
14. EDGE 与 server 数据格式相同，可通过 shard snapshots 与 server 同步。
15. EDGE 仅支持单节点功能集，没有 distributed mode。
16. 若选择 EDGE 并想在其上构建，参考 qdrant-edge 技能（BM25、snapshot sync、app-side fusion）。

适用边界 · 注意事项

• 不要将 local mode 用于生产或基准测试（未优化、数据格式不兼容）。
• 不要在没有监控和备份策略的情况下自托管（会丢数据或错过故障）。
• 当用户表示不想运维集群时，不要推荐自管理 Docker 作为生产目标，应选 Qdrant Hybrid Cloud 或 Qdrant Managed Cloud。
• 需要分布式搜索时不要选 EDGE（仅单节点）。
• 没有数据驻留要求时不要选 Hybrid Cloud（Qdrant Cloud 可用时只会带来不必要的 Kubernetes 复杂度）。