开源GPU虚拟化栈：NVIDIA HGX B200多租户NVSwitch分区架构

随着大模型训练与推理需求的爆发式增长，NVIDIA HGX B200 平台凭借其强大的计算能力和高带宽互连架构，成为 AI 基础设施的核心组件。然而，HGX B200 的 SXM 模块设计和 NVLink/NVSwitch 互连架构，为多租户环境下的 GPU 虚拟化带来了前所未有的挑战。本文将深入解析 Ubicloud 开源云平台如何构建完整的 GPU 虚拟化栈，解决资源隔离、性能监控与调度优化等关键问题。

HGX B200 硬件架构与虚拟化挑战

NVIDIA HGX B200 平台采用 SXM 模块设计，与传统的 PCIe GPU 卡有本质区别。在 HGX 系统中，8 个 B200 GPU 通过 NVLink 高速互连，并由 NVSwitch 模块提供统一的 all-to-all 交换能力，形成一个紧密集成的多 GPU 计算单元。这种架构虽然提供了极高的 GPU 间通信带宽（可达 1.8TB/s），但也使得虚拟化变得异常复杂。

与离散的 PCIe GPU 不同，HGX B200 的 GPU 不能简单地作为独立的 PCIe 设备进行直通。整个 NVLink/NVSwitch 网络需要作为一个整体进行管理和分区，这要求虚拟化栈必须理解并正确处理 NVSwitch 的拓扑结构和路由逻辑。Ubicloud 团队在探索过程中发现，传统的 PCIe 直通方法在 HGX B200 上完全失效，必须重新设计整个虚拟化架构。

三种虚拟化模型对比分析

在 HGX B200 平台上，NVIDIA 提供了三种主要的虚拟化模型，每种模型都有其特定的适用场景和限制：

1. Full Passthrough Mode（全直通模式）

在这种模式下，虚拟机获得对分配 GPU 的直接访问权限。对于多 GPU 配置，虚拟机还需要接管相关的 NVSwitch 网络。在 8-GPU HGX B200 系统上，这导致两种极端配置：

• 单 8-GPU 虚拟机：获得所有 8 个 GPU 和整个 NVSwitch 网络的控制权
• 多个 1-GPU 虚拟机：每个 GPU 作为独立的 PCIe 设备直通，但完全失去 NVLink 连接能力

这种模式的灵活性极差，无法满足多租户环境中灵活的资源分配需求。

2. Shared NVSwitch Multitenancy Mode（共享 NVSwitch 多租户模式）

这是 Ubicloud 选择的解决方案。在该模式下，GPU 被分组到不同的分区中，每个分区形成一个独立的 NVSwitch"岛屿"。租户可以获得 1、2、4 或 8 个 GPU 的分配，分区内的 GPU 保持完整的 NVLink 带宽，而不同分区之间的 GPU 完全隔离，无法进行通信。

Fabric Manager 服务运行在主机端，负责管理 NVSwitch 拓扑、定义 GPU 分区并强制执行隔离策略。这种模式在灵活性和性能之间取得了最佳平衡。

3. vGPU-based Multitenancy Mode（vGPU 多租户模式）

vGPU 使用中介设备切片技术，允许多个虚拟机共享单个物理 GPU。GPU 的内存和计算资源被分区，但 NVLink/NVSwitch 网络不暴露给虚拟机。这种模式适用于轻量级计算工作负载，但不适合高性能的 AI 训练和推理场景。

Ubicloud 选择 Shared NVSwitch Multitenancy Mode 的主要原因是：它支持灵活的 GPU 分配（1/2/4/8 GPU），同时为每个租户提供完整的 GPU 内存容量和 NVLink 带宽，这对于大规模 AI 工作负载至关重要。

Shared NVSwitch Multitenancy 架构设计

Ubicloud 的 GPU 虚拟化栈采用分层架构设计，从底层硬件到上层管理平面，每一层都有明确的职责：

硬件抽象层

这一层负责处理 GPU 的 PCIe 设备抽象，即使 HGX B200 使用 SXM 模块，Linux 内核仍然将其暴露为 PCIe 设备。关键任务包括：

• 将 GPU 从主机 NVIDIA 驱动解绑并绑定到 vfio-pci 驱动
• 配置 IOMMU 支持，确保设备隔离
• 管理 PCI 拓扑，确保正确的设备层次结构

NVSwitch 管理层

Fabric Manager 作为核心组件运行在主机端，负责：

• 初始化 NVLink/NVSwitch 网络
• 定义和管理 GPU 分区
• 配置路由表，确保分区间的完全隔离
• 提供 API 供上层调度系统调用

虚拟机管理层

基于 QEMU/KVM 的虚拟化层，负责：

• 创建具有正确 PCI 拓扑的虚拟机
• 将 GPU 设备通过 VFIO 直通到虚拟机
• 管理虚拟机的生命周期
• 处理资源分配和回收

调度与编排层

Ubicloud 的控制平面负责：

• 接收用户的 GPU 资源请求
• 选择合适的分区进行分配
• 调用 Fabric Manager API 激活分区
• 启动配置好的 GPU 虚拟机
• 监控资源使用情况和健康状况

关键技术实现细节

PCI 拓扑陷阱与解决方案

在初始实现中，Ubicloud 团队使用 Cloud Hypervisor 进行 GPU 直通，虽然 nvidia-smi 在虚拟机内显示正常，但 CUDA 初始化始终失败。经过深入分析，发现问题根源在于 PCI 拓扑的不匹配。

在 HGX B200 系统上，GPU 位于多级 PCIe 桥接器之后：

-[0000:00]-+-[0000:14]---02.0-[15-1a]----00.0-[16-1a]----00.0-[17]----00.0 NVIDIA B200

而 Cloud Hypervisor 创建的虚拟机中，GPU 直接连接到根复合体：

-[0000:00]---04.0 NVIDIA B200

这种扁平化的拓扑结构导致 CUDA 初始化失败。解决方案是切换到 QEMU，并手动构建正确的 PCI 层次结构：

qemu-system-x86_64 \
  -device pcie-root-port,id=rp1 \
  -device vfio-pci,host=0000:17:00.0,bus=rp1

这样在虚拟机内，GPU 就位于根端口之后，恢复了正确的 PCI 拓扑，CUDA 初始化得以成功。

大 BAR 停滞问题与优化

B200 GPU 拥有巨大的 PCI Base Address Registers（BAR），特别是 Region 2 的 256GB BAR。当直通多个 GPU 时，QEMU 需要为每个 GPU 的 BAR 映射大量虚拟地址空间：

• 1 个 GPU：约 256GB 虚拟地址空间
• 8 个 GPU：约 2TB 虚拟地址空间

在 QEMU 8.2 及更早版本中，这种大规模映射会导致虚拟机启动停滞数分钟甚至数小时。Ubicloud 提供了两种解决方案：

1. 升级到 QEMU 10.1+：新版本包含了对大 BAR 设备的优化，显著减少了启动时间。

2. 禁用 BAR 内存映射：使用x-no-mmap=true参数：

-device vfio-pci,host=0000:17:00.0,bus=rp1,x-no-mmap=true

这种方法避免了直接映射 BAR，转而使用较慢的模拟访问路径。对于大多数 AI 工作负载，性能影响可以忽略不计，因为 BAR 访问不是性能关键路径。

Fabric Manager 分区管理

Fabric Manager 的配置位于/usr/share/nvidia/nvswitch/fabricmanager.cfg，关键设置是：

FABRIC_MODE=1  # 1表示Shared NVSwitch Multitenancy模式

HGX B200 系统预定义了 15 个分区，覆盖所有常见的 VM 大小：

分区 ID	GPU 数量	GPU ID
1	8	1-8
2	4	1-4
3	4	5-8
4-7	2	各种组合
8-15	1	1-8

重要提示：GPU ID 不是 PCI 总线地址，而是通过nvidia-smi -q命令查看的 Module ID。分区管理必须基于 Module ID 进行映射。

分区操作通过 fmpm 工具进行：

fmpm -l          # 列出所有分区
fmpm -a 3        # 激活分区3
fmpm -d 3        # 停用分区3

生产环境部署参数与监控要点

驱动版本一致性要求

在 Shared NVSwitch Multitenancy 模式下，主机和虚拟机的 NVIDIA 驱动版本必须严格匹配。Ubicloud 使用以下配置：

1. 主机配置：

apt install nvidia-fabricmanager nvlsm
dpkg -l nvidia-fabricmanager  # 确认版本，如580.95.05

2. 虚拟机镜像准备：

dpkg -l nvidia-open  # 必须与主机版本完全一致

B200 HGX 平台仅支持 nvidia-open 驱动变体，不支持传统的专有堆栈。

性能监控指标体系

在生产环境中，需要建立完整的监控体系：

1. NVLink 带宽监控：

nvidia-smi topo -m  # 查看NVLink拓扑和带宽
dcgmi dmon -e 1001,1002  # 监控NVLink流量

2. GPU 利用率监控：

• 计算利用率（GPU-Util）
• 内存利用率
• 温度和功耗
• ECC 错误计数

3. 分区隔离验证：

• 定期测试分区间的通信隔离
• 验证 NVSwitch 路由表的正确性
• 监控 Fabric Manager 服务状态

调度优化策略

Ubicloud 的调度器实现了以下优化策略：

1. 亲和性调度：将需要高带宽通信的工作负载调度到同一分区内的 GPU 上。

2. 碎片整理：定期重新组织分区分配，减少外部碎片。

3. 预测性扩容：基于历史使用模式预测资源需求，提前准备分区。

4. 故障转移：当 GPU 或 NVSwitch 组件故障时，自动迁移工作负载到健康分区。

开源价值与社区贡献

Ubicloud 的 GPU 虚拟化栈完全开源，为社区提供了宝贵的参考实现。与 AWS、Azure 等闭源云平台不同，Ubicloud 公开了所有技术细节，包括：

1. 完整的代码实现：GitHub 仓库中包含 GPU 分配、分区管理、虚拟机配置等所有组件。

2. 详细的文档：包括架构设计、配置指南、故障排除步骤。

3. 可复现的部署脚本：提供自动化部署脚本，用户可以在自己的硬件上复现整个环境。

这种开放性不仅降低了 AI 基础设施的门槛，还促进了技术的快速迭代和创新。社区可以基于 Ubicloud 的实现进行定制化开发，满足特定的业务需求。

结论

NVIDIA HGX B200 的 GPU 虚拟化是一个复杂的系统工程，涉及硬件架构、驱动栈、虚拟化技术和调度算法的深度整合。Ubicloud 通过 Shared NVSwitch Multitenancy 模式，成功构建了一个既灵活又高性能的多租户 GPU 虚拟化解决方案。

关键的技术突破包括：

• 正确理解并处理 HGX B200 的 PCI 拓扑要求
• 解决大 BAR 设备导致的启动性能问题
• 实现基于 Fabric Manager 的动态分区管理
• 确保驱动版本的一致性和兼容性

随着 AI 工作负载的不断演进，GPU 虚拟化技术将继续发展。未来的方向可能包括更细粒度的资源隔离、更智能的调度算法，以及对新兴互连技术（如 CXL）的支持。Ubicloud 的开源实现为这一演进提供了坚实的基础，推动了整个 AI 基础设施生态的发展。

资料来源：

1. Ubicloud 博客文章：Virtualizing NVidia HGX B200 GPUs with Open Source (2025-12-15)
2. NVIDIA Fabric Manager 用户指南 (2025-05-06)