论文解读：MinionsRL — 基于 Serverless 的低成本分布式深度强化学习
解读 AAAI 2024 论文，MinionsRL 利用 Serverless 计算实现更低成本、更快速的分布式深度强化学习训练。
论文: Cheaper and Faster: Distributed Deep Reinforcement Learning with Serverless Computing (AAAI 2024, Hanfei Yu et al.)
1. 为什么需要 MinionsRL
分布式深度强化学习（DRL）训练通常采用 Actor-Learner 架构：Actor 负责采样轨迹数据，Learner 负责策略更新。On-policy 算法（如 PPO）在每轮训练结束后需要 同步——所有 Actor 完成采样后，Learner 才能更新模型。
传统基于服务器的方案面临两个核心痛点：
- 粗粒度资源管理: 以服务器为单位分配资源（如一台 VM 配 6 CPU + 1 GPU），而 Actor 实际只需要 1 个 CPU core。空闲的 Actor 资源无法释放，按时间计费持续产生费用。
- 启动延迟高: 服务器启动是分钟级别的，频繁开关 Actor 服务器不现实，导致空闲 Actor 只能"干等"。
如 Figure 1 所示：
Server-based 训练:
Actor 1: ████ Idle ████ Idle ████ ... ← 空闲仍计费
Actor 2: ██████ Idle ██ Idle █████ ...
Learner: ─── Idle ─── Update ─── Idle ─── Update ───
Serverless 训练:
Actor 1: ████ (Released) ████ (Released) ← 用完即释放
Actor 2: ██████ (Released) █████ (Released)
Learner: ─── Update ─── Update ───
核心问题: 能否利用 Serverless 的按需启停和细粒度计费，动态调整 Actor 数量，同时优化训练时间和成本？
2. Serverless Computing 与 DRL 的天然契合
2.1 什么是 Serverless Computing
Serverless Computing（也叫 FaaS, Function-as-a-Service）的特点：
| 特性 | Server-based | Serverless |
|---|---|---|
| 资源粒度 | 整台服务器（CPU+GPU 捆绑） | 单个容器（可以只要 1 CPU core） |
| 启动时间 | 分钟级 | 亚秒级 |
| 计费方式 | 按时间（含空闲时间） | 按实际执行时间 |
| 弹性伸缩 | 手动/慢速 | 即时自动扩缩 |
2.2 为什么适合 DRL
On-policy DRL 训练天然是"脉冲式"的：
- 采样阶段: 需要大量 Actor 并发采集数据
- 更新阶段: 只需要 Learner 更新策略，Actor 空闲
Serverless 的 即开即用、用完即释 恰好匹配这种模式：采样时启动 Actor 函数，采样完立即释放，不为空闲时间买单。
2.3 动态 Actor 扩缩的必要性
论文用一个关键实验说明 Actor 数量的动态调整对训练效果影响巨大。在 CartPole-v1 上用 PPO 训练，三种策略使用 相同的总 Actor 预算：
- Fixed: 每轮固定数量 Actor
- Decrease: 每 10 轮减少 10 个 Actor
- Increase: 每 10 轮增加 10 个 Actor
结果：三种策略最终 reward 差异显著。这说明 在训练的不同阶段，需要不同数量的 Actor，静态分配不是最优解。
3. MinionsRL 整体架构
MinionsRL 的架构包含两层工作流：
┌──────────────────────────────────────────────────────┐
│ MinionsRL Scheduler │
│ (DRL-based Actor Scheduler, PPO Agent) │
│ │
│ State s_k ──→ Policy π^h ──→ Action a_k (# actors) │
│ ↑ ↓ │
│ Reward r_k Schedule actors │
└──────────┬──────────────────────────────┬──────────────┘
│ │
▼ ▼
┌──────────────────────────────────────────────────────┐
│ DRL Workload Training │
│ │
│ Round k: │
│ 1. Scheduler 决定启动 I_k 个 Actor │
│ 2. Actor 函数启动，采样轨迹数据 τ_k │
│ 3. Actor 完成后立即释放 │
│ 4. Learner 函数更新策略 θ_k → θ_{k+1} │
│ 5. 反馈 state, reward 给 Scheduler │
└──────────────────────────────────────────────────────┘
关键设计：
- Actor 和 Learner 都是 serverless 函数：部署在 Azure Container Instances (ACI) 上
- 每个 Actor 容器只分配 1 CPU core：细粒度资源管理
- Learner 容器配 1 V100 GPU：策略更新需要加速
- Actor 数量范围: [1, 32]，每轮由 Scheduler 动态决定
4. DRL-Based Actor Scheduler 设计
Scheduler 本身就是一个 PPO 智能体，用"RL 来调度 RL"。
4.1 问题建模
将 Actor 调度建模为 序列决策问题。训练持续 K 轮，每轮 Scheduler 决定启动多少 Actor。
优化目标:
$$\min_{I_k} \sum_{k=1}^{K} \left( P_k^l + \max_i {P_{k,i}^a} \right)$$
其中：
- $P_k^l$: 第 k 轮 Learner 执行时间
- $P_{k,i}^a$: 第 k 轮第 i 个 Actor 的执行时间
- 每轮总时长 $P_k = P_k^l + \max_i{P_{k,i}^a}$（受最慢的 Actor 制约）
约束:
- 训练达到目标 reward $J$ 或跑完 $K$ 轮
- 总成本 $\sum C_k \leq B$（预算约束）
其中单轮成本 $C_k = c(P_k^l \cdot d^l + \sum_{i=1}^{I_k} P_{k,i}^a \cdot d^a)$，$c$ 是单位资源价格，$d^l, d^a$ 是资源分配量。
4.2 State（状态空间）
Scheduler 的状态是一个 平坦向量:
$$s_k = (k, L_{k-1}, \bar{R}{k-1}, D_k^{KL}, P{k-1}^l, P_{k-1}^a, b_k)$$
| 分量 | 含义 | 作用 |
|---|---|---|
| $k$ | 当前轮次 | 训练进度感知 |
| $L_{k-1}$ | 上一轮 loss | 反映学习状态 |
| $\bar{R}_{k-1}$ | 上一轮平均 final reward | 反映策略质量 |
| $D_k^{KL}$ | 相邻两轮策略的 KL 散度 | 衡量策略变化幅度 |
| $P_{k-1}^l$ | 上一轮 Learner 执行时间 | 时间成本感知 |
| $P_{k-1}^a$ | 上一轮 Actor 平均执行时间 | Actor 负载感知 |
| $b_k$ | 剩余预算 | 成本约束感知 |
KL 散度的作用值得特别说明：$D_k^{KL} = \sum_a \pi_k(a|s) \log \frac{\pi_k(a|s)}{\pi_{k-1}(a|s)}$。如果 KL 散度大，说明策略更新幅度大，可能需要更多 Actor 收集更多数据来稳定训练。
4.3 Action（动作空间）
$$a_k = I_k \in [1, I_{max}]$$
动作是一个标量整数值，表示当前轮要启动的 Actor 数量。$I_{max} = 32$。
4.4 Reward（奖励函数）
$$r_k = -\beta P_k, \quad \beta \in (0,1)$$
直觉：每轮训练越快越好，所以奖励是负的训练时长。$\beta$ 是缩放系数。
终止轮 K 的特殊奖励:
$$r_K = \begin{cases} -\beta P_K & \text{if } \bar{R}_K \geq J \text{ and } b_k \geq 0 \ -\beta P_K + (\max_k \bar{R}_k - J) & \text{otherwise} \end{cases}$$
如果训练失败（没达到目标 reward $J$ 且预算耗尽），额外加一个负惩罚项 $(\max_k \bar{R}_k - J)$，推动 Scheduler 学会避免这种情况。
4.5 网络结构
Scheduler 的 Policy 和 Critic 网络都很轻量：
输入 (7 维 state)
→ FC(64, Tanh)
→ FC(64, Tanh)
→ 输出 (action / value)
用 Adam 优化器，学习率 0.005，训练 100 个 episode。使用 Ray-Tune 做超参搜索。
5. 训练流程详解
5.1 一轮 On-Policy 训练
Round k:
1. Scheduler 观察 s_k，输出 a_k = I_k
2. 在 ACI 上启动 I_k 个 Actor 容器 + 1 个 Learner 容器
3. Learner 将当前策略权重 θ_k 分发给所有 Actor (via gRPC)
4. 每个 Actor 用 θ_k 在环境中采样轨迹数据
5. Actor 采样完成后将数据返回 Learner，Actor 容器立即释放
6. Learner 汇总数据，执行 PPO 更新: θ_k → θ_{k+1}
7. Learner 完成后也释放
8. 收集 metrics (loss, reward, time, KL div)
9. 计算 r_k，更新 Scheduler
5.2 函数预热（Pre-warming）
论文实测：启动一个 Actor 容器约 300ms，启动 Learner 容器（挂载 GPU）约 1500ms。MinionsRL 通过 函数预热 进一步消除启动开销。
5.3 通信开销
MinionsRL 使用 gRPC 进行 Actor 和 Learner 之间的通信：
| 环境类型 | 传输数据量 | 通信开销 |
|---|---|---|
| 连续控制 (MuJoCo) | 65,536 timesteps | < 100ms |
| 离散控制 (Atari) | 6,144 stacked frames (800 MB) | 可忽略 |
6. Scheduler 的三阶段调度行为
论文观察到 MinionsRL 的 Scheduler 在训练过程中呈现三个阶段（以 Hopper-v3 和 QbertNoFrameSkip-v4 为例）：
Actor 数量
30 ┤
│ ████ ███
20 ┤ ████ ███
│ ████ ███
10 ┤ ████████████████████████████████
│
0 ┼──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──
Phase A Phase B Phase C
(探索期) (稳定期) (冲刺期)
| 阶段 | Actor 数量 | 原因 |
|---|---|---|
| Phase A | 多 | 训练初期策略随机，需要大量数据探索 |
| Phase B | 少/稳定 | 策略趋于稳定，少量数据即可微调，节省成本 |
| Phase C | 略增 | 接近目标 reward，增加 Actor 冲刺最优性能 |
这种自适应行为是 Scheduler 自己 学习 出来的，不是人工设计的规则。
7. 实验结果
7.1 实验设置
Server-based baselines 的集群配置：
- 1 台
Standard_NC6s_v3VM（1 V100 GPU + 6 CPU） - 4 台
Standard_E16-8s_v5VM（8-core Intel Xeon Platinum） - 共 32 CPU cores 用于 Actor
MinionsRL 部署在 ACI 上：
- Learner 容器: 1 V100 GPU
- Actor 容器: 各 1 CPU core，数量 [1, 32] 动态调整
任务: 6 个 OpenAI Gym 环境
- 连续控制 (MuJoCo): Hopper-v3, Humanoid-v3, HalfCheetah-v3
- 离散控制 (Atari): GravitarNoFrameskip-v4, SpaceInvadersNoFrameskip-v4, QbertNoFrameskip-v4
7.2 与 Baselines 对比
对比对象：
- Azure ML: 微软的 MLaaS 平台，固定 Actor 数量
- IMPACT: SOTA actor-learner 架构，支持异步训练和 V-trace 修正
训练时间与成本 (Table 2):
| 环境 | 方案 | 时间 (s) | 成本 ($) |
|---|---|---|---|
| Hopper | MinionsRL | 241 ± 24 | 1.2 ± 0.2 |
| Azure ML | 277 ± 21 | 4.5 ± 0.5 | |
| IMPACT | 291 ± 26 | 4.6 ± 0.8 | |
| Humanoid | MinionsRL | 334 ± 42 | 1.3 ± 0.4 |
| Azure ML | 464 ± 56 | 9.3 ± 1.2 | |
| IMPACT | 436 ± 57 | 2.9 ± 0.7 | |
| HalfCheetah | MinionsRL | 220 ± 29 | 1.1 ± 0.3 |
| Azure ML | 458 ± 49 | 2.9 ± 0.6 | |
| IMPACT | 193 ± 12 | 3.0 ± 0.8 | |
| Gravitar | MinionsRL | 2295 ± 337 | 6.6 ± 0.9 |
| Azure ML | 2902 ± 481 | 11.4 ± 1.5 | |
| IMPACT | 3375 ± 714 | 12.0 ± 1.7 | |
| SpaceInvaders | MinionsRL | 1787 ± 229 | 7.8 ± 1.2 |
| Azure ML | 2260 ± 343 | 26.9 ± 3.1 | |
| IMPACT | 2628 ± 402 | 25.8 ± 2.4 | |
| Qbert | MinionsRL | 506 ± 59 | 2.3 ± 0.8 |
| Azure ML | 872 ± 68 | 6.0 ± 1.0 | |
| IMPACT | 768 ± 66 | 6.4 ± 1.3 |
核心结论: MinionsRL 相比 Azure ML 和 IMPACT，训练时间减少高达 52%，成本减少高达 86%。
7.3 可扩展性
随 Actor 数量增加，单轮完成时间变化：
- MuJoCo 环境（连续控制）: 增长平缓，因为单帧计算轻量
- Atari 环境（离散控制）: 增长较快，因为需要处理 84x84 stacked frames
8. 消融实验
为验证两个关键组件（serverless 函数 + DRL 调度器）的贡献，论文对比了 MinionsRL 的两个变体：
8.1 三个方案对比
| 方案 | Serverless | 调度策略 |
|---|---|---|
| MinionsRL | Yes | DRL-based Scheduler (PPO) |
| MinionsRL-Max | Yes | 每轮固定启动 32 个 Actor |
| MinionsRL-Adapt | Yes | 基于比例的启发式调度 |
MinionsRL-Adapt 的调度规则：$I_k = \text{clip}(1, \frac{\hat{J}k}{J} \cdot I{max}, I_{max})$，其中 $\hat{J}_k$ 是最近 5 轮的移动平均 reward。策略越好 → 分配越多 Actor，直觉是"好策略产生更好的数据"。
8.2 消融结果
- MinionsRL vs MinionsRL-Max: 相似的训练时间，但 MinionsRL 成本降低高达 44%。证明 DRL Scheduler 有效节省了 Actor 开支。
- MinionsRL vs MinionsRL-Adapt: MinionsRL 的 DRL Scheduler 做出更优的调度决策，训练效率更高。证明学习出的调度策略优于手工启发式。
9. Scheduler 跨任务迁移
训练 Scheduler 本身也需要时间（例如 Humanoid-v3 约 10 小时，SpaceInvadersNoFrameskip-v4 约 50 小时）。
论文发现：不同 DRL 任务的 Scheduler 具有 相同的输入输出维度（7 维 state, 1 维 action），因此可以跨任务 fine-tune。
实验结果：
- 将 Hopper-v3 的 Scheduler 迁移到 Humanoid-v3
- 将 QbertNoFrameskip-v4 的 Scheduler 迁移到 SpaceInvadersNoFrameskip-v4
- Fine-tune 只需 10 个 episode（从头训练需要 100 个）
- 训练 Scheduler 的时间和成本 减少约 90%
- 迁移后的性能与从头训练的 持平甚至更优
这意味着在实际部署中，只需为一个任务从头训练 Scheduler，后续新任务都可以快速迁移。
10. 总结与思考
核心贡献
- 首个 serverless DRL 训练框架: 将 actor-learner 架构中的 Actor 和 Learner 重构为 serverless 函数，实现细粒度资源管理和按需计费
- DRL-based Actor Scheduler: 用 PPO 智能体学习动态调度 Actor 数量，自动权衡训练性能和成本
- 显著的性能提升: 时间减少 52%，成本减少 86%
- Scheduler 可迁移: 跨任务 fine-tune 减少 90% 的 Scheduler 训练开销
局限性与思考
- 仅针对 on-policy 算法: Off-policy 算法（如 SAC, TD3）不需要严格同步，serverless 的优势可能不那么明显
- ACI 平台依赖: 实验仅在 Azure Container Instances 上验证，其他 serverless 平台（如 AWS Lambda、Google Cloud Functions）的表现有待验证
- Scheduler 的冷启动: 第一个任务仍需从头训练 Scheduler（数十小时），虽然后续可以迁移
- 通信开销: 随 Actor 数量和数据量增大，gRPC 通信可能成为瓶颈（论文中目前开销较小）
核心思想
MinionsRL 的精髓在于 "用 RL 优化 RL 的训练"——Scheduler 本身是一个 RL 智能体，通过与分布式训练环境的交互，学会在合适的时机投入合适数量的计算资源。这种 meta-level 的优化思路，结合 serverless 的弹性伸缩能力，实现了训练速度和成本的双重优化。