你让 AI 回答一道难题，它不一定从头到尾都需要最强、最贵的模型。有些片段只是连接句，有些步骤却需要认真推理。常见做法像是进门前选一位医生：整次问诊都由同一个人负责。TokenRouter 想做得更细——生成过程中，可以随时把下一步交给另一个模型。
严格说，标题里的“词”是 Token。Token 是模型读写文本的基本片段，可能是一个字、半个词，也可能只是标点。“逐 Token 路由”并不表示每一步一定换模型，而是每生成一个片段，都有机会重新选择。
这项工作的重点也不是发明如何选择模型，而是解决选择之后的交通问题：请求在多个模型之间频繁移动，服务器怎样才能不堵车。以下性能数字均来自作者在一台 8×A100-80G 服务器上的实验，尚无独立复现。
从“整题分配”到“随时换手”
模型路由（Model Routing）是把任务分给不同模型：简单请求交给较小模型，困难请求交给较大模型，或者按专业领域挑选模型。传统系统通常以整段对话或单次提问为单位。一旦选定，整份回答都由同一个模型生成。
逐 Token 路由把决定推迟到生成过程中。论文列举的 R2R 方法，在其既有实验中只把约 5% 的 Token 交给 32B 模型，就能达到该 32B 模型的质量；按整条请求路由，则约有 40% 的请求要交给大模型。另一些方法让不同专长的模型在同一回答中协作，目标不只是省算力，也可能提高质量。
但算法上“可以换手”，不等于服务系统能高效执行。推理服务（Inference Serving）是模型训练完成后，负责接收请求、组织计算并返回结果的整套系统。它通常把多条请求凑成一批，一起送进模型，以提高硬件利用率。逐 Token 换模型会打乱这种整齐节奏。
论文归纳了三个麻烦。第一，不同模型每一步耗时不同。如果所有请求必须同步，整批任务就要等最慢的模型。第二，请求抵达目标模型时，目标模型可能刚开始处理上一批，只能等待下一次入场。第三，现有系统没有为逐步路由准备简洁接口，开发者往往要改动批处理、缓存和调度等底层代码。
开发者看一条请求，系统看一组模型
TokenRouter 的核心原则是“request-centric programming, model-centric execution”：开发者从单条请求的角度写路由，运行时则围绕每个模型组织执行。
开发者只需描述三个动作。route 决定下一步留在当前模型，还是转给另一个模型；send 打包对方尚未见过的 Token 和必要状态；receive 接收这些内容，让目标模型继续生成。作者用这套接口表达了 CITER、R2R、R-Stitch、Co-LLM 和 ME 五种路由算法。它们判断换手的信号不同，但都能归纳为“选择、发送、接收”。
系统内部则为每个 LLM 启动一个 subserver——可以理解为各模型自己的独立工作台。每个工作台拥有调度器、模型执行器和私有 KV Cache。KV Cache 是模型生成时保存的中间结果，像一张草稿纸，可以避免每次都从头重算。外部用户仍只看到一个统一接口，因此论文称它可以替代标准的单模型服务器接口。
这个分工的价值在于，写路由算法的人不用亲自处理并发和批次；运行时也能从全局安排多个模型，而不是被某条请求的顺序绑住。
不再让快模型等慢模型
TokenRouter 给传统服务结构增加了一条独立的“模型间循环”。客户端收发、模型解码和模型间移交各自运行。某条请求离开当前模型后，其他请求继续计算；等它从另一个模型返回，再重新加入本地批次。各模型不必锁在同一个节拍上。
换手时，系统把请求标记为 pending，也就是暂时搁置，但保留原有服务状态。它回来后，只需追加新 Token，再恢复运行。相比把返回请求当成全新请求，这样可以跳过重复的前缀匹配和 KV Cache 分配。
不过，完全异步又会产生新问题：请求零散抵达，模型如果来一个就开一次工，批次会越来越碎。TokenRouter 因此采用 delayed batching——延迟批处理。调度器短暂等待，缓存到达的请求，达到阈值后再一起执行。早到的请求多等一点，后到的请求却可能更快入场，平均等待时间有机会下降。
阈值不能凭感觉设。太小，批次仍然零碎；太大，请求会困在队列里。作者把路由过程建模为离散时间马尔可夫链，并根据并发量、路由概率和各模型单步延迟，搜索数学模型下吞吐量最高的阈值。这里的“最优”只在模型及其假设成立时有效，不是所有部署环境的通用答案。
提速来自哪里？
作者在三类负载上测试：短输入短输出的低强度推理、最长输出 8,192 Token 的高强度推理，以及约 8,192 Token 输入的多轮 Agent 任务。系统以 SGLang 为基础，并与算法官方实现及作者搭建的标准 SGLang 服务基线比较。
在 15 个“算法×负载”组合中，论文报告 TokenRouter 相对更强基线的解码吞吐量提高 2.01–64.15 倍，端到端完成延迟相对标准服务降低 2.03–63.64 倍。这个跨度很大，不能直接理解成任何应用都会快几十倍；结果取决于模型组合、路由方式、并发量和工作负载。
消融实验更能说明各部分的作用。在并发量为 8 的一组 R2R 实验中，基础实现为 132.78 token/s；扩展 CUDA Graph 等工程优化后升至 230.79，加入异步执行后达到 296.86，再加入延迟批处理后达到 372.48 token/s。也就是说，收益不只来自一种调度技巧，而是工程优化、异步换手和批次组织共同贡献。
长输出尤其考验频繁换手。输出上限从 2,048 增至 8,192 Token 时，论文称 TokenRouter 的吞吐量保持稳定，而标准服务损失了 58.1%–85.2%。作者也测试了 0.6B、1.7B、4B、8B 和 32B 等不同大小的模型组合；相对官方 R2R 实现，吞吐提升为 1.99–3.21 倍。
为什么值得关注？
逐 Token 路由原本更像一种算法设想：知道何时该请大模型接手，却缺少能承受频繁交接的服务底座。TokenRouter 把问题从“怎么选模型”推进到“怎么让选择真正跑得动”。如果这套思路在更多环境中成立，多模型服务的成本与质量就不再只有几个固定档位，而可能在生成过程中连续调整。
它还提供了一层清晰分工：研究者描述请求怎样移动，系统负责批处理、缓存和异步执行。论文称代码已发布在 GitHub 的 thu-nics/TokenRouter 仓库，但供稿没有独立核验许可证、可用性或复现实验状态。
局限与未知
- 所有效果论断目前来自同一研究成果。实验集中在一台 8×A100-80G 服务器，尚不能代表其他硬件、延迟目标或线上流量。
- delayed batching 会主动增加一小段等待。论文展示了吞吐量与单用户速度的权衡，但实际服务如何按响应要求选阈值，仍要结合部署场景。
- 数学模型假设两次发送之间的 Token 数服从几何分布。作者承认，如何处理不满足这一假设的边缘情况仍是未来工作。