NVIDIA MIG 深度实战：GPU 硬件分区、Kubernetes 多租户调度与 AI 推理优化

一、从"GPU 独占"到"弹性共享"——AI 推理的多租户困局

2026 年的 AI 推理基础设施面临一个结构性矛盾：模型越来越大，但单卡 GPU 的利用率在多数场景下不足 40%。一组来自生产环境的数据显示，中小模型推理（7B-13B 参数）在 A100 80GB 上的典型 GPU 利用率仅为 25%-35%，显存占用不到 40GB。这意味着 60% 以上的硬件资源处于闲置状态。

传统的 GPU 共享方案有三种路径，各有缺陷：

• Time-Slicing（时间分片）：多个进程交替使用 GPU，通过 CUDA Context Switching 切换，但显存不隔离，一个进程 OOM 会影响所有进程；
• vGPU（虚拟 GPU）：NVIDIA GRID/vGPU 方案需要昂贵的许可证（vWS/vCS），且主要面向图形虚拟化场景，推理场景性价比低；
• MPS（Multi-Process Service）：允许多个进程并发执行 kernel，但共享 SM 和显存，隔离性差，调试困难。

NVIDIA MIG（Multi-Instance GPU）从硬件层面解决了这些问题：它将一块物理 GPU 切分为多个完全隔离的 GPU 实例，每个实例拥有独立的 SM 集群、显存、L2 Cache 和片上交叉开关（crossbar），实现了真正的故障隔离和 QoS 保障。

二、MIG 硬件分区原理：从 SM 切片到内存控制器

2.1 Ampere 及后续架构的硬件支撑

MIG 在 NVIDIA A100（Ampere 架构）上首次引入，并在 H100/H200（Hopper）和 B200（Blackwell）上持续演进。其硬件基础是 GPU 内部流媒体多处理器（SM）的可分区设计。

以 A100 80GB 为例，它包含 108 个 SM，分为 7 个 GPC（Graphics Processing Cluster），每个 GPC 包含 14-16 个 SM，并通过片上网络（NoC）连接到 8 个 10GB 的 HBM2e 内存控制器。MIG 的分区正是在这个硬件拓扑上进行的。

┌─────────────────────────────────────────────────────┐ │                 NVIDIA A100 (80GB)                  │ │  ┌─────┬─────┬─────┬─────┬─────┬─────┬─────┐      │ │  │GPC 0│GPC 1│GPC 2│GPC 3│GPC 4│GPC 5│GPC 6│      │ │  │14SM │14SM │14SM │14SM │14SM │12SM │14SM │      │ │  └──┬──┴──┬──┴──┬──┴──┬──┴──┴──┬──┴──┬──┴──┬──┘      │ │     │     │     │     │        │     │     │         │ │  ┌──┴─────┴─────┴─────┴────────┴─────┴─────┴──┐     │ │  │            Crossbar (片上网络)              │     │ │  └──┬─────┬─────┬─────┬────────┬─────┬─────┬──┘     │ │     │ MC0 │ MC1 │ MC2 │  MC3   │ MC4 │ ... │         │ │     │10GB │10GB │10GB │ 10GB   │10GB │     │         │ │     └─────┴─────┴─────┴────────┴─────┴─────┘         │ └─────────────────────────────────────────────────────┘ 

2.2 MIG 实例类型与几何配置

MIG 实例的命名规则为 {gpu_count}g.{memory_count}gb，其中 g 代表 GPU 实例包含的 SM 分组数量。注意：1 GPC 不等于 1g，1g 对应 1个 GPC（即约 14 个 SM），但实际配置取决于具体 GPU SKU。

A100 80GB 支持的 MIG Profile：

H100 80GB 的增强配置：

> 关键特性：MIG 实例之间具有故障隔离——一个实例的 kernel 崩溃不会影响其他实例，且每个实例在系统中表现为独立的 PCIe 设备（独立的 BDF 地址）。

2.3 分区设置的持久化与转换成本

MIP 分区配置通过 nvidia-smi mig 命令管理。需要注意的是，MIG 模式切换需要 GPU 重置（类似 NCCL 的通信组销毁），这意味着：

# 启用 MIG 模式（需要重置所有 GPU 上的进程） sudo nvidia-smi -mig 1
# 创建 GPU 实例 (GI) sudo nvidia-smi mig -cgi 19,19,19 -C # 19 是 1g.5gb 的 profile ID，这里创建 3 个实例
# 销毁 GPU 实例 sudo nvidia-smi mig -dci sudo nvidia-smi mig -dgi 

在实际运维中，MIG 切换的代价不可忽视：所有运行中的 CUDA 进程必须停止，NCCL 通信组解散。因此生产环境中通常是在节点初始化时就确定 MIG 配置，而非动态切换。

三、Kubernetes 中的 MIG 实战：GPU Operator MIG Manager

3.1 部署架构

Kubernetes 通过 NVIDIA GPU Operator 自动化管理 MIG 配置，其核心组件包括：

• NVIDIA Device Plugin：向 kubelet 暴露 MIG 实例作为可扩展资源（如 nvidia.com/mig-1g.5gb: 7）
• NVIDIA GPU Feature Discovery (GFD)：自动标记节点上的 MIG 配置
• MIG Manager：在节点上执行 MIG 配置操作（创建/销毁 GI/CI）
• DCGM Exporter：暴露 GPU 监控指标到 Prometheus

# values.yaml - GPU Operator MIG 配置 mig: strategy: mixed  # single 或 mixed migManager: enabled: true config: default: all-1g.5gb nodes:

name: "gpu-node-01"

config: default: all-3g.40gb 

3.2 MIG 策略配置

GPU Operator 提供两种 MIG 策略：

• Single Strategy：同一节点上所有 GPU 使用相同的配置
• Mixed Strategy：不同 GPU 可以使用不同的 MIG Profile

# 自定义 MIG 配置 ConfigMap apiVersion: v1 kind: ConfigMap metadata: name: mig-parted-config data: config.yaml: | version: v1 mig-configs: all-1g.5gb:

devices: all

mig-enabled: true mig-devices: "1g.5gb": 7 infer-2g-mix:

devices: 0

mig-devices: "2g.10gb": 3

devices: 1

mig-devices: "1g.5gb": 7 

3.3 Pod 请求 MIG 资源

部署推理服务时，Pod 通过资源请求指定 MIG 实例：

apiVersion: apps/v1 kind: Deployment metadata: name: llm-inference-mig spec: replicas: 7 selector: matchLabels: app: llm-inference template: metadata: labels: app: llm-inference spec: containers:

name: vllm

image: vllm/vllm-openai:latest resources: limits: nvidia.com/mig-1g.5gb: 1 requests: nvidia.com/mig-1g.5gb: 1 ports:

containerPort: 8000

env:

name: CUDA_VISIBLE_DEVICES

valueFrom: fieldRef: fieldPath: spec.containers[0].resources.limits command: ["python", "-m", "vllm.entrypoints.openai.api_server"] args:

--model
"meta-llama/Llama-3-8B-Instruct"
--max-model-len
"4096"
--gpu-memory-utilization
"0.85"

四、AI 推理场景下的 MIG 性能调优

4.1 模型 Profile 与 MIG 实例选择

不同推理模型对 GPU 资源的需求差异巨大，选择合适的 MIG Profile 可以最大化硬件利用率：

> 实测数据：在 H100 SXM5 上运行 Llama-3-8B-Instruct，1g.10gb 实例的 FP16 吞吐约为 380 tok/s，相比全卡部署（约 2800 tok/s），7个实例的总吞吐可达 2660 tok/s，达到全卡利用率的 95%。

4.2 KV Cache 与显存分配的精细控制

MIG 实例的显存是硬隔离的，这意味着需要精确配置推理框架的 KV Cache 分配：

# vLLM 配置示例：针对 MIG 1g.10gb 实例 from vllm import EngineArgs, LLMEngine
engine_args = EngineArgs( model="meta-llama/Llama-3-8B-Instruct", max_model_len=4096, gpu_memory_utilization=0.90,  # 利用 9GB/10GB，留 1GB 余量 enforce_eager=False,           # 允许 CUDA Graph 加速 max_num_seqs=16,               # 限制并发 batch 数 enable_chunked_prefill=True,   # 使用分块预填充减少峰值内存 )
engine = LLMEngine.from_engine_args(engine_args) 

关键调优参数：

• gpu_memory_utilization：MIG 实例由于硬隔离没有 OOM 缓冲，建议设置为 0.85-0.92
• max_num_seqs：需要根据显存和 KV Cache 大小计算，公式约为：max_seqs = gpu_memory / (2 num_layers hidden_size * seq_len / 1024^3)
• enable_chunked_prefill：分块预填充可以显著降低峰值显存，对 MIG 小实例尤为重要

4.3 多实例服务架构设计

在实际生产环境中，MIG 多实例的典型架构是"一模型多副本"：

┌─────────────────┐ │   Load Balancer │ │  (nginx/traefik) │ └────────┬────────┘ │ ┌───────────────────┼───────────────────┐ │                   │                   │ ┌────▼────┐        ┌────▼────┐        ┌────▼────┐ │ MIG 0   │        │ MIG 1   │        │ MIG 2   │ │ Llama-8B│        │ Llama-8B│        │ Llama-8B│ │ :8000   │        │ :8000   │        │ :8000   │ └─────────┘        └─────────┘        └─────────┘ 

使用 KServe 或 Seldon Core 时，MIG 实例可以无缝集成：

apiVersion: serving.kserve.io/v1beta1 kind: InferenceService metadata: name: llama-mig spec: predictor: minReplicas: 3 maxReplicas: 7 model: modelFormat: name: huggingface storageUri: s3://models/llama-3-8b resources: limits: nvidia.com/mig-1g.5gb: 1 containerConcurrency: 4 timeout: 60 

五、生产级监控与故障排查

5.1 DCGM 指标采集

NVIDIA Data Center GPU Manager (DCGM) 为 MIG 实例提供细粒度的监控指标。在 Kubernetes 中通过 DCGM Exporter 暴露到 Prometheus：

# Prometheus 采集配置 scrape_configs:

job_name: 'nvidia-dcgm'

kubernetes_sd_configs:

role: endpoints

relabel_configs:

source_labels: [__meta_kubernetes_label_app_kubernetes_io_name]

regex: nvidia-dcgm-exporter action: keep 

关键 MIG 监控指标：

5.2 常见问题排查

问题 1：MIG 实例无法被 kubelet 识别

# 检查 MIG Manager 日志 kubectl -n gpu-operator logs -l app=nvidia-mig-manager
# 检查 GFD 标签 kubectl get node