容器化推理服务的资源隔离Kubernetes GPU 调度、MIG 与 CUDA 多进程共享策略一、一张 GPU 八个容器资源隔离的正确姿势在 Kubernetes 中nvidia.com/gpu: 1意味着分配一整张 GPU。如果推理服务是 Llama-2-7B14GB 显存而 GPU 是 A100-80G那么剩余的 66GB 显存就被浪费了——利用率仅 17.5%。提升 GPU 利用率的三种策略CUDA MPSMulti-Process Service多进程共享一张 GPU由 MPS 服务器管理 Context 切换MIGMulti-Instance GPU将一张 GPU 硬件切分为多个独立实例每实例有独立显存、缓存和计算单元Time-SlicingKubernetes GPU Operator 的简单方案——多个 Pod 时间分片使用一张 GPU二、三种隔离策略的架构与性能模型flowchart LR subgraph MPS M1[Pod Abr/vLLM Engine] -- MPS_Server[MPS Serverbr/显存共享br/计算分时] M2[Pod Bbr/vLLM Engine] -- MPS_Server MPS_Server -- GPU_MPS[GPUbr/统一地址空间] end subgraph MIG N1[Pod Abr/MIG GI 0br/20GB 显存] -- GPU_MIG_0[GPU MIG Slice 0] N2[Pod Bbr/MIG GI 1br/40GB 显存] -- GPU_MIG_1[GPU MIG Slice 1] N3[Pod Cbr/MIG GI 2br/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 风险]三种方案的关键差异特性MPSMIGTime-Slicing显存隔离无OOM 互相影响硬件隔离最安全无故障隔离中MPS Server 崩溃影响全部高独立 GI无性能开销低Context 切换 ns 级极低中时间片切换 μs 级GPU 支持A100/A10/V100A100/A30/H100所有 GPU适用场景共享大 GPU容忍 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_UTILIZATION0.45来约束每个 vLLM 实例的显存占用。MIG 的硬隔离也是硬浪费切分后每个 MIG 实例的 L2 Cache 和内存带宽独立分配。如果推理服务 A 属于高计算低带宽模型推理服务 B 属于高带宽低计算模型MIG 的均匀切分会导致资源类型不匹配。混合切分配置可以缓解此问题。NVIDIA Device Plugin 的延迟当 Pod 创建/销毁时NVIDIA Device Plugin 需要调用nvidia-smi检查 GPU 状态。在高频扩缩容10 次/分钟下Device Plugin 的响应延迟可能成为瓶颈单次检查约 13 秒。五、总结CUDA MPS 适合内部多服务共享大 GPU场景——用应用层显存约束替代硬件隔离MIG 适合多租户平台场景——硬件级别的故障和性能隔离Time-Slicing 仅适合开发/测试。生产环境建议推理中台用 MIG 为不同团队分配隔离的 GPU 资源单个团队内不同推理服务用 MPS 共享一张 GPU配合 vLLM 显存限制。必须用dcgm-exporter监控每个 MIG 实例的 SM 利用率和显存占用建立 per-instance 而非 per-GPU 的告警。
)
