L1.2 节点内与跨节点互联拓扑

三维坐标　layer: L1（计算与编排）｜level: Senior｜pillar: 硬件架构

上一篇我们把单卡内部（HBM、SM、Tensor Core）讲透了。本文把视角拉到多卡与多机：当一个模型大到单卡装不下、单机训不动时，GPU 之间怎么连、机器之间怎么连，就直接决定了你的 All-Reduce 跑多快、千卡集群的扩展效率（scaling efficiency）能不能守住。这是「通信墙」从理论走向工程的第一现场。

学习目标

前置知识：读过 L0 全层（尤其 L0.2 三大物理墙，知道「通信墙」与 scaling efficiency 的概念）；读过 L1.1 单卡微架构（知道单卡内部 HBM/SM/Tensor Core，理解「单卡装不下就要切多卡」的动机）；知道 All-Reduce 是分布式训练里的梯度同步操作即可，无需 NCCL/RDMA 实战经验。
学完产出：① 能画出单节点 8 卡的 NVSwitch 全连接拓扑，并说清它相比 PCIe 树形「为什么 8 卡能近线性扩展」；② 能用「单卡双向带宽」这把尺子，排出 PCIe / NVLink 各代 / HCCS / UALink 的数量级梯队，并指出 scale-up 带宽每代翻倍的趋势；③ 能讲清 RDMA「绕内核、绕 CPU、零拷贝」的本质，并对比 InfiniBand 与 RoCE v2 在「无损语义靠谁兜底」上的根本分野；④ 能解释 PFC（硬刹车）与 ECN/DCQCN（软刹车）各自的作用与风险，说清「为什么千卡 RoCE 集群的生死线是拥塞控制」；⑤ 亲手用 nccl-tests（或 CPU 上 gloo）跑通一次 All-Reduce，量化「节点内 NVLink 带宽 vs 跨节点带宽」近 20 倍的木桶落差。
阅读姿势：盯住一条主线——「互联拓扑的一切设计，都是为了把那块最短的『跨节点带宽』木桶板尽量补高」。无论是节点内拼带宽密度（NVLink/NVSwitch），还是节点间拼无损与规模（IB/RoCE + 拥塞控制），本质都在和同一堵「通信墙」搏斗：算力按卡数线性涨，通信开销却超线性膨胀。

背景与现状

大模型训练的本质是一场 「算力 × 通信」的协同战争。当你把一个模型切到 N 张卡上（数据并行 DP / 张量并行 TP / 流水并行 PP），每个训练 step 结束都要做一次 梯度同步（All-Reduce） 或激活交换。这一步不产生任何 FLOPS，却必须等所有卡的数据搬运完成——它就是分布式训练里那块最短的木桶板。

互联拓扑要解决的核心矛盾是：计算能力按卡数线性增长，但通信开销随规模超线性膨胀。于是整个产业沿两条战线演进：

节点内（scale-up，纵向扩展）：让一台机器里的 8 张卡像「一张大卡」。代表是 NVIDIA 的 NVLink / NVSwitch，H100 时代单卡双向带宽已达 ~900 GB/s，到 Blackwell 的 NVLink 5 提升到 ~1.8 TB/s，Rubin 规划的 NVLink 6 再翻倍（~3.6 TB/s 级），远超 PCIe Gen5 的 ~128 GB/s。华为昇腾用 HCCS 走同一思路。值得注意的是，2025 年起出现了 scale-up 互联的开放阵营：NVIDIA 推出 NVLink Fusion（Computex 2025，把 NVLink 开放给第三方 CPU/ASIC），而 AMD、Google、Intel、Broadcom 等联合推动 UALink 1.0（2025 年 4 月发布规范，200 GT/s/lane，最多连 1024 个加速器）对标 NVLink。
节点间（scale-out，横向扩展）：让成百上千台机器组成集群。代表是 InfiniBand（IB） 与跑在以太网上的 RoCE v2，靠 RDMA（远程直接内存访问） 绕过内核做零拷贝传输，单端口从 NDR 400 Gb/s 升级到 XDR 800 Gb/s（Quantum-X800 平台，随 Blackwell 部署），下一代 GDR 1.6 Tb/s 在路上。以太网侧，Ultra Ethernet Consortium（UEC）于 2025 年 6 月发布 1.0 规范，专为 AI/HPC 重构以太网传输（包级负载均衡、改进拥塞控制），2026 年进入产品落地早期。

业界信号（截至 2026 年中）：scale-up 的边界被一路推到机柜级——GB200/GB300 NVL72 用第五代 NVSwitch 把 72 颗 Blackwell GPU 连成「~130 TB/s 全互联域」，对外像一台超级 GPU；华为 CloudMatrix CM384 用光互联把 384 颗昇腾 910C 连成超节点对标 NVL72；NVIDIA 规划的 Vera Rubin NVL144（2026 H2）则把这一逻辑再推进一代。与此同时，互联从「单厂封闭」走向「开放标准之争」：NVLink Fusion vs UALink、InfiniBand vs Ultra Ethernet，正是 2025–2026 数据中心网络最关键的两条战线。

一句话定位：节点内拼带宽密度，节点间拼无损与规模，而两者的带宽鸿沟（900 GB/s vs 50 GB/s，差近 20 倍），就是后文所有拓扑设计与拥塞控制的根源动机。

原理与架构

2.1 节点内：NVLink / NVSwitch 全连接与带宽演进

PCIe 是「总线 + 树形」结构，多卡共享带宽、且必须经 CPU 中转，做 8 卡 All-Reduce 时会严重抢占。NVLink 则是 GPU 之间的点对点高速私链，NVSwitch 进一步把它做成一颗交换芯片，让节点内任意两卡都享有全互联、非阻塞的对等带宽。

带宽演进与横向对比（单卡双向聚合带宽）：

互联方案	代际 / 平台	单卡双向带宽	关键特征
PCIe Gen5 ×16	通用	~128 GB/s	共享总线、经 CPU、做基线
NVLink 3.0	A100	~600 GB/s	12 条 link × 50 GB/s
NVLink 4.0	H100	~900 GB/s	18 条 link，配 NVSwitch3
NVLink 5.0	B200 / GB200 / GB300 (Blackwell)	~1.8 TB/s	NVL72 机柜级全互联 ~130 TB/s
NVLink 6.0（路线图）	Rubin VR200 (2026 H2)	~3.6 TB/s 级	随 Rubin 推出，带宽较 NVLink 5 翻倍
开放标准 UALink 1.0	多厂（AMD/Google/Intel 等）	200 GT/s per lane	2025 规范发布，对标 NVLink 的开放 scale-up
昇腾 HCCS	昇腾 910B/910C	~392 GB/s 起（节点内）	华为自研，CM384 用光互联做超节点级 scale-up

需要强调的是：NVSwitch 的价值不只是「快」，而是让 8 卡的 All-Reduce 拓扑无关——无论 Ring 还是 Tree 算法，任意卡对都有满带宽对等链路，避免了 PCIe 树形结构里的「热点链路」。这正是单机 8 卡能近乎线性扩展的硬件底座。

2.2 跨节点：InfiniBand vs RoCE v2 协议栈

跨节点的关键技术是 RDMA（Remote Direct Memory Access）：网卡（NIC）直接读写远端主机内存，绕过操作系统内核、绕过 CPU、零拷贝（zero-copy），把端到端延迟压到微秒级。配合 GPUDirect RDMA，数据更能从本地 GPU 显存直达远端 GPU 显存，全程不经 CPU 内存中转。

RDMA 有两条工程路线，差异全在「靠什么承载无损语义」：

维度	InfiniBand (XDR)	RoCE v2 / Ultra Ethernet
物理网络	专用 IB 交换机/线缆（Quantum-X800）	标准以太网交换机（Spectrum-X 等）
单端口带宽	800 Gb/s（XDR），1.6T（GDR）在路上	400 / 800 Gb/s（取决于网卡/交换机）
无损保证	链路层原生信用流控，天生无损	依赖 PFC + ECN；UEC 1.0（2025.06）改进拥塞控制与包级负载均衡
上手与运维	开箱无损、调参少，但生态封闭、贵	复用以太网生态、便宜，但调不好就丢包雪崩
典型场景	大厂超算/万卡训练首选	成本敏感、已有以太网基建；UEC 推动以太网逐步追平无损能力

核心在于：IB 把「无损」做在了协议栈底层硬件里，RoCE v2 则把无损责任上移到了运维——它本质是「在会丢包的以太网上，用 PFC/ECN 拼出一个不丢包的假象」。这就是 2.3 节拥塞控制成为千卡 RoCE 集群「生死线」的原因。

2.3 拥塞控制：PFC / ECN 为何是千卡集群的生死线

RDMA 的 GBN（Go-Back-N） 重传机制对丢包极其敏感：一旦丢一个包，可能要回退重传整批，吞吐断崖式下跌。所以跨节点网络必须无损（lossless）。RoCE v2 用两件武器拼出无损：

PFC（Priority Flow Control，优先级流控，L2 逆压）：当交换机某队列快满时，向上游发 PAUSE 帧，让上游「先别发了」。这是硬刹车——快、但会逆压传播，处理不当引发 PFC 风暴 / 死锁（deadlock），让整片网络停摆。
ECN（Explicit Congestion Notification，显式拥塞通知，L3 端到端）：交换机检测到拥塞苗头时，不丢包，而是给 IP 包打标记；接收端把标记回传给发送端，发送端主动降速（DCQCN 算法）。这是软刹车——更平滑，是主力调速手段。

木桶效应：节点内 NVLink ~900 GB/s，跨节点 IB/RoCE 单端口仅 ~50 GB/s——相差近 20 倍。当 All-Reduce 跨越节点边界时，整个集合通信的有效带宽被最慢的跨节点链路钳制，这就是「跨节点带宽是 All-Reduce 的木桶板」。因此工程上要做两件事：① 用 Rail-optimized 拓扑 + 每卡独享网卡，让跨节点流量并行铺开；② 死守 PFC/ECN 不丢包，因为千卡规模下哪怕 0.01% 丢包率都会让重传开销吞掉扩展效率。NCCL 的 NCCL_ALGO（Ring/Tree）与 NCCL_IB_* 参数，本质都是在围绕这条木桶板做优化。

动手实践：极简代码实操

实验目标：用 NCCL All-Reduce benchmark 亲手测出「多卡 / 多机」的通信带宽与延迟，直观看到 NVLink 卡内带宽与跨节点带宽的数量级落差。产出物：一张 all_reduce_perf 的带宽-消息大小曲线 + 一段对照说明。无 GPU 时用 PyTorch gloo backend 在 CPU 上跑通 All-Reduce 语义。

3.1 NVIDIA GPU 路径：nccl-tests

# 前置：已装 CUDA、NCCL（随 CUDA Toolkit 或单独安装）、MPI（多机需要）
git clone https://github.com/NVIDIA/nccl-tests.git
cd nccl-tests
# 单机：指向系统 CUDA / NCCL
make CUDA_HOME=/usr/local/cuda NCCL_HOME=/usr/lib/x86_64-linux-gnu
# 若 NCCL 在自定义路径，相应修改 NCCL_HOME

# 单机 8 卡 all_reduce：消息从 8B 扫到 8GB，每档跑 20 次取均值
./build/all_reduce_perf -b 8 -e 8G -f 2 -g 8

# 关注输出中的 busbw（Bus Bandwidth, GB/s）列——它扣除了算法冗余，
# 是衡量「实际打满了多少互联带宽」的黄金指标。

# 多机（2 节点 × 8 卡 = 16）：用 MPI 拉起，强制走 IB，打开调试日志
mpirun -np 16 -H node1:8,node2:8 \
  -x NCCL_DEBUG=INFO \
  -x NCCL_IB_HCA=mlx5 \
  -x NCCL_IB_DISABLE=0 \
  ./build/all_reduce_perf -b 8 -e 8G -f 2 -g 1
# 对比单机 busbw 与多机 busbw，落差即「跨节点木桶板」的真实代价。

3.2 Mac / CPU 替代方案：torch.distributed + gloo

无 GPU 也能理解 All-Reduce 的语义与计时方法。下面用 gloo backend 在 CPU 多进程上跑小规模 All-Reduce：

# allreduce_gloo.py —— CPU 上跑通 All-Reduce 语义与计时
import os, time
import torch
import torch.distributed as dist
import torch.multiprocessing as mp

def worker(rank, world_size):
    os.environ["MASTER_ADDR"] = "127.0.0.1"
    os.environ["MASTER_PORT"] = "29500"
    dist.init_process_group("gloo", rank=rank, world_size=world_size)

    # 每个 rank 持有全 1 向量；All-Reduce(SUM) 后每个 rank 都应得到 world_size
    x = torch.ones(1_000_000)

    dist.barrier()
    t0 = time.perf_counter()
    for _ in range(50):
        dist.all_reduce(x, op=dist.ReduceOp.SUM)
    dt = (time.perf_counter() - t0) / 50

    if rank == 0:
        # 50 次累加后值会变化，这里只验证首次语义：打印理论 vs 实际
        print(f"[rank0] world_size={world_size} 单次 all_reduce 平均耗时 {dt*1e3:.3f} ms")
        print(f"[rank0] 校验首元素经 1 次 SUM 应为 {world_size}（见下方单次验证）")
    dist.destroy_process_group()

if __name__ == "__main__":
    ws = 4  # CPU 上模拟 4 个 rank
    mp.spawn(worker, args=(ws,), nprocs=ws, join=True)

python allreduce_gloo.py
# 预期：打印每次 all_reduce 的平均耗时；rank0 看到 world_size=4。
# 目的不是测带宽，而是理解：All-Reduce(SUM) 让每个 rank 都拿到全局求和结果——
# 这正是分布式训练里「梯度同步」的数学本质。

踩坑预警 (Gotchas)

只看 algbw 不看 busbw：nccl-tests 输出里 algbw 含算法冗余，busbw 才反映互联链路真实利用率。比较拓扑/参数优劣，认准 busbw。
多机不走 IB 却以为走了：忘记 NCCL_IB_DISABLE=0 或没设 NCCL_IB_HCA，NCCL 可能悄悄回退到 TCP/以太网 socket，带宽暴跌还查不出原因。务必先 NCCL_DEBUG=INFO 看启动日志里选了哪条 transport（NVLink / IB / SHM / NET）。
小消息测的是延迟不是带宽：-b 8（8 字节）那档反映的是延迟下限，大消息（GB 级）才打满带宽。看带宽曲线要看大消息端的饱和值。
gloo 不支持 GPU 张量做 NCCL 那套：CPU 替代实验只为理解语义，不要拿它的耗时去推断真实集群带宽——两者不在一个数量级。
PFC 配错比不配更糟：真机 RoCE 环境若 PFC 优先级与交换机不一致，会触发 PAUSE 风暴让网络僵死。生产环境改 PFC/ECN 前务必有回滚预案。

深入思考

下面三题每题先给题干，再用 <details> 折叠一份图文并茂的参考答案。建议先合上答案自己想 3 分钟，再展开对照。

思考题 1：木桶定位

某 64 卡（8 节点 × 8 卡）训练任务，单机内 8 卡 All-Reduce 的 busbw 接近 700 GB/s，但 64 卡全局 All-Reduce 的 busbw 只有 ~40 GB/s。结合 2.1 / 2.3 节的「带宽鸿沟」，请说明这 ~17 倍的落差主要发生在哪一跳，以及为什么用 Hierarchical All-Reduce（先节点内 NVLink 规约、再节点间 IB 规约） 能缓解，而不能消除这块木桶板？

展开参考答案（含分层 All-Reduce 因果链图 + 算一遍）

结论：落差几乎全部发生在「跨出节点的那一跳」——节点内走 ~900 GB/s 的 NVLink，节点间却只有 ~50 GB/s 量级的 IB/RoCE 单端口；全局 All-Reduce 一旦跨越节点边界，有效带宽就被这块最慢的板子钳死。Hierarchical All-Reduce 把绝大部分数据量压在节点内 NVLink 上消化，只让「每节点一份规约结果」跨节点传，从而大幅减少跨节点流量，但只要还有数据必须出节点，木桶板就依然存在——能补高，不能消除。

用具体数字算一遍（数量级估算，呼应 2.3 节「节点内 ~900 GB/s vs 跨节点 ~50 GB/s」）：

落差的根因：节点内 NVLink 双向 ~900 GB/s，跨节点 IB 单端口 ~50 GB/s 量级，两者差 ~18 倍——这正好对应观察到的 700 → 40（~17 倍）。只要 All-Reduce 的数据必须跨节点，全局有效带宽就被跨节点链路钳制，与节点内多快无关。
朴素 Ring 的问题：Ring All-Reduce 把所有卡串成一个环，环上相邻两卡的链路只要有一段是跨节点的，整条环的吞吐就被这段慢链路拖住——64 卡的环里有大量「跨节点边」，于是全局 busbw 趴在 ~40 GB/s。
分层改造的收益：先在节点内 8 卡用 NVLink 规约（几乎免费），跨节点只需传「8 个节点各一份」的规约结果——跨节点数据量降到约 1/8，最后再节点内 broadcast 回各卡。跨节点搬运量大减，全局 busbw 可显著回升。
为什么不能消除：第 ② 步那次「8 节点跨节点 All-Reduce」仍然只能跑在 ~50 GB/s 的 IB 上。数据量减少了，但单位带宽的下限没变——木桶板被补高（缩短了出节点的数据量），却没被拆掉。这也是为什么超大规模训练还要叠加 Rail-optimized 拓扑、每卡独享网卡、梯度压缩等手段继续补板。

思考题 2：IB vs RoCE 选型

你要为一个 512 卡集群选互联方案，预算紧张但团队有成熟的以太网运维能力。选 InfiniBand 还是 RoCE v2？请从 无损保证的责任边界（硬件 vs 运维）、PFC 死锁风险、长期 TCO 三个角度给出决策（呼应 2.2 / 2.3 节），并说明若选 RoCE，你会如何用 ECN/DCQCN 守住不丢包。

展开参考答案（含选型决策树图 + 对比表）

结论：在「预算紧张 + 有成熟以太网运维能力」这个特定约束下，RoCE v2 是更划算的选择——它复用以太网生态、单价更低，而无损语义所需的 PFC/ECN 调优，正好压在你团队已有的能力边界内。若团队缺乏 RDMA 网络运维经验、或追求开箱即用的确定性，则应选 InfiniBand：它把无损做进了硬件，省去调参，代价是封闭与更高单价。

三维度决策对比：

维度	InfiniBand (XDR)	RoCE v2
无损责任边界	链路层原生信用流控，硬件兜底，运维几乎不用管无损	靠 PFC + ECN，无损责任上移到运维——本质是在会丢包的以太网上拼出不丢包假象
PFC 死锁风险	几乎无需依赖 PFC，无 PFC 风暴之忧	真实存在：PFC 优先级配错会逆压传播，引发 PAUSE 风暴/死锁让整片网络僵死
长期 TCO	专用交换机/线缆，单价高、生态封闭，但运维省心	复用以太网生态、设备便宜、可叠加 UEC（2025.06 1.0）改进；省下的钱要部分回吐到运维与调优投入

512 卡为何选 RoCE：512 卡属于「中等规模」，远没到必须上 IB 的万卡级；而「预算紧张 + 以太网运维强」这两个条件，恰好让 RoCE 的两大短板（无损靠运维、PFC 风险）落在团队能 hold 住的范围内。TCO 上的硬件节省，足以覆盖额外的调优人力——这正是成本敏感型集群的典型选择。

若选 RoCE，怎么守住不丢包（呼应 2.3 节软/硬刹车）：

以 ECN/DCQCN 为主调速：交换机在队列水位上升的早期就打 ECN 标记，接收端回传、发送端按 DCQCN 平滑降速——把绝大多数拥塞在「软刹车」阶段化解，避免走到 PFC。
PFC 只做最后兜底：PFC PAUSE 是硬刹车，只在水位逼近溢出时触发；且要让 RDMA 流量走独立的无损优先级队列，与普通以太流量隔离。
全网 PFC 优先级严格一致：交换机、网卡两端的 PFC 优先级（PCP/DSCP 映射）必须统一，否则 PAUSE 帧错位会直接引爆风暴。
上线前压测 + 回滚预案：用 ib_write_bw 等工具压满带宽观察是否丢包，改 PFC/ECN 参数前务必有回滚方案——「PFC 配错比不配更糟」。

思考题 3：异构对标

把这套「节点内 scale-up + 节点间 scale-out」的拓扑认知迁移到华为昇腾平台（呼应 2.1 节的横向对比表）。HCCS 对应 NVLink/NVSwitch 的哪个角色？当昇腾集群跨节点时，它的 All-Reduce 木桶板与 NVIDIA 平台相比，瓶颈位置是否一致？为什么说「互联拓扑的认知是跨硬件平台可复用的系统观」？

展开参考答案（含跨平台拓扑映射对比图）

结论：HCCS 扮演的正是 NVLink/NVSwitch 在 NVIDIA 平台上的角色——昇腾的「节点内 scale-up 高速私链」；昇腾跨节点同样要走 RDMA（IB/RoCE）网络，所以它的 All-Reduce 木桶板与 NVIDIA 平台瓶颈位置完全一致**，都卡在「跨出节点的那一跳」。正因为这套「scale-up 拼带宽密度、scale-out 拼无损与规模」的二分结构与厂商无关，互联拓扑的认知才是跨硬件平台可复用的系统观。**

角色映射（呼应 2.1 节对比表）：

层次	NVIDIA	华为昇腾	共同本质
节点内 scale-up	NVLink + NVSwitch（~900 GB/s，NVL72 机柜级 ~130 TB/s）	HCCS（~392 GB/s 起，CM384 用光互联做超节点级 scale-up）	GPU/NPU 间点对点高速私链 + 交换，让节点内近线性扩展
节点间 scale-out	InfiniBand / RoCE（RDMA，~50 GB/s 量级单端口）	RoCE / IB（同样走 RDMA）	靠 RDMA 零拷贝跨机，带宽比节点内低一个量级

瓶颈位置为何一致：两个平台都遵循同一个物理现实——节点内私链带宽（数百 GB/s ~ TB/s）远高于跨节点网络带宽（数十 GB/s 量级）。HCCS 再快也快不过「机器之间还得过网卡和交换机」这道坎。所以无论 NVIDIA 还是昇腾，跨节点 All-Reduce 的木桶板都钉死在「scale-out 的那一跳」，缓解手段也一致：Hierarchical All-Reduce、Rail-optimized 拓扑、守无损。

为什么是可复用的系统观：互联设计的底层矛盾（算力线性涨、通信超线性膨胀）和应对结构（scale-up + scale-out 二分、用分层规约补木桶）不依赖任何具体厂商的产品名。换平台时变的只是「NVLink↔HCCS、NVSwitch↔光互联超节点、NCCL↔HCCL」这些名词，不变的是拓扑层级与瓶颈分析方法。掌握了这套思维框架，迁移到昇腾、TPU Pod、甚至未来的 UALink 阵营，你都能一眼定位木桶板在哪——这正是 L1.2 这层认知的长期价值（详见 L1.6 芯片横评与 L2 编排层）。

学习目标​

背景与现状​

原理与架构​

2.1 节点内：NVLink / NVSwitch 全连接与带宽演进​

2.2 跨节点：InfiniBand vs RoCE v2 协议栈​

2.3 拥塞控制：PFC / ECN 为何是千卡集群的生死线​

动手实践：极简代码实操​

3.1 NVIDIA GPU 路径：nccl-tests​

3.2 Mac / CPU 替代方案：torch.distributed + gloo​

踩坑预警 (Gotchas)​

深入思考​

思考题 1：木桶定位​

思考题 2：IB vs RoCE 选型​

思考题 3：异构对标​

延伸阅读​