Token 级路由第一次跑赢了「不路由」
先看一个尴尬的数字。学术圈里有一种省算力的办法叫 token 级路由：同一个请求在解码过程中，简单 token 交给小模型，难 token 才交给大模型。其中一个叫 Co-LLM 的算法，官方实现跑起来只有每秒 3.46 个 token；而干脆不用路由、整个请求全塞给大模型，每秒能跑 134.79 个。也就是说，这个…
Token 级路由第一次跑赢了「不路由」
先看一个尴尬的数字。学术圈里有一种省算力的办法叫 token 级路由：同一个请求在解码过程中，简单 token 交给小模型，难 token 才交给大模型。其中一个叫 Co-LLM 的算法，官方实现跑起来只有每秒 3.46 个 token；而干脆不用路由、整个请求全塞给大模型，每秒能跑 134.79 个。也就是说，这个路由算法照原实现部署，比不部署还慢 39 倍。另一家算法 R-Stitch 的官方代码干脆没跑通。这就是 token 级路由长期停在论文里的原因：算法很多，没有一套系统能让它真正跑起来。
为什么值得费这个劲？因为粒度每细一级，省的算力就多一大截。现在的生产系统做的是请求级路由：整个请求判断完难度，走一个模型，走到黑。可是一个回答内部的难度波动很剧烈——一道数学题，「推导」那几步需要大模型，「答案：x=42」全是抄写，小模型绰绰有余。R2R 算法给过一个漂亮的数据：只把 5% 的 token 送给 32B 模型、其余交给 1.5B 模型，就能匹配 32B 的生成质量；换成请求级路由，得把 40% 的请求整个送上去才等价。从 40% 压到 5%，空间全在粒度里。
粒度切到 token 之后，系统就散架了。vLLM、SGLang 这类推理框架的全部假设是「一个请求从头到尾属于一个模型」：批内所有请求锁在同一个节奏上一步步走。token 级路由意味着一个请求解码到一半要换模型，而且是数据驱动的、不可预测的换法。两个具体的问题随之而来：批调度上，路由请求频繁到达时，目标模型往往还在跑上一批，新请求只能排队等准入；状态交接上，KV 缓存和上下文格式在模型之间怎么搬、怎么恢复，没人管过。有人试过把路由硬套进投机解码的服务框架，但投机解码是两个模型按固定节奏 tightly coupled 地轮流，token 路由是随机访问，套进去全是空转。
清华 NICS 实验室（王玉组，通讯作者）和卡内基梅隆的 Yixin Dong——SGLang 的一作之一——合写的 TokenRouter（arXiv 2610.12242）就是补这一课的系统，10 月 8 日放出代码。三层设计。最上层是编程接口：开发者只写 route、send、receive 三个函数——route 决定下一个 token 走哪个模型，send 把请求状态打包传走，receive 在新模型侧恢复解码。关键的理念是「请求侧编程、模型侧执行」：你只描述一个请求怎么流动，并发、调度、传输的脏活系统全包。中间是执行层：每个模型一个自治子服务，三个调度循环（客户端通信、解码、跨模型交互）彼此解耦异步跑，一个模型的批满了不用全系统陪等，跨模型交接由切换-恢复机制统一处理。最下层是批调度：路由导致的批次碎片化用延迟批处理吸收，调度器的关键超参不是手调的，是从系统的吞吐量数学模型里推导出来的最优值。
效果的主账在 R2R 上算得最清楚。TokenRouter 跑 R2R 每秒 244.56 个 token，是官方实现的 2.7 倍，更关键的是比「整个请求全用 8B 模型」的 LLM-only 基线还快 1.68 倍——token 级路由第一次在真实系统里跑赢了不路由。四种路由算法、多个负载、15 种组合上，论文报告对现有实现的加速在 2.01 到 64.15 倍之间（最强基线下）；四组 Qwen3 模型对（0.6B、1.7B、4B 配 8B）上稳定快 2 到 3.2 倍。拆开看每层优化的贡献也清楚：基础实现每秒 132.78，扩展 CUDA graph 到 164，异步执行到 296.86，延迟批处理收尾到 372.48。顺带一个部署经验：大模型侧加张量并行对吞吐至关重要，小模型侧加不加无所谓。
这是算法组自己下场补系统课的典型样本：同一个组 2025 年先发表了 Think-at-hard 路由算法，一年后端出服务层。代码在 thu-nics/TokenRouter，vLLM 式的对外接口可以直接替换现有单模型服务。想感受 token 级路由的全部意义，就记住 R2R 那个数字——5% 对 40%。粒度每细一级，算力的余地就大一分，而这份余地能不能落到速度上，最后要看服务系统接不接得住。