三档路由：大多数请求根本用不到旗舰模型

$325 和 $21.25。

同一批 1 万条请求，同一家供应商的同一张公开定价页，最贵的那种算法和最省的那种算法之间，差 15 倍。

而这 15 倍里，只有 5 倍是"换一个便宜模型"换来的。剩下的 3 倍在别的地方，大多数人一次都没去动过。

先把这篇文章不给什么说清楚：它不给任何一家网关的实际配置，也不推荐任何具体型号。它给的是一套分档与升降档的判断规则，规则里的阈值是我给的建议值，不是任何一家的实测结论。价格演算全部用一家供应商公开定价页上的挂牌价，理由在第一节。

一、先算清楚"换模型"这件事的上限

先说为什么只用一家的价目表。跨厂商比价有两个麻烦：一是币种不同，二是各家的档位划法不同。而分档路由这件事要回答的是"同一件事放低档还是放高档"，这个问题只有在同一张表、同一套计价规则里才是可比的。所以下面的演算全部取自 Anthropic 官方定价页上三个带日期版本号的型号：`claude-opus-4-5-20251101`、`claude-sonnet-4-5-20250929`、`claude-haiku-4-5-20251001`。选这三个不是因为它们最好，是因为它们的发布时点就写在型号名里，可以核验。该页未标注发布日期，本文所引为 2026 年 5 月中旬页面上的内容。

三个型号的挂牌价（每百万 token，输入 / 输出）：Opus 4.5 是 $5 / $25，Sonnet 4.5 是 $3 / $15，Haiku 4.5 是 $1 / $5。

下面设一个口径。假设一条请求输入 3,000 token、输出 700 token，合计 3,700。这个 3,700 不是我编的，它对得上同一张页上那个客服工单算例里的平均对话长度；但 3,000 与 700 这个拆分是我设的假设值，你换成自己业务的真实值再算一遍，结论的形状不会变。

1 万条请求：

$325 ÷ $65 = 5 倍。这就是"只靠换模型"能拿到的全部空间。

顺带把那个官方算例核一下，因为很多人会直接抄它。该页写的是：1 万个客服工单，平均每次对话约 3,700 token，用 Haiku 4.5（$1 输入 / $5 输出），总成本约 $37.00。把 3,700 × 10,000 = 3,700 万 token = 37 个百万，乘 $1，正好 $37。也就是说，这个算例把 3,700 个 token 全部按输入价算了，输出那一侧没有单独计价。 这一步除法是我自己做的。结论不是它错，是它只能当作一个下限来读——只要有一个 token 落在输出侧，你的真实账单就会比它大。照抄别人的算例去做预算，和不算是一回事。

接着算剩下那 3 倍，它在两个和模型无关的地方。

第一个地方是缓存。 同一张页上写着提示词缓存的计价规则：5 分钟档的缓存写入是基础输入价的 1.25 倍，1 小时档是 2 倍，而缓存命中（读取）是基础输入价的 0.1 倍。页面自己给了回本条件的原话：5 分钟档"caching pays off after one cache read"，1 小时档"after two cache reads"。

把这条规则套进上面的口径。假设那 3,000 个输入 token 里有 2,500 个是每次都一模一样的（系统提示词、判断标准、产品规则文档），另外 500 个才是这一条的真实内容：

• →Haiku 4.5：500×1 + 2500×0.1 + 700×5 = 4,250 → 1 万条 $42.5
• →Opus 4.5：500×5 + 2500×0.5 + 700×25 = 21,250 → 1 万条 $212.5

什么模型都没换，Haiku 那一档从 $65 降到 $42.5。

第二个地方是批处理。 同一张页写着 Batch API 对输入和输出同时打五折。不赶时间的活走异步，Haiku 那一档再从 $42.5 降到 $21.25。

于是最贵与最省的两端出来了：Opus 4.5 按标准价的 $325，对 Haiku 4.5 加缓存加批处理的 $21.25。$325 ÷ $21.25 ≈ 15.3 倍。其中换档贡献 5 倍，缓存与批处理贡献 $65 ÷ $21.25 ≈ 3.06 倍，5 × 3.06 ≈ 15.3，对得上。

所以顺序是这样的，不要换：

第 1 步，先把固定不变的那一段提到请求最前面，让它能命中缓存。 这一步不影响输出质量，只影响你把哪些字放在前面。

第 2 步，再把不赶时间的活挪到异步队列走批处理。 这一步也不影响输出质量，只影响客户什么时候看见结果。

第 3 步，最后才做分档。 分档是这三步里唯一一件会影响输出质量的事，所以它排最后。前两步没做完就先动模型的人，等于先接受了质量风险，却把不用担风险的那三倍留在桌上。

同一张页上还有一句供应商自己写的建议，可以当旁证读：简单任务用 Haiku、绝大多数生产负载用 Sonnet、最复杂的推理才用 Opus。卖模型的一方自己都没让你全用最贵那档。

二、三档怎么分：三条准入条件，答不上来就别往下走

分档不是按"难不难"分。难不难是个感觉，写不进规则里，两个人会分出两套结果。

我的建议是按这条请求的输出会不会在没人看过的情况下就产生后果来分。这一条能被写成规则，也能被两个不同的人分出同一个结果。

低档的准入条件（三条全中才算）：

• 1你能写出一条不靠人就能判对错的校验规则。比如输出必须是给定选项之一、必须是合法日期、必须能和库里某条记录对上。写不出来的，不进低档。
• 2这条请求的输入长度和结构，落在你给低档设的界之内。界要写死一个数，比如"一次最多读一份文件"。
• 3校验没通过的时候，丢掉重来的代价可以接受。低档的正确用法是允许它失败，因为失败会被规则拦住。

中档的准入条件（两条全中）：

• 1需要判断，但错了会被下一道工序拦住。这道工序可以是人，也可以是另一段程序。
• 2那道拦截工序的成本，低于换成旗舰要多花的钱。这一条要算，不要估——把第一节那张表里的差价除以你团队的时薪，得到一个小时数，如果人工复核这一万条花的时间少于它，就该留在中档。

旗舰档的准入条件（一条中即可）：

• 1输出之后没有第二双眼睛，或者错了不可撤回。对外发出去的条款、给客户的报价、写进合同的口径，都在这一档。

三档写完之后有一件事必须做，而且必须写在纸上：每一档只留两家供应商，一主一备。留两家是因为你依赖的那个型号有一天会下线；只留两家是因为适配一家要花人，第三家的边际收益接不住那笔人力。

再强调一次开头那句：上面这套是判断规则，不是任何一家的实际配置。 谁给你一份"三档就该配这三个型号"的清单，先问他一句：你的低档那条自动校验规则是什么。他答不上来，那份清单对你没有意义。

三、升档、降档、兜底，和一条不许超的上限

分档只解决了静态那一半。真正会在上线第二周把你拖垮的是另一半：这条请求什么时候该从低档升上去，什么时候能降回来，升上去还是不行怎么办。

升档只允许三种触发，而且必须是可判定的：

• →触发一：低档的输出没通过那条自动校验规则。
• →触发二：这条请求的输入超过了低档的界（比如要同时读三份文件）。
• →触发三：这条请求被标记为"要直接发给外部的人看"。

三种之外的任何理由都不许升档。特别是"我觉得这条比较重要"——这句话不是触发条件，它是每个人都能随口说出来的话，一旦允许，一个月之内所有请求都会变成重要。

升档只升一档，不许直接跳到旗舰。 低档不过去中档，中档不过才到旗舰。跳档的人拿不到中间那一层的数据，永远不知道自己的中档到底有没有用。

同一条请求最多升一次。 升到中档还是没通过校验，不要再往上送。这时候正确的动作是下面那条兜底。

兜底的方向是转人工，不是转更贵的模型。 这一条是全文最想让你记住的一句。升档失败之后再往上送，等于用最贵的单价去重复做一件已经失败过两次的事，而且失败原因通常不在模型上——是输入本身有问题、规则本身写错了、或者这类请求压根不该自动化。所以第三次的落点是人工队列，同时给发起方一个明确的状态："这一条要等人看"。不要让它安静地失败，也不要让它安静地变贵。

降档要跑满两周才能动。 连续两周，某一类请求的升档率低于 5%，才允许把这一类整体降一档；不满两周不许降，因为一周的数据里通常还没出现那类每周只来一两次的怪请求。降完之后再跑满两周，观察升档率有没有弹回去。

最后是那条不许超的上限：旗舰档的调用条数，不许超过总条数的一成。

超过一成，不要去找供应商谈折扣，也不要去优化提示词——回去改分档规则。一成这条线是我给的建议值，你可以定得更严；重要的不是这个数，是你每个月真的去数一次这个比例。多数人没数过，所以他们的账单结构永远长成"少数请求吃掉大半预算"的样子，而且找不到原因。

配套要记的账只有三个数，多了没人记：每一档的调用条数、升档率、旗舰档占总账单的比例。 每月同一天量一次，条件不变才有可比性。

四、什么时候不该这么做

第一，账单太小的时候整件事都不划算。 按第一节的口径，月一万条请求全走中档也就一百多美元。为了省下一百多美元，占用一个人两周去写校验规则、改队列、设监控，这笔账是亏的。先把量做起来。 账单变成一个每月都要看一眼的数字之后，这套才有意义。

第二，缓存不是白给的。 那张页写着缓存写入是基础输入价的 1.25 倍到 2 倍——第一次是更贵的。5 分钟档要至少命中一次才回本，1 小时档要两次。如果你的输入每次都完全不同，缓存价对你就是一个永远用不上的价格，第一节那 3 倍里有一部分要划掉。

第三，批处理是拿时间换的。 五折的前提是这件事可以异步。客户在对话框里等着的请求不能走批处理，硬走就是把省下来的钱赔在体验上。

第四，低档省下的钱可能全赔在人工复核上。 判断线自己算：贵档与便宜档的账单差，除以你团队的人工小时成本，等于你能承受的额外复核小时数。 超过这个小时数，你不是在省钱，是把钱从模型账单挪到了工资单上，而且挪多了。这条线每家不一样，因为人工成本不一样——别抄别人的分档结论，抄这个算法。

第五，一个人的公司先别做三档。 一个人同时维护三条路径、三套校验规则、一条人工队列，多半会漏。我的建议是先做两档加一条人工兜底：一个便宜档、一个旗舰档、中间那层等到升档率的数据攒够两个月再补。少一档，规则简单一半，而省钱空间还剩下四分之三。

第六，如果你连一条自动校验规则都写不出来，这套暂时不适用。 那说明这类请求的"对"还没有被定义清楚。先花一周把"什么样的输出算对"写成一句能被程序判断的话，再回来分档。这一步跳过去，低档会变成一个持续产出错误、而且没人发现的通道。

先固定规则，再谈省钱。规则里最要紧的三行是：低档的那条校验规则、升档的三个触发、以及旗舰档不许超过一成这条上限。这三行写死了，剩下的都是执行。

这套兜底规则的完整模板与阈值表，在《数字员工搭建实战》第 5 课里有配套的清单。