一、AI任務的需求與DLC
1.1 AI產品應用
雲原生場景裡面的AI任務到底是什麼樣的？
現在的AI任務，已經廣泛的應用到各種各樣的產品，是生活中不可或缺的一部分，如語言翻譯、淘寶上拍立淘識別商品、天貓精靈人工智能助手等。
此外還有在產品背後呈現的AI技術， 如淘寶上跟據用戶興趣精準推薦用到的推薦系統和廣告系統，也是AI技術。可以說，AI已經滲透到了業務產品中的方方面面。
1.2 AI任務運行平臺
在阿里雲平臺上運用AI任務三大優勢：雲原生、彈性、線性加速。
雲原生
完全基於雲的基礎設施，如Kubernets-native平臺容器化，在各種各樣的機型上都支持AI的任務，各種機器的用戶均可使用。
如果用戶對於資源要求較高，可以用SLA有保證的機型，如果用戶對價格比較敏感，可以用Spot Instance這種價格會波動的機型。藉助雲原生的力量，使得AI可以做到開箱即用。
彈性
支持半托管和全託管的計算資源，用戶在使用計算資源上，比如需要做AI任務，用相應的機器和完整的全套技術棧，把AI任務做完；而當業務不需要計算資源的時候，也不用支付資源的費用，通過全託管去相應控制。半托管和全託管，給到用戶不同的資源控制選擇。
線性加速
結合阿里巴巴內部使用AI計算的平臺上優化的經驗，我們的系統可以為AI任務提供線性加速能力，這通過通過雲上通信優化，以及包括AI模型的數據並行、模型並行等方面的工作來完成，屬於深度學習引擎框架層的範疇。
1.3 AI任務的獨特性
關鍵詞：異構計算資源、多種框架
AI任務不同於在雲上常見的服務計算或大數據計算任務，AI任務有自己的獨特性。
1）AI用戶會使用異構計算資源。現在較為通用的是GPU。GPU提供更強的算力，但價格較為昂貴，典型的GPU機型價格是 CPU機型的10倍。
因為GPU的廣泛應用，出現新的異構通信鏈路，如英偉達的GPU使用 NVLINK進行GPU之間的通信。機器間的通信方式是使用RDMA,可以bypass遠程的 CPU進行通信。隨著數據量越來越大，大規模的分佈式計算才能滿足很多用戶的這種大數據計算訴求。這些是從計算資源與底層硬件的角度來看AI任務的獨特性。
2）AI任務是多種框架，現在用的框架非常的多，AI是比較籠統的稱謂，裡面包括深度學習、相對傳統意義點的決策、AI的算法，還有為特定應用開發的框架。如X-DeepLearning是阿里巴巴廣告團隊開發的深度學習框架,在廣告領域使用效果優秀。
1.4 雲原生深度學習平臺DLC架構
為了在雲上支持AI任務，我們設計了DLC產品，DLC呈現的技術架構如下圖所示：
首先它是建立在雲原生的ECS Clusters上面的，通過在原有的支持K8s的ACK的集群添加相應的DLC的組件，使得它可以變成DLC的集群，於是它可以直接擁有相應的AI能力，包括對AI任務的提交控制能力、享受對應的框架層和系統層的優化。
整體架構圖如下：
最上層提供DLC Control Panel提供相應的管控、彈性支持，使得用戶可以很容易在上面提交自己的任務，做到開箱即用。中間核心層則由PAI-Tensorflow與PAI-PyTorch兩個框架進行支持。
我們提供深度定製的深度學習框架，在兼容社區的基礎上做了進一步的優化，結合阿里內部的場景進行錘鍊，其能力通過雲上的方式輸出，讓更多的用戶直接用上優化的效果。因為GPU很貴，比如加速兩倍，就相當於節省一半的 GPU的資源，這對用戶來說非常重要。
KubeDL Pro的CRD底層會結合在ALIYUN Cloud Kubernets的調度、容器化、GPU共享、Quota相關的優化，使得用戶可以用較為便宜的方式使用資源，比較高效使用上 AI硬件這種獨特的通信，還有計算的能力等。底層是支持現有的雲原生的所有機型、通信還有存儲方式。
二、KubeDL
KubeDL三大特性：
雲原生支持AI；
易擴展支持更多AI workload；
機器學習能力統一擴展。
2.1 雲原生支持AI
為了能夠在雲原生的場景裡面支持AI，我們跟阿里雲團隊一起合作開發了KubeDL任務提交組件，採用All-In-One的理念，使得可在一套通用開發operator上支持TensorFlow、PyTorch等典型的深度學習計算任務提交，也支持稀疏模型、樹模型等典型框架，如下圖所示：
它有三大特點：
第一,提供Unified Operator，兼容所有主流的框架，沉澱通用調度的能力。
第二,是通過插件化的調度能力，使得其可以非常容易的適配各種底層不同的調度器，提供相應的功能，如對AI來說很重要的GANG Scheduling。
第三,把代碼和基礎鏡像做了一個解耦，使得做算法的同學只需專注代碼問題，底層問題由我們解決。
第四，提供相應的Dashboard和監控的Panel，可以提供全週期任務的監控，白屏化整個管理流程。
以上內容已在GitHub上面開源，可掃圖中的二維碼查看。
2.1易擴展支持更多AI workload
KubeDL可以做一些針對性的擴展，支持更多的AI workload。
經典案例·大規模的工業界的圖神經網絡分佈式框架GraphLearn。
GraphLearn框架目前已經應用在淘寶的搜索推薦裡面。使用淘寶的用戶都有這種體驗，淘寶會根據用戶平時刷淘寶看到的相關物品，通過瀏覽記錄和購買記錄，推薦相似物品，其背後都是一套圖神經網絡。它會分析用戶的瀏覽，還有商品之間的特性，從而把圖信息嵌入到深度學習裡面，從而推斷用戶興趣愛好，而圖神經網絡是目前深度學習中的熱門流派。
上圖是一個典型的TF任務，採用PS-worker架構，PS節點主要用於存儲模型，對應的還有Work節點，它通過加載數據，從Ps節點上面獲取相應模型，對數據在模型上做計算，最後把計算結果更新到模型之上來完成一個迭代訓練流程。
雲原生場景裡面對於TF-Worker的支持，最早是屬於TF-Opreator開發，現在KubeDL上面也可跟社區一樣兼容對於TF任務的提交方式。
隨著圖神經網絡在更多的領域得以廣泛應用，我們也想把圖神經網絡的能力跟TF結合，這裡引入GraphLearn-Server角色概念。不同於TF-Worker和TF-PS的計算節點，它通過把圖數據進行預處理，還有圖分割的相關操作，允許用戶通過編程方式進行採樣、聚合等操作，把最後結果同時反饋到TF-Worker，聯合進行深度學習訓練。
GraphLearn是一個圖神經網絡框架，如何在雲原生場景裡面加入這個角色，使得它可以跟已有的TF很容易工作起來。而GraphLearn也有自己的要求，它在啟動順序上有需求，即圖神經網絡要求GraphLearn必須比TF-Worker 先啟動起來，當Worker處理的時候，能夠得到 Server相應的響應。GraphLearn還基於一套不同於TF的地址發現機制，需要在KubDL裡面能夠一併進行支持。
KubDL的架構設計較為完善，把啟動順序進行了相應的抽象，添加GraphLearn的角色並達到上述功能可以很輕鬆的完成。我們總共僅需要10+行代碼改動，就可以完美支持圖神經網絡。
2.3 KubeDL：機器學習能力統一擴展
經典案例·GANG Schedule
我們還是沿用圖神經網絡的場景來介紹GANG Schedule的問題，在引入圖神經網絡節點之後，有別於社區的TF。把新角色在同樣的任務裡做GANG Schedule，這在原生的TF-Operator裡面並不支持。
在KubeDL裡很容易做到，對於庫底層，上面無論定義多少角色及類型，只要滿足角色定義的邏輯，都會把它當成資源的Role，然後統一做GANG Schedule。
通過引入這一點，KubeDL可在底層做同時滿足Cpu/Gpu的異構資源申請。例如， TF work會需要用到GPU來做加速計算，而PS和GraphLearn都只需要CPU，這裡調度的時候，GANG Schedule考慮多種不同計算Role， GraphLearn與TF原生角色，一起進行了資源考量和任務拉起。 
所有資源檢查完畢，在集群裡面會放行與調度執行，如果這一點沒做好，可能其中一部分的角色已啟動，另外一部分角色沒有足夠的資源，整個任務就hang在那，其餘用戶也無法使用這些資源，嚴重的話會造成資源死鎖。
此外還需要統一的Quota檢查，用戶相應的Quota需要全部滿足才可執行。這些可在底層統一做，它並不只是針對GraphLearn的角色，包含任務所需要的所有角色，也可以不需要任何改動的擴展到包括原生TF在內的其他框架。
因為雲上追求靈活性，不同的用戶會選擇不同方案及對應調度器，例如社區裡，就有Kube-batch對大數據計算來設計的調度器，現在也可支持AI的任務。而KubeDL的GANG Schedule能力可以支持Kube-batch，當然也可以延伸擴展到支持任意調度器。 KubeDL還可以支持ASI調度器，這是阿里內部支持雙11日常的任務調度的高性能調度器，ASI上的能力也可通過KubeDL調用和實現，而YuniCorn調度器也同樣支持。
三、KubeDLPro
在KubeDL的工作中，我們完成了對於深度學習任務的基本支持，而KubeDLPro誕生，源自於我們對於AI任務運算的特性需求的深入的理解與新硬件的挑戰。
3.1 深入理解 AI任務運算的特性
做 AI任務調度，首先需要深入理解 AI任務運算的特性。
上圖左邊是對阿里內部計算任務做的一個統計， 80%計算任務命令Mini-batch時間約為600個毫秒以內，這樣的頻繁數據同步是AI Flow一個典型的要求。
從深度學習模型參數如今的發展上看，兩三年前Bert的參數與如今最大模型PPT3相比之下已經非常小，說明用數據並行的方式在訓練一個模型的時，如果80%的任務，可能每600毫秒需要通信整個模型參數的數據量，如今的模型通信的數據量非常大，對於整個的網絡帶寬都有個比較大的挑戰。
3.2 新硬件的挑戰
從底層硬件角度看，發現隨著AI任務的引進，底層硬件也豐富起來。 比如GPU，現在用的非常多的V100、A100等。阿里也有一些相應的AI推理的芯片，如含光800芯片，可以加速整個任務推理，在雲上還有RDMA-Nic、SmartNic這種相應的通信優化的這種硬件。如何把上下兩層之間，去彌合計算任務特性，以及跟底層硬件相關的間隙，對於AI任務的性能就顯得至關重要。而我們通過通信、計算、存儲、資源調度以及整套的監控相應的優化，試圖去解決這個問題，這就是KubeDLPro。
3.3 KubeDLPro：拓撲感知調度
接下來介紹現在在KubeDLPro上面實現的一個能力，叫拓撲感知調度，通過下圖展示一下它的功能。 
舉個例子，用戶提交一個PyTorch任務，假設PyTorch任務需要4個GPU,這個任務用戶就會起4個Worker，每個圓圈代表一個Worker，每個Worker運行在1個GPU上。
傳統的調度方法會把這4個Pod放到一個資源池裡面，調度器查看哪裡的資源有一些空閒，就按照某一調度的策略做一個擺放。但是，實際上AI計算資源池並不是像之前那麼簡單。
上述例子調度執行後可以發現，其實任務被放在了兩個不同的機器上，這裡面橘黃色的模塊表示一個機器，然後機器上它又有不同的GPU，每個GPU之間呈現不同的拓撲連接，而且並不是一個完全對稱的。
上圖展示的是一個典型v100的機型，每個綠色的方框代表一個GPU，黑色的線代表了GPU之間是通過NVLINK進行連接。
其中NVLINK在GPU通信是裡面較為重要的硬件。
首先它的帶寬比Pcie大很多，可能幾倍於Pcie的帶寬。
其次它可以使GPU跟GPU之間的通信做到零拷貝，不需要通過CPU，從而減少了數據搬移的代價。
在這個調度的場景裡面，由於傳統的方法並不關注和感知底層的數據網絡通信拓撲，它有可能一個調度把整個PyTorch任務調到了兩個機器、各使用兩個GPU，並且同個機器內的GPU，甚至無法用NVLINK進行聯繫。拓撲感知調度就是感知底層的一些拓撲信息以及任務對通信的一個需求，它可以在空閒的資源裡面選擇最佳的、緊湊的、通信帶寬大的機器/GPU來放置計算任務。 
這種NVLINK帶來的P2P GPU Direct通信的好處，一是不用數據拷貝，二是不用CPU跟GPU之間進行數據通信，三是0內核調用。
具體實現方法
首先做一層統一的感知設備間的通信能力，感知的東西，包括現在的NVLINK，然後PcleSwitch。比如同一個PcleSwitch的通信，會比跨PcleSwitch要差了百分之幾十。QPI是不同的CPU socket之間連接的通信，此外還包括RDMA NIC，因為RDMA可以用上GPU Direct。AI任務的性能，在TCP網絡和RDMA網絡上也會呈現不同的效果。
以上優化內容均先在阿里巴巴內部GPU集群上面部署驗證，我們針對於阿里內部典型的ALLReduce式的深度學習模型，可以帶來1.12到10.54的性能提升。在雲原生環境中，我們用PyTorch 10w分類任務做一個評估，與現有的社區的實現，兩者相差就可以達到10倍的性能。
而觀察發現，在阿里巴巴內部整個集群的角度，通過拓撲感知調度，NVLINK通信資源的利用率得到4倍的提升，有更多的任務及計算可以通過NVLINK的大帶寬、免拷貝形式能夠更快速完成。
3.4 拓撲感知調度系統架構
具體做法如上圖所示，從下往上看，這裡有4個GPU，NVLINK、PCleSw表示不同的網絡拓撲連接，做一層Enhanced NVIDIA Device Plugin，從硬件的角度把拓普關聯的關係抽取出來，把信息發給KubeDL的 Operator及集群調度器，使得可感知底層的硬件資源的拓撲。KubeDL會做拓撲感知Job的調度，通過調度器提供的資源預佔的接口，使得它不只是做GANG的時候考慮任務之間使用GPU時相關聯的特性，從而為它分配更大帶寬、更好的通信位置，做到精準的GPU級別調度的分配。
主要的改動在三個層面，第一層是在KubeDL，第二層是在Scheduler Framework裡面改Scheduler，第三層是在Enhanced整個的NVIDIA Device Plugin。
3.5 拓撲感知調度系統實現
上圖是實現整個大體的邏輯，用戶提交一個ALL-Reduce 任務，首先來到KubeDL，KubeDL會把相應的信息提交給GPU Coordinator，再生成資源預佔的CRD,與此同時Device plugin上報的GPU拓撲保存在 CRD裡。GPU Coordinator根據GPU拓撲的CRD以及任務資源需求的CRD分析做匹配，將整個任務所有需求考慮。進而調用調度器提供的預留資源接口，將這個任務預佔，最終把相應的Pod的信息提交到調度器。調度器會做pod的調度消費，將剛才預留過的資源精準分配給相應的Pod，完成整個任務的調度，這就是對基礎版的拓撲感知調度的實現方式。
上面的實現始於阿里內部GPU集群的驗證，而我們也發現當下的硬件能力在社區的調度方案無法充分發揮其效果，於是把這個方案輸出到阿里雲的雲原生平臺，我們希望能讓更多的人能夠享受這樣的服務。
3.6 直觀舉例分析
進一步的，舉個直觀的例子，當要提交一個8卡的深入學習任務，要用怎樣的一個方式去提交？
比如單機8卡，所有東西都放到一個進程，指定去做通信設定，進一步拓展可以2機4卡， 4機2卡，極端情況做完全分佈式8機1卡。上述不同提交方法各有利弊。1機8卡可以控制相應的計算資源，能讓任務去走相應的NVLINK進行通信，缺點是無法快速獲取資源。分佈式的8機1卡優點在於，即使當集群裡面存在一些碎片時，也可以更快拿到相應資源，比起1機8卡，其資源粒度更細，更容易拿到所需的資源，因而等待時間更短。
但現實情況是整個集群大多數情況，用戶任務都在運行，不斷的有任務完成，和到達，機器裡剩餘的可用卡數不同，並不是規整的2卡4卡8卡這種情況。這個問題應該如何解決？
在一個忙碌的集群裡面，確實很難找到這種規整GPU的計算資源，於是就會出現一個問題。如下圖所示，用戶買了4個機器，每個機器8塊卡一共32，目前空閒16塊卡，用戶希望提交一個2機每機4卡的任務，但無法提交。 
其本質原因在於，集群裡面找不到兩個機器滿足2機每機4卡的需求，因此這個任務被迫等待。可以發現， 2機4卡並不是唯一解決辦法，如果以“3+5”的形式執行該任務，那麼整個任務完成時間其實與提交2機4卡的任務一樣。
在實際場景中，用戶不知道當前跑的集群剩餘資源的情況，所以也無法提前作出3+5這種資源申請，因此需要系統運行結合調度的情況，給用戶做資源申請形狀的改變，讓用戶在等待時間和運行時間上達到平衡。
而從用戶側，其實1機8卡和8機1卡所需要的代碼完全不同，許多用戶在這上面非常糾結。我們通過系統層能力來做到自動平衡，使用戶編碼上不用糾結。
拓撲感知自動聚合
進一步對拓撲感知做擴展，擴展到拓撲感知加自動聚合。建議用戶在編碼時完全按照分佈式方式做編程，讓用戶寫PyTorch的任務，以PyTorch DDP的方式，剛剛的例子寫成一個8機的1卡。
通過KubeDL加上PAI框架，PyTorch裡面相應的一些改動來支持用戶行為，它會自動的選擇。
第一是自動選擇最佳的通訊拓撲。
第二是實現了跨Pod NVLINK的通信，現在社區的方案跨了Pod，無法看到另外一個GPU，也無法進行相應的NVLINK通信，會變成走Share Memory或者網絡的情況。
第三是當這個Pod對其他Pod的 GPU可見時，通過框架自動分配 GPU的設備到相應的PyTorch Worker上，這需要改動相應框架知道在使用哪塊卡。
上面舉例的8卡任務，在這個場景裡面可以被自動捕捉，然後以“7+1”（如上圖所示）的形式運行。它與用戶最初設想的兩個機器裡面4張卡的情況相比，性能也完全一樣。目前整體該功能囊括在PAI DOC的產品裡，TensorFlow和PyTorch均支持這樣的功能。
四、總結
綜上所述，雲原生場景中的AI任務調度工作主要如下：
第一，是提供了完全開源的KubeDL組件，做到方便擴展，同時兼容社區所有的Tf-operator/PyTorch-operator等深度學習應用提交工具的接口。
第二，基於這套組件可以簡易地進行擴展，許多開發者需要通過KubeDL來實現一些 AI任務提交，我們都有教學文檔幫助大家實現。通過All-In-One理念，只要實現很簡單的Operator，該任務就擁有底層相應資源優化的能力，通過調度器與AI框架做一些協調設計，在阿里內部的一些AI實現這種優勢特性和能力，通過兼容社區的Operator、調度器的形式進一步透出，讓 AI框架跟調度進行聯動，硬件資源可得到充分利用。
第三，觀察到大部分AI任務的用戶都是算法工程師，他們在研究算法調參上花費大量時間，但對於系統底層並不是特別瞭解，需要我們對用戶做到功能透明，使用戶無需操心繫統實現和硬件細節就可達到預期效果。GPU價格昂貴，我們希望能夠不斷優化做任務的訓練速度，提升整個集群資源利用率和任務吞吐率。
（分享人：肖文聰）
瞭解PAI-DLC雲原生深度學習訓練平臺，請訪問官網：https://www.aliyun.com/activity/bigdata/pai-dlc
歡迎加入PAI釘釘群交流：
https://h5.dingtalk.com/invite-page/index.html?bizSource=____source____&corpId=dingd0cf799086f27cb135c2f4657eb6378f&inviterUid=F21988A2A1749D4394460A2FDF52346D&encodeDeptId=0746DEFF8740D17C91E7FE61FE0552A6
