TokenRouter：让大模型逐词元路由真正高效运行

导读

同一段回答，能否由小模型处理容易的词元，再把困难部分交给大模型？词元级路由试图把模型协作细化到生成过程内部，但算法上的节省，未必能直接转化为服务系统的效率：模型速度不同、请求不断切换、批次被打散、缓存管理反复执行，都可能吞噬收益。清华大学与卡内基梅隆大学研究者提出的 TokenRouter，把路由策略与底层服务运行时分离，以请求中心的编程接口、模型自治的异步执行，以及延迟批处理调度，解决细粒度模型协作的落地问题。 本文按照原论文的六个正文部分组织，重点解释接口语义、调度机制、实验条件及结论边界。它是一篇服务系统论文，而不是综述，也不是提出新的路由决策算法。 arXiv页面注明论文已被 NeurIPS 2026 接收。 论文信息

英文题目：TokenRouter: Efficient Serving System for Token-Level LLM Routing。 作者：Tianyu Fu、Tengxuan Liu、Ruoxi Wang、Yixin Dong、Yi Ge、Yichen You、Yu Wang。前两位作者为共同第一作者，Yu Wang为通讯作者。作者单位包括清华大学与卡内基梅隆大学。 论文主页：https://arxiv.org/abs/2610.12242 原文下载：https://arxiv.org/pdf/2610.12242 代码地址：https://github.com/thu-nics/TokenRouter

1 Introduction｜绪论

大模型路由的基本思路，是把计算分配给不同模型，在成本与质量之间寻找更合适的平衡。会话级路由为整段对话选择模型，查询级路由为一个问题选择模型；词元级路由则允许在回答尚未生成完时切换模型，让多个模型共同完成一条输出序列。 细粒度路由既可能以效率为目标，让小模型处理大多数简单词元，仅在必要时调用大模型；也可能以质量为目标，在不同专家模型间选择或融合预测。但无论决策依据是置信度、熵、预测分歧还是学习到的转交信号，都需要频繁执行“生成—判断—切换—继续生成”的循环。 真正的困难，是单模型服务的默认假设不再成立。 在常规服务系统中，一个请求通常停留在同一模型上，跟随该模型的批处理节奏推进。词元级路由却要求请求在模型之间往返：同一时刻，有的请求继续由小模型生成，有的正在等待大模型，还有的刚从另一模型返回。 这会产生三类问题。第一，逐步同步让快速模型等待慢速模型；第二，不规则的跨模型到达使批次碎片化，新请求还可能错过当前批次；第三，路由算法需要深入处理请求生命周期、连续批处理和前缀缓存，实现复杂度显著上升。 TokenRouter的回答不是再设计一个“更聪明的路由器”，而是提供专用运行时：开发者按单个请求描述路由逻辑，系统按各模型的批处理需求执行。论文的核心贡献包括统一接口、异步交接与恢复机制，以及以吞吐模型指导的延迟批处理。

2 Related Work｜相关工作

模型路由。 已有方法多在会话或查询粒度选择模型。效率导向的方法把容易的问题交给较便宜的模型，质量导向的方法选择更适合该任务的专家模型。它们与既有单模型服务栈较为兼容，因为一次请求通常不需要在解码过程中频繁迁移。 词元级路由。 这类方法可以使用训练得到的轻量路由器，也可以直接依据置信度或输出熵判断何时调用大模型。另一些方法强调专家选择或输出分布融合。尽管算法不同，其系统需求具有共同性：选择下一个执行模型、传递请求状态、接纳对方生成的新词元，并继续解码。这正是论文抽象接口的基础。 大模型服务系统。 连续批处理、分页式缓存管理和结构化生成等技术，已显著提高单模型推理效率。然而，多模型并不等于任意模型协作。推测解码通常具有相对固定的“草稿—验证”结构，词元级路由则可能在任意位置，依据当前生成状态动态切换。若强行把它映射到固定同步模式，就会制造空闲等待和小批次。 因此，TokenRouter并不是替代所有已有推理引擎，而是扩展其执行组织方式。各模型继续本地管理批处理和前缀缓存，跨模型协作则由专门的请求交接机制负责。

3 Programming Interface｜编程接口

3.1 原则：面向请求的顺序编程

开发者最自然的视角，是跟踪一个请求如何生成回答：接收上下文，执行一次解码，检查结果，必要时转交，接收对方结果，然后继续。TokenRouter允许按这一顺序描述算法，而不要求开发者显式安排多个模型的批次或全局同步。 与此同时，实际运行并不是串行地执行所有请求。系统按模型组织请求队列和批次，各模型独立推进。因此，“顺序”指的是单个请求的编程语义，而不是整个服务系统的执行方式。

图1：模型路由的三种粒度与TokenRouter架构。左侧展示会话级、查询级和词元级决策；右侧展示统一服务入口，以及各模型子服务器中的调度器、模型运行器和路由组件。对应原论文图2。

3.2 核心接口

接口由三个函数组成：route、send和receive，分别回答“去哪里”“交接什么”和“如何继续”三个问题。 路由判断。route(result)在模型前向计算之后运行，可以利用隐藏状态、输出概率或采样结果作出决定。返回值0表示继续由当前模型处理，非零值表示转交相应的模型。不同算法可以复用同一运行时，而把决策逻辑放在该函数中。 状态交接。send(req)构造跨模型请求对象，包含请求标识、对方尚未见过的词元后缀、是否完成生成的状态，以及算法需要的附加信息。位置锚点用于说明新增内容在上下文中的位置。接口还允许决定是否携带刚采样的词元：如果当前模型的预测不可靠，应让对方重新生成该位置，而不是默认把它当作已确认内容。 接收与恢复。receive(peer_req)把收到的跨模型请求转为当前模型可处理的本地状态。默认行为是接纳传入词元；若算法具有不同的提交规则，也可以自定义。 这里需要区分“词元上下文交接”与“缓存迁移”：接口并不意味着把一个模型的键值缓存直接复制给另一个模型。不同模型拥有各自的缓存与表示，TokenRouter主要传递增量词元和请求语义。

3.3 运行示例

以R-Stitch为例，小模型检查输出熵。当熵高于阈值时，意味着当前预测较不确定，系统把请求转交给大模型，并丢弃小模型刚采样的那个不确定词元，由大模型重新生成。大模型在满足相应低熵条件时，再将请求交回小模型。交接仅需发送对方未见过的词元后缀，而不是每次重复传递整个历史。 其他算法也可以映射到相同接口。CITER依据低置信度触发切换，R2R使用预测分歧信号，Co-LLM依据转交概率作出决策；这些方法中的对端通常在生成一个词元后返回。R-Stitch可以让模型连续生成多个词元再切换，ME则涉及多个模型的词元级集成权重。 统一接口的价值在于覆盖不同的切换频率与提交语义，而不强制所有算法采用同一种往返模式。它降低的是实现与集成成本，是否能获得更好的生成质量，仍取决于路由策略和参与模型。

4 System Design｜系统设计

4.1 系统概览

每个模型对应一个自治子服务器，内部包含调度器、模型运行器、私有键值缓存池，以及路由相关函数。外部客户端只面对一个统一服务入口，无需感知请求在内部经历了多少次模型切换。 实现基于SGLang 0.5.1，服务前端适配FastAPI，子服务器之间通过ZeroMQ进行本地进程间通信。每个子服务器运行在独立子进程中，使用一个事件循环组织异步工作。论文描述的“三个循环”是逻辑上解耦的执行流程，不应理解为必须创建三个独立线程。 对于共享设备的模型，系统需要统一考虑权重占用和键值缓存预算，避免各模型分别按整张显卡的可用空间预留缓存。附录提出根据模型权重及每词元缓存单元的占用，确定可共同容纳的缓存容量。共同规划显存预算，不等于多个模型共享同一份键值缓存。

4.2 利用异步执行提高服务效率

论文比较了四种调度方式。逐步同步要求所有模型完成当前步之后才开始下一步；模型同步在同一时刻只推进一个模型；立即执行的异步方式消除了全局屏障，但新到达的请求仍可能错过当前批次；TokenRouter则在异步基础上加入批次组织优化。

图2：不同调度策略的执行时序。蓝色表示小模型批次，灰色表示大模型批次。原论文示例中，四种方案的平均延迟依次为13.33、13.00、10.83和8.67个小模型批次时间单位；这是机制示意，不是通用实测延迟。对应原论文图4。 子服务器包含客户端服务循环、解码循环和模型间交接循环。前者处理请求接入与结果流式返回，解码循环负责本地调度和执行，交接循环处理对端请求发送与接收。一个请求去往另一模型时，其他本地请求仍可继续运行，而无需等待对端完成。 另一个关键设计是交接后保留状态，返回时直接恢复。如果每次模型返回都当作新请求，就需要重新匹配前缀、分配缓存及更新相关数据结构。TokenRouter在“运行”和“完成”之外加入“待返回”状态：请求暂时退出当前模型的调度，但其服务状态保留；对端返回后，系统追加新词元，再恢复执行或标记完成。 因此，性能收益不仅来自“两个模型可以同时工作”，还来自避免重复执行请求初始化路径。附录对标准服务基线的一组小模型步骤进行拆分：模型推理只占4.20%，而前缀匹配、缓存节点加锁、释放和树更新占据较大比例。该数字描述特定配置，不能泛化为所有推理服务，但说明高频交接时管理开销可能成为主要瓶颈。

4.3 利用延迟批处理提高调度效率

异步执行并未自动解决不规则到达的问题。假设一个请求刚触发大模型执行，随后其他请求陆续到达，它们就要等待下一批；若每次到达都立即执行，很容易形成大量小批次。 延迟批处理让请求短暂排队，待同一模型的队列达到阈值后再启动批次。这样可用更大的批次摊薄执行成本，并减少后来请求错过批次的等待。让个别早到请求多等一会儿，可能降低整体平均等待，但不保证每个请求都更快。

阈值并非越大越好。太小会保留批次碎片化，太大则可能让队列长期无法启动，甚至使多个模型相互等待。论文用离散时间马尔可夫链建立吞吐模型，把请求并发数、路由概率、模型步骤延迟，以及各模型的队列长度、当前批次大小和剩余执行时间纳入状态描述。 模型计算稳态下单位时间提交的有效词元数，再在可行阈值集合中选择吞吐最高的组合。这里的“有效词元”很重要：某个模型生成但随后丢弃的预测，并不应被计入最终输出吞吐。 附录给出的可行条件是：各模型阈值减1后的总和，小于系统中的请求并发数。其作用是避免所有模型都处于“队列尚未达标、又没有批次正在执行”的死锁状态。 这一理论依赖路由概率的平稳性、请求间独立性以及连续执行步数的几何分布等假设。在R2R验证中，路由概率为0.35，小模型与大模型步骤延迟分别约6.0和27.9毫秒。固定小模型阈值后，理论预测在所测试的各并发水平下选出的最优大模型阈值，与硬件测量得到的最优值一致。这是给定建模假设下的吞吐优化，不是任意动态流量或尾延迟目标下的普遍最优证明。

5 Experiment｜实验

5.1 实验设置

实验平台是一台配备8张A100 80GB GPU的服务器，但并非每项实验都使用全部8张卡。主要双模型配置采用Qwen3-0.6B和Qwen3-32B，小模型张量并行度为1，大模型为2，两个模型通过CUDA MPS共享两张GPU。ME使用0.6B、8B和32B三个模型，各占一张GPU。 论文比较五种算法、三类工作负载，共15种组合。主实验并发数为4，另有单请求、并发扩展、不同模型组合和跨节点测试。 三类负载分别为：低计算量推理，使用AIME2024、最大输出长度2048；高计算量推理，同样使用AIME2024，但选取32B模型解答超过8192词元的题目、最大输出长度8192；智能体相关负载，使用SWE-Smith轨迹输入，输入约8192词元、最大输出1024。最后一类是在轨迹输入上测试生成服务，不能等同于验证完整在线智能体的工具调用和任务成功率。 基线分为官方实现和标准服务实现。Co-LLM官方实现使用按模型运行的vLLM连续批处理；CITER与R2R官方实现的引擎不具有连续批处理。R-Stitch没有可用官方代码，因而相应官方比较为空。标准服务基线由各模型的SGLang实例和外部调度器组成，通过单词元接口协调路由。 所以，标准服务基线不是“SGLang原生支持任意词元级路由后的最佳性能”，而是论文为对照构造的实现。解释加速幅度时，必须同时说明基线的能力与局限。

5.2 服务效率

图3：并发数为4时，五种路由算法在三类负载下的吞吐与端到端延迟。上半部分对应原论文图5，下半部分对应图6；两幅图的纵轴指标不同，吞吐越高越好，延迟越低越好。 主实验中，TokenRouter相对于每项设置下更强的可用基线，实现2.01—64.15倍解码吞吐提升；相对标准服务实现，端到端延迟改善为2.03—63.64倍。两组范围针对不同指标，不能直接互换，也不能把最大倍率写成每个场景的稳定收益。 当输出上限从2048增至8192时，TokenRouter的吞吐整体保持稳定，而标准服务基线损失58.1%—85.2%的吞吐。长输出增加了模型往返与状态管理的累计成本，因此交接恢复机制尤其重要。 论文还回到各算法原始模型与任务设置进行测试，而不是只比较统一模型组合。

图4：并发数为4、各算法原始设置下的性能对比。列中分别给出吞吐、首词元延迟和端到端延迟；“不适用”表示没有可用官方实现。对应原论文表2。 R2R使用DeepSeek-R1-Distill-Qwen-1.5B与32B，在AIME上吞吐由官方实现的89.62提高到244.56词元/秒，端到端延迟由751.15降至270.19秒。CITER使用Qwen2-1.5B与72B，在CommonSenseQA上吞吐由17.16提高到149.31词元/秒，延迟由7.64降至0.48秒。 Co-LLM使用调整后的小模型与LLaMA2-70B，在GSM8K上吞吐由3.46提高到76.02词元/秒，延迟由247.61降至11.46秒。R-Stitch相应设置下，TokenRouter吞吐为140.58词元/秒，延迟为151.30秒；由于缺少官方实现，不能计算对官方代码的加速倍率。 这些数据也提醒我们：系统优化不意味着路由方案在所有指标上都优于只使用大模型。 例如Co-LLM设置中，只用大模型的吞吐为134.79词元/秒，高于TokenRouter，但端到端延迟为13.39秒，略高于TokenRouter的11.46秒。吞吐、首词元延迟与单请求完成延迟，需要分别看待。 并发从1增至16时，TokenRouter总吞吐增长8.61倍，同时保留单用户初始生成速度的51.7%；官方R2R的对应值为5.14倍和31.3%。论文还报告TokenRouter在并发16时，相比官方R2R在并发1时，吞吐达到18.58倍、单用户速度达到1.13倍。这是一项跨并发比较，不是相同并发下18.58倍的直接加速。

5.3 消融研究

图5：左侧拆分并发数为8时的性能增益；右侧展示吞吐与单用户速度的权衡。右图中的18.58倍吞吐和1.13倍速度来自不同并发工作点的比较。对应原论文图1。 在R2R、并发数为8的配置中，基础实现吞吐为132.78词元/秒，官方实现为134.90。扩展阶段的CUDA图优化首先把吞吐提高到230.79，相当于官方实现的1.71倍；加入异步执行后达到296.86；再加入延迟批处理后达到372.48，最终相当于官方实现的2.76倍。 这个拆分表明，收益由多个工程机制共同构成。不能把CUDA图、异步执行和调度策略带来的总提升，全部归因于路由算法本身。 不同大小模型组合也呈现不同收益。在小模型0.6B、大模型8B的配置下，吞吐由105.10提高到336.98词元/秒，约3.21倍；0.6B与32B约2.56倍；1.7B与8B约2.76倍；4B与8B约1.99倍。模型尺寸与速度差异会改变瓶颈，因此不存在统一不变的加速系数。 附录进一步指出，提高大模型张量并行度对吞吐较重要；小模型能够装入设备后，继续提高其张量并行度的收益有限。扩展阶段CUDA图也只覆盖预先捕获的批次和词元长度范围，范围外仍需使用常规执行路径。 跨节点实验显示系统可以支持模型分布在不同节点，但通信会产生额外成本。例如并发4时，R2R由同节点的228.94降至跨节点的202.43词元/秒，CITER由308.36降至277.56。这提供了部署可行性的证据，却不足以证明系统已经覆盖广域网络或大规模复杂集群中的全部挑战。

5.4 推进帕累托前沿

图6：AMC23任务上的吞吐—准确率权衡。图中比较TokenRouter、官方R2R及不同查询级路由方法，也标出仅使用小模型或大模型的参考点。对应原论文图7。 这一实验使用Qwen3-0.6B与32B、贪心解码、最大输出8192词元，所有请求同时提交，各系统使用相同的大小模型显存比例。对照包含官方R2R，以及RouteLLM中的矩阵分解、文本编码器、大模型和相似度加权查询路由方法。 原图显示，运行时优化使词元级路由获得更有竞争力的吞吐—准确率工作点。算法原本可能已经具有合理的质量，但如果服务成本过高，就难以与查询级路由竞争；减少执行开销后，原有路由策略的潜在收益才更容易体现出来。 应注意，此图的吞吐按每个请求的输出词元数除以经过时间计算，与主实验的整体输出吞吐统计口径不同。它验证的是特定数学任务、模型组合及参数范围内的权衡，不意味着所有任务上都同时提升速度和准确率，也不表示运行时本身改善了模型的知识或推理能力。

6 Conclusion｜结论

TokenRouter的核心价值，是为词元级模型协作补上专用服务基础设施：以请求为中心表达算法，以模型为中心组织执行；用异步机制消除全局等待，用待返回状态减少重复初始化，再通过延迟批处理提高批次利用率。 对算法研究者而言，统一接口有助于把路由规则从调度细节中分离，让不同策略在共同运行时中比较。对部署者而言，更重要的是认识到模型切换成本不仅是额外的前向计算，还包括缓存管理、批次组织和交接等待。评估路由方案时，需要同时报告模型组合、并发水平、请求长度、显存分配，以及吞吐和延迟的具体定义。 论文也明确保留了边界。调度模型假设连续两次发送之间的生成步数符合几何分布，不满足这一假设的特殊情形仍需进一步研究。本文所展示的理论与实验也不能替代对非平稳流量、尾延迟约束或更大规模部署的专门验证。 因此，最稳妥的结论是：TokenRouter证明，词元级路由的实用性不仅取决于“何时换模型”，也取决于“换模型之后如何高效继续运行”。 它通过一套接口和执行机制，在所测算法、负载与模型组合下显著改善服务效率，为后续细粒度协作研究提供了更可用的系统基础。 原文与资源

论文：https://arxiv.org/abs/2610.12242 全文：https://arxiv.org/pdf/2610.12242 代码：https://github.com/thu-nics/TokenRouter 本文基于论文v1整理。配图均截自原论文，保留原始图内文字与实验标注，图片下方图注为中文解读；性能数字仅适用于原文给定条件。