GLM-5.2 背后的 RL 训练框架：slime 如何让训练-推理-数据跑在同一条路上

大语言模型的后训练（post-training）是一个工程难题。不是算法难——RLHF/GRPO/PPO 的公式论文里都写得清清楚楚——而是工程难。

你需要一个训练框架（比如 Megatron）来更新模型权重，一个推理引擎（比如 SGLang/vLLM）来生成 rollout 数据，一个数据缓冲区来管理训练样本，一个奖励计算模块来打分，可能还需要一个环境交互模块来处理 agentic 任务。这些组件各自都是复杂的系统，把它们拼在一起跑通一个完整的 RL 训练循环，是真正痛苦的事情。

slime 是清华 THUDM 团队开源的 RL 后训练框架，它背后的模型你可能更熟悉：GLM-5.2、GLM-5.1、GLM-5、GLM-4.7、GLM-4.6、GLM-4.5。

这不是一个"参考实现"——它是真正训练了这些模型的工具。

核心设计：一条路径，三个角色

slime 最关键的设计决策是：训练、rollout、数据生成走同一条路径。

很多 RL 框架的设计是"积木式"的：训练器是一个服务，rollout 引擎是另一个服务，数据生成是第三个服务，它们之间通过 API 或消息队列通信。这种设计的好处是模块化，坏处是调试困难——RL 训练中的 bug 通常是静默的（模型看起来在学，实际上在学错的东西），当数据流经多个服务时，定位问题源头非常痛苦。

slime 的设计是"管道式"的：Megatron 训练、SGLang rollout、自定义数据生成、奖励计算、验证器反馈、环境交互——所有这些组件都流经同一个"训练/rollout/数据缓冲"路径。

这个设计的好处不是性能（管道式和积木式性能差不多），而是可调试性。当所有数据流经同一条路径时，你可以在一个地方看到完整的数据流：模型生成了什么、奖励函数打了多少分、数据缓冲区里存了什么、训练器用了哪些样本更新了权重。

Megatron + SGLang：为什么选这两个

slime 选择了 Megatron（训练）和 SGLang（推理）作为核心引擎，并且"原生"地暴露它们的参数——不是封装一层抽象，而是直接透传。

这个选择背后有一个明确的哲学：不做最低公分母抽象。

很多框架试图同时支持多个训练后端（Megatron、DeepSpeed、FSDP）和多个推理后端（vLLM、SGLang、TensorRT-LLM）。为了统一接口，它们会抽象出一层"通用训练器接口"和"通用推理接口"。问题是，不同后端的能力是不同的——SGLang 支持的某些推理优化在 vLLM 里没有，Megatron 的某些并行策略在 DeepSpeed 里不支持。

为了统一接口，框架只能取交集——所有后端都支持的功能。这就是"最低公分母抽象"：你为了兼容性牺牲了每个后端的独特能力。

slime 不做这件事。它只支持 Megatron + SGLang 这一条路径，但把这两个引擎的参数直接暴露出来。你可以用 SGLang 的所有高级特性（比如 --sglang- 前缀的参数），不需要等框架去适配。

数据生成自由度：不只是数学和代码

RL 后训练的核心是训练数据。不同的任务需要不同的数据生成方式：

• 数学：需要数学题 + 答案验证器
• 代码：需要代码题 + 测试用例
• 搜索：需要搜索环境 + 答案匹配
• 工具使用：需要工具 API + 调用验证
• 多智能体：需要环境 + 交互协议

很多框架对每种任务类型提供专门的 trainer——数学 trainer、代码 trainer、agent trainer。问题是这些 trainer 之间不共享基础设施，添加新任务类型需要从头实现。

slime 的设计是：把数据生成和奖励计算作为"插件"接入统一的训练路径。数学、代码、搜索、工具、沙箱、验证器、环境、多智能体系统、长程 agentic 工作流——这些都作为数据生成或奖励工作流接入，不需要 fork 训练内核。

这意味着添加新任务类型只需要写一个数据生成脚本和一个奖励函数，不需要改训练代码。

"Battle-tested" 的真正含义

slime 的 README 里有一句话："one of the most battle-tested open RL post-training frameworks"。

这个 claim 的支撑是：GLM-5.2、GLM-5.1、GLM-5、GLM-4.7、GLM-4.6、GLM-4.5 都是用 slime 训练的。这不是在 toy dataset 上验证的框架，是在真实模型发布流程中验证的。

"Battle-tested" 意味着 slime 经历过所有 RL 训练中会遇到的工程问题：

• 权重同步：训练器更新权重后，rollout 引擎需要加载新权重。同步时机不对会导致 rollout 用旧权重生成数据
• 故障恢复：RL 训练通常跑几天到几周，中间节点崩溃是常态。需要 checkpoint 机制能恢复到正确的状态
• 调试路径：slime 支持 rollout-only 和 train-only 模式，可以分别调试推理和训练
• 可复现性：RL 训练的随机性来源多（采样、数据洗牌、分布式训练），需要显式记录所有随机种子

这些不是"功能"，是"经历过痛苦后的修复"。一个没有真正训练过大模型的框架，不会想到这些工程细节。

支持的模型生态

除了 GLM 系列，slime 还支持：

• Qwen 系列：Qwen3.6、Qwen3.5、Qwen3Next、Qwen3MoE、Qwen3、Qwen2.5
• DeepSeek V3 系列：DeepSeek V3、V3.1、DeepSeek R1
• Llama 3

这个支持列表说明 slime 不是 GLM 专属工具——它是一个通用的 RL 后训练框架，只是恰好被 GLM 团队开发并验证。

RL 后训练的基础设施化

slime 的出现指向一个趋势：RL 后训练正在从"研究实验"变成"工程基础设施"。

两年前，RLHF 还是一个需要从论文复现算法、自己写训练循环、自己搭 rollout 服务的研究课题。现在，像 slime 这样的框架把整个流程打包好了：你提供模型和数据生成逻辑，slime 负责训练循环、rollout 调度、权重同步、故障恢复。

这和 NLP 领域的 HuggingFace Transformers 做的事情类似——把训练大模型从"研究课题"变成"工程任务"。区别是，slime 聚焦的不是预训练，而是 RL 后训练。

当 RL 后训练的基础设施成熟后，更多的团队可以做 RL 训练实验。这可能会催生一批新的 RL 训练方法——就像 HuggingFace 让更多人能做预训练实验一样。

相关链接：

• GitHub: https://github.com/THUDM/slime
• 文档: https://thudm.github.io/slime
• GLM 系列: https://github.com/THUDM