AllReduce

1 3 秒看懂

AllReduce 是分散式訓練中跨所有計算裝置（GPU/NPU/加速器）同步梯度或引數的核心通訊原語。它先在每張卡上完成區域性歸約（如求和、求最大值），隨後將全域性聚合結果廣播回所有參與程序，使每張卡最終拿到完全一致的聚合資料。沒有 AllReduce，大規模模型的資料並行、甚至部分張量並行的梯度同步就無從保證訓練一致性。

2 3 分鐘產業解釋

在深度學習分散式訓練中，每個 GPU 獨立計算自己的區域性梯度。模型引數更新前，必須把所有卡的梯度聚合成一個全域性梯度，再原樣同步給所有卡——這正是 AllReduce 完成的“歸約+廣播”語義。AllReduce 誕生於高效能運算（HPC）領域的 MPI（Message Passing Interface）通訊庫標準，已有數十年成熟應用。2017 年，百度將 HPC 中經典的 Ring AllReduce 演算法引入深度學習訓練，公開分享後引發範式轉變；此後 Uber 開源的 Horovod、NVIDIA 的 NCCL 庫迅速將其工程化，使 AllReduce 成為資料並行訓練的默認同步方案，徹底取代了早前提倡的引數伺服器（PS）模式。

產業最關心兩類具體實現：Ring‑AllReduce 與 Tree‑AllReduce。環結構把 GPU 排成環形鏈路，資料分塊沿環流水傳輸並累加，頻寬可接近物理上限，但通訊時延隨 GPU 數量呈線性增長，難以擴充套件到數百卡以上。樹形結構（尤其是雙二叉樹）利用分層歸約和廣播，時延僅呈對數增長，更適合千卡、萬卡級叢集。當前主流通訊庫（如 NCCL、Blink 等）往往根據節點內 NVLink／節點間 InfiniBand 等拓撲差異，自動混合使用 Ring 和 Tree，尋求時延與頻寬的最佳平衡。AllReduce 已不只是一個演算法單點，而是驅動大型模型訓練基礎設施——從網絡卡、交換器到通訊庫、訓練架構——整體同步效率的中樞環節。

3 技術原理

給定 N 個程序，每個程序 i 擁有資料塊 D_i，執行歸約操作 \oplus（通常為求和），AllReduce 結束時每個程序都持有完全相同的歸約結果 \bigoplus_{i=1}^{N} D_i。一次理想的 AllReduce 總通訊量可達 2(N-1)/N \cdot D 的下界（D 為單程序資料量），工程上幾乎所有最佳化都圍繞如何逼近這一理論極限展開。

典型工程實現拆解為兩個子階段：

• Reduce‑Scatter：各程序將本地資料均分為 N 塊，按塊與其他程序互動並歸約。執行完成後，每個程序恰好持有全域性歸約結果的 1/N 塊。
• AllGather：各程序將自身持有的 1/N 結果塊廣播給所有其他程序，最終每個程序重構出完整的全域性結果。

以最經典的 Ring‑AllReduce（4 GPU，梯度切分 4 塊）為例：

1. Scatter‑Reduce 階段（N‑1 步） 第 k 步，每個 GPU 將本地第 j 塊傳送給下一個鄰居，同時接收上一個鄰居發來的對應塊，並就地累加。迴圈 N‑1 步後，每個 GPU 持有一塊已經過全環歸約的完整塊（且僅有這一塊）。
2. AllGather 階段（N‑1 步） 每個 GPU 將自家已歸約塊沿環依次傳給下一鄰居，鄰居接收並原樣轉發（無累加）。N‑1 步後所有 GPU 收集齊全部 N 塊，得到完整全域性梯度。

Tree‑AllReduce 則利用樹形拓撲：在樹葉至根的方向逐級向上歸約，隨後從根向葉逐級廣播。雙二叉樹方案同時執行兩棵互不相交的二叉樹，進一步加倍注入頻寬，保持對數時延特性。

NCCL 等現代庫在此基礎之上引入拓撲感知最佳化：機內通過 NVLink/NVSwitch 執行高頻寬 Ring 或 Tree，跨機通過 InfiniBand/RoCE 採用層次化 Tree（如 CollNet）將不同層級演算法組合，使全域性通訊時間最優。MoE 架構中的 expert 間路由和梯度分發使用 All‑to‑All 集體通訊，語義為每個程序向所有其他程序傳送不同資料塊，與 AllReduce 的“全同結果”完全不同。

4 關鍵引數

影響 AllReduce 實際端到端效能的核心引數有：

• 啟動延遲（\alpha，單位：秒） 每次通訊操作的固定開銷，包括 kernel 啟動、協議握手、包排程等。資料量極小時，總時間由 \alpha 和通訊步數主導。

• 每位元組傳輸時間（\beta，單位：秒/位元組） \beta = 1 / text(有效頻寬)。由硬體鏈路速率、協議效率、記憶體複製等決定。大數據量下總時間由 \beta \cdot 資料量 主導。

• 單程序資料量 D（單位：位元組） 每張 GPU 需要參與同步的梯度或引數總位元組數。通常等於模型引數量 × 資料型別大小（如 FP16 為 2 位元組）。

• 程序數 N 參與 AllReduce 的 GPU 總數（或 rank 數）。N 直接影響通訊步數及兩階段的比例因子 (N-1)/N。

以 Ring‑AllReduce 為例，總時間近似為：

T_{text(ring)} \approx 2(N-1)\alpha + 2frac(N-1){N} D \beta

頻寬利用率接近 100%，且與 N 無關，但時延線性隨 N 上升。 Tree‑AllReduce（理想雙二叉樹）近似為：

T_{text(tree)} \approx 2\log_2 N \, \alpha + 2 D \beta

時延僅為對數增長，但傳統樹結構難以完全流水線化，實際頻寬利用率常低於 Ring（約 70%–90%，取決於實現）。混合方案則根據拓撲在 \alpha 項和 \beta 項之間折中。啟動延遲與頻寬的關係決定“轉折點”資料量：低於該量時延遲主導，Ring 因步數多可能反而慢於 Tree；高於該量時頻寬主導，演算法選擇主要看能否充分利用鏈路。

5 技術路線

技術路線	核心結構	時延複雜度	頻寬利用率	≥千卡擴充套件性	代表方案/庫
Ring‑AllReduce	一維環，資料分塊流水	O(N)	~100%（最優）	弱（時延線性攀升）	百度 2017 方案、早期 Horovod、NCCL Ring
Tree‑AllReduce	二叉樹/多叉樹分層歸約	O(\log N)	高（通常略低於Ring）	強（對數時延）	NCCL Tree、標準 MPI Tree
雙二叉樹	兩棵獨立二叉樹並行	O(\log N)	近雙倍注入，利用率高	極強	NCCL 高階 Tree（如 NCCL 2.12+）
混合 Ring+Tree	節點內 Ring、節點間 Tree	介於兩者之間	高（貼合物理拓撲）	極強	NCCL CollNet、Blink（arXiv:1910.04940）
稀疏 AllReduce	僅同步非零/重要梯度	與稀疏度有關	高壓縮比，節省量	強	微軟 Sparse AllReduce (arXiv:1312.3020)、Top‑k 梯度稀疏化
引數伺服器（對照）	中心化 Star 聚合	O(N)（單點瓶頸）	極低，server 頻寬為上限	極差	早期 TensorFlow PS、PyTorch 早期 RPC

Ring 和 Tree 並非互斥。NCCL 自 2.x 時代起逐步引入樹演算法，根據 GPU 間鏈路速率、NVSwitch 可用性、節點數量動態決策。Blink 論文 （2019）展示了通過執行時探測鏈路時延與頻寬，可在同一次 AllReduce 內混合環和樹，接近理論最優。稀疏 AllReduce 則利用深度學習梯度的冪律分佈特性，僅同步幅度最大的 k% 梯度，通訊量可壓縮 10~100 倍，但會引入精度損失，需要誤差補償（如 warm‑up 階段全量同步）。

6 上游

AllReduce 的上游主要由通訊庫、互聯硬體和加速器韌體構成。

通訊庫層

• NVIDIA NCCL：事實標準，針對 NVIDIA GPU 深度最佳化，支援 Ring、Tree、CollNet，與 NVLink/NVSwitch 緊耦合。
• Intel oneCCL：為 Intel GPU/加速器提供 AllReduce，適配 Intel 乙太網路和 Omni‑Path。
• AMD RCCL：基於 ROCm 的 NCCL 相容庫，用於 AMD Instinct GPU。
• Horovod (MPI/CCL 封裝)：早期普及者，現已由 LF AI 基金會託管，底層可呼叫 MPI、NCCL、Gloo 等。
• 架構原生通訊後端：如 PyTorch 的 torch.distributed，可結合 NCCL/Gloo/MPI；TensorFlow 的 tf.distribute 使用其自有實現。
• Gloo：Meta 開源的輕量級集體通訊庫，常用於 CPU 側的部分 AllReduce。

互聯硬體

• 機內互聯：NVIDIA NVLink（900 GB/s 雙向頻寬，H100）、NVSwitch（連線多 GPU 形成非阻塞交叉）、AMD Infinity Fabric、Intel Xe Link。
• 機間互聯：InfiniBand NDR/NDRInf（400/800 Gbps）、RoCE v2 乙太網路（200/400 Gbps）、高速銅纜/有源光纜（AOC）、交換器（NVIDIA Quantum、Spectrum‑X、Arista、Cisco 等）。
• 跨叢集互聯：長距光模組、波長分波多工裝置，用於連線不同資料中心的分片。

加速器韌體與協議 GPU‑Direct RDMA 允許網絡卡直接讀寫 GPU 視訊記憶體，繞過主機側記憶體複製，大幅降低 AllReduce 延遲。PCIe 拓撲與 NUMA 親和性配置也直接影響通訊路徑效率。這些上游元件的演進直接決定 AllReduce 的頻寬上限和延遲底數。

7 下游

下游需求方將 AllReduce 作為同步運算元嵌入分散式訓練和大型模型部署流程。

• 資料並行訓練：PyTorch DDP、TensorFlow MirroredStrategy 在每個 batch 後通過 AllReduce 同步梯度，是用量最廣的範式。
• 混合並行中的同步點：張量並行（如 Megatron‑LM）中，Transformer 層的列/行切分後需執行 AllReduce 或 ReduceScatter 通訊，通訊量通常比資料並行的梯度同步更為密集。流水線並行則較少依賴 AllReduce。
• 大規模引數同步：LLaMA、GPT、Claude 等大語言模型，以及 Stable Diffusion 等擴散模型，需在數千至數萬張 GPU 上保持權重和最佳化器狀態的強一致性，AllReduce 是核心工具。
• 聯邦學習：跨機構訓練中，各參與方本地訓練後通過中心引數伺服器或去中心化方式聚合並下發全域性模型，可視為 AllReduce 的一種擴充套件或近似應用。
• 模型評估與 checkpoint 儲存：部分場景在模型儲存/評估前需同步某些全域性統計量，也呼叫輕量 AllReduce。

8 受益公司

以下各類公司因 AllReduce 的大規模應用而直接或間接受益，但不構成任何投資建議。

• NVIDIA：通過 NCCL 通訊庫與 InfiniBand/乙太網路交換器（Quantum、Spectrum 系列）形成軟硬體閉環，AllReduce 效能成為其 GPU 訓練方案的核心溢價來源。Mellanox（現為 NVIDIA Networking）提供的智慧網絡卡和交換器直接承載 AllReduce 資料流。
• 百度：2017 年引領 Ring AllReduce 範式，並在飛槳（PaddlePaddle）平台上大規模應用，提升國產深度學習架構在分散式訓練領域的競爭力。
• Meta：作為 PyTorch 的維護者和萬卡級訓練叢集的運營者，深度定製 NCCL 並開源了多項通訊最佳化，間接提高自身 AI 基礎設施效率。
• AMD / Intel：圍繞 Instinct、Gaudi 等加速器建置 RCCL/oneCCL 生態，試圖複製 NCCL 的粘性，並從中獲得資料中心 CPU/GPU/FPGA 的協同部署機會。
• 網路裝置廠商（Arista、Cisco、華為、新華三等）：AI 後端網路對高頻寬、低延遲、無損傳輸的需求驅動高速交換器、光模組的銷售。
• 光模組和線纜供應商（中際旭創、Coherent、光迅等）：AllReduce 驅動 InfiniBand 和 800G 光模組的用量增長。
• 雲端運算廠商（AWS、微軟 Azure、Google Cloud、阿里雲端、字節跳動等）：內部 AI 訓練平台大量使用 AllReduce，其自研通訊庫（如微軟 MSCCL）和網路架構的最佳化可提升訓練資源利用率、降低成本。

9 市場規模

AllReduce 本身為軟體演算法，不獨立形成可交易市場，但其價值隱含在 AI 訓練叢集的網路裝置和通訊庫相關支出中。

• NVIDIA 網路營收：NVIDIA 2024 財年（截至 2024 年 1 月 28 日）網路業務（包括 InfiniBand 和高速乙太網路）營收為 82.6 億美元，年增率增長 208%（資料來源：NVIDIA FY2024 10‑K）。該營收主要來自 ConnectX 網絡卡、BlueField DPU、Quantum InfiniBand 交換器等，直接服務於 AllReduce 通訊。
• AI 後端網路市場：市場研究機構 Dell’Oro Group 預計，2023 年全球 AI 後端網路支出約 30 億美元，到 2027 年將超過 100 億美元（來源：Dell’Oro Group, “AI Networks for AI Workloads,” 2024）。其中 InfiniBand 佔主導，但乙太網路 RoCE 份額快速提升。
• 高速光模組：LightCounting 報告指出，用於 AI 叢集的 400G 和 800G 光模組市場 2024 年規模約 40 億美元，2025 年有望超過 70 億美元（來源：LightCounting, “High‑Speed Optics for AI Clusters,” 2024 年 4 月）。
• 通訊庫及架構附加值：各大雲端服務商和 AI 實驗室每年投入數億至數十億美元用於內部訓練基礎設施的通訊最佳化，這部分支出未形成獨立產品市場，但反映 AllReduce 效率提升的經濟價值。

以上資料均來自公開財務檔案和行業研究報告，具體年份和口徑已在括號內標註。第三方市場預測可能後續調整，實際數值以各機構最新發布為準。

10 玩家對比

通訊庫/方案	主要維護方	支援的互聯技術	演算法支援	效能特徵	生態與限制
NCCL	NVIDIA	NVLink, NVSwitch, InfiniBand, RoCE	Ring, Tree, CollNet, 自定義組合	當前綜合性能最佳，與硬體緊耦合，低延遲高頻寬	僅限 NVIDIA GPU；閉源，需與 CUDA 驅動匹配
RCCL	AMD	AMD Infinity Fabric, PCIe, 乙太網路	Ring, 早期 Tree 支援	持續追趕中，部分操作接近 NCCL 效能	僅限 AMD GPU；生態成熟度低於 NCCL
oneCCL	Intel	Intel Xe Link, 乙太網路, Omni‑Path	Ring, Recursive Halving/Doubling	針對 Intel 加速器最佳化，高效利用 Intel 網路	繫結 Intel GPU/加速器；跨平台受限
Horovod	LF AI 基金會（原 Uber）	MPI/NCCL/Gloo 後端	通過後端繼承	部署簡便，生態友好；效能取決於所掛載後端	已進入維護模式，創新貢獻減緩；大規模叢集調優需深厚知識
Gloo	Meta	乙太網路, InfiniBand（有限）, 本地 IPC	Ring, 多樹	輕量級，跨平台；CPU 側效能較好	GPU 效能遠不如 NCCL；適合小規模或 CPU 通訊
MSCCL	微軟	InfiniBand, 乙太網路	自定義排程，支援在網計算	針對 Azure 叢集最佳化，嘗試利用交換器聚合	公有雲端定製，外部公開資料較少
PyTorch Distributed	Meta / 社群	通過 NCCL/Gloo/MPI 後端	取決於後端	當使用 NCCL 後端時為 de facto API	本身不實現演算法，依賴底層庫
MPI 實現（Open MPI, MPICH）	開源社群	任意網路	全部經典集體操作演算法	通用性強，適配所有 HPC 場景	DL 專用最佳化不足，延遲通常高於 NCCL

從實際部署看，NVIDIA NCCL 在 GPU 叢集中佔據絕對主導，但 AMD、Intel 正通過開源和合作縮小差距；通用 MPI 仍在小規模 CPU 訓練和學術研究中活躍。使用者選擇的核心考量並非 AllReduce 演算法本身，而是與訓練晶片、網路硬體的整合深度。

11 風險

• 硬體鎖定與生態封閉：NCCL 與 NVIDIA GPU、NVLink 深度繫結，若下一代加速器非 NVIDIA 方案，現有 AllReduce 最佳化需大量移植工作。異構叢集跨平台 AllReduce 效能損失可能達 30%–60%。
• InfiniBand 依賴與供應鏈：當前最優 AllReduce 效能高度依賴 NVIDIA 提供的 InfiniBand 交換器，其核心晶片供應集中，若出現產能、地緣政治或出口管制等事件，可能導致網路硬體成本飆升或交付延遲。
• 通訊與計算重疊不足：隨著模型增大，單次 AllReduce 資料量急劇攀升，若架構無法將通訊完全隱藏在計算之後（如反向傳播階段），Wall‑clock 時間將顯著增加，直接降低 GPU 利用率。
• 小資料量場景被 Tree 反超的部署風險：某些模型劃分或小 batch 規模時，梯度張量極小，Ring 的高步數反而增加延遲。運維團隊若未針對實際張量大小微調 NCCL 演算法選擇，可能得到次優效能。
• 新興通訊模式的替代：MoE（Mixture of Experts）架構依賴 All‑to‑All，而非 AllReduce；未來混合專家模型比例上升可能減少對 AllReduce 的絕對需求。此外，在網計算（In‑Network Computing）和交換器端歸約可能將部分 AllReduce 工作解除安裝到網路裝置，改變通訊庫的競爭格局。
• 能效與運營壓力：萬卡叢集 AllReduce 的瞬時功耗和多跳傳輸帶來的散熱壓力不容忽視，可能推高資料中心運營成本，並面臨 ESG 相關限制。

12 誤讀糾偏

• “AllReduce 就是資料並行的全部。” AllReduce 確實是資料並行梯度同步的基石，但現代大型模型混合並行中，張量並行內部也大量呼叫 AllReduce/ReduceScatter，且其通訊量往往比梯度同步更為密集。不能將 AllReduce 的使用場景窄化為僅資料並行。

• “Ring‑AllReduce 在任何規模下都是最好的。” 百度 2017 年公開 Ring 方案後，部分文章將其渲染為終極方案。實際上 Ring 時延隨 GPU 數線性增長，在超過 200~300 卡後時延開銷可能顯著阻塞計算；千卡、萬卡叢集中 Tree 或混合方案才是主流。NCCL 自 2.x 起已預設動態選擇，並非固定 Ring。

• “MoE 模型訓練裡的通訊就是 AllReduce。” 這是常見混淆。MoE 中 expert 間的令牌路由和梯度分發使用 All‑to‑All 集體通訊，語義為每個程序向所有其他程序傳送不同資料，與 AllReduce 的全同結果語義完全不同，兩者通訊模式和網路負載模型有本質差異。

• “AllReduce 只由 GPU 做就夠了。” 實際中，很多最佳化利用 CPU 或智慧網絡卡完成部分歸約工作。Gloo 支援 CPU 側聚合，DPU/BlueField 可協助資料搬移，未來交換器內歸約將部分工作從 GPU 移出。

• “只要頻寬足夠大，AllReduce 一定快。” 時延對效能的影響在大規模訓練中同樣關鍵。高頻寬、高延遲網路（如某些長距光互聯）可能導致 AllReduce 總時間遠高於低延遲中頻寬鏈路。引數 \alpha 與 \beta 的平衡決定最終效率。

13 最新事件

• NVIDIA NCCL 2.20 釋出（2024 年 3 月，來源：NVIDIA Developer Blog）：引入對 FP8 資料型別的原生聚合支援，允許在低精度訓練中保持全精度歸約，減小通訊量；進一步最佳化 NVSwitch 樹演算法，將 AllReduce 延遲再降低 10%–15%。
• Ultra Ethernet Consortium 釋出 1.0 規範（2024 年 5 月，來源：Ultra Ethernet Consortium 新聞稿）：聯合 AMD、Intel、Meta、Microsoft 等廠商，定義針對 AI/HPC 的開放乙太網路協議，內建硬體加速的 AllReduce 和擁塞控制，意圖打破 InfiniBand 的壟斷。
• NVIDIA Spectrum‑X 乙太網路平台正式商用（2024 年 Q1，來源：NVIDIA 財報會議）：針對乙太網路環境最佳化 NCCL 效能，通過自適應路由和擁塞控制，將 RoCE 上的 AllReduce 尾部延遲降低 30% 以上，拓展了 AllReduce 在非 InfiniBand 網路中的適用面。
• Meta 釋出論文“TeraScale AllReduce”（2024 年 7 月，arXiv 預印本，來源：arXiv:2407.xxx，具體編號公開資料未見，須查證）：提出一種結合環形和層次樹的混合演算法，針對 24k GPU 叢集將 AllReduce 頻寬利用率提升至 97%，並公開部分實現程式碼。
• 微軟釋出 Azure 自定義交換器聚合原型（2024 年 4 月，來源：Microsoft Research Blog）：探索在網路交換器內直接完成梯度求和，可將 AllReduce 的通訊量和延遲大幅降低，初步測試顯示加速比可達 1.8×。
• AMD RCCL 增加對雙二叉樹支援（2024 年 6 月，來源：AMD ROCm 文件更新）：為 Instinct MI300 系列引入雙二叉樹演算法，節點間通訊效率提升約 25%。
• 百度飛槳宣佈全自動 AllReduce 策略推薦（2024 年 8 月，來源：百度飛槳開發者大會）：通過叢集拓撲探測和通訊量建模，自動選擇最優 AllReduce 實現，減少使用者調優成本。

以上事件時間、內容均基於公開資訊整理，部分細節可能存在版本迭代，確切資料以官方最新公告為準。

14 追蹤指標

持續觀測 AllReduce 技術進展和產業影響的指標包括：

• NCCL 效能基準：關注 NVIDIA 官方釋出的 nccl-tests 報告，檢視不同 GPU、不同節點規模、不同資料大小的演算法頻寬和延遲變化。
• InfiniBand 交換器和網絡卡出貨量：追蹤 NVIDIA 財報中網路營收增速、各季度 Quantum 和 ConnectX 產品出貨，以及 200/400/800 Gbps 埠滲透率。
• MLPerf Training 通訊時間佔比：在 MLPerf 訓練基準的封閉賽道中，分析各平台 AllReduce 及相關通訊所佔總訓練時間的比例，可側面評估通訊棧水平。
• 高速光模組和 AOC 出貨資料：LightCounting、Omdia 等機構釋出的 400G/800G 光模組出貨量和預測，反映 AI 叢集互聯投入強度。
• AI 叢集規模演進：追蹤 OpenAI、Meta、Google、字節跳動等公佈的訓練叢集 GPU 數量（如 Meta 的 24k H100 叢集），與同步演算法擴充套件性對應。
• 開源通訊庫版本與特性：NCCL、RCCL、oneCCL、PyTorch Distributed 的釋出說明，重點關注新演算法支援、拓撲感知改進、低精度歸約等。
• 學術論文中的 AllReduce 創新：在 arXiv 上關注 cs.DC、cs.LG 子領域，關鍵詞 “AllReduce”、“gradient compression”、“in‑network aggregation”，把握稀疏化、壓縮、在網計算等前沿動向。
• 行業標準進展：Ultra Ethernet Consortium 規範更新、開放網路聯盟對 AllReduce 硬體加速的設計，會重塑未來幾年底層互聯格局。

15 信源

以下為整理本文時引用的公開資料與擴充套件閱讀來源，供查證和深入學習。

• Baidu Research. “Bringing HPC Techniques to Deep Learning.” 2017. (百度研究部落格)
• NVIDIA NCCL Documentation: https://developer.nvidia.com/nccl
• NVIDIA. “NCCL: Accelerated Multi‑Node Collective Communications.” Developer Blog, 2023–2024.
• NVIDIA Corporation. “Form 10‑K for the Fiscal Year Ended January 28, 2024.” Available at: investor.nvidia.com.
• Horovod Documentation: https://github.com/horovod/horovod
• Wang, Shibo, et al. “Blink: Fast and Generic Collectives for Distributed ML.” arXiv:1910.04940, 2019.
• Agarwal, et al. “Sparse Allreduce: Efficient Scalable Communication for Power‑Law Data.” arXiv:1312.3020, 2013.
• 知乎專欄. “GPU分散式訓練：NCCL效能解析(二)多機通訊——Ring, Tree, CollNet.” zhuanlan.zhihu.com/p/597081795.
• Dell’Oro Group. “AI Networks for AI Workloads: Market Outlook.” 2024.
• LightCounting. “High‑Speed Optics for AI Clusters.” April 2024.
• Ultra Ethernet Consortium. “Ultra Ethernet Specification 1.0 Press Release.” May 2024.
• Microsoft Research Blog. “In‑Network Aggregation for Deep Learning.” April 2024.
• Meta AI. “TeraScale AllReduce: Hybrid Ring‑Tree for 24k GPUs.” arXiv preprint, July 2024 (核實具體編號).
• AMD ROCm Documentation. “RCCL 2.16 Release Notes.” June 2024.
• 百度飛槳開發者大會，2024 年 8 月公開演講及新聞稿。

（本文部分市場預測依賴第三方機構，其口徑和基期可能隨報告版本調整，實際資料以各機構最新發布為準。公司財務資料均取自監管揭露檔案，僅作客觀引用，不代表任何估值建議。）