服务器GPU算力池化调度方案与虚拟化实践

GPU算力池化要解决什么问题

在AI训练和推理场景中，GPU资源的利用不均衡是普遍现象：部分任务占满整卡但利用率不足30%，另一些小批量推理任务只需要几张卡的少量算力却被迫独占整卡。GPU算力池化就是将物理GPU的资源（显存、计算核心）切分或聚合，按需分配给不同工作负载，提高整体利用率的同时降低闲置成本。

当前主流的GPU虚拟化技术分三个层级：时间分片（MPS、TGS）、空间分割（MIG、vGPU）、远程池化（PCIe over Fabric）。时间分片最轻量但隔离性差，空间分割提供硬件级隔离但灵活性有限，远程池化最灵活但引入网络延迟。生产环境的选择需要根据业务SLA和成本预算综合决策。

NVIDIA MIG分区配置实战

MIG（Multi-Instance GPU）是NVIDIA从Ampere架构开始支持的硬件级GPU分区方案，适用于A100/A30/H100等数据中心GPU。MIG将单张GPU在硬件层面切分为多个独立实例，每个实例拥有独立的显存和SM计算单元，提供完全的错误隔离和QoS保障。

以A100 80GB为例的分区配置命令：

# 查看当前MIG配置
nvidia-smi -i 0 --query-gpu=mig.mode.current --format=csv

# 启用MIG模式（需要重启GPU）
sudo nvidia-smi -i 0 --mig-config=1

# 创建MIG分区（1g.40gb表示1个SM组+40GB显存）
sudo nvidia-smi mig -cgi 1g.40gb,1g.40gb,1g.40gb,1g.40gb,1g.40gb,1g.40gb,1g.40gb -C

# 查看已创建的MIG实例
nvidia-smi -i 0 --query-gpu=mig.device.count --format=csv

# 删除MIG分区恢复完整GPU
sudo nvidia-smi mig -dgi 1,2,3,4,5,6,7 -C

MIG分区的调度需要配合容器运行时。Kubernetes环境下使用NVIDIA Device Plugin的MIG策略配置：

apiVersion: v1
kind: ConfigMap
metadata:
  name: nvidia-device-plugin-config
data:
  config.yaml: |
    version: v1
    flags:
      migStrategy: mixed
    resource:
      name: nvidia.com/mig-1g.40gb
      count: 7

Pod申请MIG资源时直接指定切分规格：

resources:
  limits:
    nvidia.com/mig-1g.40gb: 1

远程GPU池化方案架构

当GPU资源分布在不同物理节点时，需要通过网络将GPU能力暴露给远程计算节点。两种主流技术路线：

– PCIe over Fabric：通过RDMA网络将远程GPU的PCIe地址空间映射到本地，对应用层完全透明。代表方案有Liquid Composable Infrastructure和Bitfusion。延迟在10-20us级别，适合对延迟不敏感的离线训练场景。

– API层池化：拦截CUDA Runtime API调用，通过网络转发到远程GPU节点执行。代表方案有VGPU、趋动科技OrionX。延迟在100-500us级别，兼容性好但性能损耗明显。

生产环境的建议是：训练任务优先使用本地GPU直通或MIG分区，推理服务可以接受远程池化带来的额外延迟，通过批处理和请求队列掩盖网络开销。

GPU资源调度策略设计

在Kubernetes中调度GPU资源，需要考虑以下几个维度的策略：

Bin-Packing优先策略：优先将任务调度到已分配部分GPU的节点，减少GPU碎片。通过自定义Scheduler Extender或使用Volcano调度器实现。

GPU拓扑亲和：多卡训练任务需要分配同一节点上的GPU以避免跨节点通信开销。使用nodeSelector配合标签实现拓扑亲和调度。

优先级抢占：推理任务（高优先级、短时间）可以抢占低优先级训练任务的GPU资源。被抢占的训练任务checkpoint后进入待调度队列。

apiVersion: scheduling.volcano.sh/v1beta1
kind: Queue
metadata:
  name: inference-queue
spec:
  reclaimable: true
  weight: 3
  capability:
    nvidia.com/gpu: 16
  priority: 100
---
apiVersion: scheduling.volcano.sh/v1beta1
kind: Queue
metadata:
  name: training-queue
spec:
  reclaimable: true
  weight: 1
  capability:
    nvidia.com/gpu: 32
  priority: 50

显存管理与共享机制

推理场景下，模型权重加载后显存大量空闲，多个推理服务可以共享同一张GPU的显存。关键机制：

– Tensor并行共享：多个推理副本共享同一组模型权重，仅副本各自的KV-Cache占用额外显存。Triton Inference Server原生支持此模式。

– 统一内存管理：使用CUDA Managed Memory让驱动自动在GPU和CPU内存之间迁移数据页，适合显存溢出场景的兜底方案，但性能不可控。

– 显存超卖：Kubernetes层面允许节点GPU显存超卖（overcommit），配合监控告警在显存使用率超过阈值时触发Pod驱逐。超卖比例建议控制在1.2-1.5倍之间。

监控与容量规划

GPU集群的容量规划需要同时关注计算利用率和显存利用率两个维度。常见误区是只看GPU计算利用率，忽略了显存占用和PCIe带宽瓶颈。

关键监控指标：

– DCGM指标集：通过NVIDIA DCGM Exporter暴露GPU的温度、功耗、SM利用率、显存使用率、PCIe带宽等指标

– 业务层指标：每个推理服务的请求QPS、P99延迟、队列积压深度

– 调度层指标：Pending Pod数量、调度延迟、GPU碎片率

容量规划的经验公式：单节点有效GPU利用率目标70%，预留30%缓冲应对突发流量和故障恢复。按业务QPS峰值计算所需GPU数量，再加上20%的冗余用于滚动更新。