模型级联：先用便宜模型，失败再升级贵的

级联模型：便宜模型优先，出错再上贵的

级联的形态

三个组件，其中中间那个是人们最容易搞错的。

廉价阶段。一个更小或更旧的模型，或者同一个模型但关闭了推理功能，正常处理请求。

验证器。某种东西来决定廉价的答案是否可接受。可以是 schema 校验、置信度信号、一组断言、检索 grounding 检查，或者是另一个模型调用。

昂贵阶段。只在失败时运行。通常传入原始请求而不是失败尝试，因为给模型看一个坏答案容易让它锚定在上面。

值得明确一下级联不是什么。它不是provider错误的兜底——那是故障转移，其成本行为完全不同。它也不是路由器：路由器在请求一开始就选择一个模型，只付一次调用费用。级联至少要付两次费用。

设 C_big 为一次调用昂贵模型的费用，C_small 为廉价模型费用，C_v 为验证器费用，p 为验证器拒绝廉价答案的概率。基线是始终调用昂贵模型。级联的成本是：

E[cascade]  = C_small + C_v + p * C_big
E[baseline] = C_big

注意 C_small 和 C_v 在每个请求上都要付，包括那些升级的请求。这是大多数技术描述中遗漏的部分，而这部分决定了最终答案。

盈亏平衡升级率

设级联低于基线，解出 p：

C_small + C_v + p * C_big  <  C_big

                       p  <  1 - (C_small + C_v) / C_big

  p*  =  1 - (C_small + C_v) / C_big      the break-even rate

级联设计的全部秘密都在这个表达式里。阈值只取决于廉价路径与昂贵路径的费用比率，这很方便，因为比率比绝对数值更能抵御价格变动。

来算一下，假设三个费用：C_big = $0.0100，C_small = $0.0008，一个廉价的程序化验证器 C_v = $0.0004。

p* = 1 - (0.0008 + 0.0004) / 0.0100
   = 1 - 0.12
   = 0.88

所以除非级联在超过 88% 的请求上升级，否则级联更划算。当 p = 0.30 时：

E[cascade] = 0.0008 + 0.0004 + 0.30*0.0100 = $0.0042
相比基线节省 = 1 - 0.0042/0.0100 = 58%

现在改一个输入看看这有多脆弱。让验证器变成对昂贵模型本身的调用，这样 C_v = $0.0100：

p* = 1 - (0.0008 + 0.0100) / 0.0100 = -0.08

负阈值意味着没有任何升级率能使这个级联更便宜。它永远不可能赢，而这是人们经常构建的设计，因为"让强模型检查弱模型的工作"听起来像是明显正确的架构。如果验证器的费用和它要验证的东西一样贵，你就是在用一种更慢的方式调用昂贵模型。

验证器是整个设计的关键

有两个属性很重要，而它们拉扯的方向相反。验证器必须便宜——从公式看，C_v 直接吃掉节省——而且必须准确，因为它的错误不是对称的。

假阳性会放行一个坏答案，这是质量成本，不是金钱成本。假阴性会不必要的升级，这会让 p 逼近阈值。所以有用的顺序是：最便宜、最可靠的优先：

确定性检查。Schema 校验、JSON 解析、必填字段存在、引用的文档 ID 存在、答案中的算术正确。费用几乎为零，结论是确定的。

模型已经给你的信号。拒绝、finish_reason 表明截断、明确的"我不知道"、或者你在 schema 中请求的置信度字段。免费，而且对于检索场景出乎意料地有效——那类场景的失败模式是"上下文没有包含答案"。

小模型裁判。费用大约和廉价阶段一样，所以大致上让级联的固定部分翻倍。只有在确定性检查无法表达你在意的失败时才值得。

用昂贵模型做裁判。从成本计算来看已经排除在外的。它有它的用途——离线评估是一个——但不包括在以省钱为名的级联热路径中。

级联在其他方面的代价

均值下降了；其他指标上升了，设计评审应该把它们点名。

最坏情况成本永远上升。升级的请求费用是 C_small + C_v + C_big，根据构造它肯定超过基线。在上面的例子中是 $0.0112 对比 $0.0100——你的成本分布的 p99 上升了 12%，而均值下降了 58%。如果任何地方有按请求支出上限，必须提高它来适应级联。

延迟表现相同。升级的请求要顺序等待所有三个阶段。对于面向用户的路由，计算级联的 p95 延迟而不是均值，然后检查它是否满足界面承诺的时限。

p 不稳定。它随着流量配比、提示词变更、或任一阶段的静默模型更新而漂移。把它作为带告警的指标来追踪，因为一个 p 已经悄悄越过 p* 的级联从外表看起来和一个正常运转的级联一模一样。

复杂度是真实的分母。两个模型、一个验证器加一条升级路径意味着三倍的 bug 接触面，而槓杆评分公式里的 w 项不是装饰。

诚实的总结：级联值得构建当阶段间的价格比率大、验证器是确定性的、以及你有理由相信 p 远低于 p* 而不是刚好低于 p*。通过让廉价阶段和验证器以影子模式跑在真实流量上一天来测量 p，然后再投入设计——每个请求花费 C_small + C_v，答案精确。

级联需要两个阶段的费用以可比单位计量才能调优，而 Multigrid 返回的每个响应费用以微美元计，不管哪个模型或 provider 提供了服务——你可以在构建之前用目录里每个模型的价格来填入 C_small 和 C_big。

什么时候小模型真的就够了

削减 LLM 账单的 12 个槓杆

重试、故障转移和超时的成本