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 一个完整的请求处理流程我把一个请求从进来到出去的全过程走一遍你能看到每个环节在干什么。请求进入接入层做格式校验和限流检查。如果请求格式不对或者超过限流阈值直接返回错误不进入路由。判断层接收请求先跑规则过滤。如果命中“明显简单”规则比如纯问候、纯查询直接标记为简单跳过分类器。没命中规则的请求送入分类器。分类器输出复杂度标签和置信度。分发层根据标签查映射表找到对应的模型。如果置信度低于阈值走保守策略直接上大模型。调用模型拿到结果。如果走的是小模型进入质量检测环节。质量检测通过返回结果。不通过升级到大模型重新处理。监控层记录本次请求的复杂度标签、实际走的模型、是否升级、耗时、Token 消耗、费用。返回最终结果给用户。整个流程的额外延迟主要是分类器的推理时间大概 30 到 80 毫秒。对于大部分对话场景这个延迟可以接受。如果对延迟极度敏感可以把分类器做成异步的先返回一个默认模型的结果分类结果出来后再决定要不要替换。但这样实现复杂度会高很多我一般不建议。5. 踩过的坑和排查技巧5.1 分类器“偏科”导致某类请求全走大模型上线第一周我发现所有带“代码”两个字的请求都被判为复杂全走了大模型。但实际上很多代码请求只是“这段代码什么意思”这种简单解释小模型完全能处理。原因是训练数据里代码相关的复杂样本偏多分类器学偏了。解决办法是按类别做数据均衡。把请求按主题分类代码、写作、问答、分析等每个类别下的简单和复杂样本数量要均衡。如果某个类别复杂样本天然就多那就对简单样本做上采样或者对复杂样本做下采样。这个操作在训练前做一次就行但效果很明显。5.2 升级逻辑导致的“延迟尖刺”兜底升级机制有个副作用被升级的请求要等小模型跑完、质量检测跑完、再跑大模型总延迟是小模型延迟加大模型延迟。如果小模型本身就要 2 秒大模型要 5 秒这个请求就要 7 秒以上。用户体感就是“偶尔特别慢”。我的优化方式是并行化。对于置信度处于中间地带的请求比如分类器给出简单 0.55不等待小模型结果直接同时调用小模型和大模型谁先返回且质量合格就用谁。这样大部分情况下小模型先返回延迟和小模型单独调用差不多少数情况下大模型先返回也不会比单独调用大模型慢。代价是这些请求会同时消耗两个模型的 Token但这类请求占比不高总账还是划算的。5.3 监控数据“看起来很美”但实际没省到钱有段时间监控显示升级率只有 5%看起来很健康。但月底对账发现费用没降多少。排查后发现问题出在Token 计量口径上。监控里统计的是“请求数”但费用是按“Token 数”算的。简单请求虽然数量多但 Token 少复杂请求数量少但 Token 多。按请求数算升级率很低按 Token 数算其实不低。后来我把监控指标改成按 Token 加权统计才看到真实情况。这个坑很隐蔽因为大部分监控工具默认按请求数统计。如果你在做成本优化一定要确认你的监控指标是按什么口径算的。5.4 常见问题速查表现象可能原因排查方向解决方式成本没降监控口径不对检查是按请求数还是 Token 数统计改成 Token 加权统计某类请求全走大模型分类器训练数据偏斜按类别统计分流比例做数据均衡后重训偶发高延迟升级逻辑串行执行查看升级请求的耗时分布改为并行调用升级率突然升高小模型服务异常检查小模型返回质量加模型健康检查分类器准确率下降请求分布漂移对比新旧请求的特征分布定期重训分类器注意路由系统不是搭完就一劳永逸的。请求分布会变模型能力会变价格也会变。我建议至少每个月 review 一次路由策略每季度重训一次分类器。把它当成一个持续运营的系统而不是一个一次性项目。6. 路由之外这个趋势还会往哪走6.1 从“模型路由”到“能力路由”现在的路由基本还是在“选模型”这个层面。但往远看一点路由的粒度会更细。不是选一个模型而是选一种能力组合。比如一个请求可能需要“推理 联网搜索 代码执行”三种能力路由层负责编排这三种能力的调用顺序和参数。这时候路由就变成了一个能力调度器模型只是能力的一种载体。这个方向已经有苗头了。一些 AI Agent 框架里工具调用和模型调用是统一调度的。路由层不关心你用的是哪个模型只关心你能不能提供“搜索”这个能力。这种抽象层次更高也更灵活。6.2 路由策略的“学习化”现在的路由策略大部分还是人工配置的——你告诉系统什么情况走什么模型。但更理想的状态是系统自己学出来。给定一个目标比如“在成本不超过 X 的前提下最大化满意度”系统通过不断试错自动找到最优的路由策略。这就是强化学习在路由上的应用。我试过一个简化版的方案用多臂老虎机算法把每个“请求类型-模型”组合当成一个臂根据历史反馈动态调整选择概率。跑了一段时间效果比固定规则好一些但需要足够的流量才能收敛。小流量场景下还是规则更稳。6.3 对开发者的影响从“调模型”到“调策略”这个趋势对开发者的技能要求是有影响的。以前做 AI 应用核心工作是“写好 Prompt、调好参数”。以后可能更多是“设计好路由策略、维护好分类器”。工作重心从“和模型对话”变成“和系统对话”。这不是说 Prompt 不重要了而是说 Prompt 只是系统里的一个环节。你需要理解整个请求生命周期知道每个环节的成本和延迟贡献才能做出好的优化决策。对全栈能力的要求其实是变高了。我个人在实际操作中的体会是路由这件事看起来是技术问题其实是业务理解问题。你得非常清楚你的用户在问什么、什么答案算好答案、什么体验算可接受。这些判断没法完全交给算法得靠人对业务的理解来定框架算法在这个框架里做优化。所以别指望搭一个全自动的路由系统就完事了人的判断始终是核心。最后分享一个小技巧如果你刚开始做路由不要一上来就搞复杂的分类器。先用最简单的规则跑两周把日志攒起来看看你的请求到底长什么样。很多时候你会发现光靠“输入长度 关键词”这两条规则就能分流掉 60% 以上的请求。剩下的再慢慢优化。先跑起来再跑得好这个顺序别搞反了。