TokenRouter: Efficient Serving System for Token-Level LLM Routing¶

会议: NeurIPS 2026
arXiv: 2610.12242
OpenReview: https://openreview.net/forum?id=VCbatQAXJV
代码: https://github.com/thu-nics/TokenRouter
领域: LLM 效率
关键词: Token级路由, 大模型推理服务, 异步解耦执行, 延迟批处理, 请求状态保持

一句话总结¶

TokenRouter 针对 Token 级大模型路由服务中严重的步间失步与批次准入延迟瓶颈，提出了“请求中心编程、模型中心执行”架构，结合解耦三循环异步执行、状态切换恢复机制与基于离散马尔可夫链建模的延迟批处理调度，在保持单模型系统兼容接口的同时实现了 2.01–64.15 倍的解码吞吐提升。

研究背景与动机¶

大语言模型在推理服务中面临严格的吞吐与延迟成本约束。为了推升成本-质量 Pareto 前沿，模型路由已成为工业界与学术界的主流范式。现有的商用系统（如 ChatGPT、Cursor）与学术系统（如 RouteLLM）普遍采用会话级或查询级的粗粒度路由，在输入进入系统时根据难度预测将整条请求固定分配给单个模型完成后续全部生成。然而，单条长文本生成过程中 token 级难度的动态起伏极其剧烈，粗粒度路由无法捕捉这种局部的计算弹性。近期算法研究（如 R2R、CITER、R-Stitch、Co-LLM）表明，在 token 粒度进行动态路由能以极小的大模型调用比例匹配完整大模型性能，或在多专家间实时协作合成高质量输出。

然而，现有的高性能 LLM 推理服务系统（如 SGLang、vLLM）完全基于“单模型同步解码”假设构建：同一个 batch 内的所有活跃请求在每个解码步必须步调一致。一旦引入 token 级路由，由于不同大小模型（如 0.6B 与 32B）单步推理延迟差异悬殊，若强制批次同步，极慢的模型将导致快速模型产生严重的步间空转（Step Desynchronization）。更严重的是，请求在不同模型间频繁跳转导致到达事件高度碎片化，当某请求跳入目标子服务时往往该服务正在执行已有 batch，该请求只能停滞等待下一轮批次，造成高额的批次准入延迟（Batch Admission Delay）。此外，现有引擎缺乏逐步路由抽象，开发者只能深入底层魔改连续批处理与前缀缓存，实现复杂度极高。

为了打破这一底层系统困境，本文的切入角度是将路由算法的高层逻辑与底层服务系统的并发调度彻底解耦。核心 idea：采用“请求中心编程、模型中心执行”原则，开发者仅需基于 route-send-receive 接口描述单请求跨模型的转移逻辑，运行时由独立的模型子服务器执行解耦三循环异步流转与保持 KV 缓存的状态交接，并基于离散马尔可夫链吞吐模型推导最优延迟批处理阈值，彻底化解步间失步与批次准入瓶颈。

方法详解¶

整体框架¶

TokenRouter 在外部呈现为标准的单一服务接口（Server Interface），与现有单模型引擎客户端协议完全兼容；而在系统内部，TokenRouter 为每个参与路由的协同 LLM 启动一个自治的子服务器（Subserver）。每个子服务器独立拥有模型权重、私有 KV 缓存池、调度器以及由开发者定义的 route、send、receive 路由组件。

为了消除多模型间的同步阻塞，TokenRouter 将原本单模型引擎的双循环扩展为“解耦三循环”结构：客户端-服务器循环负责请求接入与流式响应，解码循环驱动本地批处理与前向计算，新引入的跨模型循环（Inter-model loop）通过本地高效 IPC 负责 PeerReq 请求的收发与状态挂起。在批次调度层，子服务器并不贪婪地在收到首个跨模型请求时立即起步，而是采用延迟批处理策略，在极短可控时间内聚合同一模型的后续请求后再组批执行。

%%{init: {'flowchart': {'rankSpacing': 24, 'nodeSpacing': 28, 'padding': 6, 'wrappingWidth': 400}}}%%
flowchart TD
    A["客户端请求输入"] --> B["单一外部服务接口<br/>分发至入口子服务器"]
    B --> C["自治模型子服务器<br/>私有KV池 + 独立步频"]
    C --> D["解耦三循环异步执行<br/>客户端/解码/跨模型三循环解耦"]
    D --> E["跨模型状态切换与恢复<br/>标记Pending状态，免重算KV与前缀匹配"]
    E --> F["延迟批处理调度器<br/>DTMC理论推导最优组批阈值B*"]
    F --> G["聚合执行前向解码<br/>输出Token与流式响应"]

关键设计¶

1. 请求中心编程接口：抹平跨模型流转的实现复杂度 传统服务系统缺乏细粒度调度接口，导致开发者实现 token 级路由时必须在复杂的调度循环与前缀树代码中打补丁。TokenRouter 抽象出通用的请求生命周期，提供极简的 route-send-receive 编程范式： - route(result)：在当前模型单步前向传播完成后被触发，根据输出的隐状态、logits、熵值或置信度计算目标索引，返回 0 表示本地继续生成，非 0 表示转交对应 Peer 节点； - send(req)：在发生委派时构造轻量 PeerReq 消息，根据位置锚点 req.loc 仅打包 Peer 模型尚未见过的 token 后缀，避免全量上下文冗余传输； - receive(peer_req)：在对端节点接收到消息时触发，默认将接收到的增量 token 追加至本地请求队列中准备恢复解码。

该接口让开发者仅以“单请求视角”顺畅书写逻辑，底层底层分布式通信与并发调度细节对开发者完全透明。

2. 解耦三循环异步执行与状态切换恢复：终结步间失步与缓存重算开销 在单模型服务架构中，系统仅包含处理网络 IO 的客户端循环和处理批处理的解码循环。若直接在解码步内加入阻塞式跨模型通信，整个批次必须以最慢模型的时钟为基准推进，快速小模型被迫大量空转。TokenRouter 引入第 3 个独立的跨模型循环（Inter-model loop），使各模型子服务器能够完全以自身硬件的最佳步频独立推进。

当请求需要跳向对端模型时，TokenRouter 并不注销该请求，而是将其标记为独特的 pending 中间状态。处于 pending 的请求被本地调度器跳过，但其在私有池中的 KV 缓存与上下文状态完整保留。当 Peer 节点处理完毕将控制权返还时，状态直接从 pending 恢复为 running，系统仅需在显存中追加新增生成的 token，从而彻底规避了重新进行前缀匹配（Prefix Matching）与重新分配 RadixCache 节点带来的高昂系统开销（实测该开销在原生 baseline 中占比高达 70% 以上）。

3. 延迟批处理调度与 DTMC 理论最优阈值：化解批次碎片化与准入等待 由于 token 级跳转在时间线上呈稀疏且随机分布，若采用急切异步（Eager-Async）策略，只要有请求到达就立即开跑小 batch，会导致后续短时间内到达的同模型请求被挡在门外、陷入漫长的等待（Batch Admission Delay），进而导致严重的显卡计算碎片化。TokenRouter 提出了延迟批处理调度机制：子服务器设置缓冲阈值 \(B\)，当缓冲队列中的待执行请求积累至 \(B\) 个时才触发批量前向计算。

针对阈值 \(B\) 过小导致准入排队延迟高、过大导致请求深陷队列使其他模型饥饿的严格折中，TokenRouter 建立了离散时间马尔可夫链（DTMC）吞吐数学模型。令系统包含 \(M\) 个模型、总并发度为 \(N\)，模型 \(i\) 单步前向耗时为 \(L_i\)，转移概率为 \(p_{ij}\)，转移时提交 token 数为 \(c_{ij}\)。定义系统在批次完成时刻的状态为 \(\mathbf{s} = (k_0, b_0, r_0, \dots, k_{M-1}, b_{M-1}, r_{M-1})\)，其中 \(k_i\) 为排队数，\(b_i\) 为正在运行的批大小，\(r_i\) 为剩余执行时间。系统长周期平均提交吞吐量为期望提交 token 数与期望状态保持时间之比：

\[T(\mathbf{B}) = \frac{\sum_{\mathbf{s} \in \mathcal{R}_{\mathbf{B}}} \sum_{i \in \mathcal{A}(\mathbf{s})} \sum_{j=0}^{M-1} \pi_{\mathbf{B}}(\mathbf{s}) b_i c_{ij} p_{ij}}{\sum_{\mathbf{s} \in \mathcal{R}_{\mathbf{B}}} \pi_{\mathbf{B}}(\mathbf{s}) \min_{i: b_i > 0} r_i}\]

在满足无死锁可行性条件 \(\sum_{i=0}^{M-1}(B_i - 1) < N\) 的离散集合内，通过求解平稳分布 \(\boldsymbol{\pi}_{\mathbf{B}}\)，离线或动态解析出最大化系统总吞吐的最优阈值向量 \(\mathbf{B}^*\)。

4. 路由感知的底层运行时协同优化：算子、显存与通信极致压榨 在工程实现层面，TokenRouter 针对 token 路由特有的负载特征做了系统级定制： - Extend 模式的 CUDA Graph 捕获：在标准自回归生成中 decode 步占主导，但跨模型切换使得每次返回均以增量 prompt（extend）方式灌入，TokenRouter 对常用 batch size 与 token 长度的 extend 阶段全面支持 CUDA Graph 捕获，消除内核发射开销； - 进程内路由与轻量通信：将路由判决算子作为张量操作直接置于 GPU 调度主进程中，消除跨进程 IPC 判定；跨子服务器消息则基于极速的本地 ZeroMQ IPC； - 联合 KV 缓存分配与状态隐式同步：多模型共存同一 GPU 时，根据两模型权重与每 token 显存开销联合划分最优容量配额，并在 Peer 消息中顺风车搭载全局活跃并发状态更新，无需额外集中式协调器。

实验关键数据¶

主实验¶

在 8×A100-80G 服务器上，评测覆盖 CITER（Qwen3-0.6B/32B）、R2R（Qwen3-0.6B/32B）、R-Stitch（Qwen3-0.6B/32B）、Co-LLM（Qwen3-0.6B/32B）及多模型路由 ME（0.6B/8B/32B）。涵盖短输入短输出数学推理（AIME2024）、长输出深度推理（AIME2024 Long）及多轮 Agent 任务（SWE-Smith）。

下表为原始算法设定下并发度为 4 时的吞吐与延迟表现（主流基准对比）：

算法	实现方案	解码吞吐 (token/s)	首字时间 TTFT (s)	端到端延迟 (s)	相对吞吐提升
R2R	纯大模型 (LLM-only)	145.30	0.13	411.98	1.00× (基准)
R2R	官方开源实现 (Official)	89.62	0.11	751.15	0.62×
R2R	TokenRouter (本文)	244.56	0.11	270.19	2.73×
CITER	纯大模型 (LLM-only)	123.72	0.083	2.68	1.00× (基准)
CITER	官方开源实现 (Official)	17.16	0.036	7.64	0.14×
CITER	TokenRouter (本文)	149.31	0.036	0.48	8.70×
Co-LLM	纯大模型 (LLM-only)	134.79	0.069	13.39	1.00× (基准)
Co-LLM	官方开源实现 (Official)	3.46	1.14	247.61	0.03×
Co-LLM	TokenRouter (本文)	76.02	0.067	11.46	21.97×
R-Stitch	纯大模型 (LLM-only)	150.41	0.15	360.76	1.00× (基准)
R-Stitch	TokenRouter (本文)	140.58	0.067	151.30	—

注：在完整 15 组算法-负载组合评测中，TokenRouter 相比现有可用基线实现了 2.01–64.15× 的吞吐提升，延迟降低 2.03–63.64×。

消融实验¶

在 R2R 算法（AIME2024 任务）下，对系统各项核心优化机制在不同并发度 \(N\) 下进行吞吐消融（单位：token/s）：

配置 / 剥离项	\(N=8\) 吞吐	\(N=4\) 吞吐	\(N=1\) 吞吐	说明与收益贡献
完整 TokenRouter	372.48	210.61	73.02	全功能启用，相比官方代码提升 2.76×
去除延迟批处理 (-Delayed batching)	296.86	161.26	73.02	吞吐下降 20.3%（\(N=8\)），证明防碎片化组批价值
去除异步执行 (-Async execution)	230.79	143.88	73.02	步进退化为同步等待，吞吐进一步下降 22.3%
去除路由端 CUDA Graph	228.10	142.33	72.62	算子发射开销微增
去除 LLM 端 CUDA Graph	164.08	95.55	51.22	缺少大模型图捕获，吞吐大幅下滑 28.1%
去除 SLM 端 CUDA Graph (≈ 原生 SGLang)	132.78	75.54	34.20	退化至基础实现状态
R2R 官方实现 (Baseline)	134.89	73.27	36.17	缺少连续批处理与系统级协同

跨模型尺寸适配消融（SLM-LLM 模型对，并发度 4，R2R 算法）： - 0.6B + 8B：TokenRouter 达 336.98 token/s vs 官方 105.10 token/s（3.21× 提升）； - 0.6B + 32B：TokenRouter 达 197.40 token/s vs 官方 77.08 token/s（2.56× 提升）； - 1.7B + 8B：TokenRouter 达 285.41 token/s vs 官方 103.37 token/s（2.76× 提升）； - 4B + 8B：TokenRouter 达 211.81 token/s vs 官方 106.67 token/s（1.99× 提升）。

关键发现¶

状态保持是性能跃迁的关键：分析标准 SGLang 驱动的 Std. Serving 发现在每步解码开销中，由于请求回传被当作新请求重新执行前缀匹配（占 20.94%）和 RadixCache 树维护（占 32.62%），非推理纯系统开销超过 70%。TokenRouter 借助 pending 状态原地恢复，直接抹平了该瓶颈；
长输出负载表现极具韧性：当生成长度从 2048 激增至 8192 时，传统服务系统因为前缀树急剧膨胀导致吞吐骤降 58.1%–85.2%，而 TokenRouter 的吞吐几乎保持恒定；
推升服务 Pareto 边界：在 AMC23 精度与吞吐综合权衡下，TokenRouter 显著外推了 Pareto 前沿，首次让细粒度 token 级路由在真实系统部署吞吐上全面超越最先进的查询级路由（如基于 SGLang 的 RouteLLM）。

亮点与洞察¶

“请求中心-模型中心”的架构解耦：将算法描述收敛至单请求视角的极简 route-send-receive 范式，而让底层系统承担多子服务器调度，兼顾了算法开发极高的易用性与系统运行时极其极致的并发度。
基于 DTMC 精确推导调度超参：并非依赖启发式规则猜测组批等待超时，而是将动态路由抽象为离散时间马尔可夫链稳态分布求解，为分布式动态服务系统的批处理调度提供了坚实的理论支撑。
状态交接消除系统级开销：敏锐指出现代 Serving 引擎在多模型交互场景下前缀匹配与 KV 重分配的虚耗，用一个简单的 pending 中间态实现就地唤醒，具有极强的系统级复用价值。

局限与展望¶

马氏链几何分布假设的边界：数学吞吐模型假定连续由同一模型解码的 token 长度服从几何分布（即跳转概率平稳），对于极少数具有长周期固定 chunk 切换或强上下文相关路由策略的算法，该理论拟合可能存在偏差。
跨机通信瓶颈拓展：目前实验主要验证单机多卡与低并发双机 RoCE 环境，当拓展至更大规模集群、数百并发且跨节点带宽有限时，TokenRouter 的控制消息与网络抖动抗性仍需进一步验证。
动态自适应阈值调整：目前最优阈值 \(B^*\) 依赖于给定的固定并发度 \(N\) 计算，未来可在面对真实突发流量（bursty arrivals）时探索在线自适应学习的批处理阈值调节器。

评分¶

新颖性: ⭐⭐⭐⭐⭐ 首次系统性提出面向 Token 级 LLM 路由的服务架构，抽象出请求中心编程与三循环异步执行机制。
实验充分度: ⭐⭐⭐⭐⭐ 涵盖 5 种前沿路由算法、3 类高难度实际负载、多尺度模型对及系统的数学理论建模验证。
写作质量: ⭐⭐⭐⭐⭐ 动机清晰直击痛点，系统架构与调度数学模型推导严谨，图表表达信息丰富。
价值: ⭐⭐⭐⭐⭐ 开源并无缝兼容主流服务协议，填补了大模型细粒度路由从理论算法到工业落地的关键系统空白。