Batch API 还是实时调用：如何为不同工作负载选对通道

先分清楚两种时间尺度

LLM 调用对时间的敏感度差异极大。一个用户在聊天框里等回复，容忍度是秒级；一个团队的日报生成任务，容忍度可能是小时级。Batch 通道正是为后者设计的：它把请求排队、集中处理，用更长的完成时间换更低的单 Token 价格。

Anthropic 的 [batch processing 文档](https://platform.claude.com/docs/en/build-with-claude/batch-processing)与 [pricing 页](https://claude.com/pricing)都单独列出了 batch 档价格；OpenAI 侧也有对应的 batch 与批处理折扣。两者的共性是在标准价基础上打折，差异在提交方式与完成窗口。

判断框架：四个问题

1. 有人在同步等待这个结果吗？ 是 → 实时。否 → 继续。
2. 结果可以晚几小时吗？ 可以 → batch 候选。必须分钟级 → 实时。
3. 请求是可以离线枚举的集合吗？ 是（一批文档、一批工单、一批评测样本）→ batch 非常合适。
4. 失败重跑的成本高吗？ 高 → 实时拿即时反馈；低 → batch 批量重试更划算。

典型的 batch 场景清单

• 内容分类与打标：几十万条商品、评论、工单的统一标签体系。
• 离线数据清洗：把非结构化文本批量抽成结构化字段。
• 回归评测：改提示词前，跑一遍固定评测集做对比。
• 批量摘要 / 翻译：文档库、客服记录、会议纪要的离线整理。
• 合成数据生成：为训练或评测批量生成样本。

Batch 的坑：部分成功与重试

Batch 作业不是「要么全成要么全败」。一个几百条请求的作业里，通常会有几条因为参数错误、超长输入、内容策略等原因失败。工程上必须做到：

• 逐条记录结果，不要把整批的成败当成一个布尔值。
• 区分可重试与不可重试：429 / 5xx 可重试，400 参数错误重试也没用。
• 幂等键：同一条业务数据重复提交不能造成重复计费或重复写入。
• 成本预演：提交前按 Token 估算上限，避免一次作业打出意外账单。

用一个网关同时管两条通道

把实时与 batch 拆成两套独立的账号、Key 和账单，是最常见的架构债：价格一变就要对两处，失败排查要翻两个后台。

Admesh 的做法是一个 Base URL、一套 Key、一本账单：你在业务侧用任务类型决定走哪条通道，而模型目录与单价始终来自同一份后台配置，毛利与用量在同一个地方可查。

查看限流与并发说明 →