这篇帖子讨论的是一篇声称 Qwen3.7-Max 在未知硬件上连续跑了 35 小时、通过 432 轮“写代码—编译—运行—看 profile—再修改”的闭环，把某个 attention 相关 kernel 的吞吐提升到 10× 的文章。评论里提到的 perf（Linux 性能分析工具）、disassembly（反汇编）和 SIMD（单指令多数据并行指令集）都是做底层性能调优时常见的工具和手段。争议核心是横向比较是否公平：GLM 5.1、Kimi K2.6、DeepSeek V4 Pro 等模型在同类任务上的倍率更低，但部分模型因为连续 5 轮没有 tool calls 就提前停止，而 Qwen3.7-Max 没停。讨论也顺带把这种反复生成候选 kernel、测试并择优的流程，类比成 genetic algorithm（遗传算法）或更广义的 agentic coding。
不少人直接怀疑这篇文章本身就是 LLM 写的，或者至少经过了很重的 AI 润色。理由包括作者在 X 上的英文水平看起来比较基础，以及全文措辞像生成式营销稿。还有人提到原始来源似乎之前已经在 HN 出现过，进一步削弱了“新鲜发现”的可信度。
也有人分享了自己用 LLM 做低层优化的正面经历。一个例子里，模型先完成架构重构，再把热点收敛到数学 kernel，并通过 branching、cache、vectorization、反汇编和 perf 计数器不断迭代，效果明显。另一个例子描述了 35 小时、432 轮 kernel evaluation 的闭环：写代码、编译、运行、看 profile，再改写 kernel 架构，说明这类工具在局部性能调优上确实可能比人工更快。
怀疑者并不一定否认速度提升，但担心最终产物会变得臃肿、难维护。有人直言 AI 修问题时经常是“多加代码”，短期 throughput 上去了，长期却可能埋下技术债。也有反驳说人类其实也常这么做，说明争论焦点不只是 AI，而是这种性能优化路径本身是否会把代码推向更复杂的形态。
另一条主线是质疑 benchmark 的比较方式。评论指出 GLM 5.1、Kimi K2.6、DeepSeek V4 Pro 都在同一任务上跑出了不同倍率，但前几者是因为连续 5 轮没有 tool calls 就提前停止，而 Qwen3.7-Max 没有停，因此“10× 对 7.3×/5×/3.3×”未必是同一标准下的结果。还有人补充说，大家优化的其实是同一个 Extend Attention operator（attention 相关算子）在 triton 里的实现，但如果只挑一个狭窄算子、再加上停止规则差异，就很容易把分数做大。
有人把这种“反复生成 kernel 变体、测试、择优”的过程类比为 genetic algorithm（遗传算法）和其他 non-differentiable optimization（不可导优化）方法。支持这种类比的人认为，本质上都是在大空间里做启发式搜索，而不是靠一次性写出完美代码。也有人反驳说，LLM 不是随机变异器，它会根据 profile、disassembly 和运行反馈做更有针对性的选择，因此比传统遗传算法更像被指导的搜索。
还有少数评论把这类结果看成 native agents（原生能调用工具的模型）路线的信号，认为真正强的会是能自己做规划、编译、运行和回看的模型。有人顺手拿 Anthropic 的 Claude 开玩笑，暗示现在“模型写代码”已经不是离谱设想。另一句“open weights 会 show the real deal”则表达出一种期待：开放权重模型最后会在这种 agentic workflow 里证明自己。
kernel: 在高性能计算/编译器语境里，被反复调优的核心代码块，常是性能瓶颈所在。
genetic algorithm: 通过变异、选择和迭代搜索解空间的优化方法，常用于不可导问题。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。