作者：觉醒也醉了
https://zhuanlan.zhihu.com/p/2047396735169908748

一、为什么复杂 RL 离不开分布式系统

近年来，强化学习（Reinforcement Learning, RL）在复杂决策任务中取得了大量突破，尤其是在游戏 AI、机器人控制等领域，以及近两年的大语言模型 RLHF/RLVR/Agent RL 训练。很多代表性成果看起来是算法突破，但从工程视角看，它们同样依赖大规模分布式系统。

复杂 RL 任务有一个非常直接的问题：智能体需要通过海量试错来学习，而每一次试错都要真实或模拟地与环境交互。

监督学习的数据通常已经存在，训练时主要瓶颈是数据读取和神经网络训练；而强化学习的数据并不是提前准备好的，它需要智能体一边和环境交互，一边产生训练数据。环境越复杂、对局越长、状态空间越大、动作空间越大，单机采样就越难满足训练需求。

在仿真系统或游戏场景下，典型案例包括：

AlphaStar：DeepMind 在《星际争霸 II》中训练出了达到顶尖人类水平的智能体。公开资料显示，单个 agent 使用 32 个 TPU v3 训练 44 天，league 中累计创建了近 900 个 player，每个 agent 经历的游戏量最高相当于人类训练 200 年。

OpenAI Five：OpenAI 在 5v5《Dota 2》中训练出能够击败世界冠军战队的智能体。公开资料显示，训练集群包含 256 块 GPU 和 128,000 个 CPU 核心；其中 GPU 负责模型训练，CPU 负责环境模拟。系统每天模拟约 180 年的游戏时间。

腾讯王者荣耀 AI“绝悟”：绝悟面向移动端 MOBA 游戏，在 1v1、3v3、5v5 等场景中达到了很高水平。公开报道中，其训练使用约 384 块 GPU 和 8.5 万个 CPU 核心，每天产生的自对战数据量相当于人类训练约 440 年。

分布式强化学习（Distributed RL）的核心目标是：

把 RL 训练中的环境交互、策略推理、数据传输、模型训练、模型同步等组件拆分到不同计算单元上并行执行，从而把训练时间从“年”压缩到“天”或“小时”。

二、分布式 RL 的核心系统角色

在单机 RL 中，我们通常只关心环境和算法。但在分布式 RL 中，一个训练任务会被拆成多个系统角色。

2.1 Actor / Sampler / EnvRunner：数据生产者

Actor，也常被称为 Sampler、Worker、EnvRunner，负责与环境交互并产生训练数据。

它的工作流程通常是：

• 持有一个策略副本，或向远程推理服务请求动作。
• 与环境交互，执行 rollout。
• 记录 observation、action、reward、done、logprob、value、hidden state 等数据。
• 将数据发送给 Learner、Replay Buffer 或 Trajectory Queue。
• 定期同步最新模型参数。

Actor 是 RL 系统中的数据生产者。

在游戏 AI 场景中，Actor 往往承担很重的环境模拟工作。一个复杂游戏环境可能需要完整运行游戏逻辑、技能系统、碰撞检测、寻路、视野系统、Buff 系统和战斗结算。因此，Actor 的瓶颈常常是 CPU、内存、环境逻辑耗时和网络 I/O。

2.2 Learner / Trainer：数据消费者

Learner，也常被称为 Trainer，负责从样本中学习并更新模型参数。

它的工作内容包括：

• 接收 Actor 产生的数据，或从 replay buffer 中采样数据。
• 对 trajectory 进行后处理，计算 return、advantage、TD target、V-trace target。
• 执行神经网络前向和反向传播。
• 更新模型参数和优化器状态。
• 将最新模型发布给 Actor 或 Inference Server。
• 保存 checkpoint，记录训练指标。

Learner 是 RL 系统中的数据消费者，也是主要负责模型参数更新。

Learner 的瓶颈通常是 GPU 计算、显存、batch 构造、梯度同步和模型保存。

2.3 Inference Server：集中式策略推理服务

在小模型场景中，Actor 可以本地持有模型副本并直接推理。

但当模型较大、Actor 数量很多、模型同步成本很高时，可以把策略推理从 Actor 中拆出来，交给专门的 Inference Server。

Inference Server 的职责是：

• 接收大量 Actor 发来的 observation。
• 将多个请求合并成 batch。
• 在 GPU 或 TPU 上执行策略前向传播。
• 返回 action、logprob、value、hidden state 等结果。
• 定期从 Learner 同步最新模型参数。

这种设计可以提高 GPU 推理利用率，减少大量 Actor 各自持有模型副本带来的内存和同步成本。但它也会引入额外的网络延迟和 batch 等待时间。

2.4 Trajectory Queue：流式样本队列

在有些架构中，Actor 会持续产生 trajectory，并写入一个样本队列。Learner 从队列中持续消费数据。

2.5 Replay Buffer：可复用经验池

Replay Buffer 主要用于 off-policy 算法，例如 DQN、Ape-X、R2D2、SAC、TD3 等。

它和 trajectory queue 的区别是：

• trajectory queue 更像“生产出来后尽快消费”的流式队列；
• replay buffer 更像“可反复抽样复用”的经验池。

Replay Buffer 的核心价值是提高样本利用率。Actor 产生的数据不会用一次就丢弃，而是可以被 Learner 多次采样训练。

在大规模 off-policy 分布式 RL 中，Replay Buffer 通常还会支持：

• Prioritized Experience Replay：优先采样 TD-error 较大的样本。
• Sample version tracking：记录样本由哪个策略版本产生。
• Eviction：淘汰过旧或低价值数据。

2.6 Model Store / Parameter Server：模型版本管理与同步

分布式 RL 训练过程中会产生大量模型版本。

Model Store 或 Parameter Server 负责：

• 保存最新模型。
• 保存历史 checkpoint。
• 向 Actor、Inference Server、Evaluator 分发模型。
• 支持模型回滚、版本标记、训练恢复等。

模型同步是分布式 RL 的核心问题之一。

如果同步太频繁，网络和存储压力会增大；如果同步太慢，Actor 使用的策略会明显落后于 Learner 当前策略，导致数据陈旧。

三、分布式 RL 的核心矛盾

分布式 RL 系统不能简单追求“进程越多越好”。它的设计要平衡多个矛盾。

3.1 采样吞吐 vs 训练吞吐

Actor 负责生产数据，Learner 负责消费数据。

如果 Actor 太少，Learner 会等数据，GPU 利用率低。

如果 Actor 太多，样本堆积，数据变旧，网络和存储压力增大，Learner 消费不过来。

一个好的分布式 RL 系统需要让数据生产速度和训练消费速度基本匹配。

3.2 数据新鲜度 vs 资源利用率

在 on-policy 算法中，训练数据应该尽量由当前策略产生。如果数据太旧，behavior policy 和 target policy 差异过大，训练会不稳定。

在 off-policy 算法中，旧数据可以被复用，但也不能无限陈旧。过旧数据可能来自完全不同的策略分布，导致训练偏差变大。

同步架构的数据新鲜度好，但资源利用率低；异步架构资源利用率高，但会带来 policy lag。

大规模 RL 系统经常会涉及到以下机制：

• 控制 Actor 同步模型的频率。
• 记录每条数据对应的 policy version。
• 丢弃过旧样本。
• 使用 importance sampling。
• 使用 V-trace 等 off-policy correction。
• 控制 queue size，避免样本积压过多。

3.3 推理延迟 vs batch 效率

如果 Actor 本地推理，单步决策延迟低，但每个 Actor 的模型推理可能很低效，尤其是模型较大时。

如果使用集中式 Inference Server，可以把大量请求合并成 batch，提高 GPU 利用率，但每个 Actor 需要等待网络往返和 batch 聚合。

具体可以根据实际场景权衡：

• 实时性要求极高、环境不能阻塞、模型很小：更适合本地推理；
• 环境可以等待决策、模型较大、Actor 数量很多：更适合集中式推理。

3.4 样本效率 vs wall-clock 效率

样本效率指每条环境数据能带来多少学习收益；wall-clock 效率指真实时间内训练能推进多快。

On-policy PPO 样本效率不一定最高，但工程稳定、易扩展，很多复杂游戏 AI 仍然使用。

Off-policy replay-style 算法可以多次复用样本，样本效率更高，但工程上要处理 replay 陈旧、分布偏移、优先级更新等问题。

工业系统通常不会只追求单一指标，而是综合考虑训练是否稳定、资源利用率是否高等方面。

四、典型分布式 RL 架构

4.1 同步并行架构

同步并行架构的核心思想是：

所有 Actor 使用同一版本策略采集数据，采集完成后一起等待 Learner 更新；Learner 更新完成后，再把新策略同步给所有 Actor。

整体流程如下：

• Learner 发布最新模型参数。
• 所有 Actor 同步拉取同一版本参数。
• 所有 Actor 并行运行环境，采集 rollout。
• Actor 将数据发送给 Learner。
• Learner 等待所有 Actor 的数据到齐。
• Learner 基于完整 batch 更新模型。
• 重复以上过程。

同步并行架构具有高稳定性，低效率的特点。采样时 Learner 空闲等待，训练时 Actor 空闲等待。

典型算法如 Batched-A2C 算法，以及在大规模分布式场景下 PPO 算法等。

注意：严格 on-policy 算法更偏好同步或近同步模式，但不能简单说“on-policy 只能同步”。工程上也可以通过控制 policy lag、丢弃旧样本、重要性采样修正等方式做近似异步训练。

4.2 异步梯度架构

多个 Actor 异步地计算梯度并直接更新中央全局模型，完全摒弃同步点，最大化资源利用率。反向传播计算梯度的操作在 Actor 完成，Learner 仅负责梯度下降更新参数。

整体流程如下：

• Learner 存储中央全局模型。
• 每个 Actor 循环执行3-5步骤。
• Pull：从中央模型拉取最新的参数。
• Rollout & Compute：使用当前策略与环境交互，并计算梯度（FP+BP）。
• Push：将计算出的梯度推送到中央模型，Learner 立即异步更新全局参数。

典型算法如 A3C。但这种方式由于策略滞后性，具有高吞吐，低稳定性的特点。目前大规模集群环境下用的很少。

4.3 IMPALA-style 架构

IMPALA-style 架构的核心思想是：

Actor 和 Learner 完全解耦。Actor 只负责持续采样，Learner 只负责持续训练，中间通过 trajectory queue 连接，并用 V-trace 处理策略滞后问题。

整体流程如下：

• 大量 Actor 持有策略副本，在本地环境中持续 rollout。
• Actor 将 trajectory 写入样本队列。
• Learner 从队列中持续拉取 batch。
• Learner 根据数据中的 behavior policy 信息进行 off-policy correction。
• Learner 更新主模型。
• Actor 定期从 Learner 或 Model Store 同步新参数。

IMPALA-style 的关键点是 decoupled acting and learning。Actor 不必等待 Learner 完成一次更新，Learner 也不必等待所有 Actor 同步采样完成。整个系统可以持续运转，因此吞吐很高。

但因为 Actor 使用的策略可能落后于 Learner 当前策略，所以训练数据并非严格 on-policy。IMPALA 使用 V-trace 来修正 behavior policy 与 target policy 之间的偏差，从而在高吞吐和训练稳定性之间取得平衡。

IMPALA-style 架构是工业级应用的首选架构。除了最初的 IMPALA 算法，还有许多算法也是同样的架构，如 IMPACT 算法（在 RLlib 中称之为 APPO 算法）。

4.4 SEED-style 架构

SEED-style 架构可以理解为在 IMPALA-style 基础上进一步拆分推理服务。

它的核心思想是：

Actor 不再本地执行策略前向传播，而是把 observation 发给集中式 Inference Server，由 GPU/TPU 批量推理后返回 action。

整体流程如下：

• 许多 Actors：负责运行环境模拟。当需要决策时，它将状态 s_t 发送给远程推理服务器，而不是在本地进行前向传播。
• 推理服务器集群：专门负责运行策略模型的前向传播（Forward Pass）。接收来自大量 Actors 的请求，批量处理（Batching）后返回动作 a_t。这极大地提高了 GPU 的利用效率。
• Learner：与 IMPALA 中的角色完全相同，从经验队列中拉取数据，更新模型。
• 模型同步：Learner 更新模型后，将新模型参数发布到推理服务器集群，使其能提供最新的策略推理服务。

这种架构中 Actor 计算负担轻，Model 推理服务器进行批量前向传播，GPU 利用率高，能够支持大规模的分布式训练。但由于 Actor 需要与推理服务器进行频繁的网络通信，因此对网络延迟和吞吐量要求很高。

SEED-RL 以及 OpenAIFive 版本的 Distributed-PPO 都是属于这种架构。

4.5 Replay-style 架构

Replay-style 架构主要用于 off-policy 算法。它的核心思想是：

Actor 大规模探索并把经验写入 replay buffer；Learner 从 replay buffer 中反复采样训练。

整体流程如下：

• 大量 Actor 与环境交互。
• Actor 将 transition 或 sequence 写入共享 replay buffer。
• Replay buffer 根据优先级、时间、任务类型等规则管理样本。
• Learner 从 replay buffer 中采样 batch。
• Learner 计算 TD error、更新网络。
• Learner 将新的 priority 写回 replay buffer。
• Actor 定期同步最新模型。

典型代表包括 Ape-X 和 R2D2。

如果环境具有明显的部分可观测性，且希望复用历史经验，Replay-style 架构非常值得关注。

五、算法架构的选择

不同任务适合不同分布式 RL 架构。架构选择应该从环境、模型、算法和工程约束出发。

1. 小模型 + 环境重：优先考虑 IMPALA-style

如果策略模型较小，Actor 本地推理速度很快，而环境模拟本身很重，那么可以让 Actor 本地持有模型副本。

这种情况下，SEED-style 的远程推理可能反而引入额外网络开销。

2. 大模型 + 阻塞式环境：优先考虑 SEED-style

如果模型较大，Actor 数量很多，每个 Actor 本地推理会造成 CPU/GPU 资源浪费，或者模型同步开销很大，可以考虑 SEED-style。

3. 稳定优先 + 工程简单：优先考虑同步 PPO

如果任务规模还没有大到必须完全异步，或者团队更重视训练稳定性和调试便利性，可以优先使用同步并行 PPO。

很多复杂系统的早期版本都应该先从同步 PPO 或近同步 PPO 开始，而不是一开始就做复杂的 IMPALA/SEED/Replay 全套架构。

4. 样本复用优先：考虑 Replay-style

如果环境交互成本高，或者算法本身是 off-policy，可以考虑 Replay-style。

如果策略带 RNN，需要额外考虑 sequence replay、burn-in、hidden state 保存和 representational drift。

六、环境执行加速

除了关注 Actor、Learner、GPU 和模型同步，很多时候环境本身也是很大的瓶颈。

在游戏 AI 中，环境可能包括游戏逻辑、技能系统、碰撞检测、寻路、视野系统、Buff 系统和战斗结算等计算。如果环境 step 很慢，即使 Learner 很快也没用，因为没有足够数据可以训练。

环境加速常见有两条路线。

6.1 多进程环境并行

第一类是 Vectorized Environment，也就是在 CPU 侧同时运行多个环境实例，并把它们包装成一个批量环境接口。

这样策略网络可以一次性处理一批 observation，环境也可以通过多进程、多线程或底层 C++ 实现提高吞吐。Gym / Gymnasium 中的 VectorEnv、AsyncVectorEnv、Stable-Baselines3 中的 VecEnv 都属于这种思路。

更进一步的代表是 EnvPool，它用 C++ 实现高性能并行环境池，在 Atari、MuJoCo 等标准环境上显著提高环境执行速度。

这类方法适合大多数传统 RL 环境，尤其是环境逻辑仍然主要跑在 CPU 上的场景，比如 Gym、Atari、MuJoCo，以及很多游戏 AI 中的服务端模拟环境。

6.2 硬件加速

第二类是把环境本身写成 JAX 程序，让环境 step 也可以被 jit 编译，并直接在 GPU/TPU 上批量运行。

这种方式的核心变化是，环境不再是 Python 进程里一个个 step，而是变成可以被 accelerator 编译和向量化执行的函数。这样可以把大量环境实例和策略训练放在同一块 GPU/TPU 上，减少 Python 调度和 CPU-GPU 数据传输开销。

这类例子包括：

• Brax：Google 提出的 JAX 刚体物理仿真环境，面向大规模并行物理控制和机器人 RL，强调在 accelerator 上高效并行仿真。
• Craftax：一个 JAX 实现的开放式 RL benchmark，结合了 Crafter 和 NetHack 的元素。其论文中提到，Craftax-Classic 是 Crafter 的 JAX 重写版本，最高可比原 Python 实现快 250 倍，并且可以在单块 GPU 上用不到一小时完成 10 亿次环境交互的 PPO 训练。
• gymnax / Jumanji：也是类似方向，提供 JAX-native 的 RL 环境，方便和 PureJaxRL、JAX-based PPO/SAC 等训练代码放在同一个编译图中执行。

这类方法非常适合规则清晰、状态结构规整、可以函数式表达的环境，例如物理控制、网格世界、程序生成环境等。

七、分布式强化学习工程框架

7.1 Ray

Ray 是一个通用分布式计算框架，适合构建包含异构任务的 AI 系统。

RL 训练正好具备以下特点：

• 任务粒度差异大：环境 step 可能是毫秒级，模型训练可能是分钟级或小时级。
• 资源异构：Actor 主要用 CPU，Learner 主要用 GPU，Inference Server 可能用 GPU，Evaluator 可能用 CPU 或 GPU。
• 任务有状态：环境进程、模型服务、replay buffer、参数服务器、评估器都需要持久状态。
• 执行动态图：训练过程中会动态创建任务、更新模型、启动评估、恢复失败进程。

Ray 的核心抽象包括：

• Task：无状态远程函数，适合并行计算、数据处理、轻量级任务。
• Actor：有状态远程对象，适合环境实例、模型服务、replay buffer、参数服务器、评估器等。
• Object Store：分布式对象存储，用于在 Ray 集群中共享对象。每个节点有自己的对象存储，同节点任务可以通过共享内存高效读取对象；跨节点对象会按需传输。
• Driver：用户提交任务的主进程，负责构建和控制整个分布式程序。

Ray 的价值在于，可以用比较统一的 Python 编程模型描述复杂分布式系统，而不需要直接手写大量 RPC、进程管理、资源调度和容错逻辑。

7.2 RLlib

RLlib 是基于 Ray 之上实现的高性能、高可扩展的分布式强化学习框架。

在之前想要进行分布式强化学习训练，通常会设计成(a)这种无中心的形式，每个节点各自计算，然后汇总。使用这种形式的原因是之前在监督学习范式下有很多如 MPI 之类的设计，但这种方式对于强化学习这样多异构的任务来说，开发难度、评估难度都很高。

RLlib 提出的是©这种中心分层形式，以逻辑中控和并行封装的思想实现各类强化学习组件，这样也能够方便的进行新算法扩展。

对比(a)无中心和(b)中心分层这两种形式下的分布式强化学习算法实现，明显发现(b)这种形式的算法实现更直观，更容易扩展。

RLlib 框架整体架构如下：

• Algorithm是RLlib的核心组件，也是算法的入口。
• AlgorithmConfig用于管理各种可配置参数，例如学习率或模型架构。大多数Algorithm类包含用于从强化学习环境收集训练样本的EnvRunner组件，以及负责计算梯度并更新模型的Learner组件。
• RLModule组件负责模型推理和训练，模型权重会从Learner更新到EnvRunner。
• Episodes可以理解为数据管道，存放对局相关数据。

然而实际使用 RLlib 作为分布式训练框架也存在许多不足之处：

• 框架过于“重”。因为是面向工业级，代码结构比较繁杂，一层套一层；初学者通常参照文档可以运行，但稍微想要改造一下，就感觉无从下手。
• 版本不稳定。目前 RLlib 处于新旧 API 升级的过程中，代码中新旧 API 混杂，且其中存在很多 bug，需要自己在使用过程中修复。
• 功能支持不够。原生 RLlib 不支持自博弈、动态策略库等复杂训练流程，对远程环境请求支持不够，以及其余复杂功能也需要自己实现。

7.3 其他开源生态

除了 RLlib，还有一些值得关注的 RL 工程生态。

Stable-Baselines3：适合单机实验和算法 baseline，易用性好，但不是面向大规模分布式训练设计。

Acme：DeepMind 开源的 RL 框架，抽象清晰，适合研究和构建 agent。

Sample Factory：强调高吞吐 RL 训练，尤其适合需要大量并行采样的场景。

EnvPool：专注高性能并行环境执行，可与多种 RL 框架配合。

OpenSpiel：专注博弈、多智能体、棋牌和 game theory 相关环境，适合研究多智能体强化学习和博弈环境。

八、公司自研分布式 RL 框架

很多公司会自研分布式 RL 框架，原因很直接：复杂游戏或仿真环境 AI 的工程需求通常超出通用开源框架。以下是一些公开架构示例。

8.1 腾讯 Avatar

腾讯 Avatar 是面向游戏 AI 的大规模分布式强化学习框架。Avatar 包含 Agent、Actor、Learner、Serving 等模块。

其中，Agent 和 Actor 分离体现了 SEED-style 的思想：

• Actor 更接近环境交互端，负责和游戏客户端或游戏服务器通信。
• Agent 或 Serving 更接近策略推理服务，负责执行模型前向。
• Learner 负责训练模型。
• Serving 负责模型推理服务和模型更新。

这种设计适合游戏环境复杂、Actor 数量大、模型推理需要集中管理的场景。

相比 RLlib 的 ExternalEnv 方式，公司自研框架通常会定义更贴合游戏引擎和业务协议的 AIServiceSDK，直接嵌入游戏客户端或服务器，从而降低环境接入成本。

8.2 网易 RLEase

网易 RLEase 是面向游戏 AI 的强化学习训练框架，公开资料显示其应用于《永劫无间》《逆水寒》等游戏 AI 训练。

从架构图看，RLEase 包含 Worker、Learner、Stat、Model Manager 等模块。

其中：

• Worker：负责与游戏环境交互，采集训练数据，并定期同步模型。
• Learner：负责消费数据并更新模型。
• Stat：负责训练过程中的指标统计。
• Model Manager：负责模型保存、模型加载、模型版本管理和模型发布。

从整体结构看，RLEase 更接近 IMPALA-style 加模型管理、统计监控和工程调度的训练架构。

九、总结

我认为不同架构的差异，实际上是在回答以下问题：

• 数据由谁生产？
• 数据存在哪里？
• 数据是否可以复用？
• Learner 如何消费数据？
• 模型如何同步？
• 推理在本地还是集中式服务？
• 数据滞后如何修正？
• 系统吞吐瓶颈在哪里？

理解这些问题后，再看 PPO、A3C、IMPALA、APPO、Ape-X、R2D2、SEED、AlphaStar、OpenAI Five、绝悟，就能看懂它们背后的系统设计取舍。

分布式 RL 的难点是如何让采样、训练、推理、同步、评估和监控形成一个稳定、高吞吐、可调试、可扩展的闭环系统。