想獨立開展深度學習研究，你準備好了嗎？
深度學習是一門經驗科學，具備優質的研發基礎架構通常能令科研團隊事半功倍。幸運的是，依托現有的開源生態，任何人都能構建出非常不錯的深度學習基礎架構。
在這篇文章中，我們會和大家分享如何開展深度學習的研究，也會一并介紹我們在研究中選用的基礎架構和開源技術kubernetes-ec2-autoscaler，這是一種用于Kubernetes批處理任務的彈性伸縮管理器（batch-optimizedscalingmanager）。
用例
深度學習的演進通常源于一個能夠在小問題上被驗證的構想。在這個階段，你需要快速地進行大量隨機實驗。理想情況下，只需遠程登錄到一臺機器，運行一個腳本，不到一個小時就可以得到結果。
但是構建一個真正可用的模型通常會經歷很多次失敗，需要我們不停地去修復這些缺陷。（這和其他新建的軟件系統一樣，你需要多次運行代碼才能判斷它是如何運轉的。）
你需要通過多個角度的計算來檢測模型，從而意識到它是如何學習的。DarioAmodei的這種增強學習機制（控制右側的球拍）可以在擊球游戲中獲得很高的分數，但你會發現，游戲中右側的球拍完全沒有移動。
因此深度學習的基礎架構要能允許用戶靈活地反觀模型，僅僅展示一些統計結果是不夠的。
當模型表現出一定的應用前景，你會希望將它擴展到更大的數據集和更多的GPU上運行，但這會花費大量的時間。而且你需要認真地管理實驗并非常謹慎地去選擇超參數（hyperparameters）的范圍。
這種科研的過程在早期是快速且缺乏系統性的；到了后期，過程會逐漸有條理卻很耗費精力，但為了獲得完美的結果，這是必不可少的。
案例
論文ImprovedTechniquesforTrainingGANs開篇講述了TimSalimans對于如何改進生成對抗網絡（GAN）訓練機制的一些看法。我們會挑其中較簡單的一個進行介紹（這雖然不是最好的半監督學習案例，但它生成了最好看的樣本）。
GANs由一個生成器網絡和一個鑒別器網絡構成。生成器會不停地去干擾鑒別器，而鑒別器會盡力地將生成器造出的數據和真實數據區分開來。通常來說，判斷生成器的好壞，看它能不能騙過所有鑒別器就行了，但難題仍然存在：如果生成器一直輸出完全相同的（幾乎和真實的一樣）樣本會造成網絡的崩潰。
Tim提出可以用小批次的樣本數據代替原先的一整個樣本提供給鑒別器。這樣鑒別器就可以判斷生成器是否一直在傳同樣的圖像。當崩潰發生時，生成器將會進行梯度調整來修正這個問題。
下一步就是基于MNIST和CIFAR-10將構想轉化為原型。這需要快速地構建出一個初步的模型，然后運行真實的數據并檢測結果。在經過幾次快速的迭代之后，Tim得到了CIFAR-10的樣本，這次的結果十分振奮人心，幾乎是我們見過的在這個數據集上跑出的最好樣本了。
深度學習（以及常說的AI算法）如果要真正形成一定影響就必須擴大實驗規模，一個小型神經網絡可以驗證概念，而大型的神經網絡才能真正解決問題。因此IanGoodfellow開始把模型擴展到ImageNet進行驗證。
模型學習生成ImageNet的圖像
有了更大的模型和數據集，Ian就需要用更多的GPU來并行地運行模型。任務運行時機器的CPU和GPU利用率會飆升至90%，但是即使這樣仍需要花費很多天才能完成模型訓練。在這種模式下，每一次實驗機會都顯得無比珍貴，他也會非常細致地記錄下每次實驗的結果。
雖然實驗最終得到了不錯的結果，但仍沒有達到我們的預期。為了找到原因我們做了很多嘗試，但仍然攻克不了。這大概就是科學的本質吧。
基礎架構
軟件
TensorFlow代碼的樣例
我們絕大部分的研究代碼是用Python完成的，詳細內容可以在我們的開源項目中查看到。我們通常使用TensorFlow（在特殊情況下也會使用Theano）來進行GPU計算；使用Numpy或其他方法來進行CPU計算。研究人員有時也會使用更上層的框架，比如基于TensorFlow的Keras。
和多數深度學習社區一樣，我們會使用Python2.7。Anaconda也經常會用到，它可以方便地給OpenCV打包，并對一些科學算法庫進行性能優化。
硬件
對于理想的批處理任務，將集群計算節點的數量翻倍會減半任務執行時間。不幸的是，在深度學習中，機器人維修，GPU數量的增加只會引起任務亞線性的加速。因此頂級的計算性能只能依靠頂級的GPU來實現。我們也使用了許多CPU用于構建模擬器、增強學習環境或是小規模的模型（這類模型跑在GPU上時運行效率不會有明顯的增加）。
nvidia-smi下滿載的TitanXs
AWS慷慨地為我們提供了大量計算資源。這些資源被用于CPU實例以及GPU任務的水平擴展。我們也有自己的物理機，用的是TitanXGPU。我們期望之后可以使用混合云：對不同的GPU、連接以及其他技術開展實驗是非常具有價值的，這對深度學習未來的發展也有著重要影響。
相同物理單元上的htop顯示了大量空閑的CPU。我們通常將CPU密集型和GPU密集型的任務分開運行。
配置
我們對待基礎架構就像許多公司對待他們的產品一樣：它的界面必須簡潔，必須兼顧功能性和可用性。我們會使用一致的工具來統一管理所有服務器，并且盡可能地對他們進行相同的配置。
用于管理彈性伸縮組的Terraform配置文件片段。Terraform可以創建、修改或銷毀正在運行的云資源來匹配配置文件。
我們使用Terraform來創建AWS的云資源（實例、網絡路由、DNS記錄等）。我們的云端節點和物理節點都運行Ubuntu系統，并使用Chef來做配置。為了實現加速，m.twshmhelmet.com，我們使用Packer來預先制作集群鏡像（AMI）。我們的所有集群都使用非交叉的IP范圍，用戶可以通過筆記本上的OpenVPN及物理節點上的strongSwan（AWS的客戶網關）連接到公網。
最后，我們將用戶的home目錄、數據集和結果存儲在NFS（基于物理硬件）和EFS/S3（基于AWS）上。
編排
可擴展的基礎架構通常會使原本簡單的用例復雜化。我們在對不同規模作業的基礎架構研究上投入了同等的精力，也在同步優化工具套件，使得分布式的用例能像本地用例一樣好用。
我們為隨機實驗提供了SSH節點的（有些有GPU有些沒有）集群，并且使用Kubernetes來調度物理節點和AWS節點。我們的集群橫跨3個AWS域因為有時任務量會突然爆發，從而占滿單個區域的所有資源。
Kubernetes要求每一個任務都是一個Docker容器，這樣就可以實現依賴隔離和代碼快照。但是創建一個新的Docker容器會增加迭代周期的時間，庫卡機器人何服電機維修，這個時間十分寶貴，所以我們也提供工具，將研究人員筆記本上的代碼轉成標準鏡像。
TensorBoard中的模型學習曲線