PaddlePaddle Fluid：Kubernetes 上的彈性深度學習

編者按：今天的博文是百度深度學習團隊和 CoreOS etcd 團隊聯合發表的。

PaddlePaddle Fluid：Kubernetes 上的彈性深度學習

兩個開源社群——源自百度的深度學習框架 PaddlePaddle 和最著名的容器化應用排程器 Kubernetes®——宣佈在 PaddlePaddle 新版本（代號 Fluid）中推出彈性深度學習 (EDL) 功能。

Fluid EDL 包括一個 Kubernetes 控制器，即 PaddlePaddle 自動擴縮器，它根據叢集中閒置硬體資源更改分散式作業的程序數量，以及 PaddlePaddle 設計文件中描述的新容錯架構 PaddlePaddle 設計文件。

工業深度學習需要大量的計算能力。研究實驗室和公司通常會構建由 SLURM、MPI 或 SGE 管理的 GPU 叢集。這些叢集要麼在提交的作業所需的資源少於閒置資源時執行該作業，要麼讓作業掛起一段不可預測的長久時間。這種方法有其缺點：在一個擁有 99 個可用節點，而提交的作業需要 100 個節點的示例中，該作業必須等待而不能使用任何可用節點。Fluid 與 Kubernetes 配合，為彈性深度學習作業提供支援，這些作業通常缺乏最佳資源，透過儘早暴露潛在的演算法問題。

另一個挑戰是，工業使用者傾向於將深度學習作業作為完整資料管道（包括 Web 伺服器和日誌收集器）的一個子階段來執行。這種通用叢集需要基於優先順序的彈性排程。這使得在 Web 流量高峰期，Web 伺服器作業可以執行更多的程序，而深度學習作業可以執行更少的程序；當 Web 流量較低時，則優先進行深度學習。Fluid 與 Kubernetes 的 API 伺服器通訊，以瞭解全域性情況並協調與各種作業相關的程序數量。

在這兩種情況下，PaddlePaddle 作業都能夠容忍程序的增減。我們透過實施新設計來實現這一點，該設計在舊的 PaddlePaddle 架構（如之前部落格文章中所述）的基礎上引入了一個主程序。在新設計中，只要作業中還剩三個程序，它就會繼續執行。在所有程序都被終止的極端情況下，作業可以恢復並繼續。

我們測試了 Fluid EDL 的兩個用例：1) Kubernetes 叢集僅執行 PaddlePaddle 作業；2) 叢集同時執行 PaddlePaddle 和 Nginx 作業。

在第一個測試中，我們以 10 秒的間隔一個接一個地啟動了多達 20 個 PaddlePaddle 作業。每個作業有 60 個訓練器和 10 個引數伺服器程序，並將持續數小時。我們重複了實驗 20 次：10 次關閉 FluidEDL，10 次開啟 FluidEDL。在圖 1 中，實線對應前 10 次實驗，虛線對應其餘實驗。在圖的上半部分，我們看到在沒有 EDL 的情況下，待處理作業的數量單調遞增。然而，當啟用 EDL 時，資源被均勻分配給所有作業。Fluid EDL 終止一些現有程序，以便為新作業和稍後進入的作業騰出空間。在這兩種情況下，叢集的利用率相等（見圖下半部分）。

| | | 圖 1. Fluid EDL 在作業之間均勻分配資源。
|

在第二個測試中，每個實驗執行 400 個 Nginx Pod，這些 Pod 的優先順序高於六個 PaddlePaddle 作業。最初，每個 PaddlePaddle 作業有 15 個訓練器和 10 個引數伺服器。我們每 90 秒殺死 100 個 Nginx Pod，直到剩下 100 個，然後我們開始每 90 秒增加 100 個 Nginx 作業。圖 2 的上半部分展示了這個過程。圖的中間顯示，Fluid EDL 透過減少 Nginx Pod 自動啟動了一些 PaddlePaddle 程序，然後透過增加 Nginx Pod 殺死了 PaddlePaddle 程序。結果是，叢集保持了大約 90% 的利用率，如圖底部所示。當 Fluid EDL 關閉時，沒有 PaddlePaddle 程序自動增加，並且利用率隨著 Nginx Pod 數量的變化而波動。

| | | 圖 2. Fluid 隨著 Nginx 程序的變化而改變 PaddlePaddle 程序。 |

我們將繼續開發 FluidEDL，並歡迎提出意見和貢獻。請訪問 PaddlePaddle 倉庫，您可以在其中找到設計文件、簡單教程和實驗細節。

• ←上一篇
• 下一篇→