PaddlePaddle 是 2016 年 8 月底百度開源的深度學習平臺，并且在短時間內迅速成為引發全球開發熱度，并且成為Github Pull Request 數量增速***的開源深度學習平臺。

PaddlePaddle 的迭代速度非?？欤瑫r也廣受社區的關注。剛開源的時候，PaddlePaddle 的設計思想是基于Layer的設計。后來推出了“v2”和“Fluid”兩次迭代：其中 v2增加了 operators 的概念，把 layers “打碎”成更細粒度的 operators，同時支持更復雜的網絡拓撲“圖”；Fluid 類似 PyTorch，但是不依賴 Python 的控制流（if-else、for等），而是提供自己的解釋器甚至編譯器，因此不受限于 Python 的執行速度。

我們今天就從PaddlePaddleFluid講起，隨后講述為了能更方便利用集群而提供的在瀏覽器端訓練的PaddlePaddleCloud，也著重講解集群訓練的原理、配置、和實驗結果，也就是PaddlePaddleEDL部分。***，講解PaddlePaddleVisualDL，這個非常強大的訓練日志解析和可視化工具。

PaddlePaddleFluid

PaddlePaddleFluid提供類似于高級語言中的控制流結構（例如while 、 if 、if-else、 for等），不僅能利用編譯優化技術保證計算性能，提升使用者的開發效率。

PaddlePaddleFluid 的設計思路非常領先，不再沿用層（layer）結構和操作（operator）結構的模式。也就是說不再有“模型”的概念，也就不再有“圖”（graph of operators）或者“串”（sequence of layers）。而只有“程序”的概念。同時，程序是可以導出一個圖的，從程序中可以導出成 ONNX 文件格式的模型。

深度學習基礎架構是最快速發展的技術之一，在四年之內，已經發明了三代技術。從下表可以看出，深度學習技術架構設計的方向正是逐漸擺脫模型的。

基于Python語言強大的生態，PyTorch 和 Eager Execution 中的控制流都是用的 Python，但面臨的一個瓶頸是Python 執行速度慢且難以提速。解決 PyTorch 和 Eager Execution 程序的執行速度受限于 Python 的執行速度的問題，Fluid有一個比 PyTorch 和 Eager Execution 更激進的技術思路。在Fluid的設計上，執行會把編寫的Python 程序輸出成一個 protobuf message，隨后調用 Fluid 解釋器（而不是 Python 解釋器）來解釋執行這個 protobuf message。Fluid 解釋器極大地加快了執行圖的速度。同時，在編譯執行的方式上 ，通過寫一個 transpiler 把 protobuf message翻譯成 C++ 程序，然后用 nvcc、icc、gcc 編譯成二進制代碼，可以直接運行在服務器和手機上。

PaddlePaddleCloud

PaddlePaddle 有一個 Web-based IDE，支持使用者在瀏覽器用 JupyterNotebook 編程來開發 AI 應用，隨后可以把程序發送到云端（Kubernetes 集群上）調試或者運行，程序運行時的輸出會實時地顯示在瀏覽器里。這樣使用者就不需要在個人電腦和集群等多個編程環境之間切換并且維護多個環境的版本和配置的一致性，極大地提升了工作效率。

PaddlePaddleEDL

PaddlePaddle EDL 對標的是 Google KubeFlow。PaddlePaddle EDL通過與 Kubernetes 合作來實現彈性作業調度，是全球***支持彈性作業調度的開源 AI 云解決方案。

盡管現在很多深度學習應用用一個幾臺機器的小集群就可以解決，但是 隨著數據量的增加和AI應用場景的不斷擴大，例如Web scaled 應用（廣告、搜索、推薦等），以及通過傳感器采集海量數據的無人車，都需要大規模深度學習計算能力的。

這里主要為了解決深度學習面臨的兩大挑戰。其一是需要大量的計算能力。研究室和公司經常構建由SLURM，MPI或SGE管理的GPU集群。這些集群要么運行一個提交的作業（假定它需要的比閑置的資源要少）或者將作業掛起一段難以預估的時間。但是這種方法有個缺點：在有99個可用節點和一個需要100個提交作業的任務時，作業必須等待而不能運行。

PaddlePaddle EDL彈性調度體現在可以空閑的時候一個訓練作業多用一些資源，忙碌的時候少用一些，但是資源的變化并不會導致作業失敗；這是優于KubeFlow的特點之一。同時，EDL也彈性調度其他作業（比如 Nginx、MySQL 等），從而極大地提升集群總體利用率。^[2]這樣在公有云和私有云上的推廣和部署時，就很容易節省幾倍的機器，為公司一年節省的計算成本可以高達百萬、甚至數百萬美元。

另一個挑戰是，工業用戶傾向于將深度學習作業作為完整數據管道的子集階段，例如日志采集器等。這種通用集群需要基于優先級的彈性調度。比如網絡開銷較高的時間段內深度學習任務少運行，在網絡流量較低時優先進行深度學習任務。這就需要了解全局的情況，并協調與各種工作有關的進程的數量。

PaddlePaddleEDL的測試實驗

面對上述這兩種挑戰，PaddlePaddle作業都可以輕松應對進程數量忽高忽低的變化。這里有Fluid EDL的兩種測試用例：

1. Kubernetes集群只運行PaddlePaddle作業;
2. 集群運行PaddlePaddle和Nginx作業。

在***個測試中，我們開始了20個PaddlePaddle作業，間隔10秒。每個作業有60個trainers和10個參數服務進程，并將持續數小時。我們重復實驗20次：關閉Fluid EDL 10次，打開Fluid EDL 10次。在下圖中，實線對應于前10個實驗，其余的是虛線。在圖的上半部分，我們看到未處理作業的數量在沒有EDL的情況下單調遞增。但是，當EDL打開時，資源將平均分配給所有作業。Fluid EDL殺死了一些現有的進程，為新的其他任務騰出空間，并在晚些時候任務開始運行。在這兩種情況下，集群都被平等利用（見圖的下半部分）。

在第二個測試中，每個實驗都運行了400個Nginx Pods，其優先級高于6個PaddlePaddle作業。最初，每個PaddlePaddle工作有15個trainers和10個參數服務。我們每90秒殺死100個Nginx Pods，直到剩下100個，然后我們開始將Nginx工作的數量每90秒增加100個。下圖的上半部分顯示了這個過程。圖中的中間顯示，Fluid EDL通過減少Nginx Pods來自動啟動一些PaddlePaddle進程，并在稍后增加Nginx Pods來殺死PaddlePaddle進程。結果，該集群維持在90％左右的利用率，如圖所示。當Fluid EDL被關閉時，沒有PaddlePaddle進程自動增加，并且利用率隨著Nginx Pods數量的變化而波動。

PaddlePaddleEDL的設計和實現

那上面這種深度學習服務和其它云端服務共享計算資源的過程，以及各個任務的優先級動態地調整和伸縮的過程，從而充分地利用集群CPU/GPU是如何實現的呢？

EDL和HPA

Horizontal Pod Autoscaling （HPA）是Kubernetes提供的一種彈性調度機制。它的設計出發點是通過公平分配計算資源給某一個單一的計算任務中的各個Pod來實現分布式系統資源針對單一任務的***化利用。但我們的訓練任務可能多種多樣（語音、圖像等）、部署時間有先有后，對資源的需求也不通，因此我們希望這種彈性調度機制能對每一種訓練任務所需的系統資源有個全局的了解，然后按需分配。但目前HPA controller還沒有實現。

同時，HPA的彈性調度是針對同種類型的計算任務（homogenous computing task）下的 Pods。但深度學習系統里的計算節點和參數服務器往往是在不同類型的Pods里 的。

上述特有的需求導致使用Kubernetes的時候需要有特定的彈性調度解決方案， 而不能直接采用HPA。因此更好的解決方案是PaddlePaddle EDL。

PaddlePaddleEDL 的具體設計和實現

1.讓Kubernetes支持定制的彈性調度機制

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

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

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

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

2.控制程序的實現

上面提到的定制化資源在Kubernetes里面目前有兩種實現方式。一種是 Custom Resource Definition (CRD) ，由Kubernetes 1.7版本引入;另一種是 Third Party Resource (TRP)。 PaddlePaddle項目現在用的是Kubernetes 1.6版本，所以實現的是TRP模式，今后將整合CRD模式。

當前PaddlePaddle假設只有一個單獨的training job controller在運行。當前的training job controller依照下面的邏輯管理資源:

3.彈性調度算法

PaddlePaddle根據定制資源的配置文件（training_job.yaml）來判斷某個job需不需要彈性調度， 而判斷的標準是trainer和pserver的min-instance =/ max-instance。

集群中GPU的調度

controller知道集群中全部GPU個數，以及當前閑置的GPU的個數，并試圖把閑置的GPU全部分配給當前訓練任務。PaddlePaddle給需求GPU的訓練任務定義一個“滿足程度”的評分（fulfillment score），此評分的范圍是[0，1]。PaddlePaddle會優先分配GPU資源給滿足程度評分***的訓練任務。如果有分數相同的情況，則分別優先考慮GPU需求數，CPU需求數，內存需求數。如果有某個訓練任務的GPU min-instance沒有滿足（除非cur-instance=min-instance），那么PaddlePaddle會把一個滿足程度***分的訓練任務里的GPU資源拿出來分給它。如果滿足程度分數***的訓練任務cur-instance=min-instance，則整個集群不再執行新的訓練任務，新來的任務需等待。

集群中CPU的調度

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

PaddlePaddle容錯機制

這里討論PaddlePaddle的容錯機制。在一個分布式訓練任務里，如果master進程或者所有的參數服務進程都死掉了，那么整個訓練任務會被停掉，過一段時間被Kubernetes整個重啟。如果具體訓練進程沒有都死掉，則整個訓練任務繼續。

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

當master進程被Kubernetes啟動時，它進行如下操作:

1. 從etcd中取一個唯一的master lock，以此避免多個master實例存在
2. 查看etcd中是否存在任務隊列。如果不存在，則新建一個任務隊列;否則得到這個任務隊列中的信息
3. 把自身的ip地址寫進etcd中/master/addr 這個key中，便于后來的訓練進程和自己通信
4. 開端口監聽訓練進程的任務需求，如果收到來自訓練進程的任務請求，從任務隊列中取任務分配之，并且更新任務隊列。

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

訓練進程

當訓練進程被Kubernetes啟動時，它進行如下操作:

1. 查看etcd中包含參數服務前綴 /ps/ 獲取當前參數服務進程的數量并等待，直到該數量達到配置文件中的要求
2. 從etcd的/master/addr key中獲取master進程地址
3. 向master發起任務請求，根據任務開始訓練程序

當訓練進程死掉之后，Kubernetes會將它重啟，新起來的進程會重復上述工作直到開始新的訓練工作。

參數服務進程

當參數服務進程被Kubernetes啟動時，它進行如下操作:

1. 從etcd /ps_desired中讀取訓練任務所需求的參數服務進程個數
2. 在etcd /ps/<index> （/ps/0, /ps/1, ...）里找一個小于所需進程數里***的還不存在的id，并在etcd里創建這個entry，以此作為自身的id。（如下圖）

當第三個參數服務器加入時：

3. 參數服務進程會從自身對應的etcd path中找到已有的訓練結果參數并且將它讀入

4. 參數服務進程開始接收來自訓練進程的請求。

PaddlePaddle的可視化—PaddlePaddleVisualDL

PaddlePaddleVisualDL是PaddlePaddle自帶的一個強大的可視化工具，也是一個Web應用程序套件。PaddlePaddleVisualDL目前支持4種可視化，即SCALARS、IMAGES、GRAPHS、HISTOGRAMS。這4種可視化的主要功能如下。

● SCALARS：展示訓練過程中的準確率、損失值、權重/偏置的變化情況。

● IMAGES：展示訓練過程中記錄的圖像。

● GRAPHS：展示模型的數據流圖，以及訓練在各個設備上消耗的內存和時間。

● HISTOGRAMS：展示訓練過程中記錄的數據的柱狀圖。

PaddlePaddleVisualDL通過運行一個本地服務器，來監聽8080端口。在瀏覽器發出請求時，分析訓練時記錄的數據，繪制訓練過程中的圖像。而且VisualDL 兼容 ONNX, 通過與 python SDK的結合，VisualDL可以兼容包括 PaddlePaddle, pytorch, mxnet, Caffe2 在內的大部分主流DNN平臺。而Tensorboard目前僅適用于Tensorflow、Pytorch、MXNet等。

PaddlePaddleVisualDL的可視化界面如下圖所示。

VisualDL的使用

VisualDL的使用方式非常簡單，只需要下面三個過程：

VisualDL的特性

VisualDL的特性主要有下面4點：

支持Scalar打點折線圖展示，方便觀察訓練整體趨勢

支持Image查看數據樣本的質量和訓練中間結果

支持Histogram查看參數分布展示和變化趨勢

支持Graph查看深度神經網絡的模型結構

總結

隨著PaddlePaddle新特性的不斷增加，相信在科研和使用中能給廣大使用者帶來很多幫助。這里從PaddlePaddleFluid講起，隨后講述為了能更方便利用集群而提供的在瀏覽器端訓練的PaddlePaddleCloud，也著重講解集群訓練的原理、配置、和實驗結果，也就是PaddlePaddleEDL部分。***，講解PaddlePaddleVisualDL，這個非常強大的訓練日志解析和可視化工具。