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

编者注：今天的博文由百度深度学习团队和 CoreOS 的 etcd 团队联合撰写。

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

两个开源社区——源自百度的深度学习框架 PaddlePaddle 和最著名的容器化应用调度器 Kubernetes®——共同宣布在 PaddlePaddle 代号为 Fluid 的新版本中推出弹性深度学习 (Elastic Deep Learning, EDL) 功能。

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

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

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

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

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

在第一次测试中，我们以 10 秒间隔逐个启动了最多 20 个 PaddlePaddle 作业。每个作业有 60 个 trainer 和 10 个 parameter server 进程，并将持续运行数小时。我们重复了实验 20 次：10 次关闭 FluidEDL，10 次开启 FluidEDL。图一中，实线对应前 10 次实验，虚线对应后 10 次。在图的上方部分，我们看到在没有 EDL 的情况下，pending 作业数量单调递增。然而，当 EDL 开启时，资源被均匀分配给所有作业。Fluid EDL 会杀死一些现有进程以为新作业和稍后进入的作业腾出空间。在这两种情况下，集群的利用率是相同的（见图下方部分）。

| | | 图 1. Fluid EDL 均匀分配资源给作业。
|

在第二次测试中，每个实验运行 400 个 Nginx pod，它们的优先级高于六个 PaddlePaddle 作业。最初，每个 PaddlePaddle 作业有 15 个 trainer 和 10 个 parameter servers。我们每 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 仓库，在那里你可以找到设计文档、简单教程和实验详情。

• ←上一篇
• 下一篇→