vGPU 原理揭秘：

在 NVIDIA 虚拟 GPU 助力的虚拟化环境中，NVIDIA 虚拟 GPU (vGPU) 软件与 Hypervisor 一同安装在虚拟化层上。

此软件可创建虚拟 GPU，使每个虚拟机 (VM) 都能共享安装在服务器上的物理 GPU。对于要求非常严苛的工作流程，单个 VM 可充分利用多个物理 GPU。我们的软件包含适用于各种 VM 的显卡或计算驱动。由于通常由 CPU 完成的工作分流到 GPU，因而用户可以获得更出色的体验。虚拟化和云环境可支持要求苛刻的工程和创意应用程序，以及计算密集型工作负载（例如 AI 和数据科学）。

NVIDIA 虚拟 GPU (vGPU) 软件为众多工作负载（从图形丰富的虚拟工作站到数据科学和 AI）提供强大的 GPU 性能，使 IT 能够利用虚拟化的管理和安全优势以及现代工作负载所需的 NVIDIA GPU 的性能。NVIDIA vGPU 软件安装在云或企业数据中心服务器的物理 GPU 上，会创建虚拟 GPU，这些 GPU 可以在多个虚拟机（可随时随地通过任意设备访问）之间共享。

优势：

• 通过实时迁移 GPU 加速的 VM，您可以获得持续正常运行和前瞻性管理能力 – 不会对用户产生负面影响或丢失数据。

• 利用统一的虚拟 GPU 加速基础设施来运行混合 VDI 和计算工作负载，从而提高数据中心资源的利用率。

• 拆分 GPU 资源并在多个 VM 之间共享，或者将多个 GPU 分配给单个 VM，为要求极高的工作负载提供支持。

• 借助灵活的调度选项，实现几乎与非虚拟化环境无异的性能。

支持虚拟化的GPU 卡介绍：??????

二、NVIDIA MIG 虚拟化 多实例 GPU

单个 GPU 中包含七个独立实例。

多实例 GPU (MIG) 能够提升 NVIDIA Blackwell 和 Hopper? 系列 GPU 的性能和价值。MIG 可将 GPU 划分为多达七个实例，其中每个实例均完全独立，并具有各自的高带宽显存、缓存和计算核心。如此一来，管理员便能支持各种规模的工作负载，确保服务质量 (QoS) 稳定可靠，并让每位用户都能享用加速计算资源。

优势概览：

• 借助 MIG，您可以在单个 GPU 上获得多达原来 7 倍的 GPU 资源。MIG 可让研发人员和开发者获享更多资源和更高的灵活性。

• MIG 允许灵活选择许多不同的实例大小，以便针对每项工作负载提供大小适当的 GPU 实例，最终优化利用率并充分发挥数据中心投资的价值。

• 借助 MIG，可以在单个 GPU 上同时运行推理、训练和高性能计算 (HPC) 工作负载，并使延迟和吞吐量保持稳定。与时间分片不同，各项工作负载都将并行运行，从而能够提高性能。

技术原理：

若不使用 MIG，则同一 GPU 上运行的不同作业（例如不同的 AI 推理请求）会争用相同的资源。显存带宽更大的作业会占用其他作业的资源，导致多项作业无法达成延迟目标。借助 MIG，作业可同时在不同的实例上运行，每个实例都有专用的计算、显存和显存带宽资源，从而实现可预测的性能，同时符合服务质量 (QoS) 并尽可能提升 GPU 利用率。

特性分析：

全新Multi-Instance GPU（MIG）特性允许从NVIDIA Ampere架构开始的GPU可以被安全分割为最多七种独立的GPU实例，服务于CUDA应用，从而使多个用户能各自拥有独立的GPU资源，以达到最佳利用率。这一特性特别适用于那些不能充分利用GPU计算能力的工作负载场景，用户可以通过并行运行不同的任务来最大程度提升GPU的使用效率。

对于有多租户需求的云服务提供商（CSP），MIG技术确保了单一客户端的行为不会干扰其他客户端的运行或调度，同时增强了对各个客户的安全隔离性。

在MIG模式下，每个实例所对应的处理器具备独立且隔绝的内存系统访问路径——片上交叉开关端口、L2缓存分段、内存控制器以及DRAM地址总线均会专一地分配给单个实例。这使得即便有其他任务在对其自身缓存进行大量读写操作或已使DRAM接口达到饱和的情况下，单个工作负载仍能获得稳定、可预期的执行速度和延迟时间，同时保证相同水平的L2缓存分配与DRAM带宽资源。MIG能够对GPU中的计算资源（包括流式多处理器或SM，以及诸如拷贝引擎或解码器之类的GPU引擎）进行划分，从而为不同的客户（例如虚拟机、容器或进程）提供预设的服务质量（QoS）保障及故障隔离机制。

运用MIG技术后，用户可以像管理实体GPU一样查看和安排在新建的虚拟GPU实例上的任务。MIG兼容Linux操作系统，支持基于Docker Engine的容器部署，同时亦对接Kubernetes及建立于Red Hat虚拟化和VMware vSphere等支持的虚拟机管理程序之上的虚拟机。

MIG支持如下部署方案：

1. 直接部署于裸金属环境，包含容器化部署

2. 在支持的虚拟机管理程序之上，将GPU直接传递给Linux来宾，实现GPU直通虚拟化

3. 利用支持的虚拟机管理程序实施vGPU部署

通过MIG技术，可在同一张物理GPU上并行运行多个vGPU（从而实现多个虚拟机并行运行），同时保持vGPU所提供的隔离性保障。

根据需要调配和配置实例：

一个 GPU 可划分成多个大小不同的 MIG 实例。例如，在 NVIDIA GB200 上，管理员可以创建两个各有 95GB 显存的实例、四个各有 45GB 的实例，或七个各有 23GB 的实例。

管理员还可以动态重新配置 MIG 实例，从而根据不断变化的用户需求和业务需求调整 GPU 资源。例如，白天可以使用七个 MIG 实例进行低吞吐量推理，夜间则可以重新配置为一个大型 MIG 实例，以便进行深度学习训练。

安全、并行运行工作负载：

每个 MIG 实例都拥有一组专用的计算、内存和缓存硬件资源，因此能够实现稳定可靠的服务质量和故障隔离。这意味着，如果某个实例上运行的应用发生故障，将不会影响其他实例上运行的应用。

这还意味着，不同的实例可以运行不同类型的工作负载，包括交互式模型开发、深度学习训练、AI 推理、高性能计算应用等工作负载。由于这些实例并行运行，因此工作负载也都是在同一个物理 GPU 上并行运行，但它们相互独立、彼此隔离。

Blackwell GPU 中的 MIG

Blackwell 和 Hopper GPU 通过多达 7 个 GPU 实例在虚拟化环境中支持多租户、多用户配置，以便协助实现 MIG，进而在硬件和服务器虚拟化管理程序级别利用机密计算安全地隔离每个实例。每个 MIG 实例都有专用的视频解码器，这些解码器能够在共享基础架构上提供安全、高吞吐量的智能视频分析 (IVA)。借助并发 MIG 分析，管理员可以监控规模适当的 GPU 加速，并为多个用户分配资源。???

如果工作负载较小，研究人员可以不必租用整个云实例，而是利用 MIG 安全地隔离 GPU 的一部分，同时保证其数据在静态、传输和使用时安全无虞。这可以使云服务提供商更灵活地进行定价，并抓住小型客户带来的商机。

数据中心级MIG多实例结构图?

三、MIG 规格介绍

支持MIG GPU列表

MIG划分 案例介绍：

下表列出了A100-SXM4-40GB产品上的配置名称。对于A100-SXM4-80GB产品，配置名称将根据内存比例相应改变，例如分别为1g.10gb、2g.20gb、3g.40gb、4g.40gb以及7g.80gb。

GPU Instance Profiles on A100

下图以图形方式展示了如何构建所有有效的GPU实例组合

MIG Profiles on A100

GPU Instance MIG切分介绍：

GPU的分区是通过内存切片实现的，因此可以认为A100-40GB GPU包含了8个5GB的内存切片和7个SM切片，如下图所示。

Available Slices on A100

如上所述，创建一个GPU实例（GI）需要将一定数量的内存切片与一定数量的计算切片相结合。在下图中，我们将1个5GB的内存切片与1个计算切片组合起来，生成了一个1g.5gb的GI配置：

Combining Memory and Compute Slices

同样地，4个5GB的内存切片可以与4个1个计算切片相结合来创建4g.5gb的GI配置：

Combining Memory and Compute Slices

这种配置意味着在4g.5gb的GPU实例中，总共有4个计算单元（cores或者stream processors），并且整体内存容量为4倍5GB，即总内存为20GB。这种灵活的配置方式允许用户根据其应用程序的需求量身定制GPU资源，确保能够高效利用GPU进行大规模并行计算或处理高内存需求的任务。例如，在深度学习训练、高性能计算和图形密集型应用中，适配正确的GPU资源组合至关重要。

云原生虚拟化调度GPU资源介绍：

AI 开发通常部署在容器和虚拟化环境中，以提高可移植性、效率和可扩展性。NVIDIA AI Enterprise 已经过认证，可在主流容器平台（例如 VMware Tanzu、Red Hat OpenShift、HPE Ezmeral 和上游 Kubernetes）上运行 AI 工作负载，以在混合或多云环境中加速各种 AI 用例。

在MIG实例上调度 Kubernetes pod实战

NVIDIA为Kubernetes设计的设备插件是一种Daemonset，它能够自动完成以下功能：

1. 在集群内每个节点上公开可用的GPU数量。

2. 实时监控集群中所有GPU的健康状况。

3. 允许您在Kubernetes集群中运行支持GPU的容器。

当前仓库包含了NVIDIA官方提供的Kubernetes设备插件实现版本。

请注意：

• 自Kubernetes v1.10版本起，NVIDIA设备插件API被标记为beta版。

• 当前NVIDIA设备插件尚不完善，缺少以下功能：

• 完整的GPU健康检查功能

• GPU清理功能

• NVIDIA仅对官方发布的NVIDIA设备插件提供支持（而不支持此插件的分支或其它变体）。

运行NVIDIA设备插件所需的前置条件如下：

1. NVIDIA驱动程序版本约为384.81或更高版本。

2. nvidia-docker版本大于等于2.0，或者nvidia-container-toolkit版本大于等于1.7.0（若要在基于Tegra的系统上使用集成GPU，则需大于等于1.11.0版本）。

3. 已将nvidia-container-runtime配置为默认的底层运行时环境。

4. Kubernetes集群版本不低于1.10。

准备GPU节点

以下步骤需要在所有GPU节点上执行。这份README假设您已经预先安装了NVIDIA驱动程序和nvidia-container-toolkit，并且已经将nvidia-container-runtime配置为默认使用的底层运行时环境。

参考链接：https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/install-guide.html

基于Debian系统的Docker和containerd安装示例

安装 NVIDIA Container Toolkit

有关安装和开始使用NVIDIA Container Toolkit的详细步骤，请参考官网安装指南。

同时，请注意针对以下运行时环境的具体配置说明：

• containerd

• CRI-O

• docker（已弃用）

每次应用配置更改后，记得重启相应的运行时环境。

如果需要将nvidia运行时设置为默认运行时（对于docker来说是必需的），则上述命令中必须包含--set-as-default参数。如果不这样做，就需要定义RuntimeClass。

关于CRI-O配置的注释

当使用CRI-O运行Kubernetes时，应在/etc/crio/crio.conf.d/目录下添加名为99-nvidia.conf的配置文件，以将nvidia-container-runtime设置为默认的低级OCI运行时。这样做的优先级会高于默认crun配置文件（位于/etc/crio/crio.conf.d/10-crun.conf）：

[crio]??[crio.runtime]????default_runtime?=?"nvidia"????[crio.runtime.runtimes]??????[crio.runtime.runtimes.nvidia]????????runtime_path?=?"/usr/bin/nvidia-container-runtime"????????runtime_type?=?"oci"

正如链接文档中所述，这个配置文件可通过nvidia-ctk命令自动生成：

$?sudo?nvidia-ctk?runtime?configure?--runtime=crio?--set-as-default?--config=/etc/crio/crio.conf.d/99-nvidia.conf

CRI-O使用crun作为默认的低级OCI运行时，因此需要将crun添加到nvidia-container-runtime在配置文件/etc/nvidia-container-runtime/config.toml中的运行时列表中。

[nvidia-container-runtime]runtimes?=?["crun",?"docker-runc",?"runc"]

然后重新启动CRI-O。

$?sudo?systemctl?restart?crio

在Kubernetes中启用GPU支持

一旦在集群中的所有GPU节点上配置了上述选项，您就可以通过部署以下Daemonset来启用GPU支持:

$?kubectl?create?-f?https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.14.5/nvidia-device-plugin.yml

注意: 这是一个简单的静态守护进程，用于演示nvidia-device-plugin的基本特性。在生产环境中部署插件时，请参阅下面通过helm进行部署的说明。

Running GPU Jobs

随着守护进程的部署，NVIDIA gpu现在可以由使用nvidia.com/gpu资源类型的容器请求:

$?cat?<








$?kubectl?logs?gpu-pod[Vector?addition?of?50000?elements]Copy?input?data?from?the?host?memory?to?the?CUDA?deviceCUDA?kernel?launch?with?196?blocks?of?256?threadsCopy?output?data?from?the?CUDA?device?to?the?host?memoryTest?PASSEDDone
通过 helm 部署
部署设备插件的首选方法是使用helm作为守护进程。
首先设置插件的helm存储库，并按如下方式更新:


$?helm?repo?add?nvdp?https://nvidia.github.io/k8s-device-plugin$?helm?repo?update
查看版本??



$?helm?search?repo?nvdp?--develNAME?????????????????????????CHART?VERSION??APP?VERSION??DESCRIPTIONnvdp/nvidia-device-plugin????0.14.5???0.14.5????A?Helm?chart?for?...
执行安装




helm?upgrade?-i?nvdp?nvdp/nvidia-device-plugin???--namespace?nvidia-device-plugin???--create-namespace???--version?0.14.5
创建CM











cat?<?/tmp/dp-example-config0.yamlversion:?v1flags:??migStrategy:?"none"??failOnInitError:?true??nvidiaDriverRoot:?"/"??plugin:????passDeviceSpecs:?false????deviceListStrategy:?envvar????deviceIDStrategy:?uuidEOF
开始安装





$?helm?upgrade?-i?nvdp?nvdp/nvidia-device-plugin?????--version=0.14.5?????--namespace?nvidia-device-plugin?????--create-namespace?????--set-file?config.map.config=/tmp/dp-example-config0.yaml
或者选择手动创建，而非helm模式安装?????








$?kubectl?create?ns?nvidia-device-plugin$?kubectl?create?cm?-n?nvidia-device-plugin?nvidia-plugin-configs?????--from-file=config=/tmp/dp-example-config0.yaml?$?helm?upgrade?-i?nvdp?nvdp/nvidia-device-plugin?????--version=0.14.5?????--namespace?nvidia-device-plugin?????--create-namespace?????--set?config.name=nvidia-plugin-configs
多个配置文件示例
对于多个配置文件，过程类似。
创建第二个配置文件，内容如下:











cat?<?/tmp/dp-example-config1.yamlversion:?v1flags:??migStrategy:?"mixed"?#?Only?change?from?config0.yaml??failOnInitError:?true??nvidiaDriverRoot:?"/"??plugin:????passDeviceSpecs:?false????deviceListStrategy:?envvar????deviceIDStrategy:?uuidEOF
通过helm重新部署设备插件(用指定的默认值将其指向两个配置)。







$?helm?upgrade?-i?nvdp?nvdp/nvidia-device-plugin?????--version=0.14.5?????--namespace?nvidia-device-plugin?????--create-namespace?????--set?config.default=config0?????--set-file?config.map.config0=/tmp/dp-example-config0.yaml?????--set-file?config.map.config1=/tmp/dp-example-config1.yaml
和之前一样，如果需要，这也可以通过预先创建的ConfigMap来完成:

$?kubectl?create?ns?nvidia-device-plugin



$?kubectl?create?cm?-n?nvidia-device-plugin?nvidia-plugin-configs?????--from-file=config0=/tmp/dp-example-config0.yaml?????--from-file=config1=/tmp/dp-example-config1.yaml






$?helm?upgrade?-i?nvdp?nvdp/nvidia-device-plugin?????--version=0.14.5?????--namespace?nvidia-device-plugin?????--create-namespace?????--set?config.default=config0?????--set?config.name=nvidia-plugin-configs

注意:如果没有显式设置config.default标志，那么如果其中一个配置名被设置为'default'，则会从配置中推断出默认值。如果这两个都没有设置，那么部署将失败，除非只提供了一个配置。在只提供单个配置的情况下，它将被选择为默认配置，因为没有其他选项。
使用节点标签更新每节点配置
通过这种设置，默认情况下所有节点上的插件都为其配置了config0。但是，可以设置以下标签来更改应用的配置:


kubectl?label?nodes??–-overwrite?????nvidia.com/device-plugin.config=

例如，为所有安装了T4 gpu的节点应用自定义配置是:





kubectl?label?node?????--overwrite?????--selector=nvidia.com/gpu.product=TESLA-T4?????nvidia.com/device-plugin.config=t4-config
注意: 此标签可以在插件启动之前或之后应用，以便在节点上应用所需的配置。任何时候它的值改变，插件将立即更新，开始服务所需的配置。如果设置为未知值，则跳过重新配置。如果它被取消设置，它将回退到默认值。
如前所述，设备插件的helm图继续提供直接的值来设置插件的配置选项，而不使用ConfigMap。这些应该只用于设置全局适用的选项(这些选项不应该被嵌入到ConfigMap提供的配置文件中)，或者用于根据需要覆盖这些选项。

















??migStrategy:??????the?desired?strategy?for?exposing?MIG?devices?on?GPUs?that?support?it??????[none?|?single?|?mixed]?(default?"none")??failOnInitError:??????fail?the?plugin?if?an?error?is?encountered?during?initialization,?otherwise?block?indefinitely??????(default?'true')??compatWithCPUManager:??????run?with?escalated?privileges?to?be?compatible?with?the?static?CPUManager?policy??????(default?'false')??deviceListStrategy:??????the?desired?strategy?for?passing?the?device?list?to?the?underlying?runtime??????[envvar?|?volume-mounts?|?cdi-annotations?|?cdi-cri]?(default?"envvar")??deviceIDStrategy:??????the?desired?strategy?for?passing?device?IDs?to?the?underlying?runtime??????[uuid?|?index]?(default?"uuid")??nvidiaDriverRoot:??????the?root?path?for?the?NVIDIA?driver?installation?(typical?values?are?'/'?or?'/run/nvidia/driver')

注意: 没有直接映射到插件的PASS_DEVICE_SPECS配置选项的值。取而代之的是提供一个名为compatWithCPUManager的值，它充当该选项的代理。它将插件的PASS_DEVICE_SPECS选项设置为true，并确保插件以提升的权限启动，以确保与CPUManager的适当兼容性。
除了这些插件的自定义配置选项外，其他通常被覆盖的标准helm chart值包括:


??runtimeClassName:??????the?runtimeClassName?to?use,?for?use?with?clusters?that?have?multiple?runtimes.?(typical?value?is?'nvidia')

请看一下数值。以查看设备插件的可重写参数的完整集合。

设置这些选项的示例包括:

启用与CPUManager兼容，CPU时间要求100ms，内存限制512MB。







$?helm?upgrade?-i?nvdp?nvdp/nvidia-device-plugin?????--version=0.14.5?????--namespace?nvidia-device-plugin?????--create-namespace?????--set?compatWithCPUManager=true?????--set?resources.requests.cpu=100m?????--set?resources.limits.memory=512Mi

启用与CPUManager和混合migStrategy的兼容性






$?helm?upgrade?-i?nvdp?nvdp/nvidia-device-plugin?????--version=0.14.5?????--namespace?nvidia-device-plugin?????--create-namespace?????--set?compatWithCPUManager=true?????--set?migStrategy=mixed
使用gpu-feature-discovery来部署自动节点标签

从v0.12.0开始，设备插件的helm图集成了将gpu特性发现(GFD)部署为子图的支持。可以使用GFD为节点上可用的gpu集自动生成标签。在底层，它利用Node Feature Discovery来执行这个标记。

要启用它，只需设置gfd。在helm安装期间Enabled =true。






helm?upgrade?-i?nvdp?nvdp/nvidia-device-plugin?????--version=0.14.5?????--namespace?nvidia-device-plugin?????--create-namespace?????--set?gfd.enabled=true

在底层，它还将部署节点特征发现(NFD)，因为它是GFD的先决条件。如果您已经在集群上部署了NFD，并且不希望通过此安装将其拉入，则可以使用NFD .enabled=false禁用它。

除了GFD应用的标准节点标签外，在部署带有上述时间切片扩展的插件时，还将包括以下标签。

nvidia.com/.replicas?=?
另外，如果renameByDefault=false, nvidia.com/.product将被修改如下。

nvidia.com/.product?=?-SHARED
使用这些标签，用户可以选择共享与非共享GPU，就像他们传统上选择一种GPU模型而不是另一种一样。也就是说，SHARED注释确保可以使用nodeSelector将pod吸引到具有共享gpu的节点上。

因为renameByDefault=true已经在资源名上编码了资源是共享的事实，所以没有必要用shared来注释产品名。用户已经可以通过简单地在pod规范中请求找到他们需要的共享资源。

注意:当使用renameByDefault=false和migStrategy=single运行时，MIG配置文件名称和新的共享注释将被附加到产品名称后，例如:

nvidia.com/gpu.product?=?A100-SXM4-40GB-MIG-1g.5gb-SHARED

了解AI更多方面资讯，请关注巴特星球公众号：