edl 一文读懂百度PaddlePaddle EDL技术

新智元专栏

【新智元指南】百度和CoreOS联合开发的Paddle Paddle Elastic Deep Learning(EDL)技术可以将一个集群的利用率提高到接近100%，而基于HPC的一般深度学习集群的利用率往往低于10%。本文调查了设计文档和源代码，采访了EDL的主要设计者王毅，并在操场集群部署了EDL，对桨式弹性深度学习技术进行了深入解读。

最近在Kubernetes官方博客上看到一篇专题文章http://blog . kubernites . io/2017/12/Paddle-Paddle-Fluid-Elastic-Learning . html，介绍百度和CoreOS联合开发的Paddle Paddle Elastic Deep Learning(EDL)技术。实验表明，该技术可以将集群的利用率提高到接近100%。要知道一般基于HPC的深度学习集群利用率往往不到10%。而且集群的成本很高。这项技术可以使投资获得多重收益，每年可以减少公司数百万美元的计算投资，从而吸引在人工智能领域苦苦挣扎的团队。

遗憾的是，以上很短。为了深入了解PaddlePaddle EDL，我调查了设计文档和源代码，采访了EDL的主设计师王毅，并在游乐场的集群上部署了EDL。我把我的探索写成了三篇文章

1.对EDL的深度解读

2.EDL工业园区建设

3.EDL和无人驾驶技术

本文是第一篇。

一般云环境下的机器学习训练任务包括几个主进程，一些参数服务器进程，更多的训练进程。这些流程都在云机器集群中运行，有时需要与其他培训任务共享计算资源，经常需要与其他云服务(如web服务)共享资源。理想状态是机器学习训练系统知道根据集群资源的使用情况和每个任务的优先级动态调整参数服务进程和训练进程的数量，从而充分利用集群CPU/GPU。这是弹性深度学习(EDL)系统的设计目标。

EDL和HPA

水平Pod自动缩放(HPA)是由Kubernetes提供的一种灵活的调度机制。它的出发点是通过在单个计算任务中向每个Pod公平分配计算资源，实现单个任务分布式系统资源的优化利用。在“训练深度学习模型”的场景中，“单个计算任务”可以是训练用于识别图像中的对象的模型，而另一个“单个训练任务”可以是训练语音识别系统。这两个培训任务需要部署在同一个集群中，部署时间不同，资源要求也不同。理想情况下，自动缩放控制器对每个这样的训练任务所需的系统资源有全局理解，然后根据需要分配资源。而HPA控制器对不同的训练任务并没有这样的全局理解。

另一方面，HPA的灵活调度是针对同一类型计算任务下的Pods。然而，深度学习系统中的训练过程和参数服务器往往在不同类型的Pods中。我们想要来自autoscale的不同种类的播客。这些深度学习培训系统的独特要求导致在使用Kubernetes时需要特定的灵活调度解决方案，而不是直接采用HPA。而这个具体的解决方案就是EDL在这篇论文中所讨论的那个PaddlePaddle。

PaddleEDL的设计与实现

1.让Kubernetes支持定制的灵活调度机制

1)配置文件

Kubernetes本身支持定制的资源管理机制。用户可以提交定制的资源声明文件和控制器文件，以实现某些Pods的灵活调度。以下图为例，这个training_job.yaml保证控制器会自动监管pservers，并保证它们的数量在最小实例和最大实例之间。

在Kubernetes集群上，这个定制的资源可以通过kube CTL create-f training _ job . YAML命令获得。接下来，我们需要一个定制的trainingjobcontroller来调度这个资源。

定制的培训作业控制器在Pod中运行，对集群资源有统一的理解。它通过Kubernetes API监控和调度集群资源。下图是培训作业控制器配置文件的示例。

在Kubernetes集群上，这个定制的资源管理Pod可以通过ku bectl create-f training _ job _ controller . YAML命令启动。

2)控制程序的实施

目前有两种方法可以在Kubernetes中实现上面提到的定制资源。一个是自定义资源定义(CRD)，由库本内特公司1.7版引入。另一个是第三方资源(TRP)，它是从Kubernets版本引入的，在1.8版本中被否决，在1.9版本中不再被支持。PaddlePaddle项目现在使用Kubernetes版，所以实现了TRP模式，未来还会集成CRD模式。

目前，PaddlePaddle假设只有一个训练作业控制器在运行。(后续工作可能会考虑多个控制器的操作，比如按照一定的领导选择机制管理多个控制器)

当前培训作业控制器根据以下逻辑管理资源:

灵活调度算法

PaddlePaddle根据定制资源的配置文件(training_job.yaml)判断一个作业是否需要灵活调度，判断标准为min-instance =/max-instance of trainer和pserver。(目前PaddlePaddle只支持教练机的灵活调度，不支持pserver的灵活调度。)

集群中图形处理器的调度

控制器知道集群中有多少个GPU，当前有多少个空闲GPU，并尝试将所有空闲GPU分配给当前训练任务。PaddlePaddle为需要GPU的训练任务定义了一个“完成分数”，这个分数的范围是[0，1]。PaddlePaddle会优先分配GPU资源给满意度分数最低的训练任务。如果分数相同，优先考虑GPU需求，CPU需求，内存需求。如果一个训练任务的GPU最小实例不满足(除非cur-instance=min-instance)，PaddlePaddle会取出满意度最高的训练任务中的GPU资源，分配给它。如果度分值最高的训练任务为cur-instance=min-instance，则整个集群将不再执行新的训练任务，新的任务需要等待。

集群中中央处理器的调度

CPU资源的分配和GPU一样。控制器知道集群中有多少CPU和内存以及它们的负载情况；同时也知道训练任务的CPU要求。同样，CPU资源也是根据满意度评分来分配的。

具体调度实现细节见https://github . com/PaddlePaddle/cloud/tree/develop/go/controller。

2.让PaddlePaddle支持容错

本文讨论了PaddlePaddle的容错机制。原则上，在分布式训练任务中，如果主进程或所有参数服务进程都死了，整个训练任务会在一段时间后由Kubernetes停止并重新启动。否则，如果不是所有的具体训练过程都死了，整个训练任务就继续。让我们看看PaddlePaddle的错误恢复机制。

PaddlePaddle使用etcd记录训练过程的状态。Etcd是一个高度可靠的分布式键值存储，训练过程会定期将自己的状态写入etcd，必要时会利用这些信息恢复训练过程。具体流程如下:

主进程

当主进程由Kubernetes启动时，它会执行以下操作:

1.从etcd获取唯一的主锁，以避免多个主实例的存在

2.检查etcd中是否有任务队列。如果不存在，则创建一个新的任务队列；否则，获取此任务队列中的信息

3.把自己的ip地址写入etcd中的key /master/addr，方便后面的训练过程和自己交流

4.在端口监视器中打开培训过程的任务要求。如果您从培训过程中收到任务请求，请从任务队列中取出任务并分配它，然后更新任务队列。

如果主进程因为任何原因死亡，Kubernetes会重启，从重启到获取etcd信息，再到获取训练进程的任务，一般需要几分钟。

培训过程

当训练过程由Kubernetes启动时，它执行以下操作:

1.检查etcd中包含的参数服务前缀/ps/以获取参数服务进程的当前数量，并等待直到该数量满足配置文件中的要求

2.从etcd的/master/addr键获取主进程地址

3.发起任务请求以掌握并根据任务启动培训计划

训练过程结束后，Kubernetes会重新启动，新的过程会重复上述工作，直到新的训练开始。

参数服务流程

当参数服务过程由Kubernetes启动时，它执行以下操作:

1.从etcd /ps_desired中读取培训任务所需的参数服务流程数

2.在ETCD/PS/

在etcd中创建这个条目作为它自己的id。(如下图所示)

3.参数服务过程将从其相应的etcd路径中找到现有的训练结果参数，并将其读入

4.参数服务流程开始接收来自培训流程的请求。

划桨EDL和库贝弗洛

开源社区中另一个与Kubernetes紧密结合的深度学习系统自然是来自Google的TensorFlow。近日，谷歌开启了KubeFlow项目，旨在利用Kubernetes来调度Tensorflow，完成大规模的训练任务。

从设计理念和实施思路来看，桨EDL和库贝弗洛有很多相似之处。从开源的时候开始，他们是同时的。百度和谷歌的工程师对同一话题的理解几乎是一样的。但是两者也有一些区别。

首先，KubeFlow只支持张量流，而Paddle EDL只支持PaddlePaddle。而且都是靠底层的Kubernetes。Paddledl似乎更深入地集成了Kubernetes，比如使用可定制的资源分配，用定制的逻辑与Kubernetes API进行交互。而库贝弗洛似乎直接使用了库贝内特的一般功能。所以在灵活调度的功能上，PaddlePaddle采用了上面讨论的EDL模式，而KubeFlow现在是HPA模式。这是他们最大的区别。

此外，虽然两者都支持一般的Kubernetes+docker环境，但是KubeFlow和深度学习生态系统中Google的其他开源项目一样，都高度提倡在GCE上部署和Google云服务的深度集成。桨EDL不强调云供应商服务的部署。

由于Paddle EDL和KubeFlow只是开源项目，更多的细节仍在发展中，我相信开源社区会加深对它们的使用和理解。不过有一点可以肯定，Kubernetes和深度学习系统的结合会越来越紧密，一个更接近Kubernetes API，可以调度不同后端训练系统(不再绑定Tensorflow或者PaddlePaddle)的抽象项目可能正在酝酿中。