第8章 GPU虚拟化调度方案
2025.12.07在第七章中，我们已经探讨了“板卡级”的算力调度技术，核心是解决如何将一张物理GPU卡共享给多个虚拟机或容器的问题。我们学习了GPU直通、vGPU、MIG以及基于容器的设备插件等多种技术。这些技术可以被看作是GPU虚拟化的“第一层境界”，它们大多依赖于硬件厂商提供的原生支持，在隔离性、性能和实现方式上各有侧重，但共同的目标是将物理GPU转化为可被上层调度系统识别和分配的、粒度或粗或细的“GPU资源块”。
然而，随着AI应用的场景越来越多样化，特别是云原生AI平台的蓬勃发展，仅仅满足于这种“资源块”式的分配，已经无法满足业界对极致弹性、极致利用率和极致灵活性的追求。例如：
一个用户可能只需要100MB的显存和极少量的算力来运行一个TensorBoard服务，为他分配一个哪怕是最小的MIG实例（如5GB显存）也是巨大的浪费。
一个推理任务可能在高峰期需要大量算力，而在低谷期几乎空闲，我们能否实现算力的“按需伸缩”，而不是静态绑定？
我们能否将集群中所有GPU的显存和算力真正地“池化”，形成一个统一的、巨大的虚拟GPU资源池，然后像CPU和内存一样，按需、精确地（例如，以1MB显存、1%算力为单位）切割给任意一个容器？
为了实现这些更宏伟的目标，我们需要进入GPU虚拟化的“第二层境界”。本章，我们将专题深入探讨各种GPU虚拟化调度方案。这不再仅仅是资源的分配，而是通过更深层次的技术手段，对GPU的算力和显存资源进行虚拟化、池化和精细化管理。这些方案往往更具“侵入性”，通过对CUDA API、驱动程序甚至硬件指令的拦截和重定向，创造出一种“以假乱真”的虚拟GPU（vGPU）环境。
我们将从三个维度来全面考察这个领域的生态图景：
- NVIDIA的官方GPU虚拟化调度方案：我们将重新梳理并深入NVIDIA自家的技术体系，从最基础的API Remoting，到企业级的GRID vGPU，再到硬件级的MIG，理解其官方对不同虚拟化需求的层次化解答。
- 其他硬件厂商的GPU虚拟化调度方案：我们将简要介绍AMD和Intel等其他主流GPU厂商在虚拟化方面的思路和技术实现，如SR-IOV和GVT-g，以形成更广阔的行业视野。
- 云厂商与开源社区基于容器的GPU虚拟化调度方案：这是本章的重点。我们将深入剖析以阿里云cGPU、腾讯云qGPU、以及开源社区方案为代表的、在云原生环境下大放异彩的创新技术。这些方案大多基于容器，通过API劫持等技术，实现了对GPU算力和显存的超细粒度共享和池化，是当前提升GPU集群资源利用率的最前沿探索。
通过本章的学习，你将掌握一幅完整的GPU虚拟化技术图谱，从硬件厂商的“正统”方案，到云厂商和开源社区的“奇技淫巧”，你将理解它们各自背后的核心原理、技术权衡以及最适合的应用场景。这将使你能够在构建下一代AI平台时，针对资源利用率、隔离性、性能和成本等核心指标，做出最高阶的架构决策。
8.1 NVIDIA的GPU虚拟化调度方案
NVIDIA作为GPU领域的绝对领导者，其自身的GPU虚拟化技术体系经过了多年的演进，形成了一套层次分明、覆盖不同场景的解决方案。理解这套“官方”体系，是理解其他所有虚拟化方案的基础和参照系。
8.1.1 基础层：API Remoting与vCUDA
在vGPU和MIG等重量级方案出现之前，学术界和早期工业界就已经在探索通过软件方式实现GPU共享。其最核心、最基础的思想就是API远程调用（API Remoting）。
核心原理：
- 客户端（Client）：在一个没有物理GPU的客户机（可以是VM或容器）上，提供一个“伪造”的CUDA运行时库（shim library）。这个库拥有与原生
libcuda.so完全相同的API接口。 - 服务器端（Server）：在一台拥有物理GPU的服务器上，运行一个服务守护进程。
- API拦截与转发：当客户端的应用程序调用一个CUDA API时（例如
cudaMalloc），这个调用并不会在本地执行，而是被“伪造”的库拦截（Intercept）。 - 拦截后，这个库会将API调用的名称、参数等信息进行序列化（Serialization），并通过网络（如TCP/IP）转发给远端的服务器守护进程。
- 远程执行与结果返回：服务器守护进程接收到请求后，反序列化出原始的API调用，然后在本地的物理GPU上真正地执行这个调用。
- 执行完毕后，如果API有返回值或需要通过指针返回数据，服务器守护进程会将结果再次序列化，通过网络发回给客户端的“伪造”库，最终返回给应用程序。
vCUDA项目：vCUDA是早期一个著名的、基于API Remoting思想的开源学术项目。它完整地实现了上述流程，允许多个没有GPU的虚拟机，共享使用一台物理服务器上的GPU资源。
优点：
架构简单直观：概念清晰，易于理解。
打破物理边界：首次实现了GPU资源的跨节点、网络化共享，理论上可以将整个数据中心的GPU池化。
缺点：
性能瓶颈严重：
网络延迟：每一次API调用都需要经过一次网络来回，对于那些需要频繁调用大量小API的应用，其性能开销是灾难性的。
数据传输：当API调用涉及大量数据传输时（如cudaMemcpy），所有数据都需要通过CPU和网络进行拷贝，完全丧失了PCIe和NVLink的带宽优势。
内核启动开销大：启动一个计算内核本身也成了一次数百微秒甚至毫秒级的网络操作。
兼容性问题：需要为每一个新版本的CUDA驱动和API重写和适配“伪造”库，维护成本极高。
功能不完整：很难完整地实现所有复杂的CUDA功能，特别是涉及底层硬件交互和指针操作的功能。
现状与意义：纯粹的API Remoting方案由于其固有的性能缺陷，在今天已经很少被直接用于高性能的AI训练，但它的核心思想——API拦截与转发——却被后续许多更高级的虚拟化方案所借鉴和发扬光大。它是理解cGPU等技术的思想源头。
8.1.2 企业级标准：NVIDIA GRID vGPU
我们在第七章已经详细介绍了NVIDIA vGPU的原理。这里，我们将其置于NVIDIA的整体方案中，再次强调其定位。
定位：GRID vGPU是NVIDIA官方主推的、面向企业级虚拟化环境（主要是VMware vSphere, Citrix Hypervisor等）的商业GPU虚拟化解决方案。其产品品牌经过多次演变，现在主要整合在NVIDIA AI Enterprise (NVAIE)和NVIDIA RTX Virtual Workstation (vWS)等软件套件中。
核心技术回顾：
仲裁模型（Mediated Pass-through）：与API Remoting不同，vGPU的API转发发生在虚拟机与Hypervisor之间，通过一个高效的、专门的VMM通道，而不是通用的网络。
vGPU Manager：作为运行在Hypervisor中的“总管”，负责所有vGPU实例的创建、调度和隔离。
时间分片调度：在硬件层面，通过时间分片技术，让多个vGPU实例轮流使用物理GPU的计算引擎。
显存隔离：vGPU Manager为每个vGPU实例在物理显存中划分出一段固定的、受保护的区域，确保了显存的强隔离。
在NVIDIA体系中的角色：
虚拟化环境的“正统”方案：它是唯一被NVIDIA官方完整支持、能够在VMware等主流虚拟化平台上提供完整功能、性能和企业级服务的方案。
覆盖图形与计算：vGPU不仅支持CUDA计算，也完美支持OpenGL、DirectX等图形API，因此广泛应用于云桌面（VDI）和云游戏等场景。
软件定义的灵活性：通过vGPU Manager和不同的vGPU配置文件，管理员可以灵活地为不同的VM分配不同大小的显存，并应用不同的调度策略。
8.1.3 硬件级虚拟化：NVIDIA MIG (Multi-Instance GPU)
MIG同样在第七章有所介绍。它代表了NVIDIA在硬件层面解决GPU共享问题的最新思路。
定位：MIG是面向裸金属和容器化环境的、提供强隔离的多租户共享方案。它尤其适用于需要在一个物理节点上运行多个互相不信任、且需要有性能保障的AI任务的场景，如公有云的PaaS/CaaS平台。
核心技术回顾：
空间分片（Spatial Slicing）：MIG在硬件层面，将GPU的物理资源（SM、L2缓存、显存控制器等）进行静态地、空间上地分割。
GPU实例（GPU Instance, GI）：每个分割出的单元就是一个GI。每个GI都拥有自己独立的、不受干扰的硬件资源通路。
计算实例（Compute Instance, CI）：在一个GI内部，还可以进一步创建多个CI。CI共享GI的显存，但拥有各自独立的计算引擎状态，适用于需要隔离执行上下文但可以共享数据的场景。
MIG与vGPU的对比：
隔离性：MIG的隔离性是硬件级的，比vGPU的软件仲裁隔离更强、更彻底。一个GI的故障通常不会影响到另一个GI；但该隔离是针对故障与性能的隔离，不等同于抵御恶意侧信道攻击的绝对安全边界。
性能：MIG没有API转发的开销，每个GI的性能是可预测的、有保障的，因为它独占了一部分物理硬件。vGPU的性能则是共享的、有竞争的，一个vGPU的实际性能取决于当时有多少个其他vGPU在同时工作。
灵活性：vGPU的共享是动态的（时间分片），一个vGPU在空闲时，其他vGPU可以利用全部算力。MIG的划分是静态的，一个GI即使空闲，它的硬件资源也无法被其他GI使用。
显存：vGPU的显存分配更灵活（由配置文件决定）。MIG的显存分配是与硬件切片绑定的，规格固定。
适用环境：vGPU主要面向VM环境。MIG则更适合裸金属和容器环境，与Kubernetes的Device Plugin结合得非常好。
NVIDIA方案总结：
NVIDIA提供了一套从软件到硬件、从灵活共享到强隔离的“组合拳”：
MIG提供了最强的隔离和性能保障，但灵活性稍差，是多租户容器平台的理想选择。
vGPU提供了最平衡的灵活性、隔离性和功能完整性，是企业级虚拟化环境（VM）的首选商业方案。
MPS（Multi-Process Service）则是一种轻量级的时间分片方案，适用于在单个用户、可信环境下，让多个小任务（如推理服务）共享一张卡，以提升吞吐量。
API Remoting的思想则作为一种基础技术，被开源社区和云厂商发扬光大，衍生出了更多创新的虚拟化方案。
8.2 其他硬件厂商的GPU虚拟化调度方案
虽然NVIDIA在数据中心GPU市场占据主导，但了解AMD和Intel的方案有助于我们形成一个更全面的视角。它们的方案大多围绕着业界标准化的I/O虚拟化技术展开。
8.2.1 AMD的SR-IOV方案
AMD是SR-IOV（Single Root I/O Virtualization）技术在GPU虚拟化领域的主要推动者。其MxGPU技术就是基于SR-IOV实现的。
核心原理：
AMD的数据中心GPU（如Instinct MI系列）在硬件上支持SR-IOV。
通过在Hypervisor中加载物理功能（PF）驱动，可以将一张物理GPU卡在硬件上划分为多个虚拟功能（VF）。例如，一张MI100可以划分为最多8个VF。
每个VF都拥有自己独立的调度队列、显存页表和中断，从硬件上看就是一个独立的GPU设备。
这些VF可以被直接“直通”给不同的虚拟机。
虚拟机内部加载AMD的VF驱动，即可像使用物理GPU一样使用这个VF。
与NVIDIA vGPU的对比：
实现方式：AMD SR-IOV是硬件直通模型，性能开销极小。NVIDIA vGPU是API转发模型，有软件仲裁开销。
隔离性：两者都提供硬件辅助的强隔离。
灵活性：SR-IOV的VF划分规格是固定的，不够灵活。vGPU的配置文件和时间分片调度提供了更高的灵活性。
生态系统：NVIDIA vGPU的生态系统更成熟，与VMware、Citrix等主流虚拟化平台的集成更深入，商业支持也更完善。
8.2.2 Intel的GVT-g方案
Intel在推广其集成显卡和独立数据中心GPU（如Ponte Vecchio, Gaudi）时，也推出了自己的GPU虚拟化技术，其中GVT-g（Graphics Virtualization Technology -g）是其代表作。
核心原理：GVT-g采用的是一种类似于NVIDIA vGPU的API转发/仲裁模型，但它是完全开源的，并深度集成在Linux内核（KVMGT）和QEMU中。
无Guest驱动：与vGPU不同，GVT-g的一个巧妙之处在于，它不需要在虚拟机内部安装任何特殊的驱动。虚拟机会加载一个标准的、开源的Intel i915图形驱动，这个驱动完全不知道自己运行在虚拟环境中。
Hypervisor仲裁：当Guest驱动提交图形或计算命令时，Hypervisor中的KVMGT模块会截获这些提交到底层硬件寄存器的操作，然后代表该VM，安全地将这些命令提交给物理GPU执行。
显存虚拟化：GVT-g通过影子页表（Shadow Page Table）技术，为每个VM虚拟化了GPU的地址空间（GGTT），实现了显存的隔离。
优点：
开源与免费：GVT-g是完全开源的，无需任何商业许可证。
兼容性好：无需特殊的Guest驱动，简化了部署。
技术先进：其设计思想（如无Guest驱动、影子页表）非常优雅。
缺点：
生态与成熟度：GVT-g主要围绕Intel自家的GPU产品，其在数据中心大规模AI计算领域的生态和市场认可度，与NVIDIA相比还有较大差距。
性能：作为一种软件仲裁方案，同样存在一定的性能开销。
8.3 云厂商与开源社区基于容器的GPU虚拟化调度方案
在云原生的浪潮下，如何围绕容器实现比MIG更灵活、比时间分片隔离性更好、成本比vGPU更低的GPU共享方案，成为了各大云厂商和开源社区竞相追逐的“圣杯”。这些方案的核心思想，大多可以追溯到我们之前提到的API Remoting，但它们在实现上进行了大量的创新和优化。
核心思想：本地化的API劫持与资源管控
这些方案的通用架构模式如下：
CUDA API劫持（Hooking）
它们提供一个自定义的libcuda.so动态链接库。当用户的容器启动时，通过LD_PRELOAD环境变量，强制应用程序加载这个自定义的库，而不是系统原生的CUDA库。
这个自定义库会“劫持”所有应用程序发出的CUDA API调用。
资源管理与调度中心（Daemon）
在每个GPU节点上，运行一个常驻的管理守护进程。
这个守护进程负责管理本节点上所有物理GPU的真实资源（算力、显存）。
它维护着每个容器被分配的虚拟GPU资源的“账本”（例如，容器A分配了2GB显存和20%算力）。
本地IPC通信
被劫持的API调用，并不通过网络转发，而是通过高效的本地进程间通信（IPC），如Unix Domain Socket，发送给同机上的管理守护进程。这避免了API Remoting的巨大网络开销。
按需模拟与资源限制
显存管理：当守护进程收到一个cudaMalloc请求时，它会检查该容器的显存配额是否足够。如果足够，它才会在真实的物理GPU上分配显存，并建立一个从“虚拟显存地址”到“真实显存地址”的映射。它会向容器“谎报”GPU的总显存为其被分配的配额大小。
算力管理：对于计算内核的启动，守护进程会根据容器的算力配额，来控制其内核在物理GPU上的执行机会。这可以通过多种方式实现，例如：
控制内核并发度：限制该容器在同一时间最多能有多少个线程块（Blocks）在GPU上运行。
动态调整SM频率或功耗限制（需要硬件支持）。
更精细的时间分片：结合NVIDIA MPS或自己实现的调度器，精确控制其执行时间。
8.3.1 阿里云 cGPU
cGPU（container GPU）是阿里云容器服务团队推出的GPU共享虚拟化方案。
核心特性：
算力与显存解耦：用户可以独立地申请算力和显存。例如，可以申请一个只有1GB显存但需要50%算力的容器，或者一个需要10GB显存但只需要10%算力的容器。
显存隔离：通过API劫持，cGPU为每个容器虚拟了一个独立的显存空间，一个容器无法访问到另一个容器的显存。
算力隔离：通过控制CUDA Kernel的执行（类似于时间分片），实现了算力的隔离和限制。
与Kubernetes深度集成：提供了cGPU的Device Plugin，用户可以在Pod YAML中直接以aliyun.com/gpu-mem: 1024（单位MB）和aliyun.com/gpu-core: 50（单位%）的形式声明资源，调度器会根据节点的cGPU资源余量进行调度。
8.3.2 腾讯云 qGPU
qGPU（GPU TKE-Ving）是腾讯云容器服务（TKE）推出的GPU虚拟化方案，其思想与cGPU类似，但在实现细节和商业化程度上有所不同。
核心特性：
同样实现了算力和显存的细粒度切分和隔离。
强调QoS保障，能够为不同优先级的任务提供有差异的服务质量。
与腾讯云自身的监控、计费、运维体系深度集成。
8.3.3 开源社区方案：以TKE vCUDA+GPU Manager为例
除了闭源的商业方案，开源社区也涌现了许多类似的项目，例如腾讯云早期开源的TKE GPU-Manager。
TKE vCUDA: 这是一个实现了本地API劫持的libcuda.so库。
GPU Manager: 这是一个与Kubernetes集成的调度和管理组件。
它允许用户在Pod的Annotation中声明GPU需求（如tke.cloud.tencent.com/gpu-core-percentage: 30, tke.cloud.tencent.com/gpu-mem-percentage: 30）。
一个自定义的调度器扩展（Scheduler Extender）会根据这些Annotation和节点的GPU资源使用情况，来决定Pod应该被调度到哪个节点。
节点上的GPU Manager会根据分配结果，为启动的容器设置LD_PRELOAD等环境变量，启用vCUDA的API劫持。
8.3.4 这些方案的共性、优点与挑战
共性：它们都采用了“应用无感、本地劫持、集中管控”的核心架构模式。对于用户的AI应用代码来说，完全不知道自己运行在虚拟化的GPU环境中。
优点：
极致的灵活性和利用率：实现了GPU资源的超细粒度切分和超卖，在共享任务占比高、负载碎片化的场景下可显著提升GPU利用率（各云厂商公开案例给出的幅度不一，通常宣称可从常见的两三成提升到六成以上），从而降低AI应用的单位算力成本；具体幅度取决于负载结构，应以自身集群统计为准。
算力与显存解耦：满足了各种奇形怪状的资源需求，适配了从开发、调试、推理到小规模训练的全场景。
易于集成：与云原生生态（Kubernetes, Docker）无缝集成，提供了良好的用户体验。
挑战与权衡：
性能开销：API劫持和IPC通信虽然比网络转发快得多，但仍然会引入一定的性能开销，特别是对于那些大量、频繁调用小API的应用。对于需要极致性能的大规模分布式训练，其性能可能不如MIG或物理卡。
兼容性与维护成本：最大的挑战来自于对NVIDIA驱动和CUDA版本的追随。每当NVIDIA发布新的驱动，这些方案的libcuda.so劫持库可能都需要进行适配和严格的测试，以确保所有CUDA API都能被正确地模拟和处理。这是一个巨大的、持续的工程投入。
隔离性的强度：这种软件层面的隔离，其强度和安全性理论上不如MIG或vGPU这样的硬件/Hypervisor级隔离。虽然已经可以防止大部分常规错误，但在最严格的安全要求下，仍然存在潜在的风险。
功能完整性：某些非常底层或未公开的CUDA功能可能难以被完美模拟，导致一些特殊的应用无法运行。
8.4 本章小结
在本章中，我们对GPU虚拟化调度方案进行了一次全景式的、深入的考察，将我们对GPU资源共享的理解，从第七章的“板卡级分配”提升到了“精细化虚拟化”的更高层次。
我们梳理了NVIDIA官方的虚拟化技术“全家桶”，明确了它们各自的定位：
MIG以其无与伦比的硬件强隔离和性能可预测性，成为云原生多租户场景下安全与性能的基石。
GRID vGPU凭借其在VM环境中的成熟生态、灵活的时间分片调度和完善的功能，稳坐企业级虚拟化市场的头把交椅。
API Remoting作为一种基础思想，为后来的许多创新方案奠定了理论基础。
我们还横向对比了其他硬件厂商的方案，如AMD的SR-IOV和Intel的GVT-g。我们看到，它们分别代表了硬件直通和开源仲裁这两条不同的技术路线，虽然在生态上不及NVIDIA，但其技术思路同样具有重要的参考价值。
本章的重中之重，是我们对以阿里云cGPU、腾讯云qGPU为代表的、兴起于云原生社区的容器GPU虚拟化方案的深入剖析。我们揭示了它们共同的、巧妙的核心架构：通过本地化的CUDA API劫持和集中的资源管理守护进程，它们成功地在保持应用无感的同时，实现了对GPU算力和显存的超细粒度切分、隔离与池化。这些方案以其极致的灵活性和资源利用率，完美地契合了云原生时代对弹性和成本效益的追求，代表了当前GPU虚拟化领域最活跃、最具创新性的发展方向，尽管它们也面临着性能开销、兼容性维护和隔离强度等方面的持续挑战。
最终，我们得出一个结论：不存在任何一种“银弹”式的GPU虚拟化方案。 这是一个充满了权衡的决策空间。架构师在选择方案时，必须像一位经验丰富的主厨，根据眼前的“食材”（业务场景）和需要达成的“口味”（核心诉求），来精心调配各种“调料”（技术方案）：
若安全隔离是第一要务，选择MIG或vGPU。
若极致的资源利用率和成本效益是首要目标，选择cGPU/qGPU这类方案。
若追求无损的裸金属性能，且可以接受独占，选择GPU直通或简单的独占式容器调度。
对这幅GPU虚拟化技术图谱的深刻理解，将使我们有能力为我们的AI平台构建一个既强大又经济、既稳定又灵活的算力底座，从而在激烈的AI军备竞赛中，获得关键的“成本优势”和“敏捷优势”。