[P1] 第三轮整改回退了 #11/#12/#14 的修复：StreamK fixpipe 双重计账(55us)、K=1 空洞(49.4%)、advice 误导，需恢复或给出替代论证 #17

New Issue

admin · 2026-09-03T13:03:56Z

admin commented

2026-09-03 13:03:56 +00:00

第三轮整改（f5a0b6f 前 62 个提交）无说明地回退了第二轮已闭环的 issue #11/#12/#14 修复（special.py / stream_k.py / evaluator.py 及 examples、回归测试同步回退），但 Gitea issue 状态与 docs/03_测评报告 v2.0 附录 D 未同步，形成"关闭的 issue、过时的报告、回退的行为"三方矛盾。复测数据：

#11: streamk_demo 总时延回到 55.03us、FIXPIPE=51.62us（同一批 grid_Ktile4B=8.39MB 部分和字节在 t_reduce 内计 1.61us 之外又按单核带宽计一次 51.62us，与"每核独立 DMA/带宽配平"原则矛盾）；
#12: K=1 且 B<128 恢复占位"[无方案]"（扫描 B=1..255×K=1: 378/765 = 49.4%）；
#14: FIXPIPE advice 恢复对 StreamK 提示 fp16/fp8 减半（与部分和 4B 防精度丢失规则矛盾）。
期望：若回退是有意为之（例如作者重新推翻了 #11/#12/#14 的结论），请 reopen 原 issue 并给出替代推导（尤其 StreamK 51.62us 的物理依据）；否则恢复修复。本 issue 由复评报告 v3.0 §3/R1-R4 提出。

第三轮整改（f5a0b6f 前 62 个提交）无说明地回退了第二轮已闭环的 issue #11/#12/#14 修复（special.py / stream_k.py / evaluator.py 及 examples、回归测试同步回退），但 Gitea issue 状态与 docs/03_测评报告 v2.0 附录 D 未同步，形成"关闭的 issue、过时的报告、回退的行为"三方矛盾。复测数据： - #11: streamk_demo 总时延回到 55.03us、FIXPIPE=51.62us（同一批 grid_K*tile*4B=8.39MB 部分和字节在 t_reduce 内计 1.61us 之外又按单核带宽计一次 51.62us，与"每核独立 DMA/带宽配平"原则矛盾）； - #12: K=1 且 B<128 恢复占位"[无方案]"（扫描 B=1..255×K=1: 378/765 = 49.4%）； - #14: FIXPIPE advice 恢复对 StreamK 提示 fp16/fp8 减半（与部分和 4B 防精度丢失规则矛盾）。期望：若回退是有意为之（例如作者重新推翻了 #11/#12/#14 的结论），请 reopen 原 issue 并给出替代推导（尤其 StreamK 51.62us 的物理依据）；否则恢复修复。本 issue 由复评报告 v3.0 §3/R1-R4 提出。

admin commented

2026-09-03 13:10:24 +00:00

【修复说明 · 乱码重写】原评论提交时编码损坏、内容不可恢复, 以下按 git 记录 / issue 正文 / 残留文本重建 (要点级, 非逐字原稿):

[P1] 第三轮整改回退 #11/#12/#14 已恢复 (commit 9afe6ee):

stream_k.evaluate: 归约单次计账 (t_drain = t_reduce), 稳态不再另计 fixpipe →
streamk_demo 55.03us → 9.96us, 消除 FIXPIPE 51.62us 的双重计账 (恢复 #11);
special.py: K=1 且 B<128 的 AIV 单缓冲方案恢复, K=1 空洞 (49.4%) 消除 (恢复 #12);
evaluator._advice: StreamK 分支提示修正 + REDUCE 分支 (恢复 #14);
同步 issue 状态与 docs/03_测评报告附录 D, 消除"关闭的 issue、过时的报告、回退的行为"矛盾。

【修复说明 · 乱码重写】原评论提交时编码损坏、内容不可恢复, 以下按 git 记录 / issue 正文 / 残留文本重建 (要点级, 非逐字原稿): [P1] 第三轮整改回退 #11/#12/#14 已恢复 (commit 9afe6ee): - stream_k.evaluate: 归约单次计账 (t_drain = t_reduce), 稳态不再另计 fixpipe → streamk_demo 55.03us → 9.96us, 消除 FIXPIPE 51.62us 的双重计账 (恢复 #11); - special.py: K=1 且 B<128 的 AIV 单缓冲方案恢复, K=1 空洞 (49.4%) 消除 (恢复 #12); - evaluator._advice: StreamK 分支提示修正 + REDUCE 分支 (恢复 #14); - 同步 issue 状态与 docs/03_测评报告附录 D, 消除"关闭的 issue、过时的报告、回退的行为"矛盾。

admin closed this issue

2026-09-03 13:10:25 +00:00

~~admin referenced this issue 2026-09-03 13:10:25 +00:00~~

[P2] 占位方案(used_core_num=0)可被 evaluate 判为可行并给出正常时延：recommend"无方案"与 evaluate"可行"矛盾 #18

admin referenced this issue

2026-09-04 08:31:06 +00:00

[P0] K=1 且 batch<128 的 case 在 recommend 中崩溃（AttributeError: NoneType used_core_num） #4

admin referenced this issue

2026-09-04 08:31:08 +00:00

[P2] StreamK 时延计账口径疑点：REDUCE 同时计入稳态 max() 与 drain；fixpipe 按 C dtype 与"部分和 4B"口径不一致 #9

admin referenced this issue

2026-09-04 08:31:09 +00:00