测试很丰满！百度联合Kubernetes改进弹性深度学习
两个开源社区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作业。
在第一个测试中，我们以10秒的间隔逐一开始了20个PaddlePad工作。每个作业有60个培训人员和10个参数服务器进程，并将持续数小时。我们重复实验20次：关闭Fluid EDL 10次，打开FluidEDL 10次。在图一中，实线对应于前10个实验，其余的是虚线。在图的上半部分，我们看到未处理作业的数量在没有EDL的情况下单调递增。但是，当EDL打开时，资源将平均分配给所有作业。Fluid EDL处理了一些现有的流程，为新的作业腾出空间，并在晚些时候进入作业。在这两种情况下，集群都被平等利用（见图的下半部分）。
在第二个测试中，每个实验都运行了400个Nginx Pod，其优先级高于6个PaddlePaddle作业。最初，每个PaddlePaddle工作有15个培训人员和10个参数服务器。我们每90秒处理100个Nginx pods，直到剩下100个，然后我们开始将Nginx工作的数量每90秒增加100个。图2的上半部分显示了这个过程。图中的中间显示，Fluid EDL通过减少Nginx Pod来自动启动一些PaddlePaddle进程，并在稍后增加Nginx Pod来处理PaddlePaddle进程。结果，该集群维持在90％左右的利用率，如图所示。当Fluid EDL被关闭时，没有PaddlePaddle进程自动增加，并且利用率随着Nginx Pod的数量变化而波动。