在日常的 GPU 算力优化工作中，NVIDIA MPS（Multi-Process Service，多进程服务） 经常被誉为提升 GPU 利用率的“银弹”。在单卡运行多个轻量级推理任务，或者小规模多进程数据处理时，MPS 通过允许多个 CUDA 进程共用同一个 GPU 的硬件上下文，确实能显著压榨硬件性能。
然而，一旦进入“大规模、多机多卡分布式训练”（例如使用 PyTorch DDP 训练大语言模型或巨型视觉模型）的场景，开启 MPS 大概率会变成一场技术灾难。
在标准的 PyTorch DDP（Distributed Data Parallel）实践中，我们通常遵循 “1 Process per GPU”（一卡一进程） 的黄金法则。如果在这个基础上强行引入 MPS，或者试图利用 MPS 在单卡上跑多个 DDP 子进程，将会引发一系列深层次的底层冲突。
本文将从显存机制、底层通信、分布式木桶效应以及可观测性四个维度，深度拆解 MPS 对大规模分布式训练的负面影响。
1. 显存碎片化与不可控的 OOM（Out of Memory）
在大规模 AI 训练中，显存是极其珍贵的资源。大模型训练往往需要将显存压榨到极致（通过 Activation Checkpointing、ZeRO 分阶段优化等技术）。
MPS 的核心设计思想是空间分割（Spatial Partitioning）和时间片轮转。当你在 DDP 中引入 MPS 让多个进程共享单卡时：
- 静态显存隔离的局限： 尽管 MPS 允许通过
CUDA_MPS_ACTIVE_THREAD_PERCENTAGE或显存限制来划分资源，但这种划分是硬性且静态的。例如，两路进程各分 50% 显存。在大模型训练的 Backward 阶段，激活值释放和梯度计算会导致显存需求出现剧烈波峰。原本单进程可以动态申请整块显存，现在却被硬生生阻断，直接触发 OOM。 - 显存碎片化（Memory Fragmentation）： 多个进程频繁地向同一个物理 GPU 申请和释放 PyTorch Caching Allocator 管理的显存块，会导致物理 GPU 内部的显存碎片化极其严重。这会使得虽然看似还有剩余显存，但无法分配出大块连续显存，导致模型在运行到某个特定 Step（如计算 Loss 或 All-Reduce 聚合）时突然崩溃。
2. NCCL 集合通信的“降级”与性能雪崩
PyTorch DDP 的底层核心是 NCCL（NVIDIA Collective Communications Library）。NCCL 为了实现极致的跨卡通信吞吐，会极力压榨硬件通道，包括 NVLink、PCIe Gen4/Gen5 以及 GPUDirect RDMA（InfiniBand/RoCE）。
当 MPS 介入后，NCCL 的通信逻辑会发生严重的性能退化：
- P2P 通信路径受阻： NCCL 依赖于 GPU 之间的 Peer-to-Peer（P2P）直接内存访问。在没有 MPS 的情况下，进程独占 GPU，NCCL 可以直接建立 NVLink 通信。但在 MPS 环境下，由于多个进程在虚拟化 CUDA 上下文中运行，NCCL 在初始化时可能会因为虚拟地址映射冲突，无法建立高效的 NVLink P2P 连接，被迫降级为通过系统内存（shm）或者 PCIe 甚至 CPU 进行数据中转，通信带宽直接缩水一个数量级。
- 通信与计算的流水线被打破： 现代分布式训练严重依赖“通信与计算重叠”（Computation-Communication Overlap）。在 Backward 阶段，前一个 Layer 的梯度还在计算，后一个 Layer 的梯度已经开始通过 NCCL 进行 All-Reduce。MPS 的时间片调度会打乱这种精密的流水线，导致通信进程和计算进程在 GPU 时间片上互相推挤，产生严重的调度气泡（Bubble）。
3. 分布式系统的“木桶效应”与尾部延迟（Tail Latency）
分布式训练是一个典型的同步系统（Synchronous SGD）。在每个 Step 结束时，所有机器上的所有 GPU 都必须完成梯度计算，并通过 All-Reduce 达成一致，然后才能更新参数。
这意味着：整个集群的训练速度，取决于最慢的那张卡、最慢的那一个进程。
- 非确定性调度（Non-deterministic Scheduling）： MPS 在 GPU 硬件层面的调度并不是完全硬实时的。如果有两个 DDP 进程共享一张卡，其中一个进程由于数据加载（DataLoader）稍微卡顿了一下，MPS 就会把更多的算力时间片分给另一个进程。看似提升了“单卡利用率”，但当滞后的进程恢复时，它分配到的计算资源已经变少，从而导致该卡整体完成 Step 的时间被拉长。
- 多机多卡下的误差放大： 在千卡规模的集群中，这种微小的调度不确定性会通过网络通信像滚雪球一样放大。哪怕 1024 张卡中只有一张卡因为 MPS 的资源争抢慢了 10 毫秒，整千张卡都会在同步屏障（Barrier）处空等这 10 毫秒。DDP 整体的 Scaling Efficiency（扩展效率）会因此急剧下降。
4. 灾难性的可观测性与调试成本
在分布式训练中，定位性能瓶颈（Profiling）和排查 Bug 本身就是一项重工业。引入 MPS 会让系统的复杂度呈指数级上升。
- 性能剖析工具（Profiler）失效或失真： 我们常用 PyTorch Profiler 或 NVIDIA Nsight Systems 来分析算子耗时。但在 MPS 模式下，由于多个 CUDA 上下文被合并提交到 GPU，Nsight 捕获到的 Time Slice 会高度重叠，你根本无法分清某个 Kernel 到底是哪个 DDP 进程发射的，也无法准确评估算子的真实耗时。
- 死锁（Deadlock）诊断极其困难： 分布式训练最怕 NCCL Timeout 导致的死锁。如果开启了 MPS，当发生死锁时，你很难判断是因为网络物理故障，还是因为 MPS 守护进程（
nvidia-cuda-mps-control）内部的信号量死锁，或者是由于资源争抢导致的底层进程被系统 OOM Killer 强杀。
总结：我们在什么场景下才需要 MPS？
既然 MPS 在大规模 DDP 训练中负面效应如此明显，那它是不是一无是处？
并不是。我们应当严格区分应用场景：
| 维度 | 大规模 DDP 训练 | 轻量级多任务推理 / 分布式 Serving |
|---|---|---|
| 显存占用 | 极高（通常 >80% 物理显存） | 极低（单个模型仅占 10-20%） |
| 通信频次 | 高频、高带宽（NCCL All-Reduce） | 无跨卡通信，或仅有简单的输入输出分发 |
| 同步要求 | 强同步（BSP 模式） | 异步、无状态 |
| 首选方案 | 物理卡独占（1 Process per GPU） | 开启 MPS 或 MIG（Multi-Instance GPU） |
一句话结论：
在大规模多机多卡分布式训练中，不要使用 MPS。请保持“一个进程独占一张物理卡（或 MIG 强隔离分区）”的纯净环境，把优化的重心放在算子融合、混合精度、ZeRO 内存优化以及网络拓扑上。让每张 GPU 专注、纯粹地爆发它的极限算力，才是分布式训练的正确打开方式。
