新智元專欄

【新智元指南】百度和CoreOS聯(lián)合開發(fā)的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聯(lián)合開發(fā)的Paddle Paddle Elastic Deep Learning(EDL)技術。實驗表明，該技術可以將集群的利用率提高到接近100%。要知道一般基于HPC的深度學習集群利用率往往不到10%。而且集群的成本很高。這項技術可以使投資獲得多重收益，每年可以減少公司數(shù)百萬美元的計算投資，從而吸引在人工智能領域苦苦掙扎的團隊。

遺憾的是，以上很短。為了深入了解PaddlePaddle EDL，我調查了設計文檔和源代碼，采訪了EDL的主設計師王毅，并在游樂場的集群上部署了EDL。我把我的探索寫成了三篇文章

1.對EDL的深度解讀

2.EDL工業(yè)園區(qū)建設

3.EDL和無人駕駛技術

本文是第一篇。

一般云環(huán)境下的機器學習訓練任務包括幾個主進程，一些參數(shù)服務器進程，更多的訓練進程。這些流程都在云機器集群中運行，有時需要與其他培訓任務共享計算資源，經常需要與其他云服務(如web服務)共享資源。理想狀態(tài)是機器學習訓練系統(tǒng)知道根據(jù)集群資源的使用情況和每個任務的優(yōu)先級動態(tài)調整參數(shù)服務進程和訓練進程的數(shù)量，從而充分利用集群CPU/GPU。這是彈性深度學習(EDL)系統(tǒng)的設計目標。

EDL和HPA

水平Pod自動縮放(HPA)是由Kubernetes提供的一種靈活的調度機制。它的出發(fā)點是通過在單個計算任務中向每個Pod公平分配計算資源，實現(xiàn)單個任務分布式系統(tǒng)資源的優(yōu)化利用。在“訓練深度學習模型”的場景中，“單個計算任務”可以是訓練用于識別圖像中的對象的模型，而另一個“單個訓練任務”可以是訓練語音識別系統(tǒng)。這兩個培訓任務需要部署在同一個集群中，部署時間不同，資源要求也不同。理想情況下，自動縮放控制器對每個這樣的訓練任務所需的系統(tǒng)資源有全局理解，然后根據(jù)需要分配資源。而HPA控制器對不同的訓練任務并沒有這樣的全局理解。

另一方面，HPA的靈活調度是針對同一類型計算任務下的Pods。然而，深度學習系統(tǒng)中的訓練過程和參數(shù)服務器往往在不同類型的Pods中。我們想要來自autoscale的不同種類的播客。這些深度學習培訓系統(tǒng)的獨特要求導致在使用Kubernetes時需要特定的靈活調度解決方案，而不是直接采用HPA。而這個具體的解決方案就是EDL在這篇論文中所討論的那個PaddlePaddle。

PaddleEDL的設計與實現(xiàn)

1.讓Kubernetes支持定制的靈活調度機制

1)配置文件

Kubernetes本身支持定制的資源管理機制。用戶可以提交定制的資源聲明文件和控制器文件，以實現(xiàn)某些Pods的靈活調度。以下圖為例，這個training_job.yaml保證控制器會自動監(jiān)管pservers，并保證它們的數(shù)量在最小實例和最大實例之間。

在Kubernetes集群上，這個定制的資源可以通過kube CTL create-f training _ job . YAML命令獲得。接下來，我們需要一個定制的trainingjobcontroller來調度這個資源。

定制的培訓作業(yè)控制器在Pod中運行，對集群資源有統(tǒng)一的理解。它通過Kubernetes API監(jiān)控和調度集群資源。下圖是培訓作業(yè)控制器配置文件的示例。

在Kubernetes集群上，這個定制的資源管理Pod可以通過ku bectl create-f training _ job _ controller . YAML命令啟動。

2)控制程序的實施

目前有兩種方法可以在Kubernetes中實現(xiàn)上面提到的定制資源。一個是自定義資源定義(CRD)，由庫本內特公司1.7版引入。另一個是第三方資源(TRP)，它是從Kubernets版本引入的，在1.8版本中被否決，在1.9版本中不再被支持。PaddlePaddle項目現(xiàn)在使用Kubernetes版，所以實現(xiàn)了TRP模式，未來還會集成CRD模式。

目前，PaddlePaddle假設只有一個訓練作業(yè)控制器在運行。(后續(xù)工作可能會考慮多個控制器的操作，比如按照一定的領導選擇機制管理多個控制器)

當前培訓作業(yè)控制器根據(jù)以下邏輯管理資源:

靈活調度算法

PaddlePaddle根據(jù)定制資源的配置文件(training_job.yaml)判斷一個作業(yè)是否需要靈活調度，判斷標準為min-instance =/max-instance of trainer和pserver。(目前PaddlePaddle只支持教練機的靈活調度，不支持pserver的靈活調度。)

集群中圖形處理器的調度

控制器知道集群中有多少個GPU，當前有多少個空閑GPU，并嘗試將所有空閑GPU分配給當前訓練任務。PaddlePaddle為需要GPU的訓練任務定義了一個“完成分數(shù)”，這個分數(shù)的范圍是[0，1]。PaddlePaddle會優(yōu)先分配GPU資源給滿意度分數(shù)最低的訓練任務。如果分數(shù)相同，優(yōu)先考慮GPU需求，CPU需求，內存需求。如果一個訓練任務的GPU最小實例不滿足(除非cur-instance=min-instance)，PaddlePaddle會取出滿意度最高的訓練任務中的GPU資源，分配給它。如果度分值最高的訓練任務為cur-instance=min-instance，則整個集群將不再執(zhí)行新的訓練任務，新的任務需要等待。

集群中中央處理器的調度

CPU資源的分配和GPU一樣。控制器知道集群中有多少CPU和內存以及它們的負載情況；同時也知道訓練任務的CPU要求。同樣，CPU資源也是根據(jù)滿意度評分來分配的。

具體調度實現(xiàn)細節(jié)見https://github . com/PaddlePaddle/cloud/tree/develop/go/controller。

2.讓PaddlePaddle支持容錯

本文討論了PaddlePaddle的容錯機制。原則上，在分布式訓練任務中，如果主進程或所有參數(shù)服務進程都死了，整個訓練任務會在一段時間后由Kubernetes停止并重新啟動。否則，如果不是所有的具體訓練過程都死了，整個訓練任務就繼續(xù)。讓我們看看PaddlePaddle的錯誤恢復機制。

PaddlePaddle使用etcd記錄訓練過程的狀態(tài)。Etcd是一個高度可靠的分布式鍵值存儲，訓練過程會定期將自己的狀態(tài)寫入etcd，必要時會利用這些信息恢復訓練過程。具體流程如下:

主進程

當主進程由Kubernetes啟動時，它會執(zhí)行以下操作:

1.從etcd獲取唯一的主鎖，以避免多個主實例的存在

2.檢查etcd中是否有任務隊列。如果不存在，則創(chuàng)建一個新的任務隊列；否則，獲取此任務隊列中的信息

3.把自己的ip地址寫入etcd中的key /master/addr，方便后面的訓練過程和自己交流

4.在端口監(jiān)視器中打開培訓過程的任務要求。如果您從培訓過程中收到任務請求，請從任務隊列中取出任務并分配它，然后更新任務隊列。

如果主進程因為任何原因死亡，Kubernetes會重啟，從重啟到獲取etcd信息，再到獲取訓練進程的任務，一般需要幾分鐘。

培訓過程

當訓練過程由Kubernetes啟動時，它執(zhí)行以下操作:

1.檢查etcd中包含的參數(shù)服務前綴/ps/以獲取參數(shù)服務進程的當前數(shù)量，并等待直到該數(shù)量滿足配置文件中的要求

2.從etcd的/master/addr鍵獲取主進程地址

3.發(fā)起任務請求以掌握并根據(jù)任務啟動培訓計劃

訓練過程結束后，Kubernetes會重新啟動，新的過程會重復上述工作，直到新的訓練開始。

參數(shù)服務流程

當參數(shù)服務過程由Kubernetes啟動時，它執(zhí)行以下操作:

1.從etcd /ps_desired中讀取培訓任務所需的參數(shù)服務流程數(shù)

2.在ETCD/PS/

在etcd中創(chuàng)建這個條目作為它自己的id。(如下圖所示)

3.參數(shù)服務過程將從其相應的etcd路徑中找到現(xiàn)有的訓練結果參數(shù)，并將其讀入

4.參數(shù)服務流程開始接收來自培訓流程的請求。

劃槳EDL和庫貝弗洛

開源社區(qū)中另一個與Kubernetes緊密結合的深度學習系統(tǒng)自然是來自Google的TensorFlow。近日，谷歌開啟了KubeFlow項目，旨在利用Kubernetes來調度Tensorflow，完成大規(guī)模的訓練任務。

從設計理念和實施思路來看，槳EDL和庫貝弗洛有很多相似之處。從開源的時候開始，他們是同時的。百度和谷歌的工程師對同一話題的理解幾乎是一樣的。但是兩者也有一些區(qū)別。

首先，KubeFlow只支持張量流，而Paddle EDL只支持PaddlePaddle。而且都是靠底層的Kubernetes。Paddledl似乎更深入地集成了Kubernetes，比如使用可定制的資源分配，用定制的邏輯與Kubernetes API進行交互。而庫貝弗洛似乎直接使用了庫貝內特的一般功能。所以在靈活調度的功能上，PaddlePaddle采用了上面討論的EDL模式，而KubeFlow現(xiàn)在是HPA模式。這是他們最大的區(qū)別。

此外，雖然兩者都支持一般的Kubernetes+docker環(huán)境，但是KubeFlow和深度學習生態(tài)系統(tǒng)中Google的其他開源項目一樣，都高度提倡在GCE上部署和Google云服務的深度集成。槳EDL不強調云供應商服務的部署。

由于Paddle EDL和KubeFlow只是開源項目，更多的細節(jié)仍在發(fā)展中，我相信開源社區(qū)會加深對它們的使用和理解。不過有一點可以肯定，Kubernetes和深度學習系統(tǒng)的結合會越來越緊密，一個更接近Kubernetes API，可以調度不同后端訓練系統(tǒng)(不再綁定Tensorflow或者PaddlePaddle)的抽象項目可能正在醞釀中。