30%流量省30%成本：LLM路由的四种实现路径

上个月看LLM账单时，最肉疼的不是那些复杂问题。是"你好""谢谢""查余额"——这些简单查询被你用旗舰模型处理，只因整个产品只接了一个模型ID。每个简单请求都走最贵的通道，账单自然难看。

路由能解决这个问题。不是负载均衡，不是故障转移，不是功能开关。是像CDN那样路由：每个请求发给能正确回答它的最便宜模型，其余的走强模型。在B2B客服场景里，短问题占很大比例，把底部30%流量（按复杂度）发给小模型，能在不降低评估质量的前提下砍掉约三分之一成本。这里的数字只是示意起点，你需要根据自己的评估调整。关键是：怎么判断这30%是哪些。

四种路由模式反复出现。它们的搭建成本、出错时的爆炸半径、能分流的上限各不相同。选错要么省不下钱，要么质量回退一周后才被发现。

一、长度截断：一行代码

最便宜的方案。一个条件判断。前提假设：30个token的问题很少是难的，6000个token带三个PDF附件的几乎肯定是难的。这个假设大体成立，就够了。

400字符大概是一段话。低于这个数，请求可能是问候、确认、单行查询。高于这个数，就进入强模型值得加价的领域。

为什么对某些工作负载有效：多数B2B聊天产品的输入长度分布是重尾的。众数在短的那头。如果分布的头部够胖——多数工作负载确实如此——仅靠长度截断就能把真实流量移到便宜通道，无需改动其他。

为什么失效：短不等于简单。"用Rust反转二叉树"又短又难。"把一万字文档翻译成要点"又长又简单。长度只是难度的代理。代理成立的工作负载，一行代码就能上线。不成立的，得往列表下方看。

二、级联路由：需要评估、监控、可信的信心信号

下一级。训练（更常见的是手写）一个微型分类器，在请求触碰LLM之前给它打标签。标签是"简单/复杂"或具体模型名。分类器可以基于关键词、正则、轻量嵌入，或一个微调的BERT级模型。

级联的核心是信心阈值。分类器输出概率，概率高于阈值走便宜模型，低于阈值走强模型。阈值调得太激进，简单问题漏给强模型，浪费钱；调得太保守，复杂问题发给弱模型，用户遭殃。

监控是关键。需要记录每个路由决策、实际调用的模型、用户后续行为（是否重问、是否投诉）。没有反馈回路，分类器漂移了你都不知道。

三、模型级联：用强模型验证弱模型

更重的方案。先走便宜模型，再用强模型检查答案。如果检查通过，交付；不通过，用强模型重跑。

成本结构变了：简单问题付两次（便宜+检查），复杂问题付两次（便宜+强模型重跑）。只有当便宜模型正确率够高、检查成本够低时，才划算。检查可以用规则、轻量模型，或强模型的低采样版本。

延迟是明显代价。简单问题本来毫秒级，现在可能翻倍。对延迟敏感的场景需要权衡。

四、在线学习路由：动态适应

最复杂的方案。不预设规则，让系统自己学。记录每个请求的特征、路由决策、结果质量，持续优化路由策略。

需要基础设施：特征存储、模型服务、A/B测试框架、延迟和质量的双重评估。团队得有ML工程能力，不是调prompt的级别。

天花板最高。工作负载变化时，策略自动适应。季节性波动、新产品上线、用户行为迁移，都能捕捉。

工作量越大，越值得往下走这个列表。几百个请求/天的场景，长度截断可能就够了。百万级/天的场景，在线学习的投入能被摊薄。

路由不是一次性设置。评估集要持续更新，覆盖新出现的查询类型。便宜模型升级了，路由策略要重调。强模型降价了，整个计算逻辑可能翻转。

省钱的本质是把合适的请求发给合适的模型。不是追求最便宜的方案，而是追求给定质量目标下的成本最优。质量目标不能妥协时，路由帮你守住底线；质量目标有缓冲时，路由帮你挖掘空间。