文章摘要
随着智能体强化学习发展，传统大模型后训练资源管理方案难适配新场景。研究团队推出Libra系统，从三个核心问题出发构建全局资源管理方案。该系统采用三层闭环设计，包括全局资源规划器、弹性混合池和因果驱动的多级反馈队列调度器。实验显示，Libra能提升吞吐、优化效率，为Agentic RL资源管理提供了核心启示。

随着智能体强化学习（Agentic RL）的快速发展，传统的大模型后训练资源管理方案已经难以适配新的场景。这类系统中，智能体在生成过程中会调用外部工具，形成“生成-工具调用-环境反馈-再生成”的交互轨迹，这给资源调度带来了全新的挑战。

传统方案的局限与新挑战

以往的大模型强化学习后训练，大多围绕加速rollout展开，但这种思路在Agentic RL中并不完全适用。与普通的单段文本生成不同，Agentic RL的轨迹长度由工具调用的结果决定，可能出现长尾情况：少量轨迹会因为大量工具返回、执行失败反复修复而占用绝大多数的计算资源，测试数据显示，最长的10%轨迹占据了超过50%的rollout时间。

同时，rollout和training两个阶段的资源需求差异巨大：rollout是自回归、显存和带宽敏感的过程，而training更偏向计算密集，可以通过批处理摊薄序列长度差异，而且轨迹分布还会随着策略更新持续漂移，静态的资源分配很难长期保持最优。

针对这些问题，研究团队推出了Libra系统，它的核心思路不是单独优化某个阶段，而是从三个核心问题出发构建全局资源管理方案：如何在固定GPU预算下分配training和rollout的资源？rollout集群内部应该采用怎样的异构并行配置？当瓶颈发生漂移时，如何在不暂停核心训练的情况下动态调整GPU资源？

为什么初始prompt无法决定轨迹长度

在普通的语言模型推理中，我们可以根据prompt特征预测输出长度，但在Agentic RL中，很多决定最终长度的信息在请求开始时并不存在。以代码智能体为例，工具调用的结果会直接影响后续轨迹：如果工具返回简短且执行成功，任务很快结束；如果返回大量日志，上下文会快速膨胀；如果执行失败，智能体可能会反复修改代码重试，甚至形成级联效应让轨迹接近最大长度。

研究显示，有的轨迹从1K的工具token扩展到8K，有的则从12.5K扩展到21K，极端情况下甚至可以达到40K以上。这意味着，在请求初始阶段预测最终长度存在天然局限，而工作负载的非平稳性进一步加剧了这个问题——训练过程中平均序列长度可能从2.5K增长到11.5K，让rollout逐渐成为系统瓶颈，静态资源切分无法适配动态变化的场景。

张量并行与序列长度的适配关系

张量并行（TP）的配置也需要根据序列长度调整：较小的TP通信开销更低，可以在短序列场景下部署更多并行实例；而较大的TP可以将模型权重和KV缓存分摊到更多GPU上，在长序列场景下更能缓解显存压力。

在8张A800、Qwen3-14B、batch size 512的测试中，短序列（0-2K token）下8个TP-1实例的吞吐达到1852 token/s，而单个TP-8实例只有591 token/s；长序列（16K-32K token）下，TP-1的吞吐下降到430 token/s，而TP-8仍能达到1220 token/s，是前者的2.8倍。因此，Libra没有采用统一的TP配置，而是将rollout集群拆分为多个bucket，由TP-1处理短序列，TP-2/4/8依次承接更长的请求。

Libra的整体架构：三层闭环设计

Libra面向分布式异步的Agentic RL流水线，整体分为三个相互配合的层次，共同实现端到端的最优效率。在异步RL pipeline中，端到端的迭代时间近似为max(T_rollout, T_train)，给training增加GPU会降低训练时间但挤压rollout资源，反之亦然，局部优化很容易将瓶颈从一侧推向另一侧，因此Libra直接最小化两者的最大值。

Global Resource Planner：分层规划缩小搜索空间

全局资源规划器负责决定training和rollout的GPU数量以及并行策略。直接枚举所有可能的组合会导致搜索空间爆炸，Libra采用分层规划的方式：

  • 对于稠密模型，训练策略由TP、PP、DP组成；对于MoE模型还需要考虑EP。
  • 规划器从分配给训练的GPU数量出发，逐层扩展候选并行策略，并剪去不可行的分支：TP的取值限制在单节点NVLink域内的1、2、4、8；当显存占用或通信计算比超出阈值时停止扩展；MoE的EP需要整除专家数量，并尽量将All-to-All操作留在节点内；当PP的流水线气泡超过阈值时进行剪枝；最后检查DP是否为合法整数。

这种方式将指数级的候选空间缩小到几十种可评估的配置。

对于rollout侧，规划器需要根据给定的rollout GPU数量和历史轨迹长度，决定部署多少个TP-1/2/4/8实例，以及每个实例负责的请求区间。Libra采用动态规划的方式，定义dp[g][i]为使用g张GPU处理前i个请求时的最小makespan，每次加入一个TP实例和一段连续的请求区间，通过代价评估器计算执行时间，选择最大完成时间最小的组合，自然形成“短请求进入小TP、长请求进入大TP”的异构划分，并且结果会被缓存供全局搜索复用。

代价评估器是规划器的核心接口，传统的推理和训练模拟器通常假设序列长度稳定，但Agentic RL的极端长度差异会打破这些假设。Libra的rollout代价模型根据算子的物理特征拟合：线性算子采用O(L)形式，Attention采用O(L²)形式；训练侧则显式模拟不同长度的micro-batch在流水线中的开始和结束时间，捕捉动态的micro-bubble。验证结果显示，rollout预测的平均绝对百分比误差为3.1%-5.9%，训练迭代时间的预测误差为2.4%-5.5%，在100个端到端配置的估计中，平均误差为6.35%，最大误差为9.30%。

Elastic Hybrid Pool：不中断核心训练的弹性切换

弹性混合池负责将规划器的决策转化为实际的worker动态切换，同时保证核心训练不会被打断。为了实现这一点，Libra将GPU分为三个部分：核心训练池、核心rollout池和弹性混合池。前两个部分提供稳定的容量，弹性混合池则根据瓶颈情况在training和rollout之间动态切换，还可以临时从核心rollout池借用worker作为弹性worker，应对短期的训练资源不足。

Libra的关键设计是保持核心训练的拓扑结构不变，弹性worker只以完整的、未切分的数据并行副本加入，不会重塑核心的TP/PP组。通信被分为两个域：副本内部使用稳定的NCCL集体通信，副本之间的梯度交换使用独立的侧通道，成员变化只影响这一通信域。当弹性worker从rollout切换回training时，它会异步拉取最新的模型和优化器快照，在状态恢复窗口中，核心worker继续训练，加入中的worker先发送零梯度占位，由于核心rank会将外部梯度累加到本地梯度，零占位不会改变本地值，核心的All-Reduce操作和新副本尚未加入的情况保持数学等价，状态对齐后，worker就可以开始发送真实梯度。这种非阻塞的加入方式避免了为了新增训练副本而暂停整个集群。

C-MLFQ Scheduler：基于工具返回的延迟绑定调度

因果驱动的多级反馈队列调度器不需要在请求开始时猜测最终长度，而是在每个工具返回点获取最新信息后进行延迟绑定。系统会根据历史轨迹构建前缀树，每个节点的键包含prompt ID和截至当前的工具返回状态序列，工具返回状态包括工具类型、负载大小类别和成功/失败状态，每个节点保存从当前位置到轨迹结束的剩余长度分布，比如均值和P90值。

C-MLFQ的运行流程如下： 1. Initial placement：所有请求都进入适合短上下文的小TP bucket，避免一开始就浪费大TP实例； 2. Per-tool-return routing：在工具执行期间，将KV缓存卸载到CPU，工具返回后查询前缀树； 3. Conservative migration：只有当均值和P90值都落入同一个bucket时才进行迁移，如果节点未见过，就回退到父节点的统计数据； 4. Offline update：轨迹完成后，沿着工具状态序列回溯并更新节点的剩余长度统计。

与预测模型相比，前缀树查询几乎没有在线计算成本；与传统的MLFQ相比，它不需要等到当前长度越界后逐级晋升，而是可以在工具返回时直接迁移到更合适的最终bucket。

关于KV缓存迁移的开销，Libra将迁移拆分为三步：工具执行期间将KV缓存放入CPU pinned memory，在CPU上按attention head重新分片，工具返回后由目标GPU加载对应的分片。同节点迁移在40K token时仍低于330ms，跨节点迁移最高为733ms。在跨节点场景下，系统会比较迁移和重新prefill的实际代价，选择更便宜的一种，而不是无条件搬运KV缓存。

实验验证：吞吐提升与效率优化

研究团队在6个节点、48张NVIDIA A800-SXM4-80GB GPU上进行了实验，节点内使用NVLink/NVSwitch，节点间使用200Gb/s RoCE并开启GPUDirect RDMA。训练采用GRPO方法，最大序列长度为40960 token，每个prompt采样16条轨迹，测试的模型包括Qwen3-14B和Qwen3-30B-A3B，工作负载涵盖多轮搜索与外部知识获取、竞赛级数学推理、真实代码仓库中的软件工程Agent。

基线方案包括colocated、静态均分、人工贪心启发式，以及使用初始workload找到最佳静态切分的AReaL-Static-Optimal。实验结果显示，与verl-Colocated相比，Libra在三项任务上的吞吐分别提升了约300%、196%和209%。由于所有方法都运行相同的训练步数并达到相近的最终奖励，wall-clock曲线表明，吞吐的提升确实转化为更短的time-to-reward，最高达到2.5倍的加速。

在相同的异构bucket配置下，C-MLFQ与其他四种策略相比表现更优，其迁移比例超过100%是因为同一批token可能随着请求逐级晋升而被重复迁移，而C-MLFQ更接近最优方案，同时避免了频繁的搬运开销。

消融实验：各模块的贡献

在R2E-Gym任务上的消融实验显示，基线Static-Uniform的吞吐为423 token/s： - 加入同构规划器后，吞吐提升到510 token/s，约增加20%； - 加入异构TP配置后，再增加41 token/s； - 加入C-MLFQ后，增加115 token/s，是最大的单项增益； - 加入静态到弹性的切换后，再增加97 token/s； - 完整的Libra系统达到763 token/s，比基线提升约80.4%。

开销实验也验证了周期性重配置的可行性：从training到rollout的主要成本是10.8秒的vLLM激活；从rollout到training包括3.6秒的后台快照和4.4秒的RDMA状态恢复，梯度通道注册与状态对齐约为数十毫秒。相对于R2E-Gym平均454.16秒的step time，总转换开销低于3.5%，而且只在规划器触发配置变化时发生。在128张GPU上，使用rollout memoization后，规划器的搜索时间从12.3秒降到1.9秒。

总结：Agentic RL的资源管理抽象

Libra为Agentic RL的资源管理提供了三点核心启示： 第一，rollout并非固定的瓶颈，端到端的速度由training和rollout中更慢的一侧决定，资源管理必须进行跨阶段的联合优化； 第二，Agent轨迹中的工具返回是可利用的因果信号，与其在请求开始时预测全部未来，不如在信息真正出现时进行延迟绑定，将请求导向合适的异构执行环境； 第三，弹性资源调度不应等同于重建整个训练系统，只要保持核心拓扑稳定，并将动态成员限制在独立的通信域中，资源切换就可以成为训练期间可以频繁使用的机制。

Libra的代码量约为1.3万行Python和C++/CUDA代码，基于verl、vLLM和Megatron-LM实现，目前仓库提供了Slurm与非Slurm的快速启动脚本、数据准备工具、配置参考、可观测性说明和实验脚本。

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