KubeDL 加入 CNCF Sandbox，加速 AI 产业云原生化
作者 | KubeDL 團隊
2021 年 6 月 23 日，云原生計算基金會（CNCF）宣布通過全球 TOC 投票接納 KubeDL 成為 CNCF Sandbox 項目。KubeDL 是阿里開源的基于 Kubernetes 的 AI 工作負載管理框架，取自"Kubernetes-Deep-Learning"的縮寫，希望能夠依托阿里巴巴的場景，將大規(guī)模機器學習作業(yè)調(diào)度與管理的經(jīng)驗反哺社區(qū)。
項目地址：http://kubedl.io
項目介紹
隨著 TensorFlow, PyTorch，XGBoost 等主流 AI 框架的不斷成熟，和以 GPU/TPU 為代表的多種AI異構(gòu)計算芯片的井噴式涌現(xiàn)，人工智能正快速進入“大規(guī)模工業(yè)化”落地的階段。從算法工程師著手設(shè)計第一層神經(jīng)網(wǎng)絡(luò)結(jié)構(gòu)，到最終上線服務于真實的應用場景，除 AI 算法的研發(fā)外還需要大量基礎(chǔ)架構(gòu)層面的系統(tǒng)支持，包括數(shù)據(jù)收集和清理、分布式訓練引擎、資源調(diào)度與編排、模型管理，推理服務調(diào)優(yōu)，可觀測等。如以下經(jīng)典圖例所展示，眾多系統(tǒng)組件的協(xié)同組成了完整的機器學習流水線。
與此同時，以 Kubernetes 為代表的云原生技術(shù)蓬勃發(fā)展，通過優(yōu)秀的抽象和強大的可擴展性，將應用層與 IaaS（Infrastructure as a Service）層的基礎(chǔ)設(shè)施完美解耦：應用能夠以“云”的范式按需使用資源，無需關(guān)注底層基礎(chǔ)設(shè)施的復雜性，從而解放生產(chǎn)力并專注于自身領(lǐng)域的創(chuàng)新。
Kubernetes 的出現(xiàn)解決了云資源如何高效交付的問題，但對于 AI 這類本身具備高度復雜性的工作負載還無法做到很好地原生支持，如何整合各類框架的差異并保留其通用性，同時圍繞 AI 工作負載的運行時去建設(shè)一系列完善的周邊生態(tài)及工具，業(yè)界還在不斷探索與嘗試。在實踐中，我們發(fā)現(xiàn)了 AI 負載運行在 Kubernetes 生態(tài)中面臨著如下挑戰(zhàn)：
- 機器學習框架百花齊放，各自有不同的優(yōu)化方向和適用場景，但在分布式訓練作業(yè)的生命周期管理上又存在著諸多共性，同時針對一些高級特性也有相同的訴求（如網(wǎng)絡(luò)模式，鏡像代碼分離，元數(shù)據(jù)持久化，緩存加速等）。為每類框架的負載單獨實現(xiàn) operater，各自獨立進程無法共享 state，缺乏全局視角，使得全局 Job 層面的調(diào)度以及隊列機制難以實現(xiàn)。此外，不利于功能的抽象和復用，在代碼層面存在重復勞動。
- 原生 Kubernetes 無法滿足離線任務多樣的調(diào)度需求。Kubernetes 面向 Pod 調(diào)度的模型天然適用于微服務等 Long Running 的工作負載，但針對離線任務的高吞吐，Gang Scheduling 調(diào)度（All-Or-Nothing），Elastic Capacity 等多種調(diào)度訴求，社區(qū)演進出了多種調(diào)度方案。以機器學習分布式訓練作業(yè)調(diào)度場景中極為常見的Gang Scheduling為例，社區(qū)目前就有YuniKorn，Volcano，Coscheduling 等調(diào)度器實現(xiàn)，提供不同的交互協(xié)議，我們需要有插件化的手段來啟用對應的調(diào)度協(xié)議。同時，像 PS/worker 這類根據(jù)業(yè)務特有屬性，不同 role 之間有啟動依賴的 DAG 編排訴求，需要在控制器中實現(xiàn)；
- 分布式訓練的結(jié)果往往以模型作為 output，并存儲在分布式文件系統(tǒng)中如(阿里云 OSS/NAS)，但如何從訓練作業(yè)的視角去管理模型，像容器鏡像那樣成為AI服務的“不可變基礎(chǔ)設(shè)施”并實現(xiàn)簡單且清晰的版本管理與追溯，業(yè)界還缺乏最佳實踐。同時，“訓練”與“推理”兩個階段相對獨立，算法科學家視角中的“訓練->模型->推理”機器學習流水線缺乏斷層，而“模型”作為兩者的中間產(chǎn)物正好能夠充當那個“承前啟后”的角色；
- 分布式訓練尚能大力出奇跡，但推理服務的規(guī)格配置卻是一個精細活。顯存量、 CPU 核數(shù)、BatchSize、線程數(shù)等變量都可能影響推理服務的質(zhì)量。純粹基于資源水位的容量預估無法反映業(yè)務的真實資源需求，因為某些引擎如 TensorFlow 會對顯存進行預占。理論上存在一個服務質(zhì)量與資源效能的最優(yōu)平衡點，但它就像黑暗中的幽靈，明知道它的存在卻難以琢磨。隨著 GPU 虛擬化技術(shù)的成熟，這個平衡點的價值越來越凸顯，更優(yōu)的規(guī)格能顯著提供單 GPU 卡的部署密度，節(jié)約大量的成本。
- 推理服務本身是一種特殊的 long running 微服務形態(tài)，除了基礎(chǔ)的 deployment 外，針對不同的推理場景還欠缺一些實例與流量的管理策略，如：
1) 算法科學家通常會同時部署兩個甚至多個不同版本的模型實例進行 A/B Test 以驗證最佳的服務效果，需要基于權(quán)重的精細化流量控制；
2) 能夠根據(jù)流量請求水平和當前推理服務的 metrics 來自動觸發(fā)實例的擴縮，在充分保障服務可用性的前提下最小化資源成本等等。
KubeDL
針對上述難題，阿里巴巴云原生，集群管理和 PAI 團隊將管理大規(guī)模機器學習工作負載的經(jīng)驗沉淀為通用的運行時管理框架——KubeDL，涵蓋分布式訓練，模型管理，推理服務等機器學習流水線的各階段，使工作負載能夠高效地運行在 Kubernetes 之上。
1、分布式訓練
KubeDL 支持了主流的機器學習分布式訓練框架（TensorFlow / PyTorch / MPI / XGBoost / Mars 等），其中 Mars 是阿里巴巴計算平臺開源的基于張量的大規(guī)模數(shù)據(jù)計算框架，能夠分布式地加速 numpy，pandas 等數(shù)據(jù)處理框架的效率，幫助 Mars 作業(yè)以更 native 的方式集成進云原生大數(shù)據(jù)生態(tài)中。
我們將各類訓練作業(yè)生命周期管理中的共同部分進行抽象，成為一層通用的運行時庫，被各分布式訓練作業(yè)控制器復用，同時用戶也可以在此基礎(chǔ)上快速擴展出自定義的 workload 控制器并復用現(xiàn)有的能力。借助聲明式 API 與 Kubernetes 網(wǎng)絡(luò)/存儲模型，KubeDL 能夠進行計算資源的申請/回收，各 Job Role 之間的服務發(fā)現(xiàn)與通信，運行時的 Fail-over 等，算法模型的開發(fā)者只需聲明好此次訓練依賴的 Job Role 及各自的副本數(shù)，計算資源/異構(gòu)資源數(shù)量等，然后提交任務。另外，我們針對訓練領(lǐng)域的痛點也做了諸多的特性設(shè)計來提升訓練的效率與體驗：
- 不同的訓練框架往往包含不同的 Job Role，如 TensorFlow 中的 PS/Chief/Worker 和 PyTorch 中的 Master/Worker，Role 與 Role 之間往往隱含著依賴關(guān)系，如 Worker 依賴 Master 啟動之后才能正常開始計算，錯亂的啟動順序不僅容易造成資源長時間空轉(zhuǎn)，甚至可能引發(fā) Job 直接失敗。KubeDL 設(shè)計了基于 DAG（Direct Acyclic Graph）的調(diào)度編排控制流，很好地解決了 Role 之間的啟動依賴順序，并能夠靈活擴展。
- 大模型的訓練時長往往受制于計算節(jié)點間的通信效率，RDMA 等高性能網(wǎng)絡(luò)技術(shù)的應用將極大地提升了數(shù)據(jù)的傳輸速度，但這些定制網(wǎng)絡(luò)往往需要計算節(jié)點使用 Hostnetwork 進行互相通信，同時有些時候由于環(huán)境限制無法提供基于 Service 模式的服務發(fā)現(xiàn)機制。這就需要作業(yè)管理引擎能夠支持 Host 網(wǎng)絡(luò)模式下的服務發(fā)現(xiàn)機制，處理好各計算節(jié)點的網(wǎng)絡(luò)端口分配，并與各訓練框架的特性結(jié)合來處理節(jié)點 Fail-over 后的網(wǎng)絡(luò)連通性，KubeDL 支持了 Host 網(wǎng)絡(luò)模式下的高性能分布式訓練。
- Gang Scheduling 是分布式訓練作業(yè)調(diào)度場景中的常見需求，組成單個訓練作業(yè)的一簇 Pod 往往要求同時被調(diào)度，避免在集群容量緊張時因作業(yè)間的資源競爭出現(xiàn)活鎖，但 Kubernetes 強大的可擴展性也使得不同的調(diào)度器實現(xiàn)了不同的 Gang Scheduling 協(xié)議，如 YuniKorn, KubeBatch 等。為了避免與具體調(diào)度器實現(xiàn)的耦合，適應不同用戶環(huán)境的差異，KubeDL 將 Gang Scheduling 的協(xié)議實現(xiàn)插件化，按需啟用對應的插件即可與調(diào)度器相互協(xié)作，實現(xiàn)作業(yè)的批量調(diào)度。
- Job 是一次性的，但在實際的生產(chǎn)應用中我們經(jīng)常會遇到反復訓練/定時訓練的場景，如每日拉取某一時間區(qū)間的離線表并進行數(shù)據(jù)清洗以及模型的 Re-train，KubeDL 提供了一類單獨的工作負載—Cron 來處理定時的訓練請求，并支持任意類型的訓練作業(yè)（如 TFJob，PyTorchJob 等），用戶可以提交 cron tab 風格的定時命令及作業(yè)模板，并在 Cron 資源的狀態(tài)中追蹤訓練作業(yè)的歷史及當前進行中的作業(yè)。
針對海量離線作業(yè)元數(shù)據(jù)需要長時間保存（Job CRD 被刪除后元數(shù)據(jù)即從 etcd 銷毀）的訴求，KubeDL 還內(nèi)置了元數(shù)據(jù)的持久化，實時監(jiān)聽 Job/Pod/Events 等資源對象的變化，轉(zhuǎn)化成對應的 Databse Schema Object 并持久化到存儲后端中。存儲后端的設(shè)計也是插件化的，用戶可以根據(jù)自己的線上環(huán)境來實現(xiàn)存儲插件并在部署時 enable。在 KubeDL 中 Job/Pod 默認支持了 Mysql 的存儲協(xié)議，以及將 Events 收集到阿里云 SLS 服務中。
同時我們還提供了管控套件：KubeDL-Dashboard，用戶不需要去理解 Kubernetes 的眾多 API 并在各種 kubectl 命令中掙扎，即可界面化地上手簡單易用的機器學習作業(yè)。持久化的元數(shù)據(jù)也可以直接被 Dashboard 消費使用。Dashboard 提供了簡單的作業(yè)提交、作業(yè)管理、事件/日志查看、集群資源視圖等功能，以極低的學習門檻幫助機器學習用戶上手實驗。
2、推理服務規(guī)格調(diào)優(yōu)
GPU 虛擬化與分時復用技術(shù)的發(fā)展和成熟，讓我們有機會在一塊 GPU 上同時運行多個推理服務，顯著降低成本。然而如何為推理服務選擇合適的 GPU 資源規(guī)格，尤其是不可壓縮的顯存資源，成為一個關(guān)鍵難題。一方面，頻繁的模型迭代讓算法工程師無暇去精確估計每個模型的資源需求，流量的動態(tài)變化也讓資源評估變得不準確，因此他們傾向于配置較多的 GPU 資源冗余，在穩(wěn)定性和效率之間選擇犧牲后者，造成大量浪費；另一方面，由于 Tensorflow 等機器學習框架傾向于占滿所有空閑的顯存，站在集群管理者的角度，根據(jù)顯存的歷史用量來估計推理業(yè)務的資源需求也非常不準確。在 KubeDL-Morphling 這個組件中我們實現(xiàn)了推理服務的自動規(guī)格調(diào)優(yōu)，通過主動壓測的方式，對服務在不同資源配置下進行性能畫像，最終給出最合適的容器規(guī)格推薦。畫像過程高度智能化：為了避免窮舉方式的規(guī)格點采樣，我們采用貝葉斯優(yōu)化作為畫像采樣算法的內(nèi)部核心驅(qū)動，通過不斷細化擬合函數(shù)，以低采樣率（<20%）的壓測開銷，給出接近最優(yōu)的容器規(guī)格推薦結(jié)果。
3、模型管理與推理服務
模型是訓練的產(chǎn)物，是計算與算法結(jié)合后的濃縮精華，通常收集與維護模型的方式是托管在云存儲上，通過組織文件系統(tǒng)的方式來實現(xiàn)統(tǒng)一管理。這樣的管理方式依賴于嚴格的流程規(guī)范與權(quán)限控制，沒有從系統(tǒng)層面實現(xiàn)模型管理的不可變，而容器鏡像的誕生解決的就是 RootFS 的構(gòu)建-分發(fā)-不可變等問題，KubeDL 將兩者進行結(jié)合，實現(xiàn)了基于鏡像的模型管理。訓練成功結(jié)束后，通過 Job Spec 中指定的 ModelVersion 會自動觸發(fā)模型鏡像的構(gòu)建。用戶可以在 ModelVersion.Spec 中約定模型的存儲路徑，目標的鏡像 Registry 等基本信息，將每次的訓練輸出 Push 到對應的鏡像倉庫。
同時鏡像作為訓練的輸出，以及推理服務的輸入，很好地串聯(lián)起了兩個階段，也借此實現(xiàn)了分布式訓練->模型構(gòu)建與管理->推理服務部署的完整機器學習流水線。KubeDL 提供了 Inference 資源對象提供推理服務的部署與運行時控制，一個完整的 Inference 服務可以由單個或多個 Predictor 組成，每個 Predictor 對應前序訓練輸出的模型，模型會被自動拉取并掛載到主容器 Volume 中。當多個不同模型版本的 Predictor 并存時，可以根據(jù)分配的權(quán)重進行流量的分發(fā)與控制，達到 A/B Test 的對照實驗效果，后續(xù)我們還會在 Batching 批量推理和 AutoScale 上針對推理服務場景做更多的探索。
KubeDL 分布式訓練在公有云上的實踐
- PAI-DLC
隨著云計算的深入人心以及越來越多的業(yè)務都用云原生的方式進行，阿里云計算平臺 PAI 機器學習團隊推出了 DLC（Deep Learning Cloud）這一深度學習平臺產(chǎn)品。DLC 采用全新的云原生架構(gòu)，底層采用 Kubernetes 作為資源底座支持，而訓練部分全面采用 KubeDL 進行管理，是 KubeDL 在深度學習云計算場景中的大規(guī)模實踐。
DLC 在阿里集團內(nèi)部內(nèi)廣泛支撐了眾多的業(yè)務，包括淘系安全部達摩院的圖像視頻、自然語言、語音、多模態(tài)理解、自動駕駛等眾多業(yè)務部門的深度學習計算需求。在服務于深度學習驅(qū)動的前沿業(yè)務生產(chǎn)中，PAI 團隊在框架和平臺建設(shè)方面積累了許多的經(jīng)驗，沉淀了兼容社區(qū)（eg，TensorFlow/PyTorch）并且具有鮮明特色的大規(guī)模工業(yè)界實踐過的框架平臺能力，如萬億規(guī)模參數(shù)的M6模型的訓練、工業(yè)級圖神經(jīng)網(wǎng)絡(luò)系統(tǒng) Graph-Learn、極致資源管理和復用能力等等。
如今，PAI-DLC 的能力也在全面擁抱公有云，為開發(fā)者和企業(yè)提供的云原生一站式的深度學習訓練平臺，一個靈活、穩(wěn)定、易用和高性能的機器學習訓練環(huán)境，以及全面支持支持多種社區(qū)和 PAI 深度優(yōu)化的算法框架，高性能且穩(wěn)定的運行超大規(guī)模分布式深度學習任務，為開發(fā)者和企業(yè)降本增效。
公有云的 DLC 作為阿里巴巴集團機器學習平臺最佳實踐的透出，在產(chǎn)品細節(jié)、框架優(yōu)化、平臺服務等方面都吸取了工程實踐中的寶貴的經(jīng)驗。除此之外，DLC 產(chǎn)品在設(shè)計之初就充分考量了公有云場景中的獨特屬性，提供了競價實例、自動 Fail-Over、彈性擴縮等功能，為客戶努力降低 AI 算力成本。
進一步的，DLC 也與 PAI 的其他公有云產(chǎn)品相結(jié)合，比如說服務于算法工程師建模的 DSW、服務于企業(yè)級 AI 全流程的、自動化的 AutoML、在線推理服務 EAS 等，打造全流程的 AI 標桿性產(chǎn)品。
原文鏈接：https://developer.aliyun.com/article/787300?
版權(quán)聲明：本文內(nèi)容由阿里云實名注冊用戶自發(fā)貢獻，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔相應法律責任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務協(xié)議》和《阿里云開發(fā)者社區(qū)知識產(chǎn)權(quán)保護指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進行舉報，一經(jīng)查實，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。 與50位技術(shù)專家面對面20年技術(shù)見證，附贈技術(shù)全景圖總結(jié)
以上是生活随笔為你收集整理的KubeDL 加入 CNCF Sandbox，加速 AI 产业云原生化的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 第三届 Apache Flink 极客挑
- 下一篇： 阿里云容器网络文件系统 CNFS 1.0