VeRL Async
导言
这篇文章解释为什么 RL 训练需要异步：同步流程中 rollout、reward、logprob、ref 和 actor update 互相等待，容易导致设备空闲；异步机制的目标是减少 stage bubble，提高 E2E throughput 和硬件利用率。
1. 主问题¶
- 同步 baseline 的等待时间来自哪里。
- FullAsync 如何拆开 rollout、reward、logprob 和 update。
- full async one-step offset 与 FullAsync 的差异是什么。
- 异步引入的 policy lag、staleness 和复现风险如何度量。
2. Sync Baseline¶
同步模式的优点是语义清楚、debug 简单；缺点是各阶段串行，训练卡、推理卡和 reward 资源容易互相等待。
3. FullAsync¶
3.1 要回答的实现问题¶
- 如何开关：配置项、环境变量还是启动脚本参数。
- 代码位置：trainer、worker group、async manager、queue 还是 rollout engine。
- 队列语义：每个阶段是否有独立输入队列和输出队列。
- backpressure：下游慢时，上游是否限流。
- 异常处理：某批 rollout 失败时，是否丢弃、重试或阻塞。
3.2 要回答的数据一致性问题¶
- rollout 使用的是哪个 policy version。
- old logprob 是否与采样策略严格一致。
- ref logprob 是否与 actor update 同步。
- reward 与 advantage 是否可能跨 step 使用。
4. Full Async One-Step Offset¶
待验证
one-step offset 的准确语义需要以代码为准。写作时不能只凭名字推断，必须确认它是“数据错开一拍”、还是“权重同步错开一拍”、还是“stage 执行错开一拍”。
4.1 建议对比维度¶
| 维度 | FullAsync | one-step offset | 待确认问题 |
|---|---|---|---|
| 数据来源 | 当前或异步队列数据 | 可能使用上一 step 数据 | 是否引入 policy lag |
| 权重版本 | 异步同步 | 可能错位一拍 | actor / rollout 版本如何记录 |
| 性能收益 | 减少等待 | 进一步减少同步边界 | 是否稳定提高吞吐 |
| 精度风险 | staleness | staleness 更明显 | KL 是否更容易抖动 |
5. 为什么默认不开¶
- 复现困难：异步调度改变执行顺序，结果更难完全复现。
- 稳定性风险：policy lag 可能放大 KL 和 grad norm 波动。
- 环境相关：不同网络、卡数、reward 延迟和序列长度分布下收益不同。
- debug 成本高：shape、mask、policy version 和 queue state 都需要额外记录。
6. 对 MFU / SMA 的作用¶
- 异步本身不一定提高单个 kernel 的效率。
- 它主要通过减少设备 idle time、stage bubble 和跨阶段等待来提高 E2E 利用率。
- 如果瓶颈在 reward 或数据处理，异步可能提升训练卡利用率，但不一定提升推理侧利用率。
7. 必须补充的 DFX 指标¶
- queue depth
- stage idle time
- policy version gap
- stale sample ratio
- per-stage throughput
- rollback / drop sample count
- KL / grad norm 与 policy lag 的相关性
8. 实验设计¶
- 同步 baseline。
- 只开 FullAsync。
- 只开 one-step offset。
- FullAsync + one-step offset。
- 对比不同 prompt / response 长度分布下的收益。