同样的模型，为什么实时接口比批量接口贵一倍？

1. 贵的不是模型，是「现在就要」

同一张价目表上，实时接口和批量接口常常指向同一个模型名。看起来像重复收费，其实卖的不是智力，是延迟承诺。同步接口要在这次 HTTP 请求里返回结果，厂商必须预留在线容量；批量接口允许在最长 24 小时窗口里排队执行，容量可以错峰。

OpenAI 在 Batch API 文档里把折扣写死了：相对同步 API 便宜 50%，另有独立、更高的限流池，并给出明确的 24 小时完成窗口。适用场景也写得很直：评测、大规模分类、给内容库做 embedding、离线视频任务——都是「结果可以晚点要」的活。

团队对账时最常见的错位是：产品经理看到「gpt-x 每百万 token 多少钱」，就把夜间回归评测也打到聊天用的同步端点。模型没变，乘数变了。账单涨，并不等于模型变贵。

2. 批量不是「慢一点的实时」，限流池和过期规则都不同

Batch 的限流与现有按模型的实时限流是分开的。OpenAI 写明：使用 Batch 不会消耗标准按模型限流里的 token 配额。所以「实时接口已经打满」并不等于「这个模型今天不能再跑」——评测可以换通道，而不是换模型或升 tier。

完成窗口到期后，批次进入 expired。未完成的请求被取消，已完成的响应写进输出文件，已完成部分照常计费。把 Batch 理解成「要么全成功要么全免」，会在过期当天看到半截账单，然后误判成被多扣。那是窗口规则，不是故障。

提交方式也不同：要先上传 JSONL，每行一个请求、带唯一 custom_id，再创建批次。创建成功只代表进入队列，输出文件要等批次结束才能下载。用实时客户端去「for 循环打一万次」再指望享受批量价，接口路径就不对，折扣不会自动出现。

3. Anthropic 侧：输入和输出都打五折，缓存折扣还能叠

Claude 的 Message Batches 把同一逻辑写得更短：异步处理大量 Messages 请求，费用按标准 API 价格的 50% 收取，吞吐更高，多数批次一小时内完成，上限仍是 24 小时。官方定价页同样写明：Batch 对输入 token 和输出 token 都打五折。

和 OpenAI 不同的细节也要看见：Anthropic 写明 Prompt Caching 的折扣可以和 Message Batches 叠加。长系统提示先写入缓存、再把稳定任务丢进批次，夜间作业的单价可以低于「只开了 Batch、每次仍付全价前缀」。反过来，批次里每次都改系统提示，半价只作用在那次完整前缀上，缓存写还可能更贵。

不要把两家的 50% 当成可以互换的实现。一端用 JSONL 文件，一端在 Messages Batches 里提交请求数组；一端强调独立限流池，一端强调与缓存叠乘。对账字段也不一样。能共用的只有判断：这件事能不能等。

4. 什么必须实时，什么不该实时

用户正在看屏幕的链路必须实时：客服回复、编辑器补全、对话产品里的下一句。把这些改成 Batch，半价换来的是产品不可用。OpenAI 自己把 Batch 限定在「不需要立即响应」的作业。

另一头更常被浪费：每天一次的评测集、文档入库 embedding、离线审核、批量改写、回归测试。这些任务的正确完成时刻是「明天上班前」，不是「200 毫秒内」。继续走同步接口，付的是容量预留，不是更好的答案。

混在一个脚本里最危险。白天给用户打实时，晚上同一套 client、同一个模型名、同一本「官方单价」表去跑十万条评测，限流先爆，账单再爆。拆成两条客户端、两列预算，比换更便宜的模型更先该做。

5. 账单拆两列，卡也不要和网页订阅绑死

复盘时至少拆「同步 token」和「批量 token」。哪一列在涨，动作才分得清：交互流量在涨，还是有人把可等待作业打进了实时池。把两列揉成「这个月 OpenAI 好贵」，就会用降模型去修一条其实该走 Batch 的评测管道。

API 预付积分和 ChatGPT Plus 网页订阅仍是两本账，支付通道也不该混。网页席位续费用可设额度的虚拟卡隔离，例如 RDVCC，避免订阅自动续费和 API 按量账单抢同一条卡。这不是「虚拟卡能让 Batch 更便宜」——折扣在接口路径上，不在卡 BIN 上。卡只负责别让席位续费把评测额度刷爆。