SLIME
SLIME 连接大规模训练与高吞吐 rollout 集群，用于语言模型强化学习与 Agent 轨迹训练，将 Megatron-LM 训练端与 SGLang 生成端整合进统一的强化学习数据流。它由 THUDM 与字节跳动开源，定位为「SGLang-native」的 RL scaling 后训练框架，代码见 GitHub 仓库，文档与设计动机见 slime 文档。
快速开始¶
先在最小规模上跑通端到端闭环，再扩大规模。闭环包括训练端、rollout 端、权重同步与奖励解析四个环节：策略权重从训练端同步到生成端，rollout 服务按当前策略生成轨迹，环境或验证器给出奖励，训练端消费带奖励轨迹进行更新。这条数据流可以写作 训练 -> 权重同步 -> rollout -> 奖励 -> 训练，任一环节断裂闭环就无法收敛。
第一步用可验证的简单任务验证这个闭环，确认权重能正确同步、生成的轨迹能被奖励函数解析、更新后策略确实发生变化。第二步将环境与验证器的版本、依赖锁定方式、随机种子和奖励定义写入实验记录，保证轨迹可复现。第三步再逐步扩大 rollout worker 与训练规模，注意训练端与生成端的并行策略可能不同，需要分别确认各自的资源与配置。
工程关注点¶
训练集群与生成集群可以采用不同的并行策略：训练端常用 Megatron-LM 的多维并行，生成端常用 SGLang 一类高吞吐推理服务。异步权重同步会引入版本滞后，即 rollout 使用的策略可能落后于训练端最新权重，这对在线强化学习的影响需要量化评估。
衡量系统有效性时应关注有效样本率而非只看 token 吞吐：很多生成轨迹可能因格式错误、验证失败或超时而不产生有效学习信号，只有真正进入训练的轨迹才算有效。调度、通信与权重同步的延迟都会影响实际的有效吞吐，可表示为：
其中 valid rate 指能通过解析、验证并进入训练的轨迹占比。若 rollout 吞吐很高但 valid rate 很低，系统只是在空转。
轨迹最终被策略梯度类更新消费，以 PPO 的裁剪代理目标为例，每条轨迹上的更新信号由概率比与优势构成：
其中 \(\rho_t(\theta) = \pi_\theta(a_t \mid s_t) / \pi_{\text{old}}(a_t \mid s_t)\)，\(\pi_{\text{old}}\) 是生成该轨迹的行为策略，\(A_t\) 是优势。若权重同步滞后使 \(\pi_\theta\) 与 \(\pi_{\text{old}}\) 相差过大，\(\rho_t\) 会偏离 1，clip 频繁触发，更新信号退化，这正是版本滞后需要量化的原因。
故障恢复同样重要：rollout 失败、环境超时、权重同步中断都需要有重试与断点续训机制，否则大规模训练中的一次中断就可能浪费大量已生成的轨迹。
案例¶
在代码修复环境中，rollout 服务为给定 issue 生成补丁，沙箱执行测试用例得到通过/失败结果，训练端消费带奖励的轨迹。奖励来自测试通过情况，失败轨迹同样是有价值的学习信号，不应被丢弃。
统计时应区分测试超时、无效补丁和真实失败：超时与无效补丁反映的是生成质量或环境限制，需要单独统计并纳入奖励设计。若只保留通过的轨迹，模型将失去从错误中学习的机会，且奖励分布会失真。
排查问题时先确认单条轨迹的可复现性：固定环境版本和种子后，同样的 prompt 与权重应能得到一致的奖励，否则后续的 RL 训练信号就不可信。