Haiku + Sonnet + Opus 三级路由：我的真实流量分布和账单

做产品的都知道一个事：Claude 三个模型的单价差很大。Haiku 4.5、Sonnet 4.5、Opus 4.5 之间 input 价差大概是 1 : 3.75 : 18.75 这样。意思是一次 Opus 调用 = 18.75 次 Haiku 调用。

但大家看定价表经常陷入一个误区：以为便宜的模型就是性价比高。其实要看「每美元产生多少业务价值」。一个 Haiku 回答不了的问题用 Haiku 十次也是浪费，一个简单分类用 Opus 也是浪费。

所以关键不是「用哪个模型」，而是「什么问题用哪个模型」。我摸了快一年才总结出当前这套路由，下面晒真实数据。

两次翻车：全 Sonnet 和全 Opus

先讲两次失败让大家避坑。

去年 3 月，全 Sonnet 部署。

那时候 Sonnet 4.5 刚出，大家都说性价比之王，我脑子一热把所有链路都切过去。月账单：$8,421.67。

问题出在两头：一头是大量简单分类任务（「这个工单是账号问题还是账单问题」），本来 Haiku 三毛钱能解决的，Sonnet 去做每次 $0.012，流量一大就烧钱。另一头是少数难任务（复杂合同审查），Sonnet 准确率只有 73.8%，错的那些还得人工兜底，时间成本比模型成本高多了。

去年 7 月，all-Opus 实验周。

产品经理听说 Opus 4.5 什么都能干最好，推我做了一周 all-Opus 实验看效果。第一天就花了 $1,053。一周打完 $6,847.22。

准确率确实涨了（从 Sonnet 的 91.2% 涨到 96.7%），但成本涨了 3.4 倍。ROI 算下来根本不合算。更要命的是 Opus 的 latency 平均 5.2 秒，用户投诉响应慢。

两次翻车之后才老老实实搭三级路由。

三级路由的决策框架

核心思路：每个请求进来之前，先花很小的代价判断「这个任务多难」，再分配给合适的模型。

我现在的决策器有三层：

第一层：任务复杂度分类器。

一个 Haiku 调用。prompt 很简单：给它任务描述（通常就是用户输入的前 300 字），让它判断属于 easy / medium / hard 三档。带一个 20 条的 few-shot。

每次 $0.0003 左右。贵吗？月流量 100 万次请求也就 $300，相比下游省下来的几千刀值回来。

分类逻辑的大致规则是：

• easy：明确答案的事实性问题、格式转换、简单分类、FAQ 查询
• medium：需要推理的问答、多步骤但路径清晰、带简单工具调用
• hard：开放式创作、复杂推理链、长文档深度分析、多 agent 协作、合同/代码审查

第二层：token 消耗预估。

easy 直接路由到 Haiku，但 medium 和 hard 还要再判断一次：这个任务预估要多少 input / output token。

预估办法很糙：input 直接数字符数 ÷ 2.5。output 按任务类型预设（分类 30、答复 200、摘要 500、报告 2000），让分类器同时输出一个「estimated_output_length」。

为什么要预估？因为模型价差会被 token 数放大。一个 hard 任务如果预估 output 只有 100 token，Opus 跑成本 $0.008，可以承担；如果预估 output 3000 token，Opus 跑 $0.235，就得考虑是不是要拆成多段或者改用 Sonnet。

第三层：预算约束。

每个租户有一个日/月 budget。如果这个租户今天剩余预算不多，难任务强制降级到 Sonnet。预算快见底的 warning 状态下，再难的任务也走 Haiku 或者直接拒绝。

这层的细节挺多，具体做法我在 Haiku 路由降本 里写得更细致。

当前 SaaS 的真实流量分布

我目前主力 SaaS 产品（做法律文档辅助的工具）上个月的实际数据：

流量占比（按请求数）：

• Haiku 4.5：63.2%（主要是分类器本身 + FAQ + 简单字段抽取）
• Sonnet 4.5：31.4%（主力：合同问答、起草、多轮对话）
• Opus 4.5：5.4%（疑难：复杂条款审查、批量文档比对、长推理链）

账单占比（按花费）：

• Haiku：15.2%（$319.42）
• Sonnet：58.1%（$1,220.47）
• Opus：26.7%（$561.13）
• 合计 $2,101.02

Haiku 跑了 63% 的流量只花了 15% 的钱，承担了「量」。Opus 只跑 5.4% 的流量但吃了 27% 的钱，承担了「难」。Sonnet 夹在中间是真正的主力。

这个分布我觉得是健康的。如果 Haiku 占比 < 40%，说明路由器太保守，有很多简单任务被浪费给 Sonnet 了；如果 Opus 占比 > 15%，说明要么 Sonnet 能解决的问题被错分给 Opus，要么产品本身的任务复杂度分布就是偏高，需要重新看 Opus 任务能不能拆解。

分类器本身怎么做

很多人卡在这一步：「我怎么判断一个任务多难？」

我的做法是写 20-30 条 few-shot 例子，覆盖常见任务类型。每条例子的格式：

1
2
3

任务描述：xxxxx
难度：easy / medium / hard
理由：xxxx

加理由的好处是 Haiku 会学到判断逻辑，而不只是 memorize 例子。关于 chain-of-thought vs direct 的取舍，这里是个明显适合带简化 CoT 的场景。

分类器 prompt 做完 cache，每次实际调用只有用户输入那段是 fresh 的，cache hit 率稳定在 94% 左右。单次成本降到 $0.00018。一个月分类器自己的账单大概 $95-110。

准确率怎么衡量？我每月会人工标 200 个样本，对照分类器结果算准确率。当前在 89.7%。错的那 10% 里大部分是 medium / hard 的边界模糊，实际路由到 Sonnet 或 Opus 都能完成，影响不大。真正致命的是 easy 误判为 hard（浪费钱），我对这类错误特别敏感，占比大概 1.2%。

每美元价值这个指标

前面说了别只看单价。我用的一个内部指标叫「$1 produced value」，意思是每花 $1 能产生多少有效业务结果。

定义是：成功完成的任务数 / 总花费。

实测数据：

• Haiku 单独：成功率 71.3%（有 28.7% 的任务 Haiku 做不好需要 fallback），$1 = 332 次成功任务
• Sonnet 单独：成功率 92.4%，$1 = 76 次成功任务
• Opus 单独：成功率 97.1%，$1 = 16 次成功任务
• 路由版：整体成功率 93.8%，$1 = 142 次成功任务

路由版的每美元价值是 Sonnet 单独的 1.87 倍，是 Opus 单独的 8.9 倍。这个数字就是我说「路由比选贵的好」的依据。

踩过的坑

分享两个：

坑一：分类器不要依赖上下文。

我一开始把多轮对话的历史也塞给分类器，想让它根据对话上下文判断。结果分类器变贵了（input token 涨），准确率反而掉。后来改成只看本轮用户输入，准确率反而上升。

坑二：hard 任务不要无脑 Opus。

有段时间我 hard 档直接走 Opus，结果发现某些 hard 任务其实是「长但不复杂」。比如一份 8 万字合同的字段抽取，单次调用确实长（属于 hard），但推理本身不难。这种应该走 Sonnet + 上下文压缩 + 上下文预算 策略，比 Opus 便宜 6 倍且效果几乎一样。

现在我的 hard 档里还有一个二级判断：长度 hard 走 Sonnet + 压缩，推理 hard 才走 Opus。

收尾碎碎念

路由器这东西看起来简单，实际落地细节非常多。分类器的 prompt 要调、边界样本要标、预算阈值要跟业务校准。我前后做了三版分类器才稳定。

但投入绝对值得。同样的产品、同样的功能、同样的用户体验，全 Sonnet 版 $8,421 / 月，路由版 $2,100 / 月，省下来的 $6,300 是净利润。

如果你现在还在单模型部署，花一两周搭个路由是 ROI 最高的事。