什么是模型路由？API 中转服务在什么条件下会把请求从轻量模型切到重模型

模型路由是 API 中转层在请求转发之前做的一次调度决策：同一条 OpenAI 兼容请求进来，由网关决定它交给哪个模型、哪个供应商通道去完成。它解决的不是模型聪不聪明，而是把任务按难度分给不同成本的算力。边界很清楚，如果一个应用只固定调用一个模型、也没有备用通道，那就只有转发没有路由，分档调度更无从谈起。 轻量与重模型的分档之所以成立，是因为两者在单价和首字延迟上通常不在一个量级。轻量模型参数小、解码快，适合分类、抽取、改写、简单问答这类短链路任务；重模型推理步数多、上下文长，适合多步推理、代码生成、复杂工具调用。按量计费的接口把费用直接绑在输入输出 token 上，一次重模型调用往往相当于若干次轻量调用，这就是分档的经济动机。 分档不等于必须准备两个不同厂商的模型。常见做法是同一系列里取一大一小两档，重的兜底、轻的承接大多数请求；也可以把不同供应商的同级模型放在同一档位互为备份，档内切换解决可用性，档间切换解决复杂度。两者的调度信号完全不同，混在一起谈会导致阈值永远调不准。 第一类切换条件是入口分类器的置信度不足。网关在转发前用规则或轻量模型给请求打标，判断它属于简单问答、结构化抽取还是需要多步推理，当置信度低于设定阈值时就上抛到重模型。阈值定得过松会把大量本可便宜的请求推给重模型，定得过紧又会让轻量模型在难题上反复出错，通常需要用历史请求做离线回放来校准。 第二类切换条件是输出校验不通过。结构化输出解析失败、函数调用的参数缺字段、生成的代码跑不通、引用找不到出处，这些都可以作为升级信号，把请求带着失败原因交给重模型重试一次。升级重试必须带预算，否则一次故障引发的连锁升级会把成本曲线拉成尖峰，常见做法是限制单请求最多升级一到两次。 第三类切换条件是延迟预算逼近上限。给每个请求设定首字超时和整体超时，一旦重模型通道在预算内给不出结果，就降级到轻量模型先返回一个可用答案，再由后台补齐。这条规则不适用于结果必须完整推理的场景，比如需要严格一致的结论输出，此时宁可超时也不该用降级结果糊弄调用方。 第四类切换条件是上游限流或故障。接口返回 429 或 5xx 时，路由层先在同档位换 Key、换通道重试，档位保持不变；只有当同档全部通道不可用时，才考虑跨档降级。把限流直接当成降级信号是常见误用，它会让一次上游抖动变成整体回答质量下降，故障恢复后也难以追溯。 分档调度不适合交给一个大模型对每次请求现场决策。每次调用大模型做判断，本身就有 token 成本和额外延迟，还会引入不可复现的随机性。工程上更稳的组合是确定性规则打底，覆盖关键词、长度、是否带工具、是否多轮这些可枚举特征，再用轻量分类器处理规则覆盖不到的灰色地带。 缓存是路由的上游，先命中缓存再谈分档。语义缓存、前缀缓存或固定的模板问答命中后可以直接返回，根本不消耗模型算力，也就没有切换模型的问题。把命中率做上去，等于把一部分流量从所有档位里摘出去，这比在轻重两档之间反复调阈值更划算。 路由能不能长期跑下去，取决于可观测性。每次决策至少要留下命中的规则或分类结果、最终档位、实际通道、重试次数和 token 消耗，才能回答成本为什么涨了、哪类请求被误判。没有这层日志，阈值调整只能靠猜，灰度发布和回滚也无从下手。 多通道意味着多套计价口径，账单必须合并到同一个维度。不同供应商的 token 计数方式、缓存命中折扣、失败请求是否计费都不一致，中转平台按量计费时要向调用方给出统一口径的用量。否则路由虽然省了算力，对账成本反而把收益吃掉。 有些场景根本不需要模型路由。单一模型、单一任务、请求量很小、模型成本在整体支出里占比不高、对延迟也不敏感时，引入分档只会增加维护和排障成本。这类情况先把接入和 Key 管理做稳，用 OpenAI 兼容协议把调用统一起来，等流量结构复杂到有明确的高低难度分化，再上调度层。