MIG
MIG（Multi-Instance GPU，多实例 GPU）可以理解为 NVIDIA 在部分数据中心 GPU 上提供的一种硬件级 GPU 分区能力：一块物理 GPU 可以被切成多个彼此隔离的 GPU 实例，每个实例拥有相对独立的计算资源、显存资源以及部分引擎资源，可以被不同进程、容器、虚拟机或 Kubernetes 工作负载分别使用。它并不是简单地“限制显存”或者“多个进程共享同一块卡”，而是把 GPU 内部的一部分硬件资源真正划分出去，从而获得更稳定的性能隔离和资源利用率。MIG 从 NVIDIA Ampere 架构开始支持，目前支持的具体 GPU 型号需要以 NVIDIA 的 MIG 支持列表为准。(NVIDIA Docs)
1. 为什么需要 MIG
先考虑没有 MIG 的 GPU。
假设一张 A100 80GB：
Physical GPU
┌─────────────────────────────────────┐
│ │
│ A100 │
│ │
│ SM / Tensor Core │
│ │
│ 80 GB HBM │
│ │
│ L2 Cache │
│ │
│ Memory Controller │
│ │
└─────────────────────────────────────┘如果有一个很小的推理任务，只需要：
10 GB 显存
20% 左右算力但在 Kubernetes 中为其分配：
resources:
limits:
nvidia.com/gpu: 1传统 GPU 分配模式下，这个 Pod 往往会占用“一整张 GPU”这个调度资源。
于是：
A100 80GB
实际使用：
10GB
少量计算资源
剩下：
70GB + 大量 SM
无法方便地作为独立 GPU 资源分配给另一个 Pod这会造成昂贵 GPU 的资源浪费。
MIG 的目标就是解决这个问题。
2. MIG 本质上是在切什么
理解 MIG 最重要的地方不是命令，而是 NVIDIA GPU 内部到底被切成了什么。
前文已经建立 GPU 的简化结构：
GPU
│
├── SM
│ ├── CUDA Core
│ └── Tensor Core
│
├── L2 Cache
│
├── Memory Controller
│
├── HBM
│
├── Copy Engine
│
├── Video Engine
│
└── 其他硬件引擎MIG 会把其中一部分资源按照硬件边界进行划分，包括计算资源和显存子系统。NVIDIA 的定义里有几个非常重要的层次：Memory Slice、SM Slice、GPU Slice、GPU Instance 和 Compute Instance。 (NVIDIA Docs)
可逐一分析。
3. Memory Slice：显存切片
首先是显存系统。
不要把 GPU 显存想成简单的一条：
80 GB HBM真实硬件更接近：
HBM
┌────┬────┬────┬────┐
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
Memory Controller Groups
│
▼
L2 CacheMIG 会按照 GPU 硬件内部的 memory slice 进行划分。
一个 Memory Slice 不只是：
一部分显存容量。
它还包含对应的：
- Memory Controller
- 显存带宽资源
- 一部分 Cache
因此 MIG 提供的不是：
80GB HBM 中随便划 10GB而更像：
Memory Slice 0
├── HBM capacity
├── memory controller
└── cache
Memory Slice 1
├── HBM capacity
├── memory controller
└── cacheNVIDIA 当前 MIG 概念文档将 memory slice 定义为 GPU memory 的最小可分资源，其中包含对应的 memory controller 和 cache，并提供独立的显存容量和带宽资源。(NVIDIA Docs)
这也是 MIG 相比简单的软件显存限制更重要的地方。
4. SM Slice：计算资源切片
第二部分是计算资源。
GPU 的主要计算资源在：
SMStreaming Multiprocessor。
一个 SM 内部包含：
SM
├── CUDA Core
├── Tensor Core
├── Register
├── Shared Memory
└── SchedulerMIG 会把整个 GPU 的 SM 分成多个 SM Slice。
可以抽象成：
Physical GPU
SM SM SM SM SM SM SM
│ │ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼ ▼
S0 S1 S2 S3 S4 S5 S6NVIDIA 当前 MIG 概念里，一份 SM slice 大致对应 MIG 模式下 GPU 可用 SM 的约七分之一，不过具体物理资源比例会依 GPU 产品和 profile 而变化。(NVIDIA Docs)
因此当一个 MIG instance 获得：
1g它实际上就获得了一部分确定的计算资源。
5. GPU Slice：把计算和显存组合起来
只有 SM 还不够，因为 GPU 计算必须访问显存。
所以 NVIDIA 定义了：
GPU Slice
它由：
一个 SM Slice
+
一个 Memory Slice组合而成。(NVIDIA Docs)
可以抽象成：
GPU Slice
┌────────────────────────┐
│ │
│ SM Slice │
│ │ │
│ ▼ │
│ Memory Slice │
│ │
│ HBM + Cache │
└────────────────────────┘于是整个 GPU 就可以大致想成：
Physical GPU
┌──────┬──────┬──────┬──────┐
│Slice │Slice │Slice │Slice │ ...
│ 0 │ 1 │ 2 │ 3 │
└──────┴──────┴──────┴──────┘MIG profile 就是在组合这些 slice。
6. GPU Instance：GI
由此引出 MIG 的重要概念之一：
GPU Instance，简称 GI。
GI 是由一个或多个 GPU Slice 加上一部分 GPU engines 组成的逻辑 GPU 实例。
例如：
Physical GPU
┌─────────────────────────────────────────┐
│ │
│ GI 0 GI 1 │
│ ┌──────────┐ ┌──────────────────┐ │
│ │ 1 Slice │ │ 3 Slices │ │
│ └──────────┘ └──────────────────┘ │
│ │
└─────────────────────────────────────────┘每个 GI 都拥有自己的：
- SM 资源
- Memory Slice
- HBM 容量
- HBM bandwidth
- Cache 资源
- 部分 GPU engines
因此 GI 之间具有硬件级资源隔离和相对稳定的 QoS。NVIDIA 明确将 MIG 的目标描述为在多个客户端之间提供定义明确的 QoS 和 fault isolation。(NVIDIA Docs)
7. Compute Instance：CI
GI 还能继续切。
这时候就是：
Compute Instance，简称 CI。
一个 GI 的显存资源是这个 GI 内共享的，但是 SM 计算资源可以进一步划分成多个 Compute Instance。(NVIDIA Docs)
例如：
GPU Instance
┌─────────────────────────────────┐
│ │
│ Shared Memory Resources │
│ │
│ ┌──────────┐ ┌──────────┐ │
│ │ CI 0 │ │ CI 1 │ │
│ │ SM Slice │ │ SM Slice │ │
│ └──────────┘ └──────────┘ │
│ │
└─────────────────────────────────┘所以层级关系是：
Physical GPU
│
▼
GPU Instance (GI)
│
▼
Compute Instance (CI)默认情况下，一个 MIG device 通常由一个 GI 和一个占满该 GI 计算资源的 CI 组成；只有在需要进一步细分计算资源的时候，才会继续把 GI 分成多个 CI。(NVIDIA Docs)
8. 1g.10gb 到底是什么意思
这是实际使用 MIG 时最容易遇到的表示法。
例如：
1g.10gb或者：
2g.20gb可以将其理解为：
<GPU Slice数量>g.<显存容量>例如某个具体 GPU 支持：
1g.10gb
1份 GPU compute slice
+
10GB 显存而：
3g.40gb
3份 GPU compute slice
+
40GB 显存不过这里要特别注意：
具体 profile 名称、显存大小、可创建数量并不是所有 GPU 都一样。
A100、A30、H100、H200、B200 等型号支持的 MIG profile 不完全相同，所以不能把某一个型号的 1g.10gb 规则机械套给所有卡。NVIDIA 为每种支持 MIG 的 GPU 单独列出了可用 profile 和 placement。(NVIDIA Docs)
所以生产里一定先：
nvidia-smi mig -lgip查看当前 GPU 真正支持哪些 GI profile，而不是靠记忆写 profile。
9. 一个完整例子：把 GPU 切成多个 MIG 实例
假设一张支持相应 profile 的 GPU。
原来：
GPU0
┌──────────────────────────────────────┐
│ │
│ 80GB HBM │
│ │
│ 全部计算资源 │
│ │
└──────────────────────────────────────┘切分之后可能形成：
GPU0
┌──────────┬──────────┬─────────────────┐
│ │ │ │
│ MIG 0 │ MIG 1 │ MIG 2 │
│ │ │ │
│ 小实例 │ 小实例 │ 较大实例 │
│ │ │ │
└──────────┴──────────┴─────────────────┘Kubernetes 看见的就不再只是：
nvidia.com/gpu: 1而可以把 MIG profile 作为不同类型的调度资源暴露出来。
10. MIG 和“多个进程共享 GPU”有什么不同
这是理解 MIG 最关键的问题之一。
假设没有 MIG：
Process A
\
\
GPU
/
/
Process BA、B 都共享：
SM
L2
HBM bandwidth
Memory Controller如果 A 突然大量使用显存带宽：
A HBM bandwidth ↑↑↑B 可能马上变慢。
这就是：
noisy neighbor。
而 MIG：
Process A
│
▼
MIG Instance A
│
├── dedicated compute resource
└── dedicated memory resource
Process B
│
▼
MIG Instance B
│
├── dedicated compute resource
└── dedicated memory resource资源隔离是硬件层面的。
所以 A 的高负载不会像普通进程共享那样任意抢走 B 已经划定的 SM 和 memory slice。
这就是 MIG 能提供更稳定 QoS 的根本原因。(NVIDIA Docs)
11. MIG 和 CUDA MPS 的区别
这两个特别容易混。
MPS：
Multi-Process Service。
主要目的是让多个 CUDA process 更有效地共享一个 GPU 的计算资源。
它仍然基本属于：
软件调度 / runtime sharing可以粗略理解成：
GPU
│
├── Process A
├── Process B
└── Process C
共享大量物理资源而 MIG：
GPU
│
├── Hardware Partition A
├── Hardware Partition B
└── Hardware Partition C两者最大的区别可以概括成：
| 特性 | MPS | MIG |
|---|---|---|
| 主要层次 | 软件/runtime | 硬件分区 |
| SM隔离 | 弱 | 强 |
| 显存容量隔离 | 有限 | 硬件划分 |
| 显存带宽隔离 | 弱 | 更强 |
| QoS | 有限 | 更确定 |
| 故障隔离 | 弱 | 更强 |
| 资源粒度 | 更灵活 | 受 profile 限制 |
因此二者不是完全竞争关系，而是解决不同层次的问题。
12. MIG 和 vGPU 也不是同一个概念
vGPU：
Virtual Machine
│
vGPU
│
Physical GPU重点是：
虚拟化环境中的 GPU 资源呈现和隔离。
MIG：
Physical GPU
│
Hardware Partition
│
MIG Device重点是：
GPU 芯片内部硬件资源分区。
两者甚至可以组合，例如通过 MIG-backed vGPU 将 MIG 分区用于 VM。NVIDIA 当前文档明确支持这种部署方式。(NVIDIA Docs)
13. MIG 为什么特别适合推理集群
对于大模型训练，通常希望：
8张GPU
16张GPU
64张GPU
甚至数千张GPU而且单个任务会尽可能吃满整卡。
所以：
大规模训练通常并不是 MIG 最典型的使用场景。
MIG 更适合的是：
推理
小模型
开发测试
Jupyter
数据处理
共享GPU平台例如一张 GPU 同时服务：
Embedding Service
LLM小模型推理
CV模型
Notebook它们单独占一整张高端 GPU 都非常浪费。
MIG 就非常合适。
14. 为什么训练不一定适合 MIG
训练任务非常依赖：
GPU compute
HBM bandwidth
NVLink
NCCL尤其大模型训练往往希望：
整张GPU
+
整套NVLink/NVSwitch拓扑这样得到最大的：
Tensor FLOPS
HBM bandwidth
inter-GPU bandwidth如果把 GPU 切成几个很小的 MIG instance：
GPU
├── MIG0
├── MIG1
├── MIG2
└── MIG3单个训练 worker 能使用的 SM、HBM capacity 和 bandwidth 都受到 profile 限制。
因此如果任务本身能吃满整卡：
MIG 通常不会给训练带来收益。
15. MIG 真正解决的是 GPU 资源碎片
假设 GPU 集群里很多任务需要：
10GB
20GB
30GB但 GPU 都是：
80GB不用 MIG：
Task A → 整张 80GB GPU
Task B → 整张 80GB GPU
Task C → 整张 80GB GPU实际使用可能只有：
A 10GB
B 15GB
C 20GB这就是严重浪费。
使用 MIG：
GPU 80GB
┌───────────┬───────────┬──────────────┐
│ │ │ │
│ Task A │ Task B │ Task C │
│ MIG │ MIG │ MIG │
│ │ │ │
└───────────┴───────────┴──────────────┘这时候 GPU utilization 和显存利用率都会明显提高。
16. MIG 模式怎么启用
在支持 MIG 的 GPU 上，可以查看：
nvidia-smi或者：
nvidia-smi -i 0 --query-gpu=pci.bus_id,mig.mode.current --format=csv启用：
sudo nvidia-smi -i 0 -mig 1关闭：
sudo nvidia-smi -i 0 -mig 0这里存在一个非常重要的架构差异。
对于 Ampere GPU，开启 MIG 通常需要 GPU reset，而且 MIG mode 状态可以跨 reboot 保持；而从 Hopper 及更新架构 开始，启用 MIG mode 不再需要 GPU reset，但 MIG mode 状态通常只在 NVIDIA driver 保持加载期间有效，driver unload/reload 后需要重新配置。(NVIDIA Docs)
这对运维非常重要，因为：
不同代 GPU 的 MIG 生命周期管理方式并不完全一样。
17. 创建 MIG 实例的基本流程
整体流程可以记成：
Physical GPU
│
│ Enable MIG
▼
MIG Mode
│
│ Create GI
▼
GPU Instance
│
│ Create CI
▼
Compute Instance
│
▼
MIG Device首先查看支持的 GI profile：
nvidia-smi mig -lgip然后可以按照指定 profile 创建 GPU Instance。
再查看 Compute Instance profile：
nvidia-smi mig -lcip之后创建相应 CI。
实际生产环境通常不会天天手工执行这些命令，而是交给 GPU Operator/MIG Manager 管理。
18. MIG Device 为什么像“一张独立 GPU”
MIG 实例创建完成之后，每个 MIG device 都有自己的标识符。
通常会看到类似：
GPU UUID
│
├── MIG Device UUID
├── MIG Device UUID
└── MIG Device UUIDCUDA application 可以把 MIG device 当成可见计算设备。
因此应用看见的是：
CUDA Device而不需要自己理解：
这其实只是某张物理 GPU 的一部分。
这正是 MIG 的抽象价值。
19. MIG 在 Kubernetes 中怎么工作
这部分和当前学习的 Kubernetes 很重要。
普通 GPU 节点：
Kubelet
│
▼
NVIDIA Device Plugin
│
▼
GPU0
GPU1
GPU2
GPU3Device Plugin 向 Kubernetes 注册：
nvidia.com/gpu例如：
Capacity:
nvidia.com/gpu: 4开启 MIG 后：
Physical GPU
│
├── MIG 1g.xxgb
├── MIG 1g.xxgb
└── MIG 2g.xxgbNVIDIA Device Plugin 可以把这些 MIG device 注册成 Kubernetes 可调度资源。
20. Kubernetes 的 MIG Strategy
NVIDIA Device Plugin / GPU Operator 里有一个非常重要的概念：
MIG strategy主要会看到类似：
none
single
mixed20.1. none
不使用 MIG：
nvidia.com/gpu20.2. single
节点上的 GPU 使用一致的 MIG 配置。
从调度器角度，MIG device 以较统一的 GPU 资源模型呈现。
20.3. mixed
允许节点存在不同 MIG profile。
例如：
1g.xxgb
2g.xxgb
3g.xxgb可以被作为不同扩展资源暴露。
对于共享 GPU 平台，mixed 非常实用，因为可以提供不同规格的 GPU“套餐”。
GPU Operator 支持通过 MIG Manager 管理节点 MIG 配置，并要求在启用 MIG 时选择相应 MIG strategy。(NVIDIA Docs)
21. 它其实非常像云服务器规格
例如云厂商提供：
small
medium
largeMIG 可以让 GPU 也变成：
GPU Small
GPU Medium
GPU Large例如：
小推理任务
↓
小 MIG profile
中型任务
↓
中 MIG profile
大型任务
↓
大 MIG profile于是 GPU 平台开始具备一种很重要的能力：
GPU Resource Pooling。
这对 AI Infra 平台非常重要。
22. GPU Operator 如何管理 MIG
在 Kubernetes 中，手工：
nvidia-smi mig ...不适合大规模节点。
NVIDIA GPU Operator 默认安装的一系列组件中包括：
GPU Driver
Container Toolkit
Device Plugin
DCGM Exporter
MIG ManagerMIG Manager 专门负责节点 MIG 配置生命周期。(NVIDIA Docs)
架构：
Kubernetes
│
GPU Operator
│
MIG Manager
│
▼
GPU Node
│
▼
Configure MIG
│
┌────────┼────────┐
▼ ▼ ▼
MIG0 MIG1 MIG2这样管理员只需要定义节点应该使用什么 MIG profile，而不是 SSH 到几十台机器里执行 nvidia-smi。
23. MIG 监控会发生什么变化
这和前文讨论的 DCGM 很有关。
不用 MIG 时：
DCGM metric
gpu="0"
UUID="GPU-xxxx"使用 MIG 后，需要知道：
Physical GPU
│
├── GI
│ └── CI
│ └── MIG Device所以监控也必须进入：
MIG entity level。
DCGM 本身支持 MIG hierarchy，DCGM Exporter 可以采集 GPU/MIG 实例级 telemetry，并且能够结合 Kubernetes 工作负载信息关联 Pod。NVIDIA 目前仍推荐 Kubernetes GPU telemetry 使用 DCGM Exporter。(NVIDIA Docs)
24. MIG 环境监控最重要的变化
以前：
Physical GPU
│
▼
GPU Util
Memory Used
Power
Temperature现在需要变成：
Physical GPU
│
├── Power
├── Temperature
├── Xid
│
└── MIG Instances
│
├── MIG0
│ ├── compute
│ └── memory
│
└── MIG1
├── compute
└── memory也就是说存在两个监控层级：
24.1. Physical GPU Level
观察：
- 温度
- 功耗
- Xid
- GPU 整体健康
- PCIe
- 硬件错误
24.2. MIG Instance Level
观察：
- 计算利用率
- 显存利用率
- workload
- Pod
- 实例级性能
这两个层次不能混为一谈。
25. MIG 并不能隔离所有物理故障
这也是运维很容易误解的地方。
假设：
Physical GPU0
│
├── MIG A
├── MIG B
└── MIG CMIG 提供强资源和一定的 fault isolation，但它们毕竟仍然位于：
同一块物理 GPU。
如果整个 GPU：
PCIe失联或者出现严重板卡级问题，那么：
MIG A
MIG B
MIG C全部可能受到影响。
所以调度器不能把 MIG instance 当成完全独立的物理故障域。
这对高可用设计非常关键。
例如三个模型副本：
Replica A
Replica B
Replica C如果三个都调度到：
同一Physical GPU的三个MIG从 Kubernetes 看：
3个GPU资源但从硬件 failure domain 看：
只有1张GPU一次板卡故障就能把三个 replica 全带走。
所以生产调度还必须知道：
Node
Physical GPU
MIG Instance之间的拓扑关系。
26. MIG 对调度系统提出的新问题
以前调度：
Pod需要1 GPU很简单。
现在：
Pod A需要1g
Pod B需要2g
Pod C需要3g而物理 GPU profile placement 又不是任意组合的。
于是会出现新的：
MIG fragmentation。
比如 GPU 上还有足够的“总资源”，但是剩余 slice 的排列无法构造任务需要的 profile。
这和 CPU/内存碎片不同，因为 MIG 的切割受 GPU 硬件 profile 和 placement 约束。NVIDIA 对每种 GPU 都提供了允许的 MIG profile 与 placement 组合。(NVIDIA Docs)
因此 AI Infra 调度平台还要考虑：
当前MIG布局
↓
待调度任务需求
↓
能否通过现有profile直接满足？
↓
是否需要重新配置GPU？
↓
重配置会不会影响已有任务？这就开始接近真正的 GPU scheduler 设计了。
27. 什么时候应该使用 MIG
可以建立这样一个判断模型：
| 场景 | MIG适用性 |
|---|---|
| 大模型预训练 | 通常较低 |
| 大型分布式训练 | 通常较低 |
| 小模型训练 | 可能适用 |
| LLM推理 | 很适合 |
| Embedding模型 | 很适合 |
| 开发测试环境 | 很适合 |
| Notebook/Jupyter | 很适合 |
| 多租户GPU平台 | 非常适合 |
| GPU资源池 | 非常适合 |
根本判断标准不是：
“MIG 是不是高级技术？”
而是：
单个 workload 能不能有效吃满整张 GPU。
如果答案是：
能整卡通常更合适。
如果：
不能MIG 就很有价值。
28. MIG 在 GPU 资源体系中的位置
到这里，可以把 MIG 放进完整 GPU Infra 结构：
Kubernetes
│
GPU Scheduler
│
GPU Operator
│
┌─────────────────┼─────────────────┐
│ │ │
▼ ▼ ▼
Device Plugin MIG Manager DCGM Exporter
│ │ │
│ ▼ │
│ Configure MIG │
│ │ │
└──────────┬──────┘ │
▼ │
Physical GPU │
│ │
┌──────────┼──────────┐ │
▼ ▼ ▼ │
MIG0 MIG1 MIG2 │
│ │ │ │
▼ ▼ ▼ │
Pod A Pod B Pod C │
│
Metrics ◄─────────────────┘
│
Prometheus
│
Grafana/AIOps这里各组件职责就非常清楚了：
MIG 负责硬件资源切分。
MIG Manager 负责管理切分配置。
Device Plugin 负责把 MIG resource 暴露给 Kubernetes。
Scheduler 负责决定谁使用哪一种资源。
DCGM Exporter 负责观察 GPU/MIG 的运行状态。
Prometheus 负责集中采集和存储。
29. 需要掌握的 MIG 本质
如果只记一件事情，不要记：
MIG = 一张GPU切成7张这过于表面。
应该记成：
MIG 是 NVIDIA GPU 的硬件级空间分区机制。它按照 GPU 内部的计算 slice 和 memory slice 把 SM、显存容量、显存带宽、Cache 和部分 GPU engines 组合成相对独立的 GPU Instance，并可以进一步通过 Compute Instance 划分计算资源。
因此 MIG 解决的是三个核心问题：
资源利用率
+
性能隔离 / QoS
+
多租户资源管理而它带来的新问题则是：
MIG profile规划
+
资源碎片
+
调度复杂度
+
监控粒度
+
物理GPU故障域所以对于 AI Infra 来说，MIG 不是单纯的一条 nvidia-smi 命令，而是一套从 GPU 硬件切分 → Kubernetes 资源抽象 → 调度 → 可观测性 → 多租户管理 的完整资源管理机制。
关联文档
- GPU 容器虚拟化层完整详解：对比 MIG、vGPU、MPS 等 GPU 共享与隔离技术。
- Kubernetes GPU 调度完整详解：理解 MIG 资源在 Kubernetes 中的发现与调度。
- GPU监控指标：补充物理 GPU 与 MIG 实例的监控维度。