Agentic RL 后训练资源怎么分？港中文、恒生大学提出 Libra，吞吐最高提升 3 倍

大语言模型正在从 “回答问题” 走向 “完成任务”。在 Agentic RL 后训练中，模型不仅生成文本，还会调用搜索、代码执行等外部工具，根据环境返回继续推理。这样的交互让模型拥有更强的行动能力，也让训练系统面对一种比普通 RLHF 更不稳定的工作负载：同一批请求可能产生长度相差数十倍的轨迹，少量超长轨迹拖慢整个 rollout；与此同时，训练和 rollout 对 GPU 的需求还会随着策略演化不断变化。 针对上述问题，来自香港中文大学和香港恒生大学的研究团队提出了 Li bra ，一个面向 Agentic RL Post-Training 的资源管理系统。Libra 不再把 rollout 视作固定瓶颈，而是将训练与 rollout 作为一个耦合系统统一优化，并通过 异构推理集群、因果感知调度和弹性资源切换 ，让有限 GPU 资源随着实时工作负载动态流动。 在 48 张 NVIDIA A800 GPU 上，Libra 在 Search-R1、DAPO-Math-17K 和 R2E-Gym 三类任务中均取得最高吞吐，最高达到基线的 3.0 倍 ；在相近最终奖励下，达到目标奖励所需时间最多缩短至基线的 1/2.5 。目前论文与代码均已公开。 论文标题：Libra: Efficient Resource Management for Agentic RL Post-Training 论文链接：https://arxiv.org/abs/2606.03077 开源代码: https://github.com/NetX-lab/Libra 图 1：Libra 系统总览。系统由全局资源规划器、异构 rollout 集群、C-MLFQ 调度器和弹性执行机制组成。图片来源：论文。 Agentic RL 带来的不只是 “更长的输出” 一个标准 RL 后训练迭代通常包含轨迹生成、轨迹评估和策略更新。由于评估阶段相对轻量，系统效率主要取决于两个环节：rollout 能多快地产生轨迹，以及 training 能多快地吸收这些轨迹并更新策略。 在传统推理中，请求长度通常与输入提示具有较强相关性；但在 Agentic RL 中，轨迹长度会被运行时事件改变。例如，搜索工具可能返回大段内容，代码执行可能失败并触发多轮修复，模型也可能根据环境反馈扩展后续推理。因此，轨迹最终长度在生成前很难可靠预测。 研究团队在 R2E-Gym 上观察到，最长的 10% 轨迹占据了超过 50% 的 rollout 时间。更重要的是，这种分布并不稳定：随着策略在训练中逐渐改变，模型的工具使用方式和推理长度也会发生漂移。 这种漂移会放大 rollout 与 training 的结构性差异。实验显示，当序列长度从 1K 增长到 32K token 时，rollout 延迟增长了 95 倍，而训练时间仅增长 3.9 倍。原因在于 rollout 需要自回归解码，对序列长度和 KV cache 更敏感；训练则可以通过 batching 摊薄长度变化带来的影响。 图 2：（a）随着序列变长，rollout 延迟增长远快于训练；（b）训练过程中，平均序列长度和 rollout 时间持续漂移。图片来源：论文。 这意味着， 一个在训练初期合理的静态 GPU 切分，可能在数百步之后变得严重失衡 。如果 rollout 变慢，训练 GPU 会等待新数据；如果训练变慢，rollout 产生的轨迹又会在队列中积压。端到端迭代时间实际上由二者中更慢的一方决定： T_iter = max (T_rollout, T_train) 因此，问题不能只靠 “继续优化 rollout” 解决，而需要 从全局视角动态寻找训练与 rollout 的平衡点。 全局资源规划：同时决定训练和 rollout 怎么用 GPU Libra 的第一项核心设计是 Global Resource Planner（全局资源规划器） 。在固定 GPU 预算下，它联合搜索： 多少 GPU 分配给训练，多少分配给 rollout； 训练侧采用怎样的 TP、PP、DP，以及 MoE 模型的 EP 组合； rollout 侧应当部署多少个 TP-1、TP-2、TP-4 或 TP-8 推理实例； 当前配置的训练时间、rollout 时间和最终迭代 makespan。 训练侧使用拓扑感知的决策树枚举可行并行策略，并根据显存、通信开销和 pipeline bubble 等约束提前剪枝。rollout 侧则把请求按历史长度排序，用动态规划寻找异构 TP 实例和请求区间之间的最优分配。底层 Cost Evaluator 同时建模两侧的执行时间，让规划器能够比较不同全局配置。 规划并不是只在启动时运行一次。Libra 会周期性读取最新轨迹统计，重新求解资源配置；只有当预计收益超过重配置成本时，才真正触发资源移动。这样既能追踪 workload drift，也能避免频繁切换带来的抖动。 Elastic Hybrid Pool：不重建核心通信组，也能移动算力 “算出新配置” 并不等于 “能够低成本执行新配置”。传统分布式训练中，加入或移除训练 worker 往往意味着重建通信组并重新分发状态，频繁操作代价过高。 Libra 将资源划分为三个池： Core Training Pool：保持固定的训练拓扑； Core Rollout Pool：承担稳定的异构轨迹生成； Elastic Hybrid Pool：根据瓶颈在 rollout 与 training 模式间切换。 其关键原则是保持核心训练拓扑不变。 Hybrid worker 以完整的数据并行副本形式加入，不改变核心 TP/PP 结构 。系统进一步把副本内部的 NCCL 通信与副本之间的梯度交换解耦，成员变化只发生在独立的跨副本通信域。 当 rollout worker 重新加入训练时，它会异步获取最新模型和优化器快照。恢复期间，核心训练仍然继续推进；加入中的 worker 通过侧通道发送零梯度占位，使核心 All-Reduce 与 “该 worker 尚未加入” 时在数学上保持等价。状态对齐后，它再从下一步开始贡献真实梯度。 不预测最终长度，而在工具返回时做因果路由 Libra 的第二项核心设计是 C-MLFQ（Causality-Driven Multi-Level Feedback Queue） 。 传统长度预测方法试图在请求开始时猜测最终长度，但 Agentic RL 的关键变化往往发生在中途。Libra 的观察是：工具返回大小、成功或失败状态并非普通相关特征，而是后续轨迹扩展的直接因果信号。例如，大 payload 会立刻增加上下文，工具失败则可能触发重试、诊断和代码修改。 C-MLFQ 用历史轨迹建立一棵因果感知前缀树。树节点由 prompt ID 和此前所有工具返回状态的有序序列确定，并保存从当前节点到轨迹结束的剩余长度分布。运行时流程分为三步： 请求开始时先进入适合短序列的小 TP bucket； 每次工具返回后，根据工具类型、payload 大小和执行状态查询前缀树； 只有当剩余长度的均值与 P90 指向同一 bucket 时才迁移，否则继续留在