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