Embedding API 看似只是按输入 Token 收费，没有输出。但 RAG 项目跑几个月后，超预算的原因往往不是“查询太多”，而是切块后的文档总量、换模型后的全量重嵌入，以及向量库的存储与请求费用叠加。

本文拆开这几个成本项，给出估算顺序和降本优先级。单价会调整，以站内模型价格和厂商文档为准，本文不写死数字。

说明：OpenAI、DeepSeek 等名称是其各自权利人的商标。本文以 2026 年 10 月的常见接口形态为例，模型名、计费规则与价格可能变化，采购前请再次核对官方页面。

一、计费主体是输入 Token，不是“调用次数”

多数 Embedding 接口只对输入计费，不产生输出 Token 费用。输入就是你要向量化的文本，包括标题、正文、表格转换后的文字，也包括 HTML 标签、导航栏和多余空白。

估算时有四个放大点：

  • 分词器差异：一个汉字未必等于一个 Token，不同模型的分词方式不同。不要按字数估算，先用小样本调用，读响应里的 usage 字段。
  • 切块重叠：为了保留上下文，切块时常设置 10%–20% 的重叠，这部分文字会被重复计费。重叠越高，建库成本越高。
  • 脏文本：页眉页脚、模板话术、重复目录如果不清洗，会按正常 Token 收费，却不带来检索价值。
  • 重复建库：同一批文档在测试、预发、生产各嵌一遍，成本按环境数翻倍。
成本项 何时产生 计费方 容易漏算的地方
输入 Token 文档与查询向量化 Embedding 服务商 切块重叠、页眉页脚、重复索引
批量任务 离线全量与增量索引 服务商批量接口 是否真的享受批量折扣
重嵌入 换模型、改维度、改切块 Embedding 服务商 全库重跑与切换期间的双份存储
向量存储 向量与索引落盘 向量数据库或云平台 副本、备份、索引膨胀
检索与出网 每次查询读取向量 数据库或云平台 跨区访问、峰值 QPS
生成调用 检索后交给大模型 大模型服务商 常被误算进 Embedding 成本

最后一行值得强调：Embedding 便宜，不代表 RAG 总成本低。检索片段交给大模型生成答案，输入 Token 往往比向量化费用高得多，预算要分两段算。

二、批量接口：省单价，换时间

多数平台的批量接口按低于实时接口的价格计费，代价是任务排队、返回时间以小时计，并且可能限制可用模型和单次请求大小。批量适合首次建库、夜间增量同步、离线评测；不适合用户提问时的实时向量化。

使用前核对三件事：

  1. 批量任务是否单独限额，会不会与实时请求争抢配额。
  2. 失败或部分成功的请求是否计费，重试成本由谁承担。
  3. 网关是否把上游的批量折扣传递下来。不是所有网关都会传递，采购前问清楚，或用第一张账单验证。

批量不等于无限并发。上百万条一次提交容易触发限流或任务失败。按规模分批，记录每批 Token 和耗时，失败批次单独重试，避免整批重跑。

三、重嵌入：最容易被低估的一次性成本

以下变更通常要求全量重嵌入：

  • 更换 embedding 模型，或模型升级导致向量空间变化。
  • 修改向量维度，旧向量无法与新向量混用。
  • 改变切块规则、清洗规则或文档解析方式。
  • 新增语种，原模型效果不足。

重嵌入的成本不只是调用费，还包括重跑时间、新旧索引并存的存储，以及切换期的检索质量波动。知识库很大时，这笔钱可能超过此前所有查询费用之和。

降低风险的做法：

  • 保留原始文本作为事实来源，向量只是派生数据，随时可以重建。
  • 索引元数据里记录模型名、版本、维度和切块参数。
  • 新索引建好后，用一批固定问题做对比评测，再切流量。
  • 日常只对新增和修改的文档做增量嵌入，把全量重嵌入当成有计划的迁移。

四、向量存储与出网：第二张账单

向量库的计费通常看五件事：存储容量、内存规格、副本数、请求量、出网流量。按向量数量估算容量时，先算原始大小：1536 维、float32，每个向量约 6 KB；一百万条约 6 GB，再叠加索引、元数据和副本，实际占用可能是数倍。

几个常被忽略的点：

  • 维度：维度越高，存储和检索计算越贵。部分模型支持降维输出，是否可用、对召回影响多大，要用自己的评测集验证。
  • 副本与备份：高可用副本会成倍增加存储，备份策略也会计入账单。
  • 请求量：检索次数比文档数增长得更快，按 QPS 选规格，而不是按数据量选。
  • 出网：应用与数据库跨地域部署、每次查询返回大量候选、向多个环境同步向量，都会产生流量费。把应用放在同一区域，限制单次返回的候选数量，能省下不易察觉的一笔。

小规模场景用 PostgreSQL 加 pgvector 往往够用；数据量和并发上来后，再评估托管向量库是否值得溢价。

五、把月度成本估准的顺序

  1. 统计源文档数量、平均长度和切块参数，算出切块后的总输入 Token，而不是原文字数。
  2. 用最近一周的真实查询日志，统计每日查询次数和平均查询长度。
  3. 明确未来三个月的重嵌入计划：会不会换模型、改切块、扩语种。
  4. 向向量库供应商确认计费项：存储、副本、备份、请求、出网分别怎么算。
  5. 分别计算“建库首月”和“稳定运行月”，两笔预算不要混在一起。
  6. 给估算留出余量，并用第一周的真实账单校正系数。

可复用的估算框架如下。占位数字仅用于演示，单价从模型价格和向量库账单填入。

# 估算框架：数字为占位示例，不是任何厂商的真实价格
docs_tokens = 40_000_000       # 全量文档切块后的输入 Token
query_tokens = 2_000_000       # 每月查询向量化 Token
reindex_per_month = 1          # 每月全量重嵌入次数
vector_gb = 12                 # 向量、索引、副本合计占用

embed_price_per_1k = 0.0       # 填入价格页中的每千 Token 单价
storage_price_per_gb = 0.0     # 填入向量库的每 GB 单价

monthly_embed = (docs_tokens * reindex_per_month + query_tokens) / 1000 * embed_price_per_1k
monthly_storage = vector_gb * storage_price_per_gb
print(monthly_embed + monthly_storage)

六、降本的顺序不要反

先治理输入，再考虑换更便宜的模型。顺序大致是：

  1. 清洗：去掉导航、页眉页脚、重复模板，正文抽取后再切块。
  2. 切块：按语义边界切，重叠比例够用即可，不要把重叠当成保险。
  3. 冷热分离：历史归档内容不必全部进向量库，需要时再按需嵌入。
  4. 查询缓存：高频且相同的问题直接复用向量，减少重复调用。
  5. 批量：离线索引走批量接口，实时查询走实时接口。
  6. 存储优化：合理选维度、评估量化、按查询量定副本。
  7. 模型分流：Embedding 与生成模型分开评估，别为了省向量费牺牲检索质量。

如果顺序反了，常见结局是换了略便宜的 embedding 模型，但切块重叠没降、脏文本没清、重嵌入频繁，账单几乎不动，召回还变差。

常见问题

Embedding API 为什么没有输出 Token 费用？

Embedding 输出固定长度的向量，不是生成文本，所以通常只按输入计费。少数平台可能对存储等能力单独收费，以官方文档为准。

批量接口一定比实时接口便宜吗？

通常单价更低，但要看时限、失败重试和网关是否传递折扣。需要即时返回的查询不适用，省下的单价会被等待时间抵消。

换 embedding 模型后，能不能只重嵌一部分文档？

新旧模型向量空间通常不兼容，混用会导致检索错乱。稳妥做法是全量重建，建好影子索引、评测通过后再切换；只重嵌部分文档一般不可行。

向量存储为什么可能比 Embedding 调用更贵？

因为存储按容量、副本、请求和出网持续计费，而向量化在文档不变时是一次性成本。数据量大、副本多、查询频繁时，第二张账单很容易超过第一张。

估算和实际账单对不上，先查什么？

先查切块重叠和脏文本带来的 Token 放大，再查测试环境重复建库、失败重试、批量折扣是否生效，最后核对向量库的副本与出网费用。

下一步

需要统一入口、按量计费和多种模型，可以先注册中商起航 AI 网关，用小额预算跑通一次建库和查询，再按真实用量估算。模型与价格以模型价格为准。

相关阅读：