LLM 路由器是什么？
简单说，是系统里多出来的一个小模型，专门决定每个请求交给谁答。小的答得动就走便宜路径，答不动再交给贵的那一个。
多数人把它当成本开关。它不是。它是一个决策者，只是没人给它做过评估。
这个月早些时候有人写了篇长文专门讲这件事。我看了两遍。第一遍觉得是工程细节，第二遍才反应过来它在说什么。
小模型交出一份格式全对、数字全错的账单
这条我最想抄下来。
按比例分摊算错了一位。schema 校验通过，字段齐全，格式漂亮，没有一条告警响。仪表盘上写的是：路由成功。
这类错不会升级。升级的触发条件是“看起来不对”，而它看起来非常对。
教程里的级联长这样：小模型先答，looks_ok 通过就返回。没人细说 looks_ok 里到底查了什么。查得宽，错误答案一路放行。查得严，本来合格的答案被丢掉，白等一次，白付一次。两头都是钱。
文章说这些场景是示意性的，不是哪次真实部署的复盘。这免责声明我不太信。那些细节太像真踩过的。
难度不是请求的属性
拿提示长度、关键词表、人工标注的易难分类器去猜“这题难不难”，基本不成立。
难度是相对模型而言的。一句短得离谱的正则边缘请求，对小模型是硬骨头。几千字的会议摘要，它可能干得挺好。
用长度代理难度，等于把人的直觉编码成了生产决策。而那个直觉没有被测量过。
翻译一下：你不能用题面多长，去判断这题对谁难。
升级率高的时候，你付了两次钱，还更慢
级联的默认叙事是“大部分请求走便宜路径，平均成本就降下来了”。
问题出在平均。某一类任务升级率一高，那类请求就是实打实调了两次模型，还要加上校验和重试的时间。平均延迟把这件事盖得干干净净。
有几类请求，直接调大模型更快也更简单。这话不好听，但对。
错误的代价不一样，路由器不知道
内部草稿生成器答错了，浪费几十秒。合规摘要答错了，或者一段要上线的代码改动答错了，是另一回事。
只按 token 花费去调路由器，等于对所有请求一视同仁地省小钱，然后在最不该省的地方省。
验证本身也要钱
评论区里有人提了个更硬的角度。级联悄悄漏钱，是因为它默认了假阳性和假阴性的代价对称。实际远不对称。
他的解法是把可接受的尾部错误率压到接近零，让升级率跟着经验分布浮动。这套我没有完全吃透，先放在这里，搞明白了再补。
作者回了一句我认同的：验证不便宜。你要另一个模型来判断答案对不对，那每个请求就多一次调用、多一段延迟。有些情况下，直接调强的那个更划算。
后面有人把这条讲得更清楚。schema、AST、单元测试、正则这类结构验证，成本接近零，适合塞进级联。需要模型做语义判断的那些，小模型加裁判加前沿模型这个组合，成本可能超过直接调前沿模型，还把 p95 拉长。
被丢掉的那份草稿也是钱
有人建议把“假升级”当成正式指标来测。被丢弃的小模型草稿留着，抽样打分。
同一份评分预算，能同时拿到两个错误率：接受了但答错的，和升级了但本来合格的。后者平时根本没人看。
要测什么
文章末尾给了一份清单，我抄一遍。
按任务类型看升级率，不看全局平均。 抽样给路由之后的答案打分，算出“校验通过但答案错误”的比例。 端到端延迟要含重试和校验，看 p95，不看平均。 每请求成本要带上错误估计成本，不只是 token。
第一项和第三项大多数团队有。第二项是多数人缺的，也是唯一能回答“便宜路径到底便宜不便宜”的那一项。
边界从哪开始
文章给了个起点，我觉得够用。
输出可验证、错了也便宜、或者下游能兜住的，走小模型。结构化抽取、固定标签分类，都是这一类。 错误昂贵、又不容易自动检测的，直接走大模型。 模型换了、prompt 改了、流量结构变了，全部重测。
最后一条最容易被忽略。路由器的行为跟流量分布绑着。用户变了，它就不再是原来那个路由器。
我这次想说的就一句
模型路由不是“加个分类器省点钱”。它是一个决策系统，该拿到跟面向用户的那个模型同等的评估纪律。
现在的普遍做法正好反过来。主模型被反复评测，写 eval，做回归。路由器上线以后没人碰。它的错误不报警、不进日志，只体现在账单和某个说不清来源的客诉里。
这种“系统里多出来的那个模型没人管”的毛病，我之前在 agent 的工具选择上也碰到过。同一个病。
对普通人来说，这条的用处是反过来看：以后在设置页面看到“自动选模型”“智能分流”这类开关，心里要有个数，它可能正在悄悄答错，而且没人给它打分。
本周就这些。
上面有任何一条你试过、或者觉得我讲错了，欢迎告诉我。讲错的我补，没讲清的我改。
下周见。