TAO：让工具返回时间成为智能体推理调度信号

导语

LLM 智能体的服务形态不同于连续生成的普通聊天请求：一次任务往往需要在 GPU 上运行模型，再调用分布式 CPU 工具，随后等待工具结果并回到模型侧继续生成。若调度器只关注当前 GPU 队列，就可能把大量资源留给暂时无法继续执行的会话，同时反复换入换出 KV 缓存。

论文提出的 TAO（Tool-Aware Joint Scheduling）试图解决这一问题。它不再把工具调用视为调度流程之外的暂停状态，而是将“工具何时可能返回”纳入 GPU 会话选择。

核心做法

• 工具边界中断。 会话进入外部工具调用阶段后，TAO 暂停其 GPU 执行并释放相关容量，将会话放入共享等待池。工具返回后，会话重新参与调度，而不是长期占用无法继续生成的 GPU 资源。
• 三因素会话价值评估。 TAO 针对“会话—节点”组合计算价值，综合考虑近期工具返回就绪度、节点特定的 KV 缓存信用以及 token 占用。工具就绪度可由运行时提示和历史工具时长预测，KV 缓存信用则随时间衰减，从而避免旧缓存永久占据优势。
• 联合选择与放置。 与逐个请求进行贪心路由不同，TAO 使用异步动态规划，在 GPU 容量约束下同时决定哪些等待会话应被接纳，以及它们应放置到哪个节点。论文给出的运行时开销低于整体运行时间的 0.12%，并通过异步重新校验应对计划生成后的状态变化。

实验观察

TAO 在 DeepSeek-V4 Flash、Qwen3-32B 和 GLM-4.7 等模型上进行了测试，覆盖 12 组模型、工作负载与并发设置。相较于每项指标中表现最佳的已评估基线，TAO 的端到端延迟最高下降 26.8%，平均首 token 时间（TTFT）最高下降 36.3%，解码吞吐最高提升 29.5%。

一个值得注意的取舍是：在高并发场景，TAO 可能主动延后部分会话的初始接纳，因此客户端看到的 TTFT 未必始终更低。但这种“有控制的等待”可以减少 KV 缓存抖动、抢占和重复计算。素材中给出的 AutomationBench 案例显示，在 128 个 worker 下，TAO 的平均 TTFT 为 19.1 秒，高于 Dynamo 的 3.2 秒；与此同时，整体任务时延从 1417.2 秒降至 563.1 秒，解码吞吐从 482.4 token/s 提升至 1013.2 token/s。换言之，较长的排队等待换来了更快、更稳定的任务完成过程。

意义与影响

TAO 的价值不只是增加一个调度指标，而是改变了智能体服务的优化对象：调度器需要同时理解 GPU 计算、KV 缓存局部性和外部工具的时间行为。论文还显示，动态规划相较于 best-fit-decreasing 等启发式方法的优势可能会在多轮交互中累积。一次更好的放置决策能够保留更多缓存并减少后续碎片化，使之后的调度状态不再持续恶化。

这一路线对工具调用密集、并发波动明显且 KV 缓存预算紧张的服务尤其有参考价值。不过，工具时长预测质量、节点异构程度以及不同服务目标之间的权衡，仍会影响 TAO 的实际收益。对于工程系统而言，如何把这类联合调度策略接入现有推理引擎，可能比单独实现一个评分函数更关键。

来源：Hugging Face Daily Papers