MIG 与 MPS 嵌套混部实战:在硬件切片内二次榨干 GPU 算力极限 在构建服务于企业级全业务场景的 GPU 算力中心时基础设施架构师始终在两套看似对立的诉求之间进行艰难的平衡一方面在线主业务如千亿级大模型实时推理要求绝对的硬件 QoS 隔离杜绝任何邻居干扰与显存踩踏另一方面长尾的微型推理任务如单批次 Embedding、特征提取、多模态预处理小模型如果单独分配一张物理卡甚至一个标准的 MIG 切片其内部的 Tensor Core 算力利用率依然往往不足 20%造成难以忽视的“二次闲置”。NVIDIA MIG多实例 GPU在 Hopper/Ampere 芯片底层提供了坚不可摧的物理切片隔离但其切片粒度存在物理下限例如 H100 最小的切片也是1g.10gb。如果企业内有几十个并发很低、仅需占用 1GB 显存的微服务单纯依靠 MIG 依然无法解决微观层面的装箱碎片。为了打破这一瓶颈我们在生产环境中探索出了一种将硬件级 MIG 切片与内核级 MPSMulti-Process Service多进程服务相互结合的“嵌套双层混部”创新架构在宏观层面用 MIG 划分硬隔离安全边界在微观切片内部开启 MPS 实现微秒级多进程算力深度重叠。本文全景复盘这套极致压榨 GPU 算力潜能的实战落地。硬件切片MIG与多进程服务MPS的互补性要理解嵌套架构的必要性必须先认清 MIG 与 MPS 各自的微观技术长短板1. MIG 的优势与局限核心长处硅片级硬隔离。每个切片独占独立的 SM、内存控制器通道与 L2 缓存具备 100% 故障隔离能力核心局限切分粒度静态固定单卡最多切分 7 个实例且无法在一个切片内部让多个轻量进程同时并发占用 Tensor Core。2. MPS 的优势与局限核心长处CUDA 上下文Context合并与硬件队列重叠。多个属于不同进程的 CUDA 任务通过同一个常驻的 MPS 控制守护进程共享同一个硬件 GPU Context消除进程切换带来的毫秒级开销同时允许来自不同进程的小算子在同一个 SM 核心内部并行执行Hyper-Q Concurrent Execution核心局限缺乏硬件级的硬防线。如果某个进程发生内存非法访问整个 MPS 服务及其托管的所有相邻进程会集体崩溃无法限制显存带宽争抢。3. “MIG MPS 嵌套”的架构化化学反应我们将两者嵌套融合先用 MIG 将单张物理卡切分为数个具备绝对安全边界的“独立硬件沙盒”例如 2 个3g.40gb实例和 1 个1g.10gb实例然后在专门承载长尾轻量任务的切片内部部署轻量级的 MPS 服务将该切片的显存与计算资源进一步细分为数十个微算力槽位。这样既把故障爆炸半径死死锁在单一 MIG 实例内部不影响相邻主大模型又在切片内部彻底消灭了一切算力气泡。生产级嵌套配置实操与环境初始化在单个 MIG 切片内部激活 MPS需要跨越 NVIDIA 驱动设备节点映射与 IPC 命名空间两大技术关卡。1. 宿主机定位与专属 MIG 实例锁定首先通过nvidia-smi -L提取目标 MIG 切片的全局唯一 UUID# 获取当前节点 MIG 实例列表 nvidia-smi -L # 输出示例 # GPU 0: NVIDIA H100 80GB HBM3 (UUID: GPU-xxxx) # MIG 1g.10gb Device 0: (UUID: MIG-64101e4a-b50a-41df-...)2. 在指定 MIG 设备内启动隔离的 MPS 控制守护进程为避免不同切片之间的 MPS 产生 IPC 管道冲突必须为每个切片分配独立的控制目录与管道文件# 导出当前切片的专属环境变量 export CUDA_VISIBLE_DEVICESMIG-64101e4a-b50a-41df-... export CUDA_MPS_PIPE_DIRECTORY/var/run/nvidia-mps-mig-slice0 export CUDA_MPS_LOG_DIRECTORY/var/log/nvidia-mps-mig-slice0 mkdir -p $CUDA_MPS_PIPE_DIRECTORY mkdir -p $CUDA_MPS_LOG_DIRECTORY # 针对该特定切片启动独立的 MPS 控制守护进程 nvidia-cuda-mps-control -d3. 配置微切片内部的算力与显存硬限额QoS Limits进入 MPS 控制台通过配置指令将该 MIG 切片10GB 显存精细化切分为 5 个相互受限的微租户# 进入该切片的 MPS 控制台 nvidia-cuda-mps-control EOF # 限制接入的每个客户端进程最多使用当前切片 20% 的 SM 线程资源 set_default_active_thread_percentage 20 # 开启 Volta/Hopper 架构的显存硬配额限制每个客户端限额 2GB set_default_device_pinned_mem_limit 0 2048M EOFKubernetes 容器纳管与声明式接入编排在 Kubernetes 体系中我们将运行 MPS 控制器的 Pod 作为基础设施组件向上层的微服务业务暴露统一的挂载目录apiVersion: apps/v1 kind: Deployment metadata: name: micro-embedding-worker namespace: tenant-nlp spec: replicas: 5 template: metadata: labels: app: micro-embedding spec: containers: - name: embedding-server image: registry.internal.corp/ai/bge-small:v1.0 env: # 指向该切片专属的 MPS 控制管道 - name: CUDA_MPS_PIPE_DIRECTORY value: /tmp/nvidia-mps-mig-slice0 - name: CUDA_VISIBLE_DEVICES value: MIG-64101e4a-b50a-41df-... # 单容器显存硬限制2048MB - name: CUDA_MPS_PINNED_NUMA_NODE value: 0 resources: limits: cpu: 2 memory: 4Gi volumeMounts: - name: mps-pipe mountPath: /tmp/nvidia-mps-mig-slice0 volumes: - name: mps-pipe hostPath: path: /var/run/nvidia-mps-mig-slice0当这 5 个容器同时发起向量计算时CUDA 驱动直接将它们的计算网格Grids合并提交给同一个硬件队列SM 核心在纳秒级时间内无感交错调度不同容器的 Tensor Core 计算指令消灭了任何进程切换开销。生产极限压测复盘吞吐翻倍与安全隔离验证我们在单张 80GB H100 物理卡上划分出实例 A主大模型分配7g.80gb中的 6 个切片即组合为4g.40gb 2g.20gb运行生产级 70B 对话模型实例 B长尾集群分配剩余的1g.10gb切片并在其内部开启 MPS 运行 5 个并发的 Embedding 检索服务。我们针对实例 B 施加了高密度的并发冲击并故意在其中一个 Embedding 容器中注入非法的 CUDA 显存越界崩溃代码。监控实测指标对比评估维度指标传统纯 MIG 独占方案MIG MPS 嵌套混部方案改善成效单张 1g.10gb 切片承载微服务数仅能承载 1 个服务稳定承载 5 个并发微服务服务承载密度提升 5 倍切片内部 Tensor Core 平均利用率16.4% (严重空闲)78.2% (高效饱和运转)有效算力产出提升 4.7 倍单次 Embedding 推理响应延迟18.2 毫秒19.1 毫秒 (仅微增 0.9ms)保持极高推理时效微服务突发崩溃时的影响范围N/A仅同切片 MPS 实例重启实例 A 零感知核心业务 100% 物理安全全集群整体 GPU 采购成本基线成本 100%节约长尾硬件采购 38%每年节省数百万元硬件支出架构师的工程洞见硬件的边界是刚性的但架构的想象力是无限的。通过在宏观层面用 MIG 锁定安全红线在微观层面用 MPS 压榨算力缝隙我们打破了“多租户安全”与“极致算力密度”不可兼得的技术神话为智算中心的高效集约化运转开辟了一条崭新的工程坦途。