1. 从一组数字说起为什么 56% 的 Token 只花了 14% 的钱第一次看到“56% 的 Token 只花了 14% 的钱”这个说法我盯着屏幕愣了几秒。做过 AI 应用的人都知道Token 就是钱尤其是调用闭源大模型 API 的时候输入输出每一个 Token 都在烧预算。但这句话揭示了一个反直觉的事实超过一半的 Token 消耗其实只贡献了不到七分之一的成本。换句话说剩下 44% 的 Token 吃掉了 86% 的费用。这个数字背后藏着一个正在发生的结构性变化。过去两年大家讨论 AI 应用时最常问的是“你用哪个模型”——GPT-4 还是 Claude通义还是文心。模型本身的能力被当作核心竞争力选型几乎等同于选胜负。但当你真正把 AI 应用跑起来、接入真实用户、面对每天几百万次请求的时候你会发现一个更底层的问题不是所有请求都值得用最贵的模型。这就是“路由”这个概念开始浮出水面的原因。所谓路由在 AI 系统里指的是根据请求的特征动态决定把它发给哪个模型、走哪条链路、用什么参数。它听起来像网络工程里的老概念但在 AI 应用架构里它正在成为成本和质量之间那个最关键的调节阀。我写这篇东西是想把“模型路由”这件事从概念到落地讲透。适合谁看如果你正在做 AI 应用的成本优化、正在设计多模型架构、或者单纯好奇为什么你的 API 账单降不下来那这篇内容应该能给你一些可以直接抄作业的思路。我会尽量用从业者之间聊天的口吻把原理、参数、踩过的坑都摊开说。2. 模型路由到底是什么拆开“分水岭”这个词2.1 从“选一个最好的模型”到“给每个请求配一个合适的模型”早期做 AI 应用思路很朴素找一个能力最强的模型所有请求都发给它。这个策略在用户量小的时候没问题甚至可以说是最优解——因为维护一套链路最简单效果也最稳定。但用户量一上来问题就暴露了。我拿一个真实场景举例。假设你做了一个 AI 客服系统每天处理 10 万次对话。这些对话里大概有 60% 是“查订单状态”“问退货政策”“改收货地址”这类高度模板化的问题30% 是需要一定理解能力的“帮我对比这两款产品”“这个故障可能是什么原因”剩下 10% 才是真正复杂的“我要投诉并且要求赔偿”“帮我写一封正式的维权邮件”。如果你把所有请求都发给最贵的旗舰模型那 60% 的简单问题就是在用高射炮打蚊子。而如果你只用一个便宜的小模型那 10% 的复杂请求又会翻车用户体验直接崩掉。模型路由要解决的就是这个问题让简单的请求走便宜的链路复杂的请求走贵的链路同时保证用户感知不到差异。2.2 路由的三个决策维度任务类型、质量要求、成本预算路由不是简单地“按关键词转发”。一个能跑起来的路由系统至少要考虑三个维度。第一个维度是任务类型。分类、抽取、改写、摘要、推理、生成这些任务对模型能力的要求完全不同。一个 7B 参数的模型做意图分类可能已经足够但让它做多步推理就会胡言乱语。所以路由的第一层判断往往是这个请求属于哪类任务第二个维度是质量要求。同一个任务在不同场景下的质量底线不一样。比如同样是“摘要”给内部员工看的会议纪要摘要和给客户发的合同摘要容错率差了好几个数量级。路由需要知道当前请求的“质量档位”在哪里。第三个维度是成本预算。这个最直接你愿意为这次请求花多少钱如果一次请求的预算上限是 0.001 元那旗舰模型根本不在候选列表里。预算约束会直接砍掉一批模型选项剩下的再按能力排序。这三个维度组合起来才构成一个完整的路由决策。我见过不少团队一开始只做了“按任务类型转发”结果发现成本没降多少因为大量请求虽然任务简单但被错误地路由到了贵模型。后来加上质量档位和预算约束成本才真正下来。2.3 为什么说这是“分水岭”从模型竞赛到工程竞赛“分水岭”这个词用得很准。过去两年AI 行业的竞争焦点在模型本身——谁的参数多、谁的榜单高、谁的上下文长。但当一个行业从“能不能做出来”进入“能不能便宜地做出来”的阶段竞争焦点就会转移到工程能力上。模型路由就是工程能力的典型代表。它不要求你训练新模型也不要求你发明新算法它要求的是你对业务请求有足够细的颗粒度理解对各个模型的能力边界有清晰的认知对成本结构有精确的测算。这些东西听起来不酷但它们决定了你的 AI 应用能不能规模化、能不能盈利。我个人的判断是未来一年内“你会不会做路由”会比“你用哪个模型”更能拉开团队之间的差距。因为模型能力会逐渐趋同但每个业务的请求分布、质量要求、成本结构都是独特的路由策略没有标准答案只能自己磨。3. 路由策略的核心设计怎么让 56% 的 Token 走便宜链路3.1 请求分级把“什么请求”变成“什么级别”做路由的第一步是给请求分级。分级不是拍脑袋而是基于历史数据做统计分析。我的做法通常是先跑一周的全量日志把每个请求的输入长度、输出长度、任务类型、用户反馈如果有都记录下来然后做聚类。聚类之后你会发现请求天然会分成几堆。以我最近做的一个项目为例日志跑下来请求分布大概是这样的请求级别占比典型特征可用模型档位L1 简单约 55%短输入短输出模板化意图明确小模型或规则引擎L2 中等约 30%中等长度需要一定理解输出有结构要求中档模型L3 复杂约 12%长输入多步推理输出质量要求高旗舰模型L4 特殊约 3%超长上下文或需要特定能力如代码、数学专用模型这个分布和“56% Token 花 14% 钱”的说法能对上L1 占了超过一半的请求量但因为输入输出都短Token 消耗占比很低L3 和 L4 虽然请求量少但每次消耗的 Token 多而且单价高所以吃掉了大部分成本。分级的关键是可解释、可复现。你不能今天按这个标准分明天按那个标准分否则路由策略没法迭代。我一般会把分级规则写成明确的判断条件比如输入 Token 数小于 200 且命中意图分类器的某个类别就归为 L1。这些条件要能写成代码而不是靠人工感觉。3.2 模型池管理不是模型越多越好分级做完之后你需要一个模型池。模型池不是越大越好我见过有人接了十几个模型结果维护成本高得离谱而且很多模型的能力重叠根本用不上。我的建议是模型池里保持 3 到 5 个模型就够了但要覆盖不同的能力档位和成本档位。一个典型的模型池长这样极速档小参数模型或规则引擎延迟极低成本极低负责 L1 请求。均衡档中等参数模型能力和成本平衡负责 L2 请求。旗舰档最强模型负责 L3 请求。专用档针对特定任务优化的模型比如代码模型、数学模