跳到主要内容

NVLS 超线速 AllReduce

NVLS（NVLink SHARP）利用 NVSwitch 芯片内置的归约引擎，将 AllReduce 的规约操作从 GPU 软件层下沉到交换芯片硬件，使每个 GPU 只需向交换机发送一次数据、接收一次归约结果，从根本上改变了 AllReduce 的算法复杂度和性能边界。

NVSwitch 的硬件规格和 NVLS 的物理实现细节见 ../02-硬件互联/nvswitch-nvls.md。本文聚焦集合通信算法视角：NVLS 如何改变 AllReduce 的代价模型，以及对建模的影响。

机制原理​

传统 Ring AllReduce 的问题​

Ring AllReduce 是带宽最优算法（见 all-reduce.md），但其代价结构有两个固有限制：

  1. 步数随 $N$ 线性增长：$2(N-1)$ 步，每步引入一次点对点延迟 $\alpha$，大规模场景延迟项不可忽视
  2. 带宽利用率上限 $\frac{N-1}{N}$：每个 GPU 实际需要发送和接收的数据量是 $\frac{2(N-1)}{N}M$，当 $N$ 很大时趋近于 $2M$，即每份数据发送了两次（ReduceScatter 一次 + AllGather 一次）

Ring AllReduce 的带宽项系数 $\frac{2(N-1)}{N}$ 是其理论下界——在 Ring 拓扑上，没有算法能以更少的数据量完成 AllReduce。但这个下界是针对 Ring 拓扑约束下的结论，在具备硬件归约能力的 NVSwitch 拓扑上，约束条件发生了根本改变。

NVLS 如何打破这一限制​

NVLS 将规约操作从 GPU 计算单元移入 NVSwitch 芯片内的归约引擎：

  • 发送阶段：每个 GPU 将本地数据 $A_i$（大小 $M$）发送给 NVSwitch，NVSwitch 对所有输入流水线执行累加
  • 接收阶段：NVSwitch 通过多播将归约结果 $\bigoplus A_i$ 同时分发给所有参与 GPU

整个过程对每个 GPU 而言只有 1 次发送 + 1 次接收，数据不经过任何 GPU 中转。Ring AllReduce 中每个 GPU 既是数据源也是中继节点；NVLS 消除了中继角色，GPU 只扮演数据源和数据接收方。

本质上，NVLS 是将 Reduction 从软件层（Ring 的每个 GPU 做本地规约）下沉到网络硬件层（NVSwitch 芯片内完成全局规约），与 InfiniBand SHARP 的设计哲学相同，但实现在 NVLink 专有硬件上，延迟更低、带宽更高。

与 Ring AllReduce 的带宽对比​

代价公式​

Ring AllReduce（$N$ 个 GPU，消息大小 $M$ 字节，单向链路带宽 $\beta$）：

$$\begin{equation} T_{\text{Ring}} = 2(N-1)\alpha + \frac{2(N-1)}{N} \cdot \frac{M}{\beta} \label{eq:nvls-ring-cost} \end{equation}$$

NVLS AllReduce（$\alpha_{\text{sw}}$ 为 NVSwitch 归约引擎处理延迟，约 100–200 ns）：

$$\begin{equation} T_{\text{NVLS}} = 2\alpha_{\text{sw}} + \frac{M}{\beta_{\text{NVLink}}} \label{eq:nvls-cost} \end{equation}$$

NVLS 的带宽项系数为 1（相对于 Ring 的 $\frac{2(N-1)}{N} \approx 2$），即在相同链路带宽下，NVLS 的有效吞吐量约为 Ring 的两倍。

算法指标综合对比​

指标Ring AllReduceNVLS AllReduce
每 GPU 发送量$\frac{(N-1)}{N}M$（ReduceScatter）+ $\frac{(N-1)}{N}M$（AllGather）$M$（仅 1 次）
每 GPU 接收量$\frac{(N-1)}{N}M$ + $\frac{(N-1)}{N}M$$M$（1 次多播）
步数$2(N-1)$2（固定，与 $N$ 无关）
延迟项$2(N-1)\alpha$（随 $N$ 线性增长）$2\alpha_{\text{sw}} \approx$ 常数
带宽利用率$\frac{N-1}{N}$（<100%，趋近但不达 100%）接近 100%（受链路物理带宽限制）
规模扩展性延迟随 $N$ 增大线性恶化延迟与 $N$ 无关

实测数据（H100 NVL72，消息大小 1 GB）​

算法实测带宽说明
Ring AllReduce~394 GB/s理论上限 $\frac{71}{72} \times 450 \approx 443$ GB/s；实测因软件开销低于理论值
NVLS AllReduce~480 GB/s超越 Ring 理论上限约 8%；不受 $(N-1)/N$ 系数约束

NVLS 的实测带宽超过了 Ring AllReduce 的理论上限，证明其突破的不是工程实现质量，而是算法层面的带宽约束。

适用规模与限制​

适用场景​

  • NVL8：单节点 8 个 GPU 通过 NVSwitch 全连接，NVLS 可用
  • NVL72：72 个 H100 + 9 个 NVSwitch 构成单域，NVLS 效果最显著（规模大，Ring 的 $O(N)$ 延迟劣势最明显）

所有参与 GPU 到任意 NVSwitch 都只需 1 跳，是 NVLS 的必要条件——这保证了 NVSwitch 可以收到所有 GPU 的数据并一次性完成归约。

不适用场景​

  • 多节点跨 InfiniBand/Ethernet：跨节点流量不经过 NVSwitch，无法触发 NVLS 归约引擎。此时 NCCL 自动回退到 Ring AllReduce 或 Double Binary Tree
  • 异构拓扑：部分 GPU 在 NVSwitch 域内、部分通过 PCIe 连接，整组通信无法启用 NVLS

原语限制​

当前 NVLS 仅支持 AllReduce 原语。ReduceScatter 和 AllGather 的独立 NVLS 加速尚未在 NVSwitch 3.0 上实现，仍需使用 Ring 或 Halving-Doubling 算法。这意味着：

  • 张量并行中的 AllReduce（TP 梯度同步）可受益于 NVLS
  • Sequence Parallelism 的 AllGather/ReduceScatter 暂时无法使用 NVLS

消息大小阈值：NCCL 2.17+ 在消息 > 256 KB 时自动启用 NVLS；小消息场景（< 64 KB）两种算法的延迟均由软件启动开销主导，差异不显著。

对通信建模的影响​

传统 α-β 模型的失效​

标准 α-β 模型将 AllReduce 代价建模为：

$$\begin{equation} T = \alpha_{\text{steps}} + \frac{M}{\beta_{\text{eff}}} \label{eq:nvls-alpha-beta-model} \end{equation}$$

其中 $\beta_{\text{eff}} = \frac{N}{2(N-1)} \beta_{\text{link}}$（Ring AllReduce 的有效带宽）。

在 NVLS 场景下，带宽项的 $\frac{N}{2(N-1)}$ 系数必须去掉，改为：

$$\begin{equation} \beta_{\text{eff}}^{\text{NVLS}} \approx \beta_{\text{NVLink}} \label{eq:nvls-effective-bw} \end{equation}$$

直接使用链路物理带宽，而非受 Ring 约束的有效带宽。若仍套用 Ring 模型，将系统性低估 NVLS 场景的 AllReduce 带宽约 2 倍（大规模时），导致通信时间预测偏保守，模型 MFU 估算偏低。

建模时的区域划分​

正确建模策略是区分两类通信域：

通信域判断条件AllReduce 模型
NVLS 域内所有 GPU 在同一 NVSwitch 全连接域，且消息 > 256 KB$T = 2\alpha_{\text{sw}} + \frac{M}{\beta_{\text{NVLink}}}$
跨域（Ring 回退）多节点、PCIe 连接、或消息过小$T = 2(N-1)\alpha + \frac{2(N-1)}{N} \cdot \frac{M}{\beta}$

参考资料​