在 GPU 算力虚拟化和多租户共享的场景中，NVIDIA 提供了两种主流的切分技术：MPS（Multi-Process Service，多进程服务） 和 MIG（Multi-Instance GPU，多实例 GPU）。
虽然这两者都能实现“将一块 GPU 拆给多个任务使用”的目的，但它们的底层实现逻辑、硬件隔离级别以及适用场景有着本质的区别。
简单来说，MPS 是“软件/驱动层的主动协同与逻辑复用”，而 MIG 是“芯片层面的物理硬切割”。
一、 核心机制对比：硬核切分 vs 软性共享
为了更直观地理解，我们可以先看一张底层资源维度的对比表：
| 维度 | MPS (多进程服务) | MIG (多实例 GPU) |
|---|---|---|
| 引入代际 | Kepler 时代引入，Volta 架构大幅强化 | Ampere 架构（如 A100、H100）首次引入 |
| 隔离级别 | 逻辑隔离（进程级） | 物理硬件隔离（实例级） |
| 显存带宽隔离 | 无（共享显存通道，存在争抢） | 有（物理分配独立的内存控制器和路径） |
| L2 缓存隔离 | 无（共享 L2 缓存） | 有（L2 缓存按比例物理切分并隔离） |
| 故障隔离 | 弱（一个进程 Crash 理论上可能影响整卡） | 极强（单个实例 Crash 互不影响，支持硬复位） |
| 服务质量 (QoS) | 软性限制（通过比例控制延迟，无法完全避免抖动） | 硬性保证（绝对的带宽与算力确定性） |
| 最大切分数量 | 最多 48 个客户端进程 | 最多 7 个 GPU 实例 (GI) |
二、 MIG（多实例 GPU）：芯片微架构层面的“物理分家”
MIG 是自 Ampere 架构开始引入的硬核技术。它的本质是在硅片（Silicon）层面，将一块物理 GPU 真正划分为多个独立的“小 GPU”。
1. 硬件资源的物理重组
在 MIG 模式下，GPU 的底层硬件资源（GPC、SM、内存控制器、L2 缓存、SYS 管道）被硬性解耦并重新组合。
- GPC（图形处理集群）与 SM（流式多处理器）：MIG 将物理 GPC 划分给不同的 GPU Instance (GI)。每个实例分到的 SM 是物理上固定的。
- 内存控制器（Memory Controller）与 HBM 物理通道：这是 MIG 最强大的地方。它不仅切分了显存容量，还等比例切分了显存物理带宽。例如，一个 A100 被切分为 7 个实例，每个实例会分到专属的 HBM 通道和内存控制器。
- L2 缓存与内部交叉开关（Interconnect crossbar）：L2 缓存被物理划分为独立的片区（Slices），不同实例的请求在硬件层被路由到各自的 L2 片区，绝对不会发生跨实例的缓存挤兑（Cache Thrashing）。
2. 独立的执行管道与地址空间
每个 MIG 实例拥有自己独立的内置硬件调度器（Host Interface / Copy Engines）和页表管理单元（MMU）。
在操作系统看来，每个 MIG 实例就是一块挂载在 PCIe 总线上的、完全独立的 NVIDIA GPU。它们拥有独立的 GPU 物理 ID，运行在完全独立的物理地址空间中。
3. 故障隔离（Fault Isolation）
在 MIG 模式下，如果 Instance 0 上的某个 AI 任务因为内存越界、CUDA 核心挂起或者发生了严重的段错误（Segment Fault），只会导致 Instance 0 发生硬件复位（Reset），而正在运行的 Instance 1 到 6 完全不会受到任何干扰，业务零中断。
三、 MPS（多进程服务）：漏斗式的“时空复用”
相比之下，MPS 的历史要悠久得多。它最初的设计目的是为了解决多进程提交 CUDA 任务时，GPU 上下文切换（Context Switch）带来的延迟和硬件利用率不足的问题。
1. 软性漏斗机制：MPS Server
在没有 MPS 之前，多个进程向 GPU 提交任务，GPU 只能通过时间片轮转（Time-slicing）来切换上下文，开销极大。
MPS 引入了一个代理进程——MPS Server。
- 所有的客户端进程（Client Processes）不再直接向 GPU 发送指令，而是通过 IPC（进程间通信）将任务发送给 MPS Server。
- MPS Server 扮演了一个“合流漏斗”的角色，将所有客户端的 CUDA Context 合并为一个单一的、共享的 CUDA Context，并统一提交给 GPU 执行。
2. 空间复用（Spatial Multiplexing）
由于共享了同一个 Context，不同的进程任务可以**同时（并跑在不同的 SM 上）**在 GPU 内执行。
- SM 的限制：通过设置
CUDA_MPS_ACTIVE_THREAD_PERCENTAGE，你可以限制某个进程最多使用 50% 的线程（即大约 50% 的 SM）。但这是一种软性的、由硬件协同调度器（Cooperative Distributive Scheduler）强制执行的分配，并非物理绑定。 - 共享资源的无隔离：
- L2 缓存和显存带宽是完全共享的。如果 A 进程在进行大量的显存读写，B 进程即使分配到的 SM 很少，其显存访问依然会受到严重的延迟干扰（即“吵闹邻居” Neighbor Effect）。
- 所有的进程共享同一条硬件控制管道（Command Processor）。
3. 弱故障隔离
由于所有 MPS 客户端在底层共享同一个 GPU 上下文和驱动资源，一旦某个客户端触发了可能导致 GPU 驱动挂起或硬件异常的严重错误（如未捕获的全局内存越界），整个 MPS Server 控制下的所有进程都有可能协同崩溃。
四、 核心技术痛点对比：为什么有了 MPS 还要 MIG？
我们可以用一个通俗的“租房”案例来比喻这两者的区别：
- MPS 就像合租房（Shared Flat）：
大家共享客厅、厨房和卫生间。虽然大家可以规定“你只能占用冰箱的一层”（限制 SM 比例），但如果你的室友在厨房疯狂用水（占满显存带宽），你洗澡的水流就会变小（延迟增加增加）。更糟糕的是，如果室友不小心把厨房点了（进程崩溃），整栋房子都会受灾。 - MIG 就像酒店式公寓（Apartment Block）：
每个房间都有自己独立的电表、水管和防盗门。你无论在房间里怎么折腾，都不会影响隔壁房间的热水流量和电力供应。隔壁哪怕失火，防火墙也能确保你的房间安然无恙。
为什么云厂商极度青睐 MIG？
在公有云和多租户（Multi-tenant）场景下，安全隔离和**服务质量保证（SLA）**是第一位的。
- 在 MIG 之前，使用 MPS 共享 GPU 的云主机无法对客户做出强力的确定性性能承诺，因为邻居的算力行为会通过 L2 缓存和内存带宽直接“投影”到你的任务上。
- MIG 彻底解决了这一痛点。它允许云厂商将一块 H100 物理切分成 7 个规格标准、性能绝对稳定的“微型云 GPU”转租给不同的客户，且不用担心客户之间的安全窥探和故障波及。
五、 实战落地：我们该如何选择？
这两者并不是非此即彼的对立关系，在实际的 AI 基础设施建设中，它们各有其不可替代的舞台：
1. 优先选择 MIG 的场景：
- 多租户公有云/私有云平台：用户之间互不信任，对安全隔离、故障隔离有硬性要求。
- 严苛的生产环境推理（Inference）集群：对单次推理的延迟（Latency）抖动极其敏感，必须保证 99% 的响应时间（Tail Latency）稳定。
- 混合负载部署：一块 GPU 上同时跑轻量训练、推理以及数据预处理，需要物理上互不干扰。
2. 优先选择 MPS 的场景：
- 单用户/单团队的超大规模并行计算：比如 MPI 科学计算，或者单个任务需要启动几十个进程同时处理小数据块。
- 旧代际 GPU 的复用：在不支持 MIG 的旧架构显卡（如 V100、T4，或消费级显卡 RTX 3090/4090）上，MPS 是实现空间复用、榨干 GPU 剩余算力的唯一手段。
- 微服务架构的 AI 接口服务：多个完全可控的内部微服务共同使用一块 GPU，内部不存在恶意攻击或恶意资源挤兑。
进阶玩法：在支持的架构上（如 Ampere/Hopper），你甚至可以两项技术叠加使用——先用 MIG 在底层切分出物理隔离的实例，再在某个特定的 MIG 实例内部开启 MPS，以进一步提升该实例内部小任务的并发吞吐量。这套组合拳目前正在成为主流 AI 容器云平台的标准架构。
