GPU虚拟化是一种允许单个物理GPU被多个虚拟机（VMs）共享的技术，从而在数据中心和云计算环境中实现高效、灵活且安全的GPU资源分配。通过虚拟化技术，每个虚拟机都能拥有独立并受控的GPU资源来执行图形密集型或计算密集型任务，如图形渲染、科学计算、深度学习训练等。

以下是GPU虚拟化的主要概念和技术实现方法：

VGPU (Virtual GPU):

VGPU技术，如NVIDIA的GRID vGPU和AMD的MxGPU，通过硬件和驱动层面的支持，将物理GPU划分为多个逻辑上的虚拟GPU实例。每个虚拟GPU都有独立的显存、计算核心等资源，可以为不同虚拟机提供专属的图形和计算能力。这种方式使GPU资源得以充分利用，同时保证了各虚拟环境之间的隔离性与安全性。

NVIDIA GRID vGPU：NVIDIA提供的技术，允许GPU被划分为多个虚拟GPU实例，每个实例都具有独立的显存和计算单元，并能按需分配给不同的虚拟机使用。

AMD MxGPU：AMD对应的技术，同样提供GPU资源的分区和虚拟化服务。

核心技术原理：VGPU的核心在于硬件支持与驱动程序的配合。例如，NVIDIA的GRID vGPU技术利用GPU硬件特性，通过专有的虚拟化驱动程序，在底层实现了对GPU硬件资源的细粒度划分与管理。每个虚拟GPU实例拥有独立的显存空间、流处理器和其他必要的计算资源，它们被配置成可供虚拟机直接访问和使用的设备。

资源分配与隔离：VGPU技术的关键优势之一就是资源的精细化分配和严格的隔离性。管理员可以根据每台虚拟机的实际需求为其分配适当数量的GPU资源，从而避免资源浪费或过度竞争。同时，通过底层的硬件和驱动支持，确保了每个虚拟GPU实例之间的工作互不影响，保证数据安全和性能稳定性。

应用场景：VGPU技术广泛应用于云桌面、远程工作站、大数据处理、深度学习训练等多个领域。在云桌面环境中，用户可以通过瘦客户端访问具备vGPU的虚拟机，实现高清流畅的图形交互体验；在深度学习场景下，科研人员可以利用虚拟化环境内的vGPU进行模型训练，不必担心与其他用户的任务冲突或资源争夺。

性能优化与改进：为了尽可能减少虚拟化带来的性能损耗，VGPU技术采用了多种优化策略，如内存带宽管理、帧缓冲压缩、低延迟通信协议等。同时，随着GPU硬件架构的进步以及虚拟化软件的迭代更新，VGPU的性能表现也在持续提升，力求在满足多租户资源共享的同时，最大程度地接近物理GPU的原始性能。

挑战与未来趋势：尽管VGPU技术已经取得了显著进展，但仍面临一些挑战，例如如何在复杂的混合负载场景下动态调整资源分配以保持最优性能，如何进一步降低虚拟化开销，以及如何更好地支持新兴的高性能计算和机器学习应用。未来，随着异构计算、容器化技术的发展，VGPU技术有望结合新的计算范式，实现更加灵活、高效的资源虚拟化与管理。

VGPU（Virtual GPU）技术主要由两大GPU制造商主导，分别是NVIDIA和AMD，它们各自推出了自家的GPU虚拟化解决方案。

NVIDIA的VGPU技术：

1. NVIDIA GRID vGPU：

NVIDIA GRID vGPU技术是业界领先的GPU虚拟化解决方案，它允许数据中心和云端服务商将单个高端NVIDIA Tesla或RTX系列GPU分割成多个独立的虚拟GPU实例，为多个虚拟机提供图形加速和计算能力。每个虚拟GPU实例都可以分配专用的显存和计算资源，以支持图形密集型应用、CAD/CAM工具、图像处理软件以及深度学习训练等工作负载。NVIDIA GRID还支持实时迁移、QoS控制等功能，以优化资源分配和保证服务等级。

AMD的VGPU技术：

1. AMD MxGPU (Multi-User GPU)：

AMD MxGPU技术基于SR-IOV（Single Root I/O Virtualization）标准，实现GPU硬件级别的虚拟化。通过MxGPU，AMD Radeon Instinct和Radeon Pro系列GPU可以被划分为多个独立的安全资源块，分配给多个虚拟机，确保每个虚拟机享有确定性的图形性能。与NVIDIA类似，AMD的MxGPU也强调资源隔离、性能保障和安全性，尤其适合于需要图形加速的虚拟桌面基础设施（VDI）环境，以及部分计算密集型应用。

国内方面，虽然没有自主研发的主流VGPU技术，但国内的云计算服务商和硬件厂商会集成运用NVIDIA和AMD的VGPU技术，推出符合国内市场需求的GPU虚拟化解决方案和服务。例如，国内的一些云服务提供商，如阿里云、腾讯云、华为云等，会利用这些国际品牌的GPU虚拟化技术，为用户提供包含vGPU的云服务器和桌面云服务。此外，也有一些公司如深信服等，与NVIDIA合作，将VGPU技术整合到自身的桌面云平台中，为国内市场提供基于虚拟化技术的GPU资源分配方案。

总之，VGPU作为GPU虚拟化的核心技术，通过创新性的硬件支持与软件优化，成功打破了单个物理GPU只能服务于单个系统的传统限制，极大地推动了云计算和数据中心领域的资源共享与高效利用，为企业构建弹性、敏捷、高性能的IT基础设施奠定了坚实基础。

设备仿真：

这种方式模拟了一个GPU的行为，但对于高性能需求的应用可能效率较低，适用于对图形性能要求不高的场景。

API 远程处理：

例如NVIDIA的vCUDA技术，虚拟机内应用程序通过网络接口调用远端物理GPU的CUDA功能，使得GPU计算资源能够跨服务器边界进行共享。

直接传递（Passthrough）：

PCI Passthrough 或 SR-IOV（Single Root I/O Virtualization）：这种技术将物理GPU直接绑定到特定的虚拟机，使得该虚拟机独占整个GPU资源，对于需要完整GPU性能的场景非常有效，比如专业级图形工作站或高性能计算。

中介传递（Mediated Pass-through, mediated device assignment）：

在此模式下，虚拟机通过一个中间层访问GPU，这个中间层负责管理和调度GPU资源，以支持多虚拟机间的资源隔离和QoS（Quality of Service）控制。

GPU 分片（Partitioning）：

类似于vGPU，但可能是指更细粒度的资源划分，确保每个虚拟机获得定制级别的GPU资源。

QoS 控制和调度：

管理程序在虚拟化环境中对GPU资源进行动态调度和优先级管理，确保在高负载时仍能维持服务质量。

综合以上技术和手段，GPU虚拟化不仅提高了资源利用率，还增强了系统的弹性和安全性，特别在云计算、数据中心以及大规模AI应用部署中发挥着重要作用。随着技术的发展，GPU虚拟化方案不断演进和完善，以适应不断增长的高性能计算需求。

一、术语介绍

二、GPU 虚拟化的历史和谱系

2.1 GPU 能做什么

GPU 天然适合向量计算。常用场景及 API：

此外还有加解密、哈希等场景，例如近些年来的挖矿。

渲染是 GPU 诞生之初的应用: GPU 的 G 就是 Graphics —— 图形。

2.2 系统虚拟化和 OS 虚拟化

系统的三个要素: CPU，内存，设备。

CPU 虚拟化由 VT-x/SVM 解决，内存虚拟化由 EPT/NPT 解决，这些都是非常确定的。但设备虚拟化呢？它的情况要复杂的多，不管是 VirtIO，还是 VT-d，都不能彻底解决设备虚拟化的问题，这些我们稍后还会谈到。

除了这种完整的系统虚拟化，还有一种也往往被称作「虚拟化」的方式: 从 OS 级别，把一系列的 library 和 process 捆绑在一个环境中，但所有的环境共享同一个 OS Kernel。

严格来说，这种容器技术，和以 KVM 为代表的系统虚拟化，有着本质的区别。随着容器的流行，「虚拟化」这个术语，也被用来指称这种 OS 级别的容器技术。因此我们也从众，把它也算作虚拟化的一种 —— 只不过为了区分，称之为「OS 虚拟化」。

这种 OS 虚拟化最初于 2005 年，由 Sun 公司在 Solaris 10 上实现，名为「Solaris Zone」。Linux 在 2007 ～ 2008 开始跟进，接下来有了 LXC 容器等；到了 2013 年，Docker 横空出世，彻底改变了软件分发的生态，成为事实上的标准。

2.3 GPU 虚拟化的谱系

2.3.1 作为 PCIe 设备的 GPU

不考虑嵌入式平台的话，那么，GPU 首先是一个 PCIe 设备。GPU 的虚拟化，还是要首先从 PCIe 设备虚拟化角度来考虑。

那么一个 PCIe 设备，有什么资源？有什么能力？

2 种资源:

配置空间

MMIO

(有的还有 PIO 和 Option ROM，此略)

2 种能力:

中断能力

DMA 能力

一个典型的 GPU 设备的工作流程是:

应用层调用 GPU 支持的某个 API，如 OpenGL 或 CUDA

OpenGL 或 CUDA 库，通过 UMD (User Mode Driver)，提交 workload 到 KMD (Kernel Mode Driver)

KMD 写 CSR MMIO，把它提交给 GPU 硬件

GPU 硬件开始工作... 完成后，DMA 到内存，发出中断给 CPU

CPU 找到中断处理程序 —— KMD 此前向 OS Kernel 注册过的 —— 调用它

中断处理程序找到是哪个 workload 被执行完毕了，...最终驱动唤醒相关的应用

2.3.2 PCIe 直通

我们首先来到 GPU 虚拟化的最保守的实现: PCIe 设备直通。

如前述，一个 PCIe 设备拥有 2 种资源、2 种能力。你把这 2 种资源都（直接或间接地）交给 VM、针对这 2 种能力都把设备和 VM 接通，那么，VM 就能完整使用这个 PCIe 设备，就像在物理机上一样。这种方案，我们称之为 PCIe 直通（PCIe Pass-Through）。它只能 1:1，不支持 1:N。其实并不能算真正的虚拟化，也没有超卖的可能性。

VM 中，使用的是原生的 GPU 驱动。它向 VM 内核分配内存，把 GPA 填入到 GPU 的 CSR 寄存器，GPU 用它作为 IOVA 来发起 DMA 访问，VT-d 保证把 GPA 翻译为正确的 HPA，从而 DMA 到达正确的物理内存。

PCIe 协议，在事务层(Transaction Layer)，有多种 TLP，DMA 即是其中的一种: MRd/MWr。在这种 TLP 中，必须携带发起者的 Routing ID，而在 IOMMU 中，就根据这样的 Routing ID，可以使用不同的 IOMMU 页表进行翻译。

很显然，PCIe 直通只能支持 1:1 的场景，无法满足 1:N 的需求。

2.3.3 SR-IOV

那么，业界对 1:N 的 PCIe 虚拟化是如何实现的呢？我们首先就会想到 SR-IOV。SR-IOV 是 PCI-SIG 在 2007 年推出的规范，目的就是 PCIe 设备的虚拟化。

SR-IOV 的本质是什么？

考虑我们说过的 2 种资源和 2 种能力，来看看一个 VF 有什么:

配置空间是虚拟的（特权资源）

MMIO 是物理的

中断和 DMA，因为 VF 有自己的 PCIe 协议层的标识（Routing ID，就是 BDF），从而拥有独立的地址空间。

那么，什么设备适合实现 SR-IOV？其实无非是要满足两点:

硬件资源要容易 partition

无状态（至少要接近无状态）

常见 PCIe 设备中，最适合 SR-IOV 的就是网卡了: 一或多对 TX/RX queue + 一或多个中断，结合上一个 Routing ID，就可以抽象为一个 VF。而且它是近乎无状态的。

试考虑 NVMe 设备，它的资源也很容易 partition，但是它有存储数据，因此在实现 SR-IOV 方面，就会有更多的顾虑。

回到 GPU 虚拟化：为什么 2007 年就出现 SR-IOV 规范、直到 2015 业界才出现第一个「表面上的」SRIOV-capable GPU【1】？这是因为，虽然 GPU 基本也是无状态的，但是它的硬件复杂度极高，远远超出 NIC、NVMe 这些，导致硬件资源的 partition 很难实现。

注释

【1】 AMD S7150 GPU。腾讯云 GA2 机型使用。

表面上它支持 SR-IOV，但事实上硬件只是做了 VF 在 PCIe 层的抽象。Host 上还需要一个 Virtualization-Aware 的 pGPU 驱动，负责 VF 的模拟和调度。

2.3.4 API 转发

因此，在业界长期缺乏 SRIOV-capable GPU、又有强烈的 1:N 需求的情形下，就有更 high-level 的方案出现了。我们首先回到 GPU 应用的场景:

渲染（OpenGL、DirectX，etc.）

计算（CUDA，OpenCL）

媒体编解码（VAAPI...)

业界就从这些 API 入手，在软件层面实现了「GPU 虚拟化」。以 AWS Elastic GPU 为例:

VM 中看不到真的或假的 GPU，但可以调用 OpenGL API 进行渲染

在 OpenGL API 层，软件捕捉到该调用，转发给 Host

Host 请求 GPU 进行渲染

Host 把渲染的结果，转发给 VM

API 层的 GPU 虚拟化是目前业界应用最广泛的 GPU 虚拟化方案。它的好处是:

灵活。1:N 的 N，想定为多少，软件可自行决定；哪个 VM 的优先级高，哪个 VM 的优先级低，同理。

不依赖于 GPU 硬件厂商。微软、VMWare、Citrix、华为……都可以实现。这些 API 总归是公开的。

不限于系统虚拟化环境。容器也好，普通的物理机也好，都可以 API 转发到远端。

缺点呢？

复杂度极高。同一功能有多套 API（渲染的 DirectX 和 OpenGL），同一套 API 还有不同版本（如 DirectX 9 和 DirectX 11），兼容性就复杂的要命。

功能不完整。计算渲染媒体都支持的 API 转发方案，还没听说过。并且，编解码甚至还不存在业界公用的 API！【1】

注释

【1】 Vulkan 的编解码支持，spec 刚刚添加，有望被所有 GPU 厂商支持。见下「未来展望」部分。

2.3.5 MPT/MDEV/vGPU

鉴于这些困难，业界就出现了 SR-IOV、API 转发之外的第三种方案。我们称之为 MPT（Mediated Pass-Through，受控的直通）。MPT 本质上是一种通用的 PCIe 设备虚拟化方案，甚至也可以用于 PCIe 之外的设备。它的基本思路是：

敏感资源如配置空间，是虚拟的

关键资源如 MMIO（CSR 部分），是虚拟的，以便 trap-and-emulate

性能关键资源如 MMIO（GPU 显存、NVMe CMB 等），硬件 partition 后直接赋给 VM

Host 上必须存在一个 Virtualization-Aware 的驱动程序，以负责模拟和调度，它实际上是 vGPU 的 device-model

这样，VM 中就能看到一个「看似」完整的 GPU PCIe 设备，它也可以 attach 原生的 GPU 驱动。以渲染为例，vGPU 的基本工作流程是:

VM 中的 GPU 驱动，准备好一块内存，保存的是渲染 workload

VM 中的 GPU 驱动，把这块内存的物理地址(GPA)，写入到 MMIO CSR 中

Host/Hypervisor/驱动: 捕捉到这次的 MMIO CSR 写操作，拿到了 GPA

Host/Hypervisor/驱动: 把 GPA 转换成 HPA，并 pin 住相应的内存页

Host/Hypervisor/驱动: 把 HPA（而不是 GPA），写入到 pGPU 的真实的 MMIO CSR 中

pGPU 工作，完成这个渲染 workload，并发送中断给驱动

驱动找到该中断对应哪个 workload —— 当初我是为哪个 vGPU 提交的这个 workload？—— 并注入一个虚拟的中断到相应的 VM 中

VM 中的 GPU 驱动，收到中断，知道该 workload 已完成、结果在内存中

这就是 nVidia GRID vGPU、Intel GVT-g（KVMGT、XenGT）的基本实现思路。一般认为 graphics stack 是 OS 中最复杂的，加上虚拟化之后复杂度更是暴增，任何地方出现一个编程错误，调试起来都是无比痛苦。但只要稳定下来，这种 MPT 方案，就能兼顾 1:N 灵活性、高性能、渲染计算媒体的功能完整性...是不是很完美？

其实也不是。

该方案最大的缺陷，是必须有一个 pGPU 驱动，负责 vGPU 的模拟和调度工作。逻辑上它相当于一个实现在内核态的 device-model。而且，由于 GPU 硬件通常并不公开其 PRM，所以事实上就只有 GPU 厂商才有能力提供这样的 Virtualization-Aware pGPU 驱动。使用了厂商提供的 MPT 方案，事实上就形成了对厂商的依赖。

2.3.6 SR-IOV: revisited

重新回到 GPU 的 SR-IOV。AMD 从 S7150 开始、英伟达从 Turing 架构开始，数据中心 GPU 都支持了 SR-IOV。但是 again，它不是 NIC 那样的 SR-IOV，它需要 Host 上存在一个 vGPU 的 device-model，来模拟从 VM 来的 VF 访问。

所以事实上，到目前为止，GPU 的 SR-IOV 仅仅是封装了 PCIe TLP 层的 VF 路由标识、从而规避了 runtime 时的软件 DMA 翻译，除此之外，和基于 MDEV 的 MPT 方案并无本质的不同。

2.3.7 谱系表

在介绍完了上述的这些方案后，我们重新看下 CUDA 计算、OpenGL 渲染两种场景的软件栈，看看能发现什么:

CUDA 计算 stack：

OpenGL 渲染 Stack：

可以看出，从 API 库开始，直到 GPU 硬件，Stack 中的每一个阶段，都有被截获、转发的可能性。甚至，一概称之为「API 转发」是不合适的 —— 以 GRID vGPU、GVT-g 为例的 DEV 转发，事实上就是 MPT，和任何 API 都没有关系。

三、容器 GPU 虚拟化

首先，我们这里谈到的，都是 nVidia 生产的 GPU、都只考虑 CUDA 计算场景。其次，这里的虚拟化指的是 OS 虚拟化的容器技术，不适用于 KATA 这样的、基于系统虚拟化的安全容器。

3.1 CUDA 的生态

CUDA 开发者使用的，通常是 CUDA Runtime API，它是 high-level 的；而 CUDA Driver API 则是 low-level 的，它对程序和 GPU 硬件有更精细的控制。Runtime API 是对 Driver API 的封装。

CUDA Driver 即是 UMD，它直接和 KMD 打交道。两者都属于 NVIDIA Driver package，它们之间的 ABI，是 NVIDIA Driver package 内部的，不对外公开。

英伟达软件生态封闭：

无论是 nvidia.ko，还是 libcuda.so，还是 libcudart，都是被剥离了符号表的

大多数函数名是加密替换了的

其它的反调试、反逆向手段

以 nvidia.ko 为例，为了兼容不同版本的 Linux 内核 API，它提供了相当丰富的兼容层，于是也就开源了部分代码:

其中这个 26M 大小的、被剥离了符号表的 nv-kernel.o_binary，就是 GPU 驱动的核心代码，所有的 GPU 硬件细节都藏在其中。

3.2 vCUDA 和友商 cGPU

为了让多个容器可以共享同一个 GPU，为了限定每个容器能使用的 GPU 份额，业界出现了不同的方案，典型的如 vCUDA 和 cGPU：

vCUDA 架构：

cGPU 架构：

两者的实现策略不同，cGPU 比 vCUDA 更底层，从而实现了不侵入用户环境。

3.3 GPU 池化简介

从截获的位置，看 GPU 池化的谱系：

以 CUDA API 转发的池化方案、业界某产品为例，它到了 GPU 所在的后端机器上，由于一个 GPU 卡可能运行多个 GPU 任务，这些任务之间，依然需要有算力隔离。它为了实现这一点，在后端默认启用了 nVidia MPS —— 也就是故障隔离最差的方案。这会导致什么？一个 VM 里的 CUDA 程序越界访问了显存，一堆风马牛不相及的 VM 里的 CUDA 应用就会被杀死。

所以，很显然，GPU 池化也必须以同时满足故障隔离和算力隔离的方案作为基础。

3. Time Sharing，亦即: 时分

nVidia GPU 支持基于 Engine 的 Context Switch。不管是哪一代的 GPU，其 Engine 都是支持多任务调度的。一个 OS 中同时运行多个 CUDA 任务，这些任务就是在以 Time Sharing 的方式共享 GPU。

鉴于 MIG 的高成本和不灵活、MPS 故障隔离方面的致命缺陷，事实上就只剩下一种可能：Time Sharing。唯一的问题是，如何在原厂不支持的情况下，利用 Time Sharing 支持好算力隔离、以保证 QoS。这也是学术界、工业界面临的最大难题。

3.4.1 GPU microarchitecture 和 chip

真正决定 GPU 硬件以何种方式工作的，是 chip 型号。不管是 GRID Driver 还是 Tesla Driver，要指挥 GPU 硬件工作，就要首先判断 GPU 属于哪种 chip，从而决定用什么样的软硬件接口来驱动它。

3.4.2 PFIFO: GPU Scheduling Internals

PFIFO 架构：

概念解释：

PFIFO

GPU 的调度硬件，整体上叫 PFIFO。

Engine

执行某种类型的 GPU 硬件单元。常见 Engine 有：

PGRAPH —— CUDA/Graphics

PCOPY ——— Copy Engine

PVENC ——— Video Encoding

PVDEC ——— Video Decoding

...

最重要的就是 PGRAPH Engine，它是 CUDA 和渲染的硬件执行单元。

Channel

GPU 暴露给软件的，对 Engine 的抽象。一个 app 可以对应一或多个 channels，执行时由 GPU 硬件把一个一个的 channel，放在一个一个的 engine 上执行。

channel 是软件层的让 GPU 去执行的最小调度单位。

TSG

Timeslice Group。

由一或多个 channel(s)组成。一个 TSG 共享一个 context，且作为一个调度单位被 GPU 执行。

runlist

GPU 调度的最大单位。调度时，GPU 通常是从当前 runlist 的头部摘取 TSG 或 channel 来运行。因此，切换 runlist 也意味着切换 active TSG/channel。

PBDMA

pushbuffer DMA。GPU 上的硬件，用于从 Memory 中获取 pushbuffer。

Host

GPU 上和 SYSMEM 打交道的部分(通过 PCIe 系统)。PBDMA 是 Host 的一部分。注意，Host 是 Engine 和 SYSMEM 之间的唯一桥梁。

Instance Block

每个 Channel 对应一个 Instance Block，它包含各个 Engine 的状态，用于 Context Switch 时的 Save/Restore；包含 GMMU pagetable；包含 RAMFC —— 其中包括 UMD 控制的 USERD。

3.4.4 pending channel notification

pending channel notification 是 USERD 提供的机制。UMD 可以利用它通知 GPU：某个 channel 有了新的任务了【1】。这样，GPU 硬件在当前 channel 被切换后(执行完毕、或 timeslice 到了)，就会执行相应的 channel。

注释

【1】 不同 chip，实现有所不同。

3.4.5 从硬件调度看 GRID vGPU

GRID vGPU 支持 3 种 scheduler：

1. Best Effort: 所有 vGPU 的任务随意提交，GPU 尽力执行。

现象： 如果启动了 N 个 vGPU，它们的负载足够高，那么结果就是均分算力。

原理： 所有的 vGPU 使用同一个 runlist。runlist 内，还是按照 channel 为粒度进行调度。如同在 native 机器上运行多个 CUDA 任务一样。

2. Equal Share: 所有在用的 vGPU 严格拥有同样的 GPU 配额

现象： 如果启动了 N 个 vGPU，它们严格拥有相同的算力，不管是否需要这么多。

原理： 为每个 vGPU 维护一个 runlist。当它的 timeslice 过了，GRID Host Driver 会写 GPU 寄存器，触发当前 runlist 被抢占、下一个 runlist 被调度。

3. Fixed Share: 每个 vGPU 有自己固定的 GPU 配额

现象： 每个 vGPU 严格按照创建时的规格来分配算力。

原理： Ditto.

3.5 腾讯云 qGPU 简介

qGPU == QoS GPU。它是目前业界唯一真正实现了故障隔离、显存隔离、算力隔离、且不入侵生态的容器 GPU 共享的技术。

3.5.1 qGPU 基本架构

qGPU 基本架构：

3.5.2 qGPU QoS 效果

注释

【1】 测试数据来自 T4(chip: TU104)。其它 chip 上，正确性、功能性和性能都待验证，虽然原理上是相通的。

【2】两个 PoD 的算力配比为 2：1。横坐标为 batch 值，纵坐标为运行时两个 PoD 的实际算力比例。可以看到，batch 较小时，负载较小，无法反映算力配比；随着 batch 增大，qGPU 和 MPS 都趋近理论值 2，vCUDA 也偏离不远，但缺乏算力隔离的业界某产品则逐渐趋近 1。

四、GPU 虚拟化: 未来展望

2021 以来，GPU 工业界发生了一些变化，e.g.：

1. 英伟达 GPU 的 QoS 突破

英伟达在 CUDA 计算领域占据压倒性的优势，但 QoS 表现不尽如人意。

长期以来，学术界和工业界付出了大量的努力，尝试在英伟达不支持 QoS 的前提下，实现某种程度的算力隔离。遗憾的是，这些努力，要么集中在 CUDA API 层，能够做到一定的算力隔离，但同样会带来副作用；要么尝试在 low-level 层面突破 —— 但不幸全都失败了。

qGPU 是十几年来在英伟达 GPU 上实现 QoS 的最大突破。基于它：

腾讯云 TKE 的多容器共享 GPU，将无悬念地领先整个工业界

在线推理 + 离线训练的混部，成为可能

GPU 池化的后端实现，不管采用哪种方案，都有了坚实的基础

Linux/Android 场景的渲染虚拟化，也有了坚实的基础

2. Vulkan Spec 支持了 video encode/decode

很可能，编解码 API 不统一的乱象即将终结，这对 API 转发方案有很大的意义。不远的将来，或许某种 API 方案的 vGPU 会成为主流。Google 在社区的一些活动标明，很可能它就有这样的计划。

五、参考资料和项目简介

7. nVidia official: nvidia-uvm driver for Tesla

官方，开源。Telsa Driver 配套的 UVM 驱动，代码开源。和 Tesla Driver 有很多 low-level 交互，可以从中窥见很多 GPU 硬件细节。

8. Tesla Driver

官方。细节全藏在 nv-kernel.o_binary 文件中。

9. GRID vGPU

官方。细节也是全在 nv-kernel.o_binary 文件中。与 Tesla Driver 不同的是，它为 vGPU 的 Fixed Share 和 Equal Share 两种调度策略，实现了 per-vGPU runlist。因此有很高的参考价值。

更多精彩，可以关注巴特星球公众号