ISSUE-032：旧 report 的 EPLB 收益 (2-3×) 被过强 incast 假设夸大，实测偏度下真实收益 1.1-1.5×
发现日期：2026-06-02
状态：已确认（非 bug — 接收端建模正确，旧 report 假设错误）
类型：报告结论修正（建模正确，结论依据 outdated）
影响范围：topo-routing-comm-eval report.md 的 KA1 核心结论（EPLB 提升幅度）。不影响 G5 代码（接收端建模符合 spec）。
问题现象
重写 report 时发现：v3 数据集（= v2 一致）的 EPLB 提升只有 1.08-1.46×，但旧 report.md(2026-05-27)KA1 写的是 2.3-2.9×。差一个量级，且方向性结论（EPLB 是决定性杠杆）受影响。
具体（fat-tree-k16 N=64 ecmp heavy tok256,per-chip 出向 GB/s）：
| 形态 | 旧 report 假设 | v3 实测 |
|---|---|---|
| S0 完美均衡 | 245.6 | 293.7 |
| S1 未开 EPLB | 20.7 | 271.4 |
| S2 开启 EPLB | 59.5 | 294.4 |
| EPLB 提升 (S1→S2) | 2.87× | 1.08× |
旧 report 假设"未开 EPLB 时瓶颈在目的芯片接收端口，吞吐压到硬件 5-15%"（对应 S1=20.7），v3 实测 S1=271，几乎不压制。
调查过程
-
[查代码]
configs/chips/SG2262.yaml:num_link_groups=8,line_rate_per_lg=50 B/ns→ 单 chip 出向 = 8×50 = 400 GB/s。 -
[查代码]
setup.rs:123确认 RX cap 注入生效：rx_line_rate_per_lg_bytes_per_ns = paxi_yaml.tx.line_rate_per_lg_bytes_per_ns = 50→ 接收聚合上限 = 8×50 = 400 GB/s，与出向对称。 -
[实验] v2 vs v3 同坐标对比：S1 = 268(v2)vs 271(v3)，差 1%。确认 S1 数据非 dispatch 重构引入，旧 report 的 20.7 是 pre-v2 过时实验数据。
-
[实验] 接收矩阵 incast 程度：S1 形态 RX max/mean = 1.62（符合 s1_target=1.6 设计，接收侧扎堆；TX 侧 max/mean≈1.0 发送均匀）。
-
[实验] 决定性验证 — incast chip 接收串行时间 vs critical path（T 从 busbw 反推）：
拓扑 形态 T_actual 接收 incast 串行时间 critical path fat-tree S0 36.9μs 29.0μs 网络（T > 接收，差额 = spine 争抢） fat-tree S1 39.9μs 44.0μs 接收 incast（网络也占） torus S0 29.1μs 29.0μs 接收（T ≈ 接收，网络不瓶颈） torus S1 42.2μs 44.0μs 接收 incast -
[实验] 偏度敏感性佐证(s1_target 1.4/1.6/2.0,heavy):torus 299/257/211（随偏度单调降，接收瓶颈显现），fat-tree 279/271/250（对偏度不敏感，网络先瓶颈）。若 RX cap 不生效，torus 不会对偏度敏感 → 反向证明接收端建模在起作用。
根因分析
两层瓶颈结构，接收 incast 是否进 critical path 取决于网络是否先瓶颈：
-
fat-tree 网络先瓶颈：每芯片单 uplink（度=1）接 leaf，跨 leaf 流量争 8 个 spine 容量。S0 完美均衡时 busbw 已卡在 293 < chip 400 上限，瓶颈在网络。incast(S1)来了只把 critical path 从网络部分推向接收，EPLB 缓解 incast 的收益被网络瓶颈稀释 → 1.08×。
-
torus 网络充足：每芯片直连 6 邻居（度=6，聚合 2400 GB/s），网络不瓶颈。S0=372 接近 chip 400 上限，瓶颈已在接收端。incast(S1)直接把接收 incast chip 推成 critical path（42.2μs ≈ 接收时间 44μs），EPLB 缓解 incast 收益大 → 1.46×。
接收端建模正确（对称 400 GB/s，符合收发共用全双工 SerDes 的硬件事实）。EPLB 收益 1.1-1.5× 是真实结论。
旧 report 错在 incast 假设过强："压到 5-15%" 需要 incast 倍数 7-20×（单 chip 接收近全部流量）。但 design 设计的偏度是 RX max/mean 1.4-2.0，锚定实测(NVIDIA TRT-LLM DeepSeek EP32 = 1.56,SGLang up to 2.0)。实测偏度下 incast 温和(1.62)，接收时间只 1.62× 均值，压制有限。
Spec / 文档依据
configs/chips/SG2262.yaml: num_link_groups=8, line_rate_per_lg=50 → 收发对称 400 GB/s。docs/specs/G5仿真建模/G5-RC-Link传输层设计规格.md§芯片级聚合接收 cap：接收上限 = num_link_groups × rx_line_rate，收发复用同一全双工 SerDes。design.md§流量形态：偏度档 {1.4,1.6,2.0} 锚定 NVIDIA/SGLang 实测，非极端假设。
解决方案
不改代码（接收端建模正确）。修正 report 结论：
- KA1 重写：EPLB 收益从"2-3× 决定性杠杆"改为"实测偏度下 1.1-1.5×，且收益依赖网络是否先瓶颈"。
- 机理写清：EPLB 缓解的是接收 incast；只有当网络带宽充足（如 torus）时 incast 才是瓶颈，EPLB 收益才显现；网络先瓶颈的拓扑（如 fat-tree）EPLB 收益被稀释。
- 适用范围标注：EPLB 收益强依赖偏度。实测偏度 1.4-2.0 下温和；若专家负载更极端（偏度 >> 2），incast 加剧，EPLB 收益会更大。旧 report 的 2-3× 对应极端假设，不符合实测。
验证 (Acceptance Criteria)
- v2/v3 同坐标一致（排除 dispatch 重构引入）
- RX cap 注入生效（setup.rs:123 = 50，非 0）
- incast chip 接收时间 = critical path(torus S1: 44μs ≈ T 42μs)
- 偏度敏感性佐证（torus 敏感 / fat-tree 不敏感）
- 收发带宽对称（8×50 = 400 GB/s 双向）
Lessons Learned / Prevention
- report 数字必须标注数据来源版本：旧 report 混入了 pre-v2 过时实验数据(S1=20.7)，与当前数据集差一个量级却未察觉。重写后所有数字应注明 v3 + 实验日期。
- 结论依赖的隐含假设要显式写出：旧 report 的"EPLB 2-3×"隐含"incast 极端到压制 5-15%"的假设，但正文没写明，导致结论看似稳健实则建立在未声明的极端假设上。偏度这种关键 knob 必须在结论里显式标注取值范围。