OpenRouter Batch API 定价解析：省 50%，值得等吗？

API 价格砍半当然很诱人，但如果结果在截止时间之后才到，省下的钱可能毫无意义。OpenRouter Batch API 很适合离线文本处理和 Embedding 任务，却不适合交互式调用：它采用异步机制，完成窗口最长为 24 小时，而且宣传中的折扣并不覆盖推理账单里的每一项费用。

先说结论：哪些任务该用 Batch

数据标注、评测、Embedding、积压内容摘要等不赶时间的任务，适合迁移到 OpenRouter Batch API。面向用户的聊天、IDE Agent、联网搜索工作流以及多模态请求，则应继续走同步 API。

OpenRouter 表示，Batch 通常能为 70 多个模型带来约 50% 的单 token 降价，正式承诺的完成窗口为 24 小时。其发布公告提到，Beta 期间的完成时间中位数为 7 分钟，90% 的任务可在 1 小时内完成；这些只是观测数据，并非 SLA（官方公告）。

50% 折扣究竟覆盖什么

折扣主要针对模型的 token 费用，并不是整张推理账单的统一五折。

Will Cygan 的批处理成本拆解给出了一个 Claude Sonnet 5 的案例：1000 万输入 token 加 200 万输出 token，同步调用成本为 $40，改用 Batch 后降至 $20。这是特定模型下的计算，不能当作所有模型的统一报价。

“批处理路径的计费恰好是同步费率的一半。”—— Will Cygan，Batching (LLM Inference)

在确认供应商和模型之前，不要先把节省金额写进预算。一位用户 @fogelmania 曾反馈，某个 Beta 模型的批处理反而比并发同步调用更贵，原因是 Batch 流量被路由至不同的供应商：@fogelmania 的帖子。这只是提醒你核对已完成任务的实际成本，并不能证明所有模型都会如此。

Batch 是作业系统，不是更快的接口

OpenRouter 的Batch API 公告和快速上手文档描述的是作业式流程，而非即时返回结果。提交成功后，接口会返回 HTTP 202 Accepted、一个批次 ID，以及 validating 状态。正常生命周期如下：

validating → in_progress → finalizing → completed

其他终态包括 failed、expired 和 cancelled。你的 Worker 应保存批次 ID，并持续轮询至终态，而不是一直挂着交互式请求等待结果。

OpenRouter 表示，Beta 期间已处理超过 230,000 个批次，完成时间中位数为 7 分钟，90% 在 1 小时内完成。用户 @luismmolina 在上线当天的一次测试中观测到 5–8 分钟的耗时（测试帖子）；这些数据只能作为参考，不能替代按 24 小时窗口进行的业务规划。

减少返工的实现方式

目前的快速上手文档使用内联 JSON requests 数组，而不是上传 JSONL 文件。每一行都需要唯一的 custom_id，用于将完成后的响应或错误准确关联回原始记录。

最小请求结构如下：

{
  "endpoint": "/v1/chat/completions",
  "model": "openai/gpt-4o",
  "requests": [
    {
      "custom_id": "ticket-0001",
      "body": {
        "messages": [
          {"role": "user", "content": "Classify this ticket: ..."}
        ]
      }
    }
  ]
}

快速上手文档指定的提交地址为 POST https://openrouter.ai/api/beta/batches。顶层的 endpoint 和 model 会应用于整个批次，因此 API 形态或模型不同，就需要拆分成不同批次。支持的请求形态包括 Chat Completions、Responses、Anthropic Messages 和 Embeddings。

提交后，通过 GET https://openrouter.ai/api/beta/batches/:id 轮询状态。批次完成时，结果会内联返回。每条结果包含 response 或 error，而 request_counts 会分别统计总行数、完成行数和失败行数。对于失败的行，应按其 custom_id 单独重试，不要默认重放整个批次。

如果供应商行为会影响数据策略、BYOK 或 URL 资源的处理，应使用文档中提供的供应商控制项固定供应商，而不要依赖“最便宜供应商”路由。部署前还应确认所选模型与供应商确实提供可用的 Batch 路由。

哪些场景会让 Batch 行不通

快速上手文档中的限制说明表明，Batch 本质上是一个以文本为主的工作流。批处理请求不接受图片、音频、视频和文件类型的内容部分；Base64 与 data: URI 资源也会被拒绝。URL 资源是否受支持取决于供应商。OpenRouter 自带的联网搜索插件同样无法用于 Batch。

如果用户正在等待结果、模型需要读取本地上传文件、请求涉及音频或视频，或者应用要求秒级响应时间目标，就该使用同步 API。

成本示例：什么时候省下的钱是真的

假设要处理 10,000 张客服工单，每张使用 1,000 个输入 token 和 200 个输出 token，总计就是 1000 万输入 token 与 200 万输出 token。

单次任务名义上可节省 $20；如果每周运行一次，全年可节省 $1,040。但只要故障恢复、监控或紧急同步兜底的成本高于这部分差额，实际节省就会缩水。

做决策时要把这部分预留成本算进去。如果截止时间不可妥协，就要拿 24 小时窗口与缩小范围后的重跑时间、同步兜底所需时间进行比较。单 token 更便宜，但错过截止时间就无法使用的批次，对这项业务流程而言并不便宜。

常见问题

OpenRouter Batch API 一定是半价吗？

不一定。OpenRouter 将其描述为常见折扣，具体取决于模型。联网搜索仍按标准价格收费，缓存价格因模型而异，BYOK 则将供应商推理费用与 OpenRouter 费用分开计算。

一个 OpenRouter 批次要跑多久？

支持的完成窗口是 24 小时。Beta 阶段的耗时报告可以提供一些背景参考，但不构成服务等级保证。

可以上传 JSONL 或混用模型吗？

快速上手文档接受内联 JSON requests 数组。模型和 API 形态会作用于整个批次，因此不同模型或不同 endpoint 格式必须拆为独立批次。

能否只重试失败的行？

可以。如果已完成批次返回了行级错误，可根据每一行的 custom_id 创建一个更小的重试批次。对于批次级失败、过期或取消，需要单独处理，因为结果可能无法获取。

该选 Batch 还是同步 API？

不紧急的后台任务选 Batch。结果属于活跃用户交互的一部分，或需要使用不受支持的模态和工具时，则选同步推理。

实用建议：有选择地使用 Batch

迁移某项工作负载之前，先确认以下五件事：

1. 模型页面显示存在可用的 Batch 路由，且供应商符合预期。
2. 业务流程能够容忍完整的 24 小时窗口。
3. 每一行都有稳定的 custom_id，并且制定了重试方案。
4. 应用会记录实际完成后的用量与成本。
5. 输入和结果都有明确的负责人及清理策略。

OpenRouter 的快速上手文档指出，除非提前删除，批次输入和结果会保留 30 天。当这些产物不再需要时，应删除已进入终态的批次。

最适合首次迁移的，是一份已经冻结、可供复核的语料，而不是面向客户的关键路径——在后者中，迟到答案造成的代价往往高于 token 折扣带来的收益。