超融合架构中的GPU虚拟化技术：AI算力池化与资源调度详解
随着大模型训练、推理加速、计算机视觉等AI工作负载在企业业务中的渗透，GPU算力逐步从"科研资源"演变为"基础生产资料"。然而传统物理GPU使用模式存在利用率低、调度粗放、弹性不足等问题。超融合基础设施（HCI）与GPU虚拟化的结合，为企业提供了一条将AI算力"池化、按需分配、统一运营"的可行路径。本文从技术原理、池化方式、调度机制和工程落地四个维度，对超融合场景下的GPU虚拟化技术进行系统解析。
一、GPU虚拟化的技术本质
GPU虚拟化是指将物理GPU算力抽象为可供多个虚拟机或容器共享的逻辑资源，使GPU具备类似CPU、内存的弹性分配能力。当前主流的GPU虚拟化路径主要有三类：
1.1 PCIe直通（GPU Passthrough）
通过Intel VT-d或AMD-Vi技术，将整块GPU以PCIe直通模式映射给单一虚拟机。这种方式性能损耗通常在5%以内，但缺乏灵活切分能力，适合对性能极度敏感、租户较少的高性能计算场景。
1.2 vGPU（分片虚拟化）
以NVIDIA vGPU、Intel GVT-g、AMD MxGPU为代表，将单块GPU切分为多个vGPU实例，每个实例拥有独立的显存、CUDA核心配额。常见分片规格包括1Q/2Q/4Q/8Q等，适合VDI、轻量推理、教学实验等中低密度场景。
1.3 GPU池化（GPU Pooling）
通过软件层在物理GPU之上构建全局调度器，将GPU算力抽象为可按需申请、动态分配、回收复用的资源池。代表技术包括NVIDIA MIG、趋动科技OrionX、博云GPUOS，以及开源方案HAMI。这是与超融合理念契合度最高的一种方式。
二、超融合架构中的GPU资源池化设计
超融合将计算、存储、网络虚拟化融合于标准x86/ARM节点，并通过分布式存储提供高可用能力。在该体系下构建GPU池化的关键在于把异构算力纳入统一的资源编排层。
2.1 资源编排层架构
典型的超融合GPU池化架构包含四个层次：
| 层次 | 关键组件 | 主要职责 |
|---|---|---|
| 硬件层 | GPU服务器节点、NVLink/PCIe Switch、RDMA网卡 | 提供算力与高速互联 |
| 虚拟化层 | KVM / ELF / aSV、vGPU驱动、MIG驱动 | 切分与隔离GPU资源 |
| 调度层 | Kubernetes Device Plugin、Volcano、Yunikorn | 按策略调度 |
| 平台层 | AI训练平台、推理服务网关、计费与监控 | 面向用户提供服务 |
超融合厂商通常通过其云管理平台（如深信服aCMP、安超云ArcherOS平台、SmartX SMTX OS的管理面板）对接Kubernetes调度器，将GPU资源与CPU、内存、分布式存储统一纳管。
2.2 三种主流池化实现方案对比
| 维度 | MIG硬件切分 | vGPU时间片切分 | 软件池化（OrionX/HAMI） |
|---|---|---|---|
| 隔离方式 | 硬件物理隔离 | 显存硬隔离/算力时间共享 | 显存与算力软隔离 |
| 单卡实例数 | 最多7个 | 通常2-16个 | 可数十个 |
| 性能损耗 | <2% | 5%~15% | 3%~10% |
| 弹性伸缩 | 弱（需预定义） | 中 | 强 |
| 适用场景 | 推理、HPC | VDI、轻量推理 | 共享训练、研发测试 |
2.3 与分布式存储的协同
GPU池化必须匹配高吞吐、低延迟的数据供给链路。在超融合环境中，aSAN、ZBS等分布式存储通常采用NVMe缓存分层和多副本机制，可为训练提供数十GB/s级别的聚合带宽。配合RDMA（RoCE v2）网络，GPU节点间参数同步延迟可控制在几十微秒级，有效支撑多机多卡分布式训练。
三、AI算力池化的调度机制
3.1 调度粒度
GPU调度通常按以下粒度进行：
- 整卡粒度：独占使用，性能最优；
- MIG/分片粒度：固定规格切分；
- 算力百分比 + 显存GB的组合粒度：如 30% 算力 + 8GB 显存；
- 轻量级算子级：通过MPS（Multi-Process Service）在单卡内部实现多进程并发。
企业级GPU调度平台往往将这些粒度抽象成"配额模板"，供业务部门按需申请。
3.2 关键调度策略
- 拓扑感知调度：考虑NVLink域、NUMA亲和性、PCIe拓扑，将训练相关的GPU放置在同一高速互联域内，减少跨节点参数同步开销。
- 公平配额调度：通过DRF（Dominant Resource Fairness）等算法，在多个部门间保障算力配额。
- 抢占式调度：对离线训练任务实施优先级管理，高优先级在线推理可抢占离线任务GPU。
- 碎片整理：调度器周期性迁移小任务，释放出大块的整卡资源供大规模训练使用。
- 弹性伸缩：结合HPA/VPA动态调整推理副本GPU配额。
3.3 资源利用率观测指标
- GPU SM利用率（Streaming Multiprocessor）
- 显存占用率与带宽
- PCIe / NVLink吞吐
- 任务等待队列长度
- 算力池碎片率
通过这些指标构建完整的可观测性体系，运维团队才能持续优化调度策略。
四、工程落地中的关键挑战
4.1 异构硬件统一纳管
企业环境往往存在NVIDIA A系列/H系列、AMD MI、Atlas昇腾等多种GPU/NPU，池化平台需要分别对接各自的驱动层和工具链，并向上提供一致的申请接口。
4.2 算力与I/O协同
实践中容易陷入"GPU够用、I/O瓶颈"的窘境。建议参考以下经验值：
| 训练规模 | 单机GPU数 | 数据带宽需求 | 推荐存储介质 |
|---|---|---|---|
| 小规模微调 | 2-4卡 | 5-10 GB/s | NVMe SSD + RDMA |
| 中等规模预训练 | 8-32卡 | 30-80 GB/s | 全NVMe分布式存储 |
| 大规模训练 | >64卡 | >100 GB/s | 独立并行文件系统 |
4.3 业务连续性与多副本
AI训练通常跨越数日，GPU虚拟化的故障域需要重点控制。超融合的多副本机制可将训练检查点（Checkpoint）持久化到分布式存储，一旦节点故障，任务可在新节点续跑，避免长时间计算成果丢失。
4.4 计费与成本
GPU资源单价高，池化平台需配套细粒度计费能力（按算力核时、显存GB时），并与企业内部的CMDB、ITSM联动，实现成本可量化。
五、典型场景落地建议
5.1 研发测试场景
以软件池化（HAMI/OrionX类）为主，单卡切出数十个小规格实例，供算法工程师并行调参，强调高并发、低成本。
5.2 推理服务场景
推荐MIG + Kubernetes的软硬结合方案，保障推理延迟可控的同时提升GPU复用率。
5.3 大模型训练场景
整卡直通 + RDMA + 全NVMe分布式存储，并结合拓扑感知调度与检查点持久化，确保多机训练效率与稳定性。
5.4 与现有超融合的融合
如果企业已经部署深信服HCI、SmartX SMTX OS或安超云ArcherOS，可以选择"GPU节点池 + 现有节点池"混合部署：通用业务沿用CPU节点，AI业务部署GPU节点，通过同一管理平台统一纳管，避免建设孤岛型基础设施。
六、总结
GPU虚拟化与超融合架构的结合，本质上是通过"资源池化 + 软件定义 + 统一调度"将高昂且稀缺的AI算力转化为可管理、可复用、可演进的基础设施服务。技术上需要解决切分方式、调度策略、存储加速、可观测性四个层面的问题；工程上则需重点关注异构纳管、算力与I/O协同、故障域控制和精细化计费。对于正在构建企业AI基础设施的IT团队而言，从GPU池化这一抓手出发，结合既有的超融合能力纳入统一管理，是当前阶段较为稳妥的实施路线。
深圳市天维云网络科技有限公司
- 联系人：苟总
- 联系电话：13798559654
- sztwy.com
- 地址：深圳市
深信服11年金牌代理商 | SmartX核心合作伙伴 | 安超云核心合作伙伴 | 国家高新技术企业