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次实验:关闭FluidEDL 10次,打开FluidEDL 10次。在图一中,实线对应于前10个实验,虚线对应于其余10个实验。在图的上部,我们看到未使用EDL的情况下待处理作业的数量单调增加。但是,当打开EDL时,资源将平均分配给所有作业。 Fluid EDL杀死了一些现有流程,从而为新的工作和稍后出现的工作腾出了空间。在这两种情况下,群集的利用率均相同(请参见图的下部)。

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

在第二个测试中,每个实验运行400个Nginx容器,其优先级高于六个PaddlePaddle作业。最初,每个PaddlePaddle作业都有15个培训师和10个参数服务器。我们每90秒杀死100个Nginx吊舱,直到剩下100个,然后开始每90秒将Nginx作业数量增加100个。图2的上部显示了此过程。该图的中间显示,Fluid EDL通过减少Nginx容器自动启动某些PaddlePaddle进程,并在以后通过增加Nginx容器自动终止PaddlePaddle进程。结果,如图所示,群集保持了约90%的利用率。当关闭Fluid EDL时,没有PaddlePaddle进程自动递增,并且利用率随着Nginx容器数的变化而波动。

| | | 图2.流体变化PaddlePaddle过程与Nginx过程的变化。 |

我们将继续就FluidEDL开展工作,并欢迎提出意见和贡献。造访 PaddlePaddle回购 ,在这里您可以找到 设计文件 , 一种 简单教程 实验细节 .

  • 徐艳(百度研究)

  • 王贺林(百度研究)

  • 吴义(百度研究)

  • 陈曦(百度研究)

  • 龚维宝(百度研究)

  • 李翔(CoreOS)

  • 王怡(百度研究)