轻模型干轻活、重模型啃硬活：模型路由的切换条件与按任务自动分档调度

调用大模型最贵的往往不是单价，而是把所有请求都塞进旗舰模型。很多团队接入中转后的第一件事，就是把客服问答、字段抽取、文案改写这些活儿统一丢给最大的那个模型，结果账单和响应时间一起往上走。模型路由要解决的正是这件事：让每一类请求落到最合适的那一档模型上。

所谓模型路由，是在应用和模型之间加一层调度器。它接收统一的请求，读取其中的特征，再决定把这次调用发给哪个模型。对开发者来说，出口仍然是一个兼容 OpenAI 协议的地址和一个 Key，背后却是可以随时切换的多个模型。路由做得好，业务代码几乎不用改，换模型只改一个配置项。

路由要读哪些信号？常见的判断维度有四类：任务类型，比如分类、抽取、摘要、推理、代码；输入长度与上下文规模；对延迟和并发的要求；以及是否需要函数调用或严格的结构化输出。把这些信号量化成规则或特征，路由才有依据，而不是靠拍脑袋临时决定用哪个模型。

轻量与重模型的分档调度，通常分成三档。第一档是小参数模型，处理意图识别、情感判断、短文本改写、字段抽取这类边界清晰的任务；第二档是中档通用模型，承担多轮对话、长文摘要、常规代码补全；第三档是旗舰推理模型，用于复杂推理、长链条任务、代码重构和数学题。分档的意义在于，让大多数普通请求别去占用那少数的贵资源。

什么时候该切换模型？第一个触发条件是质量不达标。常见做法叫级联：先交给轻模型，输出通过 schema 校验、字段完整度检查或置信度阈值就返回，否则升级到更强的模型重跑一次。这种方式对结构化抽取类任务特别有效，因为对错很容易用规则验证，失败成本也只是一次额外调用。

第二个条件是成本。按量计费下，token 消耗直接等于账单。给不同业务线设定 token 预算上限，接近阈值时自动降档到更便宜的模型，或者把长上下文压缩后再送进去，都是可控的止损手段。成本触发的好处是它的判断是确定性的，不依赖模型输出质量的主观评估。

第三个条件是延迟与稳定性。当 P95 延迟超过目标，或某个模型返回 429、超时、服务波动时，路由应能自动把流量切到同一档位的备用模型，而不是让请求直接失败。这一层降级策略，很多时候比模型本身选得对不对更影响用户体验，也决定了系统在高峰期是扛住还是崩掉。

第四个条件是合规边界。面向国内业务，路由池里通常只保留国产合规模型，数据不出境、调用留痕，才能过得了内部审计这一关。这一点在选型时容易被忽略，但往往是能不能上生产的前提，尤其是涉及用户数据和行业客户的项目。

怎么做到按任务自动分配？实现路径从简到繁。最先是静态规则，按关键词、输入长度、是否带代码块来分流；再进一步，用一个小模型做请求分类，它的输出就是路由标签；更复杂的是语义路由，用向量相似度把请求和历史样本比对；最重的做法是在线评测加多臂老虎机，按实际反馈动态调权重。多数团队从规则起步就够用，先跑通再谈优化。

落地时还有几个坑。同一个会话不要频繁跳档，否则回答风格和上下文记忆会漂移，建议按会话锁定模型、只在必要时升级；命中的缓存要能跨档复用，避免省了模型钱却重复花在检索上；上线前要有一份自己的评测集做灰度；日志里必须记清楚每次请求实际命中了哪个模型，否则成本归因无从谈起。

这些能力放在中转层做，比自己维护网关更省事。统一兼容 OpenAI 协议意味着切换模型只改一个配置项，Key 管理和额度控制集中在网关，按量计费的账单天然按模型拆分，做分档预算时不用再手工对账。快米兔 API 走的也是这个思路：接口保持 OpenAI 兼容，接入后按量计费，注册即送 5 元测试金，方便先用小成本跑一轮基线评测，再决定分档规则和切换阈值。

回到最初的问题，模型路由不是什么玄学，它是一套可以被量化、被观测、被逐步调优的调度逻辑。先把任务分级、把切换条件和降级策略写清楚，再挑一个能同时接入多个国产模型、计费和日志都清楚的入口，轻量与重模型的搭配才会真正省下成本，而不是换来一堆难以排查的线上问题。