10.3

2026-10-03

周六

模拟器的局限

msopprof simulator 用的 CAModel 模拟器，运行时间和 npu 真实运行时间的倍率在 174万倍-458万倍（codex 评估），所以只能用来跑 10 微秒左右的小 case，对毫秒级别的 case 无能为力，所以在优化不少题目时有困难，例如 solve

所以还是要上真机，这个平台 千域云智算 可以租到比较便宜的 910B2，一小时 3.58，而官方 模力方舟 上的 910B4 是一小时 18.68

但是，电力赛的评测机器是 B4，它和 B2 的差别还是很大的，拉个表格：

所以如果算子是 L2-bound 或 HBM-bound 的，B2 还是很不准；其余情况同样不准，但还可以凑合用。

现在拿到新算子的工作流是：如果属于新比赛，先用探针获得评测机型号。然后本地用模拟器模拟，写出正确性 baseline。baseline 一般写法是非常糟糕的，所以先进行初步的通用算法优化，拿完低垂的果实之后写探针把 case 的 shape 和 dtype 探出来，方便后续深度优化。最后就反复看有离榜一还有多远。如果很远就继续想算法优化，如果很近就上真机做微优化。

我还尝试了打包工具链，让网页版 GPT 使用模拟器进行优化，达到 NeuroGolf 一样的效果，可惜刚发完命令，O/ 就 ban 掉了对话，所以这个美好的计划失败了。

最后，模拟器模拟 910C 的时候，和真机差异巨大，暂未查原因。

关于文档管理

我在 NeuroGolf 中为 agent 构建了一个文档系统，记录所有它们发现的用于减小 onnx 体积的 trick。现在在算子优化中，我试图构建一个类似的系统。

可以借鉴的是 Nvidia 的 KDA (Kernel Design Agents) 使用的 KernelWiki 系统，它的一个优秀特点是，内容 ID 就是它的标题，而不是随便的什么数字编号，而数字索引由一个脚本随时建立。它的好处是可以让 agents 并行地添加 wiki 条目，不用担心编号冲突：写完 a003 时，发现 merge 时另一个 agent 已经写了 a003，然后需要改编号。这增强了系统的稳定性。

总之，让 Astra 把 KernelWiki 迁移到昇腾就是一句话的事，困难的是为它增加条目。在接下来的优化中，我会让 agent 有优化点就增加或完善条目。对于已经完成的星辰杯初赛题目，则只能让 agent 总结其中的优化点。更丰富的来源是算子比赛获胜者们公开在网上的仓库，问题在于太久远的比赛里用到的技巧可能对 Astra 已经是基操了，没必要写进仓库，并且可能不是最优实践，只有 Astra 优化轨迹里的那些灵光一现才保证有真正的重要性。不论如何，从公开仓库提取经验需要谨慎的处理。

电力赛

电力赛一共 10 题，我准备聚焦其中的 7 题进行优化，另外 3 题就不做了。不做的 3 题是 FireCandidateDecodeFusion，SafetyBeltViolationGeometry 和 TreeLineMinDistance，一个原因是，它们的名字太长了。

一个叫 “北枝” 的用户非常高手。SplineConv 和 Solve 题我原本是第一，他把我打到了第二。当然，比赛现在还没几个人参加，截止前应该会非常疯狂，以至于我们现在的速度在那时看来非常 naive