1. 一个反直觉的数字为什么钱没花在模型上第一次看到56% 的 Token 只花了 14% 的钱这个说法我的反应是这数据是不是统计口径有问题因为在大多数人的直觉里Token 消耗和成本应该是近似线性的——用得多就花得多用得少就花得少。但真实的生产环境跑下来这个比例关系会被彻底打破。先把这句话拆开看。它说的是在所有被消耗掉的 Token 里有 56% 是通过某种便宜通道处理的而这部分只占了总账单的 14%。换句话说剩下 44% 的 Token 吃掉了 86% 的成本。这个悬殊的差距就是路由这件事存在的全部理由。我拿自己经手过的一个 AI 客服系统举例。这个系统每天处理大约 12 万次对话请求早期是一个模型打天下——所有请求都丢给同一个旗舰模型。月底看账单的时候成本高得让人肉疼。后来我们做了一件事把请求按复杂度分层简单的走小模型复杂的才走大模型。改造完之后Token 总量几乎没变但账单直接砍掉了六成多。这里面的核心逻辑其实很朴素不是所有请求都值得用最贵的模型去处理。用户问你们的退货政策是什么和用户问帮我对比一下这三款产品在续航、重量、售后上的差异并结合我的使用场景给个建议这两件事对模型能力的要求完全不在一个量级。前者用一个小模型就能答得又快又好后者才需要旗舰模型来撑场面。所以这篇文章想聊的不是某个具体模型有多强而是当模型能力已经足够卷的时候真正的分水岭转移到了路由上——也就是怎么把每一个请求精准地送到最合适、最经济的那个模型手里。这件事听起来简单做起来全是细节。下面我会从成本结构、路由策略、落地实现、踩坑经验几个角度把这件事讲透。提示本文讨论的路由指的是 AI 请求在多个模型之间的调度分发和网络设备里的路由器、前端框架里的路由是两个完全不同的概念别混淆。2. 拆解成本结构Token 的钱到底花在哪了2.1 输入 Token 和输出 Token 的价差陷阱很多人算成本的时候习惯性地把 Token 当成一个统一单价来乘这是第一个大坑。实际上几乎所有主流模型服务商的计价都是输入和输出分开算的而且输出 Token 的单价通常是输入的 3 到 5 倍。我做过一个粗略的统计在一个典型的问答场景里如果系统提示词System Prompt写得比较长输入 Token 往往能占到总 Token 的 70% 以上。这时候如果你只盯着输出优化等于在捡芝麻丢西瓜。更麻烦的是上下文累积。多轮对话里每一轮都要把之前的历史重新塞进去。第 10 轮对话的输入 Token可能是第 1 轮的十几倍。如果不做上下文裁剪或者摘要压缩成本会随着对话轮次指数级往上窜。成本构成项典型占比优化空间系统提示词20%~40%精简、缓存历史对话上下文15%~35%裁剪、摘要用户当前输入5%~15%基本固定模型输出20%~40%控制长度、格式约束这张表是我根据几个实际项目估算出来的不同场景差异很大但规律是一致的真正必要的 Token 其实没那么多大量成本花在了冗余的上下文和过度的输出上。2.2 为什么旗舰模型的边际成本这么吓人旗舰模型贵贵在参数量、推理算力和背后的工程复杂度。但关键在于它的贵是按 Token 线性计费的而它带来的能力提升却往往不是线性的。举个具体的例子。在意图识别这个任务上一个小模型能达到 92% 的准确率旗舰模型能到 96%。看起来旗舰模型更强但为了这 4 个百分点成本可能要翻 20 倍。而在实际业务里92% 到 96% 的差距用户几乎感知不到——因为剩下的 4% 里大部分是本身就模棱两可的边界 case旗舰模型也未必答得对。这就是路由的经济学基础在能力足够的前提下永远选最便宜的那个。只有当任务复杂度超过某个阈值便宜模型确实搞不定的时候才升级到贵的模型。2.3 一个真实的成本对比测算我拿一个具体的请求来算笔账。假设用户问帮我写一段 200 字的产品介绍突出性价比和耐用性。走小模型输入约 300 Token输出约 300 Token。按小模型单价假设输入 0.001 元/千 Token输出 0.002 元/千 Token算单次成本约 0.0009 元。走旗舰模型同样 Token 量按旗舰单价假设输入 0.02 元/千 Token输出 0.06 元/千 Token算单次成本约 0.024 元。差了 26 倍。如果这个请求每天来 5 万次一年下来小模型方案是 1.6 万元旗舰方案是 43.8 万元。这中间的差价够养一个不小的团队了。而这类写一段介绍翻译一句话总结一段文字的请求在实际业务里占比往往超过一半。这就是那56% 的 Token 只花了 14% 的钱背后的真实图景——大部分请求根本不需要动用旗舰模型。3. 路由策略设计怎么判断一个请求该走哪条路3.1 基于规则的静态路由简单但有效最朴素的路由方式是写规则。比如按关键词匹配、按请求长度、按用户等级、按业务场景来分流。我早期做过一个很粗糙的版本如果用户输入少于 50 个字且不包含分析对比推理为什么这类词就走小模型否则走大模型。就这么一个简单的规则把成本压下去了将近一半而且用户投诉率没有明显上升。静态规则的好处是可解释、可预测、零额外成本。你不需要再调用一个模型来判断该用哪个模型那本身就是成本。坏处是覆盖不全遇到规则没覆盖到的边界情况容易误判。我的经验是静态规则适合作为第一层过滤处理那些特征极其明显的请求。比如纯翻译、纯格式转换、纯检索这类任务规则判断的准确率能到 95% 以上没必要上更复杂的机制。3.2 基于分类器的动态路由把判断也做成模型当规则覆盖不住的时候就得上分类器了。思路是训练一个轻量级的文本分类模型输入用户请求输出简单/中等/复杂三档然后映射到不同的模型。这个分类器可以做得非常小——用蒸馏过的小模型或者干脆用传统的文本分类算法比如 FastText、LightGBM 这类推理成本几乎可以忽略。关键是标注数据要准。我的做法是先跑一批请求人工标注哪些小模型能答好、哪些答不好用这批数据训练分类器。这里有个细节值得说分类器的目标不是判断请求难不难而是判断小模型能不能搞定。这两个目标看起来像其实不一样。有些请求看起来很难但小模型恰好擅长有些看起来简单小模型却容易翻车。所以标注的时候一定要以小模型的实际表现为准而不是凭主观感觉。3.3 基于置信度的兜底路由让小模型自己说我不行还有一种更优雅的思路先让小模型答同时让它输出一个置信度分数。如果置信度低于阈值就把请求转给大模型重答。这个方案的好处是不需要额外的分类器判断和生成合二为一。但难点在于置信度怎么拿。有些模型 API 直接返回 logprobs可以据此算置信度有些则需要让模型自己输出一个我有多确定的评分但模型自评的可靠性参差不齐。我实测下来比较稳的做法是组合判断小模型先答然后用一个极轻量的校验器可以是规则也可以是个小分类器判断答案质量。质量不达标就升级。这样比单纯依赖模型自评要可靠得多。3.4 三种策略的对比与组合策略类型判断成本准确率适用场景实现难度静态规则极低中特征明显的请求低分类器路由低高请求类型多样中置信度兜底中高对质量要求高中高实际生产里我一般用组合方案第一层静态规则快速过滤掉最明显的简单请求剩下的走分类器分类器拿不准的走置信度兜底。三层下来路由准确率能到 90% 以上而额外的判断成本不到总成本的 2%。4. 落地实现从零搭一套路由系统4.1 请求特征的提取与标准化路由的第一步是把请求变成可判断的特征。我通常会提取这几类信息文本特征长度、语言、是否包含特定关键词、句子复杂度。上下文特征对话轮次、历史长度、是否有附件。业务特征用户等级、请求来源、历史行为。任务特征是问答、生成、翻译还是分析。这些特征不需要多复杂但一定要标准化。我见过有人直接拿原始文本去匹配结果因为大小写、标点、空格的问题导致规则失效。统一做一遍清洗和归一化能省掉后面一堆麻烦。4.2 路由决策的代码骨架下面是一个简化版的路由决策逻辑用 Python 写思路清晰可以直接改成你需要的形态def route_request(request, context): # 第一层静态规则 if is_simple_task(request): return small_model # 第二层分类器 complexity classifier.predict(request.text) if complexity low: return small_model elif complexity high: return large_model # 第三层置信度兜底 answer, confidence small_model.generate_with_confidence(request) if confidence 0.85: return small_model, answer else: return large_model这段代码的关键在于分层。每一层只处理自己能处理的部分处理不了的往下传。这样既保证了效率又保证了准确率。4.3 模型调用的统一封装路由系统要对接多个模型如果每个模型都写一套调用逻辑维护起来会疯掉。我的做法是抽象一个统一的调用接口把不同模型的差异封装在底层。class ModelClient: def __init__(self, model_name, config): self.model_name model_name self.config config def generate(self, prompt, **kwargs): # 根据 model_name 分发到不同的底层实现 if self.model_name.startswith(small): return self._call_small(prompt, **kwargs) else: return self._call_large(prompt, **kwargs) def _call_small(self, prompt, **kwargs): # 小模型调用逻辑 pass def _call_large(self, prompt, **kwargs): # 大模型调用逻辑 pass这样上层路由逻辑只需要关心选哪个模型不用关心怎么调这个模型。后面要加新模型也只需要在底层加一个分支。4.4 灰度发布与效果监控路由系统上线不能一把梭。我的做法是先灰度拿 5% 的流量跑新路由对比新旧方案的成本和质量。质量指标包括用户满意度、答案采纳率、人工复核通过率。成本指标就是账单。灰度期间要重点看误判率——也就是本该走大模型却被路由到小模型的请求占比。这个指标直接决定用户体验。我一般会把误判率控制在 3% 以内超过就调整阈值。监控面板上我必看的几个数各模型的调用量占比、各模型的平均响应时间、路由决策的分布、升级率小模型答不好转大模型的比例。这几个数一波动基本就能定位到问题。5. 踩过的坑那些文档里不会写的教训5.1 上下文长度是隐形成本杀手前面提过上下文累积的问题这里展开说。我做过一个多轮对话项目前几轮成本很低到第 8 轮之后成本突然飙升。排查发现是因为历史对话没有裁剪每一轮都把前面所有内容重新塞进去。解决方案有两个一是滑动窗口只保留最近 N 轮二是摘要压缩把早期对话用一个小模型总结成一段话。我一般两个都用近期保留原文远期做摘要。这样既保住了关键信息又把 Token 量压下来了。注意裁剪上下文的时候一定要保留系统提示词和最近一轮的用户输入这两个丢了会直接影响回答质量。5.2 小模型的能力边界比想象中模糊刚开始做路由的时候我以为小模型的能力边界很清晰——简单任务能做好复杂任务做不好。实际跑下来发现边界是模糊的而且因任务而异。比如在提取结构化信息这个任务上小模型表现好得惊人几乎不输旗舰模型。但在多步推理上小模型翻车率很高。更麻烦的是同一个任务换个说法小模型的表现可能就天差地别。所以不能凭直觉划分任务难度必须用真实数据测。我的做法是每个任务类型都跑一批样本统计小模型的通过率通过率高于 90% 的归为简单低于 70% 的归为复杂中间的走兜底逻辑。5.3 路由判断本身也会出错路由系统不是万能的它自己也会误判。我遇到过几种典型的误判短请求被误判为简单用户只发了这个怎么办看起来很短但结合上下文其实是个复杂问题。长请求被误判为复杂用户粘贴了一大段文本让翻译长度很长但任务很简单。含关键词被误判请求里出现了分析两个字被规则路由到大模型但其实只是帮我分析下这句话的语法。这些误判没法完全避免但可以通过持续收集 bad case 并迭代规则/模型来降低。我一般每周复盘一次误判案例把高频的误判模式补进规则里。5.4 成本优化不能牺牲体验这是最重要的一条。我见过一些团队为了压成本把大量请求强行路由到小模型结果用户投诉暴涨最后不得不回滚。成本优化的前提是质量不掉线。我的原则是宁可多花点钱走大模型也不能让用户拿到明显糟糕的答案。具体做法是设置一个质量红线——比如用户满意度低于某个阈值就自动提高大模型的使用比例。6. 路由之外还有哪些降本空间6.1 提示词缓存很多模型服务商支持提示词缓存——如果系统提示词是固定的重复调用时可以命中缓存输入 Token 的费用能大幅降低。这个功能对于系统提示词很长的场景特别有用我实测能省下 30% 以上的输入成本。6.2 输出长度控制输出 Token 比输入贵所以控制输出长度很关键。我的做法是在提示词里明确要求简洁回答不超过 X 字同时在调用参数里设置 max_tokens 上限。但要注意max_tokens 设得太小会导致答案被截断反而影响体验。6.3 批处理与异步对于非实时场景比如批量生成内容、离线分析可以用批处理接口成本通常比实时调用低不少。我有个项目把夜间批量任务改成批处理模式成本直接降了 40%。6.4 多模型协作有些复杂任务与其用一个旗舰模型硬扛不如拆成几步每步用最合适的模型。比如分析一份财报并给出投资建议可以拆成小模型提取数据 → 中模型做初步分析 → 大模型做最终判断。这样总成本往往比单次旗舰调用更低质量还更可控。7. 我对这件事的判断路由这件事本质上是在能力、成本、体验三者之间找平衡点。模型越强这个平衡点越难找因为旗舰模型的能力溢出太严重了——大部分请求根本用不到那么强的能力。我个人的体会是路由不是一次性工程而是持续迭代的过程。业务在变模型在变用户请求的分布也在变。今天有效的路由策略三个月后可能就失效了。所以一定要把监控和迭代机制建起来让路由系统能跟着业务一起进化。另外别把路由想得太复杂。很多时候一个简单的规则加上持续的数据反馈效果比一套花哨的算法还好。我见过太多团队在路由算法上过度设计结果维护成本比省下来的钱还高。最后分享一个小技巧从最贵的请求开始优化。先找出那些单次成本最高的请求类型针对性地做路由投入产出比最高。等这些大头处理完了再去看长尾。这样能最快看到成本下降的效果也最容易说服团队继续投入。