企业官网建设流程全解析

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 请求分级：把“什么请求”变成“什么级别”

做路由的第一步，是给请求分级。分级不是拍脑袋，而是基于历史数据做统计分析。我的做法通常是先跑一周的全量日志，把每个请求的输入长度、输出长度、任务类型、用户反馈（如果有）都记录下来，然后做聚类。

聚类之后你会发现，请求天然会分成几堆。以我最近做的一个项目为例，日志跑下来，请求分布大概是这样的：

这个分布和“56% Token 花 14% 钱”的说法能对上：L1 占了超过一半的请求量，但因为输入输出都短，Token 消耗占比很低；L3 和 L4 虽然请求量少，但每次消耗的 Token 多，而且单价高，所以吃掉了大部分成本。

分级的关键是可解释、可复现。你不能今天按这个标准分，明天按那个标准分，否则路由策略没法迭代。我一般会把分级规则写成明确的判断条件，比如输入 Token 数小于 200 且命中意图分类器的某个类别，就归为 L1。这些条件要能写成代码，而不是靠人工感觉。

3.2 模型池管理：不是模型越多越好

分级做完之后，你需要一个模型池。模型池不是越大越好，我见过有人接了十几个模型，结果维护成本高得离谱，而且很多模型的能力重叠，根本用不上。

我的建议是，模型池里保持 3 到 5 个模型就够了，但要覆盖不同的能力档位和成本档位。一个典型的模型池长这样：

• 极速档：小参数模型或规则引擎，延迟极低，成本极低，负责 L1 请求。
• 均衡档：中等参数模型，能力和成本平衡，负责 L2 请求。
• 旗舰档：最强模型，负责 L3 请求。
• 专用档：针对特定任务优化的模型，比如代码模型、数学模