9.12

2026-09-12

周六

agent 算子优化

我想让 codex 为我赚回订阅费，所以参加了一些算子优化比赛，让它来操作。最早参加的是摩尔线程的 GEMM 优化大赛，目前榜一是 407 TFLOPS，但我本地已经做到了 430+ TFLOPS，只是出于奇怪的原因，线上评测不能通过。主办方做事很拖拉，迟迟没有解决我的问题，我决定 9.20 去找主办方解决一下，在此之前，都算是藏着，也是好事。

然后报名了和华为相关的三个 Ascend C 算子优化比赛，我初步让 codex 扫了下赛题，然后把精力花在最容易得奖金的赛题上。盯着 codex 做了一天 Ascend C 算子优化，总结了一些经验：

1. 使用底层 API

要让 agent 直接用底层 API 写，这样能让它被迫明白自己写下的每行代码在底层发生了什么，可以避免极度糟糕的写法。我的 prompt 是：善用底层 API 来用最小代价实现想要的硬件操作，最终只留下那些必要的硬件操作，并合理编排流水线。

2. 针对固定 shape 优化

必须让 agent 针对特定 shape 的 case 优化，才能把优化做到极致。这是合理的，因为不同 shape 本身就会对最优的计算流水线产生巨大的影响，追求通用就会在排行榜上失败，所以请面向测试点编程。另一方面，就算目的是泛化，把测试点都调到最优，积累经验后，泛化也容易得多。

3. 吸取前人的智慧

华为总结的 Ascend C 算子优化建议 还是不错的，codex 独立想到了一个有趣的优化，让两个测试点跑到了全场第一，后来查了一下发现这里面其实已经写了。所以这个文档应该梳理成表格后喂给 agent

4. 优化工作流

我们一定会给 agent 编排一个优化迭代工作流，最基础的就是 优化-perf 的循环。

1. 关于 perf，应该详细地规定如何 perf，要获取哪些性能数据来支持下一步优化。例如，如果不明确指定，codex 不会想到要 perf timeline 信息，导致支持决策的信息不足。
2. 当你规划了详尽的 perf 工作流并要求 agent 遵守，又有时会发现它过于死板。当一个优化已经在初步测试中证明没用甚至退化，就应该立刻放弃这个方向，而不是机械地执行整套 perf。告诉 agent，请积极根据 ceiling 来做剪枝！