SHARP
交换机内规约如何把 AllReduce 卸载到 IB / Ethernet 网络并减少主机通信量
核心要点：
- SHARP 把 reduction 从主机软件下沉到交换机 ASIC，端节点仅 1 发 + 1 收
- 两种聚合树：LLT （小消息整树 SRAM 常驻） 与 SAT （大消息流水分段）
- 与 NVLS 共享设计哲学 （交换机内规约），但作用域不同 （跨节点 IB / Ethernet vs 节点内 NVLink）
- 三代演进 v1 → v4, Quantum-X800 v4 14.4 TFLOPS / 交换机，v3 的 9×
- 仅卸载 AllReduce / Reduce / Broadcast / Barrier，不支持 AllToAll / AllGather / ReduceScatter
- 单交换机仅一棵活跃 SAT，多任务并发需配额管理
本文聚焦 IB / Spectrum-X （Quantum 系列） 上的 SHARP；节点内 NVLink-SHARP 详见 4.10 NVLS。SHARP 与 NVLS 共享"交换机内置 reduction engine"哲学，但介质 (IB / Ethernet vs NVLink)、作用域 （跨节点 vs 节点内）、聚合树结构 （多层 fat-tree vs 单层 NVSwitch） 均不同。
为什么需要 SHARP
核心问题：软件 AllReduce 在大规模 fat-tree 上代价为什么是天花板？
软件 AllReduce (Ring / Tree / HD) 两个固有代价 (推导见 4.8 AllReduce):
- 端到端传输量 $\approx 2 M$：数据走 RS 一遍 + AG 一遍，端口带宽被 double-count。200 / 400 Gb/s NIC 主导的大消息场景下 $2\times$ 系数直接体现在训练 step time
- 跨机架 inter-switch link 流量翻倍：叶 → spine → 叶 往返两次，bisection 被同一份梯度反复占用
SHARP 把 reduction 下沉到交换机后，端节点仅 1 发 + 1 收：发本地输入到上游交换机，收多播下来的最终结果。端口侧 $2 M \to M$, fat-tree 上行链路承载的是已部分聚合的小数据。这是 SHARP 与 NVLS 同根的"打破软件 AllReduce 带宽下界"机制 — 在交换机做规约本身是一种降维。
三代演进
核心问题：SHARP v1/v2/v3 三代在规格、延迟、支持的集合操作上有何变化？
| 代次 | 平台 / 交换机 | 链路速率 | 关键能力 | 目标场景 |
|---|---|---|---|---|
| v1 | Switch-IB 2 / Quantum (EDR) | 100 Gb/s | 小向量整数规约，聚合树，Barrier | HPC / MPI 小消息 |
| v2 | Quantum (HDR) | 200 Gb/s | 引入 SAT，支 FP16 / FP32 大向量 | 深度学习训练 （首次面向 AI） |
| v3 | Quantum-2 (NDR) | 400 Gb/s | 多租户，并行多树，BF16 / FP8 | 大规模多任务 AI 数据中心 |
| v4 | Quantum-X800 (XDR) | 800 Gb/s | 14.4 TFLOPS 在网计算 （v3 的 9×） | 超大规模 LLM 训练 |
@tbl-cc-sharp-evolution SHARP 三代演进
v2 是关键节点：SAT 让 SHARP 第一次能处理 AI 训练的大梯度向量 (Klenk et al., ISC 2020)，此前仅支 MPI Barrier 这种几十字节小操作。
v3 引入"多租户并行"：同一 subnet 大量并发聚合树，不同租户互不阻塞。v3.8 支持每 subnet 126 棵 (63 LLT + 63 SAT)，但 单交换机同时只能跑一棵 SAT （排他资源）。v3.14 上限提到 1023 (511 LLT + 511 SAT)。
聚合树：LLT 与 SAT
核心问题：LLT （低延迟树） 和 SAT （流式聚合树） 两种聚合树形态分别优化什么、适用什么消息大小？
核心问题：小消息追求延迟、大消息追求带宽，单一树结构能兼顾吗？
SHARP 在物理 fat-tree 上叠加逻辑聚合树：叶 = 主机进程 rank，内部 = 交换机内 Aggregation Node (AN)，上行规约 / 下行多播。NVIDIA 论文 (Graham et al., IEEE 2016) 与 OSU MUG 2020 教程 区分两类树：
LLT (Low Latency Tree)
整棵树和所有中间 buffer 常驻交换机片上 SRAM，整条 AllReduce 像查表一次性走完。
- 适合 MPI Barrier / 小梯度同步等 $\le$ KB 消息
- 延迟项 $\alpha$ 降到一次叶 → 根 → 叶 硬件转发延迟
- 远低于软件 Ring 的 $2 (N - 1) \alpha$
SAT (Streaming Aggregation Tree)
大消息分 segment 流水线推进，每 segment 沿树向上聚合的同时下一 segment 已在下层上行，pipeline depth = segment 数。
- 带宽项是网络物理带宽 $\beta$ 的一阶项，不带 $\frac{2 (N-1)}{N}$ 系数
- 一台 Quantum 交换机同一时刻仅一棵 SAT （硬件资源排他），多并发任务分摊到不同根交换机
SHARP 不要求规则 fat-tree，文档允许任意 IB 拓扑构建树，fat-tree / dragonfly+ 上聚合树形态最优。
与 NCCL 集成
核心问题：NCCL 如何把 AllReduce 委托给 SHARP?
NCCL 通过 CollNet 抽象层委托，由 nccl-rdma-sharp-plugins 实现，HPC-X 软件栈默认捆绑。配置见 NVIDIA SHARP × NCCL 文档。
关键环境变量
| 变量 | 含义 |
|---|---|
NCCL_COLLNET_ENABLE=1 | 激活 CollNet 路径，允许 NCCL 委托集合操作给 SHARP plugin |
NCCL_ALGO=CollNet | 强制 CollNet （NCCL 2.7.8 及更早需显式指定绕过自动选择 bug） |
NCCL_SHARP_DISABLE | 特定通信组禁用 SHARP, fallback 软件 AllReduce |
NCCL_SHARP_GROUP_SIZE_THRESH | 通信组大小阈值，小于此值不走 SHARP |
SHARP_COLL_LOCK_ON_COMM_INIT=1 | 通信组初始化时锁定 SAT 资源 （plugin v2.1+ 默认） |
NCCL_NVLS_ENABLE | 独立开关：节点内 NVLink-SHARP，与 IB SHARP 正交 |
@tbl-cc-sharp-nccl-env NCCL × SHARP 关键环境变量
NCCL 2.28 (2025) 把 SHARP / NVLS 整合进 Device API，新增 Multimem （对应 NVLink SHARP） 与 CollNet （对应 IB SHARP） 操作模式 (arXiv 2511.15076)。两层在网聚合可协同：intra-node NVLS RS + inter-node SHARP AR + intra-node NVLS AG。
最低硬件 / 软件要求
ConnectX-6 HDR 及以上 NIC, Quantum HDR 及以上交换机，GPUDirectRDMA, NCCL $\ge$ 2.7.3。
性能数据
| 场景 | 收益 | 来源 |
|---|---|---|
| MPI AllReduce 小消息 (v1, Frontera) | 软件基线 5× | NVIDIA Blog 2024 |
| MPI Barrier (v1, Frontera) | 软件基线 9× | 同上 |
| BERT 训练 (v2, MLPerf) | 软件基线 +17% | 同上 |
| AllReduce 延迟 (v3, Azure) | 近一个数量级 | 同上 |
| 服务商内部 AI workload | 端到端 +10–20% | 同上 |
| 在网计算吞吐 (v4 Quantum-X800) | 14.4 TFLOPS / switch, v3 的 9× | NVIDIA Networking for AI 白皮书 2025-02 |
@tbl-cc-sharp-perf SHARP 各代性能数据
注意：NVIDIA 数字普遍是 "lab best case"。实际收益取决于消息大小 （SAT 在 MB 级最优）、是否同时多任务 （多 SAT 竞争退化）、subnet 拓扑 （fat-tree well-formed 聚合树最优）。
限制
核心问题：什么场景不能用或不建议用 SHARP?
- 生态封闭：仅 Quantum IB 与 Spectrum-X Ethernet，其他厂商需 fallback 软件
- 仅卸载子集：AllReduce / Reduce / Broadcast / Barrier, 不支持 AllToAll / AllGather / ReduceScatter （SHARP API 不暴露中间状态）
- 数据类型有限：v1 整数；v2 + FP16 / FP32; v3 + BF16 / FP8
- SAT 单交换机排他：v3.14 后单 subnet 1023 树，但单交换机同一时刻仍一棵 SAT，多任务并发需 quota 管理
- Tree 拓扑约束：聚合树单根，根交换机故障需 Aggregation Manager 重建；Canary FGCS 2024 指出静态树在多任务拥塞下不最优
- 控制平面依赖 Subnet Manager：sharp_am 配 OpenSM，纯 RoCE / 通用 Ethernet 须 Spectrum-X
- 节点内 NVLS 独立：不同 ASIC / 协议栈 / NCCL 路径
与学术在网聚合的关系
核心问题：SHARP 与学术界的 in-network aggregation 研究（如 SwitchML/ATP）在数学原理和工程实现上有何关系？
SHARP 是工业界唯一大规模商用的在网聚合实现。学术界 （NetReduce / Flare / ATP / A2TP 等） 在 P4 可编程交换机或 FPGA SmartNIC 上探索类似机制，目标：
- 解除 SHARP 厂商绑定
- 卸载更广的集合语义
- 多租户动态调度
学术方案与 SHARP 的详细对比暂未整理成文。
开放问题
核心问题：SHARP 当前未被解决的关键开放问题有哪些？
- v4 真实万卡级 LLM 训练 step-time 收益 （vs lab 数据） 独立测量尚未公开
- Spectrum-X Ethernet 上的 SHARP 实现细节 （vs IB Quantum 的差异、聚合树是否可跨 L3 域） 公开资料有限
- 多任务并发 SAT 调度策略 （NVIDIA 默认 first-come vs 学术界 fair / congestion-aware） 对比
Takeaway
| 知识点 | 核心结论 |
|---|---|
| 机制 | 反 （reduction 下沉交换机），端节点 1 发 + 1 收 |
| 与 NVLS 区别 | 跨节点 IB / Ethernet (SHARP) vs 节点内 NVLink (NVLS) |
| 两种树 | LLT 小消息常驻 SRAM, SAT 大消息分段流水 |
| 代际跳跃 | v2 SAT 是 AI 训练分水岭，v4 14.4 TFLOPS |
| 卸载范围 | 仅 AllReduce / Reduce / Broadcast / Barrier |
| SAT 资源约束 | 单交换机同时一棵 SAT，多任务需配额 |
| NCCL 集成 | CollNet plugin + 关键环境变量，2.28 Device API |
| 两层在网聚合 | NVLS + SHARP 可协同 (intra-RS + inter-AR + intra-AG) |
| 主要限制 | 厂商封闭，集合语义子集，单根树故障代价 |
@tbl-cc-sharp-takeaway SHARP 要点
参考资料
- Graham et al., "Scalable Hierarchical Aggregation Protocol (SHArP)", IEEE COM-HPC 2016 — 原始论文
- Klenk et al., "SHARP Streaming-Aggregation Hardware Design and Evaluation", ISC 2020 — v2 SAT 设计与 HDR 评测
- Bureddy, "SHARP: In-Network Scalable Streaming Hierarchical Aggregation and Reduction Protocol", OSU MUG 2020 — v1 / v2 对比、LLT vs SAT
- Advancing Performance with NVIDIA SHARP, NVIDIA Blog 2024-10 — 三代演进官方综述
- NVIDIA Quantum-2 QM9700 Switch Datasheet — Quantum-2 + v3
- NVIDIA Networking for AI 白皮书 2025-02 — Quantum-X800 + v4 14.4 TFLOPS
- Using NVIDIA SHARP with NVIDIA NCCL — Plugin 配置、环境变量
- SHARP User Manual Rev 3.14 — 聚合树上限 1023
- SHARP User Manual Rev 3.8 — 单交换机 SAT 排他
- nccl-rdma-sharp-plugins — Plugin 源码
- Khalilov et al., "GPU-Initiated Networking for NCCL", arXiv 2511.15076 2025-11 — NCCL 2.28 Device API
- Canary: Congestion-aware in-network allreduce using dynamic trees, FGCS 2024 — SHARP 静态树局限