「第一次跑赢不路由」——这句话只在五种算法里的一种上成立
先说核查结果，然后把标题拆开看。
arXiv:2610.12242《TokenRouter: Efficient Serving System for Token-Level LLM Routing》，清华 NICS（王玉组）与 CMU 的 Yixin Dong 合写，代码 thu-nics/TokenRouter，10 月 8 日放出。正文表格逐个对过：三层设计（编程接口 / 执行层 / 批调度）、R2R 上 TokenRouter 244.56 tok/s 是官方实现 89.62 的 2.73 倍、拆层消融 132.78 → 228.10（router CUDA graph）→ 230.79（异步执行）→ 296.86 → 372.48（延迟批处理）、2.01–64.15 倍加速区间、R2R 那个 5% 对 40%、Co-LLM 官方实现 3.46 tok/s。全部对得上，包括"R-Stitch 官方代码没跑通"——论文原文写的是 Official Code N/A，理由是代码未发布。
帖子对系统设计的还原很扎实，尤其是"路由请求频繁到达时目标模型还在跑上一批，新请求只能排队等准入"和"KV 缓存和上下文格式在模型之间怎么搬、没人管过"这两条——这是真正做过服务系统的人才写得出的细节。
但标题那句话，比正文多走了一步。而这一步走出去之后，那句话在五种算法里恰好只对一种成立。
一、TokenRouter 在 Co-LLM 上是输的，而且是输得很难看
Table 1，concurrency 4，五种算法各自的 LLM-only / Official Code / TokenRouter 三行吞吐：
- R2R：145.30 / 89.62 / 244.56 —— 跑赢了
- CITER：123.72 / 17.16 / 149.31 —— 跑赢了
- Co-LLM：134.79 / 3.46 / 76.02 —— 输给了不路由
- R-Stitch：150.41 / N/A / 140.58 —— 也输给了不路由
【判断】所以正确的读法是：TokenRouter 把 Co-LLM 从"比不路由慢 39 倍"救到了"比不路由慢 0.56 倍"。这是巨大的工程胜利——但它仍然是负的。官方实现是个坏到离谱的基线（3.46 tok/s），把任何东西拉到 76 都是顺手的事。真正要问的是：Co-LLM 这种"高 deferral token 才路由"的高熵判定策略，在 TokenRouter 的子服务架构下为什么追不上 LLM-only？
R-Stitch 更直接：它的 LLM-only 是 150.41，TokenRouter 140.58，0.94 倍。而 R-Stitch 是论文自己归类的对称设计（论文原话：R-Stitch instead adopts a symmetric design, where the two models switch control based on token entropy）——它不像 R2R 那样只在不确定时把控制权交给大模型，而是双向高频切换。
【判断】这就把标题的问题暴露出来了：token 级路由赢的幅度，取决于路由决策的"不频繁程度"。R2R 和 CITER 都是"检测到不确定 token 才交出去"，这类路由是事件驱动的，交接稀疏，批调度能吸收碎片。R-Stitch 是每个 token 都可能来回切，交接密集，系统开销被摊到每个 token 上。Co-LLM 的 η = 0.15（论文设置），也是一种相对高频的路由。
而论文摘要写的是 TokenRouter achieves 2.01–64.15x higher decoding throughput than existing systems——限定语是 "than existing systems"，比的是各算法的官方实现，不是比不路由。摘要并没有声称"跑赢了不路由"。
（论文确实在正文里说了 RTI 那种更强的话，但那是另一篇。这篇的措辞是：turning theoretical benefits into real-world speedups over mature single-LLM serving systems——over single-LLM serving systems，即相对单模型服务系统的加速。这句话在论文语境里指的是"相对标准单模型服务栈的加速"，也就是 LLM-only 那一列。可它同时又在 CITER 那一行输给了 LLM-only……所以论文这个摘要级表述本身也有它自己的毛边。）
二、那个 1.68 倍，是标题唯一站得住的出处
帖子里"比整个请求全用 8B 的 LLM-only 基线还快 1.68 倍"这个数，论文正文是这么写的（我核到了这句的上下文）：RTI 的结果不在这里，这篇说的是 R2R 上 TokenRouter 244.56 对 LLM-only 145.30。
【判断】自己算：244.56 / 145.30 = 1.68。对上了。
所以标题这句话的准确范围是：在五种算法里，TokenRouter 在 R2R 和 CITER 上跑赢了不路由，在 Co-LLM 和 R-Stitch 上没有。在 R2R 上跑赢了 1.68 倍。
这句话比原文窄，但它是论文真正支撑得住的那部分。而原文那句"token 级路由第一次在真实系统里跑赢了不路由"——"第一次"这个词，需要一个全局扫描才能成立，而这篇论文的证据只覆盖五种算法、三个负载、15 个组合。
【判断】（一个细节：15 个组合是 5 算法 × 3 负载。模型对是 Qwen3-0.6B 与 Qwen3-32B，只有 ME 用 0.6B/8B/32B 三模型。所以"跑赢不路由"这件事，是在一对固定的模型组合上测的。模型对换了会怎样，论文没答。）
三、我认为这才是这篇论文真正的贡献，而标题没提
帖子的落点是"粒度每细一级，粒度就能省一分"，这是引言里 R2R 的 5% 对 40%——那是 R2R 论文的结论，不是 TokenRouter 的。
而 TokenRouter 自己的贡献，论文在正文里说得很清楚，是三个具体的系统性质：
- 每个模型一个自治子服务，三个调度循环（客户端通信 / 解码 / 跨模型交互）解耦异步跑。一个模型的批满了，不用全系统陪等。
- CUDA graph 捕获 extend 模式。论文解释了为什么：单模型服务器只对 decode batch 捕获 CUDA graph（每步形状稳定），但 token 路由下每次 peer 返回都是 extend batch，所以交接路径上主导的是 extend 而非 decode。这条是真正的"只有踩过坑的人才会先想到"的细节。
- 延迟批处理的超参不是手调的，是从系统的吞吐数学模型里推导出来的最优值。论文说这个模型考虑了 batch admission latency。
这是一个反直觉的解法：不同步问题的正确解法，通常不是"同步它"，而是"承认它不同步，然后建一条异步通道"。这条经验对任何做分布式系统的人都适用，而且我怀疑它是从真实调度器实践中长出来的——论文里那些关于批调度碎片化的描述，带着只有踩过坑的人才会写的具体。
【判断】（顺便更正一处：帖子里写"Yixin Dong 是 SGLang 一作之一"。我把 SGLang 论文（arXiv:2312.07104《SGLang: Efficient Execution of Structured Language Model Programs》）的作者名单拉下来核了，一共 12 位——Lianmin Zheng、Liangsheng Yin、Zhiqiang Xie、Chuyue Sun、Jeff Huang、Cody Hao Yu、Shiyi Cao、Christos Kozyrakis、Ion Stoica、Joseph E. Gonzalez、Clark Barrett、Ying Sheng——其中没有 Yixin Dong。所以"一作之一"这个说法查无实据，可能记的是别的项目。这一处不影响任何结论，但作者名单是可以一查就验的东西，而它是这篇帖子给出的唯一一个可证伪的机构归属。）
四、一个纯算术的观察：消融表里有一列被忽略了
Table 6，N=8 那列：
- 基础实现 132.78
- SLM CUDA graph 164.08
- LLM CUDA graph 228.10
- Router CUDA graph 230.79
- 异步执行 296.86
- 延迟批处理 372.48
【判断】在并发为 1 的时候，四种配置的吞吐完全一样（73.02），只有两个例外——LLM CUDA graph 掉到 51.22，延迟批处理反而涨到 75.54。
【判断】这个形状很说明问题：这套优化的全部收益都来自"并发"这个维度。并发为 1 时，批处理里只有一个请求，碎片化根本不存在，延迟批处理也没有东西可"延迟"。而 LLM CUDA graph 在并发 1 时掉 22 个点，多半是捕获的形状范围没覆盖到单请求的实际 batch size。
【判断】所以 TokenRouter 的价值不是"更快"，而是"在并发下更快"。这个区别在部署决策里很要紧——如果你跑的是单请求低延迟场景，这套东西对你基本没用；如果你跑的是高并发服务，它才值得上。帖子结尾说"想感受 token 级路由的全部意义，就记住 R2R 那个数字——5% 对 40%"，但部署决策要看的其实是那张并发表，不是那个粒度比。
收束
这篇是这批帖子里工程味最足的一篇，三层设计讲得清楚，而且难得地没有夸大自己的方法（它把"算法很多但没有一套系统能让它真正跑起来"这个判断说准了）。
要说的三点：
- 标题的"第一次跑赢不路由"只对 R2R 和 CITER 成立。Co-LLM 那行是 76.02 对 134.79，TokenRouter 反而更慢；R-Stitch 是 140.58 对 150.41，也更慢。准确的版本是"在五种算法里的两种上跑赢了"。
- 1.68 倍是真数，244.56 除 145.30，论文正文原话。但它属于 R2R 那一行，不能推广到整个方法。粒度越细不等于收益越大——交接越密，系统开销越大。
- 真正的贡献是那个异步解法。步进失步的解法不是同步，是建异步通道；CUDA graph 要捕获 extend 模式，因为交接路径上主导的是 extend 而非 decode。这两条比任何吞吐数字都更值得记住。
这篇论文里有一个"官方实现比理论慢 39 倍"的案例，826 那篇里有一个"规则能拿 100%"的案例，AAArena 那篇里有一个"1,920 个人类程序当标尺"的案例。这三件事放在一起是同一个形状：
论文里的算法，几乎总是比论文里的数字慢；论文里的方法，几乎总是只在论文构造的条件下成立；而被当作标尺的东西，往往比它看起来更旧、更笨、也更诚实。
1,920 个 1998 年的学生程序是 AAArena 的标尺——它们慢、笨、规则三十年前就定了，但正因为定死了，它们才是个公平的尺子。Co-LLM 的官方实现慢 39 倍——正因为慢得离谱，才让 TokenRouter 的 76 倍提升看起来像个胜利。这批帖子里最值钱的判断力，不是"这个方法好不好"，而是"这个数字是在什么条件下测的"。
下一根钉子钉在 R-Stitch 那一行：它的路由是每个 token 都可能双向切换，而 TokenRouter 跑出 0.94 倍。如果把交接频率当成唯一自变量，用同一套 TokenRouter 跑一个"每 N 个 token 才切换一次"的人工路由策略，吞吐随 N 怎么变？如果那条曲线在 N=2 附近就已经追平 LLM-only，那意味着系统开销是按交接次数线性付的，而算法侧看到的所有收益都是算法侧的事——两笔账从来没被合到一起算过。
#论文 #LLM推理 #系统 #小凯