Nvidia的GPU虚拟化调度方案

撞上电子

cagjmnezktt6404964817.png

, n( X5 t2 v' ?0 p! I/ ^

yltw4okijik6404964917.gif

6 B; m+ s' c9 u4 L* o! u5 b/ p' X
' u4 s; |5 t' l$ `6 \2 |
, r3 w6 f! r7 U' C1 ~6 N2 dGPU虚拟化调度方案
无论是基于虚拟机的PCI-E设备直通，还是基于Kubernetes的Device Plugin，对GPU调度的颗粒度都是整颗GPU芯片，这样，是不能将一颗GPU芯片共享给多个应用使用的。然而，在实践中，将GPU共享给多个应用使用是很常见的需求，特别是对于推理场景，往往不需要一直使用整颗GPU芯片的算力资源。所以，将昂贵的GPU分享给其他应用的能力就变得非常有价值。
6 ~. y9 }5 ]4 Y1 [! b' H因此，无论是GPU厂商、云计算厂商，还是开源社区，都推出了一系列GPU虚拟化方案。
5 Y  g8 ?$ J1 X8 U) ~0 _7 w本文节选自《大模型时代的基础架构：大模型算力中心建设指南》一书，2024年7月 电子工业出版社出版。
& S# o  X( @5 r) M
; v6 t! B" t3 e$ A; O
2 g# {. {8 D! o2 c6 |9 B7 u
6 ~4 [0 @+ F1 X7 ?4 @+ l$ bNvidia（英伟达）作为GPU领域的Top供应商，从2010年起就推出了GPU虚拟化的方案，其大致的发展路线图如图8-1所示。

3tqq2w3rya36404965017.png

& q- t( {7 N$ a在图8-1中，GPU虚拟化的发展路线分为三个阶段：以vCUDA为代表的APIRemoting阶段、以GRID vGPU为代表的Driver Virtualization（驱动虚拟化）阶段，以及以MIG为代表的Hardware Virtualization（硬件虚拟化）阶段。
API Remoting与vCUDA
+ y5 g2 a  l, h0 S4 ^8 i) A9 E, T8 PvCUDA技术出现于2010年前后，其实现思路是：在虚拟机中提供一个物理GPU的逻辑映像——虚拟GPU，在用户态拦截CUDA API，在虚拟GPU中重定向到真正的物理GPU上执行计算。同时，在宿主机上基于原生的CUDA运行时库和GPU驱动，运行vCUDA服务端，接管虚拟GPU拦截的CUDA API，同时进行计算任务的调度。
0 i$ v4 ~2 I. q: H" i1 X4 l9 YvCUDA的工作原理如图8-2所示。
( {8 P: }5 ~; ~( p; I( o

fatnttjzbpa6404965117.png

从图8-2可以看出，虚拟机的CUDA运行时库被替换为vCUDA，其作用就是拦截来自CUDA App的所有CUDA API调用。vCUDA运行时库会在内核中调用vGPU驱动（或称之为“客户端驱动”），vGPU驱动实际的作用就是通过虚拟机到宿主机的VMRPC（Virtual Machine Remote Procedure Call）通道，将CUDA调用发送到宿主机。宿主机的vCUDA Stub（管理端）接收到CUDA调用后，调用宿主机上真正的CUDA运行时库和物理GPU驱动，完成GPU运算。
' q& ]1 O; X* k在客户端驱动处理API之前，还需要向管理端申请GPU资源。每一个独立的调用过程都必须向宿主机的管理端申请GPU资源，从而实现GPU资源和任务的实时调度。
6 l) R! W; V. l, l- G$ x! ]0 X显然，vCUDA是一种时间片调度的虚拟化技术，也就是“时分复用”。此种实现对于用户的应用而言是透明的，无须针对虚拟GPU做任何修改，而且也可以实现非常灵活的调度，单GPU能服务的虚拟机数量不受限制。但缺点也是显而易见的：CUDA API只是GPU运算使用的API中的一种，业界还有DirectX/OpenGL等其他API标准，而且同一套API又有多个不同的版本（如DirectX 9和DirectX 11等），兼容性非常复杂。
' J) U" u# Q3 D- FNvidia如何在下一代GPU虚拟化技术中解决这一问题呢？
GRID vGPU
Nvidia在2014年前后推出了vCUDA的替代品——GRID vGPU。
+ e- I' l! c0 [( l0 }GRID vGPU是一种GPU分片虚拟化方案，也可以被认为是一种半虚拟化方案。“分片”实际上还是采用“时分复用”。
GRID vGPU的实现原理如图8-3所示。
% u+ @8 P* \, _+ ?5 C) _

gxvvr4tw0d46404965217.png

6 R# ^, k; a6 o9 y在图8-3中，VM中的CUDA应用调用的是原生的CUDA运行时库，但GuestOS（虚拟机操作系统）中的GPU驱动并不是访问GPU物理的BAR（BaseAddress Register），而是访问虚拟的BAR。
% W$ _$ a* H7 H. F) n5 G1 g在进行计算工作时，GuestOS的GPU驱动会将保存待计算Workload的GPA通过MMIO CSR（Configuration and Status Register）传递给HostOS中的GPU驱动，从而让HostOS的GPU驱动拿到GPA并将其转换为HPA，写入物理GPU的MMIOCSR，也就是启动物理GPU的计算任务。
' G% E9 V5 n4 \. }$ N7 e物理GPU在计算完成后，会发送一个MSI中断到HostOS的驱动，HostOS的驱动根据Workload反查提交这个Workload的vGPU实例，发送中断到对应的VM中。VM的GuestOS处理该中断，直到完成计算Workload，上报CUDA和应用，vGPU计算过程处理完毕。
, L; L7 b$ D; P- D8 e+ [vGPU方案也被称为MPT（Mediated Pass Through，受控直通）方案。该方案的思路是：将一些敏感资源和关键资源（如PCI-E配置空间和MMIO CSR）虚拟化，而GPU显存的MMIO则进行直通，并在HostOS上增加一个能够感知虚拟化的驱动程序，以进行硬件资源的调度。这样，在VM中就可以看出一个PCI-E设备，并安装原生的GPU驱动。
% u  u6 }9 p, S4 Z7 `, ^' v& n该方案的优势在于，继承了vCUDA的调度灵活性，并且不需要替换原有的CUDA API库，解决了上一代vCUDA的兼容性问题。该方案的缺陷在于，宿主机上的驱动为硬件厂商所控制，而该物理GPU驱动是实现整个调度能力的核心。也就是说，该方案存在着对厂商软件的依赖，厂商软件可以基于这个收取高额的软件授权费用。
Nvidia MIG
在业界的推动下，Nvidia又在2020年前后更新了一代GPU虚拟化方案MIG（Multi-Instance GPU）。MIG的实现原理如图8-4所示。

lsund0srfht6404965317.png

我们对比图8-3和图8-4会发现，MIG与vGPU的相同点在于，VM上的CUDA运行时库和GPU驱动均为原生版本。但其差异在于，MIG上看到的GPU设备实际上是真实物理硬件的一部分，其BAR和MMIO CSR的背后都是真实的物理硬件。
. @& }4 i% N3 Q( \  m这是Nvidia在Nvidia A100和Nvidia H100等高端GPU上引入的硬件能力，它不仅能将一个GPU芯片虚拟出7个实例，提供给不同的VM使用，还可以为虚拟化的实例分配指定的GPU算力和GPU内存，这实际上是一种空分复用，也就是硬件资源隔离（Hardware Partition）。
硬件资源隔离所带来的一个重要价值就是硬件故障隔离。在前两种方案中，从本质上说，GPU侧并没有实现真正的故障隔离，一旦某个提交给Nvidia的CUDA作业程序越界访问了GPU显存，其他VM的CUDA应用就都有可能在抛出的异常中被中止。而MIG提供了硬件安全机制，不同MIG实例中的程序不会相互影响，从而从根源上解决了这一问题。
% }% f! |6 P2 H) uMIG看起来是一个完美的方案，但实际上并非如此。
首先，MIG只在高端的训练GPU上才得到了支持，但实际上推理场景需要使用GPU虚拟化技术来实现多应用共享GPU的可能性更大；其次，MIG支持的实例数受硬件设计限制，目前只能支持7个GPU实例；最后，MIG只支持CUDA计算，对于渲染等其他场景不支持。
" x8 t* T3 ~" g8 q因此，工程师们也构思了更多的方案，特别是云计算厂商也推出了一系列基于容器的GPU调度方案。
7 s% ~8 a% l9 W' g  z1 n本文节选自《大模型时代的基础架构：大模型算力中心建设指南》一书
; q: n- s: w2 n书中不但讲解了大模型相关的基础技术，比如AI基本概念、GPU硬件、软件、虚拟化等，还讲解了大模型基础设施的核心内容，包括GPU集群存储、网络、I/O、算力调度、网络虚拟化、管理和运营等，并结合实际案例，讲解了如何进行机器学习应用开发与运行平台设计，在此过程中把本书中的重点内容“串联”起来进行了讲解，以期读者建立整体的认知。

1zxiv3cxbdd6404965418.png

# r; ^( P1 r$ p5 m( F) J限时五折优惠，快快抢购吧！

: C/ h/ n2 B! a6 a, V- z# K! E3 j/ R
如果喜欢本文欢迎 在看丨留言丨分享至朋友圈 三连