All-Reduce 全歸約通訊

3 秒看懂

All-Reduce 是分散式訓練中讓每塊 GPU 擁有完全一致梯度的高效全域性同步協議。它先“歸約”（求和/平均）所有節點的資料，再將結果廣播回每一個節點，是千卡、萬卡叢集訓練大型模型的通訊基石。

3 分鐘產業解釋

在深度學習的資料並行訓練中，所有 GPU 各自持有同一份模型副本，各自計算出一個梯度。為了讓模型引數同步更新，必須把分散在各 GPU 上的梯度求和（或求平均），然後讓每一塊 GPU 都獲得這個累加後的梯度值。這個“每個節點貢獻一個數組 → 所有節點都得到該陣列的全域性求和”的操作，就是 All-Reduce。

如果直接採用“選一個節點收集全部梯度 → 求和 → 再廣播”的樸素方式，收集節點的入口頻寬會成為瓶頸，千卡叢集下可能讓網路瞬間擁塞，GPU 大量時間空轉等待同步。產業界真正落地的是 Ring All-Reduce 和 Tree All-Reduce 等頻寬最佳化演算法，它們將通訊分攤到所有鏈路上，使得每塊 GPU 的傳送／接收量接近一個常數，消除了單點瓶頸，將通訊時間控制在與 GPU 數量幾乎無關的水平。

All-Reduce 效能直接決定了資料並行的擴充套件效率，已被固化為 NVIDIA NCCL、Facebook Gloo、Horovod、PyTorch DistributedDataParallel 等底層通訊庫的標準運算元。在千億引數大型模型（例如 MoE 架構）中，除資料並行外，All-Reduce 還被廣泛用於張量並行、流水線並行的梯度同步。

15 分鐘專家深入

在深度學習範疇，All-Reduce 主要以求和為歸約操作，沿以下路徑被深度最佳化：

通訊計算重疊（overlap） 現代架構將 All-Reduce 拆分為 Reduce-Scatter（先分散歸約，使每個節點持有部分結果的唯一分片）和 All-Gather（再將分片廣播至所有節點）。這種拆解可以讓通訊與反向傳播最後一層的計算重疊執行，進一步隱藏延遲。
面向拓撲的演算法選擇
- Ring All-Reduce：所有節點構成邏輯環，資料被切分為 P（節點數）個小塊，通過 P-1 輪步進式傳送／接收，最終完成全歸約。頻寬利用率接近最優（每個節點總通訊量 2(N-1)/N \cdot \text{資料量}，當 N 很大時趨於 2 倍資料量），但延遲隨 P 線性增加。
- Tree／Recursive Halving-Doubling：通過多級樹形或蝴蝶網路以對數級步數完成歸約與廣播，延遲極小，但需要更多併發鏈路，且難以充分利用節點所有出口頻寬。
- 雙二叉樹／2D-Torus 演算法：針對胖樹或2D網狀網路拓撲進行定製，避免鏈路爭用，是超大規模叢集（如 TPU Pod、某些 HPC 系統）的優選。
混合並行場景下的用量 在 3D 並行（資料並行 × 張量並行 × 流水線並行）中，張量並行通常會引發每一層內部頻繁的 All-Reduce（通訊量正比於每層的啟用或梯度）。這時通常會將資料並行和張量並行的通訊做優先順序排程，或使用 NVLink/NVSwitch 短距高頻寬域來承載張量並行的 All-Reduce，對外部節點間的資料並行採用 InfiniBand/RoCE 的 Ring 演算法。
與 All-to-All 的區別 一個常見混淆點是：張量並行通常需要 All-Reduce（或 All-Gather + Reduce-Scatter），而 MoE 的路由分發使用 All-to-All（每個節點發送不同資料到不同節點，無歸約）。如果錯誤地在 MoE dispatch 中使用 All-Reduce，不僅浪費頻寬，還會破壞專家輸入的獨立性。

技術原理

數學定義

有 p 個程序，每個程序 i 擁有一個長度為 D 的向量 x_i。All-Reduce 操作輸出向量 y 到所有程序，滿足：

y = x_1 \oplus x_2 \oplus \cdots \oplus x_p

其中 \oplus 是滿足交換律和結合律的二元運算。深度學習中通常為逐元素求和（sum），有時為平均（mean，通過對 sum 結果乘以 1/p 實現）。

實現核心：Ring All-Reduce

以 4 個節點（GPU0~GPU3）為例，每個節點的梯度被等分為 p = 4 個數據塊。演算法分兩階段：

階段 1：Reduce-Scatter（分散歸約）
節點在環上單向傳遞，每一步將收到的塊與本地對應塊歸約（求和）後，再發給下一個鄰居。經過 p-1 步，每個節點持有完整歸約結果的一個分片。

階段 2：All-Gather（全收集）
節點將持有的分片環上接力轉發，不再做歸約，只做覆蓋。再經 p-1 步，所有節點收集到全部歸約分片，重建完整梯度。

ASCII 示意（4 節點環）：

初始:   GPU0: [A0 B0 C0 D0]    GPU1: [A1 B1 C1 D1]
        GPU2: [A2 B2 C2 D2]    GPU3: [A3 B3 C3 D3]

第一步(Reduce-Scatter，傳遞方向→):
  GPU0 傳送 C0 給 GPU1；GPU1 計算 C0+C1 → 繼續發 C0+C1 給 GPU2...
  最終 GPU3 持有完整 sum(C)
  類似地，其他分片歸約完成。

第二步(All-Gather):
  GPU3 將 sum(C) 沿環傳給 GPU0、GPU1、GPU2，所有節點獲得 sum(C)。
  重複操作完成全部分片重組。

階段總步數 2(p-1)。每個節點總的資料傳輸量 = 2 \times \frac{p-1}{p} \times D ≈ 2D，與 p 無關。這意味著增加節點不會增加每個節點的通訊量，理論上可實現近乎線性的擴充套件。

通訊量與延遲

通訊量：當節點數 N 很大時，每個節點收發約 2D 元素（對於求和 All-Reduce）。對比樸素星型拓撲中央節點收發 N\cdot D 元素，Ring 徹底消除了瓶頸。
延遲：受步數 2(N-1) 影響，節點數極多時延遲可能明顯增加；可通過採用跨步更大的遞迴倍增（recursive doubling）或多環分割（hierarchical ring）來折中。

關鍵引數（定性）

演算法頻寬利用率：實際吞吐與物理鏈路頻寬的比值，取決於報文大小、步間 pipeline 填充和擁塞控制。
初始啟動延遲：樹形演算法以對數步數取得低延遲，但不容易完全佔滿頻寬。
支援的資料型別：FP16/BF16/FP32，以及 FP8 混合精度的歸約，通常要求底層集合通訊庫支援對應還原操作（BF16 求和可能需轉為 FP32 累積後放縮）。

技術演進史

MPI 時代（1990s-2010）：All-Reduce 已是 MPI 標準中的原語（MPI_Allreduce），用於科學計算。演算法以 Recursive Halving、Ring、Butterfly 為主，面向通用 CPU 叢集。
CUDA 感知的 MPI（2011-）：MVAPICH、OpenMPI 推出 CUDA-aware MPI，允許 GPU 記憶體直接參與 All-Reduce，避免 CPU 中轉。
NCCL 誕生（2015-）：NVIDIA 專為 GPU 間通訊最佳化的集合通訊庫，重點實現 GPU-direct Ring All-Reduce 和 Tree All-Reduce，並利用 NVLink、NVSwitch 實現節點內超高頻寬。
Horovod（2017-）：Uber 開源，將 All-Reduce 作為分散式 TensorFlow/Keras 訓練的標準同步原語，以 Ring All-Reduce 為主，大幅簡化分散式深度學習。
PyTorch DistributedDataParallel（2019-）：PyTorch 原生整合 NCCL/Gloo 後端，All-Reduce 成為預設梯度同步方式，支援非同步同步與通訊計算重疊。
大規模定製化（2020-）：在萬卡級叢集中，出現層次化 All-Reduce 方案（節點內 NVLink 樹 + 節點間環），以及通過 SHARP（在網計算）在交換器內部直接進行歸約，進一步降低通訊量。

技術路線對比

方案	步數複雜度	每個節點通訊量	頻寬利用效率	適用網路拓撲
樸素中心化歸約+廣播	2 步	中心節點 O(ND)	極低（中心瓶頸）	任意（差）
Recursive Halving	O(log₂N)	≈ 2D	中等（需多鏈路併發）	全互聯或胖樹
Ring All-Reduce	2(N-1)	≈ 2D	極高	環／線性／任意
雙二叉樹	2log₂N	≈ 2D	高（無擁塞設計）	胖樹或定製
網內歸約（SHARP）	1 步（邏輯）	≈ 2D	極高	需交換器支援

注：表中通訊量指總資料量歸一化到引數 D，具體常數值與環境實現有關。

上下游

上游
- 網路硬體：InfiniBand HCA、RoCE 網絡卡、NVLink/NVSwitch、乙太網路交換晶片、光電互聯。
- GPU 通訊庫：NCCL、Gloo、MPI、oneCCL。
- 晶片間互連 IP：例如 NVLink-C2C、UALink 等。
下游
- 分散式訓練架構：PyTorch DDP、FSDP；TensorFlow tf.distribute；Horovod；DeepSpeed。
- 模型並行策略與編譯器：Megatron-LM、SDPipe、GSPMD、Alpa（自動並行，將 All-Reduce 隱式插入計算圖）。
- 大型模型訓練：GPT-4、LLaMA-70B、DeepSeek V3 等千億/萬億引數模型均重度依賴高效 All-Reduce。

關鍵指標

匯流排頻寬（bus bandwidth）：All-Reduce 操作等效對外匯流排頻寬 = \frac{\text{歸約資料量}}{\text{耗時}}，常以 GB/s 衡量。理想可接近物理鏈路單向頻寬 × 節點數 × 利用係數。
延遲（latency）：小訊息下主要由固定開銷和步數決定；大訊息下由頻寬和步數劃分粒度影響。
擴充套件效率：加速比 = \frac{T_1}{T_N}，通訊佔比越低，擴充套件效率越高。定性上，Ring 在數千卡內保持良好效率，萬卡以上需層次化或網內歸約。
計算通訊重疊程度：是否允許 All-Reduce 與反向傳播的最後一個梯度計算同時進行，影響端到端吞吐。

具體數值高度依賴叢集配置，本文不提供通用硬數字。

供需與市場資料

因檢索服務受限，本節無法給出具體市場資料，僅提供產業趨勢定性描述。

大型模型訓練需求驅動了從 400Gbps 到 800Gbps 乃至 1.6Tbps 高速網路介面的快速迭代，直接服務於 All-Reduce 等集合通訊對匯流排的飢渴需求。
高速交換器和網絡卡（如 InfiniBand NDR/XDR 和 Spectrum-X）的市場規模隨 AI 訓練叢集建設急劇擴張，頭部雲端廠商的自研加速器（如 TPU、Trainium）也均在內部設計高頻寬互聯以承載 All-Reduce。
網內計算（In-Network Computing）成為新一輪競爭焦點，通過交換器直接執行求和，將 All-Reduce 資料量削減一半，被視為突破萬卡擴充套件瓶頸的重要方向。
高效能集合通訊庫（尤其 NCCL）已構成事實上的生態壁壘，其與硬體深度繫結的特性使得新進入者需要付出巨大的適配成本。

代表公司與資本對映

NVIDIA（NVDA）：擁有 NCCL 庫、NVLink/NVSwitch 及 InfiniBand（收購 Mellanox）整套垂直封閉生態，All-Reduce 效能在自家 GPU 叢集上有極大優勢。在網計算 SHARP 技術也由其交換器支援。
AMD（AMD）：推出 RCCL（ROCm Communication Collectives Library）對標 NCCL，與自家 Instinct GPU 配合，正在建置開放互聯標準 UALink。
Intel（INTC）：提供 oneCCL（oneAPI Collective Communications Library）以及 Gaudi 加速器內建的 RDMA over Converged Ethernet (RoCE) 方案。
Arista / Cisco / Broadcom：為 AI 叢集提供高吞吐、低延遲交換晶片和交換器，部分廠商正推進標準化的網內計算功能。
雲端服務商（Google / AWS / Microsoft / Oracle）：自研 AI 晶片（TPU、Trainium、Maia）時，均深度自研集合通訊棧和互聯架構，以此獲得差異化競爭力。
Meta（META）：開源了基於 RoCE 的大規模 AI 叢集設計（如 Grand Teton），並開發了集合通訊庫 Gloo，推動開放生態。

從投資視角看，All-Reduce 是衡量 AI 基礎設施互聯能力的關鍵維度，擁有高效能通訊棧和硬體耦合能力的公司，在萬卡叢集建置和大型模型訓練上掌握更強話語權。

投資邏輯

通訊即算力：當 GPU 數量足夠多時，訓練時間常由通訊主導。能為 All-Reduce 提供更低延遲、更高匯流排頻寬的互連技術，能夠直接提升 AI 訓練的可擴充套件性，構成晶片和網路公司的核心競爭力。
垂直整合溢價：NCCL + NVLink + InfiniBand 的深度耦合使得第三方加速器無法僅憑單卡算力打破壁壘，NVIDIA 系統級解決方案享受高定價權。
網內計算賽道：交換器內執行求和可減少一半資料量，成為下一代 AI 網路標案，相關交換晶片及裝置商迎來新增量。
開放生態的機會與風險：UALink 等開放標準如果成熟，可能削弱現有閉環生態的優勢，需密切關注其推廣進度及效能表現。

常見誤讀糾偏

誤讀 1：“All-Reduce 就是先 Reduce 再 Broadcast。”
實際工程實現中，高效的 All-Reduce（如 Ring All-reduce）絕不會走“中心化歸約後廣播”的流程，而是通過 Reduce-Scatter + All-Gather 或遞迴對半交換分攤通訊，消除中心節點瓶頸。
誤讀 2：“All-Reduce 通訊量隨 GPU 數量線性增長。”
對頻寬最佳化的演算法（例如 Ring），每個 GPU 的傳送/接收總量近似為常數（約 2× 梯度總資料量），並不會隨著多卡而膨脹。從每個 GPU 視角看，通訊負擔幾乎不變，這是其能線性擴充套件的關鍵。
誤讀 3：“All-Reduce 是 MoE 路由的通訊模式。”
MoE（混合專家）中 token 分發到不同專家使用的是 All-to-All 集合通訊，不存在歸約操作。兩者輸入輸出語義完全不同，不可互換。

學習路徑

基礎概念：閱讀 MPI 標準中關於 Collective Operations 章節，理解 Reduce、Broadcast、Gather、Scatter 等原子操作。
核心論文：
- “Bandwidth optimal all-reduce algorithms for clusters of workstations”（Thakur et al.）—— 經典最優演算法分析。
- “Horovod: fast and easy distributed deep learning in TensorFlow”（Sergeev & Balso）—— 展現 All-Reduce 在深度學習中的工程應用。
實現剖析：研讀 NCCL 文件及 Ring/Tree 演算法選擇的原始碼邏輯；通過 PyTorch DDP 示例體驗通訊計算重疊。
前沿趨勢：追蹤網內歸約（SHARP）、胖樹拓撲下的分層 All-Reduce 以及 OCP 開放互聯（UALink、CXL）的最新進展。

一句話總結

All-Reduce 是分散式訓練把多塊 GPU 的梯度“熔煉”成同一個更新訊號的無形骨架，它的效率直接決定大型模型能否從百卡平滑擴充套件到萬卡。

延伸閱讀與來源

Thakur R, Rabenseifner R, Gropp W. Optimization of collective communication operations in MPICH. International Journal of High Performance Computing Applications, 2005.
Sergeev A, Del Balso M. Horovod: fast and easy distributed deep learning in TensorFlow. arXiv:1802.05799, 2018.
NVIDIA Collective Communications Library (NCCL) 官方文件及原始碼，https://github.com/NVIDIA/nccl
Patarasuk P, Yuan X. Bandwidth optimal all-reduce algorithms for clusters of workstations. Journal of Parallel and Distributed Computing, 2009.
Graham R L et al. Scalable hierarchical aggregation protocol (SHArP): a hardware architecture for efficient data reduction. in Proc. of COM-HPC, 2016.
PyTorch Distributed 文件，https://pytorch.org/docs/stable/distributed.html

注：由於檢索受限，上述部分論文資訊基於通用學術認知回顧，如有版本或細節出入，請以原始發表文獻為準。

三步設好你的觀察臺

選 1-3 個想觀察的人或賽道

看一份樣張

設定一次異動告警

All-Reduce 全歸約通訊

All-Reduce 全歸約通訊

3 秒看懂

3 分鐘產業解釋

15 分鐘專家深入

技術原理

數學定義

實現核心：Ring All-Reduce

通訊量與延遲

關鍵引數（定性）

技術演進史

技術路線對比

上下游

關鍵指標

供需與市場資料

代表公司與資本對映

投資邏輯

常見誤讀糾偏

學習路徑

一句話總結

延伸閱讀與來源

All-Reduce 全歸約通訊

3 秒看懂

3 分鐘產業解釋

15 分鐘專家深入

技術原理

數學定義

實現核心：Ring All-Reduce

通訊量與延遲

關鍵引數（定性）

技術演進史

技術路線對比

上下游

關鍵指標

供需與市場資料

代表公司與資本對映

投資邏輯

常見誤讀糾偏

學習路徑

一句話總結

延伸閱讀與來源

相關推薦

同產業鏈 · 相關公司

相關概念