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 的天然场景：

产业意义：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 足够大时）

对比：

注意：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 官方文档。

技术演进史

技术路线对比

Reduce-Scatter vs 相关集合操作

Ring vs 其他算法实现

以上算法特性为经典 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 梯度累积中的同步点

关键指标

标注：上表中具体数值为基于通信量公式的理论计算和行业通用经验估算，实际性能因拓扑、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 的传输时间

网络带宽需求估算

以上为粗略理论估算，假设每步 AllReduce = 2 × 模型大小通信，RS 占一半。实际取决于并行策略、梯度累积步数、混合精度方案等。

产业推论：网络互连带宽每翻一倍，Reduce-Scatter 瓶颈减半，直接等效于训练效率提升。这驱动了 400G→800G→1.6T InfiniBand 的升级需求。

代表公司与资本映射

通信库/软件栈

硬件（决定 RS 性能上限）

投资逻辑

核心逻辑链

Reduce-Scatter 效率 → 分布式训练通信效率 → 大模型训练成本/速度
     ↑                        ↑
 网络带宽需求            通信量 = f(模型参数量)
     ↑                        ↑
 IB/RoCE 升级周期       模型参数量持续增长

可投资方向

1. 网络互连硬件（直接受益）：

   • InfiniBand 生态（NVIDIA 为主导）
   • RoCE 生态（Broadcom、Marvell 交换芯片，AMD/Pensando 网卡）
   • 800G/1.6T 光模块（中际旭创、新易盛等——中国供应链视角）

2. 通信库/软件栈：

   • NVIDIA NCCL 是 CUDA 生态的”锁”之一，增强客户黏性
   • 开源替代（如 MSCCL、RCCL for AMD）有差异化机会

3. 训练平台/框架：

   • DeepSpeed、FSDP 等框架深度耦合 RS+AG 模式，是大模型训练的”操作系统级”组件

4. 拓扑优化：

   • 定制网络拓扑（如 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 小时）

1. 理解 MPI 集合操作的基本概念（推荐：MPI Forum 官方文档中 Reduce-Scatter 部分）
2. 用 PyTorch dist.reduce_scatter_tensor() 写一个 2-GPU 的简单示例

进阶（3-5 小时）

3. 阅读 ZeRO 论文（Rajbhandari et al., 2020）—— 理解 RS+AG 如何替代 AllReduce
4. 阅读 Megatron-LM Sequence Parallelism 论文（Korthikanti et al., 2022）—— 理解 RS 在前向路径的角色
5. 用 NCCL 测试工具（nccl-tests）实测不同消息大小下 RS 的带宽

专家（持续深入）

6. 研究 NCCL 源码中的算法选择逻辑
7. 学习集合通信的计算-通信重叠（overlap）技术，如 NCCL 2.18+ 的 MSCCL 集成
8. 研究拓扑感知的集合通信调度（如 TACCL、Blink 等学术工作）
9. 跟踪 3D 并行/Context Parallelism 等新并行策略中 RS 的角色演变

一句话总结

Reduce-Scatter 是分布式训练中”全局规约、分片输出”的通信原语——它是 ZeRO 显存优化和 Megatron-LM 序列并行的通信骨架，其效率直接受网络带宽制约，是理解大模型训练基础设施成本结构的关键一环。

延伸阅读与来源

核心论文

1. ZeRO: Rajbhandari et al., “ZeRO: Memory Optimizations Toward Training Trillion Parameter Models”, SC 2020
2. Megatron-LM (SP): Korthikanti et al., “Reducing Activation Recomputation in Large Transformer Models”, 2022
3. Ring AllReduce: Patarasuk & Yuan, “Bandwidth optimal all-reduce algorithms for clusters of workstations”, J. Parallel and Distributed Computing, 2009

官方文档

4. NVIDIA NCCL Documentation: https://docs.nvidia.com/deeplearning/nccl/
5. PyTorch Distributed: https://pytorch.org/docs/stable/distributed.html
6. MPI Standard (MPI_Reduce_scatter): https://www.mpi-forum.org/docs/

工程实践

7. DeepSpeed ZeRO Tutorial: https://www.deepspeed.ai/tutorials/zero/
8. FSDP Tutorial (PyTorch): https://pytorch.org/tutorials/intermediate/FSDP_tutorial.html
9. NCCL Tests (benchmark 工具): https://github.com/NVIDIA/nccl-tests

免责声明：本文中涉及的具体性能数字（如带宽利用率百分比、耗时估算等）部分为基于通信模型的理论计算和行业通用经验估算，标注为 [供应链经验估算] 或 [理论计算] 的数据未经过特定厂商验证。硬件规格（如 NVLink 带宽、IB 速率等）以对应厂商官方公布为准。