小模型先答未必省钱：级联成本怎么算

先让便宜模型回答，失败再转给强模型，账单一定更低吗？dev.to 一篇文章比较了五组模型组合：把小模型通过率统一设为 70%，有的组合能省 65%，有的反而多花 5%。关键在于，小模型失败的那次调用也收费，而且 70% 是演算假设，并非实测结果。

目前能确认什么

这种调用方式叫级联（cascade）：每条请求先调用小模型，检查答案，通过就返回，失败再调用大模型。因此，所有请求都承担小模型费用，未通过的请求还要再付一次大模型费用。

设小模型单次成本与大模型之比为 r，通过率为 p，在暂不计答案检查等额外开销的简化条件下：

级联成本 ÷ 全部使用大模型的成本 = r＋1－p。

只有 p＞r，级联才有节费空间。

作者用「把客户邮件转成六字段 JSON 工单」作为算例。这里的 r 是单次调用成本之比，不能直接拿模型的每百万 token 标价相除：输入、输出长度及推理 token 都可能改变实际费用。

我的判断

对程序员来说，这个公式适合做实现前的第一道筛选。如果小模型通过率仅略高于成本比，加入答案检查费用后，省钱空间可能就没了。

更关键的是「通过」如何定义。作者示例只检查 JSON 能否解析、字段是否齐全；订单号填错，也可能通过。这个通过率衡量的是格式合规，不能直接当成任务正确率。

检查器放过的错误，不会自动转交给大模型。

因此，结构化抽取可以先验证格式，但还要单独衡量字段内容是否正确。自由文本若需要第三个模型评分，就必须把评分费用一起计入。失败请求还要顺序等待两次调用，成本下降也不代表响应更快。

目前节选没有提供真实任务通过率、语义错误漏检率和端到端延迟数据，尚不足以判断具体组合是否适合上线；模型价格与计费细节也仍需官方文档核对。