我把同一个成本公式写在白板上好几年了:单价 × 输出量 × 重试次数。它帮我挡掉过不少「看起来便宜」的选型。
10 月 13 日 Google DeepMind 发布 Gemini 4 Argon,API 介绍价每百万输入 token 2 美元、输出 10 美元,11 月 30 日后涨到 4 和 20。真正让我停下来的是另一行:单次输出上限从 6.4 万 token 抬到 100 万。
那天我发现,白板上那三个词里,有两个的含义都变了。
当输出天花板从 6 万抬到 100 万,成本杠杆从「你喂了多少」移到了「它吐了多少」,而一次跑到底的长任务,把失败的单位代价也一起放大了。
过去两年我做选型,表里跟长度有关的只有两列:上下文窗口多大、每百万 token 多少钱。从来没单独量过输出上限,默认所有模型都够用。
这一列现在必须加上。它决定的不是「能不能跑」,而是「一次能不能交付一个完整物」。国内口径摆在一起就很清楚:GLM-5.3 最大输出 131,072,Step 5 Preview 与 DeepSeek-V4.1 在 384K 档,Argon 是 100 万。这不是同一量级的选项。
成本那一边更直白。输出单价是输入的五倍,介绍期结束后还是五倍。一次吐 50 万 token 的长任务,单次调用就是 5 美元,涨价后 10 美元。我以前算账时把「输出量」当成大致稳定的估计值,现在它是真变量,而且乘在最贵的那个单价上。
我一直说成本要看总账,而总账里的每一项都得能单独被拉出来算。输出量这一项,以前是背景,现在是主项。
长输出最诱人的地方是省掉编排:不用切任务、不用拼接、不用在几十次请求之间传状态。我做过变电站远程智能巡检的后端,最烦的就是一件现场任务被环境打断,前面算的东西全丢,只能从头再来。所以看到「一次干完」,我本能是高兴的。
但高兴不了三秒。一次 100 万 token 的输出,中间没有任何检查点。它跑四十分钟,在第 90% 的地方偏了,你损失的是整个四十分钟和整笔钱;切成十段跑,你损失的只有最后一段。
分段拼接是为了在中间留下可以回到的地方,不是为了讨好模型的输出上限。这个理由到今天还没过时。
再看一眼输入侧。10 月 14 日阶跃星辰把缓存命中输入价从 0.35 元涨到 0.70 元,涨的恰恰是 agent 型负载最依赖的那一档。输入在变贵,输出在变长,两头一起动。我这两年攒下的长前缀复用、上下文缓存、模板化 system message,收益全押在「缓存命中价会一直降」这个从没被承诺过的假设上。
所以长输出不是不能上,是必须配两件东西。一是中间产物落盘:每完成一个可判定的子步骤就写一次状态,中断后从最后一个状态续跑,而不是从头再来。二是监控按时间间隔设:跑满 N 分钟没有新产出就告警。别等它完成回调,失败的任务永远不会回调。
任务越长,没人看的时间窗越大。
这一点有现成的反面样本。CSO 在 10 月 14 日的调查里复盘 OpenAI 侵入 Hugging Face 那次事件,持续了好几天没人发现,安全专家的原话是:人们启动了实验,然后就没看着了。
一、给选型表加一列「最大输出 token」。 顺手把成本公式里的输出项按实际输出长度重算一遍,别用估算的平均值,长任务的分布是长尾,平均值会骗人。
二、给任何启用长输出的链路加中间产物落盘。 每个可判定的子步骤完成就写一次状态文件,恢复时从最后一个状态继续。这一步不花预算,改的是编排层,不是模型。
三、把长任务的监控改成按时间间隔。 跑满 N 分钟没有新产出就告警,不依赖完成回调。我自己的日报自动化流水线就是靠这条活下来的,它断在哪一步都能续上,所以我不怕它断。