Embedding 批量调用的瓶颈：不是请求数，而是输入 Token
给知识库、客服语料或代码仓库做向量化，常见的第一版实现是循环调用接口：读一段文本，请求一次，写入向量库。数据量小的时候没问题，一旦文档到了几十万、上百万篇，就会同时遇到三件事：跑得慢、被限流、账单比预期高。要把这三件事放在同一张表里算清楚，先要明确一个前提：Embedding 按输入 Token 计费，限流也主要按 Token 与请求数两个维度计量，所以“把请求并发开大”往往不是答案。本文对照 OpenAI 与 Gemini 的官方文档（核验日期 2026-10-01，价格与限额请以官方页面为准），整理批量向量化的吞吐、限流与成本做法。
先算账：同步调用与 Batch 接口差多少
用官方给出的“每美元页数”换算成本
OpenAI 的 Embeddings 文档以每页约 800 个 Token 为例，给出了每美元能处理的页数：text-embedding-3-small 约 62,500 页，text-embedding-3-large 约 9,615 页，上一代 text-embedding-ada-002 约 12,500 页。按这个口径换算，一百万页（每页 800 Token，合计约 8 亿 Token）用 small 约 16 美元，用 large 约 104 美元。这是按文档示例做的估算，实际语料的平均长度不同，结果会按比例变化。
Batch 接口：半价，但要接受 24 小时窗口
OpenAI Batch 文档说明，批处理相比同步接口有 50% 的成本折扣，完成窗口固定为 24 小时，并支持 Embeddings 端点。同一份文档还给出了几项限制：单个批次文件最多 50,000 个请求，Embeddings 批次还额外限制为总共 50,000 个输入；文件大小上限 200 MB；每小时最多创建 2,000 个批次；使用 Batch 不会消耗标准的按模型速率限制，它有一个独立的额度池。Gemini 同样提供 batchEmbedContents，并说明 Batch 接口按默认 Embedding 价格的 50% 计费。所以对于不需要实时可用的全量初始化、夜间重建索引，Batch 接口既省钱，也避免与线上查询抢速率额度。
维度参数省的是存储，不是 API 费用
OpenAI 的 v3 模型支持 dimensions 参数，可以把向量缩短，3-small 默认 1,536 维，3-large 默认 3,072 维；Gemini 的 embedding 模型默认输出 3,072 维，可选 128 到 3,072 维，文档建议用 768、1,536 或 3,072。但计费仍然基于输入 Token，因此缩短维度只降低向量库的存储与检索成本，并不会减少调用费用。Gemini 文档还说明，gemini-embedding-2 会自动对截断后的维度做归一化，而 gemini-embedding-001 需要自己归一化；不同模型的向量空间互不兼容，换模型意味着全量重算。
| 方案 | 适用场景 | 成本特征 | 需要注意 |
|---|---|---|---|
| 同步接口逐批调用 | 增量更新、用户实时上传 | 标准价格 | 受每分钟 Token 与请求数限流 |
| Batch 接口 | 全量初始化、夜间重建 | 官方文档标注为半价 | 24 小时窗口，单批 50,000 条输入上限 |
| 缩短向量维度 | 向量库存储与检索成本高 | 不降低调用费用 | Gemini 部分模型需自行归一化 |
| 先去重再调用 | 语料里重复内容较多 | 直接减少输入 Token | 需要稳定的内容哈希 |
同步批量调用：吞吐怎么提上去
按 Token 而不是按条数分批
文档里的输入上限是按单条文本计的：OpenAI 当前模型每条最多 8,192 Token，Gemini 的 embedding-2 为 8,192，embedding-001 为 2,048。因此分批的第一步是先估算每条文本的 Token 数，超出上限的先分块，再按“每批总 Token 数”而不是“每批固定 N 条”来组批，这样既不会因为单条过长被拒，也避免一批里全是短文本导致请求数暴涨。分块与上下文预算的做法，可以对照长文档与大 PDF 的分块与 Token 预算一文。
客户端限速：让请求匀速，而不是尽快
批量任务最常见的失败方式，是启动时同时发出大量请求，几秒内撞上每分钟限额，随后一片 429。更稳的写法是在客户端实现令牌桶：按“每分钟 Token 额度的八成左右”设定发送速率，并读取响应头里的剩余额度做动态调整，遇到 429 先看是否带 retry-after。限流、过载、超时三类错误的区分方法，参见API 报 429、529 或超时的三类错误区分，这里不重复。
先去重、再排序、再调用
语料里的重复内容，例如页眉页脚、模板化的条款、重复抓取的页面，会直接白白消耗 Token。先对规范化后的文本做哈希，已向量化的直接复用，是成本最低的一步。其次，按长度排序后组批，可以让每批的总 Token 更接近上限、减少请求数；但要保留原始顺序的映射，写库时按文档 ID 对应，而不是按返回顺序。
失败续跑与质量校验
让任务可以从中间续跑
- 每批请求生成一个确定的批次 ID，由文档 ID 列表的哈希得到，写入任务表。
- 返回成功后，先写向量库，再把批次状态改成完成；顺序不能反。
- 重启后只处理状态不是完成的批次，已完成的直接跳过。
- 失败批次拆成更小的批次重试，定位是单条文本有问题，还是整体限流。
- 持续失败的单条文本进入隔离表，人工排查，而不是无限重试。
换模型前先做小样本召回对比
因为不同模型的向量空间不兼容，换模型要全量重算，成本不低。在动手前，先抽取几百条真实查询和已知相关文档，对比新旧模型的召回率与排序质量，再决定是否迁移。同一批语料用不同维度、不同模型各跑一遍，把“召回提升”和“单位成本”放在同一张表里比较，比只看价格表可靠。
把用量接进预算看板
批量向量化往往是一次性的大额支出，容易被月度账单淹没。建议给每个批量任务打上标签，记录输入 Token、模型、批次与总成本，并与团队的预算告警联动，做法可参考团队 AI 预算治理：用量看板、告警阈值与部门分摊。
总结：先去重和分块，再决定同步还是 Batch
Embedding 批量任务的优化顺序是：先去重，再按 Token 分块和组批，然后选择同步或 Batch 接口，最后才是并发与限速调参。需要实时可用的增量用同步接口并配好客户端限速，全量初始化与重建索引优先走半价的 Batch 接口。如果你的团队要在多个模型之间对比向量化效果与单价，可以把调用统一到 Tonbo AI 的 OpenAI 兼容接口，再结合内置 AI Chat 面板与 Token 套餐、按量充值，把不同模型的单位成本放在一起核对，具体接入方式见 OpenAI 兼容 Token API 接入指南。
