Kubernetes GPU 资源共享：MIG、vGPU 与时间片复用
整卡独占最简单，但未必最省钱。在生产环境中，需要根据业务场景选择合适的 GPU 资源共享方案。
三种 GPU 资源共享方式概述
MIG
MIG（Multi-Instance GPU）适用于 A100/H100 等支持硬件切分的卡型。优点是隔离性强、性能稳定、适合多租户。缺点是切分粒度固定、对模型大小和部署形态有约束。
vGPU / 虚拟化切分
适用于希望进一步提升资源密度的场景。优点是资源利用率更高、适合小模型、多租户。缺点是隔离和性能可预测性弱于 MIG、工程和商业复杂度更高。
时间片复用
适用于离线、批处理、弱实时任务。在线推理一般要谨慎，因为它容易放大尾延迟。
生产建议
- 大模型在线推理优先整卡或 MIG
- 中小模型、高密度多租户优先 MIG 或 vGPU
- 对尾延迟极敏感的场景避免激进共享
MIG 详解
什么是 MIG
MIG 是 NVIDIA A100 和 H100 GPU 上的硬件级 GPU 分区功能。它允许将一个物理 GPU 分割成多个隔离的、小型的 GPU 实例，每个实例都有独立的计算资源、显存和缓存。
MIG 的优势
硬件级隔离：MIG 提供真正的硬件级隔离，不同实例之间完全隔离，一个实例的负载不会影响其他实例。
性能可预测：由于是硬件级分区，每个 MIG 实例的性能是可预测的，适合对延迟敏感的应用。
服务质量保障：适合多租户场景，每个租户可以获得确定性的性能保障。
MIG 的配置
在 A100 上启用 MIG：
# 检查 MIG 状态
nvidia-smi -L
# 启用 MIG
sudo nvidia-smi -mig 1
# 查看可用的 MIG 配置
nvidia-smi mig -lgip在 Kubernetes 中使用 MIG：
apiVersion: v1
kind: Pod
metadata:
name: mig-pod
spec:
containers:
- name: gpu-container
image: nvidia/cuda:11.8.0-runtime-ubuntu22.04
resources:
limits:
nvidia.com/gpu: "1g.5gb" # 请求 1/2 A100 的 MIG 实例（5GB）
# 或使用其他 MIG 配置：
# nvidia.com/gpu: "1g.10gb" # 完整 1G 级别（10GB）
# nvidia.com/gpu: "2g.20gb" # 2G 级别（20GB）
# nvidia.com/gpu: "3g.40gb" # 3G 级别（40GB）
# nvidia.com/gpu: "7g.80gb" # 7G 级别（80GB）MIG 实例规格
A100 40GB 的 MIG 分区：
| MIG 规格 | 计算单元 | 显存 | 适合场景 |
|---|---|---|---|
| 1g.5gb | 14 | 5GB | 小模型、推理 |
| 2g.10gb | 28 | 10GB | 中等模型 |
| 3g.20gb | 42 | 20GB | 中大模型 |
| 4g.40gb | 56 | 40GB | 大模型 |
| 7g.80gb | 98 | 80GB | 超大模型 |
vGPU 详解
什么是 vGPU
vGPU 是通过软件层实现的 GPU 虚拟化，常见的方案包括 NVIDIA vGPU 软件、AMD MxGPU、Intel GPU 虚拟化等。与 MIG 不同，vGPU 可以更灵活地配置分区大小。
vGPU 的优势
更高的灵活性：可以灵活配置 vGPU 的大小，不受限于固定的 MIG 分区。
更高的密度：可以创建更多的虚拟 GPU 实例，适合高密度部署。
支持更多场景：支持桌面虚拟化、图形加速等 MIG 不擅长的场景。
vGPU 配置示例
apiVersion: v1
kind: Pod
metadata:
name: vgpu-pod
spec:
containers:
- name: gpu-container
image: nvidia/cuda:11.8.0-runtime-ubuntu22.04
resources:
limits:
nvidia.com/gpu: "2" # 请求 2 个 vGPUvGPU 与 MIG 的对比
| 特性 | MIG | vGPU |
|---|---|---|
| 隔离级别 | 硬件级 | 软件级 |
| 性能预测性 | 高 | 中 |
| 灵活性 | 低（固定分区） | 高 |
| 配置复杂度 | 低 | 高 |
| 支持卡型 | A100/H100 | 多卡型 |
时间片复用详解
什么是时间片复用
时间片复用是指多个任务在时间维度上共享同一个 GPU。通过快速切换执行任务，使多个任务看起来在同时运行。
时间片复用的适用场景
离线批处理：对延迟不敏感的批处理任务。
开发和测试环境：开发和测试时不需要独占 GPU。
低优先级任务：_background 任务、调度任务等。
时间片复用的配置
在 Kubernetes 中，时间片复用通常通过工作负载调度来实现：
apiVersion: batch/v1
kind: Job
metadata:
name: gpu-batch-job
spec:
template:
spec:
containers:
- name: gpu-job
image: nvidia/cuda:11.8.0-runtime-ubuntu22.04
command: ["python", "train.py"]
resources:
limits:
nvidia.com/gpu: "1"
restartPolicy: OnFailure实践建议
根据业务选择共享策略
| 业务类型 | 推荐策略 | 理由 |
|---|---|---|
| 大模型在线推理 | 整卡 | 延迟敏感，需要稳定性能 |
| 中小模型推理 | MIG | 成本敏感，需要隔离 |
| 多租户平台 | MIG 或 vGPU | 需要服务保障 |
| 离线训练 | 时间片 | 对延迟不敏感 |
| 开发测试 | 时间片 | 成本优先 |
混合使用策略
可以在同一个集群中混合使用多种策略：
# 在线服务节点池 - 整卡
nodePool: online-pool
instanceType: g5.xlarge # 1x A10G
# 推理服务节点池 - MIG
nodePool: inference-pool
instanceType: g5.2xlarge # 1/2 A10G
# 批处理节点池 - 时间片
nodePool: batch-pool
instanceType: g4dn.xlarge # 共享 GPU监控和告警
无论使用哪种共享策略，都需要监控：
- GPU 利用率
- 显存使用量
- 任务排队时间
- 延迟分布（P50/P95/P99）