如何構建自己的深度學習基礎設施

深度學習是一門經驗科學，許多基礎設施的質量也在倍增。幸運的是，現在的開源生態系統可以使任何人建立不錯的深度學習基礎設施。

在這篇文章中，我們將講述深度學習研究通常如何進行，介紹可選的對應基礎設施以及開源的kubernetes-ec2-autoscaler，用于Kubernetes的批次優化擴展管理。希望這篇文章對你構建自己的深度學習基礎設施有所幫助。

用例

深度學習典型的進步是從一個想法開始的，你在一個小問題上進行測試。在這個階段，你想要快速的進行許多臨時實驗。理想情況下，你可以通過SSH連上一臺機器，然后運行腳本，并在一小時以內得到結果。

要使模型真正工作，通常需要預見所有可能出錯的情況，并且設法解決這些限制。（這類似于構建新的軟件系統，你多次運行代碼來了解它的運行情況。）

視頻

你需要從多個角度來考察你的模型，以了解它們的實際學習情況。上面這個來自于Dario Amodei的強化學習Agent（控制右邊的球拍）取得了高比分，但當你看著它玩時，你會發現它只是呆在一個地方。因此，深度學習基礎設施必須能夠讓用戶靈活觀察模型，僅僅給出匯總統計是不夠的。

一旦模型表現不錯，你可以將它使用在更大的數據集和更多的GPU上。這是需要進行長期任務時才這么做，它們會消耗很多周期，并持續數天。你需要對實驗小心管理，對所選擇的超參數范圍要考慮非常周到。

前期的研究過程都是非結構化的、敏捷的；后期研究則是有條不紊的，并在一定程度上讓人感到痛苦，但這都是得到良好結果所必須的。

例子

論文Improved Techniques for Training GANs 開頭講述了Tim Salimans設計了幾種改善生成對抗性網絡訓 練的思想。我們將介紹最簡單的思想（產生最好的樣本，但不是最好的半監督學習）。GAN包含一個生成器和一個鑒別器網絡。生成器嘗試愚弄鑒別器，而鑒別器 則嘗試區分生成數據和真實數據。直觀地說，可以愚弄所有鑒別器的生成器是一個好的生成器。但是有一個難以修復的錯誤：生成器可能會“崩潰”，總是會輸出完 全一樣（可能是逼真的！）的樣本。

Tim提出這樣的想法，給鑒別器輸入樣本的一個 小批次 ，而不是將整個樣本作為輸入。因此鑒別器就可以區分生成器是不是不斷產生一張圖像。當發現崩潰，生成器將會進行梯度調整來糾正這一問題。

下一步就是將這個想法在MNIST和CIFAR10上構建原型。這需要盡快原型化一個小模型，使用真實數據，并檢查結果。經過一番快速迭代，TIm得到了非常令人振奮的CIFAR-10樣本——這個數據集上我們見過最好的樣本。

然而，深度學習（和一般的AI算法）必須進行擴展——小的神經網絡可以證明一個概念，但是大的神經網絡才能真正解決問題，才能為人所用。所以 Ian Goodfellow 將這個模型擴展到 ImageNet 上進行使用。

我們的模型學會了生成ImageNet的圖畫

對于更大的模型和數據集，Ian需要將模型并行部署在多個GPU上。每個Job將會占用90%的CPU和GPU，但即便如此，該模型還是需要經過多天的訓練。在這種情況下，每個實驗顯得彌足珍貴，他會一絲不茍地記錄每個實驗結果。

最終，雖然結果還不錯，但并沒有我們期望的那么好。雖然已經測試過很多假設，但仍然沒有解決。這就是科學的本質。

基礎設施

軟件

我們Tensorflow代碼的一個

我們絕大多數的研究代碼是使用Python所寫的，可以在 我們 的 開 源 項目 中看到。我們主要使用 Tensorflow （或者在特殊情況下使用 Theano ）進行GPU計算；對于CPU計算我們還會使用 Numpy 。研究人員有時還會使用高層框架，例如基于Tensorflow的 Keras 。

與多數深度學習社區一樣，使用Python 2.7。我們通常使用 Anaconda ，它能很方便的打包，如 OpenCV ，和對一些科學計算庫文件進行 性能優化 。

硬件

對于理想的批處理作業，加倍集群中的節點可以減半作業運行時間。不幸的是，在深度學習方面，增加GPU個數會 次線性 加快速度。因此，要達到頂級性能需要超頂級的GPU。我們還在 模擬器 、 強化學習環境 、或小規模模型上使用了許多CPU（這不比在GPU上運行的快）。

下滿載的Titan Xs

AWS 慷慨地給我們提供了大量的計算機。使用它們進行CPU實例以及水平擴展GPU作業。我們同樣會運行自己的物理機，主要使用的是 Titan X GPU。我們希望有混合云：它可以使用不同GPU、互聯以及將來可能成為重要深度學習的技術進行實驗。

在 htop 上同樣的物理單元顯示有許多空閑的CPU。我們通常將CPU密集型工作與GPU密集型分開運行。

配置

我們使用基礎設施與其他公司對待產品一樣：它必須有簡潔的界面，可用性與功能同等重要。我們使用一套統一的工具來管理所有的服務器并盡可能對它們進行同樣的配置。

Terraform配置管理自動擴展組片段。Terraform創建，修改，或銷毀運行的云資源來匹配你的配置文件。

我們使用 Terraform 來建立AWS云資源（實例，網絡路由，DNS記錄等）。云和物理節點運行的是 Ubuntu ，使用 Chef 進行配置。為了加速處理，我們使用 Packer 來對集群AMI進行預處理。我們所有的集群使用非重疊的IP范圍，通過用戶筆記本上 OpenV*N 在共用網絡上互聯， strongSwan 部署在物理節點上（作為AWS 客戶端網關 ）。

我們將用戶的主目錄，數據集以及結果存儲在 NFS （物理硬件）和 EFS / S3 （AWS）上。

編制

可擴展的基礎設施通常會導致簡單用例變復雜。我們在基礎設施的小型和大型作業上投入了同等精力，并且正在積極固化我們的工具包，使分布式用例與本地用例一樣可用。

我們提供了SSH節點（有的有GPU，有的沒有）的集群用于臨時實驗，并在物理節點和AWS節點上使用 Kubernetes 作為集群調度器。集群跨越3個AWS regions——我們的作業比較耗費資源，有時候會占滿單個regions所有資源。

Kubernetes要求每個作業都是一個Docker容器，這樣可以提供依賴隔離和代碼快照。然而，構建一個新的Docker容器會給研究人員迭代周期增加少量額外的時間，所以我們也提供工具將研究人員筆記本上的代碼轉換成標準鏡像。

TensorBoard中模型的

我們將Kubernetes的 flannel 網絡直接暴露給研究人員的筆記本電腦，允許用戶無縫網絡訪問他們運行的作業。這在訪問監控服務時非常有用，比如 TensorBoard 。（最初的做法——從嚴格隔離的角度來看更明確——需要用戶為他們想要暴露的端口創建一個Kubernetes 服務 ，但發現這會帶來很大阻力。）

kubernetes-ec2-autoscaler

我 們的工作量會爆發性激增，并且不可預知：一項研究可能從單臺機器可以進行的實驗迅速地發展到需要1000個核心才能進行。比如，過了幾個星期，一項實驗交 互階段只需一個Titan X，到了實驗階段需要60塊Titan X，再到需要將近1600塊 AWS GPU。因此，我們的云基礎設施需要動態的配置Kubernetes節點。

在 自動擴展 組中很容易運行Kubernetes節點，但是要正確管理這些組的大小就很難。在批處理作業提交后，集群知道它需要多少資源，然后直接分配。（相反，AWS的 擴展策略 將會產生新的節點碎片，直到有剩余資源，這可能會多次進行。）此外，在集群終止節點前，需要 洩流 節點，避免丟失正在執行的作業。

只使用原始的EC2進行大批量作業很誘人，而我們開始也是這么做的。然而，Kubernetes 生態系統帶來了很多價值：低阻力工具，日志，監控，能夠從運行實例中分別管理物理節點等。正確配置Kubernetes自動擴展比在原始EC2上重新構建這個生態系統更簡單。

我們即將推出 kubernetes-ec2-autoscaler ，面向Kubernetes的批處理優化的擴展管理。它在Kubernetes上作為普通的 Pod 運行，只需你的工作節點在自動擴展組內。

Kubernetes集群的啟動配置

自動擴展器獲取Kubernetes 主節點的狀態，包括計算集群資源需求和容量所需的一切信息。如果資源不足，它將會洩流節點，然后終止它們。如果需要更多的資源，它會計算應該創建什么服務并適當增大自動擴展組的大小（或是簡單的 取消已洩流節點警告 ，從而避免了新節點起轉的時間）。

kubernetes-ec2-autoscaler 負責處理多個自動擴展組，超過CPU（內存和GPU）的資源，限制你作業的細粒度因素，比如AWS region和實例大小。此外，突發性工作負載可能導致自動擴展組超時和錯誤，因為（令人驚訝！）AWS不具有無限容量。在這種情況 下，kubernetes-ec2-autoscaler 檢測到錯誤并把作業發配到第二個AWS region。

 

來自：https://mp.weixin.qq.com/s?__biz=MjM5NzQ3ODAwMQ==&mid=2686978257&idx=1&sn=8783c46c72b12183906c15f106253e77&scene=0&key=&ascene=7&uin=&devicetype=android-23&version=26031933&nettype=WIFI