跳到主要内容

ISSUE-029 — G5 仿真 RX 端缺 chip 级聚合带宽 cap

字段值
日期2026-05-27
状态根因已锁定 （更新 2026-05-29）：G5 接收端 (RX) 缺 chip 级聚合 cap, P1 实验已证实。修复方向 = RX 端新增 chip 级聚合 cap （镜像 TX），待 spec 冻结
类型建模缺陷 (modeling bug) — 非口径问题，仿真产出违反物理上限
影响范围G5 仿真 PAXI RX 路径 (paxi.rs) + validation 报告 docs/validation/EP拓扑路由评估/report.md KA2 结论 （B/C 形态 torus 优势虚高 ~2.7×）. 拓扑生成 edge BW 语义正确，不需改。

结论速览 (2026-05-29)​

根因：G5 PAXI 接收端 (RX) 缺 chip 级聚合带宽 cap. TX 端有 (PhyLink 8 LG 串行化到 400 GB/s), RX 端 PAXIBridge::receive_packet 只做 PSN 校验 + ACK MERGE，无速率约束 → 单 chip 接收聚合可无上限突破 SG2262 物理 cap （400 GB/s 单向）.

证实：torus-3D 4x4x4 C heavy 单 cell, cap off = 148.72 GB/s （反推 chip 0 RX = 1075 GB/s, 2.7× 物理上限）；cap on (RX 400 cap) = 54.89 GB/s (chip 0 RX = 397 ≈ 400)，与 fat-tree 持平。

性质：modeling bug （仿真产出违反物理），非口径问题。修复方向 = RX 端新增 chip 级聚合 cap，镜像 TX. 详见 §实验验证 / §根因分析 / §解决方案。

下方 §问题现象 / §调查过程 是初始诊断 （怀疑 edge BW 语义错位） 的推理痕迹，已被 §根因分析 修正 — 真实根因不在 edge BW magic constant，在 RX 缺 cap. 保留作调查历史。

问题现象​

perfmodel/topology/families/*.py 全部 9 个拓扑族文件 （torus / fat_tree / dragonfly / dragonfly_plus / hypercube / hyperx / simple / ring 等） 各自硬编码：

_DEFAULT_LINK_BW_GB_PER_S = 400.0

被赋给每个 EdgeSpec.bandwidth_gb_per_s。按 perfmodel/arch/topo_routing/graph.py:39 注释，bandwidth_gb_per_s 是 per-edge 单方向聚合带宽。

按 SG2262 规格 (docs/specs/G5仿真建模/G5-RC-Link传输层设计规格.md:567)：

"8 LG 聚合上限 = num_link_groups × line_rate_per_lg = 8 × 50 = 400 GB/s（与 SG2262 spec intra_bw = 400 GB/s 一致）"

即 400 GB/s 是 per-chip 总聚合 C2C 上限，不是 per-edge。

语义错位：代码把 chip 级 cap 当成 edge 级 cap 直接赋给每条 edge。对 chip_radix > 1 的拓扑 (torus / hypercube)，单 chip 出向 edge 聚合 BW 超过 SG2262 硬件上限：

拓扑chip_radix代码隐含 chip 出向聚合SG2262 spec 上限偏差
fat-tree-k1611 × 400 = 4004001× （一致）
torus-3D 4x4x466 × 400 = 24004006× 过配
hypercube-6d66 × 400 = 24004006× 过配
dragonfly视实例≥ 400400视实例

调查过程​

[假设 1] （初始） PhyLink 是 binding constraint, torus 多发 6× edge BW → report KA1 是 modeling artifact​

[查代码] perfmodel/topology/families/torus.py:24 _DEFAULT_LINK_BW_GB_PER_S = 400.0, line 188 赋给 EdgeSpec. 6 个邻居 × 400 = 2400 GB/s per chip.

[查实际 G5 行为] perfmodel/evaluation/g5/src/tier6/c2c_network.rs:75-94 PhyLink::transmit 使用 edge bandwidth_bytes_per_ns 做 serialization. 边带宽是 400 GB/s.

[查 PAXI 行为] perfmodel/evaluation/g5/src/top/multi_chip/setup.rs:119:

line_rate_bytes_per_ns: paxi_yaml.tx.line_rate_per_lg_bytes_per_ns,

来自 SG2262.yaml line_rate_per_lg_bytes_per_ns: 50 × num_link_groups: 8 = 400 GB/s chip aggregate. 这是另一处独立的 chip-level cap.

[查实测数据] docs/validation/EP拓扑路由评估/report.md KA1: torus-3D 4x4x4 N=64 heavy A-uniform 实测 395.8 GB/s ≈ 400 GB/s. 不是 2400 GB/s.

[结论] 假设 1 被实测数据反驳。PAXI 8 LG × 50 = 400 GB/s aggregate 看起来已经在 binding, edge BW 400 没暴露为 bottleneck.

[假设 2] PAXI 是真正 binding constraint, edge BW 过配但不影响结果 → report 结论 OK​

[支持证据] 实测 395.8 ≈ 400 chip cap，跟 PAXI aggregate 一致。

[反对证据] B preEPLB 形态下 （单点 incast 到 chip 0）：

  • fat-tree-k16: 20.7 GB/s
  • torus-3D 4x4x4: 55.2 GB/s

如果都被 PAXI 卡死 400 GB/s，这两个数字差距不应这么大。差距说明 edge contention 还是起作用 — fat-tree 单 uplink 是瓶颈，torus 多邻居分担接收侧路径。即 edge BW 配置确实在仿真结果里有影响。

[假设 2 不能完全成立]. PAXI 在 A-uniform 下卡顶，但 B preEPLB 下 edge 拥塞才是主导因素。

[假设 3] （当前最可能） PAXI 卡上限，edge BW 影响 incast 形态的 contention 程度 → report 在 A 形态结论安全，B/C 形态结论受 edge BW 过配影响​

A-uniform：流量均匀，PAXI line_rate 是瓶颈 （chip 出向 cap），edge 配 400 远超 （200+ GB/s 实际占用） 也不会成 bottleneck. → 数字"巧合"正确

B preEPLB：流量集中 → chip 0 入向多 src 流汇聚 → 单条 edge 上 contention 直接 gate. torus 6 个入向 edge 分摊 vs fat-tree 1 个入向 edge 全承担。这里 edge BW 配 400 vs 实际 SG2262 单 LG 可承载值 （≤ 50，或视 LG 分配策略） 差距大。→ 报告里 torus 优势 2.5-3× 可能是 edge 过配产物

C postEPLB：流量再次分散，介于 A 和 B 之间。

[未 verify] 改 _DEFAULT_LINK_BW_GB_PER_S = 400 → 50 重跑 torus-3D 4x4x4 N=64 ECMP，看 A vs B 结果各自变化幅度。已写实验脚本 scripts/debug_link_bw.py，待 G5 Rust 扩展重建完成才能跑。

[实验阻塞]​

[查代码] G5 Rust 入口 simulate_multi_chip 签名：

  • 当前 site-packages g5_rs (2026-04-30) 装的 9 参数版本
  • 当前 Rust 源 (perfmodel/evaluation/g5/src/lib.rs:65) 是 10 参数版本 (新增 policy_descriptor + declared_state_fields)

需 maturin develop --release 重建 + 安装。重建完成后跑了 ad-hoc 1 cell + 矩阵 stats 分析 （见下方 [假设 4]）.

[假设 4] （强证据） B/C 形态下 chip 接收侧 (RX) 过配是核心问题，不只是 TX 侧​

[实验] 用 scripts/debug_c_matrix.py 生成并分析 C-heavy 矩阵 (M3-heavy-C-postEPLB, N=64):

A heavy (uniform+naive):     Gini=0.13, dst col 7.9-8.4 MB    (近均匀)
B heavy (longtail+naive):    Gini=0.68, dst col chip 0 集中    (单点 incast)
C heavy (longtail+interleave): Gini=0.43, dst col chip 0=58.8MB, chip 63=3.3MB, max/min=17.8×

关键发现：C 矩阵远未 "完美均衡" — Zipf 分布的 token routing × stride placement 把热门 expert 散到低 ID chip, chip 0 接收量仍是平均的 7×, max/min = 17.8×.

[数学] 对 torus-3D C heavy 实测 per-chip BW = 148.7 GB/s，反推 chip 0 RX 速率：

  • bytes_per_chip = 520 MB / 64 = 8.13 MB
  • T_a2av = bytes_per_chip / BW = 8.13e6 / 148.7e9 = 54.7 us
  • chip 0 接收 58.8 MB / 54.7 us = 1075 GB/s

1075 GB/s 是 SG2262 chip cap (400 GB/s) 的 2.7 倍，物理不可实现.

[对照] fat-tree-k16 C heavy 实测 per-chip BW = 59.5 GB/s:

  • T = 137 us; chip 0 RX = 58.8 / 137 = 429 GB/s ≈ chip cap 400 （轻微越界，可能近似截断）
  • fat-tree 因 chip_radix = 1，单条 PhyLink × 400 GB/s 即 chip cap，不存在多 link 聚合 > cap 问题

[结论] TX 端 PAXI 8 LG × 50 = 400 GB/s cap 起作用 （解释 A heavy ~395），但 RX 端没有等效 chip 级聚合 cap. torus chip 0 同时从 6 个邻居以各自 400 GB/s 接，仿真允许聚合 6 × 400 = 2400 GB/s，实际跑出 1075. 这是假设 1 在 B/C 流量集中场景下的具体体现。

[影响] 报告 KA2 "torus 比 fat-tree 强 1.1-3.2×" 在 B/C 行 (2.5-3.1×) 不可信。推算 RX cap 真实限制下，torus C heavy 应为 ~55 GB/s （跟 fat-tree 持平），而不是 148.7.

verify 结论 （root cause 已锁定，2026-05-29）​

三条 verify 全部完成，结论汇总：

[verify 1 — 已确认] intra_bw = 400 GB/s 是 per-direction （单向）

  • docs/specs/G5仿真建模/G5-RC-Link传输层设计规格.md:567 "8 LG × 50 = 400 GB/s" 描述的是单向 TX 聚合；SG2262.yaml:106 line_rate_per_lg_bytes_per_ns: 50 是单 LG 单向 SerDes 线速。
  • 即 chip 级单向 cap = 400 GB/s, TX / RX 各自独立 400 （双向总 800）.
  • [推论] chip 0 在 C heavy 实测反推的 RX = 1075 GB/s 是单向接收速率，对照单向 cap 400 → 超 2.7×，物理不可实现。确认是 modeling 越界，不是 per/bi-direction 口径误读。

[verify 2 — 已确认] G5 接收端 (RX) 确实没有 chip 级聚合 cap

  • 查 perfmodel/evaluation/g5/src/tier6/paxi.rs: PAXIBridge 持 per-LG Vec<RcLinkTx> + Vec<RcLinkRx>.
  • TX 路径：PhyLink::transmit 用 busy_until_ns 串行化，8 LG 聚合受 chip 级 400 GB/s 约束 [有 cap].
  • RX 路径：PAXIBridge::receive_packet → RcLinkRx::receive_packet 只做 PSN 校验 + ACK MERGE, 无 serialization / 无 rate limit [无 cap].
  • [结论] 这是确认的 modeling gap: TX 有 chip 级聚合约束，RX 没有镜像。torus chip 0 同时从 6 个邻居各自接收，仿真允许 RX 聚合无上限，实测跑出 1075 GB/s.

[verify 3 — 已确认] SG2262 的 8 LG 是动态 hash 分发，不是静态均分到邻居 → 直接否决方案 A

  • SG2262 PAXI 用 hash-based ITLV 把 packet 分发到 8 LG 池，与 dst chip 无关 （统一 8 LG 池，不是 per-neighbor 静态切分）.
  • [推论] issue 原 §解决方案 A (edge BW = 400 / chip_radix) 的前提 "LG 静态均分到 chip_radix 个邻居" 不成立. 真实硬件是：单条 edge 物理上可占满 8 LG = 400 GB/s （当其它邻居空闲时），chip 级约束体现在 "8 LG 总池" 而非 "每邻居固定份额".
  • [结论] 正确建模应在 chip 级 （8 LG 总池） 加聚合 cap，而不是切碎到每条 edge. 这同时解释了为什么方案 A 会破坏已正确的 A-uniform 结果 （见 §解决方案）.

实验验证 (P1 minimal)​

[实验设置] 给 G5 加 env 门控开关 G5_ENABLE_CHIP_RX_CAP (paxi.rs + setup.rs，默认 off):

  • off：维持当前行为，RX 无 chip 级 cap (baseline)
  • on: RX 端启用 chip 级聚合 cap = num_link_groups × line_rate_per_lg = 8 × 50 = 400 GB/s，镜像 TX 端 PhyLink 的 busy_until_ns 串行化

[实验 cell] torus-3D 4x4x4 N=64, M3-heavy-C-postEPLB （Gini=0.43, chip 0 集中），ECMP 路由，单 cell.

[结果]

指标cap off (baseline)cap on (RX 400 GB/s)
per-chip BW148.72 GB/s54.89 GB/s
total time54.61 us147.98 us
chip 0 RX 实际速率1075 GB/s397 GB/s

[四重交叉验证] 根因 100% 闭合：

  1. baseline 复现：148.72 ↔ report 报告值 148.7 （误差 0.01%）
  2. cap on 命中预测：§假设 4 推算 "RX cap 下应为 ~55"，实测 54.89 （误差 0.2%）
  3. 物理对齐：cap on 后 chip 0 RX = 58.8 MB / 147.98 us = 397 GB/s ≈ SG2262 单向 chip cap 400
  4. 假优势消失：148.72 / 54.89 = 2.71× 的 torus "优势" 被 cap 完全消除，与 fat-tree C heavy (59.5 GB/s) 持平

根因分析​

根因 （已确认）：G5 仿真的 PAXI 接收端 (RX) 缺少 chip 级聚合带宽 cap. TX 端 PhyLink::transmit 有 busy_until_ns 串行化 （8 LG 聚合受 chip 级 400 GB/s 约束），RX 端 PAXIBridge::receive_packet 只做 PSN 校验 + ACK MERGE，无对应约束。这导致单个 chip 的接收聚合带宽可以无上限超过 SG2262 物理上限 （400 GB/s 单向）.

性质判定：这是 modeling bug，不是口径问题. 判据 — cap off 时 chip 0 RX 跑出 1075 GB/s，是 SG2262 单向 chip cap (400) 的 2.7×，物理不可实现。模型产出了违反物理的状态，不是数字解读分歧。

触发条件：skewed (B/C) 流量 + 高 radix 拓扑。A-uniform 流量下各 chip RX 均匀 （~395 GB/s 接近但不超 cap），bug 不暴露；B/C 形态流量集中到少数 chip, RX 聚合突破 cap, torus / hypercube 等高 chip_radix 拓扑因可同时从多邻居接收而虚高。

为什么不是 edge BW magic constant 问题：9 份 _DEFAULT_LINK_BW_GB_PER_S = 400.0 在语义上是正确的 — 单条 edge 物理上确实能占满 8 LG = 400 GB/s (verify 3). 问题不在 edge BW 数值，在 RX 端缺少 chip 级聚合约束。原 issue 把根因归到 edge BW magic constant 是误判。

Spec / 文档依据​

来源数字含义与代码关系
docs/specs/G5仿真建模/G5-RC-Link传输层设计规格.md:559line_rate_per_lg_bytes_per_ns: 50 = per-LG SerDes 线速G5 sim 通过 setup.rs:119 接到 PAXIBridge — 数据流通
docs/specs/G5仿真建模/G5-RC-Link传输层设计规格.md:567num_link_groups × line_rate_per_lg = 8 × 50 = 400 GB/s = SG2262 chip C2C 聚合上限 (intra_bw)跟 PAXI 8 LG 模型对齐 — 仿真已尊重此 cap
docs/specs/拓扑生成器设计规格.md:58chip_radix = 单 chip 对外 c2c 端口数，默认 1拓扑族读取并用于 multi-edge invariant 校验，但未反推单 edge BW
configs/chips/SG2262.yaml:128 注释"默认 50 = 400 GB/s 总聚合 ÷ 8 LG （SG2262 112G 配置）"注释明确 400 是聚合，但代码端没用这个口径
perfmodel/topology/families/*.py （9 处）_DEFAULT_LINK_BW_GB_PER_S = 400.0 硬编码未引用任何 spec 字段，数据流断点

业界对比​

仿真器处理方式
BookSimper-link channel BW 由用户配置，不与 chip 级聚合联动 （用户自己保证一致性）
SST/Merlin同上，把 chip 级总注入率独立于 link BW 建模
ASTRA-sim用 chunk_size / link_bandwidth 计算 link 延迟，link BW 独立配置

业界普遍把 chip 注入率和 link BW 分离建模，但要求 user 保证 link BW ≤ chip 注入率 / chip_radix. 当前 perfmodel 没做这个一致性校验，硬编码 default 也没体现这个约束。

解决方案​

[备选]

方案 A: edge BW 从 chip spec 反推​

修改 9 个拓扑族文件，让 _DEFAULT_LINK_BW_GB_PER_S 不再硬编码，而是 build_*() 时按 chip.paxi.num_link_groups × chip.paxi.tx.line_rate_per_lg_bytes_per_ns / chip_radix 反推每条 edge 的 BW:

# pseudocode
chip_aggregate_bw = chip.paxi.num_link_groups * chip.paxi.tx.line_rate_per_lg_bytes_per_ns
per_edge_bw = chip_aggregate_bw / chip_radix  # GB/s
edge.bandwidth_gb_per_s = per_edge_bw

torus-3D 4x4x4 chip_radix=6 → per edge = 400/6 ≈ 67 GB/s. fat-tree-k16 chip_radix=1 → per edge = 400/1 = 400 GB/s.

优点：edge BW 物理上反映 SG2262 真实分摊； 风险：需要重跑 477 cell 实验，KA1/KA2 结论可能改变。

方案 B：显式承认 modeling 假设，改 report 口径​

在 docs/validation/EP拓扑路由评估/design.md 平台参数段补充说明："本仿真把每条 edge BW 都视为 400 GB/s，不模拟 SG2262 chip 级 C2C 聚合 cap. 因此本研究结论适用 '高度宽 fabric 假设'，不直接代表 SG2262 实际部署." report KA1/KA2 维持原数据，但加 boundary note.

优点：不改代码，报告改个口径快； 风险：模型脱离硬件现实，后续部署决策仍可能误用。

方案 C：引入 chip 级 aggregate cap （新增 enforcement）​

不改 edge BW，但在 C2CNetwork 或 PAXIBridge 增加 per-chip aggregate egress / ingress 监控。这是 spec G5-RC-Link 1.2.0 已经做的：PAXI ITLV + DCQCN + MAC credit 已经隐含限速到 400 GB/s. 验证这个 enforcement 在所有形态 (A/B/C) 下都生效，不被 edge 大 BW 配置短路。

优点：跟 spec 设计对齐； 风险：实测数据 395.8 ≈ 400 chip cap 暗示这个机制可能已经在生效，需要更精细的 trace 验证。

[采用] 方案 C 变体：RX 端新增 chip 级聚合 cap （镜像 TX）. verify 1-3 + P1 实验已锁定。决策记录：

方案裁决理由
方案 A (edge BW = 400/chip_radix)否决verify 3: SG2262 是动态 hash LG 池，非静态均分；方案 A 静态切分与硬件不符。且会破坏已正确的 A-uniform 结果 — 把每条 edge 限到 67 GB/s, chip 想全速发单邻居只能 67 而非 400, A 形态实测 395.8 会被错误压低。物理约束在 RX 聚合，不在 src 侧 edge.
方案 B （只改 report 口径）否决P1 实验证明是真 modeling bug （产出违反物理的 1075 GB/s），不是口径问题，必须修代码。
方案 C 变体 （RX 端新增 chip 级聚合 cap）采用镜像 TX 端 PhyLink 串行化模型，在 RX 端按 num_link_groups × line_rate_per_lg = 400 GB/s 加聚合约束。P1 实验已验证：cap on 后 chip 0 RX = 397 ≈ 400，各形态物理自洽。edge BW = 400 保持不变。

注：issue 原 §解决方案 C 描述假设 "PAXI ITLV + DCQCN + MAC credit 已隐含 RX 限速，验证是否生效" — verify 2 证明此假设 错误，RX 端根本没有该 enforcement. 实际方案是 新增 RX chip 级 cap，不是验证已有。

[涉及文件 （方案 A）]

  • perfmodel/topology/families/torus.py:24
  • perfmodel/topology/families/fat_tree.py:30,32
  • perfmodel/topology/families/dragonfly.py:29,31
  • perfmodel/topology/families/dragonfly_plus.py:32,34
  • perfmodel/topology/families/hypercube.py:23
  • perfmodel/topology/families/hyperx.py:30
  • perfmodel/topology/families/simple.py:28
  • 调用方 （验证脚本）：docs/validation/EP拓扑路由评估/scripts/builders.py
  • 受影响报告：docs/validation/EP拓扑路由评估/report.md （KA1/KA2 数字需重跑）

验证 (Acceptance Criteria)​

  1. 实验数据：_DEFAULT_LINK_BW_GB_PER_S 在 {400, 50} 两个值下，跑 torus-3D 4x4x4 N=64 ECMP × {M1 heavy A-uniform, M2 heavy B-preEPLB}，报告 per-chip BW. 用于决定方案 A vs B/C.
  2. 一致性检查：chip 级 aggregate cap (PAXI 8 LG × 50 = 400 GB/s) 与 edge BW 反推值之间无歧义 （任一形态下不出现 chip 出向 > 400 GB/s）.
  3. 报告更新：不论方案如何，validation report 需 explicit 写出 modeling 假设。

Lessons Learned / Prevention​

  1. Magic number 应跟 spec 字段联动：9 份独立 400.0 constants，没有任何文档 / 注释指向 spec 来源。建议任何"默认硬件参数"都加注释指 spec section + 字段名 (例：# = SG2262.yaml paxi.num_link_groups × paxi.tx.line_rate_per_lg_bytes_per_ns / chip_radix).
  2. spec 跟实现的数据流要可追溯：当前 _DEFAULT_LINK_BW_GB_PER_S 跟 SG2262 spec 之间没有数据流，只是数字相等的巧合 （per-edge 400 vs per-chip 400，单位不同）. 类似的"语义错位"风险需要在 spec 审核时显式检查。
  3. 拓扑生成器和性能仿真的 BW 模型应统一：拓扑生成器用 edge BW 概念，G5 仿真器用 chip line_rate 概念，两者各自有 cap. 应有一个统一的"chip 级 aggregate BW"定义，拓扑生成器从 chip spec 反推 edge, G5 仿真器直接读 chip line_rate.

遗留问题​

  • 根因已锁定 （RX 缺 chip 级聚合 cap），修复方向已选定 （方案 C 变体）. 当前为 env 门控 (G5_ENABLE_CHIP_RX_CAP) 实验性实现，待 spec 冻结后改配置驱动 + 默认 on.
  • 报告 docs/validation/EP拓扑路由评估/report.md 在 issue 闭合前不应作为部署决策依据：KA1 A 形态数字安全 （~395 接近物理 cap），KA2 B/C 形态 torus 优势虚高 ~2.7×，已判定为 modeling artifact，修复后需重跑。
  • G5 Rust 扩展已重建装好 (cp314 wheel)；根目录 stale g5_rs.pyd 已替换为新版。

下一步行动 （按优先级）​

verify 1-3 + P1 实验已完成 （见上）. 剩余：

优先级行动解锁什么
P2iforge-discuss：对齐 RX chip 级 cap 的建模决策 （cap 值来源 / 配置字段 / 默认 on vs gated / 与 DCQCN 交互）进入正式修复
P2iforge-spec：在 G5-RC-Link 设计规格补 "RX 端 chip 级聚合 cap" 章节，镜像 TX §芯片级聚合吞吐冻结设计
P3iforge-act：把 G5_ENABLE_CHIP_RX_CAP env 门控改为配置驱动 + 默认 on；加 unit test （多源 incast 单 chip RX 总和 ≤ 400）实施
P3全量重跑 477 cell + 重写 report KA1/KA2 （B/C 形态数字下修 ~2.7×, torus 优势归零）闭合 issue