UC Berkeley提出新型分布式框架Ray:实时动态学习的开端

为应对新型 AI 应用不断提高的性能需求,近日 Michael Jordan 等人提出了一个新型的分布式框架 Ray,主要针对当前集群计算框架无法满足高吞吐量和低延迟需求的问题,以及很多模拟框架局限于静态计算图的缺点,并指出强化学习范式可以自然地结合该框架。

人工智能在一些现实世界应用中正逐渐发展为主力技术。然而,到目前为止,这些应用大部分都是基于相当受限的监督学习范式,其中模型是离线学习的,然后提供在线预测。随着人工智能领域的成熟,使用比标准的监督学习设置更宽泛的设置成为必需。和仅仅做出并提供单个预测不同,机器学习应用必须越来越多地在动态环境中运行,对环境变化做出反应,执行一系列动作以达到目标。这些更加宽泛的需求实际上可以自然地在强化学习(RL)的范式内构造,强化学习可以在不确定的环境中持续学习。一些基于 RL 的应用已经达到了引人注目的结果,例如谷歌的 AlphaGo 打败围棋人类世界冠军,这些应用也正在探索自动驾驶汽车、UAV 和自动化操作领域。


把 RL 应用和传统的监督学习应用区分开来的特征有三个。首先,RL 通常高度依赖模拟来探索状态、发现动作的后果。模拟器可以编码计算机游戏的规则、物理系统的牛顿动力学(如机器人),或虚拟环境的混合动力学。这通常需要消耗大量的算力,例如构建一个现实的应用可能需要经过几亿次模拟。其次,RL 应用的计算图是异质、动态演化的。一次模拟可能需要几毫秒到几分钟不等,并且模拟的结果还会影响未来模拟中使用的参数。最后,很多 RL 应用,如机器人控制或自动驾驶,需要快速采取行动以应对不断变化的环境。此外,为了选择最优动作,这些应用需要实时地执行更多的模拟。总之,我们需要一个支持异质和动态计算图的计算框架,同时可以在毫秒延迟下每秒执行百万量级的任务。


已有的集群计算框架并不能充分地满足这些需求。MapReduce [18]、Apache Spark [50]、Dryad [25]、Dask [38] 和 CIEL [32] 不支持通用 RL 应用的高吞吐量和低延迟需求,而 TensorFlow [5]、Naiad [31]、MPI [21] 和 Canary [37] 通常假定计算图是静态的。


这篇论文做出了如下贡献:

  • 指出了新兴 AI 应用的系统需求:支持(a)异质、并行计算,(b)动态任务图,(c)高吞吐量和低延迟的调度,以及(d)透明的容错性。
  • 除了任务并行的编程抽象之外,还提供了 actor 抽象(基于动态任务图计算模型)。
  • 提出了一个可水平伸缩的架构以满足以上需求,并建立了实现该架构的集群计算系统 Ray。


论文:Ray: A Distributed Framework for Emerging AI Applications



论文地址:https://arxiv.org/abs/1712.05889


下一代的 AI 应用将具备持续和环境进行交互以及在交互中学习的能力。这些应用对系统有新的高要求(无论是性能还是灵活性)。在这篇论文中,我们考虑了这些需求并提出了 Ray,一个满足上述需求的分布式系统。Ray 实现了一个动态任务图计算模型(dynamic task graph computation model),该模型支持任务并行化和 actor 编程模型。为了满足 AI 应用的性能需求,我们提出了一个架构,该架构使用共享存储系统(sharded storage system)和新型自下而上的分布式调度程序实现系统控制状态的逻辑集中。我们的实验展示了亚毫秒级的远程任务延迟,以及每秒可扩展至超过 180 万任务的线性吞吐量。实验证明 Ray 可以加速难度高的基准测试,而且是新兴强化学习应用和算法的自然、高效选择。


图 7:该系统利用 GCS 和自下而上的分布式调度程序,以线性方式实现的端到端可扩展性。Ray 用 60 个 m4.16xlarge 节点可以达到每秒 100 万任务的吞吐量,在 1 分钟内处理 1 亿任务。鉴于代价,我们忽略 x ∈ {70,80,90}。


图 8:Ray 保持平衡负载。第一个节点的驱动程序提交 10 万个任务,全局调度程序在 21 个可用节点中平衡这些任务。


图 9:对象存储写入的吞吐量和输出操作(IOPS)。对于单个客户端,在 16 核实例(m4.4xlarge)上大型对象的吞吐量超过 15GB/s(红色),小型对象的吞吐量超过 18K IOPS(蓝绿色)。它使用 8 个线程复制超过 0.5MB 的对象,用 1 个线程复制其他小型对象。条形图代表 1、2、4、8、16 个线程的吞吐量。以上结果是 5 次运行的平均值。


图 10:分布式任务的全透明容错性。虚线代表集群中节点的数量。曲线表示新任务(蓝绿色)和重新执行的任务(红色)的吞吐量。驱动程序持续提交和检索 10000 个任务。每个任务耗时 100ms,依赖于前一个回合的一个任务。每个任务的输入和输出大小为 100KB。


图 11:actor 方法的全透明容错性。驱动程序持续向集群中的 actor 提交任务。在 t = 200s 时,我们删除了 10 个节点中的 2 个,使集群的 2000 个 actor 中的 400 个在剩余节点中恢复。


图 12:Reference ES 和 Ray ES 系统在 Humanoid-v1 任务中得到 6000 分的时间 [13]。Ray ES 实现可以扩展到 8192 个核。而 Reference ES 系统无法运行超过 1024 个核。我们使用 8192 个核获得了 3.7 分钟的中位耗时,比之前公布的最佳结果快一倍。在此基准上,ES 比 PPO 快,但是运行时间方差较大。


图 13:MPI PPO 和 Ray PPO 在 Humanoid-v1 任务中得到 6000 分的时间 [13]。Ray PPO 实现优于专用的 MPI 实现 [3],前者使用的 GPU 更少,代价也只是后者的一小部分。MPI 实现中每 8 个 CPU 就需要 1 个 GPU,而 Ray 至多需要 8 个 GPU,每 8 个 CPU 所需的 GPU 不超过 1 个。


表 3:低延迟机器人模拟结果


理论分布式计算伯克利论文
暂无评论
暂无评论~