admin/matmul-analysis
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

MergeBatch L1 绑定情形 DMA 命令数多计 b0 倍, 且 beats_iterbatch 截断判定与方案口径不一致 #35

New Issue
Closed
opened 2026-09-07 12:20:53 +00:00 by admin · 1 comment
admin commented 2026-09-07 12:20:53 +00:00
Owner
Copy Link

现象

B=128, M=1~16, K=512, N=128, bf16: 两切B分支均满足进入条件 (candidates 均 True), 但仲裁全部判 IterBatch 胜 (T_MergeBatch 比 T_IterBatch 高 0.4~0.6us)。用户质疑: MergeBatch 在重叠区应更有竞争力。

根因 (两处缺陷)

缺陷 1: MergeBatch evaluate 的 L1 绑定情形 DMA 命令数多计 b0 倍 (P1, 影响仲裁方向)

merge_batch.py evaluate 的 L1 绑定分支: dma_cmds = b_core * n_k, 其中 n_k = ceil(K/k_l1^m) 是合并后的 K 段数。v1.1 §4.4 的"命令数与 IterBatch 相同 = b_core·n_K"中的 n_K 是未合并粒度; 代入合并后段数导致多计 b0 倍。

真实命令数 = 合并组数 × 每组 K 段数 = ceil(b_core/b0) * ceil(K/k_l1^m)。

本 case (b_core=4, b0=4, k_l1^m=240): 真实 1×3=3 条 (比 IterBatch 的 4 条还少), 模型计成 4×3=12 条, 虚增 450ns 命令时延, 直接把仲裁翻成 IterBatch。修复后 m=1/2 由 MergeBatch 胜 (与分界条件一致), m=4/8/16 仍 IterBatch (drain 随 M 增长, 命令节省打不平), 交叉点 m≈2~4, 物理合理。

缺陷 2: beats_iterbatch 的"K 截断"判定与方案口径不一致 (P2, 注释误导 + T_cmd<=0 策略路径会选错)

beats_iterbatch 用未合并的 k_l1_iter = min(K, L1/(2(M+N)dt)) >= K 判截断 (v1.1 line 219 字面), 与 make_plan/evaluate 的合并口径 k_l1^m = min(K, k_l1*/b0, 512B/dtype) (v1.1 line 161) 矛盾: m=1/2 时未合并截断但合并后 k_l1=240<K, 仲裁注释误报"分界条件判 MergeBatch 胜 (K截断)"。当前 T_cmd=50ns>0 时时延模型终审兜住了最终选择, 但 T_cmd<=0 策略路径会直接依此误判选错分支。

此外 v1.1 的"K截断/L1绑定"二分未覆盖 dValue 512B 推荐值截断第三情形: IterBatch a/b 形态 k_l1=K 不受 cap, 合并侧受 cap (k_l1^m=256), 此时 n_K^m=n_K, 命令数打平 (而非 b0 倍节省也非 b0 倍放大), 文档两种情形都不适用。

修复方案

  1. evaluate: dma_cmds = ceil(b_core/b0) * ceil(K/k_l1^m) (K 截断时退化为 b_core/b0, 与现口径一致; L1 绑定情形消除 b0 倍多计);
  2. beats_iterbatch: 泛化为"实际命令节省 vs drain 惩罚"比较 —— savings = (cmds_iter - cmds_mb)*T_cmd vs drain_pen = (b0-1)*(T_comp+T_write); K 截断时严格退化为文档闭式 b_core > b0*(T_comp+T_write)/T_cmd, L1 绑定理想情形退化为恒劣; T_cmd<=0 策略路径改为 cmds_mb < cmds_iter (结构性命令/指令节省) 判 MergeBatch 优先;
  3. 既有测试 (128,64,64,512) 的 T_cmd=0 期望从 True 改 False: 该 case 合并侧被 dValue 512B cap 截断 (k_l1^m=256, n_K^m=2), 命令数与 IterBatch 打平 (4=4), 无节省且 drain 翻倍, 物理上应为恒劣 —— 原期望建立在未合并口径的误分类上;
  4. 新增 TestIssue35 回归: b=128/n=128/k=512/m∈{1,2,4,8,16} 路由 m=1,2->MergeBatch, m=4,8,16->IterBatch; 命令数公式断言; 分界与 plan.k_l1 口径一致性断言;
  5. docs/02_分支理论/01_MergeBatch分支.md 分界小节补第三情形行 + 泛化分界说明。

影响面

  • 仅 MergeBatch 的 t_dma_cmd (L1 绑定情形降 b0 倍) 与 beats_iterbatch 判定/注释; K 截断情形数值不变;
  • examples 三件套中走切B且合并后 L1 绑定的 case 时延/仲裁注释会变 (重生成并做可复现 0 diff 校验);
  • IterBatch / ASW / StreamK 口径不动。
## 现象 `B=128, M=1~16, K=512, N=128, bf16`: 两切B分支均满足进入条件 (candidates 均 True), 但仲裁全部判 IterBatch 胜 (T_MergeBatch 比 T_IterBatch 高 0.4~0.6us)。用户质疑: MergeBatch 在重叠区应更有竞争力。 ## 根因 (两处缺陷) ### 缺陷 1: MergeBatch evaluate 的 L1 绑定情形 DMA 命令数多计 b0 倍 (P1, 影响仲裁方向) `merge_batch.py` evaluate 的 L1 绑定分支: `dma_cmds = b_core * n_k`, 其中 `n_k = ceil(K/k_l1^m)` 是**合并后**的 K 段数。v1.1 §4.4 的"命令数与 IterBatch 相同 = b_core·n_K"中的 n_K 是**未合并**粒度; 代入合并后段数导致多计 b0 倍。 真实命令数 = 合并组数 × 每组 K 段数 = `ceil(b_core/b0) * ceil(K/k_l1^m)`。 本 case (b_core=4, b0=4, k_l1^m=240): 真实 1×3=**3 条** (比 IterBatch 的 4 条还少), 模型计成 4×3=**12 条**, 虚增 450ns 命令时延, 直接把仲裁翻成 IterBatch。修复后 m=1/2 由 MergeBatch 胜 (与分界条件一致), m=4/8/16 仍 IterBatch (drain 随 M 增长, 命令节省打不平), 交叉点 m≈2~4, 物理合理。 ### 缺陷 2: beats_iterbatch 的"K 截断"判定与方案口径不一致 (P2, 注释误导 + T_cmd<=0 策略路径会选错) `beats_iterbatch` 用**未合并**的 `k_l1_iter = min(K, L1/(2(M+N)dt)) >= K` 判截断 (v1.1 line 219 字面), 与 make_plan/evaluate 的合并口径 `k_l1^m = min(K, k_l1*/b0, 512B/dtype)` (v1.1 line 161) 矛盾: m=1/2 时未合并截断但合并后 k_l1=240<K, 仲裁注释误报"分界条件判 MergeBatch 胜 (K截断)"。当前 T_cmd=50ns>0 时时延模型终审兜住了最终选择, 但 T_cmd<=0 策略路径会直接依此误判选错分支。 此外 v1.1 的"K截断/L1绑定"二分未覆盖 **dValue 512B 推荐值截断**第三情形: IterBatch a/b 形态 k_l1=K 不受 cap, 合并侧受 cap (k_l1^m=256), 此时 n_K^m=n_K, 命令数打平 (而非 b0 倍节省也非 b0 倍放大), 文档两种情形都不适用。 ## 修复方案 1. evaluate: `dma_cmds = ceil(b_core/b0) * ceil(K/k_l1^m)` (K 截断时退化为 b_core/b0, 与现口径一致; L1 绑定情形消除 b0 倍多计); 2. beats_iterbatch: 泛化为"实际命令节省 vs drain 惩罚"比较 —— `savings = (cmds_iter - cmds_mb)*T_cmd` vs `drain_pen = (b0-1)*(T_comp+T_write)`; K 截断时严格退化为文档闭式 `b_core > b0*(T_comp+T_write)/T_cmd`, L1 绑定理想情形退化为恒劣; T_cmd<=0 策略路径改为 `cmds_mb < cmds_iter` (结构性命令/指令节省) 判 MergeBatch 优先; 3. 既有测试 `(128,64,64,512)` 的 T_cmd=0 期望从 True 改 False: 该 case 合并侧被 dValue 512B cap 截断 (k_l1^m=256, n_K^m=2), 命令数与 IterBatch 打平 (4=4), 无节省且 drain 翻倍, 物理上应为恒劣 —— 原期望建立在未合并口径的误分类上; 4. 新增 TestIssue35 回归: b=128/n=128/k=512/m∈{1,2,4,8,16} 路由 m=1,2->MergeBatch, m=4,8,16->IterBatch; 命令数公式断言; 分界与 plan.k_l1 口径一致性断言; 5. docs/02_分支理论/01_MergeBatch分支.md 分界小节补第三情形行 + 泛化分界说明。 ## 影响面 - 仅 MergeBatch 的 t_dma_cmd (L1 绑定情形降 b0 倍) 与 beats_iterbatch 判定/注释; K 截断情形数值不变; - examples 三件套中走切B且合并后 L1 绑定的 case 时延/仲裁注释会变 (重生成并做可复现 0 diff 校验); - IterBatch / ASW / StreamK 口径不动。
admin closed this issue 2026-09-07 12:31:54 +00:00
admin commented 2026-09-07 12:32:39 +00:00
Author
Owner
Copy Link

已修复, commit fdd3c88 已推送 main。

修复内容

  1. evaluate 命令数 (缺陷1): 每核 DMA 命令数 = ⌈b_core/b0⌉ × ⌈K/k_l1^m⌉。K 截断时退化为 b_core/b0 (数值不变); L1 绑定情形消除 b0 倍多计 —— v1.1 §4.4 恒劣恒等式 "b_core·n_K" 的 n_K 是未合并粒度 ⌈K/k_l1^iter⌉, 误代入合并后段数 ⌈K/k_l1^m⌉ 会多计 b0 倍 (本 case: 真实 3 条 vs 误计 12 条, 虚增 450ns)。
  2. beats_iterbatch 泛化 (缺陷2): 直接比较两分支实际每核命令数 —— 搬移节省 (cmds_iter−cmds_mb)·T_cmd vs drain 惩罚 (b0−1)(T_comp+T_write)。K 截断时严格退化为文档闭式 b_core > b0(T_comp+T_write)/T_cmd; L1 绑定理想情形退化为恒劣; 覆盖 dValue 512B cap 截断的第三情形 (v1.1 二分未覆盖)。截断判定改用合并口径 plan.k_l1 ≥ K (与 make_plan/evaluate 同源), 不再用未合并 k_l1_iter。T_cmd≤0 策略路径改为 cmds_mb < cmds_iter 判 MergeBatch 优先。
  3. router 仲裁文案: [裁决] 位改打印最终胜者 (修复 "判IterBatch…以时延模型为准: MergeBatch" 式自相矛盾表述)。
  4. docs/02_分支理论/01_MergeBatch分支.md: 分界小节补第三情形行 + 命令数口径警示 + 泛化净收益式。

用户 case 家族修复后路由 (B=128, N=128, K=512, bf16)

M 修复前 修复后 仲裁依据
1 IterBatch MergeBatch 命令 3<4, 节省 0.05us > drain 0.04us, 分界+时延一致
2 IterBatch MergeBatch 分界判 IterBatch (0.05<0.08), 时延 10.84<10.87us 终审反超
4 IterBatch MergeBatch 分界判 IterBatch, 时延持平 11.05us (tie 归 MergeBatch)
8 IterBatch IterBatch 分界+时延一致 (drain 0.33us > 节省 0.05us)
16 IterBatch IterBatch 分界+时延一致 (drain 0.66us)

交叉点 m≈4~8: 命令节省固定 50ns (3 vs 4 条), drain 惩罚随 M 线性增长, 小 M 合并胜、大 M 逐 batch 胜 —— 物理合理, 且小 M 端与"MergeBatch 应更有竞争力"的直觉一致。

关于"静态优先级": 未引入。v1.1 §4.5 的统一分界就是重叠区的裁决机制 (L1 绑定恒劣有证明), 静态优先 MergeBatch 会在恒劣区选错; 本轮修复让时延模型口径恢复诚实后, 仲裁结果已与理论直觉对齐。

验证

  • unittest 68/68 (新增 TestIssue35 5 例: 命令数公式/K截断不变/截断口径一致/路由家族/裁决文案; test_beats_iterbatch_policy 的 (128,64,64,512) 期望 True→False: 合并侧被 dValue cap 截断 k_l1^m=256, 命令数 4=4 打平静恒劣, 原期望基于未合并口径的误分类);
  • examples 重生成可复现 0 diff; 相对上版仅仲裁文案修正 + dma_cmd_count 16.0→16 格式, plans.csv 与各 case 时延数值不变;
  • 压力回归 seed7/6000 + seed2024/4000 = 10000 例: 0 崩溃/0 NaN/0 违规/0 不可行/0 GM<V_in, 七分支全覆盖 (MergeBatch 命中 523 例)。
已修复, commit fdd3c88 已推送 main。 ## 修复内容 1. **evaluate 命令数 (缺陷1)**: 每核 DMA 命令数 = ⌈b_core/b0⌉ × ⌈K/k_l1^m⌉。K 截断时退化为 b_core/b0 (数值不变); L1 绑定情形消除 b0 倍多计 —— v1.1 §4.4 恒劣恒等式 "b_core·n_K" 的 n_K 是未合并粒度 ⌈K/k_l1^iter⌉, 误代入合并后段数 ⌈K/k_l1^m⌉ 会多计 b0 倍 (本 case: 真实 3 条 vs 误计 12 条, 虚增 450ns)。 2. **beats_iterbatch 泛化 (缺陷2)**: 直接比较两分支实际每核命令数 —— 搬移节省 (cmds_iter−cmds_mb)·T_cmd vs drain 惩罚 (b0−1)(T_comp+T_write)。K 截断时严格退化为文档闭式 b_core > b0(T_comp+T_write)/T_cmd; L1 绑定理想情形退化为恒劣; 覆盖 dValue 512B cap 截断的第三情形 (v1.1 二分未覆盖)。截断判定改用合并口径 plan.k_l1 ≥ K (与 make_plan/evaluate 同源), 不再用未合并 k_l1_iter。T_cmd≤0 策略路径改为 cmds_mb < cmds_iter 判 MergeBatch 优先。 3. **router 仲裁文案**: [裁决] 位改打印最终胜者 (修复 "判IterBatch…以时延模型为准: MergeBatch" 式自相矛盾表述)。 4. **docs/02_分支理论/01_MergeBatch分支.md**: 分界小节补第三情形行 + 命令数口径警示 + 泛化净收益式。 ## 用户 case 家族修复后路由 (B=128, N=128, K=512, bf16) | M | 修复前 | 修复后 | 仲裁依据 | |---|---|---|---| | 1 | IterBatch | **MergeBatch** | 命令 3<4, 节省 0.05us > drain 0.04us, 分界+时延一致 | | 2 | IterBatch | **MergeBatch** | 分界判 IterBatch (0.05<0.08), 时延 10.84<10.87us 终审反超 | | 4 | IterBatch | **MergeBatch** | 分界判 IterBatch, 时延持平 11.05us (tie 归 MergeBatch) | | 8 | IterBatch | IterBatch | 分界+时延一致 (drain 0.33us > 节省 0.05us) | | 16 | IterBatch | IterBatch | 分界+时延一致 (drain 0.66us) | 交叉点 m≈4~8: 命令节省固定 50ns (3 vs 4 条), drain 惩罚随 M 线性增长, 小 M 合并胜、大 M 逐 batch 胜 —— 物理合理, 且小 M 端与"MergeBatch 应更有竞争力"的直觉一致。 关于"静态优先级": 未引入。v1.1 §4.5 的统一分界就是重叠区的裁决机制 (L1 绑定恒劣有证明), 静态优先 MergeBatch 会在恒劣区选错; 本轮修复让时延模型口径恢复诚实后, 仲裁结果已与理论直觉对齐。 ## 验证 - unittest 68/68 (新增 TestIssue35 5 例: 命令数公式/K截断不变/截断口径一致/路由家族/裁决文案; test_beats_iterbatch_policy 的 (128,64,64,512) 期望 True→False: 合并侧被 dValue cap 截断 k_l1^m=256, 命令数 4=4 打平静恒劣, 原期望基于未合并口径的误分类); - examples 重生成可复现 0 diff; 相对上版仅仲裁文案修正 + dma_cmd_count 16.0→16 格式, plans.csv 与各 case 时延数值不变; - 压力回归 seed7/6000 + seed2024/4000 = 10000 例: 0 崩溃/0 NaN/0 违规/0 不可行/0 GM<V_in, 七分支全覆盖 (MergeBatch 命中 523 例)。
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
admin
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: admin/matmul-analysis#35
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?