企业多模型路由：如何平衡成本、质量与升级风险

先确定模型能接什么，再讨论该选哪一个

设想一个企业知识助手同时处理术语解释、规格比对和售后处置建议。前者可能有稳定答案；后两者可能涉及单位换算、版本冲突或执行权限。若只根据提示词长度分配模型，一条很短的“这台设备能否超负荷运行”也可能被归为简单问题。文本复杂度、业务后果与可用证据是三个不同维度。

因此，路由应先经过确定性准入条件：模型是否允许处理该数据，是否支持所需上下文、语言和工具，是否满足服务地域与授权要求。只有通过准入的候选模型，才进入成本与质量比较。涉及不可逆操作的任务，应保留业务审批或人工复核；把请求交给能力更强的模型，不能代替授权。

本文用“低成本模型”和“较强模型”描述候选角色，而不把参数规模当作能力保证。某个专用模型可能在限定任务上更好。企业首先应冻结任务边界与成功标准，再用自身样本确认谁适合承担哪类请求。以下方案是基于公开研究的工程分析，算例均为构造假设，不代表壹典实测或供应商报价。

请求前路由与生成后级联，付出的代价不同

请求前路由先观察输入，再选择一个模型生成。RouteLLM 的一种核心设计是估计较强模型相对较弱模型获得偏好胜出的概率，再按阈值分配请求。[1] 对企业而言，这个分数表达相对选择倾向，不能直接当作答案正确率；两者都答错时，也可能存在偏好高低。

生成后级联则先获得低成本模型的答案，通过检查后才交付，否则继续调用其他模型。FrugalGPT 研究了这种结合回答质量估计的模型调用策略。[2] 级联能够利用答案内容、格式检查或证据核验等额外信号，但升级路径已经支付了第一次生成与检查的费用，也承受串行等待。

选择哪种机制应从可观察信号出发。任务类型与输入特征已足够稳定时，可先验证请求前路由；必须看到答案才能发现问题时，可以考虑级联。输出必须满足结构约束的场景适合加入确定性检查，但格式合格不能证明事实正确。两种机制都需要保留“不自动交付”的出口。

降低升级比例，不等于提高路由质量

至少需要同时记录低成本路径覆盖率、该路径交付答案的错误率，以及本应升级却未升级的案例。前两项借鉴选择性预测中的风险与覆盖视角：接受更多样本时，要一起观察被接受集合的风险。[3] 相关研究的统计保证依赖其任务、方法和抽样条件，不能直接移植为开放式生成的正确性保证。

第三项需要配对评估。例如在独立样本中，低成本模型不合格而较强模型合格的请求共有 200 条，路由却把其中 40 条交给低成本模型，则这一组可被升级挽救的请求中，漏升级比例为 20%。这是构造示例，不是整体错误率；两种模型都失败的请求必须另列，不能把它们算作升级可以解决的问题。

业务风险还应分级。错写一个可编辑摘要，与错给设备处置建议，不能用同一平均分抵消。验收时，应分别给高后果任务设置自动交付条件，并对阈值附近和分布外请求增加复核。若使用模型评审提供标签，可结合错误放行校准的方法，检查评审本身的偏差，而不能把模型互相认可当作独立证据。

用可复算账本判断是否真的省钱

对请求前两模型路由，简化平均调用成本可写为 C = C_r + (1 − p)C_s + pC_h。其中 C_r 为每条请求的路由成本，C_s、C_h 分别为两条生成路径的成本，p 为进入较强模型的请求比例。这一简化要求用可比请求估计费用；真实账本还须按每条请求的输入、输出、缓存命中与重试分别计费，不能默认两条路径的 token 长度相同。

构造一个纯费用算例：假设 C_r = 0.002 元、C_s = 0.012 元、C_h = 0.120 元，且 p = 30%。则 C = 0.0464 元。每月 10 万条请求的调用费为 4,640 元，相比全部使用较强模型的 12,000 元，少支出 7,360 元，降幅约 61.3%。这些单价只是算术假设，与任何实际模型报价无关。

再假设级联的单次检查成本 C_e = 0.003 元，且每条请求都先调用低成本模型，30% 再升级一次，其平均调用费是 C_s + C_e + pC_h = 0.051 元。相同升级比例下，月费变为 5,100 元。两种方案的质量未必相同，所以不能仅用这两个金额决定胜负；还要比较最终合格交付率和升级后延迟。

如果请求前路由每月另外需要 6,000 元固定评估与维护投入，前述 7,360 元调用节省只剩 1,360 元，尚未扣除事故处理等其他成本。仅覆盖这笔固定投入的流量门槛约为 6,000 ÷ (0.120 − 0.0464) = 81,522 条/月。此门槛只适用于上述假设；流量下降、输出变长或升级比例上升，都应触发重算。

便宜路径可能改善平均值，却拉长尾部等待

仍用构造条件说明路径差异：假设路由耗时 20 毫秒，低成本模型生成 500 毫秒，较强模型生成 2,000 毫秒，级联检查 150 毫秒，暂忽略排队与网络。请求前路由的两条路径分别为 520 和 2,020 毫秒；级联直接交付为 650 毫秒，升级路径则达到 2,650 毫秒。它体现的是串行结构的代价，不是线上性能预测。

真实系统应分别测量首次可用输出时间、完整答案时间和最终可执行业务结果时间。尤其不能把两个模型各自的 P95 延迟按流量比例加权，当成整体 P95；应从真实请求轨迹计算端到端分位数，并保留升级路径的独立分布。困难请求更长、复核更多，常与高延迟同时发生。

还应验证高峰与故障：较强模型被限流时，是排队、延后处理，还是进入人工渠道？若为了维持响应时间而悄悄把高风险请求降级，原先通过的质量验收便失去意义。涉及自建服务时，服务容量验证需要覆盖升级流量集中到同一后端的情况，而非只测试平均请求配比。

评估要覆盖真正的差异，而非只看总分

先建立三条可比较基线：全部使用低成本模型、全部使用较强模型，以及待评估的路由方案。采用相同业务样本和同一验收规则，分别记录质量、完整费用、时延与未交付数量。对候选路由保留配对输出，才能知道每一次切换究竟改善了什么；只看到线上被选中模型的答案，无法直接判断另一条路径是否更好。

样本至少按任务类型、语言、输入长度、证据完整性、业务后果和时间段切片。用于训练路由、选择阈值和最终验收的数据应隔离，同一客户事件的近似改写也不应跨集合泄漏。对占比很低但后果较大的请求，可额外抽样检查，但汇总成本与覆盖率时要按真实流量权重还原。

上线前先影子运行，在不改变用户交付结果的情况下记录拟选路径与理由，再对已验证的低后果切片逐步放量。抽检必须覆盖已被自动放行的答案，不能只检查升级或投诉样本；否则最需要发现的错误放行会长期不可见。样本不足时，应报告数量与不确定性，不把“暂未发现错误”解释为零风险。

阈值、模型与流量变化，需要一起管理

RouteLLM 作者仓库建议依据接近实际请求的数据校准阈值，并提示真实流量中的模型调用比例可能与校准集不同。[4] 企业不能把上线时的“30% 升级”当作永久属性。新增产品线、语言变化、提示模板改动，以及模型服务版本调整，都可能改变两条路径的相对能力和成本。

每次交付应能追溯模型标识、路由策略版本、阈值版本、输入所属切片、选择原因、检查结果与最终路径。记录应遵循业务数据最小化要求，必要时保存脱敏特征或受控引用，而非为排查问题无差别留存全部敏感正文。配置回滚也必须能恢复相互匹配的一组版本。

运营面板应同时观察成本变化、升级率、分切片错误放行、尾延迟和弃答或人工转接数量。任何一项恶化，都应先识别流量、模型还是路由变化，而不是自动降低阈值继续追求便宜。对于证据不足的新切片，可以暂停自动交付、回到经验证的路径；回退能力应在上线前演练。

采购应验收决策证据，并约定退出条件

供应商演示能够切换模型，只能说明连接层可用。可交付的验收包还应包含：冻结的模型与策略版本、独立评估切片及样本量、各路径费用与端到端延迟、漏升级和共同失败样本，以及故障时的处置记录。若无法导出这些信息，企业很难解释成本为何变化，也难以迁移到另一套路由服务。

继续投入的条件应事先写清：目标切片的质量底线得到支持，预留人工和运营费用后仍有净收益，高峰容量符合业务时限，并且责任人能执行回退。退出条件则包括关键切片证据不足、持续漏升级、运营投入吞噬节省，或供应商变更后无法复现验收。具体阈值须由业务风险和样本证据确定，没有通用的最佳升级比例。

多模型路由最有价值的成果，是把“哪些请求值得投入更多推理资源”变成可追踪、可修正的经营决策。只有低成本路径的适用范围、错误发现机制和升级后果都能解释清楚，模型组合才有机会从账单优化进入可靠的生产体系。