SHARP
3 秒看懂
一句話： SHARP 讓交換器在資料”飛過”的過程中直接做歸約計算（如梯度求和），大幅降低了傳統樹狀 AllReduce 的上層鏈路頻寬壓力——是 NVIDIA InfiniBand 叢集在萬卡規模下壓低通訊牆的核心網路內計算技術。
3 分鐘產業解釋
為什麼需要 SHARP？
大型模型分散式訓練的”最後一公里”瓶頸往往不是算力，而是通訊。當數千張 GPU 同步梯度（AllReduce），每個節點既要傳送也要接收，網路頻寬很快被集體通訊操作（collective operations）吃滿。
傳統路徑：梯度資料從每張 GPU → NIC → 交換器 → 交換器 → … → 目標 NIC → 目標 GPU，交換器只做轉發（cut-through），不參與任何計算。這意味著 N 張卡做 AllReduce，網路中實際傳輸的資料量與 N 成正比，且每一跳都只是”搬運工”。
SHARP 的核心思想： 讓 InfiniBand 交換器的 ASIC 在轉發的同時執行歸約運算（reduction：sum、max、min、band OR 等）。資料經過樹狀拓撲中的每一層交換器時，先被部分聚合，再往上層傳遞——越往上，流量越少。最終到達根節點時，歸約結果已近完成，再廣播回來即可。
效果： 降低 AllReduce 的有效網路流量、降低延遲、釋放端點 CPU/NIC 的參與負擔。
產業地位
SHARP 是 NVIDIA 網路平台（ConnectX NIC + Quantum 系列 InfiniBand 交換器 + SHARP 協議）的差異化護城河之一。在 TOP500 超算和萬卡級 AI 叢集中，SHARP 是 InfiniBand 方案相對乙太網路方案的關鍵競爭要素。它是 NVIDIA “networking as a differentiator”戰略的技術錨點。
15 分鐘專家深入
1. In-Network Computing 範式
SHARP 屬於更廣泛的 In-Network Computing（網路內計算） 範式。該範式的基本命題是：
交換器/路由器不再只是轉發裝置，而是在資料平面（data plane）直接對有效載荷執行計算操作，從而減少總通訊輪次和資料量。
SHARP 是該範式中最成熟、部署最廣的生產級實現之一（另一代表是 HPE/Cray Slingshot 網路中的部分能力）。
2. SHARP 在 AllReduce 中的價值量化
以一個簡化的二叉樹拓撲為例，假設有 N=1024 張 GPU，每張產出 G GB 梯度：
| 指標 | 傳統 Tree AllReduce（軟體實現） | SHARP 加速的 Tree AllReduce |
|---|---|---|
| 每層歸約前資料量 | 全量 | 逐層遞減（子樹內先聚合） |
| 理論跨層頻寬消耗 | 每鏈路傳輸資料量為 G，總傳輸量約 2(N-1)G | 與傳統 Tree AllReduce 相同（每鏈路 G），收益在於延遲降低和端點解除安裝 |
| 端點參與程度 | NIC/CPU 全程參與 | 僅需發起和接收，中間歸約解除安裝到交換器 |
| 擴充套件性瓶頸 | 萬卡規模頻寬牆 | 瓶頸後移（但受限於交換器歸約引擎能力） |
注意： 實際加速比取決於拓撲深度、歸約粒度、SHARP 引擎的並行處理能力，以及資料是否可被有效分片。[NVIDIA/Mellanox 公開白皮書] 中提到在特定基準下可觀測到顯著的延遲降低，但具體倍數因場景而異，不做通用數值斷言。
3. SHARP 與 NCCL 的協同
NVIDIA 的集合通訊庫 NCCL（NVIDIA Collective Communications Library）是 SHARP 的上層消費者之一。當 NCCL 檢測到底層網路支援 SHARP 時，可將部分集合操作解除安裝（offload）到網路中的 SHARP 引擎。這並非完全替代 NCCL 的 AllReduce，而是一種分層協同：
- NCCL 負責 GPU↔NIC 的通訊排程和拓撲感知
- SHARP 負責交換器層面的歸約加速
- 管理層面通過 Sharp Daemon 協調 SHARP 資源分配
技術原理（深入機制）
核心架構
┌─────────────────────────────────────────────────────┐
│ SHARP 協議棧與執行模型 │
│ │
│ ┌─────────┐ ┌─────────────────────────────┐ │
│ │ NCCL / │───▶│ SHARP Manager (管理節點) │ │
│ │ MPI Lib │ │ - Job/Communicator 管理 │ │
│ └────┬─────┘ │ - SHARP 資源分配 │ │
│ │ └──────────┬──────────────────┘ │
│ ▼ ▼ │
│ ┌─────────┐ ┌─────────────────────────────┐ │
│ │ConnectX │ │ InfiniBand Switch (Quantum) │ │
│ │ NIC │ │ ┌─────────────────────────┐ │ │
│ │ │ │ │ SHARP Reduction Engine │ │ │
│ │ SHARP │◄──▶│ │ - 硬體歸約單元 │ │ │
│ │ Agent │ │ │ - 支援的操作: │ │ │
│ │ │ │ │ SUM / MAX / MIN / BOR │ │ │
│ └─────────┘ │ │ - 原地(in-place)歸約 │ │ │
│ │ └─────────────────────────┘ │ │
│ [GPU 0..N] └─────────────────────────────┘ │
└─────────────────────────────────────────────────────┘執行流程（以 AllReduce 為例）
傳統 AllReduce (Ring) SHARP Tree AllReduce
Step 1: GPU0→GPU1→GPU2→...→GPUn Step 1: GPU0,1 → L1-SW-A (partial sum A)
Step 2: GPU1→GPU2→...→GPUn→GPU0 GPU2,3 → L1-SW-B (partial sum B)
... ...
(2*(N-1) 步) Step 2: L1-SW-A + L1-SW-B → L2-SW (further aggregate)
...
總傳輸量 ~ 2*(N-1)*G Step K: Root-SW holds full reduction result
Step K+1: Result broadcast back to all GPUs
總傳輸量 ≈ 2*G*(N-1) (每條鏈路僅傳一次上行和一次下行)
但受制於交換器歸約引擎吞吐關鍵技術引數（定性，因搜尋未能獲取精確規格）
| 引數 | 說明 | 置信度 |
|---|---|---|
| 支援的歸約資料型別 | 通常支援常見的數值型別（float16/32、int 等） | 定性確認 |
| 每埠歸約引擎數 | 與交換器 ASIC 設計相關，具體數量級未充分揭露 | 未充分揭露 |
| 延遲開銷 | 在交換器轉發延遲基礎上增加歸約處理延遲，量級為百納秒至微秒級 | [行業估算] |
| SHARP v1 → v2 的能力擴充套件 | v2 擴充套件了可支援的資料型別和操作種類，增加了對更復雜 collective 的支援 | 定性確認 |
通訊原語：SHARP 與標準 MPI Collectives 的對應
SHARP 主要支援的是歸約類（reduction）操作，包括但不限於：
- AllReduce（最核心場景）
- Reduce
- Barrier（同步點解除安裝）
- Broadcast（結合歸約結果的廣播）
- 部分支援 Reduce-Scatter 等
⚠️ 關鍵區分： SHARP 處理的是 AllReduce/Reduce 等歸約通訊，不是 All-to-All。All-to-All 是 MoE（Mixture-of-Experts）場景中 dispatch/combine 的核心通訊模式，通常由 NCCL 或專用方案處理，與 SHARP 的歸約解除安裝屬於不同維度。
技術演進史
時間線（年份為近似）
2015-2016 Mellanox 提出 In-Network Computing 概念，SHARP v1 開始研發
│ 背景：HPC 社群對集合通訊效率的長期不滿
▼
2017-2018 SHARP v1 隨 Mellanox Quantum (HDR 200G) 交換器釋出
│ 首次在 InfiniBand 交換器 ASIC 中整合硬體歸約引擎
│ 主要面向 HPC 超算（如美國 Summit/Sierra 等 ORNL 系統的通訊棧）
▼
2019 NVIDIA 以 69 億美元收購 Mellanox，SHARP 納入 NVIDIA 網路版圖
│
▼
2021-2022 SHARP v2 隨 Quantum-2 (NDR 400G) 交換器釋出
│ 增強了歸約能力，適配更大規模 AI 訓練叢集
│ 與 NCCL 的協同深度最佳化
▼
2023-2024 SHARP 隨 Quantum-X800 (XDR 級別) 進入下一代
│ 面向萬卡級 GPU 叢集（如 xAI Colossus 等）
│ SHARP 成為 NVIDIA AI 網路棧"端到端最佳化"敘事的核心元件
▼
未來 Ultra Ethernet Consortium (UEC) 推動乙太網路實現類似能力
SHARP 可能擴充套件到更多操作型別和更大歸約粒度技術路線對比
SHARP vs 端側軟體 AllReduce vs 競品方案
| 維度 | 傳統軟體 AllReduce (NCCL Ring/Tree) | SHARP (InfiniBand In-Network) | Ultra Ethernet (UEC 目標) | Cray/Slingshot 網路能力 |
|---|---|---|---|---|
| 歸約位置 | 端點 NIC/GPU | 交換器 ASIC 內 | 乙太網路交換器（規劃中） | Slingshot 交換器（部分能力） |
| 網路型別 | 通用 | InfiniBand 專用 | 乙太網路 | Slingshot 專用 |
| 流量最佳化 | 取決於演算法 | 理論上樹狀逐層縮減 | 目標類似 | 有類似思路 |
| 成熟度 | 極成熟 | 生產級，大規模部署 | 標準制定中（截至2024） | 已部署（HPC 場景） |
| 生態鎖定 | 低（通用） | 中高（需 InfiniBand 全棧） | 低（乙太網路通用） | 高（需 Slingsht 全棧） |
| GPU 供應商相容 | 通用 | 主要最佳化 NVIDIA | 多供應商 | 多供應商 |
| 適用規模 | 中大規模有效 | 萬卡級優勢明顯 | 目標萬卡級 | 萬卡級 HPC |
投資含義： SHARP 是 NVIDIA InfiniBand 對乙太網路的結構性差異化點。UEC 若成功標準化類似能力，將削弱此優勢。
上下游
上游
| 環節 | 要素 | 代表 |
|---|---|---|
| 交換器 ASIC 設計 | 歸約引擎的電晶體資源、製程 | NVIDIA Mellanox（自研 ASIC，具體制程未充分揭露） |
| SerDes / PHY | 高速序列收發器（每埠 400G+） | Broadcom、Marvell、NVIDIA 自研 |
| 交換晶片製造 | 晶圓代工 | 台積電（高機率，NVIDIA 為主要客戶） |
| 光模組 / 銅纜 | InfiniBand 鏈路層物理連線 | 中際旭創、Coherent 等 |
下游
| 環節 | 要素 | 代表 |
|---|---|---|
| AI 訓練叢集 | 萬卡 GPU 叢集的通訊層 | xAI、Meta、字節跳動等 |
| HPC 超算 | 傳統 HPC MPI 工作負載 | ORNL、LLNL 等國家實驗室 |
| 集合通訊庫 | NCCL、OpenMPI（SHARP-aware） | NVIDIA、開源社群 |
| 叢集管理軟體 | Sharp Daemon、UFM（Unified Fabric Manager） | NVIDIA |
產業鏈價值分配（定性）
SHARP 的"附加價值"主要體現在：
- 提升 InfiniBand 交換器的 ASP（交換器不只是轉發裝置）
- 增強 NVIDIA 網路 vs 乙太網路方案的 TCO 優勢敘事
- 加深客戶對 NVIDIA 全棧（GPU + NIC + Switch + Software）的鎖定
整個價值量相對 GPU 本身較小，但戰略槓桿效應大。關鍵指標
| 指標 | 說明 | 評估 |
|---|---|---|
| AllReduce 延遲降低 | SHARP vs 純軟體方案的端到端 AllReduce 延遲差 | NVIDIA 宣稱顯著降低，具體數字因叢集規模/拓撲/資料量差異大，不做通用斷言 |
| 網路流量縮減率 | 歸約操作中實際減少的跨鏈路資料量比例（注：傳統 Tree AllReduce 每鏈路資料量已為 G，SHARP 未額外減少鏈路頻寬消耗） | SHARP 主要收益在延遲和端點解除安裝，而非流量縮減；理論上鍊路資料量無縮減 |
| 交換器功耗開銷 | 歸約引擎增加的額外功耗 | 未充分揭露，定性為”小幅增加” |
| 支援的最大叢集規模 | SHARP Manager 可管理的節點/端點數 | 隨 Quantum-2/Quantum-X800 持續擴充套件，具體上限未充分揭露 |
| 與 NCCL 整合深度 | NCCL 對 SHARP offload 的支援程度 | 隨 NCCL 版本持續最佳化，2024 年已是預設啟用（在 InfiniBand 環境下） |
供需與市場資料
直接市場：InfiniBand 交換器
| 維度 | 資料 | 來源 |
|---|---|---|
| InfiniBand 交換器市場（2023） | NVIDIA 佔據 InfiniBand 交換器絕大部分份額 | [行業報告估算] |
| SHARP 作為交換器功能 | 隨 Quantum 系列交換器出貨即包含，不單獨定價 | [廠商公開資訊] |
| AI 用網路裝置市場增速 | 2023-2025 年 CAGR 預計 > 50% | [行業報告估算] |
間接影響：對 NVIDIA 網路營收的支撐
- NVIDIA 網路業務（含 InfiniBand + Spectrum 乙太網路）在資料中心營收中佔比持續提升
- SHARP 作為 InfiniBand 的”賣點功能”，間接支撐了交換器和整網方案的溢價能力
- 在萬卡叢集專案中，網路方案選擇（IB vs 乙太網路）直接影響數十億美元級訂單
⚠️ SHARP 不是一個獨立的可售產品，而是嵌入 InfiniBand 交換器的功能模組，不存在單獨的 SHARP 市場規模資料。
代表公司與資本對映
直接相關
| 公司 | 關聯 | 上市程式碼 |
|---|---|---|
| NVIDIA | SHARP 開發方（通過收購 Mellanox），InfiniBand 全棧提供者 | NVDA |
| Intel | 間接競爭（通過 HPC Slingshot 方案及未來 UEC 標準化） | INTC |
間接受益 / 關聯
| 公司 | 關聯 | 上市程式碼 |
|---|---|---|
| 中際旭創 | InfiniBand 光模組供應（800G 光模組） | 300308.SZ |
| Coherent | 高速光模組（InfiniBand 生態供應商） | COHR |
| Arista Networks | 乙太網路競爭方案（UEC 成員），UEC 若成功可削弱 SHARP 護城河 | ANET |
| Broadcom | 交換晶片競爭（乙太網路側），Tomahawk/Jericho 系列 | AVGO |
投資對映邏輯
SHARP 本身不可直接投資，但其影響路徑：
1. 最直接：NVIDIA 網路業務營收和 ASP 提升
2. 間接受益：InfiniBand 生態供應商（光模組、聯結器）
3. 競爭觀察：UEC 進展對 SHARP 護城河的潛在削弱投資邏輯
看多邏輯
- AI 訓練叢集規模持續膨脹 → 通訊瓶頸加劇 → In-Network Computing 需求剛性上升
- NVIDIA 全棧鎖定效應 — SHARP 是”GPU + NIC + Switch + NCCL + SHARP”五層協同中的關鍵一環，競爭對手需要同時複製五層才能匹敵
- 護城河持續加寬 — SHARP v2 已經是第二代，硬體歸約引擎的 ASIC 設計經驗壁壘高
- HPC + AI 雙輪驅動 — 兩個萬億級算力市場都對高效集合通訊有剛需
看空 / 風險因素
- Ultra Ethernet Consortium (UEC) — 若乙太網路生態成功標準化類似 SHARP 的 In-Network Computing 能力（RDMA + 可程式設計交換晶片），InfiniBand 的差異化將被稀釋
- Google TPU 互聯架構 — 自研 ICI (Inter-Chip Interconnect) 不依賴 SHARP/InfiniBand，大客戶可能自建通訊棧
- AMD + Broadcom + UEC 聯盟 — 乙太網路 + RoCE + UEC 的組合可能在 TCO 上挑戰 IB 全棧
- 監管風險 — NVIDIA 網路+計算的垂直整合可能面臨反壟斷審查
關鍵驗證訊號
- NVIDIA 財報中網路業務營收增速是否持續高於 GPU 業務
- UEC 1.0 標準釋出時間及首批產品的 In-Network Computing 實測效能
- xAI、Meta 等超大叢集客戶最終選擇 IB vs 乙太網路的決策趨勢
- 800G 及以上 InfiniBand 交換器中 SHARP 能力的具體升級點
常見誤讀糾偏
誤讀 1：“SHARP 可以完全替代 NCCL 的 AllReduce”
糾偏： SHARP 不是 NCCL 的替代品，而是協同加速層。NCCL 負責 GPU 到 NIC 的通訊排程、拓撲感知、分塊策略等，SHARP 負責交換器層面的歸約解除安裝。兩者是分層互補關係，不是替代關係。SHARP 只能在 InfiniBand 交換器覆蓋的網路段內工作，端點側仍需 NCCL（或其他通訊庫）配合。
誤讀 2：“SHARP 對所有通訊操作都有加速效果”
糾偏： SHARP 的核心能力是歸約操作（reduction：sum、max、min 等）。它對 AllReduce、Reduce 有直接加速。但對於 All-to-All（MoE 的 dispatch/combine 模式）、點對點 Send/Recv 等操作，SHARP 不適用。MoE 模型訓練中 All-to-All 的通訊瓶頸，需要其他方案（如 NCCL 最佳化、拓撲感知排程）來解決，不能指望 SHARP。
誤讀 3：“SHARP 的加速效果可以線性量化為 X 倍”
糾偏： SHARP 的實際收益高度依賴於：① 叢集拓撲深度（樹越深，中間歸約的收益越大）；② 資料塊大小；③ 併發歸約流數量；④ 交換器歸約引擎的處理能力。不存在一個通用的”SHARP 加速 X 倍”數字。 NVIDIA 在特定基準測試中公佈的結果不一定代表實際工作負載。任何看到”SHARP 加速 2x/5x”之類的斷言，需追問其測試條件。
誤讀 4：“乙太網路方案完全無法實現類似 SHARP 的能力”
糾偏： 技術上，可程式設計乙太網路交換晶片（如 Barefoot Tofino / Intel）具備資料面程式設計能力，理論上可以實現歸約解除安裝。UEC 標準化組織正在推動乙太網路側的 In-Network Computing 標準化。當前差距主要在於：① InfiniBand 交換器有專用硬體歸約引擎（效能更高），乙太網路方案多依賴可程式設計流水線（靈活性高但專用效能可能不及）；② 生態成熟度（SHARP 已經是第二代且大規模部署）。但這個差距正在縮小，不是技術不可行。
學習路徑
入門（30 分鐘）
- 閱讀 NVIDIA Mellanox 關於 SHARP 的官方概述頁面（搜尋 “NVIDIA SHARP In-Network Computing”）
- 理解 AllReduce 的基本原理（推薦：Liam Li et al., “Communication Optimizing AllReduce”）
進階（2-3 小時）
- 閱讀 NVIDIA SHARP 技術白皮書（官方 PDF，注意版本，搜尋 “SHARP v2 whitepaper”）
- 瞭解 InfiniBand 拓撲（Fat-Tree / Dragonfly）與 SHARP 的樹狀歸約對映關係
- 對比閱讀：Ultra Ethernet Consortium 的願景文件，理解競爭格局
專家級（持續追蹤）
- 關注 SC（Supercomputing）和 ISC HPC 會議中關於 In-Network Computing 的論文和 BoF
- 閱讀 NCCL 的 GitHub 倉庫中關於 SHARP offload 的程式碼路徑和 issue 討論
- 追蹤 NVIDIA GTC 網路專場演講，獲取最新 SHARP 能力更新
- 關注 UEC 標準進展（ultraethernet.org），評估乙太網路側競爭能力成熟時間線
一句話總結
SHARP 是 NVIDIA InfiniBand 網路的”隱性加速器”——它把交換器從被動的搬運工變成主動的計算節點，在梯度同步的資料路徑上就地完成歸約，是萬卡級 AI 訓練叢集通訊效率的關鍵差異化技術，也是 NVIDIA 全棧鎖定策略中網路層的核心錨點。
延伸閱讀與來源
| 來源 | 說明 | 型別 |
|---|---|---|
| NVIDIA/Mellanox “SHARP In-Network Computing” 官方技術頁面 | 協議概述和版本說明 | 廠商白皮書 |
| ”In-Network Computing: Trends and Applications”（多篇 SC/ISC 論文） | 學術視角的 In-Network Computing 綜述 | 學術論文 |
| NVIDIA GTC 演講 “Accelerating AI with In-Network Computing” | 產品路線圖和效能資料 | 廠商演講 |
| Ultra Ethernet Consortium (ultraethernet.org) | 競爭標準追蹤 | 行業聯盟 |
| NCCL GitHub 倉庫（github.com/NVIDIA/nccl） | SHARP offload 程式碼路徑 | 開原始碼 |
| TOP500 Supercomputer Sites 使用 InfiniBand + SHARP 的列表 | 部署例項驗證 | 行業資料庫 |
| SemiAnalysis / The Next Platform 相關分析文章 | 第三方技術分析 | 行業分析 |
免責宣告： 本文中未能通過本次檢索獲得精確規格引數的部分，已標註為 [未充分揭露] 或 [行業估算]，具體數字請以 NVIDIA 官方最新文件為準。本文不構成投資建議。