作者：华为昇腾技术专家 周宏倜

强化学习（RL）已成为大模型从「能用」走向「好用」的核心引擎。但在 RL训练流程中，传统同步训练模式长期受困于「长尾阻塞」——生成阶段的极端耗时反复中断训练，硬件大面积空闲，既拉低吞吐又推高成本。AsyncFlow异步流式RL以训推解耦为核心，通过 TransferQueue 数据中枢与 CheckpointEngine 权重引擎，将推理（Rollout）与训练（Trainer）彻底解耦，突破同步模式的性能限制。实测在 prompt 2k → response 16k 长序列场景下，在昇腾Atlas 900 A3 SuperPoD液冷超节点、Atlas 800 A3风冷超节点等全系列产品训练吞吐从同步方案的 59.3 提升至 226.8，相对提升 3.81 倍，同时保持收敛精度对齐，目前已支持verl框架。

一、同步 RL 为何「跑不满」算力

一个标准的同步 RL step，需顺序走完六道工序：Rollout 生成 → Reward 打分 → Actor 前向（old_logprob）→ Reference 前向（ref_logprob）→ Advantage 计算 → Actor 训练更新。在这样的场景下会出现以下问题：

● 阶段间相互阻塞：训练必须等整批生成、打分、前向全部结束才能启动，等待期间训练所占算力全程闲置。

● 长尾拖垮整批：一个 batch 内绝大多数样本早已生成完毕，仅剩少数超长序列仍在逐 token 输出；整批必须对齐，已完成样本所在的资源只能陪着空等最慢的一条。

● 资源画像错配：Rollout 访存密集、占用周期长，前向计算量小却与训练共享整机资源。共卡模式下所有角色挤在同一批卡上轮流使用，无法按需分配，也难以横向扩展。

三者叠加的结果是算力利用率低下、训练周期被长尾主导、成本居高不下。

二、以「解耦 + 数据中枢 + 可控陈旧」重构流水线

AsyncFlow 的总体思路可概括为三点：

● 把「一锅煮」拆成独立工位：Rollout、两个前向、Advantage、训练各自拆为独立 Worker，运行在自己的事件循环中连续工作，不为彼此的整批进度而等待。

● 用数据中枢把工位连起来：Worker 间不直接通信，只与 TransferQueue（TQ）交互——生产者写入、消费者按需取走，任意环节在物理上彻底解耦。

● 允许训练用「稍旧」数据：通过 staleness 机制让推理超前训练若干版本地持续生成、填满空泡；再以 FlowControlQueue 约束「最多超前多少」，守住精度底线。

之上再以 CheckpointEngine 在训练更新权重后，将新权重异步广播给推理与前向 Worker。

图 1　AsyncFlow 整体架构示意图

其性能实验中资源配比 52-2-2-8：52 张卡给瓶颈所在的 Rollout，两个前向各 2 张卡，Advantage 放 CPU，训练独占 8 张卡。

三、四大核心组件拆解

3.1 四个独立 Worker：让每道工序独立连轴转

同步模式下前向、打分、训练被绑死在同一节拍，一环变慢就阻塞全局。AsyncFlow 将下游计算拆为四个职责单一的 Worker：

四者共享同一套异步循环骨架（取数 → 计算 → 写回），各自运行在独立线程的事件循环中，彼此没有整批同步点。骨架还内置两项保障：一是用「分发策略」抽象屏蔽并行后端差异，Worker 主循环无需关心自己跑在何种并行模式；二是取数前先做「全局可用量探测」，所有 rank 确认数据充足后再一起放行，避免某个 rank 卡住整组的集合通信。由此，多道工序在不同样本上同时推进，流水线真正「流动」起来。

3.2 TransferQueue：异步数据中枢

解耦之后系统须回答两个新问题：如何安全使用跨版本混合数据？组内大量重复的 prompt 如何不浪费存储与带宽？TransferQueue 采用控制面与数据面分离的分布式架构——控制面管主题、索引、版本与就绪状态但不存数据，数据面由多个分片承载真实张量。它为异步 RL 定制了四项能力：

图 2　TransferQueue 控制面 / 数据面分离架构

● 版本即数据属性：version 作为每条数据的标签，配合「最新版本 + 允许陈旧度」划出滑动窗口，一次集合运算即可筛出「足够新鲜」的样本，无需为每个版本维护分区。

● 引用计数去重：GRPO 中同一 prompt 采样 n 条，组内共享列只传一次、只存一份，大 batch、长 prompt 下显著降内存与带宽。

● 端到端零拷贝：仅序列化张量元数据，本体经 Buffer Protocol + ZMQ 零拷贝直传，序列化开销下降 95% 以上。

● 索引管理透明化：写入方只提交数据与版本，索引由 TQ 自动分配；消费方只声明数量，TQ 按「就绪 ∩ 未消费 ∩ 版本新鲜」动态分发。每个 Worker 都与全局进度解耦——这正是异步方案成立的数据底座。

3.3 CheckpointEngine：让权重「边算边传」

训练每更新一轮权重，都要同步给数十张卡的 Rollout 与前向 Worker，这是异步 RL 中最重的一次通信。CheckpointEngine 统一抽象训推权重同步，底层基于 HCCL 集合通信广播，叠加三层优化：

图 3　CheckpointEngine 双缓冲流水线广播

● 双缓冲流水线：发送与接收并行，以通信/计算重叠隐藏延迟。

● 分桶传输：小张量按桶批量打包再发，减少通信次数。

● 主机缓存 + 懒加载：将「接收权重」与「加载进模型」拆成两步，前向 Worker 收到新权重先缓存在主机内存，等下一批次开始再加载，使接收对当前计算几乎零干扰。

完整同步流程为：暂停前向与所有 Rollout 实例 → 准备元数据 → 构建通信拓扑 → 广播更新 → 收尾 → 通知加载并恢复生成。Rollout 暂停复用 vLLM 原生能力，可排空在途请求后再暂停，避免丢弃中间结果。最重的通信被拆解、重叠、缓存，对计算扰动降到最低。

3.4 FlowControlQueue：异步的「安全带」

异步若放任不管会失控：推理一路生成、训练来不及消费，TQ 中堆积过期数据最终把精度带崩。AsyncFlow 用一条带容量上限的 FlowControlQueue 约束「推理最多可超前多少」，容量为 (staleness + 1) × batch_size。主控注入新 prompt 前先查容量，将溢出则反压等待；训练每完成一批便释放等量坑位。

图 4　FlowControlQueue 陈旧度控制

由此 staleness 语义清晰可调：=0 时严格同步、退化为 on-policy；=N 时允许推理超前训练 N 个版本。同时训练侧也在一轮batch等待——训完一个完整 GBS 才将版本号加一并等待权重同步。数据流全异步、权重更新仍在 GBS 边界对齐。

四、全流程：一条样本的完整旅程

1、主控取一批 prompt 注入生成层；

2、生成层按采样数切分、限流分发给生成 Worker 调用 vLLM，记录 model_version 并并行完成 reward 打分；

3、结果带版本标签写入 TransferQueue；

4、Actor / Reference 前向 Worker 分别计算 old_logprobs、reference_logprobs 写回；Advantage Worker（CPU）凑齐 reward、按组算 advantage 写回；

5、Actor 训练 Worker 发现某样本「全列就绪且版本新鲜」便取走训练，完成后推进版本、释放流控坑位；

6、主控轮询到训练版本前进，触发 CheckpointEngine 广播新权重。

整条链路上，多道工序在不同样本上并行推进，Rollout 仍在为下一批生成——没有任何环节需等待另一环节整批完成。这便是「训推异步流水线」的真正含义。

五、性能跃升与精度对齐

在 Qwen2.5-Math-7B + DAPO-17k、prompt 2k → response 16k 场景下：

图 5　训练时间线 Trace 分析

优势核心在于细粒度的角色解耦：把计算量小的两个前向各拆到 2 张卡、Advantage 移至 CPU，从而把计算资源更多让给瓶颈所在的 Rollout，训练卡也不再被前向挤占。

精度方面，不同陈旧度评测如下：

图 6　reward 收敛曲线

可以看到：同步与异步（staleness=0）基本一致，差异 2% 以内；适度异步（≤2）可维持甚至微幅提升；过高陈旧度（=4）开始衰退。staleness 存在一个「甜点区」——这正是 FlowControlQueue 把激进程度约束在收益最大、风险可控区间的意义所在。

附：快速上手

AsyncFlow现已在verl框架下可用：https://github.com/verl-project/verl-recipe/tree/main/async_flow

昇腾开源微信小助手：ascendosc

verl开源社区讨论区：https://github.com/volcengine/verl/discussions

---

「免责声明」：以上页面展示信息由第三方发布，目的在于传播更多信息，与本网站立场无关。我们不保证该信息(包括但不限于文字、数据及图表)全部或者部分内容的准确性、真实性、完整性、有效性、及时性、原创性等。相关信息并未经过本网站证实，不对您构成任何投资建议，据此操作，风险自担，以上网页呈现的图片均为自发上传，如发生图片侵权行为与我们无关，如有请直接微信联系g1002718958。