ROLLART: Disaggregated Multi-Task Agentic RL Training at Scale

发表时间: 2025-12 · arXiv:2512.22560 (Alibaba & HKUST)

文章标题：ROLLART: Disaggregated Multi-Task Agentic RL Training at Scale
作者/机构：Wei Gao†∗, Yuheng Zhao†∗, Tianyuan Wu†∗, Shaopan Xiong‡∗, Weixun Wang‡∗, Dakai An†, Lunxi Cao†, Dilxat Muhtar‡, Zichen Liu‡, Haizhou Zhao‡, Ju Huang‡, Siran Yang‡, Yongbin Li¶, Wenbo Su‡, Jiamang Wang‡, Lin Qu‡, Bo Zheng‡, Wei Wang† (†HKUST ‡Alibaba Group ¶Tongyi Lab, Alibaba)

A1 主要贡献

本文介绍了一个名为ROLLART的系统，用于在解耦的基础设施上进行多任务智能体强化学习（Agentic RL）。

核心问题：智能体强化学习的训练工作负载具有高度异构性，混合了计算密集型的预填充（prefill）、带宽密集型的解码（decoding）、CPU密集型的环境执行以及突发性的奖励评估。现有系统要么将所有阶段部署在单一的GPU集群上，忽略了硬件异构性；要么仅在粗粒度上解耦，导致显著的跨阶段同步开销。这种资源与工作负载不匹配的问题，加上环境执行的长尾延迟和不稳定性，严重制约了训练效率。

研究目标：设计一个分布式系统，通过在解耦的异构基础设施上进行智能的工作负载映射和异步执行，最大化多任务智能体强化学习的训练吞吐量。

创新点：ROLLART的设计基于对智能体RL工作负载的实证表征，并遵循四大设计原则以解决上述挑战：
1. R1：基于硬件亲和性的工作负载映射：将每个流水线阶段（甚至rollout的子阶段）绑定到最适合的硬件。例如，计算密集型任务（如训练和prefill）映射到计算优化型GPU，带宽密集型任务（如decode）映射到带宽优化型GPU，环境执行映射到CPU集群。
2. R2：轨迹级别的异步Rollout：在轨迹（trajectory）粒度上解耦LLM生成、环境交互和奖励计算。这使得单个缓慢或失败的环境不会阻塞其他轨迹的进度，从而消除了因“掉队者”（stragglers）造成的流水线停顿。
3. R3：无服务器卸载：将无状态的组件（特别是奖励计算）卸载到无服务器（serverless）基础设施。这不仅消除了为奖励模型预留专用“热备”GPU所带来的资源浪费，还获得了自动伸缩和容错的能力。
4. R4：有界延迟的异步训练：在独立的GPU集群上并行执行训练和rollout，通过带有延迟边界的异步权重同步协议将两者重叠。这有效地隐藏了跨集群权重传输的延迟，消除了资源空闲（“气泡”），同时保证了模型的性能。

通过将声明式编程模型与异构感知的分布式运行时相结合，ROLLART实现了上述设计。实验结果表明，与多种现有RL系统相比，ROLLART能有效提升训练吞-量，并将训练时间缩短1.31至2.05倍。此外，该系统已在阿里巴巴拥有超过3000个GPU的集群上成功部署，用于训练一个千亿级参数的MoE模型（用于Qoder产品），验证了其在大规模生产环境下的稳定性和可扩展性。

Table 1: 采纳的智能体环境分类。

A3 背景知识与设计原则

2.1 智能体强化学习训练

训练流水线。多任务智能体RL训练遵循一个包含三个阶段的迭代循环。第一阶段是rollout，用于收集经验：一个智能体LLM（actor）与并行的环境进行交互以生成训练数据。与标准的LLM推理不同，rollout是多轮次且有状态的【8，DeepSeek-V3.2-Speciale. 2025. https://huggingface.co/deepseek-ai/DeepSeek-V3.2-Speciale】【54 ，Kimi K2: Open agentic intelligence. 2025. CoRR】。在每一轮，智能体观察一个状态，生成一个动作（token序列），并将其提交给环境。环境执行该动作（例如，运行代码或点击链接）并返回反馈。这个循环重复进行直到满足终止条件，从而产生一系列状态-动作对，即一条轨迹（trajectory）。Rollout之后，奖励阶段通过奖励工作者（reward worker）评估轨迹质量，产生一个标量奖励信号。奖励计算的范围从轻量级的基于规则的检查【19，DeepMath103K: A large-scale, challenging, decontaminated, and verifiable mathematical dataset for advancing reasoning. 2025. CoRR】到计算密集型的基于模型的评判（例如，LLM-as-a-Judge【49，LLM-as-a-Judge & reward model: What they can and cannot do. 2024. CoRR】【68，Optimizing RLHF training for large language models with stage fusion. 2025. NSDI】）。最后，训练阶段消耗带有奖励的轨迹，使用RL算法（如PPO【40，Proximal policy optimization algorithms. 2017. CoRR】、GRPO【44，DeepSeekMath: Pushing the limits of mathematical reasoning in open language models. 2024. CoRR】）来更新模型权重。为了达到最佳训练性能【10，AReaL: A large-scale asynchronous reinforcement learning system for language reasoning. 2025. CoRR】，生产级RL流水线通常采用同步训练，这在每一步都强制rollout和训练之间进行严格的权重同步。


Figure 1: 用于智能体RL的解耦基础设施。


Figure 2: 同步训练与异步训练对比。

环境异构性。智能体RL的一个关键挑战是环境的多样性，它决定了系统的计算特性。如表1所示，智能体任务在模态和交互频率上差异很大。复杂的推理任务，如SWE-bench【23，SWE-bench: Can language models resolve real-world GitHub issues? 2024. CoRR】（软件工程）、FrozenLake【9，Gymnasium - FrozenLake environment. 2024. https://gymnasium.farama.org/environments/toy_text/frozen_lake/】（视觉游戏）和WebShop【61 ，WebShop: Towards scalable real-world web interaction with grounded language agents. 2023. CoRR】（电子商务），需要长的交互周期（最多30-100轮）。频繁的交互迫使智能体反复处理不断增长的上下文历史，使得这些工作负载是预填充密集型（prefill-heavy）和计算密集型的。相比之下，像GEM-Math和GEM-Game【3，GEM: Generalist environment for multi-task learning. 2025. https://github.com/axon-rl/gem】这样的任务可能交互轮次较少（最多五轮），但每个动作需要更长的思维链。这些工作负载 是解码密集型（decoding-heavy）的，将瓶颈从计算转移到内存带宽。这种差异要求基础设施能够适应每种任务的rollout特性。

2.2 解耦的集群基础设施

解耦的理由。智能体RL工作负载的极端异构性，从计算密集型的训练到有状态的环境模拟（§2.1），使得单体架构效率低下。因此，智能体RL训练必须转向解耦的基础设施，将这些需求冲突的计算阶段分解为专门的资源池。如图1所示，在典型的解耦基础设施中，训练集群使用高端、计算优化的GPU（如NVIDIA H800）来维持高吞吐量；推理集群利用带宽优化的硬件（如H20）来服务内存受限的解码；CPU集群为由Kubernetes【55，Kubernetes. 2025. https://kubernetes.io】编排的各种容器化运行时环境提供弹性容量；而无服务器基础设施处理突发性、无状态的工作负载，如奖励评估。这些资源池通过标准网络结构互连，并依赖分布式存储进行持久化日志记录和容错 。

同步与异步训练。虽然解耦解决了资源不匹配问题，但它给训练范式带来了不可忽视的编排挑战，这决定了系统吞吐量和算法一致性之间的权衡。
1) 同步训练：这种范式通过阻塞rollout直到从训练集群接收到最新的模型权重来强制执行严格的一致性。在解耦环境中，这会导致大量的“依赖气泡”（图2-左），昂贵的GPU在进行高延迟的权重同步和受“掉队者”限制的环境步骤时处于空闲状态（§3）。

Table 2: NVIDIA GPU规格。

2) 异步训练：为了缓解这些“气泡”，系统可以采用异步范式（例如，图2-右中的one-off RL训练【32，DeepScaleR: Surpassing O1-Preview with a 1.5b model by scaling RL. 2025. https://pretty-radio-b75.notion.site/DeepScaleR-Surpassing-O1-Preview-with-a-1-5B-Model-by-Scaling-RL-19681902c1468005bed8ca303013a4e2】）。Rollout和训练并行运行：训练消耗来自稍旧策略（例如，在one-off训练中延迟一个迭代）的轨迹，而rollout持续产生新数据。这种设计掩盖了解耦带来的同步延迟和“掉队者”效应，用一些策略的陈旧性换取更高的硬件利用率和吞吐量 。

3. 表征与需求

为了阐述ROLLART的设计动机，我们对多任务智能体RL训练进行了全面的工作负载表征。基于这些实证观察，我们得出了ROLLART必须满足的四个关键系统需求：生成内部的硬件亲和性映射（R1）、轨迹级别的异步性（R2）、无服务器奖励卸载（R3）和有界延迟的异步训练（R4）。

3.1 阶段计算

训练步骤延迟分解。我们首先分析标准训练迭代的端到端延迟，以确定主要的成本构成。我们在32个H800 GPU上使用SWE-bench环境（批大小为128）训练Qwen3-8B/32K，其中智能体LLM与一个用于软件工程任务的容器化沙箱交互。交互涉及两个核心操作：env.reset用于通过拉取Docker镜像和启动容器来初始化环境，以及env.step用于执行智能体的动作。图3分解了五个成功迭代与五个包含环境失败的迭代的延迟。即使在成功路径上，平均迭代时间为366秒，其中LLM生成仅占54%。其余时间分配给训练（23%）、环境初始化（15%）和其他开销，这是一个混合的剖面，推翻了生成占主导地位的普遍假设【12，RollPacker: Taming long-tail rollouts for RL post-training with tail batching. 2026. NSDI】【18，History doesn’t repeat itself but rollouts rhyme: Accelerating reinforcement learning with rhymerl. 2026. ASPLOS】。当环境超时发生时，平均时间飙升至513秒，仅env.reset就消耗了78%的rollout时间，将瓶颈完全从GPU计算转移到环境开销上。我们的生产数据显示，这些故障并非罕见的角落案例，大约每十次迭代发生一次（§8）。因此，我们的实证研究揭示，在智能体RL中，系统必须处理四种异构工作负载，包括生成、训练、环境和奖励，而不是像先前系统报告的那样仅为生成主导的场景进行优化。


Figure 3: 一个训练步骤的分解：成功运行（上，平均=365.7秒）与包含环境失败的执行（下，平均=513.3秒）。

生成中的不同硬件亲和性。现代GPU在计算能力、内存容量和成本之间存在不同的权衡（表2）。虽然最近的RL系统【15，AsyncFlow: An asynchronous streaming RL framework for efficient LLM post-training. 2025. CoRR】【56，SeamlessFlow: A trainer agent isolation RL framework achieving bubble-free pipelines via tag scheduling. 2025. CoRR】【67，StreamRL: Scalable, heterogeneous, and elastic RL for LLMs with disaggregated stream generation. 2025. CoRR】主张物理上将生成与训练解耦，将rollout分配给成本效益高、带宽优化的GPU，将训练分配给计算优化的GPU，但我们的表征显示，这种静态分配对于智能体工作负载来说是不够的。LLM生成包括两个资源需求相反的阶段：计算密集型的预填充（prefill）阶段和内存带宽密集型的解码（decoding）阶段。在交互轮次少但每个动作思维链长的环境中，大部分运行时间花在解码上（解码密集型）；相反，在交互轮次多的环境中，预填充阶段占主导地位，需要高计算吞吐量（预填充密集型）。在我们的生产集群中，智能体RL任务呈现出明显的双峰分布，其特点是交互轮次数目要么很少（< 5），要么很多（> 10）。为了量化这种差异，我们使用Qwen3-8B/32K模型，在开启前缀缓存的情况下，运行一个预填充密集型任务（FrozenLake）和一个解码密集型任务（GEM-Math），共进行十次迭代。为了进行成本等效的比较，我们在两种不同的硬件配置上执行工作负载：一种是六个H20 GPU，另一种是两个H800 GPU。如图4a所示，计算密集的H800在FrozenLake上表现优于H20，将端到端rollout时间降低至0.53倍。相反，对于GEM-Math（图4b），H20的更高内存带宽加速了解码，将rollout时间降低至H800的0.49倍–0.79倍。这些结果推翻了生成任务统一是带宽密集型的假设。相反，最大化吞吐量需要动态地将任务映射到最适合它们的硬件。


Figure 4: 不同任务在H20和H800 GPU上随批次大小变化的端到端rollout时间（秒）。
Figure 5: 环境交互分析：(a) 环境初始化(env.reset)和环境步骤(env.step)耗时的累积分布函数（对数尺度）。(b) 在批处理环境交互下，长尾环境如何影响多轮rollout的示意图。

R1：生成并非统一的带宽密集型；系统必须将每个任务绑定到最适合的GPU类别，而不是将rollout全部提交给单一类型的GPU。

重尾的环境执行。由于每个训练步骤收集一批轨迹，它会同时运行数百到数千个环境，在这种规模下，强资源隔离变得至关重要：没有隔离，并发的磁盘I/O会耗尽共享配额并引发级联故障。因此，我们采用Kubernetes集群来管理和隔离每个容器化的环境。大量先前的工作【12，RollPacker: Taming long-tail rollouts for RL post-training with tail batching. 2026. NSDI】【18，History doesn’t repeat itself but rollouts rhyme: Accelerating reinforcement learning with rhymerl. 2026. ASPLOS】【67，StreamRL: Scalable, heterogeneous, and elastic RL for LLMs with disaggregated stream generation. 2025. CoRR】分析了LLM生成的长尾行为。在智能体RL中，环境交互引入了额外的长尾执行模式来源。图5a展示了env.reset和env.step的延迟分布，两者都表现出明显的长尾。env.reset的长尾延迟在生产环境中可达数百秒，主要原因是（1）网络争用，并发的Docker镜像拉取使网络链路饱和，以及（2）主机节点上的计算和I/O争用，启动容器消耗大量CPU和磁盘资源。每条轨迹的累积env.step时间也差异很大，这是由交互轮次的大方差和每步开销驱动的。这些长尾轨迹作为“掉队者”延迟了端到端的rollout延迟。由于LLM引擎以批处理方式执行请求，将环境交互与智能体LLM批处理也是很自然的做法。图5b说明了这种模式：快速的环境必须等待最慢的一个，然后才能进行下一步的生成。我们的性能分析（图3）表明，与理想执行相比，批处理环境交互使rollout时间增加了高达21.3%，这种开销随着环境失败率的增加而加剧。对我们生产部署的跟踪分析（§8）证实，这种长尾情况在整个训练过程中并不少见，并且会严重影响任何批处理执行方案。

Table 3: 从训练集群到推理集群通过TCP和RDMA的传输开销。

Figure 6: 将本地GPU专用于奖励计算时的低效资源使用。

R2：环境执行，包括env.reset和env.step，容易出现极端的长尾延迟。系统必须在轨迹粒度而不是批处理粒度上管理环境执行，这样缓慢或失败的环境就不会阻塞流水线。

无状态的奖励计算。奖励阶段紧随rollout之后，大多数奖励计算可以实现为无状态函数。对于轻量级的基于规则和代码的奖励，它们资源需求小且呈突发性，使其天然适合于弹性的无服务器执行，可以在步骤之间缩减至零。另一方面，基于LLM的奖励计算需要密集的GPU资源：将它们与rollout部署在一起会与生成任务争夺GPU内存、KV缓存容量和调度槽位，在并发需求下降低两个阶段的性能。一个常见的解决方法是为奖励LLM预留单独的GPU：在我们使用批大小为128的Qwen3-8B/32K SWE-bench运行中，我们为专用的7B奖励LLM分配了4个H800 GPU，为rollout分配了28个H800 GPU，但奖励GPU在各个步骤中的平均利用率仅为7.4%（图6）。由于奖励LLM的参数在训练期间保持不变，它可以被视为一个无状态函数，而无服务器部署【11，ServerlessLLM: Low-Latency serverless inference for large language models. 2024. OSDI】【64，Torpor: GPUenabled serverless computing for low-latency, resourceefficient inference. 2025. USENIX ATC】【65，Blitzscale: Fast and live large model autoscaling with O(1) host caching. 2025. OSDI】可以同时避免rollout的资源争用，并回收因专用预留而浪费的空闲GPU预算。

R3：奖励工作者是无状态、突发性的，并且持续利用率不足；将它们与rollout部署在一起会在并发生成时争夺GPU内存，使得弹性的无服务器部署成为更合适的选择。

3.2 阶段间通信

除了计算之外，阶段间通信在智能体RL训练中扮演着关键角色，包括两种不同类型：对稳定性至关重要的小包轨迹传输和带宽密集型的大容量权重更新。

对稳定性至关重要的轨迹传输。轨迹和观察的负载比数GB的权重传输小几个数量级：单个智能体-环境交换通常携带几KB到几MB的token化状态和动作数据，但每个rollout在每条轨迹中会发出数百到数千次这样的交换。因此，累积延迟而非带宽决定了端到端的交互成本。在实践中，环境交互因此应优先考虑网络稳定性而非网络带宽，并且环境交互与LLM生成之间的异步执行可以防止网络延迟成为rollout的瓶颈。

带宽密集型的权重更新。在训练期间，智能体LLM会定期更新其权重，这些权重随后必须与rollout阶段同步。这种权重同步是阶段间通信开销的主要来源。我们使用Mooncake【38，Mooncake: Kimi’s KVCache-centric architecture for LLM serving. 2024. CoRR】测量了在TCP（200 Gbps以太网）和RDMA（400 Gbps InfiniBand）上同步训练和推理集群之间模型参数的端到端传输成本，并在表3中报告了结果。RDMA提供了比TCP更高的带宽和更低的通信开销。在同步RL训练中，rollout阶段只有在最新的智能体LLM权重同步完成后才能继续。因此，在低带宽链路上进行权重传输的巨大成本会增加端到端的训练时间，并削弱解耦训练的加速效果（图2-左）。在异步训练中（图2-右），训练和rollout阶段在不同的GPU上并行执行。尽管这会引入数据陈旧性，但许多先前的工作【18，History doesn’t repeat itself but rollouts rhyme: Accelerating reinforcement learning with rhymerl. 2026. ASPLOS】【29，Part II: ROLL flash - accelerating RLVR and agentic training with asynchrony. 2025. CoRR】根据经验观察到，在有延迟界限的情况下，异步训练可以保持模型质量。鉴于rollout开销占主导地位，异步训练可以有效地将训练和权重同步成本与rollout重叠，从而减少端到端的训练延迟。

R4：为了系统效率和训练质量，训练和rollout必须在独立的GPU集群上以有界延迟的方式并发执行。

A2 方法细节

4. 系统概述

我们提出了ROLLART，一个在解耦的异构资源池中协调智能体RL的rollout、奖励和训练阶段的分布式系统。ROLLART用大约6万行Python代码实现。我们首先介绍系统架构，然后通过一个训练迭代来阐述其工作流程。

4.1 架构

为满足§3中的需求，ROLLART被组织成三个层次化的平面：资源平面、数据平面和控制平面，如图7所示。资源平面决定布局：它跟踪异构硬件池，并使用硬件亲和性声明将每个角色、任务或生成子阶段绑定到兼容的资源类别（R1）。数据平面通过Worker和Cluster抽象来实现流水线，这些抽象封装了用户定义的执行逻辑，并将无状态计算卸载到无服务器基础设施（R3）。控制平面协调进度：它独立地调度轨迹，在轨迹完成后分派奖励计算，缓冲已评分的样本，并在有界延迟协议下将训练与rollout重叠（R2 & R4）。


Figure 7: ROLLART的系统架构。

资源平面。资源平面由资源管理器（图7中的resource manager）实现，它监控解耦硬件池的状态，并根据Worker的角色及其相应的硬件亲和性（例如，将训练绑定到H800 GPU，rollout到H20 GPU，环境执行到CPU服务器，奖励计算到无服务器基础设施）将资源绑定到特定的Worker。

数据平面。数据平面在由资源平面提供的资源上执行分布式RL作业。它由流水线运行器（pipeline runner）实现，该运行器为训练、生成、环境执行和奖励计算构建特定角色的Cluster。每个Cluster随后启动其关联的Worker，并编排它们在适当的后端运行时（例如，Megatron【48，Megatron-LM: Training multi-billion parameter language models using model parallelism. 2019. CoRR】和vLLM【25，Efficient memory management for large language model serving with PagedAttention. 2023. SOSP】）上的执行。通过这种方式，数据平面将用户定义的Worker/Cluster逻辑转化为具体的分布式执行。

控制平面。控制平面协调轨迹级别的rollout和异步训练。它以rollout调度器（rollout scheduler）为中心，该调度器编排环境执行、生成Worker、奖励Worker和训练Worker之间的交互。为了解耦这些阶段，ROLLART引入了两个辅助组件：LLMProxy，它在环境执行和生成Worker之间中介生成请求；以及SampleBuffer，它为训练缓冲已完成并评分的轨迹。这些组件共同允许rollout、奖励评估和模型更新并发进行，从而向用户隐藏了轨迹级别的同步和权重更新协调。

4.2 端到端工作流

为了说明这三个平面如何交互，我们逐步介绍ROLLART中的第一个异步训练迭代。启动时，资源平面中的资源管理器根据用户指定的硬件亲和性，将异构的GPU、CPU和无服务器资源绑定到相应的Cluster，通过分配和放置其组成的Worker。然后，流水线运行器通过实例化相应的Cluster（用于训练、生成、环境执行和奖励计算）来具体化数据平面，每个Cluster都由其分配的Worker和执行引擎支持。

一旦流水线被实例化，控制平面中的rollout调度器会启动多个EnvManager实例来收集轨迹。每个EnvManager交替地通过共享的LLMProxy发出生成请求，并将返回的动作应用于其环境。完成的轨迹由奖励后端评分，并存入SampleBuffer，训练Cluster从中消费批次并更新模型。Rollout、奖励评估和训练并发进行。

以下各节将详细介绍这些平面。§5描述了配置资源和数据平面的编程抽象和机制。§6描述了驱动运行时执行的系统管理控制平面，随后是跨越多个平面的交叉优化。

5. 可编程的资源和数据平面

ROLLART提供了一个声明式的编程模型，将用户意图与系统执行分离开来。用户通过Worker级接口为数据平面指定执行逻辑和任务特定映射，并为资源平面指定硬件偏好。资源管理器解释资源平面的声明以构建在异构资源上的具体绑定，而流水线运行器则通过Cluster抽象来具体化数据平面。

5.1 Worker和Cluster抽象

资源和数据平面围绕两个核心抽象构建：Worker和Cluster。

Worker抽象。Worker是跨越资源和数据平面的基本执行单元。它封装了用户定义的计算逻辑以及方法级别的声明，并在由资源平面提供的硬件上执行。通过子类化和方法注解，Worker可以被特化为跨阶段所需的不同角色，包括训练、生成、奖励和环境。

Cluster抽象。虽然Worker执行实际的计算逻辑，但单独管理数千个Worker对算法开发者来说是不可行的。为了解决这个问题，ROLLART引入了Cluster抽象。一个Cluster充当特定角色Worker组的代理和控制器。Cluster负责生成Worker，绑定它们的方法，并代表它们管理集体调用。在实践中，ROLLART定义了四个Cluster：ActorTrain、ActorGen、Reward和Environment，对应于图7中显示的四个RL阶段。通过组合这些抽象，ROLLART将智能体RL流水线映射到解耦的硬件结构上。

import rollart.distributed as rdist
from rdist.worker import ActorTrainCls, ActorGenCls, RewardCls
from rdist import ResourceManager as RM

# 1. 单控制器示例
class MyActorTrain(ActorTrainCls):
    @rdist.register(mode="execute_all")
    def compute_gradients(self, input_tensor):
        ...

# 2. 在异构GPU上定义actor_gen
# 2.1 异构GPU分配
gen_rm = RM({"H800": list(range(0, 8))},
            {"H20": list(range(8, 32))})
# 2.2 硬件亲和性映射
class HeteroActorGen(ActorGenCls):
    @rdist.hw_mapping(
        hw_affinity={"FrozenLake": "H800", "default": "H20"}
    )
    def generate(self, input_ids: List[int], tag_name: str = "default"):
        return self.model.process(prompt)

# 3. 定义一个无服务器奖励计算函数
class ServerlessRewardWorker(RewardCls):
    @rdist.register_serverless(
        attribute='reward_proxy',
        serverless_url='fc://xxx.xxx'
    )
    def compute_rewards(self, traj: list):
        prompt = f"Evaluate the trajectory: {traj}"
        return ray.get(self.reward_proxy(prompt))

Listing 1: ROLLART的声明式接口

5.2 Worker声明与绑定

ROLLART通过Python装饰器暴露了三个Worker级别的接口，允许用户在统一的单控制器模型下实现特定角色的计算逻辑，并指定任务特定的映射和硬件偏好。资源管理器解释与资源相关的声明，以将Worker绑定到异构资源。

基于装饰器的接口。代码清单1展示了用于Worker声明的三个基于装饰器的接口。
1) 单控制器。与其他工业级RL框架【46，verl: Volcano engine reinforcement learning for LLM. 2024. https://github.com/volcengine/verl】【70 ，slime: An LLM post-training framework for RL scaling. 2025. https://github.com/THUDM/slime】一样，ROLLART采用单控制器编程模型来简化流水线构建。当一 个Worker方法被register装饰器注解并设置为execute_all模式时（代码清单1第7-8行），运行时会广播输入并在相应Cluster中的所有Worker上调用该方法。运行时还会收集返回的结果并自动聚合它们。一个典型的用例是定义如何在每个训练Worker上计算梯度（代码清单1第8行）。
2) 硬件亲和性映射。为了使工作负载特性与硬件能力对齐（R1），ROLLART允许用户通过hw_mapping装饰器为特定角色的Worker声明首选的硬件目标。默认情况下，训练Worker（ActorTrainCls）映射到计算优化型GPU（如H800），生成Worker（ActorGenCls）映射到带宽优化型GPU（如H20），环境Worker（EnvironmentCls）映射到CPU服务器，奖励Worker（RewardCls）映射到本地GPU服务器。用户可以用更细粒度的偏好覆盖这些默认设置。如HeteroActorGen类所示，一个基于字典的资源规范提供了异构GPU组（第13-14行），而hw_mapping装饰器（第17-19行）声明了子阶段的亲和性。预填充密集的FrozenLake rollout被路由到H800 GPU，而所有其他任务默认路由到H20。在运行时，rollout调度器将当前任务的标识（如FrozenLake）作为tag_name参数传递（第21行），允许系统将每个生成请求路由到最合适的硬件。这个声明是故意设计成粗粒度的：用户在任务域级别指定亲和性，而不是执行每个请求的负载均衡。在我们的生产跟踪中，不同的智能体任务域在计算特性（如轮次和预填充/解码比率）上存在差异，使得域标签成为硬件选择的实用基础（§8）。我们的评估证实，这种轻量级的注解足以捕捉异构性以提高吞吐量（§7.3）。这使得亲和性选择是明确的，§9讨论了在线分析器如何在运行时自动或优化这些映射。
3) 无服务器注册。奖励Worker是无状态的，在专用GPU上利用率很低（R3）。为了解决这个问题，ROLLART提供了register_serverless装饰器（第26-28行），将奖励计算卸载到无服务器平台。通过指定的serverless_url，运行时将compute_rewards（第29行）作为一个纯函数调用，通过相同的方法级接口，同时将执行重定向到外部无服务器平台（例如，函数计算【1，Alibaba Cloud function compute. 2025. https://www.alibabacloud.com/en/product/function-compute】）。这使得系统能够实现零开销的自动伸缩，而无需配置昂贵的热备用GPU 。

资源绑定。资源管理器使用一个共享的元数据存储（例如Redis）来维护一个全局、实时的资源池视图，包括计算优化型GPU（如H800）、带宽优化型GPU（如H20）、CPU集群和无服务器端点。Worker级别的注解为单个方法指定硬件亲和性和执行目标。当收到Worker部署请求时，资源管理器解释这些声明以确定具体的放置和绑定。它首先检查首选资源池的可用性，并相应地绑定请求的Worker。如果首选硬件暂时不可用，管理器会机会性地回退到兼容的默认资源，而不是暂停部署。由此产生的绑定元数据被记录下来，用于后续的分派、故障转移和重新配置。


Listing 2: Cluster的简化实现。

5.3 Cluster级别的实现

资源管理器实现了资源平面，而Cluster则在数据平面中管理执行。我们接下来描述默认的Cluster实现如何将Worker级别的装饰器转化为具体的执行行为。

Cluster构建和方法绑定。在初始化时，Cluster使用资源管理器提供的资源，从指定的worker_cls组建一个特定角色的Worker组，并初始化相应的后端运行时（例如，Megatron或vLLM），以便Worker方法在该后端上执行（代码清单2第3行）。每个Worker都与资源元数据相关联，例如其硬件类型，从而实现后续的亲和性感知分派。_bind_worker_method函数随后将worker_cls的每个方法绑定到Cluster实例，允许Cluster充当调用代理（第4行）。例如，如果worker_cls定义了compute_gradients（代码清单1第8行），用户可以直接调用Cluster.compute_gradients。

实现Worker声明。对于使用register装饰器注解的方法，Cluster进入execute_all路径，该路径在每个组成的Worker上调用目标方法，并通过ray.get聚合结果（第6-11行）。对于使用hw_mapping注解的方法，Cluster检查tag_name参数，筛选出资源类型与首选硬件匹配的Worker，并将请求路由到这些Worker（第13-19行）。对于使用register_serverless注解的方法，Cluster用一个调用已注册serverless URL的可调用对象替换奖励代理属性（attr），因此奖励计算由无服务器后端执行（第21-25行）。在所有基于亲和性的路径中，如果首选目标暂时不可用，Cluster会将执行重定向到由资源管理器提供的兼容回退方案，确保在短暂的争用下也能继续前进。

以上抽象和机制，包括Worker逻辑、装饰器注解、资源绑定和Cluster级别的实现，构成了用户在流水线设置时配置的内容。一旦流水线被具体化，控制平面就会接管：它驱动轨迹级别的rollout、奖励评估和异步训练，无需用户进一步干预，我们接下来将对此进行解释。

6. 系统管理的控制平面

ROLLART的控制平面完全由系统管理：用户无需指定任何协调逻辑。在本节中，我们首先描述控制平面如何编排轨迹级别的rollout、奖励和异步训练（§6.1–§6.2），然后介绍跨越数据和控制平面以提高端到端效率的交叉优化（§6.3）。

6.1 轨迹级别的Rollout和奖励

如§3（R2）所识别，批处理的环境交互迫使快速的环境等待“掉队者”，从而增加了端到端的rollout延迟。为了消除这个同步障碍，ROLLART采用了一种轨迹级别的设计，其中每个轨迹独立地通过生成、环境交互和奖励计算。图8给出了一个概述。三个组件实现了这一点：LLMProxy以每个轨迹的粒度分派请求，EnvManager独立驱动每个环境的生命周期，而Reward Worker异步进行评分。


Figure 8: 轨迹级Rollout和奖励概述。

LLMProxy：轨迹级别的LLM生成。如图7所示，LLMProxy位于控制平面中的EnvManager和推理Worker之间。它充当一个网关，将生成客户端与服务实例解耦，跨推理Worker分派每个轨迹的请求。每个推理Worker运行一个命令驱动的事件循环（图8），管理一个推理引擎（例如，vLLM【25，Efficient memory management for large language model serving with PagedAttention. 2023. SOSP】、SGLang【41，SGLang: Fast serving framework for large language models. 2025. https://github.com/sgl-project/sglang】）。这个循环以非阻塞方式持续运行，包含两个组件 ：
1) 步进式命令处理。循环轮询由LLMProxy分派的命令，ADD用于将请求入队，ABORT用于取消现有请求。当没有待处理的命令时，它通过为一批请求执行解码或预填充步骤来推进引擎，从而保持GPU的高利用率。因为命令是在引擎步骤之间处理的，所以添加或中止一个轨迹不会阻塞正在进行的生成。
2) 后处理。当引擎完成一个请求时，循环立即调用一个预先注册的回调函数，该函数后处理输出并将结果返回给请求的EnvManager。这使得每个轨迹在其生成完成后能立即进入环境交互，而无需等待“掉队者”。

EnvManager：轨迹级别的环境交互。每个EnvManager是一个轻量级控制器，管理单个环境的生命周期以收集轨迹（也如图8所示）。它从通过reset进行环境初始化开始，之后进入一个独立的事件循环，通过step来协调环境实例和共享的LLMProxy之间的交互。在此循环中，EnvManager维护一个(observation, action)对的列表以构建轨迹。具体来说，它将历史的(observation, action)序列作为输入提供给LLMProxy以获取下一个动作，通过step将此动作应用于环境，并记录结果观察。与批处理的环境交互（图5b）不同，在批处理中所有环境必须在下一次生成步骤之前同步，每个EnvManager都在其自己的时间线上运行，因此一个缓慢的环境永远不会阻塞其他环境。

重叠Rollout和奖励。一旦一个轨迹完成，运行时会将其分派给一个奖励Worker，该Worker将一个无服务器奖励函数作为非阻塞任务调用。因为每个EnvManager独立地产生轨迹，所以奖励计算在任何单个轨迹完成时就开始，而无需等待整个批次。ROLLART启动多个推理Worker、EnvManager和奖励Worker，以便生成、环境交互和奖励计算在时间上重叠，将奖励延迟隐藏在正在进行的rollout之后，并最大化流水线吞吐量。这种设计避免了将奖励与推理集群部署在一起，因为那会强制进行批处理计算。最近的RL后训练系统【10，AReaL: A large-scale asynchronous reinforcement learning system for language reasoning. 2025. CoRR】【12，RollPacker: Taming long-tail rollouts for RL post-training with tail batching. 2026. NSDI】【57，Reinforcement learning optimization for large-scale learning: An efficient and user-friendly scaling library. 2025. CoRR】【59，MiMo: Unlocking the reasoning potential of language model - from pretraining to posttraining. 2025. CoRR】【67，StreamRL: Scalable, heterogeneous, and elastic RL for LLMs with disaggregated stream generation. 2025. CoRR】也因此采用异步奖励计算。ROLLART通过无服务器部署进一步消除了专用奖励GPU的利用率不足问题（图6）。

6.2 异步训练编排

在解耦的设置中，同步训练迫使rollout Worker在模型权重跨集群传输时处于空闲状态。这个成本随着模型大小的增加而增长（§3, R4）。为了隐藏这个开销，ROLLART将rollout和训练重叠：两个阶段在独立的GPU集群上并发执行，通过一个权重同步协议进行协调（图9）。

权重同步协议。为了在保持rollout和训练重叠的同时将模型权重传播到推理Worker，ROLLART在每次迭代中实现了一个六步同步协议。① get_batch：运行时调用一个阻塞的get_batch调用，从SampleBuffer中检索轨迹，该缓冲区为训练缓冲已评分的轨迹（图7）。流水线会等待直到收集到预定义大小的批次。② suspend：一旦批次准备好，运行时会向LLMProxy发出一个suspend命令，阻止接受新的生成请求，同时保留正在进行的轨迹。③ update：在rollout被暂停后，流水线从训练Worker获取最新的LLM权重并更新所有推理Worker。④ resume：完成后，向LLMProxy发出一个resume命令，然后LLMProxy继续处理待定的生成请求。⑤ recomp & rollout：为了重用在先前模型版本下生成的正在进行的轨迹，ROLLART执行KV缓存重计算，在更新后的权重下重建每个轨迹的KV缓存，以便生成可以继续而无需从头开始。⑥ train_step：与恢复的rollout并行，流水线在①中检索到的批次上执行train_step，允许训练与正在进行的rollout重叠。


Figure 9: 异步训练工作流。

异步边界和缓冲区管理。上述协议让rollout和训练并发进行，但SampleBuffer中的轨迹可能来自不同的模型版本。过度的陈旧性会增加方差并破坏训练的稳定性，因此ROLLART为每个轨迹强制执行一个异步边界α（R4）。如果当前智能体LLM的版本是n，任何缓冲的轨迹必须由不早于（n - α）的版本启动；超出此窗口的轨迹将被中止。这个相同的版本窗口限制了缓冲区的增长：对于E个并发环境，SampleBuffer在不同版本间最多持有O(α · E)个待处理的轨迹。在get_batch形成训练批次之前，它会主动驱逐陈旧的轨迹，因此高度异步或乱序的完成不会导致无限制的缓冲区增长。我们的实证研究（§7.2）表明，α = 1在训练速度和稳定性之间取得了平衡。

6.3 交叉优化

上述执行工作流依赖于跨越数据和控制平面的数据移动、硬件专用的服务和调度机制。我们描述了三个提高端到端效率的优化。

数据移动。ROLLART为每个数据路径匹配适当的传输机制。传输协议将轨迹和监督信号作为Ray的对象引用【34，Ray: A distributed framework for emerging AI applications. 2018. OSDI】在各阶段之间流式传输。交换的对象被分片以匹配每个Worker的并行布局。模型更新组在各阶段之间同步权重。集群内权重同步使用NCCL【35，NVIDIA collective communication library (NCCL). 2025. https://github.com/NVIDIA/nccl】通过NVLink或InfiniBand。主要瓶颈是跨集群权重更新，它通过较低带宽的以太网连接训练集群和推理集群。ROLLART通过一个基于Mooncake【38 ，Mooncake: Kimi’s KVCache-centric architecture for LLM serving. 2024. CoRR】的异步权重更新引擎来解决这个问题：在每个训练步骤之后，更新的权重被分桶（例如，1GB）并发布到一个远程CPU驻留的Mooncake存储中，而不是同步推送到远程推理Worker。推理Worker然后按需从Mooncake存储中异步获取最新的权重桶，将权重传输与正在进行的rollout解耦，并避免由缓慢的跨集群通信引起的GPU停顿。这使得数据移动变得明确：训练Worker通过较低带宽的跨集群链接写入权重桶一次，而推理Worker则通过高带宽的集群内链接拉取它们。通过Mooncake存储增加的额外一跳只引入了最小的开销，正如我们在§7.4中量化的那样。虽然Mooncake增加了一个拉取步骤，但它使用了优化的数据移动（例如，零拷贝传输），并与正在进行的rollout和权重推送重叠。对于较小的模型，绝对传输量也较低，限制了暴露的延迟。我们在§7.4中量化了累积的拉取成本和未被重叠的暴露开销。

冗余环境Rollout。在控制平面内，LLMProxy和EnvManager的轨迹级设计使得我们能够实现一种称为冗余环境rollout的优化。这允许系统启动比收集轨迹所需更多的环境。一旦收集到目标数量的轨迹，正在进行的轨迹就可以被终止。因为rollout是在轨迹粒度上管理的，所以缓慢或失败的环境不会阻塞更快的环境，从而减轻了“掉队者”（§7.4）和环境失败（§8）的影响。

预填充-解码（PD）解耦。在数据平面内，PD解耦，这一在LLM服务系统【37，Splitwise: Efficient generative LLM inference using phase splitting. 2024. ISCA】【66，DistServe: Disaggregating prefill and decoding for goodputoptimized large language model serving. 2024. OSDI】中广泛采用的技术，优化了§6.1中描述的LLMProxy路由。ROLLART通过在计算优化型和带宽优化型GPU上分别部署预填充和解码Worker，并将每个请求的两个阶段路由到相应的Worker来支持PD解耦。我们在§7.4中评估了上述优化。

A4 实验环境

  • 模型与任务：使用Qwen3系列模型（8B至32B参数），最大上下文长度为32k tokens，在表1所示的多种智能体任务上进行训练。由于SWE-bench任务难度较大，仅用于Qwen3-32B模型。对于数学任务，使用Qwen2.5-7B作为奖励LLM来验证推理过程。

  • 硬件配置：

    • GPU：一个包含96个H800 GPU的集群和一个包含32个H20 GPU的集群。
    • 网络：集群内节点通过400 Gbps InfiniBand连接；跨集群通信使用200 Gbps以太网。
    • CPU：一个专用于SWE-bench的CPU集群，另一个用于其余环境。
    • 其他：使用内部无服务器平台处理奖励工作。
    • 除非另有说明，所有实验均使用128个GPU。

  • 软件配置：

    • 训练算法：GRPO【19，DeepMath103K: A large-scale, challenging, decontaminated, and verifiable mathematical dataset for advancing reasoning. 2025. CoRR】，批大小512，组大小8。
    • 实现库：Rollout在vLLM 0.8.4上运行，训练在Megatron v0.12.2上运行。
    • 通信库：使用NCCL v2.26.5进行集群内权重更新，使用Mooncake v0.3.7【38，Mooncake: Kimi’s KVCache-centric architecture for LLM serving. 2024. CoRR】进行跨集群通信。

  • 基线系统：

    • Sync：标准的同步RL流水线。
    • Sync+：在Sync基础上增加了异步奖励计算、异步环境交互和无服务器卸载。
    • One-off【32，DeepScaleR: Surpassing O1-Preview with a 1.5b model by scaling RL. 2025. https://pretty-radio-b75.notion.site/DeepScaleR-Surpassing-O1-Preview-with-a-1-5B-Model-by-Scaling-RL-19681902c1468005bed8ca303013a4e2】：一种异步方法，通过消费上一步的轨迹来重叠rollout和训练 。
    • AReaL【10，AReaL: A large-scale asynchronous reinforcement learning system for language reasoning. 2025. CoRR】：一种具有特定延迟边界的异步系统。
    • 所有基线系统均在128个H800 GPU上运行，以进行公平比较。

A4 实验结果

端到端评估

  • 模型收敛性 (图10a)：在Qwen3-32B模型上，为了达到0.85的目标分数，ROLLART (α=1) 的训练时间分别比Sync+、One-off和AReaL快2.05倍、1.35倍和1.31倍。这表明ROLLART的异步机制在不牺牲模型质量的前提下显著加速了训练。将异步边界增加到α=2虽然初期收敛更快，但后期达到目标分数的时间略有增加，验证了吞吐量与质量的权衡。
  • 吞吐量效率 (图10b)：与Sync+基线相比，ROLLART在不同模型尺寸（8B, 14B, 32B）上实现了1.22-1.36倍于AReaL的吞吐量，整体吞吐量是Sync基线的2.65-4.58倍。实验分解了各项优化的贡献：异步奖励/环境交互、训练/rollout重叠、以及硬件亲和性路由，每一项都带来了显著的吞吐量提升。
  • 扩展效率 (图10c)：在Qwen3-14B模型上，将GPU数量从64个扩展到128个时，ROLLART表现出比Sync+、One-off和AReaL更好的扩展性，吞吐量增益更大，证明了其架构在大规模集群上的高效性。


Figure 10: 端到端结果：(a) Qwen3-32B达到目标分数的时间；(b) 不同LLM的吞吐量（相对于Sync+归一化）；(c) Qwen3-14B在不同H800 GPU数量下的吞吐量（相对于64个H800 GPU上的Sync+归一化）。

设计需求消融实验

  • R1: 硬件亲和性映射 (图11a)：在一个成本大致相等的混合GPU配置（64个H800 + 24个H20）中，通过将任务路由到最适合的GPU，ROLLART的步进时间比纯H800配置减少了1.12-1.37倍，比纯H20配置减少了1.30-1.68倍。这证实了为prefill密集型和decode密集型任务匹配不同GPU类型的重要性。
  • R2: 轨迹级异步 (图11b)：通过人工注入不同方差的环境延迟，实验表明轨迹级rollout比批处理交互更能吸收延迟变化。当延迟标准差从1秒增加到10秒时，轨迹级rollout的性能优势从1.23倍扩大到2.27倍，有效缓解了环境“掉队者”问题。
  • R3: 无服务器卸载 (图12)：与为奖励模型预留本地GPU相比，无服务器卸载将奖励GPU的平均利用率从6%提高到88%，并将每步的rollout时间从158秒减少到77秒（减少了一半）。这证明了无服务器化在回收闲置资源和加速rollout方面的巨大优势。
  • R4: 异步边界 (图13)：实验表明，增加异步边界α可以减少因延迟过高而被中止的轨迹，从而缩短步进时间。但这种增益很快达到平台期，α=1在吞吐量和模型收敛性之间提供了一个很好的平衡点。


Figure 11: (a) 硬件亲和性和 (b) 轨迹级rollout的效率，其中环境延迟从均值为µ=10秒、标准差σ从1到10秒（x轴）的高斯分布中采样。


Figure 12: 专用本地GPU与使用无服务器卸载的比较。


Figure 13: 不同LLM和异步边界下的平均步进时间。

交叉优化评估

  • 异步权重传输 (图14a, 表4)：ROLLART的异步跨集群通信机制（基于Mooncake）比同步方案（如veRL的NCCL）将端到端步进时间减少了1.10-1.16倍。通过与rollout重叠，该机制隐藏了67-78%的权重拉取成本，将暴露的开销从38.6-157.0秒降低到最多9.6秒。
  • 冗余环境Rollout (图14b)：通过启动比所需更多的环境，系统可以提前完成轨迹收集，从而掩盖环境故障和“掉队者”的影响。实验中，该优化带来了高达1.62倍的rollout加速。
  • PD解耦 (表5)：将prefill和decode阶段分离到不同类型的GPU上，对于MoE模型在SWE任务上取得了1.11-1.21倍的加速，而对于密集模型效果较温和（1.03-1.05倍）。这表明其效果依赖于模型和工作负载。


Figure 14: 交叉优化：(a) 异步跨集群权重传输；(b) 冗余环境rollout。

Table 4: ROLLART异步跨集群权重传输（秒）的分解。

Table 5: 不同模型和配置下，colocation和disaggregation的rollout时间（秒）对比。

解耦税评估

  • 量化开销：解耦引入了数据传输开销。跨集群权重同步是最大的开销，但ROLLART的异步机制隐藏了大部分成本，暴露的残余成本仅为1.4-9.6秒。环境交互和无服务器奖励调用的I/O开销则非常小（平均每次调用0.02秒和0.01秒），可以忽略不计。因此，解耦带来的吞吐量增益远大于其引入的开销。

生产环境中的ROLLART

  • 大规模部署：ROLLART已在阿里巴巴内部用于数千个智能体RL作业。其中一个案例是使用超过3000个GPU训练一个千亿级参数的MoE模型，持续运行一周。
  • 生产负载特征 (图15)：该部署证实了实验室中的观察：任务混合了prefill密集型和decode密集型行为；“掉队者”现象持续存在（最长响应长度是平均值的9倍）；等待数据收集（get_batch）成为GPU空闲的主要原因，占迭代时间的62%。
  • 针对性优化：
    • 环境稳定性：通过部署多层缓存（内部镜像和分布式缓存）来处理Docker镜像拉取，将env.reset的成功率提升至99.99%以上，有效解决了环境初始化失败的问题。
    • 系统弹性：ROLLART的架构能隔离各组件的故障。在为期一周的运行中，系统仅出现一次故障，展示了其鲁棒性。
    • 通过基于负载特征的资源调优和环境稳定性优化，端到端速度比初始配置提升了1.66倍。


Figure 15: 生产级智能体RL工作负载的表征和优化。

A7 补充细节

9. 讨论与相关工作

自动化硬件亲和性映射。当前ROLLART需要用户静态地为每个任务域声明硬件亲和性，这在计算特性会动态变化的场景下是一个局限。然而，在生产部署中，我们观察到每个任务域的特性（如交互轮次）是相对稳定的，因此粗粒度的静态hw_mapping声明在为期一周的3000-GPU运行中无需重新调整，证明了其作为起点的实用性。一个自然的扩展是集成一个在线分析器到资源管理器中：通过监控每个域的prefill/decode延迟，ROLLART可以动态调整路由策略以应对域内特性的变化（例如，一个域在长观察和长响应提示之间交替）。同样的分析也可以驱动PD解耦的比例配置（§6.3）。由于工作负载特性主要由任务域身份而非每步的策略方差决定，分析决策在几次迭代后即可稳定，因此不需要达到每步最优。

适用场景。ROLLART主要针对在异构、解耦基础设施上进行的多任务智能体RL；在同构集群上，其硬件亲和性路由（R1）的优势会消失；对于严格的on-policy或计算量轻的RL任务，其有界延迟异步训练（R4）的重叠效果有限；在没有弹性计算资源的环境中，无服务器卸载（R3）也无法实现。然而，轨迹级rollout（R2）和冗余环境rollout（§7.4）对于任何面临长尾环境问题的智能体RL工作负载都适用。

RL后训练系统。许多系统致力于解决RL后训练的系统挑战。早期的框架【17，NeMo: A toolkit for conversational AI and large language models. 2025. https://github.com/NVIDIA/NeMo】【21 ，OpenRLHF: An easy-to-use, scalable and high-performance RLHF framework. 2024. CoRR】【46，verl: Volcano engine reinforcement learning for LLM. 2024. https://github.com/volcengine/verl】【62 ，DeepSpeed-Chat: Easy, fast and affordable RLHF training of ChatGPT-like models at all scales. 2023. CoRR】通过适当的阶段和资源映射来提高利用率。后续系统【5，ReSpec: Towards optimizing speculative decoding in reinforcement learning systems. 2025. CoRR】【6，Fast LLM post-training via decoupled and best-of-n speculation. 2025. CoRR】【10，AReaL: A large-scale asynchronous reinforcement learning system for language reasoning. 2025. CoRR】【15，AsyncFlow: An asynchronous streaming RL framework for efficient LLM post-training. 2025. CoRR】【18，History doesn’t repeat itself but rollouts rhyme: Accelerating reinforcement learning with rhymerl. 2026. ASPLOS】【27，SPECRL: Accelerating on-policy reinforcement learning via speculative rollouts. 2025. CoRR】【43，Beat the long tail: Distribution-aware speculative decoding for RL training. 2025. CoRR】【45，Laminar: A scalable asynchronous RL post-training framework. 2026. EuroSys】【67，StreamRL: Scalable, heterogeneous, and elastic RL for LLMs with disaggregated stream generation. 2025. CoRR】【68，Optimizing RLHF training for large language models with stage fusion. 2025. NSDI】探索了一系列加速技术，包括推测解码、流水线阶段融合、异步或解耦训练以隐藏延迟，以及各种形式的资源解耦。ROLLART建立在解耦范式之上，并根据硬件亲和性分配工作负载。

资源解耦。资源解耦在许多现代系统中被用于提高利用率【14，Mira: A program-behavior-guided far memory system. 2023. SOSP】【26，Disaggregated memory for expansion and sharing in blade servers. 2009. ISCA】【42，LegoOS: A disseminated, distributed OS for hardware resource disaggregation. 2018. OSDI】。这种模式在LLM服务中很普遍，其中系统将预填充和解码阶段分开【20，Inference without interference: Disaggregate LLM inference for mixed downstream workloads. 2024. CoRR】【37，Splitwise: Efficient generative LLM inference using phase splitting. 2024. ISCA】【38，Mooncake: Kimi’s KVCache-centric architecture for LLM serving. 2024. CoRR】【51，Step-3 is large yet affordable: Model-system co-design for cost-effective decoding. 2025. CoRR】【52，Déjàvu: KV-cache streaming for fast, fault-tolerant generative LLM serving. 2024. ICML】【66，DistServe: Disaggregating prefill and decoding for goodputoptimized large language model serving. 2024. OSDI】【69，MegaScaleInfer: Efficient mixture-of-experts model serving with disaggregated expert parallelism. 2025. SIGCOMM】。一些RL系统也应用了类似原则，将训练和rollout阶段分离到不同类型的GPU上【56，SeamlessFlow: A trainer agent isolation RL framework achieving bubble-free pipelines via tag scheduling. 2025. CoRR】【67，StreamRL: Scalable, heterogeneous, and elastic RL for LLMs with disaggregated stream generation. 2025. CoRR】。与这些方法相比，ROLLART提供了一个更通用、更细粒度的解耦模型，为多任务智能体RL的整个生命周期量身定制。

A5 结论

本文介绍了ROLLART，一个用于在解耦基础设施上进行多任务智能体RL训练的系统。其设计基于四个核心需求：基于硬件亲和性的工作负载映射（R1）、轨迹级别的异步rollout（R2）、对无状态奖励的无服务器卸载（R3）以及有界延迟的异步训练（R4）。在Qwen3（8B–32B）模型上的实验表明，与加强版的同步、one-off和AReaL基线相比，ROLLART将步进时间减少了1.31至2.05倍。一个为期一周、使用超过3000个GPU的生产部署，训练了一个千亿级参数的MoE模型，证实了这些增益在大规模环境下的有效性。

方法细节中的引用汇总

  • §4.1 数据平面:

    • 【48，Megatron-LM: Training multi-billion parameter language models using model parallelism. 2019. CoRR】: 用于描述数据平面中训练Cluster可以使用的后端运行时。
    • 【25，Efficient memory management for large language model serving with PagedAttention. 2023. SOSP】: 用于描述数据平面中生成Cluster可以使用的后端运行时。

  • §5.2 Worker声明与绑定:

    • 【46，verl: Volcano engine reinforcement learning for LLM. 2024. https://github.com/volcengine/verl 】: 引用来说明ROLLART与其它工业级RL框架一样采用单控制器编程模型。
    • 【70，slime: An LLM post-training framework for RL scaling. 2025. https://github.com/THUDM/slime 】: 同上，作为工业级RL框架的例子。
    • 【1，Alibaba Cloud function compute. 2025. https://www.alibabacloud.com/en/product/function-compute 】: 引用作为register_serverless装饰器可以重定向到的外部无服务器平台的一个例子。

  • §6.1 轨迹级别的Rollout和奖励:

    • 【25，Efficient memory management for large language model serving with PagedAttention. 2023. SOSP】: 引用作为推理Worker可以管理的推理引擎之一。
    • 【41，SGLang: Fast serving framework for large language models. 2025. https://github.com/sgl-project/sglang 】: 同上，作为推理引擎的另一个例子。
    • 【10，AReaL: A large-scale asynchronous reinforcement learning system for language reasoning. 2025. CoRR】, 【12，RollPacker: Taming long-tail rollouts for RL post-training with tail batching. 2026. NSDI】, 【57，Reinforcement learning optimization for large-scale learning: An efficient and user-friendly scaling library. 2025. CoRR】, 【59，MiMo: Unlocking the reasoning potential of language model - from pretraining to posttraining. 2025. CoRR】, 【67，StreamRL: Scalable, heterogeneous, and elastic RL for LLMs with disaggregated stream generation. 2025. CoRR】: 引用来说明最近的RL后训练系统也采用异步奖励计算来避免批处理。

  • §6.3 交叉优化:

    • 【34，Ray: A distributed framework for emerging AI applications. 2018. OSDI】: 引用来说明轨迹和信号在阶段间作为Ray的对象引用进行流式传输。
    • 【35，NVIDIA collective communication library (NCCL). 2025. https://github.com/NVIDIA/nccl 】: 引用来说明集群内权重同步使用NCCL。
    • 【38，Mooncake: Kimi’s KVCache-centric architecture for LLM serving. 2024. CoRR】: 引用作为ROLLART解决跨集群权重更新瓶颈所依赖的异步权重更新引擎。
    • 【37，Splitwise: Efficient generative LLM inference using phase splitting. 2024. ISCA】, 【66，DistServe: Disaggregating prefill and decoding for goodputoptimized large language model serving. 2024. OSDI】: 引用作为LLM服务系统中广泛采用PD解耦技术的例子。