PaddlePaddle Fluid：弹性深度学习在Kubernetes中的实践

【编者的话】今天的帖子是百度深度学习团队和CoreOS的etcd团队的联合写的。

两个开源社区PaddlePaddle（深度学习框架源于百度）和Kubernetes（最著名的容器化应用程序调度器）在PaddlePaddle的新版本Fluid中发布了弹性深度学习（EDL）功能。

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

工业深度学习的挑战之一是需要大量的计算能力。研究实验室和公司经常构建由SLURM，MPI或SGE管理的GPU集群。这些集群要么运行一个提交的作业（如果它需要的比闲置的资源要少）或者将作业挂起一段难以预估的时间。这种方法有其缺点：在有99个可用节点和一个需要100个提交作业的例子中，作业必须等待而不能使用任何可用节点。Fluid与Kubernetes一起工作，通过帮助尽可能早地揭示潜在的算法问题，为缺乏最佳资源的弹性深度学习工作提供动力。

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

面对这两种挑战，PaddlePaddle作业都可以轻松应对进程数量忽高忽低的变化。我们通过实现新设计来实现这一点，除了之前的博客文章中介绍的旧PaddlePaddle体系结构之外，还引入了一个主流程。在新的设计中，只要有三个进程还在工作中，就会继续下去。在所有进程都被杀死的极端情况下，作业可以重载并恢复。

我们测试了Fluid EDL的两种用例：

1. Kubernetes集群只运行PaddlePaddle作业;
2. 集群运行PaddlePaddle和Nginx作业。

在第一个测试中，我们开始了20个PaddlePaddle作业，间隔10秒。每个作业有60个trainers和10个参数服务进程，并将持续数小时。我们重复实验20次：关闭Fluid EDL 10次，打开Fluid EDL 10次。在图一中，实线对应于前10个实验，其余的是虚线。在图的上半部分，我们看到未处理作业的数量在没有EDL的情况下单调递增。但是，当EDL打开时，资源将平均分配给所有作业。Fluid EDL杀死了一些现有的进程，为新的其他任务腾出空间，并在晚些时候任务开始运行。在这两种情况下，集群都被平等利用（见图的下半部分）。

在第二个测试中，每个实验都运行了400个Nginx Pods，其优先级高于6个PaddlePaddle作业。最初，每个PaddlePaddle工作有15个trainers和10个参数服务。我们每90秒杀死100个Nginx Pods，直到剩下100个，然后我们开始将Nginx工作的数量每90秒增加100个。图2的上半部分显示了这个过程。图中的中间显示，Fluid EDL通过减少Nginx Pods来自动启动一些PaddlePaddle进程，并在稍后增加Nginx Pods来杀死PaddlePaddle进程。结果，该集群维持在90％左右的利用率，如图所示。当Fluid EDL被关闭时，没有PaddlePaddle进程自动增加，并且利用率随着Nginx Pods数量的变化而波动。

我们继续在FluidEDL上工作，并欢迎留言和加入我们。访问PaddlePaddle repo，您可以在其中找到设计文档，简单的教程和实验细节。

原文链接：PaddlePaddle Fluid: Elastic Deep Learning on Kubernetes（翻译：ds_sky2008）