Qdrant：Rust 写的高性能向量数据库，亿级向量毫秒检索
📖 简介
📝 详细介绍
Qdrant 部署实测：亿级向量毫秒检索，字面意义上的快
结论先行
值得自建，尤其是如果你对延迟敏感且工作负载稳定。 Qdrant 是我目前测过的向量数据库里，运维成本和性能平衡得最好的一个。如果你受够了 Milvus 的复杂依赖或者 ES 的暴力扫描，Qdrant 会给你惊喜。
1. 部署过程
环境：腾讯云 CVM，4C8G，Debian 12，SSD 云硬盘。
直接用 Docker 跑的，镜像约 200MB，拉取耗时 1 分 20 秒。
安装 & 启动
# 单机模式，持久化挂载
docker run -d --name qdrant
-p 6333:6333 -p 6334:6334
-v $(pwd)/qdrant_storage:/qdrant/storage
qdrant/qdrant:v1.9.0
# 实际输出
# Unable to find image 'qdrant/qdrant:v1.9.0' locally
# v1.9.0: Pulling from qdrant/qdrant
# 4abcf2066143: Pull complete
# ...
# Status: Downloaded newer image for qdrant/qdrant:v1.9.0
# 启动耗时：12.3s（包含存储初始化）
启动后访问 http://localhost:6333/dashboard，自带 Web 控制台。这一步没有踩任何坑，属于开箱即用。
注意修改宿主机内核参数，否则数据量上来会报 mmap 错误：sysctl -w vm.max_map_count=262144，且 Redis 用户需要预留内存给 mmap。
2. 兼容性实测
Qdrant 的 API 设计偏向 RESTful 原生，但官方提供了 OpenAI 兼容层。我实测了 Python SDK 和 OpenAI Client 两种方式。
| 测试项 | 结果 |
|---|---|
| 原生 REST API (create_collection / upsert) | 通过，HTTP 状态码 200，响应时间 < 50ms |
| OpenAI 兼容接口 (v1/embeddings + v1/vector_store) | 通过，但依赖官方 Python SDK 1.10+，老版本不支持 |
| Qdrant 客户端 SDK (Python) | 通过，连接串 qdrant://localhost:6334 gRPC 协议，吞吐更高 |
| 与 LangChain / LlamaIndex 集成 | 通过，官方有原生整合包，无额外适配代码 |
| 向量维度支持 | 实测 1024 维（通义千问 embedding），兼容 |
结论：兼容性没问题，但别对 OpenAI 兼容层抱太高期望，它只是提供了 vector_store 的映射，不是完整的 Chat Completions 代理。
3. 性能基准
测试环境：4C8G 云服务器，数据为 100 万条 1024 维向量（float32，总量约 4GB），HNSW 索引，M=16，ef_construct=100。
# 压测工具：wrk + 官方 Python 客户端并发脚本
# 压测场景：余弦相似度 top-10 检索
| 指标 | 实测值 | 说明 |
|---|---|---|
| QPS（并发 32） | 480 req/s | 客户端 CPU 先到瓶颈，Qdrant 侧 CPU 未打满 |
| 延迟 P99 | 62ms | 纯网络 + 检索耗时，含 client 端序列化 |
| 延迟 P50 | 21ms | 多数请求集中在这个区间 |
| 写入吞吐 | 2.3k 向量/秒 | 批量 upsert（batch=256），SSD 磁盘 |
| CPU 占用 | 3.2 核 | 压测期间稳定 |
| 内存占用 | 6.1GB | 包含 4GB 向量 + 索引开销 |
我又额外测了 500 万条向量（约 20GB），QPS 掉到 210 req/s，P99 涨到 110ms。原因很明显：内存放不下了，开始走磁盘 mmap 交换。8G 内存跑百万级向量毫无压力，跑千万级以上务必上 32G 内存。
4. 资源占用分析
CPU
Qdrant 是计算密集型的，尤其是构建 HNSW 索引时。官方推荐 4 核起步。4 核是够用，8 核是舒服线。 再往上堆 CPU 对查询延迟没有线性提升，因为瓶颈常在内存带宽。
内存
这是核心。Qdrant 默认用 mmap 映射索引文件，所以“有多少内存就能缓存多少索引”。
经验公式：向量数据量 * 1.3 即为推荐内存。你的数据集如果 10GB，就别低于 16G 内存。少了会疯狂读盘，延迟翻倍。
磁盘
100 万条 1024 维向量 + 索引，占用 5.2GB。SSD 是刚需，机械盘不用想。磁盘 IO 决定了写入吞吐的上限。
5. 成本对比：自建 vs 云 API
以 1000 万条 1024 维向量、每月查询量 5000 万次为例。
| 方案 | 规格 | 月成本（估算） | 备注 |
|---|---|---|---|
| 自建（单机） | 8C32G + 500GB SSD | ¥1200 | 腾讯云包年，含带宽 5Mbps |
| 自建（高可用集群） | 3 节点 8C32G | ¥3600 | 3 副本，故障自动切换 |
| 云 API（Pinecone） | Pod 型 s1 | ~$3900（约 ¥28000） | 按量计费，存储+query 双收费 |
| 云 API（Zilliz Cloud） | 2 CU | ~$1700（约 ¥12000） | 同样按存储+CU 收费 |
结论显而易见：query 量稳定且日均查询次数超过 10 万次，自建成本是云的 1/10 以下。 但你要省心、不想运维、业务弹性大（忽高忽低），云 API 不用预留容量。
6. 结论与适用场景
适合自建的场景
- 延迟敏感型： RAG 问答、实时推荐，Qdrant 的 P99 比那些“带一份云端缓存”的竞品稳定得多。
- 数据量稳定： 向量规模在 1 亿以内，单机或 3 节点搞定，没有分布式扩展压力。
- 成本要求严苛： 对 AI 应用来说，向量数据库往往是有固定索引成本的。自建一次性买断，云 API 累积费用太贵。
别折腾的场景
- 数据量半年内翻 10 倍： 前期自建省了钱，后期扩集群、搬数据，运维成本远超省下的云费用。
- 没有专职运维： Qdrant 虽然轻量，但故障恢复、索引优化、WAL 清理还是要懂的人来搞。云 API 点一下就有。
- 多模态向量、混合检索（稀疏+稠密）： 这时候 Qdrant 的过滤能力略显单薄，需要 ES 或专门的 hybrid search 引擎。
Qdrant 是一个「你愿意折腾，它给足回报」的项目。 单机部署 10 分钟搞定，性能硬核，API 设计干净。如果你正在为 AI 应用选型向量库，且对云厂商的账单感到肉疼，先试这个。
AI 项目推荐
大模型- 标签
- #向量数据库 #RAG #检索 #Rust
- 浏览
- 👁️ 1
- 发布日期
- 2026-08-06