7 月 9 日，GOTC 2021 全球開源技術峯會上海站與 WAIC 世界人工智能大會共同舉辦，峯會聚焦 AI 與雲原生兩大以開源驅動的前沿技術領域，邀請國家級研究機構與頂級互聯網公司的一線技術專家，爲參會的開發者和技術愛好者帶來了最硬的行業技術乾貨，提供了一個可貴的技術交流平臺。算法
在本次會議上，騰訊雲高級工程師高策進行了題爲「公有云上構建雲原生 AI 平臺的探索與實踐」的技術分享，介紹了 AI 類業務在公有云上的現狀以及相應的技術選型和麪臨的問題。最後經過分析開源社區和業界的趨勢，與聽衆分享了咱們對於將來全彈性的 AI 基礎設施的展望。編程
本文由這次分享演講內容整理而成，分享給你們一塊兒回顧精彩內容。緩存
關注【騰訊雲原生】公衆號，後臺回覆關鍵詞【雲原生AI】可獲取演講PPT原稿。服務器
背景與現狀
深度學習發展至今，新的模型結構層出不窮。自 2018 年 GPT-一、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 業務中還不能很好地利用彈性能力，而這是雲計算帶給咱們最大的紅利。只有依託真正的彈性架構，應用才能生於雲上，長在雲上，服務於企業降本增效的終極目標。
【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公衆號，及時獲取更多幹貨！！