用 Codex 实现 232 倍加速的 QR 分解
Auto-research with codex: How I achieved a 232x Faster Kernel
在 GPU Mode 举办的自动研究竞赛中，我利用 Codex 将 Householder QR 分解内核的速度提升了 232 倍，最终在 183 名参赛者中位列第 12。作为一名非专业领域的挑战者，我通过构建高效的反馈循环，在 14 天内提交了超过 1500 次尝试。本文分享了我如何从学习基础数学概念开始，逐步掌握 blocked Householder 算法，并利用 LLM 的迭代能力突破性能瓶颈的完整过程。即使没有深厚的领域知识，只要掌握正确的提问方式和自动化工具，也能在高性能计算领域取得惊人成果。
你对某个领域了解得越深入，就越能向大型语言模型提出更好的问题，因为你能将未知的未知转化为已知的未知。
HN 评论区
92- Almondsetat
过去几天，我想试试最新的 DeepSeek v4 正式版。我把一个半废弃的视频编解码器仓库丢给它，让它执行常规的“基准测试 -> 性能剖析 -> 验证 -> 研究 -> 优化”循环。我特意选了这个编解码器，因为作者提供了比特流验证器，确保你在尝试自己的实现时不会搞坏东西。我让代理访问了编译器的性能分析工具，还有 Intel 的 VTune，它的输出非常棒。几个小时内，LLM 就生成了压缩和解压算法的 SSE 和 AVX 实现，单核性能几乎翻倍。接着我让它用 NVIDIA 的 NSIGHT 性能分析器作为指南来创建 CUDA 实现，它也开始干得不错。
就我个人而言，我认为 LLM 应该被视为 Prolog 或线性规划的高级版本：你给出约束条件，提供验证正确性的方法，并设定清晰的目标。如果 LLM 能够自我验证并自动纠偏，那你基本上就可以把它交给自动驾驶模式了。
- augment_me
竞赛中有一点值得注意：前 10 名解决方案中有 8 个都采用了这种优化方式，但它们在任何非竞赛输入数据上都会完全崩溃。
唯一在测试 OOD（分布外）形状时没有崩溃的解决方案，是由那些精通 GPU 编程的专家制作的。他们没有生成 2.5 万行 CUDA 代码，而是在合理的范围内遵循并调整了自己的方案。
从中得出的教训是：这些方法总是能解决特定性问题，但引导模型生成通用解决方案要难得多。所以，如果你是某个特定模型形状的推理服务提供者，那太棒了，尽管用吧。但如果你是开源库的维护者，这就没用了。
- sqquima
算是元评论吧，但读到这么一大段看起来不像 AI 生成的文字，感觉还挺新鲜的。谢谢。
- tosh
训练材料似乎在 GPU 内核和 SIMD 方面特别丰富。
我想知道，这是因为研究人员在开发模型时需要这些，所以特意多投入了精力，还是说这只是语言模型特别擅长而人类却感到棘手的某个子领域？
- lmeyerov
为 GFQL 开发自定义变体一直非常有趣，GFQL 是首个面向 CPU+GPU 的开源可嵌入 Cypher 属性图查询引擎：
- 加速了新后端（如 polars）的推出，包括新的惰性模式（lazy mode）和规划器（planner），这些从根本上开辟了新的路径；
- 虽然我们最初的目标是拿下 GPU 基准测试的榜首，但现在我们也保持着 CPU 性能的首位！
从长远来看，更让我感兴趣的是，这开启了对“查询引擎意味着什么”的重新思考。目前，我们正在努力使其在整体上成为最快的引擎，特别是在我们自己的使用场景、主要行业基准测试以及用户的工作负载上。同时，类似于 JIT 和多阶段计算，我们正在探索用户可以采用的新的提前优化（ahead-of-time）技术，这些技术比单纯插入自定义索引更有趣。本质上，如果我们的代理能够快速进行特化，那么我们也应该向用户的代理暴露一些安全的钩子（hooks）！