ARL-Tangram: Unleash the Resource Efficiency in Agentic Reinforcement Learning

作者/机构: Bangjun Xiao†‡∗, Yihao Zhao†‡∗, Xiangwei Deng†‡, Shihua Yu‡, Yuxing Xiang†‡, Huaqiu Liu‡, Qiying Wang‡, Liang Zhao‡, Hailin Zhang‡§, Xuanzhe Liu†, Xin Jin†⋄, Fuli Luo‡⋄
(†北京大学计算机学院, ‡小米大模型核心技术团队)

A1 主要贡献

核心问题: 智能体强化学习（Agentic RL）作为一种新兴的云集群工作负载，能够通过与真实世界交互来解决复杂问题。然而，与传统RL不同，Agentic RL需要大量的外部云资源（如用于代码执行的CPU和用于奖励模型的GPU），这些资源位于主训练集群之外。现有的Agentic RL框架通常依赖静态的资源过度配置，即资源常常与长生命周期的轨迹或按任务隔离，导致严重的资源效率低下。

研究目标与创新点:
本文旨在解决Agentic RL中外部资源的低效问题。其核心创新是提出了行动级调度（action-level scheduling），将外部资源管理的粒度从传统的轨迹级或任务级，细化到原子调用（即“行动”）的级别。这一方法被整合到名为ARL-Tangram的统一资源管理系统中，以实现细粒度的外部资源共享和弹性。

ARL-Tangram系统的关键设计:
1. 统一的行动级建模: 该系统使用统一的行动建模方法，将具有异构资源需求和成本的行动进行管理。它为每个行动构建一个向量化的资源成本，涵盖CPU、GPU、内存和API配额等多种约束。此模型还包含了弹性建模，使系统能够识别弹性行动，并计算分配更多资源时执行时长的缩减量。
2. 弹性资源调度算法: ARL-Tangram的核心是一个旨在最小化行动完成时间（Action Completion Time, ACT）的弹性资源调度算法。该算法采用启发式的贪心驱逐机制，根据行动模型和实时系统状态来协调行动，避免因过于激进或保守的资源分配而导致次优的ACT和降低的RL效率。
3. 异构资源管理器: 系统为不同特性的资源定制了专门的管理器。这些管理器高效地支持行动级的执行，能够分解（breakdown）资源占用（即在每次行动后释放资源，并在下次调用时恢复环境或服务状态）并有效地池化（pool）资源（即以减轻碎片化和提高并行效率为原则分配资源）。

主要贡献总结:
* 分析了Agentic RL训练中外部资源过度配置的关键问题，并将其归类为轨迹内部和RL任务内部两个层面的过度配置。
* 提出了行动级调度，并将其整合到ARL-Tangram中，这是一个将管理粒度从轨迹级转移到行动级，并实现细粒度资源共享和弹性的统一资源管理系统。
* 设计了一个统一的行动模型和一个旨在最小化ACT同时满足异构约束的弹性调度算法。此外，针对不同资源的管理器进一步提高了外部资源利用率和训练效率。
* 通过在真实的RL训练任务上进行评估，证明ARL-Tangram显著提高了Agentic RL训练的端到端效率，并降低了外部资源成本。该系统已被部署用于支持MiMo系列模型的训练。

图1 现有方法与ARL-Tangram的比较
图1 现有方法与ARL-Tangram的比较

A3 背景知识与关键观察

2.1 Agentic RL训练

智能体RL训练流程。智能体在处理现实世界问题（如AI编码、深度搜索和具身智能）方面展现了显著的性能提升。与传统LLM不同，智能体LLM能通过外部工具（如shell命令、API或设备操作）与真实世界互动，这使得其RL流程与传统LLM有所不同。如图2所示，Agentic RL的流程是：首先，RL框架使用智能体LLM处理一批样本并收集其执行轨迹，这个阶段称为rollout。在rollout期间，框架通常遵循ReAct模式【【48，React: Synergizing reasoning and acting in language models，2022，ICLR】】，LLM根据输入提示决定如何使用工具，然后RL框架执行工具调用并获取环境观察。当一条轨迹完成后，会根据偏好（如RLHF【【27，Training language models to follow instructions with human feedback，2022，Advances in Neural Information Processing Systems】】或LLM-as-a-judger【【3，Constitutional ai: Harmlessness from ai feedback，2022，arXiv】】）或真实标签（如RLVR【【11，Deepseek-r1: Incentivizing reasoning capability in LLMs via reinforcement learning，2025，arXiv】】）计算其奖励，并用于训练LLM。

图2 Agentic RL的一个训练步骤
图2 Agentic RL的一个训练步骤

外部资源调用特性。在单条轨迹中，Agentic RL通常会重复ReAct模式多轮，以增强LLM的工具使用能力。LLM的生成和训练主要消耗GPU资源，而工具调用则依赖于CPU、GPU、存储和网络等多种异构资源类型，这些从RL框架的角度看被称为外部资源。频繁调用外部资源是Agentic RL的一个显著特点。例如，AI编码任务会反复执行shell命令或使用CPU编辑文件，而DeepSearch则会访问多个网站并消耗API配额。此外，轨迹结束时的奖励计算通常也涉及外部资源：LLM-as-a-judge通常部署为独立的模型服务，而AI编码则通过运行大量测试用例来评估奖励。所有这些调用RL框架之外资源的操作，都可以统称为外部资源调用。

2.2 外部资源管理

管理外部资源的双重动机。Agentic RL训练需要外部资源来承载环境、工具或奖励服务。对这些外部资源进行额外管理主要有两个原因：RL效率和资源成本。首先，RL任务的效率与外部资源的使用情况高度相关。直观上，如果外部资源不足或分配不当，外部调用的执行时长会增加。根据2.1节中常用的Agentic RL工作流，外部调用都位于每个样本rollout的关键路径上。因此，更长的外部调用意味着更长的rollout时间和更长的RL训练时间。例如，图3(a)展示了在不同数量的外部资源下，资源不当（0.5倍）的RL任务比资源充足（1倍）的任务具有更长的平均行动完成时间（ACT）和步骤时长。更严重的是，如果过多的外部调用失败，RL训练任务也可能失败【【16，Verltool: Towards holistic agentic reinforcement learning with tool use，2025，arXiv】】。

图3 (a): 1倍和0.5倍外部资源数量下的平均ACT。(b): MOPD中12个不同奖励服务的SM活动。(c): 代码智能体rollout时长比例。(d): 两个agentic RL任务的外部调用次数。
图3 (a): 1倍和0.5倍外部资源数量下的平均ACT。(b): MOPD中12个不同奖励服务的SM活动。(c): 代码智能体rollout时长比例。(d): 两个agentic RL任务的外部调用次数。

资源成本问题。其次，外部调用带来了额外的资源成本，因此降低外部资源的成本非常重要。通常，Agentic RL需要部署一个CPU集群来构建环境，或使用专门的GPU提供奖励服务，这都会导致额外开销。例如，一种新提出的蒸馏工作流MOPD【【46，MiMo-V2-Flash technical report，2026，arXiv】】，为一个RL任务使用数十个教师模型和数百个GPU来获取奖励。然而，这些外部GPU并未得到充分利用。图3(b)显示了12个教师模型使用的GPU的SM活动情况，其SM活动在时间和模型维度上波动，平均值低于3%，这表明外部资源存在巨大浪费。现有的框架【【7，AReaL: A large-scale asynchronous reinforcement learning system for language reasoning，2025，arXiv】】【【31，HybridFlow: A flexible and efficient RLHF framework，2025，EuroSys】】【【33，Let it flow: Agentic crafting on rock and roll, building the rome model within an open agentic learning ecosystem，2025a，arXiv】】要么忽略了这些相互依赖关系，要么默认采用静态的过度配置，导致了严重的资源浪费和成本效率低下。

2.3 外部资源的过度配置

过度配置的两个层面。在Agentic RL训练期间，外部资源的过度配置可以分为两个层面，这两个层面都加剧了训练效率低下和资源浪费。

轨迹内的过度配置。为了保证多轮调用的连续性和独立性，一些Agentic RL任务需要为每条轨迹提供一个隔离的环境以在rollout阶段进行交互。现有框架【【1，Kubernetes，2026，https://kubernetes.io/】】在轨迹的整个生命周期内静态分配外部资源，尽管轨迹只在某些时间窗口内与这些资源交互。我们以生产中的一个典型RL任务“AI编码”为例，评估了每条轨迹的行动时长（包括工具调用和奖励计算）。如图3(c)所示，每条轨迹的时间占比平均仅为47%。在实践中，LLM生成和外部调用阶段是交错进行的。然而，现有系统在整个rollout阶段创建环境并保留外部资源。结果，被保留的资源在大部分时间内处于空闲状态，浪费了本可以被其他轨迹使用的资源。例如，对于AI编码任务，浪费的外部资源占了53%（图3(c)）。此外，在有限的外部资源下，轨迹内的过度配置严重限制了系统并发性，增加了工具调用的排队延迟，并阻碍了为计算密集型操作分配额外的资源单元。这些影响延长了rollout时间，进一步降低了RL框架的整体效率以及训练集群中GPU的利用率 。

RL任务内的过度配置。在任务层面，不同的RL任务通常需要不同的外部服务进行交互或计算奖励，这是因为服务类型和配置不同【【19，Search-r1: Training LLMs to reason and leverage search engines with reinforcement learning，2025a，arXiv】】【【22，Cuda-l1: Improving cuda optimization via contrastive reinforcement learning，2025，arXiv】】【【46，MiMo-V2-Flash technical report，2026，arXiv】】。例如，使用奖励模型的不同RL任务通常会向独立的奖励服务发送请求，因为这些模型可能在模型架构或参数上有所不同。这些外部服务通常部署在不同的外部资源上【【16，Verltool: Towards holistic agentic reinforcement learning with tool use，2025，arXiv】】【【26，Multi-agent reference architecture，2025，https://github.com/microsoft/multi-a gent-reference-architecture】】。然而，由于整个RL训练过程中外部调用的动态性，这些外部服务并未一直被充分利用。对于每个RL任务，在训练阶段甚至没有外部调用，导致外部服务闲置。我们分析了两个真实的Agentic RL任务——DeepSearch和MOPD的外部调用数量，如图3(d)所示。调用数量的变化高达三个数量级，导致了外部资源的严重浪费。

2.4 机会与挑战

行动级调度的机遇。为了解决上述过度配置导致的效率低下问题，我们提出在行动层面管理外部资源。这里的“行动”指的是外部资源的原子调用，在此期间，既没有LLM生成，也没有轨迹中的任何其他行动交错进行。所有行动都被提交到一个统一的系统中，该系统集中管理异构的外部资源，而不是让每个轨迹独立执行外部调用和预留资源。在这个系统中，对长生命周期环境或服务的调用以行动的粒度进行统一调度和管理，即分解（Breakdown）长生命周期环境/服务的资源占用。此外，系统使用池化（Pool）的资源来服务这些行动，并在它们之间弹性分配资源。通过“分解与池化”的过程，行动级调度消除了过度配置问题，因为外部资源在空闲时间被释放或缩减。

行动级调度的优势。除了缓解过度配置，行动级调度相比过去的轨迹级或任务级资源分配，能实现更灵活和细粒度的资源分配。例如，当有足够资源时，它可以动态地为弹性行动分配额外的资源单元，即增加并行度（Degree-of-Parallelism, DoP），以缩短执行时间，从而进一步提高整体RL训练效率。总之，通过将资源管理的粒度从轨迹或RL任务细化到单个行动，行动级调度可以：(i) 通过跨轨迹和任务的多路复用，减少因长时间不活动造成的资源空闲时间；(ii) 通过动态扩展资源分配来缩短交互延迟。

挑战。首先，尽管行动级调度简化了单个行动的工作流程，但资源和交互模式的多样性仍然给统一管理带来了困难（§4.1）。系统中管理着多种外部资源，一个行动可能利用多种资源类型。统一协调这些资源具有挑战性。此外，行动在弹性和执行时长方面的模式也各不相同。因此，设计一个通用的抽象模型，以及一套统一的接口来管理异构资源，是构建统一调度算法的重要基础。其次，调度器必须处理多样化和突发性的工作负载（§4.2）。在这种条件下设计一个统一高效的调度算法是具有挑战性的，因为现有算法【【10，GRAPHENE: Packing and DependencyAware scheduling for Data-Parallel clusters，2016，USENIX OSDI】】【【12，Microsecond-scale preemption for concurrent GPUaccelerated DNN inferences，2022，USENIX OSDI】】【【23，Muxflow: efficient gpu sharing in production-level clusters with more than 10000 gpus，2024，Science China Information Sciences】】通常是为特定领域量身定制的，不能很好地推广到异构资源和作业模式。此外，行动的执行时长相对较短（例如，在AI编码中低至1毫秒），这为调度留下了非常短的时间窗口，使得应用重量级优化技术变得不切实际。第三，实现行动级调度需要将资源分配与长生命周期的有状态环境或服务解耦（§5）。轨迹/任务内的过度配置源于在整个轨迹/任务期间维持持久状态的需求。因此，一个关键挑战在于如何在每次行动后释放资源，同时保留环境/服务的状态，并支持实时资源分配和快速状态恢复。此外，为具有不同特性和拓扑的异构资源支持弹性的DoP和动态资源扩展也并非易事。

A2 方法细节

3 架构

ARL-Tangram系统设计。为了解决当前Agentic RL训练中固有的多方面过度配置问题——轨迹内和RL任务内，我们提出了一个统一的行动级平台，ARL-Tangram。我们的架构将外部资源管理与主要的RL训练集群解耦，将控制粒度从长生命周期的轨迹转移到单个原子交互，即行动。

图4 ARL-Tangram系统概览
图4 ARL-Tangram系统概览

工作流程。如图4所示，该系统作为多样化的RL任务和异构外部资源之间的集中中介。工作流程遵循一个标准的执行周期：(1) 行动提交：在rollout阶段，当智能体LLM调用工具或需要使用外部资源计算奖励时，它会向ARL-Tangram提交一个请求。(2) 统一建模与排队：通过建模，ARL-Tangram将各种外部资源调用转换为统一的行动。因此，这些请求被提交到一个统一的行动队列。(3) 弹性调度：调度器在外部资源的约束下调度等待队列中的行动，并与专门的资源管理器（如CPU、GPU、API管理器）协调，根据实时系统状态和行动模型弹性地分配资源。(4) 行动执行：在确定资源单元后，行动在由异构资源管理器分配的资源上独立执行。(5) 传输与观察：一旦执行完成，结果被传回RL框架，使其能够进行下一次LLM生成。

核心组件。ARL-Tangram包含三个主要组件——行动建模模块（§4.1）、行动级调度器（§4.2）和异构资源管理器（§5）。我们架构的基础是将每个原子调用都视为一个行动。因此，建模模块以统一的方式对各种行动的成本和性能弹性进行建模。然后，调度器决定一个行动是否能在资源约束下被调度，并弹性分配资源以最小化行动完成时间（ACT）。通过这种方式，ARL-Tangram减少了LLM等待外部资源调用的时间，从而进一步加速了RL训练。根据调度决策，异构资源管理器负责高效的资源分配和共享。通过一个统一的资源接口，我们的资源管理器，包括基础管理器、CPU管理器和GPU管理器，采用领域特定的技术来提高系统鲁棒性、资源利用率和行动速度。

4 统一的行动级建模与调度

本节首先在4.1节中对整个工作流程进行行动级建模。我们的模型统一了异构的外部资源类型和多样的工具类型。然后在4.2节中介绍我们的弹性资源调度算法。

4.1 行动建模

向量化的资源成本建模。首先，为了实现统一的行动级调度，我们需要一个清晰且统一的资源成本表示。对于一个给定的行动$a$，它可能同时消耗多种类型的资源。例如，DeepSearch RL任务的一个行动可能涉及对多个网站的并行或后续查询，每个网站都有独特的API配额，并被视为不同的资源类型。AI编码任务的一个行动不仅涉及CPU，还涉及内存。因此，一个行动的成本表示为一个多维向量，记为$c_a = (c_{a,0}, c_{a,1}, ..., c_{a,k-1})$，其中$k$是ARL-Tangram管理的资源类型数量。该向量使得在调度和分配过程中能够联合考虑多种资源约束。向量的每个维度对应ARL-Tangram管理的一种资源（包括CPU、GPU、内存、GPU内存、网络带宽和外部API配额）的消耗。重要的是，每种资源类型的成本不是一个静态值。对于资源数量具有弹性的行动，成本被指定为最小和最大可行资源使用量之间的一个范围。更复杂的是，对于像占用多个GPU的奖励服务这类特定任务，允许的资源单元是离散的（例如1, 2, 4, 8）。因此，$c_{a,j}$在$c_a$中有一个特定的约束，代表其所有可能的资源数量。这种建模方式允许调度器在不违反可行性约束的情况下灵活调整资源分配，或引入一些先验知识来缩小调度时的搜索空间。

弹性建模。对于弹性行动，我们引入一个额外的参数来描述它们的弹性行为。就特定资源而言，其弹性由一个从$m$个资源单元到0和1之间的弹性比率的映射来描述。该函数满足以下条件：

$$a.getDur(m) = \frac{T_{ori}}{E(m) * m} \quad (0 < E(m) \leq 1),$$

其中$T_{ori}$指的是使用单个单元时的执行时长。为了简化建模和优化，我们假设在一个行动消耗的所有资源类型中，只有一种资源类型是关键的弹性资源。这个假设在许多实际场景中是合理的。例如，基于GPU的行动需要足够的GPU内存来执行，但其执行延迟主要由并行度决定。在这个假设下，一个行动的弹性被定义为一个从关键资源类型使用量$a.getDur(m)$（$m \in c_{a,key}$，$0 \le m < k$）的映射，它量化了执行时长如何随着关键资源的分配量而变化。

执行时长建模。为了准备弹性调度算法，除了弹性之外，将执行时长也纳入行动规范中至关重要。因此，对于那些执行时长可被剖析的行动，我们引入原始执行时长，并如前述公式1所示，用单个单元对其进行归一化。这些剖析数据，连同弹性的定义，使得系统能够估计在不同资源分配下的时间成本，这对于优化调度决策和平衡性能与资源效率至关重要。

4.2 弹性资源调度

调度目标。为了在有限资源下保证效率，需要一个针对行动的弹性资源调度算法。我们首先将行动完成时间（ACT）定义为调度算法的优化目标。与作业完成时间（JCT）类似，ACT分解为：(1) 行动在队列中等待调度的时间；(2) 行动的执行时间。因此，调度目标是找到在多个行动之间分配资源的方式，以最小化ACTs的总和：

$$\text{Objective: } \text{minimize } ACTs = \sum_{0 \le i < N} (T_i^q + T_i),$$

其中$N$表示调度时等待队列中的行动数量，$T_i$表示第$i$个行动的实际执行时长，$T_i^q$表示其排队时长。

算法设计。具体到弹性调度算法，该问题包含两个耦合的问题：(1) 决定等待队列中行动的执行顺序，和 (2) 决定为每个行动分配多少资源单元，这两个问题都非易事。为了缩小搜索空间并与本文的关键观察——资源过度配置——保持一致，我们主要关注第二个问题。由于所有行动都位于其相应轨迹的关键路径上，Agentic RL训练对饥饿问题高度敏感（一个饥饿的行动可能会使整个轨迹失效）。因此，我们选择先进先出（FCFS）策略来决定调度顺序。我们的调度算法也可以与其他排序算法配合使用。第二个问题是一个经典问题：在多个弹性作业之间分配有限的资源单元以最小化总JCT，这是一个NP-hard问题【【4，Scheduling independent tasks to reduce mean finishing time，1974，Communications of the ACM】】。如§2.3所讨论，极短的调度时间窗口要求一个启发式解决方案，而资源类型和作业模式的异构性则要求通用性。因此，我们提出了一个统一的启发式调度算法，主要基于带有近似目标的贪心驱逐算法，如算法1所示。

算法1 弹性资源调度算法
算法1 弹性资源调度算法

算法流程。每次调用调度算法时，我们首先从等待队列中选择前$n$个行动作为候选集$C$（遵循FCFS），确保在为每个行动分配最少所需资源单元的情况下，向量化的资源约束$R = (R_0, ..., R_{k-1})$得到满足，即：

$$R_j \ge \{c_{0,j}^{min}, \dots, c_{n-1,j}^{min}\},$$

其中$\ge$表示不仅第$j$种资源的剩余单元不小于最小需求$c_{i,j}^{min}$的总和，而且其当前拓扑状态也能容纳所有这些候选行动（第1-2行）。然后，我们根据关键弹性资源（§4.1）将候选行动分成几组，并分别对每种资源类型应用弹性分配算法。基于行动的弹性由单一资源类型主导的假设，沿此资源扩展一个行动不会影响其他资源的分配（第3-4行）。对于每种资源类型，算法选择一个候选行动子集并确定其分配的单元数。

贪心驱逐与目标近似。对于弹性和执行时长都已知的可扩展行动，我们通过在决策过程中近似目标ACTs来提出一个贪心算法。首先，我们使用所有候选行动$C_j$的最小资源需求来调度它们，并计算初始目标。其次，我们迭代地从候选集$C_j$中驱逐最后一个行动，并将其资源重新分配给剩余的行动。对于每个缩减后的候选集$C_j[:t]$，我们计算最优资源分配和相应的目标。一旦进一步的驱逐不能减少目标，这意味着驱逐这个行动并扩展剩余候选行动未能优化ACTs，贪心算法就终止。至于目标近似（伪代码见附录），我们将其分解为两部分：候选行动的ACTs和等待队列中剩余行动的ACTs。因为候选行动将立即被调度，它们的ACTs可以使用其确定的分配精确计算。我们采用一种适用于异构资源拓扑的拓扑无关动态规划（DP）算法，在伪代码中称为DPArrange。该算法（在附录B中提供）解决了这些可扩展候选行动之间的最优离散分配，并根据分配更新完成堆。然而，剩余行动的ACTs受到它们前面分配策略的影响。递归计算最佳分配并获得这些行动的最优目标是难以处理的。相反，我们简化了过程，通过分配最小资源并将它们顺序插入完成堆来估计它们的ACTs。

算法细节与复杂度。值得注意的是，为了更精确地近似目标，我们引入了一个参数$depth$，它通过允许第一个剩余行动探索多种分配选择来扩展搜索空间。在实践中，设置$depth=2$或$3$就足够了。此外，该条件只要求已知可扩展行动的执行时长，而非所有行动。这是因为，在贪心驱逐候选行动期间，不可扩展行动的时长保持不变，不影响目标的相对比较。尽管它们的精确执行时长会影响完成堆，但用历史平均值来近似是可以接受的，因为可扩展行动的持续时间通常比不可扩展行动长得多，并主导完成堆的演变。该算法的计算复杂度主要由DP算法的实现决定。使用针对常见拓扑的经典实现，总体复杂度为$O(n R^2)$，其中$n$是候选行动的数量，$R$是某种资源类型的剩余单元数。对于不可扩展的资源或弹性未知的行动，算法直接选择这些候选行动并为其分配最少所需单元，同时保证向量化资源约束得到满足。

5 异构资源管理器

虽然提供了统一的抽象和调度算法，但要实现“分解与池化”（Breakdown & Pool）（§2.4），还需要针对特定资源的管理策略。具体来说，分解侧重于在保留执行状态或实现快速恢复（即高效的上下文切换）的同时释放资源，并支持每个行动的弹性并行度。池化则强调设计资源分配策略以减轻碎片化和提高并行效率，从而支持统一的弹性调度框架。如2.4节所述，异构资源在特性和拓扑上差异显著。因此，我们为不同类型的资源（包括CPU、GPU和其他基础资源）设计了专门的资源管理器。

图5 异构资源管理
图5 异构资源管理

5.1 基础资源管理器

对于无法扩展的外部资源，如网站配额和请求QPS限制，我们引入了一个基础资源管理器来防止竞争和违反资源约束。该管理器支持两种消耗模式：基于并发（限制最大并发使用量）和基于配额（限制一个周期内的总使用量）。它还定义了一套基础接口，可以被继承和选择性地重写，以支持行动级调度和统一的资源管理。

5.2 CPU管理器：基于执行时分配（AOE）

在当前的云CPU集群中，Kubernetes（k8s）和Docker的组合是事实上的标准，其中Docker提供环境隔离，k8s执行集群级资源管理。然而，k8s专为长时间运行的云服务设计，会产生大量的调度开销，并且仅在Pod粒度上管理资源。资源配额在Pod创建时固定，这导致了Agentic RL工作负载中轨迹内的过度配置。为了解决这个限制，我们引入了一种名为“执行时分配”（allocate-on-execution, AOE）的CPU管理机制，它直接与容器交互，为细粒度的CPU分配做准备。

CPU管理器中的分解（Breakdown）。AOE利用Docker的update接口按需修改容器的cgroup配置，包括cpulimit和cpuset等参数。在每次调用docker.exec()之前，CPU管理器根据调度算法分配的资源单元更新容器的cgroup。然后，Docker在更新后的cgroup下派生一个进程来执行行动。执行结束后，进程终止，分配的CPU资源被回收。值得注意的是，为了保留每个环境的长期状态，分配给每个容器的内存被保留，这在具有充足内存容量的现代集群中是可以接受的。

CPU管理器中的弹性并行度（DoP）。仅调整cgroup配置不足以实现弹性的DoP，因为并非所有弹性行动在实际中都天生支持并行。因此，我们应在构建RL数据集或提交行动时确保某些行动的弹性。例如，在代码生成任务中，测试用例可以高效地并行执行，但现有数据集中提供的测试命令通常只支持单进程执行。由于大多数测试命令依赖于pytest库，我们用pytest -n ${parallel_num}替换pytest，并在运行时动态设置parallel_num以启用并行执行。

CPU管理器中的池化（Pool）。CPU集群中资源分配的设计相对直接。由于CPU核心和CPU内存紧密耦合，CPU管理器联合管理这两种资源类型。对于CPU分配，管理器不仅确定分配给每个行动的核心数量，还明确指定用于并行执行的核心集合。每个核心在任何时候都由单个行动独占，以防止行动间的干扰。此外，并行效率受到核心间通信开销的影响，这取决于芯片上核心之间的物理距离。因此，在为弹性行动分配CPU核心时，CPU管理器优先选择同一非均匀内存访问（NUMA）节点内的核心。当轨迹的第一个行动被调用时，CPU管理器会筛选出有足够资源的节点——即有足够的CPU核心用于行动和足够的内存用于整个轨迹——并根据CPU内存负载均衡策略选择一个节点。同一轨迹内的所有后续行动都被限制在所选节点上执行。尽管不同节点间的CPU无法协作进行并行执行，但现代云CPU节点通常提供128个或更多的核心。这个容量相对于每个行动分配的CPU核心数来说很大，因此，CPU核心的碎片化在实践中通常不严重。因此，CPU管理器为每个节点独立执行调度算法。

5.3 GPU管理器：基于执行时驱逐（EOE）

与基于Docker的CPU环境相比，GPU集群上的长生命周期服务会产生高得多的设置开销。例如，一个奖励模型服务必须编译内核、建立通信组，最关键的是将模型参数加载到GPU内存中【【25，Hydraserve: Minimizing cold start latency for serverless llm serving in public clouds，2025，arXiv】】【【51，BlitzScale: Fast and live large model autoscaling with O (1) host caching，2025，USENIX OSDI】】。此外，GPU内存既稀缺又竞争激烈，无法将所有服务都持久地缓存。仅仅依赖CPU内存缓存会引入高昂的恢复开销。我们采用一种“执行时驱逐”（evict-on-execution, EOE）机制来减少上下文切换开销，并设计相应的资源分配策略来减轻资源碎片化和服务抖动。

GPU管理器中的分解（Breakdown）。初始化时，GPU管理器通过在每个可行的GPU组上部署所有需要的服务，并将其状态备份到CPU内存中，来迭代地准备这些服务。当一个行动请求服务时，GPU管理器分配一组具有所需单元的GPU，并检查所请求的服务是否已驻留在GPU内存中。如果是，则立即执行行动。否则，GPU管理器从CPU内存中恢复服务，并根据需要从GPU内存中驱逐缓存的服务，直到有足够的内存可供独占执行。行动完成后，恢复的服务将保留在GPU内存中，直到稍后被驱逐。尽管驱逐和恢复不可避免地会引入额外的延迟，但我们观察到许多服务的GPU内存状态在多次调用之间保持不变。因此，驱逐不需要将服务状态写回CPU内存；只需释放占用的GPU内存，同时在CPU内存中保留一个不变的副本即可。关于从CPU内存恢复服务的开销，先前的工作【【45，Aegaeon: Effective gpu pooling for concurrent llm serving on the market，2025，ACM SOSP】】【【51，BlitzScale: Fast and live large model autoscaling with O (1) host caching，2025，USENIX OSDI】】已经表明这个成本可以被有效降低，使得开销在实践中是可接受的。

GPU管理器中的弹性并行度（DoP）。通过将服务的不同DoP配置视为不同的服务，EOE自然地支持了弹性的DoP。一个请求服务的行动可以被路由到任意DoP的任何实例，并依赖调度算法做出决策。值得注意的是，EOE保证了所有缓存的服务都有足够的GPU内存来服务行动，而GPU分配则强制在任何时候每个GPU上最多执行一个行动。这种设计使得GPU集群能够为Agentic RL训练高效地托管多个服务。

GPU管理器中的池化（Pool）。GPU集群的特殊拓扑——其特点是每个节点的设备较少，且对并行执行有强烈需求——需要仔细减轻GPU碎片化。我们采用多级单元结构【【54，HiveD: Sharing a GPU cluster for deep learning with guarantees，2020，USENIX OSDI】】来组织和管理GPU资源。针对常见的DoP，一个合法的分配集，称为块（chunk），被定义为一个连续的GPU区间$(start, end)$，满足：

$$end - start = 2^{a} \text{ and } start|2^{a} \quad (a \in \{0, 1, 2, 3\}),$$

其中$a$指的是这个块的级别。最初，每个GPU节点表示为一个级别为3的可用块(0, 8)。当分配$k$个GPU时，其中$2^{a-1} < k \le 2^a$，GPU管理器按级别顺序遍历可用块，并选择级别为$b$（$b \ge a$）的最小块。如果$b > a$，GPU管理器会相应地将块拆分成几个合法的块，并返回结果块。此外，GPU管理器应用最近最少使用（LRU）驱逐策略，以减少服务缓存的抖动。当有多个相同级别的块可用时，优先选择已经缓存了所请求服务的块。所有统一调度算法所需且与外部资源拓扑相关的接口都在GPU管理器中被重载，特别是拓扑无关的DP算法，详见附录B。

A4 实验环境

  • 测试平台:

    • RL框架集群: 部署在生产集群上，最多48个GPU节点，每个节点配备8个NVIDIA Hopper架构GPU，通过高带宽NVLink和RDMA网络互联。
    • 外部资源 (由ARL-Tangram管理):
      • CPU集群: 15个节点，每个节点有256个AMD CPU核心和2.4TB内存。
      • GPU集群: 5个节点，每个节点配备8个高端NVIDIA GPU和3TB CPU内存。
      • API服务: 管理对多个外部API服务的访问，如Google搜索和PDF解析服务，这些服务有配额限制。

  • 软件配置:

    • RL框架: 采用VeRL【【31，HybridFlow: A flexible and efficient RLHF framework，2025，EuroSys】】，并为其增加了外部资源调用、序列级和异步rollout的能力。
    • 模型: RL训练模型选用Qwen3-32B【【47，Qwen3 technical report，2025，arXiv】】和MiMo-V2-Flash【【46，MiMo-V2-Flash technical report，2026，arXiv】】。

  • 工作负载:

    • AI编码: 使用一个内部数据集，其结构遵循SWE-Bench【【17，SWE-bench: Can language models resolve real-world github issues?，2024，ICLR】】，该数据集为生产使用设计，比SWE-Bench更全面。使用CPU构建隔离的执行环境。
    • DeepSearch: 数据集基于BrowseComp【【36，Browsecomp: A simple yet challenging benchmark for browsing agents，2025，arXiv】】。持续访问外部网站以辅助基于LLM的问答。奖励使用一个基于LLM的评判器（微调的GPT-OSS【【2，gpt-oss-120b & gpt-oss-20b model card，2025，arXiv】】）计算。
    • MOPD: 集成了多个RL任务（包括智能体任务），在rollout阶段使用相应的教师模型计算轨迹的对数概率以进行对齐。
    • AI编码与DeepSearch 采用GRPO【【29，Deepseekmath: Pushing the limits of mathematical reasoning in open language models，22024，arXiv】】作为RL算法。为测试任务间资源共享，还同时运行了DeepSearch和MOPD。

  • 基线系统:

    • AI编码: 使用Kubernetes管理CPU集群，每个轨迹请求创建一个pod。
    • MOPD: 使用SGLang【【56，Sglang: Efficient execution of structured language model programs，2024，Advances in neural information processing systems】】在GPU集群上部署9个教师模型。
    • DeepSearch: 每个轨迹独立进行API调用，并有重试机制。奖励服务在GPU集群上部署5个副本。
    • MOPD+Search: 共10个奖励服务，每个模型使用4个GPU部署。
    • GPU可扩展性: 额外引入ServerlessLLM【【8，ServerlessLLM:Low-Latency serverless inference for large language models，2024，USENIX OSDI】】作为基线。

  • ARL-Tangram配置: 调度算法中的depth参数设为2；仅对CPU上的奖励计算和GPU上的奖励模型推理提前进行了可扩展性和执行时长的剖析。

A4 实验结果

端到端性能
* 行动完成时间(ACT): 如图6所示，在所有工作负载下，ARL-Tangram的ACT始终低于基线系统，这表明它能更有效地处理突发工作负载，并通过缓解过度配置和提高资源利用率来降低ACT。
* 训练速度: ARL-Tangram显著缩短了RL训练的步骤时长，AI Coding和DeepSearch分别提速1.4倍和1.5倍。MOPD的提速较小，因其流程受长尾轨迹主导。
* 耗时分解 (图7):
* 在AI Coding任务中，ARL-Tangram将环境交互和奖励计算的耗时分别减少了9.0倍和2.8倍，总ACT提升4.3倍。前者得益于缓解了轨迹内的过度配置，后者得益于对可扩展行动的弹性DoP分配。
* MOPD任务受益于跨RL任务的教师模型复用和GPU资源池化。
* 在DeepSearch任务中，尽管由于恢复开销，奖励计算时间略长，但通过流量控制避免了API错误和重试，总体性能更优。
* 在“MOPD+Search”的混合场景中，ARL-Tangram展现出显著优势。

图6 不同RL任务下的ACT。数字和箭头表示RL任务的步骤时长。
图6 不同RL任务下的ACT。数字和箭头表示RL任务的步骤时长。
图7 不同RL任务的端到端性能。条形图中的数字表示绝对时长（秒）。
图7 不同RL任务的端到端性能。条形图中的数字表示绝对时长（秒）。

系统可扩展性 (图8)

  • CPU可扩展性: 随着RL批处理大小的增加，ARL-Tangram相比Kubernetes基线，平均ACT降低了3.1倍至27.7倍。在高负载下，Kubernetes不堪重负，而ARL-Tangram仍能稳定运行。在资源受限时，ARL-Tangram的优势依然明显。
  • GPU可扩展性: ARL-Tangram在高并发下显著优于SGLang和ServerlessLLM基线。在批处理大小为2048时，比SGLang快18.1倍，而ServerlessLLM已无法服务。在资源成本方面，ARL-Tangram仅用基线29%的GPU即可达到相同的ACT，即节省了71.2%的资源。
图8 不同外部资源在RL批处理大小和资源容量下的可扩展性。
图8 不同外部资源在RL批处理大小和资源容量下的可扩展性。

ARL-Tangram系统分析
* 调度算法影响 (图9): 消融实验表明，弹性调度算法始终优于固定DoP的基线。例如，在批处理大小为1280时，比DoP=16的基线快3.0倍。这得益于算法能根据资源竞争情况弹性分配资源。
* 开销分析 (表1): 系统开销很小。在CPU密集型的AI Coding任务中，系统开销不到执行时间的3%。在GPU密集型的MOPD任务中，主要由恢复服务带来的开销约占执行时间的25%，但该开销并未随并发度增加而爆炸性增长，保证了系统在高并发下的效率和稳定性。

图9 ARL-Tangram调度的影响。
图9 ARL-Tangram调度的影响。

表1 ACTs分解。

表1 ACTs分解
表1 ACTs分解

A7 补充细节

RL框架的优化。LLM RL的优势引起了对RL框架优化的高度关注【【7，AReaL: A large-scale asynchronous reinforcement learning system for language reasoning，2025，arXiv】】【【13，AsyncFlow: An asynchronous streaming RL framework for efficient LLM post-training，2025，arXiv】】【【14，History Rhymes: Accelerating LLM reinforcement learning with RhymeRL，2025，arXiv】】【【15，OpenRLHF: An easy-to-use, scalable and high-performance RLHF framework，2024，arXiv】】【【21，PUZZLE: Efficiently aligning large language models through Light-Weight context switch，2024，USENIX ATC】】【【30，Nemo-aligner: Scalable toolkit for efficient model alignment，2024，arXiv】】【【31，HybridFlow: A flexible and efficient RLHF framework，2025，EuroSys】】【【35，DistFlow: A fully distributed RL framework for scalable and efficient LLM post-training，2025b，arXiv】】【【49，DeepSpeed-Chat: Easy, fast and affordable RLHF training of chatgpt-like models at all scales，2023，arXiv】】【【57，StreamRL: Scalable, heterogeneous, and elastic RL for LLMs with disaggregated stream generation，2025a，arXiv】】【【58，Optimizing RLHF training for large language models with stage fusion，2025b，USENIX NSDI】】。OpenRLHF【【15，OpenRLHF: An easy-to-use, scalable and high-performance RLHF framework，2024，arXiv】】和verl【【31，HybridFlow: A flexible and efficient RLHF framework，2025，EuroSys】】分别探讨了解耦和协同部署架构。后续框架提出了融合【【58，Optimizing RLHF training for large language models with stage fusion，2025b，USENIX NSDI】】、流水线【【58，Optimizing RLHF training for large language models with stage fusion，2025b，USENIX NSDI】】、流式处理【【57，StreamRL: Scalable, heterogeneous, and elastic RL for LLMs with disaggregated stream generation，2025a，arXiv】】和异步执行【【7，AReaL: A large-scale asynchronous reinforcement learning system for language reasoning，2025，arXiv】】来提高系统效率。此外，一些近期的优化提出了请求级调度、负载均衡和推测解码【【9，Rollpacker: Mitigating long-tail rollouts for fast, synchronous rl post-training，2025，arXiv】】【【20，Efficient rl for llms with dynamic and online speculative decoding，2025b，Frontier AI Systems Workshop (FAISys)】】以进一步加速rollout阶段。尽管取得了这些进展，但现有框架通常将外部调用视为次要问题，要么忽略其资源管理，要么默认采用静态过度配置。这导致了显著的资源浪费，特别是因为Agentic RL任务涉及更长的轨迹和更复杂的环境交互。

智能体资源管理。Agentic RL日益增加的复杂性要求对用于工具和奖励的外部资源进行更精细的管理。最近的工作如Mars【【59，Towards efficient reward service for rlvr with request-level flexibility and batch-level constraint，2026，USENIX NSDI】】通过将奖励计算部署为独立服务来解决其效率问题。Mars利用“请求入，批量出”的特性，将请求级延迟要求放宽为批次级约束。虽然这对奖励计算有效，但ARL-Tangram通过建立一个统一的行动级平台，为所有类型的工具使用和奖励服务（包括API调用、代码执行和模拟器）提供了更全面的解决方案。MegaFlow【【52，Megaflow: Large-scale distributed orchestration system for the agentic era，2026，arXiv】】、SkyRL-Agent【【5，Skyrl-agent: Efficient rl training for multi-turn llm agent，2025，arXiv】】和ROCK【【33，Let it flow: Agentic crafting on rock and roll, building the rome model within an open agentic learning ecosystem，2025a，arXiv】】抽象了智能体服务，并采用云计算技术来管理工具。通过整合工具的可扩展性和共享模式等特性，ARL-Tangram为工具调用和奖励服务实现了专门的优化。

资源自动伸缩。自动伸缩是云计算的基石，采用反应式、主动式或混合方法【【24，A review of auto-scaling techniques for elastic applications in cloud environments，2014，Journal of grid computing】】【【34，Autothrottle: A practical bi-level approach to resource management for SLO-targeted microservices，2024，USENIX NSDI】】【【37，Xron: A hybrid elastic cloud overlay network for video conferencing at planetary scale，2023，ACM SIGCOMM】】【【38，Can’t be late: optimizing spot instance savings under deadlines，2024，USENIX NSDI】】【【53，Jolteon: Unleashing the promise of serverless for serverless workflows，2024，USENIX NSDI】】来维持服务水平目标（SLO）。在LLM领域，一些系统【【45，Aegaeon: Effective gpu pooling for concurrent llm serving on the market，2025，ACM SOSP】】【【50，?? Scale: Enabling fast scaling for serverless large language model inference，2025，arXiv】】【【51，BlitzScale: Fast and live large model autoscaling with O (1) host caching，2025，USENIX OSDI】】【【55，SeaLLM: Service-aware and latency-optimized resource sharing for large language model inference，2025，arXiv】】已针对大规模推理工作负载优化了自动伸缩。对于RL特定任务，Mars【【59，Towards efficient reward service for rlvr with request-level flexibility and batch-level constraint，2026，USENIX NSDI】】引入了基于历史的伸缩和超时感知机制，以在批次边界预测和调整资源需求。ARL-Tangram通过引入一个弹性的行动级调度器来扩展这些原则，该调度器旨在处理Agentic RL行动的突发性和异构性。通过对各种行动的可扩展性进行建模，ARL-Tangram最小化了总ACT，从而加速了RL训练过程。

A5 结论

本文介绍了ARL-Tangram，一个用于Agentic RL的统一资源管理系统，它实现了对异构外部资源的细粒度共享和弹性编排。通过在行动层面建模外部交互，对其进行弹性调度，并设计异构资源管理器，ARL-Tangram在提高外部资源利用率的同时，也增强了整体训练效率。在真实世界的Agentic RL工作负载上进行的大量评估表明，ARL-Tangram显著缩短了训练步骤时长，降低了平均行动完成时间（ACT），并大幅减少了外部资源成本，使Agentic RL在云环境中更加高效。

A6 附录

A ACTs近似的伪代码

ACTs近似的伪代码如算法2所示。

算法2 ACTs近似
算法2 ACTs近似

B 统一的DPArrange算法

实际上，解决多个可扩展候选项和可用单元之间的最优离散分配问题是多维装箱问题的一个经典变体。然而，由于不同资源类型的拓扑结构异构，§4.2中提到的DPArrange函数不能完全被解决多维装箱问题的经典算法覆盖。因此，我们提出了一个拓扑无关的统一DP算法，如算法3所示，并与异构资源管理器的DP算子设计相协调。

通过拓扑无关的DPArrange算法，我们只需要为每个专门的拓扑实现几个在基础DP算子中定义的基元。基础DP算子适用于CPU管理器的拓扑，而我们为GPU管理器设计了一个分块的基础DP算子，如算法4所示。

我们为大小为{1,2,4,8}的GPU块定义了一个拓扑感知的DP算子。每个DP状态由一个元组$(c_1, c_2, c_4, c_8)$表示，指示每种大小的可用块的数量，并通过混合基数编码线性化为唯一的标量索引，确保DP状态空间无冲突且有限。起始状态对应于由集群规模决定的最小支持块配置。给定一个需要k个GPU的任务，前驱算子贪婪地使用从大到小可用的块来分解k，允许块分裂同时保持2的幂次约束。如果分解可行，算子转换到编码后的剩余块状态；否则，转换无效。该算子使动态规划能够明确地对GPU拓扑进行推理，同时与标准的一维DP公式保持兼容。

算法3 拓扑无关的DPArrange
算法3 拓扑无关的DPArrange
// 每个任务至少需要一个单元
Require: 一组可扩展任务 T = {t1, ..., tn}, 可用资源单元 R, 支持的单元集 S = {s1, ..., sn},
         资源管理器 M, 及其 DP 算子 O
Ensure: 最优执行时间 T*, 分配 {u1, ..., un}
1: n ← min{End(O), End(S)}
2: if R < n then
3:   return error
4: 初始化 DP 表 dp[i][j] ← ∞, for 0 ≤ i ≤ n, 0 ≤ j ≤ R
5: 初始化选择表 choice[i][j] ← 0
6: dp[0][0] ← 0
7: state_start ← 0
8: state_end ← O.Start(s1)
9: for i = 1 → n do
10:   for j = state_start → R do
11:     for all u ∈ si do
12:       j' ← O.Prev(j, u)
13:       if j' < state_start or ¬O.IsValid(j', s1:i-1) then
14:         continue
15:       dur(u) ← O.GetDuration(ti, u)
16:       if dp[i-1][j'] + dur(u) < dp[i][j] then
17:         dp[i][j] ← dp[i-1][j'] + dur(u)
18:         choice[i][j] ← u
19:   state_start ← state_end
20:   state_end ← O.Start(s1:i+1)
21: j ← R
22: for i = n → 1 do
23:   ui ← choice[i][j]
24:   j ← O.Prev(j, ui)
25: return dp[n][R], {u1, ..., un}

基础 DP 算子
26: function Start(S)
27:   return Σ_s min(si)
28: function End(O)
29:   if O is a unit list then
30:     return |O|
31:   else
32:     return Σ_s max(si)
33: function Prev(j, u)
34:   return j - u
35: function IsValid(j, s)
36:   if j < 0 then
37:     return false
38:   if s = ∅ then
39:     return (j = 0)
40:   for all u ∈ s1 do
41:     if u ≤ j and IsValid(j-u, s2:) then
42:       return true
43:   return false

// 算法4 Chunk-wise DP 算子
Require: 最大可用块数 (c1, c2, c4, c8) 对应块大小 {1, 2, 4, 8}
状态表示:
一个状态是 (n1, n2, n4, n8) 其中
n1 ∈ [0, c1], n2 ∈ [0, c2], n4 ∈ [0, c4], n8 ∈ [0, c8]
1: function Encode(n1, n2, n4, n8)
2:   return n1 + (c1 + 1) · n2 + (c1 + 1)(c2 + 1) · n4 + (c1 + 1)(c2 + 1)(c4 + 1) · n8
3: function Decode(state)
4:   n1 ← state mod (c1 + 1)
5:   state ← ⌊ state / (c1 + 1) ⌋
6:   n2 ← state mod (c2 + 1)
7:   state ← ⌊ state / (c2 + 1) ⌋
8:   n4 ← state mod (c4 + 1)
9:   state ← ⌊ state / (c4 + 1) ⌋
10:  n8 ← state
11:  return (n1, n2, n4, n8)
12: function Start(S)
      S: 所有任务的支持单元集
13:  (n1_min, n2_min, n4_min, n8_min) ← 从S推断出的最小所需块
14:  return Encode(n1_min, n2_min, n4_min, n8_min)
15: function IsValid(state)
16:  (n1, n2, n4, n8) ← Decode(state)
17:  if n1 < 0 or n2 < 0 or n4 < 0 or n8 < 0 then
18:    return false
19:  if n1 > c1 or n2 > c2 or n4 > c4 or n8 > c8 then
20:    return false
21:  return true
22: function Prev(state, k)
23:  (n1, n2, n4, n8) ← Decode(state)
24:  rem ← k
25:  k8 ← min(n8, ⌊rem / 8⌋)
26:  rem ← rem - 8 · k8
27:  k4 ← min(n4, ⌊rem / 4⌋)
28:  rem ← rem - 4 · k4
29:  k2 ← min(n2, ⌊rem / 2⌋)
30:  rem ← rem - 2 · k2
31:  k1 ← min(n1, rem)
32:  rem ← rem - k1
33:  if rem > 0 then
34:    return ⊥
35:  n1' ← n1 - k1
36:  n2' ← n2 - k2
37:  n4' ← n4 - k4
38:  n8' ← n8 - k8
39:  return Encode(n1', n2', n4', n8')