batch api 打五折值得等吗

你可能遇到过这种局面：手上一批活（跑数据集、批量翻译、离线打标）不要求秒回，但官方接口的批量通道标着低折扣，代价是要等窗口返回。这时候真正要算的不是折扣本身，而是「等待会不会把省下的钱又花回去」。这篇给一套判断顺序和可执行动作，帮你决定这批活走不走批量。

手上一批活——跑数据集、批量翻译、离线打标——不要求秒回，但官方接口的批量通道标着低折扣，代价是要等窗口返回。这时候要算的不是折扣本身，而是等待会不会把省下的钱又花回去。折扣省的是单位成本，等待增加的是交付周期，两者不在同一个账本上，得先分开看。

下面给一套判断顺序：先认清批量折扣是谁换谁，再用三个问题筛掉不该等的活，然后按「先算返工、再算折扣」的顺序算账，最后落到哪些活适合批量、哪些必须实时。整篇只讲取舍逻辑，具体价差和窗口时长请到站内 /price-watch 核对当时的数字。

批量折扣的本质：用等待换单价

批量通道不是「慢一点」，而是把提交和返回拆成两件事：你提交任务，它排到一个统一窗口出结果。所以它省的是单价，不改变 token 数量、上下文长度和重试次数。这三样该花多少还是多少，折扣不会帮你缩小输入本身。

三个问题决定等不等

别一上来就比价，先用这三个问题筛。任何一个答不上来或者答案是「会卡」，就倾向不走批量。它们判断的是等待会不会把折扣吃掉，而不是折扣有多大。

• 这批结果有没有下游依赖：日报、线上流程、客户交付里只要卡一个时间点，就倾向不等
• 等待窗口会不会撞上你的排期：如果任务本来就要跑一整晚，多等那几个小时不额外掏钱
• 调错重来的成本谁承担：批量任务改一次提示词就要整批重跑，重跑一次等于把折扣吃掉一半

这三个问题的顺序有讲究：先看下游依赖，再看排期，最后看返工归属。前两个决定了你能不能等，第三个决定了你等完还剩多少折扣。三个都过关，再进下一节算账。

算账顺序：先算一次返工，再算折扣

很多人先算折扣再算风险，顺序反了。正确顺序是先把「返工一次要花多少」估出来，再拿它跟折扣差额比。差额比一次返工还小，走批量就是在赌自己一次调对，这个赌注通常不划算。

1. 估一次返工按当前提示词和输出格式，估一个「大概率要改几次」的次数，乘上整批的输入量，得到返工成本量级。
2. 算折扣差额到站内 /tools/price-calculator 把同一份输入分别按实时价和批量价跑一遍，记录差额绝对值，不要记比例。
3. 两者对比差额明显大于一次返工成本，批量才值得等；差额小于一次返工，等来的折扣基本会被重跑抵消。
4. 留出验证位真要走批量，先跑一小批验证输出格式，确认无误再放大到全量，避免整批翻车。

什么情况下不适用：提示词还在调、输出格式没定型、需要人工看中间结果再决定下一步的场景，都不该走批量。这类活的核心成本是试错次数，不是单价，批量反而把试错周期拉长。

哪些活适合批量，哪些必须实时

判断标准很简单：看这个任务的产出是立刻被人或系统消费，还是先落库、之后才被消费。前者实时，后者可以谈批量。以下是常见的分法。

还有一种混合做法：把链路拆成「探索段走实时、定稿段走批量」，用一个中间文件把两段接起来。探索段负责把提示词和格式磨稳，定稿段负责跑量。这样既不牺牲试错速度，又能吃到定稿段的折扣。

如果批量通道由中转站提供，先确认它的窗口承诺和失败重发怎么算。窗口不明确或失败不退的通道，等完可能连结果都拿不回来。可以先到站内 /sites 看该通道的检测记录，再决定要不要把批量的活交给它。

最后提醒一句：价差和窗口时长会变，任何凭记忆写下的数字都不可靠。真要做决定前，到站内 /rankings 和 /price-watch 核对当时的数字，再套上面的判断顺序。