Python 模型级联：先用便宜模型再升级

模型路由想解决一个实际问题：简单请求也调用最贵模型，账单很难降下来。原文给出的办法是先让便宜模型尝试，再用质量检查决定是否升级，把预算留给真正困难的任务。

这个方向对接入 AI 的开发团队有用，但文章的结论要拆开看：路由模式值得借鉴，Copilot Fusion 的产品信息和基准成绩需要核实，Python 示例与省钱算式也有明显缺口。真正值得带走的，是怎样设计检查关卡，以及怎样把成本账算完整。

先分清任务，再决定调用几次模型

原文把模型路由分成三种执行模式：

• Single：一个模型完成整个请求，适合日常修改和问答。
• Cascade：便宜模型先生成草稿，通过检查就返回，失败才升级。
• Critique：一个模型起草，多个模型并行评审，再由起草模型修改。

三者解决的问题不同。Single 减少调用和等待；Cascade 利用简单任务占多数的特点节省费用；Critique 则增加评审环节，为复杂问题争取更可靠的结果。

作者以 Copilot Fusion 为例解释这种变化。据原文，GitHub 于 2026 年 10 月 28 日将其全面开放，覆盖所有 Copilot 套餐，以及 VS Code、Copilot app、Copilot CLI 和 JetBrains IDEs。用户选择 Standard、High 或 Max，运行时编排引擎再决定调用哪些模型、如何组合。

原文列出的模型池包括 Claude Opus 5.5、Claude Sonnet 5.5、GPT-6 Astra 和 GPT-6 Sol，并称调用范围受企业或组织策略限制。计费按参与模型的标准价格累计，没有单独的 Fusion 费用；付费套餐的模型费用优惠为 30%，截至 2026 年 11 月 30 日。这些均为原文陈述，本篇没有进行外部核验。

这里最有用的思路，是把「选模型」从固定配置变成每次请求的决策。普通编辑可以直接交给中档模型；明显困难的请求，也没有必要先付一次便宜模型的试错成本。

便宜模型能不能用，取决于检查关卡

Cascade 的关键是 judge，也就是决定草稿是否合格的检查关卡。

省钱的前提，是你能用较低成本识别不合格答案。

检查过严，每次都升级，最后支付的是便宜模型加旗舰模型两笔费用。检查过松，错误答案直接流出，质量取决于便宜模型的发挥。

作者建议优先使用单元测试、lint、类型检查和 schema 校验。这对代码任务确实有吸引力：返回值是否符合结构、代码能否通过类型检查，往往能自动判断。但测试只能覆盖已经表达出来的要求，不能被当成完整的正确性证明。需求理解错了，代码仍可能通过现有测试。

开放式写作更难检查，往往需要另一个模型按评分标准评审，即 LLM-as-judge。它会增加调用费用，也可能和起草模型犯同类错误。

原文的 Python 示例包含 cheap_draft、flagship_answer、judge 和记录结果的 RouteDecision。升级时把失败草稿传给旗舰模型，让它基于已有内容继续处理。下面这行负责返回升级后的结果及路由记录：

return answer, RouteDecision("flagship", True, False, cost)

要看清其中的 False：它对应前一份草稿未通过检查，并不表示旗舰答案已经被验证。示例没有对旗舰输出再次调用 judge。

而且，输入中的代码已经出现换行和格式损坏，不能直接复制运行。它还定义了 looks_complex，用超过 120 个词，以及 refactor、rewrite、architecture、multi-file、race condition、deadlock、concurrency、root cause、debug 等信号识别复杂请求，但 route 没有调用这个函数。所谓「复杂任务直接走旗舰」停留在说明中，尚未接入示例流程。

judge 的实现也只是检查空格和文本长度，长度条件为大于 20、小于 4000。这样的占位逻辑无法判断程序是否正确。它能说明路由结构，不能支撑生产质量承诺。

省下多少，得把每次调用都算进去

原文引用 Artificial Analysis 的 Coding Agent Index：Fusion Max 每任务平均花费 $5.59，Claude Code 运行 Opus 5.5 Max 为 $11.42，约低 51%；分数相差不到两分，每任务耗时约少 40%。

作者同时提醒，这是被厂商发布材料引用的基准成绩，尚无独立方法审计。原文也没有给出他们团队在真实业务中持续运行的账单，因此不能把这些成绩当成所有代码任务的收益保证。

更直接的问题出在文章的成本示例。

作者假设每天 1,000 个请求，每个 2,000 tokens，检查通过率 80%；便宜模型每百万 tokens 为 $0.15，旗舰模型为 $3。全部使用旗舰模型，每天 $6.00。

随后原文却按每次便宜调用 $0.00075、每次升级约 $0.00675 计算，得到 800 次便宜请求花费 $0.60，200 次升级花费 $1.35，合计 $1.95，宣称节省约 67%。

这些单价与前面的 token 数量对不上。

如果每次便宜调用确实只计 2,000 tokens，费用应为 $0.00030；升级时再增加一次同为 2,000 tokens 的旗舰调用，单次合计为 $0.00630。按这个简化口径，总费用为 $1.50，节省 75%。原文没有说明 $0.00075 是否包含额外上下文或其他 token 开销，无法替它补齐。

文章能说明路由可能省钱，但它给出的算式不能直接拿来做预算。

代码里的 CHEAP_RATE = 0.00015 和 FLAGSHIP_RATE = 0.003 按每千 tokens 计费，与上述每百万 $0.15 和 $3 对应。真正接 API 时，还需要分别统计输入、输出、评审调用，以及升级时携带草稿的成本。原文没有展开这些差异。

我的判断

我认同作者把注意力放在质量关卡上。相比反复调整「哪个模型更强」，先明确什么结果可以接受，更容易形成可维护的工程流程。

但「便宜模型先跑一次」不适合成为无条件默认值。原文自己也建议，多文件修改、需求含糊、安全敏感代码，以及验证错误草稿比生成正确答案还费事的任务，可以直接使用旗舰模型。日常编辑用中档模型执行 Single，也可能比维护路由更划算。

与 prompt caching、batching、semantic caching 相比，路由改变的是由谁完成请求、需要执行几步；这些缓存和批处理手段可以与它叠加。原文没有给出统一条件下的对照数据，无法判断哪种手段应当优先投入。这部分仍是工程经验。

还有两个边界不能漏掉。按原文描述，Fusion 没有独立的上下文窗口，每一步受当次模型限制，界面显示的是模型池中最小的窗口。更关键的是，草稿即使后来被丢弃，已经写入文件的修改也不会自动回滚。对于 AI 编程，拒绝一个答案和撤销它的操作，是两件需要分别处理的事。

本地开放权重模型也能充当便宜起草者，但原文没有核算硬件和运维费用，不能直接把本地部署等同于零成本。

能拿来做什么

• 给前端或 Node 的 AI 功能试接路由时，先选能自动验收的任务，例如输出必须通过 schema 校验的结构化生成，并提前定义失败条件。
• 在日常 AI 编程中，把类型检查、lint 和相关测试作为升级依据，同时保留人工审查需求与边界行为的环节。
• 记录每次请求的模型、输入输出 tokens、检查结果、升级次数和总费用，用同一批任务与固定模型方案比较，再判断路由是否值得维护。
• 让会修改文件的草稿运行在独立分支或工作区，明确失败后的清理方式；复杂任务则允许跳过便宜阶段，直接交给更合适的模型。