想象一场交响乐演出：几十位乐手各执一件乐器，但演奏必须严丝合缝地同步。每个人都要知道其他人在拉什么、整体节奏走到哪里，才能把自己的声部对进去。AI大模型训练也是同样的场景——成百上千块 GPU 就像一支临时拼凑的乐团，每块 GPU 都在独自计算一小块数据，算出一个叫“梯度”的中间结果。梯度之于模型，就像乐手对节奏的理解：如果各弹各的，模型永远无法收敛。 在 AMD 平台上，负责让这些 GPU“合奏”的正是 RCCL（ROCm Collective Communications Library，ROCm 集合通信库）。它像乐团总指挥，为 GPU 们设计最高效的协作方案：谁先传给谁、走哪条通道、如何避免拥堵，最终让所有 GPU 达成一致的梯度共识。本文将从零开始，带你认识这位 AI 时代的“指挥家”——它的核心原语、通信组、拓扑感知、RDMA 加速，以及如何用它平滑替代 NVIDIA 的 NCCL。

岗位关联

对 AI 从业者的价值：掌握 RCCL 是驾驭 AMD 与国产 GPU 多卡训练的关键能力。学会它，你就能在异构算力集群上独立完成分布式训练的通信层配置与调优，从“只会单卡”进阶为“能管千卡”。

目录
  1. 可视化演示
  2. RCCL生态定位——乐团的心脏与指挥
  3. 集合通信原语——乐手们的合奏默契
  4. 通信组构建——给乐手编号入座
  5. 拓扑感知优化——编排最省力的传谱路线
  6. RDMA高速传输——音符的直达通道
  7. NCCL兼容API——国际通用的五线谱
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

本节配有交互动效（进入视口后自动加载，约 3KB）。

RCCL生态定位——乐团的心脏与指挥

想象一场交响乐演出：几十位乐手各执一件乐器，但他们的演奏必须严丝合缝地同步。因为每个人都需要及时知道其他人在拉什么、整体节奏走到哪里，才能把自己的声部对进去。AI大模型训练也是同样的场景——成百上千块 GPU 就像一支临时拼凑的乐团，每一块 GPU 都在独自计算一小块数据，算出一个叫“梯度”的中间结果。梯度之于模型，就像乐手对节奏的理解：如果各弹各的，模型永远无法统一。

在 AMD 平台上，负责让这些 GPU“合奏”的正是 RCCL（ROCm Collective Communications Library，ROCm 集合通信库）。它是 ROCm 生态中面向多卡通信的底层组件，定位与 NVIDIA 的 NCCL 完全对标：NCCL 如何在 CUDA 平台上管理多 GPU 通信，RCCL 就如何在 ROCm 平台上做同样的事。可以这样理解：NCCL 是 NVIDIA 乐团的专属指挥，而 RCCL 是 AMD 乐团的专属指挥，两人读的是同一套五线谱，指挥风格却各有所长。

在分布式训练中，RCCL 既是“通信调度员”也是“路线规划师”。它负责选择最省时间的通信原语、规划每块数据走哪条物理路径、决定是否需要走 RDMA 高速通道。没有它，多 GPU 只是一群各自演奏的乐手；有了它，它们才真正成为一个步调一致的乐团。后续几节，我们将逐一拆解这位指挥家的“指挥方案”。

集合通信原语——乐手们的合奏默契

指挥靠的是一套约定俗成的“合奏模式”。RCCL 提供的集合通信原语（Collective Communication Primitives），就是这些模式中最核心的几条。最常用的是 AllReduce：所有 GPU 把自己算出的梯度交出来，汇总平均后再发回给所有人。想象一个弦乐四重奏排练，每位乐手先按自己的理解拉一遍，然后大家把各自的节奏片段拿出来比对，最终统一成同一个速度——这个过程不断重复，直到每个人都拿到相同的“标准节奏”。

数学上，N 个 GPU 各持有一个梯度向量，第 i 个 GPU 上的第 j 个分量为 \(x_{i,j}\)。AllReduce（求和后取平均）的输出是：

除了 AllReduce，RCCL 还提供 AllGather（每个 GPU 把自己的数据广播给所有人，最后每人都持有完整数据集）、Broadcast（一个 GPU 向所有 GPU 发送同一份数据）、Reduce（汇总到单一 GPU）和 Scatter（把大数据块拆散分给各个 GPU）。它们各自适合不同的并行策略：数据并行用 AllReduce 同步梯度，模型并行用 AllGather 交换激活值，参数服务器模式则常用 Reduce 和 Scatter。理解了这些“合奏模式”，就理解了 RCCL 能为训练提供的全部“乐谱”。

yj=1N∑i=1Nxi,j\displaystyle y_j = \frac{1}{N} \sum_{i=1}^{N} x_{i,j}
  1. 下标含义\(x_{i,j}\) 表示第 \(i\) 个 GPU 上梯度向量的第 \(j\) 个分量，其中 \(i\) 从 1 到 \(N\) 遍历所有 GPU。
    xi,j(i=1,2,…,N; j=1,2,…,d)\displaystyle x_{i,j} \quad (i=1,2,\dots,N; \ j=1,2,\dots,d)
  2. 累加求和把所有 GPU 上同一个位置的第 \(j\) 个分量全部加起来，得到该分量的总和。
    ∑i=1Nxi,j\displaystyle \sum_{i=1}^{N} x_{i,j}
  3. 取平均除以 GPU 总数 \(N\)，得到所有 GPU 共同的梯度均值，这就是分布式训练中“梯度同步”的数学本质。
    yj=1N∑i=1Nxi,j\displaystyle y_j = \frac{1}{N} \sum_{i=1}^{N} x_{i,j}

通信组构建——给乐手编号入座

正式演出前，指挥必须先确认乐队编制：谁坐第一小提琴、谁坐第二小提琴、总共有多少人。RCCL 中，参与通信的 GPU 集合被称为通信组（Communicator），组内每个成员拥有一个唯一编号 rank，而组内 GPU 总数叫作 world_size。这就像乐团每位乐手的座席编号：首席小提琴是 0 号，第二小提琴是 1 号……有了编号，指挥才能精确下达指令：“3 号乐手，把你的声部传给 4 号。”

通信组的初始化在 RCCL 中通过 rcclCommInitRank 完成，参数依次是通信组指针、组内总人数、通信组 ID 和当前 rank。在多机场景下，通信组 ID 由 rank 0 生成并以广播方式分发给其他节点，随后所有节点各自调用初始化函数，最终建立跨越机器的“虚拟乐团”。组内每个成员都清楚自己的前后邻居，也清楚整个组的规模，这是后续一切通信操作的前提。

如果用全连接模型让每对 GPU 都建立独立通道，通道数会随 GPU 数量急剧膨胀：

对比来看，Ring AllReduce 让每个 GPU 只与前后两个邻居通信，就像乐手只需要把谱子传给左手边的人，再由他传下去。这种“班组式”的小范围协作，远比所有人围成一团互相递谱高效得多。

M=(N2)=N(N−1)2\displaystyle M = \binom{N}{2} = \frac{N(N-1)}{2}
  1. 组合数含义\(\binom{N}{2}\) 表示从 \(N\) 个 GPU 中选出 2 个来建立连接的组合数，也就是两两配对的通道总数。
    (N2)=N!2!(N−2)!\displaystyle \binom{N}{2} = \frac{N!}{2!(N-2)!}
  2. 展开阶乘将组合数展开为阶乘形式，其中 \(N!\) 是 \(N\) 的阶乘，代表所有排列数。
    N!2!(N−2)!\displaystyle \frac{N!}{2!(N-2)!}
  3. 约分化简对阶乘进行约分，得到简洁形式 \(\frac{N(N-1)}{2}\)。当 \(N=64\) 时通道数高达 2016，而 Ring 拓扑只需要 64 条边——这正是 Ring AllReduce 高效的核心原因。
    N(N−1)2\displaystyle \frac{N(N-1)}{2}

拓扑感知优化——编排最省力的传谱路线

有经验的指挥知道舞台上谁离谁近，绝不会让第一小提琴穿过整个舞台去给低音提琴递谱。RCCL 启动时也会做“拓扑探测”：它扫描 GPU 之间的物理连接结构，建立一张精确的“舞台地图”。这张地图标注了哪些 GPU 在同一个 Die 内、哪些跨了 Die 但仍在同一颗 GPU 芯片上、哪些在不同 PCIe 交换机下、哪些需要跨机器通信，从而为每次通信规划最优路径。

这背后是 RCCL 的拓扑感知路由机制：它根据探测到的层级拓扑，把通信任务调度到延迟最低、带宽最大的链路上，避免数据在慢速链路上“堵车”。在 AMD 平台上，同一颗 GPU 内的计算单元通过 Infinity Fabric 高速互联，同节点多卡通过 PCIe 交换机相连，跨节点则依赖 RoCE 或 InfiniBand 网络。这三层链路的带宽差异往往在一个数量级以上，选错路径的代价是极其昂贵的。

为了量化路径优劣，RCCL 内部会把每条链路的通信代价建模为一个简单公式：

拓扑感知优化让 RCCL 像熟悉剧场的指挥一样，总能为每个音符挑选最顺畅的传递路线。在千卡集群上，这种“路线规划”能力往往决定了训练的通信时间是从分钟级降到秒级，还是反过来。

C(l)=Tlat(l)+DB(l)\displaystyle C(l) = T_{\text{lat}}(l) + \frac{D}{B(l)}
  1. 固定延迟项\(T_{\text{lat}}(l)\) 是链路 \(l\) 上的固定延迟，包括协议握手、路由跳转等开销，与传输的数据量无关。
    Tlat(l)\displaystyle T_{\text{lat}}(l)
  2. 传输时间项\(\frac{D}{B(l)}\) 表示传输 \(D\) 字节数据所需的时间，\(B(l)\) 是链路 \(l\) 的带宽。数据量越大，或带宽越低，这项开销越大。
    DB(l)\displaystyle \frac{D}{B(l)}
  3. 代价求和两者相加得到链路总代价。RCCL 对每条候选路径计算该值，并选择代价最小的路径来调度通信。
    C(l)=Tlat(l)+DB(l)\displaystyle C(l) = T_{\text{lat}}(l) + \frac{D}{B(l)}

RDMA高速传输——音符的直达通道

传统网络通信中，数据要从 GPU 显存拷贝到 CPU 内存，再由 CPU 交给网卡发送，对端还要经过内核协议栈层层解析才能到达 GPU 显存。这就像传谱人要经过后勤组层层转交，每经手一次就多一层延迟。而 RDMA（Remote Direct Memory Access，远程直接内存访问）完全改变了这个流程：它让 GPU 显存里的数据直接跨越网络写入对端 GPU 显存，全程绕开 CPU 和操作系统内核。

在分布式训练中，RDMA 的意义相当于乐手之间直接递谱，无需指挥台转手。RCCL 在检测到支持 RoCE/InfiniBand 的 AMD 集群时，会优先启用 RDMA 传输，并配合 GPU Direct 技术，让数据在 GPU 显存与网卡之间直接 DMA 搬运，彻底解除 CPU 这个“后勤瓶颈”。对千卡规模的 AllReduce 而言，这意味着每轮梯度同步的延迟可以从毫秒级降至微秒级。

RDMA 的有效带宽可以用下面的公式理解：

在 AMD 平台上，RCCL 对 RDMA 的支持让跨节点通信的带宽利用率大幅提升，通常能达到传统 TCP 方案的数倍甚至一个数量级以上。这正是它能够在超大规模训练中承担“指挥”角色的底气所在。

Beff=DTsetup+D/Bpeak\displaystyle B_{\text{eff}} = \frac{D}{T_{\text{setup}} + D / B_{\text{peak}}}
  1. 传输总耗时一次 RDMA 传输的总时间由两部分组成：固定的建立时间 \(T_{\text{setup}}\)（连接建立、内存注册等）和纯搬运时间 \(D/B_{\text{peak}}\)。
    Ttotal=Tsetup+DBpeak\displaystyle T_{\text{total}} = T_{\text{setup}} + \frac{D}{B_{\text{peak}}}
  2. 有效带宽定义有效带宽 \(B_{\text{eff}}\) 等于实际传输的数据量 \(D\) 除以总耗时。
    Beff=DTtotal\displaystyle B_{\text{eff}} = \frac{D}{T_{\text{total}}}
  3. 代入合并把总耗时表达式代回，就得到了最终公式。当 \(D\) 很大时，\(\frac{D}{B_{\text{peak}}}\) 占主导，有效带宽逼近峰值带宽；当 \(D\) 很小时，固定开销 \(T_{\text{setup}}\) 占主导，这也是为什么要用“大块数据”做通信，而不是一次传一点点。
    Beff=DTsetup+D/Bpeak\displaystyle B_{\text{eff}} = \frac{D}{T_{\text{setup}} + D / B_{\text{peak}}}

NCCL兼容API——国际通用的五线谱

乐谱如果只有本国音乐家能看懂，就难以跨国巡演。NCCL 是分布式训练领域事实上的标准，几乎所有大模型训练框架都围绕它的 API 编写。为此，ROCm 为 RCCL 提供了一整套NCCL 兼容层：绝大多数 NCCL API 在 RCCL 中都有对应的实现，函数名几乎一致，参数含义完全相同。

迁移 NCCL 代码到 AMD 平台时，通常只需要做三步改动：第一，把 cudaStream_t 替换为 hipStream_t，因为 ROCm 的设备抽象层是 HIP；第二，头文件由 nccl.h 调整为 rccl.h；第三，链接库从 libnccl.so 换为 librccl.so。而核心通信调用，比如 ncclCommInitRank 和 ncclAllReduce，在兼容层下可以原样保留，甚至 RCCL 会直接提供 nccl*.h 头文件以承接存量代码。

这种“五线谱标准化”的价值，体现在 AI 工程师可以把在 NVIDIA 集群上打磨成熟的分布式训练代码，低成本移植到 AMD 或者国产生态平台上。无论是 PyTorch 的 torch.distributed 还是更底层的自定义通信逻辑，迁移后都能快速复用多年积累的工程经验。此外，RCCL 支持与 NCCL 类似的环境变量调优手段，例如开关 RDMA、设置超时重试、限定使用的网络设备等，方便工程师在真实集群上做性能诊断。

当然，兼容不等于完全一致。RCCL 的内部实现——包括拓扑探测算法、路由调度策略和针对 Infinity Fabric 的底层优化——都是 AMD 根据自身硬件特性的独立实现。工程师在迁移后，仍需要通过 RCCL 提供的日志与计数器工具验证通信链路是否健康，就像指挥在新剧场排练时，也要亲自确认每个乐手的位置和传谱路线是否畅通。

AI 应用场景

大语言模型分布式训练中的梯度同步

阶段：模型训练

解决的问题：在大模型训练中，数据并行是最常见的策略，每个 GPU 持有完整模型副本和不同的数据批次。传统单机串行方式无法完成梯度同步，而朴素的全连接通信方式在 GPU 数量增多时通信量呈平方级爆炸。RCCL 的 Ring AllReduce 让通信量保持恒定，并且通过 RDMA 和拓扑感知把梯度同步延迟降到最低。

具体案例：一个百亿参数的 LLM 在 64 张 AMD Instinct GPU 集群上训练。每完成一个 batch 的正向与反向传播，64 个 GPU 各自算出一份梯度，RCCL 通过 2×(64-1) 轮环形通信完成梯度归约与广播，全程只需几十毫秒，确保通信不成为训练瓶颈。工程师用 ROCR_VISIBLE_DEVICES 和 RCCL 日志验证通信组状态，精确定位慢节点。

多机多卡并行推理中的张量并行通信

阶段：模型推理/部署

解决的问题：当单卡放不下完整模型时，需要把模型切分到多张 GPU 上，每层前向传播都需要跨卡交换中间激活值。传统 CPU 转发的传输方式延迟高、吞吐低，无法满足在线推理的时延要求。RCCL 的 AllGather 和 Broadcast 原语配合 RDMA，可以在微秒级完成跨卡激活值同步。

具体案例：在 AMD 平台上用 vLLM 或类 TensorRT-LLM 的推理引擎部署 70B 规模模型，4 张 GPU 做张量并行。每层 Attention 计算完成后，需要 AllGather 把分散在各个 GPU 上的 KV 缓存片段汇总。RCCL 通过拓扑感知选择 PCIe 交换机下的最优路径，使 token 生成吞吐从单卡的 500 tokens/s 提升到接近 1800 tokens/s。

从NCCL集群迁移到AMD/国产GPU集群

阶段：工程部署/平台迁移

解决的问题：许多团队的分布式训练代码深度依赖 NCCL，直接更换硬件平台意味着重写通信层，成本极高。RCCL 的 NCCL 兼容 API 让迁移变得平滑，通信层代码几乎零改动。

具体案例：某团队原本在 NVIDIA A100 集群上使用 torch.distributed 训练多模态模型，迁移到 AMD Instinct MI250 集群时，只需将 PyTorch 换成 ROCm 版本，底层自动链接 librccl。代码中的 ncclCommInitRank、ncclAllReduce 等调用在兼容层下直接工作，唯一改动是把 cudaStream_t 换成 hipStream_t，整个迁移在一周内完成，训练性能与原先持平。

Python 演示

python48 行
import numpy as np  def ring_allreduce(gpus):    """模拟RCCL中的Ring AllReduce (SUM再取平均)."""    world_size = len(gpus)    chunks = [np.array_split(np.array(g, dtype=float), world_size)              for g in gpus]     # 阶段一: scatter-reduce, 梯度分块沿环累加    for k in range(world_size - 1):        old = [list(c) for c in chunks]        for i in range(world_size):            recv_idx = (i - k - 2) % world_size            src = (i - 1) % world_size            chunks[i][recv_idx] = old[i][recv_idx] + old[src][recv_idx]     # 阶段二: allgather, 完整聚合值沿环广播    for k in range(world_size - 1):        old = [list(c) for c in chunks]        for i in range(world_size):            recv_idx = (i - k - 1) % world_size            src = (i - 1) % world_size            chunks[i][recv_idx] = old[src][recv_idx]     return [np.concatenate(c) / world_size for c in chunks]  def main():    world_size = 4    gpus = [        [1.0, 2.0, 3.0, 4.0],        [5.0, 6.0, 7.0, 8.0],        [9.0, 10.0, 11.0, 12.0],        [13.0, 14.0, 15.0, 16.0],    ]    results = ring_allreduce(gpus)    for rank, res in enumerate(results):        print("GPU{} 同步后梯度: {}".format(rank, res))     expect = np.mean(gpus, axis=0)    for rank, res in enumerate(results):        assert np.allclose(res, expect), "GPU{} 结果错误".format(rank)    print("验证通过: 所有GPU梯度与全局平均一致")  if __name__ == "__main__":    main()
目的：用纯 Python 和 NumPy 模拟 RCCL 的核心算法 Ring AllReduce，展示 4 个 GPU 如何通过“分块累加 + 环形广播”获得一致的梯度平均值。无需真实 AMD GPU 即可运行。
  1. chunks = [np.array_split(np.array(g, dtype=float), world_size) for g in gpus]把每个 GPU 的梯度向量切成 world_size 个小块，相当于把总谱拆成小节分给各乐手。
  2. old = [list(c) for c in chunks]做“同步快照”。真实通信中所有 GPU 同时收发，快照让模拟不受执行顺序影响。
  3. chunks[i][recv_idx] = old[i][recv_idx] + old[src][recv_idx]从环形前驱收到分块，累加到自己的对应块，这是 scatter-reduce 阶段的核心。
  4. chunks[i][recv_idx] = old[src][recv_idx]直接用已完整的聚合块覆盖本地块，这是 allgather 阶段的传递逻辑。
  5. return [np.concatenate(c) / world_size for c in chunks]把分块拼回完整向量并除以 GPU 数，得到全局平均梯度。

常见误区

误区RCCL 和 NCCL 代码完全一样，AMD 直接复制了 NVIDIA 的实现，只是改了个名。

正解RCCL 是 AMD 基于 ROCm 生态独立开发的集合通信库。它只在 API 层面与 NCCL 兼容，内部的路由调度、拓扑探测和底层传输都针对 AMD 的 Infinity Fabric 与 ROCm 驱动做了专门优化。就像两个指挥家读同一份总谱，但各自的处理手法截然不同。

为何常见：两者 API 高度相似，且官方文档经常强调“兼容 NCCL”，让人误以为底层实现也是复制的。

误区AllReduce 就是所有人直接把数据传给所有人，GPU 数量越多通信越慢，通信量随 GPU 数平方增长。

正解Ring AllReduce 采用的是环形拓扑，每个 GPU 只与前后两个邻居通信。数据分块后沿环流动累加，再沿环广播回每个 GPU，总通信量并不随 GPU 数量增加而爆炸。这正是它能扩展到千卡规模的关键。

为何常见：从“汇总”的直觉出发，容易认为所有人直接交换数据是最自然的实现，忽略了环形流水线这种工程上的精巧优化。

误区RDMA 是网络文件存储技术，用来快速读取 NAS 或对象存储上的数据集。

正解RDMA（远程直接内存访问）是一种网络传输机制，核心是让数据从一端的内存或显存直接写入另一端的内存或显存，绕过操作系统协议栈和 CPU 拷贝。在 RCCL 中它用于 GPU 之间的梯度直传，与文件存储完全无关。类比地说，RDMA 是乐手之间直接递谱，不是去仓库取谱。

为何常见：RDMA 的“远程”和“直接访问”字眼容易让人联想到网络磁盘共享。

误区NCCL 代码是跨平台的，拿到 AMD 机器上重新编译链接就能运行，不需要任何改动。

正解即便 API 兼容，底层仍有硬性依赖：NCCL 依赖 CUDA 驱动和 cudaStream_t，而 AMD 平台需要 ROCm 环境、hipStream_t 头文件以及 librccl 链接库。PyTorch 等框架能在高层掩盖差异，但自研 C++ 通信逻辑仍需手动切换相关类型。

为何常见：AI 框架层把平台差异屏蔽得太好，让工程师误以为驱动和通信库也自动跨平台兼容。

面试题

Q1. RCCL 在 AMD ROCm 生态中的主要作用是什么？

单选题 · easy

  • A.负责 GPU 内核的编译优化
  • B.提供多 GPU 集合通信能力← 正确答案
  • C.管理 GPU 显存的分配回收
  • D.控制 GPU 的散热与功耗

答案：B。RCCL 的定位是集合通信库，负责让多块 GPU 高效交换梯度。内核编译优化是编译器的工作，显存管理归驱动和运行时，散热控制更与通信库无关。

Q2. 下列哪个操作是集合通信原语？

单选题 · easy

  • A.在 GPU 上动态分配显存
  • B.让所有 GPU 交换梯度并达成一致← 正确答案
  • C.将训练数据从磁盘读入内存
  • D.在屏幕上绘制训练损失曲线

答案：B。AllReduce 这类集合通信原语的目标是让所有 GPU 获得一致的全局结果。分配显存是内存管理，读盘是 I/O，绘图是可视化，都与多卡协作无关。

Q3. 下列选项中，属于 RCCL 集合通信原语的是？

单选题 · easy

  • A.AllReduce 梯度全局汇总← 正确答案
  • B.AllGather 数据全收集← 正确答案
  • C.Broadcast 数据广播← 正确答案
  • D.RDMA 内存直通技术

答案：ABC。AllReduce、AllGather、Broadcast 都是集合通信原语，RDMA 是底层传输技术，不是通信模式本身。

Q4. 在 N 个 GPU 组成的 Ring AllReduce 中，完整执行全部通信需要多少轮？

单选题 · mid

  • A.N 轮即可完成
  • B.需要 2×(N-1) 轮← 正确答案
  • C.需要 N×(N-1) 轮
  • D.需要 2×N 轮

答案：B。Ring AllReduce 分两个阶段：scatter-reduce 需要 N-1 轮，allgather 也需要 N-1 轮，总计 2(N-1) 轮。选项 C 是全连接两两通信的轮数，D 则高估了一倍。

Q5. RCCL 通信组中 rank 的含义是什么？

单选题 · mid

  • A.通信组中每个参与者的编号← 正确答案
  • B.GPU 的默认运行频率等级
  • C.神经网络中全连接层数量
  • D.网络数据包的重传次数

答案：A。rank 是通信组内每个 GPU 的唯一编号，类似乐团乐手的座席号。频率等级、网络层数、重传次数都与 rank 无关。

Q6. RDMA 相比传统网络通信的核心优势是什么？

单选题 · mid

  • A.让数据绕过 CPU 与内核直达远端内存← 正确答案
  • B.让 CPU 可以更高频率地超频运行
  • C.完全不需要任何物理网卡设备
  • D.将多个 GPU 合并为一块虚拟显存

答案：A。RDMA 的核心在于绕过 CPU 和操作系统内核，让数据从一端内存直接写入对端内存，降低延迟和 CPU 占用。它仍然需要网卡（如 InfiniBand/RoCE），也不是显存虚拟化技术。

Q7. 迁移 NCCL 代码到 RCCL 时，下列哪些说法正确？

多选题 · mid

  • A.ncclCommInitRank 可初始化通信组← 正确答案
  • B.ncclAllReduce 可完成梯度汇总← 正确答案
  • C.cudaMalloc 负责分配 GPU 显存
  • D.cv2.imread 读取训练数据集

答案：AB。在 RCCL 的兼容层下，NCCL 的通信 API 大多可继续使用。cudaMalloc 是 CUDA 显存分配接口并非 NCCL 通信 API，cv2.imread 是 OpenCV 的图像读取函数，与通信无关。

Q8. RCCL 拓扑感知优化的核心目标是什么？

单选题 · hard

  • A.提高 GPU 核心运行频率
  • B.按硬件布局选择最优路径← 正确答案
  • C.增加神经网络层数
  • D.降低分布式训练的批次

答案：B。拓扑感知是指 RCCL 探测 GPU 物理连接结构（同片、跨片、跨节点），据此选择延迟最低、带宽最大的传输路径。这与频率、网络层数、批次大小无关。

Q9. 关于拓扑感知与链路层级，下列说法正确的有？

多选题 · hard

  • A.Infinity Fabric 是 AMD 高速互联技术← 正确答案
  • B.拓扑感知让 RCCL 避开慢速链路← 正确答案
  • C.所有通信链路带宽完全相同
  • D.跨节点通信通常比节点内更慢← 正确答案

答案：ABD。Infinity Fabric 是 AMD 的片上/片间互联技术，拓扑感知的目的就是为通信选择最优路径。同节点内链路带宽远高于跨节点网络，三层链路带宽差异显著，因此选项 C 错误，D 正确。

Q10. 在 N=4 的 Ring AllReduce 中，scatter-reduce 阶段结束后正确的状态是？

单选题 · extreme

  • A.每个 GPU 都拥有全部 4 块完整聚合值
  • B.每个 GPU 拥有其中一块的完整聚合值← 正确答案
  • C.所有梯度数据仍只存在于 GPU0 上
  • D.每个 GPU 只保留自己原始的梯度块

答案：B。scatter-reduce 的目标是让每个 GPU 各持有一块的全局聚合结果。全部块都完整是 allgather 结束后的状态，所有数据仍在 GPU0 是朴素 Reduce 的模式，只保留原始块则说明通信尚未发生。