雙引擎 GPU 容器虛擬化，用戶態(tài)和內(nèi)核態(tài)的技術(shù)解析和實踐分享

2023-01-06 07:58:11來源：百度智能云技術(shù)站

?如何讓硬件算力發(fā)揮最大效率，是所有資源運(yùn)營商和用戶非常關(guān)注的問題。百度作為一家領(lǐng)先的 AI 公司，擁有可能是業(yè)界最全的 AI 應(yīng)用場景。

(相關(guān)資料圖)

在這篇文章中，將和大家分享和討論 GPU 容器虛擬化在復(fù)雜AI場景中的解決方案和廠內(nèi)的最佳實踐。

下面這張圖片的左右兩部分，在不同場合下已經(jīng)多次展示過，放到這里主要想強(qiáng)調(diào)算力需求 —— 硬件算力的指數(shù)型增長，與真實應(yīng)用場景中利用率偏低資源浪費(fèi)之間的矛盾。

左邊的部分是 OpenAI 統(tǒng)計的數(shù)據(jù)，從 2012 年以來，模型訓(xùn)練所需的算力每 3.4 個月翻一倍，截止到 AlphaGoZero 這類的大模型，訓(xùn)練算力已經(jīng)增長了 30 萬倍，并且這種趨勢還在繼續(xù)。一方面，隨著算力需求的增長，主流 AI 加速單元計算性能也在以每兩年翻一倍的速率增加。另一方面，資源利用效率卻制約著硬件效能的充分發(fā)揮。

右邊的部分是 Facebook 在 2021 年對數(shù)據(jù)中心 Machine Learning 負(fù)載分析的結(jié)果。大量的 AI 算力損失在故障、調(diào)度、時間片浪費(fèi)、空間單元浪費(fèi)等環(huán)節(jié)，真正的算力利用率不到 30%。我們相信，這也是國內(nèi)各大基礎(chǔ)設(shè)施運(yùn)營商所面臨的現(xiàn)狀。

剛才提到在線集群不到 30% 利用率可能不符合很多同學(xué)的認(rèn)知。在線的很多同學(xué)可能是模型和算法的開發(fā)者。我們普遍的認(rèn)知是，在訓(xùn)練和測試過程中利用率可以保持很高的水平，甚至可以達(dá)到 100% 利用率。

但模型在生產(chǎn)環(huán)境上線，會受到很多約束，這些約束導(dǎo)致利用率遠(yuǎn)遠(yuǎn)達(dá)不到我們的預(yù)期。?

下面我們用有限的篇幅總結(jié)一下主要的制約因素：

模型特點(diǎn)：每個模型網(wǎng)絡(luò)不同，調(diào)用的底層算子組合不同，很大程度上會影響 GPU 的利用率。服務(wù) SLA：不同場景下的服務(wù)需要不同的 SLA，有的服務(wù)實時性要求較高，甚至需要嚴(yán)格控制在 10ms 以內(nèi)，那么這些服務(wù)就不能通過增加 batchsize 的方式提升利用率，甚至 batchsize 只能為 1。流量模式：不同模型算法服務(wù)于不同的應(yīng)用場景，比如 OCR 識別，可能在工作期間被頻繁調(diào)用。而語音識別則更多的在通勤時間或者娛樂休閑時才會被調(diào)用，這樣就導(dǎo)致了一天中 GPU 利用率的峰谷波動。優(yōu)化效果：根據(jù)模型的迭代頻率以及覆蓋場景的不同，模型的優(yōu)化粒度也不盡相同?？上攵?，一個未經(jīng)充分優(yōu)化的模型利用率也很難達(dá)到較高的水平。容量冗余：模型上線前都要經(jīng)過詳細(xì)的容量規(guī)劃，最大流量是多少，是否需要多地域，在此過程中會預(yù)留難以忽略的容量冗余，這些冗余在平時也造成了算力的浪費(fèi)。

在上面種種約束條件的制約下，真實生產(chǎn)環(huán)境的利用率可能是接下來我們要展示的。我們從復(fù)雜多變的在線生產(chǎn)環(huán)境中抽象出這幾種利用率模式。

均值偏低型：如左上圖，為一個真實的在線推理業(yè)務(wù)，由于模型特點(diǎn)和服務(wù) SLA 的限制，GPU 的峰值利用率只有 10%，平均利用率會更低。峰谷波動型：如左下圖，是典型的在線推理業(yè)務(wù)的利用率模式，服務(wù)在白天會達(dá)到高峰，在深夜至第二天早上是利用率的低谷，全天平均利用率只有 20% 左右，低谷利用率只有 10% 不到。短時激增型：如右上圖，利用率曲線基本與左下圖一致，但在夜間黃金時段會有兩個明顯的利用率高峰，高峰階段的利用率高達(dá) 80%，為了滿足高峰階段的服務(wù)質(zhì)量，該服務(wù)在部署過程中會預(yù)留不小的 buffer，資源平均利用率也剛剛超過 30%。周期觸發(fā)型：如右下圖，是典型在線訓(xùn)練場景的利用模式，在線訓(xùn)練任務(wù)介于離線訓(xùn)練和在線推理之間，這是一種周期性批處理的任務(wù)。例如每 15 分鐘會有一批數(shù)據(jù)到達(dá)，但這批數(shù)據(jù)的訓(xùn)練只需要 2-3 分鐘，大量的時間 GPU 處于閑置狀態(tài)。

AI應(yīng)用場景復(fù)雜多變，上面只是列舉了四種典型場景。如何在復(fù)雜場景中，平衡業(yè)務(wù)性能與資源效率，是我們在 GPU 虛擬化中遇到的第一個挑戰(zhàn)。

GPU 虛擬化過程中我們面臨的第二個挑戰(zhàn)就是缺乏完善的 GPU 隔離與混布機(jī)制。

我們以目前主流的 NVIDIA GPU 為例。典型的 AI 軟硬件生態(tài)都分為這樣幾個層次 ——應(yīng)用 & 框架層，運(yùn)行時層，驅(qū)動層，硬件層。

首先最上層是用戶的應(yīng)用，這里包含了各種常見的框架 PaddlePaddle、TensorFlow、PyTorch 等等。在應(yīng)用層之下是硬件提供商封裝的 API 接口層，包含各類常用算子庫與硬件運(yùn)行時訪問接口。在這層 API 接口之下，是與硬件溝通的驅(qū)動層，該層位于內(nèi)核態(tài)，是直接與設(shè)備溝通的軟件接口層。位于最底層是真正的 AI 加速硬件，負(fù)責(zé)算子的執(zhí)行。

傳統(tǒng)的虛擬化方案，都會結(jié)合驅(qū)動內(nèi)核態(tài)以及硬件虛擬化邏輯實現(xiàn)。這兩個層次是硬件提供商最核心的 IP，一般是閉源的。后續(xù)會提到，當(dāng)前 GPU 原生的的隔離機(jī)制在靈活性和分配力度上都無法滿足云原生場景下的使用需求。

除了隔離機(jī)制，現(xiàn)有的混布機(jī)制也很難滿足復(fù)雜場景的需求，我們看到業(yè)界有很多共享調(diào)度的開源方案，這些開源方案只是從資源的層面把兩個任務(wù)簡單的調(diào)度到一張卡上。在實際場景中，簡單的共享會造成業(yè)務(wù)之間相互影響，長尾延遲甚至吞吐的惡化導(dǎo)致簡單共享無法真正應(yīng)用于生產(chǎn)環(huán)境。

在上文利用率模式分析一節(jié)我們看到不同的業(yè)務(wù)，不同的場景下，利用率模式都不盡相同。如何抽象業(yè)務(wù)場景，定制混布方案，是生產(chǎn)環(huán)境落地的關(guān)鍵。

為了讓大家更全面地了解 GPU 的發(fā)展以及虛擬化歷史，這里我們用一張圖來展示 GPU 虛擬化發(fā)展史。

GPU 應(yīng)用于通用計算最早可以追溯到 G80 時代的 Tesla 架構(gòu)，是第一代實現(xiàn)統(tǒng)一著色器的架構(gòu)，用通用處理器 SM 替代了原來的頂點(diǎn)、像素管線分離的圖形圖像處理器。

百度最早引進(jìn)的 GPU 可以追溯到 Fermi 架構(gòu)。從這個時間點(diǎn)開始，業(yè)界就出現(xiàn)了一批虛擬化方案，其中大部分以 API 劫持為主。這里的典型代表是 rCUDA，該項目最初由學(xué)術(shù)團(tuán)體維護(hù)，直到近期，還保持一定頻率的更新和迭代，但看起來以學(xué)術(shù)研究為主，并沒有在生產(chǎn)環(huán)境大范圍使用。

百度大規(guī)模引入 GPU 是在 Kepler 架構(gòu)，Kepler 架構(gòu)開啟了百度自研的超級AI計算機(jī)X-MAN 時代。X-MAN 1.0 首次實現(xiàn)單機(jī) 16 卡配置，可以在 PCIe 硬件層面實現(xiàn) CPU 和 GPU 的動態(tài)綁定和靈活配比。受限于單卡性能，當(dāng)時更多的考慮是擴(kuò)展，而不是切分。

隨后的 Pascal 架構(gòu)、Volta 架構(gòu)、Turing 架構(gòu)性能有了飛速提升，這時虛擬化的需求日益顯著起來。我們看到，最早從 Kepler 架構(gòu)，NV 官方提供了 GRID vGPU 虛擬化方案，最開始主要是面向圖形渲染和遠(yuǎn)程桌面場景。在 2019 年前后，針對 AI 和高性能計算場景也提供了解決方案。但這些方案都是基于虛機(jī)的，在 AI 場景中很少使用。

在 Ampere 這一代，NV 推出了 MIG 實例切分方案，該方案在硬件層面實現(xiàn)了 SM、MEM、L2 Cache 等多種硬件資源的切分，提供了良好的硬件隔離性能。但該方案從Ampere 架構(gòu)開始支持，且對于卡的型號還有一定的限制。只有 A100、A30 少數(shù)幾個型號可以支持。而且即使切分之后，單個實例的性能也超過了 T4 算力，并無法很好地解決當(dāng)前生產(chǎn)環(huán)境的效率問題。

大家對 GPU 架構(gòu)與虛擬化歷史脈絡(luò)有了一些印象之后，我們來詳細(xì)介紹下實現(xiàn) GPU虛擬化的幾個主要層次，或者說是技術(shù)路線。

實現(xiàn)資源虛擬化隔離，首先需要資源在時間或空間維度是可分的，在用戶視角看來就是多個任務(wù)可以并發(fā)（concurrent）或并行（parallel）地執(zhí)行。

這里我們在用戶態(tài)、內(nèi)核態(tài)、硬件多個層次上討論一下并行或并發(fā)空間。

由于 NV 的軟硬件生態(tài)是閉源的，這里的示意圖是我們綜合架構(gòu)白皮書，逆向論文和我們自己的理解而繪制的，不準(zhǔn)確的地方還希望大家及時指正。

用戶態(tài)方案

我們從上至下來看這張圖，首先多個進(jìn)程在 GPU 來看，天然就是并發(fā)的，也就是時分復(fù)用的。驅(qū)動和硬件負(fù)責(zé)以時間片輪轉(zhuǎn)的方式進(jìn)行任務(wù)的切換。利用這層機(jī)制，我們可以在 API 層面上實現(xiàn)計算資源、顯存資源的限制，達(dá)到虛擬化的效果。這里的 API 可以分為兩層，一層是驅(qū)動 API，這層 API 緊貼驅(qū)動，是所有上層調(diào)用訪問 GPU 必經(jīng)之路，只要控制了這層 API，就相當(dāng)于控制了用戶的資源訪問。這里先提一句， NV 提供的 MPS 技術(shù)可以實現(xiàn)空分復(fù)用，這也為業(yè)務(wù)性能的進(jìn)一步優(yōu)化提供了可能。在后續(xù)落地實踐部分我們會詳細(xì)展開。

內(nèi)核態(tài)方案

再往下一層是內(nèi)核態(tài)，無論是虛機(jī)層面的全虛擬化、半虛擬化，還是近兩年各大云廠商的容器方案，都是在內(nèi)核層實現(xiàn)了系統(tǒng)調(diào)用攔截和 MMIO 劫持，內(nèi)核態(tài)最大的困難在于很多寄存器和 MMIO 行為沒有很好的文檔說明，這些都需要復(fù)雜的逆向工程。

硬件方案

內(nèi)核態(tài)之下是硬件層，真正的并行是在這一層進(jìn)行保證的，無論是 NV 的 MIG 技術(shù)還是百度昆侖的 SR-IOV 技術(shù)，都在硬件邏輯上進(jìn)行了算力切分，實現(xiàn)了真正的并行和空分復(fù)用。如昆侖可以實現(xiàn) 1/3，1/2 的硬件劃分，A100 可以實現(xiàn)最小 1/7 粒度的資源劃分。

上面我們花了不小的篇幅向大家介紹了 GPU 虛擬化的挑戰(zhàn)和現(xiàn)狀，接下來我們看百度內(nèi)部是如何應(yīng)對這些挑戰(zhàn)的。

這張圖展示了百度智能云 ——雙引擎 GPU 容器虛擬化架構(gòu)。

這里強(qiáng)調(diào)容器，因為我們相信，未來 AI 全鏈路應(yīng)用會逐步收斂到云原生平臺，實現(xiàn)全容器化開發(fā)、訓(xùn)練、推理。據(jù) Gartner 調(diào)研顯示，2023 年 70% 的 AI 任務(wù)將會容器化部署。百度內(nèi)部容器化從 2011 年就開始了，目前已經(jīng)有 10 余年的部署和優(yōu)化經(jīng)驗，我們也致力于將這部分真刀真槍打磨出來的產(chǎn)品能力和優(yōu)化經(jīng)驗貢獻(xiàn)給社區(qū)和廣大的用戶。

這里還強(qiáng)調(diào)了雙引擎。在整體架構(gòu)中我們采用了用戶態(tài)和內(nèi)核態(tài)兩套隔離引擎，以滿足用戶對隔離性、性能、效率等多方面不同側(cè)重的需求。

在隔離引擎之上，是資源池化層，該層次基于我們對軟硬件體系深刻理解，逐步實 AI 加速資源的解耦、拉遠(yuǎn)和池化，是我們面向未來基礎(chǔ)設(shè)施打造的池化抽象層。

在資源池化層之上，是 Matrix / k8s 統(tǒng)一資源調(diào)度層（這里的 Matrix 是百度廠內(nèi)的容器化調(diào)度系統(tǒng)），在調(diào)度機(jī)制之上，我們會根據(jù)不同業(yè)務(wù)場景，抽象出來多種混布策略，包括共享混布，搶占混布，分時混布，潮汐混布等。這些混布策略，后續(xù)實踐部分會詳細(xì)展開。

依托于資源隔離和資源調(diào)度之上的是 AI 業(yè)務(wù)的全鏈路場景，包括模型開發(fā)、模型訓(xùn)練、在線推理。

接下來會分別給大家分享用戶態(tài)和內(nèi)核態(tài)隔離引擎的實現(xiàn)。

下圖是用戶態(tài)隔離引擎核心架構(gòu)示意圖。位于架構(gòu)圖最上的是用戶應(yīng)用，這里包含了各類常用框架，如PaddlePaddle、TensorFlow、PyTorch等。

位于用戶應(yīng)用之下的是一系列的 API Hook 接口，也是基于這套接口我們可以實現(xiàn) GPU 資源的本地使用和遠(yuǎn)程掛載。通過替換框架依賴的底層動態(tài)庫，實現(xiàn)資源的控制和隔離。需要重點(diǎn)說明的是，該方案對于應(yīng)用是完全透明的，必要的庫替換操作已經(jīng)由容器引擎和調(diào)度部分自動完成。

CUDA API 在 Hook 之后會通過兩個通路最終到達(dá)執(zhí)行器。在這里，絕大多數(shù) API ，如設(shè)備管理 API 經(jīng)過 Hook 之后不做任何操作直接 pass-through 給執(zhí)行器執(zhí)行。少數(shù)和資源申請相關(guān)的 API 會經(jīng)過一層攔截，通過這層攔截實現(xiàn)用戶態(tài)虛擬化的一系列功能。這層的邏輯實現(xiàn)得足夠高效，對性能的影響幾乎忽略不計。

目前用戶態(tài)隔離引擎可以提供豐富的隔離和控制功能，包括基礎(chǔ)的顯存隔離、算力隔離。我們還擴(kuò)展了很多高級功能：編碼器隔離、高優(yōu)搶占、顯存超發(fā)、顯存池化等等。?

用戶態(tài)方案的優(yōu)點(diǎn)是性能好，長尾延遲低，適合追求機(jī)制性能、極致效率的業(yè)務(wù)場景，如延遲敏感的在線推理業(yè)務(wù)。?

在隔離的基礎(chǔ)上，我們提供遠(yuǎn)程功能，遠(yuǎn)程的引入將大大提升資源配置的靈活度和使用效率，這一點(diǎn)我們將在本文最后展開。

本次分享是一次技術(shù)分享，這里用少量篇幅展開一下遠(yuǎn)程技術(shù)的重點(diǎn)和難點(diǎn)，希望能激發(fā)大家的業(yè)務(wù)思路和技術(shù)討論。

根據(jù)我們在前文虛擬化挑戰(zhàn)中講到的軟硬件技術(shù)棧， GPU 的遠(yuǎn)程訪問大致上也可以在硬件鏈路層、驅(qū)動層、運(yùn)行時層和用戶層實現(xiàn)，但經(jīng)過深入的技術(shù)分析并結(jié)合對業(yè)務(wù)場景的理解，我們認(rèn)為目前最適合的還是運(yùn)行時層。

確定運(yùn)行時層技術(shù)路線，如何實現(xiàn)？技術(shù)的重點(diǎn)是什么？我們認(rèn)為主要是語義一致性問題?；谶\(yùn)行時的遠(yuǎn)程，需要把原始的 local 進(jìn)程拆分為 client、 server 兩個進(jìn)程。CUDA 運(yùn)行時是閉源的，內(nèi)部實現(xiàn)邏輯無從探究。如何保證拆分進(jìn)程后仍保持原有的程序邏輯和 API 語義，這里我們用一對一線程模型保證 API 內(nèi)部的邏輯和語義對齊。

遠(yuǎn)程實現(xiàn)的難點(diǎn)是 API 繁多的問題，運(yùn)行時除了 libcudart.so 這個動態(tài)庫，還涉及cuDNN、cuBLAS、cuFFT 等一系列動態(tài)庫和 API，涉及數(shù)千個不同的 API 接口。我們用編譯技術(shù)實現(xiàn)了頭文件的自動解析和代碼的自動生成，并通過逆向技術(shù)完成了隱藏API的解析。

解決遠(yuǎn)程方案 0-1 適配之后，接下來的向后兼容性其實是比較好解決的。目前看來 CUDA API 相對穩(wěn)定，新版本只需要少量增量適配即可。

上面多次提到空分復(fù)用和時分復(fù)用。這里做一下詳細(xì)的解釋：

時分復(fù)用：顧名思義，是時間片層面的復(fù)用。這里與 CPU 的進(jìn)程調(diào)度類似，在單一時間片內(nèi)，只有一個 GPU 進(jìn)程在運(yùn)行。多個 GPU 進(jìn)程之間在微觀層面上是交替運(yùn)行的，只能成為并發(fā)（concurrent）。這也導(dǎo)致，在某一時間片內(nèi)，如果該進(jìn)程無法很好的利用計算資源，這些計算資源就是浪費(fèi)掉的?？辗謴?fù)用：與時分復(fù)用不同，空分復(fù)用時，在某一微觀時刻，多個進(jìn)程是可以同時運(yùn)行在一個 GPU 上的，只要這個 GPU 的資源沒有用滿，其它進(jìn)程的 Kernel 就可以發(fā)射上來，兩個進(jìn)程的 Kernel 在微觀層面上是交織運(yùn)行的，真正實現(xiàn)了并行（parallel），進(jìn)一步利用 GPU 資源。

如綜述部分介紹，當(dāng)前常見的虛擬化方式，包括內(nèi)核態(tài)虛擬化、NVIDIA vGPU虛擬化，在底層實際都是基于時間片輪轉(zhuǎn)的時分復(fù)用方案。?

NV 面向多進(jìn)程并發(fā)場景推出了 MPS ——多進(jìn)程服務(wù)解決方案，該方案可以做到空分復(fù)用，是目前看到同時兼顧效率與性能的方案。?

這里簡單介紹一下 MPS，MPS 相當(dāng)于把兩個進(jìn)程的上下文融合成了一個進(jìn)程，融合后的進(jìn)程將之前兩個進(jìn)程的 Kernel 交織到一起進(jìn)行發(fā)射。這樣做有兩個好處：

進(jìn)程之間無需上下文切換，減少了上下文切換的開銷。同一時刻，不同進(jìn)程的 kernel 交織，提升了資源空間利用率。

說到 MPS，不得不提被人詬病的一個缺點(diǎn)——故障隔離問題。?

如何解決這個 MPS 穩(wěn)定性問題的呢？百度智能云結(jié)合調(diào)度、容器引擎、業(yè)務(wù)?；钐岢鲆徽走M(jìn)程融合共享方案。

通過 kill 命令重定向?qū)崿F(xiàn)業(yè)務(wù)進(jìn)程優(yōu)雅退出通過 MPS 狀態(tài)檢測機(jī)制實現(xiàn)健康檢查和假死檢測通過服務(wù)保活實現(xiàn)用戶進(jìn)程自動重啟

該方案已經(jīng)覆蓋商業(yè)（延遲敏感型重要業(yè)務(wù)）90%+ 資源，并長期運(yùn)行超兩年的時間，在提供極致性能的同時，相信能夠滿足絕大多數(shù)用戶對穩(wěn)定性的需求。

隨著 MPS 的接受程度越來越高，NV 也不斷增強(qiáng) MPS 的穩(wěn)定性。這里可以提前透露一個好消息，NV 在今年下半年會在 MPS 穩(wěn)定性上大幅度增強(qiáng)，包括假死狀態(tài)檢測，進(jìn)程優(yōu)雅退出這些功能都會成為 MPS 產(chǎn)品的一部分，MPS 的穩(wěn)定性和易用性會進(jìn)一步提升。

在介紹高優(yōu)搶占功能之前，先和大家分享一下高優(yōu)搶占的業(yè)務(wù)場景。根據(jù)我們和廠內(nèi)外不同用戶的討論，大多數(shù) AI 應(yīng)用生產(chǎn)環(huán)境中按延遲敏感程度可以分為在線、近線、離線這三類任務(wù)。

在線任務(wù)，對延遲最高，一般是實時響應(yīng)用戶請求的推理任務(wù)；近線任務(wù)，是一般是批處理任務(wù)，對單條日志的延遲沒有要求，但對一批數(shù)據(jù)的完成時間有小時到分鐘級不等的要求；離線任務(wù)，對延遲無要求，只關(guān)注吞吐，一般是模型訓(xùn)練類任務(wù)。

如果我們把延遲敏感型任務(wù)定義為高優(yōu)任務(wù)，把延遲不敏感的近線離線任務(wù)定義為低優(yōu)任務(wù)。并在兩類任務(wù)混布時根據(jù)任務(wù)優(yōu)先級不同定義不同的 kernel 發(fā)射優(yōu)先級，就是我們上面提到的高優(yōu)搶占功能。?

實現(xiàn)原理如下圖所示，用戶態(tài)隔離引擎為高優(yōu)任務(wù)和低優(yōu)任務(wù)各自維護(hù)了一個邏輯上的 kernel 隊列。當(dāng)整體負(fù)載較低時，允許兩個隊列同時發(fā)射 kernel，這時兩個隊列的 kernel 是交織在一起運(yùn)行的。一旦負(fù)載增高，分級發(fā)射模塊就會第一時間 pending 低優(yōu)隊列的發(fā)射，從而保證高優(yōu)任務(wù)的執(zhí)行延遲。

該功能的優(yōu)勢是保證離線吞吐的同時，減少甚至避免了在線任務(wù)的影響。

同理，我們先介紹分時混布的定義和場景。

分時混布，在混布模式上有點(diǎn)像時間片輪轉(zhuǎn)的共享混布。不同之處在于分時混布針對顯存不提出了顯存 swap 方案，這樣在顯存長期占用但算力間歇使用或偶爾觸發(fā)的場景就派上了用場。當(dāng)進(jìn)程需要算力時獲取顯存的訪問權(quán)限，當(dāng)進(jìn)程完成運(yùn)算后釋放顯存的訪問權(quán)限，讓其它等待該權(quán)限的進(jìn)程獲得運(yùn)行機(jī)會，讓間歇閑置的 GPU 資源得到充分利用。

分時混布的核心技術(shù)是顯存 swap。我們可以類比 CPU 的內(nèi)存 swap，當(dāng)某一進(jìn)程的內(nèi)存不夠用了，系統(tǒng)會根據(jù)一定的策略換出一部分系統(tǒng)內(nèi)存資源到磁盤，從而騰挪出空間給在運(yùn)行的進(jìn)程使用。

顯存 swap 的實現(xiàn)原理如下圖所示。我們在顯存的物理地址上維護(hù)了一個顯存池，上層通過資源鎖來確定哪個進(jìn)程有權(quán)限使用 GPU。當(dāng)進(jìn)程獲得鎖時，顯存便會從內(nèi)存或磁盤搬運(yùn)到物理顯存池中，進(jìn)一步映射到虛擬地址空間供進(jìn)程使用。當(dāng)進(jìn)程釋放鎖時，會保留進(jìn)程的虛擬顯存空間，將物理顯存搬移到內(nèi)存或磁盤上。該鎖是互斥的，只有一個進(jìn)程可以獲得鎖，其它的進(jìn)程 pending 在等待隊列上，以 FIFO 的方式依次獲得資源鎖。

上面介紹了用戶態(tài)隔離引擎的功能實現(xiàn)，在實際應(yīng)用中，性能如何，對用戶的影響如何？這里我們直接上測試數(shù)據(jù)。

下圖是我們在公開測試集 MLPerf 上選擇典型模型 ResNet-50 Server 場景下的數(shù)據(jù)對比。圖中的柱子從左至右依次表示獨(dú)占、裸混、用戶態(tài)隔離、內(nèi)核態(tài)隔離下的性能。

左圖是平均吞吐對比，在推理場景下請求是間歇觸發(fā)的，我們可以看到，無論何種方案在吞吐下都能直接達(dá)到發(fā)壓值。這里想說明，推理場景下吞吐并不能很好的展示虛擬化性能，在生產(chǎn)環(huán)境中落地時應(yīng)該更多的關(guān)注延遲。

右圖是 P99 分位延遲的對比?？梢钥吹剑诘蛪毫ο拢≦PS = 40）用戶態(tài)，裸混對長尾延遲的影響基本一致，內(nèi)核態(tài)由于采用了時分復(fù)用，對長尾延遲影響稍大。我們繼續(xù)增大壓力，在 QPS = 60 時，用戶態(tài)的優(yōu)勢就顯現(xiàn)了，空分復(fù)用大大降低了對長尾延遲的影響。隨著壓力的進(jìn)一步加大，用戶態(tài)進(jìn)程融合方案甚至比其它混布方式有數(shù)量級的提升。

盡管長尾延遲控制不如用戶態(tài)，但在隔離性方面，內(nèi)核態(tài)具備優(yōu)勢，更側(cè)重于對隔離要求有強(qiáng)訴求的場景。?

下面我們來了解下內(nèi)核態(tài)隔離引擎的技術(shù)實現(xiàn)。

首先來看內(nèi)核態(tài)虛擬化實現(xiàn)的特點(diǎn)，包括如下：

內(nèi)核態(tài)實現(xiàn)；隔離性好：支持顯存，算力和故障隔離；顯存 MB 級隔離；算力 1% 級分配；支持 P4，V100，T4，A100/A10/A30 等主流 GPU；支持 410 到 510 GPU 驅(qū)動版本；用戶態(tài)運(yùn)行環(huán)境無需任何改變；支持容器化部署。

不同于用戶態(tài)的實現(xiàn)，內(nèi)核態(tài)虛擬化對 GPU 的隔離功能都是在內(nèi)核態(tài)實現(xiàn)。下圖的左半部分是我們內(nèi)核態(tài)虛擬化實現(xiàn)的一個架構(gòu)圖，從底層到上層，分別是 GPU 硬件，內(nèi)核層，用戶層。

硬件層面就是我們的 GPU，這個 GPU 可以裸機(jī)的 GPU，也可以是透傳的 GPU。

內(nèi)核層的底下是 GPU 原有的驅(qū)動，它實際控制著 GPU 的功能，真正操作 GPU 的都是這個驅(qū)動，然后 GPU 驅(qū)動上面就是我們實現(xiàn)的 GPU 虛擬化的一個內(nèi)核模塊，也就是 GPU 攔截驅(qū)動，就是黃色的部分，包含三部分功能，包括顯存攔截，算力攔截和算力調(diào)度。分別實現(xiàn)的顯存隔離，算力隔離。

用戶層，首先是攔截接口。這個接口是由攔截模塊提供的，分為兩部分：一部分是設(shè)備文件接口，一部分是配置攔截模塊的接口。設(shè)備文件是提供給容器的，我們先來看容器。容器上面是應(yīng)用，底下是 cuda runtime，在下面是cuda 底層庫，包括 driver api/nvml api 等。通過把我們的設(shè)備文件提供給容器作為假的設(shè)備文件，那么上層 cuda 訪問時，就訪問的是我們的設(shè)備文件，這樣就完成了 cuda 底層庫對訪問 GPU驅(qū)動的攔截。

?我們在內(nèi)核的攔截模塊，會攔截所有訪問的系統(tǒng)調(diào)用，攔截并解析，然后把真正的訪問，重定向到真正的 GPU 底層驅(qū)動。GPU底層驅(qū)動處理完后，把結(jié)果返回給我們的攔截模塊，攔截模塊再次進(jìn)行處理，最后把結(jié)果返回給容器里的底層庫。

簡單來說，就是通過模擬設(shè)備文件來攔截底層庫對 GPU 驅(qū)動的訪問，通過攔截、解析和注入等操作，完成顯存和算力等攔截。?

目前顯存隔離是通過攔截所有顯存相關(guān)的系統(tǒng)調(diào)用來實現(xiàn)，主要包括顯存信息，顯存分配和顯存釋放等。而且當(dāng)前顯存隔離只能靜態(tài)設(shè)置，不能動態(tài)改變。相對用戶態(tài)可以支持顯存超發(fā)，內(nèi)核態(tài)還無法做到顯存超發(fā)。

算力隔離方面，通過攔截進(jìn)程的 CUDA Context 來獲取相關(guān)信息。調(diào)度對象是進(jìn)程相關(guān)的 CUDA Context。CUDA Context 對應(yīng)的算力資源包括計算資源（Execution）和內(nèi)存拷貝（Copy）資源。每個 GPU 有一個內(nèi)核線程進(jìn)行此 GPU 上所有 CUDA Context 的調(diào)度。

我們實現(xiàn)了 4 種內(nèi)核態(tài)算力調(diào)度算法：

Fixed Share：每個 POD 分配固定的算力資源，即整個 GPU 的算力固定分為 n 份，每個 POD 分 1/n 的算力。Equal Share：所有活躍的 POD 平分算力資源，即活躍的 POD 數(shù)為 n，每個 POD 分 1/n 的算力。Weight Share：每個 POD 按照權(quán)重分配算力資源，即整個 GPU 的算力按照權(quán)重值分配給每個 POD。不管 POD 是否有業(yè)務(wù)負(fù)載，都按照權(quán)重分配算力。Burst Weight Share：活動的 POD 按照權(quán)重分配算力資源，即每個 POD 分配權(quán)重值，活躍的POD按照權(quán)重的比值分配算力。

內(nèi)核態(tài)因為是通過時間片進(jìn)行算力調(diào)度，所以對于延遲敏感型的業(yè)務(wù)不是很友好。我們特別開發(fā)了在離線混部技術(shù)，通過在線業(yè)務(wù)和離線業(yè)務(wù)進(jìn)行混部，大大提高在線業(yè)務(wù)的響應(yīng)速度的同時，也能讓離線業(yè)務(wù)共享 GPU 的算力資源，達(dá)到提高 GPU 資源使用率的目標(biāo)。我們在離線混部的特點(diǎn)是：

在線 POD：推理任務(wù)，平時占用少量算力。離線 POD：訓(xùn)練任務(wù)，平時占用大部分算力。

當(dāng)在線 POD 有任務(wù)負(fù)載時，立刻搶占離線 POD，占用全部算力提供推理服務(wù)。當(dāng)任務(wù)負(fù)載結(jié)束時，釋放算力給離線 POD。?

以下是內(nèi)核態(tài)算力隔離的評測結(jié)果：

測試環(huán)境是單卡 V100 SXM2 16G，訓(xùn)練場景下測試吞吐，測試采用 horovod 框架，模型為 resnet50。

POD 1 和 POD 2 的 weight 比值為 1:2。

上面的圖的結(jié)果，可以看出，POD 1 和 POD 2 吞吐比值在 45~50%，大概就是 1/2 這樣一個結(jié)果，符合我們預(yù)設(shè)的值。同時 POD SUM 較 Native 有 2~4%的損耗，因為算力隔離需要對 Cuda Context 進(jìn)行切換操作，不可避免有損耗，但是我們的損耗在 5% 以內(nèi)，可以說在容忍范圍中。

我們比較一下內(nèi)核態(tài)和用戶態(tài)的特點(diǎn)。

故障隔離方面，內(nèi)核態(tài)較用戶態(tài)有優(yōu)勢，而且內(nèi)核態(tài)不需要對底層庫進(jìn)行替換。用戶態(tài)算力調(diào)度采用時分加空分復(fù)用，內(nèi)核態(tài)采用的時分復(fù)用。用戶態(tài)高級功能包括在離線混部，顯存超發(fā)到內(nèi)存、編解碼實例（將 AI 加速卡的編碼跟解碼資源獨(dú)立分配），內(nèi)核態(tài)我們也支持在離線混部等。

如何利用虛擬化技術(shù)提升 AI 場景中 GPU 的利用效率，下面結(jié)合廠內(nèi)實際案例分享一下大規(guī)模 AI 場景下的最佳實踐。

我們首先看一個推理服務(wù)中的典型場景。由于模型本身架構(gòu)或者是服務(wù)延遲要求較高，某些任務(wù)只能在 batchsize 很小，甚至為 batchsize 為 1 的配置下運(yùn)行。直接導(dǎo)致 GPU 利用率長期偏低，甚至峰值利用率僅有 10%。

這種場景下，首先應(yīng)該想到的是多個低利用率任務(wù)之間進(jìn)行混布。

我們把這種混布策略歸納為共享混布。無論在開發(fā)、訓(xùn)練、還是推理場景，在多個低利用率任務(wù)之間，我們都可以采用共享混布。

結(jié)合上面提到過的進(jìn)程融合技術(shù)，可以在保證服務(wù)延遲的基礎(chǔ)上，實現(xiàn)2個實例甚至多實例的共享混布，資源利用率提升 2 倍以上。?

于此同時，多數(shù) GPU 上都有獨(dú)立的編解碼資源。在大多數(shù)場景下，如左下圖所示，該資源長期閑置。我們可以在共享計算資源的基礎(chǔ)上，再混布一個編碼或解碼實例，進(jìn)一步提升資源效能，激活閑置資源。

推理服務(wù)一個典型的負(fù)載模式是一天中峰谷波動明顯，且會出現(xiàn)不可預(yù)期的短時間流量激增。這就出現(xiàn)了雖然峰值很高，但平均利用率卻很差，均值經(jīng)常不到 30% 甚至 20%。

這類波動明顯，短時激增的服務(wù)如何進(jìn)行效率優(yōu)化呢？我們提出了搶占混布策略。

搶占混布是在峰值較高且延遲敏感的高優(yōu)業(yè)務(wù)上混布一個延遲不敏感的低優(yōu)任務(wù)。這里的高優(yōu)、低優(yōu)是由用戶自己定義，并且在申請資源時顯式聲明的。我們在百度內(nèi)部實踐中，會將近線、離線的刷庫或訓(xùn)練任務(wù)定義為低優(yōu)，這類業(yè)務(wù)對吞吐有一定的要求，對延遲基本上沒有要求。?

利用虛擬化功能中的高優(yōu)搶占機(jī)制，高優(yōu)任務(wù)時刻掌握占用資源的主動權(quán)。當(dāng)流量處于波谷時，整卡的負(fù)載不高，低優(yōu)任務(wù)可以正常運(yùn)行，一旦流量處于波峰或者出現(xiàn)短時激增，高優(yōu)搶占機(jī)制可以實時感知并且在 kernel 粒度上進(jìn)行算力的搶占，此時低優(yōu)任務(wù)會被限流甚至完全 pending，保障高優(yōu)任務(wù)的服務(wù)質(zhì)量。

這種混布模式下可能會出現(xiàn)顯存不足的情況，此時算力可能還有很大冗余。針對這類場景，我們提供了隱式的顯存超發(fā)機(jī)制。用戶可以通過環(huán)境變量對低優(yōu)任務(wù)進(jìn)行顯存超發(fā)，混布更多的實例，確保隨時有算力填充利用率的波谷，實現(xiàn)整體利用效率最大化。

第三類業(yè)務(wù)場景大家可能并不陌生，這就是顯存常駐、算力間歇性觸發(fā)場景。典型的代表業(yè)務(wù)是開發(fā)任務(wù)和在線訓(xùn)練。

這里以在線訓(xùn)練為例。我們知道很多模型需要根據(jù)用戶每日甚至每時的數(shù)據(jù)進(jìn)行在線更新，例如推薦模型，這就需要用到在線訓(xùn)練。和吞吐實時打滿的離線訓(xùn)練不同，在線訓(xùn)練需要積累一批數(shù)據(jù)后觸發(fā)一次訓(xùn)練。百度內(nèi)部，典型的模式可能是 15 分鐘到達(dá)一批數(shù)據(jù)，但真正的訓(xùn)練時間只有 2 到 3 分鐘，剩余的時間里這個訓(xùn)練進(jìn)程就常駐顯存等在那里，直至下一批數(shù)據(jù)從上游抵達(dá)。在此期間，利用率長期為 0，造成了大量的資源浪費(fèi)。

這類任務(wù)由于顯存基本占滿，無法使用上面提到的共享混布或搶占混布。結(jié)合之前提到的顯存 swap 機(jī)制，我們提出了分時混布策略。

分時混布類似于時間片輪轉(zhuǎn)的共享混布，但此時顯存也會隨著計算的上下文一同被換入換出。由于底層的虛擬化層無法感知業(yè)務(wù)何時需要計算，我們針對每張 GPU 卡，維護(hù)了一個全局的資源鎖。并封裝了相應(yīng)的 C++ 和 Python 接口供用戶調(diào)用。用戶只需要在需要計算的時候申請這把鎖，顯存就會從其它空間自動換入到顯存空間；在計算完成后釋放這把鎖，對應(yīng)的顯存會被換出到內(nèi)存或者磁盤空間。利用這個簡單的接口，用戶可以實現(xiàn)多個任務(wù)分時獨(dú)占 GPU。在線訓(xùn)練場景中，使用分時混布，可以在拉升整體利用率的基礎(chǔ)上實現(xiàn)最高 4/5 的資源節(jié)省。

上面提到的三個場景的最佳實踐，在百度內(nèi)部業(yè)務(wù)上已經(jīng)實現(xiàn)了長期驗證和規(guī)模落地。相關(guān)功能也已經(jīng)上線百度百舸·AI異構(gòu)計算平臺，大家可以即刻申請和試用。

這里我再用三分鐘左右的篇幅講一下還在內(nèi)部驗證中的功能，這些功能將會近期完成在百度百舸平臺的上線，進(jìn)一步解決在大規(guī)模AI場景下常見的配比不均、供需失衡、資源碎片等問題。

做基礎(chǔ)架構(gòu)的同學(xué)一定會經(jīng)常聽到資源的解耦、池化這類概念。如何將池化概念落地，并轉(zhuǎn)化為實際生產(chǎn)力，是我們一直以來積極探索和推進(jìn)的。早在 2015 年，我們就實現(xiàn)了業(yè)界首個基于 PCIe Fabric 方案的硬件池化方案，并在百度內(nèi)部實現(xiàn)規(guī)模化落地，這就是剛才提到的 X-MAN 1.0（目前已經(jīng)演進(jìn)到 4.0）。通過 PCIe Fabric 網(wǎng)絡(luò)配置 CPU 和 GPU之間的互聯(lián)，實現(xiàn)資源的動態(tài)分配，解決各類場景下的配比問題。受限于硬件連接和協(xié)議的限制，該方案只能解決機(jī)柜內(nèi)部的池化。

軟件層池化是我們認(rèn)為更靈活的技術(shù)方案。隨著數(shù)據(jù)中心網(wǎng)絡(luò)不斷升級，100G 甚至200G 的網(wǎng)絡(luò)未來會成為基礎(chǔ)設(shè)施的標(biāo)配，高速網(wǎng)絡(luò)為資源池化提供了通信高速路。

資源的解耦和池化讓業(yè)務(wù)擁有更大的靈活度，也為效能優(yōu)化提供了更大的想象空間。例如 CPU 和 GPU 之間的配比問題，開發(fā)場景中長期資源占用供需失衡效率低下的問題，訓(xùn)練場景中資源碎片任務(wù)阻塞問題、設(shè)備異常訓(xùn)練重啟問題，這類場景都能在池化及衍生方案中得到解決。

最后，上述分享的所有的虛擬化技術(shù)和最佳實踐，都已經(jīng)上線百度百舸·AI異構(gòu)計算平臺。在百度智能云官網(wǎng)搜索“百度百舸”，即刻加速 AI 任務(wù)，激發(fā)業(yè)務(wù)想象！

Q& A 精選

Q：一般資源通過 namespace 和 cgroup 來實現(xiàn)容器化。請問 GPU 通過什么技術(shù)實現(xiàn)資源控制的？

A：namespace 和 cgroup 都是內(nèi)核提供的機(jī)制，本質(zhì)上還要依賴于硬件提供的相關(guān)能力。這一點(diǎn)在目前 GPU 上是不存在的，GPU 目前并長期是閉源狀態(tài)，這些能夠 upstream 到內(nèi)核主線的功能只有硬件提供商有能力提供。當(dāng)前三方的方案都是在用戶態(tài)或內(nèi)核態(tài)做的非標(biāo)準(zhǔn)實現(xiàn)，暫時還沒有辦法納入 namespace 和 cgroup 范疇。但可以認(rèn)為 GPU 虛擬化要實現(xiàn)的就是這些接口下面對應(yīng)的機(jī)制，至于是否能標(biāo)準(zhǔn)化是另外一個更大的問題。

Q：請問除了 GPGPU 的虛擬化技術(shù)，咱們是否有開展 NPU 相關(guān)虛擬化技術(shù)？是否與 NV 技術(shù)棧進(jìn)行解耦。謝謝！

A：我理解這里說的 NPU 應(yīng)該是 Network Processing Unit，泛指當(dāng)前所有的 AI 加速硬件。我們正在做其它 AI 加速硬件的虛擬化適配。首先是昆侖芯，我們已經(jīng)在昆侖芯上做了上面提到虛擬化能力的適配。隨著場景的擴(kuò)展，會不斷適配其它主流加速硬件。

Q ：用戶態(tài)和內(nèi)核態(tài)是兩個不同的產(chǎn)品嗎？

A：是同一個產(chǎn)品，底層不同的實現(xiàn)方式，用戶接口層面是統(tǒng)一的。

Q ：用戶態(tài)虛擬化能做到什么顆粒度？

A：算力做到 1% 粒度切分，顯存做到 1MB 切分。

Q ：請問內(nèi)核態(tài)的虛擬化是否會造成較大的控制開銷？

A：內(nèi)核態(tài)虛擬化是基于時間分片的，這里的開銷是時間分片帶來的，精準(zhǔn)的隔離必然會帶來算力的損失。如果是指對應(yīng)用性能帶來的開銷，確實內(nèi)核態(tài)會比用戶態(tài)大一些。

Q ：按照時分實現(xiàn)的方案，在線推理感覺還是自由競爭平均時間更快。

A：按照我們測試結(jié)果來看，性能由好變差依次為：進(jìn)程融合，裸混（自由競爭），硬限隔離。

Q ：GPU 這兩種虛擬化的方式可以在一個 k8s 集群共存嗎？

A：從機(jī)制和原理來講，是可以做到共存的。但目前從產(chǎn)品維度不想設(shè)計的這么復(fù)雜，所以還是分開的。如果后續(xù)業(yè)務(wù)有廣泛的訴求，我們會考慮推出類似共存的方案。

Q ：請問可以詳細(xì)介紹下 k8s 的調(diào)度器如何擴(kuò)展嗎？是否需要節(jié)點(diǎn)上的 agent 上報 GPU 拓?fù)浜涂偭浚?/p>

A：需要，這塊需要單機(jī)的 agent 上傳資源（包括顯存資源和算力資源）和拓?fù)湫畔ⅰ?/p>