容器化推理服务的资源隔离：Kubernetes GPU 调度、MIG 与 CUDA 多进程共享策略

一、一张 GPU 八个容器：资源隔离的正确姿势

在 Kubernetes 中，nvidia.com/gpu: 1 意味着"分配一整张 GPU"。如果推理服务是 Llama-2-7B（14GB 显存）而 GPU 是 A100-80G，那么剩余的 66GB 显存就被浪费了——利用率仅 17.5%。

提升 GPU 利用率的三种策略：

• CUDA MPS（Multi-Process Service）：多进程共享一张 GPU，由 MPS 服务器管理 Context 切换
• MIG（Multi-Instance GPU）：将一张 GPU 硬件切分为多个独立实例，每实例有独立显存、缓存和计算单元
• Time-Slicing：Kubernetes GPU Operator 的简单方案——多个 Pod 时间分片使用一张 GPU

二、三种隔离策略的架构与性能模型

flowchart LR
    subgraph MPS
        M1[Pod A<br/>vLLM Engine] --> MPS_Server[MPS Server<br/>显存共享<br/>计算分时]
        M2[Pod B<br/>vLLM Engine] --> MPS_Server
        MPS_Server --> GPU_MPS[GPU<br/>统一地址空间]
    end

    subgraph MIG
        N1[Pod A<br/>MIG GI 0<br/>20GB 显存] --> GPU_MIG_0[GPU MIG Slice 0]
        N2[Pod B<br/>MIG GI 1<br/>40GB 显存] --> GPU_MIG_1[GPU MIG Slice 1]
        N3[Pod C<br/>MIG GI 2<br/>20GB 显存] --> GPU_MIG_2[GPU MIG Slice 2]
    end

    subgraph TimeSlicing
        T1[Pod A] -->|Time Slice 1| GPU_TS[GPU]
        T2[Pod B] -->|Time Slice 2| GPU_TS
        T3[Pod C] -->|Time Slice 3| GPU_TS
    end

    Note_MPS["MPS: 显存共享 — 无显存保护<br/>MIG: 硬件隔离 — 最安全<br/>TimeSlicing: 最弱隔离 — OOM 风险"]

三种方案的关键差异：

三、Kubernetes MIG 配置实战

# ===== MIG 策略配置 =====
# mig-config.yaml — 定义 GPU 的 MIG 切分配置
apiVersion: v1
kind: ConfigMap
metadata:
  name: mig-config
  namespace: gpu-operator
data:
  config.yaml: |
    version: v1
    mig-configs:
      # A100-80GB 的最优切分方案（用于 7B-13B 推理）
      all-1g.20gb:
        - devices: all
          mig-enabled: true
          mig-devices:
            "1g.20gb": 4  # 切成 4 个 1g.20gb 实例

      # 混合切分：1 个 40GB + 2 个 20GB
      mixed-inference:
        - devices: all
          mig-enabled: true
          mig-devices:
            "2g.40gb": 1
            "1g.20gb": 2
---
# ===== GPU Operator 配置 =====
# 启用 MIG 策略和 Time-Slicing 支持
apiVersion: v1
kind: ConfigMap
metadata:
  name: device-plugin-config
  namespace: gpu-operator
data:
  mig-strategy: mixed  # single | mixed
  time-slicing: |
    version: v1
    sharing:
      timeSlicing:
        resources:
          - name: nvidia.com/gpu
            replicas: 4  # 每张 GPU 创建 4 个时间片副本

# ===== 推理服务 Pod 定义 =====
# 使用 MIG 切分后的 GPU 实例
apiVersion: v1
kind: Pod
metadata:
  name: vllm-llama2-7b
spec:
  containers:
  - name: vllm
    image: vllm/vllm-openai:v0.5.0
    resources:
      limits:
        # 请求 1 个 1g.20gb MIG 实例
        nvidia.com/mig-1g.20gb: 1
        memory: "32Gi"
        cpu: "8"
    env:
    - name: CUDA_VISIBLE_DEVICES
      value: "0"  # MIG 实例在容器内显示为独立的 GPU 0
    - name: VLLM_GPU_MEMORY_UTILIZATION
      value: "0.90"
    command:
    - python
    - -m
    - vllm.entrypoints.openai.api_server
    - --model
    - meta-llama/Llama-2-7b-chat-hf
    - --max-model-len
    - "4096"

四、MPS/MIG 的工程陷阱与调优经验

MPS 的显存"多米诺效应"：如果 Pod A 的推理请求突然增多，它可能吞掉 Pod B 的显存空间，导致 Pod B 因 OOM 被 Kill。MPS 没有显存配额机制——它完全信任各个进程。生产环境使用 MPS 时，必须在应用层（而非 GPU 层）做显存限制——通过 VLLM_GPU_MEMORY_UTILIZATION=0.45 来约束每个 vLLM 实例的显存占用。

MIG 的"硬隔离"也是"硬浪费"：切分后每个 MIG 实例的 L2 Cache 和内存带宽独立分配。如果推理服务 A 属于"高计算低带宽"模型，推理服务 B 属于"高带宽低计算"模型，MIG 的均匀切分会导致资源类型不匹配。混合切分配置可以缓解此问题。

NVIDIA Device Plugin 的延迟：当 Pod 创建/销毁时，NVIDIA Device Plugin 需要调用 nvidia-smi 检查 GPU 状态。在高频扩缩容（>10 次/分钟）下，Device Plugin 的响应延迟可能成为瓶颈（单次检查约 1～3 秒）。

五、总结

CUDA MPS 适合"内部多服务共享大 GPU"场景——用应用层显存约束替代硬件隔离；MIG 适合"多租户平台"场景——硬件级别的故障和性能隔离；Time-Slicing 仅适合开发/测试。

生产环境建议：推理中台用 MIG 为不同团队分配隔离的 GPU 资源；单个团队内不同推理服务用 MPS 共享一张 GPU（配合 vLLM 显存限制）。必须用 dcgm-exporter 监控每个 MIG 实例的 SM 利用率和显存占用，建立 per-instance 而非 per-GPU 的告警。