文章摘要
当前Agentic RL后训练使模型行动能力增强，但给训练系统带来复杂挑战。为此，香港高校团队推出Libra资源管理系统，将训练与rollout作为耦合系统统一优化。它有全局资源规划、弹性混合池、因果感知调度三种核心机制。实验显示，其在三类任务中均实现最高吞吐，达成目标奖励速度最高提升2.5倍，论文与代码已公开。

当前大语言模型的能力正从被动回答问题，转向主动完成复杂任务，而Agentic RL后训练正是支撑这一转变的关键技术之一。在这类训练流程中，模型不仅会生成文本，还会调用搜索、代码执行等外部工具，根据环境反馈持续推进推理。这种交互模式让模型拥有了更强的行动能力，但也给训练系统带来了比普通RLHF更复杂的挑战：同一批请求生成的轨迹长度可能相差数十倍，少量超长轨迹会拖慢整体的rollout流程；同时，训练和rollout对GPU的需求还会随着模型策略的演化不断变化。

针对这些痛点，来自两所香港高校的研究团队推出了Libra，一款专为Agentic RL后训练设计的资源管理系统。不同于传统方案将rollout视为固定瓶颈的思路，Libra将训练与rollout作为一个耦合系统进行统一优化，通过异构推理集群、因果感知调度和弹性资源切换三种核心机制，让有限的GPU资源能够随着实时工作负载动态调整分配。

在48张NVIDIA A800 GPU的集群上，Libra在Search-R1、DAPO-Math-17K和R2E-Gym三类任务中均实现了最高吞吐，最高达到基线方案的3.0倍；在最终奖励相近的前提下，达到目标奖励所需的时间最多缩短至基线的1/2.5。目前该研究的论文与开源代码均已公开。

标准的RL后训练迭代通常包含轨迹生成、轨迹评估和策略更新三个环节，由于评估阶段相对轻量，系统效率主要取决于两个核心环节：rollout生成轨迹的速度，以及训练吸收轨迹并更新策略的速度。

与传统推理中请求长度与输入提示强相关的情况不同，Agentic RL中的轨迹长度会被运行时事件显著改变：比如搜索工具可能返回大段内容，代码执行失败会触发多轮修复，模型也可能根据环境反馈扩展后续推理步骤，因此轨迹的最终长度在生成前很难可靠预测。

研究团队在R2E-Gym任务中观察到，最长的10%轨迹占据了超过50%的rollout时间。更关键的是，这种轨迹长度的分布并不稳定：随着模型策略在训练中逐渐演化，工具的使用方式和推理长度都会发生漂移。

这种漂移会进一步放大rollout与训练之间的结构性差异。实验数据显示，当序列长度从1K增长到32K token时，rollout的延迟增长了95倍，而训练时间仅增长3.9倍。这是因为rollout需要自回归解码，对序列长度和KV cache更为敏感；而训练则可以通过batching摊薄长度变化带来的影响。

这意味着，一个在训练初期合理的静态GPU切分，在数百步训练后就可能出现严重的资源失衡：如果rollout变慢，训练GPU会等待新的轨迹数据；如果训练变慢，rollout生成的轨迹又会在队列中积压。端到端的迭代时间实际上由两者中更慢的一方决定，公式可以表示为T_iter = max(T_rollout, T_train)。因此，单纯优化rollout环节无法解决根本问题，需要从全局视角动态寻找训练与rollout的资源平衡点。

全局资源规划：同步统筹训练与rollout的GPU分配

Libra的第一项核心设计是Global Resource Planner（全局资源规划器）。在固定的GPU预算下，该模块会联合搜索多个维度的最优配置：

  • 分配给训练和rollout的GPU数量比例；
  • 训练侧采用的TP、PP、DP以及MoE模型的EP组合策略；
  • rollout侧需要部署的不同TP等级（TP-1、TP-2、TP-4或TP-8）的推理实例数量；
  • 当前配置下的训练时间、rollout时间和最终迭代makespan。

训练侧会通过拓扑感知的决策树枚举可行的并行策略，并根据显存、通信开销和pipeline bubble等约束提前剪枝；rollout侧则会将请求按照历史长度排序，通过动态规划寻找异构TP实例与请求区间之间的最优分配。底层的Cost Evaluator会同时对两侧的执行时间进行建模，让规划器能够对比不同全局配置的优劣。

规划过程并非只在系统启动时运行一次。Libra会周期性读取最新的轨迹统计数据，重新求解资源配置；只有当预计的收益超过重配置成本时，才会真正触发资源的移动。这种设计既能追踪工作负载的漂移，也能避免频繁切换带来的系统抖动。

弹性混合池：无需重建核心通信组即可动态调整算力

仅仅计算出新的资源配置，并不等于能够低成本地执行这个配置。在传统的分布式训练中，添加或移除训练worker往往意味着需要重建通信组并重新分发模型状态，频繁的操作会带来极高的成本。

Libra将集群资源划分为三个独立的池：

  • Core Training Pool：保持固定的训练拓扑结构，避免频繁调整带来的开销；
  • Core Rollout Pool：承担稳定的异构轨迹生成任务；
  • Elastic Hybrid Pool：根据当前的系统瓶颈，在rollout与training模式之间动态切换。

该设计的核心原则是保持核心训练拓扑不变。Hybrid worker会以完整的数据并行副本的形式加入集群，不会改变核心的TP/PP结构。系统还会将副本内部的NCCL通信与副本之间的梯度交换解耦，让成员变化只发生在独立的跨副本通信域中。

当rollout worker重新加入训练环节时，它会异步获取最新的模型和优化器快照。在状态恢复的过程中，核心训练仍然可以正常推进；加入中的worker会通过侧通道发送零梯度占位，让核心的All-Reduce操作与该worker尚未加入时的数学结果保持等价。直到状态完全对齐后，该worker才会从下一步开始贡献真实的梯度。

因果感知调度：基于工具返回信号动态调整请求分配

Libra的第二项核心设计是C-MLFQ（Causality-Driven Multi-Level Feedback Queue）调度器。传统的长度预测方法通常会在请求开始时尝试猜测最终的轨迹长度，但Agentic RL中的关键变化往往发生在推理中途。

Libra的设计思路是：工具返回的大小、成功或失败状态并非普通的相关特征，而是后续轨迹扩展的直接因果信号。比如，大的payload会立刻增加上下文窗口，工具执行失败则可能触发重试、诊断和代码修改流程。

C-MLFQ会基于历史轨迹构建一棵因果感知前缀树，树节点由prompt ID和此前所有工具返回状态的有序序列确定，并保存从当前节点到轨迹结束的剩余长度分布。运行时的调度流程分为三步：

  1. 请求开始时，先进入适合短序列的小TP bucket；
  2. 每次工具返回后，根据工具类型、payload大小和执行状态查询前缀树；
  3. 只有当剩余长度的均值与P90分位数指向同一个bucket时，才会将请求迁移到对应的bucket，否则继续留在当前bucket；轨迹结束后再离线更新前缀树。

这种设计避免了额外的模型推理开销，也不需要随着策略变化反复训练长度预测器。与传统MLFQ需要等到长度越界后逐级迁移不同，C-MLFQ可以在工具返回后更早地做出一次性决策。在Search-R1任务上，C-MLFQ的单次路由准确率达到91.1%，明显高于基于embedding的长度预测方法（65.2%）和传统MLFQ（44.8%）；与此同时，其迁移的token比例仅为8.2%，系统吞吐达到2700 token/s。

48张A800上的端到端测试结果

研究团队在6个节点、共48张NVIDIA A800-SXM4-80GB GPU的集群上进行了实验。节点内部使用NVLink/NVSwitch连接，节点之间使用支持GPUDirect RDMA的200 Gb/s RoCE网络。实验采用GRPO训练框架，最大模型长度为40960 token，每个prompt会采样16条轨迹。

实验覆盖了三个差异显著的Agentic RL场景：

  • Search-R1：模型需要多轮生成搜索查询并利用外部知识完成任务；
  • R2E-Gym：软件工程Agent操作真实代码仓库并调用Bash、Python等工具；
  • DAPO-Math-17K：包含17K道竞赛级数学问题的数据集。

对比方案包括verl-Colocated、verl-Static-Uniform、verl-Greedy-Heuristic，以及基于初始workload选出最优静态配置的AReaL-Static-Optimal。

在Search-R1任务上，Libra的平均吞吐约为2700 token/s，相比AReaL-Static-Optimal提升约63%，相比verl-Greedy-Heuristic提升80%，相比verl-Colocated提升300%。在DAPO-Math-17K和R2E-Gym任务上，Libra同样保持了最高的吞吐效率。

由于所有对比方法都训练同一模型并执行相同的步数，最终达到的奖励水平相近，区别主要在于实际耗时。Libra在Search-R1、DAPO-Math-17K和R2E-Gym上分别用17.9、26.7和63.2小时完成训练，达到目标奖励的速度最高提升了2.5倍。

消融实验进一步验证了各模块的作用。在R2E-Gym任务上，Static-Uniform基线的吞吐为423 token/s；加入同构资源规划后提升到510 token/s，异构TP配置再带来41 token/s的提升，C-MLFQ增加115 token/s，最终弹性执行模块继续增加97 token/s，完整的Libra系统最终达到763 token/s，整体相比基线提升约80.4%。

系统实现与开源情况

Libra整体包含约1.3万行Python和C++/CUDA代码，核心的RL训练循环基于verl框架，生成侧使用vLLM，训练侧使用Megatron-LM。开源仓库提供了Slurm与非Slurm环境下的快速启动脚本、数据准备工具、配置参考、可观测性说明以及完整的实验脚本。

Libra的核心观点在于：在Agentic RL训练流程中，rollout并非永恒不变的系统瓶颈。随着模型策略和轨迹分布的演化，真正的资源瓶颈会在训练与rollout之间动态移动。只有同时解决跨阶段的资源分配、阶段内部的异构执行以及低成本的资源切换问题，系统才能在长期训练过程中持续接近最优的资源利用状态。

以上内容不代表本平台立场，仅供读者参考