K8s 混合调度 MIG 与 MPS 的终极实践：把 GPU 榨出最后一滴油水

在 AI 推理服务的生产环境中，最让基础设施团队头疼的，莫过于 “显存闲置” 与 “算力浪费”。

普通的 AI 推理任务（尤其是中小模型、NLP 分类、OCR、语音识别等）往往呈现“高频、低延迟、低 GPU 利用率”的特点。如果给每个容器分配一张独占 GPU，利用率可能只有 10%~20%，资金成本直接爆炸；如果用纯粹的软切分或时间片轮转，又极易因“邻居干扰（Noisy Neighbor）”导致 P99 延迟突破天际，甚至因一个容器爆显存导致整张物理卡上的服务全部“连坐”挂掉。

为了解决这个问题，NVIDIA 提供了两种核心共享技术：

1. MIG (Multi-Instance GPU)：硬件级硬隔离。将一张物理卡划分成多个独立的 GPU 实例，每个实例拥有专属的 SM（流处理器）和显存，安全、稳定，但划分粒度粗（比如 A100 最多切 7 块）。
2. MPS (Multi-Process Service)：多进程服务。多个进程共享同一块 GPU 的算力和显存，通过 CUDA 上下文过滤实现软隔离，利用率极高，但缺乏强力的显存硬件防线，一个进程 OOM 可能会波及同台其他进程。

小孩子才做选择，成熟的平台架构师全都要：在 K8s 中，将 MIG 的“硬隔离”与 MPS 的“高密度”嵌套结合——先用 MIG 把物理卡切成几个大块（实现业务/部门间的硬安全隔离），再在每个 MIG 实例内部启用 MPS（实现单个业务内多个副本的极致并发）。

本文将手把手带你打通 K8s 上同时调度与配置 MIG 与 MPS 的生产级链路。

一、 为什么是“MIG + MPS”双剑合璧？

我们先看一张对比表，理解为什么要将二者嵌套：

通过 “MIG + MPS”，你可以实现：

• 业务线隔离：将 A100 (80GB) 划分为两个 3g.40gb 的 MIG 实例。部门 A 和部门 B 各占一个，互不干扰，即使部门 A 的代码写炸了导致显存溢出，部门 B 也毫无感知。
• 极致性价比：在部门 A 的 3g.40gb 实例内部，启用 MPS，将其进一步虚拟化为 8 个虚拟 Pod，每个 Pod 限制使用 5GB 显存。原本只能跑 1 个 Pod 的通道，现在塞下了 8 个实例，吞吐量直接翻倍。

二、 核心架构设计

在 K8s 中，要让这一套体系丝滑运转，我们需要依赖 NVIDIA 的官方技术栈：NVIDIA GPU Operator、MIG Parted，以及支持 MPS 资源声明的 Device Plugin。

架构拓扑如下：

+-----------------------------------------------------------------------------------+
|                               Physical GPU (e.g., A100 / H100)                    |
+----------------------------------------+------------------------------------------+
                                         |
               +-------------------------+-------------------------+
               | (MIG Slicing by mig-parted)                       |
               v                                                   v
+-----------------------------------------+ +---------------------------------------+
|          MIG Instance 1 (e.g., 3g.40gb) | |        MIG Instance 2 (e.g., 3g.40gb) |
+-----------------------------------------+ +---------------------------------------+
|  MPS Control Daemon (MIG 1)             | |  MPS Control Daemon (MIG 2)           |
|  +-----------------------------------+  | |  +---------------------------------+  |
|  | Pod A1 (5GB)  | Pod A2 (5GB)      |  | |  | Pod B1 (10GB) | Pod B2 (10GB)   |  |
|  | (CUDA_MPS_...) | (CUDA_MPS_...)   |  | |  | (CUDA_MPS_...) | (CUDA_MPS_...) |  |
|  +-----------------------------------+  | |  +---------------------------------+  |
+-----------------------------------------+ +---------------------------------------+

三、 实战：一步步在 K8s 中配置部署

Step 1: 物理卡 MIG 动态切分

首先，我们需要在宿主机上启用 MIG，并定义切分规则。通过 nvidia-mis-manager（或 GPU Operator 中的 mig-parted 配置）进行切分。

定义 mig-cfg.yaml 配置文件：

version: v1
mig-configs:
  all-a100-80gb:
    - devices: [all]
      mig-enabled: true
      mig-devices:
        "3g.40gb": 2 # 将 A100-80GB 对半切分为两个 3g.40gb 实例

应用此配置后，通过 nvidia-smi 可以看到物理卡已被划分为两个独立的 MIG 3g.40gb 实例，它们在内核驱动层面拥有完全独立的 PCIe 地址空间。

Step 2: 部署并配置 NVIDIA GPU Operator

使用 Helm 部署 GPU Operator，核心在于同时开启 MIG 和共享（Sharing）模式。自 GPU Operator v23.9.0 起，官方对 MPS 的支持大为改观。

创建 Helm 的 values.yaml 自定义配置文件：

# values.yaml
mig:
  strategy: mixed # 混合模式，允许节点上同时存在物理卡和 MIG 实例

devicePlugin:
  enabled: true
  config:
    name: mps-shared-config

# 定义共享策略，在 MIG 实例之上启用 MPS
gfd:
  enabled: true # GPU Feature Discovery，用于给节点打标

通过 ConfigMap 定义名为 mps-shared-config 的共享策略：

apiVersion: v1
kind: ConfigMap
metadata:
  name: mps-shared-config
  namespace: gpu-operator-resources
data:
  sharing-config.yaml: |
    version: v1
    sharing:
      mps:
        resources:
          - name: nvidia.com/mig-3g.40gb
            replicas: 10 # 允许将每个 3g.40gb 实例最多分给 10 个 Pod 共享

原理解析：这里的 replicas: 10 非常关键。它告诉 K8s 调度器：每一个 nvidia.com/mig-3g.40gb 资源在逻辑上可以被当做 10 个虚拟单位进行分配。当 Pod 请求该资源时，GPU Operator 会在容器启动前自动注入 MPS 环境变量，并挂载对应的 MPS Control Daemon 管道。

Step 3: 在 Pod 级别配置 MPS 显存与算力硬限制

如果不对 MPS 容器做任何限制，所有的 Pod 都会默认去抢占这整个 MIG 实例的所有显存。为了防止“一鸟死，全家灭”的惨剧，必须在 Pod 声明中，通过环境变量精准限制每个 Pod 的显存上限和算力比例。

下面是一个生产级 AI 推理 Pod 的 YAML 声明：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ml-inference-service-dept-a
  namespace: ai-platform
spec:
  replicas: 4 # 部署 4 个副本，它们将共享同一个 MIG 实例
  selector:
    matchLabels:
      app: ml-inference
  template:
    metadata:
      labels:
        app: ml-inference
    spec:
      containers:
      - name: inference-container
        image: pytorch/pytorch:2.0.1-cuda11.7-cudnn8-runtime
        command: ["python", "app.py"]
        env:
        # 1. 限制显存使用绝对值：单位为字节 (例如限制为 5GB = 5368709120 字节)
        # 这能强力防止 PyTorch 默认初始化抢占全部显存导致的 OOM
        - name: CUDA_MPS_ACTIVE_THREAD_PERCENTAGE
          value: "30" # 限制该 Pod 最多使用该 MIG 实例 30% 的 SM 算力
        - name: CUDA_MPS_PINNED_DEVICE_MEM_LIMIT
          value: "0:5G" # 限制 0 号设备（即分配给它的 MIG 实例）显存上限为 5GB
        
        resources:
          limits:
            nvidia.com/mig-3g.40gb: "1" # 请求 1 个虚拟 MPS 份额
          requests:
            nvidia.com/mig-3g.40gb: "1"

参数深度拆解：

• nvidia.com/mig-3g.40gb: "1"：这向调度器申请了该 MIG 实例 1/10 的分配入场券。
• CUDA_MPS_ACTIVE_THREAD_PERCENTAGE = 30：限制该 Pod 内部硬件线程占用的最大百分比，实现算力维度的硬隔离。如果不设，高负载 Pod 会挤占低负载 Pod 的算力，导致推理延迟产生波动（Jitter）。
• CUDA_MPS_PINNED_DEVICE_MEM_LIMIT = 0:5G：限制 0 号设备（这里对应被映射进去的那个 MIG 实例）能申请的物理显存上限。一旦代码试图申请超过 5GB 显存，CUDA 会直接返回 out of memory，而不会破坏同个 MIG 实例下其他正在运行的容器。这就完美解决了传统 MPS 最大的安全隐患。

四、 调度避坑指南：如何避免 K8s “瞎调度”？

当我们在集群中既有普通 GPU，又有 MIG，还有启用了 MPS 的 MIG 时，默认的 K8s Scheduler 很容易把不相干的 Pod 调度到同一个实例上，导致资源碎片。

1. 节点标签与亲和性（Affinity）

确保你的推理 Pod 带有明确的节点选择器，只调度到“已经开启了嵌套虚拟化”的节点。
GPU Feature Discovery 会自动为节点打标，利用好这些 Label：

nodeSelector:
  nvidia.com/gpu.family: ampere # 锁定 Ampere 架构（如 A100）
  nvidia.com/mig.config: all-a100-80gb

2. 避免跨 MIG 实例的“软脏数据”

虽然 MPS 提供了内存隔离，但多个 Pod 共享同一个 MPS 守护进程时，由于 CUDA Context 的切换，冷启动时可能会有微弱的时延。

• 最佳实践：建议将同一种业务、同一种模型的 Pod 副本，调度到同一个 MIG 实例内。这样即使有轻微的 CPU/GPU 缓存共享，也是针对相同模型的权重，反而能够提升推理的 Hit Rate。
• 可以通过 K8s 的 podAntiAffinity（Pod 反亲和性） 或者 Volcano 等高级调度器，实现“在单个 MIG 实例内，尽量紧凑堆叠同类业务，不同业务打散到不同 MIG”的精准调度策略。

五、 性能与性价比收益实测

我们在某 AI 公司的线上多路视频分析推理场景中，对该方案进行了长达一个月的灰度测试。

• 物理硬件：NVIDIA A100 80GB PCIe 一张。
• 原方案：不切分，纯用 K8s GPU Share（基于时间片轮转），单卡跑 4 个大模型推理 Pod。
• 新方案：切分为两个 3g.40gb MIG 实例。每个实例内部运行一个 MPS Daemon，并各自塞入 8 个 Pod（共 16 个 Pod）。每个 Pod 限制 4.5GB 显存与 12% 算力。

测试数据对比：

为什么延迟反而降低了？
因为在纯软件共享或时间片轮转中，CUDA 上下文频繁切换（Context Switch）开销极大。而 MPS 允许多个容器的 CUDA 内核并行跑在同一个 GPU 的不同 SM 上，省去了上下文切换的昂贵代价，使得整体吞吐和延迟曲线异常丝滑。

六、 总结与生产避坑总结

把 GPU 榨干是一门艺术，但在生产环境，“稳”字永远大于一切。在落地 MIG + MPS 架构时，切记以下三条硬法则：

1. 显存限制是生命线：千万不要省略 CUDA_MPS_PINNED_DEVICE_MEM_LIMIT，否则一旦发生内存越界，由于 MPS 机制，整张 MIG 实例上的所有 Pod 都会瞬间收到 Error: Gpu Assist Page Fault 进而崩溃。
2. 监控指标要跟上：传统的 nvidia-smi 只能看到物理卡总用量，无法看清 MPS 内部的资源争抢。必须在 Prometheus 中接入 dcgm-exporter，采集 nv_gpu_memory_used_bytes 和 nv_gpu_utilization，精确监控每一个虚拟 GPU 容器的画像。
3. 冷启动与预热：MPS 环境下，首个 Pod 启动拉起 MPS Daemon 时会有 1~2 秒的初始化延迟。建议在推理服务中加入 Liveness / Readiness Probe（健康检查探针），确保容器真正就绪后再接入线上流量。

通过这套架构，你可以彻底告别“空置的显存”，在保障业务 SLA 的同时，让老板在看账单时露出满意的微笑。