# 如何高效共享与优化 AI 工作负载的 GPU 资源

> 探索企业如何通过 vGPU、MPS、MIG、CUDA Hook 等技术高效共享 GPU 资源，了解现代 AI 基础设施中提升 GPU 利用率所面临的挑战、取舍与最佳实践。

- 发布时间: 2025-03-25
- 更新时间: 2025-03-25
- 作者: [ZSvirt 团队](https://github.com/ZSvirt)
- 分类: 技术分享
- 标签: AI 基础设施, 深度学习, GPU 虚拟化, MIG, vGPU, CUDA Hook, 分布式并行

## 引言

由于 **GPU 基础设施成本高昂，尤其是高端加速器** ，企业越来越关注 GPU 利用率的提升。一个常见的问题随之而来： **既然 GPU 资源很少被持续充分利用，那么是否可以像 CPU 虚拟化在物理服务器上运行多台虚拟机一样，将一块 GPU 分区并共享给多个用户，从而最大化资源效率？**

然而在实践中， **GPU 虚拟化与资源共享相比 CPU 虚拟化仍远未成熟** ，原因在于以下一些根本性差异，包括：

*   **GPU 与 CPU 之间的架构差异**

*   **工作负载特性与使用场景的差异**

*   **各 GPU 厂商软硬件生态成熟度的差异**

**本文概述 GPU 架构，并深入探讨共享 GPU 资源的主要技术路线，包括 vGPU、MPS、MIG、CUDA Hook 以及远程调用等技术。同时，文章还将分析企业如何在现代 AI 环境中选择合适的 GPU 共享策略以提升利用率与效率。**

## 一、概述

### 1.1 GPU 的工作原理概述

#### 1.1.1 高度并行的硬件架构

GPU（图形处理器）最初为图形加速而设计，如今已演进为针对 **大规模并行计算工作负载** 进行优化的处理器。与面向通用计算和复杂串行运算的 CPU 不同，GPU 拥有大量的 **流式多处理器（SM）和计算核心** ，能够在 **单指令多数据（SIMD）或单指令多线程（SIMT）执行模型** 下同时运行数千个线程。

[图片可在规范 HTML 页面中查看: 理解 GPU 与 CPU 的对比](https://zsvirt.io/zh/blog/how-to-efficiently-share-gpu-resources/)

#### 1.1.2 上下文与显存（VRAM）

**CUDA 上下文：**

在 CUDA 编程环境中，当多个进程或容器访问同一块 GPU 时，每个进程通常都需要自己的 CUDA 上下文。GPU 通过 **时间片轮转机制或上下文共享方式** 来管理这些上下文，例如 NVIDIA 多进程服务（MPS）将多个进程合并到一个共享的执行上下文中。

**显存（VRAM）：**

与主要依赖操作系统级内存虚拟化机制（如 MMU）的 CPU 内存管理不同，GPU 内存管理通常要求 **显式地分配和管理 VRAM 资源** 。

GPU 资源包含多个组成部分，包括 **计算单元、内存带宽和显存容量** ，在评估 GPU 利用率与共享策略时必须综合考量。

[图片可在规范 HTML 页面中查看: 显存（VRAM）](https://zsvirt.io/zh/blog/how-to-efficiently-share-gpu-resources/)

#### 1.1.3 GPU 硬件与调度机制

GPU 上下文切换 **远比 CPU 上下文切换复杂且资源开销更大** 。GPU 通常需要先完成正在执行的内核（GPU 执行任务）才能切换工作负载，而保存和恢复执行状态还会带来额外的开销。

GPU 资源通常可以从两个主要维度进行评估：

*   **计算能力（如 SM 可用性和处理吞吐量）**

*   **内存能力（包括显存分配和带宽可用性）**

[图片可在规范 HTML 页面中查看: 传统上下文切换](https://zsvirt.io/zh/blog/how-to-efficiently-share-gpu-resources/)

在实际 AI 工作负载中，优化 GPU 利用率需要在计算效率与内存消耗之间取得平衡。

## 1.2 为什么 GPU 共享技术不如 CPU 虚拟化成熟

### 1.2.1 成熟的 CPU 虚拟化与强大的硬件支持

CPU 虚拟化技术（包括 KVM、Xen 和 VMware 虚拟化方案）已发展了数十年。现代 CPU 通过 **Intel VT-x 和 AMD-V** 等技术提供了强大的硬件虚拟化支持，能够实现高效的资源隔离与分配。

此外，CPU 架构还得益于 **硬件厂商与虚拟化软件厂商之间的深度协作** ，形成了成熟且标准化的生态系统。

### 1.2.2 高并行度与昂贵的 GPU 上下文切换

由于 GPU 架构高度并行，实现高效的资源共享需要同时管理 **并发工作负载、显存竞争、调度复杂性以及与专有 GPU 驱动程序的兼容性** 。

与 CPU 可在指令集层面抽象硬件资源的虚拟化方式不同，GPU 拥有成千上万个并行执行单元和专用计算流水线，实现完整的硬件级虚拟化要困难得多。

**因此，GPU 资源共享技术持续通过硬件分区、基于软件的虚拟化以及工作负载级调度等不同途径演进。**

### 1.2.3 工作负载需求的差异

CPU 通常在大规模虚拟机和容器环境中被广泛共享，此类工作负载更看重 **资源可用性、隔离性和整体效率** 。

相比之下，AI 工作负载（包括模型训练与推理）往往更看重 **最大计算吞吐量、低延迟和可预测的性能** 。GPU 虚拟化会引入额外的调度开销和资源竞争问题，可能影响服务质量（QoS）要求。

### 1.2.4 不同 GPU 厂商生态之间的差异

CPU 市场相对集中，Intel 和 AMD 的 x86 架构主导了全球企业环境，同时还有 ARM 等新兴指令集架构。

而 GPU 生态则碎片化严重，涉及多种技术栈，包括 **CUDA、CUDA 兼容平台、ROCm，以及 CANN 等专有加速生态** 。

这种多样性给实现统一的 GPU 虚拟化标准和跨平台兼容性带来了额外挑战。

**总而言之，硬件架构、工作负载特性以及生态成熟度的差异，解释了为什么 GPU 共享技术与 CPU 虚拟化相比仍不够标准化和成熟。**

## 二、常见 GPU 共享方式的优缺点与适用场景

GPU 资源共享方式大致可归为几类主要技术。 **虽然各厂商和各平台的实现可能有所不同，但底层原理通常归属于以下类别：**

*   **vGPU（虚拟 GPU）：基于硬件或软件的 GPU 虚拟化方案，包括 NVIDIA vGPU、AMD MxGPU，以及 cGPU/qGPU 等开源方案。**

*   **MPS（多进程服务）：NVIDIA 提供的进程级 GPU 共享机制，使多个工作负载能够共享 GPU 执行资源。**

*   **MIG（多实例 GPU）：NVIDIA Ampere 及后续架构引入的硬件级 GPU 分区技术。**

*   **CUDA Hook：基于软件的 API 拦截方法，可在应用层实现动态 GPU 资源管理。**

*   **远程调用（如 rCUDA）：一种通过网络让远程应用利用 GPU 资源的访问方式。**

## 常见 GPU 共享技术对比

不同的 GPU 共享方式在隔离性、灵活性、性能和部署复杂度方面各有差异。企业应根据工作负载特性、基础设施需求和运营目标选择合适的技术。

| 技术 | 资源隔离 | 灵活性 | 性能效率 | 最适合的场景 |
| --- | --- | --- | --- | --- |
| **vGPU** | **通过虚拟 GPU 抽象实现高隔离** | **高灵活性，可配置 GPU 配置档** | **性能良好，存在虚拟化开销** | **虚拟桌面、云平台、多租户 GPU 环境及基于虚拟机的 AI 工作负载** |
| **MPS** | **隔离有限，工作负载共享同一 GPU 上下文** | **进程级共享，灵活性中等** | **并发小型工作负载效率高** | **多进程推理、工作负载整合和 GPU 吞吐优化** |
| **MIG** | **极高的硬件级隔离** | **受预定义 GPU 配置档限制，灵活性有限** | **受支持配置下接近原生性能** | **企业 AI 云、多租户环境及要求严格隔离的工作负载** |
| **CUDA Hook** | **软件级隔离，依赖具体实现** | **定制灵活性非常高** | **取决于拦截策略，可能产生开销** | **自定义 GPU 调度、开发环境和内部资源管理场景** |
| **远程调用（rCUDA 等）** | **取决于网络架构与实现** | **分布式节点间部署灵活度高** | **受网络延迟和带宽约束限制** | **对延迟要求宽松的特定分布式加速场景** |

**总体而言，MIG 和官方 vGPU 等硬件方案能提供更强的隔离性和企业级可靠性，而 MPS、CUDA Hook 等软件方案则在工作负载优化方面提供更大的灵活性。**

对于现代 AI 环境，最佳策略通常是将 **GPU 虚拟化技术与工作负载级调度和分布式计算框架相结合。**

## 2.1 vGPU

### 基本原理

vGPU 技术 **通过硬件辅助、内核级或用户空间的虚拟化机制，将一块物理 GPU 划分为多个虚拟 GPU 实例。**

NVIDIA vGPU 和 AMD MxGPU 等方案提供 **官方的软硬件支持** ，而 KVMGT（Intel GVT-g）、cGPU、qGPU 等开源实现则提供了 GPU 资源共享的替代途径。

[图片可在规范 HTML 页面中查看: 基于 vGPU 的虚拟化](https://zsvirt.io/zh/blog/how-to-efficiently-share-gpu-resources/)

### 优势

*   **灵活分配 GPU 计算资源和显存，使多台虚拟机或容器共享一块物理 GPU。**

*   **获得主流硬件厂商的强生态支持，包括成熟的驱动管理、QoS 能力以及虚拟化兼容性。**

### 局限

*   NVIDIA vGPU 等部分官方方案 **主要面向虚拟机环境，可能需要商业授权，从而带来额外的部署成本。**

*   vCUDA、cGPU 等开源方案 **可能需要针对不同 CUDA 版本进行适配，且与厂商支持的方案相比，隔离性和安全性保证通常较弱。**

### 典型应用场景

*   需要 GPU 加速的 **虚拟桌面、远程工作站或云游戏环境。**

*   需要 **GPU 资源配额、工作负载隔离和利用率提升** 的多服务环境。

*   在 **隔离需求适中，同时需要兼顾灵活性、兼容性和成本** 的场景。

## 2.2 MPS（多进程服务）

### 基本原理

MPS（多进程服务）是 NVIDIA 提供的 **GPU 工作负载共享机制，面向 Volta 及之后的 GPU 架构** 。

多个进程作为 MPS 客户端通过 MPS 守护进程提交工作负载，该进程 **将执行请求合并到一个统一的 GPU 上下文中，从而实现更高效的资源调度。**

[图片可在规范 HTML 页面中查看: MPS](https://zsvirt.io/zh/blog/how-to-efficiently-share-gpu-resources/)

### 优势

*   **提升 GPU 利用率与性能效率：**
    多个工作负载可以在细粒度层面并发执行，减少频繁的 CUDA 上下文切换开销。这使得 MPS 适用于 **小规模推理工作负载和多进程训练场景。**

*   **强大的 CUDA 生态兼容性：**
    MPS 依赖 NVIDIA 官方驱动，能够 **与现有 CUDA 应用和框架实现更好的兼容。**

### 局限

*   **故障隔离有限：**
    由于多个进程共享同一个执行上下文，MPS 环境内的故障可能影响同一块 GPU 上运行的其他工作负载。

*   **无硬件级显存隔离：**
    需要额外的调度和资源管理机制，以防止内存过度消耗影响其他进程。

### 典型应用场景

*   涉及多个小型 AI 工作负载的 **高吞吐推理场景。**

*   需要在 **可接受的性能前提下，将多个 GPU 任务高效整合到单个加速器上** 的环境。

## 2.3 MIG（多实例 GPU）

### 基本原理

MIG（多实例 GPU）是 **NVIDIA Ampere 架构（包括 A100 和 H100 GPU）引入的硬件级 GPU 分区技术。**

MIG 通过划分 **GPU 计算资源、内存资源和缓存结构** ，将一块 GPU 分割为多个相互隔离的 GPU 实例。一块 A100 GPU 最多可划分为 **七个独立的 GPU 实例** ，每个实例拥有专用的硬件资源。

[图片可在规范 HTML 页面中查看: A100 MIG 支持的配置文件](https://zsvirt.io/zh/blog/how-to-efficiently-share-gpu-resources/)

### 优势

*   **强大的硬件级隔离：**
    计算资源、内存带宽和显存在实例之间相互隔离，可防止工作负载相互干扰并提升可靠性。

*   **无需额外的软件 API 拦截或外部授权：**
    MIG 功能直接集成在受支持的 NVIDIA GPU 硬件中。

### 局限

*   **灵活性有限：**
    MIG 提供预定义的 GPU 配置档（如 1g.5gb、2g.10gb、3g.20gb），资源分配的粒度相对固定。

*   **硬件支持范围有限：**
    MIG 仅适用于特定 NVIDIA GPU 代际，包括 A100、H100、A30 和 A16 平台。

### 典型应用场景

*   需要 **具备强隔离保证的多租户 GPU 工作负载** 的高性能计算和云环境。

*   共享高端 GPU 服务器、多个用户需要 **在无工作负载干扰的情况下获得专属 GPU 计算资源** 的组织。

## 2.4 CUDA Hook（API 拦截）

### 基本原理

CUDA Hook 是一种基于软件的方法， **通过拦截 CUDA 运行时或驱动 API 调用来监控和管理 GPU 资源的使用。**

通过捕获显存分配和内核提交等操作，CUDA Hook 可以在用户空间实现 **资源配额、工作负载调度、使用监控以及动态 GPU 分配策略。**

[图片可在规范 HTML 页面中查看: CUDA Hook 应用场景](https://zsvirt.io/zh/blog/how-to-efficiently-share-gpu-resources/)

### 优势

*   **实现复杂度较低：**
    CUDA Hook 不需要大幅修改内核或依赖专用硬件虚拟化支持，可以在更广泛的现有 GPU 平台上部署。

*   **灵活的资源管理：**
    支持自定义 GPU 调度策略，包括工作负载限流、使用监控和资源配额管理。

### 局限

*   **可能存在性能开销：**
    由于 GPU 操作会经过额外的拦截层，实现不当可能引入调度延迟或执行开销。

*   **不适合大规模训练工作负载：**
    在密集型分布式 AI 训练场景中，频繁的 API 拦截和监控可能降低效率。

### 典型应用场景

*   需要 **面向开发、测试和小规模 AI 工作负载进行灵活 GPU 共享** 的内部企业环境。

*   需要 **在无需专用硬件支持的情况下快速进行 GPU 资源分区** 的场景。

## 2.5 远程调用（如 rCUDA）

### 概念

rCUDA、VGL 等远程调用技术提供 **GPU API 远程能力** ，允许在无 GPU 节点上运行的应用通过网络通信将 GPU 操作发送到远程 GPU 服务器。

这种方式实现了 **分布式环境下的 GPU 资源池化。**

[图片可在规范 HTML 页面中查看: 远程调用](https://zsvirt.io/zh/blog/how-to-efficiently-share-gpu-resources/)

### 优势

*   为 **未在本地安装 GPU 的计算节点** 提供 GPU 加速能力。

*   为 **跨多台服务器的集中式 GPU 资源共享** 提供了一种可行的思路。

### 局限

*   **网络带宽和延迟成为主要的性能瓶颈** ，尤其对于高吞吐 AI 工作负载。

*   **额外的数据序列化、传输和执行转换开销** 可能会显著降低对延迟敏感场景的效率。

[图片可在规范 HTML 页面中查看: 网络与 CPU、GPU 的带宽对比](https://zsvirt.io/zh/blog/how-to-efficiently-share-gpu-resources/)

### 典型应用场景

*   涉及 **小规模、对延迟容忍度高的工作负载** 的分布式环境。

*   GPU 需求有限的场景，如轻量级推理或偶发性的加速任务。

对于大规模 AI 训练和实时推理工作负载，通常 **不建议采用远程调用，因其存在性能局限。**

## 三、模型级"共享"与 GPU 切片

随着 **Qwen、Llama 和 DeepSeek** 等大语言模型（LLM）的快速发展，模型规模、参数数量和显存需求持续增长。单块 GPU、甚至单台服务器往往无法为大规模训练和推理工作负载提供足够的内存容量或计算资源。

因此，AI 基础设施已向 **模型级资源分布方式** 演进，包括：

*   张量并行

*   流水线并行

*   专家并行

*   零冗余优化器（ZeRO）

*   分布式训练框架中的高级显存优化技术

*   面向多用户推理工作负载的 GPU 分区

在部署大规模 AI 模型时，工作负载通常分布在多块 GPU 或多台服务器上，以利用 **聚合的内存容量和计算能力** 。

在这种场景下，模型并行成为一种更高层次的 **GPU 资源协同方式** ，由分布式框架将多个加速器作为一个统一的计算系统来管理。

[图片可在规范 HTML 页面中查看: 张量并行](https://zsvirt.io/zh/blog/how-to-efficiently-share-gpu-resources/)

与 vGPU、MIG、MPS 等传统 GPU 切片方法相比：

*   **大型 AI 模型往往需要聚合多块 GPU，而不是对单块 GPU 进行分区。**

*   **当显存容量不足时，将一块 GPU 划分为更小的实例并不能解决根本性的内存瓶颈。**

*   在混合专家（MoE）架构中，最大化吞吐量更多地取决于 **高效的工作负载路由、GPU 调度和高性能互联技术** ，而不是简单地划分 GPU 资源。

[图片可在规范 HTML 页面中查看: 专家并行在混合专家模型中的应用](https://zsvirt.io/zh/blog/how-to-efficiently-share-gpu-resources/)

### 3.1 何时使用模型并行 vs GPU 虚拟化

#### 3.1.1 超大模型场景

当单块 GPU 无法为模型提供足够的显存容量时，企业必须采用 **多 GPU 或多节点分布式计算策略** 。

在这些场景中，GPU 切片的意义不大，因为目标不是将一块 GPU 划分给多个工作负载，而是 **组合多块 GPU 以支持更大模型的运行。**

#### 3.1.2 成熟的 AI 训练与推理应用

对于生产级的 LLM 训练和推理环境， **分布式执行框架、多 GPU 调度和批处理优化策略通常已经成熟。**

在此类场景中，引入额外的 GPU 虚拟化层可能增加运营复杂度并带来性能开销。

因此，企业往往优先采用：

*   **直接 GPU 访问**

*   **分布式并行执行**

*   **优化的 GPU 通信框架**

*   **高性能 GPU 互联技术**

以实现最大的吞吐量和效率。

#### 3.1.3 小型模型与开发/测试环境

对于开发、测试、小型模型推理或低批处理工作负载，GPU 虚拟化和共享技术可以显著提升利用率。

例如，一块高端 GPU 在运行以下负载时，可能只消耗其可用计算能力或显存的一小部分：

*   嵌入模型

*   重排序模型

*   轻量级推理服务

*   开发工作负载

在这些情况下， **MIG、vGPU、MPS 或 CUDA Hook** 等 GPU 分区方法可以通过让多个工作负载共享单个加速器来提升资源效率。

### 3.2 企业是否应使用远程调用？

远程调用技术可以支持特定的分布式 GPU 共享场景，但通常不适用于 **对延迟敏感的 AI 工作负载，例如大规模推理和模型训练。**

在生产环境中，企业通常更倾向于 **直接 GPU 访问或基于硬件/软件的 GPU 分区方法** ，以最大限度地降低通信开销并保持性能可预测。

网络传输延迟、序列化开销和额外的处理层会显著影响：

*   推理延迟

*   训练效率

*   整体吞吐量

因此，远程 GPU 调用通常仅在 **性能要求宽松且网络环境优化的特定场景** 下被推荐。

## 四、通用建议与结论

### 4.1 大型模型与高性能 AI 应用

对于单块 GPU 显存容量不足的大规模 AI 模型，企业应优先采用 **模型级分布式计算方法** ，包括：

*   张量并行

*   流水线并行

*   专家并行（MoE）

*   分布式训练优化框架

这些方法在模型层面聚合多块 GPU 资源，能够实现更高性能，同时避免物理 GPU 分区带来的不必要开销。

除非部署在具备超低延迟、高带宽网络的特定环境中，否则通常 **不建议在高性能 AI 工作负载中使用 rCUDA 等远程调用技术。**

### 4.2 小模型测试与低 GPU 利用率场景

对于资源需求适中的虚拟机和容器 AI 环境，GPU 虚拟化技术可以显著提升利用率。

推荐方案包括：

*   在 A100、H100 等受支持的 NVIDIA GPU 上， **使用 MIG 满足高隔离环境需求。**

*   当企业需要成熟的虚拟化支持和强大的生态兼容性时， **选择官方 vGPU 方案。**

*   **使用 MPS 提升多进程推理场景的吞吐量。**

*   **采用基于 CUDA Hook 的方案** 满足灵活的资源分配和自定义 GPU 调度需求。

组织在选择 GPU 共享策略前，应仔细评估：

*   工作负载隔离需求

*   性能预期

*   授权成本

*   硬件兼容性

*   运营复杂度

### 4.3 不建议在大规模 GPU 共享中使用远程调用

通过 API 远程化进行 GPU 虚拟化会引入额外的网络通信开销和执行延迟。

虽然它可能适用于有限的分布式加速场景，但通常不适合：

*   大规模 AI 训练

*   实时推理服务

*   高吞吐生产工作负载

对于这些环境，直接 GPU 访问或经过优化的 GPU 分区方式能提供更好的性能和可靠性。

## 现代 AI 基础设施中的 GPU 资源管理

随着企业加速 AI 应用落地，高效的 GPU 资源管理已成为构建可扩展 AI 基础设施的关键能力。

除了单独的 GPU 共享技术之外，组织越来越需要一个统一的基础设施平台来管理：

*   **异构 GPU 资源**

*   **跨虚拟机和容器的 AI 工作负载**

*   **动态资源分配与调度**

*   **高性能计算环境**

*   **多租户 AI 服务交付**

一个现代 AI 基础设施平台不仅应提供 GPU 虚拟化能力，还应具备 **全面的资源编排、监控和生命周期管理能力。**

ZSvirt 和 ZStack 云基础设施生态旨在帮助企业构建灵活的 AI 就绪环境，其能力包括：

*   **计算、存储和网络资源的统一管理**

*   **与 GPU 加速工作负载的灵活集成**

*   **不同应用场景间的高效资源分配**

*   **面向企业 AI 基础设施的简化运维管理**

通过将 GPU 资源优化与云基础设施管理能力相结合，企业可以在保持可扩展性、可靠性和运营效率的同时，最大化加速器利用率。

## 五、总结

GPU 的架构特性决定了 GPU 共享比传统 CPU 虚拟化更为复杂。 **高度并行的执行模型、昂贵的上下文切换、显存管理以及碎片化的厂商生态** 等挑战，持续影响着 GPU 虚拟化技术的发展。

不同的 GPU 共享方式服务于不同的应用需求：

**面向超大规模 AI 模型和生产级工作负载：**

当模型需要海量显存容量和分布式计算资源时，企业应依赖 **多 GPU 和多节点并行计算策略** ，例如张量并行、流水线并行和专家并行。

在这些场景中，目标不是划分单块 GPU，而是 **将多个加速器组合成一个统一的计算环境。**

**面向小型模型、测试环境和多用户 AI 服务：**

GPU 虚拟化和共享技术可以显著提升加速器利用率。

技术选型取决于具体需求：

*   **MIG 提供强大的硬件级隔离，但灵活性有限。**

*   **官方 vGPU 方案提供成熟的虚拟化能力和更广泛的企业支持。**

*   **MPS 提升工作负载的并发性和吞吐量，但隔离性有限。**

*   **CUDA Hook 提供灵活的资源管理，但定制需求更高。**

**面向远程调用技术：**

API 远程化可以支持特定的分布式 GPU 访问场景，但由于网络开销和延迟限制，通常不适合性能敏感的 AI 工作负载。

最终，随着 AI 工作负载的持续演进，最优的 GPU 资源策略取决于工作负载特性、性能要求和运营目标。

对于大规模 LLM， **分布式模型并行仍是最大化 GPU 效率的首选方式。**

对于较小的 AI 工作负载和共享开发环境， **GPU 虚拟化和资源分区是提升利用率、最大化基础设施效率的有效方法。**

**通过选择合适的 GPU 共享策略，企业可以实现更高的加速器利用率、优化基础设施投资，并构建更高效的 AI 计算环境。**

## 官方链接


- [规范 HTML 页面](https://zsvirt.io/zh/blog/how-to-efficiently-share-gpu-resources/)
- [在 GitHub 讨论](https://github.com/ZSvirt/zsvirt/discussions)