关于GPU透传、MIG、vGPU等云环境GPU虚拟化与分配的理解验证

背景 #

我正尝试验证自己对OpenStack、Kubernetes、AWS、GCP及VMware等云/私有云环境中GPU分配与GPU虚拟化的理解，仅为掌握通用计算概念，不涉及代码开发。

当前理解梳理 #

• GPU透传并非将GPU通过网络远程挂载至任意虚拟机，而是虚拟机必须运行在装有该GPU的物理主机上，PCIe GPU设备被直接分配给该虚拟机；
• NVIDIA MIG并非远程GPU技术，它是在同一GPU主机内将A100/H100/H200等支持的物理GPU划分为固定配置；
• Kubernetes自身不拆分或迁移GPU，而是将Pod/Job调度至已通过NVIDIA设备插件或GPU Operator暴露GPU或MIG资源的节点；
• AWS/GCP的GPU实例或GPU加速虚拟机仍由装有GPU的物理主机提供支撑；
• VMware vGPU可在同一ESXi主机内将单块物理GPU共享给多台虚拟机，但需满足NVIDIA vGPU授权与支持要求；
• VMware Bitfusion更接近远程GPU模式，但已不再是新架构的主流选择。

基于此得出的核心结论：常规架构并非「仅CPU虚拟机 + 网络远程GPU」，而是将虚拟机/Pod/Job调度至具备GPU能力的主机或节点。

核心技术点确认 #

1. PCIe透传是否可理解为将同一物理主机上的GPU直接分配给虚拟机？
   完全正确。PCIe透传（PCI Passthrough）就是把物理主机本地的PCIe设备（包括GPU）直接映射给同一主机上的虚拟机，虚拟机获得对GPU的独占原生访问权限，无中间虚拟化层性能损耗，前提是虚拟机必须运行在装有该GPU的物理节点上。

2. MIG是否可理解为本地GPU分区，而非远程GPU挂载？
   正确。NVIDIA MIG（Multi-Instance GPU）是在单块支持的物理GPU（如A100/H100/H200）内部划分多个独立GPU实例，每个实例拥有专属显存、计算核心和带宽，所有操作均在本地物理主机内完成，和远程挂载无关。

3. Kubernetes是否仅负责将工作负载调度至具备GPU能力的节点，自身不拆分GPU？
   正确。Kubernetes本身不具备GPU拆分或虚拟化能力，它仅通过NVIDIA设备插件或GPU Operator感知节点上的GPU/MIG资源，将带有GPU资源请求的Pod/Job调度到对应节点；GPU的拆分（如MIG）由底层硬件和驱动完成，K8s只负责资源的调度与分配管理。

4. GCP的「为虚拟机添加GPU加速器」是否本质上仍是将虚拟机调度至具备GPU能力的物理主机？
   正确。GCP的GPU加速虚拟机并非远程挂载GPU，当你为VM添加GPU时，平台会自动将该VM调度到装有对应型号GPU的物理主机上，VM与GPU处于同一物理节点，GPU资源由本地硬件直接支撑。

GPUaaS平台可行实现路径分析 #

全新GPUaaS平台的可行实现路径确实应优先选择以下方案，而非尝试将GPU通过网络远程挂载至已有的仅CPU虚拟机：

• 基于PCIe透传的GPU虚拟机服务：提供原生性能的独占GPU实例，适合对计算性能要求极高的场景；
• 基于Kubernetes的GPU工作节点池：借助K8s成熟的调度能力管理GPU节点，快速分配Pod级别的GPU资源；
• 基于MIG/vGPU的分区方案：通过硬件级（MIG）或虚拟化级（vGPU）的GPU分区，提升GPU资源利用率，支持多租户共享单块GPU。

远程GPU挂载方案（如VMware Bitfusion）因网络延迟、带宽瓶颈、性能损耗等问题，目前并非主流选择，仅适用于特定轻量计算场景，不适合作为GPUaaS的核心架构。

内容的提问来源于stack exchange，提问作者Kyun