我一直负责公司内部AI研发部门的基础架构建设，随着模型训练任务的激增，传统的裸机GPU服务器已无法满足多个团队并发、高效使用资源的需求。我们面临的核心问题是如何将原本静态的GPU服务器资源，转化为灵活可调度的云服务，供多个团队协同、独立使用。于是，我着手把现有的GPU服务器集群虚拟化，实现GPU资源池化与按需调度，构建出一套内部GPU云平台。
这篇教程记录了我从0到1搭建GPU云服务器的整个过程，包括硬件选型、虚拟化平台部署、GPU虚拟化技术选型、网络与存储架构、调度系统部署，以及资源隔离与管理策略。它并不是一份泛泛而谈的方案描述，而是一次贴近实际、可落地的实操总结。
一、GPU服务器集群硬件配置
首先，从硬件入手。我们使用的是基于英伟达A100 GPU的高性能计算服务器，具体型号为 浪潮 NF5488A5，这是目前广泛部署在AI训练场景中的主力产品。
单节点服务器规格如下：
- CPU：2 × AMD EPYC 7742（64核，2.25GHz）
- 内存：1TB DDR4 ECC
- GPU：8 × NVIDIA A100 40GB PCIe
- 硬盘：2 × 1.92TB NVMe SSD（系统盘） + 4 × 7.68TB U.2 NVMe SSD（数据盘）
- 网络：2 × 100Gbps Mellanox InfiniBand HDR + 2 × 25GbE
- 电源冗余：2 × 3000W 80Plus Platinum
- BMC远程管理：支持IPMI
集群规模为20台，总计160块GPU，总算力为6.4 PFLOPS（FP16）。
二、虚拟化技术选型与架构设计
为了实现GPU的资源池化和弹性调度，虚拟化是核心能力。我们对比了几种GPU虚拟化技术及平台，最终确定采用Kubernetes + NVIDIA GPU Operator + MIG（Multi-Instance GPU）技术组合部署。
2.1 技术方案构成
- 虚拟化：平台 Kubernetes 1.27
- 容器运行时： containerd
- GPU调度插件： NVIDIA GPU Operator
- GPU虚拟化： MIG（A100支持）
- 存储系统： Ceph RBD（块存储）
- 网络插件： Calico + SR-IOV
- 资源调度层： KubeScheduler + Volcano
- 用户门户： Rancher + 自研Dashboard
2.2 关键架构要点
- GPU资源虚拟化方式：通过MIG划分单卡为多个实例（如1张A100划分为7个GPU实例，每实例拥有独立的Tensor Core和内存）。
- 容器调度集成：每个容器Pod通过CUDA_VISIBLE_DEVICES绑定MIG实例，具备准裸机性能。
- 存储持久化：训练数据、模型权重通过Ceph块存储绑定PVC挂载，确保任务跨节点迁移时状态不丢失。
- 网络隔离：Pod通过SR-IOV直接访问物理网卡，避免虚拟化IO瓶颈，同时通过Calico实现VPC级隔离。
三、部署过程实操细节
3.1 操作系统与基本环境
我们在所有节点部署 Ubuntu Server 22.04 LTS，配置统一的基础环境。
# 安装 containerd
sudo apt update && sudo apt install -y containerd
# 安装Kubernetes相关组件
apt install -y kubelet kubeadm kubectl
3.2 安装NVIDIA驱动与CUDA工具链
# 安装NVIDIA驱动（以A100为例）
sudo apt install -y nvidia-driver-525
# 验证安装
nvidia-smi
3.3 开启MIG功能（每张卡按需划分）
nvidia-smi -i 0 -mig 1
nvidia-smi mig -cgi 0,1,2,3,4,5,6 -C
3.4 部署GPU Operator
kubectl create namespace gpu-operator
helm repo add nvidia https://nvidia.github.io/gpu-operator
helm install gpu-operator nvidia/gpu-operator -n gpu-operator
GPU Operator会自动部署如下组件：
- NVIDIA驱动
- DCGM监控插件
- Device Plugin（用于Pod调度GPU）
- MIG Manager
3.5 存储与网络部署
Ceph块存储使用Rook Operator自动部署。
SR-IOV插件配置方式如下：
kubectl apply -f sriov-network-operator.yaml
需要配合主板BIOS中开启IOMMU及SR-IOV。
四、资源调度与隔离策略
为实现按需分配GPU资源，我们在Kubernetes中做了如下资源定义：
resources:
limits:
nvidia.com/mig-1g.5gb: 1
每类MIG实例被注册为独立资源，便于调度器精确分配。配合Volcano调度器进行队列式资源管理，实现资源共享与优先级控制。
此外，为防止资源争抢，每个Namespace配置了ResourceQuota限制GPU使用上限。
五、使用与运维实践
通过自研的Dashboard，研发团队可：
- 申请GPU资源（基于MIG类型）
- 提交训练任务或Notebook
- 查看GPU使用率和队列状况
- 挂载项目数据集与模型目录
运维关键指标：
- GPU利用率保持在 80% 左右（原来仅为40%-50%）
- 每张A100可支持6~7个中小模型训练任务并行
- 支持任务抢占、预留、限额与超额控制
将传统GPU服务器虚拟化成GPU云服务器的过程，既涉及底层硬件配置，也需要熟悉Kubernetes容器编排与GPU虚拟化技术。通过合理的MIG划分、调度系统设计与网络存储优化，我们最终实现了一套高效、可维护的GPU云平台。这不仅极大提升了算力资源的利用率，也让多个团队在同一集群中高效协作而互不干扰。
这套方案仍在不断优化，例如计划引入弹性计费系统、自助式任务模板库和混合云调度能力。希望本文能为正在探索GPU虚拟化实践的团队提供参考与启发。
