token 级路由打破单模型服务假设
token 级路由允许生成每个 token 的模型逐步变化。这比查询级路由更细：查询级路由把请求交给一个模型，由该模型生成整个回复。论文引用 R2R 作为效率收益的证据：它只把 5% 的 token 路由给 32B 模型、其余交给 1.5B 模型解码，就能达到 32B 模型的质量；相比之下，查询级路由需要把约 40% 的查询交给 32B 模型。
SGLang 和 vLLM 等现有服务系统按单个 LLM 设计，所有活跃请求在每个解码步保持同步。token 级路由从三个方面打破这一假设。第一是步不同步：不同模型的单步延迟差异很大，同步批处理必须等待最慢的模型，较快的模型只能空闲。第二是批准入延迟：模型切换频繁，被路由的请求到达时目标模型往往仍在处理上一批，只能等待下一批，造成空泡并切碎批次。第三是实现复杂度：这些系统没有为逐步路由决策提供接口，开发者必须大幅修改代码，还要让路由逻辑与连续批处理、前缀缓存等紧密耦合的功能协调一致。
以请求为中心编程，以模型为中心执行
TokenRouter 的设计原则把问题拆成两半。开发者通过 route-send-receive 接口追踪单个请求如何在多个协作 LLM 之间流动，以此描述路由算法。运行时则为每个 LLM 启动一个子服务器并异步分派请求，从而对开发者隐藏路由的服务系统复杂度。
这种拆分把路由算法与服务系统优化解耦。在实现上，TokenRouter 构建于 SGLang 0.5.1 之上，服务器接口改编自 SGLang 的 FastAPI 前端以支持多模型端口参数，子服务器之间的消息通过本地 ZeroMQ IPC 传递。每个子服务器在独立子进程中用单个事件循环运行三阶段迭代，子服务器之间唯一的协调是 peer-message 通道。所有被评估的路由算法共享这一运行时，各自实现为调度器子类。
延迟批处理用准入延迟换更满的批次
每个子服务器使用延迟批处理调度器：只有当该模型的等待队列中至少有阈值数量的请求时，才启动新批次。阈值是关键调节参数。设得太低，批次小而零碎；设得太高，请求会不必要地等待，甚至可能死锁——没有任何模型能积累足够多的排队请求来启动批次。
论文通过推导得到最优阈值，而不是手工调参。它把系统建模为在批次完成事件上观测的离散时间马尔可夫链，状态记录每个模型的队列长度、运行中批次大小和剩余执行时间。模型假设路由概率在各解码步之间平稳，且各请求的路由决策相互独立。根据平稳分布，模型把稳态已提交 token 吞吐量计算为每次状态转移的期望已提交 token 数除以期望转移时间，然后在防止死锁的可行性条件下搜索使吞吐量最大的阈值向量。
预测阈值与实测最优阈值一致
论文用 R2R 的双模型设置验证吞吐量模型，其中模型 0 是小模型，模型 1 是大模型。路由概率 p = 0.35，实测解码步延迟为小模型 6.0 ms、大模型 27.9 ms，时间量子为 0.1 ms，模型据此预测不同并发水平和阈值向量下的吞吐量。
把小模型阈值固定为 1、改变大模型阈值时，预测吞吐量在并发水平 N = 2、3、4 下都与实测吞吐量走势一致。更重要的是，在每个评估的并发水平上，预测吞吐量最大的阈值都与实测最优阈值相同。论文据此认为，该模型足以指导阈值选择，而不只是事后描述趋势。
吞吐量提升覆盖多种算法与模型组合
在多种路由算法、工作负载和模型组合上，TokenRouter 的解码吞吐量比现有系统高 2.01–64.15 倍。区间下限本身也有信息量：在某些小模型/大模型组合上，提升约为两倍，而不是数量级。表 3 给出 R2R 与 TokenRouter 在三组模型上的吞吐量（token/s）：0.6B/32B 为 77.08 对 197.40（2.56 倍），1.7B/8B 为 103.37 对 285.41（2.76 倍），4B/8B 为 106.67 对 211.81（1.99 倍）。
论文还报告了一项影响这些数字的并行策略发现：增大模型的张量并行规模对吞吐量至关重要，而小模型的张量并行规模影响很小。因此，除非另有说明，实验把大模型张量并行设为 2、小模型张量并行设为 1。读者比较吞吐量数字时应注意，这些是在该配置下以 token/s 计的解码吞吐量，而不是端到端延迟。
细粒度路由推动帕累托前沿
吞吐量本身不能说明 token 级路由是否值得部署。论文因此在 AMC23 上评估吞吐量–准确率权衡，使用 Qwen3-0.6B 与 Qwen3-32B 组合、贪心解码、最大输出长度 8,192 token。所有请求并发发送，吞吐量按每个请求计算为输出 token 数除以耗时，并在各系统间保持小模型/大模型显存比例相同，以保证比较公平。
在这些条件下，TokenRouter 把 token 级路由推到新的帕累托前沿，使细粒度路由在 SGLang 等先进框架上比粗粒度路由更有竞争力。比较对象包括官方 R2R 实现和 RouteLLM 的查询级路由基线。这一结果改变了读者权衡路由粒度的方式：问题不只是 token 级路由能否节省算力，还在于服务系统能否把这些节省转化为吞吐量，同时不牺牲准确率。
吞吐量模型的适用边界
这一优化依赖一个假设：两次连续发送之间的 token 数服从几何分布。论文指出，多数 token 级路由算法满足该假设，违反该假设的边角情况留待未来工作。模型还假设路由概率平稳、请求之间相互独立；论文说明，如果路由概率随时间变化，只要在短时间区间内可近似为常数，同样的分析仍然适用。
这些是阈值优化的条件，而不是异步子服务器架构的条件。发送间隔不服从几何分布的路由算法仍可运行在 TokenRouter 上，但其延迟批处理阈值不受推导出的最优值覆盖。实际优先级由此划分：异步、以模型为中心的执行带来的架构收益是论文更广泛的结论；具体阈值则在 R2R 的双模型设置上验证，其他路由模式需要重新推导。
本文引用的文献
TokenRouter: Efficient Serving System for Token-Level LLM Routing
TokenRouter 把以请求为中心的路由编程与以模型为中心的异步执行分开，为每个模型启动子服务器，并用吞吐量模型推导延迟批处理阈值；在多种路由算法、工作负载和模型组合上，其解码吞吐量比现有系统高 2.01–64.15 倍。