ISSUE-049：CP 多芯片桥漏建纯通信芯片导致守恒违规
| 字段 | 值 |
|---|---|
| 编号 | ISSUE-049 |
| 日期 | 2026-06-22 |
| 状态 | Resolved |
| 类型 | 实现 bug（桥构造遗漏，非 spec 设计问题） |
| 影响范围 | CP 多芯片桥 A1 路径（build_multi_chip_program）；CP=4 prefill 端到端 |
问题现象
CP=4 prefill 走 A1 多芯片桥（run_g5_pipeline 传 network_graph → simulate_multi_chip）后，多芯片通信守恒 KPI 非 0：
multi_chip.incomplete_txns = 8multi_chip.unsent_frames = 72
按项目严格守恒哲学，非 0 即传输不可信。其他 e2e（端到端跑通、走多芯片路径判定）通过——多芯片路径本身通了，仅通信守恒违规。
复现：pytest tests/evaluation/g5/test_cp_multichip_e2e.py::test_multichip_conservation_all_zero
调查过程
- [反馈环] 用
test_multichip_conservation_all_zero（严格全 0 断言）作确定性 pass/fail 信号。 - [假设 1] 折叠 allgather 字节口径错 → 排除。隔离构造同 participants/bytes 的 allgather（空 CoreProgram）在 ports=1/2/4/8 全部守恒 0。
- [假设 2] compute↔comm 交互残留 → 排除。把桥程序的 CoreProgram 全清空（仅留 comm_schedule），守恒违规仍是 8/72，与含 compute 完全一致 → 与 compute 无关。
- [实验·决定性对照] 把桥实际产出的
MultiChipProgram与手动等价重建逐字段对比：CommOp 全字段相同（op_id/comm_type/participants/data_bytes/algorithm/dimensions/num_chunks/send_counts），c2c_ports_per_chip同为 8。唯一差异——桥的chip_programs.keys() == [0]，手动重建为 [0,1,2,3]。手动版守恒 0，桥版 8/72。
根因分析
桥的 all_chips 仅从 COMPUTE 节点的 chip_ids 推导。CP 切分下 MLA attention 的 COMPUTE 节点 chip_ids 不跨全部 rank（只落在 chip 0），故 chip_programs 只建了 chip 0。但折叠后的 allgather participants=[0,1,2,3] 要求 4 个芯片都在场。芯片 1/2/3 无 CoreProgram 条目 → simulate_multi_chip 未为其建立通信端点 → 这些端点的事务无法完成（incomplete_txns=8）、待发帧无处投递（unsent_frames=72）。
定位：perfmodel/mapping/g5/multi_chip_bridge.py build_multi_chip_program 的 all_chips 推导。
Spec / 文档依据
A1 桥设计（discuss 收敛 + plan-review APPROVED）：每芯片 CoreProgram 由 emit(本芯片 COMPUTE) 产出，COMM 转 CommOp。设计未显式覆盖「只参与通信、不承载 compute 的芯片仍需 CoreProgram 条目」这一约束——属实现遗漏，非设计错误，故不改 spec，仅修桥。
解决方案
all_chips 取 COMPUTE 与 COMM 全部参与芯片的并集：
all_chips = sorted({c for op in (compute_ops + comm_ops) for c in op.chip_ids})
无 compute 的芯片 emit([]) → 空 CoreProgram，仍作为通信端点参与。chips_dict 随 all_chips 自动覆盖全部芯片。
涉及文件：perfmodel/mapping/g5/multi_chip_bridge.py（build_multi_chip_program）。
验证
test_multichip_conservation_all_zero：修复前 8/72 失败，修复后全 0 通过。tests/evaluation/g5/：67 passed，无回归（comm-primitive 多芯片、单芯片 LLM、桥单测全过）。
Lessons Learned / Prevention
桥构造时「参与方全集」必须取 compute ∪ comm，不能只看 compute——多芯片仿真的端点集合由通信参与方定义，纯通信芯片同样是合法端点。决定性证据来自「桥实际产物 vs 手动重建逐字段 diff」，而非反复读代码：同参数隔离守恒、桥路径不守恒的矛盾，直接把范围缩到「两者结构差异」一处。