Verl vs AReaL | Blog de Simon🫣

type

status

date

slug

summary

1. 绪论：RLHF训练范式的效率瓶颈与演进

随着大型语言模型（LLM）从预训练（Pre-training）和监督微调（SFT）阶段迈向强化学习（RL）阶段，特别是强化学习人类反馈（RLHF）及其变体（如RLAIF、RLEF），训练系统的效率问题日益凸显。

不同于SFT阶段相对固定的数据流和计算模式，RLHF引入了复杂的四模型交互（Actor, Critic, Reward, Reference）以及生成（Rollout）与训练（Training）交替的动态过程。这种复杂性导致了传统同步训练框架在GPU资源利用率上的显著下降，主要表现为计算气泡（Bubbles）和长尾延迟效应。

📎

1. 长尾延迟效应 (Long-tail Latency Effect)

定义： 长尾延迟是指在批量（Batch）处理任务时，极少数样本的处理时间远远超过平均处理时间，形成了一个“长尾”分布。在 LLM 生成（Rollout）阶段，这种现象尤为严重。

长度方差极大： 训练推理模型（如 o1, DeepSeek-R1 类）时，模型通过思维链（Chain-of-Thought, CoT）进行思考。对于同一个 Prompt，模型可能在一次尝试中只生成 200 个 Token 就结束（例如认为问题无解），而在另一次尝试中生成 10,000 个 Token（进行了深度搜索和回溯）。

不可预测性： 这种生成长度的差异是动态的、难以预先知道的。

木桶效应： 在同步训练框架（如 verl 的标准 PPO 流程）中，一个 Batch（例如 64 个样本）的处理时间并不取决于平均长度，而是严格取决于最长的那一条样本。这就是长尾样本“拖累”整体进度的现象。

2. 计算气泡 (Computational Bubbles)

定义： 计算气泡是指在并行计算中，由于任务完成时间不一致，导致部分计算单元（GPU）在等待其他单元完成任务时处于闲置（Idle）状态。这段闲置的时间窗口被称为“气泡”。

形成过程（以同步 RLHF 为例）： 假设你有 4 张 GPU，正在并行生成 4 条数据（Batch Size = 4）：

GPU 1: 生成了 500 tokens，耗时 1秒。

GPU 2: 生成了 600 tokens，耗时 1.2秒。

GPU 3: 生成了 400 tokens，耗时 0.8秒。

GPU 4 (长尾样本): 生成了 8,000 tokens，耗时 16秒。

结果：

同步屏障（Barrier）： 为了进行下一步（Reward 模型打分或 PPO 训练），系统必须等待 GPU 4 完成。

气泡产生：

GPU 3 在 0.8秒时工作结束，它必须空转等待 15.2秒（16 - 0.8）。这段 15.2秒的时间就是“计算气泡”。
GPU 1 等待 15秒。
GPU 2 等待 14.8秒。

资源浪费： 在这个 Batch 的 16秒周期内，绝大部分 GPU 的利用率可能不到 10%。这就是为什么 AReaL 论文中指出同步系统在处理变长推理任务时 GPU 利用率低下的根本原因。

1.1 RLHF计算流的固有缺陷

标准的PPO（Proximal Policy Optimization）训练循环通常包含以下串行阶段：

生成阶段（Make Experience）： Actor模型根据提示词（Prompts）生成回复序列。

评估阶段（Evaluation）： Reward模型对回复打分，Critic模型评估状态价值，Reference模型计算KL散度约束。

学习阶段（Learn）： 基于优势函数（Advantage）和价值损失（Value Loss）更新Actor和Critic的参数。

在同步架构中，所有GPU设备必须等待这一批次中最长的序列生成完毕才能进入下一个阶段。

由于LLM生成长度的极大方差（Variance），短序列生成完成后，GPU计算单元将长时间处于闲置状态，仅保留显存占用，这种现象被称为“Padding Bubbles”或“Idle Time”。

AReaL与verl的架构创新，核心均在于试图打破或缓解这一串行依赖，但两者选择的路径截然不同。

2. 架构哲学对比：HybridFlow 与完全异步

在深入具体的异步实现细节之前，必须明确verl和AReaL在系统设计哲学上的根本分歧。verl倾向于通过灵活的编程模型优化数据流图，以在保持算法数学严格性（On-Policy）的前提下最大化吞吐；而AReaL则激进地解耦了生成与训练，引入了算法上的近似（Off-Policy Staleness）以换取极致的硬件利用率。

2.1 verl：混合流（HybridFlow）架构解析

verl 的核心创新在于提出了 HybridFlow 编程模型

传统的RL框架通常分为两类：单控制器（Single-Controller）模式，易于编程但调度开销大

多控制器（Multi-Controller）模式，执行效率高但难以扩展新算法。HybridFlow试图融合两者之长。

2.1.1 HybridFlow的“异步”定义

当verl被描述为支持“异步”时，其含义主要体现在数据流图（Dataflow Graph）层面的非阻塞调度，而非破坏PPO算法同步性的“参数异步”。

解耦控制流与计算流： 在 verl 中，通过 Ray 等分布式后端，控制平面（Driver/Controller）与计算平面（Workers）是分离的。Controller 下发任务（如actor.generate_sequences()）后，会立即获得一个Future对象，而无需阻塞等待结果返回。

流水线并行（Pipelining）： 利用这种非阻塞特性，verl 可以在 Actor 进行生成的过程中，预取下一个批次的数据，或者并行调度 Critic 模型的初始化工作。

3D-HybridEngine： verl 针对 RLHF 特有的“生成-训练”切换开销，设计了3D-HybridEngine 1。它允许Actor模型在生成阶段和训练阶段采用不同的并行策略（例如生成时使用张量并行TP，训练时使用完全分片数据并行FSDP），并通过高效的通信原语在两个阶段间通过NCCL重新分片（Resharding）参数。

关键局限： 尽管 verl 支持异步API，但在标准的PPO实现中，为了保证策略的同分布性（On-Policy），Controller通常会显式地调用ray.get()或类似原语来同步等待当前批次的所有Rollout完成，然后再启动训练步骤。

因此，在端到端的PPO流程中，verl表现出的是强同步（Synchronous）特性，即GPU依然存在等待“长尾样本”完成的闲置时间。

2.2 AReaL：完全异步（Fully Asynchronous）架构解析

AReaL的设计初衷是为了彻底消除同步等待带来的计算气泡。它不仅仅是在编程模型上支持异步，而是从系统架构上将生成集群（Rollout Workers）和训练集群（Trainer Workers）进行了物理或逻辑上的完全割裂。

2.2.1 AReaL的“异步”定义

AReaL的“异步”是指生成任务与训练任务在时间轴上的完全重叠与解耦。

无阻塞生成（Non-blocking Rollout）： Rollout Worker也是一个独立的死循环进程。它不断地从任务队列中获取Prompt，利用当前的策略参数生成数据，并推送到重放缓冲区（Replay Buffer）。它绝不等待训练器的指令，也不等待训练结束。

无阻塞训练（Non-blocking Training）： Trainer Worker是一个独立的死循环进程。它不断从Replay Buffer中采样数据（可能是由甚至更早的策略生成的），计算梯度并更新参数。

参数异步同步（Asynchronous Weight Sync）： 当Trainer完成一次参数更新后，会将新权重广播（或通过共享存储）发送出去。Rollout Worker在检测到新权重时，会尝试加载。最关键的是，这种加载可能发生在Rollout Worker正在生成某个长序列的中间时刻。

这种设计使得AReaL的GPU利用率几乎可以达到100%，因为没有任何设备在等待其他设备。但它引入了数据陈旧性（Data Staleness），即训练所用的数据是由旧版策略生成的（Off-Policy）。

3. 深度案例分析：异步机制的具体运作流程

为了回应用户关于“异步在哪里”的详细追问，本节将构建一个毫秒级的微观时间线，对比verl（标准模式）与AReaL在处理同一批任务时的行为差异。

📎

场景假设：

系统包含两组GPU资源：Group A（用于Actor生成/训练），Group B（用于Critic/Reward）。

任务：需要完成Batch 的训练。

样本情况：Batch 中包含一条极长序列（生成耗时10秒），其余均为短序列（生成耗时2秒）。

3.1 对照组：verl (Synchronous PPO) 的时间线

时间 (Time)	Controller行为	Group A (Actor) 状态	Group B (Critic) 状态	系统状态分析
T=0s	发送Rollout指令	开始生成 Batch	闲置 / 等待	全系统忙碌
T=2s	等待结果	生成完毕，显存保留KV Cache，计算单元停机	闲置	计算气泡出现：处理短序列的GPU开始空转，等待长序列。
T=5s	等待结果	仅处理的GPU在工作，其余GPU空转	闲置	资源浪费严重。
T=10s	收到所有结果	生成完毕。所有数据准备就绪。	开始Reward计算	同步点（Synchronization Barrier）到达。
T=10.1s	调度训练	开始PPO训练（Forward/Backward）	辅助计算	训练直到生成彻底结束才开始。
T=15s	训练结束，广播参数	更新参数	同步参数	下一轮Rollout才能开始。

总结： 在verl的同步模式下，异步体现在T=0s时指令下发的非阻塞，但在T=2s到T=10s之间，大量GPU资源因等待最长任务而被浪费。训练严格串行于生成之后。

3.2 实验组：AReaL (Fully Asynchronous) 的时间线

AReaL中，Rollout Worker和Trainer Worker是并行的。

假设我们观察时刻T，此时Trainer正在更新第步。

时间 (Time)	Rollout Worker (生成流)	Trainer Worker (训练流)	交互与冲突 (The "Async" Moment)
T=0s	正在生成Prompt A的第50个Token（基于参数）。	正在基于Buffer中的旧数据（由生成）计算的梯度。	完全并行：两个进程互不干扰。生成不等待训练，训练不等待生成。
T=0.5s	继续生成Prompt A的第60个Token。	梯度计算完成，优化器步进。参数更新为。	异步事件发生： Trainer发布了新参数。
T=0.6s	检测到新参数事件： Rollout Worker收到中断信号或轮询发现新权重。	开始从Buffer采样新Batch，准备下一轮训练。	关键决策点： AReaL的“部分Rollout”机制介入。
T=0.7s	中断（Interrupt）：停止Prompt A的生成。丢弃下的KV Cache。	持续训练...	Rollout Worker决定不再使用过时的继续生成。
T=1.0s	加载参数：加载新权重。	持续训练...	权重同步耗时。
T=1.5s	重计算（Recompute/Prefill）：使用对Prompt A已生成的60个Token进行Forward Pass，生成新的KV Cache。	持续训练...	代价支付：为了修正Off-Policy，支付了重计算的开销。
T=2.0s	恢复生成（Resume）：基于继续生成第61个Token。	持续训练...	生成任务无缝衔接，但策略已更新。

总结： AReaL的“异步”在于：

没有全局同步屏障（Barrier）： 短序列生成完立即存入Buffer供训练使用，无需等待长序列。

权重更新随时发生： 训练器一旦算出新权重就发布，这就迫使生成器必须处理“正在生成时权重变了”的复杂情况。这就是所谓的Interruptible Rollout（可中断Rollout）4。

4. AReaL 或者其他 partially rollout 框架，在rollout时，会不会保存之前policy的KV cache？

4.1 结论先行

根据对AReaL源代码文档、技术论文及相关研究材料的深入分析：

AReaL 框架：不会保存之前 Policy 的 KV Cache。

在发生权重更新导致的中断（Interruption）和恢复（Resumption）时，AReaL 明确采取了丢弃旧 KV Cache 并重新计算的策略。

4.2 为什么 AReaL 选择丢弃 KV Cache？

这一设计决策并非由于技术无法实现保存，而是基于数学严格性和分布一致性的考量。

4.2.1 KV Cache 的本质依赖

Key-Value Cache 本质上是模型权重与输入Token的函数。

其中和是模型Transformer层中的投影矩阵权重。

状态T1： 模型拥有权重。生成的Token序列对应的缓存是。

状态T2： 训练器更新了权重，模型加载了。

如果此时直接复用并尝试基于生成下一个 Token ：

这里的是由计算的，而是由计算的。这就导致了特征空间的错位。虽然和可能差异微小（因为学习率通常很低），但在深层网络中，这种微小的权重变化会经过层层放大，导致Attention机制关注到错误的上下文信息，产生严重的分布漂移（Distribution Shift）。

4.2.2 AReaL 的官方阐述

AReaL 的论文明确指出：

📎

"Upon the interruption, the rollout workers discard KV caches computed by old weights, and re-compute them using the new weights. Afterwards, the rollout workers continue to decode the unfinished sequences..." 7

（在中断发生时，Rollout Worker 会丢弃由旧权重计算得到的 KV Cache，并使用新权重重新计算它们。随后，Worker 继续解码未完成的序列...）

这一机制确保了即使序列的生成过程跨越了多个策略版本，但用于生成每一个新Token的上下文表征（Context Representation）都是基于当前最新权重的精确值，从而最大程度地减少了Off-Policy带来的训练不稳定性。

5. 综合对比

5.1 AReaL vs. verl 核心维度对比表

特性维度	verl (HybridFlow)	AReaL (Fully Async)
基础架构	Hybrid-Controller：控制与数据流解耦，支持复杂DAG图。	Single-Controller：生成与训练彻底解耦，双循环结构。
异步本质	编程接口异步：支持非阻塞调用，但业务逻辑通常保持同步（Wait for batch）。	系统执行异步：Rollout与Train物理并行，互不等待。
气泡处理	通过微批次（Micro-batching）和3D引擎优化，但仍受限于最长样本。	通过中断机制（Interruption）和缓冲区，彻底消除等待气泡。
数据陈旧性	无（None）：严格保持 On-Policy，数学性质优良。	有（High）：存在 Policy Lag，需使用 IS（重要性采样）修正算法。
部分Rollout	并非核心特性，侧重于数据流图的表达能力。	核心特性：长序列生成可被随时打断，以同步权重。
KV Cache	标准推理模式，Batch 内复用，Batch 间清除。	跨版本丢弃：中断时丢弃旧 Cache，加载新权重后重算。
吞吐性能	高（相比传统框架），但在长尾分布数据上受限。	极高（Very High），官方宣称相比同步系统有 2.77x 加速 7。
适用场景	对算法稳定性要求高，资源相对充裕，追求标准复现。	对训练速度和资源利用率要求极高，能容忍一定算法偏差。