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

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

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

左邊的部分是 OpenAI 統(tǒng)計(jì)的數(shù)據(jù)，從 2012 年以來(lái)，模型訓(xùn)練所需的算力每 3.4 個(gè)月翻一倍，截止到 AlphaGoZero 這類(lèi)的大模型，訓(xùn)練算力已經(jīng)增長(zhǎng)了 30 萬(wàn)倍，并且這種趨勢(shì)還在繼續(xù)。一方面，隨著算力需求的增長(zhǎng)，主流 AI 加速單元計(jì)算性能也在以每?jī)赡攴槐兜乃俾试黾印Ａ硪环矫妫Y源利用效率卻制約著硬件效能的充分發(fā)揮。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

這里我們?cè)谟脩魬B(tài)、內(nèi)核態(tài)、硬件多個(gè)層次上討論一下并行或并發(fā)空間。

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

用戶態(tài)方案

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

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

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

硬件方案

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

上面多次提到空分復(fù)用和時(shí)分復(fù)用。這里做一下詳細(xì)的解釋?zhuān)?/p>

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

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

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

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

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

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

如何解決這個(gè) MPS 穩(wěn)定性問(wèn)題的呢？百度智能云結(jié)合調(diào)度、容器引擎、業(yè)務(wù)保活提出一整套進(jìn)程融合共享方案。

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

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

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

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

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

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

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

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

同理，我們先介紹分時(shí)混布的定義和場(chǎng)景。

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

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

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

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

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

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

右圖是 P99 分位延遲的對(duì)比。可以看到，在低壓力下（QPS = 40）用戶態(tài)，裸混對(duì)長(zhǎng)尾延遲的影響基本一致，內(nèi)核態(tài)由于采用了時(shí)分復(fù)用，對(duì)長(zhǎng)尾延遲影響稍大。我們繼續(xù)增大壓力，在 QPS = 60 時(shí)，用戶態(tài)的優(yōu)勢(shì)就顯現(xiàn)了，空分復(fù)用大大降低了對(duì)長(zhǎng)尾延遲的影響。隨著壓力的進(jìn)一步加大，用戶態(tài)進(jìn)程融合方案甚至比其它混布方式有數(shù)量級(jí)的提升。

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

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

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

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

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

硬件層面就是我們的 GPU，這個(gè) GPU 可以裸機(jī)的 GPU，也可以是透?jìng)鞯?GPU。

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

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

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

簡(jiǎn)單來(lái)說(shuō)，就是通過(guò)模擬設(shè)備文件來(lái)攔截底層庫(kù)對(duì) GPU 驅(qū)動(dòng)的訪問(wèn)，通過(guò)攔截、解析和注入等操作，完成顯存和算力等攔截。?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Q & A 精選

Q：一般資源通過(guò) namespace 和 cgroup 來(lái)實(shí)現(xiàn)容器化。請(qǐng)問(wèn) GPU 通過(guò)什么技術(shù)實(shí)現(xiàn)資源控制的？

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

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

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

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

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

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

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

Q ：請(qǐng)問(wèn)內(nèi)核態(tài)的虛擬化是否會(huì)造成較大的控制開(kāi)銷(xiāo)？

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

Q ：按照時(shí)分實(shí)現(xiàn)的方案，在線推理感覺(jué)還是自由競(jìng)爭(zhēng)平均時(shí)間更快。

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

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

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

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

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

Q ：請(qǐng)問(wèn)時(shí)分和空分的選擇上有什么建議嗎？

A： 延遲敏感型的在線推理任務(wù)，建議選擇基于進(jìn)程融合的空分方案。要求嚴(yán)格隔離的場(chǎng)景建議選擇時(shí)分方案。其它場(chǎng)景選擇兩者沒(méi)有區(qū)別。

Q ：內(nèi)核態(tài)能支持到哪個(gè) CUDA 版本？如果 NV 更新了，百度智能云的更新周期要多久？

A： 內(nèi)核態(tài)因?yàn)槭窃趦?nèi)核做的虛擬化，對(duì) CUDA 版本沒(méi)有特別要求，目前支持所有CUDA 版本。如果 NV 更新 CUDA，預(yù)期不需要做特別支持工作。

Q ：使用內(nèi)核態(tài)，需不需要使用專(zhuān)門(mén)的百度智能云提供的 OS 鏡像？專(zhuān)用的驅(qū)動(dòng)程序？

A：內(nèi)核態(tài)不需要百度智能云專(zhuān)門(mén)提供 OS 鏡像。目前我們對(duì) centos7 和 ubuntu 都做了支持。不過(guò)需要用我們自己的部署框架來(lái)使用。對(duì)容器鏡像沒(méi)有特別要求，都可以透明支持。

Q ：是不是只有在公有云才能使用？能私有化部署嗎？

A：公有云和私有云都可以部署和使用。?