轻任务走小模型、重任务才上调：模型路由的分档依据与切换条件

在真实的 AI 应用里，请求从来不是同一种。用户问一句「这句话是好评还是差评」，和丢进来三万字合同让它逐条比对风险，算力开销可能差上百倍。如果这两类请求都被无条件打给同一个旗舰模型，账单会在月底给出答案，而延迟会在用户侧先给出答案。模型路由要解决的，就是这个不区分任务、只认一个模型的粗放调用问题。

所谓模型路由，是在业务代码和上游模型之间加一层调度决策。对外它仍然是一个兼容 OpenAI 协议的接口地址和一把 Key，对内它要判断这次请求该交给哪个模型、走哪条上游通道。判断依据通常包括任务类型、输入长度、输出格式要求、时延敏感度，以及上游此刻的健康状况与限流余量。业务侧感知不到切换动作，只看到一个稳定的 endpoint。

分档调度是最容易落地的一种路由策略。把可用模型按能力和成本切成几档：轻量档负责文本分类、关键词抽取、意图识别、短句改写、简单摘要；中档覆盖常规问答与多轮对话；重档留给长链推理、代码生成、跨文档分析和复杂工具调用。同一套业务里三档并存，比全量使用重档更接近真实的成本结构。

判断一个任务属于哪一档，可以看几个相对客观的信号。一是输入长度，超过某个阈值往往意味着需要更强的长上下文处理能力。二是输出约束，要求严格 JSON 结构或复杂字段填写的任务，小模型翻车概率明显更高。三是推理步数，需要多步推导、带中间验证的任务不适合压到轻量档。四是交互形态，流式对话对首 token 延迟敏感，而离线批处理更在意单位成本。这些信号组合起来，就能给请求打出一个轻重分档。

切换模型的条件大致有两类。第一类是显式条件，也就是业务自己写进路由规则表的判断，例如「任务标签是意图识别就走轻量档」「输入超过 8k token 就走重档」。第二类是隐式条件，由中转层根据运行状态触发，比如某条上游响应变慢、错误率抬头或者触发限流，就把新请求切到备用通道，等上游恢复再切回来。前者决定该用哪个，后者决定现在还能不能用。

怎么按任务自动分配模型，实践中常见三种做法。最简单的是规则匹配，可解释性最强，也最容易排查问题。进一步是轻量分类器打分，先用一个成本极低的小模型给请求打标签，再据此选档。第三种是先小后大的兜底回退：先让轻量档尝试，如果置信度低、输出解析失败或者触发预设的质量校验，就自动上调到更强的模型重跑一次，把升级成本花在真正需要的那部分请求上。

路由做得好不好，很大程度取决于切换时的稳定性处理。跨模型切换不能丢掉上下文，历史消息、系统提示、工具定义都需要原样透传；结构化输出的字段格式也要保持一致，否则下游解析逻辑会被打乱。同时还需要健康检查、超时熔断、失败重试这些基础设施配合，避免一次上游抖动被放大成业务侧的整体不可用。这些工作放在中转层做，业务代码里就只需要维护一个 base_url。

成本是路由最直观的收益。按量计费下，把七成原本跑在重档上的简单请求挪到轻量档，账单变化可以直接在用量明细里核对。这种优化不需要一次性重构，适合先小范围灰度。快米兔 API 注册即送 5 元测试金，按量计费、不设门槛，做分档策略的对比实验时，可以用很低的成本先跑通链路，再决定阈值怎么定，具体的计费口径与赠送规则以官方说明为准。

落地顺序建议从可观测性开始。先把请求按任务类型打标，记录每次路由决策命中了哪条规则、最终走了哪个模型、耗时和 token 消耗各是多少。有了这些数据，阈值才不是拍脑袋定出来的。接着选定两三个高频场景做灰度，比如客服意图分类走轻量档、长文合同问答走重档，观察质量指标有没有下滑。确认无碍后再逐步扩大规则的覆盖范围，每一步都留好回退开关。

Key 管理也是分档调度的一部分。业务量上来之后，往往需要按团队、按项目、按环境拆分调用凭证，分别设置额度与限流。一个统一入口下挂多个模型，用同一套 OpenAI 兼容协议调用，能省掉每接一个新模型就改一次 SDK 的重复劳动。对于同时跑多条业务线的团队，这种一处配置、多处复用的结构会明显降低维护负担，也让额度核算更清晰。

还有一个容易被忽略的细节：分档不是越细越好。档位太多，规则会迅速膨胀到没人敢改；档位太少，又退化成粗放调用。比较务实的做法是先设三档，等用量数据积累到能看清分布，再决定要不要拆出中间档或者针对某个场景单独开一条通道。路由规则本身也要版本化管理，改动留痕，出问题能快速定位到是哪次调整引起的。

回到最初的问题：什么条件下该切换模型。答案是当任务的复杂度、质量要求和时延预期与当前模型不再匹配的时候。轻任务长期占用重档资源是浪费，重任务硬压给轻量档是体验事故，这两种偏差都可以通过分档调度纠正。像快米兔 API 这样把多模型接入、路由切换和用量计费放在同一层处理的方式，在需要频繁调整策略的场景里会更省事一些，也更容易把成本控制在可预期的范围内。选型时不妨先拿真实流量跑一轮，看谁的调度逻辑更贴合自己的任务结构。