MPI（Message Passing Interface）

3 秒看懂

MPI 是分散式平行計算的標準化通訊協議層——定義了一套”誰給誰發什麼訊息”的 API 規範。大型模型訓練中梯度同步（AllReduce）、流水線並行（Send/Recv）、MoE 專家路由（All-to-All）等核心通訊操作，底層均源於 MPI 定義的通訊原語。

3 分鐘產業解釋

為什麼 MPI 對 AI 產業至關重要？

當你看到”GPT-4 使用了數萬張 GPU 訓練”這句話時，一個關鍵問題浮出水面：這些 GPU 之間如何高效地交換資料？

MPI 正是回答這個問題的”元協議”。

產業定位：

HPC 時代（1994—至今）： MPI 是超算領域事實上的標準程式設計介面，全球 Top500 超算幾乎全部支援 MPI。
AI 時代（2016—至今）： MPI 的通訊原語被提煉、GPU 化後，滲透進每一款深度學習架構。NVIDIA NCCL、Gloo（PyTorch 預設後端）、Horovod 等架構的集體通訊語義，均可追溯到 MPI 規範。

一句話產業邏輯： MPI 不是某個公司的產品，而是一份公開規範（類似 HTTP 之於 Web），它定義了平行計算中”訊息傳遞”的語法和語義。任何涉及多節點協同的計算——從天氣預報到萬億引數模型訓練——都離不開 MPI 及其衍生技術棧。

15 分鐘專家深入

MPI 在 AI 訓練技術棧中的位置

┌─────────────────────────────────────────────────┐
│              AI Training Frameworks              │
│         (PyTorch / JAX / DeepSpeed / Megatron)    │
├─────────────────────────────────────────────────┤
│          集體通訊庫 (Collective Libraries)          │
│     NCCL (NVIDIA GPU)  │  Gloo (CPU/GPU)          │
│     oneCCL (Intel)     │  MPI 實現 (OpenMPI等)     │
├─────────────────────────────────────────────────┤
│          通訊執行時 / 抽象層                        │
│     UCX / libfabric / GASNet                      │
├─────────────────────────────────────────────────┤
│          硬體傳輸層                                 │
│  InfiniBand (RDMA) │ RoCE │ NVLink │ NVSwitch     │
│  PCIe │ 乙太網路 │ Slingshot (HPE)                   │
└─────────────────────────────────────────────────┘

核心通訊原語分類

1. 點對點通訊（Point-to-Point）

原語	語義	AI 訓練中的典型用途
`MPI_Send` / `MPI_Recv`	阻塞式傳送/接收	Pipeline 並行中相鄰 stage 的微批次傳遞
`MPI_Isend` / `MPI_Irecv`	非阻塞式（非同步）	計算-通訊重疊（overlap），隱藏通訊延遲
`MPI_Sendrecv`	同時傳送和接收	Pipeline 並行中雙向資料交換

2. 集體通訊（Collective）——AI 訓練的命脈

原語	語義	AI 訓練中的典型用途
`MPI_Allreduce`	全歸約（所有程序得到全域性聚合結果）	資料並行梯度同步，最核心操作
`MPI_Allgather`	全收集（每個程序收集所有程序的資料）	張量並行中切分權重的聚合
`MPI_Scatter` / `MPI_Gather`	分發/收集	資料載入分發
`MPI_Broadcast`	廣播	模型引數、超參分發
`MPI_AlltoAll`	全交換（每個程序向每個程序傳送不同資料）	MoE 專家路由 dispatch/combine
`MPI_Reduce_scatter`	歸約後分散	Megatron 張量並行中 AllReduce 的拆解實現
`MPI_Barrier`	同步屏障	階段性同步、除錯

AllReduce 的核心演算法

資料並行訓練中，每個 GPU 計算本地梯度後，需要通過 AllReduce 得到全域性梯度均值。Ring AllReduce 是最經典的實現：

假定 N 個 GPU，每個持有大小為 D 的梯度向量

Ring AllReduce 步驟（兩階段）：
┌──────────────────────────────────────────┐
│ 階段 1: Reduce-Scatter                     │
│   - 將 D 分成 N 段                         │
│   - N-1 步，每步每個 GPU 向環中下一 GPU      │
│     傳送一個分段並接收前驅的一個分段          │
│   - 每步傳輸量: D/N                         │
│   - 結束後，每個 GPU 持有一個分段的完整歸約值  │
├──────────────────────────────────────────┤
│ 階段 2: AllGather                          │
│   - N-1 步，方向相同                        │
│   - 每步傳輸量: D/N                         │
│   - 結束後，每個 GPU 持有全部 N 段的歸約值    │
└──────────────────────────────────────────┘

總傳輸量 = 2 × (N-1)/N × D ≈ 2D（當 N 較大時）
每個 GPU 總通訊量與 N 無關，僅與 D 成正比 → 良好擴充套件性

頻寬最優性： Ring AllReduce 達到了理論下界——在頻寬受限場景下不可再最佳化。但在延遲受限場景（小訊息）中，Tree-based 或 Recursive Halving-Doubling 演算法更優。

MPI 與 NCCL 的關係

這是理解 AI 通訊棧的關鍵：

維度	MPI	NCCL
性質	開放標準規範（任何人可實現）	NVIDIA 私有實現
設計目標	通用 HPC 並行通訊	GPU 叢集集體通訊最佳化
硬體感知	通用（CPU 為主，需適配 GPU）	深度 GPU 感知（NVLink、NVSwitch、InfiniBand）
通訊模型	以 CPU 執行緒為通訊主體	從 CPU 發起，在 GPU stream 上非同步執行
拓撲發現	有限	自動探測 NVLink/NVSwitch/PCIe/IB 拓撲，最佳化路徑
在 AI 中的角色	早期後端（Horovod）；仍在用	PyTorch DDP 預設後端；主流選擇

關鍵洞察： NCCL 並非”替代” MPI，而是在 GPU AI 訓練這個特定場景下，將 MPI 集體通訊語義用 GPU-native 方式重新實現。NCCL 的 ncclAllReduce 語義與 MPI_Allreduce 等價，但實現路徑完全不同——NCCL 會在 GPU 上啟動通訊 kernel，直接通過 GPUDirect RDMA 寫入遠端 GPU 視訊記憶體，繞過 CPU。

MPI 的實現生態

實現	性質	備註
OpenMPI	開源	社群驅動，廣泛用於學術和工業
MPICH	開源	ANL 主導，是許多商業實現的基線
Intel MPI（oneAPI MPI）	商業/免費	Intel 最佳化，常與 Slurm 配合
MVAPICH	開源	OSU 主導，InfiniBand 優化出色
Cray MPICH	商業	Cray/Slingshot 平台
NVIDIA HPC-X	商業套件	包含 OpenMPI + UCX + NCCL

技術原理

通訊模型

MPI 採用 SPMD（Single Program Multiple Data） 模型：

┌───────────────────────────────────────────────┐
│  同一個程式在 N 個程序上並行執行                   │
│  每個程序有唯一的 rank (0 ~ N-1)                 │
│  程序間通過顯式訊息傳遞交換資料                     │
│  共享狀態僅通過通訊建立                            │
└───────────────────────────────────────────────┘

核心語義要素：

Communicator（通訊域）： 定義程序組及其通訊上下文。MPI_COMM_WORLD 包含所有程序。
Rank（程序編號）： 通訊域內唯一標識。
Tag（訊息標籤）： 用於訊息匹配過濾。
Blocking vs Non-blocking：
- 阻塞：呼叫返回時緩衝區可安全複用
- 非阻塞：立即返回 handle，需 MPI_Wait / MPI_Test 完成確認
- MPI-3 引入非阻塞集體通訊（MPI_Iallreduce 等），對計算-通訊重疊至關重要
Derived Datatypes： 允許定義非連續記憶體版面配置的複合資料型別，減少 packing/unpacking 開銷。

關鍵機制詳解

（1）RMA（Remote Memory Access）—— MPI-2/3

也稱 "單邊通訊"（One-Sided Communication）

MPI_Put:   本地程序直接寫入遠端程序的記憶體視窗
MPI_Get:   本地程序直接讀取遠端程序的記憶體視窗
MPI_Accumulate: 遠端原子累加

視窗 = MPI_Win_create() 註冊的共享記憶體區域

優勢: 減少遠端 CPU 參與（需 RDMA 支援）
AI 場景: 引數伺服器架構中可直接更新遠端梯度

（2）程序拓撲

MPI 提供虛擬拓撲對映：
- MPI_Cart_create: 笛卡爾網格拓撲
- MPI_Graph_create: 圖拓撲

用途: 將邏輯通訊模式對映到物理拓撲
例: 2D mesh 的 AllReduce 可按行列分別執行
對 AI: 多維並行（DP × TP × PP）的通訊域劃分

（3）MPI+X 混合程式設計模型

現代 AI 訓練棧的實際架構:

MPI (程序管理/粗粒度通訊)
  + CUDA/GPU kernels (計算)
  + NCCL (GPU 集體通訊)
  + OpenMP (CPU 多執行緒)
  + UCX (統一通訊架構)

MPI 的角色已從 "計算+通訊" 轉為:
  ① 程序啟動與管理 (PMIx/PMI)
  ② CPU 側控制平面通訊
  ③ 與 NCCL 等 GPU 庫共存的基礎設施

技術演進史

時間	里程碑	意義
1992	MPI 論壇成立	統一 HPC 分散式程式設計的努力開始
1994	MPI-1.0 釋出	點對點通訊 + 集體通訊基礎架構
1997	MPI-2.0	動態程序管理、單邊通訊（RMA）、並行 I/O
~2009	MVAPICH2 GPU-aware	早期 GPU-aware MPI 嘗試
2012	MPI-3.0	非阻塞集體通訊、改進的 RMA、大計數支援
~2017	Horovod 釋出	Uber 開源，MPI 作為 DL 分散式訓練後端進入 AI 領域
~2016—2017	NCCL 1.x/2.x	NVIDIA GPU-native 集體通訊，逐步成為 AI 訓練主流
~2019	OpenMPI + UCX	統一通訊後端，支援 GPU-aware + RDMA
2021	MPI-4.0	大訊息支援（>2GB）、改進的持久化通訊、會話（Sessions）模型
~2022—至今	MPI 在 AI 中角色轉型	從”直接通訊層”轉向”程序管理+基礎設施”，NCCL/RCCL/Gloo 承擔 GPU 集體通訊

技術路線對比

AI 訓練中主要通訊後端對比

維度	MPI 實現 (OpenMPI/MPICH)	NCCL	Gloo	oneCCL (Intel)
硬體適用	CPU 為主，GPU-aware 可選	NVIDIA GPU	CPU + GPU (有限)	Intel GPU/CPU
點對點	✅ 完整	✅ 提供	❌ 不提供	✅
集體通訊	✅ 完整	✅ 專精 AllReduce/AllGather 等	✅ 基礎	✅
GPU 原生	需 GPUDirect 支援	✅ 深度整合 NVLink/NVSwitch/IB	有限	有限
拓撲最佳化	有限	✅ 自動探測最優路徑	❌	有限
可擴充套件性	數十萬程序級驗證	萬級 GPU	千級	萬級
在 PyTorch 中	需手動指定 backend	預設 DDP 後端	CPU 預設後端	XPU 後端
易用性	需 mpirun 啟動	torchrun 啟動即可	內建	需配置

AllReduce 實現演算法對比

演算法	通訊複雜度（頻寬）	延遲複雜度	適用場景
Ring AllReduce	2(N-1)/N × D	O(N)	大訊息、頻寬受限
Recursive Halving-Doubling	2(1-1/N) × D	O(log N)	中等訊息
Tree-based	2(N-1)×D（根程序，O(N·D)）	O(log N)	小訊息、延遲受限
Double Binary Tree	2D × (1+o(1))	O(log N)	NCCL 預設最佳化之一

上下游

上游（MPI 依賴的技術層）

硬體層:
├── CPU: x86 (Intel/AMD), ARM (Ampere/Fujitsu A64FX)
├── 互聯:
│   ├── InfiniBand (NVIDIA Mellanox) — HPC + AI 主力
│   ├── RoCE v2 — 資料中心乙太網路 RDMA
│   ├── Slingshot (HPE/Cray)
│   ├── NVLink / NVSwitch — GPU 間直連（NCCL 更直接利用）
│   └── 乙太網路 — 回退方案
├── RDMA 庫: libibverbs, RDMA Core
└── 統一通訊架構: UCX (Unified Communication X)
    └── MPI 實現越來越多建置在 UCX 之上

下游（使用 MPI 或其原語的系統）

AI 架構與庫:
├── Horovod (Uber) — 最早將 MPI 引入 DL，支援 MPI/Gloo/NCCL 後端
├── PyTorch DDP — 預設 NCCL，但 Gloo 後端語義同 MPI
├── Megatron-LM (NVIDIA) — TP/PP/DP 並行通訊
├── DeepSpeed (Microsoft) — ZeRO 通訊模式
├── JAX pjit — 基於 XLA 的通訊編譯
├── Ray / Alpa — 自動並行
└── ColossalAI / FSDP — 各種並行策略

傳統 HPC:
├── GROMACS, NAMD (分子動力學)
├── WRF (天氣預報)
├── OpenFOAM (流體力學)
└── 各類 MPI-native 科學計算應用

編排與排程:
├── Slurm — MPI 作業啟動的事實標準
├── PMIx — 程序管理介面（替代傳統 mpirun 的 Launcher）
└── Kubernetes + MPI Operator — 雲端原生 MPI 部署

關鍵指標

評估 MPI 實現 / 網路通訊效能的核心指標

指標	含義	典型量級（定性）	影響
Latency（延遲）	單次小訊息端到端時間	InfiniBand: 數微秒級；乙太網路: 數十微秒級	影響小訊息 collective 的尾部延遲
Bandwidth（頻寬）	最大單鏈路吞吐	IB HDR: 200 Gb/s；IB NDR: 400 Gb/s；800G 乙太網路已出現	決定大梯度 AllReduce 的傳輸時間
Injection Rate（注入率）	網絡卡每秒傳送訊息數	數千萬 msgs/s（高階）	影響小訊息聚合場景
AllReduce 吞吐	集體通訊的實際頻寬利用率	理論鏈路頻寬的 70%—95% 為良好	取決於演算法實現 + 網路拓撲
Message Size Threshold	頻寬最佳化 vs 延遲最佳化的切換點	通常在數 KB 到數十 KB	影響演算法選擇
GPU-Direct RDMA 效率	GPU 視訊記憶體 ↔ 網絡卡間直傳效率	消除 CPU 中轉，延遲降低	對 AI 訓練尤為關鍵

與 AI 訓練效率的關聯

大型模型訓練中的通訊時間佔比（粗略定性估算）:

小模型 + 低頻寬網路:  通訊時間可佔 50%+
大型模型 + 高頻寬網路:  通訊時間 ~10%-30%
MoE 模型:           All-to-All 通訊可能成為瓶頸
Pipeline 並行:       bubble ratio 取決於 micro-batch 數和通訊

供需與市場資料

直接市場

MPI 本身是開放標準，沒有獨立的”MPI 市場規模”。但其生態鏈涉及：

環節	代表廠商/產品	估算規模
HPC 超算互聯（承載 MPI 的物理網路）	NVIDIA InfiniBand, HPE Slingshot	[行業估算] 全球 HPC 互聯市場約數十億美元/年
MPI 商業發行/支援	Intel oneAPI MPI, NVIDIA HPC-X, Cray MPICH	包含在 HPC 軟體棧中，無獨立估值
AI 訓練叢集網路	與上重疊，AI 叢集大量使用 IB	[廠商財報] NVIDIA 網路部門（含 Mellanox）營收近年顯著增長
UCX 開發與支援	UCF (Unified Communication Framework) 社群	開源主導

關鍵資料點

全球 Top500 超算幾乎全部使用某種 MPI 實現
NVIDIA 在 AI 訓練叢集互聯市場佔據主導地位（InfiniBand），其網路業務營收近年來隨 AI 需求增長顯著
[廠商財報] NVIDIA 資料中心業務（含 GPU + 網路）FY2024 營收約 475 億美元（含 GPU 但網路佔比較小，精確拆分未公開）
新興競爭: Ultra Ethernet Consortium（UEC）推動乙太網路在 AI/HPC 場景替代 InfiniBand，可能改變 MPI 底層傳輸格局

代表公司與資本對映

公司/組織	與 MPI 的關係	資本對映
NVIDIA	HPC-X（含 OpenMPI）、NCCL 繼承 MPI 語義、InfiniBand 網路	NVDA（GPU + 網路）
Intel	oneAPI MPI（原 Intel MPI）、oneCCL、Omni-Path 互聯	INTC
HPE（含 Cray）	Slingshot 互聯、Cray MPICH	HPE
AMD	ROCm 生態中的 RCCL（類 NCCL）、支援 OpenMPI	AMD
Microsoft	DeepSpeed（使用 MPI 概念）、Azure HPC	MSFT
Google	GCP HPC + TPU 互聯（非傳統 MPI 但借鑑語義）、JAX	GOOGL
AWS	EFA（Elastic Fabric Adapter，支援 libfabric/UCX/MPI）、SageMaker 分散式訓練	AMZN
UCF 社群	UCX、UCC（Unified Collective Communication）—— 新興開源通訊層	無直接標的

投資對映思路

直接鏈路:
  MPI 規範 ──(物理承載)──> InfiniBand/高速網路 ──> NVIDIA (NVDA)
  MPI 規範 ──(GPU 化)──> NCCL/RCCL ──> NVIDIA (NVDA) / AMD (AMD)
  MPI 規範 ──(HPC 軟體棧)──> HPE-Cray (HPE) / Intel (INTC)

間接鏈路:
  MPI 通訊效率 ──> 訓練效率 ──> 算力需求 ──> GPU 出貨量
  更快互聯 ──> 更大叢集可用 ──> 更大規模訓練 ──> 更多 GPU + 網路裝置

投資邏輯

核心觀點

1. MPI 是 AI 基礎設施的”隱性關鍵層”

投資 AI 基礎設施時，關注點通常在 GPU（NVIDIA/AMD）、儲存、散熱。但通訊瓶頸正在成為大規模訓練的核心約束——當 GPU 算力按 2x/代增長時，網路頻寬的代際提升如果不匹配，通訊佔比將顯著上升。

2. 通訊效率 → 訓練成本 → 算力需求

更高效的通訊（更優的 AllReduce 實現、更快的互聯）意味著：

相同 GPU 數量下訓練更快 → 單位 token 訓練成本下降
或者，相同時間內可訓練更大型模型 → 推動更大規模 GPU 叢集需求

這形成了一個正反饋：通訊越好 → 算力需求越大 → GPU 銷量越高。

3. 關注三個邊際變化

邊際變化	內涵	涉及標的
UEC（Ultra Ethernet）	乙太網路聯盟推動 AI 原生乙太網路標準，可能部分替代 InfiniBand	博通 (AVGO)、Cisco、AMD、Meta 等 UEC 成員
UALink	GPU 間直連開放標準，對標 NVLink	AMD、Intel、Broadcom 等
UCX/UCC 開源生態	統一通訊層降低對單一廠商依賴	利好 AMD/Intel 等非 NVIDIA 陣營

常見誤讀糾偏

❌ 誤讀 1：“MPI 已經過時了，AI 訓練只用 NCCL”

糾偏： MPI 並未過時，而是在 AI 訓練棧中角色發生了轉變：

程序管理層面： 許多 AI 訓練作業仍通過 mpirun 或基於 PMIx 的 launcher 啟動
CPU 側通訊： 控制平面訊息、後設資料交換仍常走 MPI
NCCL 繼承了 MPI 集體通訊的語義設計： 說”NCCL 替代 MPI”不如說”NCCL 是 MPI 集體通訊在 GPU 場景的 GPU-native 重實現”
HPC + AI 融合場景： 許多科學 AI（AI for Science）應用仍直接使用 MPI
Horovod 雖然熱度下降，但 MPI 概念已內化到各架構中

❌ 誤讀 2：“AllReduce 就是 MPI AllReduce”

糾偏： AllReduce 是一個通用的集體通訊操作語義，MPI 規範定義了其介面標準。但實際執行 AllReduce 的可能是完全不同的實現：

NCCL ncclAllReduce： 在 GPU 上以通訊 kernel 執行，利用 NVLink/NVSwitch/IB 直傳
Gloo allreduce： 使用 TCP 或 IB，CPU 側為主
MPI MPI_Allreduce： 傳統 CPU 側實現，或 GPU-aware 版本
自定義架構內建： PyTorch FSDP 中 AllReduce 可能由 NCCL 執行，與 MPI 無直接關係

關鍵區分： MPI 定義了 AllReduce 的語義規範（輸入、輸出、數學運算），但不代表 AllReduce = MPI AllReduce。

❌ 誤讀 3：“MoE 中的 All-to-All 通訊就是 MPI AlltoAll”

糾偏： 語義上確實對應 MPI 的 MPI_AlltoAll，但實際實現通常不走 MPI：

Megatron-MoE 等架構使用 NCCL 的 All-to-All 或自定義實現
MoE 的 All-to-All 特點是稀疏且動態（每次路由的 expert 分配不同），對通訊模式的可預測性要求不同於傳統 HPC 的 All-to-All
實際最佳化常涉及 token 合併/拆分、capacity factor 控制等 MoE 特有的通訊排程策略

學習路徑

入門（1—2 天）

理解 MPI 的 SPMD 模型、rank、communicator 概念
掌握 Send/Recv/Isend/Irecv 點對點通訊
掌握 Allreduce/Allgather/Broadcast/Scatter/Gather 五大集體操作
用 OpenMPI 或 MPICH 在單機多程序上跑 Hello World + 簡單 AllReduce

進階（1—2 周）

理解 Ring AllReduce 演算法原理，手推通訊量
學習 UCX 架構，理解 MPI 實現如何利用 RDMA
瞭解 GPU-aware MPI 的概念（GPUDirect RDMA/IPC）
對比 MPI AllReduce vs NCCL AllReduce 的實現差異
用 Horovod 或 PyTorch DDP（Gloo 後端）進行分散式訓練

專家（持續）

閱讀 MPI-3.0/4.0 規範文件（特別是 RMA 和 Sessions）
研究 NCCL 原始碼中的拓撲發現與演算法選擇邏輯
理解多維並行（DP × TP × PP × EP）中通訊域的劃分與排程
追蹤 UEC / UALink 等新興互聯標準對 MPI 生態的影響
實測不同 AllReduce 演算法在不同訊息規模和叢集拓撲下的效能差異

一句話總結

MPI 是平行計算通訊的”TCP/IP”——它定義了分散式計算中訊息傳遞的標準語義，而 AI 訓練中的梯度同步、模型切分通訊、MoE 路由等核心操作，本質上都是 MPI 集體通訊原語在 GPU-native 環境中的繼承與演進。

延伸閱讀與來源

來源	內容
MPI Forum (mpi-forum.org)	MPI 標準規範 (MPI-1 ~ MPI-4)
Using MPI (Gropp, Lusk, Skjellum)	MPI 程式設計經典教材
Parallel Programming with MPI (Pacheco)	入門教材
NVIDIA NCCL 文件 (docs.nvidia.com/deeplearning/nccl)	NCCL 架構與 API
OSU Micro-Benchmarks (mvapich.cse.ohio-state.edu/benchmarks/)	MPI/NCCL 效能基準測試
Horovod 技術論文 (Sergeev & Del Balso, 2018)	MPI 在 DL 分散式訓練中的早期應用
UCX 專案 (openucx.org)	統一通訊架構，現代 MPI 實現基礎
Megatron-LM 論文 (Shoeybi et al., 2019; Narayanan et al., 2021)	張量並行 + 流水線並行的通訊設計
Ultra Ethernet Consortium (ultraethernet.org)	AI 原生乙太網路標準進展
NVIDIA 財報/投資者日材料	網路業務營收資料（具體拆分視公開程度）

⚠️ 關於精確數字的說明： 本文涉及的市場資料、營收資料等如未標註具體來源，均為行業定性判斷或公開常識性認知，不構成精確引用。網路效能資料因硬體型號、韌體版本、叢集配置差異顯著，建議以實際 benchmark 為參考。