建站
咨詢
售后
建站咨詢
新聞中心
今天給大家分享的主題是百度智能云在「GPU 容器虛擬化」方面的最新進(jìn)展和全場景實(shí)踐，希望通過這次分享和大家一起探討如何在實(shí)際業(yè)務(wù)場景更好的應(yīng)用 GPU 容器虛擬化技術(shù)。
本次分享將首先介紹百度智能云 GPU 容器虛擬化 2.0 的升級變化，然后介紹新版本中的技術(shù)實(shí)現(xiàn)方法并演示具體功能，最后介紹在各類業(yè)務(wù)場景的實(shí)踐和探索。
1. 雙引擎 GPU 容器虛擬化 2.0
我們?nèi)ツ臧l(fā)布了業(yè)內(nèi)首個(gè)雙引擎 GPU 容器虛擬化架構(gòu)，采用了「用戶態(tài)」和「內(nèi)核態(tài)」兩種引擎，以滿足用戶對隔離性、性能、效率等多方面不同側(cè)重的需求。
在隔離引擎之上是資源池化層，該層次主要基于遠(yuǎn)程調(diào)用實(shí)現(xiàn)資源的解耦和池化。
在資源池化層之上是 K8s 統(tǒng)一資源調(diào)度層。在調(diào)度機(jī)制之上，我們會根據(jù)不同業(yè)務(wù)場景，抽象出來多種混布方式，包括共享混布、搶占混布、分時(shí)混布、潮汐混布等。
通過以上技術(shù)能力支持了各類 AI 業(yè)務(wù)的落地，包括模型開發(fā)、模型訓(xùn)練、在線推理等，大幅提升了 GPU 資源的使用率，減少了 GPU 的使用數(shù)量。
關(guān)于這些內(nèi)容更詳細(xì)全面的講解，在我們?nèi)ツ甑姆窒碇薪榻B過，文字稿件的鏈接在文末。
圖片
1.0 版本很好地滿足了 AI 場景的業(yè)務(wù)需求，不管是廠內(nèi)還是廠外的業(yè)務(wù)中，得到了比較廣泛的應(yīng)用。
我們的技術(shù)目標(biāo)就是希望：吃干榨盡所有資源，覆蓋所有業(yè)務(wù)場景，提升業(yè)務(wù)總體表現(xiàn)。
所以 1.0 版本還不夠完美，并沒有釋放 GPU 的全部能力：GPU 上的所有資源在容器虛擬化環(huán)境中并沒有完全使能，更多的場景是無法使用 GPU 容器虛擬化能力的，所以今年我們繼續(xù)推出了 2.0 版本。
圖片
這是我們雙引擎 GPU 容器虛擬化 2.0 架構(gòu)圖。
在 2.0 版本中， 除了對 GPU 的顯存和 AI 算力進(jìn)行隔離之外，還實(shí)現(xiàn)了對 GPU 的渲染算力和編解碼器的隔離。
基于這些新的能力，在資源調(diào)度層面可以提供渲染混布和編解碼混布，實(shí)現(xiàn)了 AI 算力、渲染算力、編解碼器等 GPU 全部資源的統(tǒng)一調(diào)度。
同時(shí)，2.0 版本可以通過多調(diào)度器的方式，支持客戶的現(xiàn)有業(yè)務(wù)平滑融合到我們的架構(gòu)中，這對客戶業(yè)務(wù)能夠快速使用最新的 GPU 容器虛擬化能力，是非常重要的。
在這些新能力的支持下，更多的業(yè)務(wù)場景，比如自動駕駛仿真、ARM 平臺的云游戲等都可以通過這套平臺提升資源利用率，將所需 GPU 的使用量明顯降低。
除此之外，兩個(gè)容器虛擬化引擎我們都會隨著底層庫的更新進(jìn)行不斷迭代，確保用戶能夠使用業(yè)界最新的技術(shù)。其中用戶態(tài)支持最新版本 nvidia driver 和cuda 12.1，內(nèi)核態(tài)支持 nvidia driver 525/530/535 等最新版本。
圖片
2. 新能力技術(shù)解析
接下來我會詳細(xì)介紹渲染算力和編解碼器隔離的技術(shù)方案。
首先我們先分析一下 AI 算力和渲染算力的區(qū)別。
在 NVIDIA GPU 上不僅能進(jìn)行 AI 計(jì)算，還可以做圖形的渲染計(jì)算。AI 負(fù)載通過 Cuda 訪問 GPU，渲染負(fù)載通過 OpenGL/Vulkan 訪問 GPU。 這兩類計(jì)算均使用相同的算力資源。
那么在 AI 計(jì)算隔離已經(jīng)實(shí)現(xiàn)的基礎(chǔ)上，渲染負(fù)載能否在 AI 計(jì)算的隔離環(huán)境中成功運(yùn)行？
如果渲染負(fù)載能夠隔離成功，使用哪種類型的 GPU 容器虛擬化引擎是合適的方案？
圖片
接下來我們詳細(xì)分析一下 AI 算力架構(gòu)。
從上往下看，最上層的是 AI APP，它們依賴于底層的 Cuda 系列庫，包括 cuda-x，cuda runtime 等，它們給上層 AI APP 提供易于使用的高級 API。再往下就是應(yīng)用層 driver 庫，包括 cuda driver，NVML 等，它們會通過設(shè)備文件和內(nèi)核態(tài)的 driver 進(jìn)行通信，最終達(dá)到使用 GPU 的目的。
架構(gòu)圖中灰色的箭頭是 AI 程序使用 GPU 的控制流，紅色的箭頭是 AI 程序使用 GPU 的的數(shù)據(jù)流。
那么 AI 算力架構(gòu)和渲染架構(gòu)有什么不一樣呢？我們繼續(xù)往下看。
圖片
渲染算力架構(gòu)，從上往下看，最上層的是 UI/3D APP，比如游戲引擎，它的底層庫相比 AI 算力架構(gòu)要復(fù)雜一些，調(diào)用底層庫主要包括兩種方式：通過轉(zhuǎn)發(fā)層 GLX 調(diào)用 X11 server，或者直接調(diào)用 EGL。
最終他們都會調(diào)用底層的圖形庫 OpenGL 或者 Vulkan，這些圖形庫就相當(dāng)于 AI 計(jì)算中的 Cuda 庫。
再往下就是應(yīng)用層 driver 庫，包括 libnvidia-glcore/libnvidia-eglcore/libdrm 等，它們也是通過設(shè)備文件和內(nèi)核態(tài)的 driver 進(jìn)行通信，最終達(dá)到使用 GPU 的目的。
架構(gòu)圖中灰色的箭頭是渲染程序使用 GPU 的控制流，紅色的箭頭是渲染程序使用 GPU 的數(shù)據(jù)流。
圖片
經(jīng)過以上分析和對比，我們可以發(fā)現(xiàn) AI 算力架構(gòu)和渲染算力架構(gòu)，雖然上層軟件不同，但是他們的控制流都是一致的，使用相同的設(shè)備文件和內(nèi)核模塊進(jìn)行通信。
回到我們之前的問題，渲染負(fù)載能否在 AI 計(jì)算的隔離環(huán)境中成功運(yùn)行？依據(jù)這個(gè)分析結(jié)果預(yù)測，渲染應(yīng)用是可以在 AI 算力的隔離環(huán)境中運(yùn)行。
但是在實(shí)際驗(yàn)證中，結(jié)論是否定的。
經(jīng)過逆向分析發(fā)現(xiàn)兩個(gè)方案的控制命令字存在一些差異，需要將這部分差異在隔離實(shí)現(xiàn)中區(qū)分開來。通過大量的實(shí)驗(yàn)后，最終在內(nèi)核層面實(shí)現(xiàn)了渲染算力的隔離。
為什么我們沒有選擇在用戶態(tài)實(shí)現(xiàn)這個(gè)方案呢？
因?yàn)橛脩魬B(tài)實(shí)現(xiàn)需要攔截的上層庫函數(shù)多，實(shí)現(xiàn)難度高。同時(shí)，對用戶的軟件不透明。所以通過用戶態(tài)實(shí)現(xiàn)渲染算力隔離并不是一個(gè)好的工程方案。
圖片
接下來我向大家演示 AI 算力和渲染算力的隔離效果。演示的硬件環(huán)境為一張 NVIDIA V100 16G。
在這個(gè) GPU 上運(yùn)行單個(gè) AI 負(fù)載，pytorch resnet50 訓(xùn)練，batch-size 為 32 時(shí)，分配 100% 算力，吞吐在 340 左右。運(yùn)行單個(gè)渲染負(fù)載，使用的 GPUtest 的 Furmask 測試，分配 100% 算力，F(xiàn)PS 在 550。在混合負(fù)載測試中，一個(gè) AI 負(fù)載，一個(gè)渲染負(fù)載，各分配 50% 算力，AI 負(fù)載的吞吐為 170，渲染的 FPS 為 260~270。
可以看到在單個(gè) GPU 上，AI 負(fù)載和渲染負(fù)載都實(shí)現(xiàn)了隔離，獲得了約一半的算力，得到了預(yù)期的性能表現(xiàn)。
圖片
在 2.0 版本中，另外一個(gè)新增的功能就是編解碼器的隔離。
我們分別在用戶態(tài)和內(nèi)核態(tài)都實(shí)現(xiàn)了編解碼實(shí)例。
用戶態(tài)的編解碼器實(shí)例中，編解碼器是裸混使用，不支持對編解碼器的算力做隔離，每個(gè)實(shí)例都可以全部編解碼算力。
內(nèi)核態(tài)的編解碼器實(shí)例中，我們實(shí)現(xiàn)了對編解碼器的隔離，在實(shí)例中編碼器的權(quán)重和 AI 算力、渲染算力的權(quán)重共享，做到統(tǒng)一算力分配。
那么內(nèi)核態(tài)和用戶態(tài)的實(shí)現(xiàn)有什么不同呢？用戶態(tài)在實(shí)例中使用的是編解碼器的全部算力，而內(nèi)核態(tài)實(shí)現(xiàn)了編解碼器的算力分配。比如在內(nèi)核態(tài)分配 20% 的算力，那么你就可以在內(nèi)核態(tài)的編解碼實(shí)例中使用 20% 的編解碼能力。
這樣我們就完成了 GPU 資源的統(tǒng)一算力分配和使能，做到了資源的吃干榨凈。
圖片
3. 全場景實(shí)踐
接下來我們將會結(jié)合前面的技術(shù)，做各個(gè)場景的實(shí)踐分享。
我們先看看用戶態(tài)和內(nèi)核態(tài)兩個(gè)引擎在技術(shù)和場景上的差異。
在技術(shù)特性對比上，業(yè)務(wù)層一般會在隔離性能的強(qiáng)弱、延時(shí)高低、資源分配顆粒度、多用戶支持能力等維度做技術(shù)考量，為應(yīng)用匹配合適的 GPU 容器虛擬化引擎。
依據(jù)這些特性的分析，我們列出了不同應(yīng)用場景適用的技術(shù)方案。
比如在線推理，對延時(shí)的要求很高，一般就會推薦用戶態(tài)的方案。離線推理，則兩種方案都可以選擇。在渲染仿真場景，由于用戶態(tài)不支持渲染隔離，故只能使用內(nèi)核態(tài)的方案。
圖片
這是一個(gè)經(jīng)典的互聯(lián)網(wǎng)的推薦業(yè)務(wù)，包含了數(shù)據(jù)處理、模型開發(fā)和在線服務(wù)等業(yè)務(wù)。其中數(shù)據(jù)處理和模型開發(fā)是離線業(yè)務(wù)，用來支持在線服務(wù)，所有業(yè)務(wù)都使用了大量的 GPU。
在沒有使用 GPU 容器虛擬化方案之前，每個(gè)業(yè)務(wù)實(shí)例使用一個(gè) GPU，通過大量的監(jiān)控?cái)?shù)據(jù)發(fā)現(xiàn)，在線推理服務(wù)的整體 GPU 使用率并不高，整體在 20%，這是一個(gè)業(yè)界普遍存在的問題。
因?yàn)樵诰€服務(wù)對時(shí)延要求比較高，我們在這種場景選擇部署用戶態(tài)的方案。在保證業(yè)務(wù) SLA 相同的情況下，大幅提升整體 GPU 資源使用率，將整體資源利用率到 35%。
在結(jié)合用戶態(tài)本身支持的搶占混布和分時(shí)混布，使得數(shù)據(jù)處理和模型開發(fā)等離線任務(wù)，可以和在線推理業(yè)務(wù)進(jìn)行在離線混布，當(dāng)在線業(yè)務(wù)處于波谷時(shí)，離線業(yè)務(wù)搶占較多 GPU 空閑資源進(jìn)行業(yè)務(wù)處理，節(jié)省了整體的 GPU 使用數(shù)量。
這種場景在廠內(nèi)和廠外都得到了大量的應(yīng)用，節(jié)省了很多的成本。在 GPU 資源比較緊張的時(shí)代是一個(gè)很好的技術(shù)選擇。
圖片
很多客戶的平臺中已經(jīng)存在自己定制的任務(wù)調(diào)度器，包括自定義的排隊(duì)算法等功能。客戶如果要引入第三方供應(yīng)商的 GPU 容器虛擬化平臺，則需要使用相應(yīng)的任務(wù)調(diào)度器。
如何使得定制的任務(wù)調(diào)度器和百度智能云的任務(wù)調(diào)度器在客戶業(yè)務(wù)中共存，一種方式是使用多套 K8s 集群，這會導(dǎo)致管理復(fù)雜。另外一種方式就是使用百度智能云開發(fā)的多調(diào)度器支持方案，在同一 K8s 調(diào)度集群內(nèi)使用多個(gè)調(diào)度器。
在這個(gè)方案里面我們將 GPU 資源分為兩個(gè)池子，通過標(biāo)簽識別兩個(gè) GPU 池的資源。任務(wù)描述使用不同的標(biāo)簽，K8s 會把任務(wù)分配對應(yīng)的任務(wù)調(diào)度器，從而使不同任務(wù)調(diào)度器的共存。
如果客戶使用的是開源版的任務(wù)調(diào)度器，未做深度改動，則可以通過這套方案實(shí)現(xiàn)業(yè)務(wù)的平滑過渡，最后將所有業(yè)務(wù)都遷移到百度智能云的任務(wù)調(diào)度器上。
圖片
開發(fā)人員會用小規(guī)模的模型進(jìn)行調(diào)試、驗(yàn)證、算子開發(fā)等工作，這些模型參數(shù)規(guī)模一般在 1.5B 以內(nèi)。一般使用一塊 A100 或者 A800 GPU進(jìn)行，支持 2~4 個(gè)用戶。
但是在開發(fā)過程中，GPU 有較多時(shí)間處于空閑狀態(tài)，導(dǎo)致整體 GPU 使用率較低。
同時(shí)，每個(gè)開發(fā)人員需要大量的存儲資源，保存自己的訓(xùn)練數(shù)據(jù)和模型數(shù)據(jù)，需要通過大容量的遠(yuǎn)程文件系統(tǒng)來存儲。
遠(yuǎn)程文件系統(tǒng)要掛載到客戶容器內(nèi)，需要采用不同參數(shù)進(jìn)行掛載，以掛載不同的卷。這是通過不同用戶的 user id 來識別用戶的身份來實(shí)現(xiàn)的。
但是用戶態(tài)虛擬化不支持不同 user id 的用戶使用，即不支持多用戶隔離，無法在此場景使用。內(nèi)核態(tài)虛擬化可以實(shí)現(xiàn)多用戶隔離，可以保證不同用戶同時(shí)掛載不同的資源來使用。
內(nèi)核態(tài)虛擬化支持 burst 調(diào)度策略，可以只針對活躍的容器負(fù)載，按照權(quán)重進(jìn)行算力分配。比如一個(gè) GPU，虛擬化給兩個(gè)用戶使用，平分 50% 的算力，當(dāng)只有一個(gè)用戶實(shí)際使用 GPU 時(shí)，調(diào)度策略會把所有算力分配給此用戶。當(dāng)兩個(gè)用戶都在使用時(shí)，各使用 50% 的算力。
這樣既提供了共享算力的能力，又總體提高了 GPU 的使用率和業(yè)務(wù)表現(xiàn)。
圖片
自動駕駛仿真場景涉及到了 3 個(gè)模塊，其中渲染仿真編碼模塊和感知推理模塊使用了 GPU，覆蓋了 AI 計(jì)算、圖形渲染和編解碼器等全部資源類型。
在沒有使用 GPU 容器虛擬化方案之前，渲染仿真編碼仿真使用一塊 GPU 運(yùn)行類似游戲引擎的環(huán)境，實(shí)時(shí)渲染出車輛和路面狀況，每隔 1 到 2 秒，截取一張圖片編碼后輸出給感知推理模塊。感知推理模塊使用另外一塊 GPU，運(yùn)行類似圖像識別和分類推理的 AI 模型，識別出車道線、行人、障礙物等，把數(shù)據(jù)給規(guī)控模塊。規(guī)控模塊會根據(jù)感知數(shù)據(jù)，規(guī)劃和控制車輛的下一步狀態(tài)，發(fā)送控制命令給仿真模塊，進(jìn)行下一步操作。
這時(shí)候業(yè)務(wù)對 GPU 的使用率都較低，不超過 50%。
我們采用內(nèi)核態(tài)虛擬化技術(shù)，在同一個(gè) GPU 上同時(shí)運(yùn)行仿真和推理任務(wù)，每個(gè)任務(wù)分配 50% 的算力，達(dá)到同時(shí)在一個(gè) GPU 運(yùn)行兩種不同的負(fù)載。同時(shí)數(shù)據(jù)在一個(gè) GPU 中的顯存?zhèn)鬟f，提高了數(shù)據(jù)傳輸效率，提升了業(yè)務(wù)性能。
相比過去，這樣在仿真環(huán)境提高了 100% 的 GPU 使用率。
圖片
云游戲通常是同一個(gè) GPU 上運(yùn)行多個(gè)容器，每個(gè)容器運(yùn)行著一個(gè)完整的 android 實(shí)例。在這個(gè)實(shí)例里包含了 android 的運(yùn)行時(shí)環(huán)境，在最上面會運(yùn)行一個(gè) android 游戲，例如王者榮耀、和平精英、原神等。
因?yàn)樵朴螒蚴菦]有真實(shí)屏幕的，只有模擬出來的虛擬屏幕，每個(gè)實(shí)例會使用 GPU 渲染資源，把游戲的圖像界面渲染到虛擬屏幕的上。這些圖像畫面會通過對虛擬屏幕的截屏和編碼，輸出成類似 H.264 視頻流，通過流媒體協(xié)議播放到用戶的手機(jī)客戶端上。
在沒有使用 GPU 容器虛擬化方案之前，多個(gè)云游戲?qū)嵗峭ㄟ^裸混爭搶的方式，共享 GPU 的渲染資源，可以說是沒有任何服務(wù)保證和資源隔離能力的，導(dǎo)致游戲體驗(yàn)無法進(jìn)行 SLA 管理。
由于手機(jī)云游戲運(yùn)行在 ARM 平臺中，我們做了大量新的技術(shù)開發(fā)，使得整個(gè)云原生 AI 平臺能夠運(yùn)行在 ARM 上。
我們使用內(nèi)核態(tài)方案來對每個(gè) android 實(shí)例進(jìn)行管理，進(jìn)行渲染顯存的隔離，保證顯存分配的 QoS。
那么在這個(gè)場景中，我們?yōu)槭裁礇]有用內(nèi)核態(tài)虛擬化對渲染算力和編解碼器做隔離？因?yàn)樵朴螒驅(qū)?shí)時(shí)性要求比較高，內(nèi)核態(tài)虛擬化無法滿足時(shí)延的要求，渲染隔離更多滿足對實(shí)時(shí)性不高的場景。所以在這個(gè)場景，只使用了內(nèi)核態(tài)虛擬化的顯存隔離能力，保證顯存分配的 QoS。
圖片
以上就是我今天和大家分享的全部內(nèi)容了。
當(dāng)前標(biāo)題：GPU容器虛擬化新能力發(fā)布和全場景實(shí)踐
URL標(biāo)題：http://fisionsoft.com.cn/article/cdhhpcc.html
