‍
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/5d2c576607e944559f8c873b30b2633e.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16)

作者：張凱

## 前言

雲原生（Cloud Native）[1]是雲端計算領域過去 5 年發展最快、關注度最高的方向之一。CNCF（Cloud Native Computing Foundation，雲原生計算基金會）2021年度調查報告[2]顯示，全球已經有超過 680 萬的雲原生技術開發者。同一時期，人工智慧 AI 領域也在“深度學習演算法+GPU 大算力+海量資料”的推動下持續蓬勃發展。有趣的是，雲原生技術和 AI，尤其是深度學習，出現了很多關聯。

大量 AI 演算法工程師都在使用雲原生容器技術除錯、執行深度學習 AI 任務。很多企業的 AI 應用和 AI 系統，都構建在容器叢集上。為了幫助使用者更容易、更高效地在基於容器環境構建 AI 系統，提高生產 AI 應用的能力，2021 年阿里雲容器服務 ACK 推出了雲原生 AI 套件產品。本文將介紹和梳理我們對雲原生 AI 這個新領域的思考和定位，介紹雲原生 AI 套件產品的核心場景、架構和主要能力。

## AI 與雲原生極簡史

回顧 AI 的發展歷史，我們會發現這早已不是一個新的領域。從 1956 年達特茅斯學術研討會上被首次定義，到 2006 年 Geoffery Hinton 提出了“深度信念網路”(Deep Believe Network），AI 已歷經 3 次發展浪潮。尤其是近 10 年，在以深度學習（Deep Learning）為核心演算法、以 GPU 為代表的大算力為基礎，疊加海量生產資料積累的推動下，AI 技術取得了令人矚目的進展。與前兩次不同，這一次  AI  在機器視覺、語音識別、自然語言理解等技術上實現突破，並在商業、醫療、教育、工業、安全、交通等非常多行業成功落地，甚至還催生了自動駕駛、AIoT 等新領域。

然而，伴隨 AI 技術的突飛猛進和廣泛應用，很多企業和機構也發現想要保證“演算法+算力+資料”的飛輪高效運轉，規模化生產出有商業落地價值的 AI 能力，其實並不容易。昂貴的算力投入和運維成本，低下的 AI 服務生產效率，以及缺乏可解釋性和通用性的 AI 演算法，都成為橫亙在 AI 使用者面前的重重門檻。

與 AI 的歷史類似，雲原生領域的代表技術 —— 容器（container），也不是一個新的概念。其最早可追溯到 1979 年誕生的 UNIX chroot 技術，就開始顯現出容器的雛型。接下來又出現了 FreeBSD Jails，Linux VServer，OpenVZ，Warden 等一系列基於核心的輕量級資源隔離技術。直到 2013 年 Docker 橫空出世，以完善的容器物件封裝、標準的 API 定義和友好的開發運維體驗，重新定義了使用資料中心計算資源的介面。隨後的故事大家都知道了，Kubernetes 在與 Docker Swarm 和 Mesos 的競爭中勝出，成為容器編排與排程的事實標準。Kubernetes 和容器（包括 Docker，Containerd，CRI-O 等多種容器執行時和管理工具）構成了 CNCF 定義的雲原生核心技術。經過 5 年高速發展，雲原生技術生態已經覆蓋了容器執行時、網路、儲存和叢集管理、可觀測性、彈性、DevOps、服務網格、無伺服器架構、資料庫、資料倉儲等 IT 系統的方方面面。

## 為何出現雲原生 AI
據 CNCF 2021 年度相關調查報告顯示， 96% 的受訪企業正在使用或評估 Kubernetes，這其中包括了很多 AI 相關業務的需求。Gartner 曾預測，到 2023 年 70% 的 AI 應用將基於容器和 Serverless 技術開發。

現實中，在研發阿里雲容器服務 ACK[3]（Alibaba Container service for Kubernetes）產品過程中，我們看到越來越多使用者希望在 Kubernetes 容器叢集中管理 GPU 資源，開發執行深度學習和大資料任務，部署和彈性管理 AI 服務，且使用者來源於各行各業，既包括網際網路、遊戲、直播等快速增長的公司，也有自動駕駛、AIoT 這類新興領域，甚至不乏政企、金融、製造等傳統行業。

使用者在開發、生成、使用 AI 能力時碰到很多共性的挑戰，包括 **AI 開發門檻高、工程效率低、成本高、軟體環境維護複雜、異構硬體管理分散、計算資源分配不均、儲存接入繁瑣等等**。其中不少使用者已經在使用雲原生技術，併成功提升了應用和微服務的開發運維效率。他們希望能將相同經驗複製到 AI 領域，基於雲原生技術構建 AI 應用和系統。

在初期，使用者利用 Kubernetes，Kubeflow，nvidia-docker 可以快速搭建 GPU 叢集，以標準介面訪問儲存服務，自動實現 AI 作業排程和 GPU 資源分配，訓練好的模型可以部署在叢集中，這樣基本實現了 AI 開發和生產流程。緊接著，使用者對生產效率有了更高要求，也遇到更多問題。比如 **GPU 利用率低，分散式訓練擴充套件性差，作業無法彈性伸縮，訓練資料訪問慢，缺少資料集、模型和任務管理，無法方便獲取實時日誌、監控、視覺化，模型釋出缺乏質量和效能驗證，上線後缺少服務化運維和治理手段，Kubernetes 和容器使用門檻高，使用者體驗不符合資料科學家的使用習慣，團隊協作和共享困難，經常出現資源爭搶，甚至資料安全問題等等。**

從根本上解決這些問題，AI 生產環境必然要從“單打獨鬥的小作坊”模式，向 “**資源池化+AI 工程平臺化+多角色協作”** 模式升級。為了幫助有此類訴求的“**雲原生+AI”** 使用者實現靈活可控、系統化地演進，我們在 ACK 基礎上推出雲原生 AI 套件[4]產品。只要使用者擁有一個 ACK Pro 叢集，或者任何標準 Kubernetes 叢集，就可以使用雲原生 AI 套件，快速定製化搭建出一個自己的 AI 平臺。把資料科學家和演算法工程師從繁雜低效的環境管理、資源分配和任務排程工作中解放出來，把他們更多的精力留給“腦洞”演算法和“煉丹”。
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/b45c63b388cc470884f1cd04b90255d5.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_17,color_FFFFFF,t_70,g_se,x_16)

圖0：AI 生產環境向平臺化演進

## 如何定義雲原生 AI

隨著企業 IT 架構逐步深入地向雲端計算演進，以容器、Kubernetes、服務網格等為代表的雲原生技術，已經幫助大量應用服務快速落地雲平臺，並在彈性、微服務化、無服務化、DevOps 等場景中獲取很大價值。與此同時，IT 決策者們也在考慮如何透過雲原生技術，以統一架構、統一技術堆疊支撐更多型別的工作負載。以避免不同負載使用不同架構和技術實現，帶來“煙囪”系統、重複投入和割裂運維的負擔。

深度學習和 AI 任務，正是社群尋求雲原生支撐的重要工作負載之一。事實上，越來越多深度學習系統、AI 平臺已經構建在容器和 Kubernetes 叢集之上。在 2020 年，我們就明確提出“雲原生 AI”的概念、核心場景和參考技術架構，以期為這個全新領域提供具象的定義，可落地的路線圖和最佳實踐。

**阿里雲容器服務 ACK 對雲原生 AI 的定義 - 充分利用雲的資源彈性、異構算力、標準化服務以及容器、自動化、微服務等雲原生技術手段，為 AI/ML 提供工程效率高、成本低、可擴充套件、可複製的端到端解決方案。**

### 核心場景
我們將雲原生 AI 領域聚焦在兩個核心場景：持續最佳化異構資源效率，和高效執行 AI 等異構工作負載。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/4aa99c9652634d6cb3e148b6e3b5ec3d.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16)

圖1：雲原生 AI 的核心場景

**場景 1、最佳化異構資源效率**

對阿里雲 IaaS 或者客戶 IDC 內各種異構的計算（如CPU，GPU，NPU，VPU，FPGA，ASIC）、儲存（OSS，NAS， CPFS，HDFS）、網路（TCP， RDMA）資源進行抽象，統一管理、運維和分配，透過彈性和軟硬協同最佳化，持續提升資源利用率。

**場景 2、執行 AI 等異構工作負載**

相容 Tensorflow，Pytorch，Horovod，ONNX，Spark，Flink 等主流或者使用者自有的各種計算引擎和執行時，統一執行各類異構工作負載流程，統一管理作業生命週期，統一排程任務工作流，保證任務規模和效能。一方面不斷提升執行任務的價效比，另一方面持續改善開發運維體驗和工程效率。

圍繞這兩個核心場景，可以擴充套件出更多使用者定製化場景，比如構建符合使用者使用習慣的 MLOps 流程；或者針對 CV 類（Computer Vision, 計算機視覺）AI 服務特點，混合排程 CPU，GPU，VPU（Video Process Unit）支援不同階段的資料處理流水線；還可以針對大模型預訓練和微調場景，擴充套件支援更高階的分散式訓練框架，配合任務和資料排程策略，以及彈性、容錯方案，最佳化大模型訓練任務成本和成功率。

**參考架構**
為了能支撐上述核心場景，我們提出了雲原生 AI 參考技術架構。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/52ce888be19a45d2b9b37d3fb6ccb338.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16)

圖 2：雲原生 AI 參考架構圖

雲原生 AI 參考技術架構以元件化、可擴充套件和可組裝的白盒化設計原則，以 Kubernetes 標準物件和 API 暴露介面，支援開發運維人員按需選擇任意元件，進行組裝和二次開發，快速定製化構建出自己的 AI 平臺。

參考架構中以 Kubernetes 容器服務為底座，向下封裝對各類異構資源的統一管理，向上提供標準 Kubernetes 叢集環境和 API，以執行各核心元件，實現資源運維管理、AI 任務排程和彈性伸縮、資料訪問加速、工作流編排、大資料服務整合、AI 作業生命週期管理、各種 AI 製品管理、統一運維等服務。再向上針對 AI 生產流程（MLOps）中的主要環節，支援 AI 資料集管理，AI模型開發、訓練、評測，以及模型推理服務；並且透過統一的命令列工具、多種語言 SDK 和控制檯介面，支援使用者直接使用或定製開發。而且透過同樣的元件和工具，也可以支援雲上 AI 服務、開源 AI 框架和第三方 AI 能力的整合。

## 企業需要什麼樣的雲原生 AI 能力

我們定義了雲原生 AI 的概念、核心場景、設計原則和參考架構。接下來，需要提供什麼樣的雲原生 AI 產品給使用者呢？透過對 ACK 上執行 AI 任務的使用者調研，對雲原生、MLOps、MLSys 等社群的觀察，結合業界一些容器化 AI 產品的分析，我們總結出一款雲原生 AI 產品需要具備的特徵和關鍵能力。
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/a63a667e852f4a8ab989f700c3591bf7.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16)

圖 3：企業需要什麼樣的雲原生 AI 能力

**• 效率高**
主要包括：異構資源使用效率，AI 作業執行和管理效率，租戶共享和團隊協作效率等三個維度
**• 相容性好**
相容常見的 AI 計算引擎和模型。支援各類儲存服務，並能提供通用的資料訪問效能最佳化能力。可以與多種大資料服務整合，並能被業務應用方便地整合。特別地，還要符合資料安全與隱私保護的要求。
• **可擴充套件**
產品架構實現可擴充套件、可組裝、可復現。提供標準API和工具，便於使用、整合和二次開發。同樣的架構下，產品實現儘量適配公共雲，專有云，混合雲，以及邊緣等多種環境的交付。

## 阿里雲容器服務 ACK 雲原生 AI 套件
基於雲原生 AI 參考架構，面向上述核心場景和使用者需求，阿里雲容器服務團隊在 2021 年正式釋出了 ACK 雲原生 AI 套件產品[5]，已經在全球 27 個區域同步上線公測，幫助 Kubernetes 使用者快速定製化構建自己的雲原生 AI 平臺。

ACK 雲原生 AI 套件主要面向 AI 平臺開發運維團隊，幫助其快速、低成本地管理 AI 基礎設施。同時將各元件功能封裝成命令列和控制檯工具，供資料科學家和演算法工程師直接使用。使用者在 ACK 叢集中安裝雲原生 AI 套件後，所有元件開箱即用，快速實現統一管理異構資源和低門檻執行 AI 任務。產品安裝和使用方式，可以參考產品文件[6]。

###  架構設計
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/f6e1de5476ae4ac48a163f753a97cafc.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_15,color_FFFFFF,t_70,g_se,x_16)

圖 4：雲原生 AI 套件架構大圖

雲原生 AI 套件的功能從底向上分為：

1. **異構資源層**，包括異構算力最佳化和異構儲存接入
2. **AI 排程層**，包括各種排程策略最佳化
3. **AI 彈性層**，包括彈性 AI 訓練任務和彈性 AI 推理服務
4. **AI 資料加速與編排層**，包括資料集管理，分散式快取加速，大資料服務整合
5. **AI 作業管理層**，包括 AI 作業全生命週期管理服務和工具集
6. **AI 運維層**，包括監控、日誌、彈性伸縮、故障診斷和多租戶
7. **AI 製品倉庫**，包括 AI 容器映象，模型和 AI 實驗記錄

下文將簡要介紹雲原生 AI 套件產品中異構資源層，AI 排程層，AI 彈性任務層，AI 資料加速與編排層和 AI 作業管理層的主要能力和基本架構設計。

**1、異構資源統一管理**

雲原生 AI 套件在 ACK 上，增加了對 Nvidia GPU，含光 800 NPU，FPGA，VPU，RDMA 高效能網路等各種異構資源的支援，基本覆蓋了阿里雲上所有裝置型別，使得在 Kubernetes 中使用這些資源的方式和使用 CPU、記憶體一樣簡單，只要在任務引數中宣告需要的資源數量即可。針對 GPU，NPU 這類比較昂貴的資源，還提供了多種資源利用率最佳化方法。
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/718a75acc5fe4b7faf9c3edc6f2d591b.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16)

圖 5：異構資源統一管理

### GPU 監控
針對 GPU 提供了多維度監控能力，使得 GPU 的分配、使用和健康狀態一目瞭然。透過內建Kubernetes NPD（Node Problem Detector）自動檢測和告警 GPU 裝置異常。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/68cf2e766d33478a9e8aeb9ca7f87f33.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16)

圖 6：GPU 監控

### GPU 彈性伸縮

結合 ACK 彈性節點池提供的多種彈性伸縮能力，對 GPU 在資源節點數和執行任務例項數兩層都可以按需自動伸縮。觸發彈性的條件既有 GPU 的資源使用指標，也支援使用者自定義指標。伸縮節點型別支援普通 EGS 例項，也支援 ECI 例項，Spot 例項等。
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/89a66d122de740c19e794614241d3370.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16)

圖 7：GPU 彈性伸縮

### GPU 共享排程

原生 Kubernetes 僅支援以 GPU 整卡粒度為單位排程，任務容器會獨佔 GPU 卡。如果任務模型比較小（計算量、視訊記憶體用量），就會造成 GPU 卡資源空閒浪費。雲原生 AI 套件提供了 GPU 共享排程能力，可以按模型的 GPU 算力和視訊記憶體需求量，將一塊 GPU 卡分配給多個任務容器共享使用。這樣理論上就能夠用更多工最大限度地佔滿 GPU 資源。

同時，為了避免共享 GPU 的多個容器之間相互干擾，還整合了阿里雲 cGPU 技術，確保共享使用GPU的安全性和穩定性。容器間使用 GPU 資源是相互隔離的。不會出現超用，或者發生錯誤時彼此影響。

GPU 共享排程還支援多種分配策略，包括單容器單 GPU 卡共享，常用於支援模型推理場景；單容器多 GPU 卡共享，常用於開發環境中除錯分散式模型訓練；GPU 卡Binpack/Spread 策略，可以平衡 GPU 卡的分配密度和可用性。類似的細粒度共享排程能力也適用於 ACK 叢集中的阿里自研含光 800 AI 推理晶片。
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/dbee17ebc82b4273b7403f96d8ee58a4.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16)

圖 8：GPU 共享排程

GPU 共享排程和 cGPU 隔離對 GPU 資源利用率提升是顯而易見的，已經有很多使用者案例。比如某客戶將數百臺不同型號 GPU 例項，以視訊記憶體維度統一劃分池化，利用 GPU 共享排程和視訊記憶體自動彈性伸縮，部署了上百種 AI 模型。既大幅度提高資源利用率，也顯著降低運維複雜度。

### GPU 拓撲感知排程

隨著深度學習模型複雜度和訓練資料量提升，多 GPU 卡分散式訓練已經很非常普遍。對於使用梯度下降最佳化的演算法，多 GPU 卡之間需要頻繁傳輸資料，資料通訊頻寬往往成為限制 GPU 計算效能的瓶頸。

GPU 拓撲感知排程功能，透過獲取計算節點上所有 GPU 卡間連線拓撲結構，排程器為多卡訓練任務選擇 GPU 資源時，根據拓撲資訊考慮 NVLINK，PCIe Switch，QPI 以及 RDMA 網路卡等所有互聯鏈路，自動選擇出能夠提供最大通訊頻寬的 GPU 卡組合，避免頻寬限制影響 GPU 計算效率。開啟 GPU 拓撲感知排程完全是可配置的工作，對模型和訓練任務程式碼都是零侵入的。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/d4e638d2ffc04670a77bbe9e84942975.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16)

圖 9：GPU 拓撲感知排程

透過與普通 Kubernetes 排程和執行多卡 GPU 分散式訓練任務的效能對比，可以發現對於同樣的計算引擎（如 Tensorflow，Pytorch 等）和模型任務（Resnet50， VGG16等），GPU 拓撲感知排程可以零成本帶來效率提升。相較於較小的 Resnet50 模型，由於 VGG16 模型訓練過程引入的資料傳輸量較大，更優的GPU 互聯頻寬對訓練效能提升效果會更加明顯。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/11aa2431a6ea4728bde431f7caaff7a2.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_16,color_FFFFFF,t_70,g_se,x_16)

圖 10：GPU 拓撲感知排程 vs 普通多卡 GPU 排程的訓練效能

**2、 AI 任務排程（Cybernetes）**

AI 分散式訓練是典型的批次任務型別。使用者提交的一個訓練任務（Job），在執行時一般會由一組子任務（Task）共同執行才能完成。不同AI訓練框架對子任務分組有不同的策略，比如 Tensorflow 訓練任務可以採用多個 Parameter Servers 子任務 + 多個 Workers 子任務的分組，Horovod 執行 Ring all-reduce 訓練時，採用一個 Launcher + 多個 Workers 的策略。

在 Kubernetes 中，一個子任務一般對應一個 Pod 容器程式。排程一個訓練任務，就轉化為對一組，或多組子任務 Pod 容器的共同排程。這類似 Hadoop Yarn 對 MapReduce，Spark 批次作業的排程。Kubernetes 預設排程器只能以單個 Pod 容器為排程單元，無法滿足批次任務排程的需求。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/2ab1160b87ed48328a5dc594276e79d6.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16)

ACK 排程器（Cybernetes[7]）擴充套件 Kubernetes 原生排程框架，實現了很多典型批次排程策略，包括 Gang Scheduling（Coscheduling）、FIFO scheduling、Capacity Scheduling、Fair sharing、Binpack/Spread 等。還增加了新的優先順序任務佇列，支援自定義的任務優先順序管理和租戶彈性資源配額控制；也可以整合 Kubeflow Pipelines 或 Argo 雲原生工作流引擎，為複雜的 AI 任務提供工作流編排服務。由“任務佇列+任務排程器+工作流+任務控制器”組成的架構，為基於 Kubernetes 構建批次任務系統提供了基礎支撐，同時也顯著提升叢集整體資源利用率。

目前，雲原生 AI 套件環境裡不僅可以支援 Tensorflow，Pytorch，Horovod 等各種深度學習 AI 任務訓練，也可以支援 Spark，Flink 等大資料任務，還能夠支援 MPI 高效能運算作業。我們也將部分批次任務排程能力，貢獻給了 Kubernetes 排程器上游開源專案，並持續推動社群向雲原生任務系統基礎架構演進。可前往 Github 瞭解相關專案詳情：https://github.com/kubernetes-sigs/scheduler-plugins

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/946094670a814d99a3848f2e2e7ceca5.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16)

圖 13：ACK Cybernetes 排程器

ACK 排程器支援的典型批次任務排程策略舉例如下：

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/321737159c2240ff9a6d32429ce3c026.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16)

圖 14：ACK 支援的典型任務排程策略

• **Gang Scheduling**
叢集能夠滿足一個任務的所有子任務的需求時才為任務整體分配資源，否則不為其分配任何資源。避免由於資源死鎖，導致大任務擠佔小任務。

**• Capacity Scheduling**
透過提供彈性配額和租戶佇列的設定，確保在滿足租戶最低資源需求分配的基礎上透過彈性配額共享來提升整體資源利用率。

**• Binpack Scheduling**
作業優先集中分配在某個節點，當節點資源不足時，依次在下一節點集中分配，適合單機多 GPU 卡訓練任務，避免跨機資料傳輸。也可以防止大量小作業帶來的資源碎片。

**• Resource Reservation Scheduling**
為特定作業預留資源，定向分配或者重複使用。既保證了特定作業獲得資源的確定性，也加速了資源分配速度，還支援使用者自定義預留策略。

**3、彈性 AI 任務**

彈性是雲原生和 Kubernetes 容器叢集最重要的基礎能力。綜合考慮資源狀況、應用忙閒程度和成本約束，智慧伸縮服務例項數和叢集節點數，既要滿足應用的基本服務質量，也要避免過度的雲資源消費。雲原生 AI 套件分別支援彈性模型訓練任務和彈性模型推理服務。

**彈性模型訓練（Elastic Training）**

支援彈性排程分散式深度學習訓練任務。訓練過程中可以動態伸縮子任務 worker 例項數量和節點數量，同時基本維持整體訓練進度和模型精度。在叢集資源空閒時，增加更多 worker 加速訓練，在資源緊張時，可以釋放部分 worker，保證訓練的基本執行進度。這樣可以極大提升叢集的總體利用率，避免計算節點故障影響，同時顯著減少使用者提交作業之後等待作業啟動的時間。

值得注意的是，彈性深度學習訓練除了需要資源彈效能力外，還需要計算引擎和分散式通訊框架的支援，還要演算法、資料切分策略、訓練最佳化器等多方面共同配合最佳化（找到最佳的方法保證 global batch size 和 learning rate 的適配），才能保證模型訓練的精度目標和效能要求。目前業界還沒有通用的手段，在普遍的模型上實現強復現的彈性訓練。在一定約束下（模型特徵，分散式訓練方法，資源規模以及彈性幅度等），比如 32 卡GPU以內的 ResNet50，BERT 使用 Pytorch 和 Tensorflow 都有穩定的方法實現滿意的彈性訓練收益。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/ec04a80134834021b84bd7506c93fb64.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16)

圖 15：彈性 AI 訓練

**彈性模型推理服務（Elastic Inference）**

結合阿里雲豐富的資源彈效能力，充分利用包括停機不回收、彈性資源池、定時彈性、競價例項彈性、 Spotfleet 模式等各種資源型別，自動擴縮容 AI 推理服務。在服務效能和成本之間維持較最佳化的平衡。

事實上，AI 模型線上推理服務的彈性，以及服務化運維，與微服務和 Web 應用是比較類似。很多雲原生已有技術都可以直接用在線上推理服務上。但是 AI 模型推理依然有很多特殊之處，模型最佳化方法、流水線服務化、精細化的排程編排、異構執行環境適配等等方面都有專門訴求和處理手段，這裡不再展開。

### 4、 AI 資料編排與加速（Fluid）

在雲上透過雲原生架構執行 AI、大資料等任務，可以享受計算資源彈性的優勢，但同時也會遇到，計算和儲存分離架構帶來的資料訪問延遲和遠端拉取資料頻寬開銷大的挑戰。尤其在 GPU 深度學習訓練場景中，迭代式的遠端讀取大量訓練資料方法會嚴重拖慢 GPU 計算效率。

另一方面，Kubernetes 只提供了異構儲存服務接入和管理標準介面（CSI，Container Storage Interface），對應用如何在容器叢集中使用和管理資料並沒有定義。在執行訓練任務時，資料科學家需要能夠管理資料集版本、控制訪問許可權、資料集預處理、加速異構資料讀取等。但是在 Kubernetes 中還沒有這樣的標準方案，這是雲原生容器社群缺失的重要能力之一。

ACK 雲原生 AI 套件對“計算任務使用資料的過程”進行抽象，提出了彈性資料集 Dataset 的概念，並作為“first class citizen”在 Kubernetes 中實現。圍繞彈性資料集 Dataset，ACK 建立了資料編排與加速系統 Fluid，來實現 Dataset 管理（CRUD 操作）、許可權控制和訪問加速等能力。

Fluid 可以為每個 Dataset 配置快取服務，既能在訓練過程中將資料自動快取在計算任務本地，供下輪迭代計算，也能將新的訓練任務排程到已存在 Dataset 快取資料的計算節點上執行。再加上資料集預熱、快取容量監控和彈性伸縮，可以大大降低任務遠端拉取資料的開銷。Fluid 可以將多個不同類儲存服務作為資料來源（比如 OSS，HDFS）聚合到同一個 Dataset 中使用，還可以接入不同位置的儲存服務實現混合雲環境下的資料管理與訪問加速。
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/5c7c8268df1b49769ca6c192bf252050.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16)

圖 16：Fluid Dataset

演算法工程師在 AI 任務容器中使用 Fluid Dataset 與在 Kubernetes 中使用 PVC（Persistent Volume Claim）的方式類似，只需在任務描述檔案中指定 Dataset 的名字，並作為 volume 掛載到容器中任務讀取資料的路徑即可。我們希望為訓練任務增加 GPU 資源，能近乎線性地加快模型的訓練速度。但往往受限於更多 GPU 併發拉取 OSS bucket 的頻寬限制，單純增加 GPU 並不能有效提速訓練。透過使用 Fluid Dataset 的分散式快取能力，有效化解了遠端併發拉資料的效能瓶頸，使得分散式訓練擴充套件 GPU 獲得更好的加速比。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/25ec005acff140ef8f3ec3e2fdb614fb.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_17,color_FFFFFF,t_70,g_se,x_16)

圖 17：Fluid 分散式快取加速模型訓練效能對比

ACK 團隊聯合南京大學、Alluxio 公司，共同發起了 Fluid 開源專案[8]，並託管為 CNCF 沙箱專案，希望能與社群一起推動雲原生資料編排和加速領域的發展和落地。Fluid 的架構可以透過 CacheRuntime plugin 的方式，擴充套件相容多種分散式快取服務。目前已經支援了阿里雲 EMR 的 JindoFS，開源的 Alluxio，Juicefs 等快取引擎。無論在開源社群共建，還是雲上使用者落地都取得了不錯的進展。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/c7f99aa7ac5d4689abc2e003f887f81b.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16)

圖 18：Fluid 系統架構

Fluid 雲原生資料編排和加速的主要能力包括：
• 透過資料親和性排程和分散式快取引擎加速，實現資料和計算之間的融合，從而加速計算對資料的訪問。
• 將資料獨立於儲存進行管理，並且透過 Kubernetes 的名稱空間進行資源隔離，實現資料的安全隔離。
• 將來自不同儲存的資料聯合起來進行運算，從而有機會打破不同儲存的差異性帶來的資料孤島效應。

### 5、AI 作業生命週期管理（Arena）

ACK 雲原生 AI 套件提供的所有元件都以 Kubernetes 標準介面（CRD）和 API 形式，交付給 AI 平臺開發運維人員呼叫。這對基於 Kubernetes 構建雲原生 AI 平臺來說是非常方便和易用的。

但對於資料科學家和演算法工程師開發訓練 AI 模型來說，Kubernetes 的語法和操作卻是一種“負擔”。他們更習慣在 Jupyter Notebook 等 IDE 中除錯程式碼，使用命令列或者 Web 介面提交、管理訓練任務。任務執行時的日誌、監控、儲存接入、GPU 資源分配和叢集維護，最好都是內建的能力，使用工具就可以簡單操作。

對於 AI 服務的生產過程，主要包含資料準備與管理、模型開發構建、模型訓練、模型評測、模型推理服務上線運維等階段。這些環節以迴圈迭代的方式，根據線上資料變化，持續最佳化更新模型，透過推理服務將模型釋出到線上，收集到新的資料，進入下一輪迭代。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/1467da4ccbff426aa3a6477a6b40071e.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_12,color_FFFFFF,t_70,g_se,x_16)

圖 19：深度學習 AI 任務生命週期

雲原生 AI 套件將這個生產過程中的主要工作環節進行抽象，並以命令列工具 Arena[9] 實現管理。Arena 完全遮蔽了底層資源和環境管理，任務排程，GPU 分配和監控的複雜性，相容主流 AI 框架和工具，包括 Tensorflow, Pytorch, Horovod, Spark, JupyterLab, TF-Serving, Triton 等。

除了命令列工具，Arena 還支援 golang/java/python 語言 SDK，便於使用者二次開發。另外，考慮到不少資料科學家習慣使用 Web 介面管理資源和任務，雲原生 AI 套件也提供了簡單的運維大盤和開發控制檯，滿足使用者快速瀏覽叢集狀態、提交訓練任務的需要。這些元件共同形成了雲原生 AI 作業管理工具集 Arena。

Kubeflow[10] 是 Kubernetes 社群中支援機器學習負載的主流開源專案。Arena 已經內建 Kubeflow 的 TensorflowJob，PytorchJob，MPIJob 任務控制器，以及開源的 SparkApplication 任務控制器，也可以整合 KFServing，Kubeflow Pipelines 專案。使用者在 ACK 叢集中無需單獨安裝 Kubeflow，只需要使用 Arena 即可。

值得一提的是，ACK 團隊早期也將 arena 命令列和 SDK 工具貢獻到了 Kubeflow 社群，有很多企業使用者透過擴充套件、封裝 arena，構建了自己的 AI 平臺 MLOps 流程和體驗。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/ebf2ccf013cf4612a2c7c4d774f1bb52.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16)

圖 20：Arena 架構

雲原生 AI 套件主要為以下兩類使用者解決問題：
• **AI 開發人員**，如資料科學家和演算法工程師
• **AI 平臺運維人員**，如 AI 叢集管理員

AI 開發人員可以使用 arena 命令列或者開發控制檯 Web 介面，建立 Jupyter notebook 開發環境，提交和管理模型訓練任務，查詢 GPU 分配情況，實時檢視訓練任務日誌、監控和視覺化資料，對比評測不同模型版本，並將選出的模型部署到叢集，還可以對線上模型推理服務進行 AB 測試、灰度釋出、流控和彈性伸縮。

```css
# 提交Tensorflow分散式訓練任務
arena submit mpijob
    --name=tf-dist-data --workers=6 --gpus=2 --data=tfdata:/data_dir \
    --env=num_batch=100 --env=batch_size=80 --image=ali-tensorflow:gpu-tf-1.6.0 \ 
    "/root/hvd-distribute.sh 12 2”
```

```css
# 檢視訓練任務狀態
arena get tf-dist-data
NAME          STATUS       TRAINER  AGE  INSTANCE                              NODE
tf-dist-data  RUNNING        tfjob       3d     tf-dist-data-tfjob-ps-0        192.168.1.120
tf-dist-data  SUCCEEDED  tfjob       3d     tf-dist-data-tfjob-worker-0   N/A
tf-dist-data  SUCCEEDED  tfjob      3d     tf-dist-data-tfjob-worker-1     N/A
Your tensorboard will be available on:
192.168.1.117:32594
```

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/352ddcc50108400e9576d9d078bc0a51.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16)

圖 21：Arena 開發控制檯

AI 叢集管理員可以使用 Arena 運維大盤瞭解和管理叢集資源、任務 ，配置使用者許可權、租戶配額以及資料集管理等。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/4abec9a1d5f94184b06982e1b8d5d484.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16)

圖 22：Arena 運維大盤

### 使用者案例
雲原生 AI 套件在早期公測時已經獲得不少使用者的興趣和測試。使用者行業包括了網際網路、線上教育、自動駕駛等 AI 重度使用者。這裡分享兩個代表性使用者案例。

**• 微博**

微博深度學習平臺[11]藉助 Kubernetes 混合雲叢集，統一管理阿里雲上的 GPU 例項和 IDC 內的資源。

透過異構資源排程、監控和彈性伸縮能力，統一管理大量 GPU 資源。利用 GPU 共享排程能力，在 AI 模型推理服務場景大幅提升 GPU 利用率。
透過封裝 Arena，定製開發了微博自己的 AI 任務管理平臺，將所有深度學習訓練任務集中管理，工程效率獲得 50% 提升。

透過使用 AI 任務排程器，實現大規模 Tensorflow 和 Pytorch 分散式訓練任務的高效排程。

透過使用 Fluid + EMR Jindofs 分散式快取能力，尤其是針對 HDFS 中的海量小檔案快取最佳化，把  Pytorch 分散式訓練任務端到端速度提升了數倍。使用者測試極端情況下，訓練時長從兩週縮短到 16 小時[12]。

**• 毫末智行**

毫末智行是長城汽車投資的智慧駕駛明星創業公司。毫末很早期就啟動了基於雲原生技術構建統一 AI 工程平臺的工作。毫末首先使用 Kubeflow， arena 工具集，GPU 統一排程等能力構建起自己的機器學習平臺。進而整合了 Fluid+JindoRuntime，顯著提升了雲端訓練和推理的效率，尤其是一些小模型，在雲端做訓練和推理  JindoRuntime 可以有效解決 IO 瓶頸問題，訓練速度最高可提升約 300% 。同時也大幅度提升雲端 GPU 使用效率，加速了在雲端資料驅動的迭代效率。
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/b888d72acefd4c6d8db42b4511a74ad4.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16)

圖 23：毫末智行 AI 平臺使用 Fluid 資料集加速分散式 GPU 訓練

毫末智行不僅分享了基於 ACK 的雲原生 AI 在自動駕駛領域的應用探索與落地實踐[13]，也會和 Fluid 等雲原生 AI 社群一起共建，計劃進一步加強：

• 支援定時任務支援動態擴縮容
• 提供效能監控控制檯
• 支援規模化 Kubernetes 叢集中多資料集的全生命週期管理
• 支援對快取資料和快取後設資料的動態刪減

## 展望

企業 IT 轉型大潮中對數字化和智慧化的訴求越來越強烈，最突出的需求是如何能快速、精準地從海量業務資料中挖掘出新的商業機會和模式創新，以更好應對多變、不確定性的市場挑戰。AI 人工智慧無疑是當下和未來幫助企業實現這一目標最重要的手段之一。顯然，如何持續提升 AI 工程效率，最佳化 AI 生產成本，不斷降低 AI 門檻，實現 AI 能力普惠，具有很大的現實價值和社會意義。

我們清晰地看到，雲原生在分散式架構、標準化 API 和生態豐富度上的優勢，正在迅速成為使用者高效使用雲端計算的新介面，來幫助業務提升服務敏捷性和可擴充套件性。越來越多使用者也在積極探索如何基於雲原生容器技術，提升 AI 服務的生產效率。進而利用同一套技術堆疊支撐企業內部各種異構工作負載。

阿里雲 ACK 提供雲原生 AI 套件產品，從底層異構計算資源，AI 任務排程，AI 資料加速，到上層計算引擎相容和 AI 作業生命週期管理，全棧支撐 AI 生產和運維過程。以簡潔的使用者體驗，可擴充套件的架構，和統一最佳化的產品實現，加速使用者定製化構建雲原生 AI 平臺的程式。我們也將部分成果分享到社群，以共同推動雲原生 AI 領域的發展和落地。

## 相關連結

[1] 雲原生（Cloud Native）
https://github.com/cncf/toc/blob/main/DEFINITION.md

[2] 2021 年度調查報告
https://www.cncf.io/blog/2021/12/20/new-slashdata-report-5-6-million-developers-use-kubernetes-an-increase-of-67-over-one-year/

[3] 阿里雲容器服務 ACK
https://help.aliyun.com/product/85222.html

[4] 雲原生 AI 套件
https://help.aliyun.com/document_detail/270040.html

[5] 釋出了 ACK 雲原生 AI 套件產品
https://yqh.aliyun.com/live/cloudnative_ai_release

[6] 安裝雲原生 AI 套件產品文件
https://help.aliyun.com/document_detail/201997.html

[7] ACK 排程器（Cybernetes）
https://help.aliyun.com/document_detail/214238.html

[8] Fluid 開源專案
https://github.com/fluid-cloudnative/fluid

[9] 命令列工具 Arena
https://github.com/kubeflow/arena

[10] Kubeflow
https://github.com/kubeflow/kubeflow

[11] 微博深度學習平臺
https://www.infoq.cn/article/MXpf_TOJH9P10Ppdq9hl

[12] 訓練時長從兩週縮短到 16 小時
https://www.infoq.cn/article/FClx4Cco6b1jomi6UZSy

[13] 雲原生 AI 在自動駕駛領域的應用探索與落地實踐
https://www.infoq.cn/article/YkTwXpZGaE86E29MdVo2

擺脫 AI 生產“小作坊”：如何基於 Kubernetes 構建雲原生 AI 平臺

相關文章