Agentic RL 后训练最近是 LLM 对齐和智能体训练里绕不开的话题。港中文、恒生大学提出的 Libra核心就是把后训练阶段的计算资源分配从“拍脑袋”变成可调度、可观测、可复现的方法按项目材料里的说法吞吐最高能提升 3 倍。如果你手头有 GPU 集群正在跑 PPO、GRPO 这类依赖 rollout 的强化学习训练或者被“GPU 利用率忽高忽低、任务发下去不知道给多少资源、训练速度上不去”这些事卡过下面这些内容值得看完。先说结论Libra 不是又一个新的基座模型而是一种 Agentic RL 后训练资源配置方案。它真正要回答的问题是同一批卡、同一份显存、同一个训练周期里怎么分给策略采样rollout 生成和策略更新policy update才能让训练又快又稳。下面按实际落地顺序拆开讲先讲清楚瓶颈再讲怎么操作最后给排查链路。1. 先搞清楚Agentic RL 后训练的资源瓶颈到底在哪1.1 一条训练链路里谁在抢资源Agentic RL 后训练通俗说就是把已经完成预训练和指令微调的模型放到一个带工具调用、多步推理、环境交互的任务环境里用强化学习继续训练让模型学会自己规划、自己尝试、根据反馈修正行为。这个阶段和普通 SFT 最大的区别是SFT 只需要一次前向和一次反向而强化学习后训练要反复执行“采样、评估、更新”三个动作。采样需要把当前模型部署成推理服务生成大量轨迹评估需要给每条轨迹打分可能是规则奖励也可能是另一个模型做评判更新则需要把采样得到的轨迹重新算梯度回传给策略模型。资源就在这里被分成了三块rollout 推理资源负责生成轨迹吃的是 GPU 算力和显存要求低延迟、高吞吐。reward 评估资源负责给轨迹打分通常消耗较小但长轨迹场景容易成为瓶颈。策略更新资源负责反向传播和参数更新吃显存和大 batch要求稳定、可同步。这三块不是独立的。rollout 产出的轨迹不够更新阶段就空等更新阶段占太多资源rollout 生成速度又跟不上。很多团队跑 Agentic RL 后训练第一反应是“卡不够”但实际看 nvidia-smi往往是同一批卡里某几块跑满、另外几块闲着。1.2 资源分配不是越大越好而是平衡问题我把这个现象叫“资源分配的跷跷板效应”。给 rollout 分配太多 GPU轨迹生成是快了但轨迹缓冲区和奖励评估跟不上生成出来的样本在队列里堆积更新的参数还是旧的样本新鲜度下降。给更新分配太多资源策略更新快了但 rollout 端变成瓶颈GPU 出现周期性空闲整体训练时长被拉长。Libra 这类方案解决的问题就是在这一组矛盾里找到接近最优的分割点。项目名称里的 Libra 本身就有“平衡”的含义这基本能看出它想做的事情不是无脑加资源而是把采样、评估、更新之间的资源比例调到合理区间让整条链路的吞吐尽量接近流水线瓶颈的上限。这个判断在资源受限任务里特别明显。很多小团队用几台机器跑 Agentic RL最后训练卡住不是模型出了问题也不是奖励函数写错而是 rollout 和 update 的资源比例从一开始就没算过。所以后训练资源分配这件事并不是显存越大、显卡越多就一定能跑得动先弄清楚链路里谁在等谁比盲目加卡更重要。2. Libra 在做什么把吞吐提升当作结果而不是口号2.1 最值得关注的三个可调节点既然要谈资源分配就得先明确能调什么。从“吞吐最高提升 3 倍”这个结果倒推Libra 这一类方案大概率是通过下面三类调度参数来起作用采样与更新的资源切分比例。也就是配置里常见的 actor 节点数和 learner 节点数之比或者推理实例和训练实例的 GPU 数量之比。组大小和批量大小。Agentic RL 里每个问题通常要采样多个候选轨迹这个数目直接影响显存占用和样本多样性。调度优先级和排队策略。多任务同时并发时谁先跑、谁排队、能不能在空闲时把资源临时补给瓶颈侧决定了整体吞吐而不是单任务速度。这三类参数在普通 RL 后训练框架里也存在但大多数框架默认让你手动指定一个固定值不会在训练过程中动态调整。Libra 的核心思路应该是把这套分配从“静态配置”变成“动态调节”让空闲资源能临时补位。2.2 “吞吐提升 3 倍”应该怎么理解看到 3 倍这个数字先别急着归档到性能神话。吞吐不等于训练效果也不等于所有环境都能复现。按我的理解这个数字更合理的解读是在相同硬件规模、相同任务难度的条件下通过更合理的资源分配单位时间内能完成的 rollout 样本数或训练步数最多可以到原来的 3 倍。这里最容易踩的坑是把“吞吐最高提升 3 倍”当成“训练速度一定提升 3 倍”。吞吐提升只是速度提升的一个必要条件如果资源分配调到极端比如把大部分卡都拿去生成轨迹吞吐可能很高但模型根本不收敛那这个吞吐没有意义。实际评估时一定要同时看三个东西吞吐、收敛性和稳定性。项目材料里没有给出 3 倍数字的完整复现条件所以落地时不要直接拿这个数字当验收标准。先在自己的任务、自己的模型规模上跑基线再对比优化前后的差距才是更稳的做法。2.3 和常规后训练框架的差异常规框架里资源分配通常发生在“任务提交”这一步。你写一个训练脚本指定 actor_count8、learner_count4然后整个训练过程就按这个比例运行。问题在于训练过程中某个阶段的 rollout 变长、另一个阶段轨迹变短固定比例并不始终最优。Libra 这类调度方案强调的是训练过程中的再平衡。它把资源切分做成一个可观测、可调度、可动态变化的过程。这个思路听起来不复杂但落地时涉及到资源调度器、训练框架、推理服务之间的联动任何一个环节没打通动态分配就只是一句口号。所以你在实际使用时先别急着追求动态调度。先把静态分配调明白理解瓶颈在哪再考虑要不要上动态方案。等于是先学走再学跑。3. 跑通之前先盘点环境、依赖和可量化指标3.1 硬件和软件条件不管用 Libra 还是先用普通 RL 后训练框架做基线第一步都是盘点环境。按我的习惯清单至少包含GPU 型号和数量。实际可用显存比标称显存更有参考价值。显存分配模型参数量、激活值、rollout 缓存、优化器状态各占多少。CPU 和内存轨迹处理和奖励评估通常在 CPU 上做一部分内存不够会拖慢 rollout。存储和网络共享文件系统或分布式存储的读写速度决定 checkpoint 和大批量轨迹写盘的速度。软件栈训练框架版本、分布式通信库版本、推理服务版本。这里最容易出现依赖版本不一致导致的隐性卡顿。原始材料没有给出 Libra 的具体依赖清单所以落地时一定要先确认它依赖的训练框架和调度器版本再按官方文档配对安装。不要一上来就装最新版也不要把所有依赖都升级到最新很多时候版本回退反而更稳。3.2 必须先记录的四类指标调资源分配之前先把基线指标记全。没有基线后面所有对比都是空的。第一类是吞吐指标每秒生成的 rollout 步数step/s、每分钟完成的轨迹条数trajectory/min、每秒处理 sample 数。第二类是资源占用指标每张卡的显存峰值、GPU 利用率、显存利用率、CPU 占用、网络吞吐。我一般会每 10 秒采集一次训练结束再汇总。第三类是队列指标rollout 缓冲区积压了多少条轨迹、评估队列长度、更新等待时间。这些数据能直接告诉你瓶颈在哪一侧。第四类是训练质量指标loss 曲线、reward 均值、样本多样性、任务成功率。没有质量指标你无法判断资源分配是让训练变快了还是变差了。3.3 给资源分配建立基线建立基线动作很简单先用默认配置完整跑一个小任务记录上面四类指标。任务要选得足够小小到一个小时内能出结果但又要保留 Agentic RL 的核心特征比如多轮交互、工具调用、奖励稀疏。我建议用一组固定 seed 跑三遍确保基线本身可重复。如果同一份配置三次结果差异很大说明你的环境本身不稳定先解决环境问题再谈资源优化。基线稳定之后后面每一次参数调整才有可比性。4. 从单任务开始最小可复现的资源配置流程4.1 第一步跑一次全默认配置资源分配优化不要从零开始发明先跑一次全默认。常见的 RL 后训练框架在默认配置里已经给了一套相对平衡的初始值虽然不一定最优但能作为参照。以代码生成智能体的 RL 后训练为例训练脚本里通常有类似这样一段配置# 示例RL 后训练资源配置伪配置具体字段以实际框架为准 rollout: actor_count: 8 # 负责生成轨迹的 GPU 数量 per_sample_rollout_count: 4 # 每个问题采样多少条轨迹即 group size learner: learner_count: 4 # 负责策略更新的 GPU 数量 batch_size: 32 learning_rate: 1.0e-6 buffer: max_queue_size: 200 # rollout 缓冲队列上限 scheduler: enable_dynamic: false # 是否开启动态分配这里每个字段都不是随便填的。actor_count 和 learner_count 的比例决定两条链路谁快谁慢per_sample_rollout_count 决定单条问题带来的显存和样本量max_queue_size 决定 rollout 被阻塞时能缓冲多少数据。4.2 第二步拆 rollout 和 update 的吞吐占比跑完默认配置后从日志里找两个数字rollout 的每秒步数和 learner 每秒消耗的 sample 数。把两个数字放在一起看基本就能判断瓶颈。如果 rollout 步数远大于 learner 消费速度说明样本生成太多、更新来不及资源应该从 rollout 挪给 learner如果 learner 经常空等说明 rollout 供给不足资源应该反向分配。我在实测时更关注一个比例learner 的空闲时间占比。这个数字如果超过 20%基本可以判定 rollout 是短板。需要注意的是采样这个比例不能只看单个时间点要看一个完整训练周期的平均值因为训练不同阶段的速度差异很大。4.3 第三步按比例调整资源并验证明确了瓶颈之后就做一次小幅调整。比如把 actor_count 从 8 调到 12learner_count 从 4 调到 3或者保持 GPU 数量不变只调整 group size 和 batch size。每次只改一个变量跑完一轮对比基线的四类指标判断是变好还是变坏。不要一次同时调三个参数否则出了问题根本定位不到是谁引起的。成功调整的标准是整轮训练耗时下降。GPU 利用率的波动变小周期性空档减少。reward 曲线和基线相比没有明显变差。如果三个条件只满足前两个第三个不满足说明吞吐是靠牺牲训练质量换来的不算成功。4.4 参数参考表下面这张表是我做资源分配实验时常用的参数和判断口径可以当成模板。具体值要以你的模型规模和任务难度为准不能照搬。参数含义初始建议调整方向actor_count / learner_countrollout 和 update 的 GPU 数比例2:1 起步learner 空等就加大 actor缓冲区积压就加大 learnerper_sample_rollout_count每个样本生成的轨迹条数4 到 8显存不足就降低多样性不足就提高learner batch_size每次更新用的样本数16 到 64吞吐高但 loss 震荡就降低max_queue_sizerollout 缓冲队列长度100 到 200队列长期满说明更新慢队列长期空说明 rollout 慢采样间隔rollout 和 update 的交替频率按框架默认间隔过长样本新鲜度下降过短同步开销上升这套流程的核心思想是每次只动一个参数观察结果后再决定下一步。资源分配不是一个一次性配好的动作而是一个持续校准的过程。5. 多任务和批量训练队列、重试和输出一致性5.1 批量跑的时候资源怎么切单任务能把吞吐调上来只说明你的分配逻辑在单个场景里成立。实际生产中更常见的是同一时间跑多个智能体任务比如同时训练几个不同领域的工具调用模型。这时资源分配要考虑的就不是单任务的 rollout 比例而是多任务之间的队列优先级。我建议在批量场景里先给每个任务设定一个最小资源保证再让调度器在空闲时把多余资源分配给当前吞吐最低的任务。这样既不会让某个任务饿死也不会让资源被单个任务独占。Libra 这类方案的价值在并发场景里比单任务更明显。还有一个容易被忽略的点任务数量不是越多越好。同时跑太多的任务共享存储和网络会成为新的瓶颈。你可能会发现每个任务的 rollout 和 learner 比例都很合理但整体吞吐就是上不去这时候要去查存储读写和节点间通信而不是继续调整训练参数。5.2 失败重试和 checkpoint批量训练还会暴露一个容易被忽略的问题失败重试。资源分配再合理也会遇到显存溢出、节点掉线、网络超时。这时候要看框架能不能把失败任务自动重试以及 checkpoint 的保存频率。我的经验是训练卡死时不要急着扩大资源先看 checkpoint 恢复是否正常。如果每次恢复都要从头开始那吞吐再高也没有意义因为失败成本太高。连续跑 24 小时以上的任务checkpoint 频率和恢复验证一定要提前做不能等真的挂了再想办法。验证 checkpoint 的方法很简单手动杀掉一个正在训练的任务然后从最近的 checkpoint 恢复确认恢复后的 reward 曲线和杀掉之前能对上。这个动作在新环境里应该作为标准流程跑一遍。5.3 输出一致性判断批量任务还有一个容易被资源分配掩盖的问题多条轨迹之间的输出一致性。当你调大 group size 后模型从同一个问题里采样出多条轨迹如果这些轨迹高度重复说明样本多样性不足继续加大 rollout 数量只是浪费计算资源。判断标准是轨迹之间的文本相似度、行为多样性以及成功路径是否覆盖了多种解决思路。我在实际中见过一种情况吞吐提升很明显但模型最后只会走同一条工具调用路径遇到输入稍微变化就失败。这就是只优化了吞吐而没有监控样本多样性导致的。如果要批量产出训练结果建议在训练日志里加一个轨迹去重率或相似度统计。这个指标不用太复杂每 N 步抽样对比一次就行重点在于能及时发现样本退化。6. 吞吐高了不代表效果稳验证和排查链路6.1 先看现象再改参数遇到问题先别急着调参数。我的标准排查顺序是看现象是直接报错、训练卡住、速度骤降还是 loss 不收敛。看日志报错信息里的关键词通常能直接指向方向。看输入问题集、工具定义、奖励函数、轨迹格式有没有问题。看资源显存、内存、GPU 利用率、网络 IO 在异常时刻的曲线。看参数最近改过哪些配置是不是改完才出的问题。看版本框架、依赖、推理服务版本是否匹配。这个顺序很重要。很多人一遇到吞吐下降就去调 actor/learner 比例结果发现是共享文件系统满了磁盘写不进去rollout 全部阻塞。先看资源再看参数能省很多无用功。6.2 常见报错和指向我把跑 Agentic RL 后训练常见的几个现象整理成一张排查表遇到问题时可以先对着查现象优先检查常见原因GPU 显存溢出OOMrollout 的 group size、batch size、长轨迹长度单条轨迹太长或候选轨迹数太多训练速度突然变慢磁盘 IO、共享存储、网络checkpoint 写盘阻塞或节点间通信异常reward 长时间不涨奖励函数、任务设定、工具反馈奖励信号太稀疏或 rollout 探索不足GPU 利用率周期性掉到 0rollout 与 learner 的同步点同步等待导致流水线周期性空闲多任务互相抢卡调度器优先级、资源配额没有最小资源保证任务互相挤占如果日志里看到的是某个工具调用返回超时先别怀疑资源分配去看工具服务的并发上限和响应时间。Agentic RL 里工具服务本身经常成为隐藏瓶颈尤其是外部 API 调用的场景超时和限流比训练参数更容易拖垮整体吞吐。6.3 质量评估reward 曲线、样本多样性和收敛资源分配调优的最终验收不能只看吞吐。我一般会同时盯三条线rollout 吞吐单位时间内生成的合理轨迹数量。reward 曲线整体上升并且波动在可接受范围内。样本多样性同一问题产生的多条轨迹不能高度重复。如果吞吐涨了但 reward 曲线震荡加剧说明资源分配可能偏向于快速生成大量低质量样本训练稳定性下降。这时就该回退参数而不是继续加大 rollout。如果 reward 曲线稳步上升但轨迹多样性持续变差说明探索不足可以考虑提高 group size 或增加温度系数而不是继续调整资源比例。这三条线要放在一个仪表盘里看而不是盯着某一个指标做决策。只看吞吐容易牺牲质量只看 reward容易忽略资源效率。Libra 这类方案把吞吐提上去了但最终的模型能不能用还是要回归到这些训练质量指标上。7. 边界和经验Libra 这类思路适合谁不适合谁7.1 适合的场景从实际经验看这类“动态资源分配”思路最适合以下场景已经跑通 Agentic RL 后训练但总感觉 GPU 利用率不高。需要同时训练多个智能体任务任务之间抢资源严重。使用小规模集群比如几台到几十台 GPU没条件上超大集群的团队。训练任务周期长超过一天甚至一周资源分配带来的时间节省非常可观。如果你只是学习 RL 后训练用一个单机小模型跑 Demo默认配置通常够用不需要第一时间上调度方案。先把流程跑通理解 rollout、reward、update 三者之间的关系比直接套用调度框架更有价值。7.2 不要期待的点这个方案不是万能的。它对单个模型的最终效果提升有限如果你的奖励函数设计不合理、任务环境本身有问题再优化资源分配也只是让训练更快地走向一个坏结果。也不要期待动态分配能完全替代人工排查。框架再智能也需要你先把输入格式、工具调用、奖励函数这些前置条件搞对。动态分配优化的是流程效率不是内容质量。如果任务本身定义不清楚给多少资源都白搭。7.3 最后几条实操建议如果让我给你留一份行动清单我会写五条先用小任务跑出基线记录吞吐、资源占用、队列和 reward 四类指标。每次只改一个资源参数改完跑完整实验再对比。单个任务调到稳定后再考虑多任务并发和动态调度。上线长时间训练前先验证 checkpoint 恢复和失败重试。最终验收看“吞吐、收敛、多样性”三个指标不能只看速度。踩过几次之后我最大的感受是Agentic RL 后训练里很多问题不是模型能力不够而是资源分配和前置环境没有处理干净。Libra 这一类方案提供了更有体系的做法但真正落地时最该盯住的还是指标采集、环境稳定性和失败重试这三块基本功。先把基本功补齐再去追求那 3 倍的吞吐提升才不会变成一场空跑。