Codex把GPU内核跑快232倍

截至 2026 年 8 月 15 日，一项由开发者 Sankalp 公开的实验显示，Codex 在持续编写、测试和淘汰 GPU Kernel 实现后，将目标内核的性能提升至初始版本的 232 倍。

这个数字足够抢眼，但也最容易被误读：232 倍不是整个大模型训练或推理系统快了 232 倍，也不代表 Codex 在所有 CUDA 优化任务上都有同等表现。它是特定硬件、特定输入形状、特定基线与单个 Kernel 共同作用下的结果。

真正重要的变化是，Codex 不再只是补全几行代码，而是开始承担一段完整的性能研究流程：提出假设、修改实现、编译运行、检查正确性、读取延迟，再根据结果决定保留还是回滚。这种工作方式更接近一个不知疲倦的初级性能工程师，而不是传统意义上的代码生成器。

232 倍是怎么跑出来的

**GPU Kernel 是运行在 GPU 上、负责执行某一类并行计算任务的底层函数。**矩阵乘法、归一化、注意力计算、激活函数和采样，都可能由一个或多个 Kernel 完成；它们往往只有几十到几百行，却能决定模型推理中的大部分延迟。

**自动研究是让智能体围绕一个可量化目标，自主执行“提出方案—运行实验—读取结果—继续迭代”的闭环。**它与一次性生成代码的区别在于，评价标准不来自模型自己的判断，而来自外部测试系统：输出错了就淘汰，速度慢了就回滚，只有更快且正确的版本才会成为下一轮起点。

Sankalp 的做法可以概括为四个环节：

1. 给 Codex 一份可以工作的初始 Kernel、参考实现与测试入口；
2. 要求它只围绕性能目标修改实现，并记录每轮实验结果；
3. 每次修改后先验证数值正确性，再执行基准测试；
4. 保留当前最快版本，让 Codex 从这个版本继续搜索。

**这套流程的关键不是提示词写得多复杂，而是实验环境足够机械、明确和可重复。**Codex 不需要凭语言概率判断某次优化是否有效，它可以直接看到延迟、吞吐量、编译错误和数值偏差。性能优化因此从开放式问答，变成了带有硬反馈的搜索问题。

按作者公布的口径，最终实现相对初始 Kernel 达到 232 倍加速。若两次测试的计时方法、输入规模和硬件完全一致，这相当于把执行时间压缩到原来的约 0.431%，即延迟下降约 99.57%。不过，原始耗时若未与结果一起披露，232 倍本身仍不足以说明它对真实应用有多大价值。

**超高倍数通常也意味着起点存在大量低垂果实。**一个没有合并访存、重复读写显存、使用低效线程布局或频繁同步的初始实现，确实可能被成熟方案拉开两个数量级；但当基线换成 cuBLAS、cuDNN、FlashAttention 或经过人工调优的 CUTLASS 实现后，剩余空间往往只有几个百分点到数十个百分点。

Codex 实际在优化什么

**GPU Kernel 优化本质上是在计算量、显存带宽、并行度和硬件资源占用之间重新分配成本。**模型可以改动的表面对象是代码，真正需要操纵的却是 GPU 的执行方式。

Codex 在这类循环中通常会探索以下方向：

• 调整 block、warp 和线程数量，使任务切分更贴合输入形状；
• 合并全局显存访问，减少不连续读取造成的带宽浪费；
• 使用共享内存或寄存器缓存中间结果，避免重复访问显存；
• 融合相邻操作，减少 Kernel Launch 和中间张量写回；
• 调整循环展开、向量化宽度和数据布局；
• 在允许误差范围内选择 FP16、BF16、FP8 或更合适的累加精度；
• 根据具体 GPU 的共享内存容量、寄存器数量和 Tensor Core 能力调整实现。

**Triton 是一种面向 GPU Kernel 的 Python 风格编程语言和编译器。**它比直接编写 CUDA C++ 更容易修改线程块、掩码和数据布局，因此特别适合让智能体进行高频实验；但 Triton 并不会自动消除硬件知识门槛，错误的 tile 大小、过高的寄存器压力和不合理的访存模式，照样会让性能变差。

Codex 的优势恰好在于它可以快速覆盖大量候选方案。人类工程师通常会基于经验选择三到五个最可能奏效的方向，而智能体可以继续尝试那些“看起来不太优雅但值得测一次”的组合。只要单轮编译与测试成本足够低，搜索数量本身就会转化为优势。

**智能体的短板则是缺少稳定的硬件因果模型。**它可能知道共享内存、warp divergence 和 occupancy 的概念，却未必能一次判断瓶颈究竟来自显存带宽、指令吞吐还是寄存器溢出。没有 profiler 数据时，它很容易退化成高成本的局部随机搜索。

232 倍与公开竞技场结果并不矛盾

**单例纪录和多任务平均成绩衡量的是两件不同的事。**前者展示智能体在一个有巨大优化空间的目标上能够走多远，后者则回答它面对不同算子、不同输入和不同基线时是否稳定。

2026 年 5 月公开的 AMD GPU 内核优化竞技场测试中，Codex Agent 搭配 GPT-5.3-Codex，在三类任务上的加速比分别为 3.61 倍、1.68 倍和 5.20 倍，整体表现与使用相近模型的 Cursor Agent 接近。这个结果远低于 232 倍，却更接近日常工程环境中可重复获得的收益区间。

| 测试口径 | 智能体或工具 | 公布加速比 | 更适合说明什么 | 主要限制 | |---|---|---:|---|---| | Sankalp 单 Kernel 自动研究实验 | Codex | 232 倍 | 单一目标上的搜索上限 | 高度依赖初始基线、硬件和输入形状 | | AMD 竞技场任务组一 | Codex Agent + GPT-5.3-Codex | 3.61 倍 | 跨任务优化能力 | 不能直接外推到所有 GPU 与算子 | | AMD 竞技场任务组二 | Codex Agent + GPT-5.3-Codex | 1.68 倍 | 面对较强基线时的实际增益 | 优化余量可能已经较小 | | AMD 竞技场任务组三 | Codex Agent + GPT-5.3-Codex | 5.20 倍 | 特定任务中的较高收益 | 仍是受控基准测试 |

**更合理的结论不是“Codex 普遍能提速 232 倍”，而是“Codex 已经能够自主发现人类初始实现中的大量性能损失”。**对于成熟库，期待 232 倍通常不现实；对于研究原型、临时算子、特殊张量形状和新硬件移植，几倍乃至数十倍仍有可能。

正确性检查比跑分更重要

**正确性优先是自动 Kernel 优化不可省略的底线。**一个把输出写成零、跳过边界元素或降低数值精度的实现可以非常快，但它不是优化，只是换了一道题。

RightNow-AI 开源的 AutoKernel 采用了类似思路：每个候选 Kernel 都先与 PyTorch 参考实现比较输出，通过正确性检查后才进入性能测量；错误实现会被立即回滚。项目同时提供 Triton 与 CUDA C++ 起始实现，并在 H100、A100 和 RTX 4090 上进行过测试。

**可靠的测试至少需要控制五类变量。**如果其中任何一项没有固定，智能体很可能会优化测试漏洞，而不是优化 Kernel。

• **数值容差：**应根据数据类型和计算规模设定 atol 与 rtol，不能只检查少量样本；
• **预热过程：**首次运行包含编译、缓存和显存初始化成本，不能直接用于计时；
• **重复测量：**应报告中位数和尾部延迟，避免单次系统抖动制造虚假提升；
• **输入覆盖：**必须测试多个形状、批量大小和非对齐边界，而不是只优化一个幸运尺寸；
• **环境固定：**GPU 型号、时钟、功耗限制、驱动和编译器版本都应记录。

**只为固定形状生成 Kernel 并不一定是作弊。**大模型在线推理本来就存在大量可预测形状，例如固定 head dimension、固定隐藏层宽度和有限的 batch 桶；针对这些形状专门编译，正是 TensorRT、Inductor 与各类推理引擎的常见做法。问题在于，文章或基准测试必须明确适用边界。

单个 Kernel 快 232 倍，系统可能只快一点

**阿姆达尔定律是计算程序局部优化对整体性能上限的公式。**如果某个 Kernel 只占端到端耗时的 1%，即使把它优化到接近零耗时，整个系统最多也只会快约 1.01 倍。

反过来，如果一个 Kernel 占总耗时的 60%，将它提速 1.5 倍，端到端性能约可提升到 1.25 倍；这比把一个仅占 5% 耗时的 Kernel 提速 3 倍更有价值，后者对整体性能的提升只有约 1.03 倍。

| Kernel 原始耗时占比 | Kernel 加速比 | 理论端到端加速比 | 工程价值判断 | |---:|---:|---:|---| | 1% | 232 倍 | 约 1.010 倍 | 跑分惊人，系统收益很小 | | 10% | 232 倍 | 约 1.111 倍 | 有价值，但远非数量级提升 | | 60% | 1.5 倍 | 1.25 倍 | 通常比冷门算子的极端纪录更重要 | | 80% | 5 倍 | 约 2.78 倍 | 足以显著改变吞吐与成本 |

AutoKernel 将这一原则直接放进编排器：先 profile 整个模型，再按潜在端到端收益排列瓶颈，并在边际收益下降时切换目标。这比让 Codex 无限打磨一个已经不重要的 Kernel 更接近生产实践。

**未来的竞争重点会从“谁能生成最快的单个 Kernel”转向“谁能决定最该优化哪个 Kernel”。**这要求智能体理解调用图、输入分布、显存峰值、并发策略和服务级目标，而不只是阅读一份孤立的 CUDA 文件。

这套方法对开发者有什么实际价值

**Codex 自动研究最适合有明确测试函数和明确指标的工程任务。**GPU Kernel 是理想试验场，因为正确性可以通过参考输出判断，性能可以用微秒测量，候选版本也能快速回滚。

适合交给智能体持续搜索的任务包括：

• 针对固定模型形状优化 Triton 算子；
• 把 PyTorch 组合操作融合为更少的 Kernel；
• 将 CUDA 实现迁移到新一代 GPU 或 AMD 平台；
• 为量化、稀疏计算和特殊数据布局寻找实现方案；
• 在多个候选参数之间自动搜索 block size、num warps 与 pipeline stage。

**不适合完全无人值守的任务是那些正确性难以自动判定、错误后果严重或测量噪声很大的优化。**例如跨节点通信、训练稳定性、并发内存安全和驱动层修改，都应由有经验的工程师审查。社区经验也普遍认为，在性能优化和重大功能变更中，专家 Review 仍然不可替代。

开发者还可以通过 awesome-kernel-skills 一类项目，把 profile、诊断、Triton、CUDA、CUTLASS 和不同 GPU 架构的调优经验整理成智能体可读取的技能文件。相比不断加长单次提示词，这种结构化知识更容易复用，也更便于团队审计。

我们的判断：232 倍是展示上限，不是交付承诺

**这次实验最值得关注的不是 232 倍，而是性能工程首次具备了可规模化搜索的雏形。**过去，Kernel 优化依赖少数熟悉 GPU 微架构的工程师，他们需要手动阅读 profiler、修改代码、重新编译并记录结果；现在，Codex 可以接管其中重复度最高的实验环节，让人类把精力集中在瓶颈判断、测试设计和最终审查上。

**Codex 目前更像性能工程师的实验执行器，而不是可以独立签字的专家。**它能够以远高于人的频率尝试方案，但仍需要人类决定指标是否合理、基线是否公平、数值误差是否可接受，以及单项提速能否转化为端到端收益。

232 倍因此应该被视为一个能力边界信号：当任务拥有可执行环境、严格测试和即时反馈时，编程智能体的上限明显高于一次性代码生成。下一阶段真正有商业价值的产品，不会只展示一张最快跑分截图，而会把 profiler、正确性验证、Amdahl 排序、硬件知识与自动回滚整合成一套持续运行的优化系统。

参考来源

• RightNow-AI / AutoKernel：面向 GPU Kernel 的自主优化框架，提供正确性验证、模型级 profile、瓶颈排序以及 Triton、CUDA C++ 起始实现。
• awesome-kernel-skills：GPU 算子优化技能集合，覆盖 Triton、CUDA、CUTLASS 及 NVIDIA、AMD 双平台经验。
• Codex 在推理框架上能蹬出什么优化：开发者对 Codex 参与推理框架优化、代码审查边界和实际工作量的经验总结。