大模型开始自己排班：LLM 路由落地时我踩到的三个坑
一个团队把大模型接进工单系统三个月后，发现账单涨得比调用量还快。原因不复杂：所有请求都走同一个旗舰模型，而真实流量里六成是「把这段文本压成三行摘要」这种活。
现在的通行做法是在前面加一层路由器：轻量模型先判难度，简单任务就地解决，复杂任务才升级到旗舰。几家云厂商的推理平台都做过类似的分级调度，OpenAI 兼容接口里模型名本身也就是一个可路由的参数。方向没问题，坑在后面。
坑一：分类器自己就是不确定性来源
用 7B 模型当路由，它判断「这条需不需要升级到 200K 上下文的旗舰」这件事本身就会出错，而且错得很安静：它把复杂请求判成简单，直接交给弱模型作答，输出的仍然是格式正确的文本。
我们最初的监控完全没发现，直到人工抽检才看到一批「看起来对但结论错」的样本。后来加了两条硬规则：凡是带多步推理信号（「证明」「为什么不一致」「比较这五个方案」）一律不走小模型；路由置信度低于阈值直接升级。路由器宁可过度升级，也不能漏判。
坑二：升级链路会把上下文撕碎
小模型读完三十轮对话，觉得需要升级，把请求交给旗舰模型。如果传的是小模型写的摘要，旗舰拿到的信息已经损失一半；如果传原始全量，那小模型省下的钱又还回去了。
比较务实的做法是给路由层一个「证据清单」：小模型不产出摘要，只产出它认为相关的片段编号，升级时按编号拼原文。这样既不做有损压缩，也不会把整个会话搬上去。代价是路由层的输出结构变复杂了，必须严格约束成 JSON，否则解析经常崩。
坑三：路由决策没有可观测性，就无法复盘
上线两周后想回答「这次成本下降到底是路由的功劳还是模型降价」，没有原始决策记录就完全无法归因。
我们在网关侧只记三样东西：进入路由的请求指纹、命中的模型、升级原因（关键词命中 / 置信度低 / 用户显式指定）。字段不多，但足够把每一次成本波动拆到具体规则上。真正有价值的发现是：升级原因里「置信度低」的占比在两周内从 21% 降到 6%，说明业务侧的提问方式在变短。这类趋势只看总量是看不出来的。
我的看法
大模型这一轮工程化，重点正在从「模型能做什么」转向「系统怎么分配模型」。这跟早年做微服务拆分的逻辑一模一样：先有能力，再有能力之间的调度，最后调度本身变成新的瓶颈。
路由不是省钱开关，它是对质量与成本的一次重新定价。只把它当降本手段，三个月后一定有人拿着错答的截图来质问；把它当成一层有明确责任边界的服务，配上错误率指标和降级路径，它才真的能留在架构里。
模型会继续变便宜，但「用哪个模型」这个决策不会消失，只会从人手里挪到系统里。早点把它当成一等公民来设计，比省下的那点账单更值钱。