Agentic RL 的 80% 算力浪费问题，北京大学用「以轨迹为中心」的思路重写了调度系统

> 论文：Heddle: A Distributed Orchestration System for Agentic RL Rollout > 作者：Yinmin Zhong, Jiaming Liu 等（北京大学，字节跳动） > arXiv: 2603.28101 > 代码：论文未提供独立开源仓库，但基于 Verl + SGLang + Ray 实现

---

一个让人坐不住的数字：80%

如果你做过 Agentic RL 训练——让 LLM 智能体在环境中多步交互、调用工具、收集轨迹做强化学习——你大概率遇到过这样一个场景：

集群跑得好好的，突然所有 GPU 一起闲下来。不是挂了，是在等。等那条最长的轨迹跑完。

北京大学和字节跳动的团队量化了这个现象：在 Agentic RL 训练中，rollout 阶段消耗了整个训练流程 80% 以上的时间。不是训练慢，是收集数据慢。不是数据收集本身慢，是数据收集里的"长尾轨迹"拖死了所有人。

这个数字让我坐不住了。80% 的算力浪费在等待上，这意味着你花在 H100 上的钱，有八成是在为空转买单。

长尾是怎么产生的

理解问题之前，先看一个事实：Agentic RL 的轨迹长度分布是严重长尾的。

论文给了一张图：在一个编程 Agent 任务（CodeForces 数据集）上，轨迹的完成时间分布极度偏斜。中位数轨迹可能几十秒就跑完了，但最慢的那条轨迹——可能因为反复 debug、反复调用沙箱、反复修正代码——要花中位数 4 倍以上的时间。

这和传统 LLM 训练完全不同。传统训练喂的是静态数据，每条样本长度可控、可预测。Agentic RL 的轨迹是 Agent 在环境中实时交互生成的，长度由任务难度、工具反馈、Agent 策略共同决定——你事先不知道哪条轨迹会长。

更糟的是，在 GRPO 等 RL 算法里，一个 prompt 要采样 16 条轨迹做 advantage 估计。温度 1.0 的采样意味着：同一个 prompt 的 16 条轨迹，长度可能差 10 倍。一条通过了测试用例就结束，另一条反复失败、反复修正、反复调用工具，最后拖成超级长尾。

在同步框架里，所有轨迹必须等最慢的那条跑完才能进入下一轮训练。 这就是 80% 浪费的根源——不是 GPU 不够快，是 GPU 在等那条最慢的轨迹。

旧范式：以「步」为中心

现有的 Agentic RL 框架（Verl、Slime、SGLang-router）是怎么处理这个问题的？

答案是：没有处理。

这些系统继承自传统 LLM serving 的设计——以"步"（step）为调度单位。Agent 每调用一次 LLM 生成，就是一个独立的推理请求。系统把这个请求扔给某个 worker，worker 生成完返回结果，Agent 拿到结果调用工具，工具返回后再发起下一个 LLM 请求。

每一步都是独立调度的，系统不知道这条轨迹从哪来、到哪去、还要走多远。

这导致三个致命问题：

1. 队列延迟（T_queue）：长尾轨迹每一步都要重新排队。在 round-robin 调度下，它和那些只需要 2-3 步就结束的短轨迹抢同一个队列位置。结果是长尾轨迹反复排队、反复等待，累计延迟巨大。

2. 干扰开销（Interference）：长尾轨迹和短轨迹被混在同一个 worker 上执行。长尾轨迹的 batch 很大，挤压了短轨迹的算力，导致短轨迹也变慢。这是 GPU 资源争用的经典问题。

3. 单 token 时间膨胀（T_base）：所有 worker 用同构配置（比如都是 MP=1 或都是 MP=8）。MP=1 吞吐量高但长尾轨迹的 per-token 时间长；MP=8 per-token 时间短但吞吐量低。你只能选一个，怎么选都是错。

Heddle 的思路：以「轨迹」为中心

Heddle 的核心创新是视角的转换：从"以步为中心"转向"以轨迹为中心"的全局管理。

这不是一个调参优化，而是一个系统架构的重新设计。Heddle 把三个原本独立的决策——何时调度（when）、放在哪里（where）、用多少资源（how）——统一到轨迹级别来优化。

1. 何时调度：渐进式优先级调度

Heddle 的第一个机制解决队列延迟问题。

传统调度器要么用 FCFS（先来先服务），要么用 Round-Robin（轮转），要么用 SJF（最短作业优先）。这些策略都有一个问题：它们需要事先知道轨迹长度。但在 Agentic RL 里，你事先不知道。

Heddle 的做法是：渐进式预测 + 动态优先级。

它训练了一个轻量级预测模型，在轨迹执行过程中持续更新长度估计。第一步之后预测一次，第二步之后再修正一次。随着轨迹展开，预测越来越准。

基于这个预测，Heddle 给长尾轨迹更高的优先级——让它们跳过队列，直接执行。这和 SJF 相反：SJF 优先短作业，Heddle 优先长作业。为什么？因为短作业即使排队也很快完成，长作业排队就是灾难。

实验显示，这个调度策略将端到端 rollout 时间降低了 1.1-1.26 倍。关键收益来自队列延迟的减少——长尾轨迹不再反复排队。

2. 放在哪里：轨迹感知物理隔离

第二个机制解决干扰开销。

传统放置策略要么是 cache-affinity（把同一条轨迹固定在一个 worker 上，保持 KV cache），要么是 least-load（把请求发给最闲的 worker）。前者导致负载不均（长尾轨迹全堆在一个 worker 上），后者导致 cache 频繁失效（每步换 worker，KV cache 全废）。

Heddle 的做法是：预排序动态规划 + 运行时迁移。

预排序动态规划：Heddle 先按预测长度把所有轨迹排序，然后用动态规划算法找到一个最优分组——把轨迹分配到 m 个 worker 上，使得每个 worker 的"最长轨迹 × 干扰因子"尽可能均衡。

这里有一个漂亮的数学洞察：存在一个最优解，使得每个组是排好序的轨迹列表的一个连续子序列（Lemma 5.0）。这个引理把搜索空间从 Stirling 数 S(n,m)（组合爆炸）压缩到了 C(n-1, m-1)（多项式可解）。配合动态规划算法，复杂度降到 O(n²m)，对于 n=6400、m=16 的规模，42 毫秒就能算完。

运行时迁移：预测有误差，初始放置可能不对。Heddle 在轨迹执行过程中，如果发现预测长度有重大更新，就把这条轨迹的 KV cache 通过 GPU-Direct RDMA 迁移到更合适的 worker 上。

关键工程细节：迁移在工具调用间隔进行。Agent 调用工具时 GPU 是闲的，Heddle 利用这个空闲窗口异步传输 KV cache，不阻塞关键路径。这是一个很漂亮的"隐藏开销"设计。

3. 用多少资源：轨迹自适应资源管理

第三个机制解决 per-token 时间膨胀。

传统系统所有 worker 用同构配置。Heddle 提出异构配置：给长尾轨迹分配高模型并行度（低 per-token 时间），给短轨迹分配低模型并行度（高吞吐量）。

这是一个经典的 trade-off：MP=1 的 worker 吞吐量高但每 token 慢，MP=8 的 worker 每 token 快但吞吐量低。Heddle 同时部署两种 worker，长尾轨迹路由到高 MP worker，短轨迹路由到低 MP worker。

GPU 预算怎么分？Heddle 用排序初始化的模拟退火算法来搜索最优分配。初始化时随机采样一组 MP 配置，排序后和轨迹分组对齐（长轨迹配高 MP）。然后用模拟退火搜索——每次随机扰动（redistribute/split/merge），如果 makespan 变小就接受，如果变大也以一定概率接受（跳出局部最优）。

这个搜索过程的评估函数是 presorted DP 算法——每次扰动都要跑一次 DP 来计算 makespan。一次 DP 42 毫秒，模拟退火跑几百次迭代，总开销约 5 秒。但这个 5 秒是周期性执行的，可以摊到多轮训练上，影响可忽略。

实验结果：2.5 倍吞吐量

Heddle 在 64 块 Hopper GPU（8 节点 × 8 GPU）的集群上做了全面评估。

三个任务领域：编程 Agent（CodeForces）、搜索 Agent（HotpotQA）、数学 Agent（DAPO-Math）。

三个模型规模：Qwen3-8B、14B、32B。

对比基线：Verl、Verl*（Verl + SGLang-router 混合策略）、Slime。

结果：

对比	Heddle 的加速比
vs Verl	1.4× – 2.3×
vs Verl*	1.1× – 2.4×
vs Slime	1.2× – 2.5×

最高 2.5 倍吞吐量提升。而且模型越大，提升越明显——因为大模型的计算和内存争用更严重，长尾轨迹的干扰因子更高，Heddle 的轨迹感知放置收益更大。

消融实验：每个组件的贡献

• 调度器：1.1-1.26× 加速，主要来自队列延迟减少
• 放置策略：1.2-1.5× 加速，超过 cache-aware 和 least-load 基线
• 资源管理器：1.1-1.3× 加速，超过 Fix-1（吞吐优化）和 Fix-8（延迟优化）

三个组件叠加，效果是乘性的。这就是"以轨迹为中心"的系统性优势——每个组件都在解决同一个问题的不同维度。

工程细节：几个值得学习的做法

1. Rust 实现的 Agentic Trajectory Router

Heddle 的路由器用 Rust 写，维护轨迹元数据（放置分配、预测长度、预排序排名）。为什么用 Rust？因为路由器在关键路径上，每一步都要查它，延迟必须控制在微秒级。Python 做不到，Rust 可以。

2. 工具调用间隔的异步迁移

这是全文最漂亮的工程细节。Agent 调用工具时，worker 的 GPU 是空闲的。Heddle 利用这个窗口做 KV cache 迁移——把轨迹的 prefix cache 通过 RDMA 传到目标 worker。工具调用结束、Agent 回来要生成下一步时，迁移已经完成了，GPU 直接在新 worker 上继续。

这等于"免费"完成了迁移——没有额外开销，因为迁移发生在本来就会空闲的时间窗口里。

3. 干扰因子的 profiler-based 模拟

干扰因子 F 没有解析表达式，Heddle 用 profiler 采样不同 batch size 下的 per-token 时间，然后模拟一组轨迹并发执行时的干扰。这是一个务实的选择——不追求理论最优，追求工程可用。

4. 短轨迹聚合加速

预排序 DP 的复杂度是 O(n²m)，n=6400 时还是有点慢。Heddle 把长度低于某个阈值的短轨迹聚合成一个"超级轨迹"，减少有效输入规模。这对长尾轨迹的放置决策没有影响（短轨迹怎么放都无所谓），但显著加速了算法。

和其他技术的正交性

论文在 Discussion 部分讨论了 Heddle 和其他三个技术的关系，这个讨论很有价值：

异步 RL：异步 RL 通过 partial rollout 提高吞吐，但需要 staleness 阈值防止梯度偏差。Heddle 可以和异步 RL 无缝集成——加速长尾轨迹不引入额外的 policy divergence。

PD Disaggregation：Prefill-Decode 分离在 prefill 和 decode 阶段之间用不同 MP，但每个阶段内部还是同构的。Heddle 可以在 prefill 阶段内部进一步做异构分配——给长尾轨迹更高的 MP。

Speculative Decoding：投机解码用小模型生成候选 token、大模型并行验证。但在 prefill-heavy 的 Agentic RL 任务里（短生成、频繁工具调用），SD 效果不好。Heddle 优化 prefill 阶段，和 SD 正交，可以叠加使用。

这种"和现有技术正交"的特性，说明 Heddle 的设计是系统层面的增量创新，不是和现有框架竞争，而是可以叠加在现有框架之上。

我的思考：从「步」到「轨迹」的范式转换

这篇论文让我想到一个更广的趋势：LLM 系统设计的颗粒度正在从"单次推理"细化到"完整交互"。

传统 LLM serving 优化的是单次推理的吞吐和延迟——batch size、KV cache、模型并行度，都是围绕"一次生成"来设计的。

但 Agentic RL 不是一次生成，是一条由多次生成、多次工具调用、多次环境交互组成的轨迹。如果你还用"单次推理"的颗粒度来优化，你永远在局部最优里打转——每一步都很快，但整条轨迹很慢。

Heddle 的贡献是把优化颗粒度提升到轨迹级别。这不是一个技术细节，而是一个范式选择：

• 调度：从"下一步给谁"变成"这条轨迹怎么安排"
• 放置：从"这个请求放哪"变成"这条轨迹放哪"
• 资源：从"所有 worker 一样"变成"不同轨迹配不同资源"

每个维度都是同一个思想的实例化：以轨迹为单位思考。

这和 CodeRescue（我之前写过的编码 Agent 恢复路由论文）有结构上的相似性——CodeRescue 也是把决策从"单次失败"提升到"恢复动作"级别。两篇论文不约而同地指向同一个方向：在 Agent 时代，系统的优化单位必须从"调用"升级到"轨迹"。

更深一层：这可能是 Agent 系统设计的一个普遍原则。Agent 的行为不是离散的调用，而是连续的轨迹。你优化什么颗粒度，就决定了你能看到什么问题。以"步"为中心，你看到的是队列延迟和 cache 命中率；以"轨迹"为中心，你看到的是长尾效应和资源异构性。前者是战术，后者是战略。

Heddle 给我们的启示不是"长尾轨迹要优先"这个具体结论，而是"你优化系统的颗粒度，应该和你被优化的对象的颗粒度一致"。Agent 是轨迹级别的实体，那系统设计也应该是轨迹级别的。这个思想可以推广到 Agent 系统的方方面面——监控、调试、评估、计费，都应该以轨迹为单位，而不是以调用为单位。

局限性

论文也诚实地承认了一些局限：

1. 预测器依赖运行时上下文：第一步预测精度有限，Heddle-1 的 recall 比 Heddle-2 差不少。这意味着在轨迹早期，调度决策可能不准。 2. 干扰因子是经验建模：F 函数没有解析表达式，依赖 profiler 采样。不同硬件、不同模型可能需要重新 profiling。 3. 异构资源管理用模拟退火：不保证全局最优，只保证近优。5 秒的开销虽然可摊销，但对实时性要求极高的场景可能还是太慢。 4. 只评估了 64 GPU 规模：更大规模（几百上千 GPU）的行为未知。O(n²m) 的 DP 在 n=6400 时 42ms，如果 n=64000 呢？

这些局限不致命，但它们指向了 Heddle 的适用边界：中大规模 Agentic RL 训练，轨迹长度分布严重长尾，硬件支持 RDMA 迁移。在这个范围内，Heddle 的收益是实打实的。

结语

Agentic RL 是当前 AI 系统最前沿的训练范式之一。Claude Code、Deep Research、OpenClaw 这些产品的背后，都是 Agentic RL 在驱动 LLM 学会多步推理和工具使用。

但这个范式的训练效率问题一直没被系统性地解决。Heddle 的贡献不是发明了一个新算法，而是识别出了问题的本质——长尾轨迹——并从系统架构层面给出了一个完整的解法。

80% 的算力浪费，不是一个可以靠调参解决的问题。它需要你重新思考调度的颗粒度、放置的策略、资源的分配。Heddle 做了这个重新思考，并且用 2.5 倍的吞吐量提升证明了它的价值。

下次你在训练 Agentic RL 的时候，如果发现 GPU 利用率上不去，先看看你的轨迹长度分布。如果它是长尾的——它大概率是——那你需要的不是更多 GPU，而是一个以轨迹为中心的调度系统。

---

论文链接：https://arxiv.org/abs/2603.28101 基线框架：Verl | Slime | SGLang

---

*当你发现 GPU 在等，先问：它们在等什么？答案大概率是——一条长尾轨迹。*