PaddlePaddle Fluid：改进Kubernetes上的弹性深度学习

2017 年 12 月 22 日 AI前线

作者｜【Kubernetes 博客】

译者｜冬雨

编辑｜Emily

AI 前线导读：PaddlePaddle 和 Kubernetes®宣布：PaddlePaddle 在新版本 Fluid 中推出了弹性深度学习（EDL）特性。Fluid EDL 中包括一个 Kubernetes 控制器、一个根据集群中的闲置硬件资源改变分布式作业进程数量的 PaddlePaddle 自动调度器，以及如 PaddlePaddle 设计文档中所述的新的容错架构。

更多干货内容请关注微信公众号“AI 前线”，（ID：ai-front）

在 PaddlePaddle 设计文档中提到，Fluid EDL 中包括一个 Kubernetes 控制器、一个根据集群中的闲置硬件资源改变分布式作业进程数量的 PaddlePaddle 自动调度器，以及如 PaddlePaddle 设计文档中所述的新的容错架构。

工业化的深度学习需要非常强大的计算能力。研究实验室和公司经常构建由 SLURM、MPI 或者 SGE 管理的 GPU 集群。如果闲置资源能满足所提交作业的需求，这些集群就会运行它，否则可能将其挂起一段难以估计的时间。这种方法有其不足：比如可用节点有 99 个，但提交的作业需要 100 个，那么这个作业必须等待，无法使用任何可用的节点。弹性深度学习作业经常缺乏最佳资源，Fluid 与 Kubernetes 一起协作来帮助尽可能早地揭示潜在的算法问题，从而更好地供能。

另一个挑战是，工业化用户喜欢将深度学习作业作为完整数据管道的子阶段来运行，包括 Web 服务器和日志控制器。比如通用集群需要基于优先级的弹性调度。这使其可以在高网络流量时令 Web 服务作业中运行更多的进程，减少深度学习进程，当网络流量降低时，则优先进行深度学习。Fluid 通过 Kubernetes 的 API 服务器了解整体情况，协调不同作业的进程数量。

在这两种场景中，无论进程量忽然冲高还是降低，PaddlePaddle 作业均可忍受。我们通过实现新的设计做到了这一点，在之前的博客中曾描述过以前的 PaddlePaddle 架构，而这个新思想又在此之上额外加入了一个主控进程。在新的设计中，只要一个作业中还有三个进程，就继续工作。在所有进程都被杀掉的极端情况下，该进程可以被恢复并重新执行。

我们针对两种情况测试过 Fluid EDL：

Kubernetes 集群只运行 PaddlePaddle 作业；
集群同时运行 PaddlePaddle 和 Nginx 两类作业。

在第一类测试中，我们以 10 秒钟每个的间隔开启了 20 个 PaddlePaddle 作业。每个作业有 60 个训练器和 10 个参数服务进程，然后持续了数个小时。我们将该实验重复了 20 次：10 个关掉了 Fluid EDL，10 个是开启的。在图 1 中，实线表示前 10 次实验，虚线表示后 10 次。在这张图的上半部分，我们看到在没有 EDL 的情况下挂起的作业数单调递增。而打开 EDL 时，资源会被均匀分布给所有的作业。Fluid EDL 杀掉一些已有的进程，为新作业和稍后开始的作业腾出资源。在这两种情况下，集群得到了平等地利用（如图下半部分）。

图 1. Fluid EDL 在作业中均匀分配资源

在第二次测试中，每个实验运行 400 个 Nginx Pod，它们的优先级高于 6 个 PaddlePaddle 作业。最初，每个 PaddlePaddle 有 15 个训练器和 10 个参数服务器。我们每 90 秒杀掉 100 个 Nginx Pod，直至剩下 100 个，然后再每 90 秒增加 100 个 Nginx 作业。图 2 的上半部分展示了这个过程。图表中部显示 Fluid EDL 通过减少 Nginx Pod，自动开启了一些 PaddlePaddle 进程，并在稍后增加 Nginx Pod 来杀掉 PaddlePaddle 进程。最终，集群的利用率保持在 90% 左右，如图底部所示。但当关闭 Fluid EDL 时，PaddlePaddle 进程是不会自动增加的，利用率也会随着 Nginx Pod 数量的不同产生波动。