Kubernetes GPU 共享方案对比时间片 vs MIG vs MPS一、三个方案摆在面前选型不看差异表就是在赌GPU 共享不是要不要的问题而是选哪个的问题。在 AI 推理平台上独占 GPU 的利用率不到 30% 是不可接受的浪费但升级到共享方案时NVIDIA 提供了三种主要方式时间片Time-Slicing、MIGMulti-Instance GPU和 MPSMulti-Process Service。每种方案在隔离性、兼容性、改造成本上差异显著。技术选型中最常见的错误是按照功能列表做决策而非按照失败模式做决策。选型的关键不是方案能做什么而是方案出问题时影响范围有多大。基础设施不需要漂亮话GPU 共享方案的选型文档里如果只写了优点没写故障模式那不是文档是免责声明。二、三种方案的架构差异与隔离能力模型从隔离性的维度看MIG MPS Time-Slicing。从改造成本看Time-Slicing MIG MPS。这三个维度的交叉构成了选型矩阵。graph TB subgraph Time-Slicing: 复用 SM 时间 TS_GPU[物理 GPU] TS_Sched[CUDA Time-Slice Scheduler] TS_A[容器 Abr/时间片 1] TS_B[容器 Bbr/时间片 2] TS_C[容器 Cbr/时间片 3] TS_D[容器 Dbr/时间片 4] TS_Note[隔离: 无br/故障域: 整卡br/显存: 共享无限制br/改造: 零成本br/兼容: 所有 GPU] TS_GPU -- TS_Sched TS_Sched -- TS_A TS_Sched -- TS_B TS_Sched -- TS_C TS_Sched -- TS_D end subgraph MPS: 复用 CUDA Context MPS_GPU[物理 GPU] MPS_Daemon[MPS Serverbr/守护进程] MPS_Ctx[CUDA Contextbr/共享地址空间] MPS_A[Client Abr/逻辑 CUDA Stream A] MPS_B[Client Bbr/逻辑 CUDA Stream B] MPS_C[Client Cbr/逻辑 CUDA Stream C] MPS_Note[隔离: 逻辑流隔离br/故障域: 整卡br/显存: 共享无限制br/改造: 环境变量br/兼容: 所有 GPUbr/IPC: 支持] MPS_GPU -- MPS_Daemon MPS_Daemon -- MPS_Ctx MPS_Ctx -- MPS_A MPS_Ctx -- MPS_B MPS_Ctx -- MPS_C end subgraph MIG: 硬件分区 MIG_GPU[物理 A100 GPU] MIG_Ctrl[MIG 硬件分区控制器] MIG_GI0[GI 0: 3g.40gbbr/独立显存/缓存] MIG_GI1[GI 1: 2g.20gbbr/独立显存/缓存] MIG_GI2[GI 2: 1g.10gbbr/独立显存/缓存] MIG_Note[隔离: 硬件隔离br/故障域: 仅当前 GIbr/显存: 固定分区br/改造: 需重启br/兼容: A100/A30/H100br/IPC: 不支持] MIG_GPU -- MIG_Ctrl MIG_Ctrl -- MIG_GI0 MIG_Ctrl -- MIG_GI1 MIG_Ctrl -- MIG_GI2 end style TS_Note fill:#ffcdd2,color:#333 style MPS_Note fill:#fff9c4,color:#333 style MIG_Note fill:#c8e6c9,color:#333 classDef ts fill:#ffcdd2,color:#333,stroke:#d32f2f classDef mps fill:#fff9c4,color:#333,stroke:#f9a825 classDef mig fill:#c8e6c9,color:#333,stroke:#388e3c class TS_A,TS_B,TS_C,TS_D,TS_Sched ts class MPS_A,MPS_B,MPS_C,MPS_Daemon,MPS_Ctx mps class MIG_GI0,MIG_GI1,MIG_GI2,MIG_Ctrl migTime-Slicing 深入时间片方案依赖 CUDA Time-Slice SchedulerNVIDIA 驱动 R450通过 GPU Operator 在 Device Plugin 层做 GPU 复制。每张物理 GPU 被复制为 N 个逻辑设备Kubernetes 看到 N 个nvidia.com/gpu。CUDA Context 仍然独立但 SM 的执行时间被切分成固定时长的时间片通常 100ms轮转分配给不同 CUDA Context。关键局限时间片长度固定短 Kernel 完成后时间片不会提前释放。这意味着即使用户只提交 1ms 的 Kernel也需要等完整时间片到期后下一用户才能使用 GPU。时间片太短则上下文切换开销占比增大约 2-3% 切换损耗。MPS 深入MPS 本质是将多个 CUDA 进程的 Kernel 提交合并到一个 CUDA Context 中由一个 MPS Server 进程统一管理 GPU 的执行调度。这样一来不同进程的 Kernel 可以在 SM 级别并发执行——进程 A 的 Kernel 用部分 SM进程 B 的 Kernel 同时用另一部分 SM实现空间维度的并发而非时间片的时间维度。MPS 的隔离性优于时间片但弱于 MIG。一个进程的 Kernel 如果导致 GPU 异常如非法内存访问会影响 MPS Server 进程进而影响所有连接的 Client。这种故障传播是 MPS 方案在多租户平台中的主要风险。MIG 深入MIG 是唯一硬件级别的隔离方案。GPU 内部的计算单元和显存通道被物理切分通过 PCIe 对外呈现为独立设备。操作系统视角是多个 GPU容器运行时视角也是多个 GPU。MIG 的配置需要重启 GPU切换 MIG Mode且 Profile 创建后无法动态调整。三、三种方案的生产级配置示例Time-Slicing 配置GPU Operator 方式# time-slicing.yaml — GPU Operator 时间片配置 apiVersion: v1 kind: ConfigMap metadata: name: time-slicing-config-all namespace: gpu-operator data: any: |- version: v1 sharing: timeSlicing: resources: - name: nvidia.com/gpu replicas: 4 # 每张物理 GPU 注册 4 个逻辑 GPUMPS 配置环境变量方式容器内无需额外守护进程GPU Operator 自动管理 MPS Daemon# mps-pod.yaml — 启用 MPS 的推理 Pod apiVersion: v1 kind: Pod metadata: name: inference-mps spec: containers: - name: vllm image: vllm/vllm-openai:latest env: - name: CUDA_MPS_PIPE_DIRECTORY value: /tmp/nvidia-mps - name: CUDA_MPS_LOG_DIRECTORY value: /tmp/nvidia-log resources: limits: nvidia.com/gpu: 1 volumeMounts: - name: mps mountPath: /tmp/nvidia-mps - name: mps-log mountPath: /tmp/nvidia-log volumes: - name: mps hostPath: path: /tmp/nvidia-mps - name: mps-log hostPath: path: /tmp/nvidia-logMIG 配置手动创建 GI/CI// mig_provisioner.go — MIG 自动配置器 // 在 GPU 节点初始化时自动创建 MIG 分区 // 策略totalVRAM80GB → 3g.40gb 2g.20gb 1g.10gb 1g.10gb (或待分配) package main import ( context fmt time ) // MIGProfilePlan 定义一个 MIG 分区规划 type MIGProfilePlan struct { Profiles []string // 如 [3g.40gb, 2g.20gb, 1g.10gb, 1g.10gb] } // PlanMIGLayout 根据 GPU 总显存规划 MIG 分区 // 注意A100-80GB 的总显存为 80GB但 MIG Profile 的显存为分配保证值 // 实际可分配的组合受硬件限制 func PlanMIGLayout(totalVRAMGB int) (*MIGProfilePlan, error) { switch { case totalVRAMGB 80: // A100-80GB: 推荐 3g.40gb 2g.20gb 2× 1g.10gb return MIGProfilePlan{ Profiles: []string{3g.40gb, 2g.20gb, 1g.10gb, 1g.10gb}, }, nil case totalVRAMGB 40: // A100-40GB: 推荐 2g.20gb 2× 1g.10gb return MIGProfilePlan{ Profiles: []string{2g.20gb, 1g.10gb, 1g.10gb}, }, nil default: return nil, fmt.Errorf(不支持的 GPU 显存大小: %dGB (需要 ≥ 40GB), totalVRAMGB) } } // ApplyMIGPlan 在 GPU 上创建 MIG 实例 func ApplyMIGPlan(ctx context.Context, gpuIndex int, plan *MIGProfilePlan) error { // 1. 启用 MIG 模式 // nvidia-smi -i gpuIndex -mig 1 // → 需要 GPU reset如果首次启用 // 2. 禁用已有 MIG (清理旧配置) // nvidia-smi mig -i gpuIndex -dci -dgi // → 错误可忽略可能没有旧配置 // 3. 按 Profile 顺序创建 GI 和 CI for i, profile : range plan.Profiles { fmt.Printf(GPU %d: 创建 GI %d → %s\n, gpuIndex, i, profile) // nvidia-smi mig -i gpuIndex -cgi profile -C i // nvidia-smi mig -i gpuIndex -gi giID -cci 1 time.Sleep(500 * time.Millisecond) // 等硬件完成初始化 } return nil }四、选型决策矩阵与混合策略三种方案不是互斥的。在实际集群中可以按节点组使用不同方案维度Time-SlicingMPSMIG隔离强度无逻辑流级别硬件级别故障爆炸半径整卡整卡单个 GI显存隔离无无固定分区GPU 兼容性所有 NVIDIA GPU所有 NVIDIA GPUA100/A30/H100CUDA IPC 支持支持支持不支持改造成本零环境变量重启节点动态调整调整 replicas不适用需重建 GI适用场景开发/测试、低 SLA 推理单租户多模型推理多租户生产推理混合策略推荐H100 节点池 → Time-SlicingH100 尚未完全支持 MIGA100 推理节点池 → MIG多租户需要硬件隔离A100 训练节点池 → 独占训练不共享 GPU开发/测试环境 → Time-Slicing降低成本故障容忍度高MIG MPS 可以同时使用在每个 MIG GI 内部可以启用 MPS将 GI 的计算资源进一步分配给多个进程。这适用于 GI 内部仍有 SM 资源空余的场景。但显存分区仍然由 MIG 控制MPS 只在 SM 层面做进一步复用。五、总结GPU 共享方案选型的核心原则隔离要求决定选型下线。多租户场景必须用 MIG硬件隔离单租户可用 MPS 或时间片。故障模式比功能列表更重要。选方案时要问这个方案最坏情况下会发生什么而不是这个方案能做什么混合策略是常态不同节点组使用不同共享方案而非全集群统一。时间片是入门、MPS 是中间态、MIG 是终局。从时间片开始试水验证共享方案的延迟影响再根据 SLA 要求升级到 MPS 或 MIG。