本地 embedding vs 在线 embedding 选型：速度、质量、成本的权衡

最近折腾 Hindsight 记忆系统，遇到一个很实际的问题：它的 embedding 默认用 BAAI/bge-small-en-v1.5（384 维，本地跑），但 MTEB 分数只有 ~58。要不要换一个更好的模型？换成在线 API 还是自托管？

这个问题本质上是一个选型权衡，而且几乎所有做 RAG 或记忆系统的人都会遇到。本文用真实数据帮你理清思路。

不是什么新鲜问题，但这次有真实数据

我的环境很简单：一个跑在普通服务器上的 pgvector（HNSW 索引），配合 Hindsight 做记忆存储。当前 embedding 走 CPU 推理（bge-small，384 维），一次 embedding 耗时 5-15ms。

换模型的核心约束有两个：

1. dim 变了就得全部 re-embedding — Hindsight 在启动时检测向量维度，改模型后原有数据全部不可用
2. pgvector 的存储和索引速度跟 dim 直接相关 — 384 维升到 1024 维，磁盘和内存需求翻 2.5 倍以上

我花了几天收集 2026 年最新的 benchmark 数据，整理出下面这张全景表。

三个维度：速度、质量、成本

速度：本地 CPU 其实不慢

很多人觉得在线 API 更快，实际上对短文本（<512 tokens）来说，本地 CPU 推理单条 2-15ms，比大多数在线 API 都快——因为省掉了网络往返。

在线 API 的延迟方差很大。OpenAI 的 p95 延迟在 GCP 区域可以达到 60 秒（来自 Zep Blog 的实测数据）。Google 的 text-embedding-004 从 GCP 内部调用最快（10-50ms），但这是特例。

结论：如果你的场景以单条短文本为主，本地 CPU 推理的延迟是最低的。如果有批量需求，带 GPU 的本地方案更有优势。

质量：差距确实存在

这是 2026 年 4 月的 MTEB 检索分数：

Qwen3-Embedding-8B      70.6  ████████████████████
gte-Qwen3-8B            68.1  ███████████████████
voyage-3-large          67.1  ██████████████████
Cohere embed-v4         66.3  █████████████████
jina-embeddings-v3      65.5  ████████████████
text-embedding-3-large  64.6  ███████████████
BGE-large-en-v1.5       63.6  ██████████████
text-embedding-3-small  62.3  ████████████
BGE-small-en-v1.5       ~58   ██████████
all-MiniLM-L6-v2        42.7  ███████

从 BGE-small (~58) 到 Qwen3-8B (70.6)，MTEB 差距 12 分，转化为 recall@10 约提升 8-15%。中文场景下，BGE-large-zh-v1.5 和 Qwen3-Embedding 系列是推荐选择。

但这里要做一个务实的判断：12 分的 MTEB 差距在你的业务上能感觉到吗？ 如果你的用户搜索的是技术文档中的精确关键词，384 维的 bge-small 可能已经够用。如果是开放域问答，质量提升会更明显。

成本：分水岭在 10-15M tokens/月

用 Spheron 报告中的实测数据算一笔账：

• A100 80GB 自托管：$1.04/hr，吞吐 60,000 tok/s，折合每百万 token $0.0048
• 最便宜的在线 API（Jina v3）：$0.02/百万 token

自托管成本 = 固定的 GPU 租金，API 成本 = 按量付费。两条线相交的点是 每月 10-15M tokens。

月 token < 10M：API 更便宜（月费 < $2-10）
月 token > 15M：自托管更划算（A100 月费 ~$750，但无上限）

如果正好有一块空闲的本地 GPU（比如 4090），自托管的边际成本接近零。没有 GPU 的话，CPU 推理虽然慢一点，但 BGE-small 级别的模型对 CPU 很友好，也是零成本方案。

决策树

月 token < 10M → API（Jina v3 / OpenAI small，零运维）

月 token > 15M 或需要 <10ms 延迟
  ├─ 已有空闲 GPU → 自托管 BGE-M3 或 Qwen3-0.6B
  └─ 无 GPU → API 批量折扣

中文为主
  ├─ API：Jina v3（便宜）或 Voyage-3（质量）
  └─ 本地：BGE-large-zh-v1.5 或 Qwen3-Embedding

已在生产环境 → 警惕 re-embedding 成本
  通常选择 API 更安全——滚动切换不用重建索引

两个容易被忽略的坑

1. dim 变更的成本比想象中大

我最初想直接从 384 dim 升到 4096 dim（Qwen3-Embedding-0.6B），算了一笔账后发现：

• 向量大小从 1.5KB → 16KB，翻了 10x
• 10M 条向量的存储从 15GB → 160GB
• pgvector HNSW 索引构建时间从几分钟变成几十分钟
• 全量 re-embedding 需要数小时

这个迁移成本本身可能就够买半年的 API 了。所以对于已上线的系统，先算迁移成本再选模型。

2. 在线 API 的尾部延迟比你以为的差

OpenAI embedding API 在 GCP 区域的 p95 延迟达到 60s，这是我看到 Zep Blog 实测数据之前没想到的。如果你的搜索 API 内部串行调 embedding，60 秒的尾部延迟会让整个服务变得极不稳定。解决方法是加本地缓存、批量请求、或者用异步队列。

总结

没有银弹。选型建议按优先级：

1. 已上线系统 — 先用 API（Jina v3 或 OpenAI small），避免 re-embedding 成本
2. 新项目，无 GPU — API，成本可控，品质在线
3. 新项目，有 GPU — BGE-M3（性价比最佳）或 Qwen3-0.6B（最新轻量旗舰）
4. 中文为主 — BGE-large-zh-v1.5 或 Cohere embed-v4
5. 零预算个人项目 — 保持 CPU 推理的 bge-small，够用就好

最后一句实话：如果你的搜索场景是精确关键词匹配，换模型带来的提升可能不如换个向量检索算法来得大。先用好工具，再升级工具。