文章标题：AsyncFlow: An Asynchronous Streaming RL Framework for Efficient LLM Post-Training
作者/机构：Zhenyu Han, Ansheng You, Haibo Wang, Kui Luo, Guang Yang, Wenqi Shi, Menglong Chen, Sicheng Zhang, Zeshun Lan, Chunshi Deng, Huazhong Ji, Wenjie Liu, Yu Huang, Yixiang Zhang, Chenyi Pan, Jing Wang, Xin Huang, Chunsheng Li, Jianping Wu (Huawei & Individual Researcher)

A1 主要贡献

本文针对大规模语言模型（LLM）后训练（Post-Training）阶段中强化学习（RL）框架面临的挑战，提出了一个名为AsyncFlow的异步流式RL框架。

核心问题：
现有的RL后训练框架主要分为两类，各有其瓶颈：
1. 任务共置（Task-colocated）框架（如DeepSpeed-Chat）：将所有RL任务（如actor rollout、actor update等）部署在同一组设备上，一次只执行一个任务。这导致了严重的内存效率低下、模型在不同并行策略间切换时产生巨大的重分片（resharding）开销，以及对于不同大小的模型存在次优并行度的问题。
2. 任务分离（Task-separated）框架（如OpenRLHF）：将不同RL任务分配到按需配置的独立资源池中。然而，RL算法固有的数据依赖性限制了任务的完全并行化，导致下游任务（如critic update）需要等待上游任务（如actor rollout）完成，从而产生大量的资源空闲。此外，LLM复杂的嵌套并行策略使得跨任务数据流变得更加复杂，降低了计算效率。
3. 框架可用性问题：大多数现有框架与特定的训练或推理引擎（如Megatron-LM, DeepSpeed, vLLM）紧密耦合，限制了其在工业界定制化后端上的灵活性和适应性。

研究目标：
为解决上述挑战，本文旨在设计一个高效、可扩展且灵活的RL后训练框架。具体目标包括：
* 优化任务分离架构中的数据流，实现任务间的自动化负载均衡和流水线重叠。
* 通过异步工作流设计，最大限度地减少因数据依赖造成的计算资源空闲。
* 将框架核心能力与底层训练/推理引擎解耦，提供模块化和可定制的用户体验，以弥合学术研究的灵活性和工业部署的可扩展性之间的差距。

创新贡献：
AsyncFlow框架通过以下几个核心设计实现了上述目标：
* 分布式数据管理模块（TransferQueue）：设计了一个分布式数据存储与传输模块，以完全流式的方式提供统一的数据管理和细粒度调度能力。该架构天然支持RL任务间的自动化负载均衡和流水线重叠，显著提升了任务分离框架的训练效率。
* 基于生产者-消费者的异步工作流：提出了一种基于生产者-消费者模型的异步工作流优化算法。通过在可控的陈旧度（staleness）阈值内策略性地延迟参数更新过程，该方法最小化了计算空闲时间。
* 服务化用户接口：将AsyncFlow的核心调度能力与底层训练/推理引擎解耦，并封装为面向服务的用户接口。这种设计支持多样化的后端引擎，为用户提供了模块化、可定制的体验，兼顾了学术研究的灵活性与工业部署的可扩展性。
* 显著的性能提升：通过大量实验证明，与当前最先进的基线相比，AsyncFlow平均实现了1.59倍的吞吐量提升，在大型集群中峰值可达2.03倍。

A3 系统概述

AsyncFlow的整体分层架构。本文介绍了AsyncFlow的架构设计，它是一个用于可扩展后训练的异步流式强化学习框架，如图2所示。其基础是资源层，该层利用Ray来管理计算资源，并通过一个执行时间模拟器预先优化硬件分配以确保高效训练。在此之上，后端层为各种异构的训练和推理引擎提供了模块化适配器。因此，RL任务可以在这些后端引擎上实例化，同时保持引擎无关性。在优化层，我们试图解决任务分离框架在数据流管理和资源利用方面的两个关键挑战。我们引入TransferQueue作为流式数据加载器，以动态调度跨越RL任务不同并行策略的复杂数据流。此外，我们提出一种基于生产者-消费者的异步工作流来实现高计算资源利用率。结合流式流水线重叠和延迟参数更新机制，我们可以显著减少任务分离框架中的空闲时间。在可用性设计方面，接口层提供了一个统一的算法入口点，作为满足算法研究需求的单一控制器。作为补充，AsyncFlow为工业工作流提供了一套面向服务的API，能够与现有的训练和推理集群无缝集成。总而言之，AsyncFlow旨在通过提供一个统一的框架，协调灵活性与可扩展效率，从而弥合LLM后训练中算法研究与工业部署之间的差距。

A2 方法细节

3 TransferQueue: 高性能异步流式数据加载器

在RL后训练过程中，任务间的数据依赖性对任务分离框架的设计构成了重大挑战。现有实现仅为整个训练数据集提供基本的数据存储和传输能力，导致下游任务大量资源空闲。在AsyncFlow中，我们引入了TransferQueue——一个具有分布式存储能力的集中式数据管理模块，作为异步流式数据加载器。在任务分离的RL框架中，这种设计通过允许下游任务访问部分训练样本进行计算，而不是等待整个数据集准备就绪，从而促进了流式流水线重叠。

集中式数据视图与灵活编程。在数据管理能力方面，我们的目标是为每个RL任务提供一个集中的数据状态视图。这一特性消除了在多个RL任务之间手动定义所有数据流的需求。这种设计使我们区别于现有的解决方案，如OpenRLHF【索引编号5，Openrlhf: An easy-to-use, scalable and high-performance rlhf framework，2024，arXiv】和StreamRL【索引编号38，StreamRL: Scalable, Heterogeneous, and Elastic RL for LLMs with Disaggregated Stream Generation，2025，arXiv】，提供了一种更灵活、更高效的编程范式。这种集中式视图有助于实现更好的负载均衡策略。

存控分离的可扩展架构。在数据存储和传输方面，我们的目标是支持大规模后训练中的高并发、异步请求。受软件定义网络（SDN）的启发，我们将数据平面与控制平面解耦，并在每个平面中实例化多个控制器和数据存储对象。这种设计减轻了潜在的I/O和网络瓶颈，并支持不同的存储系统，从而实现了可扩展的后训练。

图3. TransferQueue的架构设计。每个DP组与其对应的TransferQueue控制器交互以根据请求获取元数据，然后与数据平面中的存储单元执行读/写操作。虚线表示元数据通信，而实线描绘了与真实数据的通信过程。所有这些交互过程都被封装成一个分布式流式数据加载器，以无缝集成到训练和推理引擎中。

3.1 架构概述

TransferQueue作为流式数据调度器。如图3所示，TransferQueue作为一个流式数据调度器，连接训练和推理集群，管理RL后训练过程中的整个数据流。具体来说，每个RL任务都配备了一个专用的TransferQueue控制器，该控制器维护训练样本的元数据，包括存储位置、数据状态和消费状态。由于RL任务在算法上本身不会相互干扰，这些控制器独立运行。在数据存储方面，每个存储单元负责当前全局批次内的一个样本子集。这些样本被分配了全局索引，以确保所有分布式控制器都能准确寻址。当新数据写入存储单元时，会触发一个更新通知给所有控制器以更新其元数据。这种机制允许每个RL任务在请求时动态访问新生成的数据。

数据请求与消费流程。当一个数据并行（DP）组需要新数据时，它首先向其对应的控制器发送一个读请求。控制器从当前可用数据中动态地组合一个批次的样本，并将其元数据返回给请求者。然后，DP组使用提供的元数据从分布式存储单元中检索相应的数据。为了确保每个DP组都能访问到不同的样本且不重复，控制器会跟踪每个样本的消费记录，保证在同一个RL任务中只有一个DP组能访问该样本的元数据。类似地，在一个DP组完成计算后，它通过元数据原子地将结果写回存储单元，以保证分布式组件之间的一致性。

DataLoader封装以简化集成。为了确保与训练和推理引擎的输入格式兼容，我们将上述交互逻辑封装成一个PyTorch DataLoader。这使得用户可以无缝地将TransferQueue集成为一个分布式流式数据加载器，而无需理解底层的实现细节。

3.2 数据平面: 分布式数据传输与存储

3.2.1 数据结构

二维列式数据结构。为满足RL任务多样化的数据需求，我们采用了一种二维列式数据结构，如图4所示。在这种设计中，列对应于特定任务的数据组件，如actor的响应和reference的对数概率。行代表完整的训练样本，每个样本都可以通过一个全局索引进行唯一寻址。这种结构使得RL任务能够根据算法需求仅检索特定的数据组件。例如，reference模型需要输入token ID和响应，就可以只请求相关的列，从而最小化不必要的数据传输。此外，这种组织方式支持在不同位置进行并发读/写操作，增强了在高并发场景下的可扩展性。

分布式数据存储。考虑到潜在的I/O和带宽瓶颈，我们以分布式方式存储训练样本。每个存储单元维护一部分数据条目（即行），以分摊整个系统的存储和通信开销。

图4. TransferQueue的数据结构。每一行代表一个完整的数据样本，而每一列代表任务特定的数据组件。通过全局索引，我们可以准确地在不同存储单元中寻址数据样本，以进行并发读/写操作。

3.2.2 元数据通知

元数据广播通知机制。当新数据被写入数据存储单元时，会触发一个通知给控制器以更新其元数据。如图5所示，在写操作完成后，数据存储单元会向所有控制器（在初始化时注册）广播相应的行索引和列标识符。这种机制确保控制器能够立即知晓这些位置的数据已准备好被消费。

图5. TransferQueue的元数据通知过程。数据存储单元将向所有控制器广播元数据（包括全局索引和相应的数据列）。

3.3 控制平面: 集中式数据管理视图

集中式数据管理解耦复杂依赖。LLM训练中固有的嵌套并行策略，加上多个并发的RL任务，导致后训练期间数据流变得异常复杂。为了解开这些复杂的数据依赖关系，我们利用TransferQueue的控制平面作为集中式数据管理模块，确保每个任务在分布式工作节点间进行一致的协调。

图6. TransferQueue控制器的调度过程。红色索引表示相应的数据样本满足RL任务要求，而复选标记表示相应的数据已在早期的请求中被消费。

控制器的数据状态维护。我们为每个RL任务初始化不同的TransferQueue控制器。控制器维护其对应任务范围内的数据状态元数据，其中包含所需列的所有条目。数据状态元数据使用二进制状态指示器：状态0表示数据不可用，状态1表示数据已准备好被检索。如第3.2.2节所述，每当新数据写入数据存储单元时，这些元数据条目都会动态更新。

数据调度与消费标记。如图6所示，在收到读请求后，TransferQueue控制器会扫描元数据，以识别满足RL任务需求的条目——具体来说，是所有列状态都等于1且没有被其他DP组消费过的条目。如果当前可用数据超过了请求的微批次大小，控制器会根据负载均衡策略选择并打包元数据成一个微批次。然后，这些样本会被标记为已消费，以防止同一RL任务内的其他DP组重复获取。利用这些元数据，消费者与分布式数据存储单元通信，执行实际的数据检索过程。

动态负载均衡优势。我们架构的一个关键优势在于其集中的数据管理。通过控制器动态调度所有可用数据，而不是将它们预分配给DP组，TransferQueue能够实现先进的负载均衡策略。例如，处理速度较快的实例（由于硬件异构性或响应长度较短）可以动态请求更多数据，从而提高整体效率。此外，可以实施主动的负载均衡，以确保在DP组之间公平分配处理的token数量，从而最小化actor更新过程中的计算空闲。总之，TransferQueue为下一代数据流管理系统的开发提供了重要的见解。

3.4 交互接口

PyTorch DataLoader封装接口。为了简化TransferQueue的使用，我们将其功能封装成一个PyTorch DataLoader。如代码1所示，用户首先通过指定当前的RL任务、所需的输入数据列和微批次大小来初始化TransferQueue作为一个流式数据加载器。在每个前向传播步骤中，所需的数据可以通过一个迭代器包装器轻松获取。该接口简化了TransferQueue的集成，确保了与现有训练工作流的无缝兼容。

# 代码 1. TransferQueue 使用示例
# 初始化 TransferQueue
tq = TransferQueue(
    task_name='actor_rollout', # 指定RL任务
    input_columns=['prompt_ids', 'prompt_len'], # 指定所需数据
    batch_size=args.micro_batch_size, # 设置微批次大小
)

# 封装为 PyTorch DataLoader
dataloader = DataLoader(tq)

# 迭代数据
for data in dataloader:
    # 训练/推理逻辑
    ...

3.5 高并发设计

可扩展的存控分离架构。TransferQueue通过三个步骤来应对大规模后训练的挑战。首先，其解耦的控制平面和数据平面架构支持可扩展的数据存储单元，以实现高并发操作。当出现I/O或网络带宽瓶颈时，可以轻松初始化额外的数据存储单元来扩展总带宽并降低系统延迟。这种设计还支持未来轻松切换到其他存储后端，如Mooncake Store【索引编号18，Mooncake: Trading More Storage for Less Computation — A KVCache-centric Architecture for Serving LLM Chatbot，2025，FAST 25】，Redis【索引编号22，Redis，2025，https://redis.io/】或其他为LLM训练量身定制的存储系统。此外，控制平面的调度过程和数据平面的I/O操作是并发执行的，形成了一个流水线化的工作流，高效地处理多个传入请求。

优化的通信模式。其次，考虑到在一个DP组中每个rank应接收相同的数据（不考虑序列并行），TransferQueue通过指定每个DP组内的一个rank与系统交互来优化通信效率。检索到的数据随后会广播到DP组内的其他rank。这种方法显著减少了大规模后训练场景下对TransferQueue的直接请求数量。

消除不必要的填充。第三，我们消除了在数据存储和传输过程中的不必要填充。TransferQueue天生支持可变长度数据传输。对于设备到设备的华为集体通信库（HCCL）通信，张量会沿着序列维度进行拼接以进行广播操作，然后我们使用长度元数据恢复接收到的张量。这种策略最小化了由填充引起的冗余通信开销，特别是在具有大微批次大小的设置中。总的来说，这些设计缓解了数据存储和传输瓶颈，确保了大规模后训练工作负载的强大高并发性能。

4 基于生产者-消费者的异步工作流优化

任务分离框架中的一个关键挑战源于流水线气泡——由部署在不同设备集上的任务之间的数据依赖性导致的硬件资源空闲。为了克服这一挑战，AsyncFlow实现了一系列流水线优化技术以最大化硬件利用率。

综合优化策略。首先，我们的流式数据加载器实现了RL任务间的流水线重叠，极大地减少了后训练的端到端执行时间。其次，在离策略（off-policy）场景中，我们设计了一种延迟参数更新机制，很好地平衡了算法收敛性和训练效率。通过允许actor rollout和actor update之间存在持续的一步异步，该方法通过最小化预热（warm-up）和冷却（cool-down）阶段，有效消除了流水线气泡。最后，通过主动资源规划和动态负载均衡策略实现细粒度的执行时间优化，充分释放了任务分离框架在LLM后训练中的可扩展性。

4.1 跨RL任务的流式流水线重叠

基于TransferQueue的流水线重叠。利用TransferQueue，AsyncFlow不仅简化了数据流管理，还通过实现RL任务间的流水线重叠来提高训练吞吐量。在这种范式中，所有的训练和推理实例只需与流式数据加载器交互，后者动态地调度和重定向跨任务的最细粒度数据样本。该架构天生支持流水线重叠，如图7所示。与现有框架【索引编号5，Openrlhf: An easy-to-use, scalable and high-performance rlhf framework，2024，arXiv；索引编号38，StreamRL: Scalable, Heterogeneous, and Elastic RL for LLMs with Disaggregated Stream Generation，2025，arXiv】中的设计不同，我们可以轻松地将这种重叠策略扩展到任何具有不同任务的RL算法，无需手动重新调度数据流。

图 7. 流式流水线重叠。

4.2 异步离策略（Off-Policy）气泡减少

4.2.1 基础异步RL算法

同步On-Policy算法的低效性。传统的LLM后训练RL算法主要采用同步在策略（on-policy）范式，其中actor rollout和actor update在相同的参数状态上操作。虽然这保证了算法的收敛性，但其计算效率低下——源于严格的同步要求——严重限制了大规模后训练的可扩展性。

异步Off-Policy的探索。然而，最近的进展挑战了这一范式：诸如部分rollout【索引编号29，Kimi k1. 5: Scaling reinforcement learning with llms，2025，arXiv】和流式rollout【索引编号24，Seed1.5-Thinking: Advancing Superb Reasoning Models with Reinforcement Learning，2025，arXiv】等优化技术通过允许在更新阶段使用由旧模型生成的响应数据，实际上放宽了on-policy的假设。这些创新为探索异步、离策略（off-policy）框架创造了机会，这些框架通过流水线重叠有望在保持收敛保证的同时显著提高训练效率。

异步工作流与收敛性权衡。如图8(a)所示，on-policy算法在actor rollout和actor update阶段之间强制执行严格的同步，这导致了迭代间的预热和冷却气泡。一个直接的缓解策略是增大actor rollout阶段的全局批次大小，过渡到一个异步off-policy场景，其中actor update利用由陈旧参数生成的响应，如图8(b)所示。这种调整延长了RL流水线的稳定阶段，从而减少了预热和冷却阶段中流水线气泡的比例。然而，算法收敛性约束对actor rollout和actor update阶段之间允许的版本差异施加了严格的限制。经验研究表明，actor rollout和actor update之间的一步异步不会导致显著的性能或收敛性下降【索引编号13，Asynchronous RLHF: Faster and More Efficient Off-Policy RL for Language Models，2024，arXiv；索引编号38，StreamRL: Scalable, Heterogeneous, and Elastic RL for LLMs with Disaggregated Stream Generation，2025，arXiv】。但当版本差异超过此阈值时，性能会呈对数下降。这种权衡凸显了在大规模LLM后训练中协调训练效率与算法稳定性的机制的迫切需求。

图 8. 异步off-policy RL工作流的图示。(c)中利用提出的延迟参数更新机制，AsyncFlow可以扩展RL流水线的稳定阶段以进一步减少流水线气泡。(d)中通过顺序地为rollout实例启用参数更新，我们可以实现子步异步。

4.2.2 延迟参数更新机制

延迟参数更新机制消除气泡。为解决上述困境，我们提出了一种延迟参数更新机制，通过解耦actor rollout和actor update的模型权重，进一步消除流水线气泡。如图8(c)所示，该机制将参数更新延迟一步，使得在迭代间的过渡期能够连续进行rollout。具体来说，当actor update完成后，actor rollout工作节点不会立即停止生成。相反，它继续使用旧的模型权重生成响应，同时异步地将接收到的新参数写入主机内存。新参数将在当前生成迭代完成后加载到昇腾神经网络处理单元（NPU）中，从而将暴露的同步开销减少为相对较快的主机到设备（H2D）传输。通过允许持续的一步异步，它使得稳定阶段几乎可以无限扩展，从而消除了预热和冷却阶段。虽然概念上与StreamRL【索引编号38，StreamRL: Scalable, Heterogeneous, and Elastic RL for LLMs with Disaggregated Stream Generation，2025，arXiv】相似，我们的方法通过TransferQueue的集中式数据流管理，在训练引擎内重叠所有RL任务，进一步增强了可扩展性。总之，该设计有效减少了RL后训练工作流中的预热和冷却流水线气泡，充分利用了任务分离框架的架构潜力。

子步异步更新机制。此外，我们提出了一种新颖的参数更新机制，可实现子步异步算法工作流，如图8(d)所示。为了高效地为下游任务提供数据，我们通常为actor rollout任务分配充足的硬件资源。这种设置允许rollout实例顺序执行参数更新，而其余实例则继续满足下游训练任务的数据需求。因此，在每次迭代中，我们可以利用最新更新的参数来生成部分数据，实现子步异步。此外，这种设计还最小化了检查点加载的开销，从而提高了系统效率。

我们将该机制的实现细节留作未来一项重要的工作。

4.2.3 参数更新重叠

参数更新模块设计。参数更新模块主要由部署在训练集群上的一个发送器和一个部署在推理集群上的接收器组成。为了最小化RL训练流水线中的权重传输时间，发送器和接收器被设计为支持同步和异步两种模式。

同步与异步更新模式。在同步模式下，actor rollout会被参数更新过程阻塞。为了缩短暴露的传输时间，我们利用跨昇腾NPU的高带宽HCCL链接来传输模型权重。为了进一步减少端到端时间，我们进一步开发了一个可以与计算任务完全重叠的异步参数更新过程，用于异步RL算法。具体来说，来自训练引擎的模型权重被卸载到主机设备，并通过主机网络异步传输到推理引擎，从而将计算工作负载与权重同步过程解耦。这种设计确保了参数更新过程既不会停滞也不会干扰正在进行的计算任务，从而维持了一个连续的RL工作流。

4.3 任务资源规划

基于图的资源规划模块。为了实现图8(c)中所示的理想工作流，我们构建了一个基于图的资源规划模块，该模块能在给定资源约束下准确搜索最优配置。通过模拟不同配置下的计算和通信时间，我们可以获得能够最小化整个RL工作流端到端时间的资源分配设置和超参数。

混合成本模型。考虑到LLM后训练的巨大搜索空间，我们采用了一种结合了分析方法和性能剖析方法的混合成本模型。分析方法利用硬件规格以及理论计算和通信量来估计执行时间，提供了一种快速评估，可以迅速缩小搜索空间。相比之下，性能剖析方法通过实际运行训练和推理任务来提供块级性能。它提供了准确的评估，但时间成本要高得多。利用混合成本模型，我们在效率和准确性之间取得了良好的平衡，使其非常适合优化LLM后训练的复杂RL工作流。

5 面向服务的用户接口

高层抽象接口的重要性。为了提供增强的用户体验，RL框架应提供一个高层抽象层来协调所有特定于算法的任务。对于学术研究，这种设计为算法开发提供了一个统一的入口点，通过标准化的API实现快速实验。对于工业场景，支持各种训练和推理后端同时保持架构灵活性至关重要。因此，维护一个适当的用户接口至关重要。

分层式面向服务的接口设计。在AsyncFlow中，我们实现了一个分层的面向服务的接口，如图9所示。具体来说，用户级接口封装了面向最终用户的RL算法逻辑，暴露了一组关键API来控制后训练工作流。此外，后端级接口提供了RL任务的模块化抽象，通过多个后端适配器将算法逻辑与执行引擎解耦。上述设计实现了清晰的关注点分离：算法研究人员可以与高层API交互进行算法设计，而基础设施工程师可以专注于底层实现以获得更高效率。这些接口的协同作用很好地平衡了学术灵活性与工业可扩展性，确保AsyncFlow既能满足快速算法迭代的需求，也能满足生产级部署的需求。

5.1 用户级接口

RL算法控制器RLTrainer。AsyncFlow在RLTrainer类中提供了一个RL算法控制器，作为主训练工作流的集中入口点。这个抽象无缝地组织了关键的RL任务，如actor_rollout和actor_update。研究人员可以轻松地通过RLTrainer类修改核心RL算法。

面向工业场景的关键API。为了促进工业场景中的工作流自动化，我们实现了一些关键API，用于以最少的配置启动整个后训练任务，例如：
* init_engines: 初始化训练和推理引擎。
* load_prompt_data: 将提示数据集加载到后训练系统中。
* send_experience_data 和 recv_experience_data: 在训练和推理引擎之间协调生成的经验数据。
* sync_actor_model: 通知训练和推理引擎更新模型权重。

上述用户级接口提供了对后训练工作流的直观控制，从而简化了系统的使用。

5.2 后端级接口

RL任务的底层抽象Backend。考虑到不同的训练和推理后端引擎，我们通过Backend类设计了一个RL任务的底层抽象，如代码2所示。

# 代码 2. 后端级接口。
class Backend:
    """RL任务的抽象"""
    def __init__(self, **kwargs):
        ...

    def actor_rollout(self, **kwargs):
        """Actor模型的Rollout逻辑"""
        ...

    def actor_update(self, **kwargs):
        """Actor模型的更新逻辑"""
        ...

这一层确保了各种训练/推理后端（如FSDP, DeepSpeed, vLLM）的无缝集成，同时保持与定制化框架的兼容性，允许工程师优化硬件利用率或切换系统而不会破坏工作流的完整性。

A4 实验环境

模型：选择Qwen2.5系列模型【索引编号34，Qwen2.5 technical report，2024，arXiv】，参数规模从7B到32B不等，作为RL后训练评估的基础模型。
RL算法：实现并使用Group Relative Policy Optimization (GRPO)【索引编号20，Group robust preference optimization in reward-free rlhf，2024，NeurIPS】作为代表性RL算法进行评估。GRPO通过利用每个提示的多个响应来估计偏好信号，从而无需单独的critic模型，显著提高了后训练效率。PPO算法的支持正在开发中。
数据集：采用DeepScaleR数据集【索引编号10，DeepScaleR: Surpassing O1- Preview with a 1.5B Model by Scaling RL，2025，Notion Blog】进行RL后训练，该数据集包含超过4万个精心编制的数学问答-解题对。
硬件配置：实验在大型昇腾（Ascend）NPU集群上进行。每个节点包含16个NPU，系统内存为2880 GB。
软件配置：
- 基础平台：Ascend Extension for PyTorch 7.0.0 (基于PyTorch-2.5.1) 和 Ascend Compute Architecture for Neural Networks (CANN) 8.1.RC1。
- AsyncFlow后端：推理后端使用vLLM-Ascend 0.7.3，训练后端使用MindSpeed。
基线：与verl【索引编号27，Hybridflow: A flexible and efficient rlhf framework，2024，arXiv】进行比较。verl是一个先进的任务共置（task-collocated）RL框架，为了在昇腾NPU平台上运行，我们对其进行了必要的适配。

A4 实验结果

总体性能分析 (Overall Performance)
- 实验内容：在32到1024个NPU的集群规模上，评估AsyncFlow在Qwen2.5-7B和Qwen2.5-32B模型上的性能，并与verl基线进行比较。
- 实验结果：如图10所示，AsyncFlow在所有配置下均持续优于verl基线，平均吞吐量提升了1.59倍。在大型集群中性能提升尤为显著，7B模型在256个NPU上达到峰值2.03倍的性能提升。AsyncFlow展现出很高的扩展效率，当集群规模扩大16倍时，线性度保持在0.65和0.88。
- 分析结论：AsyncFlow在大规模场景下具有优越的性能和扩展性，验证了任务分离框架的潜力。
  
  图10. 在不同集群和模型大小下的端到端吞吐量和可扩展性分析。我们报告了10-20次迭代的平均吞吐量，以减少开始时的测量波动。
消融研究 (Ablation Studies)
- 实验内容：在512个NPU上运行7B模型，通过禁用不同优化项来验证TransferQueue和异步工作流优化的有效性。
- 实验结果：如表1所示，与基线（顺序执行的任务分离框架）相比，仅集成TransferQueue（启用流水线重叠）就带来了2.01倍的吞吐量提升。在此基础上，再加入异步工作流优化（延迟参数更新、重叠技术等）后，吞吐量进一步提升了36.3%。
- 分析结论：TransferQueue实现的流水线重叠和异步工作流优化机制均对性能有显著贡献。
  
  表1. 在512个NPU上运行7B模型的性能提升分解。
AsyncFlow优化后工作流分析
- 实验内容：通过甘特图（图11）展示了32B模型在512个NPU上分布式训练和推理实例的实际执行时间线。
- 实验结果：图表显示，在优化的数据流调度下，RL任务实现了高度并行，任务间的空闲时间极小。
- 分析结论：实验性地验证了任务分离框架能够在资源利用率和可扩展性之间取得良好平衡，从而实现高效的大规模后训练。
  
  图11. 每个训练和推理实例的AsyncFlow工作流。我们展示了使用512个NPU的32B模型，迭代0-3。
异步RL算法的稳定性
- 实验内容：在16个NPU上部署7B模型，在相同的时间限制下，比较启用和禁用异步工作流时的平均奖励和响应长度。
- 实验结果：如图12所示，两种设置下的奖励分数差异可以忽略不计，响应长度的方差也呈现收敛趋势。
- 分析结论：所提出的异步RL工作流不会对模型性能产生负面影响。
  
  图12. 所提出的异步RL工作流与原生同步RL工作流的奖励和平均响应长度比较。

A5 结论

本文提出了AsyncFlow，一个任务分离的强化学习框架，旨在为大规模集群提供模块化和可扩展的后训练能力。

为实现此目标，我们首先引入了TransferQueue，一个提供集中式数据管理和分布式存储能力的流式数据加载器。它通过动态路由训练和推理实例间的复杂数据依赖，克服了静态数据依赖图带来的瓶颈。其次，我们基于生产者-消费者抽象开发了一个异步工作流，通过允许actor rollout和actor update之间存在一步参数异步，平衡了训练效率和收敛稳定性。通过将参数更新与计算任务重叠，该设计在保持算法完整性的同时，最大限度地减少了迭代间的硬件空闲。在可用性方面，我们实现了一套面向服务的接口，为算法工作流和后端引擎提供了两级抽象，有效弥合了理论研究与工业部署之间的差距。

实验结果表明，AsyncFlow相比最先进的基线实现了显著的吞吐量提升，并在线性扩展性上表现出优越性。

未来工作展望：我们认为在rollout系统设计中存在关键的优化机会。在保证生成响应足以支持下游任务的前提下，可以错开每个推理实例的参数更新时间，以消除响应生成过程中的同步障碍。这种方法不仅能减少暴露的转换时间，还能实现一种子步异步（sub-step asynchronization）工作流，使得actor rollout和actor update之间的陈旧度阈值低于一个训练步。

总之，本研究为任务分离RL框架的设计提供了启示，证明了其在大规模后训练场景下的优越可扩展性和效率。