文档预览

深浅色

第 6 周：NCCL/MCCL 算法、channel、多 rail 与性能测量 ​

对应原计划：plans/muxi-fabric-network-learning-plan.md 第 6 周。
相关工程：plans/muxi-fabric-probe.md 的 W1/W4，以及 project/lab-workspace/reports/rounds/muxi_fabric_final_20260719.md。
本章定位：理解通信库如何把 collective 变成具体网络流量，以及为什么 channel、rail、rank mapping 的 A/B 结果只能作为跨层行为证据。

0. 这一周到底学什么 ​

前几周你分别学了网络、RDMA、RoCE/QoS。第 6 周回到通信库：

MCCL/NCCL 如何决定谁和谁通信、用几条 channel、走哪些 HCA/rail、产生多少 flow？

学完你要能回答：

  • Ring、tree、hierarchical collective 的通信模式有什么区别？
  • channel、chunk、protocol 影响哪些层？
  • 多 rail 为什么不是自动 4 倍？
  • MCCL_IB_HCA、channel 环境变量、GPU 可见性改变的是哪些变量？
  • 为什么 matched-world 要拆 rank 数、节点数、每节点 GPU 数、每节点注入？
  • 为什么 W4 channel/rail/GPU A/B 没有稳定修复，不等于这些因素无关？

本周核心原则：

text
通信库变量通常跨层生效。
一次 A/B 改的不只是“算法”，也可能改了 QP、flow entropy、rail、GPU-HCA 亲和和同步尾部。

1. Collective 算法直觉 ​

1.1 Ring ​

Ring 把 rank 排成环：

text
r0 → r1 → r2 → r3 → r0

大消息 AllReduce 常见做法是把 tensor 切块，让 chunk 在环上分阶段流动。

优点：

text
每个 rank 每步收发量规则；
大消息带宽利用高；
实现相对简单。

风险：

text
步数随 rank 数增加；
一个慢边可能拖全局；
rank 顺序会决定哪些物理节点相邻；
跨 leaf/spine/rail 的路径组合可能不均。

1.2 Tree ​

Tree 把 rank 组织成树：

text
      r0
     /  \
   r1    r2
        /  \
      r3    r4

优点：

text
步数少；
小消息 latency 可能更好。

风险：

text
树根/内部节点可能成为热点；
树形是否贴合物理拓扑很重要；
某些上行或 rail 可能被集中使用。

1.3 Hierarchical ​

多 GPU 节点常用分层策略：

text
节点内 reduce
  ↓
节点间 collective
  ↓
节点内 broadcast/allgather

这样能利用机内高速互联，但也会让“每节点几张 GPU 参与”成为关键变量。

1.4 小 case：ring 顺序为什么影响网络 ​

假设 4 个 rank：

text
rank0, rank1 在 leaf A
rank2, rank3 在 leaf B

ring 顺序 1：

text
r0 → r1 → r2 → r3 → r0

跨 leaf 边：

text
r1→r2, r3→r0

ring 顺序 2：

text
r0 → r2 → r1 → r3 → r0

跨 leaf 边更多或分布不同。

所以 rank permutation 可能改变网络压力。没有实际 rank→host 映射，就无法解释。

2. Channel、chunk、protocol ​

2.1 chunk ​

大 tensor 会被切成 chunk：

text
tensor = chunk0 + chunk1 + chunk2 + ...

chunk 大小影响：

text
pipeline 深度；
每次传输大小；
GPU kernel 调度；
网络 packet 流形态。

2.2 channel ​

channel 是通信库内部并行车道：

text
chunk0 → channel0
chunk1 → channel1
chunk2 → channel2
chunk3 → channel3

channel 可能映射到不同 QP、不同 HCA、不同 rail，也可能多个 channel 共享同一资源。

2.3 protocol ​

不同消息大小和硬件条件下，通信库可能选不同 protocol。你不需要一开始记名字，但要知道它可能改变：

text
GPU kernel 行为；
CPU/proxy 行为；
buffering；
latency/throughput tradeoff；
网络注入模式。

2.4 小 case：channel 数变化的多重解释 ​

观察：

text
channel=4: p50 好，但 p99 差
channel=16: p50 稍差，但 p99 稳

可能解释：

text
更多 channel 分散 ECMP；
更多 channel 提高 RNIC 并发；
更多 channel 改变 HCA/rail 分配；
更多 channel 增加同步等待；
更多 channel 增加 CQ/proxy 压力；
背景流量刚好变化。

所以 channel A/B 必须结合 QP、HCA、rail、per-rank timeline 看。

3. 多 rail：为什么不是自动四倍 ​

Muxi 每节点有 4×200G xscale。直觉上：

text
4 rail × 24GB/s ≈ 96GB/s

但真实要满足很多条件：

text
通信库把流量均匀分到 4 rail；
GPU 到各 HCA 亲和相近；
每个 rail 的交换路径都健康；
ECMP 分布足够均匀；
接收端也能并行消化；
collective 提供足够并发；
没有单 GPU/单 rail 入口瓶颈；
QoS/queue 配置一致。

任何一项不满足，都可能非线性。

3.1 rail 掩码 A/B 能说明什么 ​

如果测试：

text
xscale_0
xscale_0,1
xscale_2,3
xscale_0,1,2,3

观察到差异，说明：

text
rail 选择影响行为。

但不能直接说明：

text
rail0 物理坏；
rail2/3 接到另一组 leaf；
四 rail 是四套独立 fabric；
某个 switch 有问题。

需要逐 rail bytes、host→switch port、GPU-HCA 亲和和复测稳定性。

4. matched-world：拆开 rank 数、节点数、每节点注入 ​

大规模 collective 里很多变量一起变：

text
world size 增加；
节点数增加；
每节点 GPU 数增加；
每节点注入增加；
覆盖更多 leaf/spine；
通信库算法阈值变化；
channel/QP 选择变化。

matched-world 的目标是一次只改变一个主要变量。

4.1 小 case：world=64 可以有多种形态 ​

text
8 节点 × 每节点 8 GPU = 64 rank
16 节点 × 每节点 4 GPU = 64 rank
32 节点 × 每节点 2 GPU = 64 rank
64 节点 × 每节点 1 GPU = 64 rank

world size 一样，但：

text
节点覆盖不同；
每节点注入不同；
机内/跨机比例不同；
rail 使用不同；
拓扑覆盖不同。

如果性能不同，不能只说“world=64 有问题”。

4.2 Muxi W1 的意义 ​

W1 matched-world 就是为了区分：

text
rank 数效应；
节点覆盖效应；
每节点 GPU 数/注入效应；
rail 和 mapping 效应。

5. 性能指标再辨析 ​

5.1 time ​

全体 rank 完成 collective 的时间，受最慢阶段约束。

5.2 alg_bw ​

用户语义数据量 / time。

5.3 bus_bw ​

按 collective 理论通信量折算，便于比较不同 collective，但不是物理链路速率。

5.4 per-rank min/max ​

如果所有 rank time 接近，不代表没有慢点，因为 collective 同步会让大家一起等。

5.5 p50/p99 ​

p50 描述典型情况，p99 描述尾部。大规模训练更怕 tail，因为慢一步会拖全局。

5.6 小 case：p50 变好但 p99 变坏 ​

这可能意味着：

text
大多数 iteration 更快；
但偶发 stall 更严重；
训练整体可能仍受 p99 影响。

所以不能只看平均。

6. 和 Muxi W4 结果的关系 ​

最终报告里 W4 做了：

text
channel A/B；
rail A/B；
GPU 物理集合/顺序 A/B；
rank block permutation。

结论不是“这些因素无关”，而是：

text
这些因素会影响行为；
但没有形成三块一致、可重复、超过预注册门槛的稳定缓解；
因此不能把它们写成单一根因或已修复路径。

这很重要。一个变量有影响，不等于它是根因；一个 A/B 没修复，也不等于它完全无关。

6.1 候选解释 ​

MCCL/本地软件映射仍是中等置信参与因素，因为：

text
channel 数和 GPU 集合能显著改变 p50/尾部；
变量透传和物理映射已证实；
但没有稳定恢复到目标带宽。

所以它应该继续作为候选层，而不是被完全排除。

7. 推荐阅读提炼 ​

7.1 NCCL Collective Operations ​

一句话 ​

它解释不同 collective 的语义和通信量。

抓哪个问题 ​

text
AllReduce、ReduceScatter、AllGather、Broadcast 为什么不能用同一个通信量直觉？

和 Muxi 的关系 ​

帮助你理解 alg_bw/bus_bw 和 AllReduce 分阶段。MCCL 具体算法仍需日志确认。

7.2 NCCL source / Demystifying NCCL ​

一句话 ​

帮助理解 channel、chunk、protocol、ring/tree 如何变成执行计划。

抓哪个问题 ​

text
为什么 channel 和 rank 顺序会改变网络流量形态？

不能照搬 ​

NCCL 的实现不是 MCCL 的实现。你要把它当成“该向 MCCL 问哪些问题”的框架。

7.3 SuperBench ​

一句话 ​

SuperBench 展示如何系统化做 GPU 集群 benchmark。

抓哪个问题 ​

text
为什么要从单机、P2P、incast、collective 多层建立基线？

和 Muxi 的关系 ​

Muxi 当前的 W0-W4 正是在建立多层证据链，而不是只看一个 AllReduce 数字。

8. 常见误判 ​

  • channel 越多越好。
  • 4 rail 就应该 4 倍。
  • AllReduce 慢一定是网络慢。
  • 单 pair 快就能反证通信库问题。
  • bus_bw 可以和 incast aggregate 直接比较。
  • GPU 顺序影响性能就说明某张 GPU 坏。
  • A/B 没达到修复门槛就说明该变量无关。
  • A/B 有变化就说明该变量是根因。

9. 本周任务设计 ​

9.1 任务 A：画 collective 到 flow 的映射 ​

画出：

text
AllReduce → algorithm → chunks → channels → QP/HCA/rail → RoCE flows

标出哪些环节你当前能观测，哪些需要厂商日志。

9.2 任务 B：matched-world 表 ​

设计：

text
world=64 的 8n8r / 16n4r / 32n2r / 64n1r

说明每种形态改变了哪些变量。

9.3 任务 C：rail A/B 辨析 ​

给定：

text
dual01 比 dual23 快
quad 比 dual01 快但不是两倍

列出至少 6 个可能原因，并说明要什么证据才能命名物理 rail 问题。

9.4 任务 D：channel A/B 结论边界 ​

写一段话说明：

text
channel 改变带宽，支持什么，不能证明什么。

10. 和 agent 讨论的问题模板 ​

10.1 collective 候选拆解 ​

text
请把这个 AllReduce 掉速拆成通信库算法、channel/QP、rank mapping、rail 使用、网络 fabric 五类候选。
每类列出需要固定的变量和可观察指标。

10.2 matched-world 设计 ​

text
请设计一个 matched-world 实验，分别控制 world size、节点数、每节点 GPU 数、rail 数和 channel 数，避免一次改变多个因素。

10.3 W4 结果解释 ​

text
请解释 channel/rail/GPU mapping A/B 没有稳定修复时，哪些候选被削弱，哪些仍保留为参与因素。
不要把“未修复”等同于“无关”。

11. 本周最小掌握清单 ​

  1. collective 算法决定通信模式：ring/tree/hierarchical 压力不同。
  2. channel 是跨层变量：影响 chunk、QP、flow、rail、tail。
  3. 多 rail 不自动线性：需要通信库、HCA、ECMP、接收端都配合。
  4. matched-world 拆变量：world size 相同不代表网络压力相同。
  5. p99 很重要：大规模同步会放大尾部。
  6. A/B 结论要有边界：有影响不等于根因，没修复不等于无关。

12. 本周结束时你应该能解释的一段话 ​

如果有人问：

“4 rail 比 1 rail 快，但不是 4 倍，是不是说明 rail 或交换机有问题？”

你应该能回答：

text
不能直接这么说。4 rail 非线性可能来自通信库没有均匀分配 channel/QP，GPU-HCA 亲和不同，某些 rail 的 ECMP/queue 状态不同，接收端入口或 GPU 处理成为瓶颈，collective 并发不足，或者 QoS/背景流量影响。它支持 rail 选择影响行为，但不能证明某条物理 rail 或交换机故障。要命名物理原因，需要逐 rail bytes、host→switch port 映射、GPU-HCA 亲和、QP/channel 映射和多次复测。

15. 进阶 case：同一个 AllReduce，不同算法的网络形态 ​

假设 8 个 rank 分布在 2 台机器：

text
node0: r0 r1 r2 r3
node1: r4 r5 r6 r7

15.1 扁平 ring ​

如果直接形成一个跨所有 rank 的 ring：

text
r0 → r1 → r2 → r3 → r4 → r5 → r6 → r7 → r0

跨机边可能是：

text
r3→r4
r7→r0

这时跨机流量集中在少数 ring 边上，但会随 chunk pipeline 持续流动。

15.2 分层算法 ​

如果先机内 reduce，再跨机，再机内 broadcast：

text
node0 内部 r0-r3 聚合
node1 内部 r4-r7 聚合
  ↓
node0 representative ↔ node1 representative
  ↓
各节点内部分发

跨机 rank 数可能减少，但代表 rank 的出口压力增加。

15.3 tree ​

如果形成树：

text
        r0
      /    \
    r1      r4
   /  \    /  \
 r2   r3 r5   r6
              \
              r7

某些内部 rank 可能承载更多转发/规约压力。

15.4 结论 ​

同样是：

text
world=8, message=256MiB

算法不同，网络看到的 flow 完全不同。

所以如果 MCCL 在某个 world size 改了算法阈值，性能可能突然变化。这种变化看起来像“网络规模阈值”，但也可能是通信库算法阈值。

16. 进阶 case：rank mapping 如何制造热点 ​

16.1 物理节点布局 ​

假设 4 台 host：

text
hostA, hostB 在 leaf1
hostC, hostD 在 leaf2

16.2 好的 rank 顺序 ​

text
r0=A
r1=B
r2=C
r3=D
ring: A→B→C→D→A

跨 leaf 边：

text
B→C
D→A

16.3 坏的 rank 顺序 ​

text
r0=A
r1=C
r2=B
r3=D
ring: A→C→B→D→A

跨 leaf 边：

text
A→C
C→B
B→D
D→A

跨 leaf 压力翻倍。

16.4 Muxi 边界 ​

当前 Muxi 没有稳定物理 leaf/spine ground truth，所以不能直接构造“按 leaf 优化”的 rank order。但可以做行为层 rank permutation：

text
固定节点集合；
改变 rank block order；
观察 p50/p99；
复测稳定性；

如果 rank permutation 明显影响性能，它支持 mapping 参与；如果不明显，也不能完全排除拓扑，因为可能缺少正确的物理分组或 workload 不敏感。

17. 进阶 case：channel 到 rail 的未知映射 ​

17.1 理想想象 ​

你可能以为 4 rail 下：

text
channel0 → xscale_0
channel1 → xscale_1
channel2 → xscale_2
channel3 → xscale_3

这样刚好均匀。

17.2 真实可能 ​

实际可能是：

text
channel0 → xscale_0
channel1 → xscale_0
channel2 → xscale_1
channel3 → xscale_0

或者：

text
不同 peer 选择不同 HCA；
不同 message size 选择不同 channel 数；
某些 HCA 被过滤；
rail 选择受环境变量和通信库内部策略共同影响；

17.3 为什么这影响结论 ​

如果 quad rail 没有 4 倍，可能是：

text
物理 rail 不独立；
也可能只是通信库没有均匀用 rail；
也可能是接收端单 GPU 瓶颈；
也可能是 channel 数不够；

所以要尽量拿：

text
per-HCA bytes；
MCCL debug HCA selection；
channel→HCA 映射；
QP→HCA 映射；

18. 进阶 case：为什么 matched-world 是必要的 ​

18.1 错误实验 ​

只跑：

text
w64, w128, w256, w512

然后看到 w512 掉速，就说：

text
512 规模触发网络问题。

这个结论太粗。

18.2 规模变化同时改变了什么 ​

从 w256 到 w512，可能同时改变：

text
rank 总数；
节点数；
每节点 GPU 数；
每节点注入；
跨 leaf 覆盖；
算法阈值；
channel 数；
QP 数；
同步尾部概率；

18.3 matched-world 的价值 ​

matched-world 通过固定 world，改变节点布局：

text
world=64:
8n8r
16n4r
32n2r
64n1r

可以初步区分：

text
同样 world 下，节点覆盖增加是否影响性能？
同样 world 下，每节点注入降低是否改善？

18.4 进一步控制 ​

更好还要控制：

text
消息大小；
channel；
rail；
GPU set；
rank order；
运行时间；
背景流量；

这就是为什么实验计划强调“一次只改变一个可解释因素”。

19. 进阶 case：如何解读 W4 A/B 没有修复 ​

19.1 预注册门槛的重要性 ​

如果没有预先定义“什么叫修复”，很容易事后挑数据。

比如：

text
某次 channel=16 比默认高 8%

如果没有门槛，你可能说它有效。

但如果预注册门槛是：

text
三块 run 一致提升 ≥20%，且 p99 不恶化

那 8% 就不能算修复。

19.2 没修复不等于没影响 ​

W4 里 channel、rail、GPU mapping 都有一定行为影响。

正确结论是：

text
这些变量可能参与性能形成；
但没有任何一个单独变量形成稳定、可复现、足够大的缓解；

19.3 这对后续意味着什么 ​

后续不是继续盲目扫参数，而是要问：

text
这些变量改变了什么底层事实？
有没有 QP/channel/HCA/rail bytes 证据？
有没有网络 counter？
有没有 per-rank timeline？

20. 进阶辨析：算法问题 vs mapping 问题 vs fabric 问题 ​

20.1 算法问题 ​

特点：

text
特定 world/message/collective 下明显；
换算法/channel/protocol 后变化；
可能不依赖特定节点；

需要证据：

text
实际 algorithm/protocol 日志；
固定节点集合的算法 A/B；
不同 message size 阈值；

20.2 mapping 问题 ​

特点：

text
rank order、GPU set、HCA/rail 选择影响明显；
同一节点不同 GPU/HCA 组合不同；

需要证据：

text
rank→GPU→HCA；
GPU-HCA topo；
per-HCA bytes；
rank permutation；

20.3 fabric 问题 ​

特点：

text
特定物理路径/端口/queue/counter 异常；
端点行为能和网络 counter 对齐；

需要证据：

text
host→switch port；
per-port bytes；
queue occupancy；
PFC/ECN/drop/retry；

20.4 为什么三者会混 ​

channel A/B 可能同时改变：

text
算法并发；
QP 数；
rail 使用；
ECMP entropy；
queue 压力；

所以必须把 A/B 结果写成“行为支持”，而不是直接归因。

21. 推荐阅读进一步拆解 ​

21.1 读 NCCL source，不要试图从第一天读完整源码 ​

建议只抓三个问题：

text
算法在哪里选择？
channel 数在哪里决定？
transport/HCA 在哪里选择？

然后把这些问题翻译给 MCCL：

text
MCCL 有没有对应 debug log？
能否打印 algorithm/protocol/channel？
能否打印 HCA/QP 选择？

21.2 读 Demystifying NCCL，看“抽象层” ​

重点不是每个函数名，而是层次：

text
collective API
  ↓
algorithm selection
  ↓
channel/chunk planning
  ↓
transport selection
  ↓
GPU kernel / proxy

这个层次能帮助你对 Muxi 提问。

21.3 读 SuperBench，看“基准组合” ​

SuperBench 的价值是：

text
不要用单一 benchmark 判断系统；
要用多层、可重复、结构化基准定位问题。

映射到 Muxi：

text
单机基线；
跨机 P2P；
incast；
matched-world；
pair matrix；
collective A/B；

22. 本周自测题：带答案方向 ​

22.1 为什么 4 rail 不一定 4 倍？ ​

答案方向：

text
通信库可能没有均匀用 rail，GPU-HCA 亲和不同，接收端入口限制，ECMP/queue/QoS 不均，collective 并发不足。

22.2 为什么 channel 是跨层变量？ ​

答案方向：

text
channel 改变 chunk pipeline、QP/flow 数、HCA/rail 映射、RNIC/CQ 压力、ECMP entropy 和同步尾部。

22.3 matched-world 解决什么问题？ ​

答案方向：

text
它在 world size 相同的情况下改变节点数/每节点 rank，用来拆开 rank 数、节点覆盖和每节点注入的影响。

22.4 W4 没有稳定修复说明什么？ ​

答案方向：

text
说明 channel/rail/GPU mapping 单独改变没有达到预注册稳定缓解门槛；它们仍可能是参与因素，但不是已证实单一根因。

22.5 rank order 为什么可能影响网络？ ​

答案方向：

text
rank order 决定通信算法中的逻辑邻居，逻辑邻居映射到物理节点后，会改变跨 leaf/spine/rail 的流量组合。