Agentic RL Infrastructure / Agentic RL 基础设施

把 agentic-and-long-horizon-rl 里的算法变成可跑的系统工程:怎么搭异步 rollout 集群、怎么管环境沙盒、怎么排 GPU 显存、怎么选训练栈。先读 agentic 篇懂「为什么」,再用本篇懂「怎么搭」。

0. TL;DR 速查

• agent RL 训练与标准 RLHF 的本质差异:多轮轨迹(非单轮 response)+ 交互式环境(非静态数据集)+ 异步 rollout(推理与训练解耦)。
• 三池架构 = 核心心智模型:Rollout 池(推理引擎+环境)→ Reward 池(验证/判题)→ Training 池(策略更新);三池异步、各可独立扩缩。
• 训练栈选型四维度:是否原生支持多轮 / 是否支持异步 rollout / 环境管理方式 / GPU 显存策略(hybrid engine vs 分离部署)。
• verl(Volcano Engine):hybrid engine(推理+训练同 GPU,分时复用),SPMD 3D 并行,agent RL 支持在快速迭代中。
• OpenRLHF(Ray 生态):Ray actor 天然异步,PPO/DPO/Ray 强化学习管线成熟;agent 扩展通过自定义 environment wrapper。
• AReaL(Ant Group):全异步 agent-native 设计,解耦生成与训练;系统级而非算法级(见 agentic §5)。
• 环境是瓶颈,不是 GPU:SWE 单次测试 10-60s,web 页面加载数秒——环境延迟 >> 推理延迟;并行环境数 × 单环境速度决定吞吐上界。
• 多轮 KV cache 显存爆炸:$T$ 轮、每轮 $L$ token → cache $\propto T \times L$;缓解 = KV 驱逐(有损) / 摘要压缩(有误差) / 截断重启(丢历史)。
• 轨迹存储 = 新的数据工程:一条 agent 轨迹可达数万 token;训练千条即 GB 级;需存原始轨迹 + reward + 元数据,格式设计影响回放和过滤效率。
• 容错是硬需求:环境 flaky(网络超时/沙盒崩溃/测试非确定性)、GPU OOM、rollout worker 挂——训练框架必须处理重试/降级/checkpoint,否则跑不完一个 epoch。

1. 为什么 agent RL 的 infra 不同于标准 RLHF / Why agent RL infra ≠ RLHF infra

标准 RLHF 的假设在 agent 场景全部失效:

这直接决定了 agent RL 训练栈的核心设计:

1. 推理与训练通常需解耦(异步):对慢交互环境(代码执行/web 交互,环境步秒级 >> GPU 推理毫秒级),同步等待 = GPU 空转;快验证器或长生成主导场景下 GPU 可能才是瓶颈——瓶颈位置随任务与规模转移(见 Q9)。
2. 环境管理是第一等公民:需要环境池(docker sandbox pool / browser pool)、健康检查、超时杀、自动重置。
3. 轨迹是长序列:KV cache 管理、截断策略、存储格式全得重新考虑。

2. 三池架构 / The three-pool architecture

agent RL 训练的核心心智模型:三个可独立扩缩的异步池,各自有不同资源特征。

                    ┌─────────────────────┐
                    │   Training Pool      │
                    │  (GPU: policy update)│
                    │  - 消费轨迹 batch    │
                    │  - 梯度累积 + 更新   │
                    │  - 定期推送新权重    │
                    └──────────┬──────────┘
                               │ new weights
                               ▼
┌─────────────────────┐  ┌─────────────────────┐
│   Rollout Pool       │  │   Reward Pool        │
│  (GPU: inference +   │  │  (CPU: verification) │
│   CPU: environment)  │  │                      │
│                      │  │  - 跑单测 / 判终态   │
│  - 推理引擎(vLLM/    │  │  - 规则校验          │
│    SGLang)生成动作   │  │  - LLM-judge(可选)   │
│  - 环境执行动作       │  │                      │
│  - 收集完整轨迹       │──▶  - 产出 reward 向量  │
│                      │  │                      │
└─────────────────────┘  └─────────────────────┘

Rollout Pool (推理 + 环境,GPU+CPU 混合):

• 推理引擎(vLLM5PagedAttention + continuous batching。Kwon 2023 ↗/SGLang6RadixAttention + 结构化生成。Zheng 2024 ↗)以 TP/DP 方式部署,承载多轮生成的 token 产出
• 每个 rollout worker 绑定一个环境实例(docker container / browser instance)
• 循环:推理引擎产出动作 → worker 执行环境步 → 观测注入上下文 → 继续推理,直到终止
• 吞吐关键:并行 worker 数 × 每 worker 的推理速度;GPU 不直接等环境(环境步期间 GPU 服务其他 worker)

Reward Pool (验证,CPU 密集型):

• 接收完整轨迹,执行奖励计算:跑单元测试 / 校验环境终态 / 运行验证脚本
• 可与 Rollout Pool 物理同机但逻辑独立(方便独立扩缩)
• 瓶颈:SWE 单测执行可达数十秒;WebArena 终态校验需要浏览器交互

Training Pool (策略更新,GPU 密集型):

• 从轨迹缓冲区取 batch,计算 PPO/GRPO 损失 + 梯度更新
• hybrid engine 模式:训练 GPU 同时承载推理(GPU 分时复用,训完一批→切推理→生成新轨迹→切回训练)
• 分离模式:推理 GPU 和训练 GPU 物理分离,适合大规模持续训练

from-scratch 实现(三池异步 rollout 骨架,面试手撕标准):

import threading, queue, time
from concurrent.futures import ThreadPoolExecutor

class AsyncRolloutPipeline:
    """异步三池骨架:Rollout worker → Reward worker → Trajectory buffer → Training."""
    def __init__(self, env_factory, reward_fn, policy_model, buffer_size=1000):
        self.env = env_factory                            # 环境工厂(每个 worker 独立实例)
        self.reward_fn = reward_fn                        # reward 计算(环境执行/判题/校验)
        self.model = policy_model                         # 当前策略(定期从 Training 池同步)
        self.buffer = queue.Queue(maxsize=buffer_size)    # 轨迹缓冲区(解耦推理与训练)

    def rollout_worker(self, prompts, num_envs=8):
        """Rollout 池:并行与交互式环境采样生成轨迹。GPU 推理 + CPU 环境执行交叉。"""
        def run_one(prompt):
            env = self.env()                              # 每 worker 独立环境实例
            obs, traj = env.reset(prompt), []
            for _ in range(max_steps := 50):
                # 1. 推理(在 GPU 上):当前策略给定历史→下一动作
                action = self.model.generate(obs["history"])
                # 2. 执行(在 CPU 上):动作送入环境,环境返回新观测与局部奖励
                next_obs, done = env.step(action)
                traj.append({"obs": obs, "action": action, "done": done})
                if done: break
                obs = next_obs
            return traj

        with ThreadPoolExecutor(max_workers=num_envs) as ex:
            trajectories = list(ex.map(run_one, prompts))
        return trajectories

    def reward_worker(self, trajectories):
        """Reward 池:对每条轨迹计算最终 reward(环境终态校验/判题)。"""
        for traj in trajectories:
            final_state = traj[-1]["obs"]                 # 轨迹终态
            traj_reward = self.reward_fn(final_state)     # 纯 CPU 计算(跑单测/查网页)
            traj.append({"reward": traj_reward})
        return trajectories

    def train_step(self, batch):
        """Training 池:从 buffer 取轨迹→算 loss→梯度更新(在这里调用,与 rollout 异步)。"""
        # 实际实现:从 self.buffer 取 batch → compute PPO/GRPO loss → optimizer.step()
        pass                                              # 训练细节见 agentic-RL 篇代码

    def run_async(self, prompts, sync_interval=10):
        """启动异步循环:rollout+reward 持续产出→喂 buffer→train 从 buffer 消费。"""
        def producer():
            while True:
                trajs = self.rollout_worker(prompts)
                trajs = self.reward_worker(trajs)
                for t in trajs:
                    self.buffer.put(t)                    # 解耦:rollout 产出速度 ≠ train 消费速度
                time.sleep(0.1)
        threading.Thread(target=producer, daemon=True).start()
        # Training 端(另一线程/进程)从 buffer 取 batch → train_step
# 面试关键点:
# ① 三池异步解耦: rollout/reward/training 各自独立,不互相阻塞
# ② 环境是瓶颈(source):环境步数×单步延迟 ≫ 推理延迟时,同步=GPU 空等
# ③ ThreadPoolExecutor 模拟多环境并行;生产会用 Ray actor / k8s pod
# ④ Buffer 解耦: rollout 产出速度波动不影响 training 消费节奏

3. 训练栈对比 / Training stack comparison

3.1 verl (Volcano Engine)

verl1ByteDance Seed 发起、社区维护的 RL 训练框架:hybrid engine 分时复用 GPU(推理↔训练切换)、SPMD 3D 并行、多算法支持。github.com/verl-project/verl(原 volcengine/verl) 的核心设计是 hybrid engine:同一组 GPU 在推理和训练模式间分时切换——训完一批 → 切推理模式生成新 rollout → 切回训练。省 GPU(不需两套集群),但切换有开销(权重同步 + 显存重分配)。

• 并行策略:SPMD(单程序多数据),支持 DP/TP/PP 3D 组合
• 算法支持:PPO / GRPO / DPO / ReMax;agent RL 支持在活跃开发中
• agent 适配:社区有 verl-agent 扩展,在 RL 循环里嵌入环境交互步
• 适用场景:中等规模(几十到几百 GPU)、团队已有 FSDP/Megatron 经验

3.2 OpenRLHF

OpenRLHF2Ray 原生的 RLHF 框架:天然异步 actor、PPO/DPO/Rejection Sampling 支持。Hu 2024 ↗ 基于 Ray 的分布式 actor 模型:

• 天然异步:每个 Ray actor 独立调度,rollout worker / trainer / reward model 通过 Ray 通信,无需手动同步
• 调度灵活:可以给 rollout 和 trainer 分配不同 GPU,也可以 hybrid
• 算法:成熟的 PPO / DPO / Rejection Sampling / Conditional SFT 实现
• agent 扩展:通过自定义 Environment 抽象接入任意交互式环境;Ray 的 actor 模型让环境 worker 的扩缩和容错较自然
• 适用场景:快速原型、中等规模、需要灵活调度的团队

3.3 AReaL (Ant Group)

AReaL3Ant Group 的全异步 RL 系统(面向 LLM 推理):生成与训练完全分离;paper 实验聚焦数学/代码推理,但其异步架构同样适用于 agentic 长程场景。arXiv:2505.24298 系统级设计,非 GRPO 算法变体(见 agentic §5):

• 全异步:生成(rollout)与训练完全解耦,各自独立 GPU 池;生成池不停产轨迹,训练池不停消费
• agent 适用性:paper 实验在推理领域,但其全异步架构对长程、多轮 agent RL 场景同样适用(架构层面不依赖单轮 assumption)
• 适用场景:大规模持续训练、需要高吞吐的长程 agent RL

3.4 SkyRL-Agent (NovaSky/Berkeley)

SkyRL-Agent4NovaSky/Berkeley 的长程多轮工具异步训练栈:CPU 侧运行时与 GPU 生成重叠。arXiv:2511.16108 的核心贡献是异步流水线派发器:

• 把 CPU 侧的环境初始化 / 奖励计算与 GPU 生成时间重叠
• 长短轨迹混批时不被慢轨迹拖住(通过动态调度)
• 报告较 naive 异步批处理约 1.55× 吞吐提升
• 可对接 VeRL / Tinker 等后端

4. 环境管理 / Environment management

这是 agent RL infra 最容易被低估的一层——环境比 GPU 更慢、更不可靠、更难扩缩。

4.1 三类环境及其挑战

4.2 环境池设计模式

          ┌──────────────────────────────┐
          │     Environment Pool           │
          │                                │
          │  ┌─────┐ ┌─────┐ ┌─────┐     │
          │  │ Env │ │ Env │ │ Env │ ...  │  ← N 个预热好的环境实例
          │  │ #1  │ │ #2  │ │ #3  │     │
          │  └─────┘ └─────┘ └─────┘     │
          │       ↑  acquire               │
          │       │  release               │
          └───────┼────────────────────────┘
                  │
          ┌───────┴────────┐
          │ Rollout Worker │ → 取环境 → 跑一条轨迹 → 重置 → 归还
          └────────────────┘

关键机制:

1. 预热(pre-warm):环境实例在池中预先启动好(docker 已拉镜像、web server 已启动),worker 取到即可用;冷启动 docker 容器可达数十秒。
2. 健康检查(health check):定期或取用前检查环境是否可达(docker ps、HTTP ping);坏实例自动替换。
3. 自动重置(auto-reset):轨迹完成后 worker 调用 reset 恢复初始状态(git checkout 回初始 commit、数据库回滚、VM 快照恢复);归还前必须重置。
4. 超时杀(timeout kill):单步或整条轨迹超时 → 强制终止环境进程 → 重新创建实例(而非复用),防止残留状态污染。
5. 池大小 = N_env:由并发 worker 数 + 环境重置延迟决定;太小 → worker 空等;太大 → 资源浪费。

4.3 环境与推理的吞吐匹配

核心公式:要使 GPU 不等环境,需要 N_env × throughput_per_env ≥ GPU_inference_throughput。

具体:若一个环境轨迹平均 20 步、每步环境延迟 5s、GPU 推理每步 0.2s,那么 GPU 处理一个 worker 的每步仅需 0.2s 但要等 5s 环境 → GPU 利用率仅 0.2/5.2 ≈ 3.8%。所以需要大量环境 worker 并行:至少 5.2/0.2 ≈ 26 个 worker 才能让 GPU 在任意时刻都有可服务的请求。实际通常需要百级环境 worker 来喂饱一块 GPU。

5. GPU 显存与多轮 KV cache / GPU memory & multi-turn KV cache

5.1 多轮 KV cache 增长模型

单轮推理:prompt 编码一次 → decode $L$ token → KV cache $\propto \text{prompt\_len} + L$。多轮 agent:$T$ 轮对话,每轮上下文包含此前所有轮的历史。第 $t$ 轮时上下文长度约 $t \times L$,总 KV cache 呈 $O(T \times L)$ 增长。

具体数字:若每轮 500 token(think 200 + act 100 + observe 200),20 轮后上下文长 10k token。对 7B 模型(FP16)单层 KV cache ≈ 2×2×num_heads×head_dim×seq_len bytes,全层累计可达数 GB——一条轨迹的 KV cache 就可能占满一张 GPU 的显存。

5.2 缓解策略

5.3 Hybrid engine 的显存管理

Hybrid engine 模式下,同一 GPU 分时用于推理和训练,显存要在两种模式间切换:

• 推理阶段:显存放模型权重 + KV cache(多轮! 大!)
• 训练阶段:显存放模型权重 + 优化器状态 + 梯度 + 激活(比推理多 ~3-4× 权重显存)
• 切换开销:释放 KV cache → 分配优化器状态 → 加载;约数秒,频繁切换(每条轨迹切一次)会显著降低吞吐

6. 轨迹数据管线 / Trajectory data pipeline

一条 agent 轨迹的元数据结构:

trajectory = {
  task_id,              # 任务标识
  trajectory_id,        # 轨迹唯一 ID
  turns: [              # 多轮列表
    {think, act, obs, reward_step, done},
    ...
  ],
  total_reward,         # 终端 reward
  metadata: {           # 元数据
    env_version,        # 环境版本(可复现)
    total_steps,        # 步数
    total_tokens,       # token 消耗
    wall_time,          # 墙钟时间
    truncated,          # 是否被截断
    env_errors,         # 环境错误次数
  }
}

存储量级:一条 20 轮轨迹 ≈ 10k-20k token(含 think + act + obs);千条轨迹 ≈ 10M-20M token → 原始格式约 50-100MB(含 metadata + reward)。万条级训练需 GB 级存储;百万条轨迹的离线数据集可达 TB 级。

过滤管线(训练前,选哪些轨迹进 batch):

1. 完整性过滤:丢弃被截断 / 环境报错的轨迹(可选保留用于诊断)
2. 质量过滤:丢弃 reward 为零或异常低/高的轨迹(视任务而定;全零轨迹在 GRPO 中无信号但仍需保留少数作为负例)
3. 多样性过滤:丢弃与已有轨迹重复度过高的轨迹(基于 action n-gram 或 embedding 相似度)——防 Echo Trap(见 agentic Q14)
4. 平衡采样:确保 batch 中正例(reward > 0)和负例的比例合理,避免一方主导梯度

7. 异步 staleness 与流量控制 / Async staleness & flow control

全异步架构下,rollout 和训练之间天然存在策略滞后(policy lag):

Rollout 池用 θ_t 生成轨迹 → Reward 池计算 → Training 池此时已更新到 θ_{t+k} → 轨迹是用旧策略生成的

staleness 的影响:

• 轨迹是用旧版本策略采样的,当前策略 θ_{t+k} 下这些轨迹的 log-prob 和 advantage 都变了 → IS(importance sampling)修正的方差随 staleness 增大
• 离线程度 = (rollout 完成时 trainer 的 step) - (rollout 开始时 policy 的 version);过大则轨迹几乎来自不同策略 → 训练信号退化

控制手段:

1. 权重版本号:每条轨迹标记生成时的 policy_version,训练时丢弃 version 过旧的轨迹(设置 max_policy_lag)
2. IS 修正(V-trace / 截断 IS):用 $\frac{\pi_{\theta_{\text{new}}}(a|s)}{\pi_{\theta_{\text{old}}}(a|s)}$ 修正,但方差随 lag 增长;需截断($\rho = \min(\frac{\pi_{\text{new}}}{\pi_{\text{old}}}, \bar{c})$)或 ESS(effective sample size)监控
3. 队列反压:若 Training Pool 消费速度 < Rollout Pool 生产速度 → 轨迹队列积压 → staleness 增大 → 需要反压(限速 rollout 或提速训练),保持稳态队列深度
4. stale 轨迹复用策略:略旧轨迹并非完全无用——可降权使用(weight = $e^{-\lambda \cdot \text{lag}}$)而非直接丢弃,在高吞吐与信号质量之间折中

8. 容错 / Fault tolerance

agent RL 训练链路长,每一步都可能挂。生产级训练必须处理以下故障:

checkpoint 策略:至少保存 (model_weights, optimizer_state, LR_scheduler_state, global_step)→ 从最近 checkpoint 续训。推荐每 N 个 training step 或每 M 分钟 checkpoint 一次。若用 hybrid engine,checkpoint 前确保切换到 training mode 以保存完整优化器状态。

9. 成本估算 / Cost estimation

给定以下参数,可粗估一次 agent RL 训练的成本:

推理成本(rollout): $$\text{Tokens}_{\text{rollout}} = N_{\text{task}} \times N_{\text{rollout-per-task}} \times \bar{T} \times \bar{L}_{\text{turn}}$$

对 5k 任务、每任务 4 条 rollout、平均 20 轮、每轮 500 token:约 200M token。以 vLLM 在 8×A100 上推理速度 ~5k token/s 估计,约需 11 wall-clock hours(≈89 GPU-hours = 8 GPU × 11h)。

训练成本: $$\text{Tokens}_{\text{train}} = \text{Tokens}_{\text{rollout}} \times N_{\text{epoch}}$$

训练吞吐取决于模型大小 + 并行策略。7B 模型在 8×A100 上 PPO 训练约 2k-5k token/s(含 advantage 计算 + 梯度更新),200M token 训练 1 epoch ≈ 11-28 wall-clock hours(≈89-222 GPU-hours)。

环境成本(常被忽略):SWE docker sandbox 需要 CPU 实例;若 100 并发环境跑 1 周,CPU 实例成本可接近 GPU 成本。

分层面试题 / Stratified follow-ups

L1 基础

L2 进阶

L3 深入

参考文献 / References

均为系统/框架的一手来源,已 web 核实。框架版本与性能数字快变,本页只引架构设计思想。

1. Volcano Engine. verl: Volcano Engine Reinforcement Learning for LLMs. github.com/volcengine/verl — hybrid engine, SPMD 3D 并行, agent RL 支持活跃开发中. ↩
2. Hu et al. OpenRLHF: An Easy-to-use, Scalable and High-performance RLHF Framework. 2024. arXiv:2405.11143 — Ray 原生异步 RLHF 框架. ↩
3. Ant Group. AReaL: A Large-Scale Asynchronous RL System for Language Reasoning. 2025. arXiv:2505.24298 — 全异步 RL 系统(系统级,非算法变体;paper 聚焦推理,架构适用于 agent). ↩
4. NovaSky/Berkeley. SkyRL-Agent: Efficient RL Training for Multi-turn LLM Agent. 2025. arXiv:2511.16108 — CPU/GPU 流水线重叠 + 长程工具调度. ↩
5. Kwon et al. Efficient Memory Management for Large Language Model Serving with PagedAttention. 2023. arXiv:2309.06180 — vLLM: PagedAttention + continuous batching. ↩
6. Zheng et al. SGLang: Efficient Execution of Structured Language Model Programs. 2024. arXiv:2312.07104 — SGLang radix attention + 结构化生成. ↩
7. Duan et al. SWE-RL: Advancing LLM Reasoning via Reinforcement Learning on Open Software Evolution. 2025. arXiv:2502.18449 — SWE 领域 RL 训练数据管线(本页引其环境设计). ↩
8. Qi et al. WebRL: Training LLM Web Agents via Self-Evolving Online Curriculum Reinforcement Learning. 2024. arXiv:2411.02337 — Web 领域 RL 训练的环境与自进化课程. ↩