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

編者註：今天的文章是百度深度學習團隊和 CoreOS etcd 團隊的聯合文章

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

兩個開源社群—PaddlePaddle，源自百度的深度學習框架，以及 Kubernetes®，最著名的容器化應用程式排程器—正在宣布 PaddlePaddle 新版本 Fluid 中的彈性深度學習 (EDL) 功能。

Fluid EDL 包括一個 Kubernetes 控制器、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。在圖一中，實線對應於前 10 個實驗，虛線對應於其餘實驗。在圖的上半部分，我們看到在沒有 EDL 的情況下，掛起的任務數量單調遞增。但是，當 EDL 開啟時，資源會均勻分配給所有任務。Fluid EDL 終止了一些現有的進程，為新任務和稍後進入的任務騰出空間。在這兩種情況下，叢集都被同等地利用（見圖的下半部分）。

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

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

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

我們將繼續致力於 FluidEDL，並歡迎評論和貢獻。請訪問 PaddlePaddle repo，您可以在其中找到 設計文件、簡單教程 和 實驗細節。

• ←上一篇
下一篇→