本文來自微信公眾號“twt企業(yè)IT社區(qū)”，作者/汪照輝，中國銀河證券架構(gòu)師，專注于容器云、微服務(wù)、DevOps、數(shù)據(jù)治理、數(shù)字化轉(zhuǎn)型等領(lǐng)域，對相關(guān)技術(shù)有獨特的理解和見解。擅長于軟件規(guī)劃和設(shè)計，提出的“平臺融合”的觀點越來越得到認同和事實證明。發(fā)表了眾多技術(shù)文章探討容器平臺建設(shè)、微服務(wù)技術(shù)、DevOps、數(shù)字化轉(zhuǎn)型、數(shù)據(jù)治理、中臺建設(shè)等內(nèi)容，受到了廣泛關(guān)注和肯定。
智能化應(yīng)用如人臉識別、語音識別、文本識別、智能推薦、智能客服、智能風(fēng)控等已廣泛應(yīng)用于各行各業(yè)，這些應(yīng)用被稱為判定式AI的范疇，通常和特定的業(yè)務(wù)場景相綁定，因此在使用GPU（Graphics Processing Unit）卡的時候也通常各自獨立，未考慮業(yè)務(wù)間GPU共享能力，至多實現(xiàn)vGPU虛擬化切分，從而一張物理GPU卡虛擬出多張vGPU，可以運行多個判定式AI應(yīng)用。隨著大模型的興起，對GPU算力的需求越來越多，而當(dāng)前現(xiàn)實情況使企業(yè)往往受限于有限的GPU卡資源，難以支撐眾多的業(yè)務(wù)需求，同時由于業(yè)務(wù)特性等，即便進行了虛擬化，往往難以充分使用GPU卡資源或持續(xù)使用資源，從而也造成有限的卡資源也無法有效利用。
從GPU虛擬化需求到池化需求
智能化應(yīng)用數(shù)量的增長對GPU算力資源的需求越來越多。NVIDIA雖然提供了GPU虛擬化和多GPU實例切分方案等，依然無法滿足自由定義虛擬GPU和整個企業(yè)GPU資源的共享復(fù)用需求。TensorFlow、Pytorch等智能化應(yīng)用框架開發(fā)的應(yīng)用往往會獨占一張GPU整卡（AntMan框架是為共享的形式設(shè)計的），從而使GPU卡短缺，另一方面，大部分應(yīng)用卻只使用卡的一小部分資源，例如身份證識別、票據(jù)識別、語音識別、投研分析等推理場景，這些場景GPU卡的利用率都比較低，沒有業(yè)務(wù)請求時利用率甚至是0%，有算力卻受限于卡的有限數(shù)量。單個推理場景占用一張卡造成很大浪費，和卡數(shù)量不足形成矛盾，因此，算力切分是目前很多場景的基本需求。再者，往往受限于組織架構(gòu)等因素，GPU由各團隊自行采購和使用，算力資源形成孤島，分布不均衡，有的團隊GPU資源空閑，有團隊無卡可用。
為解決GPU算力資源不均衡等問題，同時支持GPU算力的國產(chǎn)化替代，協(xié)調(diào)在線和離線資源需求、業(yè)務(wù)高峰和低峰資源需求、訓(xùn)練和推理、以及開發(fā)、測試、生產(chǎn)環(huán)境對資源需求不同，實現(xiàn)算力的統(tǒng)一管理和調(diào)度復(fù)用，實現(xiàn)GPU資源的切分、聚合、超分、遠程調(diào)用、應(yīng)用熱遷移等能力，提升GPU資源的利用率，GPU算力池化需求迫在眉睫。
GPU設(shè)備虛擬化路線
GPU設(shè)備虛擬化有幾種可行方案。
首先是PCIe直通模式（PCIe Pass-through技術(shù)，pGPU），也就是將物理主機上的整塊GPU卡直通掛載到虛擬機上使用。但這種方式是獨占模式，GPU卡沒有虛擬化切分，并不能解決多個應(yīng)用運行在一張卡上的問題，因此意義不是很大。
第二是采用SR-IOV技術(shù)，允許一個PCIe設(shè)備在多個虛擬機之間共享，同時保持較高性能。通過SR-IOV在物理GPU設(shè)備上創(chuàng)建多個虛擬vGPU來實現(xiàn)的，每個虛擬vGPU可以被分配給一個虛擬機，讓虛擬機直接訪問和控制這些虛擬功能，從而實現(xiàn)高效的I/O虛擬化。NVIDIA早期的vGPU就是這樣的實現(xiàn)，不過NVIDIA vGPU需要額外的license，額外增加了成本。SR-IOV雖然實現(xiàn)了1：N的能力，但其靈活性比較差，難以更細粒度的分割和調(diào)度。
第三是MPT（Mediated Pass-Through，受控的直通）模式。MPT本質(zhì)上是一種通用的PCIe設(shè)備虛擬化方案。兼顧了1:N靈活性、高性能、功能完整性，但邏輯上相當(dāng)于實現(xiàn)在內(nèi)核態(tài)的device-model，廠商通常不會公開硬件編程接口，因此采用MPT可能會形成廠商依賴。
用的最多的模式是API轉(zhuǎn)發(fā)模式。根據(jù)AI應(yīng)用的調(diào)用層次（如下圖），API轉(zhuǎn)發(fā)有多個層次，包括CUDA API轉(zhuǎn)發(fā)（圖中①）、GPU Driver API轉(zhuǎn)發(fā)（圖中②）和設(shè)備硬件層API轉(zhuǎn)發(fā)（圖中③）。設(shè)備硬件層API通常是難以獲得的，因此目前市面上通常采用CUDA API轉(zhuǎn)發(fā)模式（截獲CUDA請求轉(zhuǎn)發(fā)，也被稱為用戶態(tài)）和GPU卡驅(qū)動Driver API轉(zhuǎn)發(fā)模式（截取驅(qū)動層請求轉(zhuǎn)發(fā)，也被稱為內(nèi)核態(tài)）。
另外AI開發(fā)框架往往和GPU卡綁定（比如華為支持CANN框架，海光支持DTK框架，英偉達則支持TensorFlow、Pytorch等框架），AI應(yīng)用在使用AI框架時，也可以在AI框架層進行轉(zhuǎn)發(fā)，在AI應(yīng)用遷移時比較有用。
AI應(yīng)用調(diào)用層次
GPU虛擬化和共享方案
了解了GPU設(shè)備虛擬化的方式，基于設(shè)備虛擬化技術(shù)，看下GPU虛擬化和共享的實現(xiàn)方式。GPU虛擬化和共享有多種方案，英偉達從官方也提供了vGPU、MIG、MPS等方案，以及非官方的vCUDA、rCUDA、內(nèi)核劫持等多種方案。
NVIDIA VGPU方案
NVIDIA vGPU是NVIDIA提供的一種虛擬化方案，可靠性和安全性高，但不支持容器，只能虛擬化若干個vGPU，使用不靈活；無法動態(tài)調(diào)整資源比例；有一定的共享損耗；不支持定制開發(fā)，需支付額外license費用。
MIG方案
MIG是多實例GPU方案。只支持Linux操作系統(tǒng)，需要CUDA11/R450或更高版本；支持MIG的卡有A100,H100等比較高端的卡；支持裸機和容器，支持vGPU模式，一旦GPU卡設(shè)置了MIG后，就可以動態(tài)管理instance了，MIG設(shè)置時persistent的，即使reboot也不會受影響，直到用戶顯式地切換。借助MIG，用戶可以在單個GPU卡上獲得最多7倍的GPU資源，為研發(fā)人員提供了更多的資源和更高的靈活性。優(yōu)化了GPU的利用率，并支持在單個GPU上同時運行推理、訓(xùn)練和高性能計算（HPC）任務(wù)。每個MIG實例對于應(yīng)用程序都像獨立GPU一樣運行，使其編程模型沒有變化，對開發(fā)者友好。
MPS(Multi-Process Scheduling)
MPS多進程調(diào)度是CUDA應(yīng)用程序編程接口的替代二進制兼容實現(xiàn)。從Kepler的GP10架構(gòu)開始，NVIDIA引入了MPS，允許多個流（Stream）或者CPU的進程同時向GPU發(fā)射K ernel函數(shù)，結(jié)合為一個單一應(yīng)用程序的上下文在GPU上運行，從而實現(xiàn)更好的GPU利用率。當(dāng)使用MPS時，MPS Server會通過一個CUDA Context管理GPU硬件資源，多個MPS Clients會將他們的任務(wù)通過MPS Server傳入GPU，從而越過了硬件時間分片調(diào)度的限制，使得他們的CUDA Kernels實現(xiàn)真正意義上的并行。但MPS由于共享CUDA Context也帶來一個致命缺陷，其故障隔離差，如果一個在執(zhí)行kernel的任務(wù)退出，和該任務(wù)共享share IPC和UVM的任務(wù)一會一同出錯退出。
rCUDA
rCUDA指remote CUDA，是遠程GPU調(diào)用方案，支持以透明的方式并發(fā)遠程使用CUDA設(shè)備。rCUDA提供了非GPU節(jié)點訪問使用GPU的方式，從而可以在非GPU節(jié)點運行AI應(yīng)用程序。rCUDA是一種C/S架構(gòu)，Client使用CUDA運行庫遠程調(diào)用Server上的GPU接口，Server監(jiān)控請求并使用GPU執(zhí)行請求，返回執(zhí)行結(jié)果。在實際場景中，無需為本地節(jié)點配置GPU資源，可以通過遠程調(diào)用GPU資源從而無需關(guān)注GPU所在位置，是非常重要的能力，隔離了應(yīng)用和GPU資源層。
vCUDA
vCUDA采用在用戶層攔截和重定向CUDA API的方式，在VM中建立pGPU的邏輯映像，即vGPU，來實現(xiàn)GPU資源的細粒度劃分、重組和再利用，支持多機并發(fā)、掛起恢復(fù)等VM的高級特性。vCUDA庫是一個對nvidia-ml和libcuda庫的封裝庫，通過劫持容器內(nèi)用戶程序的CUDA調(diào)用限制當(dāng)前容器內(nèi)進程對GPU算力和顯存的使用。vCUDA優(yōu)點是API開源，容易實現(xiàn)；缺點是CUDA庫升級快，CUDA庫升級則需要不斷適配，成本高；另外隔離不準確無法提供算力精準限制的能力、安全性低用戶可以繞過限制等。目前市面上廠商基本上都是采用vCUDA API轉(zhuǎn)發(fā)的方式實現(xiàn)GPU算力池化。
GPU算力池化云原生實現(xiàn)
GPU池化（GPU-Pooling）是通過對物理GPU進行軟件定義，融合了GPU虛擬化、多卡聚合、遠程調(diào)用、動態(tài)釋放等多種能力，解決GPU使用效率低和彈性擴展差的問題。GPU資源池化最理想的方案是屏蔽底層GPU異構(gòu)資源細節(jié)(支持英偉達和國產(chǎn)各廠商GPU)，分離上層AI框架應(yīng)用和底層GPU類型的耦合性。不過目前AI框架和GPU類型是緊耦合的，尚沒有實現(xiàn)的方案抽象出一層能屏蔽異構(gòu)GPU?；诓煌蚣荛_發(fā)的應(yīng)用在遷移到其他類型GPU時，不得不重新構(gòu)建應(yīng)用，至少得遷移應(yīng)用到另外的GPU，往往需要重新的適配和調(diào)試。
算力隔離、故障隔離是GPU虛擬化和池化的關(guān)鍵。算力隔離有硬件隔離也就是空分的方式，MPS共享CUDA Context方式和Time Sharing時分的方式。越靠底層，隔離效果越好，如MIG硬件算力隔離方案，是一種硬件資源隔離、故障隔離方式，效果最好。但硬件設(shè)備編程接口和驅(qū)動接口往往是不公開的，所以對廠商依賴大，實施的難度非常大，靈活性差，如支持Ampere架構(gòu)的A100等，最多只能切分為7個MIG實例等。NVIDIA MPS是除MIG外，算力隔離最好的。它將多個CUDA Context合并到一個CUDA Context中，省去Context Switch的開銷并在Context內(nèi)部實現(xiàn)了算力隔離，但也致額外的故障傳播。MIG和MPS優(yōu)缺點都非常明顯，實際工程中用的并不普遍。采用API轉(zhuǎn)發(fā)的多任務(wù)GPU時間分片的實現(xiàn)模式相對容易實現(xiàn)和應(yīng)用最廣。
根據(jù)AI應(yīng)用使用GPU的調(diào)用層次，可以實現(xiàn)不同層次的資源池化能力。比如CUDA層、Diver層、硬件設(shè)備層等。在不同的抽象層次，將需要加速的應(yīng)用轉(zhuǎn)發(fā)(Forwarding)到GPU資源池中。總的來說，越靠底層的轉(zhuǎn)發(fā)性能損失越小，可操作的范圍越大；但同時，編程量也越大，也越難。
由于云原生應(yīng)用的大量部署，GPU算力資源池化需要支持云原生部署能力，比如說支持Kubernetes、Docker服務(wù)，通過K8s Pod綁定由GPU資源池按需虛擬出來的vGPU，執(zhí)行Pod中的應(yīng)用。不管是英偉達的GPU卡或者是國產(chǎn)GPU，所有的卡都在算力資源池中，當(dāng)前可以將不同的卡進行分類，不同框架的應(yīng)用按需調(diào)度到合適的分類GPU算力池上。從而提升資源管理效率。算力資源池同樣需要實現(xiàn)相應(yīng)的資源、資產(chǎn)管理和運行監(jiān)控和可觀測性，優(yōu)化調(diào)度能力，減少GPU資源碎片。隨著AI應(yīng)用需求的迅速增長，算力資源池化在未來一段時間內(nèi)將是企業(yè)關(guān)注的重要的一個方面。
