TokenRouter: Efficient Serving System for Token-Level LLM Routing

一句话概括

TokenRouter 是面向 token 级 LLM 路由的高效服务系统，在多种路由算法与模型组合下，解码吞吐比现有系统高 2.01-64.15 倍。它用「请求中心编程、模型中心执行」的设计，降低开发复杂度并缓解调度失步问题。

速览

任务：为 token 级路由的 LLM 推理提供高效、易开发的服务系统。
方法：开发者按单请求视角写路由逻辑，运行时为每个 LLM 启动子服务器并异步派发请求。
关键数字：解码吞吐提升 2.01-64.15 倍，覆盖多种路由算法、负载与模型对。
数据与开源：代码已开源，地址为 https://github.com/thu-nics/TokenRouter；数据集细节摘要未给出。

问题背景

LLM 路由（LLM routing）把推理任务分派到不同模型，用来推进服务的成本-质量帕累托前沿。会话级或查询级的粗粒度路由已在生产系统中广泛使用。近期算法工作显示，token 级（token-level）细粒度路由能带来效率与质量的双重收益。但现有系统建立在「单 LLM」假设上，难以高效支撑这种细粒度路由。它们会出现严重的步失步（step desynchronization）与频繁的批准入延迟（batch admission delay）。同时，这类系统给开发者带来很高的实现复杂度。

方法要点

TokenRouter 的核心原则是「请求中心编程，模型中心执行」（request-centric programming, model-centric execution）。

编程侧：开发者只从单个请求的视角描述路由逻辑，不必关心多模型并发的底层细节。
执行侧：运行时为每个 LLM 启动一个子服务器（subserver），并异步派发请求。
调度侧：每个子服务器使用延迟批处理调度器（delayed-batching scheduler）。
参数侧：调度器的最优超参数由系统的数学吞吐模型推导得到。

这套设计同时针对两个痛点：一是用异步派发与独立子服务器缓解步失步；二是用延迟批处理减少批准入延迟。对开发者而言，编程抽象从「多模型协同」退回「单请求描述」，实现复杂度随之下降。

关键结论

在多种路由算法、负载与模型对下，TokenRouter 的解码吞吐比现有系统高 2.01-64.15 倍。
该结果说明 token 级路由的服务效率可以被显著推进，而不只是算法层面的潜力。
收益来源指向两点：请求中心编程降低了开发与集成成本；模型中心执行配合延迟批处理调度改善了运行时效率。
摘要未给出质量指标、延迟分位数、硬件配置与具体基线系统的名称。

读后思考

token 级路由把「选哪个模型」的决策粒度压到单个 token，理论上更贴近成本-质量的真实权衡。但粒度越细，系统调度的抖动越难隐藏，这正是现有单 LLM 系统失配的地方。TokenRouter 的思路是把复杂性从开发者转移到运行时：人写单请求逻辑，机器管多模型并发。延迟批处理加数学吞吐模型推导超参数，也提示调度参数不该靠试错，而应有可解释的模型支撑。值得追问的是，2.01-64.15 倍这个跨度很大，说明收益高度依赖路由算法与模型对的组合；在收益偏低的一端，系统开销是否仍划算，摘要未给出。

局限与开放问题

摘要未给出质量、延迟与成本侧的完整评测，吞吐提升是否伴随质量损失未知。
吞吐跨度 2.01-64.15 倍的下界场景特征未说明，适用边界不清晰。
数学吞吐模型的形式、假设与适用范围摘要未给出。
延迟批处理调度器的最优超参数是否对负载变化鲁棒，摘要未给出。
与生产级部署相关的容错、扩缩容与多租户问题，摘要未涉及。
开源代码已提供，但可复现性细节与实验配置需查阅原文。