MIG：强隔离的资源单位与运维代价
MIG 的本质是用硬件级隔离换取可预测性，但离散资源单位和重配置成本也带来了新的工程挑战。
MIG 解决的到底是什么问题
在真实的在线推理/多租户平台里，GPU 的主要矛盾往往不是“能不能共享”，而是：
- 共享后能否给出稳定的尾延迟（P95/P99）与吞吐承诺
- 共享后是否能避免跨租户干扰（noisy neighbor）
- 是否能做“可验收”的资源交付（SLA/QoS）
MIG 的设计动机就是把“一张卡”划分为多个彼此隔离的实例，每个实例拥有独立的高带宽显存、缓存与计算资源，从而获得更可预测的性能与 QoS。
这也是为什么 MIG 常被用于：
- 多租户推理服务（尤其是对尾延迟敏感的场景）
- 共享研发集群（不同团队并行试验但需要隔离）
- 需要较强"资源边界"的 MLOps 平台
关键概念：实例、离散 Profile 与"几何形状（geometry）"
MIG 在概念上至少要分清两层：
- GPU Instance（GI）：可以理解为“显存 + 一部分 GPU 资源”的大切片边界。
- Compute Instance（CI）：在 GI 内进一步划出可执行计算的单位（具体实现细节随架构/代际演进而变化）。
你不需要在本章穷尽 GI/CI 的所有细节，但必须形成一个直觉：MIG 的资源单位不是连续可调的，而是预定义的离散档位（profiles）。这意味着：
- 你可以得到强隔离，但只能在若干固定档位中选；
- 你会遇到“内部碎片”（例如需要 9GB 显存但只能用 10GB 档位）；
- 你会遇到“组合碎片”（某个节点上 MIG profile 的组合不再适配新工作负载）。
一个常见误区是把 MIG 当成"GPU 的 cgroup"。事实恰好相反：MIG 更像把一张卡变成一个离散设备池，每个实例是一个"新设备"。
为什么说 MIG 是"强隔离"
多数软件级共享方案（time-slicing、进程级复用、显存软限制、MPS 等）最终都绕不开一个问题：隔离强度依赖实现细节与负载行为，一旦负载模式变化，干扰就会暴露在尾延迟上。
MIG 的核心优势在于：它把“隔离”下沉到了硬件层，把一张 GPU 分成多个完全隔离的实例，每个实例拥有自己的显存分区、缓存与计算核心。
你可以把它视为三类隔离的组合：
- 显存隔离：显存是第一约束，隔离能显著降低 OOM 与抢占式抖动的外溢。
- 缓存/片上资源隔离：降低跨租户争抢带来的长尾。
- 计算资源隔离：减少“同卡不同进程”互相挤占 SM 的不确定性。
这些特性共同指向一个结论：MIG 适合"把可预测性当成第一原则"的平台型场景。
代价一：资源单位离散带来的碎片与弹性边界
MIG 允许把 GPU 分成最多若干个实例（以代际/型号为准），但它不是任意分配，而是按照固定 profile 组合。
这带来两个直接后果：
- 资源匹配是离散优化问题：调度从“填箱（bin packing）”进一步变成“带 profile 约束的填箱”。
- 弹性变差：当你的负载形态频繁变化，MIG 的 profile 组合很可能需要重配；而重配本身就是强运维动作（见下一节）。
典型碎片模式
- 内部碎片：申请略高于某档位阈值导致整体浪费。
- 组合碎片：节点上剩余的实例组合无法拼出新任务需要的 profile（即使总剩余显存看起来足够）。
- 集群碎片：不同节点的 MIG“几何形状”不一致，导致队列层面长期排队与倾斜。
因此，MIG 更适合：
- 工作负载形态相对稳定（例如固定几类模型推理）
- 你愿意用节点池分层消化异构（把不同 MIG geometry 放在不同 nodepool）
代价二：重配置是运维动作，且与调度强耦合
在 Kubernetes 语境下，这是 MIG 的最大“隐藏成本”。
以 NVIDIA GPU Operator 的 MIG 支持为例：其 MIG Manager 在配置 GPU 的 MIG 模式或 geometry 时，要求被配置的 GPU 上没有用户工作负载在运行；在一些云环境里甚至可能需要重启节点，因此往往需要先 cordon/drain。
这意味着：MIG 的几何形状不是一个可以随业务波动频繁调整的弹性旋钮。你一旦把“动态重配”当成常规手段，就会把平台稳定性拖入运维地狱：
- 需要编排停机窗口或迁移机制
- 需要在队列/调度层面协调重配时机
- 需要清晰的“重配触发条件”与回滚策略
正确姿势：把 MIG 当成“预切分设备池”
更现实的工程策略是：
- 按 nodepool 预设 MIG geometry，将其当成“节点属性”
- 通过标签/taint/affinity 把不同工作负载导向合适的几何池
- 由控制面（队列、配额、优先级）来做治理，而不是靠频繁改几何来追逐短期利用率
Kubernetes 集成：资源语义与暴露策略
Kubernetes 的扩展资源（extended resources）天然更接近“设备分配”，而不是“可分配的连续度量”。这与 MIG 的“实例就是设备”非常契合：MIG 实例可以被暴露为独立资源类型，由调度器做整数分配。
在 Kubernetes 中最常见的暴露方式是 NVIDIA k8s-device-plugin。它支持通过 MIG_STRATEGY 决定如何在节点上暴露 MIG 设备：
none：不区分 MIG 与否，仍以nvidia.com/gpu暴露整卡single：只暴露 MIG 设备（并要求节点上的 MIG 配置一致性更强）mixed：同时暴露整卡与 MIG 设备（更灵活，但治理复杂度更高）
你在本书后续章节会看到：“mixed 能力”经常被误用——它会让资源目录更丰富，但也会让配额、计量与公平性更难解释。除非你有明确的治理模型，否则更推荐以 nodepool 隔离的方式管理“整卡池 vs MIG 池”。
如果你把 GPU 共享方案放回本书的控制面地图，MIG 的定位非常清晰：
- 数据平面：硬切分 + 强隔离
- 控制面：把每个 MIG 实例当成独立设备，做队列/配额/优先级治理
- 端到端：适合"可声明、可验收"的资源交付，而不是追求极限的细粒度弹性
Hands-on：用你的两台 A100（MIG 开/关）建立直觉
你当前环境非常适合做一组“对照实验”：
- 机器 1：A100，MIG Disabled（整卡共享只能依赖软件方案）
- 机器 2：A100，MIG Enabled（硬切分、多实例隔离）
建议把本章的 hands-on 目标定义为三件事：
- 确认资源单位变化：从 1 张 GPU 变成 N 个 MIG 设备
- 确认 K8s 暴露语义：Pod 以“设备数量”申请 MIG profile
- 确认隔离收益与边界：干扰是否显著降低、但 profile 是否带来碎片与重配成本
下面给出一个最小操作路径，便于读者复现。具体命令可在 Lab 章节展开。
在 MIG 节点上确认 MIG 设备枚举
可以通过如下命令列举 MIG 设备和实例：
# 机器 2（MIG Enabled）
nvidia-smi -L
nvidia-smi mig -lgi # 列出 GPU instances
nvidia-smi mig -lci # 列出 compute instances（如适用）
观察点：
- 输出中是否出现多个 MIG 设备条目（每个条目是一个“新设备”）
在 Kubernetes 中暴露 MIG 资源
如果你使用 NVIDIA device plugin / GPU Operator，核心是选定 MIG 暴露策略（single 或 mixed），并让节点上报对应资源。
常见的现象是：Node 的 Capacity/Allocatable 会出现类似 nvidia.com/mig-<profile> 的资源项（profile 具体命名依赖实现与配置）。
用一个最小 Pod 验证“按 MIG 设备分配”
以下 YAML 用于验证 Pod 能否按 MIG 设备分配：
apiVersion: v1
kind: Pod
metadata:
name: mig-smoke-test
spec:
restartPolicy: Never
containers:
- name: cuda
image: nvidia/cuda:12.4.1-base-ubuntu22.04
command: ["bash", "-lc", "nvidia-smi && sleep 3600"]
resources:
limits:
# 这里的资源名需要替换成你集群实际暴露的 MIG profile
# 例如 nvidia.com/mig-1g.5gb: 1
nvidia.com/mig-<profile>: 1
观察点：
- Pod 是否被调度到 MIG 节点
- 容器内
nvidia-smi看到的设备是否是 MIG instance - 同一张卡上并行跑多个相同 profile 的 Pod 时，是否表现出更稳定的尾延迟（在后续 Lab 用基准测量）
把 MIG 回填到“决策轴矩阵”
你可以把 MIG 在本书决策轴中先填一个“默认结论”，后续再用实验数据修正：
- 资源单位：离散（profile 驱动），可作为独立设备暴露
- 隔离强度：强（硬件隔离，QoS 更可预测）
- 性能损耗/干扰：干扰显著降低；但不同 profile 的绝对性能上限受切分约束
- 运维重配置成本：高（改模式/几何通常要求无用户负载，可能需 cordon/drain，部分环境需重启）
- 兼容性/侵入性：对应用相对透明（像“拿到一块小 GPU”），但对平台治理模型要求更高
- 异构扩展路径：适合用 nodepool/标签把几何形状固化为“节点属性”
总结
MIG 不是“通用 GPU 共享”的终点，而是一个非常清晰的工程选择：
- 当你的首要目标是隔离与可预测性：MIG 常是最省心的硬件路径。
- 当你的首要目标是极致弹性与细粒度分配：MIG 的离散 profile 与重配成本会成为结构性瓶颈。
在本书后续章节，我们会用同一组决策轴去对比：MIG、HAMi（软件级 vGPU/共享）、以及 time-slicing 等机制，并在你的两台 A100 环境上做可复现实验，把“直觉判断”变成“可验收结论链”。