训练一个 Agentic RL 模型最让人难受的事情往往不是损失不下降而是 GPU 明明在用吞吐却上不去。你盯着监控面板发现采样进程在等环境返回奖励模型在排队训练进程的空闲率很高可是资源早就占满了。Agentic RL 后训练的吞吐问题并不是单纯的“算力不够”更多时候是一种资源分配失配。港中文和恒生大学提出的 Libra直接把矛头对准了后训练阶段的资源分配给出的收益是吞吐最高提升 3 倍。这个数字放在今天的大模型训练环境里已经足够让团队重新审视自己的后训练流程。很多人会以为提高吞吐就是加卡、加大 batch、升级显卡。但真正跑过 Agentic RL 后训练的人会知道问题往往不出在单卡算力而出在整个流程里不同环节互相等待。等待不解决加再多的卡也只是让某一个环节更忙整体效率不会同步提升。这篇文章不打算复述 Libra 的每个技术细节因为公开信息有限我更想从工程视角拆开一个问题Agentic RL 后训练里的资源分配为什么值得单独立项去解决。1. 为什么 Agentic RL 后训练的吞吐问题比预训练更隐蔽1.1 Agentic RL 的算力消耗不是一个“训练任务”而是一条流水线预训练阶段的资源模型相对稳定输入序列、batch size、模型参数都是提前定义好的虽然上下文长度会有波动但计算模式整体单一资源分配可以近似看作一个静态问题。Agentic RL 后训练完全不同。Agentic RL 指的是把模型放进一个能够调用工具、做多步推理、与外部环境交互的场景里通过强化学习继续训练。它不只在处理文本而是在处理一整条轨迹模型发起一次行动环境返回一个观察模型再根据观察决定下一步。每一步都可能调用外部工具、检索数据库、执行代码或者与另一个模型对话。这条轨迹的长度、工具调用的次数、每一步输入的上下文长度都是高度动态的。一条轨迹可能只有几十步也可能长到几千步一次任务可能只需要一次工具调用也可能要连续调用五六次。资源需求随任务内容剧烈变化不再是预训练那种“输入固定、计算固定”的模式。更关键的是Agentic RL 后训练不是单一计算任务而是一条完整流水线采样、环境交互、奖励计算、经验存储、策略更新。每一个环节都消耗资源而且它们之间的速率如果不同步整体吞吐就会被最慢的一环卡住。1.2 资源分配的核心矛盾采样、奖励和更新在抢同一批 GPU在一个典型的 Agentic RL 后训练流程里至少有三个角色在争抢算力。第一个是采样器。它要用当前策略模型生成大量轨迹本质上是一大批推理任务。推理任务多显存占用相对低但计算频率高如果并发不够采样速度就会拖慢整个流程。第二个是奖励计算。Agentic RL 场景下奖励往往不是简单规则而是一个独立的奖励模型或者是多个模型的综合打分。这个模型要在线处理每一条轨迹如果奖励模型推理速度跟不上采样速度采样得到的经验数据就会堆积在缓冲区里无法进入下一步。第三个是策略更新。这是传统意义上的训练任务需要反向传播、梯度计算、多卡通信。它和采样推理的资源需求差异很大通常需要较大的 batch size 和更集中的显存。问题在于这三个环节共享同一批物理资源。采样时 GPU 利用率高但训练环节可能正在等待数据训练更新时算力集中在参数更新但采样器又需要等待空闲 GPU。原本每个环节都能用满资源但放在一起就会出现“抢”和“等”的循环。这就是 Agentic RL 后训练吞吐上不去的核心原因不是某种硬件不够强而是各环节之间缺少统一的资源分配策略。1.3 后训练吞吐上不去的真正信号吞吐上不去表现很多但最常见的并不是“GPU 利用率低”而是“GPU 利用率很高端到端吞吐还是低”。这种状态最容易迷惑人。比如采样器把 GPU 跑到了 95% 的利用率但它生成的大量轨迹无法被奖励模型及时消化经验缓冲区被填满后采样器就必须暂停等待。从监控看GPU 一直很忙但有效产出非常低。真正的信号应该看这几项训练迭代的间隔时间是否稳定经验缓冲区是否经常处于满或空的状态同一个 GPU 上采样推理和训练更新的时间占比是否严重失衡环境交互返回的延迟是否频繁超过采样推理的时间如果只看 GPU 利用率往往会错过真正的瓶颈。这也是为什么 Libra 一类方案会把“资源分配”当成后训练里的核心问题它不是在优化单个算子而是在优化整条流水线的匹配度。2. Libra 这枚“资源调度器”到底在调什么2.1 资源分配不是简单的“多给卡”读到“资源分配”这四个字第一反应可能是“给某个环节多分几张卡”。但在 Agentic RL 后训练里资源分配至少要覆盖四个维度。第一是算力分配。采样推理、奖励模型、策略更新分别占据多少 GPU 算力按什么比例切分以及是否允许动态调整。第二是显存分配。奖励模型和策略模型可能同时驻留在同一批显卡上显存预留多少给奖励推理多少给训练状态和激活值会直接影响批处理大小。第三是存储和 IO。Agentic RL 会高频产生轨迹日志、中间观察、工具返回结果。如果写入速度跟不上即使 GPU 算力充足也会因为等待磁盘 IO 而停滞。第四是调度优先级。当多个任务同时需要资源时谁先运行、谁可以抢占、谁必须等待。这里的“调度”已经不是排队问题而是需要根据当前流程状态做实时判断。所以 Libra 调的不是单张卡的利用率而是整条后训练流水线里的资源视角。它更像是一个资源编排层只不过针对的是 Agentic RL 这一类高动态负载。2.2 从流程角度理解 3 倍吞吐收益关于 Libra目前公开能聚焦的关键信息是“吞吐最高提升 3 倍”。这个数字如果放在预训练场景里听起来有些不可思议因为预训练的优化空间已经非常有限。但放在 Agentic RL 后训练里3 倍提升完全有可能甚至可以说很多团队的流程里本来就藏着这样的浪费。举一个常见情况采样器在跑推理时训练进程闲置奖励模型在排队时采样器已经产出了大量轨迹训练进程开始更新时采样器又因为等待奖励结果而暂停。整条流水线断断续续每个环节都有空闲碎片。Libra 这类方案要做的事情就是把这些空闲碎片找出来用动态调整资源的方式重新拼接起来。采样空闲时把算力让给训练训练等待时把算力让给奖励模型某个任务不再需要那么多采样并发时就把资源释放给其他任务。从流程角度理解3 倍吞吐的源头不是“每一步都快了 3 倍”而是“等待变少了”。这是两种完全不同的优化路径也是 Libra 最值得关注的出发点。2.3 提升 3 倍意味着什么又意味着不是什么吞吐提升 3 倍意味着在同样的资源总量下单位时间内能收集和处理更多经验轨迹。对实验型团队来说这等于把模型迭代周期显著缩短对生产型团队来说这等于让同一个 GPU 集群能支撑更多尝试。但必须说清楚边界吞吐提升不等于训练效果提升。3 倍吞吐只代表数据流动更快了不代表每条轨迹的质量更好也不代表奖励设计和策略更新更有效。如果采样策略本身有问题再高的吞吐也只是更快地产生无效经验。另外“最高提升 3 倍”并不意味着所有场景都会提升 3 倍。它的适用范围、基准任务、资源规模目前没有更多公开细节。对于读者来说更合理的理解是通过优化后训练阶段的资源分配吞吐有大幅提升的空间但具体收益要结合自己的流程去测量。3. 落地前先学会排查自己后训练流程的瓶颈3.1 先量化每一轮采样、奖励、更新分别占多少时间很多团队一上来就想复现 Libra 的调度策略但手里连最基本的耗时数据都没有。这是最大的误区。在引入任何资源调度方案之前第一件事是量化当前后训练流程的时间分布。怎么做最简单的方法是给每个环节加上时间戳或者用 profiler 记录采样阶段平均生成一条完整轨迹需要多少秒环境交互工具调用平均延迟是多少是否有明显长尾奖励计算奖励模型处理一条轨迹需要多少秒训练更新一个 batch 从开始到更新完成需要多少秒缓冲区等待轨迹在采样输出和训练输入之间等待了多长时间这份数据不需要很精确但一定要能回答一个问题时间到底花在哪个环节如果没有这个基础数据后续所有优化都可能是在盲调。3.2 再分层输入、环境、策略、存储逐个排除拿到时间分布后如果发现吞吐确实低就要分层排查。常见的层次包括输入层、环境层、策略层、存储层。输入层要检查的是数据格式、上下文长度、提示词设计。比如上下文长度过长会显著拖慢采样推理如果工具调用过程中产生了大量中间输出也会加大奖励模型的处理负担。环境层要检查的是外部工具、模拟器或服务端的响应速度。Agentic RL 里环境并不总是很快。如果一个工具接口平均要 2 秒才返回结果采样器再快也只能等。策略层要检查的是推理 batch size、并发数、模型量化程度。采样推理和训练更新对 batch size 的敏感度不同需要单独调优。存储层要检查的是轨迹日志写入频率、缓冲区大小、中间结果是否有冗余落盘。很多团队忽视这一步结果 GPU 算力完全没问题但训练进程和采样进程同时在读写磁盘IO 直接成为瓶颈。3.3 一个可直接套用的排查顺序这里给出一张表我自己排查时会按这个顺序走现象可能瓶颈优先检查采样慢训练经常空闲rollout 推理并发不足或环境返回慢推理 batch size、并发 worker 数、工具调用超时训练慢采样结果堆积训练 batch 过大或梯度同步开销高训练 batch size、并行策略、通信方式奖励计算排队严重奖励模型推理过慢奖励模型 batch、是否有缓存、能否离线预计算显存占用高但利用率有碎片显存分配策略不合理模型驻留方式、缓存池、序列长度 padding磁盘等待频繁轨迹日志或中间结果写入过密日志采样率、是否压缩、存储类型这张表解决的是“从哪一层开始看”的问题。实际排查时不要同时改多个变量一次只验证一个假设。3.4 小规模验证是唯一可靠起点排查完瓶颈后你可能会萌生一个想法直接写一套自己的调度逻辑或者移植 Libra 的思路。我的建议是不要直接把调度器应用到大规模训练上。先做小规模验证。用 1 个任务、1 个 batch、1 个很小的环境集合把整个后训练流程跑通记录调度前后的吞吐差异。然后再扩大到 2 个任务、4 个任务观察调度策略是否稳定。整个过程至少有这几步单任务验证确认流程本身没有问题小批量并发确认资源分配逻辑在多任务下仍然有效压力测试把采样、奖励、更新三个环节都推高观察是否出现新的等待点这本质上是一个“先跑通、再优化、最后工程化”的顺序。跳过任何一步都可能在更大规模下踩到完全预料不到的坑。4. 吞吐提升之外Agentic RL 后训练还缺什么工程能力4.1 只看吞吐会忽略稳定性、成本与可复现性吞吐是一个非常直观的指标但它不应该成为唯一指标。如果调度策略提升了吞吐却让整个流程变得不稳定比如某些任务被无限期等待或者某个环节频繁 OOM那这个调度策略就值得再想想。Agentic RL 后训练的长链路里稳定性比单次吞吐更影响实际使用。成本也要算。调度器本身当然不贵但它可能会引入额外的资源检测、动态重分配、任务抢占机制这些机制在落地时都会消耗开发和运维时间。如果团队只有一两个人维护这套系统复杂度就需要严格控住。可复现性同样重要。后训练里的实验往往需要对比多次运行结果。如果资源调度导致每次运行的数据生成顺序、batch 组成都不同实验对比就会变得困难。提高吞吐的同时还得保证实验记录完整、随机种子可管理、样本日志可追溯。4.2 Libra 这类方案适合谁不适合谁先说适合的场景。Libra 这类资源分配方案最适合的是已经有比较复杂的 Agentic RL 后训练流程、多任务并发、并且采样与训练负载明显不平衡的团队。这类场景下资源调度能带来肉眼可见的吞吐变化。它也适合那些已经跑通算法、开始追求规模化效率的团队。当模型不再只是单机实验而是需要在多卡集群上持续迭代时资源分配就从一个优化项变成了必要性。不适合的场景也很清楚如果你只是做小规模实验每天只跑几个任务或者后训练流程非常简单单机单卡就能搞定那么引入一个完整的资源调度层只会增加复杂度。这时候更值得做的事是把算法、奖励设计、采样质量打磨好。资源调度带来的吞吐提升在一个本来就没有瓶颈的小流程里并不会带来 3 倍收益。4.3 引入调度方案前要补的四个前置条件如果你判断自己的场景确实需要调度我建议先补齐四个前置条件。第一是监控覆盖。至少要有 GPU 利用率、显存、磁盘 IO、各阶段耗时、队列堆积长度这些维度。没有监控调度策略就无法被验证。第二是可观测性。不只要知道资源占用还要能定位到具体任务和样本。一条轨迹走到哪个环节、被谁处理、耗费多久都应该能被追踪。第三是实验记录。每次调度策略调整后都要记录前后对比、参数配置、运行时长。否则你无法判断这次优化是有效还是无效。第四是回滚能力。调度策略是有可能引入新问题的。如果调整后吞吐没有提升甚至导致任务卡死你需要能快速回到上一版配置。注意不要一上来就设计一套复杂的动态调度规则。先从小范围的固定策略开始记录足够数据后再考虑动态调整。5. 我的建议资源分配意识的优先级应该高于调参5.1 不要一上来就复现别人的调度器看到一个方案吞吐提升 3 倍第一反应是“我也要复现”这是能理解的。但复现一个调度器不等于解决了自己的问题。调度器的核心是对负载的假设。Libra 的负载假设是基于 Agentic RL 后训练里采样、奖励、更新的多环节不平衡。如果你的实际负载并不是这种形态硬套调度策略可能适得其反。我更建议先把自己的流程拆开问三个问题我的时间到底花在采样、奖励还是训练更新上我的 GPU 集群是否同时存在大量空闲和大量排队我当前吞吐上不去的主要原因是不是资源互相等待如果三个问题的答案都是“是”那资源分配确实值得投入。如果答案里有明显的“不是”那问题很可能在算法、数据或奖励设计上。5.2 先做一次“一天版”的资源审计很多团队会拖延觉得资源分配是系统工程师的事等流程跑大了再处理。但等到流程跑大了再回头补监控和调度逻辑改动成本会高很多。一个比较务实的做法是拿出一到两天做一次“一天版”资源审计。具体可以这样做选一个典型 Agentic RL 后训练任务在采样和训练之间插入时间统计收集一个小时内每个环节的耗时分布画出这几个环节之间的等待关系标出你认为最大的等待点做完这次审计你至少能知道自己的流程里是否存在明显的资源失配。如果存在再考虑调度方案如果不存在那么继续打磨算法不要被吞吐指标带偏。5.3 一个调度方案值得不值得引入用三个标准判断当资源分配方案摆到你面前时不管是 Libra 还是其他方案都可以用三个标准判断。第一它是否有效减少了等待。注意是“等待”而不是“计算”。调度器真正创造的价值在于把空闲时间和排队时间压缩掉。如果某个方案只是把计算更快地堆到最忙的环节里那它并没有解决根本问题。第二它是否容易接入现有流程。接入成本包括代码改动、监控补全、机器配置变化、学习成本。如果接入一个方案需要你重写整个后训练框架那么收益再大也要先评估风险。第三它是否带来额外的可维护负担。调度策略增加了动态性也就增加了出问题的可能性。如果一个方案在提升吞吐的同时让系统状态变得难以理解和排查那么你需要额外的人工投入来维持这套系统。这三个标准都不满足的方案最好的选择是不用满足越多越值得继续深入。Agentic RL 后训练的复杂度决定了它很难用一套静态配置跑到最优。Libra 的意义不在于“提升 3 倍”这个数字本身而在于它提醒我们当采样、奖励、更新被放进同一条流水线时资源分配不再是一个后台问题而是决定整个后训练效率的关键变量。与其等瓶颈出现再救火不如在开始设计后训练流程时就把资源分配当成一个必须回答的问题。先量化自己的流程再决定要不要引入更聪明的调度方案这条路虽然看起来慢但往往是最稳的。