文档预览

深浅色

第 8 周：以 Muxi 512 为毕业项目 ​

对应原计划：plans/muxi-fabric-network-learning-plan.md 第 8 周。
主要输入：plans/muxi-fabric-probe.md、project/lab-workspace/reports/rounds/muxi_fabric_final_20260719.md、project/lab-workspace/reports/rounds/muxi_topology_facts_20260719_102558.md。
本章定位：把前 7 周的知识转成一份能和 agent、网络组、通信库开发者讨论的 Muxi 512 evidence map。重点不是再学新概念，而是形成结论边界和下一步提问能力。

0. 这一周到底做什么 ​

第 8 周是毕业项目：面对 Muxi 512 卡 RoCE fabric 的实际现象，你要能做到：

text
不先猜根因；
先整理事实；
再列候选；
再写支持证据和反证；
再说明不能证明什么；
最后提出最小下一步证据请求。

你最终要能回答：

  • 现有事实到底有哪些？
  • 哪些结论已经比较稳？
  • 哪些候选被削弱？
  • 哪些机制仍可能但没闭环？
  • 为什么不能写成“交换机拥塞已证实”？
  • 网络组/沐曦/H3C 最小需要提供哪些 ground truth？
  • 如果继续让 agent 做工作，应该问什么，而不是让它盲目猜？

本周核心原则：

text
最终交付不是“给一个根因”，而是给 evidence map。

1. Muxi 512 当前事实清单 ​

先只列事实，不解释。

1.1 集群事实 ​

text
目标集群：vc-c550-h3c-test
规模：64 节点 × 8 卡 = 512 卡
每节点：4 × 200G xscale RoCEv2
当前 GID index：5

1.2 已观测性能事实 ​

text
w512 AllReduce 可以跑通；
w512 bus_bw 多次结果约几 GB/s 级别，明显低于理想；
跨机单流和不相交 pair 可到约 23～24GB/s；
7→1、15→1 incast aggregate 约 24.2GB/s；
4 rail 比 1 rail 快，但不是 4 倍线性；

1.3 W2 行为拓扑事实 ​

text
完成 64 节点 2016 pair matrix；
原始矩阵有极慢 pair；
最差 pair 正反复测恢复；
无稳定双向慢；
无稳定方向性慢；
节点边际异常不明显；
无稳定物理拓扑聚类；

1.4 W3 QoS/ECMP 可见性事实 ​

text
仅证实 MCCL 读取 TC128；
缺 QP/wire/switch/counter 闭环；
无法强证 PFC/ECN/CNP/ECMP；

1.5 W4 干预事实 ​

text
channel A/B 有行为影响，但未达到稳定修复门槛；
rail A/B 有行为差异，但未形成可重复物理拓扑结论；
GPU 物理集合/顺序有影响，但不是单一根因；
rank block permutation 无明显稳定敏感性；

2. 一张跨层 evidence map ​

可以把候选层写成：

text
H0 benchmark/timing
H1 MCCL algorithm/protocol/channel
H2 rank→GPU→HCA→rail mapping
H3 endpoint GPU/NUMA/PCIe/RNIC
H4 physical link intermittent error
H5 QoS/PFC/ECN/DCQCN
H6 ECMP/oversubscription/shared buffer
H7 background traffic / probe interference

对每个候选都要写：

text
支持证据：
反证：
替代解释：
置信度：
下一证据：

这就是毕业项目的核心格式。

3. 候选 1：大规模同步尾部与间歇 stall ​

3.1 支持证据 ​

text
w512 多次出现低带宽；
原始 pair matrix 有极慢 pair；
最差 pair 复测恢复；
W4 中 p50/尾部会随配置变化；

这些支持：

text
问题可能不是固定坏边，而是间歇性 stall 或同步尾部。

3.2 反证和边界 ​

text
没有稳定定位到某个固定 pair；
没有网络 counter 说明 stall 来自哪类机制；

所以不能写：

text
已证实是 PFC/ECN/ECMP。

3.3 下一证据 ​

text
per-rank timeline；
per-channel timeline；
交换机时间窗 counter；
RNIC retry/CNP；
背景流量记录；

4. 候选 2：rail/GPU-NIC 路径行为差异 ​

4.1 支持证据 ​

text
4 rail 比 1 rail 快；
不同 rail 掩码表现不同；
GPU 集合/顺序影响行为；

4.2 不能证明什么 ​

这些不能证明：

text
某条 rail 物理坏；
某个 leaf/spine 有问题；
四 rail 物理独立或不独立；

4.3 替代解释 ​

text
通信库 channel 到 HCA 分配不均；
GPU-HCA 亲和；
接收端单 GPU/单 rail 入口；
ECMP/QoS 差异；
背景流量；

4.4 下一证据 ​

text
host rail → switch port；
per-rail bytes；
GPU-HCA topo；
MCCL channel/HCA 日志；

5. 候选 3：节点覆盖与每节点注入耦合 ​

5.1 支持证据 ​

matched-world 显示不同布局会影响行为。

这说明：

text
world size 不是唯一变量；
节点覆盖和每节点注入都重要；

5.2 替代解释 ​

text
MCCL 算法阈值；
rank mapping；
不同 leaf/spine 覆盖；
每节点 GPU 数改变机内/跨机比例；

5.3 下一证据 ​

text
固定 algorithm/channel 的 matched-world；
固定节点集合，改变 nproc；
固定 nproc，改变节点覆盖；
网络 counter 对齐；

6. 候选 4：MCCL/本地软件映射 ​

6.1 支持证据 ​

text
channel 数能影响 p50/尾部；
GPU 集合和顺序能影响行为；
环境变量透传和部分映射已证实；

6.2 反证和边界 ​

text
channel、rail、GPU 三类 W4 干预均未形成稳定 ≥门槛收益；
rank permutation 无明显稳定敏感性；

6.3 正确结论 ​

text
MCCL/本地软件映射是参与因素；
但当前不能写成单一根因或已修复路径。

6.4 下一证据 ​

text
实际 algorithm/protocol/channel；
channel→QP→HCA 映射；
per-channel timeline；
厂商支持的 tuning 值域；

7. 候选 5：固定坏节点或固定坏 pair ​

7.1 支持证据 ​

原始矩阵里有极慢 pair。

7.2 强反证 ​

text
最差 pair 正反复测恢复；
无稳定双向慢；
无稳定方向性慢；
节点边际异常不明显；

7.3 正确结论 ​

text
固定坏节点/固定坏 pair 作为优先根因被明显削弱。

不是说未来不会出现坏硬件，而是当前这批证据不支持优先换卡/换线。

8. 仍未证实但不能排除的机制 ​

这些机制仍可能存在：

text
交换机 egress queue 拥塞；
shared buffer；
PFC pause；
ECN CE；
CNP/DCQCN 降速；
ECMP 碰撞；
上行超分；
背景流量；

为什么不能排除？

因为当前缺：

text
host→switch port；
per-port bytes；
queue occupancy；
PFC pause；
CE/CNP；
drop/retry；
CRC/FEC；
ECMP group/hash field；

为什么不能证实？

因为端到端带宽下降不是机制证据。

9. 网络组 / H3C / 沐曦最小 ground truth 请求 ​

9.1 物理映射 ​

text
64 host × xscale_0..3 → switch chassis / port / rail
leaf/spine 层级
上行链路速率
超分设计

用途：

text
把行为 pair 对齐到物理端口和路径候选。

9.2 QoS 映射 ​

text
MCCL_IB_TC 对应 wire DSCP/ECN/PCP；
switch trust L2/L3；
DSCP/PCP → priority；
priority → PG/TC/queue；
PFC enable / threshold / headroom；
ECN threshold；
CNP priority；

用途：

text
验证 RoCE 流量是否进入预期 queue，以及 PFC/ECN 是否可能触发。

9.3 时间窗 counter ​

text
per-port bytes；
queue occupancy；
PFC pause frames/duration；
ECN CE；
CNP sent/received；
drop；
retry；
CRC/FEC；

用途：

text
把实验时间窗的端到端行为和网络机制对齐。

9.4 ECMP 信息 ​

text
ECMP group；
hash fields；
hash seed / polarization 风险；
QP/UDP source port 是否参与；

用途：

text
判断 QP/flow entropy 实验能否解释路径分布。

10. 如果没有网络组配合，端侧还能做什么 ​

低风险方向：

text
更严格的 matched-world；
per-rank/per-channel timeline；
rail/QP 小矩阵；
重复性和随机化；
消息大小 sweep；
rank mapping sweep；
背景流量时间对比；

但要承认边界：

text
端侧实验可以提高候选排序；
不能替代物理 ground truth。

11. 毕业交付应长什么样 ​

最终文档应该包括：

text
1. 问题定义；
2. 数据路径图；
3. 已确认事实；
4. 指标口径；
5. 实验列表和结果根；
6. evidence map；
7. 候选根因排序；
8. 被削弱/反证的假设；
9. 不可判定项；
10. 最小 ground truth 请求；
11. 下一步决策：工程修复 / 继续探索 / 研究问题；

12. 推荐阅读回顾：前 7 周如何合成 ​

Week 1 通信栈 ​

告诉你：AllReduce 慢是跨层症状。

Week 2 Ethernet/IP/ECMP ​

告诉你：逻辑拓扑、行为拓扑、物理拓扑不能混。

Week 3 RDMA/RNIC ​

告诉你：QP/MR/CQ/RNIC 是通信库和网络之间的关键接口。

Week 4 RoCE/QoS ​

告诉你：端点 TC 到交换机 queue 需要完整映射链。

Week 5 PFC/ECN ​

告诉你：拥塞机制必须靠 counter 闭环。

Week 6 MCCL/channel/rail ​

告诉你：通信库变量跨层影响 flow、rail 和 tail。

Week 7 tomography ​

告诉你：端侧矩阵给行为假设，不能唯一恢复物理拓扑。

13. 常见错误结论 ​

不要写：

text
w512 慢，所以交换机拥塞。
单 pair 快，所以网络没问题。
pair matrix 有块，所以恢复了 leaf。
多 QP 快，所以 UDP port 进 hash。
incast 24GB/s，所以 PFC 触发。
channel A/B 有变化，所以 MCCL 是根因。
最差 pair 慢，所以坏链路。

正确写法是：

text
这个现象支持某候选；
但仍有替代解释；
需要某 ground truth 才能闭环。

14. 本周任务设计 ​

14.1 任务 A：写 evidence map ​

表头：

text
候选机制 | 支持证据 | 反证 | 替代解释 | 置信度 | 下一证据

14.2 任务 B：写网络组请求 ​

每项字段都要说明：

text
用于区分哪个候选；
缺失时什么不可判定；

14.3 任务 C：写一页非过度结论摘要 ​

要求：

text
不使用“已证实交换机拥塞”；
不命名 leaf/spine；
清楚写出行为结论和外部阻塞；

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

15.1 evidence map ​

text
请基于当前 Muxi 证据写一份候选根因排序。
每个候选必须包含：支持证据、反证、替代解释、置信度、下一证据。
禁止把未闭环机制写成已证实根因。

15.2 ground truth 请求 ​

text
请为网络组生成一份最小 ground truth 请求清单。
要求每个字段都说明：用于区分哪个候选机制，缺失时会导致什么不可判定。

15.3 报告整理 ​

text
请把所有已有 Muxi 报告整理成一张 evidence map：
行是候选机制，列是支持证据、反证、缺失 ground truth、对应结果目录。

16. 毕业自测题 ​

16.1 为什么不能说交换机拥塞已证实？ ​

答案方向：

text
缺少交换机 queue、bytes、PFC/ECN/CNP/drop 等 counter 闭环；端到端带宽下降只能支持候选。

16.2 为什么固定坏 pair 被削弱？ ​

答案方向：

text
原始最差 pair 复测恢复，无稳定双向慢/方向性慢/节点边际异常。

16.3 为什么 MCCL 仍是参与因素？ ​

答案方向：

text
channel、GPU 集合、rail 掩码能影响行为，但未形成稳定修复；说明参与但非单一已证实根因。

16.4 最小 ground truth 是什么？ ​

答案方向：

text
host rail→switch port、QoS 映射、实验窗口 per-port/queue/PFC/ECN/CNP/drop/retry/FEC counter、ECMP hash/group。

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

如果有人问：

“Muxi 512 的根因到底是什么？”

你应该能回答：

text
当前证据不支持给一个单一已证实根因。比较稳的结论是：w512 掉速是真实现象，单跨机流和不相交 pair 能接近单 200G rail 有效上限，固定坏节点/固定坏 pair 被复测明显削弱；channel、rail、GPU mapping 等本地/通信库变量会影响行为但没有形成稳定修复；QoS/ECMP/PFC/ECN/shared buffer 等网络机制仍是可能解释，但缺少交换机端口、queue、PFC/ECN/CNP/drop/retry 等 ground truth，不能写成已证实。下一步最有价值的是拿网络侧时间窗 counter 和 host rail→switch port 映射，把端到端行为和物理机制对齐。

18. 具体 evidence map 示例 ​

下面是一个示例格式，后续可以让 agent 基于真实报告填表。

18.1 大规模同步尾部 / 间歇 stall ​

text
候选机制：大规模同步尾部 / 间歇 stall
支持证据：
  - w512 多次低带宽；
  - 原始 pair matrix 有极慢边；
  - 极慢边复测恢复，说明存在瞬时性；
  - W4 p50/p99 对配置敏感；
反证：
  - 没有稳定定位到固定 pair 或固定节点；
替代解释：
  - ECMP 碰撞；
  - PFC/ECN 控制；
  - 背景流量；
  - MCCL channel/QP 映射；
置信度：
  - 行为层中高；具体机制低；
下一证据：
  - per-rank/per-channel timeline；
  - 网络时间窗 counter；

18.2 固定坏节点 / 坏 pair ​

text
候选机制：固定坏节点 / 固定坏 pair
支持证据：
  - 原始矩阵出现极慢 pair；
反证：
  - 最差 pair 复测恢复；
  - 无稳定双向慢；
  - 无稳定方向性慢；
  - 节点边际异常不明显；
置信度：
  - 作为优先根因低；
下一证据：
  - 只对未来重复出现的慢点做定点复核；

18.3 ECMP 碰撞 ​

text
候选机制：ECMP 碰撞 / flow hash 不均
支持证据：
  - 多流大象流场景下理论可能；
  - channel/QP/rail 变化会改变行为；
反证：
  - 当前缺少实际 UDP source port、ECMP group、per-uplink bytes；
替代解释：
  - RNIC QP 并发；
  - 通信库 channel；
  - shared buffer；
  - PFC/ECN；
置信度：
  - 可能但未闭环；
下一证据：
  - QP/UDP port；
  - per-uplink bytes；
  - 多 seed flow salt 实验；

18.4 PFC / ECN / CNP ​

text
候选机制：PFC / ECN / CNP / DCQCN
支持证据：
  - RoCE fabric 中理论可能；
  - incast 和大规模同步会制造 queue 压力；
反证：
  - 当前没有 pause/CE/CNP/rate counter 闭环；
替代解释：
  - 普通入口容量上限；
  - ECMP；
  - 通信库同步尾部；
置信度：
  - 可能但未证实；
下一证据：
  - PFC pause frame/duration；
  - CE marks；
  - CNP sent/received；
  - queue occupancy；

19. 如何写“不夸大”的最终摘要 ​

19.1 错误摘要 ​

text
我们证明了 Muxi 512 掉速是交换机拥塞导致，可能是 PFC/ECN/ECMP 问题。

问题：

text
把候选机制写成已证实；
没有区分 PFC/ECN/ECMP；
没有说明缺 counter；

19.2 更好的摘要 ​

text
我们确认 w512 AllReduce 掉速是真实现象，并通过单 pair、不相交多流、incast、matched-world、pair matrix 和 W4 A/B 将问题约束到“大规模同步、多 rail、多节点覆盖和网络行为耦合”的范围。单跨机流可接近单 200G rail 有效上限，固定坏节点/固定坏 pair 被复测明显削弱。channel、rail、GPU mapping 会影响行为但未形成稳定修复。交换机拥塞、PFC、ECN、CNP、shared buffer、ECMP 仍是可能解释，但当前缺少 host rail→switch port、queue、pause、CE/CNP、drop/retry、per-port bytes 等 ground truth，不能写成已证实根因。

这段话的优点：

text
事实和候选分开；
支持和边界分开；
没有过度命名物理机制；
明确下一步需要什么；

20. 如何和不同角色沟通 ​

20.1 和训练侧沟通 ​

训练侧关心：

text
能不能恢复吞吐；
默认配置怎么设；
要不要避开某些节点；

你应该说：

text
当前没有证据支持固定坏节点优先剔除；
默认态保持 quad rail、默认 channel、unset GPU visibility；
继续大规模实验前应先拿 ground truth 或做低风险对照；

20.2 和通信库开发者沟通 ​

通信库开发者关心：

text
algorithm/protocol/channel 选择；
QP/HCA/rail 映射；
日志可见性；

你应该请求：

text
打印实际 algorithm/protocol；
打印 channel→HCA/QP；
打印 rank order；
提供 tuning 参数安全范围；

20.3 和网络组沟通 ​

网络组关心：

text
哪个时间窗；
哪些 host/port；
什么流量；
需要哪些 counter；

你应该给：

text
run_id；
绝对时间窗；
host list；
HCA/rail list；
目标机制；
counter 清单；

20.4 和 agent 沟通 ​

agent 容易过度推断。你要明确要求：

text
不要直接给根因；
按 evidence map 输出；
每个结论写不能证明什么；

21. 后续路线：如果继续做工程 ​

21.1 优先级 1：补可见性 ​

text
MCCL algorithm/channel/QP/HCA 日志；
rank→GPU→HCA→rail 表；
per-rank timeline；

21.2 优先级 2：补网络 ground truth ​

text
host rail→switch port；
QoS mapping；
time-window counters；
ECMP hash/group；

21.3 优先级 3：低风险端侧复核 ​

text
小规模 QP/rail matrix；
matched-world 复测；
message size sweep；
rank mapping sweep；

21.4 优先级 4：修复验证 ​

只有当某个候选有明确证据，才做修复 A/B：

text
改 channel；
改 rank placement；
改 rail selection；
网络侧 QoS 调整；

且必须有回滚和停止条件。

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

22.1 什么是 evidence map？ ​

答案方向：

text
把每个候选机制的支持证据、反证、替代解释、置信度、下一证据放在同一张表里，避免直接猜根因。

22.2 为什么固定坏节点不是优先根因？ ​

答案方向：

text
因为原始最差 pair 复测恢复，且没有稳定双向慢、方向性慢和节点边际异常。

22.3 为什么仍不能排除交换机机制？ ​

答案方向：

text
因为缺少交换机 port、queue、PFC/ECN/CNP/drop/retry 等 ground truth。端点观测不足以反证所有网络机制。

22.4 和网络组沟通时最关键的信息是什么？ ​

答案方向：

text
run_id、时间窗、host/rail 列表、需要的端口/queue/counter，以及每个字段用于区分哪个候选。

22.5 最终报告为什么不能只有一个根因？ ​

答案方向：

text
当前证据支持跨层耦合和候选排序，但没有单一机制闭环。给单根因会过度推断。

23. 最终报告模板 ​

你可以直接用这个结构写最终报告。

23.1 标题 ​

text
Muxi 512 RoCE Fabric 行为归因报告

23.2 摘要 ​

必须包含：

text
问题是什么；
已确认事实；
最强候选；
被削弱候选；
不可判定项；
下一步 ground truth；

23.3 背景 ​

写清：

text
集群规模；
HCA/rail；
GID；
benchmark；
消息大小；
指标口径；

23.4 证据 ​

按实验阶段写：

text
W0 timing / baseline；
W1 matched-world；
W2 pair matrix；
W3 QoS visibility；
W4 channel/rail/GPU A/B；

每个阶段都要写：

text
目的；
方法；
结果；
支持什么；
不能证明什么；

23.5 候选排序 ​

使用 evidence map。

23.6 决策 ​

写：

text
是否继续实验；
是否请求网络组；
是否请求 MCCL 支持；
是否先停止大规模作业；

24. 决策树：下一步该做什么 ​

24.1 如果拿不到网络组数据 ​

text
不要继续宣称物理机制；
做低风险端侧复测；
补 per-rank/per-channel 可见性；
整理匿名化行为数据；

24.2 如果拿到 host→switch port ​

下一步：

text
把 pair matrix 对齐物理端口；
检查慢点是否集中到端口/leaf/uplink；
重新评估聚类；

24.3 如果拿到 queue/PFC/ECN counter ​

下一步：

text
按 run_id 时间窗计算 delta；
对齐带宽曲线；
判断 PFC/ECN 是否闭环；

24.4 如果 MCCL 提供 channel/QP/HCA 日志 ​

下一步：

text
解释 W4 channel/rail/GPU A/B；
判断 rail 使用是否均匀；
判断 QP/flow entropy 是否足够；

24.5 如果某个机制闭环 ​

才进入修复验证：

text
预注册成功门槛；
小规模 A/B；
回滚方案；
多次复测；
再扩大规模；

25. 最后的元规则 ​

Muxi 512 这类问题最难的不是没有猜想，而是猜想太多。最终报告要克制：

text
宁可写“无法区分”，不要写错的确定结论。
宁可给候选排序，不要给单点故事。
宁可请求 ground truth，不要用热力图命名物理设备。

这就是整套 8 周学习的目的。