在這篇文章中，我們會(huì)和大家分享如何開展深度學(xué)習(xí)的研究，也會(huì)一并介紹我們?cè)谘芯恐羞x用的基礎(chǔ)架構(gòu)和開源技術(shù) kubernetes-ec2-autoscaler，這是一種用于 Kubernetes 批處理任務(wù)的彈性伸縮管理器（batch-optimized scaling manager）。

 

 

　　深度學(xué)習(xí)的演進(jìn)通常源于一個(gè)能夠在小問題上被驗(yàn)證的構(gòu)想。在這個(gè)階段，你需要快速地進(jìn)行大量隨機(jī)實(shí)驗(yàn)。理想情況下，只需遠(yuǎn)程登錄到一臺(tái)機(jī)器，運(yùn)行一個(gè)腳本，不到一個(gè)小時(shí)就可以得到結(jié)果。

 

　　但是構(gòu)建一個(gè)真正可用的模型通常會(huì)經(jīng)歷很多次失敗，需要我們不停地去修復(fù)這些缺陷。（這和其他新建的軟件系統(tǒng)一樣，你需要多次運(yùn)行代碼才能判斷它是如何運(yùn)轉(zhuǎn)的。）

 

　　你需要通過多個(gè)角度的計(jì)算來檢測(cè)模型，從而意識(shí)到它是如何學(xué)習(xí)的。Dario Amodei 的這種增強(qiáng)學(xué)習(xí)機(jī)制（控制右側(cè)的球拍）可以在擊球游戲中獲得很高的分?jǐn)?shù)，但你會(huì)發(fā)現(xiàn)，游戲中右側(cè)的球拍完全沒有移動(dòng)。

 

　　因此深度學(xué)習(xí)的基礎(chǔ)架構(gòu)要能允許用戶靈活地反觀模型，僅僅展示一些統(tǒng)計(jì)結(jié)果是不夠的。

 

　　當(dāng)模型表現(xiàn)出一定的應(yīng)用前景，你會(huì)希望將它擴(kuò)展到更大的數(shù)據(jù)集和更多的 GPU 上運(yùn)行，但這會(huì)花費(fèi)大量的時(shí)間。而且你需要認(rèn)真地管理實(shí)驗(yàn)并非常謹(jǐn)慎地去選擇超參數(shù)（hyperparameters）的范圍。

 

　　這種科研的過程在早期是快速且缺乏系統(tǒng)性的；到了后期，過程會(huì)逐漸有條理卻很耗費(fèi)精力，但為了獲得完美的結(jié)果，這是必不可少的。

 

 

　　論文 Improved Techniques for Training GANs 開篇講述了 Tim Salimans 對(duì)于如何改進(jìn)生成對(duì)抗網(wǎng)絡(luò)（GAN）訓(xùn)練機(jī)制的一些看法。我們會(huì)挑其中較簡(jiǎn)單的一個(gè)進(jìn)行介紹（這雖然不是最好的半監(jiān)督學(xué)習(xí)案例，但它生成了最好看的樣本）。

 

　　GANs 由一個(gè)生成器網(wǎng)絡(luò)和一個(gè)鑒別器網(wǎng)絡(luò)構(gòu)成。生成器會(huì)不停地去干擾鑒別器，而鑒別器會(huì)盡力地將生成器造出的數(shù)據(jù)和真實(shí)數(shù)據(jù)區(qū)分開來。通常來說，判斷生成器的好壞，看它能不能騙過所有鑒別器就行了，但難題仍然存在：如果生成器一直輸出完全相同的（幾乎和真實(shí)的一樣）樣本會(huì)造成網(wǎng)絡(luò)的崩潰。

 

　　Tim 提出可以用小批次的樣本數(shù)據(jù)代替原先的一整個(gè)樣本提供給鑒別器。這樣鑒別器就可以判斷生成器是否一直在傳同樣的圖像。當(dāng)“崩潰”發(fā)生時(shí)，生成器將會(huì)進(jìn)行梯度調(diào)整來修正這個(gè)問題。

 

　　下一步就是基于 MNIST 和 CIFAR-10 將構(gòu)想轉(zhuǎn)化為原型。這需要快速地構(gòu)建出一個(gè)初步的模型，然后運(yùn)行真實(shí)的數(shù)據(jù)并檢測(cè)結(jié)果。在經(jīng)過幾次快速的迭代之后，Tim 得到了 CIFAR-10 的樣本，這次的結(jié)果十分振奮人心，幾乎是我們見過的在這個(gè)數(shù)據(jù)集上跑出的最好樣本了。

 

　　深度學(xué)習(xí)（以及常說的 AI 算法）如果要真正形成一定影響就必須擴(kuò)大實(shí)驗(yàn)規(guī)模，一個(gè)小型神經(jīng)網(wǎng)絡(luò)可以驗(yàn)證概念，而大型的神經(jīng)網(wǎng)絡(luò)才能真正解決問題。因此 Ian Goodfellow 開始把模型擴(kuò)展到 ImageNet 進(jìn)行驗(yàn)證。

 

　　模型學(xué)習(xí)生成 ImageNet 的圖像

 

　　有了更大的模型和數(shù)據(jù)集，Ian 就需要用更多的 GPU 來并行地運(yùn)行模型。任務(wù)運(yùn)行時(shí)機(jī)器的 CPU 和 GPU 利用率會(huì)飆升至 90%，但是即使這樣仍需要花費(fèi)很多天才能完成模型訓(xùn)練。在這種模式下，每一次實(shí)驗(yàn)機(jī)會(huì)都顯得無比珍貴，他也會(huì)非常細(xì)致地記錄下每次實(shí)驗(yàn)的結(jié)果。

 

　　雖然實(shí)驗(yàn)最終得到了不錯(cuò)的結(jié)果，但仍沒有達(dá)到我們的預(yù)期。為了找到原因我們做了很多嘗試，但仍然攻克不了。這大概就是科學(xué)的本質(zhì)吧。

 

 

 

　　TensorFlow 代碼的樣例

 

　　我們絕大部分的研究代碼是用 Python 完成的，詳細(xì)內(nèi)容可以在我們的開源項(xiàng)目中查看到。我們通常使用 TensorFlow（在特殊情況下也會(huì)使用 Theano）來進(jìn)行 GPU 計(jì)算；使用 Numpy 或其他方法來進(jìn)行 CPU 計(jì)算。研究人員有時(shí)也會(huì)使用更上層的框架，比如基于 TensorFlow 的 Keras。

 

　　和多數(shù)深度學(xué)習(xí)社區(qū)一樣，我們會(huì)使用 Python2.7。Anaconda 也經(jīng)常會(huì)用到，它可以方便地給 OpenCV 打包，并對(duì)一些科學(xué)算法庫(kù)進(jìn)行性能優(yōu)化。

 

 

　　對(duì)于理想的批處理任務(wù)，將集群計(jì)算節(jié)點(diǎn)的數(shù)量翻倍會(huì)減半任務(wù)執(zhí)行時(shí)間。不幸的是，在深度學(xué)習(xí)中，GPU 數(shù)量的增加只會(huì)引起任務(wù)亞線性的加速。因此頂級(jí)的計(jì)算性能只能依靠頂級(jí)的 GPU 來實(shí)現(xiàn)。我們也使用了許多 CPU 用于構(gòu)建模擬器、增強(qiáng)學(xué)習(xí)環(huán)境或是小規(guī)模的模型（這類模型跑在 GPU 上時(shí)運(yùn)行效率不會(huì)有明顯的增加）。

 

　　nvidia-smi 下滿載的 Titan Xs

 

　　AWS 慷慨地為我們提供了大量計(jì)算資源。這些資源被用于 CPU 實(shí)例以及 GPU 任務(wù)的水平擴(kuò)展。我們也有自己的物理機(jī)，用的是 Titan X GPU。我們期望之后可以使用混合云：對(duì)不同的 GPU、連接以及其他技術(shù)開展實(shí)驗(yàn)是非常具有價(jià)值的，這對(duì)深度學(xué)習(xí)未來的發(fā)展也有著重要影響。

 

　　相同物理單元上的 htop 顯示了大量空閑的 CPU。我們通常將 CPU 密集型和 GPU 密集型的任務(wù)分開運(yùn)行。

 

 

　　我們對(duì)待基礎(chǔ)架構(gòu)就像許多公司對(duì)待他們的產(chǎn)品一樣：它的界面必須簡(jiǎn)潔，必須兼顧功能性和可用性。我們會(huì)使用一致的工具來統(tǒng)一管理所有服務(wù)器，并且盡可能地對(duì)他們進(jìn)行相同的配置。

 

　　用于管理彈性伸縮組的 Terraform 配置文件片段。Terraform 可以創(chuàng)建、修改或銷毀正在運(yùn)行的云資源來匹配配置文件。

 

　　我們使用 Terraform 來創(chuàng)建 AWS 的云資源（實(shí)例、網(wǎng)絡(luò)路由、DNS 記錄等）。我們的云端節(jié)點(diǎn)和物理節(jié)點(diǎn)都運(yùn)行 Ubuntu 系統(tǒng)，并使用 Chef 來做配置。為了實(shí)現(xiàn)加速，我們使用 Packer 來預(yù)先制作集群鏡像（AMI）。我們的所有集群都使用非交叉的 IP 范圍，用戶可以通過筆記本上的 OpenVPN 及物理節(jié)點(diǎn)上的 strongSwan（AWS 的客戶網(wǎng)關(guān)）連接到公網(wǎng)。

 

　　最后，我們將用戶的 home 目錄、數(shù)據(jù)集和結(jié)果存儲(chǔ)在 NFS（基于物理硬件）和 EFS/S3（基于 AWS）上。

 

 

　　可擴(kuò)展的基礎(chǔ)架構(gòu)通常會(huì)使原本簡(jiǎn)單的用例復(fù)雜化。我們?cè)趯?duì)不同規(guī)模作業(yè)的基礎(chǔ)架構(gòu)研究上投入了同等的精力，也在同步優(yōu)化工具套件，使得分布式的用例能像本地用例一樣好用。

 

　　我們?yōu)殡S機(jī)實(shí)驗(yàn)提供了 SSH 節(jié)點(diǎn)的（有些有 GPU 有些沒有）集群，并且使用 Kubernetes 來調(diào)度物理節(jié)點(diǎn)和 AWS 節(jié)點(diǎn)。我們的集群橫跨 3 個(gè) AWS 域——因?yàn)橛袝r(shí)任務(wù)量會(huì)突然爆發(fā)，從而占滿單個(gè)區(qū)域的所有資源。

 

　　Kubernetes 要求每一個(gè)任務(wù)都是一個(gè) Docker 容器，這樣就可以實(shí)現(xiàn)依賴隔離和代碼快照。但是創(chuàng)建一個(gè)新的 Docker 容器會(huì)增加迭代周期的時(shí)間，這個(gè)時(shí)間十分寶貴，所以我們也提供工具，將研究人員筆記本上的代碼轉(zhuǎn)成標(biāo)準(zhǔn)鏡像。

 

　　TensorBoard 中的模型學(xué)習(xí)曲線

 

　　我們將 Kubernetes 的 flannel 網(wǎng)絡(luò)直接暴露至研究人員的電腦，使用戶可以無縫訪問正在運(yùn)行的任務(wù)。這對(duì)于訪問 TensorBoard 這類監(jiān)控服務(wù)特別有幫助。（為了實(shí)現(xiàn)絕對(duì)的隔離，我們最初要求針對(duì)每一個(gè)暴露的端口都要?jiǎng)?chuàng)建 Kubernetes 服務(wù)，但這樣會(huì)帶來很多困難。）

 

 

　　我們的任務(wù)負(fù)載具有突發(fā)性和不可預(yù)測(cè)性：原先只需要單節(jié)點(diǎn)的實(shí)驗(yàn)可能很快就發(fā)展到需要 1000 個(gè)核。比如在幾周的時(shí)間里，實(shí)驗(yàn)從只需要一個(gè) Titan X 的交互階段發(fā)展到了需要 60 個(gè) Titan X 的實(shí)驗(yàn)階段，這需要將近 1600 個(gè) AWS 的 GPU。因此，我們的云架構(gòu)要能動(dòng)態(tài)配置 Kubernetes 節(jié)點(diǎn)。

 

　　在彈性伸縮組中運(yùn)行 Kubernetes 節(jié)點(diǎn)非常簡(jiǎn)單，困難的是如何正確地配置這些組的規(guī)模。在提交批處理任務(wù)后，集群可以準(zhǔn)確地知道它需要的資源并直接進(jìn)行分配。（相反，AWS 的擴(kuò)展策略會(huì)不斷地啟動(dòng)新的節(jié)點(diǎn)碎片來提供足夠的資源，這是一個(gè)多次迭代的過程。）集群還需要在終止節(jié)點(diǎn)前進(jìn)行任務(wù)遷移（drain）操作，避免丟失正在運(yùn)行的任務(wù)。

 

　　很多人想直接使用原始的 EC2 來處理大批量的任務(wù)，我們一開始也是這么做的。但是 Kubernetes 的生態(tài)具有更多優(yōu)勢(shì)：比如易用的工具、日志記錄、監(jiān)控、從運(yùn)行實(shí)例中區(qū)分管理物理節(jié)點(diǎn)的能力等。合理配置 Kubernetes 使其能夠正確地動(dòng)態(tài)擴(kuò)展要比在原始 EC2 上重建這種環(huán)境來的簡(jiǎn)單。

 

　　我們發(fā)布的 kubernetes-ec2-autoscaler，是一種用于 Kubernetes 批處理任務(wù)的彈性伸縮管理器。它在 Kubernetes 上作為一個(gè)普通的 Pod 運(yùn)行，且只要求你的工作節(jié)點(diǎn)運(yùn)行在彈性伸縮組內(nèi)。

 

　　Kubernetes 集群的啟動(dòng)配置

 

　　自動(dòng)擴(kuò)展器會(huì)輪詢 Kubernetes 主節(jié)點(diǎn)的狀態(tài)，包括用于計(jì)算集群所需資源和容量的所有信息。如果超出了容量，它會(huì)將相關(guān)節(jié)點(diǎn)的任務(wù)遷移（drain）后將其終止。如果需要更多的資源，它會(huì)計(jì)算需要?jiǎng)?chuàng)建什么樣的服務(wù)器并適當(dāng)?shù)卦黾訌椥陨炜s組的規(guī)模（或直接解鎖 （uncordon） 執(zhí)行過 drain 操作的節(jié)點(diǎn)，來避免新節(jié)點(diǎn)增加的啟動(dòng)時(shí)間）。

 

　　kubernetes-ec2-autoscaler 管理著多個(gè)彈性伸縮組、CPU 之外的資源（內(nèi)存和 GPU）以及對(duì)任務(wù)細(xì)粒度的約束，例如 AWS 區(qū)域和實(shí)例大小。另外，突增的負(fù)載會(huì)引起彈性伸縮組的超時(shí)和報(bào)錯(cuò)，因?yàn)榧词故?AWS 也不具備無限擴(kuò)展的容量。這種情況下，kubernetes-ec2-autoscaler 會(huì)檢測(cè)到錯(cuò)誤并將超出部分的任務(wù)分配到次級(jí)的 AWS 區(qū)域執(zhí)行。

 

　　我們的基礎(chǔ)架構(gòu)設(shè)計(jì)旨在最大程度地提高科研人員的工作效率，使他們能夠?qū)Ｗ⒂诳蒲斜旧?。我們將繼續(xù)深入優(yōu)化基礎(chǔ)架構(gòu)和工作流程，之后也會(huì)陸續(xù)和大家分享經(jīng)驗(yàn)。我們期待與您的合作，共同促進(jìn)深度學(xué)習(xí)的發(fā)展！