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

编者按：今天的文章是由百度深度学习团队和 CoreOS 的 etcd 团队联合发布的。

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

两个开源社区——源于百度的深度学习框架 PaddlePaddle 和最著名的容器化应用调度器 Kubernetes®——正在宣布 PaddlePaddle 新版本（代号 Fluid）中的弹性深度学习 (EDL) 功能。

Fluid EDL 包括一个 Kubernetes 控制器，PaddlePaddle 自动伸缩器，它根据集群中空闲的硬件资源更改分布式作业的进程数量，以及 PaddlePaddle 设计文档中描述的新的容错架构。

工业深度学习需要大量的计算能力。研究实验室和公司通常会构建由 SLURM、MPI 或 SGE 管理的 GPU 集群。这些集群要么在提交的作业所需的资源少于空闲资源时运行该作业，要么将作业挂起不可预测的长时间。这种方法有其缺点：例如，在有 99 个可用节点且提交的作业需要 100 个节点的情况下，该作业必须等待而无法使用任何可用节点。Fluid 与 Kubernetes 协同工作，为通常缺乏最佳资源的弹性深度学习作业提供支持，从而帮助尽早发现潜在的算法问题。

另一个挑战是，工业用户倾向于将深度学习作业作为完整数据管道（包括 Web 服务器和日志收集器）的子阶段运行。这种通用集群需要基于优先级的弹性调度。这使得在 Web 流量高峰期间可以在 Web 服务器作业中运行更多进程，而在深度学习中运行更少进程，然后在 Web 流量较低时优先处理深度学习。Fluid 与 Kubernetes 的 API 服务器通信以了解全局情况，并协调与各种作业关联的进程数量。

在这两种情况下，PaddlePaddle 作业都能够容忍进程的峰值和减少。我们通过实现新的设计实现了这一点，该设计在 之前的博客文章中描述的旧 PaddlePaddle 架构的基础上引入了一个主进程。在新的设计中，只要一个作业中剩下三个进程，它就会继续。在所有进程都被杀死等极端情况下，该作业可以被恢复并继续运行。

我们针对两种用例测试了 Fluid EDL：1) Kubernetes 集群仅运行 PaddlePaddle 作业；2) 集群运行 PaddlePaddle 和 Nginx 作业。

在第一个测试中，我们以 10 秒的间隔逐个启动了多达 20 个 PaddlePaddle 作业。每个作业有 60 个训练器和 10 个参数服务器进程，并将持续数小时。我们重复了该实验 20 次：10 次关闭 FluidEDL，10 次开启 FluidEDL。在图一中，实线对应于前 10 次实验，虚线对应于其余的实验。在该图的上半部分，我们看到在没有 EDL 的情况下，挂起作业的数量单调递增。但是，当 EDL 打开时，资源会均匀分配给所有作业。Fluid EDL 会杀死一些现有进程，为新作业和稍后时间点进入的作业腾出空间。在这两种情况下，集群都得到同等利用（参见图的下半部分）。

| | | 图 1. Fluid EDL 在作业之间均匀分配资源。
|

在第二个测试中，每个实验运行了 400 个 Nginx pod，它们的优先级高于六个 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 数量的变化而波动。

| | | 图 2. Fluid 随着 Nginx 进程的变化而更改 PaddlePaddle 进程。 |

我们将继续开发 FluidEDL，并欢迎您的评论和贡献。访问 PaddlePaddle 仓库，您可以在其中找到设计文档、简单教程 和 实验详情。

• ←上一篇
下一篇→