公有云上構建雲原生 AI 平臺的探索與實踐 - GOTC 技術論壇分享回顧

騰訊雲原生 發表於 2021-07-26
Go

7 月 9 日,GOTC 2021 全球開源技術峰會上海站與 WAIC 世界人工智慧大會共同舉辦,峰會聚焦 AI 與雲原生兩大以開源驅動的前沿技術領域,邀請國家級研究機構與頂級網際網路公司的一線技術專家,為參會的開發者和技術愛好者帶來了最硬的行業技術乾貨,提供了一個難得的技術交流平臺。

在本次會議上,騰訊雲高階工程師高策進行了題為“公有云上構建雲原生 AI 平臺的探索與實踐”的技術分享,介紹了 AI 類業務在公有云上的現狀以及相應的技術選型和麵臨的問題。最後通過分析開源社群和業界的趨勢,與聽眾分享了我們對於未來全彈性的 AI 基礎設施的展望。

本文由此次分享演講內容整理而成,分享給大家一起回顧精彩內容。

關注【騰訊雲原生】公眾號,後臺回覆關鍵詞【雲原生AI】可獲取演講PPT原稿。

背景與現狀

公有云上構建雲原生 AI 平臺的探索與實踐 - GOTC 技術論壇分享回顧

深度學習發展至今,新的模型結構層出不窮。自 2018 年 GPT-1、Bert 相繼問世,模型結構的引數量呈指數級增長。目前 Transformer 等結構不僅在自然語言處理領域發光發熱,在計算機視覺等領域,也呈野火燎原之勢。由此可見,未來對於算力和視訊記憶體的需求會越發強烈。而以 Nvidia 為代表的硬體廠商提供的硬體效能卻並不能與之同步提高。上圖展示了兩者之間的鴻溝,紅色線條是模型引數規模的變化趨勢,目前正在以每年 120 倍的速度提升。而綠色線條代表的視訊記憶體容量每年提高的速度只有 2 倍。

因此,無論是在計算機視覺、自然語言處理等領域,還是網際網路行業落地廣泛的搜尋廣告推薦領域,分散式訓練都成為了主流訓練方式。

公有云上構建雲原生 AI 平臺的探索與實踐 - GOTC 技術論壇分享回顧

與之相對應的,深度學習框架也呈百花齊放的態勢。傳統的框架如 TensorFlow、PyTorch、Keras 仍然十分流行。而一些新的框架也逐漸出現,比如微軟的 DeepSpeed、百度的 Paddle 等。

公有云上構建雲原生 AI 平臺的探索與實踐 - GOTC 技術論壇分享回顧

總結來說,目前 AI 在工業界的各個領域都有了廣泛的落地。傳統的搜尋廣告推薦領域自不必說,在視覺與自然語言處理領域,基於深度學習的方法已經成為了 state-of-art。在遊戲、機器人等領域,強化學習也在慢慢走向生產。為了滿足業務對複雜模型的需求,新的硬體和框架層出不窮。當然,還有一個非常明顯的趨勢,不少 AI 類業務正在上公有云,希望藉助公有云的彈性計算能力降低算力成本,提高效率。

在公有云上的 AI 落地

公有云上構建雲原生 AI 平臺的探索與實踐 - GOTC 技術論壇分享回顧

接下來,我們介紹一下在服務公有云上的客戶時關於雲原生 AI 的一些觀察。

基於公有云的雲原生 AI 目前正在逐漸落地,其中既包括稀疏類的搜尋/廣告/推薦業務,也包括稠密類的計算機視覺等業務。網際網路領域的推薦場景落地相對較多。也正是由於搜尋/廣告/推薦業務場景複雜,端到端延遲要求低,因此改造的成本相對較高,所以大多數業務,尤其是離線訓練過程,仍然不能很好地利用雲的彈效能力。

與此同時從深度學習框架的角度看,目前絕大多數的業務仍然在使用 TensorFlow。這與之前的觀察有一定的相關性。搜尋/廣告/推薦業務中 TensorFlow 仍然佔據了絕對的市場。但是目前 PyTorch 的使用也越來越多,尤其是在計算機視覺、自然語言處理等領域。

騰訊雲原生AI服務

結合我們的這些觀察和實踐,騰訊雲原生團隊圍繞著 Kubeflow 構建了騰訊雲容器服務的雲原生 AI 產品化方案。目前已經開始免費內測,歡迎聯絡我們試用,您的任何建議都會成為我們的寶貴動力。
騰訊云云原生AI服務為使用者提供了 AI環境的快速交付以及管理能力、彈性的 Jupyter 服務、以及分散式模型服務等能力,目前關於模型管理等產品特性也在逐步建設中。
此外,為了解決頻寬效能的瓶頸問題,我們不僅在儲存端聯合騰訊 COS 團隊,藉助 GooseFS 快取引擎優化,而且在計算端聯合騰訊雲優圖實驗室,藉助其在訓練與推理上多年來的經驗沉澱,準備推出高度優化的深度學習框架。我們會充分利用雲原生AI作為統一視窗的優勢,與騰訊雲多個團隊合作共建平臺,提供開箱即用的產品化能力,反哺客戶與社群。
更多關於雲原生AI的最佳實踐會在我們後續的《雲原生AI標準指南》以及《雲原生AI前沿觀察》系列中推出。

落地實踐

公有云上構建雲原生 AI 平臺的探索與實踐 - GOTC 技術論壇分享回顧

在介紹完公有云的 AI 雲原生落地情況後,我們分享一下在公有云上執行 AI 類業務的典型選型。首先是訓練相關的技術棧。首先,在最底層的雲伺服器側,一般而言是由雲廠商提供的虛擬機器或者裸金屬機器。目前大部分業務都採用 Kubernetes 容器服務,所以一般計算側會將伺服器組成 Kubernetes 叢集進行資源管理和排程。在其上,一般會依賴物件儲存、檔案儲存或者塊儲存進行訓練樣本和模型的儲存。一般而言在讀寫壓力不太大的場景下,大多使用物件儲存。相比於其他方式,物件儲存支援分層壓縮歸檔,價效比高。在讀寫壓力比較大的場景,檔案儲存和塊儲存有更多的落地。

為了能夠儘可能提高資料的吞吐,有時會利用一些計算側的快取進行加速。其中的選型包括 Alluxio 和騰訊雲物件儲存快取加速產品 GooseFS 等。通過把遠端的資料快取在計算側叢集中,避免了遠端拉取資料的開銷,在某些場景下能夠顯著地提高訓練速度。

構建在伺服器和儲存之上的是分散式訓練的基礎設施。目前 Kubeflow 被應用地最為廣泛。通過 Kubeflow,使用者可以輕鬆地建立出 TensorFlow、PyTorch、Horovod 等框架的分散式訓練任務。並且 Kubeflow 可以很好地與 Kubernetes 的各種特性協同工作,能夠支援 Volcano 等排程器。

儘管 Kubeflow 已經能夠支援使用者進行模型的訓練和評估,但是直接使用 Kubeflow 仍然具有一些問題。不同的資料依賴可能在不同的資料系統中,因此資料處理的邏輯可能非常複雜。為了簡化演算法工程師的使用流程,提高使用者體驗,一般在上層會構建一個流水線系統,用來將機器學習流程中的各個環節進行組合連線。同時會提供方便的可程式設計環境,幫助演算法工程師更快地實現業務。在這一環節中,一般來說可選的系統包括 Jupyter、Argo Workflow、Airflow、Kubeflow 等。從使用者的角度看,演算法工程師只需要關心最上層的實驗環境和流水線系統。而其下的各層 Infra 則由基礎設施團隊和公有云提供。這樣的分層能夠降低不同角色的工程師的心智負擔,提高效率。

公有云上構建雲原生 AI 平臺的探索與實踐 - GOTC 技術論壇分享回顧

接下來,我們就以分散式訓練為例,介紹選型中可能遇到的問題,以及解決辦法。在分散式訓練中,按照引數更新的方式不同,可以分為 Parameter Server(以下簡稱為 PS)Worker 的模式和 AllReduce 的模式。在 PS 模式下,一共有兩個角色參與訓練,分別是 PS 和 Worker。其中 Worker 負責主要的計算,計算好的梯度會傳送給對應的 PS,PS 更新對應的引數,隨後發回給 Worker。在 AllReduce 模式中,每個 Worker 中有全量的模型,不同 Worker 接受不同的資料,相互之間傳遞梯度,進行梯度的更新與同步。

公有云上構建雲原生 AI 平臺的探索與實踐 - GOTC 技術論壇分享回顧

無論上述的哪種訓練方式,都存在一些問題。首先是在模型引數較多的情況下,梯度或引數通訊時的網路頻寬需求很高,網路會成為訓練過程中的瓶頸。這一問題在稠密類模型的訓練中尤為明顯。其次,在一個執行深度學習任務的叢集上,往往執行著多個深度學習任務。不同的任務都需要訪問儲存,這時儲存頻寬也可能成為瓶頸。總結起來,在網路和儲存上,都有可能遇到頻寬不足的問題。

公有云上構建雲原生 AI 平臺的探索與實踐 - GOTC 技術論壇分享回顧

在公有云上,通常雲伺服器不提供 RDMA 網路卡,內網頻寬通常在 20-50Gbps 左右。在這樣的環境下,為了能夠降低梯度同步帶來的頻寬壓力,一般會需要進行梯度壓縮等優化。梯度壓縮可以降低單次同步的梯度大小,與此同時,也可以替換 AllReduce 的實現,選擇對低頻寬環境更為友好的實現,如 2DReduce 等。這些工作在騰訊雲的 Ti-Horovod 中都有對應實現。它在低頻寬的情況下會有比原生的 Horovod 更好的表現。

公有云上構建雲原生 AI 平臺的探索與實踐 - GOTC 技術論壇分享回顧

而如果在裸金屬等伺服器上進行訓練,則可以利用 RDMA 網路卡進行梯度的加速。在這樣的訓練環境中,存在一張 VPC 網路卡,用於與物件儲存等雲產品互動;一張 RoCE 網路卡以及一個顯示卡。因此需要進行一定的改造,來支援通過 VPC 網路卡進行訓練樣本的拉取,而梯度同步更新則通過 RDMA 網路卡進行。

公有云上構建雲原生 AI 平臺的探索與實踐 - GOTC 技術論壇分享回顧

而這樣的方式,會有比較高的概率遇到之前所說的儲存頻寬的問題。梯度的同步通過高頻寬的 RDMA 進行了加速,相對應地儲存上就更有可能成為瓶頸。為了解決這一問題,在公有云上可以利用計算側的快取產品,如騰訊雲的 GooseFS,或者開源的 Allxuio 等方案,將資料快取在叢集內,避免在訓練時線上拉取物件儲存中的資料,避免儲存帶來的瓶頸問題。

公有云上構建雲原生 AI 平臺的探索與實踐 - GOTC 技術論壇分享回顧

在推理場景下,架構相對更為簡單。最底層依然是雲伺服器組成的 Kubernetes 叢集,模型一般而言會儲存在物件儲存中,模型服務則會通過 TFServing、Triton Inference Server 或者自研服務框架的方式對外提供服務。

公有云上構建雲原生 AI 平臺的探索與實踐 - GOTC 技術論壇分享回顧

由於部分業務的端到端流程相對複雜,有繁複的前處理和後處理環節。如果使用 TFServing 或者 Triton Inference Server來實現,邏輯會尤為複雜。與此同時,模型服務會與內部的基礎設施有耦合,需要對接內部的閘道器等服務。因此自研服務框架的需求也相對旺盛。儘管 TFServing 和 Triton Inference Server 在開源領域廣受關注,但是目前仍有相當規模的業務使用自研服務框架。

未來展望

AI 業務在上公有云的過程中,有各種各樣的問題。在通訊、儲存側的頻寬瓶頸自不必說。除此之外,深度學習往往依賴 Nvidia 的諸多底層庫,以及 Python 的各類依賴。在整合環境中,Jupyter 佔用的 GPU 視訊記憶體以及計算的利用率過低等。

公有云上構建雲原生 AI 平臺的探索與實踐 - GOTC 技術論壇分享回顧

基礎架構的演進也一定會朝著解決這些問題的方向前進。我們認為,未來的 AI 基礎設施一定是全彈性的。在訓練場景下,原本的訓練方式需要將參與訓練的各個角色的配置固定下來。比如由 5 個 Worker 參與的分散式訓練任務,在訓練過程中需要保證有且僅有 5 個 Worker 參與。這使得資源的配置只能靜態地指定,在叢集資源情況發生變化時無法動態地調整參與訓練的 Worker 數量。

目前,能看到有越來越多的深度學習框架正在支援彈性訓練。以 Horovod 為例,它引入了 Driver 的概念,管理 Worker 的生命週期。當有任何一個 Worker 出現問題時,Driver 會捕獲到異常並且根據配置重新建立環,讓訓練繼續下去。在這一過程中,訓練不會中斷。這使得訓練任務可以在叢集負載低,有空閒 GPU 的時候擴容,在叢集負載高的時候縮容。這樣的架構能夠結合公有云的彈性例項等能力,在提高容錯性的同時,降低訓練的成本。

公有云上構建雲原生 AI 平臺的探索與實踐 - GOTC 技術論壇分享回顧

與之相似的,還有彈性的 Jupyter 能力。在 Jupyter 原本的實現中,每個 Kernel 都是與 Notebook 執行在一起的,這也就意味著它需要長期佔有一張完整的 GPU 卡,這同樣使得 GPU 的利用率得不到提升。Jupyter 在卡的使用上如果能夠做到按需申請使用,也一定會進一步地提高叢集的資源利用率,降本增效。

總結

公有云上構建雲原生 AI 平臺的探索與實踐 - GOTC 技術論壇分享回顧

最後,我們總結本次分享的主要觀點。目前公有云的內網頻寬仍然是制約 AI 業務上雲的一個主要問題。我們針對不同的場景有不同的方法可以緩解它,也有包括裸金屬在內的 RDMA 方案可供選擇。相信在未來隨著公有云網路頻寬的逐步提升,這將不再成為問題。

其次,工業界目前仍然缺乏 AI 基礎設施的事實標準。目前有非常多的開源 AI 基礎設施專案,其中 Kubeflow 是落地最多的,憑藉著與 Kubernetes 的深度整合,與公司內部現有的基礎設施能夠更好地協同工作,有一定的優勢。不過整體而言,目前這一領域仍然缺乏事實標準。各個系統之間的差異非常大。這也是目前這一領域最大的問題之一,各個公司的 AI 基礎設施都各有特色,難以像叢集排程領域 Kubernetes 一樣,在社群形成合力,共同推動行業進步。

最後,全彈性的架構是我們認為的下一步演進方向。目前在 AI 業務中還不能很好地利用彈效能力,而這是雲端計算帶給我們最大的紅利。只有依託真正的彈性架構,應用才能生於雲上,長在雲上,服務於企業降本增效的終極目標。

【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊,掃碼關注同名公眾號,及時獲取更多幹貨!!
公有云上構建雲原生 AI 平臺的探索與實踐 - GOTC 技術論壇分享回顧

相關文章