跳到主要内容

ISSUE-005: G5 单 PAXIBridge 实例导致 TX datapath 成为吞吐瓶颈

发现日期：2026-04-28 状态：已修复，已验证 （v2 实现按 spec v1.2.0 per-LG 独立 RC Link 模型；198/198 单元测试通过；端到端验证 NAK=0 + 8 LG 完美均衡 + Ring 类 5.95x→2.37x 显著加速） 类型：建模误差 影响范围：所有 C2C 通信场景。中大消息（>100KB）延迟膨胀 5-6x，小消息（<32KB）影响较小（PAXI 事务开销被 startup latency 掩盖）。

历史记录说明：调查过程中引用的 docs/design/PAXI/ 和 docs/design/2262-C2C/ 路径在 2026-06-01 docs 重组中已删除；原硬件 spec 整理的核心数值与协议描述已沉淀进 docs/specs/G5仿真建模/G5-PAXICore事务层设计规格.md、G5-RC-Link传输层设计规格.md、G5-CDMA建模设计规格.md。下文路径保留作历史快照，不再可达。

问题现象​

64 芯片 TP=2 配置下，G5 仿真延迟远高于 Math 基线：

ModulePrimitiveSize (MB)G5 (us)Math (us)G5/Math
Dense_MLPallreduce0.437511.6791.9645.95x
MLAallgather1.12519.8393.9675.00x
MLAreducescatter1.017.6633.6034.90x
DSAtopk_allgather0.031250.7990.7811.02x

小消息 (32KB) 基本对齐，中大消息出现 5-6x 的系统性差距。

调查过程​

  • [查代码] multi_chip.rs:451 -- line_rate_bytes_per_ns = paxi_yaml.tx.datapath_bytes，值为 64（512-bit datapath）
  • [查代码] multi_chip.rs:440-462 -- 每个 chip_id 只创建一个 PAXIBridge，所有目标芯片共享同一 TX
  • [查代码] rc_link_tx.rs:306 -- pack_delay = ceil(wire_bytes / datapath_bytes)，1394B 包需要 22 个周期（22 ns）
  • [假设 1] TX datapath 64 bytes/ns 是瓶颈，而非 link 带宽 -> 验证如下
  • [计算验证] AllGather N=2, 1.125MB:
    • MPS 分段：1,179,648B / 4096 = 288 segments
    • Ring 2-port N=2: CW 和 CCW 方向的目标都是同一芯片（(i+1)%2 = (i+N-1)%2 = 1），实际 576 segments（双倍）
    • 每 segment 4 packets (3x1344B + 1x64B) = 2304 packets （双向合计）
    • 但 2-port 两个方向共享同一 TX，实际串行处理 1152 packets（每方向 576 packets 交错调度）
    • TX pipeline: pack_delay(22ns) + link_serial(3.5ns) = ~25.5 ns/pkt（pipeline 重叠后约 22 ns/pkt）
    • 纯 1-port (576 packets): 576 x 22 = 12672 ns
    • 2-port (1152 packets): 1152 x 22 = 25344 ns... 但因为 CW/CCW 发送同样的数据到同一目标，等效不超过 1-port 的 576 packets 就已覆盖全部数据
    • 实际 G5 2-port 延迟 19839 ns ~ 576 pkt x 22 ns/pkt x 1.57 (ACK/credit overhead factor)
    • 估算 19864 ns vs G5 实际 19839 ns，误差 25 ns（0.13%），确认 TX pack_delay 主导
  • [查 spec] docs/design/PAXI/02_architecture.md -- UVIP_PAXI_MAC_DW=512 (64B)，400G 配置应为 1024 (128B)
  • [查 spec] docs/design/PAXI/13_rclink.md -- RC Link DW=512 (PAXI->RC Link)，MAC_DW=1024 (400G)
  • [查 spec] docs/design/2262-C2C/00_overview.md -- 每芯片 8 个 C2C Link Group，每 group 有独立 MAC/PAXI
  • [查 spec] docs/design/2262-C2C/02_cdma.md -- 4 CDMA/Die x 2 Die = 8 CDMA，CDMA-MAC 非固定绑定
  • [查 spec] docs/design/2262-C2C/06_modeling-params.md -- 总 C2C BW=448 GB/s，PAXI 有效=431.9 GB/s
  • [结论] G5 只建模 1 个 PAXIBridge/chip pair，硬件有 8 个并行实例，差距 = 8x 吞吐限制

根因分析​

直接原因：multi_chip.rs 中每个 chip_id 只创建 1 个 PAXIBridge 实例（line 440-462），所有发往不同目标芯片的流量都串行通过同一个 TX datapath。

TX datapath 瓶颈量化：

单 TX 吞吐 = datapath_bytes = 64 bytes/ns = 64 GB/s = 512 Gbps
Link 带宽   = 400 GB/s = 3200 Gbps
瓶颈比     = 400 / 64 = 6.25x

每个 1394B PAXI 包的 TX 处理时间 = ceil(1394/64) = 22 ns，而 link 序列化时间仅 3.49 ns（1394 / 400）。TX pack_delay 占总包处理时间的 86%（22 / 25.5）。

硬件实际架构：SG2262 每芯片有 8 个 C2C Link Group，每个 group 包含独立的 MAC 和 PAXI 实例。聚合吞吐 = 8 x 64 = 512 GB/s，远高于 400 GB/s 的 link 带宽。CDMA 通过 NoC 以 many-to-many 方式接入 MAC，流量可分散到多个 PAXI TX。

次要问题 -- N=2 时 2-port 冗余：Ring 2-port 算法在 N=2 时，CW 方向 dst=(i+1)%2 和 CCW 方向 dst=(i+N-1)%2 指向同一目标芯片。两个方向传输完全相同的数据，包数翻倍但无吞吐增益。当所有包共享同一 TX 时，2-port 反而比 1-port 更慢。

Spec / 文档依据​

原始 Spec（硬件/协议文档）：

UVIP_PAXI_MAC_DW=512 (64 bytes)，当需要 400G 带宽时应配置为 1024 (128 bytes) -- docs/design/PAXI/02_architecture.md

每芯片 8 个 C2C Link Group，每 Group 含独立 MAC/PAXI -- docs/design/2262-C2C/00_overview.md

4 CDMA/Die x 2 Die = 8 CDMA，CDMA-MAC 为 many-to-many 映射 -- docs/design/2262-C2C/02_cdma.md

总 C2C 双向带宽 448 GB/s，PAXI 有效带宽 431.9 GB/s -- docs/design/2262-C2C/06_modeling-params.md

项目 Spec（已有 Issue）：

ISSUE-003 Phase 3 遗留："如果 PAXIBridge 成为瓶颈（OST 耗尽），需要创建多个 PAXIBridge 实例" -- ISSUE-003 （已归档）

与用户确认的行为：

  • [2026-04-28] 确认：link latency 应为 0.025us（物理传播延迟），不是 0.2us（含协议开销的端到端延迟）
  • [2026-04-28] 确认：硬件有 8 个并行 PAXI 实例，G5 只建模 1 个是根因

解决方案​

备选方案​

方案描述优点缺点
A：多 PAXIBridge 实例每 chip pair 创建 N 个 PAXIBridge（N = C2C Link Group 数），CDMA 请求按目标/QP 分发到不同实例精确建模硬件架构，聚合吞吐对齐 spec实现复杂度高，需修改 CDMA 分发逻辑和事件路由
B：提高单 TX datapath 宽度将 datapath_bytes 从 64 提升到 512（等效 8 个并行 TX），作为简化建模改动最小（仅改配置参数）不真实反映硬件分组结构，无法建模组间干扰和负载不均
C: N=2 时退化为 1-port当 ring allgather/allreduce N=2 时，强制使用 1-port 避免冗余立即可做，减少 N=2 场景的无效包不解决根本的 TX 吞吐问题，N>2 仍有差距

推荐方向​

方案 A 为长期正确方向（精确建模多 PAXI 实例），方案 C 作为 quick-fix 先落地（消除 N=2 冗余）。方案 B 可作为临时校准手段验证吞吐模型。

实际采纳方案 （2026-04-28, v2 修订版）​

v1 失败教训：第一次尝试用"单 PAXI Core 共享 PSN + N 个 TX datapath slot + per-packet round-robin"的简化模型，端到端验证触发 NAK 风暴（8000+ 重传）。根因：8 个 LG 并行打包后通过单条 c2c 物理 link 重新串行化，到达 RX 顺序与全局 PSN 顺序不一致 → PSN gap → Go-Back-N。这个简化模型与业界硬件实际不符。

v2 方案：N 个独立 RC Link 实例 (per-LG)——采纳 ISSUE-005 §备选方案 A 的精确实现，参考 IB dual-port HCA / NVLink multi-sub-link / ConnectX 多端口的硬件做法。理由：

  • 业界压倒性走 per-port/per-LG 独立 RC 状态机：IB dual-port HCA / Mellanox ConnectX / NVLink multi-sub-link / CXL multi-stack 均如此
  • 贴 SG2262 spec 的 IP 分层：PAXI Core （单实例，OST 总池/MPS 分段） + 8 组独立 MAC/RC Link （per-LG 物理通道）
  • 物理保序天然：同 segment 的 packet 走同一 LG，单 LG 内 PSN 严格递增，RX 按 (src_chip, lg_id, qp_id) 分别校验，跨 LG 无保序约束 → 零 NAK 风暴
  • 单流场景能用满 8 LG: PAXI Core 在 segment 级别按 ITLV (least_busy_lg) 分发，单笔大消息也能跨 8 LG 并行

关键设计决策：

  1. 状态作用域 — per-LG 独立：

    • PSN 序列：per-(lg_id, dst, qp_id)，每 LG 自己的 12-bit 环形空间
    • Slot 池 (TYPE1_OST=512): per-LG 独立
    • CBFC credit (initial=1024): per-(lg_id, dst, vc_id)，每 LG 与对端 RX 独立账本
    • Retry counter & DCQCN per-QP rate: per-LG
    • RX EPSN: per-(src_chip, lg_id, qp_id)，跨 LG 不互相校验

  2. 状态作用域 — PAXI Core 共享：

    • W/R OST 总池 (256/256)：跨 LG 共享，限制总并发事务数
    • MPS 分段逻辑 （4096B 切 segment）
    • segment 完成聚合 → DataArrived 事件

  3. ITLV 分发粒度：segment 级 （不是 packet 级）

    • PAXI Core 在 submit() 时为每个 segment 选定 lg_id
    • 同 segment 的所有 packet 走同一 LG，保证单 LG 内 PSN 连续
    • LG 选择策略：least_busy_lg （默认） / round_robin / hash(qp_id)

  4. datapath_bytes 与 line_rate 解耦 (新增 paxi.tx.line_rate_per_lg_bytes_per_ns: 50)

    • datapath_bytes=64 决定单包 pack_delay （保持物理意义）
    • line_rate=50 决定 DCQCN 速率上限，单 LG = 400 GB/s ÷ 8

  5. C2CLinkDone 事件契约更新：

    • 必须携带 lg_id, RX 才能路由到正确的 (src_chip, lg_id, qp_id) EPSN 表
    • ACK / NAK / CreditReturn 事件同样携带 lg_id

  6. N=1 退化：

    • num_link_groups=1 时所有状态聚合到单实例，等价于 1.1.0 之前的单 LG 模型
    • 向下兼容已有单元测试

涉及文件（方案 A）：

文件改动说明
perfmodel/evaluation/g5/src/top/multi_chip.rs创建多个 PAXIBridge 实例，按 chip config 的 C2C Link Group 数
perfmodel/evaluation/g5/src/top/event_handlers.rsCDMA 请求分发到对应 PAXIBridge 实例
perfmodel/evaluation/g5/src/tier6/rc_link_tx.rs可能需要支持实例级独立状态
configs/chips/SG2262.yaml可能需要新增 c2c_link_groups 参数

涉及文件（方案 C）：

文件改动说明
perfmodel/evaluation/g5/src/collective/expand.rsN=2 时选择 1-port 而非 2-port

验证​

修复后的预期指标：

PrimitiveSize修复前 G5 (us)预期修复后 (us)Math (us)
allgather1.125 MB19.839~4-53.967
allreduce0.4375 MB11.679~2-31.964
reducescatter1.0 MB17.663~4-53.603

预期方案 A 落地后 G5/Math 比值从 5-6x 降至 1.2-1.5x（剩余差距来自 PAXI per-packet 协议开销，属于 G5 比 Math 更精确的部分）。

修复实录​

实现 plan：docs/plans/2026-04-28-g5-paxi-multi-link-group.md（已归档删除）

改动文件 （8 个）：

  • perfmodel/evaluation/g5/src/types.rs — Event::RcPackDone 新增 lg_id: u8 字段
  • perfmodel/evaluation/g5/src/tier6/rc_link_tx.rs — tx_busy: bool → Vec<bool>，新增 pick_idle_lg、lg_rr_ptr、diag_lg_busy_ns[N]; on_tx_done 加 lg_id 参数
  • perfmodel/evaluation/g5/src/tier6/paxi.rs — PAXIBridge::on_tx_done 透传 lg_id
  • perfmodel/evaluation/g5/src/top/event_handlers.rs — handle_rc_pack_done 透传 lg_id
  • perfmodel/evaluation/g5/src/top/multi_chip.rs — 事件分发解构 lg_id; line_rate 改读独立字段
  • perfmodel/evaluation/g5/src/input.rs — yaml schema 新增 num_link_groups、line_rate_per_lg_bytes_per_ns
  • configs/chips/SG2262.yaml, configs/chips/_template.yaml — 同步新字段

配套 Spec 更新：docs/specs/G5仿真建模/G5-RC-Link传输层设计规格.md 升级为 v1.2.0，新增 §多 Link Group 并行模型 章节。

单元测试：197/197 通过，含新增：

  • test_multi_lg_round_robin: 8 LG 时连续 8 包散布到 LG 0..=7，第 9 包阻塞 （验证 all_lg_busy）
  • test_multi_lg_pack_delay_concurrent: 8 包并发完成时刻 = 单包 pack_delay (22 ns)，不是串行累加 (8×22 ns)
  • test_tx_busy_single_lg: N=1 退化场景兼容性

端到端验证 (v1, 2026-04-28)：❌ 失败。修复后实测 G5 延迟反而上升 (Dense_MLP allreduce 11.679 → 22.789 us, MoE combine 60 → 539 us)。DIAG 输出显示 nak=3485, nak_retx=8195 — NAK 风暴。根因诊断：v1 实现采用"共享 PSN + per-packet RR"，违反 RC Link 严格保序假设。

v2 重做计划：按 spec v1.2.0 （per-LG 独立 RC Link） 重写。代码改动量预估 ~500-700 行 （含测试）。已 revert v1 错误实现 → 走新 plan → 走 act → 重新验证。

端到端验证 (v2, 2026-04-28)：✅ 成功。

ModulePrimitiveSize修复前 G5 (us)v2 修复后 G5 (us)Math (us)修复前 G5/Mathv2 G5/Math
Dense_MLPallreduce0.4375 MB11.6797.5781.9645.95x3.86x
MLAallgather1.125 MB19.8399.4213.9675.00x2.37x
MLAreducescatter1.0 MB17.6638.3973.6034.90x2.33x
MLAallreduce0.4375 MB11.6797.5781.9645.95x3.86x
DSAtopk_allgather32KB0.7990.4610.7811.02x0.59x
MoEdispatch (a2a EP=64)0.875 MB33.29633.4285.2896.30x6.32x (~)
MoEcombine (a2a EP=64)1.75 MB60.10360.2137.8377.67x7.68x (~)
LMHeadallreduce0.4375 MB11.6797.5781.9645.95x3.86x

关键指标：

  • ✅ NAK=0, nak_retx=0 （v1 失败的 8000+ 重传风暴完全消除）
  • ✅ 8 LG 完美均衡 （[DIAG] 输出每 LG sent=84 packets, busy 计数偏差 <1%）
  • ✅ Ring 类通信 1.5-2.5x 加速 (5.95x → 2.37x for 1.125MB allgather)
  • ✅ MoE alltoall 不回归 （v1 失败的 539us → v2 60us，与修复前持平）
  • ✅ 小消息不回归 （DSA topk 0.799 → 0.461 us，反而因 line_rate 解耦后单 LG 优化更准）

未达 plan 预期 1.0-1.5x 的部分：

  • Ring 类 G5/Math 仍在 2.3-3.9x （plan 预期 ≤1.5x）
  • MoE alltoall 几乎无改善 （因 EP=64 的 pairwise 已天然多流，ITLV 多 LG 散布对其受益有限）
  • 进一步收敛需要调优 startup latency / line_rate / DCQCN 参数，或改进 alltoall 算法。后续作为单独优化任务跟进。

遗留问题​

  1. datapath_bytes 应为 128？ 已确认 64 是单 LG MAC 位宽 （SG2262 112G x4 配置），1024-bit MAC_DW 是 400G 单链路配置，不适用。无需改。
  2. CDMA → LinkGroup 实际硬件绑定关系 （静态 affinity vs 动态散布）：仿真按 PAXI 内部 round-robin 建模，与硬件实际 ITLV 实现可能有偏差。RTL 确认后视情况调整。
  3. 单笔 transfer 内多 segment 是否真的散布到多 LG：当前模型按 packet 粒度散布，与 spec 约束 #4 "ITLV" 语义一致但粒度未对齐到具体值。
  4. N=2 物理硬件能否真的用满 8 LG：当前按 yaml 配置的 400 GB/s 上限建模 （假设可以）。若硬件实际 N=2 单笔通信只能用 1 个 LG，仿真会偏乐观。
  5. 多 PAXI 实例间的负载均衡策略：round-robin 是建模选择，真实硬件 ITLV 策略 (hash/RR/affinity) 待确认。
  6. ISSUE-003 遗留的 overcredit_limit 队列：多 LG 后 pending 队列深度是否需要按实例数缩放，当前未变。
  7. 2-port Ring N=2 冗余 （调查中发现的次要问题）：拆分到 ISSUE-006 独立处理 （已归档）。

v2 Code Review 发现的 backlog （中等严重度，后续单独优化）​

  1. lg_id 越界 panic 风险: paxi.tx_lgs[lg_id as usize] 散落在 event_handlers 多处直接索引，lg_id 错误时直接 panic。建议在 PAXIBridge 加 tx_lg(lg_id) / rx_lg(lg_id) 方法封装边界检查。
  2. credit 总额可能高估：当前 init_credits 对每个 (LG, VC) 写入 initial_credit, N=8 时单 chip pair 单 VC 总 credit = 8 × 1024 × 256B = 2 MB。需与 RTL 同事确认 yaml initial_credit 是 per-LG 还是全局配置。
  3. submit/on_ack 全 LG 空仲裁开销：每次都遍历 N 个 LG try_arbitrate，大部分是空仲裁。建议跟踪有 pending segment 的 LG 列表，只对这些 LG 仲裁。
  4. submit 1ns 占位 hack 语义模糊: tx_busy_until_ns[lg] = cur + 1.0 防止同次 submit 全选同一 LG，但 1ns 不反映真实 pack_delay (~30ns)。建议改为 prev + estimated_pack_delay，缓存到 PAXIBridge 字段。
  5. 测试覆盖缺失：跨 LG 事务完成测试 / NAK 限定单 LG 不影响其他 LG / per-LG 独立 PSN 显式断言 / drain_pending tiebreak 回归测试。
  6. 永久 eprintln：[RX-NAK] [TIMEOUT] 等 eprintln 在 hot path 上，应改为 debug_assert 或限流日志。