NVIDIA MIG 多租户推理实战：在隔离性、碎片率与调度复杂度之间寻找最优解

问题背景：当 GPU 成为"超售"的重灾区

在承载数百个在线推理服务的多租户平台中，我们面临一个经典困境：单个 A100-80GB GPU 上跑一个 7B 参数的 LLM 服务，显存占用仅 16GB，计算单元利用率不到 15%，但为了避免邻居效应（Noisy Neighbor）导致的 P99 延迟抖动，工程师往往被迫选择独占整张卡。这种资源浪费在规模化场景下不可接受。

NVIDIA Multi-Instance GPU (MIG) 技术通过硬件级隔离提供了看似完美的解决方案，但生产实践告诉我们：MIG 不是银弹，而是一套需要精确计算取舍的工程学博弈。

MIG 的核心能力与隐藏成本

MIG 将物理 GPU 划分为最多 7 个独立实例（以 A100-40GB 为例），每个实例拥有：

• 独占的计算单元（SM 分区，非虚拟化）
• 独立的显存控制器与带宽（关键 QoS 保障）
• 故障隔离域（实例崩溃不影响其他分区）

但代价同样明显：

1. 静态配置刚性：修改切分策略需要重置 GPU（约 2-5 秒中断，影响所有实例）
2. 拓扑约束：7g 模式（全卡）与 1g.5gb×7 模式互斥，且切换需重建
3. 显存碎片：MIG 实例的显存分配是物理连续的，非按需分配

三角平衡：隔离性 vs 碎片率 vs 调度复杂度

维度一：算力隔离的刚性需求

对于在线推理（特别是延迟敏感型服务），MIG 的硬件隔离是唯一能满足 <5ms 抖动要求的方案。实测数据显示：

• MPS（Multi-Process Service）：共享计算单元，P99 延迟抖动可达 20-40ms（当批处理大小差异显著时）
• MIG 硬隔离：P99 抖动控制在 <2ms，接近物理独占卡表现

工程决策点：只有对延迟 SLA 要求 >50ms 的离线批处理任务，才考虑退回到 MPS 或时间切片（Time Slicing）以换取更高灵活性。

维度二：资源碎片率的量化陷阱

A100-40GB 的典型切分方案对比：

关键发现：当平台同时存在 1g.5gb（小模型）和 3g.20gb（大模型）需求时，静态拓扑会导致 20-30% 的显存碎片。这要求我们必须在调度层引入"实例合并"（Defragmentation）策略。

维度三：调度系统的工程复杂度

Kubernetes 场景下的实现路径：

方案 A：静态 MIG 分区（Static Partitioning）

• 提前将节点划分为 mig-1g.5gb 标签的节点池和 mig-3g.20gb 节点池
• 优点：调度简单（标准 Extended Resources），无运行时开销
• 缺点：资源僵化，无法应对流量突发；碎片率随时间递增

方案 B：动态 MIG 重配置（Dynamic Reconfiguration）

• 通过 nvidia-smi mig -cgi 动态创建/销毁实例
• 优点：资源弹性接近 VM 级别
• 缺点：
  • 重建延迟 2-5s（对在线服务不可接受）
  • 需要维护复杂的实例状态机
  • GPU Operator v23.03+ 才支持有限度的动态配置

方案 C：混合调度（Hybrid Scheduling）

• 基础层：MIG 提供硬隔离保障（1g/2g/3g 静态池）
• 突发层：同一 MIG 实例内通过 CUDA MPS 承载多个同优先级服务
• 离线层：夜间低峰期通过时间切片（Time Slicing）超售

推荐架构：

# 节点拓扑感知调度示例
spec:
  nodeSelector:
    nvidia.com/gpu.product: A100-SXM4-40GB
  resources:
    limits:
      nvidia.com/mig-2g.10gb: 1  # 硬隔离保障 QoS
  annotations:
    nvidia.com/time-slicing.replicas: "2"  # 仅在 2g.10gb 内部超售离线任务

工程实践中的关键取舍

取舍 1：显存 vs 算力的匹配错位

许多团队按显存需求切分 MIG，却忽略算力配比。A100 的 1g 实例仅包含 10 SM（Streaming Multiprocessors），而 3g 实例包含 28 SM。若将计算密集型小模型（如 ViT）放入 1g 实例，即使显存充足，吞吐量也会下降 60%。

建议：建立 "算力密度"（TFLOPS/GB） 指标，高算力密度任务优先分配大 MIG 实例，而非按显存简单匹配。

取舍 2：冷启动延迟与资源预占

MIG 实例的创建延迟（2-5s）对于 Serverless 推理场景过长。实践中采用 "预热池"（Warm Pool） 策略：

• 维护 10-15% 的 GPU 容量作为未绑定 MIG 配置的"裸卡"
• 根据队列深度动态实例化（Instantiation），而非按需创建
• 牺牲部分资源利用率换取 100ms 级别的调度延迟

取舍 3：故障域的粒度控制

MIG 实例的故障隔离是双刃剑：当某个 1g 实例因 OOM 崩溃时，其他 6 个实例正常，但整张卡的健康检查会变得复杂。建议：

• 在 DCGM（Data Center GPU Manager）中配置 MIG 级别的监控
• 避免在单张 GPU 上混合部署不同重要等级的服务（如核心支付风控与实验性推荐模型）

落地 checklist

1. 基准测试：在目标 GPU 型号上测试 1g.5gb, 2g.10gb, 3g.20gb 对你的模型推理吞吐的影响，建立性能基线
2. 碎片阈值设定：当节点碎片率 >15% 时，触发实例迁移与合并（需评估迁移成本）
3. 降级策略：MIG 配置失败时，自动回退到 MPS 或独占 GPU，避免调度死锁
4. 版本锁定：MIG 与驱动版本强相关，生产环境建议固定 NVIDIA Driver 535/550 LTS 分支与 GPU Operator 23.9.x

结论

MIG 技术为多租户推理平台提供了硬件级隔离的可能性，但其价值不在于技术先进性，而在于对业务负载特征的精确匹配。在工程实现上，建议采用"静态 MIG 分区为主，时间切片超售为辅"的混合架构，接受 10-15% 的资源碎片作为隔离性的必要成本，同时通过智能调度将碎片率控制在可接受范围内。对于延迟不敏感的离线任务，MPS 仍然是更轻量的选择——没有最好的技术，只有最适合当前 SLI 的妥协。