随着大语言模型规模从千亿向万亿参数迈进，强化学习后训练成为提升模型推理、工具调用等复杂能力的关键路径。然而，传统 RL 训练框架在应对 MoE 模型、长序列生成等场景时，面临推理延迟不可缩放、内存墙、分布式同步开销三大核心挑战。清华 THUDM 团队开源的 slime 框架，正是针对这些规模化瓶颈设计的下一代 RL 后训练基础设施。
架构解耦：训练、推理、数据缓冲的三模块范式
slime 的核心设计哲学是解耦。它将 RL 训练流程拆分为三个独立模块：训练模块（基于 Megatron-LM）、推理模块（基于 SGLang 与 sgl-router）、数据缓冲区。这种分离并非简单的逻辑划分，而是针对 RL 工作负载特性的深度优化。
训练模块专注于梯度计算与参数更新，复用 Megatron-LM 成熟的张量、流水线、专家并行策略。推理模块则通过 SGLang 实现高吞吐、低延迟的序列生成，并利用 sgl-router 统一管理多节点推理服务。数据缓冲区作为粘合剂，负责 prompt 初始化、自定义数据注入以及 rollout 结果的暂存与分发。
这种架构带来的最大优势是灵活性。用户可以通过 HTTP 请求与 sgl-router 交互，将复杂的智能体环境直接接入训练流程，无需修改环境代码。同时，借助 Ray 进行资源管理，slime 支持同卡部署（colocated）与异卡部署（decoupled）两种模式，仅需一个--colocate标志即可切换。异步训练也通过 Ray 的.remote()调用自然实现，只需调整ray.get的同步点即可改变训练策略。
分布式奖励建模：数据流与计算流的分离
在传统 RLHF 流程中，奖励模型评估与策略模型生成往往耦合在同一个计算图中，导致内存占用高、难以扩展。slime 通过分布式奖励建模解决了这一问题。其关键是将奖励计算（或更广义的验证器输出）作为推理环节的一部分，在 SGLang 服务器中完成。
具体实现中，用户可以在自定义的 rollout 逻辑中，通过 SGLang 服务器提供的 OpenAI 兼容 API，同时获取策略模型的生成结果和奖励模型的评分。这些数据连同元信息被统一存入数据缓冲区。训练模块从缓冲区读取包含奖励信号的训练数据，进行 PPO 等算法的更新。这种分离使得奖励模型可以独立缩放，甚至部署在专用硬件上，避免了与策略模型争夺计算资源。
slime 团队与社区合作，为 SGLang 增加了/abort_request端点，以支持类似 DAPO 算法中的动态过采样需求。该端点能立即终止进行中的生成请求，并回收已生成的部分内容，实现部分 rollout，进一步优化了数据生成效率。
梯度累积的内存优化：从 CPU Adam 到通用内存卸载
MoE 模型训练最大的瓶颈之一是 GPU 内存。推理需要加载 fp8 量化参数，而训练则需要保存 bf16 参数、fp32 梯度、fp32 主参数以及 Adam 优化器的动量与方差状态，显存需求往往是参数量的 18 倍以上。slime 采用多级内存优化策略应对这一挑战。
第一层优化是CPU Adam。slime 利用 Megatron-LM 内置的 CPU Adam 实现，将优化器状态卸载到主机内存，仅保留当前计算所需的参数与梯度在 GPU 上。这使得训练 GLM-4.5 355B-A32B 这类巨型 MoE 模型所需节点数从 16 个降至 8 个，大幅降低硬件门槛。
第二层优化是通用 GPU 张量卸载。为了给 SGLang 推理预留更多 KV Cache 空间（通过提高mem_fraction至 0.7-0.8），slime 需要将 Megatron 训练部分的残留显存占用从 15-18GB 压缩到 3-5GB。团队没有采用笨拙地寻找并转移所有 GPU 张量的方法，而是创新性地通过LD_PRELOAD，在训练进程中用 CUDA 虚拟内存管理（VMM）API 替换CUDACachingAllocator使用的cudaMalloc和cudaFree。这样，当需要释放显存时，底层 VMM 层可以 “秘密地” 解除内存映射，而上层 PyTorch 应用无感知。此方案由 SGLang 社区的torch_memory_saver改进而来。
第三层优化针对NCCL 通信缓冲区。大型 MoE 模型因使用多种并行策略，NCCL 群组可能占用超 10GB 显存。slime 通过猴子补丁dist.new_group，包装一层ReloadableProcessGroup，在卸载 Megatron 时销毁 NCCL 群组，重新加载时再重建。虽然这会轻微影响每次训练迭代首次通信的速度，但换来了显著的显存节省和更好的框架维护性。
量化推理与延迟优化：突破单样本生成瓶颈
RL 训练与预训练的根本区别在于，其速度上限由单样本推理延迟决定，而非整体吞吐量。slime v0.1.0 集成了三项关键优化来推高这一上限。
fp8 量化推理：针对 RL 训练中长校准不切实际的特点，slime 选择 fp8 块状量化。结合 SGLang 的 fp8 支持，可将权重和激活值精度降至 8 位，显著减少内存访问量。
DeepEP 低延迟模式：对于跨机部署的 MoE 模型，专家间的 all2all 通信是主要延迟源。DeepEP 通过优化专家并行通信路径，降低跨节点延迟。slime 支持在训练和推理中同时启用 DeepEP。
推测采样：slime 允许加载任意草稿模型加速自回归生成。虽然当前版本不支持训练中更新草稿模型，但静态草稿模型仍能有效提升生成速度。
通过这三项优化，slime 将 GLM-4.5 355B-A32B 模型的单样本生成速度从不足 10 token/s 提升至 60-70 token/s，为 RL 训练速率带来数量级提升。
工程化部署参数与监控清单
基于上述优化，在实际部署 slime 进行大规模 RL 训练时，建议关注以下参数与监控点：
关键配置参数
--sglang-mem-fraction：SGLang 服务器 GPU 内存利用率，建议设置为 0.7-0.8，前提是已启用上述内存卸载。--sglang-enable-deepep-moe：启用 DeepEP 专家并行优化，对跨节点 MoE 模型至关重要。--sglang-enable-ep-moe与--sglang-enable-dp-attention：启用 MoE 推理的其他并行优化。--colocate：根据硬件拓扑选择同卡或异卡部署模式。同卡减少通信开销，异卡提供更大内存灵活性。--tensor-model-parallel-size等 Megatron 并行参数：根据模型规模与 GPU 数量精细调整。
核心监控指标
perf/longest_sample_tokens_per_sec：最慢样本的生成速度，直接决定 RL 训练迭代周期。- KV Cache 利用率：监控是否发生 KV Cache 溢出，溢出会导致生成任务排队等待，等效延长生成长度。
- 训练 MFU（模型浮点运算利用率）：通过 Megatron 内置监控，确保训练计算效率。
- 参数同步时间：记录权重从训练模块同步到推理模块的耗时，slime v0.1.0 对 355B 模型 bf16 权重同步需 48 秒，fp8 量化同步需 100 秒。
- 数据缓冲区吞吐：确保 rollout 生成的数据能及时被训练模块消费，避免成为瓶颈。
性能基准检查清单
在评估或对比 RL 训练框架时，可参考 slime 团队提出的定性检查点：是否支持 MoE 训练？推理内存占比能否超过 0.7？是否支持 fp8 或更低精度推理？是否支持 DeepEP？是否支持推测采样？是否集成高效训练后端（如 Megatron）并支持全部必要的并行策略？
局限与展望
尽管 slime 在性能优化上取得了显著进展，但其复杂度不容忽视。用户需同时理解 Megatron-LM 和 SGLang 两套系统，学习曲线陡峭。此外，万亿参数 MoE 模型的 RL 训练仍需数百甚至上千 GPU，硬件成本高昂。
未来，slime 团队计划进一步探索大规模 MoE 模型的最佳 RL 训练策略，增强更多后训练工作流支持（如 SFT、拒绝采样），并考虑添加原生 PyTorch 训练后端以降低入门门槛。随着框架的不断成熟，slime 有望成为 RL 规模化研究与实践的标准基础设施之一，推动智能体能力的边界向更复杂、更开放的任务演进。
参考资料
- slime GitHub 仓库：https://github.com/THUDM/slime
- slime v0.1.0 发布博客：https://thudm.github.io/slime/blogs/release_v0.1.0.html