Skip to content

Latest commit

 

History

History
272 lines (164 loc) · 17.8 KB

10.2.3-分布式强化学习框架和应用.md

File metadata and controls

272 lines (164 loc) · 17.8 KB

10.2.3 分布式强化学习框架

上一章我们讨论了分布式强化学习框架面临的挑战以及需求。这一章我们更进一步地举例分析一些走在时代前沿的框架。

Github上的强化学习框架数量巨大，而我们可以根据其支持的功能简单地分为以下大类：

  • 支持某些特定的环境/模拟器。例如：gym[2]支持了一些简单的2D小游戏（例如Atari）。ELF支持一系列并发的实时战略游戏，并且支持C++和python的高效接口。 在 C++ 方面，ELF[3]利用用C++ 多线程并行托管多个游戏，从而提高模拟器的效率。 而在 Python 方面也是类似的，ELF通过一次返回批量的游戏状态，来提高模拟器的吞吐量。

  • 支持通用的强化学习的算法。例如：Baselines[4]等强化学习工具包，支持了一系列非分布式的强化学习算法。

  • 支持分布式强化学习算法，例如：ACME[5]，RLlib[1]等强化学习工具包，他们都在一定程度上帮助用户快速地将分布式强化学习算法部署在多节点上。

  • 针对某个算法开发的项目，不存在通用性；例如：TorchBeast[6]是一个基于IMPALA[7]的高效实现，可以支持分布式的部署；不支持除了IMPALA以外的其他算法。

下表整理了部分有代表性的受欢迎的强化学习平台：

开源框架 支持通用的算法接口 基于环境开发 支持分布式 受欢迎程度
ACMEACME[5] + Reverb[14] ✔ x x 2.1k
ELF[3] x ✔ ✔ 2k
Ray + RLlib[1] ✔ x ✔ 16.4k
Gym[16] x ✔ x 24.5k
Baselines[3] ✔ x x 11.6k
TorchBeast[6] x x ✔ 553
SEEDRL[14] x x ✔ 617
Tianshou[15] ✔ x ? 3.2k
Keras-RL[16] ✔ x x 5.1k

可以看到，用户对通用的强化学习框架的需求十分旺盛；而其中，可以分布式的强化学习框架或者系统受到了更多用户的青睐。这也暗示了未来的强化学习框架的发展方向是朝着通用性，可扩展性和大规模分布式的方向发展。

除此之外，还可以根据是否支持多智能体（multi-agent）的任务对强化学习框架进行分类。例如：MARO[8]就是一个多智能体资源优化平台，可以用于实际资源优化。

我们以上面表体里提到的一些最受欢迎的经典强化学习平台为例，希望能通过对这些强化学习系统的论文的介绍，讨论他们在系统设计时的一些思考，并且希望这些思考能为未来设计提供参考和灵感。

RLlib

在RLlib[1]设计之初，并没有太多的可以参考的统一的强化学习平台。 那时候虽然深度学习(Deep Learning)的系统和抽象方面取得了很大的进步（例如：Tensorflow[9]， Pytorch[10]等），但对强化学习的系统和抽象设计方面的进展相对较少。尽管如此，强化学习中的许多挑战都源于对学习和仿真/模拟环境的规模化需求，同时也需要整合快速增长的算法和模型。因此设计这么一个系统是很有必要的。

而RLlib提出的区别于其他框架的主要观点包括：

  • 采用自顶向下分层控制分布式强化学习算法，从而更好地采用并行计算资源调度来完成这些任务；

  • 需要定义一个通用的强化学习范式，能够让一系列的强化学习算法达到可拓展和大量代码重用；

下面我们从这两点区别入手来探讨RLlib的细节。

分层控制分布式强化学习

  1. 强化学习训练的计算模式不规则性

目前的强化学习算法的计算模式中是高度多样化的。如下表所示，目前强化学习算法的计算模式突破了如今流行的分布式框架所支持的计算模型的界限。

根据算法的不同， 这种不规则发生在如下几个层面：

  • 不同不同的强化学习任务的持续时间和资源需求也有数量级的差异；例如A3C的更新可能需要几毫秒，但其他算法如PPO需要更大粒度时间颗粒。

  • 不同的强化学习算法的通信模式各异，从同步到异步的梯度优化，再到在高通量的异策略学习算法（如ApeX[12]和IMPALA[7]）中拥有多种类型的异步任务，通信模式各不相同。

  • 不同的强化学习算法的模块构成高度多样化。由于强化学习或深度学习训练相结合， 因而有超参数调优、或是在单一算法中结合无导数优化和基于梯度的优化等方式产生嵌套计算的需求。因而强化学习算法经常需要维护和更新大量的状态，包括策略参数、重放缓冲区，甚至还有外部模拟器等。

下表的例子从不同维度上说明了，单机DQN和大规模集群的IMPALA+PBT在这些方面上都存在巨大的差别。

维度 单机DQN 大规模集群的IMPALA+PBT
单任务时长 ~1ms 数min
单任务所需要的资源 1 CPU 数个CPU和GPU
总共需要的资源 1 CPU 数百个CPU和GPU
嵌套深度 1层 >3层
所需内存 mb量级 百GB级别
执行方式 同步 异步高并发
  1. 当前的现状和解决方案

因此，开发人员只能使用大杂烩的框架来实现他们的算法，包括参数服务器(Parameter Server)、类MPI框架中的集体通信基元、任务队列等。

对于更复杂的算法，常见的做法是构建自定义的分布式系统，在这个系统中，进程之间独立计算和协调，没有中央控制。虽然这种方法可以实现较高的性能，但开发和评估的成本很大，不仅因为需要实现和调试分布式程序，而且因为这些算法的组成进一步使其实现复杂化。

此外，今天的计算框架（如Spark[11]、MPI）通常是假设有规律的计算模式，当子任务的持续时间、资源需求或嵌套不同时，这些计算框架会有性能损失。

因此，RLLib希望以一个单一的编程模型能够满足强化学习算法训练的所有要求，并且可以在不放弃结构化计算的情况下实现。

图10.2.10 目前大多数强化学习算法都是以 (a)的模式实现的。RLlib提出了一种分层控制模型 (c)，它扩展了 (b)，支持强化学习中的嵌套和超参数调优工作，简化和统一了用于实现的编程模型。

举例来说，对于每个分布式强化学习算法，RLlib写出一个等效的算法，表现出逻辑上集中的程序控制（图(b)）。也就是说，不用让独立执行进程（图(a) 中的A、B、C、D）相互协调（例如，通过RPC、共享内存、参数服务器或集体通信），而是一个单一的驱动程序（(b) 和(c) 中的D）可以将算法的子任务委托给其他进程并行执行。在这种工作模式中，工作进程A、B、C被动地保持状态（如策略或仿真器状态），但在被D调用之前不执行任何计算，为了支持嵌套计算，我们提出用分层委托控制模型（图(c)）来扩展集中控制模型，允许工作进程（如B、C）在执行任务时进一步将自己的工作（如仿真、梯度计算）委托给自己的子工作进程。

在这样一个逻辑上集中的分层控制模型的基础上搭建强化学习框架，有如下重要优势：

  • 等效算法在实际应用中往往更容易实现，因为分布式控制逻辑完全封装在一个进程中，而不是多个进程同时执行。

  • 将算法组件分离成不同的子程序（例如，做卷积运算、计算梯度与某些策略的目标函数的梯度），可以在不同的执行模式下实现代码的重用。有不同资源需求的子任务（CPU任务或者GPU任务）可以放在不同的机器上，从而能够降低计算成本。

  • 在这个模型中编写的分布式算法可以相互之间无缝嵌套，满足了并行性封装原则。

举例来说明具体的编程模型上的差别：

图10.2.11 分布式和分层控制的编程模式的差别。用同一种颜色加粗的代码可以归类为实现同一个目的的代码模块。

如图10.2.11所示，将分布式超参数搜索与分布式计算的函数组合在一起，会涉及到复杂的嵌套并行计算模式。如果使用MPI (a)，作为底层来设计并行化写强化学习算法代码的时候，需要对每个算法的适配进行定制化代码修改。这限制了新的分布式强化学习算法的快速开发。使用分层控制 (b)，组件可以保持不变，并且可以作为远程任务简单地调用。 尽管图10.2.11中的示例很简单，但例如HyperBand、PBT等需要长时间运行的、精细的超参数调整的算法越来越需要对培训进行细粒度的控制。

因此RLlib在基于任务的灵活编程模型（如Ray[13]）的基础上，通过分层控制和逻辑中控来构建强化学习算法库。 基于任务的系统允许在细粒度的基础上，在子进程上异步调度和执行子例程，并在进程之间检索或传递结果。

通用的强化学习范式

由于强化学习算法之间的差距较大，在RLLib之前几乎没有一个统一强化学习接口的框架。因而大部分的代码可复用性差，导致强化学习开发和学习的成本较高。

RLlib将强化学习算法里的智能体（agent）抽象成两大块：和算法相关的策略(policy)和与算法无关的策略优化器 （policy optimizer)。 其中策略包括策略图（policy graph）和 策略模型（policy model）。策略图定义了如何算法里如何探索和利用，以及如何用采样得到的数据训练模型等，策略模型用来定于算法的模型的网络结构。这两块都支持用户的定制化。而策略优化器是与算法无关的部分。策略优化器负责分布式采样、参数更新和管理重放缓冲区等性能关键任务。

将策略优化器如此抽象具有以下优点： 通过将执行策略与策略优化函数定义分开，各种不同的优化器可以被替换进来，以利用不同的硬件和算法特性，却不需要改变算法的其余部分。策略图类封装了与深度学习框架的交互，使得用户可以避免将分布式系统代码与数值计算混合在一起，并使优化器的实现能够被在不同的深度学习框架中改进和重用。

图10.2.13 四种RLlib策略优化器步骤方法的伪代码。 每次调用优化函数时，都在本地策略图和远程评估程序副本阵列上运行。 图中用橙色高亮Ray的远程执行调用，用蓝色高亮 Ray的其他调用。

如图10.2.13所示，通过利用集中控制，策略优化器简洁地抽象了强化学习算法优化中的多种选择：同步与异步，全局规约与参数服务器，以及使用GPU与CPU的选择。

评估强化学习系统

那么，当完成了强化学习系统设计以后，需要怎么评估呢？

  • 算法的完备性。

    RLlib目前可以支持大部分的算法类型，包括：基于DQN的变形算法，基于策略梯度，基于进化策略，AlphaGo，多智能体等。同时RLlib也支持大部分的强化学习的模块和组件，并支持用户在之上做二次开发。

  • 性能的高效性。

    • 采样效率。通常通过单位时间内能采样多少样本来评估。

      而在RLlib里，它对采样进程收集样本的可扩展性进行了基准测试。

      图10.2.14 策略评估的吞吐量从1到128核几乎呈线性扩展。

    • 是否能有效地支持大规模的任务。 通常情况下，这是衡量框架是否有高效的可扩展性的重要指标。

      RLlib使用Redis、OpenMPI和分布式TensorFlow评估了RLlib在ES、PPO和A3C三种算法上的性能，并与专门为这些算法构建的专用系统进行了比较。所有实验中都使用了相同的超参数。实验结果证明，RLlib在使用相同资源的情况下，能够比MPI等获得更好的结果。

      图10.2.15 在Humanoid-v1任务上达到6000的奖励所需的时间。RLlib实现的ES和PPO的性能优于已有实现。

    • 是否支持训练的可扩展性，例如: 否支持高效的多GPU训练。

      RLlib评估了在使用全局规约和本地多GPU两种优化器模式下，在4个GPU和16个GPU的计算资源下，不同的任务（Pong-v0和Humanoid-v1）下，优化器每秒能处理的数据量。

      策略优化器 梯度计算资源 任务 SGD每秒计算吞吐量
      全局规约 4 GPU Humanoid-v1 330,000
      全局规约 4 GPU Pong-v0 230,000
      全局规约 16 GPU Humanoid-v1 440,000
      全局规约 16 GPU Pong-v0 100,000
      本地多GPU 4 GPU Humanoid-v1 2,100,000
      本地多GPU 4 GPU Pong-v0 N/A（内存无法加载）
      本地多GPU 16 GPU Humanoid-v1 1,700,000
      本地多GPU 16 GPU Pong-v0 150,000

    上表展示了，一个专门的多GPU策略优化器在数据可以完全装入GPU内存时，表现优于全局规约。事实上，不同的策略在不同条件下表现更好，这表明策略优化器是一个有用的抽象。

总结

RLlib是一个强化学习的开源框架，它利用细粒度的嵌套并行机制在各种强化学习任务中实现了最优性能。它既提供了标准强化学习算法的集合，又提供了可扩展的接口，以方便地编写新的强化学习算法。即便如此，RLlib中仍然存在一些值得改进的地方，并且后续有许多工作针对RLlib进行了改进。

思考

RLlib中哪些设计的地方不合理呢？

小结与讨论

本章主要围绕，分布式强化学习框架，RLlib，分层控制分布式强化学习，通用的强化学习范式，评估强化学习系统展开介绍。

参考文献

  1. Liang E, Liaw R, Nishihara R, et al. RLlib: Abstractions for distributed reinforcement learning[C.//International Conference on Machine Learning. P MLR, 2018: 3053-3062.
  1. Brockman G, Cheung V, Pettersson L, et al. Openai gym[J.. arXiv preprint arXiv:1606.01540, 2016.
  1. Tian Y, Gong Q, Shang W, et al. Elf: An extensive, lightweight and flexible research platform for real-time strategy games[J.. Advances in Neural Information Processing Systems, 2017, 30.
  1. https://github.com/openai/baselines
  1. Hoffman M, Shahriari B, Aslanides J, et al. Acme: A research framework for distributed reinforcement learning[J.. arXiv preprint arXiv:2006.00979, 2020.
  1. Küttler H, Nardelli N, Lavril T, et al. Torchbeast: A pytorch platform for distributed rl[J.. arXiv preprint arXiv:1910.03552, 2019.
  1. Espeholt L, Soyer H, Munos R, et al. Impala: Scalable distributed deep-rl with importance weighted actor-learner architectures[C.//International Conference on Machine Learning. PMLR, 2018: 1407-1416.
  1. https://github.com/microsoft/maro
  1. Abadi M, Barham P, Chen J, et al. {TensorFlow}: A System for {Large-Scale} Machine Learning[C.//12th USENIX symposium on operating systems design and implementation (OSDI 16). 2016: 265-283.
  1. Paszke A, Gross S, Massa F, et al. Pytorch: An imperative style, high-performance deep learning library[J.. Advances in neural information processing systems, 2019, 32.
  1. https://github.com/apache/spark
  1. Horgan D, Quan J, Budden D, et al. Distributed prioritized experience replay[J.. arXiv preprint arXiv:1803.00933, 2018.
  1. Moritz P, Nishihara R, Wang S, et al. Ray: A distributed framework for emerging {AI} applications[C.//13th USENIX Symposium on Operating Systems Design and Implementation (OSDI 18). 2018: 561-577.
  1. https://github.com/google-research/seed_rl
  1. https://github.com/thu-ml/tianshou
  1. https://github.com/keras-rl/keras-rl