本文转载自: 大模型时代的基础架构长什么样?

Overview

无论是基于虚拟机的PCI-E设备直通,还是基于Kubernetes的Device Plugin,对GPU调度的颗粒度都是整颗GPU芯片,这样,是不能将一颗GPU芯片共享给多个应用使用的。然而,在实践中,将GPU共享给多个应用使用是很常见的需求,特别是对于推理场景,往往不需要一直使用整颗GPU芯片的算力资源。所以,将昂贵的GPU分享给其他应用的能力就变得非常有价值。

因此,无论是GPU厂商、云计算厂商,还是开源社区,都推出了一系列GPU虚拟化方案。

Nvidia(英伟达)作为GPU领域的Top供应商,从2010年起就推出了GPU虚拟化的方案,其大致的发展路线图如图8-1所示。

在图8-1中,GPU虚拟化的发展路线分为三个阶段:以vCUDA为代表的API Remoting阶段、以GRID vGPU为代表的Driver Virtualization(驱动虚拟化)阶段,以及以MIG为代表的Hardware Virtualization(硬件虚拟化)阶段。

API Remoting与vCUDA

vCUDA技术出现于2010年前后,其实现思路是:在虚拟机中提供一个物理GPU的逻辑映像——虚拟GPU,在用户态拦截CUDA API,在虚拟GPU中重定向到真正的物理GPU上执行计算。同时,在宿主机上基于原生的CUDA运行时库和GPU驱动,运行vCUDA服务端,接管虚拟GPU拦截的CUDA API,同时进行计算任务的调度。

vCUDA的工作原理如图8-2所示。

从图8-2可以看出,虚拟机的CUDA运行时库被替换为vCUDA,其作用就是拦截来自CUDA App的所有CUDA API调用。vCUDA运行时库会在内核中调用vGPU驱动(或称之为“客户端驱动”),vGPU驱动实际的作用就是通过虚拟机到宿主机的VMRPC(Virtual Machine Remote Procedure Call)通道,将CUDA调用发送到宿主机。宿主机的vCUDA Stub(管理端)接收到CUDA调用后,调用宿主机上真正的CUDA运行时库和物理GPU驱动,完成GPU运算。

在客户端驱动处理API之前,还需要向管理端申请GPU资源。每一个独立的调用过程都必须向宿主机的管理端申请GPU资源,从而实现GPU资源和任务的实时调度。

显然,vCUDA是一种时间片调度的虚拟化技术,也就是“时分复用”。此种实现对于用户的应用而言是透明的,无须针对虚拟GPU做任何修改,而且也可以实现非常灵活的调度,单GPU能服务的虚拟机数量不受限制。但缺点也是显而易见的:CUDA API只是GPU运算使用的API中的一种,业界还有DirectX/OpenGL等其他API标准,而且同一套API又有多个不同的版本(如DirectX 9和DirectX 11等),兼容性非常复杂。

Nvidia如何在下一代GPU虚拟化技术中解决这一问题呢?

GRID vGPU

Nvidia在2014年前后推出了vCUDA的替代品——GRID vGPU。

GRID vGPU是一种GPU分片虚拟化方案,也可以被认为是一种半虚拟化方案。“分片”实际上还是采用“时分复用”。

GRID vGPU的实现原理如图8-3所示。

在图8-3中,VM中的CUDA应用调用的是原生的CUDA运行时库,但GuestOS(虚拟机操作系统)中的GPU驱动并不是访问GPU物理的BAR(Base Address Register),而是访问虚拟的BAR。

在进行计算工作时,GuestOS的GPU驱动会将保存待计算Workload的GPA通过MMIO CSR(Configuration and Status Register)传递给HostOS中的GPU驱动,从而让HostOS的GPU驱动拿到GPA并将其转换为HPA,写入物理GPU的MMIO CSR,也就是启动物理GPU的计算任务。

物理GPU在计算完成后,会发送一个MSI中断到HostOS的驱动,HostOS的驱动根据Workload反查提交这个Workload的vGPU实例,发送中断到对应的VM中。VM的GuestOS处理该中断,直到完成计算Workload,上报CUDA和应用,vGPU计算过程处理完毕。

vGPU方案也被称为MPT(Mediated Pass Through,受控直通)方案。该方案的思路是:将一些敏感资源和关键资源(如PCI-E配置空间和MMIO CSR)虚拟化,而GPU显存的MMIO则进行直通,并在HostOS上增加一个能够感知虚拟化的驱动程序,以进行硬件资源的调度。这样,在VM中就可以看出一个PCI-E设备,并安装原生的GPU驱动。

该方案的优势在于,继承了vCUDA的调度灵活性,并且不需要替换原有的CUDA API库,解决了上一代vCUDA的兼容性问题。该方案的缺陷在于,宿主机上的驱动为硬件厂商所控制,而该物理GPU驱动是实现整个调度能力的核心。也就是说,该方案存在着对厂商软件的依赖,厂商软件可以基于这个收取高额的软件授权费用。

Nvidia MIG

在业界的推动下,Nvidia又在2020年前后更新了一代GPU虚拟化方案MIG(Multi-Instance GPU)。MIG的实现原理如图8-4所示。

我们对比图8-3和图8-4会发现,MIG与vGPU的相同点在于,VM上的CUDA运行时库和GPU驱动均为原生版本。但其差异在于,MIG上看到的GPU设备实际上是真实物理硬件的一部分,其BAR和MMIO CSR的背后都是真实的物理硬件。

这是Nvidia在Nvidia A100和Nvidia H100等高端GPU上引入的硬件能力,它不仅能将一个GPU芯片虚拟出7个实例,提供给不同的VM使用,还可以为虚拟化的实例分配指定的GPU算力和GPU内存,这实际上是一种空分复用,也就是硬件资源隔离(Hardware Partition)。

硬件资源隔离所带来的一个重要价值就是硬件故障隔离。在前两种方案中,从本质上说,GPU侧并没有实现真正的故障隔离,一旦某个提交给Nvidia的CUDA作业程序越界访问了GPU显存,其他VM的CUDA应用就都有可能在抛出的异常中被中止。而MIG提供了硬件安全机制,不同MIG实例中的程序不会相互影响,从而从根源上解决了这一问题。

SR-IOV is a pre-requisite for running vGPUs on MIG,所以MMIO BAR是直通的,无需trap(而GRID vGPU需要trap MMIO BAR)。

MIG看起来是一个完美的方案,但实际上并非如此。

首先,MIG只在高端的训练GPU上才得到了支持,但实际上推理场景需要使用GPU虚拟化技术来实现多应用共享GPU的可能性更大;其次,MIG支持的实例数受硬件设计限制,目前只能支持7个GPU实例;最后,MIG只支持CUDA计算,对于渲染等其他场景不支持。

因此,工程师们也构思了更多的方案,特别是云计算厂商也推出了一系列基于容器的GPU调度方案。


参考资料:

  1. NVIDIA Multi-Instance GPU(MIG) 技术简介¶
  2. vSphere 7 with Multi-Instance GPUs (MIG) on the NVIDIA A100 for Machine Learning Applications – Part 2 : Profiles and Setup