几乎所有团队引入多模型路由时，都会先掏出计算器敲一遍：简单的任务甩给便宜模型，难题才上旗舰模型，再备个兜底方案应对某个服务商抽风。表格上的数字好看得让人心潮澎湃，单次推理成本腰斩，端到端质量还守住了。可这套算术一旦撞进真实的生产流量里，账本就开始朝意想不到的方向狂飙——你以为省下的每一分钱，最后都加着利息吐了出去。

我是在一个真刀真枪的KYC（客户身份核验）系统里吃尽了这个苦头。这个系统关系到实打实的合规风险，一句错误的结论可能带来的不是准确率下降几个点，而是监管重锤。在这个项目上，挑选用哪个大语言模型反而是最简单的环节。真正的工程地狱全都藏在路由决策的缝隙里：怎样才能知道某条路正在静悄悄变差？启用兜底模型时，延迟和准确率到底要付出多大代价？如何分辨一个便宜模型的输出是真正完成了任务，还是只是碰巧输送了一段看起来没毛病的文本？这些才是行业里几乎没人向你预警的暗礁。

下面，我把在生产中亲手踩出的三个最大深坑摊开，每一个都曾让团队在深夜复盘时冷汗直流。

坑一：算账时看不见的“重路由税”

团队第一个反应就是把路由规则绑在成本上：感觉简单的请求优先发给小模型，只有触发某种升级条件才把任务转给大模型。这听起来天经地义，因为小模型每次调用的单价确实低得诱人。可一旦系统跑起来，你就会发现那份成本账单只算了一半。

当小模型给出的结果被判定为错误时，你不得不把同一个请求再交由大模型处理。这下子，一次本该便宜了结的操作，瞬间变成了两张账单，外加两轮请求的往返延迟，还要搭上检测错误所花的计算开销。更扎心的是，如果你的路由门槛设得稍微冒进一点，就会发现相当大比例的流量都在同时为便宜模型和昂贵模型付款，最终端到端的延迟甚至比一早就直接使用大模型还要糟糕。

这个陷阱的核心在于：单个Token的单价是明晃晃挂在外头的数字，而重路由的“隐性税”却不会自动跳出来示警。你很容易只看到那些顺利过车的小模型调用省了多少钱，却根本感知不到那些翻车之后引发的连环成本。多数团队根本没为这一环设计足够的监控，于是不由自主地朝着一个隐藏着自己反噬效应的数字拼命优化。

真正该被祭上优化神坛的，不是单次调用的单价，而是端到端的“单次成功任务成本”——把重试成本、升级调用开销、检测环节消耗统统打包进去。只有在算清楚便宜模型究竟失败了多少次之后，你才有资格说它到底值不值得留在那条路由路径上。

坑二：延迟是一团会自由变形的迷雾

第二个大面积翻车的认知是，许多人把服务商的延迟当成一个可以查一次就刻在脑子里的静态参数。但真实世界里，延迟是一张活生生的分布图，它会随着服务商自身的负载变化、一天中的时间段、请求的上下文长度，以及你的账号在容量吃紧时会不会被降级处理而剧烈晃动。

倘若你的路由逻辑只盯着延迟的中位数作决策，那它会在服务商的尾部延迟突然爆掉时依然欢快地向前引路。一个小时前看起来利落的中位数，此刻已经毫无意义，而你那百分之九十九分位的用户，正在被你亲手选择的缓慢路径死死拖住。如果你还在上头叠加了超时触发的兜底机制，那么“兜底”非但不能削峰填谷，反而会堆叠出更可怕的等待时间：用户首先干等着第一个模型慢慢超时，然后再从头耗上第二个模型的完整处理周期，总延迟往往比直接选用强模型还要惨烈。