清华等团队发布了 TokenRouter，帮助大小 AI 协同写出同一个回答：小模型先写，当系统判断需要大模型时，交给大模型继续写，之后甚至可以再交回给小模型。你可以把它理解为助手和专家一起工作，专家不必从头到尾处理所有内容。

官方介绍：https://fuvty.github.io/thinking_yard_project_page/projects/tokenrouter/

… 但大小 AI 之间频繁交接也会浪费时间。TokenRouter 所做的就是减少这些等待，让同一台设备每秒能生成更多内容。作者使用 Qwen3-0.6B 和 32B 模型，共享两块 A100 80GB GPU（CUDA MPS），同时处理 8 个请求：在 R2R 协作方案下，所有请求每秒生成的总内容从原程序的约 135 个 token 增加到 372 个，提升了 2.76 倍。Token 可以大致理解为一小段文本，但并不等同于一个汉字。这个数字指的是同时服务多个用户时的总输出，并不意味着每个人的回答都快了 2.76 倍。

论文：https://arxiv.org/html/2610.12242v1

代码已公开，作者测试了五种不同的大小模型协作方案。开发者可以用它来构建自己的协作服务，决定何时交给哪个模型处理。

代码：https://github.com/thu-nics/TokenRouter

TokenRouter · 面向 token 级 LLM 路由的高效服务引擎

来源：https://fuvty.github.io/thinking_yard_project_page/projects/tokenrouter/

一个面向 token 级 LLM 路由 的高效服务引擎。

机遇

一次回答。多个模型。

Token 级路由允许大小模型在单次回答中协同工作。服务引擎必须跟上每一次切换的步伐。

路由发生在哪里？

三种粒度的模型分配

Turn 1 · Token 1

一个会话三轮对话中示意性的模型分配；非实际生成轨迹。

独立推进。

快速模型应在较慢的同行处理被路由的 token 时继续解码。

有效的批次。

不规则的 token 到达需要调度器在正确的时间将请求聚合在一起。

简洁的接口。

路由策略描述单个请求。运行时管理批处理、交接和缓存状态。

引擎

每个模型按自己的节奏运行。

以请求为中心的编程。

以模型为中心的执行。

一个服务端点

请求准入与流式输出

小模型

入口子服务器

调度器

LLM 运行器

路由

解码

A B C

Step 1

Local KV cache

Request A · running

A send / receive

Token suffix + routing state

L

大模型

对等子服务器

调度器

LLM 运行器

路由

解码

Idle —

Local KV cache

Independent model state

解码一个本地批次。

小模型在一个批次中推进请求 A、B 和 C。

Decode

示意性的交接过程；动画速度不代表模型延迟。每个子服务器都有自己的解码循环。只有 token 后缀和路由状态在模型之间传输；KV 缓存保留在本地。该架构可扩展到两个以上的模型。

客户端-服务器循环

准入请求并流式输出完成的 token。

解码循环

调度本地批次并执行模型步骤。

模型间循环

发送、接收和恢复被路由的请求。

无需从头开始恢复。

待处理的请求保留其服务状态和 KV 槽位。返回的 token 直接追加，无需重复前缀匹配或 KV 分配。

Running

Pending

Running

or finished

编程接口

三个函数。一种路由策略。

描述请求何时切换模型、随请求传输的内容以及如何恢复解码。

route(batch, result)

选择下一个模型。

每次前向传播后，返回每个请求对应的模型名称。返回当前模型名称表示继续本地解码。现有的双模型调度器也接受布尔决策。R-Stitch 示例：True 表示委托给唯一的对等模型；False 表示在本地继续解码。

R-Stitch 代码摘自已发布的实现（https://github.com/thu-nics/TokenRouter）。已省略配置和周围的类定义。

五种被评测的策略，同一接口

发布的代码还包含 GlimpRouter、请求级路由和随机基线。参见支持的调度器。

快速开始

从源码安装并使用 Qwen3 0.6B / 32B 配置启动 R2R 服务器。

git clone https://github.com/thu-nics/TokenRouter.git
cd TokenRouter
conda create -n tokenrouter python=3.10
conda activate tokenrouter
pip install -e .
python -m tokenrouter.launch_server \
  --config_path config/r2r/Qwen3-0.6B_Qwen3-32B.yaml

服务器启动后，可使用 OpenAI 客户端示例或 requests 示例。Python 引擎示例无需单独的 HTTP 服务器即可直接运行。README 涵盖了多节点部署；复现指南 包含配置、工作负载和基准测试命令。

延迟批处理

少量等待。更好的批次。

立即开始可能让下一个到达的请求等待整个解码步骤。短暂而受控的等待可以让被路由的请求进入同一个批次。

相同的 token。不同的调度。

三个请求 · 每个请求五个 token

调度时间线

四种执行策略的概念性对比。

t = 0.0

小模型：Ready

大模型：Idle

已完成：0 of 3 requests

—

平均完成时间

固定路由序列和延迟来自论文的调度示例。每个块代表一个 token；相同的开始时间表示一个批次。延迟批处理使用 B_small = 1 和 B_large = 2。

实测阈值扫描

阈值很重要。

更大的批次有用，但等待时间过长会减少在途工作量。最佳阈值取决于并发度和路由行为。

吞吐量 · 输出 tokens/s

R2R · Qwen3-0.6B / 32B · AIME2024

实测值来自提供的阈值扫描。

阈值如何选择？

一个离散时间马尔可夫链对排队请求、活跃批次和每个子服务器的剩余执行时间进行建模。给定并发度、路由概率和模型步长延迟，TokenRouter 在可行的阈值中搜索最高期望吞吐量。

B* = arg max_B E[committed tokens] / E[elapsed time]

约束条件 ∑ᵢ(Bᵢ − 1) < N 避免了所有请求都在队列中等待的状态。该分析模型假设路由概率平稳且每步模型延迟固定；它不对所有非平稳路由模式进行建模。

服务效率

路由收益。

以每秒 token 数交付。

五种算法、三种工作负载、两种基线。

TokenRouter 加速的是执行路由策略的系统。

高强度推理

并发度 4 · 输出 tokens/s · 越高越好

官方代码 · 标准服务 · TokenRouter

比值是将 TokenRouter 与每种算法可用的更强基线进行比较。所有柱状图使用从零开始的线性刻度。

本次选择的精确数值

模型与硬件

CITER、R2R、R-Stitch 和 Co-LLM 使用 Qwen3-0.6B / 32B。ME 额外使用 Qwen3-8B，权重为 0.5 / 0.3 / 0.2。实验使用一台 8×A100-80GB 主机。双模型运行通过 CUDA MPS 共享两块 GPU：小模型使用 TP1，大模型使用 TP2。ME 将每个模型放在一块 GPU 上。

工作负载

低强度： AIME2024，约 100 token 输入，2,048 token 输出上限。

高强度： 精选的 AIME2024 题目，约 100 token 输入，8,192 token 输出上限。

Agent 场景： 多轮 SWE-Smith 轨迹，约 8,192 token 输入，1,024 token 输出上限。

基线与指标

官方代码： 该算法的已发布实现。不可用的条目显示为 N/A。

标准服务： 每个模型一个 SGLang 服务器，每次调用向外部调度器返回一个 token。吞吐量 = 生成的输出 token 总数 ÷ 经过时间。延迟 = 端到端请求完成时间。TokenRouter 基于 SGLang 0.5.1 构建。

扩展并发

更高吞吐量。响应式生成。

随着并发度增加，异步执行将更多在途请求转化为有效的模型工作。

生成速度 vs. 总吞吐量

R2R · 并发度 1–16

TokenRouter · R2R 官方实现

吞吐量与单用户生成速度

TokenRouter 和官方 R2R 实现在并发度 1 到 16 的对比。

并发请求数

8

每个点代表一个实测的并发设置；连线按顺序连接各设置。速度为单用户 token 生成速率。吞吐量为所有请求的聚合值。

18.58×

在可比的单用户速度下实现更高吞吐量。

TokenRouter 在并发度 16 时达到 630.57 tokens/s，单用户 39.41 tokens/s。官方 R2R 实现在并发度 1 时达到 33.94 tokens/s，单用户 34.87 tokens/s。此对比使用了不同的并发水平。

收益从何而来

运行时在每个环节都很关键。

CUDA Graph 支持、异步执行和延迟批处理层层递进。

累积系统优化

R2R · 并发度 8 · 输出 tokens/s

每一行包含前述的优化。官方 R2R 实现达到 134.90 tokens/s；完整的引擎达到 372.48 tokens/s（2.76×）。这些是顺序消融实验，不是独立的叠加效果。

扩展 CUDA Graph。

捕获被路由请求恢复时遇到的更大范围的扩展长度。

保持路由本地化。

将路由器与模型一起运行，避免每个 token 都产生独立的 IPC 往返。

保留服务状态。

保留待处理的请求，并在同机部署的模型之间协调 KV 预算。

不同的大小模型配对

在跨节点、相同模型资源下

Qwen3-0.6B 使用一块 GPU，Qwen3-32B 使用两块 GPU（TP2），无 GPU 重叠。模型部署在一到两个节点上，通过 3.7 GB/s RoCE 连接。以下测量使用低强度推理。算法在其原始模型和任务设置下运行。

团队

认识研究者们。

*共同贡献

†通讯作者

引用

引用我们的工作。

@article{fu2026tokenrouter,
  title={TokenRouter: Efficient Serving System for Token-Level LLM Routing},
  author={Tianyu Fu and Tengxuan Liu and Ruoxi Wang and Yixin Dong and Yi Ge and Yichen You and Yu Wang},
  journal={arXiv preprint arXiv:2610.12242},
  year={2026},
}

Tianyu Fu (@fuvty123): 🔥 TokenRouter 来了！高效的 token 级 LLM 路由，现已可用于服务部署。

🚀 吞吐量较服务基线提升 2.01–64.15 倍 ✍️ 仅需三个函数：send、receive、route

带上你的路由算法，服务层我们来搞定。