批处理和后台任务的 AI API 成本，应该按一条完整管线估算，而不是把它当成“更便宜的实时聊天”。一个批处理工作流包含输入文件、队列任务、校验、重试、输出存储、监控和完成窗口。真正决定成本的是每个处理对象完成一次要经过多少步骤。
这篇文章适合不需要立即返回结果的 AI 工作：批量翻译、商品库补全、客服工单打标签、夜间报告、评测任务和历史数据回填。如果用户正在页面上等结果，就应该单独做实时路径预算。
先判断任务是不是真的适合批处理
后台任务不一定等于批处理。先把任务按时间要求分成四类：
| 时间模型 | 用户预期 | 成本规划含义 |
|---|---|---|
| 实时 | 用户正在等待回答 | 优先保证延迟和可靠性 |
| 准实时队列 | 用户希望较快完成 | 控制队列延迟和重试行为 |
| 定时批处理 | 可以晚点完成 | 优化吞吐、文件准备和完成窗口 |
| 回填或迁移 | 临时高量任务 | 单独预算一次性峰值 |
这个区分很重要。官方 batch API 通常面向大规模、非紧急任务。Gemini Batch API 文档强调异步处理大量请求和完成窗口；Azure OpenAI batch 文档强调 batch deployment、输入文件、创建任务等步骤；Amazon Bedrock 也把 batch inference 当成独立的托管任务流，而不是普通聊天请求。
预算也应该按这个结构来做。
用处理对象作为成本单位
不要从 API 请求数开始。先定义业务上“完成一次”的对象是什么。
| 工作流 | 处理对象 | 需要额外计算的隐藏工作 |
|---|---|---|
| 批量翻译 | 文档、段落或语言文件 | 切块、术语表 prompt、QA 检查 |
| 商品信息补全 | 商品记录 | 抽取、生成、校验 |
| 客服工单打标签 | 工单 | 分类、置信度检查、重试 |
| 报告生成 | 报告 | 检索、综合、格式化 |
| 数据回填 | 行、文件或账号 | 去重、重跑、审计日志 |
可以用这个公式：
单个处理对象成本 = 预处理调用 + 生成调用 + 校验调用 + 重试调用 + 最终整理调用
月度批处理成本 = 单个处理对象成本 × 处理对象数 × 安全余量如果一个商品记录需要抽取、改写和校验，它就不是一次模型调用。如果一个文档被切成 20 个 chunk 再做最终总结，它也不是一个“文档级 prompt”。
按完整批处理管线建模
真实批处理管线不只是“把 prompt 发给模型”：
- 收集源记录
- 去重或跳过已处理对象
- 准备 JSONL 或供应商要求的输入文件
- 估算每个对象的输入 token
- 提交任务
- 监控任务状态
- 拉取输出文件
- 校验输出格式或质量
- 重试失败记录
- 存储结果和审计元数据
Gemini Batch API 文档区分 inline requests 和 JSONL input files，并包含任务状态监控和结果获取；Azure OpenAI batch 文档包含准备 batch file、input format、创建 input file 和创建 batch job。这些都是运营步骤，也会通过切块、校验或重跑影响成本。
不要假设批量输出天然正确
批处理输出经常需要校验。结构化抽取可能返回不合法 JSON；翻译可能漏掉占位符；分类可能置信度太低；报告生成可能需要最后格式整理。
先区分哪些检查是确定性规则，哪些需要模型调用：
| 检查类型 | 通常可确定性完成？ | 可能需要模型调用？ |
|---|---|---|
| JSON schema 校验 | 是 | 否 |
| 必填字段检查 | 是 | 否 |
| 语气或质量检查 | 否 | 是 |
| 翻译 QA | 部分 | 是 |
| 幻觉或引用检查 | 否 | 是 |
| 最终报告摘要 | 否 | 是 |
校验调用往往是“看起来便宜”和“真实账单更高”之间的差距。必须单独预算。
重试和幂等是成本控制，不只是工程细节
后台任务一定会遇到重试：超时、输出无效、队列重复投递、部分失败、供应商错误、人工手动重跑。如果没有幂等，同一个对象可能处理两次，也就可能计费两次。
需要记录：
- 重试率
- 每个对象最大尝试次数
- 重试是重跑完整 prompt，还是只重跑失败 chunk
- 去重 key
- 是否复用中间结果
- 人工重跑流程
估算公式：
有效处理对象数 = 原始对象数 × (1 + 重试率)如果任务是 chunk 级处理，要同时在 chunk 层和对象层考虑重试。最终摘要失败时，如果保存了中间结果，重跑摘要通常比重跑所有 chunk 便宜。
把存储、监控和输出处理写进流程
AICostNest 主要估算 AI API 成本，但批处理任务周围还有运营成本和限制：
- 输入文件生成和存储
- 输出文件存储
- 任务元数据和审计日志
- 队列 worker 或调度器
- 监控和告警
- 人工复核队列
- 过期文件清理
这些不一定进入 token 成本公式，但它们决定了任务是否可控。批处理不是孤立 prompt，而是运营管线。
示例：商品库批量补全
假设一个商品团队每月补全 50,000 条商品记录。
| 步骤 | 假设 | 预算说明 |
|---|---|---|
| 准备 prompt | 每个商品一个 prompt | 包含标题、规格、类目、规则 |
| 生成调用 | 一次模型调用 | 生成描述和属性 |
| 确定性校验 | schema 检查 | 不需要模型调用 |
| 质量抽检 | 5% 记录 | 可用小模型或人工样本 |
| 重试率 | 4% | 重跑失败或无效对象 |
| 安全余量 | 20% | 覆盖长记录和重跑 |
第一版预算不应该是“50,000 次 API 调用”这么粗，而应该是：
50,000 次生成调用 + 重试 + 抽检调用 + 安全余量然后把平均输入和输出 token 放进 文本模型计算器，再用 模型价格表 核对模型假设。
批处理什么时候真的能降成本
当供应商支持 batch pricing，或异步处理让团队可以做更合适的模型路由时，批处理可能降低总成本。Gemini Batch API 页面在调研时写到 batch 成本相对标准成本有折扣，但这类信息必须以最新官方价格页为准，文章里不应写死长期承诺。
即使没有折扣，批处理设计也可能通过这些方式降低成本：
- 去重重复记录
- 合并相似任务
- 缓存稳定说明和规则
- 只重试失败 chunk
- 分类任务用更小模型
- 只对样本做质量复核
- 把一次性回填和日常流量分开
不要默认批处理一定便宜。应该比较每个完成对象的总成本。
批处理成本表
建议每个批处理任务一行：
| 字段 | 应填写内容 |
|---|---|
| 任务名称 | 翻译、补全、标签、报告、回填 |
| 时间模型 | 队列、定时批处理、迁移 |
| 处理对象 | 文档、记录、工单、报告、行 |
| 月处理对象数 | 正常每月重复量 |
| 一次性回填量 | 迁移或历史数据 |
| 每个对象调用次数 | 生成、抽取、校验、摘要 |
| 每次输入 token | 源文本、prompt、元数据、示例 |
| 每次输出 token | 生成文本、JSON、摘要 |
| 校验方式 | 确定性、模型复核、人工样本 |
| 重试率 | 失败或无效对象 |
| 最大尝试次数 | 成本防护栏 |
| 完成窗口 | 分钟、小时、次日 |
| 安全余量 | 长输入和运营意外 |
可以从 Token 预算模板 开始，但这里建议每个后台任务单独建一行。
第一次运行后要核对账单
第一次生产批处理结束后，用真实数据对比预算：
- 处理对象数
- 平均输入 token
- 平均输出 token
- 校验调用数
- 失败对象数
- 重试次数
- 重复任务数
- 实际使用模型
- 实际适用的计费模式
如果账单高于预期，先用 AI API 账单核对指南 排查，再考虑换模型。问题可能来自重复任务、完整重跑 chunk、输出过长，而不一定是模型价格。
FAQ
批处理一定比实时 API 便宜吗？
不一定。只有供应商支持 batch pricing，或者工作流可以使用更慢但更合适的模型路由时，才可能更便宜。校验、重试、长输入和重复任务都可能抵消节省。
批处理 AI 成本最适合用什么单位？
用每个处理对象成本，例如商品记录、文档、工单、报告、数据库行或文件。API 请求数只是更底层的指标。
一次性回填要放进月度预算吗？
要单独列。迁移或历史回填会制造临时峰值，不应该被误认为正常月度成本。
使用 batch pricing 前要确认什么？
确认供应商支持、模型可用性、输入格式、完成窗口、配额、重试策略和最新价格条款。不要把 batch 假设套到实时用户路径上。