一文读懂GPU虚拟化：除了直通、全虚拟化 (vGPU)，还有谁？|gpu|插件功能|服务器|虚拟机

大家伙，我是老猫，今天我们来聊聊GPU虚拟化。

随着AI、加密货币等技术的发展，GPU在市场上“一卡难求”，这也导致GPU售价非常昂贵，而且供货周期也不稳定。

对于有GPU需求的企业用户，不但需要思考GPU卡的选型，同时需要考虑怎样尽可能高效利用GPU资源。为了提高GPU资源利用率，很多人选择对GPU进行虚拟化。

当然，除了提升资源利用率，GPU虚拟化还可以提供了良好的隔离性，从而确保虚拟环境之间的安全和独立性。另外，通过GPU虚拟化，用户还可以根据应用程序的需求动态调整虚拟GPU的计算和显存资源，实现资源的弹性扩展。

今天我们就详细聊下GPU的虚拟化技术。

▉GPU虚拟化的分类

相比于CPU虚拟化，GPU虚拟化人们了解的并不多。

目前，在GPU虚拟化大类上一般分为三种：软件模拟、直通独占(类似网卡独占、显卡独占)、直通共享（如vGPU、MIG）。

下面我们来具体看下每一种的特点。

第一种，软件模拟（eg sGPU），又被叫半虚拟化。这种方式主要通过软件模拟来完成，也就是大部分的KVM在用，主要原理就是在Host操作系统层面上建立一些比较底层的API，让Guest看上去好像就是真的硬件一样。

这种方式的优点是比较灵活，而且并不需要有实体GPU，当然没有实体GPU的缺点就很明显了，模拟出来的东西运行比较慢。另外就是这个方式并没有官方研发，因此产品质量肯参差不齐。软件模拟虚拟化就不讲了，因为真实场景太少，做做实验还将就用，几乎没法用在生产环境，毕竟性能损失太多。

第二种，直通独占 (pGPU) 。直通是最早出现，即技术上最简单和成熟的方案。直通主要是利用PCIe Pass-through技术，将物理主机上的整块GPU显卡直通挂载到虚拟机上使用，与市场网卡直通的原理类似，但是这种方式需要主机支持IOMMU。

因为直通方式的性能损耗最小，各大公用云厂商广泛采用直通模式，但直通方式相当于虚拟机独享GPU，因此硬件驱动无需修改。另外因为直通模式没有对可支持的GPU数量做限制，也没有对GPU功能性做阉割，因此大多数功能可以在直通模式下无修改支持。

但GPU 直通的缺点是一张GPU卡不能同时直通给多个虚拟机使用，相当于虚拟机独占了GPU卡。如果多个虚拟机需要同时使用GPU，需要在服务器中安装多块GPU卡，分别直通给不同的虚拟机使用。而且直通GPU的虚拟机不支持在线迁移。

为了应对GPU直通不能共享GPU的限制，第三种方式直通共享的虚拟化方式出现了。直通共享在技术上分类叫全虚拟化。实现原理是物理GPU虚拟化为多个虚拟机GPU，每个虚拟GPU直接分配给虚拟机使用，通过软件调度的方式在Host与计算机的Guest之间提供一个中间设备来允许Guest虚拟机访问Host中的物理GPU。

GUP直通共享方式是目前GPU厂商主推的技术趋势，接下来我们就详细介绍的下直通共享虚拟化这方面的内容。

▉不同GPU直通技术有何区别？

在本文开头介绍过，GPU全虚拟化的实现原理是将物理GPU虚拟化为多个虚拟机GPU，每个虚拟GPU直接分配给虚拟机使用。

目前，GPU全虚拟化技术先后有SR-IOV(开源技术) ，API转发、MPS还有vGPU 、MIG等，下面我们就详细看下。

第一种：PCIe SR-IOV

前文我们提到了GPU直通，这种通过PCIe直通GPU的方式只能支持1：1，不支持GPU资源分隔。于是为了解决这个问题，PCIe SR-IOV(Single Root Input/Output Virtualization)出现。

PCIe SR-IOV(Single Root Input/Output Virtualization)是一种更高级的虚拟化技术，允许一个PCIe设备在多个虚拟机之间共享，同时保持较高的性能。

PCIe SR-IOV通过在物理设备(Physical Functions，PF)上创建多个虚拟功能(Virtual Functions，VF)来实现的，每个虚拟功能可以被分配给一个虚拟机，让虚拟机直接访问和控制这些虚拟功能，从而实现高效的I/O虚拟化。基于PCIe SR-IOV的GPU虚拟化方案，本质是把一个物理GPU显卡设备(PF)拆分成多份虚拟(VF)的显卡设备，而且VF 依然是符合 PCIe 规范的设备。核心架构如下图：

PCIe SR-IOV的有点就是真正实现了真正实现了1：N，一个PCIe设备提供给多个VM使用；但缺点是灵活性较差，无法进行更细粒度的分割与调度；并且不支持热迁移。

第二种：API转发

在苦等PCIe SR-IOV期间，业界出现了基于API转发的GPU虚拟化方案。API转发分为被调方和调用方，两方对外提供同样的接口(API)，被调方API实现是真实的渲染、计算处理逻辑，而调用方API实现仅仅是转发，转发给被调方。其核心架构示意如下图：

在GPU API层的转发，业界有针对OpenGL的AWS Elastic GPU，OrionX，有针对CUDA的腾讯vCUDA，瓦伦西亚理工大学rCUDA；在GPU驱动层的转发，有针对CUDA的阿里云cGPU和腾讯云pGPU。

API转发方案的优点是实现了1：N，并且N是可以自行设定，灵活性高。同时不依赖GPU硬件厂商。但缺点复杂度极高。同一功能有多套 API(渲染的 DirectX 和 OpenGL)，同一套 API 还有不同版本(如 DirectX 9 和 DirectX 11)，兼容性非常复杂。并且功能不完整，如不支持媒体编解码，并且，编解码甚至还不存在业界公用的 API。

第三种：MPS方案

除了PCIe SR-IOV，Nvidia还推出了MPS方案，这是一种算力分割的软件虚拟化方案。该方案和PCIe SR-IOV方案相比，配置很灵活，并且和docker适配良好。

MPS基于C/S架构，配置成MPS模式的GPU上运行的所有进程，会动态的将其启动的内核发送给MPS server，MPS Server借助CUDA stream，实现多个内核同时启动执行。除此之外，MPS还可配置各个进程对GPU的使用占比。

但该方案的一个问题在于，各个服务进程依赖MPS，一旦MPS进程出现问题，所有在该GPU上的进程直接受影响，需要使用Nvidia-smi重置GPU 的方式才能恢复。

第四种：MIG技术

也属于全虚拟化技术。MIG是Nvidia 搞出的新技术，可将单个 GPU 分区为最多7个完全的隔离vGPU实例，每个实例均完全独立于各自的高带宽显存、缓存和计算核心。