深入解讀 PaddlePaddle EDL

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

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

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

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

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

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

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

1）配置文件

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

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

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

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

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

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

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

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

彈性調(diào)度算法

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

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

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

2.讓PaddlePaddle支持容錯

這里討論PaddlePaddle的容錯機制。原則上，在一個分布式訓(xùn)練任務(wù)里，如果master進程或者所 有的參數(shù)服務(wù)進程都死掉了，那么整個訓(xùn)練任務(wù)會被停掉，過一段時間被Kubernetes整個重啟。 否則如果具體訓(xùn)練進程沒有都死掉，則整個訓(xùn)練任務(wù)繼續(xù)。我們來看看PaddlePaddle的錯誤恢復(fù)機制。

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

Master進程

當(dāng)master進程被Kubernetes啟動時，它進行如下操作:

1. 從etcd中取一個唯一的master lock，以此避免多個master實例存在

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

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

4. 開端口監(jiān)聽訓(xùn)練進程的任務(wù)需求，如果收到來自訓(xùn)練進程的任務(wù)請求，從任務(wù)隊列中取任務(wù)分配之，并且更新任務(wù)隊列。

如果master進程因為任何原因死掉了，Kubernetes會將它重啟，從被重啟到獲取etcd的信息，獲取訓(xùn)練進程的任務(wù)，這個過程一般是幾分鐘。

訓(xùn)練進程

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

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

2. 從etcd的/master/addr key中獲取master進程地址

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

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

參數(shù)服務(wù)進程

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

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

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

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

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

4. 參數(shù)服務(wù)進程開始接收來自訓(xùn)練進程的請求。

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

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

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

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

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