📚 课程目录第3章虚拟化技术概述

3. 虚拟化技术概述：虚拟化分类、GPU虚拟化需求与挑战

3.1 虚拟化的本质与分类框架

虚拟化的核心思想是将物理资源（计算、存储、网络、设备）转换为逻辑上可分割、可组合、可调度的资源池，从而打破物理边界对应用部署的约束。在GPU虚拟化语境下，理解分类框架有助于定位不同技术方案的适用场景。按抽象层次划分，虚拟化可分为以下类型：

分类维度	代表技术	资源抽象粒度	典型开销
硬件辅助虚拟化	Intel VT-x / AMD-V，SR-IOV	物理核、PCIe设备功能	低（接近物理性能）
操作系统级虚拟化	容器（Docker/K8s）、CGroup	进程、命名空间、设备cgroup	极低（共享内核）
半虚拟化 / 全虚拟化	KVM、Xen、VMware ESXi	整机、虚拟CPU/内存/设备	中（需VMM翻译）
API级虚拟化（远程/重定向）	CUDA-V、rCUDA、API forwarding	库函数调用、显存对象	高（网络/进程间通信）

GPU虚拟化并非单一技术，而是横跨上述多个层次的组合方案。例如，vGPU（NVIDIA MIG / AMD MxGPU）属于硬件辅助的SR-IOV变种，而CUDA-V则属于API级虚拟化。选择何种方案，取决于对隔离性、性能、兼容性和密度之间的权衡。

关键认知：GPU虚拟化不是“把一块GPU切成几块”这么简单。它涉及显存隔离、计算流调度、上下文切换、DMA重映射、中断处理等多个硬件/软件协同层面。分类框架帮助我们判断：当前瓶颈在哪个抽象层，就应在该层做资源切分或转发。

3.2 GPU虚拟化的核心需求与驱动场景

为什么需要GPU虚拟化？从实际部署角度看，需求主要来自以下四类场景：

多租户共享：云平台中多个用户或任务共享同一块物理GPU，要求相互隔离且互不干扰（例如：A用户训练任务不能因B用户的显存溢出而崩溃）。
资源利用率提升：AI推理任务往往只占用GPU小部分算力，通过虚拟化将空闲算力切分给多个轻量级任务，可将利用率从20%提升至70%以上。
故障隔离与热迁移：虚拟机或容器需要独立重启、升级或迁移，而物理GPU无法直接热插拔，虚拟化层需提供状态保存与恢复能力。
安全边界：不同租户的数据（模型权重、训练数据）必须物理隔离，防止通过GPU显存侧信道或DMA攻击窃取信息。

以Kubernetes集群为例，调度器需要感知GPU资源（显存大小、算力份额、显存带宽），并将Pod调度到满足需求的节点。若没有GPU虚拟化，每个Pod只能独占整块GPU，导致大量碎片资源浪费。

# 未虚拟化时：一个Pod独占整卡
resources:
  limits:
    nvidia.com/gpu: 1   # 只能申请整数卡

# 启用vGPU后：可申请小数份额
resources:
  limits:
    nvidia.com/gpu: 0.25  # 占用1/4算力与显存

3.3 GPU虚拟化的主要技术路径与原理

当前主流GPU虚拟化技术可归纳为四条路径，每条路径在隔离性、性能、兼容性上各有取舍：

直通独占（Passthrough）：将物理GPU直接分配给单个虚拟机，性能接近物理卡，但无共享能力，且虚拟机迁移受限。
硬件分区（SR-IOV / MIG）：GPU硬件原生支持将物理设备划分为多个独立实例（如NVIDIA A100 MIG可切分为7个实例），每个实例拥有独立的显存、计算核心和带宽，硬件级隔离，性能损耗极小。
软件时间片切分（vGPU / 算力切分）：通过驱动层截获GPU命令，按时间片轮转或优先级调度多个租户的上下文。显存可静态划分或动态复用，但上下文切换有开销。
API转发（远程/库拦截）：拦截CUDA/OpenCL调用，转发到远端GPU或本地共享进程。灵活度最高，但每次调用都有序列化/反序列化开销，不适合高吞吐训练。

  工程实践提示：在NVIDIA平台上，MIG（Multi-Instance GPU）适合对隔离性要求高的生产环境；而时间片切分（如vGPU的算力模式）适合开发测试或推理场景。AMD的MxGPU则基于SR-IOV硬件虚拟化，每个虚拟设备拥有独立调度器。

3.4 案例：Kubernetes集群中的GPU虚拟化部署

以一个实际AI平台为例，该平台有4张NVIDIA A100 40GB GPU，需要支撑12个推理服务（每个约需5GB显存、20%算力）和2个训练任务（每个需整卡算力）。若不虚拟化，12个推理服务需12张卡，远超物理资源；若全部使用MIG，则每张A100可切分为7个5GB实例，但训练任务需要整卡，无法与MIG共存。

最终方案采用混合策略：

2张GPU配置为MIG模式，每张切分为4个实例（每个10GB显存、约25%算力），共8个实例承载推理服务。
2张GPU保持直通模式，分别分配给2个训练任务。
通过Kubernetes device plugin上报虚拟化资源，调度器自动匹配。

该方案将GPU利用率从35%提升至82%，同时训练任务获得确定性性能保障。关键配置如下：

# 在GPU节点上启用MIG
nvidia-smi -mig 1
nvidia-smi mig -cgi 1g.10gb -C   # 创建4个1g.10gb实例

# Kubernetes device plugin配置
spec:
  containers:
  - name: inference
    resources:
      limits:
        nvidia.com/gpu: 1
        nvidia.com/mig-1g.10gb: 1   # 指定MIG实例类型

3.5 误区与复盘：GPU虚拟化的常见陷阱

误区一：认为vGPU = 性能无损。实际上，时间片切分会产生上下文切换开销，尤其在频繁小kernel调用时，性能可能下降20%-40%。MIG硬件隔离性能较好，但实例间无法共享显存，且创建/销毁实例需要重置GPU。

误区二：忽略显存隔离的粒度。某些软件虚拟化方案（如API转发）虽然能限制显存总量，但无法阻止租户通过CUDA的cudaMemcpyPeer等操作尝试访问其他租户的显存区域。必须依赖驱动级页表隔离或硬件MIG才能提供真正的安全边界。

误区三：盲目追求高密度切分。将一张GPU切分为过多实例会导致每个实例的算力过小，无法满足推理延迟要求。例如，将A100切分为14个5GB实例后，每个实例的FP16算力仅约20 TFLOPS，对于大模型推理可能不够。

复盘建议：在规划GPU虚拟化方案时，应首先量化工作负载的显存占用、算力需求（TFLOPS）、显存带宽需求以及延迟敏感度。然后根据这些参数选择虚拟化粒度。建议先做POC测试，用真实模型跑通后再决定生产配置。

3.6 本章小结

GPU虚拟化的本质是在物理GPU与计算任务之间建立一层资源抽象与隔离机制。理解虚拟化分类（硬件辅助、OS级、半虚拟化、API级）有助于判断不同方案的适用边界。核心需求包括多租户共享、利用率提升、故障隔离与安全防护。技术路径上，直通独占性能最佳但无共享；MIG硬件分区在隔离性与性能间取得最佳平衡；时间片切分提供高密度但牺牲部分性能；API转发灵活但开销最大。实际部署中应结合工作负载特征（显存、算力、延迟要求）选择混合策略，并通过POC验证后再投入生产。