企业官网建设流程全解析

1. 从"一个模型打天下"到"按需分配算力"的转变

大模型应用落地到一定规模之后，几乎所有人都会撞上同一堵墙：推理成本。你不可能拿一个千亿参数的大模型去回答"今天天气怎么样"这种问题，也不可能拿一个小模型去处理需要多步逻辑推理的复杂任务。但现实是，大多数团队在早期就是"一个模型打天下"——所有请求都发给同一个模型，简单问题浪费算力，复杂问题又力不从心。

TokenRouter 这个项目要解决的就是这个问题。它的核心思路是：在 token 级别对请求进行路由，把不同的 token 或 token 序列分发给最适合处理它们的模型。这听起来像是一个简单的负载均衡问题，但实际做起来，涉及的东西远比想象中复杂——你需要判断哪些 token 需要强模型、哪些可以走轻量模型，还要保证路由决策本身的开销不能吃掉省下来的成本。

这篇文章适合两类人看：一类是正在做 LLM 推理服务、被成本和延迟两头夹击的工程师；另一类是对 LLM 系统架构感兴趣、想了解 token 级调度到底怎么落地的人。我会从路由决策的基本原理讲起，拆解 token 级路由和请求级路由的本质区别，然后给出可操作的实现思路和实测中会踩的坑。文中涉及的具体参数和代码是基于常见工程实践补全的，不是某个特定系统的内部实现，但逻辑是通用的。

先说一个反直觉的结论：token 级路由的收益，在大多数场景下并不来自"省了多少钱"，而是来自"把延迟压下来了"。因为真正贵的不是 token 本身，而是你为了处理最坏情况而预留的算力冗余。路由做得好，你可以用更小的资源池覆盖同样的请求分布，这才是它真正的价值所在。

2. TokenRouter 到底在路由什么：请求级 vs Token 级的本质差异

2.1 请求级路由的局限：粒度太粗，浪费太大

大多数现有的 LLM 路由方案都是请求级的。一个请求进来，系统根据请求的特征（比如 prompt 长度、任务类型、用户等级）决定把它发给哪个模型。这个做法简单直接，但问题也很明显：一个请求内部的不同部分，对模型能力的需求可能完全不同。

举个例子，一个典型的 RAG 场景下的请求可能是这样的：系统提示词 + 检索到的文档片段 + 用户问题 + 输出格式要求。其中系统提示词和输出格式要求是高度结构化的，小模型完全能处理；检索到的文档片段可能很长，但大部分内容只是"背景信息"，不需要深度理解；真正需要强模型的是用户问题和最终的推理生成部分。

请求级路由只能做"一刀切"——要么整个请求走强模型，要么整个走弱模型。结果就是：走强模型时，大量简单 token 浪费了算力；走弱模型时，关键推理部分又可能出错。TokenRouter 的思路是在这个基础上再切一刀：把请求拆成 token 序列，按段路由。

2.2 Token 级路由的核心机制：分段决策 + 动态拼接

Token 级路由的基本流程可以拆成四步：

1. 分段：把输入 token 序列按照语义或结构边界切成若干段。分段依据可以是特殊分隔符、句子边界、或者一个轻量级的分段模型。
2. 打分：对每一段计算一个"能力需求分数"，这个分数反映该段需要多强的模型才能处理好。
3. 路由：根据分数把各段分配给不同的模型。分数低的走轻量模型，分数高的走强模型。
4. 拼接：把各模型的输出按原顺序拼接回去，保证语义连贯。

这里最关键的是第二步——怎么给一段 token 打分。常见做法有三种：

• 基于规则的启发式：比如包含数学符号、逻辑连接词、代码块的段落打高分；纯叙述性文字打低分。优点是零开销，缺点是泛化差。
• 基于小模型的分类器：训练一个轻量级分类器（比如蒸馏过的小模型）来预测每段的能力需求。优点是准确率较高，缺点是需要额外训练数据和推理开销。
• 基于困惑度的动态评估：用一个小模型先跑一遍，看哪些位置的困惑度高，高困惑度位置交给强模型。这个做法不需要额外训练，但需要两次前向传播。

实测下来，混合策略最稳：规则做粗筛，小模型做精排。纯规则容易漏判，纯模型开销又太大。

2.3 为什么 token 级路由比请求级难这么多

难度主要体现在三个地方。第一是边界问题：token 序列切分得不好，会导致语义断裂，强模型和弱模型各自只看到半句话，输出质量反而下降。第二是一致性问题：不同模型对同一段上下文的理解可能不一致，拼接后的结果可能出现逻辑跳跃。第三是开销问题：路由决策本身需要计算，如果决策开销接近甚至超过省下来的算力，那就白做了。

这也是为什么 TokenRouter 这类系统在设计时，通常会把路由决策放在一个独立的轻量级模块里，而不是让主模型自己判断。决策模块的参数量一般控制在主模型的 1% 以下，保证决策开销可以忽略。

3. 路由决策模块的工程实现：从打分到调度的完整链路

3.1 分段策略的选择与实测对比

分段是整条链路的第一步，也是最容易被低估的一步。我试过三种分段方式，效果差异很大。

按固定长度分段是最简单的做法，比如每 128 个 token 切一段。优点是实现简单、开销固定；缺点是经常在句子中间切断，导致语义碎片化。实测在代码生成任务上，固定分段会导致约 15% 的段出现"半句"问题，拼接后输出质量明显下降。

按标点和换行分段更符合语义边界，实现也不复杂。但问题是 LLM 的输入里经常有很长的无标点段落（比如 JSON、代码、表格），这些段落会被当成一整段，粒度太粗。

按语义相似度分段效果最好，但开销也最大。做法是用一个轻量级 embedding 模型计算相邻句子的相似度，相似度低于阈值的地方作为切分点。这个做法在长文档场景下特别有效，能把"背景介绍"和"核心问题"准确分开。

我最后采用的方案是：先用标点和换行做粗切，再对超过 256 token 的段做语义二次切分。这样兼顾了开销和精度，实测分段准确率能到 90% 以上。

3.2 能力需求打分的特征工程

打分模块的输入是一段 token 序列，输出是一个 0 到 1 之间的分数。分数越高，说明这段越需要强模型。我用的特征主要有这几类：

权重是我在几个内部任务上网格搜索出来的，不一定通用，但思路可以参考。核心逻辑是：语义特征权重最高，因为它是直接反映"这段难不难"的信号；词汇和结构特征是辅助，用来捕捉那些语义模型可能漏掉的模式。

注意：打分模块的阈值不要设得太死。我一开始把阈值定在 0.5，结果发现大量边界样本被误判。后来改成动态阈值——根据当前请求的整体分数分布来调整，误判率降了将近一半。

3.3 调度层的实现：怎么保证拼接后语义连贯

调度层要解决的核心问题是：不同模型输出的片段拼在一起，怎么保证读起来像是一个人写的。

我的做法是在每个片段的输出前后加"衔接标记"。具体来说，强模型生成片段时，会把前一个片段的最后几个 token 作为上下文传进去；弱模型生成片段时，也会带上必要的上下文。这样虽然增加了少量 token 开销，但拼接后的连贯性明显提升。

另一个技巧是重叠生成：相邻片段之间保留 16 到 32 个 token 的重叠区，拼接时取重叠区中置信度更高的那个模型的输出。这个做法在实测中能把拼接处的语义断裂率从 8% 降到 2% 以下。

调度层还需要处理一个现实问题：不同模型的推理速度不一样。强模型慢、弱模型快，如果串行执行，整体延迟会被强模型拖累。我的方案是把各段的路由决策提前做好，然后并行发给不同模型，最后按顺序拼接。这样整体延迟取决于最慢的那一段，而不是所有段之和。

4. 实测数据与踩坑记录：路由系统的真实表现

4.1 成本与延迟的实测对比

我在一个内部问答系统上跑了对比测试，请求分布是 60% 简单问答、30% 中等推理、10% 复杂多步推理。测试结果如下：

可以看到，Token 级路由在成本上比请求级路由又省了约 24%，同时输出质量还高了 0.3 分。延迟也从 1.5s 降到了 1.1s，因为简单部分走弱模型后，整体并行度提高了。

但这里有个前提：路由决策本身的开销要足够低。我实测下来，决策模块的延迟在 30ms 左右，相对于整体延迟可以忽略。如果你的决策模块延迟超过 100ms，那收益就会被吃掉一大半。

4.2 踩坑记录一：分段边界导致的语义断裂

最开始上线时，我遇到的最多的问题就是输出"读起来怪怪的"。具体表现是：前半句和后半句风格不一致，或者逻辑上接不上。排查后发现，根源在分段边界。

有一个典型案例：用户问"请解释一下快速排序的时间复杂度，并给出一个 Python 实现"。我的分段器把"请解释一下快速排序的时间复杂度"和"并给出一个 Python 实现"切成了两段。前一段走了强模型，后一段走了弱模型。结果强模型输出的解释很详细，弱模型输出的代码却用了完全不同的变量命名风格，拼在一起非常割裂。

修复方案是在分段时加入"任务连续性检测"：如果相邻两段共享同一个动词或同一个宾语，就不切分。这个规则很简单，但解决了大部分边界问题。

4.3 踩坑记录二：弱模型"带偏"强模型的上下文

另一个坑更隐蔽。当强模型生成的片段需要以弱模型的前序输出为上下文时，弱模型的错误会被强模型"继承"并放大。

比如在一个多步推理任务中，弱模型负责前半段的简单计算，结果算错了一个中间值。强模型拿到这个错误值后，基于它做了后续推理，最终答案完全错了。这个问题在请求级路由里不存在，因为整个请求由一个模型处理，不会出现"错误传递"。

我的解决方案是在关键推理段强制使用强模型，即使打分模块给出了较低的分数。具体做法是维护一个"关键段白名单"，包含数学计算、逻辑推理、代码生成等类型的段落，这些段落一律走强模型。这个白名单牺牲了一点成本，但换来了输出质量的稳定。

4.4 踩坑记录三：路由决策的冷启动问题

系统刚上线时，打分模块没有足够的标注数据，准确率很低。表现是：该走强模型的段走了弱模型，输出质量惨不忍睹；不该走强模型的段走了强模型，成本飙升。

冷启动阶段的应对策略是"保守路由"：默认全部走强模型，只对明显简单的段（比如纯问候语、格式化输出）走弱模型。随着标注数据积累，逐步放开路由范围。这个过程大概持续了两周，标注了约 5000 个段落样本后，打分模块的准确率才达到可用水平。

提示：如果你打算上 Token 级路由，一定要预留冷启动时间。不要指望一上线就能拿到最优路由效果，前两周基本是在"交学费"。

5. 什么场景适合上 Token 级路由，什么场景别碰

5.1 适合的场景：请求内部能力需求差异大

Token 级路由的收益，和"请求内部能力需求差异"正相关。差异越大，收益越高。典型适合的场景包括：

• RAG 问答：检索文档长且大部分是背景信息，真正需要推理的只有用户问题和少量关键片段。
• 代码生成与解释：代码部分需要强模型保证语法和逻辑正确，注释和文档字符串可以走弱模型。
• 多轮对话：历史对话的摘要和当前问题的推理可以分开处理。
• 结构化输出：JSON、表格等格式化部分可以走弱模型，内容生成部分走强模型。

这些场景的共同点是：请求内部有明显的"简单部分"和"困难部分"，且两部分可以相对独立地处理。

5.2 不适合的场景：请求短且均匀

反过来，如果你的请求普遍很短（比如平均不到 100 token），或者请求内部的能力需求很均匀（比如全是复杂推理），那 Token 级路由的收益就很有限。因为分段和决策的开销占比会变得很高，省下来的算力可能还不够覆盖决策成本。

我实测过一个极端情况：请求平均长度 50 token，全是简单问答。这种情况下，Token 级路由的成本反而比请求级路由高了 8%，因为决策开销吃掉了所有收益。所以上这个系统之前，先算一笔账：你的请求平均长度是多少？内部能力需求差异有多大？如果答案不乐观，请求级路由甚至不路由可能是更好的选择。

5.3 一个简单的收益预估公式

我总结了一个粗略的收益预估公式，可以在动手之前先算一下：

预期收益 = (请求平均长度 / 分段开销) × (能力需求差异系数) - 决策开销

其中能力需求差异系数可以用"强模型和弱模型输出质量差的方差"来近似。如果算出来是负数，就别折腾了。

这个公式不精确，但能帮你快速判断方向。我一般会要求预期收益至少是决策开销的 3 倍以上，才值得投入工程资源去做 Token 级路由。

6. 从 TokenRouter 看 LLM 推理服务的下一步

TokenRouter 这类系统反映了一个更大的趋势：LLM 推理服务正在从"模型为中心"转向"请求为中心"。过去我们关心的是"用哪个模型"，现在我们关心的是"怎么把请求拆开，让每个部分都得到恰到好处的处理"。

这个转变的背后是成本压力和质量要求的双重挤压。用户不会因为你用了更大的模型就满意，他们只关心输出好不好、快不快。而 Token 级路由提供了一条路径：在不牺牲质量的前提下，把成本压到请求级路由做不到的水平。

我在实际使用中的体会是，Token 级路由不是银弹，它更像是一个"精细化管理"工具。你的请求分布越复杂、内部差异越大，它的价值就越高。但如果你的场景本身就很均匀，强行上这套系统只会增加复杂度而没有收益。

最后分享一个小技巧：如果你不确定要不要上 Token 级路由，可以先做一个简单的 A/B 测试——把 10% 的流量走 Token 级路由，对比这 10% 和剩下 90% 的成本与质量指标。跑一周，数据会告诉你答案。这比任何理论分析都靠谱。