1. 从一组成本数据说起为什么路由比模型更值得关注第一次看到56% 的 Token 只花了 14% 的钱这个说法我的直觉是这要么是统计口径有问题要么就是背后藏着一套非常精细的调度逻辑。后来自己动手拆了几套线上 AI 应用的调用日志才发现这个比例其实相当真实甚至在某些场景下比这还极端。先把这句话翻译成人话。假设一个 AI 应用一天消耗 1000 万个 Token其中大约 560 万个 Token 走的是便宜通道只花掉了总成本的 14%剩下 440 万个 Token 走了贵通道吃掉了 86% 的钱。也就是说真正决定账单的不是你用了多强的模型而是你把哪些请求分给了哪个模型。这件事的意义在于过去两年大家讨论 AI 应用焦点几乎都在模型本身参数多大、上下文多长、推理能力多强、榜单排第几。但当你真正把 AI 应用跑起来、开始按 Token 付费之后会发现一个很现实的问题——大部分请求根本不需要最强模型。用户问今天天气怎么样和问帮我分析这份合同里的风险条款需要的推理深度完全不是一个量级但如果你不做区分两者都会打到同一个贵模型上钱就是这么烧掉的。所以这篇文章想聊的核心不是某个具体模型有多强而是路由Routing这件事为什么正在成为 AI 应用的分水岭。我会从 Token 成本结构讲起拆解路由的几种典型策略给出可落地的实现思路再聊聊实际做路由时踩过的坑。适合正在做 AI 应用、被 Token 账单困扰、或者想搞清楚多模型协作到底怎么落地的朋友。提示本文讨论的路由指的是请求分发与模型调度层面的路由和网络设备里的路由、前端框架里的路由不是一回事虽然底层根据条件选择路径的思想是相通的。2. Token 成本的真实结构贵在哪里便宜在哪里2.1 为什么 Token 单价差异能到几十倍要理解 56% 对 14% 这个比例得先搞清楚 Token 定价的逻辑。不同模型的 Token 单价差异本质上来自三个维度模型规模、推理时延要求、以及输出质量的下限保证。模型规模好理解参数越多、激活的计算量越大单次推理的算力成本就越高。但很多人忽略的是输入 Token 和输出 Token 的价格往往不一样而且输出通常更贵。原因在于输入阶段可以做并行处理Prefill而输出阶段是逐 Token 生成的Decode后者对显存带宽和调度效率的要求高得多单位算力产出更低。第二个维度是时延要求。一个要求 200ms 内返回的实时对话场景和一个可以等 10 秒的批量分析任务能用的模型和部署方式完全不同。低时延往往意味着要用更小的模型、更激进的批处理策略成本结构自然不一样。第三个维度最容易被忽视质量下限保证。有些贵模型贵不只是因为大而是因为它在长尾问题上的稳定性更好。你让它处理一个刁钻的边界情况它不会胡编便宜模型可能 90% 的情况都对但剩下 10% 会给你惹麻烦。这 10% 的保险成本就是贵模型溢价的一部分。2.2 一个真实的成本拆解示例我拿自己经手的一个客服辅助系统举例。这个系统每天处理大约 8 万次请求接入的是两档模型一档是轻量模型一档是旗舰模型。跑了一个月之后我把日志按请求类型做了归类结果大致是这样的请求类型占比平均输入 Token平均输出 Token走哪档模型成本占比简单问答/寒暄38%12080轻量4%信息检索/摘要18%800200轻量10%多轮对话理解22%1500400旗舰28%复杂推理/分析15%3000800旗舰42%兜底/异常处理7%2000600旗舰16%把轻量的两档加起来请求占比 56%成本占比 14%。这就是标题里那个数字的来源。而剩下 44% 的请求吃掉了 86% 的成本。这张表最值得琢磨的地方在于简单问答和寒暄占了将近四成的请求量但成本几乎可以忽略。如果你不做路由把这 38% 的请求也打到旗舰模型上成本会直接翻好几倍。反过来复杂推理只占 15% 的请求量却是成本大头这部分你想省也省不了因为省了质量就崩。2.3 成本优化的三个杠杆路由是性价比最高的那个做 AI 应用的成本优化通常有三个杠杆模型选型、Prompt 压缩、请求路由。模型选型是战略级的一旦定了短期内不好改而且往往受制于效果要求。Prompt 压缩是战术级的能省一部分输入 Token但压缩本身有信息损失风险压过头了效果就掉。请求路由则是结构级的优化它不改变单个请求的处理质量只是把请求放到最合适的地方去处理理论上没有质量损失收益却最直接。这也是为什么我说路由正在成为分水岭。模型选型大家都会做Prompt 压缩是基本功但能不能把路由做细、做稳、做智能直接决定了你的单位成本能压到多低。同样一套功能路由做得好的团队成本可能是做得糙的团队的三分之一甚至更低。3. 路由策略的四种典型形态从规则到学习3.1 静态规则路由最土但最稳的起点刚起步的团队我一般建议从静态规则路由开始。所谓静态规则就是根据请求的显式特征做判断比如按请求来源分内部工具走轻量面向客户走旗舰按输入长度分输入 Token 少于 500 走轻量超过走旗舰按功能模块分翻译、摘要走轻量代码生成、逻辑推理走旗舰按用户等级分免费用户走轻量付费用户走旗舰这种路由的好处是完全可预测、可解释、好调试。出了问题你能一眼看出是哪个规则把请求分错了。坏处也很明显规则是死的请求是活的。用户可能用很短的输入问一个极难的问题也可能用很长的输入问一个很简单的问题纯靠长度或来源判断误判率不低。我的经验是静态规则适合作为第一层粗筛先把明显该走轻量的请求分流出去剩下的再交给更精细的判断。不要指望一层规则解决所有问题。3.2 分类器路由用小模型判断该用哪个大模型再进一步就是训练一个轻量分类器专门判断这个请求该走哪档模型。这个分类器本身可以是个小模型甚至是个传统的文本分类模型成本极低。分类器的输入是请求的文本特征输出是简单/复杂或者该走哪档的标签。训练数据从哪来两个来源一是历史日志里已经标注过的请求二是人工构造的样本。我一般会先跑一段时间全量走旗舰模型把请求和响应质量都记下来然后人工标注一批这个请求其实轻量模型也能处理好的样本用来训练分类器。这里有个关键细节分类器的目标不是判断请求难不难而是判断轻量模型能不能处理好。这两者不是一回事。有些请求看起来复杂但轻量模型处理得挺好有些请求看起来简单但轻量模型就是会翻车。所以标注的时候判断标准应该是轻量模型的输出是否可接受而不是这个问题本身难不难。分类器路由的准确率能做到 85% 到 92% 之间具体取决于场景。剩下的误判一部分是该走旗舰的走了轻量质量风险一部分是该走轻量的走了旗舰成本浪费。前者更危险所以实际部署时通常会给分类器设一个偏向保守的阈值宁可多花点钱走旗舰也不要让质量掉下去。3.3 置信度路由让模型自己说我不确定还有一种思路更巧妙先让轻量模型处理同时让它输出一个置信度或者自评分数如果置信度低于阈值再升级到旗舰模型重跑一遍。这种先便宜后贵的策略理论上能把成本压到最低因为只有真正需要升级的请求才会走贵通道。但实操中有两个坑第一个坑是轻量模型的置信度往往不准。模型说我很确定的时候可能其实在胡编说我不确定的时候可能答案是对的。这需要专门做置信度校准或者用多次采样的一致性来估计可靠性。第二个坑是升级重跑有额外成本。如果轻量模型已经生成了一大段输出再让旗舰模型重跑等于同一份输入付了两次钱。所以这种策略更适合输出较短的场景或者让轻量模型只做判断不做生成判断完再决定谁来生成。3.4 学习型路由把路由本身当成一个优化问题最前沿的做法是把路由当成一个强化学习或者在线优化问题系统根据历史反馈不断调整路由策略目标是在质量约束下最小化成本。这种做法的想象空间很大但落地门槛也高。它需要稳定的质量反馈信号——你得知道每次路由决策之后用户到底满不满意。如果拿不到可靠的反馈学习型路由就是在瞎调。而且在线学习本身有探索成本探索期间可能会把一些请求错误地分到轻量模型上造成质量波动。我的建议是除非你有成熟的反馈闭环和足够的流量否则不要一上来就搞学习型路由。静态规则加分类器已经能拿到大部分收益了。4. 把路由落地一套可复现的实现框架4.1 路由层应该放在哪里路由层的位置很关键。常见的三种放法第一种是放在网关层所有请求先经过网关网关决定转发给哪个模型服务。好处是统一管控、对上层透明坏处是网关层拿不到业务上下文只能靠请求本身的信息做判断。第二种是放在业务层每个业务模块自己决定调哪个模型。好处是上下文丰富、判断更准坏处是路由逻辑分散不好统一优化和监控。第三种是独立的路由服务业务层把请求和上下文一起发给路由服务路由服务返回该用哪个模型。这种折中方案我比较推荐既保留了上下文又能集中管理路由策略。实际部署时我通常会在网关层做一层粗筛比如按来源、按长度然后在业务层或独立路由服务做精细判断。两层配合效果比单层好很多。4.2 一个最小可用的路由决策流程下面这套流程是我在几个项目里反复用过的可以直接参考def route_request(request, context): # 第一层硬规则快速分流 if request.source internal_tool: return light_model if request.max_tokens 200 and request.task_type in [chat, translate]: return light_model # 第二层分类器判断 features extract_features(request, context) complexity_score classifier.predict_proba(features) # 第三层结合业务约束 if context.user_tier free and complexity_score 0.7: return light_model if complexity_score 0.4: return light_model elif complexity_score 0.75: return mid_model else: return flagship_model这段代码的关键在于分层决策先用零成本的硬规则砍掉一批明显简单的请求再用分类器处理剩下的最后结合业务约束做微调。每一层都有明确的职责出问题也好定位。4.3 特征工程路由判断到底看什么分类器路由的效果很大程度上取决于特征选得好不好。我总结下来真正有用的特征大概分四类文本本身的特征输入长度、句子数、是否包含代码块、是否包含数字或公式、词汇复杂度。这些特征便宜好算能覆盖大部分情况。任务类型的特征请求属于哪个功能模块、期望的输出格式是短回答还是长文、是否要求结构化输出。任务类型往往比文本本身更能说明问题。上下文的特征这是第几轮对话、历史对话里有没有复杂推理、用户之前有没有对质量表达过不满。多轮对话场景下上下文特征特别重要。业务的特征用户等级、请求时段、当前系统负载。这些特征和模型能力无关但和成本、体验的权衡有关。有个反直觉的经验输入长度这个特征单独用效果一般但和其他特征组合起来很有用。因为长输入既可能是复杂任务也可能只是用户贴了一大段背景资料。得结合任务类型一起看。4.4 灰度上线与效果验证路由策略上线绝对不能一把梭。我的做法是灰度 对照先切 5% 的流量走新路由同时保留一个对照组走原来的全量旗舰模型。跑一周对比两组的成本、响应时延、以及质量指标。质量指标怎么来可以用人工抽检也可以用自动评估比如让旗舰模型给轻量模型的输出打分。如果质量指标没有明显下降成本明显下降再逐步放量到 20%、50%、100%。每一步都要留观察期别急着全量。注意灰度期间一定要监控升级率和降级率。升级率是指本该走轻量却走了旗舰的比例降级率反过来。降级率过高说明路由太保守成本没省下来升级率过高说明路由太激进质量有风险。5. 路由做深之后才会遇到的坑5.1 分类器的分布漂移上线三个月后突然不准了这是我踩过最隐蔽的一个坑。分类器刚上线时准确率 90%跑了三个月掉到 78%但没有任何代码改动。排查了很久才发现是请求分布漂移了业务上线了新功能用户提问的方式变了分类器训练时见过的特征分布和现在对不上了。解决办法有两个一是定期用新数据重新训练分类器我一般设一个月一次二是监控特征分布一旦发现某个关键特征的分布明显偏移就触发告警。第二个办法更主动能在准确率掉下来之前就发现问题。5.2 多轮对话里的路由一致性单轮请求路由很简单但多轮对话就麻烦了。如果第一轮走了轻量模型第二轮走了旗舰模型两轮的回答风格、知识水平可能不一致用户会觉得这个 AI 怎么一会儿聪明一会儿笨。我的处理方式是以会话为单位做路由而不是以单次请求为单位。一个会话开始时就根据首轮请求定好档位后续轮次除非有明确的升级信号比如用户说你答得不对否则保持同一档位。这样体验更连贯实现上也简单。5.3 路由失败时的兜底逻辑路由层本身也会失败分类器超时、特征提取报错、路由服务不可用。这时候必须有兜底逻辑否则整个请求就挂了。兜底的原则是宁可走贵的不能走错的。路由失败时默认走旗舰模型保证质量。同时记录失败日志事后分析。我见过有团队为了省钱路由失败时默认走轻量模型结果偶尔出现质量事故得不偿失。5.4 成本节省的虚假繁荣还有一种坑比较微妙路由确实把成本降下来了但用户体验也悄悄降了只是短期内没暴露。比如轻量模型在某个边界场景下会给出似是而非的答案用户当时没发现过几天才回来投诉。防范这种问题除了常规的质量抽检我还会做一件事定期把轻量模型的输出拿给旗舰模型复核看看有多少是旗舰模型会给出不同答案的。如果差异率超过某个阈值就说明路由太激进了得收紧。6. 路由之外多模型协作的更大图景6.1 路由只是第一步编排才是终局路由解决的是这个请求给谁做但更复杂的场景需要的是多个模型怎么配合做。比如一个任务先让轻量模型做信息抽取再让旗舰模型做推理最后让另一个模型做格式化输出。这就是模型编排比单纯的路由更进一步。编排的复杂度高很多但收益也大。它能让每个模型只做自己最擅长、最划算的那部分整体成本和质量的平衡点比单模型路由更优。6.2 缓存与路由的配合路由和缓存是天然的一对。很多请求其实是重复的或者高度相似的。如果能在路由之前先查缓存命中就直接返回连模型都不用调。缓存的粒度可以很细完全相同的请求、语义相似的请求、同一用户的连续请求。语义缓存需要用向量检索来判断相似度成本比精确匹配高但命中率也高得多。我一般会先上精确缓存跑一段时间看命中率再决定要不要上语义缓存。6.3 路由策略的持续演进路由不是一次性的工程而是需要持续迭代的。业务在变、模型在变、用户也在变路由策略得跟着变。我的做法是把路由策略当成一个产品来运营有明确的指标成本、质量、时延、有定期的复盘、有版本管理。具体来说我会每个月做一次路由复盘看几个核心指标整体成本、各档模型的调用占比、分类器准确率、升级降级率、用户质量反馈。哪个指标异常就深挖哪个。这套机制跑下来路由策略能一直保持在比较优的状态。7. 我自己的几条实操心得聊了这么多策略和框架最后分享几条我自己踩坑踩出来的经验都是文档里不会写的。第一条先量化再优化。很多人一上来就想搞智能路由但连自己现在的成本结构都没搞清楚。先老老实实把日志打全按请求类型、模型档位、Token 用量做一次完整的成本拆解你会发现问题往往比想象的简单——可能 80% 的成本就集中在两三个功能模块上把那几个模块的路由做对收益就拿到了。第二条路由的收益有上限别指望它解决所有成本问题。路由能优化的是分配不能优化总量。如果你的 Prompt 本身就很冗长或者业务逻辑上就是需要大量 Token路由帮不了你。该做 Prompt 压缩还得做该优化业务流程还得优化。第三条质量监控比成本监控更重要。成本降下来是看得见的质量掉下去往往是隐性的。我见过太多团队盯着成本曲线沾沾自喜结果用户流失了才发现问题。质量监控的投入不能省。第四条别过度设计。静态规则能解决的就别上分类器分类器能解决的就别上强化学习。每多一层复杂度就多一份维护成本和出错概率。路由策略的复杂度应该和你的流量规模、成本压力匹配。小流量场景下一套简单的规则路由可能就够了。第五条把路由决策记录下来。每次请求走了哪个模型、为什么这么走、当时的特征是什么都要记下来。这些日志是后续优化的金矿也是出问题时排查的依据。我一般会把路由决策日志和请求日志分开存方便单独分析。这套东西做下来你会发现56% 的 Token 只花了 14% 的钱不是终点而是一个起点。真正有意思的是当你把路由做细之后会不断发现新的优化空间——某个功能模块其实可以再降一档某类请求其实可以走缓存某个分类器的阈值其实可以再调。这种持续优化的过程才是 AI 应用工程化最有意思的部分。