一个回答里让小模型和大模型接力——绝大多数 token 由便宜的小模型生成,只在真正难的地方递给大模型——这是 token 级路由给出的推理降本路线。算法侧这条路已经热闹了一阵,论文摘要里也直言:粗粒度的 session/query 级路由在生产系统里已被广泛采用,而近期算法工作显示 token 级路由能带来可观的效率与质量收益。短板一直卡在系统侧——现有推理引擎是按「一个请求从头到尾绑死一个模型」的假设设计的。

卡在哪

论文把问题拆成三层。其一,步失步(step desynchronization):两个模型解码速度天然不同,快的一方要停下来等慢的一方。其二,批准入延迟:token 在模型间不规则往返,常规连续批处理凑不出有效批次。其三,实现复杂度:路由算法作者要亲自处理批调度、模型交接和缓存状态,算法很难走出论文。

TokenRouter 的答案

清华电子系 NICS-EFC 团队的方案叫 TokenRouter,已被 NeurIPS 2026 接收,论文 10 月上 arXiv,代码同步开源。设计原则一句话:请求中心编程,模型中心执行——开发者用 route()、send()、receive() 三个接口只描述单个请求的路由逻辑;运行时为每个模型启动一个独立的 subserver,各自维持解码循环、异步调度。

两个工程细节值得单说。一是模型之间只传 token 后缀和路由状态,KV 缓存全部留在本地、不搬运;被路由出去的请求保持 pending 状态并保住自己的 KV 槽位,token 回流后直接续写,不重做前缀匹配和缓存分配。二是每个 subserver 配一个 delayed-batching 调度器,把不规则的 token 到达攒成批次,而最优阈值不是拍脑袋定的,由团队给系统建的数学吞吐模型推导出来。

工程亲和度也照顾到了:系统基于 SGLang 的 server args 扩展,单 YAML 文件完成配置,支持双节点各放一个模型,对外提供 OpenAI 兼容接口,也可以用 TokenRoutingEngine 直接在 Python 里内嵌使用。

数字与生态位

论文报告的官方数字:在多种路由算法、负载和模型组合上,解码吞吐比现有系统高 2.01 到 64.15 倍。覆盖的路由算法有五种——CITER、R2R、R-Stitch、Co-LLM、ME,另有 GlimpRouter、query 级路由和随机基线;实测模型对包括 Qwen2 1.5B/72B、LLaMA2 7B/70B、L1-1.5B-short/QwQ-32B 等,横跨 CommonsenseQA、GSM8K、AIME 三类基准。其中 R2R 本身就是同组的前序算法工作,这次相当于给自己的算法家族补上了发动机。

我的看法

这件事的价值不在 64 倍这个区间上限,而在把「换路由策略」从改系统变成换一个 YAML 文件。token 级路由算法一年能出好几个,但没有 serving 引擎承接,它们就只是论文里的表格;现在算法与系统的闭环补上了。冷水也要泼两条:64.15x 是极端配置下的上限,区间下限是 2.01x;且吞吐提升不等于质量提升,回答好坏仍取决于路由算法自身的判断力。repo 目前 20 star、2 个 commit,还在冷启动期——值得盯,但别急着上生产。

参考:arXiv 2610.12242(https://arxiv.org/abs/2610.12242);GitHub thu-nics/TokenRouter(https://github.com/thu-nics/TokenRouter)