2021 年 6 月 23 日，云原生計(jì)算基金會(huì)（CNCF）宣布通過全球 TOC 投票接納 KubeDL 成為 CNCF Sandbox 項(xiàng)目。KubeDL 是阿里開源的基于 Kubernetes 的 AI 工作負(fù)載管理框架，取自"Kubernetes-Deep-Learning"的縮寫，希望能夠依托阿里巴巴的場景，將大規(guī)模機(jī)器學(xué)習(xí)作業(yè)調(diào)度與管理的經(jīng)驗(yàn)反哺社區(qū)。

項(xiàng)目地址：http://kubedl.io

項(xiàng)目介紹

隨著 TensorFlow, PyTorch，XGBoost 等主流 AI 框架的不斷成熟，和以 GPU/TPU 為代表的多種AI異構(gòu)計(jì)算芯片的井噴式涌現(xiàn)，人工智能正快速進(jìn)入“大規(guī)模工業(yè)化”落地的階段。從算法工程師著手設(shè)計(jì)第一層神經(jīng)網(wǎng)絡(luò)結(jié)構(gòu)，到最終上線服務(wù)于真實(shí)的應(yīng)用場景，除 AI 算法的研發(fā)外還需要大量基礎(chǔ)架構(gòu)層面的系統(tǒng)支持，包括數(shù)據(jù)收集和清理、分布式訓(xùn)練引擎、資源調(diào)度與編排、模型管理，推理服務(wù)調(diào)優(yōu)，可觀測等。如以下經(jīng)典圖例所展示，眾多系統(tǒng)組件的協(xié)同組成了完整的機(jī)器學(xué)習(xí)流水線。

與此同時(shí)，以 Kubernetes 為代表的云原生技術(shù)蓬勃發(fā)展，通過優(yōu)秀的抽象和強(qiáng)大的可擴(kuò)展性，將應(yīng)用層與 IaaS（Infrastructure as a Service）層的基礎(chǔ)設(shè)施完美解耦：應(yīng)用能夠以“云”的范式按需使用資源，無需關(guān)注底層基礎(chǔ)設(shè)施的復(fù)雜性，從而解放生產(chǎn)力并專注于自身領(lǐng)域的創(chuàng)新。

Kubernetes 的出現(xiàn)解決了云資源如何高效交付的問題，但對于 AI 這類本身具備高度復(fù)雜性的工作負(fù)載還無法做到很好地原生支持，如何整合各類框架的差異并保留其通用性，同時(shí)圍繞 AI 工作負(fù)載的運(yùn)行時(shí)去建設(shè)一系列完善的周邊生態(tài)及工具，業(yè)界還在不斷探索與嘗試。在實(shí)踐中，我們發(fā)現(xiàn)了 AI 負(fù)載運(yùn)行在 Kubernetes 生態(tài)中面臨著如下挑戰(zhàn)：

機(jī)器學(xué)習(xí)框架百花齊放，各自有不同的優(yōu)化方向和適用場景，但在分布式訓(xùn)練作業(yè)的生命周期管理上又存在著諸多共性，同時(shí)針對一些高級特性也有相同的訴求（如網(wǎng)絡(luò)模式，鏡像代碼分離，元數(shù)據(jù)持久化，緩存加速等）。為每類框架的負(fù)載單獨(dú)實(shí)現(xiàn) operater，各自獨(dú)立進(jìn)程無法共享 state，缺乏全局視角，使得全局 Job 層面的調(diào)度以及隊(duì)列機(jī)制難以實(shí)現(xiàn)。此外，不利于功能的抽象和復(fù)用，在代碼層面存在重復(fù)勞動(dòng)。
原生 Kubernetes 無法滿足離線任務(wù)多樣的調(diào)度需求。Kubernetes 面向 Pod 調(diào)度的模型天然適用于微服務(wù)等 Long Running 的工作負(fù)載，但針對離線任務(wù)的高吞吐，Gang Scheduling 調(diào)度（All-Or-Nothing），Elastic Capacity 等多種調(diào)度訴求，社區(qū)演進(jìn)出了多種調(diào)度方案。以機(jī)器學(xué)習(xí)分布式訓(xùn)練作業(yè)調(diào)度場景中極為常見的Gang Scheduling為例，社區(qū)目前就有YuniKorn，Volcano，Coscheduling 等調(diào)度器實(shí)現(xiàn)，提供不同的交互協(xié)議，我們需要有插件化的手段來啟用對應(yīng)的調(diào)度協(xié)議。同時(shí)，像 PS/worker 這類根據(jù)業(yè)務(wù)特有屬性，不同 role 之間有啟動(dòng)依賴的 DAG 編排訴求，需要在控制器中實(shí)現(xiàn)；
分布式訓(xùn)練的結(jié)果往往以模型作為 output，并存儲(chǔ)在分布式文件系統(tǒng)中如(阿里云 OSS/NAS)，但如何從訓(xùn)練作業(yè)的視角去管理模型，像容器鏡像那樣成為AI服務(wù)的“不可變基礎(chǔ)設(shè)施”并實(shí)現(xiàn)簡單且清晰的版本管理與追溯，業(yè)界還缺乏最佳實(shí)踐。同時(shí)，“訓(xùn)練”與“推理”兩個(gè)階段相對獨(dú)立，算法科學(xué)家視角中的“訓(xùn)練->模型->推理”機(jī)器學(xué)習(xí)流水線缺乏斷層，而“模型”作為兩者的中間產(chǎn)物正好能夠充當(dāng)那個(gè)“承前啟后”的角色；
分布式訓(xùn)練尚能大力出奇跡，但推理服務(wù)的規(guī)格配置卻是一個(gè)精細(xì)活。顯存量、 CPU 核數(shù)、BatchSize、線程數(shù)等變量都可能影響推理服務(wù)的質(zhì)量。純粹基于資源水位的容量預(yù)估無法反映業(yè)務(wù)的真實(shí)資源需求，因?yàn)槟承┮嫒?TensorFlow 會(huì)對顯存進(jìn)行預(yù)占。理論上存在一個(gè)服務(wù)質(zhì)量與資源效能的最優(yōu)平衡點(diǎn)，但它就像黑暗中的幽靈，明知道它的存在卻難以琢磨。隨著 GPU 虛擬化技術(shù)的成熟，這個(gè)平衡點(diǎn)的價(jià)值越來越凸顯，更優(yōu)的規(guī)格能顯著提供單 GPU 卡的部署密度，節(jié)約大量的成本。
推理服務(wù)本身是一種特殊的 long running 微服務(wù)形態(tài)，除了基礎(chǔ)的 deployment 外，針對不同的推理場景還欠缺一些實(shí)例與流量的管理策略，如：

1) 算法科學(xué)家通常會(huì)同時(shí)部署兩個(gè)甚至多個(gè)不同版本的模型實(shí)例進(jìn)行 A/B Test 以驗(yàn)證最佳的服務(wù)效果，需要基于權(quán)重的精細(xì)化流量控制；

2) 能夠根據(jù)流量請求水平和當(dāng)前推理服務(wù)的 metrics 來自動(dòng)觸發(fā)實(shí)例的擴(kuò)縮，在充分保障服務(wù)可用性的前提下最小化資源成本等等。

KubeDL

針對上述難題，阿里巴巴云原生，集群管理和 PAI 團(tuán)隊(duì)將管理大規(guī)模機(jī)器學(xué)習(xí)工作負(fù)載的經(jīng)驗(yàn)沉淀為通用的運(yùn)行時(shí)管理框架——KubeDL，涵蓋分布式訓(xùn)練，模型管理，推理服務(wù)等機(jī)器學(xué)習(xí)流水線的各階段，使工作負(fù)載能夠高效地運(yùn)行在 Kubernetes 之上。

1、分布式訓(xùn)練

KubeDL 支持了主流的機(jī)器學(xué)習(xí)分布式訓(xùn)練框架（TensorFlow / PyTorch / MPI / XGBoost / Mars 等），其中 Mars 是阿里巴巴計(jì)算平臺(tái)開源的基于張量的大規(guī)模數(shù)據(jù)計(jì)算框架，能夠分布式地加速 numpy，pandas 等數(shù)據(jù)處理框架的效率，幫助 Mars 作業(yè)以更 native 的方式集成進(jìn)云原生大數(shù)據(jù)生態(tài)中。

我們將各類訓(xùn)練作業(yè)生命周期管理中的共同部分進(jìn)行抽象，成為一層通用的運(yùn)行時(shí)庫，被各分布式訓(xùn)練作業(yè)控制器復(fù)用，同時(shí)用戶也可以在此基礎(chǔ)上快速擴(kuò)展出自定義的 workload 控制器并復(fù)用現(xiàn)有的能力。借助聲明式 API 與 Kubernetes 網(wǎng)絡(luò)/存儲(chǔ)模型，KubeDL 能夠進(jìn)行計(jì)算資源的申請/回收，各 Job Role 之間的服務(wù)發(fā)現(xiàn)與通信，運(yùn)行時(shí)的 Fail-over 等，算法模型的開發(fā)者只需聲明好此次訓(xùn)練依賴的 Job Role 及各自的副本數(shù)，計(jì)算資源/異構(gòu)資源數(shù)量等，然后提交任務(wù)。另外，我們針對訓(xùn)練領(lǐng)域的痛點(diǎn)也做了諸多的特性設(shè)計(jì)來提升訓(xùn)練的效率與體驗(yàn)：

不同的訓(xùn)練框架往往包含不同的 Job Role，如 TensorFlow 中的 PS/Chief/Worker 和 PyTorch 中的 Master/Worker，Role 與 Role 之間往往隱含著依賴關(guān)系，如 Worker 依賴 Master 啟動(dòng)之后才能正常開始計(jì)算，錯(cuò)亂的啟動(dòng)順序不僅容易造成資源長時(shí)間空轉(zhuǎn)，甚至可能引發(fā) Job 直接失敗。KubeDL 設(shè)計(jì)了基于 DAG（Direct Acyclic Graph）的調(diào)度編排控制流，很好地解決了 Role 之間的啟動(dòng)依賴順序，并能夠靈活擴(kuò)展。
大模型的訓(xùn)練時(shí)長往往受制于計(jì)算節(jié)點(diǎn)間的通信效率，RDMA 等高性能網(wǎng)絡(luò)技術(shù)的應(yīng)用將極大地提升了數(shù)據(jù)的傳輸速度，但這些定制網(wǎng)絡(luò)往往需要計(jì)算節(jié)點(diǎn)使用 Hostnetwork 進(jìn)行互相通信，同時(shí)有些時(shí)候由于環(huán)境限制無法提供基于 Service 模式的服務(wù)發(fā)現(xiàn)機(jī)制。這就需要作業(yè)管理引擎能夠支持 Host 網(wǎng)絡(luò)模式下的服務(wù)發(fā)現(xiàn)機(jī)制，處理好各計(jì)算節(jié)點(diǎn)的網(wǎng)絡(luò)端口分配，并與各訓(xùn)練框架的特性結(jié)合來處理節(jié)點(diǎn) Fail-over 后的網(wǎng)絡(luò)連通性，KubeDL 支持了 Host 網(wǎng)絡(luò)模式下的高性能分布式訓(xùn)練。
Gang Scheduling 是分布式訓(xùn)練作業(yè)調(diào)度場景中的常見需求，組成單個(gè)訓(xùn)練作業(yè)的一簇 Pod 往往要求同時(shí)被調(diào)度，避免在集群容量緊張時(shí)因作業(yè)間的資源競爭出現(xiàn)活鎖，但 Kubernetes 強(qiáng)大的可擴(kuò)展性也使得不同的調(diào)度器實(shí)現(xiàn)了不同的 Gang Scheduling 協(xié)議，如 YuniKorn, KubeBatch 等。為了避免與具體調(diào)度器實(shí)現(xiàn)的耦合，適應(yīng)不同用戶環(huán)境的差異，KubeDL 將 Gang Scheduling 的協(xié)議實(shí)現(xiàn)插件化，按需啟用對應(yīng)的插件即可與調(diào)度器相互協(xié)作，實(shí)現(xiàn)作業(yè)的批量調(diào)度。
Job 是一次性的，但在實(shí)際的生產(chǎn)應(yīng)用中我們經(jīng)常會(huì)遇到反復(fù)訓(xùn)練/定時(shí)訓(xùn)練的場景，如每日拉取某一時(shí)間區(qū)間的離線表并進(jìn)行數(shù)據(jù)清洗以及模型的 Re-train，KubeDL 提供了一類單獨(dú)的工作負(fù)載—Cron 來處理定時(shí)的訓(xùn)練請求，并支持任意類型的訓(xùn)練作業(yè)（如 TFJob，PyTorchJob 等），用戶可以提交 cron tab 風(fēng)格的定時(shí)命令及作業(yè)模板，并在 Cron 資源的狀態(tài)中追蹤訓(xùn)練作業(yè)的歷史及當(dāng)前進(jìn)行中的作業(yè)。
針對海量離線作業(yè)元數(shù)據(jù)需要長時(shí)間保存（Job CRD 被刪除后元數(shù)據(jù)即從 etcd 銷毀）的訴求，KubeDL 還內(nèi)置了元數(shù)據(jù)的持久化，實(shí)時(shí)監(jiān)聽 Job/Pod/Events 等資源對象的變化，轉(zhuǎn)化成對應(yīng)的 Databse Schema Object 并持久化到存儲(chǔ)后端中。存儲(chǔ)后端的設(shè)計(jì)也是插件化的，用戶可以根據(jù)自己的線上環(huán)境來實(shí)現(xiàn)存儲(chǔ)插件并在部署時(shí) enable。在 KubeDL 中 Job/Pod 默認(rèn)支持了 Mysql 的存儲(chǔ)協(xié)議，以及將 Events 收集到阿里云 SLS 服務(wù)中。

同時(shí)我們還提供了管控套件：KubeDL-Dashboard，用戶不需要去理解 Kubernetes 的眾多 API 并在各種 kubectl 命令中掙扎，即可界面化地上手簡單易用的機(jī)器學(xué)習(xí)作業(yè)。持久化的元數(shù)據(jù)也可以直接被 Dashboard 消費(fèi)使用。Dashboard 提供了簡單的作業(yè)提交、作業(yè)管理、事件/日志查看、集群資源視圖等功能，以極低的學(xué)習(xí)門檻幫助機(jī)器學(xué)習(xí)用戶上手實(shí)驗(yàn)。

2、推理服務(wù)規(guī)格調(diào)優(yōu)

GPU 虛擬化與分時(shí)復(fù)用技術(shù)的發(fā)展和成熟，讓我們有機(jī)會(huì)在一塊 GPU 上同時(shí)運(yùn)行多個(gè)推理服務(wù)，顯著降低成本。然而如何為推理服務(wù)選擇合適的 GPU 資源規(guī)格，尤其是不可壓縮的顯存資源，成為一個(gè)關(guān)鍵難題。一方面，頻繁的模型迭代讓算法工程師無暇去精確估計(jì)每個(gè)模型的資源需求，流量的動(dòng)態(tài)變化也讓資源評估變得不準(zhǔn)確，因此他們傾向于配置較多的 GPU 資源冗余，在穩(wěn)定性和效率之間選擇犧牲后者，造成大量浪費(fèi)；另一方面，由于 Tensorflow 等機(jī)器學(xué)習(xí)框架傾向于占滿所有空閑的顯存，站在集群管理者的角度，根據(jù)顯存的歷史用量來估計(jì)推理業(yè)務(wù)的資源需求也非常不準(zhǔn)確。在 KubeDL-Morphling 這個(gè)組件中我們實(shí)現(xiàn)了推理服務(wù)的自動(dòng)規(guī)格調(diào)優(yōu)，通過主動(dòng)壓測的方式，對服務(wù)在不同資源配置下進(jìn)行性能畫像，最終給出最合適的容器規(guī)格推薦。畫像過程高度智能化：為了避免窮舉方式的規(guī)格點(diǎn)采樣，我們采用貝葉斯優(yōu)化作為畫像采樣算法的內(nèi)部核心驅(qū)動(dòng)，通過不斷細(xì)化擬合函數(shù)，以低采樣率（<20%）的壓測開銷，給出接近最優(yōu)的容器規(guī)格推薦結(jié)果。

3、模型管理與推理服務(wù)

模型是訓(xùn)練的產(chǎn)物，是計(jì)算與算法結(jié)合后的濃縮精華，通常收集與維護(hù)模型的方式是托管在云存儲(chǔ)上，通過組織文件系統(tǒng)的方式來實(shí)現(xiàn)統(tǒng)一管理。這樣的管理方式依賴于嚴(yán)格的流程規(guī)范與權(quán)限控制，沒有從系統(tǒng)層面實(shí)現(xiàn)模型管理的不可變，而容器鏡像的誕生解決的就是 RootFS 的構(gòu)建-分發(fā)-不可變等問題，KubeDL 將兩者進(jìn)行結(jié)合，實(shí)現(xiàn)了基于鏡像的模型管理。訓(xùn)練成功結(jié)束后，通過 Job Spec 中指定的 ModelVersion 會(huì)自動(dòng)觸發(fā)模型鏡像的構(gòu)建。用戶可以在 ModelVersion.Spec 中約定模型的存儲(chǔ)路徑，目標(biāo)的鏡像 Registry 等基本信息，將每次的訓(xùn)練輸出 Push 到對應(yīng)的鏡像倉庫。

同時(shí)鏡像作為訓(xùn)練的輸出，以及推理服務(wù)的輸入，很好地串聯(lián)起了兩個(gè)階段，也借此實(shí)現(xiàn)了分布式訓(xùn)練->模型構(gòu)建與管理->推理服務(wù)部署的完整機(jī)器學(xué)習(xí)流水線。KubeDL 提供了 Inference 資源對象提供推理服務(wù)的部署與運(yùn)行時(shí)控制，一個(gè)完整的 Inference 服務(wù)可以由單個(gè)或多個(gè) Predictor 組成，每個(gè) Predictor 對應(yīng)前序訓(xùn)練輸出的模型，模型會(huì)被自動(dòng)拉取并掛載到主容器 Volume 中。當(dāng)多個(gè)不同模型版本的 Predictor 并存時(shí)，可以根據(jù)分配的權(quán)重進(jìn)行流量的分發(fā)與控制，達(dá)到 A/B Test 的對照實(shí)驗(yàn)效果，后續(xù)我們還會(huì)在 Batching 批量推理和 AutoScale 上針對推理服務(wù)場景做更多的探索。

KubeDL 分布式訓(xùn)練在公有云上的實(shí)踐

PAI-DLC

隨著云計(jì)算的深入人心以及越來越多的業(yè)務(wù)都用云原生的方式進(jìn)行，阿里云計(jì)算平臺(tái) PAI 機(jī)器學(xué)習(xí)團(tuán)隊(duì)推出了 DLC（Deep Learning Cloud）這一深度學(xué)習(xí)平臺(tái)產(chǎn)品。DLC 采用全新的云原生架構(gòu)，底層采用 Kubernetes 作為資源底座支持，而訓(xùn)練部分全面采用 KubeDL 進(jìn)行管理，是 KubeDL 在深度學(xué)習(xí)云計(jì)算場景中的大規(guī)模實(shí)踐。

DLC 在阿里集團(tuán)內(nèi)部內(nèi)廣泛支撐了眾多的業(yè)務(wù)，包括淘系安全部達(dá)摩院的圖像視頻、自然語言、語音、多模態(tài)理解、自動(dòng)駕駛等眾多業(yè)務(wù)部門的深度學(xué)習(xí)計(jì)算需求。在服務(wù)于深度學(xué)習(xí)驅(qū)動(dòng)的前沿業(yè)務(wù)生產(chǎn)中，PAI 團(tuán)隊(duì)在框架和平臺(tái)建設(shè)方面積累了許多的經(jīng)驗(yàn)，沉淀了兼容社區(qū)（eg，TensorFlow/PyTorch）并且具有鮮明特色的大規(guī)模工業(yè)界實(shí)踐過的框架平臺(tái)能力，如萬億規(guī)模參數(shù)的M6模型的訓(xùn)練、工業(yè)級圖神經(jīng)網(wǎng)絡(luò)系統(tǒng) Graph-Learn、極致資源管理和復(fù)用能力等等。

如今，PAI-DLC 的能力也在全面擁抱公有云，為開發(fā)者和企業(yè)提供的云原生一站式的深度學(xué)習(xí)訓(xùn)練平臺(tái)，一個(gè)靈活、穩(wěn)定、易用和高性能的機(jī)器學(xué)習(xí)訓(xùn)練環(huán)境，以及全面支持支持多種社區(qū)和 PAI 深度優(yōu)化的算法框架，高性能且穩(wěn)定的運(yùn)行超大規(guī)模分布式深度學(xué)習(xí)任務(wù)，為開發(fā)者和企業(yè)降本增效。

公有云的 DLC 作為阿里巴巴集團(tuán)機(jī)器學(xué)習(xí)平臺(tái)最佳實(shí)踐的透出，在產(chǎn)品細(xì)節(jié)、框架優(yōu)化、平臺(tái)服務(wù)等方面都吸取了工程實(shí)踐中的寶貴的經(jīng)驗(yàn)。除此之外，DLC 產(chǎn)品在設(shè)計(jì)之初就充分考量了公有云場景中的獨(dú)特屬性，提供了競價(jià)實(shí)例、自動(dòng) Fail-Over、彈性擴(kuò)縮等功能，為客戶努力降低 AI 算力成本。

進(jìn)一步的，DLC 也與 PAI 的其他公有云產(chǎn)品相結(jié)合，比如說服務(wù)于算法工程師建模的 DSW、服務(wù)于企業(yè)級 AI 全流程的、自動(dòng)化的 AutoML、在線推理服務(wù) EAS 等，打造全流程的 AI 標(biāo)桿性產(chǎn)品。