第 1 周：建立通信库与数据路径全景
对应原计划：
plans/muxi-fabric-network-learning-plan.md第 1 周。
配套工程：plans/muxi-fabric-probe.md的 “从 GPU buffer 到远端 GPU：故障面”。
相关最终结论：project/lab-workspace/reports/rounds/muxi_fabric_final_20260719.md。
本章定位：这是整套学习手册的入口。目标不是立刻读懂 NCCL/MCCL 源码，而是建立一张“从 collective 到网络行为”的跨层地图。后面讲 Ethernet、RDMA、RoCE、PFC、ECMP、tomography，都要回到这张地图上。
0. 这一周到底学什么
这一周的核心问题是：
当我们说 “AllReduce 慢” 时，到底是哪一层慢？
这句话听起来简单，但它是 Muxi fabric 探测里最容易误判的地方。因为 “AllReduce 慢” 只是一个最终症状，它可能来自：
benchmark timing 口径错误；
collective 算法选择不合适；
channel / chunk / protocol 不合适；
rank 到 GPU/HCA/rail 的映射形成热点；
某个 GPU↔HCA 路径慢；
RNIC / QP / CQ polling 出问题；
RoCE GID / MTU / TC / QoS 映射不对；
ECMP hash 不均；
交换机 egress queue / shared buffer 拥塞；
PFC / ECN / CNP / DCQCN 触发；
背景流量或间歇 stall；这周学完之后，你应该能和 agent 讨论这些问题：
- 为什么 AllReduce 不是一次简单的
send/recv？ rank、local_rank、world size、nproc_per_node分别是什么？- 为什么 rank 慢不等于 host 坏？
- 为什么
min≈max不能排除慢卡或慢链路？ ring、tree、hierarchical这些算法会如何改变网络压力？channel、chunk、protocol在通信库里大概起什么作用？alg_bw、bus_bw、P2P 单流带宽、incast aggregate 为什么不能混用？- 为什么单 pair 可以 23～24GB/s，但 w512 AllReduce 仍可能只有几 GB/s？
本周最重要的能力不是背术语，而是形成一个习惯：
先把现象放回路径图，再讨论候选根因。1. 一张总图：从 GPU buffer 到远端 GPU
先画最粗的一条路径：
训练代码 / benchmark
↓
torch.distributed / MCCL API
↓
collective 语义：AllReduce / Broadcast / ReduceScatter / AllGather
↓
通信库计划：algorithm / protocol / channel / chunk / rank order
↓
进程与设备映射：rank → local_rank → GPU → HCA / rail
↓
端点执行：GPU kernel / proxy thread / CUDA stream / GDRDMA
↓
RNIC/RDMA：MR / QP / WQE / CQE / GID / MTU / TC
↓
RoCEv2 packet：Ethernet / IP / UDP / RoCE header
↓
交换网络：leaf / spine / ECMP / queue / buffer / QoS
↓
远端 RNIC / GPU buffer
↓
collective 下一阶段或完成这张图里有一个重要事实：
用户看到的是 collective；
通信库执行的是分阶段数据搬运；
RNIC 看到的是 work request；
交换机看到的是 packet / flow / queue；
最终日志看到的是所有层叠加后的时间。所以，任何一个最终带宽数字都不是单层事实。
1.1 三个视角
同一个 AllReduce，可以从三个视角看。
用户视角
我调用 all_reduce(tensor)，希望所有 rank 得到规约结果。用户关心：
这一步训练花了多久？
吞吐下降了吗？通信库视角
我要选择算法；
把 tensor 切 chunk；
分配 channel；
决定 rank 顺序；
决定每一步和谁通信；
决定用哪些 HCA/rail；
处理同步和 completion。通信库关心：
如何让 GPU/RNIC/网络都忙起来；
如何避免某个 channel 或 rank 拖尾；
如何适配消息大小和拓扑。网络视角
我只看到一堆 RoCEv2 packet。
它们有 src/dst IP、UDP port、DSCP/ECN、queue、ECMP path。交换机不知道：
这是 AllReduce 的第几个 chunk；
这个 flow 属于哪个 rank；
这个 rank 是否在等待其他 rank。这就是为什么排障时要做“翻译”：
collective 里的 rank/channel/chunk
↔
网络里的 flow/QP/rail/path/queue2. Collective 语义：AllReduce 不是一次简单发送
2.1 Broadcast：一个源扩散给所有人
Broadcast 的语义：
输入：
rank0: data
rank1: empty
rank2: empty
rank3: empty
输出：
rank0: data
rank1: data
rank2: data
rank3: data它的关键模式是：
一个源，多个目的。可能形成的压力：
源端出口压力；
树形转发中的中间节点压力；
多个接收端同步等待。2.2 AllGather：每个人收集所有人的分片
AllGather 的语义：
输入：
r0: A
r1: B
r2: C
r3: D
输出：
r0: A B C D
r1: A B C D
r2: A B C D
r3: A B C D关键模式：
每个 rank 的数据最终要到所有 rank。可能形成的压力：
全体多轮交换；
接收端聚合；
rank 顺序和通信计划影响网络路径。2.3 ReduceScatter：先规约，再分散结果
ReduceScatter 的语义：
每个 rank 都有完整输入；
先做 reduce；
然后每个 rank 只保留结果的一段 slice。它常和 AllGather 组合成 AllReduce。
2.4 AllReduce：规约结果每个人都要
AllReduce 的语义：
每个 rank 输入一个 tensor；
对所有 rank 的 tensor 做 reduce；
每个 rank 都拿到完整 reduce 结果。一个常见理解：
AllReduce ≈ ReduceScatter + AllGather所以它至少包含两类动作：
把数据合起来；
再把结果分发给所有人。这就是为什么 AllReduce 的网络模式复杂得多。
2.5 小 case：4 rank AllReduce 为什么会多阶段
假设 4 个 rank：
r0, r1, r2, r3它们不是简单做：
r0 发给 r1/r2/r3；
r1 发给 r0/r2/r3；
...通信库可能会把 tensor 切成多块，然后每一轮只和部分 peer 交换：
round 1: r0↔r1, r2↔r3
round 2: r0↔r2, r1↔r3
round 3: r0↔r3, r1↔r2真实算法可能不是这个具体顺序，但直觉是：
AllReduce 是多阶段、多 peer、多 chunk 的 pipeline。如果其中某一阶段慢，后面阶段可能都被拖住。
3. rank、world、node、GPU：逻辑编号和物理路径不是一回事
3.1 world size
world size 是参与 collective 的总 rank 数。
world size = 512表示有 512 个 rank 参与，不直接说明：
有多少节点；
每节点几张 GPU；
每个 rank 走哪个 HCA；
覆盖多少 leaf/spine。3.2 rank
rank 是 collective 内的逻辑编号：
rank 0, rank 1, ..., rank 511rank 是逻辑身份，不是物理身份。
3.3 local rank
local_rank 是某个节点内的本地编号，通常用于选择本机 GPU：
node0: local_rank 0..7
node1: local_rank 0..7常见映射可能是：
local_rank 0 → GPU0
local_rank 1 → GPU1
...但这会受 CUDA_VISIBLE_DEVICES、启动脚本和容器环境影响。
3.4 nproc_per_node
nproc_per_node 表示每个节点起多少进程/多少 rank。
例如：
64 节点 × nproc_per_node=8 → world size=512
64 节点 × nproc_per_node=1 → world size=64这会强烈影响：
每节点注入流量；
机内通信比例；
跨机通信比例；
rail 使用；
rank mapping；
通信库算法阈值。3.5 小 case：world=64 不等于同一种实验
world=64 可以有很多形态：
8 节点 × 每节点 8 rank
16 节点 × 每节点 4 rank
32 节点 × 每节点 2 rank
64 节点 × 每节点 1 rank它们 world size 一样，但完全不是同一种网络压力。
例如：
8n8r：每节点注入高，节点覆盖少；
64n1r：每节点注入低，节点覆盖广；如果性能不同，不能只说：
world=64 有问题。你应该问：
是 rank 数问题？
是节点覆盖问题？
是每节点注入问题？
是机内/跨机比例问题？
是通信库算法阈值问题？3.6 rank 慢不等于 host 坏
观察：
rank 17 慢可能解释：
rank 17 所在 host 有问题；
rank 17 对应 GPU-HCA 亲和差；
rank 17 的 peer 经过拥塞 path；
rank 17 分到的 channel/chunk 是尾部；
rank 17 只是等待其他 rank；
rank mapping 下一次变化后慢点转移；所以排障时第一张表必须是：
rank | pod | host | local_rank | GPU | HCA/rail | IP/GID | node label没有这张表，就不要急着换卡、换线或命名 leaf。
4. 通信库算法：ring、tree、hierarchical
4.1 ring 算法直觉
ring 把 rank 排成一个环：
r0 → r1 → r2 → r3 → r0大消息 AllReduce 常用 ring 或 ring-like pipeline，因为它可以让每个 rank 持续收发 chunk。
优点：
大消息吞吐好；
每个 rank 通信量规则；
pipeline 容易让链路忙起来。风险：
步数随 rank 增加；
一个慢边影响全局；
rank 顺序决定哪些物理节点成为邻居；
跨 leaf/spine 的边分布可能不均。4.2 tree 算法直觉
tree 把 rank 组织成树：
r0
/ \
r1 r2
/ \
r3 r4优点：
小消息 latency 可能更好；
步数少；
适合某些规约/广播模式。风险：
树根或内部节点可能成为热点；
树形如果不贴合物理拓扑，可能把流量压到少数路径。4.3 hierarchical 算法直觉
多 GPU 节点里，机内通信和跨机通信能力不同。hierarchical 算法可能先做：
节点内 reduce
↓
节点间 collective
↓
节点内 broadcast这会让“每节点几张 GPU 参与”变成关键变量。
4.4 小 case：rank 顺序如何改变网络压力
假设：
r0, r1 在 leaf A
r2, r3 在 leaf Bring 顺序 1：
r0 → r1 → r2 → r3 → r0跨 leaf 边是：
r1→r2
r3→r0ring 顺序 2：
r0 → r2 → r1 → r3 → r0跨 leaf 边变成：
r0→r2
r2→r1
r1→r3
r3→r0同样 4 个 rank，网络压力完全不同。
所以如果 rank permutation 改变性能，它可能影响：
物理邻接；
ECMP path；
跨 leaf 流量数量；
同步尾部；不能直接说 rank permutation 是根因，它只是改变流量形态。
5. channel、chunk、protocol：通信库内部并行结构
5.1 chunk
大 tensor 会被切成 chunk：
tensor = chunk0 + chunk1 + chunk2 + ...切 chunk 是为了：
pipeline；
并行传输；
让 GPU/RNIC/网络持续工作；
减少单次大传输阻塞。5.2 channel
channel 可以理解为通信库内部的并行车道：
chunk0 → channel0
chunk1 → channel1
chunk2 → channel2
chunk3 → channel3channel 可能映射到：
不同 GPU kernel work；
不同 proxy thread；
不同 QP；
不同 HCA；
不同 rail；
不同 network flow。但“可能”不等于“一定”。具体要看通信库实现。
5.3 protocol
protocol 是通信库对不同消息大小/硬件路径的传输方式选择。
它可能影响：
是否走低延迟路径；
是否使用特定 GPU kernel；
buffering 策略；
chunk size；
CPU/GPU 协作方式；
网络注入模式。5.4 小 case：channel 数变多为什么可能变快
假设 1 个 channel：
chunk 串行推进；
单 QP 或少量 flow；
rail 利用不足；
ECMP entropy 不足。改成 8 个 channel 后：
更多并发；
更多 QP/flow；
可能分到多个 rail；
可能更好利用 ECMP。所以带宽变快。
5.5 小 case：channel 数变多为什么可能变慢
更多 channel 也可能导致：
更多 CQ polling；
更多 proxy thread 压力；
更多同步尾部；
更多 queue 竞争；
某些 channel 被映射到热点 HCA/rail；
小消息 overhead 增加。所以 channel 不是越多越好。
5.6 对 Muxi 的含义
如果 W4 里 channel A/B 改变了 p50/p99，应该写：
channel 是参与因素；
它改变了通信库并发和可能的 QP/rail/flow 形态；
但没有 QP/channel/HCA 逐项映射和多次复测时，不能说它就是根因。6. 多 rail：为什么 4×200G 不是自动 800G
Muxi 每节点有 4 个 xscale RoCE rail。直觉上：
4 rail × 200Gb/s = 800Gb/s换成 GB/s：
800Gb/s ÷ 8 ≈ 100GB/s但真实有效值会受很多条件限制。
6.1 多 rail 要线性，需要什么
至少需要：
通信库把 channel/QP 分到多个 rail；
GPU 到 HCA 的路径都健康；
每个 rail 的 GID/MTU/TC 正确；
每个 rail 的交换路径容量相近；
ECMP 分布足够均匀；
接收端能同时吃多个 rail；
collective 本身有足够并发；
没有单 GPU/单 rail 入口瓶颈；6.2 小 case：4 rail 比 1 rail 快但不是 4 倍
这可能说明：
多 rail 确实提供额外容量；
但某个上游因素限制了线性扩展。候选包括：
通信库没有均匀使用 4 rail；
GPU-HCA 亲和不均；
接收端单 GPU 聚合入口限制；
某些 rail 的 ECMP/queue 状态差；
collective 阶段没有足够并发；
per-rail QoS/MTU/GID 不一致；不能直接说：
某条 rail 坏了；
交换机有问题；
4 rail 设计无效。6.3 rail 掩码实验能说明什么
如果你做：
只用 xscale_0
只用 xscale_1
用 xscale_0,1
用 xscale_2,3
用 xscale_0,1,2,3它能支持：
rail 选择影响行为；
某些 rail 组合在当前 workload 下更好/更差。不能证明：
某条物理链路坏；
某个 leaf 有问题；
rail0/1 和 rail2/3 接在不同 spine 平面；需要额外 ground truth：
host rail → switch port；
per-rail bytes；
GPU-HCA 亲和；
queue/counter；
多时段复测；7. 指标口径：再次防止混用
7.1 time
collective 完成时间。它通常受最慢 rank 或最慢阶段限制。
7.2 alg_bw
用户语义数据量除以 time。
alg_bw ≈ tensor size / time它回答：
用户看起来处理数据多快？7.3 bus_bw
按 collective 理论通信量折算的总线带宽。
它回答：
按这个 collective 的通信模式折算，等效总线压力是多少？它不是某条网线的真实速率。
7.4 P2P bandwidth
一个 pair 的源到目的有效带宽。
src → dst更接近单 flow/单 rail 基线。
7.5 incast aggregate
多个源到一个目的的聚合入口：
src1 ┐
src2 ├→ dst
src3 ┘要分清：
per-flow bandwidth
aggregate ingress7.6 p50/p99
p50 是典型值，p99 是尾部。对于同步 collective，p99 很关键。
7.7 小 case：p50 好但 p99 差
假设：
配置 A: p50=6GB/s, p99=2GB/s
配置 B: p50=5.5GB/s, p99=5GB/s如果训练被尾部拖住，B 可能更好。
所以 W4 判断不能只看平均，要看多块、多次、p50/p90/p99 和稳定性。
8. 和 Muxi W1/W4 的关系
8.1 W1：matched-world 的意义
Muxi W1 试图拆开：
rank 数；
节点数；
每节点 GPU 数；
每节点注入；
节点覆盖；
消息大小；
collective 类型；
rail 和 mapping；这很重要，因为 w512 掉速可能不是单纯 world size，而是多个变量同时越过阈值。
8.2 W4：channel、rail、GPU mapping 干预
最终报告里 W4 做了三类 A/B：
channel；
rail；
GPU 物理集合/顺序；结果没有达到稳定修复门槛。
正确理解是：
这些变量确实能影响行为；
但没有形成一致、可重复、足够大的缓解；
因此它们是参与因素，不是已证实单一根因。8.3 为什么“未修复”不等于“无关”
如果 channel 改变只提升 10%，而目标是恢复 50%，不能说 channel 无关。它可能只是：
解决了部分瓶颈；
改变了暴露 stall 的时序；
没有触及真正瓶颈；
和网络/rail/queue 问题耦合。同理，如果 rail A/B 有差异，也不能直接命名物理 rail 问题。
9. 推荐阅读提炼
9.1 NCCL Collective Operations
一句话
这份文档告诉你不同 collective 的语义和通信模式，不同 collective 的指标不能直接混比。
抓哪个问题
AllReduce、ReduceScatter、AllGather、Broadcast 的数据移动模式有什么区别？关键知识点
- AllReduce 通常可拆成 reduce-scatter 和 all-gather。
- collective 的理论通信量和用户 tensor size 不一定一样。
- 不同 collective 对 latency 和 bandwidth 的敏感点不同。
Muxi 迁移
用它理解 alg_bw / bus_bw 和 AllReduce 为什么多阶段。MCCL 的具体算法选择必须看 MCCL 日志。
9.2 NCCL source / Demystifying NCCL
一句话
这些材料帮你看到 channel、chunk、protocol、ring/tree 是如何从概念进入执行计划的。
抓哪个问题
通信库如何把一个大 tensor 切成并行传输的多个 chunk？
为什么 channel 数改变会影响底层 flow？关键知识点
- channel 是通信库内部并行结构。
- chunk size 影响 pipeline。
- protocol 选择会随消息大小和硬件路径变化。
- rank order 会影响物理通信邻接。
Muxi 迁移
它不是 MCCL 真相源，但能告诉你该向沐曦/MCCL 日志追问：
实际算法是什么？
channel 数是多少？
每个 channel 走哪个 HCA/QP？
rank 顺序如何？
protocol 如何选择？9.3 SuperBench
一句话
SuperBench 展示如何系统化 benchmark GPU 集群，不只看最终训练吞吐。
抓哪个问题
为什么要做单机、P2P、incast、collective 多层基线？Muxi 迁移
Muxi W0-W4 就是这个思想：
先修 timing；
再做单 pair / incast / matched-world / pair matrix / QoS visibility / W4 A/B；最终不是靠一个数字下结论，而是靠证据链。
10. 常见误判
- channel 越多越好。
- 4 rail 就应该 4 倍。
- AllReduce 慢一定是网络慢。
- 单 pair 快就能反证通信库问题。
bus_bw可以和 incast aggregate 直接比较。- GPU 顺序影响性能就说明某张 GPU 坏。
- A/B 没达到修复门槛就说明该变量无关。
- A/B 有变化就说明该变量是根因。
- world size 一样就代表实验等价。
- rank permutation 没明显影响就说明拓扑无关。
11. 本周任务设计
11.1 任务 A：画 collective 到 flow 的映射
画出：
AllReduce
↓
algorithm
↓
chunks
↓
channels
↓
QP / HCA / rail
↓
RoCE flows
↓
ECMP / queue期望理解：
通信库变量会改变网络看到的 flow 形态。不能证明：
画出这张图不等于知道 MCCL 实际映射；实际映射需要日志或厂商支持。11.2 任务 B：matched-world 表
设计一个表：
形态 节点数 每节点 rank world 每节点注入 节点覆盖
8n8r 8 8 64 高 低
16n4r 16 4 64 中 中
32n2r 32 2 64 低 高
64n1r 64 1 64 很低 最高期望理解：
world 相同，不代表网络压力相同。11.3 任务 C：rail A/B 辨析
给定：
dual01 比 dual23 快；
quad 比 dual01 快但不是两倍；请列出：
通信库原因；
GPU-HCA 亲和原因；
网络路径原因；
QoS/ECMP 原因；
接收端瓶颈原因；
测量噪声原因。11.4 任务 D：channel A/B 结论边界
写出四行：
它支持什么：
它不能证明什么：
替代解释：
还缺什么 ground truth：12. 和 agent 讨论的问题模板
12.1 collective 候选拆解
请把这个 AllReduce 掉速拆成通信库算法、channel/QP、rank mapping、rail 使用、网络 fabric 五类候选。
每类列出需要固定的变量和可观察指标。12.2 matched-world 设计
请设计一个 matched-world 实验，分别控制 world size、节点数、每节点 GPU 数、rail 数和 channel 数，避免一次改变多个因素。12.3 W4 结果解释
请解释 channel/rail/GPU mapping A/B 没有稳定修复时，哪些候选被削弱，哪些仍保留为参与因素。
不要把“未修复”等同于“无关”。12.4 指标解释
请解释这个报告中的 time、alg_bw、bus_bw、p50、p99、per-flow bandwidth、aggregate ingress。
说明哪些能互相比较，哪些不能。13. 本周最小掌握清单
- collective 算法决定通信模式：ring/tree/hierarchical 压力不同。
- channel 是跨层变量：影响 chunk、QP、flow、rail、tail。
- 多 rail 不自动线性：需要通信库、HCA、ECMP、接收端都配合。
- matched-world 拆变量：world size 相同不代表网络压力相同。
- p99 很重要：大规模同步会放大尾部。
- A/B 结论要有边界：有影响不等于根因，没修复不等于无关。
- NCCL 是心智模型：MCCL 实际行为必须回日志和厂商资料。
14. 本周结束时你应该能解释的一段话
如果有人问：
“4 rail 比 1 rail 快，但不是 4 倍，是不是说明 rail 或交换机有问题？”
你应该能回答：
不能直接这么说。4 rail 非线性可能来自通信库没有均匀分配 channel/QP，GPU-HCA 亲和不同，某些 rail 的 ECMP/queue 状态不同，接收端入口或 GPU 处理成为瓶颈，collective 并发不足，或者 QoS/背景流量影响。它支持 rail 选择影响行为，但不能证明某条物理 rail 或交换机故障。要命名物理原因，需要逐 rail bytes、host→switch port 映射、GPU-HCA 亲和、QP/channel 映射和多次复测。15. 进阶辨析：四种“慢”不是一回事
排障时最容易犯的错误，是把所有慢都归成一个词：
通信慢但至少要分成四类。
15.1 启动慢
比如：
init process group 慢；
rank rendezvous 慢；
第一次 collective 慢；
第一次 memory registration 慢；这类慢可能来自：
进程启动；
容器调度；
DNS / rendezvous；
JIT / lazy init；
MR 注册；
连接建立；它不一定代表稳态网络带宽低。
15.2 稳态吞吐慢
比如：
大消息 AllReduce 连续多轮都只有低 bus_bw这更可能和：
算法；
channel；
rail；
ECMP；
queue；
每节点注入；相关。
15.3 尾部慢
比如：
大部分 iteration 正常；
偶尔一个 iteration 特别慢；
p50 还行，p99 很差；这可能来自：
间歇拥塞；
PFC/ECN 控制环震荡；
背景流量；
某些 rank 等待；
CPU/proxy 抢占；15.4 局部慢
比如：
某个 pair 慢；
某个 rank 慢；
某个 rail 慢；
某个 GPU 集合慢；局部慢最容易被误判为坏硬件，但也可能是映射和路径问题。
15.5 小 case：同一个 5GB/s 可能完全不同
看到：
AllReduce bus_bw = 5GB/s至少要问：
是第一轮慢，还是每轮都慢？
是平均慢，还是 p99 慢？
是所有 rank 都同步慢，还是某个阶段拖尾？
是同一批节点复现，还是随机出现？
改变 channel/rail/GPU 后是否迁移？如果这些问题不问，就会把不同机制混成一个“网络慢”。
16. 进阶 case：怎么读一条 AllReduce 日志
假设你看到一条简化日志：
world=512
message=256MiB
nproc_per_node=8
nodes=64
alg_bw=4.8GB/s
bus_bw=5.1GB/s
min_time≈max_time
HCA=xscale_0,xscale_1,xscale_2,xscale_3
GID_INDEX=516.1 第一反应不应该是什么
不要直接说：
交换机拥塞；
某条链路坏；
PFC 有问题；
MCCL 算法差；这些都是候选，但不是日志直接证明的事实。
16.2 先抽取事实
可以写：
事实 1：512 rank 参与，覆盖 64 节点，每节点 8 rank。
事实 2：消息是 256MiB，大消息，偏稳态吞吐。
事实 3：使用 4 个 xscale HCA，至少端点配置尝试使用 quad rail。
事实 4：GID index 记录为 5。
事实 5：alg_bw/bus_bw 均低于单 pair 23~24GB/s，但口径不同不能直接比较。
事实 6：min≈max 只能说明 collective 完成时间同步，不能排除局部慢点。16.3 再列候选层
H0：timing 或指标口径错；
H1：MCCL algorithm/protocol/channel 选择不理想；
H2：rank→GPU→HCA→rail 映射形成热点；
H3：单节点 GPU-HCA/RNIC 路径限制；
H4：某些物理口间歇错误；
H5：QoS/PFC/ECN/DCQCN 映射问题；
H6：ECMP 碰撞、上行超分、shared buffer；
H7：背景流量或同步探针制造拥塞；16.4 再问下一步证据
有没有单 pair P2P 基线？
有没有 incast 基线？
有没有 matched-world？
有没有 per-rank/per-channel timeline？
有没有 rail 掩码 A/B？
有没有 QP/channel 实际映射？
有没有交换机 counter？这就是从日志进入实验设计的路径。
17. 进阶 case：为什么单 pair 快不能反证网络问题
17.1 表面矛盾
你可能看到：
A→B 单 pair: 24GB/s
w512 AllReduce: 5GB/s有人会说：
单 pair 快，所以网络没问题；AllReduce 慢一定是 MCCL。这句话不严谨。
17.2 单 pair 测到什么
单 pair 主要测：
一个源；
一个目的；
一个或少量 rail/QP；
一个时间窗口；
较简单同步结构；它能支持：
至少这对端点、这条配置下，简单路径可以接近 200G 有效上限。17.3 AllReduce 多了什么
w512 多了：
512 rank；
64 节点；
每节点 8 rank；
多阶段；
多 channel；
多 rail；
同步等待；
更多 ECMP flow；
更多 queue 竞争；
更多接收端聚合；它可能触发单 pair 不触发的问题：
bisection 压力；
incast-like 聚合；
ECMP 大象流碰撞；
PFC/ECN 控制环；
shared buffer；
通信库算法阈值；所以单 pair 快只能说明一件事：
不要优先怀疑所有端口都坏；简单数据面有可用基线。不能说明：
大规模网络没有问题；
交换机队列没有问题；
MCCL 一定是唯一根因。18. 进阶 case：为什么 AllReduce 慢也不能直接证明网络问题
反过来，看到：
w512 AllReduce 慢也不能直接说：
交换机拥塞。因为 AllReduce 慢也可能来自：
通信库算法在 512 rank 选择了不合适路径；
channel 数过少或过多；
rank order 与物理拓扑不匹配；
GPU-HCA 亲和差；
某些 proxy thread 被 CPU 抢占；
benchmark timing 包含了额外同步；
消息大小触发不同 protocol；正确做法是拆层：
先确认 timing；
再做单 pair；
再做 incast；
再做 matched-world；
再做 rail/channel/GPU A/B；
再索取网络 ground truth；这就是主计划 W0→W4 的意义。
19. 推荐阅读进一步拆解：你应该怎么读 NCCL 材料
19.1 读 NCCL Documentation 时，不要先陷入环境变量大全
NCCL 文档很多，初学时不要从所有环境变量开始背。先抓四个问题：
1. communicator 是什么？
2. rank/world 是什么？
3. collective 语义是什么？
4. 性能指标怎么定义？读的时候可以做一张表：
概念 人话解释 Muxi 对应问题
communicator 一组参与通信的 rank 当前 world 是哪些 pod/rank？
rank collective 内逻辑编号 rank→host/GPU/HCA 映射是什么？
AllReduce 所有人规约并拿到结果 w512 掉速是哪类 collective？
algorithm 通信计划形态 MCCL 实际选了什么算法？
channel 并行通信车道 channel A/B 改了什么？19.2 读 NCCL Tests Performance 时，重点看指标定义
不要只看它怎么跑 benchmark，要看：
bytes 如何算；
time 如何算；
alg_bw 如何算；
bus_bw 如何折算；然后问 Muxi 脚本：
我们的 timing 是 global max 还是 local time？
是否包含 warmup？
是否同步所有 rank？
是否区分 alg_bw/bus_bw/P2P？19.3 读 Demystifying NCCL 时，重点看“拆分”
你要吸收的是：
一个 collective 会被拆成算法、channel、chunk、kernel、proxy、transport。不要急着把它和 MCCL 一一对应。正确迁移方式是：
NCCL 有 channel → 问 MCCL 有没有类似 channel，如何打印？
NCCL 有 protocol → 问 MCCL protocol 如何选择？
NCCL rank order 重要 → 问 MCCL 当前 rank order 是什么？
NCCL transport 映射 HCA → 问 MCCL channel 到 xscale 如何映射？20. 本周自测题：带答案方向
20.1 为什么 min≈max 不能排除慢 rank？
答案方向：
collective 是同步操作，一个慢 rank 或慢阶段会让其他 rank 等待，最终所有 rank 看到的完成时间可能接近。20.2 为什么 world size 相同不代表实验等价？
答案方向：
world size 只说明 rank 总数，不说明节点数、每节点 rank、每节点注入、节点覆盖、机内/跨机比例和算法选择。20.3 为什么单 pair 快不能反证 w512 网络问题？
答案方向：
单 pair 是简单端到端基线，w512 是大规模同步 collective，会触发聚合容量、ECMP、queue、rail、通信库调度等问题。20.4 为什么 AllReduce 慢也不能直接证明交换机拥塞？
答案方向：
AllReduce 慢可能来自 timing、算法、channel、rank mapping、GPU-HCA、RNIC、QoS、ECMP、背景流量等多层，需要逐层证据。20.5 如果 channel A/B 有差异，为什么不能直接说 channel 是根因？
答案方向：
channel 改变会同时改变 chunk 并发、QP/flow、rail 使用、RNIC/CQ 压力和同步尾部；它是跨层干预，不是单一机制证据。