做 RAG 或语义搜索时，Embedding 往往是最先被外包出去的一环：把文本传给托管 API，拿回向量，交给向量数据库。它上手快，但数据量上来、合规变严或账单难以预测时，团队就会寻找替代方案。

常见路线有三条：托管 Embedding API、自己部署开源权重模型、使用向量数据库内置的向量化能力。三者没有绝对优劣，差别集中在维度与语言、延迟、隐私、成本和运维五件事上。

本文按这五个维度拆解，给出场景选择表和迁移清单。具体模型、维度与价格以各厂商官方文档和站内模型价格为准。

说明：OpenAI、Azure、Cohere、Pinecone、Qdrant、Milvus、Weaviate、BAAI、Qwen 等名称是其各自权利人的商标。本文仅作技术路线对比，不表示任何合作或授权关系；模型规格与接口限制可能随版本变化，请以官方文档为准。

一、三条路线先分清

托管 Embedding API。 包括模型厂商直连、云厂商模型服务和 OpenAI 兼容网关。优点是免运维、按量计费、切换快；缺点是文本要离开自己的网络，成本随调用量增长。

开源权重模型。 例如 BGE-M3、Qwen3-Embedding、EmbeddingGemma、multilingual-e5 和 jina 系列。权重可下载，部署在自己的服务器或私有云。优点是数据不出内网；缺点是要准备推理资源，自己处理版本、扩容和监控。

向量数据库内置向量化。 Pinecone 的 integrated embedding、Weaviate 的 vectorizer、Qdrant 的 FastEmbed、Milvus 的 embedding function 都属于这一类。写入时直接传文本，由数据库或它调用的模型生成向量，少写一层胶水代码。但内置向量化不一定等于本地推理，很多实现仍会调用外部模型服务。pgvector 只负责存储和检索，不生成向量。

二、维度：不是越高越好

维度决定表达能力，也直接决定存储和检索成本。常见例子：OpenAI 的 text-embedding-3-small 默认 1536 维、3-large 默认 3072 维；BGE-M3 为 1024 维；Qwen3-Embedding 的 0.6B、4B、8B 分别对应 1024、2560、4096 维；EmbeddingGemma 默认 768 维，可截断到 512、256 或 128 维。以上只作示例，以官方文档为准。

存储可以粗略估算：向量数 × 维度 × 每个浮点数的字节数。一百万条 1024 维 float32 向量，原始数据约 4 GB；3072 维约 12 GB，还没算索引、副本和元数据。

# 估算原始向量占用，不含索引、副本和元数据
chunks = 1_000_000
for dim in (768, 1024, 1536, 3072):
    gb = chunks * dim * 4 / 1024**3
    print(f"{dim} 维: {gb:.1f} GB")

关键是，维度和模型必须绑定。不同模型、不同 dimensions 参数生成的向量不能混在同一索引；换模型后必须全量重算，不能补零或截断凑长度。

三、语言覆盖：中文场景要单独测

很多模型都宣称支持上百种语言，但“支持”不等于在你的语料上效果好。中文、中英混合、俄语、商品型号、缩写和错别字都会影响召回。

选型时不要只看榜单，用真实用户问题、真实文档切块和难例（同义改写、跨语言提问、带编号的条款）做小评测。指标至少看 recall@k 和 MRR，再看排序是否符合直觉。这些模型都强调多语言，但最终要用自己的数据说话。

分词效率也要关注。同样 8192 Token 上限，中文、英文和代码能放下的字符数不同。切块按 Token 留余量更稳妥。

四、延迟与吞吐：看 p95，不看平均值

托管 API 的延迟由网络往返、队列和推理组成。跨地域调用、网络抖动、高峰排队都会让 p95 高于 p50。批量请求能摊薄成本，但会拉高单次响应时间，适合离线入库。

自部署的延迟主要来自推理排队和批处理。小模型在 CPU 上也能跑，但吞吐有限；大模型需要 GPU，还要考虑显存、并发和冷启动。没有运维团队时，这部分成本常被低估。

向量库内置向量化多了一次调用链，写入和查询都要等模型返回。它省代码复杂度，不一定省延迟。应分别测入库吞吐和查询 p95。

五、隐私与合规：文本去哪了

托管 API 意味着文本会离开自己的网络。要确认数据是否用于训练、保留多久、存在哪个区域、是否支持企业级数据协议。涉及个人信息、合同和财务时，先过合规评估。

开源自部署把文本留在自己的 VPC 内，但不自动等于合规：模型许可、日志、备份、访问控制都要自己负责。向量库内置向量化则要看清底层调用谁的模型、请求发往哪个区域。

向量本身也可能泄露信息。Embedding 不是加密，攻击者能做相似度推断。权限标签、租户隔离和访问日志要和原文一样认真对待。

六、成本结构：单价只是其中一项

比较方案时，不要只比每百万 Token 的报价。完整成本至少包括：

  • 入库 Token：文档首次向量化和增量更新。
  • 查询 Token：每次提问都要重新向量化。
  • 重算与迁移：换模型、改切块规则时全库重跑，以及双写、切流和回滚。
  • 存储与内存：向量、索引、副本和元数据。
  • 推理与运维：自部署的 GPU、CPU、电力、部署、升级和监控。

其中重算成本最容易被低估。一次全量重跑可能持续数小时甚至数天。具体单价以站内模型价格为准，价格会随厂商和版本调整，本文不写死数字。

七、按场景选路线

场景 优先路线 理由 注意事项
小团队快速验证 托管 API 无需运维，按量付费 记录模型名、维度和切块版本
数据不能出内网 开源自部署 文本留在自己的 VPC 评估 GPU、许可和备份
已在用某向量库且量不大 向量库内置向量化 少一层拼接代码 确认底层模型与请求区域
海量离线入库、成本敏感 开源自部署或批量托管 批处理摊薄成本 先做召回评测再全量
多语言客服、跨境电商 多语言托管模型或 BGE-M3 类模型 语言覆盖广 用真实语料验证小语种
在线查询延迟敏感 托管 API 就近部署，或本地小模型 减少跨网往返 看 p95，不只看平均
需要稠密加稀疏混合检索 支持多输出的开源模型 一次推理多种向量 索引和打分逻辑更复杂

这张表只是起点。真实选择取决于现有基础设施：已用某个云，优先看它的模型服务；已有 GPU 集群，自部署边际成本更低；已用某个向量库，内置向量化能省工程时间。

八、迁移清单

  1. 盘点现状：模型名、维度、距离度量、切块规则、索引参数和日调用量。
  2. 建评测集：几百条真实问题和正确文档，固定做回归。
  3. 选两到三个候选，不要一次换太多变量。
  4. 小流量双写：新旧向量各写一份，查询走新索引，记录召回差异。
  5. 校验维度、归一化和距离度量，确认 cosine、dot product 与索引配置一致。
  6. 新建集合做全量重算，不要在旧索引里混写不同维度的向量。
  7. 按百分比切流，保留旧索引和回滚开关，观察至少一个业务周期。
  8. 归档模型版本、维度、切块版本和重算日期，写进数据字典。

迁移中最常见的失败不是效果差，而是维度、归一化或距离度量不一致。先把工程细节对齐，再谈效果。

常见问题

Embedding API 可以完全用开源模型替代吗？

多数场景可以，尤其是数据敏感或调用量稳定的团队。但要自己维护推理服务、做模型评测、承担版本升级。快速验证阶段，托管 API 更省事。

向量数据库内置向量化和直接调 API 有什么区别？

内置向量化把生成向量收进数据库写入流程，代码更少，但底层往往仍调用外部模型服务。它不会自动解决隐私和成本问题，签约前要确认模型来源、区域和计费。

换 Embedding 模型必须全量重算吗？

必须。不同模型的向量空间不兼容，混用会让检索结果不可靠。维度相同也不代表能混用。全量重算前先做小规模评测。

维度越高效果越好吗？

不一定。维度更高会增强表达能力，也会增加存储和检索成本。很多模型支持 Matryoshka 截断，可在效果和成本间权衡，但截断后要重新评测。

自部署 Embedding 需要什么样的 GPU？

取决于模型大小、批量、延迟目标和并发量。小模型在 CPU 上也能服务低 QPS 场景，大模型通常需要 GPU 和批处理。先用真实流量压测，再决定规格。

下一步

如果希望先用托管方式验证效果，可以在中商起航 AI 网关创建测试 Key，用 OpenAI 兼容接口跑通入库和查询，再决定是否自部署。模型可用性与价格以模型价格为准。

相关阅读：