面向AI应用分布式执行框架( 二 ) _框架

2）自底向上的分布式调度器。任务由 driver 和 worker 自底向上地提交给局部调度器（local scheduler）。局部调度器可以选择局部调度任务，或将任务传递给全局调度器。通过允许本地决策，降低了任务延迟，并且通过减少全局调度器的负担，增加了系统的吞吐量。

文章插图

自底向上的分布式调度器
性能表现
1）可扩展性和表现性能
端到端可扩展性。GCS 的主要优势是增强系统的横向可扩展性。我们可以观察到几乎线性的任务吞吐量增长。在 60 节点，Ray 可以达到超过每秒 100 万个任务的吞吐量，并线性地在 100 个节点上超过每秒 180 万个任务。最右边的数据点显示，Ray 可以在不到一分钟的时间处理 1 亿个任务（54s）。

文章插图

全局调度器的主要职责是在整个系统中保持负载平衡。Driver 在第一个节点提交了100K 任务，由全局调度器平衡分配给21 个可用节点。

文章插图

对象存储性能。对于大对象，单一客户端吞吐量超过了15GB/s（红色），对于小对象，对象存储IOPS 达到18K（青色），每次操作时间约56 微秒。

文章插图

2）容错性
从对象失败中恢复。随着 worker 节点被终结，活跃的局部调度器会自动触发丢失对象重建。在重建期间，driver 最初提交的任务被搁置，因为它们的依赖关系不能满足。但是整体的任务吞吐量保持稳定，完全利用可用资源，直到丢失的依赖项被重建。

文章插图

分布式任务的完全透明容错。虚线表示集群中的节点数。曲线显示新任务（青色）和重新执行任务（红色）的吞吐量，到210s 时，越来越多的节点加回到系统，Ray 可以完全恢复到初始的任务吞吐量。
从actor 失败中恢复。通过将每个actor 的方法调用编码到依赖关系图中，我们可以重用同一对象重构机制。

文章插图

t=200s 时，我们停止 10 个节点中的 2 个，导致集群中 2000 个 actor 中的 400 个需要在剩余节点上恢复。（a）显示的是没有中间节点状态被存储的极端情况。调用丢失的 actor 的方法必须重新串行执行（t = 210-330s）。丢失的角色将自动分布在可用节点上，吞吐量在重建后完全恢复。（b）显示的是同样工作负载下，每 10 次方法调用每个 actor 自动进行了一次 checkpoint 存储。节点失效后，大部分重建是通过执行 checkpoint 任务重建 actor 的状态（t = 210-270s）。
GCS 复制消耗。为了使 GCS 容错，我们复制每个数据库碎片。当客户端写入 GCS 的一个碎片时，它将写入复制到所有副本。通过减少 GCS 的碎片数量，我们人为地使 GCS 成为工作负载的瓶颈，双向复制的开销小于 10% 。
3）RL 应用
我们用 Ray 实现了两种 RL 算法，与专为这两种算法设计的系统进行对比，Ray 可以赶上甚至超越特定的系统。除此之外，使用 Ray 在集群上分布这些算法只需要在算法实现中修改很少几行代码。
ES 算法（Evolution Strategies）

文章插图

Ray 和参考系统实现 ES 算法在 Humanoid v1 任务上达到 6000 分所需时间对比。
在 Ray 上实现的 ES 算法可以很好地扩展到 8192 核，而特制的系统在 1024 核后便无法运行。在 8192 核上，我们取得了中值为 3.7 分钟的效果，比目前最好效果快两倍。
PPO 算法（Proximal Policy Optimization）
为了评估 Ray 在单一节点和更小 RL 工作负载的性能，我们在 Ray 上实现了 PPO 算法，与 OpenMPI 实现的算法进行对比。

文章插图

MPI 和 Ray 实现 PPO 算法在 Humanoid v1 任务上达到 6000 分所需时间对比。
用 Ray 实现的 PPO 算法超越了特殊的 MPI 实现，并且使用 GPU 更少。
控制仿真机器人
实验表明，Ray 可以达到实时控制模拟机器人的软实时要求。Ray 的驱动程序能运行模拟机器人，并在固定的时间间隔采取行动，从 1 毫秒到 30 毫秒，以模拟不同的实时要求。