TokenRouter：让大模型按 Token 路由，也能高效服务

导语

在大模型服务中，路由通常发生在会话或请求层面：系统先判断任务难度，再把整个请求交给某一个模型。这种方式易于部署，但粒度较粗。近年来，一些研究开始探索 Token 级路由，即在生成过程中根据当前状态，为不同 Token 选择更合适的模型，从而在质量、成本和速度之间获得更细致的平衡。

问题在于，Token 级路由也把服务系统变得复杂。不同模型可能以不同速度推进生成步骤，传统围绕单一模型设计的推理引擎容易出现 step desynchronization（步进失同步）。与此同时，请求被动态分流后，各模型的批次难以及时凑齐，新的请求还可能因等待批处理而产生额外延迟。

TokenRouter 做了什么

TokenRouter 的设计重点不是提出一种新的路由算法，而是提供一套面向 Token 级路由的服务运行时。它采用“请求中心编程、模型中心执行”的思路：开发者从单个请求的角度描述路由逻辑，运行时则为每个 LLM 启动独立子服务，并以异步方式在这些子服务之间分发请求。

这种拆分带来两个好处。首先，路由逻辑与底层调度解耦，开发者不必为每个模型分别编写复杂的服务控制代码。其次，不同模型可以在各自的执行节奏下运行，避免整个系统被某一个模型或某一批请求强行同步。

每个子服务还配备了延迟批处理调度器。它不会在请求一到达时立即执行，而是结合系统吞吐特性，在等待组批收益与新增排队延迟之间做权衡。论文通过吞吐模型推导调度器的关键超参数，试图让这一策略不再完全依赖经验调参。

核心要点

• 支持 Token 级而非仅请求级的模型路由。
• 采用独立模型子服务和异步请求分发机制。
• 通过延迟批处理缓解动态分流后的批次不足。
• 用数学吞吐模型指导调度参数设置。
• 在多种路由算法、工作负载和模型组合上进行评估。
• 论文报告的解码吞吐提升范围为 2.01 至 64.15 倍。

意义与影响

TokenRouter 的价值在于，它把 Token 级路由从算法问题进一步推进到系统工程问题。只有当路由策略能够被稳定、高效地执行，理论上的质量或成本收益才有机会转化为真实服务能力。请求与模型执行的分离，也为未来组合不同规模、不同能力模型提供了更清晰的系统抽象。

不过，论文摘要并未披露完整的硬件配置、基线实现细节和各项测试的绝对吞吐，因此不能仅凭提升倍数判断其在所有生产环境中的收益。实际部署仍需关注路由开销、模型间通信、批处理等待时间以及工作负载差异。总体而言，TokenRouter 说明：随着模型路由从“选一个模型”走向“逐 Token 调度”，推理服务架构也需要同步演进。

来源：Hugging Face Daily Papers