深入解讀 PaddlePaddle EDL

百度和 CoreOS 的聯(lián)合開(kāi)發(fā)的 PaddlePaddle Elastic Deep Learning(EDL)技術(shù)可以把一個(gè)機(jī)群的利用率提高到接近100%，而基于HPC的一般深度學(xué)習(xí)機(jī)群的使用率往往低于10%。本文作者調(diào)研了設(shè)計(jì)文檔和源碼，訪問(wèn)了EDL的主要設(shè)計(jì)者王益，并且在Playground的機(jī)群上部署了 EDL，以深度解讀PaddlePaddle Elastic Deep Learning技術(shù)。

最近看到 Kubernetes 官方博客上發(fā)表特邀文章，介紹了百度和 CoreOS 的聯(lián)合開(kāi)發(fā)的 PaddlePaddle Elastic Deep Learning(EDL)技術(shù)。文中試驗(yàn)表明這套技術(shù)可以把一個(gè)機(jī)群的利用率提高到接近100%。要知道基于HPC的一般深度學(xué)習(xí)機(jī)群的使用率往往低于10%。而機(jī)群成本是很高的。這樣讓一份投資收獲多倍效益的技術(shù)可能讓一家公司的計(jì)算投資每年減少數(shù)百萬(wàn)美元，很吸引在AI領(lǐng)域奮斗的團(tuán)隊(duì)。

可惜上文很簡(jiǎn)短。為了深入了解 PaddlePaddle EDL，我調(diào)研了設(shè)計(jì)文檔和源碼，訪問(wèn)了EDL的 主要設(shè)計(jì)者王益，并且在Playground的機(jī)群上部署了EDL。

一般云端的機(jī)器學(xué)習(xí)訓(xùn)練任務(wù)會(huì)包含幾個(gè)master進(jìn)程，一些參數(shù)服務(wù)(parameter server)進(jìn)程 ，和比較多的訓(xùn)練進(jìn)程(training process)。這些進(jìn)程全部運(yùn)行在云端機(jī)器集群里，有時(shí)需要和其它訓(xùn)練任務(wù)共享計(jì)算資源，經(jīng)常還需要和其它的云端服務(wù)(比如web服務(wù))共享資源。理想的狀態(tài)是機(jī)器學(xué)習(xí)訓(xùn)練系統(tǒng)知道根據(jù)集群資源使用情況和各個(gè)任務(wù)的優(yōu)先級(jí)動(dòng)態(tài)地調(diào)整參數(shù)服務(wù) 進(jìn)程和訓(xùn)練進(jìn)程的個(gè)數(shù)，從而達(dá)到充分地利用集群CPU/GPU的目的。而這正是Elastic Deep Learning (EDL) 系統(tǒng)的設(shè)計(jì)目標(biāo)。

Horizontal Pod Autoscaling (HPA)是Kubernetes提供的一種彈性調(diào)度機(jī)制。它的出發(fā)點(diǎn)是通過(guò)公平分配計(jì)算資源給某一個(gè)單一的計(jì)算任務(wù)中的各個(gè)Pod來(lái)實(shí)現(xiàn)分布式系統(tǒng)資源針對(duì)單一任務(wù)的最優(yōu)化利用。在“訓(xùn)練深度學(xué)習(xí)模型”這個(gè)場(chǎng)景下，“某一個(gè)單一的計(jì)算任務(wù)”可能是訓(xùn)練一個(gè)識(shí)別圖 像中物體的模型，而另一個(gè)“單一的訓(xùn)練任務(wù)”可能是訓(xùn)練一個(gè)語(yǔ)音識(shí)別系統(tǒng)。這兩個(gè)訓(xùn)練任務(wù)可 能都需要部署在同一個(gè)集群里，部署時(shí)間有先后，對(duì)資源的需求也有不同。理想的情況是 autoscaling controller對(duì)每一個(gè)這樣的訓(xùn)練任務(wù)所需的系統(tǒng)資源有一個(gè)全局的了解，然后按需分配 資源?？墒荋PA controller并沒(méi)有對(duì)不同訓(xùn)練任務(wù)有那樣一個(gè)全局了解。

另一方面，HPA的彈性調(diào)度是針對(duì)同種類(lèi)型的計(jì)算任務(wù)(homogenous computing task)下的 Pods。但是深度學(xué)習(xí)系統(tǒng)里的training process和parameter server往往是在不同類(lèi)型的Pods里 的。我們想要autoscale不同種類(lèi)的Pods。 這些深度學(xué)習(xí)訓(xùn)練系統(tǒng)特有的需求導(dǎo)致使用Kubernetes的時(shí)候需要有特定的彈性調(diào)度解決方案， 而不能直接采用HPA。而這套特定的解決方案就是本文討論的PaddlePaddle EDL。

1.讓Kubernetes支持定制的彈性調(diào)度機(jī)制

1）配置文件

Kubernetes本身就支持定制的資源管理機(jī)制。用戶可以通過(guò)提交定制的resource declaration file 和controller file來(lái)實(shí)現(xiàn)對(duì)某種Pods的彈性調(diào)度。以下圖為例，這個(gè)training_job.yaml保證了 controller會(huì)自動(dòng)監(jiān)管pservers，并且保證它們的數(shù)量在min-instance和max-instance之間。

在Kubernetes集群上，這個(gè)定制的資源可以通過(guò)kubectl create -f training_job.yaml 命令獲得。接下來(lái)，我們需要有個(gè)定制的trainingjobcontroller來(lái)調(diào)度這個(gè)資源。

定制的training job controller跑在一個(gè)Pod里，對(duì)集群資源有一個(gè)統(tǒng)一的了解，它通過(guò)Kubernetes API對(duì)集群資源起到監(jiān)控和調(diào)度的作用。下圖是training job controller配置文件的一個(gè)例子。

在Kubernetes集群上，這個(gè)定制的資源管理Pod可以通過(guò) kubectl create -f training_job_controller.yaml 命令啟動(dòng)。

2）控制程序的實(shí)現(xiàn)

上面提到的定制化資源在Kubernetes里面目前有兩種實(shí)現(xiàn)方式。一種是 Custom Resource Definition (CRD) ，由Kubernetes 1.7版本引入;另一種是 Third Party Resource (TRP) ，自Kuberenets 1.2版本引入，1.8版本中過(guò)時(shí)(deprecated)，1.9版本中將不再支持。 PaddlePaddle項(xiàng)目現(xiàn)在用的是Kubernetes 1.6版本，所以實(shí)現(xiàn)的是TRP模式，今后將整合CRD模 式。

當(dāng)前PaddlePaddle假設(shè)只有一個(gè)單獨(dú)的training job controller在運(yùn)行。(后續(xù)工作可能會(huì)考慮多個(gè) controller運(yùn)行的情況，比如根據(jù)某個(gè)leader selection機(jī)制來(lái)管理多個(gè)controller)

當(dāng)前的training job controller依照下面的邏輯管理資源:

彈性調(diào)度算法

PaddlePaddle根據(jù)定制資源的配置文件(training_job.yaml)來(lái)判斷某個(gè)job需不需要彈性調(diào)度， 而判斷的標(biāo)準(zhǔn)是trainer和pserver的min-instance =/ max-instance。(當(dāng)前PaddlePaddle只支持 trainer的彈性調(diào)度，還不支持pserver的彈性調(diào)度)

集群中GPU的調(diào)度

controller知道集群中一共有多少個(gè)GPU，當(dāng)前有多少個(gè)閑置的GPU，并試圖把閑置的GPU全部 分配給當(dāng)前的訓(xùn)練任務(wù)。PaddlePaddle給需求GPU的訓(xùn)練任務(wù)定義一個(gè)“滿足程度”的評(píng)分( fulfillment score)，此評(píng)分的范圍是[0，1]。PaddlePaddle會(huì)優(yōu)先分配GPU資源給滿足程度評(píng)分最低的訓(xùn)練任務(wù)。如果有分?jǐn)?shù)相同的情況，則分別優(yōu)先考慮GPU需求數(shù)，CPU需求數(shù)，內(nèi)存需求數(shù)。如果有某個(gè)訓(xùn)練任務(wù)的GPU min-instance沒(méi)有滿足(除非cur-instance=min-instance)，那么PaddlePaddle會(huì)把一個(gè)滿足程度最高分的訓(xùn)練任務(wù)里的GPU資源拿出來(lái)分給它。如果滿足程度分?jǐn)?shù)最高的訓(xùn)練任務(wù)cur-instance=min-instance，則整個(gè)集群不再執(zhí)行新的訓(xùn)練任務(wù)，新來(lái)的任務(wù)需等待。

集群中CPU的調(diào)度

CPU資源的分配和GPU思路相同。controller知道集群中一共有多少個(gè)CPU，內(nèi)存，它們的負(fù)載情況;同時(shí)也知道訓(xùn)練任務(wù)對(duì)CPU的需求。同樣的，CPU資源根據(jù)滿足程度評(píng)分被按需分配。

2.讓PaddlePaddle支持容錯(cuò)

這里討論P(yáng)addlePaddle的容錯(cuò)機(jī)制。原則上，在一個(gè)分布式訓(xùn)練任務(wù)里，如果master進(jìn)程或者所 有的參數(shù)服務(wù)進(jìn)程都死掉了，那么整個(gè)訓(xùn)練任務(wù)會(huì)被停掉，過(guò)一段時(shí)間被Kubernetes整個(gè)重啟。 否則如果具體訓(xùn)練進(jìn)程沒(méi)有都死掉，則整個(gè)訓(xùn)練任務(wù)繼續(xù)。我們來(lái)看看PaddlePaddle的錯(cuò)誤恢復(fù)機(jī)制。

PaddlePaddle用etcd來(lái)記錄訓(xùn)練進(jìn)程的狀態(tài)。etcd是高可靠性的分布式key-value存儲(chǔ)，訓(xùn)練進(jìn)程會(huì)定時(shí)把自身狀態(tài)寫(xiě)進(jìn)etcd，而這些信息將會(huì)在必要的時(shí)候用來(lái)恢復(fù)訓(xùn)練進(jìn)程。具體過(guò)程如下圖：

Master進(jìn)程

當(dāng)master進(jìn)程被Kubernetes啟動(dòng)時(shí)，它進(jìn)行如下操作:

1. 從etcd中取一個(gè)唯一的master lock，以此避免多個(gè)master實(shí)例存在

2. 查看etcd中是否存在任務(wù)隊(duì)列。如果不存在，則新建一個(gè)任務(wù)隊(duì)列;否則得到這個(gè)任務(wù)隊(duì)列中的信息

3. 把自身的ip地址寫(xiě)進(jìn)etcd中/master/addr 這個(gè)key中，便于后來(lái)的訓(xùn)練進(jìn)程和自己通信

4. 開(kāi)端口監(jiān)聽(tīng)訓(xùn)練進(jìn)程的任務(wù)需求，如果收到來(lái)自訓(xùn)練進(jìn)程的任務(wù)請(qǐng)求，從任務(wù)隊(duì)列中取任務(wù)分配之，并且更新任務(wù)隊(duì)列。

如果master進(jìn)程因?yàn)槿魏卧蛩赖袅?，Kubernetes會(huì)將它重啟，從被重啟到獲取etcd的信息，獲取訓(xùn)練進(jìn)程的任務(wù)，這個(gè)過(guò)程一般是幾分鐘。

訓(xùn)練進(jìn)程

當(dāng)訓(xùn)練進(jìn)程被Kubernetes啟動(dòng)時(shí)，它進(jìn)行如下操作:

1. 查看etcd中包含參數(shù)服務(wù)前綴 /ps/ 獲取當(dāng)前參數(shù)服務(wù)進(jìn)程的數(shù)量并等待，直到該數(shù)量達(dá)到配置文件中的要求

2. 從etcd的/master/addr key中獲取master進(jìn)程地址

3. 向master發(fā)起任務(wù)請(qǐng)求，根據(jù)任務(wù)開(kāi)始訓(xùn)練程序

當(dāng)訓(xùn)練進(jìn)程死掉之后，Kubernetes會(huì)將它重啟，新起來(lái)的進(jìn)程會(huì)重復(fù)上述工作直到開(kāi)始新的訓(xùn)練工作。

參數(shù)服務(wù)進(jìn)程

當(dāng)參數(shù)服務(wù)進(jìn)程被Kubernetes啟動(dòng)時(shí)，它進(jìn)行如下操作:

1. 從etcd /ps_desired中讀取訓(xùn)練任務(wù)所需求的參數(shù)服務(wù)進(jìn)程個(gè)數(shù)

2. 在etcd /ps/ (/ps/0, /ps/1, ...) 里找一個(gè)小于所需進(jìn)程數(shù)里最大的還不存在的id，并

在etcd里創(chuàng)建這個(gè)entry，以此作為自身的id。(如下圖所示)

3. 參數(shù)服務(wù)進(jìn)程會(huì)從自身對(duì)應(yīng)的etcd path中找到已有的訓(xùn)練結(jié)果參數(shù)并且將它讀入

4. 參數(shù)服務(wù)進(jìn)程開(kāi)始接收來(lái)自訓(xùn)練進(jìn)程的請(qǐng)求。

開(kāi)源社區(qū)中另一個(gè)和Kubernetes緊密結(jié)合的深度學(xué)習(xí)系統(tǒng)自然是和Kubernetes同樣來(lái)自Google 的TensorFlow。近期，Google開(kāi)源了KubeFlow項(xiàng)目，旨在利用Kubernetes調(diào)度Tensorflow，完成大規(guī)模訓(xùn)練任務(wù)。

從設(shè)計(jì)理念和實(shí)現(xiàn)思路來(lái)看，Paddle EDL和KubeFlow有非常多的相似之處。從開(kāi)源的時(shí)間來(lái)看 ，二者也是同一時(shí)段，百度和谷歌的工程師對(duì)同一主題的幾乎一樣的理解。不過(guò)二者的確存在一些差別。

首先，KubeFlow目前只支持Tensorflow，而Paddle EDL目前只支持PaddlePaddle。而它們底層都依托于Kubernetes。Paddle EDL似乎對(duì)Kubernetes的整合更深入一些，比如利用可定制的資源分配方式，和自定義邏輯與Kubernetes API交互。而KubeFlow似乎直接使用Kubernetes一般性的 功能。因此，在彈性調(diào)度這個(gè)功能上，PaddlePaddle采取的是前文討論的EDL方式，而 KubeFlow現(xiàn)在是HPA方式。這是二者最大的不同。

另外，雖然二者都支持一般的Kubernetes+docker環(huán)境，KubeFlow和Google在深度學(xué)習(xí)生態(tài)系 統(tǒng)中的其它開(kāi)源項(xiàng)目一樣，非常推崇在GCE上布署，深度整合Google云服務(wù)。而Paddle EDL并沒(méi)有強(qiáng)調(diào)布署云的供應(yīng)商服務(wù)。

由于Paddle EDL和KubeFlow都是剛剛開(kāi)源的項(xiàng)目，更多的細(xì)節(jié)還在演化當(dāng)中，我相信開(kāi)源社區(qū)對(duì)它們的使用和理解會(huì)不斷加深的。不過(guò)有一點(diǎn)可以肯定，Kubernetes和深度學(xué)習(xí)系統(tǒng)的結(jié)合將會(huì)越來(lái)越緊密，一個(gè)抽象層的，和Kubernetes API結(jié)合更緊密的，可調(diào)度不同后端訓(xùn)練系統(tǒng)(不 再綁定Tensorflow或者PaddlePaddle)的項(xiàng)目也許正在孕育中。