選自Kubernetes等參與：吳攀、李亞洲、蔣思源
2016 年 9 月，百度開源了深度學習框架 PaddlePaddle，今天，百度又宣布實現了這一框架和集群管理系統（cluster management system）Kubernetes 的兼容，從而使 PaddlePaddle 成為了迄今為止唯一一個官方支持 Kubernetes 的框架。
據百度研究官網介紹，這種兼容性將使得開發者可以很方便地在全球所有主要的雲服務提供商（包括百度雲和企業內部的集群（on-premise clusters））上訓練大型的模型。該項目是由百度和 CoreOS 聯合開發的；CoreOS 是 Kubernetes 的主要貢獻者之一。
開發者通常會將人工智慧程序與網絡服務、日誌收集器和數據處理器一起聯合部署在同一個通用的集群上，以實現高效的數據流程（data pipelines）。為了管理這個過程，開發者就會用到 Kubernetes 這樣的工具；Kubernetes 是現在最複雜精細的通用集群管理系統之一。通過使 PaddlePaddle 與 Kubernetes 兼容，開發者現在可以用它們開發高效的深度學習驅動的應用。
「使用 Kubernetes 這樣的框架，開發者再也不用擔心為了在一個標準雲平臺上配置和部署深度學習訓練系統而編寫不必要的代碼。」PaddlePaddle 項目技術負責人 Yi Wang 說，「這最終能幫助他們更快地將他們的項目落地。」
Kubernetes 可將 PaddlePaddle 中需要 GPU 的工作和需要其它資源（如大型存儲或磁碟 I/O 流通）的工作封裝到同一套物理計算機上，從而可以充分利用集群硬體。而且當白天存在許多活躍用戶時，它還會自動擴展其在線服務，而到了夜間用戶較少時它又會釋放出一些資源。
PaddlePaddle 是一個源於百度的易用的深度學習框架，已經在百度的許多產品和技術中得到了應用，其中包括搜索排序和機器翻譯。據介紹，該框架非常適合用於訓練循環神經網絡，從而使其可以高效地被應用在自然語言理解、語音和多媒體等應用中。百度聲稱，自去年 9 月開源之後，PaddlePaddle 已經成為了現在增長最快的深度學習框架之一。
關於在 Kubernetes 上運行 PaddlePaddle 的更多細節，可在下面的介紹文章中了解（下文作者為 Baidu Research 的 Yi Wang 和 CoreOS 的 Xiang Li）。
什麼是 PaddlePaddle
PaddlePaddle 是一個易於使用、高效、靈活和可擴展的深度學習平臺，該平臺最初是由百度在 2014 年為其產品應用深度學習而開發的。
現在已經使用 PaddlePaddle 的創新已經超過了 50 項，並支持包括搜尋引擎、在線廣告、Q＆A 和系統安全等 15 項百度產品。
2016 年 9 月，百度開源了 PaddlePaddle，並且很快就吸引了很多來自百度外的參與者。
為什麼要在 Kubernetes 上運行 PaddlePaddle
PaddlePaddle 是被工程師們設計成精簡且不依賴於計算基礎設備的深度學習平臺。用戶可以在 Hadoop、Spark、Mesos、Kubernetes 和其他平臺上運行它。我們對 Kubernetes 有很強烈的興趣，因為它的適應性、高效性等豐富的特點。
當我們將 PaddlePaddle 應用於百度的各種產品時，我們注意到 PaddlePaddle 的兩種主要用法——研究和產品。用於研究的數據並不會經常性地變動，重點是快速地實驗以達到預期的科學度量。而應用於產品的數據會經常性地變動，它通常來自網頁服務而產生的日誌信息。
一個成功的深度學習項目包括了研究和數據處理流程（pipeline）。因為有很多參數需要調整，許多工程師在整個項目的不同部分同時工作。
為了確保項目易於管理且能高效利用硬體資源，我們希望能將項目的所有部分運行在同一個基礎平臺之上。
這樣的平臺需要提供：
容錯性（fault-tolerance）。它應該將流程（pipeline）的每一個階段摘取為一個服務，並且這些服務包含了許多過程，這樣的冗餘能夠提供高流通量（high throughput）和魯棒性。自動擴展（auto-scaling）。在白天，通常有許多活躍用戶，因此平臺就需要能向外擴展其在線服務。而到了晚上，平臺就需要釋放一些資源進行深度學習試驗。工作封裝和隔離（job packing and isolation）。平臺需要能夠為 PaddlePaddle 訓練器過程（trainer process）分配要求的 GPU、需要大內存的網絡後端服務和需要磁碟吞吐量的 CephFS 過程，並且保證相同的節點充分利用其硬體資源。
我們想要的是一個能在同一個集群上運行深度學習系統、網頁伺服器（如 Nginx）、日誌收集器（如 fluentd）、分布式隊列服務（如 Kafka）、日誌加入器（log joiner）和使用 Storm、 Spark、Hadoop MapReduce 編寫的其他數據處理器的平臺。我們希望所有的工作（線上線下、產品和實驗）都能在同一個集群上運作，這樣我們才能充分利用集群，因為不同的工作需要不同的硬體資源。
我們選擇的是基於容器（container based）的解決方案，因為由虛擬機（VM）引入的總開銷與我們的高效、實用這一目標相矛盾。
基於我們對不同的基於容器（container based）解決方案的研究，Kubernetes 最符合我們的要求。
在 Kubernetes 上的分布式訓練
PaddlePaddle 本就支持分布式訓練，在 PaddlePaddle 集群中有兩個角色：參數伺服器（parameter server）和訓練器（trainer）。每個參數伺服器處理包含全局模型的一部分，每個訓練器有該模型的局部複製，並且使用它的局部數據更新該模型。
在訓練的過程中，訓練器將模型更新信息發送到參數伺服器，參數伺服器負責聚集這些更新，以便於訓練器能夠能夠與全局模型同步它們的本地複製版本。
圖 1：模型被劃分為兩個分片（shard），分別由兩個參數伺服器管理。
一些其他的方法使用一系列參數伺服器在多臺主機的 CPU 存儲空間中一起存儲一個非常大型的模型。但在實際中，我們通常沒有這麼大的模型，因為由於 GPU 的存儲限制，處理特別大的模型是效率低下的。在我們的配置中，多參數伺服器大部分是為了快速通信。假設只有一個參數伺服器處理與所有的訓練器一起工作，參數伺服器要聚集來自所有訓練器的梯度，這是一個瓶頸。在我們的經驗中，經實驗驗證的有效配置包括同樣數量的訓練器和參數伺服器。我們通常在同樣的節點上運行一對訓練器和參數伺服器。在下面的 Kubernetes 配置中，我們啟動了一個運行了 N 個 pod 的工作，其中每個 pod 中都有一個參數伺服器和一個訓練器。
yaml
apiVersion: batch/v1
kind: Job
metadata:
name: PaddlePaddle-cluster-job
spec:
parallelism: 3
completions: 3
template:
metadata:
name: PaddlePaddle-cluster-job
spec:
volumes:
- name: jobpath
hostPath:
path: /home/admin/efs
containers:
- name: trainer
image: your_repo/paddle:mypaddle
command: ["bin/bash", "-c", "/root/start.sh"]
env:
- name: JOB_NAME
value: paddle-cluster-job
- name: JOB_PATH
value: /home/jobpath
- name: JOB_NAMESPACE
value: default
volumeMounts:
- name: jobpath
mountPath: /home/jobpath
restartPolicy: Never
我們能從配置中看到，並行和實現都被設定為 3。所以該工作將同步啟動 3 個 PaddlePaddle pod，而且在所有的 3 個 pod 結束後運行的工作才會結束。
圖片 2：運行在 2 個節點上的 3 個 pod 的 Job A 和 1 個 pod 的 Job B
每個 pod 的入口是 start.sh。它從一個存儲服務下載數據，所以訓練器可以從 pod 本地的磁碟空間快速讀取。下載完成之後，其會運行一個 Python 腳本 start_paddle.py，該腳本會啟動一個參數伺服器，然後等待所有 pod 的參數伺服器都為使用做好準備，之後再啟動該 pod 中的訓練器過程。
這裡的等待是必需的，因為每個訓練器都需要與所有的參數伺服器進行通信（如圖 1）。Kubernetes API 使訓練器能夠檢查 pod 的狀態，所以該 Python 腳本可以等待，直到所有的參數伺服器的狀態都改為「running」，然後它才會觸發訓練過程。
目前，從數據分片（data shards）到 pods/trainers 的映射是靜態的。如果我們要運行 N 個訓練器，我們需要將數據分割成 N 個分片，並將每個數據分片靜態地分配給訓練器。同樣我們依賴於 Kubernetes API 來獲取工作中的 pods，因此我們可以將 pods / trainers 從 1 到 N 建立索引。第 i 個訓練器將讀取第 i 個數據分段。
訓練數據通常是在一個分布式文件系統上提供的。我們實際上在我們的企業內集群上使用了 CephFS，在 AWS 上使用了 Amazon Elastic File System。如果你對構建 Kubernetes 集群來運行分布式 PaddlePaddle 訓練工作感興趣，請參考這個教程：https://github.com/PaddlePaddle/Paddle/blob/develop/doc/howto/usage/k8s/k8s_aws_en.md
未來
我們正在努力讓 PaddlePaddle 能夠在 Kubernetes 上運行得更加順暢。
你可能已經注意到，當前的訓練器調度（trainer scheduling）完全依賴於基於靜態分區圖（static partition map）的 Kubernetes。這種方法開始是很簡單，但也可能會導致一些效率問題。
首先，緩慢或死亡的訓練器會終止整個工作。在初始部署之後就沒有什麼受控的優先權（preemption）或重新調度（rescheduling）了。
其次，其資源配置是靜態的。所以如果 Kubernetes 有比我們預計的更多的資源，那麼我們就必須手動修改其資源要求。這是一個非常繁重的工作，與我們的效率和實用的目標不一致。
為了解決上述問題，我們將添加一個理解 Kubernetes API 的 PaddlePaddle master，其可以動態地添加/移除資源量，並且可以以一種更加動態的方式為訓練器處理分片（shard）。該 PaddlePaddle master 使用 etcd 作為從分片到訓練器的動態映射的容錯存儲。因此，即使該 master 崩潰，該映射也不會丟失。Kubernetes 可以重啟該 master，然後該工作將會繼續運行。
另一個潛在的提升是更好的 PaddlePaddle 工作配置（job configuration）。我們的有相同數量的訓練器和參數伺服器的經驗大多數都收集自在專用集群（special-purpose clusters）上的應用。據我們觀察，這種策略在我們客戶的僅運行 PaddlePaddle 工作的集群上是高性能的。但是，這種策略可能在能夠運行許多種工作的通用集群上並不是最優的。
PaddlePaddle 訓練器可以利用多個 GPU 來加速計算。GPU 目前還不是 Kubernetes 中的首選資源。我們還必須半人工地管理 GPU。我們期望能與 Kubernetes 社區一起提升 GPU 支持，以確保 PaddlePaddle 能在 Kubernetes 上實現最佳的表現。
資源
Kubernetes：http://get.k8s.io/本 Kubernetes 項目的 GitHub：https://github.com/kubernetes/kubernetesStack Overflow 問題討論：http://stackoverflow.com/questions/tagged/kubernetesSlack 社區：http://slack.k8s.io/