模型降档省钱吗：小模型能不能替代大模型，用一个能算的公式判断
一个季度成本复盘会上，最容易出现的一句话是「我们换个小一点的模型吧」。理由看起来无懈可击：打开定价页，同一个系列的大小两档，价格能差出一个数量级。有人当场就把这个倍数乘进了年度预算表，省下来的数字大得让人不好意思反对。
问题是，这个乘法算的是「每百万 token 的挂牌价」，而你真正要省的是「每完成一个业务任务的钱」。这两个口径中间隔着一件事：小模型在你这个任务上的通过率。降档不是白拿的折扣，它拿更高的失败率去换更低的单价。所以「降档到底成不成立」不该靠感觉回答，它是一道有解析解的算术题——多高的失败率会把这个价差吃干净？
这篇就把那个临界点算出来。价格全部取 DeepInfra 官方定价页的挂牌价（来源：https://deepinfra.com/pricing，$ / 1M tokens），所有数字只是按官方标价做的算术演示，实际以官方定价页为准。文中不对任何模型的能力做评价、不引用任何跑分——通过率这个变量必须由你自己在自己的评测集上测出来，谁的数据都不能替你填。
一、价差到底有多大：先把倍数算准
先看同一系列的三档挂牌价：
| 模型 | 输入 $/1M | 缓存输入 $/1M | 输出 $/1M |
|---|---|---|---|
| DeepSeek-V4-Pro | 1.30 | 0.10 | 2.60 |
| DeepSeek-V3.2 | 0.26 | 0.13 | 0.38 |
| DeepSeek-V4-Flash | 0.09 | 0.018 | 0.18 |
（来源：DeepInfra 官方定价页，以官方定价页为准。）
Pro 与 Flash 之间：
- 输入：1.30 ÷ 0.09 = 14.44，约 14.4 倍
- 输出：2.60 ÷ 0.18 = 14.44，约 14.4 倍
这里有个很省事的巧合：输入和输出的倍数恰好相同（因为 1.30 : 0.09 与 2.60 : 0.18 是同一个比）。这意味着不管你的任务是输入重（长文档摘要）还是输出重（长文生成），Pro 换 Flash 的总成本倍数都是 14.4，与输入输出配比无关。这是个很干净的性质，后面所有推导都能直接用这个单一倍数。
但别把这个巧合当规律。看中间那档 V3.2：输入 1.30 ÷ 0.26 = 5.0 倍，输出 2.60 ÷ 0.38 = 6.84 倍——两个倍数不一样。这时候总成本倍数就取决于你的输入输出配比了，输出越重，降到 V3.2 省得越多。所以凡是要跨档比价，必须按你自己真实的输入/输出 token 配比去算总成本，不能只看输入单价。这一点在按成本选模型里展开过，价格表的坑基本都出在只盯一列上。
设一个贯穿全文的算例任务，参数是假设值，请按你自己的实测配比替换：
算例假设：单次任务输入 3000 token、输出 500 token，全部按未命中缓存的普通输入计价。
| 档位 | 输入成本 | 输出成本 | 单任务合计 | 相对 Pro |
|---|---|---|---|---|
| V4-Pro | 3000÷10⁶×1.30 = $0.003900 | 500÷10⁶×2.60 = $0.001300 | $0.005200 | 1 |
| V3.2 | 3000÷10⁶×0.26 = $0.000780 | 500÷10⁶×0.38 = $0.000190 | $0.000970 | 1/5.36 |
| V4-Flash | 3000÷10⁶×0.09 = $0.000270 | 500÷10⁶×0.18 = $0.000090 | $0.000360 | 1/14.44 |
记住两个数：c_大 = $0.005200，c_小 = $0.000360，单任务差价 $0.004840。
按 100 万次任务/月的量算：全走 Pro 是 $5200/月，全走 Flash 是 $360/月，账面差 $4840/月。这就是那个「大得不好意思反对」的数字的来历。下面开始扣。
二、临界公式：单位任务有效成本
省钱的正确度量单位不是「单次调用价」，是单位任务有效成本——把一个任务真正做成、交付出去，一共花了多少钱。写成式子：
单位任务有效成本 C = c × E[调用次数] + f_人工 × h
c：一次调用的 token 成本E[调用次数]：把这个任务做成，平均要调几次（含自动重试）f_人工：最终仍需要人介入的任务比例h：一次人工返工的成本
先看最干净的情形：失败能被自动判定、自动重试，且不需要人（f_人工 = 0）。设单次调用通过验收的概率为 p，重试到成功的期望调用次数就是 1/p，于是
C_小 = c_小 / p_小
「降档仍然划算」的条件是 C_小 ≤ c_大，即
c_小 / p_小 ≤ c_大 ⟺ p_小 ≥ c_小 / c_大
临界通过率就等于价格比。 这是全文最该记住的一行。
代入算例：p_小 ≥ 0.000360 ÷ 0.005200 = 0.0692，即 6.9%。
换成重试率的说法更直观。设 r 为平均每个任务的额外重试次数，有效成本 c_小 × (1 + r) ≤ c_大，则
r ≤ c_大 / c_小 − 1 = 14.44 − 1 = 13.4
平均每个任务重试 13 次以内，降档都还是赚的。
这个数字大到荒谬，但它恰恰是结论本身：十几倍的价差，纯自动重试几乎不可能吃得掉。一个通过率只有 7% 的方案，早在成本讨论之前就会因为业务不可用被毙掉。也就是说，如果你的场景真的满足「失败可自动识别 + 自动重试 + 不需要人」，那么降档在成本上基本是稳赢的，剩下的只是效果能不能接受的问题，跟钱无关了。
顺带把中间档也算了：V3.2 对 Pro 的临界通过率是 0.000970 ÷ 0.005200 = 18.7%。同样低得没有约束力。
所以到这里应该警觉：如果一个降档方案在纯自动口径下算不赢，那说明它的失败率高到离谱，问题不在成本模型，在方案本身。 真正会翻车的是下一节。
三、真正吃掉差价的是人工返工
把 f_人工 × h 这一项加回来。假设降档前后大模型那侧的人工返工率是 f_大、小模型这侧是 f_小，令 Δf = f_小 − f_大（降档多出来的人工返工率）。忽略自动重试那点增量（上一节已证明它可以忽略），划算的条件是：
c_小 + Δf × h ≤ c_大 ⟺ Δf ≤ (c_大 − c_小) / h
临界额外人工率 = 单任务差价 ÷ 单次人工返工成本。
单任务差价是 $0.004840。人工成本得给个假设值：
算例假设：人力折算 $15/小时 = $0.25/分钟。这是假设值，请替换成你自己的真实口径（含社保、管理摊销、机会成本）。
| 单次人工返工耗时 | 单次人工成本 h | 临界额外人工率 Δf |
|---|---|---|
| 1 分钟 | $0.25 | 1.94% |
| 3 分钟 | $0.75 | 0.65% |
| 5 分钟 | $1.25 | 0.39% |
| 10 分钟 | $2.50 | 0.19% |
| 30 分钟 | $7.50 | 0.065% |
（逐项复算：0.004840÷0.25 = 1.936%；÷0.75 = 0.6453%；÷1.25 = 0.3872%；÷2.50 = 0.1936%；÷7.50 = 0.06453%。）
对比一下：纯自动口径的容忍度是「多重试 13 次」，加了人之后的容忍度是「多 0.65% 的任务需要人看 3 分钟」。同一个价差，容忍度差了三个数量级。
还有个更刺眼的算法。把差价直接换算成人工时间：
0.004840 ÷ 0.25 = 0.01936 分钟 ≈ 1.16 秒
降档省下的钱，平均每个任务只够买 1.16 秒的人工时间。 只要降档让人平均每个任务多花一秒钟——多瞄一眼输出、多点一次确认、多切一次窗口——省下来的就没了。
放到月度规模上更清楚。100 万次任务/月，降档账面省 $4840。如果降档后多出 1% 的任务需要人工返工 3 分钟：
10,000 次 × $0.75 = $7,500 的人工成本
$7,500 − $4,840 = 净亏 $2,660/月
多 1% 的返工率，在做人工兜底的场景里根本不算什么。这就是为什么**「有人在环」的场景降档必须极其谨慎**：你省的是 token 的钱，赔的是人的钱，而这两种钱的单价差着几个量级。
反过来，这个公式也告诉你降档最该往哪儿推：优先在没有人的链路上降档。任何一条链路，只要末端挂着人工审核，它的降档收益天花板就被 (c_大 − c_小) / h 死死压住了。
四、什么样的任务适合降档
别去背「摘要适合、代码不适合」这种任务清单，那种清单跨场景不可迁移。用特征判断：
适合降档的四个特征（最好同时满足）
- 验收标准客观、可自动判定。JSON schema 校验通过、抽取的字段在原文中能对上、分类结果在枚举内、代码能跑通测试。有机器可判的对错，重试才有意义。
- 失败可被自动识别。这条和上一条不是一回事——标准客观，不代表你的代码真的在判。很多线上系统的「失败」是靠用户投诉发现的，那
f_人工就不是你能控制的变量了。 - 单次任务价值低。一条商品标题的规范化错了，代价是重跑一次；一份对外报价单错了，代价是一次商务事故。
- 量大。差价是按次累加的，量小的时候你省的钱还不够写路由逻辑的工时。
不适合降档的三个特征（命中一条就该停）
- 错误代价高且不可回滚。一旦输出会直接触发外部动作（发消息、下单、改数据库、对客户可见），单次错误的期望损失往往就超过整月的降档收益。
- 失败难以自动发现。最典型的是「格式完全合法但内容悄悄错了」——schema 校验一路绿灯，错误要等到下游甚至用户那里才暴露。这种任务的真实
f_人工你根本测不准，公式里的分母就是虚的。 - 需要长链推理 / 多步依赖。任务链条越长，中间某一步的偏差被后续步骤放大得越厉害，失败的形态也越难被单点校验拦住。
还有个容易被漏掉的判据：输出结构越硬，降档越安全。因为结构化输出的失败大多能被 schema 当场拦住，属于「可自动识别 + 可自动重试」，正好落在纯自动口径里。这方面的返工代价怎么量化，结构化输出的返工成本那篇讲得更细。
五、别做二选一，做分层调度
前面所有推导都假设「要么全走大，要么全走小」。这个假设本身就是最大的浪费——你的请求分布几乎肯定是长尾的，简单请求占大头，难请求占小头，用一个模型接全部流量必然在一头上亏。
分层调度的骨架很简单：简单请求走小模型，复杂请求直接走大模型，小模型失败的自动升级重试。麻烦的地方在两件事：路由判据怎么定，以及升级重试的钱怎么算。
5.1 升级重试的成本必须算进总账
先算钱，因为这一步最容易漏。「小模型失败后升级到大模型重试」意味着这些任务两次都付：
C = c_小 + (1 − p_小) × c_大
划算的条件 C ≤ c_大：
c_小 + (1 − p_小) × c_大 ≤ c_大
⟺ c_小 ≤ p_小 × c_大
⟺ p_小 ≥ c_小 / c_大
有意思的是，临界通过率跟第二节纯自动重试的结论一模一样，都是价格比 6.9%。这不是巧合：无论失败后重试同一档还是升级到上一档，第一次调用的钱都已经沉没，能不能赚回来只看这次「便宜的尝试」有多大概率省掉一次贵的调用。
代入算例，看不同 p_小 下的实际账单（相对全走 Pro 的百分比）：
| 小模型通过率 p_小 | 单位任务成本 | 相对全走 Pro |
|---|---|---|
| 95% | 0.000360 + 0.05×0.005200 = $0.000620 | 11.9% |
| 90% | 0.000360 + 0.10×0.005200 = $0.000880 | 16.9% |
| 80% | 0.000360 + 0.20×0.005200 = $0.001400 | 26.9% |
| 60% | 0.000360 + 0.40×0.005200 = $0.002440 | 46.9% |
| 30% | 0.000360 + 0.70×0.005200 = $0.004000 | 76.9% |
这张表有个漂亮的规律：相对成本 = 6.9% + (1 − p_小)。所以在做预算时，你只要能给出小模型通过率的一个保守下界，就能立刻给出成本上界，不需要跑完整模拟。
注意 p_小 = 60% 这一行：即便小模型有四成任务要推给大模型重做，总账仍然只有全走 Pro 的 47%。升级重试策略对通过率的容忍度非常高，这是它比「一刀切降档」优越的根本原因——它把「效果风险」换成了「成本风险」，而成本风险是有界且可算的。
5.2 路由判据怎么定
四类判据，可靠性从低到高，成本也从低到高：
- 输入长度 / token 数。最便宜，本地就能算，零延迟零成本。但它跟任务难度只是弱相关——短输入可能是个难题，长输入可能只是格式冗长。只适合当粗筛的第一道闸门，比如超过某个长度直接进大模型通道，不指望它做细分。
- 任务类型 / 来源渠道。按业务标签路由（哪个入口、哪种模板、哪个客户等级）。可靠性取决于你的标签质量，好处是完全可解释、可审计、出问题能定位到规则。大多数团队的第一版应该做到这一层就停，它的投入产出比最高。
- 小模型自评。让小模型输出结果的同时给一个置信度或「我不确定」的标记，低置信度的升级。听上去优雅，实际有个众所周知的坑：自评分数的绝对值没有意义，它只在你自己的数据上做过分位数校准之后才有用。别直接拿「置信度 < 0.8 就升级」这种拍脑袋阈值上线，先用离线数据画出「自评分数 vs 实际通过率」的曲线，找到分位点再定阈值。而且自评本身会增加输出 token，这部分钱要算进
c_小。 - 独立校验器。用规则、schema、单元测试、检索比对之类的确定性手段判定，判不过就升级。可靠性最高，且完全不依赖模型的自我认知。缺点是要为每类任务单独写，工程量最大。但只要你的任务命中了第四节「验收标准客观可自动判定」这条，就应该优先做这个，它同时解决了路由和失败识别两个问题。
实践上最稳的组合是：长度做粗闸门 + 业务标签做主路由 + 独立校验器做升级触发，自评只作为校验器覆盖不到的补充。
5.3 三个容易翻车的实现细节
- 降级链不能是无限的。升级重试要设硬上限（一次就够），否则一个卡住的任务会把两档的钱都烧一遍还出不来。这类失控消耗的机制在重试的隐藏成本里拆得很细，分层调度会把它放大，因为你现在有两条链路可以互相踢皮球。
- 两档的采样参数必须分别定。直接把大模型那套参数原样搬到小模型上，测出来的通过率没有参考价值。
- 路由本身要可观测。至少要能随时答出：各档的流量占比、各档的通过率、升级重试的触发率、各档的单位任务成本。答不出这四个数，你就没法验证降档到底省没省钱——账单只会告诉你总数变了，不会告诉你为什么。
六、怎么验证：一个可复现的流程
公式给的是判据，数值得你自己测。流程比结论重要：
- 固定评测集。从真实流量里抽样，必须包含长尾困难样本。抽样时按难度分层，别只抽最近一周的（会偏向当期热点）。规模上，样本量要够让通过率的置信区间收得住——通过率越接近 50%，需要的样本越多。
- 固定验收标准，而且要先于测试写下来。标准里必须区分「硬失败」（schema 不合法、字段缺失、跑不通）和「软失败」（合法但不达标），因为这两类的自动可识别性完全不同，前者进纯自动口径，后者进人工口径。
- 固定采样参数，两档用同一套配置跑。任何参数差异都会污染对比。
- 分离验证集。如果你在测试过程中调过 prompt，那调完之后必须换一批没见过的样本重测，否则你测的是「prompt 在这批样本上的过拟合程度」，不是真实通过率。这一步最常被跳过，也是最致命的。
- 打分，算通过率，硬失败率和软失败率分开记。
- 算单位任务成本，用第二、三、五节的公式，把重试和人工都折进去。
- 小流量灰度，用真实流量跑一段，把线上实际通过率和离线测的对一对。差得多，说明评测集的分布不对，回第 1 步。
结果记录表模板（三档同时评估时按行扩展）：
| 字段 | 大模型档 | 小模型档 |
|---|---|---|
| 模型 ID | ||
| 采样参数（一字不差地记） | ||
| 评测集版本 / 样本数 | ||
| 是否为独立验证集 | ||
| 平均输入 token | ||
| 平均输出 token | ||
| 单次调用成本 c | ||
| 硬失败率（可自动识别） | ||
| 软失败率（需人工发现） | ||
| 期望调用次数 1/p | ||
| 人工返工率 f_人工 | ||
| 单次人工成本 h（标注假设口径） | ||
| 单位任务有效成本 C | ||
| 结论：是否降档 / 路由到哪一档 |
把这张表存进版本库，每次换模型、换 prompt、换供应商都重跑一遍。成本决策最怕的不是算错，是没有可比的历史基线——三个月后有人问「上次为什么选了这档」，没人答得上来，就只能再吵一轮。这套记录口径和评估你的应用那篇讲的评测集管理是同一套东西，做一次能同时服务效果和成本两条线。
七、四种常见误判
误判一：拿几个「看起来差不多」的例子就下结论。 手动跑五个 case，两档输出肉眼看不出差别，于是拍板降档。五个样本对通过率几乎没有约束力，而且人挑的样本天然偏向典型情况。成本决策要的是通过率的分布，不是几个点。
误判二：忽略长尾困难样本。 评测集从「最常见的请求」里抽，测出来通过率很高，上线后发现真正吃人工的全是那些不常见的请求。降档的损失恰恰集中在长尾上——常见请求两档都能做对，差异只发生在难样本上。评测集里困难样本的比例如果低于真实流量，你算出来的 f_人工 就是系统性偏低的。
误判三：在评测集上调过 prompt，却没留验证集。 这条单独拎出来说，因为它太普遍了。为小模型做了一轮 prompt 优化，通过率从 70% 提到 88%，很兴奋地上线，线上回到 74%。那 18 个点里有相当一部分是在测试样本上拟合出来的。规矩很简单：调过参数的那批样本，就不再有资格当评审。
误判四：只盯着换模型，忘了不换模型也能省。 看回第一节那张价格表：V4-Pro 的缓存输入价是 $0.10，普通输入 $1.30，正好 13 倍——和降档到 Flash 的 14.4 倍是同一个量级，但完全不换模型、不引入任何效果风险。用算例任务验证：输入全部命中缓存的话，Pro 的单任务成本是 3000÷10⁶×0.10 + 500÷10⁶×2.60 = 0.000300 + 0.001300 = $0.001600，只有原来 $0.005200 的 30.8%，省掉近七成。
对于系统提示词长、few-shot 示例多、检索上下文重复度高的场景，先把缓存命中率提上去，收益既大又零风险。降档应该是缓存、prompt 压缩这些无风险手段做完之后才考虑的，而不是第一个动的开关。小模型的适用边界和缓存的省钱测算可以放在一起看，顺序搞反了很容易花大力气冒大风险，省下的还不如改个缓存策略。
自查清单
上线任何一次降档之前，逐条过：
- 我的
c_大和c_小是按自己真实的输入/输出 token 配比算出来的单任务成本，不是照抄定价页的输入单价倍数。 - 我算出了临界通过率
p* = c_小 / c_大，并且知道自己实测的p_小离它有多远。 - 这条链路末端有没有人？有人的话，我算了临界额外人工率
Δf* = (c_大 − c_小) / h，并且h用的是真实人力口径（写清假设值）。 - 失败能不能被代码当场判出来？判不出来的失败占多少？这部分只能算进人工口径，不能算进自动重试。
- 评测集里有长尾困难样本，且困难样本比例不低于真实流量。
- 调过 prompt 之后，换了一批没见过的样本重测，报出的通过率来自验证集。
- 如果做分层调度：升级重试的钱按
c_小 + (1−p_小) × c_大算进了总账，重试次数有硬上限，四个观测指标（各档流量占比 / 各档通过率 / 升级触发率 / 各档单位任务成本）都能查。 - 缓存命中率、prompt 长度这些零效果风险的降本手段，已经先做过一轮了。