7 月 9 日，GOTC 2021 全球開源技術峰會上海站與 WAIC 世界人工智慧大會共同舉辦，峰會聚焦 AI 與雲原生兩大以開源驅動的前沿技術領域，邀請國家級研究機構與頂級網際網路公司的一線技術專家，為參會的開發者和技術愛好者帶來了最硬的行業技術乾貨，提供了一個難得的技術交流平臺。
在本次會議上，騰訊雲高階工程師高策進行了題為“公有云上構建雲原生 AI 平臺的探索與實踐”的技術分享，介紹了 AI 類業務在公有云上的現狀以及相應的技術選型和麵臨的問題。最後通過分析開源社群和業界的趨勢，與聽眾分享了我們對於未來全彈性的 AI 基礎設施的展望。
本文由此次分享演講內容整理而成，分享給大家一起回顧精彩內容。
關注【騰訊雲原生】公眾號，後臺回覆關鍵詞【雲原生AI】可獲取演講PPT原稿。
背景與現狀
深度學習發展至今，新的模型結構層出不窮。自 2018 年 GPT-1、Bert 相繼問世，模型結構的引數量呈指數級增長。目前 Transformer 等結構不僅在自然語言處理領域發光發熱，在計算機視覺等領域，也呈野火燎原之勢。由此可見，未來對於算力和視訊記憶體的需求會越發強烈。而以 Nvidia 為代表的硬體廠商提供的硬體效能卻並不能與之同步提高。上圖展示了兩者之間的鴻溝，紅色線條是模型引數規模的變化趨勢，目前正在以每年 120 倍的速度提升。而綠色線條代表的視訊記憶體容量每年提高的速度只有 2 倍。
因此，無論是在計算機視覺、自然語言處理等領域，還是網際網路行業落地廣泛的搜尋廣告推薦領域，分散式訓練都成為了主流訓練方式。
與之相對應的，深度學習框架也呈百花齊放的態勢。傳統的框架如 TensorFlow、PyTorch、Keras 仍然十分流行。而一些新的框架也逐漸出現，比如微軟的 DeepSpeed、百度的 Paddle 等。
總結來說，目前 AI 在工業界的各個領域都有了廣泛的落地。傳統的搜尋廣告推薦領域自不必說，在視覺與自然語言處理領域，基於深度學習的方法已經成為了 state-of-art。在遊戲、機器人等領域，強化學習也在慢慢走向生產。為了滿足業務對複雜模型的需求，新的硬體和框架層出不窮。當然，還有一個非常明顯的趨勢，不少 AI 類業務正在上公有云，希望藉助公有云的彈性計算能力降低算力成本，提高效率。
在公有云上的 AI 落地
接下來，我們介紹一下在服務公有云上的客戶時關於雲原生 AI 的一些觀察。
基於公有云的雲原生 AI 目前正在逐漸落地，其中既包括稀疏類的搜尋/廣告/推薦業務，也包括稠密類的計算機視覺等業務。網際網路領域的推薦場景落地相對較多。也正是由於搜尋/廣告/推薦業務場景複雜，端到端延遲要求低，因此改造的成本相對較高，所以大多數業務，尤其是離線訓練過程，仍然不能很好地利用雲的彈效能力。
與此同時從深度學習框架的角度看，目前絕大多數的業務仍然在使用 TensorFlow。這與之前的觀察有一定的相關性。搜尋/廣告/推薦業務中 TensorFlow 仍然佔據了絕對的市場。但是目前 PyTorch 的使用也越來越多，尤其是在計算機視覺、自然語言處理等領域。
騰訊雲原生AI服務
結合我們的這些觀察和實踐，騰訊雲原生團隊圍繞著 Kubeflow 構建了騰訊雲容器服務的雲原生 AI 產品化方案。目前已經開始免費內測，歡迎聯絡我們試用，您的任何建議都會成為我們的寶貴動力。
騰訊云云原生AI服務為使用者提供了 AI環境的快速交付以及管理能力、彈性的 Jupyter 服務、以及分散式模型服務等能力，目前關於模型管理等產品特性也在逐步建設中。
此外，為了解決頻寬效能的瓶頸問題，我們不僅在儲存端聯合騰訊 COS 團隊，藉助 GooseFS 快取引擎優化，而且在計算端聯合騰訊雲優圖實驗室，藉助其在訓練與推理上多年來的經驗沉澱，準備推出高度優化的深度學習框架。我們會充分利用雲原生AI作為統一視窗的優勢，與騰訊雲多個團隊合作共建平臺，提供開箱即用的產品化能力，反哺客戶與社群。
更多關於雲原生AI的最佳實踐會在我們後續的《雲原生AI標準指南》以及《雲原生AI前沿觀察》系列中推出。
落地實踐
在介紹完公有云的 AI 雲原生落地情況後，我們分享一下在公有云上執行 AI 類業務的典型選型。首先是訓練相關的技術棧。首先，在最底層的雲伺服器側，一般而言是由雲廠商提供的虛擬機器或者裸金屬機器。目前大部分業務都採用 Kubernetes 容器服務，所以一般計算側會將伺服器組成 Kubernetes 叢集進行資源管理和排程。在其上，一般會依賴物件儲存、檔案儲存或者塊儲存進行訓練樣本和模型的儲存。一般而言在讀寫壓力不太大的場景下，大多使用物件儲存。相比於其他方式，物件儲存支援分層壓縮歸檔，價效比高。在讀寫壓力比較大的場景，檔案儲存和塊儲存有更多的落地。
為了能夠儘可能提高資料的吞吐，有時會利用一些計算側的快取進行加速。其中的選型包括 Alluxio 和騰訊雲物件儲存快取加速產品 GooseFS 等。通過把遠端的資料快取在計算側叢集中，避免了遠端拉取資料的開銷，在某些場景下能夠顯著地提高訓練速度。
構建在伺服器和儲存之上的是分散式訓練的基礎設施。目前 Kubeflow 被應用地最為廣泛。通過 Kubeflow，使用者可以輕鬆地建立出 TensorFlow、PyTorch、Horovod 等框架的分散式訓練任務。並且 Kubeflow 可以很好地與 Kubernetes 的各種特性協同工作，能夠支援 Volcano 等排程器。
儘管 Kubeflow 已經能夠支援使用者進行模型的訓練和評估，但是直接使用 Kubeflow 仍然具有一些問題。不同的資料依賴可能在不同的資料系統中，因此資料處理的邏輯可能非常複雜。為了簡化演算法工程師的使用流程，提高使用者體驗，一般在上層會構建一個流水線系統，用來將機器學習流程中的各個環節進行組合連線。同時會提供方便的可程式設計環境，幫助演算法工程師更快地實現業務。在這一環節中，一般來說可選的系統包括 Jupyter、Argo Workflow、Airflow、Kubeflow 等。從使用者的角度看，演算法工程師只需要關心最上層的實驗環境和流水線系統。而其下的各層 Infra 則由基礎設施團隊和公有云提供。這樣的分層能夠降低不同角色的工程師的心智負擔，提高效率。
接下來，我們就以分散式訓練為例，介紹選型中可能遇到的問題，以及解決辦法。在分散式訓練中，按照引數更新的方式不同，可以分為 Parameter Server（以下簡稱為 PS）Worker 的模式和 AllReduce 的模式。在 PS 模式下，一共有兩個角色參與訓練，分別是 PS 和 Worker。其中 Worker 負責主要的計算，計算好的梯度會傳送給對應的 PS，PS 更新對應的引數，隨後發回給 Worker。在 AllReduce 模式中，每個 Worker 中有全量的模型，不同 Worker 接受不同的資料，相互之間傳遞梯度，進行梯度的更新與同步。
無論上述的哪種訓練方式，都存在一些問題。首先是在模型引數較多的情況下，梯度或引數通訊時的網路頻寬需求很高，網路會成為訓練過程中的瓶頸。這一問題在稠密類模型的訓練中尤為明顯。其次，在一個執行深度學習任務的叢集上，往往執行著多個深度學習任務。不同的任務都需要訪問儲存，這時儲存頻寬也可能成為瓶頸。總結起來，在網路和儲存上，都有可能遇到頻寬不足的問題。
在公有云上，通常雲伺服器不提供 RDMA 網路卡，內網頻寬通常在 20-50Gbps 左右。在這樣的環境下，為了能夠降低梯度同步帶來的頻寬壓力，一般會需要進行梯度壓縮等優化。梯度壓縮可以降低單次同步的梯度大小，與此同時，也可以替換 AllReduce 的實現，選擇對低頻寬環境更為友好的實現，如 2DReduce 等。這些工作在騰訊雲的 Ti-Horovod 中都有對應實現。它在低頻寬的情況下會有比原生的 Horovod 更好的表現。
而如果在裸金屬等伺服器上進行訓練，則可以利用 RDMA 網路卡進行梯度的加速。在這樣的訓練環境中，存在一張 VPC 網路卡，用於與物件儲存等雲產品互動；一張 RoCE 網路卡以及一個顯示卡。因此需要進行一定的改造，來支援通過 VPC 網路卡進行訓練樣本的拉取，而梯度同步更新則通過 RDMA 網路卡進行。
而這樣的方式，會有比較高的概率遇到之前所說的儲存頻寬的問題。梯度的同步通過高頻寬的 RDMA 進行了加速，相對應地儲存上就更有可能成為瓶頸。為了解決這一問題，在公有云上可以利用計算側的快取產品，如騰訊雲的 GooseFS，或者開源的 Allxuio 等方案，將資料快取在叢集內，避免在訓練時線上拉取物件儲存中的資料，避免儲存帶來的瓶頸問題。
在推理場景下，架構相對更為簡單。最底層依然是雲伺服器組成的 Kubernetes 叢集，模型一般而言會儲存在物件儲存中，模型服務則會通過 TFServing、Triton Inference Server 或者自研服務框架的方式對外提供服務。
由於部分業務的端到端流程相對複雜，有繁複的前處理和後處理環節。如果使用 TFServing 或者 Triton Inference Server來實現，邏輯會尤為複雜。與此同時，模型服務會與內部的基礎設施有耦合，需要對接內部的閘道器等服務。因此自研服務框架的需求也相對旺盛。儘管 TFServing 和 Triton Inference Server 在開源領域廣受關注，但是目前仍有相當規模的業務使用自研服務框架。
未來展望
AI 業務在上公有云的過程中，有各種各樣的問題。在通訊、儲存側的頻寬瓶頸自不必說。除此之外，深度學習往往依賴 Nvidia 的諸多底層庫，以及 Python 的各類依賴。在整合環境中，Jupyter 佔用的 GPU 視訊記憶體以及計算的利用率過低等。
基礎架構的演進也一定會朝著解決這些問題的方向前進。我們認為，未來的 AI 基礎設施一定是全彈性的。在訓練場景下，原本的訓練方式需要將參與訓練的各個角色的配置固定下來。比如由 5 個 Worker 參與的分散式訓練任務，在訓練過程中需要保證有且僅有 5 個 Worker 參與。這使得資源的配置只能靜態地指定，在叢集資源情況發生變化時無法動態地調整參與訓練的 Worker 數量。
目前，能看到有越來越多的深度學習框架正在支援彈性訓練。以 Horovod 為例，它引入了 Driver 的概念，管理 Worker 的生命週期。當有任何一個 Worker 出現問題時，Driver 會捕獲到異常並且根據配置重新建立環，讓訓練繼續下去。在這一過程中，訓練不會中斷。這使得訓練任務可以在叢集負載低，有空閒 GPU 的時候擴容，在叢集負載高的時候縮容。這樣的架構能夠結合公有云的彈性例項等能力，在提高容錯性的同時，降低訓練的成本。
與之相似的，還有彈性的 Jupyter 能力。在 Jupyter 原本的實現中，每個 Kernel 都是與 Notebook 執行在一起的，這也就意味著它需要長期佔有一張完整的 GPU 卡，這同樣使得 GPU 的利用率得不到提升。Jupyter 在卡的使用上如果能夠做到按需申請使用，也一定會進一步地提高叢集的資源利用率，降本增效。
總結
最後，我們總結本次分享的主要觀點。目前公有云的內網頻寬仍然是制約 AI 業務上雲的一個主要問題。我們針對不同的場景有不同的方法可以緩解它，也有包括裸金屬在內的 RDMA 方案可供選擇。相信在未來隨著公有云網路頻寬的逐步提升，這將不再成為問題。
其次，工業界目前仍然缺乏 AI 基礎設施的事實標準。目前有非常多的開源 AI 基礎設施專案，其中 Kubeflow 是落地最多的，憑藉著與 Kubernetes 的深度整合，與公司內部現有的基礎設施能夠更好地協同工作，有一定的優勢。不過整體而言，目前這一領域仍然缺乏事實標準。各個系統之間的差異非常大。這也是目前這一領域最大的問題之一，各個公司的 AI 基礎設施都各有特色，難以像叢集排程領域 Kubernetes 一樣，在社群形成合力，共同推動行業進步。
最後，全彈性的架構是我們認為的下一步演進方向。目前在 AI 業務中還不能很好地利用彈效能力，而這是雲端計算帶給我們最大的紅利。只有依託真正的彈性架構，應用才能生於雲上，長在雲上，服務於企業降本增效的終極目標。
【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多幹貨！！
