1. 从一组数字说起：为什么56%和14%值得单独拎出来聊

第一次看到“56% 的 Token 只花了 14% 的钱”这个说法，我盯着看了好一会儿。做过大模型应用落地的人都知道，Token 消耗和费用之间的关系，从来不是线性的。你调一次 GPT-4 级别的模型，和调一次小参数量的轻量模型，同样一段输入输出，账单能差出几十倍。但真正让我觉得有意思的，不是这个比例本身，而是它背后指向的一个趋势：AI 系统的成本结构正在从“模型定价”转向“路由策略”。

说白了，过去两年大家比的是谁的模型更强、参数更大、榜单更高。但到了真正把 AI 塞进业务流里跑的时候，你会发现一个很现实的问题——不是所有请求都值得用最贵的模型。用户问“今天天气怎么样”和“帮我分析这份合同里的法律风险”，这两件事对模型能力的要求天差地别。如果全都走同一个高配模型，成本会失控；如果全都走低配模型，体验会崩盘。于是，“路由”这个概念就被推到了台前。

这篇文章我想聊的，就是**AI 路由（AI Routing）**这件事。它是什么、为什么现在变得关键、怎么落地、踩过哪些坑。适合正在做 AI 应用开发、成本优化、或者单纯对“多模型协作”感兴趣的从业者。不管你是刚接触大模型 API 调用的新手，还是已经在跑生产环境的工程师，应该都能从里面找到能直接用的东西。

我先把核心结论摆出来：路由的本质，是在“能力”和“成本”之间做动态匹配。56% 的 Token 走了便宜通道，只贡献了 14% 的费用，这不是魔法，而是把合适的请求分发给合适的模型之后，自然产生的结构性优化。下面我拆开讲。

2. 路由到底是什么：把“选模型”这件事从人手里拿走

2.1 一个生活化的类比：路由就像医院的预检分诊

你去三甲医院看病，不会一进门就直接冲进专家诊室。门口有个分诊台，护士问你哪儿不舒服，感冒发烧让你去普通内科，胸口疼让你去心内科，骨折让你去骨科。这个分诊台干的事，就是路由。

AI 路由干的是同一件事。用户发来一个请求，路由层先判断这个请求的“复杂度”和“意图”，然后决定把它交给哪个模型处理。简单问题交给小模型，复杂问题交给大模型，需要联网的走搜索增强，需要代码执行的走代码专用模型。整个过程对用户透明，用户只知道自己得到了回答，不知道背后换了几个模型。

这个思路其实不新鲜。微服务架构里的 API Gateway 早就在做类似的事——根据请求路径、Header、负载情况，把流量分发到不同的后端服务。AI 路由是把这套逻辑搬到了模型调用层，判断依据从“URL 路径”变成了“语义复杂度”。

2.2 为什么是现在：三个条件同时成熟了

路由这个概念能落地，不是偶然。我观察下来，有三个前提条件在最近一年同时具备了。

第一，模型梯队已经形成。现在市面上从轻量到旗舰，至少有四五个档次的模型可选。轻量模型处理简单任务的能力已经足够好，旗舰模型在复杂推理上的优势依然明显。这个“能力梯度”是路由存在的基础——如果所有模型能力都差不多，路由就没意义了。

第二，调用成本差异足够大。不同档次模型之间的价格差，普遍在 10 倍到 50 倍之间。这个差距大到足以让路由带来的成本优化变得非常可观。56% 的 Token 走便宜通道省下 86% 的费用，这个账算得过来。

第三，请求复杂度分布极不均匀。在真实业务里，大部分请求其实是简单请求。客服场景里 70% 以上是常见问题，代码助手场景里大量是补全和简单查询。这种“长尾分布”意味着，只要能把简单请求识别出来并分流，就能用很小的代价换到很大的成本下降。

注意：路由不是“用便宜模型替代贵模型”，而是“让每个请求找到它配得上的模型”。前者是降级，后者是匹配。这个区别很关键，搞混了就会做出体验很差的东西。

2.3 路由和“多 AI 协作”的区别

很多人把路由和多模型协作混为一谈，其实两者解决的是不同问题。多模型协作是“一个任务拆给多个模型一起干”，比如一个模型写初稿、另一个模型审校、第三个模型润色。路由是“一个请求选一个模型来干”，是分发逻辑，不是协作逻辑。

当然两者可以叠加。一个复杂请求可以先被路由判断为“需要多步处理”，然后进入一个协作流程，流程内部再对每一步做路由。但这是两层结构，不要混在一起设计，否则调试的时候会很痛苦。

3. 路由的核心机制：判断、分发、兜底

3.1 复杂度判断：路由器的“大脑”

路由最关键的一步是判断请求复杂度。这一步做不准，后面全白搭。我试过几种判断方式，各有优劣。

基于规则的方式是最简单的。比如按输入长度判断——超过 500 个 Token 的走大模型，否则走小模型。或者按关键词判断——出现“分析”“推理”“对比”这类词就走大模型。这种方式实现快、延迟低、可解释性强，但准确率有限，容易误判。一个很短的问题可能是极难的逻辑题，一个很长的输入可能只是复制粘贴的文本。

基于小模型分类的方式准确率更高。用一个轻量模型（或者一个专门训练的文本分类器）来判断请求属于哪个复杂度等级。这个分类器可以基于历史数据训练，输入是用户请求，输出是“简单/中等/复杂”三分类。实测下来，一个几百兆的分类模型就能做到 85% 以上的准确率，而且推理延迟可以控制在 50ms 以内。

基于语义嵌入的方式介于两者之间。把请求转成向量，和预先标注好的样本做相似度匹配，看它更接近哪一类。这种方式不需要训练，冷启动快，但需要维护一个标注样本库。

我目前用的是“规则 + 小模型分类”的混合方案。先用规则快速过滤掉明显简单的请求（比如纯问候、纯查询），剩下的交给分类器判断。这样既保证了速度，又保证了准确率。

3.2 分发策略：不只是“选一个模型”

判断完复杂度之后，分发策略决定了具体走哪条路。这里有几个维度要考虑。

成本优先还是体验优先。这是最根本的取舍。成本优先意味着尽量往便宜模型分流，体验优先意味着尽量往强模型分流。实际业务里通常是分场景配置——客服场景成本优先，核心业务体验优先。

静态分发还是动态分发。静态分发是预先配好规则，比如“简单请求走 A 模型，复杂请求走 B 模型”。动态分发会根据实时情况调整，比如某个模型当前响应慢或者限流了，自动切到备用模型。动态分发更稳，但实现复杂度高不少。

单模型还是模型组合。有些请求可以先用小模型试一下，如果小模型给出的答案置信度低，再升级到大模型。这种“级联”策略能在保证质量的前提下进一步省成本，但会增加一次调用的延迟。

下面这张表是我在实际项目里用过的几种分发策略对比：

3.3 兜底机制：路由出错怎么办

路由不可能 100% 准确。一个复杂请求被误判为简单，走了小模型，用户拿到一个敷衍的答案，这个体验损失比省下的那点钱大得多。所以兜底机制必须有。

我的做法是加一层“质量检测”。小模型返回答案后，用一个轻量的评估逻辑判断这个答案是否合格。判断方式可以是检查答案长度、检查是否包含“我不知道”这类回避性表述、或者用一个评估模型打分。如果判定不合格，自动升级到大模型重新处理。

这层兜底会增加成本，但增加的是“误判请求”的成本，而不是所有请求的成本。因为大部分请求是判断正确的，只有少数误判会触发升级。算总账还是划算的。

提示：兜底逻辑一定要设置上限，比如一个请求最多升级一次。否则可能出现小模型判不合格、大模型也判不合格、无限循环的情况。我见过有人没设上限，结果一个请求把两个模型都调了七八次。

4. 落地实操：从零搭一个可用的路由层

4.1 整体架构设计

我搭的路由层分四个模块：接入层、判断层、分发层、监控层。接入层负责接收请求、做基础校验和限流；判断层做复杂度分类；分发层根据分类结果调用对应模型；监控层记录每次路由的决策和结果，用于后续优化。

这个架构不复杂，但每个模块的边界要清晰。我见过有人把判断逻辑和分发逻辑写在一起，结果想调整判断规则的时候，发现要动分发代码，牵一发动全身。分开写，判断层只输出一个“复杂度标签”，分发层只根据标签做映射，两层通过一个简单的数据结构通信。

4.2 复杂度分类器的训练数据从哪来

这是很多人卡住的地方。要训练一个分类器，得有标注数据。但一开始你哪来的标注数据？

我的做法是先用规则跑一段时间，积累日志。规则判断虽然不准，但能跑起来。跑一周左右，你会积累几千条真实请求。然后人工抽检其中几百条，标注它们的真实复杂度。用这批数据训练第一版分类器，替换掉规则。分类器上线后继续积累日志，定期用新数据重新训练。

标注的时候有个技巧：不要标“简单/复杂”这种主观标签，要标“这个请求用哪个模型处理能得到满意结果”。这个标签更客观，也更贴近路由的实际目标。同一个请求，如果小模型能处理好，就标“小模型”；如果必须大模型，就标“大模型”。这样训练出来的分类器，直接对应分发决策。

4.3 关键参数配置与计算

路由层有几个参数需要仔细调，我把我用的配置和计算逻辑列出来。

分类阈值。分类器输出的是一个概率分布，比如“简单 0.7、中等 0.2、复杂 0.1”。你需要设一个阈值来决定怎么分。阈值设高了，很多请求会被判为复杂，成本下不来；设低了，简单请求会被误判，体验下降。我的经验是先用 0.6 作为初始阈值，然后根据监控数据微调。如果发现升级率超过 15%，说明阈值偏低，往上调；如果成本下降不明显，说明阈值偏高，往下调。

升级触发条件。什么情况下把小模型的答案升级到大模型？我设了三个条件：答案长度低于 20 个字符、答案包含“无法回答”类表述、评估模型打分低于 0.5。三个条件满足任意一个就触发升级。实测下来升级率在 8% 左右，比较健康。

超时与重试。每个模型调用设 10 秒超时，超时后自动切到备用模型。重试最多一次，避免雪崩。这里要注意，重试的时候不要重试同一个模型，要切到不同模型，否则如果那个模型本身有问题，重试也是白搭。

成本核算公式。我每周会算一次路由的实际节省效果。公式很简单：

节省比例 = 1 - (实际总费用 / 全走大模型的预估费用)

其中“全走大模型的预估费用”是用实际 Token 总量乘以大模型的单价算出来的。这个数字能直观告诉你路由到底省了多少钱。我最近一次算下来，节省比例在 72% 左右，和“56% Token 花 14% 钱”的说法基本吻合。

4.4 一个完整的请求处理流程

我把一个请求从进来到出去的全过程走一遍，你能看到每个环节在干什么。

1. 请求进入接入层，做格式校验和限流检查。如果请求格式不对或者超过限流阈值，直接返回错误，不进入路由。
2. 判断层接收请求，先跑规则过滤。如果命中“明显简单”规则（比如纯问候、纯查询），直接标记为简单，跳过分类器。
3. 没命中规则的请求，送入分类器。分类器输出复杂度标签和置信度。
4. 分发层根据标签查映射表，找到对应的模型。如果置信度低于阈值，走保守策略，直接上大模型。
5. 调用模型，拿到结果。如果走的是小模型，进入质量检测环节。
6. 质量检测通过，返回结果。不通过，升级到大模型重新处理。
7. 监控层记录本次请求的复杂度标签、实际走的模型、是否升级、耗时、Token 消耗、费用。
8. 返回最终结果给用户。

整个流程的额外延迟，主要是分类器的推理时间，大概 30 到 80 毫秒。对于大部分对话场景，这个延迟可以接受。如果对延迟极度敏感，可以把分类器做成异步的，先返回一个默认模型的结果，分类结果出来后再决定要不要替换。但这样实现复杂度会高很多，我一般不建议。

5. 踩过的坑和排查技巧

5.1 分类器“偏科”导致某类请求全走大模型

上线第一周我发现，所有带“代码”两个字的请求都被判为复杂，全走了大模型。但实际上很多代码请求只是“这段代码什么意思”这种简单解释，小模型完全能处理。原因是训练数据里代码相关的复杂样本偏多，分类器学偏了。

解决办法是按类别做数据均衡。把请求按主题分类（代码、写作、问答、分析等），每个类别下的简单和复杂样本数量要均衡。如果某个类别复杂样本天然就多，那就对简单样本做上采样，或者对复杂样本做下采样。这个操作在训练前做一次就行，但效果很明显。

5.2 升级逻辑导致的“延迟尖刺”

兜底升级机制有个副作用：被升级的请求要等小模型跑完、质量检测跑完、再跑大模型，总延迟是小模型延迟加大模型延迟。如果小模型本身就要 2 秒，大模型要 5 秒，这个请求就要 7 秒以上。用户体感就是“偶尔特别慢”。

我的优化方式是并行化。对于置信度处于中间地带的请求（比如分类器给出简单 0.55），不等待小模型结果，直接同时调用小模型和大模型，谁先返回且质量合格就用谁。这样大部分情况下小模型先返回，延迟和小模型单独调用差不多；少数情况下大模型先返回，也不会比单独调用大模型慢。代价是这些请求会同时消耗两个模型的 Token，但这类请求占比不高，总账还是划算的。

5.3 监控数据“看起来很美”但实际没省到钱

有段时间监控显示升级率只有 5%，看起来很健康。但月底对账发现费用没降多少。排查后发现，问题出在Token 计量口径上。监控里统计的是“请求数”，但费用是按“Token 数”算的。简单请求虽然数量多，但 Token 少；复杂请求数量少，但 Token 多。按请求数算升级率很低，按 Token 数算其实不低。

后来我把监控指标改成按 Token 加权统计，才看到真实情况。这个坑很隐蔽，因为大部分监控工具默认按请求数统计。如果你在做成本优化，一定要确认你的监控指标是按什么口径算的。

5.4 常见问题速查表

注意：路由系统不是搭完就一劳永逸的。请求分布会变，模型能力会变，价格也会变。我建议至少每个月 review 一次路由策略，每季度重训一次分类器。把它当成一个持续运营的系统，而不是一个一次性项目。

6. 路由之外：这个趋势还会往哪走

6.1 从“模型路由”到“能力路由”

现在的路由基本还是在“选模型”这个层面。但往远看一点，路由的粒度会更细。不是选一个模型，而是选一种能力组合。比如一个请求可能需要“推理 + 联网搜索 + 代码执行”三种能力，路由层负责编排这三种能力的调用顺序和参数。这时候路由就变成了一个能力调度器，模型只是能力的一种载体。

这个方向已经有苗头了。一些 AI Agent 框架里，工具调用和模型调用是统一调度的。路由层不关心你用的是哪个模型，只关心你能不能提供“搜索”这个能力。这种抽象层次更高，也更灵活。

6.2 路由策略的“学习化”

现在的路由策略大部分还是人工配置的——你告诉系统什么情况走什么模型。但更理想的状态是系统自己学出来。给定一个目标（比如“在成本不超过 X 的前提下最大化满意度”），系统通过不断试错，自动找到最优的路由策略。这就是强化学习在路由上的应用。

我试过一个简化版的方案：用多臂老虎机算法，把每个“请求类型-模型”组合当成一个臂，根据历史反馈动态调整选择概率。跑了一段时间，效果比固定规则好一些，但需要足够的流量才能收敛。小流量场景下，还是规则更稳。

6.3 对开发者的影响：从“调模型”到“调策略”

这个趋势对开发者的技能要求是有影响的。以前做 AI 应用，核心工作是“写好 Prompt、调好参数”。以后可能更多是“设计好路由策略、维护好分类器”。工作重心从“和模型对话”变成“和系统对话”。

这不是说 Prompt 不重要了，而是说 Prompt 只是系统里的一个环节。你需要理解整个请求生命周期，知道每个环节的成本和延迟贡献，才能做出好的优化决策。对全栈能力的要求其实是变高了。

我个人在实际操作中的体会是，路由这件事看起来是技术问题，其实是业务理解问题。你得非常清楚你的用户在问什么、什么答案算好答案、什么体验算可接受。这些判断没法完全交给算法，得靠人对业务的理解来定框架，算法在这个框架里做优化。所以别指望搭一个全自动的路由系统就完事了，人的判断始终是核心。

最后分享一个小技巧：如果你刚开始做路由，不要一上来就搞复杂的分类器。先用最简单的规则跑两周，把日志攒起来，看看你的请求到底长什么样。很多时候你会发现，光靠“输入长度 + 关键词”这两条规则，就能分流掉 60% 以上的请求。剩下的再慢慢优化。先跑起来，再跑得好，这个顺序别搞反了。