NVIDIA MIG 怎么用于生产：实例划分、隔离与容量规划

NVIDIA Multi-Instance GPU（MIG）可以把受支持的 GPU 划分为多个具有独立计算与显存资源的实例。它适合将一块大 GPU 分配给多个边界清晰的工作负载，但不能替代所有形式的虚拟化，也不会自动解决模型容量、网络带宽和调度公平性。

生产规划应先从作业画像出发，再选择实例规格和数量。为了把 GPU 填满而切出大量小实例，可能造成模型无法放入、显存余量不足或运维复杂度增加。

用真实负载确定实例颗粒度

对每类任务记录显存峰值、持续时间、利用率、并发、启动时间和服务时延。推理服务还要保留上下文长度、批量和流量峰谷；批处理任务则关注队列等待与完成时限。

实例规格需要留出框架、缓存和突发余量，不能用一次空闲测试的最低显存占用作为容量上限。模型频繁变化的团队，应保留少量较大实例或整卡资源池。

配置变化要进入维护流程

MIG 模式和实例布局的变更会影响设备可见性、调度和正在运行的作业。应把目标布局做成版本化配置，明确变更前排空、应用配置、验证设备、恢复服务和失败回滚的顺序。

驱动、容器运行时、调度器和监控组件都要验证 MIG 支持。节点能够识别实例，不代表调度器标签、资源配额和容器设备映射已经正确。

隔离能力仍有边界

MIG 提供硬件层面的资源划分，但生产系统还需要操作系统、容器、存储、网络和身份权限共同隔离。涉及不同信任等级租户时，应由安全团队评估整体边界，而不是只依据 GPU 实例独立。

多个实例共享服务器的 CPU、系统内存、PCIe、网卡和存储出口。高并发数据加载或网络推理可能先争用主机资源，因此容量测试必须在预期并发下进行。

监控与计费按实例口径统一

监控应能关联物理 GPU、MIG 实例、容器、作业和租户，至少记录实例利用率、显存、错误、温度和作业时延。只看物理 GPU 平均利用率，会掩盖单个实例过载或长期闲置。

上线前用代表性任务验证实例创建、调度、故障重启、节点维护和指标采集。容量报告同时给出有效利用、排队时间和无法调度的任务，才能判断切分策略是否真的提高资源效率。

明确哪些任务不进入 MIG 资源池

需要整卡显存、强依赖跨 GPU 通信、对设备拓扑有固定要求或尚未验证 MIG 支持的任务，应保留在独立资源池。把所有节点统一切分会让这类任务失去可调度位置。

资源池边界应随模型和框架版本复核。新任务先在验证节点确认性能、错误处理和监控，再决定是否进入共享池，不用一次成功运行替代持续稳定性验证。