1. 模型路由到底在解决什么问题1.1 从一个真实场景说起去年下半年我帮一家做智能客服的团队做架构评审。他们的产品接入了三个不同的大模型一个国产通用模型处理日常问答一个推理能力更强的模型处理复杂工单还有一个轻量模型专门做意图分类。上线三个月账单从每月两万涨到十一万而用户满意度反而掉了几个百分点。问题出在哪他们的路由逻辑是按关键词硬编码——只要用户消息里出现退款投诉这类词就无脑丢给最贵的那个模型。结果大量简单咨询被送进了重型模型响应时间从1.2秒涨到4秒成本翻了五倍体验还变差了。这就是模型路由要解决的核心矛盾不是所有请求都值得用同一个模型处理。模型路由Model Routing本质上是一层调度逻辑它站在用户请求和底层模型之间根据请求的特征、业务规则、成本预算、延迟要求等维度动态决定这次请求该交给哪个模型。说白了它就像公司前台的分诊台。感冒发烧去普通门诊疑难杂症挂专家号急诊走绿色通道。如果所有病人都直接冲进专家诊室专家累死普通病人也等死。1.2 模型路由和多模型调用的区别很多人会把这两个概念混为一谈。多模型调用只是我接了好几个模型而模型路由是我知道什么时候该用哪个。前者是能力储备后者是决策系统。我见过不少团队接了三四个模型但实际使用中就是主模型备用模型的降级关系——主模型挂了才切备用。这不叫路由这叫容灾。真正的路由要回答的是在正常情况下这次请求交给谁最划算判断标准很简单如果你的系统里同一个请求在不同时间、不同负载下会被分给不同模型并且这个分配是有依据的那才叫路由。如果分配逻辑永远是先试AA不行再试B那只是故障转移。1.3 为什么现在这个问题变得紧迫两年前大家不太关心路由因为模型选择少价格差异也不大。现在情况完全变了同一个能力档位的模型价格能差十倍同一个模型的不同版本延迟能差三倍开源模型本地部署和API调用的成本结构完全不同。更关键的是AI应用从能用就行进入了要算账的阶段。我接触的团队里凡是月调用量超过百万次的没有不做成本优化的。而模型路由往往是ROI最高的那个优化点——不需要改模型不需要重训只调整调度逻辑成本就能降30%到60%。但这里有个陷阱不是所有AI应用都值得做模型路由。我见过一个日调用量只有几千次的内部工具团队花了两周搭路由系统结果省下来的钱还不够付搭建的人力成本。所以接下来我要讲的四个问题就是帮你在动手之前先判断清楚这事到底值不值得做。2. 第一个问题你的请求分布是否足够不均匀2.1 均匀分布意味着路由没有价值模型路由能省钱的前提是你的请求里存在明显的简单请求和复杂请求的分层。如果所有请求的难度都差不多那路由就失去了意义——你总不能把同样难度的请求随机分给不同模型吧我一般会建议团队先做一次请求采样分析。具体做法是随机抽取1000条真实请求用你当前的主力模型跑一遍记录每条请求的token消耗、响应时间、以及人工评估的质量分。然后把质量分和成本画成散点图。如果散点图呈现明显的两极分化——大量请求用便宜模型就能达到可接受质量只有少数请求必须用贵模型——那路由就有价值。如果散点图是一条平滑的斜线说明请求难度是连续分布的硬切分反而会伤害体验。2.2 怎么量化不均匀程度我常用一个土办法计算简单请求占比。定义简单请求为用最便宜的候选模型能达到主力模型90%以上质量分的请求。如果这个占比超过40%路由就值得做如果低于20%基本可以放弃。这个阈值不是拍脑袋来的。假设简单请求占比是p贵模型单价是便宜模型的k倍那么路由的理论成本节省是 p × (1 - 1/k)。当p40%、k5时节省约32%当p20%时节省只有16%扣掉路由本身的判断开销和误判损失基本不剩什么。注意这里的质量分必须用你自己的业务标准来定义不能直接用通用benchmark。客服场景里回答准确但语气生硬可能就不合格而写作场景里结构松散但内容有料可能可以接受。质量标准的定义直接决定了简单请求的占比。2.3 一个反直觉的发现我踩过的一个坑是请求长度和请求难度不成正比。早期我天真地以为长请求复杂请求按token数做路由。结果发现很多长请求只是用户粘贴了一大段背景信息核心问题一句话就能回答反而有些短请求比如帮我分析下这个季度的异常需要模型做大量推理。后来我改成用意图复杂度做判断具体看三个信号请求是否包含多步推理要求、是否需要外部知识、是否涉及数值计算。这三个信号比长度靠谱得多。当然这需要你先有一批标注数据来训练判断逻辑或者用一个小模型来做意图分类。3. 第二个问题你的成本结构里模型调用占多大比重3.1 算清楚这笔账再动手模型路由的直接收益是降低模型调用成本。但如果模型调用只占你总成本的10%那就算省一半也只降5%的总成本投入产出比很难看。我一般让团队列一张成本结构表把AI应用的总成本拆成几块模型调用费、向量数据库和检索费、服务器和带宽费、人力运维费、以及业务侧的分摊成本。然后看模型调用费占比。经验值是模型调用费占比超过30%路由才值得认真做。低于这个数优先优化其他环节。我见过一个团队模型调用只占成本的8%但检索环节因为索引设计不合理占了45%。他们花大力气做路由不如去优化检索。3.2 别忽略隐性成本模型调用成本不只是API账单。如果你用的是自部署模型成本还包括GPU折旧、电费、运维人力。这些隐性成本往往被低估。举个例子一个团队自部署了一个7B模型做简单任务觉得反正是自己的卡不花钱。但实际上那块A100如果拿去做别的推理任务每月能产生几千块的收益。这就是机会成本。做路由决策时要把自部署模型的成本按市场租用价折算进去否则会做出错误判断。3.3 成本节省的天花板在哪假设你的请求分布是理想的40%简单请求候选模型价格差是5倍那么理论最大节省是32%。但实际能达到的通常只有理论值的60%到70%因为路由判断本身有开销要么用小模型判断要么用规则判断都有成本误判会导致质量下降或成本反弹部分请求无法被清晰分类只能走保守策略所以现实预期应该是成本降低20%到40%。如果有人告诉你路由能省80%要么他的请求分布极端不均匀要么他在偷换概念比如把降级也算成路由。4. 第三个问题你的质量容忍度有多高4.1 路由的本质是用质量换成本这句话可能不太好听但事实如此。模型路由能省钱是因为它把一部分请求交给了能力较弱的模型这些请求的回答质量必然会有下降——问题只在于下降多少、你能不能接受。所以做路由之前必须先明确哪些场景的质量下降是可以接受的。这需要业务方参与不能由技术团队单方面决定。我一般会推动业务方定义质量红线哪些请求绝对不能出错比如涉及金额、法律条款、医疗建议哪些请求可以容忍一定误差比如闲聊、创意生成、初步筛选。红线内的请求永远走最强模型红线外的才参与路由。4.2 建立质量监控机制路由上线后必须有质量监控。我推荐的做法是对路由到弱模型的请求按5%到10%的比例抽样用强模型重新跑一遍对比两者输出的差异。如果差异超过阈值就触发告警。这个影子评估机制很关键。我见过一个团队路由上线后成本确实降了但三个月后才发现某类请求的质量一直在缓慢下滑因为路由规则把一批看起来简单实际很微妙的请求错误地分给了弱模型。等发现时用户已经流失了一批。提示影子评估的抽样比例要动态调整。刚上线时抽10%稳定后降到3%到5%。但永远不要降到0因为用户请求的分布会随时间漂移今天的简单请求明天可能变复杂。4.3 质量下降的补偿策略如果某类请求路由到弱模型后质量不达标有几个补救方向一是调整路由规则把这类请求重新划给强模型二是对弱模型的输出做后处理比如用规则校验、用强模型做润色三是接受质量下降但通过其他方式补偿用户比如更快的响应速度、更低的定价。第三条路常被忽略。实际上很多用户对快的敏感度高于对完美的敏感度。如果弱模型能把响应时间从3秒降到0.8秒即使质量略降用户满意度可能反而上升。这需要你真正理解用户的核心诉求。5. 第四个问题你的工程能力能否支撑路由系统5.1 路由不是加个if-else那么简单很多人以为模型路由就是写几个判断条件把请求分发给不同模型。真做起来会发现它涉及一整套工程能力请求特征提取怎么在毫秒级内判断一个请求的复杂度用规则、用小模型、还是用启发式模型池管理多个模型的API密钥、限流、重试、超时怎么统一管理降级与熔断某个模型挂了怎么快速切换而不影响用户体验效果追踪怎么知道路由决策是对的需要完整的日志和评估链路。配置热更新路由规则要能随时调整不能每次改规则都发版。这些能力缺一个路由系统就会变成运维噩梦。我见过最惨的案例是路由规则硬编码在代码里每次调整都要走完整发布流程结果规则永远滞后于业务变化最后团队干脆放弃了路由。5.2 最小可行路由系统的构成如果你工程资源有限我建议从最小可行版本开始。一个能用的路由系统至少需要三个组件第一是规则引擎支持用配置文件定义路由规则能热加载。规则可以很简单比如包含特定关键词走A模型否则走B模型但必须能改。第二是统一调用层把所有模型的调用封装成统一接口上层不关心底层是哪个模型。这样切换模型时不用改业务代码。第三是决策日志记录每次路由的输入特征、决策结果、实际使用的模型、响应时间和质量评估。没有这个日志你永远不知道路由效果如何。这三个组件加起来一个熟练的工程师大概一周能搭出原型。但要做好、做稳需要持续迭代。5.3 什么时候该用现成方案如果你的团队没有专门的平台工程能力可以考虑用现成的路由方案。目前主流的有两类一类是模型网关产品提供路由、限流、监控等能力另一类是在应用框架层面做路由比如一些Agent开发框架内置了模型选择逻辑。选现成方案的好处是快坏处是灵活性受限而且可能引入额外的依赖和成本。我的建议是如果路由逻辑简单比如就两三个模型、规则固定用现成方案如果路由逻辑复杂或需要频繁调整自己搭更可控。6. 四个问题的综合判断与决策矩阵6.1 把四个问题串起来看单独回答每个问题还不够要把它们综合起来判断。我一般用一个简单的决策矩阵请求不均匀度模型成本占比质量容忍度工程能力建议高40%简单请求高30%中高强立即做ROI最高高高低强做但红线要划清高低中高强缓做先优化其他成本低20%高中高强谨慎做先改善请求分层任意任意任意弱先用现成方案或暂缓这个矩阵不是绝对的但能帮你快速定位自己的情况。我见过最多的情况是请求不均匀度高、成本占比高、但工程能力弱这种团队最纠结。我的建议是先用最简单的规则路由起步跑通再逐步完善。6.2 一个容易忽略的维度业务增长速度除了上面四个问题还要看业务增长速度。如果你的调用量每月翻倍那即使现在成本占比不高半年后也会变成大问题。这种情况下提前布局路由是值得的因为等成本压力来了再动手往往来不及。反过来如果业务在萎缩或者趋于稳定那路由的紧迫性就低很多。我一般建议调用量年增长超过3倍的团队即使当前成本占比不高也应该开始做路由的技术储备。6.3 决策的时间窗口还有一个现实问题什么时候做决策。我的经验是在成本压力显现之前做而不是之后。因为路由系统的搭建和调优需要时间等账单已经压得你喘不过气时再动手中间会有一段成本还在涨但路由还没生效的痛苦期。比较理想的节奏是当模型调用成本占到总成本的20%左右时开始调研到30%时开始搭建到40%时已经跑通。这样成本曲线会在最陡的时候被拉平而不是等到高位才刹车。7. 实操中的常见坑与排查技巧7.1 路由规则越复杂越好吗不是。我见过一个团队路由规则写了三十多条覆盖各种边界情况。结果规则之间互相冲突维护成本极高新人根本看不懂。后来我们把它精简到五条核心规则效果反而更好。路由规则的设计原则是能用简单规则解决的不要用复杂规则。复杂规则应该只在简单规则无法覆盖且影响显著时才引入。而且每条规则都要有明确的业务依据不能凭感觉加。7.2 误判的代价怎么控制路由误判有两种把简单请求分给强模型浪费成本把复杂请求分给弱模型伤害质量。前者的代价是钱后者的代价是体验。一般来说后者的代价更大所以路由策略应该宁可错杀不可放过——不确定的请求走强模型。但这也意味着成本节省会打折扣。我一般建议把不确定的请求比例控制在10%以内超过这个数说明你的判断逻辑不够好需要优化。7.3 模型版本更新带来的连锁反应这是个隐蔽的坑。你基于模型A和模型B的能力差异设计了路由规则结果某天模型A升级了能力大幅提升价格还降了。这时候你的路由规则可能就过时了——原本该走B的请求现在走A更好。所以路由系统必须定期重新评估。我建议每季度做一次全量评估重新测量各模型在你业务场景下的实际表现和成本然后调整路由规则。这个评估不能只看官方benchmark必须用你自己的数据。7.4 常见问题速查表问题现象可能原因排查方向成本没降反升路由判断本身开销过大检查判断逻辑的token消耗和延迟质量明显下滑复杂请求被误分给弱模型抽样对比强弱模型输出差异响应时间不稳定模型池限流或重试策略不当检查各模型的限流配置和超时设置规则调整不生效配置未热加载或缓存未刷新检查配置加载机制和缓存策略某模型调用量异常路由规则倾斜或误判分析决策日志看特征分布7.5 我个人的几条经验第一先做减法再做加法。不要一上来就设计完美的路由系统先用最简单的规则跑起来看效果再逐步加复杂度。第二质量监控比成本监控更重要。成本降了但质量崩了是灾难质量稳住了成本没降只是没赚到。优先级要清楚。第三路由规则要业务方参与制定。技术团队懂模型但不懂业务红线。哪些请求不能出错只有业务方知道。第四留好回退开关。路由系统出问题时要能一键切回全部走强模型的保守模式。这个开关平时不用但关键时刻能救命。第五别追求极致优化。路由能省30%就很好了非要省50%往往意味着质量风险大幅上升。找到成本和质量的平衡点比追求单指标最优更重要。8. 一个简化版的路由实现参考8.1 整体架构如果你决定要做这里给一个我实际用过的简化架构。它不完美但能跑通适合作为起点。整个系统分三层接入层负责接收请求和返回响应决策层负责判断该用哪个模型执行层负责实际调用模型并处理结果。三层之间通过统一的数据结构通信决策层可以独立替换。8.2 决策层的实现思路决策层我一般用规则小模型的混合方式。先用规则做快速筛选规则覆盖不了的再用小模型判断。规则部分用配置文件定义比如rules: - name: simple_greeting condition: intent greeting model: light - name: complex_reasoning condition: contains_any([分析, 推理, 计算, 对比]) model: heavy - name: default condition: true model: medium小模型部分用一个轻量分类模型输入是请求文本输出是复杂度等级。这个模型可以用标注数据微调也可以用现成的文本分类模型。8.3 执行层的关键细节执行层最重要的是统一接口和错误处理。所有模型调用都走同一个函数传入模型标识和请求内容返回统一格式的结果。这样上层不用关心底层是哪个模型。错误处理要分情况超时重试、限流退避、模型不可用时的降级。降级策略要预先定义好比如heavy模型不可用时降级到mediummedium不可用时降级到light。8.4 监控与迭代上线后要监控几个核心指标各模型的调用量分布、路由决策的准确率通过影子评估、成本变化、质量变化。这些指标要能实时看至少每天看一次。迭代节奏我建议是上线后第一周每天调规则第二周隔天调之后每周review一次。稳定后可以放宽到每月review。但影子评估要一直跑不能停。这套东西搭下来一个两人小组大概两到三周能跑通第一版。之后就是持续调优的功夫了。我自己的体会是路由系统的价值不在搭建而在持续运营——规则要跟着业务变模型要跟着版本变评估要跟着数据变。把它当成一个长期项目而不是一次性工程才能真正拿到收益。