企业官网建设流程全解析

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 万次请求，接入的是两档模型：一档是轻量模型，一档是旗舰模型。跑了一个月之后，我把日志按请求类型做了归类，结果大致是这样的：

把轻量的两档加起来，请求占比 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 应用工程化最有意思的部分。