从模型到路由：AI应用成本优化的关键跃迁

上周帮一个技术团队优化AI客服账单，看到他们的月度消耗报表时，我愣了一下：总量约2亿Token的调用里，有56%的Token其实在处理“查订单状态”“问门店营业时间”“帮用户格式化一段地址”这种几乎不需要任何推理的任务。这些请求全部被丢给了当时最贵的旗舰模型，费用占比自然高得离谱。我们只是在入口加了一层路由，把这部分流量导到便宜模型上，结果这56%的Token最终只花了总成本的14%，整体账单直接砍掉一半多，回答质量几乎没有肉眼可见的下降。

这件事让我对“AI应用的分水岭”有了很直观的认知：以前大家拼的是谁能接上更强的模型，现在和接下来一段时间，拼的是谁把模型用得聪明。而“用得聪明”的关键，已经不在模型本身，而在路由。

1. 先看懂趋势：为什么说AI的分水岭正在从模型转向路由

1.1 大多数AI应用的真正痛点不是模型不够强，而是用得太奢侈

我见过太多团队把GPT-4o、Claude Opus这类顶级模型当成默认选项，所有流量无脑打到最贵的接口上。理由是“省心”——反正模型够强，什么问题都能答。这个思路在Demo阶段没问题，一旦流量起来就非常难受。

举一个很常见的例子：电商平台的智能助手。用户问的问题分布极其悬殊，绝大多数是“我的快递到哪了”“怎么申请退货”“你们客服电话多少”这类低难度请求，真正需要多步推理、复杂理解、代码生成的高难度请求可能连20%都不到。但如果不做任何区分，每一个请求都在按旗舰模型的价格计费，相当于你用一把手术刀去削苹果皮，能削，但成本完全失控。

这里有一个很关键的认知：模型的“能力”是存在严重溢出的。旗舰模型能解数学证明题，不代表它适合回答“营业时间是几点”。能力溢出的部分你没有用到，却要照单全付。路由解决的问题，就是不让你为永远用不到的那部分能力买单。

1.2 路由层的本质：给每个请求找到能力与价格匹配的模型

说到路由，很多人的第一反应是“这不就是负载均衡嘛”。传统的网关路由确实也是按规则把请求分给不同后端，但AI场景下的路由有一个本质区别：它分配的不是服务器，而是“智能程度”，而且判断依据不是简单的URL或请求头，而是自然语言背后的语义和任务难度。

换句话说，传统路由看的是“请求长什么样”，AI路由看的是“请求需要多聪明的模型才答得出来”。这个判断本身就是一个小型AI任务。你要在请求到达模型之前，先对它做一次“预审”——意图是什么、难度有多高、需要什么级别的推理能力、有没有领域限制。

这也是我认为“分水岭从模型转向路由”的深层原因：当各家模型的能力差距在快速缩小，决定一个应用成本结构和体验上限的，已经从“选哪家模型”变成了“怎么在正确的时间把请求交给正确的模型”。模型是发动机，路由是变速箱。发动机再强，挡位挂错了也跑不出好成绩。

2. 拆解成本账：56%的Token为什么只花了14%的钱

2.1 请求分级：先把长尾流量按难度分层

想做好路由，第一步不是写代码，而是把现有流量彻底盘一遍。我一般会让团队从日志里随机抽几千条真实请求，人工打标签，归类成三档：

• L0档：信息查询类、格式化类、简单问答。比如“查一下订单号12345的状态”“把这段文字改成表格”。这类请求基本不需要推理，检索或套模板即可，小模型完全能胜任。
• L1档：需要一定理解或归纳的任务。比如“帮我总结这份合同里关于违约的条款”“这个差评想表达什么核心诉求”。需要中等模型跑一遍。
• L2档：复杂推理、长上下文、多步骤任务。比如“对比这三个方案并给出建议”“根据这段代码找出潜在 bug 并解释原因”。必须上旗舰模型。

从真实数据看，大部分B端场景里L0档请求占比会非常高，50%到70%都很正常。这56%的Token，通常就落在这一档。分级做完了，成本优化的天花板也基本看清楚了。

2.2 模型分级：建立能力阶梯与价格阶梯

请求分好级，下一步是给模型排一个“价格梯队”。以我常用的组合为例：

• 便宜档：自部署的开源小模型（比如7B到8B量级），或者各家API的迷你版。单价通常在每百万Token 0.1到0.5美元之间，如果本地部署甚至只花电费和显卡折旧。
• 中端档：中等规模的模型，比如GPT-4o mini、Claude Haiku这一档，单价大概在0.4到1美元每百万Token。
• 旗舰档：GPT-4o、Claude Opus这类顶级模型，输入单价往往是便宜档的8到15倍，输出更贵。

这里最核心的杠杆就是价格差。旗舰模型和便宜小模型之间的单价差越大，路由带来的节省就越夸张。这也是为什么“56%的Token只花14%的钱”这个数据看起来反直觉——它背后就是一道简单的算术题。

2.3 算一笔具体的账：模型的成本数学推导

我拿一个实际项目里的数字拆给大家看，这样比较好理解。

假设某个月总共消耗了2亿Token，其中：

• 简单请求消耗1.12亿Token，占比56%
• 复杂请求消耗8800万Token，占比44%

价格设定：

• 便宜模型：每百万Token 0.3美元
• 旗舰模型：每百万Token 2.34美元

如果所有流量全部走旗舰模型，总费用是200 × 2.34 = 468美元。

加上路由之后：

• 简单请求费用：112 × 0.3 = 33.6美元
• 复杂请求费用：88 × 2.34 = 205.92美元
• 总费用：239.52美元

这56%的Token（112万 × 百万单位）花了33.6美元，占总费用239.52美元的14.03%。看，数据完全对上了。

更直观的是总成本变化：468美元降到239.52美元，省了将近一半。而且这还只是输入Token的计算，如果把输出Token的差价也算进去，节省比例会更夸张。我在实际项目里见过路由之后整体成本降到原来的三分之一甚至四分之一的情况。

这里的核心公式其实非常简单：只有当便宜模型的单价远低于旗舰模型，且便宜模型能处理的请求占比足够高时，路由的收益才会显著。如果一个场景里80%都是复杂请求，路由能省的钱就很有限，这也是为什么我建议团队先做流量分析再决定要不要上路由。

3. 路由方案的实操步骤：从规则路由到智能路由

3.1 第一版：关键词规则路由，30分钟上线

最朴素的路由实现就是写规则，通过关键词、正则、请求来源、会话上下文等条件，把请求分到不同模型。这个版本不需要任何额外模型开销，几乎零成本，适合绝大多数场景跑通第一版。

分享一个典型的规则设计思路：

• 命中“订单号”“物流”“查询”“退款”等词，且句子长度在20个token以内，走便宜模型
• 包含“总结”“对比”“分析”“为什么”“解释”等强推理词，走旗舰模型
• 包含代码片段、报错日志、JSON结构，走中端或旗舰模型
• 默认兜底策略：分不清的一律走中端模型

class KeywordRouter: def __init__(self): self.simple_keywords = ["订单", "物流", "营业时间", "电话", "地址", "退款"] self.complex_keywords = ["总结", "对比", "分析", "为什么", "原因", "建议", "代码"] def route(self, query: str, token_count: int) -> str: if any(k in query for k in self.complex_keywords): return "premium" if any(k in query for k in self.simple_keywords) and token_count < 40: return "cheap" return "standard"

这套规则的问题也很明显：关键词覆盖不全，长句子和复杂语义识别不准。所以它只适合作为“第一版”，主要目标是快速把成本结构拉对，给后面的精细化留出时间。

3.2 第二版：向量语义路由，把“像什么”变成分数

规则路由撑不住语义变化的时候，就可以上第二版：用Embedding模型把用户问题转成向量，跟预定义的类别模板做相似度匹配。这一步的本质是把“问题像什么”变成“一个可量化的分数”。

操作上，先给高频意图各写几个模板句，比如“物流查询”“售后政策”“产品推荐”“代码调试”，分别用Embedding模型生成向量，存到本地向量库里。请求进来后，把用户query也向量化，然后算它跟每个模板的余弦相似度，最高分超过阈值就路由到对应档位。

这个方法比关键词路由鲁棒很多，用户用各种口语化表达提问也能命中。比如“我这个东西什么时候能到”虽然没出现“物流”两个字，但语义上跟“物流查询”模板的相似度会很高。

需要注意两个细节：

• 模板句的质量决定路由上限。每个类别写20到30个不同表达，覆盖各种问法，效果才会稳定。
• Embedding模型的消耗也要算进成本。虽然Embedding很便宜，但流量特别大的时候也是一笔开销，需要纳入总成本模型里。

3.3 第三版：动态评分与兜底升级机制

语义路由解决“分得准”的问题，动态评分则解决“分得稳”的问题。我给路由层加了一个小小的难度评分模型，输入用户query、历史对话、请求类型，输出一个0到1的“难度分”。比如分数低于0.3走便宜模型，0.3到0.7走中端，0.7以上走旗舰。

但任何评分模型都会犯错，所以关键不是追求100%准确，而是做好兜底。我会在路由层加一个“升级机制”：如果请求先发给了便宜模型，但检测到以下三种情况，立即自动升级到高一级模型重新调用：

• 便宜模型返回的结果太短、明显答非所问，或包含“我不知道”“无法回答”
• 用户明确表达了不满，比如追问“你没回答我的问题”“重新说”
• 请求涉及的内容触发安全过滤或需要更专业的领域知识

升级机制等于给误判上了保险，允许路由犯错，但代价是至少多一次失败调用。从实际效果看，这套机制能把用户体验兜在一个可接受的范围里，同时不至于让成本反弹。

def routed_inference(query, history): score = difficulty_estimator(query, history) if score < 0.3: model = "cheap" elif score < 0.7: model = "standard" else: model = "premium" result = call_model(model, query, history) if should_upgrade(result, query) and model != "premium": model = "premium" result = call_model(model, query, history) return result

3.4 路由层必须配套的三件事：缓存、超时、降级

没有配套机制的路由是半成品，这里必须提三件事。

缓存。L0档的大量请求其实是可以直接缓存的。同一个“门店几点开门”的问题，一周内被问几百次，每次重新生成纯属浪费。在路由层前置一个带语义匹配的缓存（相同或相似query直接hit），能再省掉一大部分Token消耗。我见过一个项目，加了一层语义缓存之后，接近30%的流量根本不需要进模型。

超时。便宜模型或自部署模型偶尔会慢，而路由增加了额外一跳，延迟会叠加。要给模型调用设置分层超时：便宜的模型超时短一点，快速失败后直接升级到上一档重试；旗舰模型超时可以给足，但也要有应急预案。

降级。旗舰模型API不是永远稳定，哪天限流或故障了，路由要能自动把所有流量降级到中端模型，保证业务不中断。这不是便宜模型该干的活儿，是路由层该干的活儿。我通常会把模型健康检查做成一个独立模块，每30秒探测一次各档位的可用性，一旦发现异常立即调整路由表的权重。

4. 踩过的坑与排查实录：路由工程最容易翻车的地方

4.1 误判的代价：简单问题发错是浪费，复杂问题发错是灾难

路由最核心的指标是误判率。但我不建议追求单一的“准确率”，因为误判方向不同，代价完全不一样。

简单问题被误判成复杂问题，代价是浪费钱——本来1分钱能搞定的事花了1毛钱，心疼但不致命。复杂问题被误判成简单问题，代价是质量事故——模型能力不够，硬着头皮答，给用户输出一堆似是而非的内容，这就不只是钱的问题了。

所以我在设置路由阈值时有一个原则：拿不准的请求，一律往高一级走。也就是说，宁可偶尔浪费一次旗舰调用，也绝不让复杂问题掉到小模型上。这个原则听着保守，但算总账反而更省钱，因为一次质量事故带来的客诉、返工、品牌损失，远比多调几次旗舰模型贵得多。

4.2 口径混乱：Token统计与计价的几个暗坑

很多团队看到“56%的Token只花了14%的钱”这个数据，自己回去一算发现对不上，很大概率是口径错了。

第一个坑是输入和输出的计费差异。绝大多数模型API的输入Token价格和输出Token价格不一样，通常输出更贵。如果只按总Token算账，忽略输入输出的比例，成本模型会失真。路由对输入Token的控制力强，但对输出Token的控制力弱，因为输出长度取决于模型生成结果。这会导致路由看起来省了很多，实际账单比预期的要多。

第二个坑是上下文Token的重复计算。多轮对话里，每轮请求都会把之前的上下文重新发给模型，这些历史Token每次都计费。如果会话很长，历史上下文Token量可能远超本轮新产生的Token。路由只改变了本轮的分发方式，但历史上下文的成本依然存在。有些团队一算“56%的Token”以为这是全部成本，其实只是冰山一角。

第三个坑是各家模型的Token计算方式不一致。同一个句子，在A模型的Tokenizer下是100个Token，到B模型可能变成120个。做成本对比时，要统一用同一套Tokenizer去量，否则对比没有意义。

4.3 多轮会话里跨模型切换的上下文难题

这个坑最隐蔽，也最让我头疼。路由不是一次性的，一个会话可能聊着聊着难度升级了。用户一开始问“怎么登录”，简单，走了便宜模型；接着贴了一段报错日志说“帮我看看为什么登录失败”，这下需要旗舰模型了。问题来了：便宜模型和旗舰模型用的可能不是同一个Tokenizer，甚至是不同公司的模型，上下文历史怎么传给新的模型？

最省事的做法是只把最近一轮的对话发给新模型，但这会让模型丢失前文信息，体验很差。我实际的解法是在路由层维护一个“会话摘要”：便宜模型处理过的关键信息，实时抽取成摘要，升级时把摘要+最新一轮完整上下文一起交给旗舰模型。这样既保留关键上下文，又不至于把大量低价值的中间过程Token重复喂给贵模型。

4.4 路由层自身的性能瓶颈

路由层本质上是给AI应用加了一个前置环节，处理不当会变成新的瓶颈。Embedding计算、难度评分、相似度检索都是有耗时的，如果把这些都串行做完再调模型，整体响应延迟可能增加几百毫秒，用户能明显感知。

我的处理方式是两个：一是把路由决策拆成异步+并行的，请求进来先并行做关键词命中和Embedding计算，谁先出结果用谁，降低等待时间；二是对高频模板做预计算，把类别向量存在内存里，避免每次请求都重新算一遍。实测可以把路由层增加的延迟控制在50到100毫秒以内，用户基本无感。

4.5 常见问题速查表

5. 最后分享一点我的实际体会

这个项目做完之后，我对AI应用的优化有了一个很明确的判断：模型能力会越来越强、越来越便宜，但路由的价值不会因此降低，反而会越来越高。原因很简单，只要请求的难度分布不均，只要模型之间存在价格差，路由就永远有空间。

我也越来越觉得，路由不是一个“要不要做”的问题，而是“什么时候做、做到什么程度”的问题。哪怕你的业务只有几千个请求一天，先上一个基于关键词的规则路由，把L0档流量导出去，成本结构立刻就会不一样。等流量涨上来，再逐步加语义匹配、难度评分、缓存降级这些能力，一步步演进来得及。

最后给一个小技巧：做路由优化的时候，不要只盯总费用这一个指标，建议把“单位高质量回答的成本”当成核心北极星。有些优化看起来省了很多钱，但把回答质量底线拉低了，得不偿失。好路由的衡量标准，从来不是最便宜，而是用更少的钱买到与原来几乎相同的体验。这是我踩了几次坑之后，最想强调的一点。