Reduce-Scatter
3 秒看懂
Reduce-Scatter 是分散式計算中的一種集合通訊（Collective Communication）操作：多個參與節點各自持有資料，執行規約（如求和）後，將結果均勻分片散射給各節點——每個節點只最終持有自己負責的那一片完整規約結果。
一句話公式：
輸入：N 個節點，每個節點持有 N 份資料塊（M₁, M₂, …, Mₙ） 輸出：節點 i 獲得 Σ(M₁…Mₙ) 中的第 i 個分片
它是 AllReduce 的前半段，也是 ZeRO 最佳化器梯度分發的底層骨架。
3 分鐘產業解釋
為什麼 Reduce-Scatter 是萬億引數時代的”隱形基礎設施”
大型模型訓練的核心矛盾是：每個 GPU 的視訊記憶體裝不下完整模型。解決方案是把模型切分到成百上千張卡上平行計算，但切分後梯度必須全域性同步，這就需要集合通訊。
業界長期將 AllReduce（全規約廣播）視為標準梯度同步原語。但 AllReduce 的一個隱含假設是：每個節點都需要完整的規約結果。在 ZeRO（Zero Redundancy Optimizer）等視訊記憶體最佳化方案普及後，這個假設被打破——每個節點只需要自己負責更新的那部分引數對應的梯度。
這正是 Reduce-Scatter 的天然場景：
| 場景 | AllReduce | Reduce-Scatter |
|---|---|---|
| 資料並行 + 傳統最佳化器 | ✅ 每個節點需要完整梯度 | ❌ 浪費了 |
| ZeRO Stage 2 | 功能冗餘 | ✅ 每個節點只取自己分片 |
| 張量並行（Megatron-LM） | 可用但非最優 | ✅ 與 AllGather 配對更高效 |
產業意義：Reduce-Scatter + AllGather 的組合取代了傳統 AllReduce，成為 Megatron-LM 張量並行和 ZeRO 資料並行的核心通訊骨架。理解它，就理解了分散式訓練通訊效率的底層邏輯。
15 分鐘專家深入
一、Reduce-Scatter 在分散式訓練架構中的精確位置
1. Megatron-LM 張量並行（Tensor Parallelism）
Megatron-LM 將 Transformer 層的線性層在列/行兩個維度切分：
- 列並行（Column Parallel Linear）：權重按列切分，各 GPU 獨立計算部分輸出。
- 行並行（Row Parallel Linear）：權重按行切分，各 GPU 計算部分結果後需要規約。
在 Megatron-LM 的標準實現中，行並行層輸出使用 AllReduce 完成規約（即 Reduce-Scatter + AllGather 的合併版本）。但在引入**序列並行（Sequence Parallelism, SP）**後（Megatron-LM 後續版本及 Megatron-DeepSpeed），架構變為：
LayerNorm (各 GPU 處理不同序列段)
↓
AllGather → 收集完整啟用
↓
Column Parallel Linear (前向)
↓
Dropout / GeLU
↓
Row Parallel Linear (前向)
↓
Reduce-Scatter → 規約結果 + 分片回各 GPU 序列段 ← 這裡
↓
LayerNorm (各 GPU 處理自己分到的序列段)關鍵變化：SP 版本將 AllReduce 拆解為 Reduce-Scatter（前向路徑末尾）+ AllGather（前向路徑開頭），使得 LayerNorm 和 Dropout 的輸入只需處理區域性序列段，大幅節省了啟用視訊記憶體。
2. ZeRO 資料並行（Data Parallelism）
ZeRO 的核心洞察：
- 傳統資料並行：每個 rank 保留完整模型引數 → AllReduce 同步梯度 → 每個 rank 用完整梯度更新完整引數。
- ZeRO Stage 1：最佳化器狀態分片（每個 rank 只保留 1/N 的最佳化器狀態），但每個 rank 仍需完整梯度來更新完整模型引數，因此梯度同步依然是 AllReduce 語義。
- ZeRO Stage 2：梯度本身也分片儲存，此時每個 rank 僅需自己負責的那部分梯度。
因此，在 ZeRO Stage 2 中，傳統 AllReduce 被拆解為：
前向 + 反向 計算完成，每個 rank 持有完整本地梯度
↓
Reduce-Scatter ← 規約後，rank i 只持有第 i 片梯度
↓
rank i 用第 i 片梯度更新第 i 片引數
↓
AllGather ← 廣播更新後的引數分片，各 rank 拼回完整模型這比 AllReduce + 全量更新的方案每個 rank 節省了 ~4× 視訊記憶體（最佳化器狀態+梯度+引數副本方面）[來源：Rajbhandari et al., ZeRO Paper, 2020]。
二、通訊量分析
Ring 演算法下，Reduce-Scatter 的通訊量特性：
- 參與節點數：N
- 訊息總大小：M（每個節點持有 M 大小的資料）
- 每個節點發送/接收總量：(N-1)/N × M
- 步數：N-1（環演算法每步傳 1/N 的資料）
- 頻寬利用率：接近理論最優（漸近為 M，當 N 足夠大時）
對比：
| 操作 | 每節點通訊量 | 步數 | 頻寬最優性 |
|---|---|---|---|
| Reduce-Scatter | (N-1)/N × M | N-1 | ✅ 頻寬最優 |
| AllGather | (N-1)/N × M | N-1 | ✅ 頻寬最優 |
| AllReduce (=RS+AG) | 2(N-1)/N × M | 2(N-1) | ✅ 頻寬最優 |
| All-to-All | (N-1)/N × M | 取決於實現 | 因實現而異 |
注意：All-to-All 通訊量形式上與 Reduce-Scatter/Ring-AllGather 相似，但語義完全不同。All-to-All 是每對節點間交換不同資料（用於 MoE 的 dispatch/combine），Reduce-Scatter 是全域性規約後分片。
三、演算法實現
Ring Reduce-Scatter（最經典）
假設 N=4 個 rank，每個 rank 持有 [A, B, C, D] 四塊資料
目標：rank 0 得到 A+B+C+D 的第 0 片，rank 1 得到第 1 片……
Step 1: 每個 rank 傳送第 (rank+1)%4 塊給下一個 rank，接收上一個 rank 的對應塊
累加收到的資料到本地對應塊
Step 2: 繼續輪轉發送/接收，累加
Step 3: (N-1=3 步後) 每個 rank 的某個塊包含所有 rank 該塊的規約結果
該塊即為該 rank 的最終輸出頻寬分析：每步每個 rank 傳送 M/N 資料，共 N-1 步，總通訊量 (N-1)/N × M。當 N 較大時接近 M，為頻寬下界。
其他演算法
- Recursive Halving-Doubling：延遲最佳化，步數 O(log N)，但每步通訊量更大。適合小訊息+大節點數場景。
- Ring + Tree 混合：NCCL 等實現中，根據訊息大小和節點數自適應選擇演算法。
技術原理（最深）
數學定義
給定 N 個程序（rank 0, 1, …, N-1），每個 rank i 持有輸入向量 X_i（長度為 N·K，分為 N 個長度為 K 的塊：X_i = [X_i⁰, X_i¹, …, X_i^{N-1}]）。
Reduce-Scatter 運算定義為：
輸出 rank j 的結果 Y_j = Σ_{i=0}^{N-1} X_i^j即所有 rank 對應第 j 塊的元素求和，結果歸 rank j。
規約操作通常為 SUM，也支援 MAX、MIN、PROD 等。
Ring 演算法詳細機制
N=4, 每個 rank 資料分為 4 塊: [b0, b1, b2, b3]
初始狀態:
Rank 0: [a0, a1, a2, a3]
Rank 1: [b0, b1, b2, b3]
Rank 2: [c0, c1, c2, c3]
Rank 3: [d0, d1, d2, d3]
Step 1 (傳送 rank+1 mod 4 的塊):
Rank 0 發 a1 → Rank 1, 接收 d1 (上一 rank 的第 1 塊)
→ Rank 0: [a0, a1, a2, a3], 本地第 1 塊累加 → [a0, a1+d1, a2, a3]
(實際上 ring 的 index 計算有細節，此處簡化示意)
經過 N-1=3 步後:
Rank 0 持有: [a0+b0+c0+d0, _, _, _] (第 0 塊的完整規約)
Rank 1 持有: [_, a1+b1+c1+d1, _, _] (第 1 塊的完整規約)
Rank 2 持有: [_, _, a2+b2+c2+d2, _]
Rank 3 持有: [_, _, _, a3+b3+c3+d3]關鍵效能公式
Ring Reduce-Scatter 延遲模型:
T_rs = (N-1) × α + (N-1)/N × M/β
其中:
α = 網路延遲（latency per hop）
β = 網路頻寬（bandwidth）
N = rank 數量
M = 每個 rank 的訊息大小（位元組）
(N-1)×α = N-1 次 hop 的累積延遲
(N-1)/N × M/β = 總資料傳輸時間（頻寬受限部分）關鍵推論：
- 當 M 很大（大型模型梯度同步正是此場景），頻寬項主導，延遲項可忽略。
- 此時 Reduce-Scatter 通訊量趨近 M，頻寬利用率接近 100%。
- 這是大型模型訓練中集合通訊頻寬敏感（bandwidth-bound）的理論基礎。
與 AllReduce 的嚴格關係
AllReduce(X) = AllGather( Reduce-Scatter(X) )
證明:
Reduce-Scatter 後: rank i 持有 Y_i = Σ X_j^i (第 i 片規約結果)
AllGather 後: 每個 rank 收集所有 Y_i，得到 [Y_0, Y_1, ..., Y_{N-1}]
即完整的規約結果，與 AllReduce 語義一致。 ∎NCCL 實現層
NCCL（NVIDIA Collective Communications Library）是 NVIDIA GPU 叢集上最常用的集合通訊庫。Reduce-Scatter 在 NCCL 中的介面為 ncclReduceScatter。
NCCL 根據以下因素自適應選擇演算法：
- 訊息大小：小訊息傾向 Tree/Halving-Doubling，大訊息傾向 Ring
- 節點內 vs 節點間：節點內常用 NVLink/NVSwitch 直連拓撲；節點間走 InfiniBand/RoCE
- 拓撲感知：NCCL 會檢測實際硬體拓撲，建置通訊環/樹
注意：NCCL 的具體演算法選擇策略隨版本迭代，此處僅描述一般原則，具體版本行為請參閱 NCCL 官方文件。
技術演進史
| 時間線 | 事件 | 意義 |
|---|---|---|
| ~1994 | MPI 標準化（MPI-1） | Reduce-Scatter 作為標準集合操作被定義（MPI_Reduce_scatter） |
| ~2010s | NCCL v1 釋出 | NVIDIA 為 GPU 叢集提供原生集合通訊庫 |
| 2017 | Horovod（Uber 開源） | 基於 NCCL/MPI 封裝，降低分散式訓練門檻；底層梯度同步仍用 AllReduce |
| 2019 | Megatron-LM（NVIDIA） | 提出張量並行，展示了 AllReduce 在 Transformer 層間的精確嵌入位置 |
| 2020 | ZeRO（DeepSpeed/Microsoft） | 關鍵轉折：將 AllReduce 拆解為 Reduce-Scatter + AllGather，使 Reduce-Scatter 從理論原語變為工業級必需 |
| 2021 | Megatron-DeepSpeed + Sequence Parallelism | Reduce-Scatter 在 SP 前向路徑中承擔啟用分片職責 |
| 2022+ | 3D/4D 並行成為萬億模型標配 | Reduce-Scatter 在張量並行維和 ZeRO 資料並行維同時活躍，成為通訊 profile 中佔比最高的操作之一 |
技術路線對比
Reduce-Scatter vs 相關集合操作
| 維度 | Reduce-Scatter | AllReduce | AllGather | All-to-All |
|---|---|---|---|---|
| 語義 | 全域性規約 → 分片輸出 | 全域性規約 → 全量輸出 | 拼接各 rank 片段 | 每對 rank 交換不同資料 |
| 輸出 | 每個 rank 得 1/N 規約結果 | 每個 rank 得完整規約結果 | 每個 rank 得完整拼接 | 每個 rank 得定製資料 |
| Ring 通訊量/節點 | (N-1)/N × M | 2(N-1)/N × M | (N-1)/N × M | (N-1)/N × M |
| 典型訓練場景 | ZeRO 梯度分發、SP 前向 | 傳統 DP 梯度同步 | ZeRO 引數廣播、SP 反向 | MoE Expert dispatch |
| 是否頻寬最優 | ✅ | ✅ | ✅ | 因實現而異 |
Ring vs 其他演算法實現
| 演算法 | 步數 | 每步通訊量 | 總通訊量/節點 | 適用場景 |
|---|---|---|---|---|
| Ring | N-1 | M/N | (N-1)/N·M | 大訊息，頻寬受限 |
| Recursive Halving-Doubling | log₂N | M/(2^k) 遞增 | M（漸近） | 小訊息，延遲受限 |
| Rabenseifner’s Algorithm | log₂N | 漸進式 | ~M | 兼顧延遲與頻寬 |
以上演算法特性為經典 HPC 文獻中的理論分析，NCCL 等實際庫的實現可能採用混合策略。
上下游
上游（Reduce-Scatter 依賴什麼）
硬體層:
├── GPU: NVIDIA A100/H100/H200/B100/B200 (計算端)
├── 互連: NVLink/NVSwitch (節點內), InfiniBand/RoCE (節點間)
└── 網絡卡: ConnectX-6/7 (InfiniBand), BlueField DPU (可選)
通訊庫層:
├── NCCL (NVIDIA) ← 最主流
├── MPI (OpenMPI, MVAPICH)
├── Gloo (Meta, PyTorch 預設後端之一)
└── 專用庫: HCCL (華為), OneCCL (Intel)
架構層呼叫入口:
├── PyTorch: dist.reduce_scatter() / dist.reduce_scatter_tensor()
├── DeepSpeed: 通過 ZeRO 最佳化器自動編排
├── Megatron-LM: SP 路徑中內嵌
└── JAX: jax.lax.ppermute / psum + shard 模式下游（Reduce-Scatter 被誰消費）
訓練範式:
├── ZeRO Stage 1/2/3: 梯度規約後分片，各 rank 更新本地分片
├── 張量並行 + SP: 前向路徑規約行並行輸出
├── 2D/3D 並行: 多個並行維度中各自使用
└── 模型並行 + 流水線並行: micro-batch 梯度累積中的同步點關鍵指標
| 指標 | 說明 | 典型量級（估算） |
|---|---|---|
| 通訊量/節點 | (N-1)/N × M | N=64, M=1GB → ~0.985 GB |
| 時延（Ring） | (N-1)×α + (N-1)/N×M/β | 取決於網路；IB HDR 200Gbps 下，大訊息秒級完成 |
| 頻寬利用率 | 理論趨近 100%（大訊息） | 實測可達理論頻寬 80-95%（NCCL Ring）[供應鏈經驗估算] |
| 與 AllReduce 的比值 | 通訊量 ≈ AllReduce 的 1/2 | 精確為 (N-1)/N × M vs 2(N-1)/N × M |
| GPU 利用率影響 | 計算-通訊重疊程度 | 理想情況可 100% 重疊（計算做滿時通訊在後臺） |
標註：上表中具體數值為基於通訊量公式的理論計算和行業通用經驗估算，實際效能因拓撲、NCCL 版本、訊息大小等因素而異。
供需與市場資料
為什麼 Reduce-Scatter 的效率直接影響訓練成本
訓練總時間 ≈ 計算時間 + 通訊時間 + 資料載入時間 + 其他開銷
通訊時間中，Reduce-Scatter（及 AllGather）的佔比:
- ZeRO 模式: 每個 training step 觸發 1 次 Reduce-Scatter + 1 次 AllGather
- 通訊量 ≈ 2 × (N-1)/N × (模型引數量 × sizeof(dtype))
- 對於 175B 引數、FP16/BF16: ~700 GB 總通訊量（每步）
- 節點間頻寬直接決定這 700 GB 的傳輸時間網路頻寬需求估算
| 模型規模 | 每步梯度同步資料量（BF16） | 1024 GPU Ring 下 RS 單次耗時（估算） |
|---|---|---|
| 7B | ~14 GB | 400Gbps IB → 亞秒級 |
| 70B | ~140 GB | 400Gbps IB → 數秒 |
| 175B | ~700 GB | 400Gbps IB → ~14-16 秒 |
| 1T+ | ~2 TB | 需要 NVSwitch 叢集 + 高速 IB，否則通訊成為瓶頸 |
以上為粗略理論估算，假設每步 AllReduce = 2 × 模型大小通訊，RS 佔一半。實際取決於並行策略、梯度累積步數、混合精度方案等。
產業推論：網路互連頻寬每翻一倍，Reduce-Scatter 瓶頸減半，直接等效於訓練效率提升。這驅動了 400G→800G→1.6T InfiniBand 的升級需求。
代表公司與資本對映
通訊庫/軟體棧
| 公司/組織 | 產品 | 與 Reduce-Scatter 的關係 |
|---|---|---|
| NVIDIA | NCCL | 最主流實現，決定性影響實際效能 |
| Microsoft | DeepSpeed (ZeRO) | 將 RS 從理論原語推向工業標配 |
| Meta | PyTorch FSDP (Fully Sharded Data Parallel) | 底層使用 RS+AG 替代 AllReduce |
| 華為 | HCCL | 昇騰生態的集合通訊庫 |
硬體（決定 RS 效能上限）
| 維度 | 代表公司/產品 | 影響 |
|---|---|---|
| 節點內互連 | NVIDIA NVLink/NVSwitch | 節點內 RS 頻寬可達 900 GB/s（NVSwitch on H100） |
| 節點間網路 | NVIDIA InfiniBand（ConnectX-7）、Broadcom/Marvell 交換晶片 | 節點間 RS 頻寬上限 |
| RDMA 網絡卡 | NVIDIA ConnectX-7、AMD Pensando | 零複製、核心旁路降低延遲 |
| 智慧網絡卡/DPU | NVIDIA BlueField、Intel IPU | 可解除安裝部分通訊邏輯 |
投資邏輯
核心邏輯鏈
Reduce-Scatter 效率 → 分散式訓練通訊效率 → 大型模型訓練成本/速度
↑ ↑
網路頻寬需求 通訊量 = f(模型引數量)
↑ ↑
IB/RoCE 升級週期 模型引數量持續增長可投資方向
-
網路互連硬體（直接受益）：
- InfiniBand 生態（NVIDIA 為主導）
- RoCE 生態（Broadcom、Marvell 交換晶片，AMD/Pensando 網絡卡）
- 800G/1.6T 光模組（中際旭創、新易盛等——中國供應鏈視角）
-
通訊庫/軟體棧：
- NVIDIA NCCL 是 CUDA 生態的”鎖”之一，增強客戶黏性
- 開源替代（如 MSCCL、RCCL for AMD）有差異化機會
-
訓練平台/架構：
- DeepSpeed、FSDP 等架構深度耦合 RS+AG 模式，是大型模型訓練的”作業系統級”元件
-
拓撲最佳化：
- 定製網路拓撲（如 NVIDIA 的 rail-optimized 拓撲）旨在最大化 RS/AG 的實際頻寬
常見誤讀糾偏
❌ 誤讀一：“Reduce-Scatter 就是 AllReduce 的一半”
糾偏：通訊量確實是 AllReduce 的約一半（Ring 演算法下），但語義完全不同。AllReduce 的輸出是每個節點得到完整規約結果，Reduce-Scatter 的輸出是每個節點只得到自己負責的那 1/N 分片。它們不是”同一功能的最佳化”，而是不同需求場景下的不同操作。將 RS 視為 AllReduce 的”最佳化版”會導致對 ZeRO 等方案的架構理解錯誤。
❌ 誤讀二：“Reduce-Scatter 只在反向傳播中使用”
糾偏：在傳統 ZeRO 資料並行中，RS 確實主要在反向傳播的梯度同步階段使用。但在引入序列並行的張量並行中，Reduce-Scatter 也出現在前向傳播路徑（行並行層輸出的規約階段）。將 RS 限定為”反向操作”會遺漏 SP 前向路徑中的關鍵通訊。
❌ 誤讀三：“Ring 演算法總是最優的 Reduce-Scatter 實現”
糾偏：Ring 在大訊息場景下頻寬最優，但對小訊息（如某些梯度累積的中間步驟），其 O(N) 的延遲可能成為瓶頸。Recursive Halving-Doubling 等演算法在小訊息場景下 O(log N) 的延遲更優。實際部署中 NCCL 會根據訊息大小和拓撲自適應選擇演算法。不存在”通用最優”的單一演算法。
❌ 誤讀四：“Reduce-Scatter 的通訊量與並行度無關”
糾偏：Ring 演算法下每節點通訊量為 (N-1)/N × M，當 N（並行度）增大時，該值趨近 M。但拓撲約束下，節點數增加意味著環上 hop 數增加，延遲項 (N-1)×α 線性增長。此外，更多節點可能需要跨更多網路域（機架、pod），有效頻寬下降。因此並非節點越多 RS 越快，存在通訊效率的拐點。
學習路徑
入門（1-2 小時）
- 理解 MPI 集合操作的基本概念（推薦：MPI Forum 官方文件中 Reduce-Scatter 部分）
- 用 PyTorch
dist.reduce_scatter_tensor()寫一個 2-GPU 的簡單示例
進階（3-5 小時）
- 閱讀 ZeRO 論文（Rajbhandari et al., 2020）—— 理解 RS+AG 如何替代 AllReduce
- 閱讀 Megatron-LM Sequence Parallelism 論文（Korthikanti et al., 2022）—— 理解 RS 在前向路徑的角色
- 用 NCCL 測試工具（
nccl-tests）實測不同訊息大小下 RS 的頻寬
專家（持續深入）
- 研究 NCCL 原始碼中的演算法選擇邏輯
- 學習集合通訊的計算-通訊重疊（overlap）技術，如 NCCL 2.18+ 的 MSCCL 整合
- 研究拓撲感知的集合通訊排程（如 TACCL、Blink 等學術工作）
- 追蹤 3D 並行/Context Parallelism 等新並行策略中 RS 的角色演變
一句話總結
Reduce-Scatter 是分散式訓練中”全域性規約、分片輸出”的通訊原語——它是 ZeRO 視訊記憶體最佳化和 Megatron-LM 序列並行的通訊骨架，其效率直接受網路頻寬制約，是理解大型模型訓練基礎設施成本結構的關鍵一環。
延伸閱讀與來源
核心論文
- ZeRO: Rajbhandari et al., “ZeRO: Memory Optimizations Toward Training Trillion Parameter Models”, SC 2020
- Megatron-LM (SP): Korthikanti et al., “Reducing Activation Recomputation in Large Transformer Models”, 2022
- Ring AllReduce: Patarasuk & Yuan, “Bandwidth optimal all-reduce algorithms for clusters of workstations”, J. Parallel and Distributed Computing, 2009
官方文件
- NVIDIA NCCL Documentation: https://docs.nvidia.com/deeplearning/nccl/
- PyTorch Distributed: https://pytorch.org/docs/stable/distributed.html
- MPI Standard (MPI_Reduce_scatter): https://www.mpi-forum.org/docs/
工程實踐
- DeepSpeed ZeRO Tutorial: https://www.deepspeed.ai/tutorials/zero/
- FSDP Tutorial (PyTorch): https://pytorch.org/tutorials/intermediate/FSDP_tutorial.html
- NCCL Tests (benchmark 工具): https://github.com/NVIDIA/nccl-tests
免責宣告：本文中涉及的具體效能數字（如頻寬利用率百分比、耗時估算等）部分為基於通訊模型的理論計算和行業通用經驗估算，標註為 [供應鏈經驗估算] 或 [理論計算] 的資料未經過特定廠商驗證。硬體規格（如 NVLink 頻寬、IB 速率等）以對應廠商官方公佈為準。