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万次以下这个量级，优化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 从规则路由起步的具体做法

如果你决定要做，我的建议是从基于规则的轻量路由开始。具体来说，先定义三到五条最简单的规则，比如：

1. 请求token数小于50且不包含特定复杂意图关键词的，走小模型。
2. 请求中包含"分析""对比""推理""计算"等词的，走大模型。
3. 命中缓存的直接返回，不走模型。
4. 其他情况走默认的中等模型。

这四条规则大概半天就能写完，上线后观察两周。如果效果好，再逐步引入分类器做更精细的判断。这种渐进式的做法，风险可控，而且能让你在早期就积累路由运营的经验。

6.3 监控指标清单

路由上线后，这几个指标必须盯住：

• 路由分布比例：简单/复杂请求的实际占比，如果偏离预期超过10%，要查原因。
• 分类器准确率：每周抽样100条人工复核。
• 各模型的质量分：用固定测试集每周跑一次。
• P99延迟：对比路由前后的变化。
• 单位请求成本：这是最终要看的数字，但不要只看它，要结合质量分一起看。

我个人的习惯是做一个简单的看板，把这五个指标放在一屏里，每天早上扫一眼。异常的时候再深入排查，正常的时候不花太多时间。

7. 那些我踩过的坑和总结出的经验

7.1 分类器不是越准越好

刚开始做路由的时候，我总想把分类器准确率做到95%以上。后来发现，分类器的准确率和它的成本、延迟是矛盾的。一个95%准确率的分类器，可能需要一个不小的模型，延迟和成本都上去了。而一个85%准确率的轻量分类器，虽然会误判15%的请求，但整体收益反而更高。因为那15%的误判里，大部分是边界情况，即使用错了模型，质量差异也没有那么大。

所以我的经验是：分类器准确率做到85%左右就够了，剩下的精力放在兜底策略上。比如对分类置信度低的请求，直接走大模型，宁可多花点钱也不冒质量风险。

7.2 缓存和路由要一起设计

缓存和路由是天然的好搭档。很多请求是重复的，命中缓存直接返回，连路由都不用做。我在一个项目里，把缓存命中率从20%提升到45%之后，路由系统的压力直接减半，整体成本又降了一截。所以如果你要做路由，一定要同时看缓存策略，两者结合起来设计，效果是1+1大于2的。

7.3 不要忽略小模型的进步速度

这是一个战略层面的提醒。小模型的能力每几个月就在提升，今天需要大模型才能处理的请求，半年后可能小模型就能搞定。所以路由规则要定期重新评估，不要一套规则用一年。我现在的做法是每个季度做一次全量评估，看看有没有哪些原本走大模型的请求，现在可以下放到小模型。

7.4 组织协调往往比技术更难

最后说一个非技术但极其重要的点。模型路由的决策，往往涉及算法团队、工程团队、产品团队和财务团队。算法团队关心质量，工程团队关心稳定性，产品团队关心体验，财务团队关心成本。这四个团队的诉求不完全一致，路由方案很容易变成各方妥协的产物，最后谁都不满意。

我的经验是，在启动路由项目之前，先跟这四个团队对齐一个共同的目标函数。比如"在质量分不低于当前95%的前提下，把单位请求成本降低30%"。有了这个共同目标，后面的技术决策就有了统一的判断标准，扯皮会少很多。

模型路由这件事，技术本身不复杂，难的是判断时机和持续运营。四个问题回答清楚，该不该做、什么时候做、怎么做，基本就都有答案了。我在实际项目里最大的体会是：克制比激进更难，但往往更正确。