TokenRouter：让大小模型「逐字接力」也能高效上线

小模型写大部分字，难字交给大模型——并让它真的跑得快

3 分钟版

问题　生成一段回答时，大部分字很简单（标点、套话），少数字很难（关键推理步骤）。研究发现：让 1.5B 的小模型写大部分字、只把 5% 的难字交给 32B 大模型，质量就能追上 32B。但现有推理服务（vLLM、SGLang）是为「一个模型从头写到尾」设计的，两个模型来回接力时会互相等待、批次被打碎，反而比只用大模型还慢。

思路　「按请求编程，按模型执行」。开发者只需用三个函数描述一条请求怎么在模型间流转：route（下一个字该谁写）、send（交接时传什么）、receive（收到后怎么接上）。系统则为每个模型起一个独立的子服务器，各跑各的节奏，请求异步来回传递；交接时保留请求的缓存状态，回来时只需追加几个字。每个子服务器还会稍等片刻、攒够同一模型的请求再一起算（延迟批处理），等多久由一个数学模型算出最优值。

结果　在 5 种逐 token 路由算法、3 类负载、多组模型搭配上，TokenRouter 的解码吞吐比现有最强实现高 2.01–64.15 倍。以 R2R 算法为例，并发 8 时吞吐是官方实现的 2.76 倍；并发 16 时吞吐是官方 R2R 单用户时的 18.58 倍，每个用户的速度还快 1.13 倍。

所以呢　逐 token 路由从「论文里省钱」变成「服务器上省钱」的门槛被拉低了。它对外是一个标准接口，可以直接替换现有单模型服务。对做推理平台、模型组合（小模型 + 大模型）和端云协同的团队，这意味着新的成本曲线；对只卖单一大模型 API 的厂商，则是潜在的价格压力。

关键数字

• 2.01–64.15× 解码吞吐提升范围（Abstract · §5.2）
• 2.76× R2R 算法，并发 8 时的吞吐（Fig. 1(a) · §5.3）
• 18.58× 并发 16 时 vs 官方 R2R 单用户的吞吐（§5.2）
• 5% R2R：交给 32B 大模型的 token 比例（§1）
• 8.61× 并发从 1 到 16 的吞吐增长（§5.2）

局限与疑问

• 吞吐模型依赖几何分布假设，违反假设的场景未覆盖（作者自述）。
• 64.15× 这类上限来自对比研究原型实现，标准服务基线更能代表真实收益。
• Co-LLM、R-Stitch 等算法路由后吞吐仍低于只用大模型，是否省钱取决于算法。
• 实验主要基于 Qwen3 系列与单台 8×A100 服务器。

arXiv 摘要页 · PDF