ReelOS.AI 禅定｜先看懂这条推理链
GPU 集群有了高速网络，不代表训练一定快。
- GPU 很贵。
- 但大模型训练不是每张 GPU 各算各的。
- 多张 GPU 要在同一个训练节奏里不断同步数据。
- 数据包括梯度、参数、激活值、MoE 路由、Tensor Parallel 中间结果。
- 数据没同步完，下一轮计算就不能顺利开始。
- 一部分 GPU 算完了，却在等通信结果；GPU 等待，就是算力浪费。
- InfiniBand / RoCE 解决的是“路够不够快”。
- RDMA / GPUDirect 解决的是“数据能不能少绕路”。
- NCCL 解决的是“多张 GPU 的数据到底怎么流动”。
- 它会根据 GPU 拓扑、网卡位置、通信规模、算法和协议，选择更合适的通信路径。
- AllReduce、AllGather、ReduceScatter、AllToAll，本质都是 GPU 集群的集合通信动作。
- 所以 NCCL 不是让单张 GPU 更快，而是让多张 GPU 少等待、少空转。
- 判断 AI 集群不能只看 GPU 数量和端口带宽，更要看 NCCL 的有效带宽、通信耗时和扩展效率。
- NCCL 的本质，是把硬件网络能力转化成训练真正可用的集合通信吞吐。
很多人理解 GPU 集群，容易先看硬件。
有多少张 GPU？是 H100、H200，还是 B200、B300？节点之间用的是 InfiniBand，还是 RoCE？网卡是 400G，还是 800G？
这些都重要。
但真正跑大模型训练时，你会发现一个更隐蔽的问题：
GPU 有了，网络也有了，训练不一定就快。
因为高速网络只是把路修好了。
数据到底怎么走、什么时候走、走哪条链路、分成几段走、能不能和计算重叠，还需要一个通信调度层。
这个通信调度层，就是 NCCL。
NCCL 全称是 NVIDIA Collective Communications Library，中文可以理解成 NVIDIA 集合通信库。NVIDIA 官方定义它是一个面向 GPU 间通信的库，提供 topology-aware 的 inter-GPU communication primitives，也就是能感知拓扑的 GPU 通信原语。它不是完整的并行编程框架，而是专门聚焦于加速 GPU 之间通信的库。
一句话：
GPU 负责计算，网络负责连接，NCCL 负责组织 GPU 之间的数据怎么流动。
如果没有 NCCL，或者 NCCL 没有正确用好 GPU 拓扑和网络能力，再贵的 GPU、再快的 InfiniBand / RoCE，也可能变成等待。
一、先抓住主杆：NCCL 解决的是 GPU 等待问题
大模型训练不是每张 GPU 各算各的。
在分布式训练里，一批 GPU 会共同训练同一个模型。每张 GPU 算完自己负责的部分后，需要和其他 GPU 同步数据。
这些数据包括：
- 梯度；
- 参数；
- 激活值；
- MoE 专家路由数据；
- Tensor Parallel 中间结果；
- Pipeline Parallel 边界数据；
- 数据并行中的同步结果。
只要数据没同步完，下一轮计算就不能顺利开始。
所以 GPU 集群最怕的不是“某一张卡慢一点”，而是：
一部分 GPU 算完了，却在等另一部分 GPU 的通信结果。
这就是 NCCL 的位置。
它不是为了让单张 GPU 算得更快。
它是为了让多张 GPU 在一个训练节奏里更高效地交换数据。
可以这样理解：
NCCL 的核心使命，是减少 GPU 集群里的通信等待。
这也是为什么判断一个 AI 集群不能只看 GPU 数量，也不能只看端口带宽。
真正要看的是：
- NCCL AllReduce 耗时；
- NCCL AllGather 耗时；
- NCCL ReduceScatter 耗时；
- NCCL AllToAll 耗时；
- NCCL algbw；
- NCCL busbw；
- 通信是否稳定；
- 多节点扩展后性能是否衰减。
网络是路。
NCCL 是车流调度。
训练效率，取决于车能不能持续、稳定、少拥塞地跑起来。
二、NCCL 在 GPU 集群里处在哪一层？
理解 NCCL，要先把系统分层看。
| 层级 | 解决什么问题 | 代表技术 |
|---|---|---|
| GPU 计算层 | 单张卡怎么计算 | CUDA / Tensor Core / HBM |
| 节点内互连层 | 一台服务器内多张 GPU 怎么通信 | NVLink / NVSwitch / PCIe |
| 节点间网络层 | 多台服务器怎么互连 | InfiniBand / RoCE / Ethernet |
| 直接数据通道 | 数据怎么少经过 CPU 和内核 | RDMA / GPUDirect RDMA |
| 集合通信层 | 多张 GPU 的数据怎么同步 | NCCL |
| 训练框架层 | 模型训练任务怎么组织 | PyTorch / Megatron / DeepSpeed |
| 调度运维层 | 任务、资源、故障怎么管理 | Slurm / Kubernetes / 监控系统 |
NCCL 不负责训练模型，也不负责调度 GPU，更不负责物理网络转发。
它负责的是：
当训练框架需要多张 GPU 交换数据时，NCCL 用最高效的方式完成这次通信。
它会考虑节点内外的不同路径：
- 同一台机器内，优先利用 NVLink、NVSwitch、PCIe；
- 跨机器通信时，利用 InfiniBand、RoCE、RDMA、GPUDirect；
- 多张网卡时，尽可能利用多 rail；
- 不同通信规模下，选择不同算法和协议。
所以 NCCL 是连接“硬件网络能力”和“训练通信需求”的中间层。
没有它，训练框架很难直接高效驾驭复杂的 GPU 拓扑和网络拓扑。
三、什么是集合通信？
NCCL 里的核心概念叫 Collective Communication，也就是集合通信。
集合通信不是两台机器之间简单发消息。
它是很多 GPU 一起参与的一组通信动作。
NVIDIA NCCL 文档列出了 AllReduce、Broadcast、Reduce、AllGather、ReduceScatter、AllToAll、Gather、Scatter 等集合通信原语。
理解 NCCL，最重要的是理解下面几个动作。
AllReduce：大模型训练里最经典的通信
AllReduce 是 NCCL 里最重要的操作之一。
它的作用是：
每张 GPU 都拿出一份数据，大家一起做归约计算，然后每张 GPU 都拿到相同的最终结果。
比如数据并行训练中，每张 GPU 都算出一份梯度。
但模型参数要保持一致，所以所有 GPU 的梯度需要汇总。
AllReduce 就会把这些梯度做求和、平均或其他归约操作，然后把结果发回每张 GPU。
用人话说：
每张卡都交作业，NCCL 帮大家汇总答案，再把统一答案发回每张卡。
为什么 AllReduce 重要？
因为在传统数据并行训练中，每一步训练几乎都要同步梯度。
如果 AllReduce 慢，所有 GPU 都要等。
所以 AllReduce 的耗时，直接影响训练 step time。
AllGather：每张 GPU 有一块，最后大家都拿到完整数据
AllGather 的作用是：
每张 GPU 拿出一份数据，最后所有 GPU 都拿到完整集合。
它常见于模型并行、参数切分、上下文并行等场景。
可以这样理解：
每张卡手里有一块拼图，AllGather 让每张卡都拿到完整拼图。
ReduceScatter：先汇总，再分片
ReduceScatter 可以理解成 AllReduce 的拆分版。
它先对多张 GPU 的数据做归约，然后把结果切成不同部分，分发给不同 GPU。
它在现代大模型训练里很关键。
因为不是所有场景都需要每张 GPU 拿到完整结果。
有时候每张 GPU 只需要最终结果的一部分。
这可以减少通信量，提高效率。
AllToAll：MoE 和专家并行里的关键通信
AllToAll 的含义是：
每张 GPU 都要和其他 GPU 交换不同的数据。
这在 MoE，也就是 Mixture of Experts 模型里非常关键。
因为不同 token 会被路由到不同专家，而不同专家可能分布在不同 GPU 上。
于是 GPU 之间要大量交换 token 或激活值。
AllToAll 和 AllReduce 不一样。
AllReduce 更像“大家把结果汇总成同一个答案”。
AllToAll 更像“每个人都要把不同包裹发给不同人”。
所以 AllToAll 对网络非常敏感。
它容易形成复杂流量，也更容易暴露拓扑、拥塞和调度问题。
四、Rank、Communicator、Topology：NCCL 的三个基本概念
要真正理解 NCCL，还要理解三个词。
Rank：通信里的编号
在 NCCL 里，每个参与通信的 GPU 通常会对应一个 rank。
rank 可以理解成通信系统里的编号。
它不是“第几张物理 GPU”这么简单，而是本次通信中的逻辑身份。
同样一组 GPU，不同 rank 映射方式，可能影响通信效率。
因为 rank 顺序会影响数据流向、路径选择和集合通信布局。
Communicator：通信组
Communicator 可以理解成一组参与通信的 GPU 组成的通信群。
一次 AllReduce、AllGather、ReduceScatter，都发生在某个 communicator 内部。
如果有多个并行维度，比如数据并行、张量并行、流水线并行，可能会有多个 communicator。
不同 communicator 服务于不同通信目的。
Topology：拓扑
Topology 是 NCCL 非常核心的能力。
NCCL 是 topology-aware 的通信库。
这意味着它会感知 GPU 之间的连接关系，比如：
- 哪些 GPU 之间有 NVLink；
- 哪些 GPU 之间只能走 PCIe；
- 哪些 GPU 更靠近哪张网卡；
- 哪些网卡属于同一个 rail；
- 跨节点通信要走 InfiniBand 还是 RoCE；
- GPUDirect RDMA 是否可用。
拓扑感知非常关键。
因为同样是 8 张 GPU，不同服务器架构下，GPU 到 GPU、GPU 到 NIC 的路径可能完全不同。
如果 NCCL 选错路径，数据可能绕路。
一绕路，延迟和带宽都会变差。
五、NCCL 怎么决定数据怎么走？
NCCL 做通信，不是简单“从 A 发到 B”。
它要综合考虑三类问题。
第一，走什么物理路径？
同一台机器内，可能有：
- NVLink；
- NVSwitch；
- PCIe P2P；
- CPU 内存中转。
跨机器时，可能有：
- InfiniBand；
- RoCE；
- TCP Socket；
- RDMA；
- GPUDirect RDMA。
NCCL 要尽量选择最快、最直接的路径。
NCCL 官方环境变量文档说明，默认情况下，如果拓扑允许，NCCL 会启用 GPU Direct RDMA；NCCL_NET_GDR_LEVEL 可以细粒度控制 NIC 与 GPU 在什么拓扑距离下使用 GPUDirect RDMA。
第二，用什么算法？
不同通信规模、不同拓扑下，适合的算法不同。
NCCL 支持通过 NCCL_ALGO 控制可用算法。官方文档列出的算法包括 Ring、Tree、CollNetChain、CollNetDirect、NVLS、NVLSTree、PAT 等，并说明默认情况下 NCCL 会根据节点拓扑和架构自动选择可用算法。
可以简单理解：
- Ring 更适合充分利用带宽；
- Tree 往往更关注降低层级传播延迟；
- CollNet / SHARP / NVLS 这类能力会结合更高级的网络或 NVLink offload 能力；
- NCCL 会根据实际拓扑和通信大小选择。
不建议普通用户随意强行指定算法。
因为手动指定的算法，可能反而破坏 NCCL 的自动优化。
第三，用什么协议？
NCCL 还涉及不同通信协议。
官方文档中的 NCCL_PROTO 可控制 LL、LL128、Simple 等协议，但也明确提醒，除非怀疑特定协议 bug，否则不鼓励用户设置这个变量；不支持的平台上启用 LL128 甚至可能导致数据损坏。
可以这样理解：
- 小消息更关注延迟；
- 大消息更关注带宽；
- 不同协议在延迟、带宽、资源占用之间取舍不同；
- NCCL 通常会自动选择。
所以，NCCL 的核心能力不是“发数据”。
而是：
根据拓扑、数据大小、通信模式和可用硬件，选择合适路径、算法和协议。
六、NCCL 和 InfiniBand、RoCE、GPUDirect 是什么关系？
这几个概念经常被混在一起。
它们不是同一个层级。
| 概念 | 作用 |
|---|---|
| InfiniBand | 高性能专用计算网络 |
| RoCE | 在以太网上承载 RDMA |
| RDMA | 远程直接内存访问，减少 CPU 和内核参与 |
| GPUDirect RDMA | GPU 显存与网卡之间更直接交换数据 |
| NCCL | 组织多 GPU 集合通信 |
| NCCL Tests | 测量 NCCL 通信性能和正确性 |
可以这样理解：
InfiniBand / RoCE 是高速公路。
RDMA / GPUDirect 是直达货运通道。
NCCL 是车流调度系统。
nccl-tests 是测速工具。
所以，有了 InfiniBand 或 RoCE，不代表训练一定快。
如果 NCCL 没有正确识别网卡、没有启用 GPUDirect、没有用好多 rail、没有匹配合适算法，训练还是会慢。
反过来，如果 NCCL 调度得很好，但底层网络拥塞、PFC 风暴、链路误码、ECN/DCQCN 配置不合理，训练也会慢。
真正的性能来自协同：
GPU 拓扑 + 网络 Fabric + RDMA/GPUDirect + NCCL + 训练框架。
七、为什么 NCCL 有效带宽比端口带宽更重要？
很多人看网络，喜欢问：
这张网卡是 400G 还是 800G？
这个问题当然重要，但不够。
因为端口带宽只是物理上限。
训练真正看到的是 NCCL 有效带宽。
NVIDIA 官方 nccl-tests 文档说明，NCCL tests 会报告平均操作时间，以及两类带宽：algorithm bandwidth 和 bus bandwidth。algorithm bandwidth 是按操作数据大小除以时间得到；bus bandwidth 则用于反映 inter-GPU communication 对硬件带宽的利用情况，便于和硬件峰值带宽比较。
也就是说，判断集群通信效率，不能只看网卡标称值。
要看：
time：一次集合通信花多久；algbw：从算法视角看，数据处理效率是多少；busbw：从硬件总线视角看，底层通信带宽利用得怎么样。
这就是为什么在 AI 集群验收里，经常要跑 nccl-tests。
NVIDIA 的 nccl-tests 项目说明，它用于检查 NCCL 操作的性能和正确性，并支持单节点、多节点、多进程测试。
一句话：
端口带宽是硬件参数，NCCL busbw / algbw 才是训练通信看到的真实结果。
八、为什么有时候 NCCL 跑不快？
NCCL 跑不快，原因通常不只是 NCCL 本身。
它更像一个“暴露系统短板”的放大镜。
常见问题有九类。
1. GPU 到网卡拓扑不合理
比如 GPU 和 NIC 不在同一个 PCIe switch 下，或者跨 NUMA 访问。
这会导致数据绕远路。
2. GPUDirect RDMA 没有启用
如果 GPUDirect RDMA 没启用，数据可能需要先经过 CPU 或主机内存中转。
NCCL 文档说明，默认情况下，如果拓扑允许，NCCL 会启用 GPUDirect RDMA，但它也受 GPU-NIC 拓扑距离等条件影响。
3. NCCL 选错网卡或网口
多网卡机器里，如果 NCCL 用了错误网口，可能走到管理网、业务网，或者只用了部分 NIC。
NCCL 文档里的 NCCL_SOCKET_IFNAME 可以指定 IP interface，NCCL_IB_HCA 可以指定 RDMA HCA 接口。
4. 多 rail 没有正确利用
很多 AI 节点会有多张高速网卡。
如果 NCCL 没有正确使用多 rail，单卡网络可能打满，但整体带宽上不去。
5. InfiniBand / RoCE 本身有拥塞
底层网络有拥塞、丢包、ECN 配置不合理、PFC 异常，NCCL 结果一定会变差。
6. 交换机或光模块异常
链路误码、光模块问题、端口 flap，会造成 NCCL 性能抖动。
7. Rank 映射不合理
rank 到 GPU 的映射影响通信拓扑。
映射不合理，可能导致跨节点、跨 NIC、跨 PCIe 的路径变差。
8. 训练并行策略导致通信压力过大
不同并行方式通信模式不同。
数据并行偏 AllReduce。
张量并行可能有频繁 AllReduce / AllGather / ReduceScatter。
MoE 专家并行会产生大量 AllToAll。
所以不是所有模型对网络的压力都一样。
9. 小消息和大消息瓶颈不同
小消息更受延迟影响。
大消息更受带宽影响。
所以只看一个消息大小的 NCCL 测试结果不够，要扫不同 size。
九、NCCL 调优应该怎么想？
不要一上来就调环境变量。
先建立一个顺序。
第一步：确认硬件和拓扑
先看：
- GPU 型号；
- GPU 数量；
- NVLink / NVSwitch 拓扑；
- PCIe 拓扑；
- NIC 数量；
- NIC 到 GPU 的距离；
- NUMA 关系；
- IB / RoCE 网络是否正常。
如果拓扑不合理，后面调 NCCL 只是补救。
第二步：确认网络路径
确认 NCCL 是否用了正确网络。
常见检查点：
- 是否用了 IB / RoCE；
- 是否走了正确 HCA；
- 是否误走 TCP；
- 是否用了管理网；
- 多 NIC 是否都被利用；
- GID / RoCE version 是否正确；
- 网络 MTU、PFC、ECN、DCQCN 是否匹配。
第三步：确认 GPUDirect RDMA
看 NCCL log，确认 GDR 是否启用。
如果没启用，要继续查：
- GPU 和 NIC 拓扑距离；
- 驱动版本；
- CUDA / NCCL / OFED 版本；
- BIOS / IOMMU / ACS 设置；
- 容器权限；
- Kubernetes device plugin 配置。
第四步：跑 nccl-tests 基线
先跑单机。
再跑双机。
再扩大到多机。
不要一上来就跑 1024 卡。
否则出了问题，不知道是哪一层坏了。
第五步：对比不同集合通信
至少看：
- AllReduce；
- AllGather；
- ReduceScatter；
- AllToAll。
因为不同模型瓶颈不同。
第六步：再考虑 NCCL 参数
在清楚瓶颈后，再考虑：
NCCL_SOCKET_IFNAME；NCCL_IB_HCA；NCCL_NET_GDR_LEVEL；NCCL_ALGO；NCCL_PROTO；- rail / plane 相关配置；
- debug 日志。
但要注意，NVIDIA 文档也提醒，一些 debug 或调优环境变量不应长期保留在生产脚本中，否则可能导致性能下降、崩溃或 hang。
NCCL 调优的原则是：
先确认系统路径，再确认网络，再确认 GDR，再看算法参数。
不要反过来。
十、NCCL 和 SHARP、NVLink SHARP 是什么关系？
随着 GPU 集群变大，单纯依靠服务器之间交换数据，可能会遇到通信瓶颈。
于是出现了更高级的 offload 思路：
能不能把一部分集合通信操作下沉到网络或交换层完成？
这就是 SHARP 这类技术的价值。
NVIDIA 文档说明，NCCL-RDMA-SHARP plugin 可以让 NCCL 使用 RDMA 和 SHARP collectives。
直观理解：
普通 AllReduce 是 GPU 和 GPU 之间来回交换数据。
SHARP 的思路是让交换网络参与部分归约。
这样可以减少节点之间重复传输，提高大规模集合通信效率。
另外，NCCL 官方环境变量文档中也提到，NVLS 和 NVLSTree 用于启用 NVLink SHARP offload。
所以，未来 NCCL 不只是“软件调度”。
它会越来越多地结合：
- GPU 内部互连；
- NVLink / NVSwitch；
- InfiniBand switch；
- SHARP；
- 网络内计算；
- 多层级拓扑优化。
这也是 AI 集群网络继续复杂化的原因。
通信优化正在从“软件库”变成“软硬件协同系统”。
十一、NCCL 对训练框架意味着什么？
对训练框架来说，NCCL 是底层通信后端。
训练框架不希望每个开发者都手写 AllReduce、AllGather、ReduceScatter。
它们会通过分布式训练接口调用底层通信库。
所以你平时可能没直接写 NCCL 代码，但你已经在用 NCCL。
比如你跑分布式训练时，表面上是在用训练框架。
实际上，一旦进入多 GPU、多节点同步，底层很可能就会调用 NCCL 完成通信。
这就是为什么训练慢的时候，不能只看模型代码。
还要看 NCCL log、NCCL tests、网络指标和 GPU 拓扑。
因为问题可能不在模型。
而在通信。
十二、理解 NCCL 的五个常见误区
误区一：有高速网络，NCCL 就一定快
不一定。
NCCL 要正确识别拓扑、选对网卡、启用 GDR、用好多 rail，才能把高速网络转成训练效率。
误区二：NCCL 慢就是 NCCL 的问题
不一定。
NCCL 慢，经常是硬件拓扑、网络拥塞、驱动版本、容器权限、Rank 映射、RoCE 配置的问题。
NCCL 只是把问题暴露出来。
误区三：只跑 AllReduce 就能代表全部训练性能
不够。
AllReduce 很重要，但 AllGather、ReduceScatter、AllToAll 也很关键。
尤其是大模型并行和 MoE 场景，AllToAll 可能成为核心瓶颈。
误区四：端口带宽越高，训练越快
不一定。
端口带宽是理论上限。
训练看到的是 NCCL 有效带宽、集合通信耗时和通信与计算重叠效果。
误区五：NCCL 参数越多调得越好
不一定。
很多 NCCL 参数是诊断或特殊场景下使用的。
长期乱设，可能破坏自动选择策略，甚至引发 hang、崩溃或性能退化。
十三、NCCL 学习路线
如果你想系统学习 NCCL，可以按这条路线走。
第一层：理解集合通信
先搞懂 AllReduce、AllGather、ReduceScatter、AllToAll、Broadcast、Reduce。
不要急着看参数。
先理解这些通信动作为什么存在。
第二层：理解 GPU 拓扑
搞清楚 PCIe、NVLink、NVSwitch、GPU 到 NIC 的路径、NUMA、单机 8 卡拓扑。
第三层：理解节点间网络
搞清楚 InfiniBand、RoCE、RDMA、GPUDirect RDMA、多 rail、GID、HCA、PFC / ECN / DCQCN。
第四层：理解 NCCL 选择策略
重点看 topology-aware、Ring / Tree、LL / LL128 / Simple、CollNet、SHARP、NVLS。
学到这一步，才开始看 NCCL_ALGO、NCCL_PROTO 这类参数。
第五层：理解性能测试
学会跑单机 nccl-tests、双机 nccl-tests、多机 nccl-tests。
重点看：
- time；
- algbw；
- busbw；
- 稳定性；
- 扩展性；
- 抖动。
第六层：理解真实训练瓶颈
最后再回到训练框架：
- step time；
- compute time；
- communication time；
- overlap；
- GPU utilization；
- tokens/s；
- scaling efficiency。
NCCL 不是孤立学习的。
它应该放在完整 AI Compute Fabric 里理解。
十四、最终判断：NCCL 是 GPU 集群效率的放大器
NCCL 最重要的价值，不是“能让 GPU 通信”。
而是：
把复杂 GPU 拓扑、节点间网络、RDMA 通道和集合通信需求，组织成高效的数据流。
没有 NCCL，训练框架很难高效使用多 GPU。
NCCL 配置不好，昂贵的 GPU 会等待。
底层网络不好，NCCL 会把问题暴露出来。
硬件、网络、NCCL、训练框架协同得好，GPU 集群才能真正变成算力系统。
所以，理解 NCCL，要抓住一句话：
NCCL 是把 GPU 集群从“很多张卡”变成“一个协同计算系统”的关键通信层。
判断一个 AI 集群，不要只问：
有多少 GPU？网卡多少 G？用了 InfiniBand 还是 RoCE？
还要问：
- NCCL AllReduce 多快？
- AllGather 稳不稳？
- AllToAll 有没有拥塞？
- GPUDirect RDMA 是否启用？
- busbw 能不能接近硬件能力？
- 多节点扩展后性能掉多少？
- 通信能不能和计算重叠？
当 AI 计算从单机走向大规模集群，NCCL 就不再只是一个库。
它是 GPU 集群能否跑满的关键软件层。
权威资料与参考项目
如果想系统理解 NCCL，不建议只看概念文章。更好的路径是：官方文档 → 测试工具 → 源码项目 → 扩展通信库 → 论文。
- NVIDIA NCCL User Guide：理解 NCCL 的官方入口。
- NCCL Collective Operations：理解 AllReduce、AllGather、ReduceScatter、AllToAll 等集合通信操作。
- NCCL Environment Variables：理解
NCCL_SOCKET_IFNAME、NCCL_IB_HCA、NCCL_NET_GDR_LEVEL、NCCL_ALGO、NCCL_PROTO等调优入口。 - NVIDIA/nccl：NCCL 核心源码项目。
- NVIDIA/nccl-tests：检查 NCCL 操作性能和正确性的核心工具。
- nccl-tests Performance：理解
time、algbw、busbw的关键文档。 - NCCL-RDMA-SHARP Plugins：理解 NCCL 如何和 RDMA、SHARP 结合。
- Mellanox/nccl-rdma-sharp-plugins：NCCL RDMA SHARP 插件项目。
- OpenUCX：理解更通用的 HPC / RDMA 通信栈。
- Microsoft MSCCL：理解自定义集合通信算法。
- Microsoft MSCCL++：理解下一代 GPU 通信抽象。
- ROCm RCCL：理解 AMD ROCm 生态下的集合通信库。
- NVIDIA NVSHMEM：理解 GPU-initiated、one-sided communication。
- Demystifying NCCL：深入理解 NCCL 通信协议和算法。
- MSCCL++: Rethinking GPU Communication Abstractions for Cutting-edge AI Applications：理解可定制 GPU 通信抽象的方向。