本月初，Kubernetes在其官網上宣布了百度的PaddlePaddle成為目前唯一官方支持Kubernetes的深度學習框架。PaddlePaddle是百度于2016年9月開源的一款深度學習平臺，具有易用，高效，靈活和可伸縮等特點，為百度內部多項產品提供深度學習算法支持。兩個開源項目的結合意味著深度學習對于廣大開發者正變得“觸手可及”。還有呢？
一、編者按
AlphaGo 圍棋之戰引燃了人工智能，也激發了技術圈的研究熱情；江湖傳言其單個訓練作業要依賴數千個GPU，而更有人猜測規模恐怕遠超于此，縱然Google對其使用的集群規模等技術細節三緘其口，也沒有阻擋住技術人探索的腳步。機器 / 深度學習作為人工智能領域中的重要分支，有著如 TensorFlow、Torch、Theano、Caffe等不少的開源項目，PaddlePaddle（PArallel Distributed Deep LEarning）是百度于2016年9月開源的一款深度學習平臺，具有易用，高效，靈活和可伸縮等特點，為百度內部多項產品提供深度學習算法支持。
這套打磨逾三年的技術，需要在大規模集群上進行分布式作業。如何啟動系統并將分散的資源和眾多的學習任務良好匹配是一個無法回避的技術問題。問題總是相似的，容器技術也面臨著如何簡單地管理好分散的物理計算資源這個難題。解決方案之一Kubernetes是Google為生產環境設計的開源的容器管理調度系統。
本月初，Kubernetes在其官網上宣布了百度的PaddlePaddle成為目前唯一官方支持Kubernetes的深度學習框架。兩個開源項目的結合意味著深度學習對于廣大開發者正變得“觸手可及”。為什么會有這樣的組合？PaddlePaddle on Kubernetes的意味著什么？如何看待深度學習擁抱容器技術？帶著這些問題InfoQ采訪了博客文章的原作者百度王益和CoreOS李響探求更多的技術內容，同時還采訪了Kubernetes Project Manager、HyperHQ項目成員 張磊，本文整理自三位嘉賓的采訪素材。
二、大規模深度學習遭遇痛點
在人工智能專家王益博士看來，現代的人工智能是建立在大數據基礎之上的，而大數據的主要來源有兩個：互聯網服務的log（記錄用戶行為）以及通過各種crawler采集的外部數據。在具體落地上，對于工業級應用，需要把從Web服務到內外部數據收集和處理的整個通道，都與AI建設在一個機群上，才能實現高效的知識提取，然后將結果反饋從而提升服務質量。
在百度，分布式深度學習平臺PaddlePaddle在徐偉博士的帶領下經過三年多研發和打磨，已經應用于包括搜索、翻譯、電商和計算基礎架構等方面共五十余個應用，該項目現已開源。王益在成為百度PaddlePaddle團隊負責人之后，非常希望該項目可以更容易地部署與運行。
王益在與李響等容器專家們的交流討論之后，PaddlePaddle on Kubernetes項目于2016年10月拉開帷幕。
Kubernetes可謂容器生態圈的當紅明星，業界甚至有人斷言 “Kubernetes已經贏得了容器生態的圈地戰爭”；在李響看來，Kubernetes將會是今后的云管理平臺的統治者。
PaddlePaddle on Kubernetes也恰好符合于Kubernetes社區所喜聞樂見的，后者希望將一些流行的應用在Kubernetes上原生運行起來，可以讓更多人感受到Kubernetes的神奇之處。
三、Kubernetes被用來做哪些事情？
Kubernetes 把很多分散的物理計算資源抽象成一個巨大的資源池，它利用這些資源來幫助用戶執行計算任務。對于用戶來說，操作一個分散的集群資源可以像使用一臺計算機一樣簡單。
對于這個項目，Kubernetes 主要負責將學習任務分配到集群的物理節點上進行運算；如果遇到任務失敗的情況，Kubernetes 會自動重啟任務。
具體而言，技術層面需要通過實現fault-tolerable的訓練——AI作業在進程數量發生變化的時候不要暫停或者失敗——來實現機群里各個作業的auto-scaling。Kubernetes可以把很多并發進程組織成service，并且實現auto scaling——白天用戶數量多的時候，增加Web service里的進程數，減少AI作業的進程數。晚上減少Web service里的進程數，釋放資源給AI作業。
四、為什么是Kubernetes，而不是其他？
除了Kubernetes之外，還有Mesos、Fleet和Swarm等容器調度方案。目前還沒有一個開源深度學習框架和Kubernetes深度結合，那為什么百度選擇了Kubernetes呢？
在王益看來，現有容器調度方案們各有千秋，但是PaddlePaddle兼容Kubernetes是開源社區用戶的選擇。
PaddlePaddle最初在百度的集群上運行。但是PaddlePaddle并不依賴特定的并行計算平臺——只要有辦法在一個平臺上啟動PaddlePaddle，就可以運行分布式訓練作業。百度的大數據團隊（BDG）的同學們做了一套PaddlePaddle on Spark系統，確保PaddlePaddle和Spark的兼容。而PaddlePaddle on Kubernetes 要感謝社區貢獻了。
到目前為止，PaddlePaddle on Kubernetes的結合工作也不是百度的PaddlePaddle開發團隊做的，而是由CoreOS公司的etcd項目負責人李響、百度上海JPaaS團隊的周倜、陳國彥、CISCO硅谷辦公室的tech lead陳曦以及百度美研ADU團隊的王鶴麟做的。同時，PaddlePaddle正在和Kubernetes社區合作這項工作，王益稱期待盡快給大家帶來一個驚喜。
五、為什么社區技術人如此喜愛Kubernetes？
在容器圈專家張磊先生看來，相對而言，Kubernetes確實是最好的技術選擇。
單純就離線計算業務而言，“老”項目Mesos在大數據領域被大規模應用多年，固然有著明顯的優勢。但是，要更好地支持深度學習框架作業，Mesos的資源管理和調度能力只能說是錦上添花的功能。
能不能將框架的作業和任務模式，同“容器”這個全新的部署概念匹配起來，才是現階段最重要的。畢竟，如果框架連正常運行起來都很困難，再好的資源利用率提升機制也沒有用武之地。在這一點上，Kubernetes應該說是現有的容器管理項目中做的最好的。
就比如前面已經說過它的Pod設計，就能很好地跟Paddle的作業模型匹配：一個Pod里放兩個容器，分別是參數服務器（parameter server）和訓練器（trainer）。這個匹配并非巧合，而是因為Kubernetes從一開就認為容器之間往往存在像這樣緊密的協作關系，這是“lesson learned from Borg”。只不過在過去，大家都只關注在容器里運行簡單Web服務的時候，才會認為Pod“沒什么用”。
除了Pod，Kubernetes提出的比如Replica（容器副本），Job（計算型任務），StatefulApp（有狀態應用）等諸多已經被業界采納為標準的編排概念，都體現出了這個項目在容器作業管理方面獨到的技術視野（雖然還一度被國內用戶詬病為理念太超前），這一點上其它項目與Kubernetes之間存在著follower和leader的差距。實際上，Kubernetes不僅簡單地解決了容器業務部署和運行的問題，它還關注如何幫助用戶構建容器化分布式服務這個問題，對于在容器化道路上尚需要“摸著石頭過河”的用戶來說，這是非常重要的。
相比之下，Docker的集群模式（Swarm模式）關注的范疇要小很多，相當于Kubernetes在應用管理方面的一個子集。它的關注重點之一是用戶友好，但也為此犧牲了不少可擴展性。對于開發者而言，比如做一個PaaS，這是夠用并且很方便的，但是如果要依賴于它作為基礎設施、甚至在它之上再構建另一套更復雜的系統，這個集群模式就比較難勝任了，如果這中途還需要自己定制和擴展的話，會更加困難重重。
不過Kubernetes也還存在不足：首先，作為一個正在快速演進的項目，Kubernetes本身有很多特性亟待完善，說的直白一點就是潛在的坑還是很多的，這也是采用新技術的必然代價。好在Kubernetes的社區足夠繁榮，一定程度上能夠彌補一些。其次，相比于Swarm模式的用戶友好程度，Kubernetes的Geek氣息依然太濃，很多時候需要用戶自己拿主意（比如“故意”不提供內置的跨主網絡和分布式存儲方案）。
總體上看，要支持PaddlePaddle、Tensorflow這樣非云原生應用（多容器協作，甚至有狀態）項目，Kubernetes目前是個最佳的選擇。
六、對容器圈而言，這是一個里程碑事件
PaddlePaddle on Kubernetes項目的消息一經發布，技術圈內反響強烈。容器圈專家張磊先生，他告訴InfoQ早期的小道消息是在InfoQ的CNUTCon全球容器技術大會2016（注：王益、李響和張磊三位大牛均為大會的講師，技術圈的學習交流社交哦~）的講師晚宴獲知的。當時對Kubernetes的roadmap有了很多討論，后來百度JPaaS組負責了項目的實施。
在張磊看來，這次PaddlePaddle與Kubernetes框架的深度集成算得上一個里程碑事件。容器與容器編排管理技術在過去兩年里的迅猛發展跟去年人工智能集中式的爆發終于產生了深度的化學反應，也讓我們看到一套完善的容器編排與調度體系確實能夠為技術人員帶來更多價值，而非“空有熱度”。這一點是非常重要的，容器熱潮的興起，源自于對的云原生應用（比如輕量級的Web服務）的完美支持，但容器云技術能否最終落地，還取決于它能不能對非云原生應用（傳統服務、復雜應用）有良好的支持和擴展，深度學習框架正是非云原生應用的一個典型案例。
七、容器化實施深度學習的優點
事實上，2016年人工智能熱點爆發的一個強有力推動者正是同樣源自Google的Tensorflow項目，它也很早就進行了同Kubernetes的集成工作。只不過由于師出同門，Tensorflow集成的案例說服力一般。但是現在我們再參考Paddle的集成工作，我們不難看到容器編排和調度平臺對于這類框架的一些獨有優勢。
輕量級
這個輕量級不只只是跟OpenStack比，而是因為哪怕是虛擬機，我們也可以通過HyperContainer的方式接入Kubernetes，繼續對用戶提供秒級的響應能力。這種敏捷性是至關重要的，我們通常都喜歡把容器跟CI/CD聯系在一起，說能夠快速迭代交付云云。實際上，深度學習的訓練過程，才是真正對“快速迭代”有著關鍵需求的作業方式，在這一點上，容器的輕量級特性就凸顯出來了。
更高的資源利用率
深度學習框架的最終目的是提供AI服務，而不是做“挖礦機”，所以任何一個從業者都不可能像比特幣那樣不計成本的投入計算資源。相比于使用物理機或者虛擬化來做計算任務的管理，容器這種操作系統層面的進程封裝已經被證明能夠大大提高作業的部署密度，而Borg等知名項目所提供的理論支持，也對基于容器做資源利用率的進一步提升指明了方向。
基于容器的設計模式
深度學習框架不同于常規Web服務，它有著自己獨有的作業組織和部署模式，一個作業往往需要多個任務協作完成，這就對下層的容器編排和調度系統的設計提出了更高的要求。Kubernetes項目使用Pod這個概念使用戶能夠使用一組容器來完成一組相互協作的任務的編排。這套組織和調度容器的理論被業界成為為容器設計模式，這是基于容器支持深度學習框架另一個獨有的優勢，用虛擬機或者裸機都很難模擬。
高度的可擴展性和容錯能力
這個不多說了，容器對于構建可擴展的分布式服務的便利程度已經被國內外企業實踐過了。
八、容器化實施深度學習的挑戰
容器管理技術的普及也就最近幾年的時間，Kubernetes也是非常年輕的項目，無論跟哪個深度學習框架都不可能100%貼合。接下來容器管理平臺要著重解決的包括：
計算型作業（Job）的管理和調度
當前Kubernetes的Job特性雖然在容器管理領域內算得上是佼佼者，但是跟已經成熟多年的大數據框架相比還差距甚遠的。這一部分的功能進一步完善、甚至能直接對接大多數計算框架已經是板上釘釘的事情。
GPU支持
Kubernetes對GPU支持的投入力度一直很大，目前也走在容器管理領域的前列。但GPU支持對于主流容器技術來說也只是剛剛起步，相比于物理機器和容器對CPU資源管理的完善程度，容器平臺在GPU設備管理、GPU資源共享、多GPU支持、OpenCL等GPU框架支持上還有非常多的空白需要填補。目前這些都已經出現在Kubernetes的路線圖上。
更高級的資源管理
Kubernetes在資源管理模型設計上繼承于Borg，但是相比于前輩強大的資源分配和共享機制，現有的模型在支持計算型任務還很初步，也不能實現離線業務和在線業務高效混部、搶占，也不支持動態的資源邊界。所以這一部分的優化空間還是非常大的，對于進一步提升深度學習作業的效率也非常重要。
九、PaddlePaddle on Kubernetes項目技術細節
兜兜轉轉講了很多宏觀的內容，那么現在讓我們看看項目的技術細節吧。
1、分布式訓練
PaddlePaddle是一個誕生在工業界的系統，從一開始就強調支持分布式訓練。
在PaddlePaddle誕生的年代里，并沒有今天這么多的開源深度學習框架。所以PaddlePaddle的很多設計，在當時都是領先的。其中一些重要的設計決定直到今天都是很獨特的。
PaddlePaddle有parameter server，但是設計思路和Google在DistBelief論文中描述的parameter server很不一樣。DistBelief中的parameter server主要是為了能訓練很大的模型（model parallelism）而設計的。每個trainer進程和每個parameter server進程都只擁有模型的一塊（一部分）。PaddlePaddle的parameter server也支持這樣的使用模式，但是這么大的模型并不常見，所以parameter server的使用模式更經常是用來加速網絡通信。在這種使用模式下，每個trainer都有整個模型，但是每個parameter server只擁有模型的一部分。
通信模式如這篇博客中圖一所示。
http://blog.kubernetes.io/2017/02/run-deep-learning-with-paddlepaddle-on-kubernetes.html
百度經過證明，認為這種通信模式和HPC中經過多年來持續優化的ring-based AllReduce算法的效率是一樣的。而且當模型的梯度矩陣比較稀疏的時候，甚至效率更高。
之前在百度里很多訓練作業的配置是：trainers進程和parameter servers進程的數量一樣。但是其實不一定要是是一樣的。百度希望努力做到根據機群的實際情況，自動動態啟動或者殺死一些進程，使得作業的效率在規定的硬件使用下最高。Kubernetes負責將學習任務分配到集群的物理節點，并且在任務失敗時，實現自動對任務進行重新啟動。
2、映射還是靜態的，將會實現動態
目前主流的開源深度學習框架都沒有動態任務分發機制，而PaddlePaddle也還不能實現動態的協調和容錯。
非動態的映射有兩個缺點：
整體學習任務有可能被延遲甚至終止
在并發規模不是很大的時候，數據分片到trainer的靜態映射是沒問題的。但是當訓練規模變大，或者訓練在通用機群（general-purpose clusters）上進行的時候，經常會碰到有些trainer被更高級別作業擠壓殺死的情況。此時，其他trainer（或者parameter servers）如果要等待所有trainer的gradients的話，訓練作業就陷入死結（halt）了。
資源利用率不能達到最優化
在學習過程中即使有更多的資源可以使用，也不能動態的增加資源。
王益稱PaddlePaddle已經有一個design doc來實現任務的動態分配——引入一個master進程，負責把邏輯數據分片分發給“活著的”trainers進程。這個設計同時考慮到如何用類似Google MapReduce框架的做法，實現訓練作業的“不死”——即便一些trainers或者parameter servers被殺了（搶占了），訓練作業也能繼續進行，只是速度稍慢。當機群上其他高優先級作業結束之后，Kubernetes會增加作業里的trainers數量，此時作業的進行速度也就自然更快了。
李響稱希望今后利用 etcd 這樣的分布式協調系統來專門為 PaddlePaddle 設計一個全局動態管理者組件。這個組件可以幫助 PaddlePaddle 動態地調節資源使用，在集群中有剩余資源的情況下增多學習者，對完成的部分任務設置檢查點等等。
十、未來，敬請期待
對百度而言，PaddlePaddle的目標從來都不是一統江湖，他們認為只有通過鼓勵新的創新不斷出現，才能維護好整個深度學習社區的健康。這樣PaddlePaddle也才有機會借鑒和學習新的創新思路。PaddlePaddle只有一個版本，內外部都使用開源版本。百度不會做openwashing（偽開放）。
當然，沒有完美的系統。和很多項目一樣，PaddlePaddle面臨著不斷增加新功能和維持好代碼的精煉簡潔之間的矛盾。百度告訴InfoQ通過借鑒Keras、mxnet、和DyNet的長處，最近在重構PaddlePaddle的API，接下來要重構分布式計算方法。希望持續保持好PaddlePaddle的健康狀態，并期待三月初給大家帶來一個更加易學易用的PaddlePaddle。
PaddlePaddle on Kubernetes這個項目的執行，是社區的功勞，而并非百度PaddlePaddle團隊成員的工作。PaddlePaddle社區會努力和Kubernetes進一步深化合作，把深度學習對機群管理的需求不斷提給Kubernetes社區，幫助Kubernetes在支持Web服務和數據處理之后，也支持好AI。
對于 PaddlePaddle 和 Kubernetes 融合這個項目來說，在當下更關注的是對開發者友好，因為在初級階段，需要的是更快速地迭代開發普適的功能，而不是局限于去支持現有特定的企業級應用。當項目收獲到越來越多開發者反饋的時候，逐漸成熟并具備強穩定性時，才會考慮根據企業具體情況增加功能。
作者介紹
王益，現任百度深度學習研究院資深科學家，超大規模人工智能系統專家。曾是硅谷AI創業公司Scaled Inference創始科學家，LinkedIn高級主任數據科學家，騰訊社交廣告技術總監，Google研究員。2012年開發的Peacock系統是語意理解系統的世界紀錄保持者，利用三千CPU從數百TB數據中歸納和理解一百萬小眾語意。
李響，CoreOS分布式項目主管，開源項目etcd作者。目前負責Kubernetes、etcd等分布式系統相關項目在CoreOS的開發工作，主要興趣在于分布式一致協議、分布式存儲、分布式系統調度等。
張磊，HyperHQ項目成員，Kubernetes Project Manager和Feature Maintainer。曾任浙江大學科研人員并著有技術書籍《Docker容器與容器云》。目前主要關注大規模容器集群管理和虛擬化容器運行時技術。
