λLLM Wiki
4 min read#reading-guide#rlhf#sglang#slime#verl

Reading Guide to Zhaochenyang20's RL Systems Blog Series

M
memset0
Apr 7, 2026

这是一份面向阅读路径的导览页，把 zhaochenyang20 关于 RL 系统的博客按主题和依赖关系组织成七章。目标不是复述每篇文章，而是说清楚每篇在讲什么、为什么放在这个位置、以及它和哪些知识点相关——让你能带着问题进入原文。

整套文章围绕两个核心实体展开：sglang（推理与 rollout serving 引擎）和 slime（RL 训练系统平台）。它们之间的关系是：slime 负责上层 RL 训练循环，sglang 负责下层推理运行时，两者在权重更新、rollout 吞吐、训推一致性等问题上深度耦合。

怎么使用这份导览

  • 如果想先建立全局框架，从第一章（问题意识）和第四章（训练后端）开始。
  • 如果更关心 RL 训练稳定性和 同策略/异策略 取舍，优先读第一章和第二章。
  • 如果更关心 sglang 推理系统内部实现，优先读第五章和第六章。
  • 如果更关心 多轮 agent 训练，优先读第三章。

第一章：先建立 RL 训练问题意识

这一章回答最基本的问题：大模型 RL 到底在和什么系统问题搏斗，为什么 rollout 端的工程质量会直接影响训练效果。

推荐顺序：

  1. Training-Inference Mismatch in RL and Its Mitigations — 系统讨论 rollout 引擎与训练引擎的数值不一致来源，以及 truly on-policy、TIS/MIS 等纠偏方法
  2. GRPO in SGLang — 介绍 GRPO 算法在 sglang 中的实现，包括 rollout、权重同步和训练流程的工程细节
  3. Partial Rollout for Long-Context RL — 介绍 partial rollout 如何通过牺牲严格 同策略(On-Policy) 保证，换取长上下文场景下更高的资源利用率

阅读重点：

  • 第一篇建立全文最重要的主线：训推不一致(Training-Inference Mismatch)。核心发现是即使权重相同，rollout 引擎和训练引擎的 logits 也会因为 CUDA 算子、batch size、reduction order 等差异而不同步。dense 模型的 KL 散度通常在 10−510^{-5} 到 10−310^{-3}，MoE 模型可达 10−310^{-3} 到 10−110^{-1}。文章给出两条修正路线：（1）bit-level 对齐的 truly on-policy 模式；（2）用截断重要性采样(MIS)做算法纠偏。
  • 第二篇补上 GRPO 这个训练算法入口。GRPO 去掉了 PPO 的 critic model，改为在组内对 reward 做归一化来计算 advantage。工程上的关键点是 sglang 作为外部服务运行（不像 vLLM 可以 in-process），权重更新通过 HTTP 接口 /update_weights_from_tensor 传输序列化的 handle tuple，而不是拷贝整个 tensor。
  • 第三篇把视角拉到长上下文和长尾样本。核心矛盾是：严格 on-policy 要求所有样本在同一策略版本下采完再训，但长上下文任务会导致少数样本拖慢整个 batch。partial rollout 允许已完成的样本先进入训练，剩余样本继续用旧策略生成——这是效率与算法严谨性之间的务实妥协。

第二章：理解 slime 里的 RL 加速与低精度路线

在第一章建立问题意识之后，这一章关心：如何在不破坏训练效果的前提下，通过低精度和投机采样把 rollout 和训练做快。三篇文章构成”speculative decoding → FP8 → INT4”的递进关系。

推荐顺序：

  1. Speculative Decoding for RL Rollouts in Slime — 在 slime 中引入 EAGLE MTP draft model 做投机解码，且 draft model 随主模型在线训练以维持 accept rate
  2. FP8 Training and Rollout for RL in Slime — 训练端和 rollout 端同时使用 FP8，分析吞吐收益和训推一致性影响
  3. End-to-End INT4 Quantization-Aware RL Training in Slime — 从训练到 rollout 的 INT4 QAT 闭环，包括 Fake Quantization、STE、Marlin 内核适配

阅读重点：

  • 第一篇的核心创新是在线 MTP 训练。draft model 不是冻结的，而是用主模型 hidden states 做 cross-entropy loss 持续更新。这样即使主模型策略在 RL 中不断漂移，draft model 的 accept rate 也能保持。实测比冻结 MTP 提升 14-25% 的 rollout 吞吐，总计约 35%。
  • 第二篇从精度格式讲起：E4M3（精度优先）vs E5M2（范围优先），以及为什么当前 Hopper 硬件上更倾向用 FP32 scale 而非 E8M0 block scaling。FP8 的直接收益是显存减半、吞吐翻倍，同时还能缓解 MoE 模型的训推不一致——因为训练端也用低精度，数值行为更接近 rollout 端。
  • 第三篇是最偏工程的一篇。INT4 QAT 的关键链路是：Fake Quantization + STE 让低精度梯度可回传 → 训练完成后把权重转成真正的 INT4 格式 → 用 Marlin 内核在 rollout 端高效推理。

第三章：多轮 Agent 训练怎么组织

这一章把视角从单轮回答转向 多轮交互。核心问题是：环境、tokenization、rollout loop、tool use 和训练 masking 怎么组合在一起。

推荐顺序：

  1. Unified Multi-Turn RL for VLM and LLM in Slime — slime 中统一 VLM 与 LLM 多轮训练的设计哲学和 rollout 循环
  2. Tokenizer-Level Complexities in Agentic Multi-Turn Training — 多轮训练中增量分词和 loss mask 的工程难题
  3. AgentLoop Code Walkthrough in VERL — VERL 多轮 agent loop 的代码路径和控制逻辑
  4. DAPO Dynamic Filtering and Batch Size in VERL — DAPO 动态过滤、batch size 控制和优势计算
  5. Profiling Time Costs in VERL Multi-Turn Training — 多轮 tool use 场景下的 profile 数据和时间开销分析

阅读重点：

  • 第一篇是这一章的纲领。slime 的核心设计是把 rollout 逻辑和 environment 实现解耦：用户提供自定义 rollout_function_path 来处理任意交互协议。多轮循环的每一步是”生成 action tokens → 执行环境 → 编码 observation delta → 更新多模态状态”。训练时只对 action token 计 loss（loss_mask=1），observation token 不参与监督（loss_mask=0）。
  • 第二篇解决多轮训练中最容易被低估的问题。带 think token 的模型（QwQ、Qwen3）的 chat template 行为是位置敏感的——非末尾消息会被删掉 reasoning 内容，导致增量分词和全量分词结果不一致。最终方案是用固定的 BASE_CONVERSATION 作为分词参考点，防止模板引入位置依赖的默认行为。
  • 第三、四篇进入代码路径。第三篇帮你建立对 VERL agent loop 控制流的具体理解；第四篇讲 DAPO 的动态 batch filtering 如何和多轮 rollout 配合。
  • 第五篇用 profile 数据回答”为什么慢”。它把多轮 tool use 的时间开销拆到各环节，帮你判断优化应该投入在哪里。

第四章：RL 训练系统后端怎么搭起来

这一章关注训练基础设施本身。读完之后你会理解为什么权重更新、并行策略、MoE 架构这些”看起来是训练的事”，会反过来约束 rollout 和 在线权重刷新 的设计。

推荐顺序：

  1. Weight Update Mechanisms in RL Systems — handle tuple 序列化、三种权重更新接口、slime 的 bucket 策略
  2. FSDP as a Training Backend for RL Systems — FSDP1/FSDP2 差异、延迟初始化、reference model 的 CPU offload
  3. Megatron Parallelism in RL Systems — TP/PP/DP 三维并行、Megatron-Core 的 MoE 支持和 scaling 特性
  4. DeepSeek MoE, Expert Parallelism, and FSDP Engineering — 细粒度 MoE 架构、EP vs TP 通信代价分析、DeepEP 的 RDMA 直接转发
  5. Extending the OpenRLHF Inference Engine — OpenRLHF 开发日志，记录另一条实现路线的工程改造与问题排查

阅读重点：

  • 第一篇是最关键的起点。核心技术是 handle tuple 序列化：把 FSDP 参数聚合成完整 tensor 后，只序列化内存句柄和元数据（不拷贝数据本身），在 sglang 端反序列化并通过 CUDA IPC 共享。slime 额外实现了 bucket 策略——对 Megatron 的 PP/EP 维度做分桶上传，避免一次性物化全部参数导致 OOM。
  • 第二篇从 FSDP 讲训练后端。FSDP2 用 DTensor 替换了 FSDP1 的 FlatParameter，支持逐参数元数据管理和更好的 checkpoint 效率。延迟初始化（先在 fake device 上构造，逐层物化再分片）是解决十亿参数模型冷启动 OOM 的关键。
  • 第三篇展开三维并行：TP 切层内权重，PP 把层分配到不同 GPU 做 microbatch 流水线，DP 复制后做梯度 all-reduce。Megatron-Core 对 MoE 有专门支持（token-dropless routing、多种负载均衡策略），在 MoE 场景下显著优于 DeepSpeed。
  • 第四篇聚焦 MoE 的并行通信选择。EP 的 All-to-All 流量是 2k×S/N2k \times S/N（kk 为激活专家数），TP 的 ring all-reduce 流量恒为 2S2S——所以激活专家越少，EP 通信优势越大。但 EP 跨节点走 RDMA（50-100 GB/s），TP 走节点内 NVLink（900 GB/s）。DeepEP 通过 RDMA 直接转发 + Stream-K overlap 把 All-to-All 延迟藏进计算中，使 EP 在 MoE 场景下成为更优选择。

第五章：SGLang 推理内核与运行时结构

这一章深入 sglang 内部。建议在理解第四章之后再看——否则容易把这里的优化点当成零散技巧，而看不到它们和 RL 训练后端之间的呼应关系。

推荐顺序：

  1. How Models Are Loaded in SGLang — 从权重读取、格式适配到运行时初始化的完整链路
  2. SGLang KV Cache Code Walkthrough — kv-cache 的池化映射、paged allocation 与 radix cache 的代码实现
  3. SGLang Scheduler Overview — 调度器的 continuous batching、prefill-first 策略和类 TCP 拥塞控制
  4. Data-Parallel Attention in SGLang — DP attention 如何减少 KV 复制并改善特定模型结构的吞吐瓶颈

阅读重点：

  • 先看模型加载，建立运行时入口。这篇讲清楚从磁盘上的权重文件到 GPU 上可运行的模型之间经过了什么——格式适配、并行切分、初始化顺序。这些细节在你后面读在线权重更新（第六章）时会直接相关。
  • 第二、三篇适合一起读。kv-cache 管理是 调度器做所有决策的基础——scheduler 调度的不是”文本长度”而是可用的 KV 容量和 prefix 可复用程度。KV cache 文章讲 ReqToTokenPool / TokenToKVPool 两层映射和 radix cache；scheduler 文章讲基于这些结构的 continuous batching、prefill-first 调度、in-batch prefix caching 和类 TCP 拥塞控制（用 new_token_ratio 动态试探 GPU 显存极限）。
  • DP attention 那篇是对特殊模型结构的系统级适配。理解了它之后更容易看清 sglang 不只是做通用 runtime，而是会针对模型结构做专门优化。

第六章：在线权重更新与服务侧延迟优化

这一章和第四章形成闭环：第四章从训练端讲权重怎么组织和序列化，这一章从 serving 端讲权重怎么接收和热加载。核心知识点见 sglang-online-weight-updates。

推荐顺序：

  1. Online Weight Updates in SGLang — 在线权重更新的实现思路：分层调用链路、进程组广播、与离线加载的区别
  2. Latency Acceleration for Weight Updates in SGLang — 如何缩短权重切换路径、减少同步等待、提升可用性

阅读重点：

  • 第一篇回答”怎么更新”。更新调用链分三层下传：Runtime 接请求 → TpModelWorker 分发到 worker → ModelRunner 写入模型。关键区别是 online_update_weights（trainer 通过分布式通信直接广播参数）vs 传统 update_weights（从磁盘重新加载），前者更适合 RL 场景。
  • 第二篇回答”怎么把更新做得足够快”。权重更新延迟不只是广播时间——参数准备、广播、load 到 module、同步 barrier 都会叠加。文章强调必须用 torch.cuda.synchronize() 做准确测量。真正的难点还包括参数格式兼容（dtype、分片方式、量化格式必须和 serving 端一致）以及 cache 状态处理（权重变了，旧请求的 logits 分布就不再匹配新模型）。

第七章：从 SGLang 的视角回看推理加速

这一章只放一篇，但值得单独抽出来——它和第二章里 slime 的 speculative decoding 刚好形成”推理框架通用实现”与”RL rollout 特定改造”两个视角。

建议对照阅读：

  1. 先读这篇，理解 speculative decoding 作为通用推理加速机制的原理和实现
  2. 再回读第二章的 Speculative Decoding for RL Rollouts in Slime，看 slime 在 RL 场景下做了什么额外改造（在线 MTP 训练、随策略漂移更新 draft model）

这样更容易看清通用加速和 RL 特化之间的边界。

两条推荐阅读路线

路线 A：先学 RL 训练系统

第一章 → 第四章 → 第二章 → 第三章

先从训推不一致建立问题意识（第一章），再理解训练后端的基础设施（第四章），然后看 slime 的加速手段（第二章），最后进入多轮 agent 场景（第三章）。

路线 B：先学 SGLang 与 rollout serving

第五章 → 第六章 → 第七章 → 第一章

先深入 sglang 运行时内部（第五章），再看权重热更新（第六章）和推理加速（第七章），最后回到 RL 训练侧理解为什么这些能力是必要的（第一章）。

贯穿全文的四条主线

  • 训推一致性(Training-Inference Alignment)：从第一章的 mismatch 分析、第二章的 FP8/INT4 统一精度、到第六章的 online weight update，本质都在解决”训练和推理不是两套独立系统”这个问题。对应知识点 on-policy-vs-off-policy-rl、sglang-online-weight-updates。
  • rollout 吞吐(Rollout Throughput)：partial rollout、speculative decoding、scheduler 调度、kv-cache 管理、weight update 延迟——这些文章都在围绕”怎么让采样更快”这个目标。
  • 多轮 agent 训练(Multi-turn Agent Training)：第三章的 slime + VERL 文章是理解 多轮 RL 最直接的一条线，从设计哲学到 tokenization 工程到 profile 数据。
  • 训练后端(Training Backend)：FSDP、Megatron、MoE 不是背景知识，而是决定 RL 系统规模上限的核心部分。第四章的四篇构成一套”训练后端导论”。

Comments