1. 模型路由不是技术炫技而是一道成本与体验的算术题很多团队在AI应用上线三个月后都会遇到同一个尴尬局面账单里推理成本一路飙升但用户对回答质量的抱怨却没减少。这时候技术负责人往往会冒出一个念头——是不是该上模型路由了把简单请求丢给便宜的小模型复杂请求交给贵的大模型听起来既省钱又聪明。但我见过太多团队在这个节点上冲动决策最后落得个路由规则写了三百行省下的钱还不够付维护它的人力成本。模型路由Model Routing的本质是在请求入口和模型出口之间加一层决策逻辑根据请求的特征动态选择最合适的模型。它解决的问题很具体当你的AI应用同时面对今天天气怎么样和帮我分析这份财报里的关联交易风险这两类请求时用同一个模型处理要么贵得离谱要么差得离谱。适合考虑模型路由的通常是已经跑通了AI应用基本链路、有稳定流量、并且开始对成本和延迟敏感的团队。如果你还在验证产品需求阶段日调用量不过几千次那这篇文章的结论大概率是先别做。我在实际项目里总结出一个判断框架核心就是四个问题。这四个问题不是走流程每一个都对应着真实的决策分叉点。回答完它们你基本能确定自己该不该动手、什么时候动手、以及动手后怎么避免踩坑。下面我把这四个问题拆开讲每个都配上我踩过的坑和验证过的判断标准。2. 第一个问题你的请求复杂度分布真的呈现明显的双峰吗2.1 复杂度不是你以为的复杂度模型路由成立的前提是请求之间存在可区分的复杂度差异。但很多团队对复杂度的理解停留在直觉层面觉得短问题就是简单长问题就是复杂。这个判断在真实流量里经常翻车。我做过一个客服场景的统计把用户请求按token长度分成五档结果发现长度和实际所需模型能力之间的相关性只有0.3左右。一条20个字的请求你们这个退款政策是不是违法的需要的推理深度远超一条500字的流水账描述。所以判断复杂度分布不能只看长度要看语义意图的分布。具体怎么做我通常建议先跑两周的请求采样对每个请求打三个标签意图类型问答/生成/推理/抽取、所需知识深度常识/领域/专业、输出约束强度自由文本/结构化/精确计算。然后看这些标签的组合是否集中在少数几个簇上。如果80%的请求都落在常识问答自由文本这一个簇里那说明你的流量是单峰的路由没有意义——直接用一个中等模型全量处理就行。2.2 双峰分布长什么样真正适合路由的流量通常呈现两个明显分离的簇。比如我接触过一个法律文书助手它的请求分布是这样的约65%是这个条款什么意思这类解释性问答用7B级别的小模型就能答得不错剩下35%是对比这两份合同的违约责任差异并给出修改建议必须上到70B以上甚至更强的模型。这两个簇之间的能力需求差距足以覆盖路由层带来的额外延迟和工程复杂度。这里有个量化判断标准如果两个簇各自占比都超过20%且用便宜模型处理简单簇的准确率能达到复杂模型处理效果的90%以上路由才有正收益。低于这个比例路由省下的钱会被决策逻辑的误判成本吃掉。我见过一个团队简单请求只占15%硬上路由结果因为分类器把一些中等复杂度的请求误判成简单导致这部分请求质量下降用户投诉增加最后回滚。2.3 怎么低成本验证分布不用一上来就搭分类器。最土但最有效的办法是随机抽取500条真实请求人工标注复杂度然后分别用大小模型各跑一遍对比输出质量。这个实验大概花两天时间但能给你一个非常扎实的决策依据。如果人工标注发现复杂度是连续渐变的没有明显断层那路由的收益就会很有限因为任何硬性切分都会在边界处产生大量误判。提示做这个验证时一定要用真实线上请求不要用自己构造的测试集。真实请求里的口语化表达、错别字、多意图混合才是分类器真正要面对的挑战。3. 第二个问题你的成本结构里推理费用占比到底有多高3.1 算清楚路由的盈亏平衡点模型路由本身是有成本的。这个成本包括分类器的推理开销哪怕用最小的模型每次请求也要多跑一次、路由决策的延迟增加通常50到200毫秒、以及最容易被低估的——规则维护和误判处理的人力成本。我见过一个团队路由规则写了半年最后发现省下的推理费用刚好等于一个工程师维护这些规则的人力成本等于白忙。所以第二个问题必须算清楚你现在的推理费用占总运营成本的比例是多少如果这个比例低于15%路由带来的节省空间非常有限。举个例子假设你每月推理费用是2万总运营成本15万推理占比13%。就算路由能省下40%的推理费用也就是8000块但你需要投入至少0.5个工程师维护路由逻辑人力成本可能就超过这个数。3.2 不同规模下的成本敏感度成本敏感度跟调用量强相关。我整理了一个粗略的判断表基于我经手过的几个项目月调用量级推理费用占比典型值路由的优先级10万次以下通常低于10%不建议做优化prompt更划算10万-100万次15%-30%可以评估但先做缓存和批处理100万-1000万次30%-50%值得做收益明显1000万次以上50%以上必须做且要做精细化的多级路由这个表不是绝对的但能帮你快速定位自己处在哪个阶段。我特别想强调的是在10万次以下这个量级优化prompt和做结果缓存带来的收益往往比模型路由高一个数量级。很多团队跳过这两步直接上路由属于典型的用复杂方案解决简单问题。3.3 被忽略的隐性成本除了显性的推理费用还有几块隐性成本必须算进去。第一是质量下降带来的用户流失这个很难量化但真实存在。第二是路由误判的兜底成本比如简单请求被误判成复杂浪费了贵模型的调用复杂请求被误判成简单导致需要重试或人工介入。第三是系统复杂度上升带来的故障率多一个路由层就多一个故障点。我的经验是在计算路由收益时把理论节省金额乘以0.6作为实际预期收益。这个折扣系数来自我多个项目的平均偏差。如果打完折之后收益仍然可观那才值得做。4. 第三个问题你的延迟预算能容纳路由决策的开销吗4.1 路由决策本身要花多少时间模型路由不是免费的午餐它要在请求到达模型之前插入一次判断。这次判断的耗时取决于你用什么方式做决策。我实测过几种常见方案基于规则的判断关键词匹配、长度阈值通常5到20毫秒但准确率有限边界情况误判多。基于小模型的分类器50到150毫秒准确率较好但需要额外部署一个模型。基于语义向量的相似度匹配30到80毫秒需要预先构建向量库。基于大模型自己判断300毫秒以上成本也高基本不划算。如果你的应用是实时对话场景用户对首字延迟的容忍度通常在1秒以内。假设模型本身推理要600毫秒那留给路由决策的预算就只有300到400毫秒。这个预算下小模型分类器是可行的但如果你再叠加其他中间层比如内容安全过滤、敏感词检测预算就会非常紧张。4.2 流式输出下的特殊考量现在很多AI应用采用流式输出用户看到第一个字的时间TTFT是体验的关键指标。路由决策发生在流式输出之前所以它会直接加到TTFT上。我做过一个测试在同一个应用里加了一层80毫秒的分类器用户主观感受到的卡顿感明显上升尽管总响应时间只增加了不到10%。这里有个技巧如果路由决策和内容安全检测可以并行执行就并行。比如分类器判断复杂度的同时另一个轻量模块做敏感词扫描两者结果都出来后再决定用哪个模型。这样能把串行延迟变成并行延迟实际增加的时间取两者最大值而非之和。4.3 什么时候延迟比成本更重要有些场景下延迟的优先级高于成本。比如实时翻译、语音助手、在线客服的即时回复这些场景用户对速度极其敏感多100毫秒都可能影响留存。这种情况下模型路由的设计原则要反过来优先保证路由决策不增加延迟宁可牺牲一点成本节省。具体做法是把路由决策前置到请求进入系统的最早环节或者用缓存的方式预判——对高频重复的请求模式直接查表返回路由结果跳过实时分类。注意如果你的应用SLA里对P99延迟有硬性要求上路由之前一定要做全链路的延迟压测把路由层的最坏情况耗时算进去。我见过一个团队因为忽略了分类器在冷启动时的加载延迟导致上线后P99延迟超标紧急回滚。5. 第四个问题你有没有能力持续维护路由规则和评估效果5.1 路由不是一次性的工程这是四个问题里最容易被低估的一个。很多团队把模型路由当成一个做完就完事的项目上线之后就不管了。但真实情况是模型路由是一个需要持续运营的系统。原因很简单你的流量分布在变模型的能力和价格在变用户对质量的预期也在变。三个月前合理的路由规则三个月后可能就完全失效了。我维护过的一个路由系统平均每两周就要调整一次规则。调整的依据来自几个方面分类器的准确率监控、各模型的实际输出质量抽检、成本报表的异常波动。这些工作加起来每周大概需要投入4到6个小时。如果你的团队没有这个人力预算那路由系统会很快退化成一个看起来在省钱实际上在制造问题的摆设。5.2 评估体系怎么搭没有评估就没有优化。路由系统的评估要覆盖三个层面第一层是分类准确率。你需要定期抽样人工检查分类器把请求分到简单/复杂两类的判断是否正确。我通常设定一个阈值如果分类准确率低于85%就要重新训练或调整分类器。第二层是各模型的实际表现。简单请求走小模型后输出质量是否达标复杂请求走大模型后是否真的比小模型好很多这需要建立一套自动化的质量评估可以用另一个模型做裁判也可以维护一个带标注的测试集定期跑分。第三层是成本和质量的总账。路由的最终目标是在质量不降的前提下省钱所以要定期对比全量用大模型和路由方案的总成本和总质量分。如果发现质量分下降超过5%即使成本省了30%也要重新审视路由策略。5.3 什么情况下应该放弃路由我经历过两次回滚路由系统的决策原因都很有代表性。第一次是流量模式发生了根本变化原本的双峰分布变成了单峰路由失去了意义。第二次是上游模型厂商推出了一个价格和性能都介于原来大小模型之间的新模型直接用这个新模型全量处理比维护路由系统更简单也更便宜。所以第四个问题的本质是你是否有持续投入的意愿和能力以及你是否接受路由可能只是阶段性方案。如果答案是否定的那不如把精力放在prompt优化、缓存策略、或者直接换一个更合适的模型上。6. 四个问题回答完之后我的实操决策路径6.1 一张决策流程图文字版把四个问题的答案组合起来我通常按这个路径做决策如果复杂度分布是单峰或者推理费用占比低于15%或者延迟预算极其紧张或者没有持续维护的人力——四个条件满足任何一个就先不做路由。如果四个条件都满足但月调用量在10万到100万之间——先做缓存和批处理观察三个月再评估。如果四个条件都满足且月调用量超过100万——可以做但要从最简单的规则路由开始不要一上来就上分类器。如果月调用量超过1000万——必须做而且要设计多级路由同时建立完整的评估和监控体系。这个路径不是死的但能帮你避免最常见的冲动决策。我见过太多团队在条件不成熟的时候硬上路由最后浪费了几个月时间还不如当初直接优化prompt。6.2 从规则路由起步的具体做法如果你决定要做我的建议是从基于规则的轻量路由开始。具体来说先定义三到五条最简单的规则比如请求token数小于50且不包含特定复杂意图关键词的走小模型。请求中包含分析对比推理计算等词的走大模型。命中缓存的直接返回不走模型。其他情况走默认的中等模型。这四条规则大概半天就能写完上线后观察两周。如果效果好再逐步引入分类器做更精细的判断。这种渐进式的做法风险可控而且能让你在早期就积累路由运营的经验。6.3 监控指标清单路由上线后这几个指标必须盯住路由分布比例简单/复杂请求的实际占比如果偏离预期超过10%要查原因。分类器准确率每周抽样100条人工复核。各模型的质量分用固定测试集每周跑一次。P99延迟对比路由前后的变化。单位请求成本这是最终要看的数字但不要只看它要结合质量分一起看。我个人的习惯是做一个简单的看板把这五个指标放在一屏里每天早上扫一眼。异常的时候再深入排查正常的时候不花太多时间。7. 那些我踩过的坑和总结出的经验7.1 分类器不是越准越好刚开始做路由的时候我总想把分类器准确率做到95%以上。后来发现分类器的准确率和它的成本、延迟是矛盾的。一个95%准确率的分类器可能需要一个不小的模型延迟和成本都上去了。而一个85%准确率的轻量分类器虽然会误判15%的请求但整体收益反而更高。因为那15%的误判里大部分是边界情况即使用错了模型质量差异也没有那么大。所以我的经验是分类器准确率做到85%左右就够了剩下的精力放在兜底策略上。比如对分类置信度低的请求直接走大模型宁可多花点钱也不冒质量风险。7.2 缓存和路由要一起设计缓存和路由是天然的好搭档。很多请求是重复的命中缓存直接返回连路由都不用做。我在一个项目里把缓存命中率从20%提升到45%之后路由系统的压力直接减半整体成本又降了一截。所以如果你要做路由一定要同时看缓存策略两者结合起来设计效果是11大于2的。7.3 不要忽略小模型的进步速度这是一个战略层面的提醒。小模型的能力每几个月就在提升今天需要大模型才能处理的请求半年后可能小模型就能搞定。所以路由规则要定期重新评估不要一套规则用一年。我现在的做法是每个季度做一次全量评估看看有没有哪些原本走大模型的请求现在可以下放到小模型。7.4 组织协调往往比技术更难最后说一个非技术但极其重要的点。模型路由的决策往往涉及算法团队、工程团队、产品团队和财务团队。算法团队关心质量工程团队关心稳定性产品团队关心体验财务团队关心成本。这四个团队的诉求不完全一致路由方案很容易变成各方妥协的产物最后谁都不满意。我的经验是在启动路由项目之前先跟这四个团队对齐一个共同的目标函数。比如在质量分不低于当前95%的前提下把单位请求成本降低30%。有了这个共同目标后面的技术决策就有了统一的判断标准扯皮会少很多。模型路由这件事技术本身不复杂难的是判断时机和持续运营。四个问题回答清楚该不该做、什么时候做、怎么做基本就都有答案了。我在实际项目里最大的体会是克制比激进更难但往往更正确。