同一任务 换模型 省多少

同一个活，换一个模型跑，账单差多少？很多人只比每百万 token 的单价，结果换完发现没省钱甚至更贵。这篇不讲具体数字，只给判断口径：先固定任务、再对齐计价项、然后按输入输出结构折算，最后看哪些情况下换模型根本不省。

同一个活，换一个模型跑，账单差多少？多数人的做法是打开两家的价目页，看一眼每百万 token 的单价，谁便宜选谁。真换完往往发现没省，或者只省了预期的一小截。

问题出在比较的粒度上：你比的是单价，你付的是这个任务的一整套用量。输入多少、输出多少、调用几轮、失败几次，这些结构差异会把单价差放大或者抹平。下面给一套能重复使用的口径，先讲怎么算，再讲哪些情况下换模型根本不省。

第一步：把「同一个任务」固定死

对比的前提是两边跑的确实是同一件事。把任务边界写成一页纸：输入是什么形态、要求输出什么格式、允许几轮交互、失败重试上限几次。边界只要动一处，两个模型之间的用量对比就作废，得重跑。

• 写清输入形态：是短问句、整篇文档，还是带工具调用的多轮对话
• 写清输出要求：纯 JSON、固定字段的表格，还是自由文本，格式约束越松输出越容易变长
• 写清轮次上限与重试策略：允许返工的任务，用量天然高于一次成型
• 固定后用同一批样本跑基准，记录输入 token、输出 token、调用次数三项

不要拿单次试跑的观感当基准。找一个几十到上百条的同类样本批次，取中位数比平均值更抗极端值——偶尔一条超长输入会把平均值拉得没法看。

第二步：把两边的计价口径对齐

单价不能直接乘，得先确认两边的计价项是不是同一个集合。现在常见的是输入、输出、缓存写、缓存读分开计，有的还带最小计费单位或者按次起收，这些在小请求上特别容易把单价优势吃掉。

具体单价、计费颗粒度和最小计费单位这些会变动，动手前到 /price-watch 核对当时的数字，别用记忆里的旧口径。如果走的是中转，先到 /sites 看这家的计费说明与额度折算方式。

第三步：按任务结构折算，而不是按单价直觉

算法本身很朴素：输入 token 数乘输入单价，加上输出 token 数乘输出单价，再加上缓存和重试那部分，得到单次任务的成本。关键在于逐项算，而不是拿两个总价拍脑袋。

1. 拆用量结构把基准样本的输入、输出、缓存读、缓存写四类用量分别汇总，算出各自占总成本的比例。
2. 建两个场景一个按高输入低输出算，一个按低输入高输出算，同一个任务在两种结构下，换模型的结论经常是反的。
3. 把重试算进去用实际重试率修正调用次数，而不是按理论上的「一次成功」算。这一步最容易漏，也最容易把省下的钱赔回去。
4. 折算成每千次任务成本把结论写成「每千次任务差多少」而不是百分比。团队做预算时，绝对值比比例好沟通得多。

验证方法也简单：拿修正后的模型跑同一批样本，用真实账单回填，看预测值和实际值的偏差有多大。偏差超过一个明显量级，说明用量结构或者计价口径还有没对齐的地方。

哪些情况下换模型并不省

便宜模型更啰嗦是常见现象：多说几句解释、格式不严格、重复输出字段，输出 token 可能直接上浮一截。单价差本来就不大，输出一涨就持平甚至反超。

• 输出膨胀：格式约束松的任务，便宜模型更容易把答案写长
• 多轮返工：一次没做对再补一轮，两次调用换一次调用，单价差不够赔
• 人工兜底：质量不达标需要人看一眼的任务，省的是 API 费用，花的是人力
• 工具调用密集：每轮都带上下文，缓存读和输入部分才是主要开销，单价差异权重很低
• 长上下文检索：输入占绝对大头，比较重点应该放在输入与缓存计价，而不是输出单价

不适用的场景要单独拎出来：如果任务对延迟、稳定性或者合规有硬要求，省费就不该是决策的第一顺位。这类任务先确认能不能用，再谈省不省。

换之前跑一遍的检查清单

把上面几步压成一条可复用的动作链，每次要换模型的时候照着跑一遍，结论存表，下次直接复用。

1. 固定任务脚本同一份输入样本、同一份输出约束、同一份重试策略，两边完全一致。
2. 双模型跑同批样本各跑一批，记录输入 token、输出 token、调用次数、重试次数四项。
3. 对齐计价口径到 /price-watch 核当期单价，确认是否含缓存项、最小计费单位是多少。
4. 折算每千次成本按上面的公式逐项算，输出高输入低两个场景各算一遍。
5. 做小规模真实回填上线一小部分流量，用真实账单验证预测值，偏差大就回去查口径。
6. 季度复算模型和价格都在动，上季度的最优解这季度未必成立，把这张表纳入例行复算。