能力成本
编码助手是目前最强大的 B2B SaaS 应用之一：根据代币经济学模型，六大厂商的年经常性收入（ARR）市场规模已超 300 亿美元，有望在年底突破 1000 亿美元。
（来源：SemiAnalysis 代币经济学模型估算）
这些助手的智能编码能力并非仅靠预训练获得。后训练，尤其是强化学习（RL），才是从预训练模型中激发出这些能力的关键。Claude Opus 4.8 在 SWE‑bench Pro 上得分 69.2%，在 Terminal‑Bench 2.1 上得分 74.6%，强化学习训练正是提升分数的主要推手。
Anthropic CEO Dario Amodei 曾指出，强化学习表现出与预训练相似的扩展性，即性能随训练时间呈对数线性增长（链接）。但这种扩展成本极高，因此 RL 系统的效率决定了你能负担多大规模的强化学习，进而影响模型能力的上限。
RL 训练系统的效率到底取决于什么？本文通过开源 RL 框架在开放模型上的实验，对比了 Tinker 等托管式训练方案，发现系统效率的关键在于训练器和生成器吞吐量的匹配程度。
三位演员
开源 RL 训练系统由三个核心组件组成：生成器、RL 环境和训练器。
生成器对数据集中的提示进行推理，产出 rollout（一个提示及其对应的模型响应）。与预训练不同，数据集只提供提示而非完整目标，系统必须自行生成训练信号。生成器需要与 RL 环境交互，由环境根据 rollout 产出奖励——例如代码环境会在沙箱中执行生成的代码，并根据测试通过率打分。随后，训练器接收 rollout 和奖励，训练模型并生成新的权重，最后将权重推送给生成器，完成一个 RL 训练步骤的闭环。
强化学习算法，恰到好处
与最大化对数似然的预训练不同，RL 训练最大化的对象是预期奖励。组相对策略优化（GRPO）已成为开源标准，多数开源权重模型都基于其变体训练。
GRPO 会针对每个提示抽取多个完成样本，形成一个 rollout 组。为每个 rollout 分配奖励后，计算其优势——即 rollout 奖励相对于组平均值的对比，衡量其好坏。高于组平均值的 rollout 被强化，低于的则被抑制。
如果一组中所有测试都获得相同奖励，则每个 rollout 的奖励都等于组平均值，优势为零，该组便无法提供任何训练信号。这取决于奖励分布：极端情况是任务太简单（全通过）或太难（全失败），导致解决率接近 0% 或 100%。
从同步到异步强化学习
经典策略梯度算法假设同一组 rollout 都来自同一策略（同一权重）。在训练系统中，这意味着生成器必须等待当前批次 rollout 处理完毕才能更新权重。若训练器完成了训练步骤，也必须等待生成器完成，导致训练与生成同步执行，系统效率大幅降低。
PipelineRL 则允许训练器在 rollout 仍在生成时便推送新权重，在系统中引入异步性，使训练执行与 rollout 生成重叠。代价是策略陈旧——每个样本由新旧策略混合生成。
PipelineRL 证明，RL 算法可在一定程度上容忍策略陈旧，但过于陈旧的样本会降低学习效率。同步执行过于浪费计算资源，异步技术因此不可或缺。本质上，PipelineRL 是一种吞吐量匹配方案，它限制了策略陈旧程度，允许训练器和生成器以不同速率运行，但上限由样本陈旧程度决定。正因如此，它已成为开源 RL 训练的标准实现。
（资料来源：Magistral、Mistral AI）
RL 环境和沙箱
RL 环境为模型提供反馈，帮助模型学习完成任务。在实现上，RL 环境通常以沙箱的形式出现——一种用于代码执行的容器化运行时。根据复杂度，它可以是轻量级的 Firecracker 微 VM，也可以是功能完整的 QEMU 虚拟机。
沙箱面临独特的系统挑战：生成器与 RL 环境间的交互延迟对端到端部署延迟至关重要，沙箱启动延迟是主要开销之一。服务商如 Modal 利用内容寻址缓存等技术优化启动延迟。
大规模部署时，沙箱数量随并发部署数波动剧烈，且必须能抵御系统故障——模型意外行为（如创建百万个文件）可能导致资源耗尽，沙箱编排需要检测并从中恢复。
吞吐量匹配框架
量化训练器和生成器吞吐量
我们把 RL 训练系统看作一个队列：生成器将 rollout 放入队列，训练器从中取出消耗。生成慢于训练时，队列清空，训练器闲置；生成快于训练时，队列增长，样本老化，引发策略失效。
系统效率的关键在于匹配生产者和消费者的吞吐量。理想系统中，训练器的消耗速率约等于生成器的生产速率。我们测量训练步骤时间（包括等待空闲、计算和权重广播），得出样本吞吐量（样本/秒），并计算每 GPU 的 FLOP/s 及 FLOP 利用率（MFU）来表征硬件效率。
生成器通过 LLM 推理与 RL 环境交互生成样本。由于组内最长的 rollout（即掉队者）决定组完成时间，我们以端到端延迟估算平均样本吞吐量。端到端延迟进一步拆分为 LLM 推理时间和 RL 环境交互时间，后者包括沙箱启动及执行耗时。
吞吐量限制
训练器消耗率 = 每步样本数 / 训练步时间。
影响样本数量的因素：
- 组大小：每个提示的样本数 N（通常 8 或 16），任务越难可越大（如 GPU 内核写入任务 N=64）。
- 奖励分布与优势过滤：任务过易或过难导致奖励均匀，造成零优势；若过滤零优势样本，则减少每步所需样本数。
- 批次大小：存在最小有效批次以稳定学习；训练器通常部署在足够 GPU 节点上以容纳数据。
影响训练步时间的因素：
- 模型：架构、大小、激活函数大小、精度决定内存占用，并设定最小 GPU 数以避免 OOM，也决定操作的执行时间。
- 并行性与内存配置：张量/流水线/数据/专家并行、FSDP、内存卸载、激活检查点等，受 GPU 数量影响，决定系统效率和训练步时间。
生成器方面，生产率 = 并发部署次数 / 端到端延迟。
影响端到端延迟的因素：
- 推理吞吐量：推理引擎调优（并行策略、KV Cache 量化、PD 解耦、推测解码）。
- 沙箱延迟：启动时间与执行时间。
- 奖励模型类型：数学/编程用轻量验证器快；写作任务用 LLM 评判器慢。
- 奖励形状：过程奖励模型评估每回合，部分模型仅评估整 rollout。
并发部署次数受 KV Cache 空间和平均序列长度限制。总内存容量（模型权重 + 激活）即 KV Cache 空间，除以平均序列长度可估算最大并发数。
由于训练信号质量差异，并非所有生成样本都会被训练器使用。有效生成率 = 接受率 × 生成率。影响接受率的因素：
- 早期剪枝：根据长度上限、值函数或中间结果验证器检查，在 rollout 完成前剪枝，动态减少并发数。
- 自适应抽样：根据标准（如在线优势过滤）拒绝 rollout。
策略陈旧
策略陈旧是指生成样本的策略版本与训练器应用梯度时的策略版本之间的差异，是异步训练的副产品。它出现在不同粒度级别：轨迹级（部署策略版本与更新后版本差异）、令牌级（部署过程中发生权重更新）、以及环境状态级（稍后详述）。
策略陈旧意味着训练器使用偏离策略的信号训练模型，可能导致训练不稳定，因此通常会设置策略陈旧预算。该预算限制样本可容忍的陈旧度，即生成器领先训练器的步数上限，从而允许两者以不同速率运行。
不断变化的目标：模型能力与行为
RL 训练中，模型能力与行为是重要的系统变量。能力决定了模型解决任务的效率，用解决率衡量。解决率趋近 0 或 100% 时，奖励分布均匀，无优势，训练信号消失。这影响组大小和优势过滤策略的决策，也影响课程设置——任务难度排序，需将解决率保持在有效中间区间，让任务既不过易也不过难。
模型的令牌使用行为影响输出长度，进而决定生成器最大并发 rollout 数。RL 训练常引发链式推理，导致更长推理轨迹，增加平均输出长度和 KV Cache 占用，减少并发数，增加端到端延迟。工具调用行为则影响沙箱时间：调用次数越多，沙箱耗时越长；意外的工具调用操作会给沙箱基础设施带来压力。我们会跟踪工具调用次数和沙箱错误率。
随着 RL 训练推进，模型能力提升，但行为发生漂移，约束条件随之改变，训练系统必须动态调整以保持效率。
案例研究
我们通过实验验证了理论，并分享使用开源 RL 框架的经验。配置如下：
- 模型：混合专家（MoE）模型，因其是主流开源模型。
- RL 环境与任务：智能体编码任务，复杂度较高，可观察沙箱性能特征。
- 节点数：至少 10 个节点，以展现训练器-生成器动态并拟合模型。
长期模型响应与早期探索训练阶段
设置
- 模型：Qwen3‑235B‑A22B‑Thinking‑2507，BF16 训练，FP8 生成。
- 训练器：64 块 H200 GPU，FSDP，EP8，CPU 卸载优化器状态和激活。
- 生成器：192 块 GPU，24 个推理实例（DP1、TP8、EP8）。
- 批次大小：512 样本。
- 组大小：每问题 16 rollout。
- 每批次问题数：32。
- 最大序列长度：32K。
- 策略陈旧上限：16 步。
- RL 环境：Mini SWE Agent Plus，联合 Prime Intellect 沙箱。
- RL 框架：Prime RL。
- 代码：配方将推送到主分支，原始提交记录在此。
分析
本次运行展示了两个因素如何影响效率：模型产生长思考链的长响应，以及模型学习任务的程度。
长响应行为是 LLM 推理时间的主要驱动，而推理时间又占样本生成时间的大头。响应长度的方差还导致每个 rollout 组出现严重的长尾延迟，迫使系统采用过采样缓解：生成器每次启动比需要更多的并发 rollout，一旦达到目标计数就丢弃未完成或出错的 rollout。本次运行中，高达 60% 的已调度 rollout 被丢弃，反映出响应时间较长的极端偏斜分布。
（来源：SemiAnalysis）
在模型能力方面，课程难度对基础模型略高。第一次训练后，产生零解的 rollout 组数量骤增，但平均奖励和 Pass@16 正在缓慢恢复。这表明早期探索使策略在重新学会前偏离了之前可解决的问题。
（来源：SemiAnalysis）
综合看，系统受限于生成次数：队列耗尽，训练器资源不足。为缓解，我们牺牲训练器效率换生成器效率。训练器以 2.75 样本/秒消耗，等待时间占运行总时间的 30%，MFU 仅 10.5%；生成器以 1.95 样本/秒产出，但计算资源是训练器的三倍，凸显推理效率在 RL 训练中的重要性。
（来源：SemiAnalysis）
频繁使用工具与任务过于简单
设置
- 模型：GLM‑5，BF16 训练，FP8 生成。
- 训练器：128 块 H200 GPU，FSDP，CP2，EP8，CPU 卸载优化器状态。
- 生成器：128 块 H200 GPU，2×64 GPU 推理副本。
- PD 解耦：32 预填充 GPU，32 解码 GPU，支持 DP32 和 EP32。
- 每节点 1 TB KV Cache 卸载。
- 批次大小：512 样本，组大小 16，每批次问题数 32。
- 最大序列长度：64K。
- 策略陈旧上限：16 步。
- RL 环境：Mini SWE Agent Plus，联合 Prime Intellect 沙箱。
- RL 框架：Prime RL。
- 代码：主分支待发布，原始提交记录在此。
分析
此次运行的两个核心因素是：模型行为漂移和课程过易。
平均响应长度和工具调用次数（由 20 次升至 51 次）在运行期间均翻了三倍，导致序列长度增加，工作负载转向以预填充为主。这印证了我们选择分散式服务，因它能改善预填充请求的最差情况首令牌响应时间（TTFT）。
（来源：SemiAnalysis）
从能力角度，课程难度对模型过低。平均 55% 的问题解决率达 100%，即组内所有 rollout 全部通过。全部奖励相同，则优势为零，训练信号消失，平均奖励停滞不前。课程难度不匹配减少了有效训练样本，降低了生成器的有效生成率。
（来源：SemiAnalysis）
这些因素导致系统严重受限于生成时间。队列很快填满，但大量被过滤，产出极低。LLM 推理占端到端生成时间的绝大部分，且随训练进行不断增长。训练器 74% 的挂钟时间在等待，消耗率是生成器输出率的约 5 倍。
（来源：SemiAnalysis）
沙箱扩展挑战
设置
- 模型：Qwen3‑235B‑A22B‑Instruct‑2507，全 FP16。
- 硬件：GB300。
- RL 框架：verl + 单智能体部署。
- RL 环境：SWE‑bench 风格环境，配备 Modal 沙箱。
- 算法：GRPO。
- 最大序列长度：128K。
训练阶段
第一阶段：
- 训练器：32 GPU，TP16/EP32，CPU 卸载。
- 生成器：24 GPU，6 副本，TP4。
- 组大小：8，并发 rollout 数：96。
第二/第三阶段：
- 训练器：48 GPU，TP4/CP4/PP3/EP16，CPU 卸载。
- 生成器：24 GPU，6 副本，TP4。
- 组大小：8，并发 rollout 数：256（第二阶段）、360（第三阶段）。
分析
训练动态与其他 Qwen3 235B 运行基本一致：生成受限，训练器空闲 30%‑60%；迭代长度增长迅速，3%‑8% 的样本达到 128K 长度上限，在第 9 步一个明显掉队的样本尾延迟飙至 7500 秒。
本案例独特之处在于尝试提升并发部署时，撞上了沙箱扩展问题。提升并发部署对样本生成吞吐量至关重要，可支撑更大批次、更丰富的奖励方差，提供更优质训练信号。然而，每次部署至少对应一个沙箱，提升并发数会考验沙箱基础设施的可靠性。在试图将并发数从 96 增至 960 时，一旦超过账户限制，便出现沙箱初始化失败错误，启动延迟长达一小时。为缓解，我们回缩至 96，但部署效率依然低下。此实验表明，沙箱扩展对 RL 训练效率至关重要。
（感谢 vLLM / Inferact 的 Ao Shen 和 Kaichao You 协助。详细错误记录在此，最终阶段训练的 WandB 日志在此，代码仓库：verl、uni‑agent。）
部分部署与有状态沙箱设计
设置
- 模型：Qwen3‑235B‑A22B‑Thinking‑2507‑FP8（FP8 生成，BF16 训练）。
- 训练器：32 块 H200 GPU，TP4/CP4/PP2/EP8。
- 生成器：64 块 H200 GPU，8 副本，TP8/EP8。
- 最大序列长度：32K，全局批次大小 64。
- 算法：GSPO，组大小 8。
- RL 框架：Slime。
- 异步设置：完全异步 + 部分 release。
- RL 环境：SWE‑Bench 验证和精简版，搭配 OpenHands 框架和 Modal 沙箱。
- 代码库：slime SWE Bench 示例。
分析
整体系统特性类似其他 Qwen3 235B 运行：生成受限，训练器等待约 60%，每回合响应长度 12K，平均工具调用 12 次/序列，解决率偏低。
重点在于 Slime 的部分 release 功能，以及沙箱为此所做的适配。部分 release 允许将延迟的 rollout 保存至缓冲区，在后续批次中重启，以此缓解长尾延迟，提高系统效率。
在 Slime 中，部分部署会将掉队 rollout 标记为中止，存入回放缓冲区，排队等待后续批次。这给沙箱带来挑战：
- SWE‑Bench 问题可能具有状态性（如部分 rollout 可能在编辑文件），沙箱须在多次批次间保持稳定，需要额外逻辑跟踪沙箱 ID 与样本映射关系。
- 沙箱需延迟创建：样本处理逻辑与沙箱创建耦合，但有的样本可能根本不调用工具，提前创建沙箱则浪费。
- 沙箱故障恢复：若样本中止至重启期间沙箱发生故障，需额外逻辑保证正确性。由于尚未找到在 Modal 上实现故障恢复的方法，我们选择将此类样本标记为失败。
Slime 在两种情况下触发部分 rollout 中止：目标 rollout 批次已满（本例为 64 样本），或训练器推送权重更新。这导致回放缓冲区中部分 rollout 计数呈现有趣的动态。权重更新每 5 步一次，第 5、10、15 步后计数显著增加；第 7 和 17 步出现峰值，我们推测是因为前一步（6、16）提前达到目标批次，产生大量积压。
（来源：SemiAnalysis）
与 PipelineRL 不同，Slime 的 SGLang 配置会清除中止 rollout 的 KV Cache，因此恢复 rollout 本质上是大型预填充请求，而这正是 PD 解耦最能获益的工作负载类型。
（来源：Kimi Researcher，Moonshot AI）
部分 rollout 正是环境状态层面策略陈旧性的体现。当中止的 rollout 在后续批次恢复时，训练器可能已推送新权重，恢复的 rollout 不仅面临策略差距，还面临有状态环境特有的状态差距。在 SWE‑Bench 场景中，它唤醒的沙箱并非全新代码库，而是保留了旧策略先前产生的未完全应用的编辑、已创建的文件及工作目录状态。新策略现在必须从一个它未创建且未必会自行创建的状态继续执行，这可能破坏训练信号：优势被归因于当前策略仅部分拥有的轨迹。考虑到权重更新后恢复 rollout 的次数很高，我们怀疑环境状态层面的陈旧性是导致运行解决率偏低的原因之一。
总而言之，部分部署能挽救掉队者，维持队列填充吞吐量，代价是有状态沙箱的复杂性和显式的环境状态级策略陈旧。
软件用户体验
Prime RL
Prime RL 用户友好度出色。多通过 UV 键执行命令，配置写在 .toml 文件中；内置技能文件也让 AI 代理更容易使用其代码库。
在系统设计上，协调者（orchestrator）角色明确处理训练器-生成器动态，Environments Hub 设计宜人。训练侧使用 Torch Titan，生成侧使用 vLLM，沙箱则基于自研 Prime Sandbox。该框架已支持生成器的 PD 解耦，对智能体 RL 提升显著。整体代码库精简，技术栈主流。
但我们也遇到一些挑战：
- 对 UV 的重度依赖要求用户必须熟悉 UV；为安装 Flash Attention 3 和解决 UV 卸载问题，我们耗费了大量时间。建议 Prime Intellect 提供更多 UV 工作流指南。
- 虽默认运行于 SLURM 集群，但假设作业在裸机而非 Pyxis 上，容器化作业本可更轻松解决 DeepGEMM 库的 CUDA 版本不匹配。
- 多次运行失败最终定位到 Prime Sandbox 的问题，错误信息难解析，多出现在运行后期，包括悬空沙箱占用配额、资源不足、积分不足等，其中不少可在运行前检测到。Prime Sandbox 仍处测试阶段，期待后续改进。
（感谢 Prime Intellect 对本工作的软件与硬件支持。基于此 PR 的配方提供训练方案。）
Slime
Slime 以简洁高效的抽象著称，尤其是其 Hook 抽象，允许自定义 rollout 处理、奖励函数和指标日志，函数签名与契约清晰，集成与添加新功能十分便捷。
团队也非常友好：核心维护者 Zilin 提供了配置调优指导，并解答了设计疑问。
主要憾点在于异步模式文档不足，我们主要通过试错才理解完全异步与部分部署的机制。希望未来能补充更完善的文档。
Modal
Modal 的 API 文档出色，沙箱 API 清晰易用，服务在实验期间相对稳定，即使小规模测试中创建/终止沙箱也简单快捷。团队同样热心，早期便提供了 API 积分支持，成员 Peyton 和 Nan 为我们的结果提供了宝贵建议。
主要挑战出现在高并发沙箱时：如前所述，初始化错误和过长的启动延迟。事后排查发现是账户资源限制所致。Modal 提升限制后，我们验证了高并发沙箱的稳定性（复现代码在此）。我们感谢 Modal 的快速响应，并期望未来提供更多沙箱可观测性工具及扩展文档。
开源强化学习框架的历史
DeepSeek R1 的发布激发了开源社区复现其算法与基础设施的努力。早期成果之一的 OpenRLHF 是大规模 RL 训练框架，实现了 PPO、REINFORCE++ 及后来的 GRPO，对后续框架影响深远。许多 OpenRLHF 维护者后来开发了流行的 RL 框架，包括 slime 和 verl，并带动了活跃的中国 RL 社区，为中国模型的近期发展贡献了积极力量。这些开源框架也使学术研究人员能开发新算法与技术，让 RL 研究走进高校。
（感谢 Kaichao 分享这段历史，他曾领导 vLLM 在 OpenRLHF、verl 等项目的早期 RL 集成工作。真诚合作与分享，而非敌对竞争与信息封锁，才是推动科学进步的动力。）
结论
RL 训练系统的效率取决于队列的健康状况：过采样、早期剪枝和部分 rollout 控制什么进入队列，自适应采样和策略陈旧性控制什么离开队列，而飞行中权重更新则允许训练器和生成器以不同速率运行。
RL 训练既是算法问题，也是基础设施问题。本文聚焦系统层面，阐明了系统设计与算法设计的相互联系，并通过实际实验加以说明。希望这能激发更多人对 RL 基础设施的兴趣，促进算法研究人员与系统工程师的交流。
更多关于 RL 训练基础设施的深度探讨，欢迎移步 云栈社区 交流。
semianalysis.com
发表于 3 小时前
|
查看: 4|
回复: 0
