ProRL Agent: Rollout-as-a-Service for RL Training of Multi-Turn LLM Agents

发表时间: 2026-03 · arXiv:2603.18815 (NVIDIA NeMo Gym)

Hao Zhang*, Mingjie Liu*, Shaokun Zhang*, Songyang Han, Jian Hu, Zhenghui Jin, Yuchi Zhang, Shizhe Diao, Ximing Lu, Binfeng Xu, Zhiding Yu, Jan Kautz, Yi Dong

A1 主要贡献

本文探讨了在多轮次大型语言模型（LLM）智能体的强化学习（RL）训练中存在的一个核心问题：现有的RL训练框架通常将智能体在沙盒环境中的轨迹生成（rollout）过程与策略训练循环紧密耦合。这种设计导致了两个主要限制：

  1. 冲突的系统需求：Rollout是I/O密集型任务，涉及沙盒创建、长时工具会话和异步协调；而策略训练是GPU密集型任务，专注于前向/后向传播和梯度同步。将两者耦合会导致资源竞争，降低整体效率。
  2. 迁移和维护困难：当rollout逻辑嵌入训练器中时，更换训练后端或改进rollout基础设施（如支持新环境或任务）都变得非常困难，需要对耦合的系统进行大量修改，减缓了双方的独立发展。

为了解决这一问题，本文提出了ProRL Agent，一个基于“rollout即服务”（rollout-as-a-service）理念构建的可扩展基础架构。其核心思想是将智能体的整个rollout生命周期（从环境初始化到结果评估）从训练器中解耦出来，作为一个独立的HTTP服务。如下图所示，训练器仅通过API提交rollout请求并接收完成的轨迹和奖励，而无需管理rollout过程的任何细节。

图1：耦合与解耦设计对比。左图：现有框架通常将完整的智能体rollout生命周期嵌入到RL训练栈中。右图：ProRL Agent将rollout视为一个独立的HTTP服务。训练器提交rollout请求并接收完成的轨迹和奖励，而rollout服务器处理环境执行、工具使用、评估和推理协调。这种解耦设计改善了资源隔离、可移植性和可扩展性。
图1：耦合与解耦设计对比。左图：现有框架通常将完整的智能体rollout生命周期嵌入到RL训练栈中。右图：ProRL Agent将rollout视为一个独立的HTTP服务。训练器提交rollout请求并接收完成的轨迹和奖励，而rollout服务器处理环境执行、工具使用、评估和推理协调。这种解耦设计改善了资源隔离、可移植性和可扩展性。

本文的主要贡献如下：

  • 识别并解决了现有智能体RL训练框架的核心局限性：指出现有框架中多轮次智能体rollout与RL训练栈的紧密耦合问题，并提出ProRL Agent作为解决方案。ProRL Agent基于“rollout即服务”原则，通过统一的HTTP接口将完整的rollout生命周期与训练器解耦。

  • 为多轮次RL训练设计了多个实用特性：

    • Token-in/Token-out：在整个训练流程中使用token ID进行通信，避免了因重编码（re-tokenization）导致的漂移问题。
    • 可扩展的沙盒环境：为异构工具和任务提供灵活支持。
    • 无根（rootless）部署：支持在共享的高性能计算（HPC）集群中进行部署，适应了常见的权限和隔离约束。

  • 通过端到端RL训练验证了ProRL Agent的有效性：在软件工程、数学、STEM和编码等多个智能体领域，使用ProRL训练框架【【15】ProRL: Prolonged Reinforcement Learning Expands Reasoning Boundaries in Large Language Models, 2025, 39th Conference on Neural Information Processing Systems】对4B、8B和14B规模的模型进行了训练。实验结果表明，该架构在SWE-Bench Verified等基准上取得了显著的性能提升。

A3 相关工作

与现有用于多轮次智能体RL的框架对比: ProRL Agent的特点是解耦了rollout与训练，支持在共享HPC环境中进行无根沙盒化，并且独立于任何特定的训练框架。

表1：ProRL Agent与现有多轮次智能体RL框架的比较。ProRL Agent将rollout与训练解耦，支持共享HPC环境的无根沙盒，并且独立于任何特定的训练框架。
表1：ProRL Agent与现有多轮次智能体RL框架的比较。ProRL Agent将rollout与训练解耦，支持共享HPC环境的无根沙盒，并且独立于任何特定的训练框架。

多轮次LLM智能体的强化学习。强化学习在提升单轮次推理任务（如数学、逻辑和编码）方面非常有效【【5】Deepseek-r1: Incentivizing reasoning capability in llms via reinforcement learning, 2025, arXiv】,【【6】Open-reasonerzero: An open source approach to scaling up reinforcement learning on the base model, 2025, arXiv】,【【23】Deepseekmath: Pushing the limits of mathematical reasoning in open language models, 2024, arXiv】,【【33】Nemotron-research-tool-n1: Exploring tool-using language models with reinforced reasoning, 2026, The Fourteenth International Conference on Learning Representations】。近期研究已将RL扩展到多轮次智能体场景，智能体在这些场景中与外部环境进行长时程交互【【2】Skyrl-v0: Train real-world long-horizon agents via reinforcement learning, 2025a】,【【4】Beyond ten turns: Unlocking long-horizon agentic search with large-scale asynchronous rl, 2025, arXiv】,【【11】Search-r1: Training llms to reason and leverage search engines with reinforcement learning, 2025, arXiv】,【【14】Torl: Scaling tool-integrated rl, 2025, arXiv】,【【18】Deepswe: Training a state-of-the-art coding agent by scaling rl, 2025a】,【【28】VAGEN: Reinforcing world model reasoning for multi-turn VLM agents, 2025, The Thirty-ninth Annual Conference on Neural Information Processing Systems】,【【30】Ragen-v2: Understanding reasoning collapse in multi-turn agent reinforcement learning, 2026】。在这些场景中，多轮次智能体被自然地建模为部分可观察马尔可夫决策过程（POMDP）【【12】Planning and acting in partially observable stochastic domains, 1998, Artificial Intelligence】，智能体通过工具调用产生动作【【22】The berkeley function calling leaderboard (BFCL): From tool use to agentic evaluation of large language models, 2025, Forty-second International Conference on Machine Learning】,【【29】Executable code actions elicit better llm agents, 2024a】,【【32】Offline training of language model agents with functions as learnable weights, 2024, Forty-first International Conference on Machine Learning】,【【35】React: Synergizing reasoning and acting in language models, 2022, The Eleventh International Conference on Learning Representations】并在每一步接收环境观察。随着任务复杂性增加，多轮次rollout通常涉及在多样化环境中（如代码仓库【【7】R2e-gym: Procedural environments and hybrid verifiers for scaling open-weights swe agents, 2025, arXiv】,【【10】Swe-bench: Can language models resolve real-world github issues?, 2024, The Twelfth International Conference on Learning Representations】、网页浏览器【【37】Webarena: A realistic web environment for building autonomous agents, 2023, arXiv】甚至计算机操作系统【【31】Osworld: Benchmarking multimodal agents for open-ended tasks in real computer environments, 2024, Advances in Neural Information Processing Systems】）执行数十个步骤。因此，大规模生成、管理和评估这些rollout所需的基础设施已成为RL训练的主要瓶颈。ProRL Agent旨在通过将多轮次智能体rollout的整个生命周期与训练栈解耦来应对这一挑战，使研究人员和从业者能专注于训练算法和智能体设计。

智能体RL基础设施。越来越多的工作开始解决智能体可扩展RL训练的挑战，包括支持多样化的工具集成【【8】Verl-tool: Towards holistic agentic reinforcement learning with tool use, 2025, arXiv】,【【14】Torl: Scaling tool-integrated rl, 2025, arXiv】、灵活的环境抽象【【16】Gem: A gym for agentic llms, 2025b, arXiv】,【【26】rllm: A framework for post-training language agents, 2025】和高效的rollout调度【【3】Skyrl-agent: Efficient rl training for multi-turn llm agent, 2025b, arXiv】。然而，在这些框架中，rollout的编排，包括环境生命周期管理、工具执行、轨迹收集和评估，仍然是作为训练循环内的进程内库实现的。在这种设计下，采用新的训练后端通常需要重新实现或移植整个rollout栈。这种紧密耦合使得rollout基础设施成为多轮次智能体RL中的主要摩擦源，其工程工作量常常超过训练算法本身。

智能体沙盒环境。多轮次智能体训练需要能够大规模提供隔离性、可复现性和安全性的沙盒环境。现有平台【【7】R2e-gym: Procedural environments and hybrid verifiers for scaling open-weights swe agents, 2025, arXiv】,【【10】Swe-bench: Can language models resolve real-world github issues?, 2024, The Twelfth International Conference on Learning Representations】,【【29】Openhands: An open platform for ai software developers as generalist agents, 2024b, The Thirteenth International Conference on Learning Representations】,【【34】Swe-agent: Agent-computer interfaces enable automated software engineering, 2024, Advances in Neural Information Processing Systems】已经建立了一些基本协议，但它们深度依赖Docker进行智能体执行。Docker需要守护进程访问权限和等同于root的权限，这在共享的Slurm管理的HPC集群上通常是不可用的。因此，从业者常常面临在为评估和部署维护独立基础设施，或在受限系统上承担特权容器运行时操作复杂性之间的权衡。ProRL Agent通过在Singularity上构建其沙盒基础设施来解决这一限制，实现了无根执行和原生的Slurm集成，从而支持在HPC系统上进行大规模的智能体训练。

A2 方法细节

图2：ProRL Agent架构概览。该系统由三个组件构成。(1) 沙盒环境：每个rollout都在一个SingularityRuntime容器内执行，并由AgentHandler进行编排，该处理器暴露了init()、run()和eval()三个生命周期方法，分别用于环境设置、多轮次智能体执行和奖励评分。(2) ProRL Agent服务器：一个HTTP服务，通过一个三阶段异步流水线（INIT → RUN → EVAL）和独立的工??池来管理rollout，并维护一个支持动态注册和检查点切换的最小堆LLM后端池。(3) RL训练器：任何训练框架（例如veRL、NeMo RL）仅通过HTTP与服务器交互，通过POST /process提交作业，并通过/add_llm_server和/cancel管理后端；完成的轨迹和奖励会返回给训练器以更新策略。
图2：ProRL Agent架构概览。该系统由三个组件构成。(1) 沙盒环境：每个rollout都在一个SingularityRuntime容器内执行，并由AgentHandler进行编排，该处理器暴露了init()、run()和eval()三个生命周期方法，分别用于环境设置、多轮次智能体执行和奖励评分。(2) ProRL Agent服务器：一个HTTP服务，通过一个三阶段异步流水线（INIT → RUN → EVAL）和独立的工??池来管理rollout，并维护一个支持动态注册和检查点切换的最小堆LLM后端池。(3) RL训练器：任何训练框架（例如veRL、NeMo RL）仅通过HTTP与服务器交互，通过POST /process提交作业，并通过/add_llm_server和/cancel管理后端；完成的轨迹和奖励会返回给训练器以更新策略。

3.1. 概览

现有系统的耦合问题。在智能体任务上训练RL智能体通常涉及与实时执行环境的多轮次交互。每个数据样本都包含沙盒环境设置、工具执行和结果评分，这一过程比单步生成复杂得多。先前的系统通常将rollout逻辑直接嵌入训练循环中【【3】Skyrl-agent: Efficient rl training for multi-turn llm agent, 2025b, arXiv】，将智能体任务循环、执行环境和RL算法紧密耦合。当切换任务和RL训练器时，这种耦合带来了巨大的工程开销。

ProRL Agent的解耦设计。ProRL Agent通过“rollout即服务”的设计和rollout级别的解耦来解决这个问题，其中rollout的编排与训练过程完全分离。具体来说，ProRL Agent服务器作为一个独立的HTTP服务运行，它接收一个任务实例，内部执行完整的智能体rollout，并返回一个带有奖励信号的已完成轨迹。训练框架仅通过此接口与服务器交互，对RL基础设施保持无知。

解耦带来的实际优势。这种解耦设计带来了三个实际好处：
* RL训练器和智能体rollout逻辑可以独立开发和部署：rollout节点和训练节点可以分别进行优化以获得更大的吞吐量。
* 添加新任务仅需要在rollout服务器端实现一个处理器插件，而无需更改训练代码。
* 智能体脚手架可以被修改或替换而不影响训练基础设施，因为rollout服务和智能体实现是完全解耦的。

系统架构概览。图2展示了整体架构，它由三个主要组件构成：可扩展的沙盒环境、用于rollout调度的ProRL Agent服务器，以及RL训练后端。我们将依次介绍每个组件以及它们在系统中的交互方式。

3.2. 可扩展的沙盒环境

在多样化的多轮次智能体任务上进行RL训练通常需要一个沙盒层，该层既能适应异构的任务环境，又能在没有特权访问的情况下在HPC集群上可移植地运行。我们围绕两个组件构建了这样的沙盒系统：一个将特定于任务的逻辑与服务器核心解耦的可插拔任务抽象，以及一个支持大规模隔离、无根的智能体任务执行的HPC兼容容器运行时。

3.2.1. 可插拔的任务抽象

AgentHandler接口设计。不同的智能体任务，如软件工程、数学推理、计算机使用，各自需要独特的环境设置、智能体行为和奖励计算。在服务器中硬编码这些差异会使其变得脆弱且高度依赖人力。因此，我们将所有特定于任务的逻辑封装在一个名为AgentHandler的抽象接口中，它定义了与三个流水线阶段相对应的三个核心生命周期方法：
* init: 初始化任务的沙盒环境，为智能体配置相应的工具集。
* run: 在准备好的沙盒环境中驱动多轮次智能体循环，收集动作-观察轨迹和任何任务产物。
* eval: 根据基准事实对智能体的输出进行评分，并返回一个标量奖励信号供后续的RL训练使用。

错误处理与结果序列化。每个处理器还额外暴露了针对每个阶段的错误回调函数（init_exception, run_exception, eval_exception）和一个final_result方法用于响应序列化，确保即使rollout中途失败，服务器也总能发出格式正确的输出。代码清单1展示了该接口和一个最小的注册示例。

# 代码清单1：AgentHandler接口和任务注册。每个任务域都子类化AgentHandler并在一个唯一的名称下注册。服务器通过匹配不同的注册表来分发传入的作业。

class AgentHandler ( ABC ) : 
    @abstractmethod 
    async def init ( self , job_details ) -> ( Runtime , Metadata , Config ) : 
        """ Provision environment ; return ( runtime , metadata , config ).""" 
    @abstractmethod 
    async def run ( self , job_details ) -> dict : 
        """ Execute agent loop ; return trajectory and artifacts .""" 
    @abstractmethod 
    async def eval ( self , job_details ) -> dict : 
        """ Score output ; return reward signal .""" 
    # Error callbacks (one per stage ) and result serializer 
    def init_exception ( self , job_details , exc ) -> dict : 
    def run_exception ( self , job_details , exc ) -> dict : 
    def eval_exception ( self , job_details , exc ) -> dict : 
    def final_result ( self , job_details ) -> dict :

任务分发机制。当服务器收到一个作业时，它会读取任务实例，在注册表中查找相应的处理器，并按顺序将其分派给其生命周期方法。

3.2.2. HPC兼容的容器运行时

SingularityRuntime的引入。大多数智能体沙盒环境都假设在云或工作站环境中使用，其中Docker随时可用。然而，HPC集群出于安全原因通常禁止Docker守护进程，要求所有用户进程在批处理调度程序（如Slurm）下以无root权限运行。为了弥合这一差距，我们实现了SingularityRuntime，这是一个无需持久守护进程并完全作为非特权用户进程运行的容器系统，用于提供沙盒环境。

容器隔离与端口管理。每个容器都作为其自身会话中的一个子进程启动；关闭时会先通过SIGTERM优雅地进行，如有必要再升级为SIGKILL。为了支持在同一节点上同时运行许多容器而无端口冲突，每个容器实例通过一个线程安全的分配器被分配一个在127.x.x.x范围内的唯一环回IP地址。两个标志解决了常见的HPC约束：–fakeroot为容器授予模拟的root访问权限以进行软件包安装，而无需实际的主机权限；–network none可选择性地禁用外部网络访问，以隔离rollout免受干扰。

镜像构建流水线。容器镜像被打包成Singularity镜像文件（.sif），它将完整的执行环境封装在一个单一的可移植文件中。这种格式特别适合Slurm共享文件系统，因为那里没有持久的容器守护进程可用。一个配套的SingularityRuntimeBuilder从Jinja2模板构建镜像，并支持三种缓存模式：Scratch总是执行完整重建；Versioned在基础镜像和框架版本未变时重用缓存的镜像；Lock在依赖项锁定文件相同时重用它。这种模板驱动的设计使得能够为异构的智能体环境灵活地定制运行时。例如，在以GUI为中心的任务中使用的基于QEMU的虚拟机可以向构建器提供自定义的定义文件，而无需对核心构建逻辑进行任何修改。

3.2.3. 高效的工具后端

工具调用开销。智能体主要通过工具与环境交互：它读写文件、执行shell命令、运行Python代码以及浏览网页。从智能体的角度来看，每个工具调用都是一个同步阻塞操作，智能体必须等待观察结果才能决定下一步行动。由于一个典型的rollout包含数十个此类调用，每个工具的延迟会直接累加到总rollout时间中，在高并发下，这种开销可能超过LLM推理，成为主要瓶颈。因此，我们优化了三个关键的工具后端。

高效Bash执行。在所有以代码为中心的智能体任务中，shell执行是最频繁的动作。传统实现通过tmux会话路由bash命令，这会产生终端复用的开销。我们用一个基于ptyprocess的直接伪终端替换了它，这为智能体提供了一个原始的shell，无需tmux中介，从而显著减少了shell命令的往返延迟。

持久化IPython内核。当一个智能体在多个步骤中编写并执行Python代码时，它通常是在自己先前工作的基础上进行的：一次性导入一个库，然后反复使用它；定义一个辅助函数，然后稍后调用它。一个持久的IPython内核使这变得很自然，这样在一个步骤中定义的变量和导入在后续步骤中仍然可用，智能体就不需要在每次调用时重复设置代码。托管这种内核的传统方式是通过Jupyter内核网关，但这即使在内核与智能体在同一台机器上运行时也会增加网络往返开销。我们改为通过其进程内API直接连接到内核，完全消除了这种开销。

Unix域套接字通信。当智能体决定采取一个动作，如运行shell命令、编辑文件或执行Python时，该动作不是由智能体进程直接运行的。相反，它被发送到容器内运行的一个小型执行服务器，该服务器执行动作并传回观察结果。此通道的常用传输方式是TCP环回，虽然可以正常工作，但它迫使共享相同IP的同地进程只能通过端口号来区分，这使得无冲突的端口分配变得复杂，并且其吞吐量通常低于Unix域套接字。我们用Unix域套接字（UDS）替换了它，这是一种更简单的IPC机制，它直接通过操作系统内核传递消息，没有任何网络开销。由于此通道在每个智能体动作上都会被使用，在此处节省的延迟在整个rollout过程中会显著累积。

优化效果总结。这三个优化共同确保了随着rollout并发扩展到数百个并行智能体时，工具执行不会成为吞吐量瓶颈。

3.3. ProRL Agent 服务器

在沙盒层处理单个rollout执行的情况下，服务器在RL训练期间的核心职责是并发地编排数百个这样的rollout，同时为训练框架提供对rollout基础设施的实时控制。

服务器设计需求。服务器有两个基本要求：
* 首先，三个rollout阶段具有根本不同的资源需求：容器初始化是I/O密集型的，智能体执行是LLM推理密集型的，而结果评估的耗时从直接评分的几毫秒到完整测试套件执行的几分钟不等。在每个作业中执行这些阶段不应将吞吐量限制在最慢的阶段。
* 其次，训练框架需要对LLM推理后端进行动态控制：它必须能够在新服务器加入计算集群时注册它们，在模型检查点更新时交换后端，以及取消其梯度批次已经前进的过时在途作业，所有这些都无需与服务器内部紧密耦合。

ProRL Agent服务器的解决机制。ProRL Agent服务器通过两种机制解决了这两个方面的问题：（1）一个异步的三阶段流水线，将每个rollout阶段分配给一个独立的工人池，以便所有三个阶段可以在作业群体中重叠；（2）一个轻量级的管理API，通过HTTP向任何RL训练框架暴露作业提交、每个作业的取消、LLM后端注册和服务器生命周期控制。代码清单2勾勒了由此产生的架构。

# 代码清单2：ProRL Agent服务器的简化逻辑。三个独立的工人池并发地处理各自的队列。

# -- 三个独立的工人池
STAGES = [ INIT , RUN , EVAL ]
queues = { s : Queue () for s in STAGES } # 每个阶段的线程安全FIFO队列
pools = { s : ThreadPool ( N [ s ]) for s in STAGES }
llm_backends = MinHeap () # 以在途任务数量为键的最小堆
def worker_loop ( stage ) : 
    while running : 
        job = queues [ stage ]. get () 
        if job .id in discarded : 
            continue 
        with job . timer . phase ( stage ) : # 只有此阶段计入超时
            try : 
                result = handler [ stage ]( job ) 
            except Exception as e : 
                result = handler [ stage +'_exception ']( job , e ) 
            job . store ( stage , result ) 
            if stage == RUN : 
                cleanup ( job . runtime ) # 在评估开始前释放容器
        if stage != EVAL : 
            queues [ next_stage [ stage ]]. put ( job )
        else : 
            job . done . set () # 解除等待的HTTP处理程序的阻塞

3.3.1. 三阶段Rollout流水线

流水线设计的必要性。可以把rollout过程想象成一条装配线。一个简单的实现会为每个作业分配一个工人，让这个工人做所有事情：启动容器、运行智能体、评分结果，然后再接下一个作业。问题在于，每个阶段花费的时间和使用的资源都大相径庭。容器启动慢是因为它在等待磁盘I/O和网络。智能体执行每次调用都很快，但会发出数十个LLM请求，因此受限于GPU吞吐量。评估对于一个数学答案检查可能几乎是瞬时的，但对于一个完整的测试套件可能需要几分钟。一个工人按顺序经历所有三个阶段，大部分时间都会处于空闲状态，等待那个碰巧很慢的阶段。

三阶段解耦流水线工作原理。在ProRL Agent服务器中，解决方案是解耦这些阶段，就像工厂解耦装配站一样。AgentHandler的三个生命周期方法（见3.2.1节）映射到三个独立的工人池，每个池都有自己的队列。初始化工人不断地拉取新作业，启动容器，然后将它们交给rollout队列。Rollout工人驱动智能体循环，并将完成的轨迹交给评估队列。评估工人对结果进行评分并将其返回给调用者。

并行处理与资源优化。在任何时刻，所有三个池都在同时忙于不同的作业：当一个作业正在被评估时，第二个作业正在rollout中，第三个作业的容器正在启动。因为这些池是独立的，它们也可以根据各自的工作负载单独调整大小，例如，增加初始化工人以吸收缓慢的I/O启动，或者在测试套件特别长时增加评估工人。

3.3.2. LLM后端管理

# 代码清单3：ProRL Agent服务器的简化逻辑。管理API在运行时为训练框架提供了对作业和LLM后端的完全控制。

# -- 管理API (HTTP端点) 
POST / add_llm_server {" address ": " http :// host : port /v1"} # 注册后端 
POST / clear_llm_server # 清空所有后端 
POST / process {" instance ": {...} , " sampling_params ": {...}} # 提交作业 
POST / cancel {" job_id ": " } # 中止运行中的作业 
POST / start | POST / stop # 服务器生命周期 
GET / status # 队列深度

LLM后端管理API。智能体循环的每一步都需要一次LLM补全：模型接收当前的对话历史并产生下一个动作。当数百个rollout并行运行时，这些调用会以高频率同时到达推理层。单个LLM服务器（例如vLLM服务器）很快会成为瓶颈，因此RL训练通常会协同部署一个LLM服务器池，并将推理流量分布到它们之间。ProRL Agent服务器直接管理这个池，处理注册和路由，这样训练框架就不需要自己协调LLM访问。

动态注册与检查点切换。在训练运行期间，可以随时通过管理API注册和注销LLM后端。我们在代码清单3.3.2中展示了简化逻辑。当一个新的LLM服务器上线时，训练器调用POST /add_llm_server并附上服务器的端点；该服务器立即可以用于路由。当RL训练器更新策略检查点时（例如，在梯度同步步骤之后），旧的LLM权重不再有效。训练器不是重启rollout服务器，而是调用POST /clear_llm_server来清空所有已注册的后端，然后重新注册重新加载的LLM服务器端点。从那时起，所有后续的rollout都会自动使用更新后的模型，而不会中断已经在流水线中的作业。

通过最小堆实现的负载均衡。每个LLM后端与一个分配计数器一起存储在一个最小堆中。每当rollout阶段需要发出LLM调用时，ProRL Agent服务器会自动选择计数器最低的后端，并将整个任务分配给所选的LLM。计数器是按任务（而不是按调用）递增的，以确保同一任务内的所有后续调用都一致地路由到同一后端，从而最大化前缀缓存的重用。分配后，后端的更新计数器用于维护其在堆中的位置：
公式：c_i ← c_i + 1
其中$c_i$计算了自服务器$i$注册以来分配给它的推理调用总数。由于选择与分配计数成比例，接收较重流量的服务器优先级会下降，从而在池中实现类似轮询的平衡，而无需任何全局同步。整个操作由单个锁保护，使其在rollout工人池的高并发下是安全的。

3.3.3. Token-in/Token-out

重编码漂移问题。如果轨迹以纯文本形式在训练流水线中传输，接收端的重编码（re-tokenization）可能是无损的：产生的token序列可能与rollout期间最初生成的序列不同【【27】No more retokenization drift: Returning token ids via the openai compatible api matters in agent rl, 2025, http://blog.vllm.ai】，导致非预期的离策略（off-policy）差异。

令牌ID作为标准表示。ProRL Agent通过在整个训练过程中使用token ID作为规范表示来消除这种重编码漂移。Rollout工人直接将prompt_ids发送到LLM后端，并接收带有每个token对数概率的response_ids；每条消息还携带在生成时填充并保持不变的input_ids、output_ids和logprobs字段。在多轮次rollout期间，先前的助手轮次保留其原始token ID，并直接连接到输入缓冲区中；只有新消息（例如环境观察）才会被编码并追加。这确保了返回给训练器的每个token ID都与rollout期间产生的ID完全相同。

3.3.4. 作业生命周期和取消

作业生命周期管理。我们接着描述每个作业实例的生命周期和取消机制，这两者共同为RL训练器提供了更大的灵活性。

阶段感知的超时机制。每个作业都与一个PausableTimer相关联，该计时器仅在活动的流水线阶段（init、run和eval）累积经过的时间，同时排除了在阶段间队列中等待的时间。这种设计确保了超时预算反映的是实际执行时间，而不是暂时的服务器端延迟。

任务取消机制。训练框架可以随时通过POST /cancel中止任何在途作业。一旦收到请求，ProRL Agent服务器将：（i）将作业标记为已丢弃，以便任何尚未将其出队的工人都会跳过它；（ii）取消当前正在执行的异步任务；（iii）关闭相关的容器运行时以立即释放资源；以及（iv）发出作业的完成事件信号，使等待的HTTP处理程序无需阻塞即可返回。这使得RL训练器能够在收集到足够数量的有效样本后丢弃未完成的rollout。

故障隔离。每个流水线阶段都注册了一个专用的异常回调函数。一旦发生故障，回调函数会用一个结构化的回退结果填充JobDetails并设置完成事件，从而防止任何单个失败的rollout阻塞共享的工人池。

优雅停机。一旦收到POST /stop，服务器会取消所有在途作业，通过进程组扫描终止Singularity进程，清空工人池，并干净地退出，不会在节点上留下任何孤立的容器。

图3：DAPO实现对比（K=4）。我们的高效实现优化了工人同步，与基线逐批次方法相比，显著减少了rollout生成之间的空闲时间（等待期）。
图3：DAPO实现对比（K=4）。我们的高效实现优化了工人同步，与基线逐批次方法相比，显著减少了rollout生成之间的空闲时间（等待期）。

3.4. 与RL训练器连接

与训练器的接口。Rollout级别的解耦使得智能体服务器可以与多种RL训练器对接。在我们的实现中，我们同时支持VeRL【【25】Hybridflow: A flexible and efficient rlhf framework, 2025, Proceedings of the Twentieth European Conference on Computer Systems】和NeMo RL【【1】Nemo rl: A scalable and efficient post-training library, 2025, GitHub repository】。此外，我们还提供了几个关键特性以进一步改进RL训练。

高效的异步任务调度。在RL客户端侧，我们实现了一个两阶段的分层负载均衡策略，该策略共同优化了通信局部性和全局负载均衡。在第一阶段，通过IP地址匹配，优先将LLM服务器分配给同一物理节点上的ProRL Agent服务器，以减少网络延迟。在第二阶段，任何剩余的服务器以轮询方式分发，以维持所有可用LLM服务器之间的均衡分配。

高效的DAPO。我们采用动态采样策略优化（DAPO）【【36】Dapo: An open-source llm reinforcement learning system at scale, 2025, arXiv】作为我们的核心强化学习算法。DAPO通过过滤掉“零方差提示”（Zero-Variance Prompts）——那些其rollout产生统一奖励（例如，全部正确或全部错误）因而无法提供梯度信号的提示——来增强训练稳定性和数据效率。然而，将DAPO应用于智能体RL具有挑战性，因为智能体rollout通常是长时间运行、异步且计算昂贵的。一种简单的逐批次实现——训练器请求$K$个提示，过滤掉无信息量的提示，并重复触发新批次直到收集到$K$个“信息性提示”（Informative Prompts）——效率极低。这种同步方法导致工人空闲时间，并产生超过目标数量的冗余rollout。此外，在一个批次结束时丢弃未完成的rollout会导致显著的数据浪费。

异步补充机制。为了解决这些瓶颈，我们实现了一种异步补充机制：
1. 持续吞吐量：我们一旦作业队列变空就立即补充，以维持最大的rollout吞吐量。
2. 提前终止：一旦达到目标数量的“信息性提示”，我们就终止剩余的活动作业。
3. 跨迭代持久化：未完成的作业会被带到后续迭代中，以保留部分进度。

优化效果。如图3所示，与基线相比，我们优化的实现显著减少了工人空闲时间，并提高了整体硬件利用率。

A4 实验环境

  • RL算法：默认采用动态采样策略优化（DAPO）【【36】Dapo: An open-source llm reinforcement learning system at scale, 2025, arXiv】，该算法会过滤掉结果完全一致（解决率100%或0%）的实例。

  • 模型与超参数：

    • 模型：Qwen3-4B-Instruct2507, Qwen3-8B, Qwen3-14B。
    • 批大小（Batch Size）: 32。
    • 小批大小（Mini-batch Size）: 8。
    • 每个实例的Rollout数量：8。
    • KL散度系数：$1 \times 10^{-4}$。
    • 学习率：$1 \times 10^{-6}$。

  • 硬件配置：所有RL训练均在32个NVIDIA H100 GPU上进行。

  • 数据集与任务：
    • 软件工程：在SkyRL-v0【【2】Skyrl-v0: Train real-world long-horizon agents via reinforcement learning, 2025a】使用的SWE-Gym的293个实例子集上进行训练，并在SWE-Bench Verified上进行评估。
    • STEM：使用SCP-116K数据集【【17】Scp-116k: A high-quality problem-solution dataset and a generalized pipeline for automated extraction in the higher education science domain, 2025, arXiv】进行训练。
    • 数学：使用DeepScaleR数据【【19】Deepscaler: Surpassing o1-preview with a 1.5b model by scaling rl, 2025b, Notion Blog】进行训练，并在AMC上评估。
    • 编码：使用Eurus-2-RL-Data【【37】Free process rewards without process labels, 2024, arXiv】作为训练数据，并在Codeforces的测试集上进行评估。

A5 实验结果

4.2. 在软件工程任务上的主要结果

我们主要在软件工程任务上评估ProRL Agent。具体来说，我们训练了Qwen3-4B-Instruct2507、Qwen3-8B和Qwen3-14B模型。对于支持思考模式的Qwen3-8B和Qwen3-14B模型，我们在训练期间启用了该模式。结果如表2所示。

表2：不同规模模型在SWE-Bench Verified上的性能比较。我们报告了复现的性能，以及在可用情况下来自先前工作的报告结果。在所有模型尺寸上
表2：不同规模模型在SWE-Bench Verified上的性能比较。我们报告了复现的性能，以及在可用情况下来自先前工作的报告结果。在所有模型尺寸上

如表2所示，ProRL Agent在所有模型尺寸上都持续提升了性能。与SkyRL-v0【【2】Skyrl-v0: Train real-world long-horizon agents via reinforcement learning, 2025a】相比，对于8B模型，性能提升尤为显著，ProRL Agent在SWE-Bench Verified上取得了近2倍的改进。这些结果表明，我们的基础设施为软件工程智能体的RL训练提供了一个更有效、更稳定的基础。

4.3. 在不同智能体领域的通用性

除了软件工程智能体，我们还通过在其他领域进行RL训练来进一步展示ProRL Agent的通用性。

图4：ProRL Agent在三个智能体领域的训练曲线。从左到右：STEM智能体RL训练期间的平均奖励，数学智能体RL训练期间在AMC上的Pass@1，以及代码智能体RL训练期间在Codeforces上的Pass@1。所有三条曲线在训练期间都显示出稳步提升，证明了ProRL Agent在软件工程任务之外的通用性。
图4：ProRL Agent在三个智能体领域的训练曲线。从左到右：STEM智能体RL训练期间的平均奖励，数学智能体RL训练期间在AMC上的Pass@1，以及代码智能体RL训练期间在Codeforces上的Pass@1。所有三条曲线在训练期间都显示出稳步提升，证明了ProRL Agent在软件工程任务之外的通用性。
  • STEM智能体：该智能体旨在解决科学、技术、工程和数学领域的复杂问答任务。其主要工具是网络搜索，并辅以Bash和IPython工具。如图4a所示，在RL训练过程中，平均奖励从约0.2稳步上升至约0.65，表明ProRL Agent能够自然地扩展到新领域。
  • 数学智能体：该智能体用于解决数学问题，主要工具是IPython执行，并配有think工具进行显式规划。如图4b所示，在RL训练期间，AMC上的Pass@1性能从0.4稳步提升至约0.9，表明智能体通过RL训练学会了有效利用外部工具进行数学推理。
  • 代码智能体：该智能体用于程序合成任务，主要工具是文件编辑，并辅以Bash和IPython工具进行开发、测试和调试。如图4c所示，在RL训练期间，Codeforces上的Pass@1性能从0.23稳步提升至约0.42，证明ProRL Agent可以通过工具使用有效地学习代码生成。

4.4. 系统分析

4.4.1. 跨计算节点的可扩展性

为了评估ProRL Agent的可扩展性，我们测量了在软件工程任务上，随着计算节点数量增加，rollout吞吐量（每秒实例数）的变化。结果如图5所示。

图5：软件工程任务上的rollout吞吐量（实例/秒）与计算节点数量的关系。吞吐量的近线性增长表明ProRL Agent能够有效地利用额外的计算资源。
图5：软件工程任务上的rollout吞吐量（实例/秒）与计算节点数量的关系。吞吐量的近线性增长表明ProRL Agent能够有效地利用额外的计算资源。

如图5所示，吞吐量随节点数量近乎线性增长，表明ProRL Agent能够以最小的扩展开销有效利用额外的计算资源。这种可扩展性对于RL训练尤其有价值，因为高效的rollout生成通常是主要的系统瓶颈，并直接影响整体训练效率。

4.4.2. 组件消融研究

我们进行了消融实验来评估ProRL Agent关键组件的有效性，包括负载均衡（Load Balancing, LB）、高效Bash（Efficient Bash, EB）和过时作业清理（Stale job Cleanup, SC）。我们依次移除每个组件，测量DAPO训练的rollout吞吐量。

表3：所提出系统组件的消融研究。Action Time表示执行shell命令动作所需的平均时间。每个组件都通过提高GPU利用率或减少动作执行时间来提高rollout吞吐量。
表3：所提出系统组件的消融研究。Action Time表示执行shell命令动作所需的平均时间。每个组件都通过提高GPU利用率或减少动作执行时间来提高rollout吞吐量。

结果如表3所示，每个提出的组件都对提高DAPO训练期间的rollout吞DAPO训练期间的rollout吞吐量做出了贡献。特别是，负载均衡和过时作业清理通过提高GPU利用率来提升吞吐量，而高效Bash则通过减少动作执行时间来提升吞吐量。

A6 结论

本文介绍了ProRL Agent，一个为HPC原生的多轮次智能体训练设计的开源、可扩展的rollout基础设施。通过将整个rollout生命周期与策略训练分离，ProRL Agent提升了智能体RL的模块化、可扩展性和可部署性。跨越软件工程、STEM、数学和代码智能体的实验证明了其端到端RL训练的有效性，并在多种模型规模上取得了显著的性能增益。我们将ProRL Agent作为开源项目并作为NVIDIA NeMo Gym的一部分发布，未来的工作将致力于更丰富的环境和改进的集群规模鲁棒性。

A7 附录

此处，我们提供了对现有智能体RL基础设施的详细架构分析，并附有说明图。

ProRL Agent架构。ProRL Agent将完整的智能体rollout生命周期，从环境管理到奖励计算，与GPU密集型训练分离开来，从而将I/O密集型的rollout与训练解耦。
图6：ProRL Agent将完整的智能体rollout生命周期，从环境管理到奖励计算，与GPU密集型训练分离开来，从而将I/O密集型的rollout与训练解耦。

SkyRL-Agent架构。训练驱动程序在单个CPU进程上运行并发的轨迹生成协程。它控制多轮次智能体循环，查询远程vLLM服务器进行推理，并与远程环境容器交互以执行。尽管推理和环境执行被卸载，但rollout控制仍保留在训练驱动程序内部。
图7：SkyRL-Agent。训练驱动程序在单个CPU进程上运行并发的轨迹生成协程。它控制多轮次智能体循环，查询远程vLLM服务器进行推理，并与远程环境容器交互以执行。尽管推理和环境执行被卸载，但rollout控制仍保留在训练驱动程序内部。

Agent Lightning架构。Agent Lightning将训练循环、LightningStoreServer和所有rollout工人都置于单个进程树中。存储服务器作为后台线程运行，而rollout工人则作为训练器的子进程生成。因此，rollout没有独立的服务生命周期：如果训练进程终止，存储服务器也会停止，rollout工人也会被中断。因此，rollout仍然在训练栈内部进行管理，而不是被清晰地解耦。图8：Agent Lightning。Agent Lightning将训练循环、LightningStoreServer和所有rollout工人都置于单个进程树中。存储服务器作为后台线程运行，而rollout工人则作为训练器的子进程生成。因此，rollout没有独立的服务生命周期：如果训练进程终止，存储服务器也会停止，rollout工人也会被中断。因此，rollout仍然在训练栈内部进行管理，而不是被清晰地解耦。

VeRL-Tool架构。VeRL-Tool扩展了标准的veRL训练器以支持多轮次智能体rollout。训练系统管理智能体循环和轨迹收集，而工具执行则被卸载到另一个基于CPU的环境服务。在这种设计中，rollout控制仍保留在训练器内部。
![图9：VeRL-Tool。VeRL-Tool扩展