RLinf：通过宏-微流变换实现灵活高效的大规模 RL 训练——原理详解

论文：RLinf: Flexible and Efficient Large-scale Reinforcement Learning via Macro-to-Micro Flow Transformation
机构：清华大学、中关村科学院、Infinigence AI、北京大学、UC Berkeley、北航、上海交通大学
发布时间：2025年9月
🔗 arXiv | PDF | 代码

一句话总结

RLinf 提出了 M2Flow（宏-微流变换） 范式：开发者用自然的过程式接口编写高层 RL 工作流（宏逻辑流），系统自动将其拆解并重组为在时间和空间维度上优化的执行流（微执行流），通过弹性流水线、上下文切换和 profiling 引导的调度策略，在 reasoning RL 上取得 1.1×–1.58× 加速，在 embodied RL 上取得 1.25×–2.13× 加速，同时训出的模型在数学推理和机器人操作 benchmark 上均达到 SOTA。

一、问题与动机

1.1 RL 已成为 LLM 时代的关键训练范式

随着预训练的 Scaling 回报趋于平缓，RL 成为推动大模型能力突破的核心范式。从 RLHF/GRPO 的推理对齐，到具身智能中的 VLA 后训练，再到 Deep Research 的搜索交互——各类 RL 工作流的计算需求正在急速增长。OpenAI 等预测 RL 的算力消耗将很快超过预训练。

1.2 RL 工作流的本质困难：异构 + 动态

与预训练不同，RL 工作流天然包含多个异构组件，每个组件的资源特征差异巨大：

组件	GPU 显存	GPU 算力利用率	并行策略	特殊需求
LLM 训练	高（需梯度+优化器状态）	高	DP + TP + PP	-
LLM 生成	中（KV Cache）	低（内存带宽瓶颈）	实例复制	长度动态变化
LLM 推理	低	中	实例复制	prefill-only
仿真器	低~中	低（<24%）	实例复制	CPU 物理仿真 + GPU 渲染

动态性同样是核心挑战。生成阶段的响应长度天然波动，具身任务的 episode 长度不一，Deep Research 的搜索交互次数不可预测——这些都导致批处理中出现严重的长尾问题：少数慢样本拖住整个阶段，大量 GPU 空闲等待。

1.3 现有执行模式的困境

当前 RL 系统基本采用两种执行模式，但两者都不是万能的：

执行模式	原理	优点	缺点
Collocated（共置）	所有组件分时复用同一组 GPU	简单、无通信开销	长尾效应严重，GPU 大量空闲
Disaggregated Pipeline（分离流水线）	组件分配到不同 GPU 上并行流水	缓解长尾	内存/计算不均衡，流水线气泡

以 embodied RL 为例：仿真器 GPU 利用率低但内存线性增长，不适合与生成共置；生成计算利用率高但时间长，不适合纯分离。最优策略往往是混合模式——但手动设计混合调度既复杂又脆弱，且不同工作流的最优方案不同。

1.4 核心洞察：灵活性是效率的关键

RLinf 的核心观察是：高效 RL 训练的主要障碍在于系统灵活性不足。开发者需要一个系统，能够让他们用简单直觉的方式编写工作流逻辑，而系统自动探索包括时间复用、空间流水线和混合调度在内的广阔调度空间，找到最高效的执行方式。

二、核心方法：M2Flow 范式

2.1 设计哲学：逻辑与执行的解耦

M2Flow 的核心思想可以用一个类比理解：

把写 RL 工作流想象成写剧本——编剧（开发者）只需要写清楚"谁先做什么、然后谁做什么、数据怎么传"的逻辑剧情（宏逻辑流）。至于"用几个摄影机、怎么调度拍摄顺序、哪些场景可以并行拍"这些执行细节（微执行流），交给导演（系统调度器）根据实际资源自动优化。

形式化地说：

宏逻辑流（Macro Logical Flow）：开发者用过程式接口描述的高层 RL 工作流，定义组件间的数据通信和同步关系
微执行流（Micro Execution Flow）：系统自动生成的细粒度执行计划，决定每个组件在何时（temporal）、何处（spatial） 以何种粒度执行

2.2 系统架构

RLinf 架构由四个核心模块组成：

┌─────────────────────────────────────────────────┐
│          过程式编程接口（Procedural API）            │
├─────────────────────────────────────────────────┤
│  Worker 抽象          │  调度器（Scheduler）         │
│  ├─ Communicator     │  ├─ Profiler              │
│  ├─ Offloading       │  ├─ Policy                │
│  └─ Data Channel     │  └─ Exec Flow Manager     │
├─────────────────────────────────────────────────┤
│       M2Flow 变换：弹性流水线 + 上下文切换            │
├─────────────────────────────────────────────────┤
│       数据平面：自适应通信层                          │
├─────────────────────────────────────────────────┤
│       集群管理（Ray）                               │
└─────────────────────────────────────────────────┘

2.3 Worker 抽象与编程接口

RLinf 采用过程式编程（而非图式声明编程），让开发者像写普通 Python 程序一样定义 RL 工作流。

Worker 基类提供三个核心能力：

通信原语：send(obj, dst) / recv(src) 实现任意 worker 间的点对点通信
资源管理：onload() / offload() 控制 GPU 资源的加载和释放
数据通道：基于 FIFO 队列的生产者-消费者通信，解耦控制流和数据流

WorkerGroup 将同一 worker 的多个进程统一管理，函数调用自动分发到所有进程，返回异步句柄。一个典型的 RL 工作流代码不到 100 行：

python

class RLWorkflowRunner:
    def run(self):
        for batch in batch_iterator:
            self._update_rollout_weights()       # 权重同步
            self.data_ch.put(batch)               # 数据入队
            self.rollout_group.generate(           # 生成（异步）
                in_channel=self.data_ch,
                out_channel=self.rollout_ch
            )
            self.actor_group.train(self.rollout_ch).wait()  # 训练（等待完成）

关键设计：wait() 提供显式的同步屏障。例如 GRPO 中 rollout 可以逐 query 流水，但归一化必须等所有响应就绪。

2.4 M2Flow 变换的两大机制

2.4.1 弹性流水线（Elastic Pipelining）——空间调度

弹性流水线控制数据处理粒度，实现灵活的空间调度。

核心洞察：RL 中大多数 worker 遵循 SPMD 模式，可以在任意 batch size 下执行。LLM 推理引擎（如 SGLang、vLLM）可以处理 1 个或 N 个 prompt，训练可以在不同的 micro-batch 粒度下运行。

Execution Flow Manager 可以：

细化粒度：将输出拆分为更小的 chunk，下游 worker 更早开始（减少流水线气泡）
粗化粒度：合并为更大的 chunk，减少调度开销

例如，对于一个包含 4 个 batch 的 rollout 任务：

4-to-4 流水线：rollout 每完成 1 个 batch 就传给下游
4-to-2 流水线：rollout 每完成 2 个 batch 才传给下游

2.4.2 上下文切换（Context Switching）——时间调度

上下文切换实现设备的时间复用：多个无法同时驻留 GPU（显存不足）的 worker，通过顺序执行共享设备。

实现机制是分布式设备锁（device lock）：

Worker 在使用 GPU 前必须获取锁
获取锁时自动调用 onload() 加载资源
完成后释放锁并调用 offload() 释放显存
下游 worker 只有在上游数据就绪且释放锁后才能获取锁

这个设计巧妙地利用了数据通道的依赖信息来定义锁的获取优先级，从而避免死锁和不必要的资源加载/卸载。

2.4.3 空间-时间混合调度

M2Flow 的真正威力在于将弹性流水线和上下文切换结合，覆盖完整的调度空间：

调度模式	适用场景	示例
纯时间调度	大模型训练必须占用所有 GPU	GRPO：生成→推理→训练顺序分时
纯空间调度	组件可以独立运行在不同 GPU 上	推理和训练分配到不同 GPU 组流水执行
混合调度	组件特征差异大，需要灵活编排	Embodied RL：仿真器+生成流水线，结束后切换为训练

2.5 Profiling 引导的调度策略

RLinf 通过自动搜索而非手动调优找到最优调度，核心是 Algorithm 1 中的递归分区算法：

输入：工作流图 $G$ 、设备数 $N$

过程：

预处理：将循环依赖折叠为单一节点
递归分区：对每条 s-t cut（将图分为两个子图 $G_{s}, G_{t}$ ），评估两种调度：
- 共享设备（时间调度）：代价 = $T_{s} + T_{t}$ + offload/onload 开销
- 分离设备（空间调度）：代价按流水线模型估算

流水线的执行时间估算为：

T = T_{critical} + (\frac{M}{m} - 1) \times T_{bottleneck}

其中 $T_{critical}$ 是流水线启动和清空时间， $T_{bottleneck}$ 是最慢子图的运行时间， $M$ 是总 batch 大小， $m$ 是数据处理粒度。

选择最优：取所有分区和调度方式中代价最小的方案
递归终止：子图退化为单个节点时，返回 profiling 测量的执行时间

通过动态规划缓存（ $D_{table}$ ），避免重复计算同一子图在相同设备数下的调度结果。

2.6 自适应通信层

RL 组件的空间和时间动态性要求通信层同时满足灵活性和高性能：

设计目标	实现方式
灵活性	透明的连接生命周期管理，worker 启动时注册到全局管理器，连接在首次通信时惰性建立
自适应	根据 worker 和数据的放置位置，自动选择最优后端：GPU-GPU 用 NCCL，同 GPU 内用 cudaIPC 零拷贝，CPU 间用 Gloo
数据动态性	支持任意 Python 对象作为通信负载，结构感知序列化（数据缓冲区直接传输，元数据附在通信头部）
负载均衡	Data Channel 支持带权重的 enqueue 和自定义的消费者负载均衡策略

三、实验结果

3.1 实验设置

维度	配置
测试集群	32 节点 × 8 H100-80GB GPU（共 256 GPU），NVLink + 8×400Gbps RoCEv2
Reasoning 模型	Qwen2.5-1.5B/7B/32B（DeepSeek-R1 蒸馏版）
Embodied 模型	OpenVLA（ManiSkill）、OpenVLA-OFT（LIBERO）
Reasoning baseline	veRL v0.5（SGLang + MegatronLM）
Embodied baseline	SimpleVLA-RL、RL4VLA
RL 算法	GRPO（Token-Level Loss + Minibatch Early-Stop）、PPO

3.2 Reasoning RL 端到端性能

在 GRPO 训练吞吐量（tokens/sec）上，RLinf 在所有模型规模和集群规模下均超越 veRL：

模型	64 GPU	128 GPU	256 GPU
1.5B	1.10×	1.25×	1.38×
7B	1.20×	1.35×	1.50×
32B	veRL OOM	1.40×	1.58×

veRL 扩展性差的两大原因：(1) log probability 计算成为瓶颈；(2) rollout 引擎显存占用过高，挤压了 KV cache 的可用空间。

在长上下文（28672 tokens）场景下，分离流水线模式相比共置模式额外获得 1.17×–1.21× 的加速，因为尽管 rollout 只分配了 40/64 的 GPU，端到端 rollout 时间仅增加 14%，而推理和训练可以与剩余 rollout 并行执行。

3.3 Embodied RL 端到端性能

ManiSkill（GPU 仿真器）：混合模式在 8 GPU 上取得 1.88× 加速，16–32 GPU 上为 1.61×–1.69×。

LIBERO（CPU 仿真器）：共置模式反而更优，取得 1.25×–2.13× 加速。原因是 LIBERO 瓶颈在 CPU rollout，共置模式将所有 GPU 资源集中给 rollout 阶段。

关键启示：不同工作流特征需要不同的调度策略，验证了 M2Flow 灵活调度的必要性。

3.4 模型性能

数学推理：RLinf 训出的模型在同规模 SOTA 中表现最佳：

模型	AIME 24	AIME 25	GPQA-diamond	平均
DeepSeek-R1-Distill-Qwen-1.5B（base）	28.33	24.90	27.45	26.89
FastCuRL-1.5B-V3	43.65	32.49	35.00	37.05
RLinf-math-1.5B	48.44	35.63	38.46	40.84
DeepSeek-R1-Distill-Qwen-7B（base）	54.90	40.20	45.48	46.86
AceMath-RL-Nemotron-7B	67.30	55.00	45.57	55.96
RLinf-math-7B	68.33	52.19	48.18	56.23

1.5B 模型相比基座提升 +14 分（平均），7B 模型在 GPQA-diamond 上领先所有对比模型。

具身操作：在 LIBERO benchmark 上，从单条轨迹 SFT 的 OpenVLA-OFT 出发，经 GRPO 训练后：

任务	SFT Baseline	RLinf	提升
Spatial	56.5%	99.0%	+42.5%
Object	25.6%	99.0%	+73.4%
Goal	45.6%	99.0%	+53.4%
Long	9.7%	94.4%	+84.7%
平均	34.4%	97.9%	+63.5%

从 34.4% 到 97.9% 的平均成功率提升尤为惊人，超越了 π₀（94.2%）和 UniVLA（95.2%）。

3.5 性能剖析

对 Qwen2.5-7B 的延迟分解显示，RLinf 的优势主要来自：

更快的 rollout：优化的推理引擎减少了 KV cache 显存浪费
更快的 logprob 计算：动作和 log probability 合并为单次 forward pass
流水线重叠：推理和训练可以与 rollout 并行执行

对 LIBERO 的分解显示，RLinf 在 rollout 和 training 阶段都更快，得益于：(1) 消除了 rollout 阶段的冗余环境初始化；(2) 单次 forward pass 同时计算动作和 logprob。

四、局限性与未来方向

调度搜索的可扩展性：当前的递归分区算法在组件数量很多或依赖关系复杂时，搜索空间可能爆炸。虽然有 $D_{table}$ 缓存和循环折叠的优化，但对于极端复杂的工作流（如多 agent 交互），调度效率可能下降。
故障恢复的粒度：当前的故障处理策略是"一旦任何 worker 崩溃，立即杀死整个系统"。这对于大规模长时间训练来说代价高昂，未来可以探索局部重启和 checkpoint 恢复机制。
跨异构加速器支持：当前主要针对同构 GPU 集群（H100）。随着 RL 工作流中 CPU、GPU、NPU 等异构硬件的混合使用日益普遍，M2Flow 的调度策略需要扩展到异构场景。
动态在线重调度：当前的调度决策在 profiling 阶段确定后固定不变。但 RL 训练过程中，模型的生成长度分布、任务难度等都在变化，理想情况下调度策略应该能够在线自适应调整。

五、个人思考

5.1 "RL 的操作系统"——一个恰当的愿景

论文结尾将 RLinf 定位为"AI 工作负载的操作系统的早期步骤"。这个定位是准确的：正如操作系统将程序逻辑与 CPU 调度、内存管理解耦，M2Flow 将 RL 工作流逻辑与 GPU 调度、通信管理解耦。这不是一个"更快的框架"，而是一种新的系统设计范式。

5.2 灵活性 vs 效率的非对立

传统系统设计中，灵活性和效率常常被视为对立的——灵活的系统引入更多间接层和开销，专用系统更快但适用范围窄。RLinf 的贡献在于证明：通过正确的抽象层次（M2Flow），灵活性可以成为效率的来源。关键是找到了 RL 工作流中"逻辑不变、执行可变"的自然分界线。

5.3 Embodied RL 的系统瓶颈被低估了

项目中已有的 VLA RL 论文（RISE、VLA-RL、WoVR）主要关注算法层面的创新。但 RLinf 的 embodied RL 实验揭示了一个容易被忽视的事实：系统效率同样是具身 RL 的关键瓶颈。即使算法不变，仅通过更好的系统调度就能将训练吞吐提升 2× 以上，这意味着在相同的硬件和时间预算下可以做两倍多的 RL 迭代。

5.4 LIBERO 结果的意义

LIBERO 上从单条轨迹 SFT 的 34.4% 到 97.9% 的飞跃，以及超越 π₀ 和 UniVLA 这些用大量数据训练的模型，传递了一个强烈信号：RL 后训练可以弥补数据量的不足。这与 reasoning RL（如 DeepSeek-R1）的发现一致——RL 的价值不仅在于微调，更在于发现训练数据中不存在的行为策略。

5.5 从"单点优化"到"全栈思维"

RLinf 提醒我们，RL 后训练不仅仅是算法问题。一个完整的 RL 训练 pipeline 涉及模型推理、环境交互、奖励计算、策略更新、权重同步等多个阶段。任何单点的优化如果没有系统层面的配合，效果都会被瓶颈稀释。未来 VLA RL 领域的竞争，可能不仅是算法的竞争，也是系统工程能力的竞争。

参考

veRL (HybridFlow)：RLinf 在 reasoning RL 上的主要对比基线，采用共置执行模式的 RLHF 框架
SimpleVLA-RL：基于 veRL 扩展的 VLA RL 框架，RLinf 在 LIBERO 上的对比基线
RL4VLA：VLA 的高效 PPO 训练方案，RLinf 在 ManiSkill 上的对比基线
AReal：引入异步模型更新的任务分离式 RL 系统，RLinf 的调度空间涵盖了其异步流水线模式
GRPO (DeepSeekMath)：RLinf 支持的核心 RL 算法之一，单 LLM 多响应 + 组内对比
PPO (Schulman et al.)：RLinf 支持的经典 RL 算法，用于 embodied RL 训练
OpenVLA / OpenVLA-OFT：RLinf 在具身 RL 中使用的基座 VLA 模型
ManiSkill / LIBERO：RLinf 具身 RL 实验使用的两个仿真环境 benchmark

幻觉缓解

Token 压缩

基础模型

高效推理

推理增强

RL 后训练

RLinf：通过宏-微流变换实现灵活高效的大规模 RL 训练——原理详解 ​

一句话总结 ​

一、问题与动机 ​

1.1 RL 已成为 LLM 时代的关键训练范式 ​

1.2 RL 工作流的本质困难：异构 + 动态 ​

1.3 现有执行模式的困境 ​

1.4 核心洞察：灵活性是效率的关键 ​

二、核心方法：M2Flow 范式 ​

2.1 设计哲学：逻辑与执行的解耦 ​

2.2 系统架构 ​

2.3 Worker 抽象与编程接口 ​

2.4 M2Flow 变换的两大机制 ​

2.4.1 弹性流水线（Elastic Pipelining）——空间调度 ​

2.4.2 上下文切换（Context Switching）——时间调度 ​

2.4.3 空间-时间混合调度 ​

2.5 Profiling 引导的调度策略 ​

2.6 自适应通信层 ​

三、实验结果 ​

3.1 实验设置 ​

3.2 Reasoning RL 端到端性能 ​

3.3 Embodied RL 端到端性能 ​

3.4 模型性能 ​

3.5 性能剖析 ​

四、局限性与未来方向 ​

五、个人思考 ​

5.1 "RL 的操作系统"——一个恰当的愿景 ​

5.2 灵活性 vs 效率的非对立 ​

5.3 Embodied RL 的系统瓶颈被低估了 ​

5.4 LIBERO 结果的意义 ​

5.5 从"单点优化"到"全栈思维" ​

参考 ​