---
title: "从 Chroma 换成 Qdrant，我踩了 100 万向量的坑"
author: "云朵君（数据STUDIO）"
source_url: "https://mp.weixin.qq.com/s/Aovqh95_LBYtVOj8_tTD_w"
published_date: "2026-05-20"
feed_name: "微信公众号"
tags: [vector-database, chroma, qdrant, rag, python, infrastructure, tech-selection]
type: article
review_value: 7
review_confidence: 8
review_recommendation: "pass"
sha256: f756d62b4f1c6d11284fdd3a53ee023f92fbc13bdf85d543fb8aea68e1ec5e1e
---
---
# 从 Chroma 换成 Qdrant，我踩了 100 万向量的坑
> 原文：从 Chroma 换成 Qdrant，我踩了 100 万向量的坑
> 作者：云朵君（数据STUDIO）
> 来源：https://mp.weixin.qq.com/s/Aovqh95_LBYtVOj8_tTD_w
> 日期：2026年5月20日
## TL;DR
- 选向量库不是在比功能，是把你的场景参数（数据量、查询复杂度、运维条件）套进决策框架
- Chroma 是嵌入式帮手（零运维、<100 万向量最佳），Qdrant 是独立引擎（生产级、过滤不伤召回率）
- 两段可运行 Python 代码已给出
## 核心观点
**"Chroma 和 Qdrant 哪个更好"——这是错的。选型不是在比产品，是在比场景。**
- 你的数据量多大？
- 查询条件是简单标签还是复杂组合？
- 有人帮你管服务器吗？
## 选型决策矩阵
| 你的情况 | 选谁 | 原因 |
|---------|------|------|
| 个人项目 / 快速原型 / pip install 就完事 | **Chroma** | 零运维，和 Python 脚本共享进程 |
| 数据量 < 100 万向量 | 两个都行 | 这个量级你感知不到差异 |
| 数据量 > 100 万向量 | **Qdrant** | Chroma 在这个规模开始吃力 |
| 查询经常带复杂过滤（时间 + 标签 + 状态...） | **Qdrant** | 过滤不伤召回率 |
| 预算紧 + 数据量大（TB 级） | **Chroma** | S3 比纯内存便宜 250 倍 |
| 生产环境 / 需要高可用 | **Qdrant** | Raft 共识 + 水平分片 + 自动修复 |
## 作者的真实踩坑经历
> 自己做 RAG 原型时无脑选了 Chroma（pip install 省事）。后来项目数据量涨到 200 万条，检索从 **50ms 漂到 800ms**，排查半天才发现不是 embedding 模型的问题，是 Chroma 在数据量过阈值后合并层扛不住了。换成 Qdrant，延迟回到 **40ms 以内**。
所以 100 万向量这个阈值不是从哪抄的——是真的交过学费。
## 架构对比
### Chroma：嵌入式（住在你家客房的帮手）
- Python 进程内开 Rust 运行时（Tokio），把向量距离计算扔给 Rust Worker 线程，绕过 Python GIL
- 数据在进程内零拷贝传递
- 查询时同时做两件事：
  - 已建索引数据 → HNSW 图遍历
  - 还没建索引的新数据 → 暴力扫描
  - 两边结果在位图合并层汇合后返回
- **优点：** 新插入的数据立刻能被搜到，不需要等索引构建。适合 Agent 记忆、频繁增删数据的场景
- **缺点：** Python HTTP 客户端的封包效率成为瓶颈，>100 万向量时合并层压力扛不住
### Qdrant：独立服务（隔壁开了间办公室的团队）
- 独立服务进程，通过 HTTP/gRPC 与 Python 通信
- 数据拆成多个独立"段"（Segment），每个段有自己的向量存储、元数据索引和 HNSW 图
- 写入先记 WAL（预写日志），再应用到对应段——断电了 WAL 帮你还原
- 段分两种：可追加的（新数据往里写）和不可追加的（后台默默合并、重建索引）
- **优点：** 前台查询和后台合段是隔离的，不会因为索引重建而感觉查询变卡
- **缺点：** 需要维护一个独立服务
### 架构类比
- **Chroma 像开放式厨房** — 厨师同时切菜、炒菜、装盘，效率高但客人一多就乱
- **Qdrant 像分区仓库** — 进货区、存储区、出货区物理隔离，吞吐量大但前期基建投入多
## 性能边界
### Chroma 的软肋：100 万向量
> 基准测试显示，Chroma 在这个量级附近开始出现明显性能退化。不是突然挂——延迟开始不稳定，有时候 20ms 返回，有时候 200ms。
原因：
1. Python 和 Rust 之间的跨语言通信在大数据量时成为瓶颈
2. 元数据连接的内存膨胀触发 GC 抖动
按每条文本 500 token、embedding 维度 768 算，100 万向量大约是 10 万篇中等长度文章。大多数个人项目和中小团队离这个天花板还远。
### Qdrant 的"大材小用"
Qdrant 在 **5000 万向量**规模下依然稳定在 ~41 QPS（99% 召回率），靠三件套：
- Rust SIMD 指令集
- 分段隔离
- TurboQuant 量化压缩
但如果只有 5 万个向量，Qdrant 的优势完全感受不到，反倒多了一个要维护的 Docker 容器。
> 菜市场买菜开了辆重卡——不是车不好，是场景不对。
## 查询过滤：最容易被忽略的杀手
假设存了 50 万条文档，每条 5 个标签。做语义搜索时还要过滤掉 2023 年之前的、只保留某些话题：
- **Chroma：** 先搜再过滤，或者先过滤再搜。前者精度可能不够，后者在条件复杂时性能衰减
- **Qdrant：** Filterable HNSW 在 HNSW 图遍历时直接应用位图掩码——语义搜索和条件过滤同时完成，互不干扰
**你的 WHERE 子句越复杂，越该考虑 Qdrant。**
## 踩坑案例
Flask 服务里跑了 Chroma 做知识库检索，读写都在同一条线上。高峰期用户一多，GIL 把向量计算和 HTTP 响应绑在一起，整条链路都在等。
解决：Qdrant 独立服务 + Python 只做业务逻辑。
根因不是 Chroma 不行，是没做好读写隔离——但 Chroma 的嵌入式设计确实让这种错误更容易犯。
## 实践建议
### 四问题选型框架
1. 数据量：一年内向量存量会超过 100 万吗？
2. 查询复杂度：过滤条件是简单标签还是多字段组合？
3. 运维条件：你愿意维护一个独立服务吗？
4. 预算：大规模场景下，RAM 成本敏感吗？
### 决策树
```
数据量 < 100万 且 过滤简单    → Chroma
数据量 < 100万 且 过滤复杂    → Qdrant
数据量 > 100万               → Qdrant（几乎必选）
预算极紧 + 数据量超大          → Chroma（S3，250倍成本差）
做 Agent / 上下文管理         → Chroma（原生支持更好）
```
### 作者的建议
新项目一律 Chroma 起步，快速验证想法。等到数据量和查询复杂度真的摸到阈值了，再迁 Qdrant——到那时候，迁移的理由是数据告诉你的，不是别人推荐的。
> 别提前优化，但也别不知道边界在哪。