在 AI 算力最紧张的时代，一块 A100 显卡就像一栋黄金地段的创业大楼：位置极佳、硬件豪华，过去却只能“整栋出租”。一家公司租下来，往往只用了几个工位，仓库（显存）却堆得满满当当，其他楼层全在吃灰；旁边的公司想入驻，连门都进不去。直到 NVIDIA 推出 MIG（Multi-Instance GPU，多实例 GPU），这栋大楼才被装上“实体隔断墙”，最多隔成 7 间独立办公室：每间都有独立小仓库、独立电表、独立电梯配额，一家公司烧水短路，绝不会牵连隔壁。 从此，园区多了两位“智能管家”：Slurm 像租约经理，按队列优先级把房间长租给作业；K8s 像智能门禁管家，容器启动时自动刷脸分房。两位管家都要先把 MIG 的每间办公室登记成正式“房源”，才能在集群中调度。本文就用“隔间装修 + 房源出租”这条故事线，带你彻底搞懂 MIG 的原理、配置、调度、隔离效果与落地技巧。

岗位关联

学完本节，你能在真实集群中用 Slurm/K8s 为推理、训练任务按需分配 MIG 实例，把 GPU 利用率从 30% 拉到 85%，也能从容回答面试中关于多实例 GPU 的高频问题——这是 AI 基础设施工程师的核心竞争力。

目录
  1. 可视化演示
  2. MIG 基本概念
  3. 硬件切分原理
  4. 实例类型配置
  5. 集群调度集成
  6. 性能隔离特性
  7. 配置管理实践
  8. 应用场景案例
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

三步展示MIG多实例GPU：GPU物理结构（A100的7个GPC→SM流式多处理器→硬件级分区）、MIG Profile配置（1g.5gb最多7实例/2g.10gb/3g.20gb/7g.40gb）、多租户推理场景（7个1g.5gb实例分别托管BERT/ResNet等模型，硬件隔离互不影响）。

本节配有交互动效（进入视口后自动加载，约 3KB）。

A100 GPU物理结构 GPC:图形处理集群，7个GPC组成A100 SM:流式多处理器，每个GPC含多个SM 内存：40GB HBM2,每GPC分5GB MIG_instance = GPC_subset + SM_subset + memory_slice 硬件级分区实现强隔离。

MIG 基本概念

当年“整栋出租”的痛点，你肯定感同身受：团队 A 租下整块 A100，只开两个办公区的灯，仓库（显存）却堆到天花板；团队 B 的推理服务急着上线，只能眼巴巴排队。资源利用率低到 30%，是裸金属 GPU 集群的通病。MIG 要解决的，正是“大楼如何安全分租”这个根本问题。

MIG（Multi-Instance GPU，多实例 GPU）是 NVIDIA 在 Ampere 架构起引入的硬件级切分技术。它把一块物理 GPU 的计算核心、显存、L2 缓存和显存带宽切成若干独立分区，每个分区都是一个完整的 “小 GPU”——有自己的仓库门禁、独立电梯、独立电表，驱动会把它识别成独立设备。这和“拉个帘子”的时间切片、只在墙上挂公司牌子的 vGPU 有本质区别：MIG 的墙是实体墙，邻居抢不走你的资源。

在 A100（40GB）上，一块物理 GPU 最多可以切出 7 个 MIG 实例。每个实例独占一部分 SM（流式多处理器）计算单元、一部分显存容量和相应的带宽切片。任务跑在实例里，就像租户在自己的隔间办公，不需要关心隔壁是谁，也不需要改代码——CUDA 程序基本透明适配。

为了衡量“分租到底赚了多少”，我们引入资源利用率的概念：

回到大楼的比喻：MIG 之前，一栋楼只有一家公司，加班也只用三分之一的设备，利用率自然低；MIG 之后，七家租户轮班使用全楼，每个隔间都有人干活，整栋楼的“上座率”自然翻倍。

U=∑i=1nPi×tiPpeak×T\displaystyle U = \frac{\sum_{i=1}^{n} P_i \times t_i}{P_{\text{peak}} \times T}
利用率 U = 所有任务实际消耗的算力 ÷ GPU 满负荷运转的理论总算力。MIG 的价值就是把分母“吃满”。
  1. 分子算力消耗之和：统计窗口内每个任务消耗的算力与运行时间的乘积，再求和。
    ∑i=1nPi×ti\displaystyle \sum_{i=1}^{n} P_i \times t_i
  2. 分母理论峰值容量：GPU 以峰值算力 \(P_{\text{peak}}\) 连续运行总时间 \(T\) 能提供的最大算力。
    Ppeak×T\displaystyle P_{\text{peak}} \times T
  3. 利用率比值两者相除得到 0~1 之间的利用率，越接近 1 说明资源越物尽其用。
    U=∑i=1nPi×tiPpeak×T\displaystyle U = \frac{\sum_{i=1}^{n} P_i \times t_i}{P_{\text{peak}} \times T}

硬件切分原理

装修队进场了。要把创业大楼安全隔开，关键是怎么砌墙：既不能破坏承重结构，又要保证每家都有独立的水电。GPU 的“承重结构”就是 GPC（Graphics Processing Cluster，图形处理簇）。A100 的 108 个 SM 计算单元分成 7 个 GPC 分组，每个 GPC 天然是“一层标准办公区”。

MIG 的砌墙方案非常巧妙：把 7 个 GPC 对应的计算切片作为“楼层”，再把显存切成“仓库配额”，两者一一配套。一个 1g.5gb 的实例 = 拿到 1 层办公区（1 个 GPC 的计算切片）+ 5GB 显存配额 + 约 1/7 的 L2 缓存 + 约 1/7 的显存带宽。计算切片与内存切片像拼图一样组合，就形成了不同的“户型”。

显存带宽的隔离是硬件级的：每个 MIG 实例拥有独立的带宽切片，不会因为邻居疯狂读写显存而导致自己的数据传输变慢。L2 缓存也被分区，进一步减少跨租户的缓存争抢。这意味着哪怕“楼下”在跑满负荷的大模型训练，“楼上”做推理的延迟也纹丝不动。

用资源占比向量表示每个实例拿到的“房间配置”：

形象地说，装修队每砌一道墙，都会同步安装独立电表（算力）、独立水表（带宽）、独立储物柜（显存）。租户拿到钥匙的那一刻，就知道自己能用多少水、多少电，绝不会和邻居“抢龙头”。

Ri=(ciC, miM, biB)\displaystyle R_i = \left( \frac{c_i}{C},\ \frac{m_i}{M},\ \frac{b_i}{B} \right)
这组三元组分别表示：计算切片占比、显存占比、带宽占比。MIG 保证每一项都是“硬配额”，而非“尽力而为”。
  1. 计算切片占比实例 i 分到的 GPC 计算片数 \(c_i\) 除以总计算片数 \(C\)。A100 上 \(C=7\)。
    ciC\displaystyle \frac{c_i}{C}
  2. 显存占比实例 i 的显存配额 \(m_i\) 除以总显存 \(M\)。如 5GB ÷ 40GB = 1/8。
    miM\displaystyle \frac{m_i}{M}
  3. 带宽占比实例 i 的带宽切片 \(b_i\) 除以总带宽 \(B\)。三个比例共同构成实例的资源画像。
    biB\displaystyle \frac{b_i}{B}

实例类型配置

大楼的开发商（NVIDIA）提供了一套“标准户型图”，物业不能随意乱砌。A100 40GB 的官方户型有：1g.5gb、1g.10gb、2g.10gb、2g.20gb、3g.20gb、3g.40gb、4g.20gb、7g.40gb。名字里的数字不是随便写的：第一个数字是“计算片数”（g 代表 GPC 计算片），后半段是该实例独占的显存大小。

这里要区分两个层级：GPU Instance（GI，GPU 实例）是自己拥有独立显存的“整间办公室”；Compute Instance（CI，计算实例）则是装在 GI 里的“工位隔断”，可以进一步把算力细分，但显存归属仍归外层 GI 所有。理解这点，调度时才知道任务到底“住进了哪一层”。

配置有两条硬规则：第一，一张卡在某个时刻只能选择一种户型组合，不能一半切 1g.5gb、另一半切 4g.20gb 混搭；第二，切换户型必须让 GPU 完全空闲并执行 reset（相当于拉闸断电重装），不是热插拔。所以 MIG 的“装修”成本不低，规划要一次到位。

任意切分方案都要满足容量约束：

好比开发商规定：一层楼最多隔 7 间，每间的仓库和工位数都有标准模板。想临时把 1g 改成 2g？可以，但要整层楼清空、断电、重新砌墙，不能租户住着的时候施工。

∑ini×ci≤C,∑ini×mi≤M,∑ini≤7\displaystyle \sum_{i} n_i \times c_i \le C, \qquad \sum_{i} n_i \times m_i \le M, \qquad \sum_{i} n_i \le 7
三条不等式分别约束：计算片总数、显存总数、实例数量，三者同时满足才算合法户型。
  1. 计算片约束所有实例的计算片数之和不能超过 7 个 GPC 总片数。
    ∑ini×ci≤C\displaystyle \sum_{i} n_i \times c_i \le C
  2. 显存约束所有实例显存配额之和不能超过物理显存总量。
    ∑ini×mi≤M\displaystyle \sum_{i} n_i \times m_i \le M
  3. 数量上限约束A100 硬件最多支持 7 个实例同时存在。
    ∑ini≤7\displaystyle \sum_{i} n_i \le 7

集群调度集成

房间砌好了，接下来要让“智能管家”发钥匙。Slurm 和 K8s 是园区里最常见的两位管家，但它们管理房源的方式不同。Slurm 更像“租约经理”：系统管理员把 MIG 户型写进 gres.conf（租约台账），用户通过 --gres=gpu:1g.10gb 这样的参数申请指定户型，Slurm 负责在合适的节点上分配并保障租约期内独占。

K8s 则走“自动化管家”路线：NVIDIA Device Plugin（设备插件）相当于门禁系统的“房源登记模块”，它把每张卡上的 MIG 实例上报为集群资源，如 nvidia.com/mig-1g.10gb。用户容器只需在资源请求里写明要几个“1g 房间”，K8s 调度器就会自动找到有空房的节点并完成绑定。配合 NVIDIA MIG Manager（MIG 管理器），管理员可以在 K8s 里声明节点应切成哪种户型，由管理器自动执行切分。

两位管家都要解决同一个核心问题：调度器如何判断“这间房能不能给这位租客”。用匹配函数表达：

想象一下：租约经理用手写台账（Slurm GRES），逐条核对“这间房空不空”；智能门禁管家则把房源同步到中央系统（K8s API），自动匹配。理解了两者的差异，你就能在真实集群中选对工具——超算传统作业用 Slurm，云原生容器平台用 K8s。

Φj={1,greq≤Gjavail0,其他\displaystyle \Phi_j = \begin{cases} 1, & g_{\text{req}} \le G_{j}^{\text{avail}} \\ 0, & \text{其他} \end{cases}
节点 j 的空闲 MIG 资源足以满足任务请求时，\(\Phi_j=1\)，方案可行；否则为 0，换下一个节点。
  1. 请求量任务声明的 MIG 资源量，如 2 个 1g.10gb 实例。
    greq\displaystyle g_{\text{req}}
  2. 可用量节点 j 当前空闲（未出租）的 MIG 资源总量。
    Gjavail\displaystyle G_{j}^{\text{avail}}
  3. 匹配判定请求不超过可用量则标记为可调度候选，否则跳过该节点。
    Φj={1,greq≤Gjavail0,其他\displaystyle \Phi_j = \begin{cases} 1, & g_{\text{req}} \le G_{j}^{\text{avail}} \\ 0, & \text{其他} \end{cases}

性能隔离特性

隔间装修完工，该验收“隔音效果”了。时间切片方案下，隔壁租户开会（跑满计算）时，你的视频会议就会卡顿；而 MIG 的实体墙保证了什么呢？第一是确定性性能：无论邻居负载多高，你的算力、带宽配额纹丝不动，任务完成时间可预期；第二是故障隔离：隔壁线路短路（GPU 报错、显存故障），不会传导到你的隔间，一个实例的异常不会拖垮整卡。

第二堵“墙”是带宽保障。MIG 给每个实例的显存带宽切片是硬件独享的，这意味着推理服务的 P99 延迟不会因为“楼下跑训练”而突然飙高。对比三种共享方案：时间切片（time-slicing）是轮流用同一张桌子，邻居开大会你就得等；CUDA MPS 是软件层面的协作调度，一个进程崩溃可能影响同卡其他人；而 MIG 是硬件级隔离，安全性和隔离性最强。

用加速比量化隔离收益：

楼里开派对不再吵到加班的人，跳闸也不会整楼停电——这就是实体墙的底气。对于延迟敏感的线上推理，MIG 的确定性比“纸面吞吐”更值钱。

S=TsharedTmig\displaystyle S = \frac{T_{\text{shared}}}{T_{\text{mig}}}
S 表示同一任务在“受邻居干扰的共享环境”与“MIG 隔离环境”下的完成时间之比。S 越大，说明 MIG 的确定性收益越明显。
  1. 共享环境完成时间任务在时间切片共享下，因邻居抢占而拉长的实际完成时间。
    Tshared\displaystyle T_{\text{shared}}
  2. MIG 环境完成时间同一任务在 MIG 隔离下不受干扰的基础完成时间。
    Tmig\displaystyle T_{\text{mig}}
  3. 加速比两者相除。S=1.5 意味着隔离环境下任务快了 50%，这就是“确定性”的价值。
    S=TsharedTmig\displaystyle S = \frac{T_{\text{shared}}}{T_{\text{mig}}}

配置管理实践

好户型需要规范的施工流程。管理员的操作手册大致四步：第一，用 nvidia-smi -mig 1 开启整张卡的 MIG 模式（相当于给大楼发“可分割”的规划许可）；第二，在 GPU 空闲时执行切分配置，例如 nvidia-smi mig -cgi 1g.10gb,2g.20gb -cipc，把显存和计算片组合成目标户型；第三，用 nvidia-smi mig -lgi 验收各实例状态；第四，接入 DCGM 或 nvidia-smi dmon 持续监控每个实例的利用率与温度。

资源规划要警惕“碎片化”——这是分租最大的隐形杀手。假设你切成 3g+3g+1g，但排队任务里全是需要 2g 的租户，剩下那个 1g 房间就永远空置，而 2g 任务也塞不进 1g 房间。规划户型前必须统计真实负载画像：推理任务多就多切 1g/2g，训练任务多就保留 3g/7g 大户型。

碎片率是衡量规划水平的关键指标：

物业的智慧在于“先招商再装修”：先统计园区租户的规模分布，再决定隔几间大的、几间小的。盲目按最大户型切分，或全部切成鸽子笼，都会造成长期空置。

F=mwasteM\displaystyle F = \frac{m_{\text{waste}}}{M}
碎片率 = 因户型组合不匹配而无法被任何排队任务利用的显存 ÷ 总显存。F 越小，切分规划越健康。
  1. 碎片显存当前剩余但无法匹配任何等待任务请求的显存空间。
    mwaste\displaystyle m_{\text{waste}}
  2. 总显存整卡物理显存容量。
    M\displaystyle M
  3. 碎片率比值越低说明户型与任务匹配度越高。实践中应结合队列历史调整户型。
    F=mwasteM\displaystyle F = \frac{m_{\text{waste}}}{M}

应用场景案例

故事来到高潮：园区入驻了三位典型的租户。第一家是“多模型推理公司”，手握几十个小模型（BERT、GPT 小型号），每个模型只需 5~10GB 显存。它们把一张 A100 切成 7 个 1g.5gb 房间，7 个推理服务同时在线，吞吐量是整卡串行推理的 5 倍以上——这是 MIG 最经典的“模型推理”场景。

第二家是“多租户共享平台”，承接内部多个互不信任的团队。每个团队分到独立 MIG 实例，硬件隔离保证数据安全与性能互不干扰，团队之间再无“谁抢了谁的显存”的扯皮。管理员还能按团队优先级动态调整户型——当然，必须在低峰期重启后生效。

第三家是“混合负载工厂”：白天推理服务是主力（切 7×1g 细户型），夜间训练任务上场（切换为 2g+3g+3g 大户型）。通过脚本在固定时段自动 reset GPU 并重建 MIG 配置，实现了“一卡两吃”。核算下来，单位算力成本显著下降：

创客大楼的故事讲完了：硬件砌墙（MIG 原理）、户型选择（实例配置）、管家分房（调度集成）、隔音验收（性能隔离）、施工规范（配置管理），最终各家租户都找到了性价比最高的入住方式。理解这条完整链路，你就能在真实工作中把 MIG 用出真正的价值。

Cunit=CtotalQavg×U\displaystyle C_{\text{unit}} = \frac{C_{\text{total}}}{Q_{\text{avg}} \times U}
单位成本 = 硬件+电费+运维总成本 ÷（平均吞吐 × 利用率）。U 从 30% 拉到 85%，分母变大，每一块钱买的算力自然更多。
  1. 总成本包含 GPU 折旧、电费、机房与运维开销。
    Ctotal\displaystyle C_{\text{total}}
  2. 有效产出平均吞吐量与利用率的乘积，衡量系统“真正干活的量”。
    Qavg×U\displaystyle Q_{\text{avg}} \times U
  3. 单位成本总成本除以有效产出，得到每单位推理/训练量的开销。
    Cunit=CtotalQavg×U\displaystyle C_{\text{unit}} = \frac{C_{\text{total}}}{Q_{\text{avg}} \times U}

AI 应用场景

多租户推理平台（K8s + MIG 混合切分）

阶段：算力集群与调度 / 资源分配

解决的问题：传统方式下，内部多个团队共享一台 8 卡 A100 服务器，互相抢显存、抢带宽；用时间切片虽能共存，但一个团队跑满计算就会拖慢所有人的延迟。MIG 把每张卡切成 1g.10gb + 1g.10gb + 2g.20gb + 3g.20gb 等多套户型，K8s 通过 Device Plugin 暴露 nvidia.com/mig-1g.10gb 等资源，各团队容器各居其室，互不干扰。

具体案例：某公司 NLP 平台将 8 张 A100 切成 32 个“1g 推理间”动态分配给线上问答服务，同时保留 8 个“3g 训练间”给模型微调。改造后 GPU 利用率从 35% 提升到 85%，推理 P99 延迟保持稳定。

超算中心 Slurm 队列小作业分流

阶段：作业调度 / 队列管理

解决的问题：超算中心大量小作业（单卡显存 <10GB）排队等整卡，浪费严重。Slurm 在 gres.conf 中将 MIG 户型登记为 GRES 资源类型，用户通过 srun --gres=gpu:1g.10gb 提交小任务，调度器把多个小任务塞进同一张物理卡的不同实例。

具体案例：某国家超算分中心在登录节点配置 MIG 后，小作业平均排队时间从 6 小时缩短到 1.5 小时，整卡利用率提升 3 倍，用户满意度显著上升。

推理训练错峰的成本优化

阶段：成本优化 / 容量规划

解决的问题：白天推理峰值、夜间训练峰值，静态切分无法适配。利用 MIG“切分需重启”的特性，在业务低峰期定时切换户型，实现一张卡白天当推理集群、晚上当训练集群。

具体案例：某自动驾驶公司白天将 A100 切成 7×1g 跑感知模型推理，夜间切换为 2g+3g+3g 跑数据回放训练，通过定时脚本运维自动完成 reset 与重配置，月度 GPU 采购成本节约 30%。

Python 演示

python72 行
"""MIG 多实例 GPU 调度模拟器模拟一张 40GB / 7 计算片的 A100 被切成多个 MIG 实例，并为不同任务类型（推理/训练）匹配合适的户型。""" MIG_PROFILES = [    {"name": "1g.5gb",  "compute": 1, "memory": 5},    {"name": "1g.10gb", "compute": 1, "memory": 10},    {"name": "2g.10gb", "compute": 2, "memory": 10},    {"name": "3g.20gb", "compute": 3, "memory": 20},    {"name": "7g.40gb", "compute": 7, "memory": 40},]  class GpuNode:    """一张支持 MIG 的物理 GPU"""     def __init__(self, total_memory=40, total_compute=7):        self.total_memory = total_memory        self.total_compute = total_compute        self.used_memory = 0        self.used_compute = 0     def free(self):        return {            "memory": self.total_memory - self.used_memory,            "compute": self.total_compute - self.used_compute,        }     def allocate(self, profile):        if profile["memory"] > self.free()["memory"]:            return False        if profile["compute"] > self.free()["compute"]:            return False        self.used_memory += profile["memory"]        self.used_compute += profile["compute"]        return True     def release(self, profile):        self.used_memory -= profile["memory"]        self.used_compute -= profile["compute"]  def schedule(jobs):    """按任务类型返回推荐的 MIG 配置"""    node = GpuNode()    plan = []    for job in jobs:        if job["type"] == "inference":            profile = MIG_PROFILES[1]  # 1g.10gb 适合小模型推理        elif job["type"] == "training":            profile = MIG_PROFILES[3]  # 3g.20gb 适合中型训练        else:            profile = MIG_PROFILES[4]  # batch 类型用整卡        if node.allocate(profile):            plan.append((job["name"], profile["name"]))        else:            plan.append((job["name"], "排队等待"))    return plan, node.free()  if __name__ == "__main__":    jobs = [        {"name": "bert-qa", "type": "inference"},        {"name": "resnet-train", "type": "training"},        {"name": "llm-train", "type": "training"},        {"name": "bert-senti", "type": "inference"},    ]    plan, free = schedule(jobs)    for name, profile in plan:        print("%-14s -> %s" % (name, profile))    print("剩余资源: 显存 %dGB, 计算片 %d" % (free["memory"], free["compute"]))
目的：模拟一张 A100 在 MIG 模式下如何按任务类型分配实例，直观展示计算片与显存的容量约束。
  1. class GpuNode:定义一张物理 GPU，记录总显存、总计算片及已用量，对应“整栋大楼”的资源台账。
  2. def free(self):返回当前剩余显存与计算片，相当于物业查询“还有几间空房”。
  3. def allocate(self, profile):尝试把一个 MIG 户型分配出去，容量不足时返回 False。
  4. profile = MIG_PROFILES[1]推理任务固定推荐 1g.10gb 小户型，避免浪费大房间。
  5. if node.allocate(profile):分配成功则写入方案，失败则进入“排队等待”。
  6. print("剩余资源: ...")输出最终剩余资源，反映切分规划是否合理。

常见误区

误区“MIG 不就是把 GPU 切分嘛，和 time-slicing、vGPU 差不多，都是让多个任务共用一张卡。”初学者常把三者混为一谈。

正解三者隔离层级完全不同。时间切片是时分复用，任务轮流用同一批计算单元，邻居满载你会被拖慢；vGPU 是虚拟化抽象，隔离靠软件层；MIG 是硬件级物理隔离，计算、显存、带宽、L2 全部独立切片，邻居无论怎么跑都影响不了你。用大楼比喻：时间切片是共用一张桌子的“轮班制”，MIG 是隔成独立办公室的“实体墙”，产权和基础设施完全分开。

为何常见：因为从用户视角看，三者都表现为“一张卡跑多个任务”，不深入硬件细节很难区分隔离层级。

误区“既然能用 nvidia-smi 命令切分，那生产环境里就可以根据流量动态调整 MIG 户型，白天多切 1g、晚上多切 3g。”

正解MIG 的配置变更必须在 GPU 完全空闲时执行 reset 操作才能生效。正在跑任务的实例无法被重新切分，切换前需要排空所有作业并重启 GPU。实际生产中的“动态调整”本质是：停机 → 重新切分 → 拉起新任务，只是把流程脚本化、自动化了。

为何常见：nvidia-smi 命令执行很快，容易让人误以为底层可以即改即用，忽略了 GPU 需要重启重建资源切片的限制。

误区“既然 1g 户型最小，那把整卡切成 7 个 1g 就是最优解，能塞最多任务。”

正解切分粒度必须匹配任务需求。7 个 1g.5gb 实例的总显存只有 35GB，且每个实例算力有限，无法运行需要 20GB+ 显存的模型。如果队列里全是 2g 任务，切成 7×1g 反而造成显存碎片和算力浪费。正确做法是统计负载画像，用混合户型（如 1g+2g+3g）对齐真实需求，才能最大化利用率。

为何常见：人直觉上认为“切得越小越灵活”，忽略了 MIG 户型有固定的计算-显存配比，以及任务本身有最小资源需求。

误区“只要 GPU 节点装了 NVIDIA 驱动，K8s 里自然就能调度 MIG 实例。”

正解K8s 要调度 MIG，需要三件套：开启 MIG 模式的驱动、NVIDIA Device Plugin 将 MIG 实例上报为扩展资源（如 nvidia.com/mig-1g.10gb）、以及 MIG Manager 负责按配置执行切分。缺了任何一环，调度器都“看不见”MIG 实例，只能把整卡当作普通 GPU 分配。

为何常见：普通 GPU 在 K8s 里即插即用，用户误以为 MIG 也同理，忽略了 MIG 需要额外的资源上报与管理组件。

面试题

Q1. MIG 的全称是什么？

单选题 · easy

  • A.Multi-Instance GPU（多实例 GPU）← 正确答案
  • B.Multi-Interface GPU（多接口 GPU）
  • C.Memory-Isolated GPU（显存隔离 GPU）
  • D.Mixed-Instance GPU（混合实例 GPU）

答案：A。MIG 是 Multi-Instance GPU 的缩写，核心含义是把一块物理 GPU 分成多个独立实例。B 的“接口”、C 的“显存隔离”、D 的“混合”都是对概念的歪曲，MIG 隔离的不只是显存，还包括计算和带宽。

Q2. 一块 A100 40GB 最多可切出多少个 MIG 实例？

单选题 · easy

  • A.4 个
  • B.7 个← 正确答案
  • C.8 个
  • D.16 个

答案：B。A100 的硬件架构将 GPU 划分为 7 个 GPC 计算簇，对应最多 7 个 MIG 实例。4 是常见 GPU 分区的数量错觉，8 和 16 来自于 V100 MPS 的时间分片数量，均不准确。

Q3. MIG 与时间切片（time-slicing）的本质区别是？

单选题 · mid

  • A.MIG 只能跑推理任务
  • B.MIG 是硬件级资源隔离，时间切片是时分复用← 正确答案
  • C.MIG 不支持多租户
  • D.时间切片不需要驱动支持

答案：B。MIG 通过硬件把计算、显存、带宽切成独立实例，邻居无法抢占；时间切片则是多个任务轮流使用同一套计算资源，负载高时互相拖慢。MIG 同样支持训练任务，天然适合多租户，故 A、C 错误；时间切片同样需要驱动，D 错误。

Q4. MIG 实例能够隔离下列哪些资源？（多选）

多选题 · mid

  • A.显存容量← 正确答案
  • B.计算核心（SM）← 正确答案
  • C.显存带宽← 正确答案
  • D.主机 CPU 核数

答案：ABC。MIG 隔离的是 GPU 内部的资源：显存容量、SM 计算核心、显存带宽和 L2 缓存。它不隔离主机侧 CPU 与内存，那些由容器或 Slurm 的 CPU 资源管理负责，因此 D 不属于 MIG 的能力范围。

Q5. 更换 MIG 配置（如从 1g.5gb 组合改为 2g.10gb）后，一般需要执行什么操作才能生效？

单选题 · mid

  • A.立即热生效，无需任何操作
  • B.在 GPU 空闲时执行 reset / 重启节点← 正确答案
  • C.重新安装显卡驱动
  • D.刷新主板 BIOS

答案：B。MIG 的切分由硬件资源切片决定，必须在 GPU 无运行上下文时执行 GPU reset 才能重建切片，不能热切换。无需重装驱动或刷新 BIOS，C、D 属于过度操作。

Q6. Slurm 中通常通过什么机制为作业分配 MIG 实例？

单选题 · mid

  • A.GPU_FEATURES 环境变量
  • B.GRES（通用资源）配合 --gres 参数← 正确答案
  • C.--mem 内存参数
  • D.CUDA_VISIBLE_DEVICES 掩码

答案：B。Slurm 通过 GRES（General Resource）机制管理 MIG，管理员在 gres.conf 中登记户型，用户用 --gres=gpu:1g.10gb 申请。GPU_FEATURES 只是特性描述，--mem 只管内存，CUDA_VISIBLE_DEVICES 是应用侧掩码，都不是调度分配机制。

Q7. K8s 中 MIG 设备由哪个组件上报为可分配资源？

单选题 · easy

  • A.kubelet 原生代码
  • B.NVIDIA Device Plugin← 正确答案
  • C.Prometheus Exporter
  • D.CSI 存储驱动

答案：B。NVIDIA Device Plugin 负责识别 GPU 上的 MIG 实例，并以 nvidia.com/mig-1g.10gb 等扩展资源名上报给 K8s。kubelet 本身不认识 MIG，Prometheus 只做监控，CSI 是存储接口，均与资源上报无关。

Q8. 关于"1g.10gb"这一 MIG 配置，下列说法正确的是？（多选）

多选题 · hard

  • A.占用 1 个 GPC 计算片← 正确答案
  • B.独占 10GB 显存← 正确答案
  • C.获得约 1/7 的 L2 缓存与带宽← 正确答案
  • D.可以在桌面级 RTX 4090 上使用

答案：ABC。1g 表示 1 个 GPC 计算片，10gb 表示独占 10GB 显存，同时按比例获得约 1/7 的 L2 和带宽。MIG 仅支持数据中心级 GPU（A100/H100 等），GeForce 系列不支持 MIG，故 D 错误。

Q9. MIG 配置切换后需要重启 GPU，其根本原因是什么？

单选题 · hard

  • A.显存需要在物理层面重新布线
  • B.GPU 必须在无计算上下文时重建硬件资源切片← 正确答案
  • C.驱动文件需要重新编译加载
  • D.必须拔插显卡重新枚举 PCIe

答案：B。MIG 切片是在 GPU 硬件层面划分的，切换户型必须清空所有计算上下文并执行 GPU reset，硬件才能重新分配 SM、显存、L2 等切片。驱动无需重编译，也不涉及物理布线或拔插显卡。

Q10. 下列哪些场景适合使用 MIG 多实例？（多选）

多选题 · hard

  • A.多个小模型在线推理共享一张卡← 正确答案
  • B.互不信任的租户间隔离部署← 正确答案
  • C.单任务占满整卡的大规模分布式训练
  • D.追求确定性延迟的混合负载← 正确答案

答案：ABD。MIG 适合小模型推理共卡、多租户隔离、混合负载等场景，硬件隔离保证性能确定。而单任务本就需要整卡算力和显存，再切分反而浪费，应使用 7g.40gb 整卡模式直接训练，故 C 不适合 MIG 切分。