深度進修是一門經(jīng)歷迷信，具有優(yōu)良的研發(fā)基本架構平日能令科研團隊事半功倍。榮幸的是，依托現(xiàn)有的開源生態(tài)，任何人都能構建出異常不錯的深度進修基本架構。
在這篇文章中，我們會和年夜家分享若何展開深度進修的研討，也會一并引見我們在研討當選用的基本架構和開源技巧 kubernetes-ec2-autoscaler，這是一種用于 Kubernetes 批處置義務的彈性伸縮治理器（batch-optimized scaling manager）。
用例
深度進修的演進平日源于一個可以或許在小成績上被驗證的構思。在這個階段，你須要疾速地停止年夜量隨機試驗。幻想情形下，只需長途登錄到一臺機械，運轉一個劇本，不到一個小時便可以獲得成果。
然則構建一個真正可用的模子平日會閱歷許多次掉敗，須要我們一直地去修復這些缺點。（這和其他新建的軟件體系一樣，你須要屢次運轉代碼能力斷定它是若何運轉的。）
你須要經(jīng)由過程多個角度的盤算來檢測模子，從而認識到它是若何進修的。Dario Amodei 的這類加強進修機制（掌握右邊的球拍）可以在擊球游戲中取得很高的分數(shù)，但你會發(fā)明，游戲中右邊的球拍完整沒有挪動。
是以深度進修的基本架構要能許可用戶靈巧地反不雅模子，僅僅展現(xiàn)一些統(tǒng)計成果是不敷的。
當模子表示出必定的運用遠景，你會愿望將它擴大到更年夜的數(shù)據(jù)集和更多的 GPU 上運轉，但這會消費年夜量的時光。并且你須要賣力地治理試驗并不是常謹嚴地去選擇超參數(shù)（hyperparameters）的規(guī)模。
這類科研的進程在晚期是疾速且缺少體系性的；到了前期，進程會逐步有層次卻很消耗精神，但為了取得完善的成果，這是必弗成少的。
案例
論文 Improved Techniques for Training GANs 開篇講述了 Tim Salimans 關于若何改良生成反抗收集（GAN）練習機制的一些意見。我們會挑個中較簡略的一個停止引見（這固然不是最好的半監(jiān)視進修案例，但它生成了最悅目的樣本）。
GANs 由一個生成器收集和一個辨別器收集組成。生成器會一直地去攪擾辨別器，而辨別器會努力地將生成器造出的數(shù)據(jù)和真實數(shù)據(jù)辨別開來。平日來講，斷定生成器的利害，看它能不克不及騙過一切辨別器就好了，但困難依然存在：假如生成器一向輸入完整雷同的（簡直和真實的一樣）樣本會形成收集的瓦解。
Tim 提出可以用小批次的樣本數(shù)據(jù)取代本來的一全部樣本供給給辨別器。如許辨別器便可以斷定生成器能否一向在傳異樣的圖象。當“瓦解”產(chǎn)生時，生成器將會停止梯度調劑來修改這個成績。
下一步就是基于 MNIST 和 CIFAR-10 將構思轉化為原型。這須要疾速地構建出一個初步的模子，然后運轉真實的數(shù)據(jù)并檢測成果。在經(jīng)由幾回疾速的迭代以后，Tim 獲得了 CIFAR-10 的樣本，此次的成果非常振奮人心，簡直是我們見過的在這個數(shù)據(jù)集上跑出的最好樣本了。
深度進修（和常說的 AI 算法）假如要真正構成必定影響就必需擴展試驗范圍，一個小型神經(jīng)收集可以驗證概念，而年夜型的神經(jīng)收集能力真正處理成績。是以 Ian Goodfellow 開端把模子擴大到 ImageNet 停止驗證。
模子進修生成 ImageNet 的圖象
有了更年夜的模子和數(shù)據(jù)集，Ian 就須要用更多的 GPU 來并行地運轉模子。義務運轉機會器的 CPU 和 GPU 應用率會飆升至 90%，然則即便如許仍須要消費許多天賦能完成模子練習。在這類形式下，每次試驗機遇都顯得非常名貴，他也會異常過細地記載下每次試驗的成果。
固然試驗終究獲得了不錯的成果，但仍沒有到達我們的預期。為了找到緣由我們做了許多測驗考試，但依然霸占不了。這年夜概就是迷信的實質吧。
基本架構
軟件
TensorFlow 代碼的樣例
我們絕年夜部門的研討代碼是用 Python 完成的，具體內容可以在我們的開源項目中檢查到。我們平日應用 TensorFlow（在特別情形下也會應用 Theano）來停止 GPU 盤算；應用 Numpy 或其他辦法來停止 CPU 盤算。研討人員有時也會應用更下層的框架，好比基于 TensorFlow 的 Keras。
和多半深度進修社區(qū)一樣，我們會應用 Python2.7。Anaconda 也常常會用到，它可以便利地給 OpenCV 打包，并對一些迷信算法庫停止機能優(yōu)化。
硬件
關于幻想的批處置義務，將集群盤算節(jié)點的數(shù)目翻倍會減半義務履行時光。不幸的是，在深度進修中，GPU 數(shù)目的增長只會惹起義務亞線性的加快。是以頂級的盤算機能只能依附頂級的 GPU 來完成。我們也應用了很多 CPU 用于構建模仿器、加強進修情況或是小范圍的模子（這類模子跑在 GPU 上時運轉效力不會有顯著的增長）。
nvidia-smi 下滿載的 Titan Xs
AWS 大方地為我們供給了年夜量盤算資本。這些資本被用于 CPU 實例和 GPU 義務的程度擴大。我們也有本身的物理機，用的是 Titan X GPU。我們希冀以后可使用混雜云：對分歧的 GPU、銜接和其他技巧展開試驗長短常具有價值的，這對深度進修將來的成長也有側重要影響。
雷同物理單位上的 htop 顯示了年夜量余暇的 CPU。我們平日將 CPU 密集型和 GPU 密集型的義務離開運轉。
設置裝備擺設
我們看待基本架構就像很多公司看待他們的產(chǎn)物一樣：它的界面必需簡練，必需統(tǒng)籌功效性和可用性。我們會應用分歧的對象來同一治理一切辦事器，而且盡量地對他們停止雷同的設置裝備擺設。
用于治理彈性伸縮組的 Terraform 設置裝備擺設文件片斷。Terraform 可以創(chuàng)立、修正或燒毀正在運轉的云資本來婚配設置裝備擺設文件。
我們應用 Terraform 來創(chuàng)立 AWS 的云資本（實例、收集路由、DNS 記載等）。我們的云端節(jié)點和物理節(jié)點都運轉 Ubuntu 體系，并應用 Chef 來做設置裝備擺設。為了完成加快，我們應用 Packer 來事后制造集群鏡像（AMI）。我們的一切集群都應用非穿插的 IP 規(guī)模，用戶可以經(jīng)由過程筆記本上的 OpenVPN 及物理節(jié)點上的 strongSwan（AWS 的客戶網(wǎng)關）銜接到公網(wǎng)。
最初，我們將用戶的 home 目次、數(shù)據(jù)集和成果存儲在 NFS（基于物理硬件）和 EFS/S3（基于 AWS）上。
編排
可擴大的基本架構平日會使本來簡略的用例龐雜化。我們在對分歧范圍功課的基本架構研討上投入了一致的精神，也在同步優(yōu)化對象套件，使得散布式的用例能像當?shù)赜美粯雍糜谩?/p>
我們?yōu)殡S機試驗供給了 SSH 節(jié)點的（有些有 GPU 有些沒有）集群，而且應用 Kubernetes 來調劑物理節(jié)點和 AWS 節(jié)點。我們的集群橫跨 3 個 AWS 域——由于有時義務量會忽然迸發(fā)，從而占滿單個區(qū)域的一切資本。
Kubernetes 請求每個義務都是一個 Docker 容器，如許便可以完成依附隔離和代碼快照。然則創(chuàng)立一個新的 Docker 容器會增長迭代周期的時光，這個時光非常名貴，所以我們也供給對象，將研討人員筆記本上的代碼轉成尺度鏡像。
TensorBoard 中的模子進修曲線
我們將 Kubernetes 的 flannel 收集直接裸露至研討人員的電腦，應用戶可以無縫拜訪正在運轉的義務。這關于拜訪 TensorBoard 這類監(jiān)控辦事特殊有贊助。（為了完成相對的隔離，我們最后請求針對每個裸露的端口都要創(chuàng)立 Kubernetes 辦事，但如許會帶來許多艱苦。）
kubernetes-ec2-autoscaler
我們的義務負載具有突發(fā)性和弗成猜測性：本來只須要單節(jié)點的試驗能夠很快就成長到須要 1000 個核。好比在幾周的時光里，試驗從只須要一個 Titan X 的交互階段成長到了須要 60 個 Titan X 的試驗階段，這須要快要 1600 個 AWS 的 GPU。是以，我們的云架構要能靜態(tài)設置裝備擺設 Kubernetes 節(jié)點。
在彈性伸縮組中運轉 Kubernetes 節(jié)點異常簡略，艱苦的是若何準確地設置裝備擺設這些組的范圍。在提交批處置義務后，集群可以精確地曉得它須要的資本并直接停止分派。（相反，AWS 的擴大戰(zhàn)略會賡續(xù)地啟動新的節(jié)點碎片來供給足夠的資本，這是一個屢次迭代的進程。）集群還須要在終止節(jié)點進步行義務遷徙（drain）操作，防止喪失正在運轉的義務。
許多人想直接應用原始的 EC2 來處置年夜批量的義務，我們一開端也是這么做的。然則 Kubernetes 的生態(tài)具有更多優(yōu)勢：好比易用的對象、日記記載、監(jiān)控、從運轉實例中辨別治理物理節(jié)點的才能等。公道設置裝備擺設 Kubernetes 使其可以或許準確地震態(tài)擴大要比在原始 EC2 上重建這類情況來的簡略。
我們宣布的 kubernetes-ec2-autoscaler，是一種用于 Kubernetes 批處置義務的彈性伸縮治理器。它在 Kubernetes 上作為一個通俗的 Pod 運轉，且只需求你的任務節(jié)點運轉在彈性伸縮組內。
Kubernetes 集群的啟動設置裝備擺設
主動擴大器會輪詢 Kubernetes 主節(jié)點的狀況，包含用于盤算集群所需資本和容量的一切信息。假如超越了容量，它會將相干節(jié)點的義務遷徙（drain）后將其終止。假如須要更多的資本，它管帳算須要創(chuàng)立甚么樣的辦事器并恰當?shù)卦鲩L彈性伸縮組的范圍（或直接解鎖 （uncordon） 履行過 drain 操作的節(jié)點，來防止新節(jié)點增長的啟動時光）。
kubernetes-ec2-autoscaler 治理著多個彈性伸縮組、CPU 以外的資本（內存和 GPU）和對義務細粒度的束縛，例如 AWS 區(qū)域和實例年夜小。別的，突增的負載會惹起彈性伸縮組的超時和報錯，由于即便是 AWS 也不具有無窮擴大的容量。這類情形下，kubernetes-ec2-autoscaler 會檢測到毛病并將超越部門的義務分派到次級的 AWS 區(qū)域履行。
我們的基本架構設計旨在最年夜水平地進步科研人員的任務效力，使他們可以或許專注于科研自己。我們將持續(xù)深刻優(yōu)化基本架構和任務流程，以后也會陸續(xù)和年夜家分享經(jīng)歷。我們等待與您的協(xié)作，配合增進深度進修的成長！
