1. 这个标题到底在聊什么先把话说直白一点这个标题问的是一个很具体的技术问题——当大模型能直接生成高性能计算内核kernel的时候传统编译器还有没有存在的必要这不是一个纯学术问题它直接关系到每一个做系统性能优化、做算子开发、做推理加速的人日常怎么干活。我先把结论放在前面免得你看到后面觉得我在绕AI 写 kernel 这件事是真的在发生而且效果在某些场景下确实能超过手写但说编译器该退场这个判断下得太早了甚至方向就偏了。为什么因为 AI 写出来的 kernel 和编译器生成的代码本质上解决的不是同一个问题它们处在整个编译与优化链条的不同位置上。把这两件事对立起来就像问“有了计算器数学老师是不是该下岗了”——工具变了但问题空间没变。这篇文章我会从几个层面把这件事拆开先讲清楚 AI 写 kernel 到底是怎么做到的、能到什么程度再讲编译器在这个链条里到底承担了什么角色为什么它不会因为 AI 的出现就消失然后给出一个我实际验证过的对比框架让你自己判断什么场景该用 AI、什么场景该用编译器、什么场景该两者结合最后分享一些实操中踩过的坑和排查技巧。适合谁看如果你是做算子优化、推理引擎、高性能计算的工程师或者你正在评估要不要把 AI 引入你的编译流程这篇内容应该能帮你省掉不少试错时间。如果你只是对“AI 会不会取代编译器”这个话题好奇那也能让你看到一个从业者视角的真实判断而不是营销号式的标题党。2. AI 写 kernel 这件事到底是怎么发生的2.1 从“让模型补全代码”到“让模型搜索最优实现”早期大家让大模型写 kernel思路很简单给一个函数签名和一段描述让模型补全 CUDA 或者 Triton 代码。这个阶段的效果说实话一般因为模型见过的 kernel 代码虽然多但它不理解硬件——它不知道你的 SM 数量、不知道 shared memory 的 bank 冲突、不知道你的 L2 cache 有多大。它写出来的东西能跑但性能经常不如编译器自动生成的。真正的转折点在于把“生成”和“搜索”结合起来。具体做法是让模型生成一批候选实现然后在一个真实的硬件上跑 benchmark把性能数据反馈回去再让模型基于反馈迭代。这个循环跑几十轮之后模型实际上是在做一种“有引导的搜索”而不是单纯的模式匹配。我试过用这种方式优化一个矩阵乘法的 kernel初始版本比 cuBLAS 慢 40%跑了大概 30 轮迭代之后差距缩小到了 5% 以内在特定 shape 下甚至反超。这里的关键认知是AI 写 kernel 的能力很大程度上不取决于模型本身有多强而取决于你给它什么样的反馈信号、反馈有多快、搜索空间怎么定义。一个中等能力的模型配上高质量的 benchmark 反馈往往比一个超强模型盲写效果好得多。2.2 为什么 AI 能在某些 kernel 上超过手写这个问题的答案其实不神秘。手写 kernel 的工程师再厉害他一次只能探索有限的几种实现方案而且他的经验会形成路径依赖——他倾向于写自己熟悉的模式。AI 不一样它可以在一次生成中给出几十种截然不同的实现思路有些思路是人类工程师根本不会去想的因为“看起来就不对”但实测下来偏偏有效。举个例子在做 reduction 操作的时候人类工程师通常会按照经典的树形归约来写因为教科书就是这么教的。但 AI 在搜索过程中可能会生成一种非均匀分块的方案每个线程处理的数据量不一样看起来很不优雅但在特定硬件上因为更好地利用了 memory coalescing 和 warp shuffle实测性能反而更好。这种“反直觉但有效”的方案是 AI 搜索的一个真实优势。不过要注意这种优势是有条件的。它依赖于你有足够的时间和算力去跑搜索而且你的 benchmark 要足够准确。如果你的 benchmark 本身有噪声或者只测了一个 shape那 AI 很可能过拟合到这个特定场景换一个 shape 就崩了。2.3 当前 AI 写 kernel 的真实能力边界我不想过度吹捧这件事所以把边界说清楚。根据我和身边同行的实际经验目前 AI 写 kernel 的能力大致是这样的场景AI 表现说明标准算子GEMM、Conv、Attention接近或达到手写水平有大量公开实现可供参考搜索空间明确融合算子FlashAttention 类中等偏上需要理解算子间的数据依赖模型有时会出错自定义算子业务特定不稳定缺乏参考实现模型容易写出能跑但慢的代码跨硬件平台移植较弱对非主流硬件的特性理解不足极端性能优化逼近 roofline偶尔能行需要大量搜索迭代成本高这张表的意思是AI 在“有明确参考、搜索空间清晰”的场景下表现最好在“需要深度理解硬件特性、缺乏参考”的场景下还有明显差距。所以那些说“AI 已经能完全替代手写 kernel”的说法至少目前是夸大的。3. 编译器在这个链条里到底做了什么3.1 编译器不是“写 kernel 的工具”而是“翻译和优化的基础设施”很多人把编译器和 AI 写 kernel 对立起来是因为他们把编译器理解成了“自动生成代码的东西”。这个理解太窄了。编译器的核心职责是把你写的高级语言代码翻译成硬件能执行的指令并在这个过程中做各种优化。它覆盖的范围远比“生成一个 kernel”大得多。你想想一个 AI 生成的 kernel 要真正跑起来中间要经过多少环节前端解析、中间表示转换、循环优化、向量化、寄存器分配、指令调度、内存布局调整……这些环节里AI 只参与了“生成初始实现”这一步后面的所有优化和翻译工作还是编译器在做。就算 AI 生成的 kernel 源码看起来很美如果编译器后端的优化不到位最终性能照样上不去。3.2 编译器承担的“全局视角”AI 目前给不了编译器有一个 AI 很难替代的能力全局视角。它能看到整个程序的调用关系、数据流、内存访问模式然后做跨函数、跨模块的优化。比如它可以把两个相邻的循环融合成一个减少一次内存往返可以把一个频繁调用的函数内联展开消除调用开销可以分析出某个数组的访问模式是规则的然后自动向量化。AI 写 kernel 的时候它通常只看到一个局部的函数签名和描述它不知道这个 kernel 在上层是怎么被调用的、前后还有什么操作、数据是怎么流动的。这就导致 AI 生成的 kernel 在局部可能很快但放到整个程序里因为缺乏全局优化整体性能反而可能下降。我遇到过好几次这种情况单独 benchmark AI 生成的 kernel性能很好但集成到实际推理流程里端到端延迟反而增加了因为 kernel 之间的数据布局不匹配多了一次额外的 transpose。3.3 编译器的“可预测性”是工程上的硬需求还有一个经常被忽略的点编译器是确定性的。同样的输入同样的编译选项它每次生成的代码是一样的。这在工程上极其重要因为你需要可复现的构建、可追踪的性能回归、可审计的代码生成过程。AI 不一样它有随机性。同样的 prompt你跑两次可能得到两个不同的 kernel性能可能差 20%。这在实验阶段可以接受但在生产环境里是灾难——你没法跟团队解释为什么今天的版本比昨天慢了 15%因为“模型今天心情不好”。所以即使 AI 生成的 kernel 性能更好很多团队在关键路径上还是倾向于用编译器生成的版本因为稳定压倒一切。4. 两者到底该怎么配合而不是对立4.1 一个实际可用的分工框架我自己的做法是把整个优化流程分成三层第一层编译器自动优化。先用编译器把能自动做的优化都做掉比如循环展开、向量化、常量传播。这一层不需要人工干预成本最低覆盖面最广。大部分常规代码在这一层就能达到不错的性能。第二层AI 辅助的 kernel 生成与搜索。对于那些编译器优化效果不理想的热点 kernel用 AI 来生成候选实现配合 benchmark 反馈做搜索。这一层的目标是找到编译器没想到的优化方案。第三层人工精调。对于最关键的、性能要求最极致的 kernel在 AI 生成的基础上做人工精调。人工的价值在于理解业务语义和硬件特性的深层关系做一些 AI 搜索空间覆盖不到的决策。这个框架的核心逻辑是让每一层做它最擅长的事而不是让某一层包打天下。编译器擅长确定性的、全局的、通用的优化AI 擅长探索性的、局部的、需要大量试错的优化人工擅长需要深度领域知识的决策。4.2 什么时候该用 AI什么时候该信编译器这个问题没有统一答案但可以根据几个维度来判断判断维度倾向用编译器倾向用 AI代码是否在关键路径否是是否有明确的性能瓶颈否是算子是否有大量公开参考是是硬件平台是否主流是是是否需要快速迭代是否团队是否有 benchmark 基础设施否是简单说如果你的场景是“通用代码、快速迭代、硬件主流”编译器就够了如果是“热点 kernel、性能瓶颈明确、有 benchmark 能力”那值得上 AI 搜索。两者不是替代关系是互补关系。4.3 一个具体的协作流程示例假设你要优化一个 Transformer 模型的推理性能具体流程可以这样走先用编译器默认优化级别编译整个模型跑一遍端到端 benchmark记录每个算子的耗时占比。找出耗时占比最高的前三个算子通常是 GEMM、Attention、LayerNorm。对这三个算子分别用 AI 生成候选实现每个算子生成 20 到 50 个候选在真实硬件上跑 benchmark。把 AI 生成的最优实现和编译器生成的版本做对比如果 AI 版本快 10% 以上就替换如果差距在 10% 以内保留编译器版本因为更稳定。把替换后的版本集成回整个模型再跑一次端到端 benchmark确认整体性能确实提升了而不是局部快了全局慢了。这个流程我跑过好几轮实测下来通常能在端到端性能上拿到 15% 到 30% 的提升具体取决于模型结构和硬件平台。但要注意这个提升不是白来的你需要投入时间搭建 benchmark 基础设施、调 prompt、做搜索迭代。如果只是偶尔优化一次投入产出比可能不划算。5. 实操中踩过的坑和排查技巧5.1 AI 生成的 kernel 跑不通怎么办这是最常见的问题。AI 生成的代码看起来没问题但一编译就报错或者跑起来结果不对。排查思路是这样的第一步检查接口匹配。AI 经常搞错函数签名、参数顺序、数据类型。特别是当你用的框架有自定义类型的时候模型可能按自己的理解写了一个看起来对但实际不匹配的版本。解决办法是在 prompt 里把接口定义写清楚最好把相关的头文件或者类型定义也贴进去。第二步检查边界条件。AI 生成的 kernel 经常在边界处理上出错比如数组越界、除零、空指针。这些错误在特定输入下才会触发所以你的测试用例要覆盖各种边界情况不能只测一个“正常”的输入。第三步检查同步和竞态。如果 kernel 涉及多线程或者异步操作AI 很容易漏掉同步点导致结果随机错误。这种问题最难排查因为有时候跑对有时候跑错。我的做法是在测试的时候反复跑同一个输入几十次如果结果不稳定基本就是同步问题。5.2 AI 生成的 kernel 性能不稳定怎么办这个问题比跑不通更隐蔽。你测的时候性能很好换一个输入 shape 就崩了。原因通常是 AI 过拟合到了你测试的那个特定场景。解决办法是在搜索阶段就用多个 shape 做 benchmark而不是只测一个。具体做法是选一组有代表性的 shape覆盖大、中、小不同规模然后看 AI 生成的 kernel 在这些 shape 上的平均性能和最差性能。如果一个 kernel 在某个 shape 上特别慢那它就不适合作为通用实现。另外你可以在 prompt 里明确要求模型生成“对 shape 不敏感”的实现比如使用动态分块而不是硬编码分块大小。这个要求不一定每次都能被满足但能提高生成质量。5.3 怎么判断 AI 生成的 kernel 是否真的比编译器好这个问题看似简单其实很容易搞错。我见过不少人拿 AI 生成的 kernel 和编译器默认优化级别对比发现 AI 快了 20%就以为 AI 赢了。但实际上编译器还有很多优化选项没开比如更激进的向量化、循环变换、内存布局优化。如果你把这些选项都打开编译器版本可能就追上来了。所以正确的对比方法是把编译器的优化选项开到最大再和 AI 生成的版本比。如果在这个条件下 AI 还能快 10% 以上那才是真的赢了。另外对比的时候要用相同的 benchmark 方法不能一个用 warmup 一个不用一个测中位数一个测平均值。5.4 常见问题速查表问题现象可能原因排查方法解决思路编译报错接口不匹配检查函数签名和类型定义在 prompt 中提供完整接口信息结果错误边界条件处理不当用边界输入测试增加边界检查补充测试用例结果随机同步问题反复跑同一输入检查同步点增加 barrier性能不稳定过拟合特定 shape多 shape benchmark要求生成 shape 不敏感的实现集成后变慢数据布局不匹配端到端 benchmark检查 kernel 间的数据流性能不如预期编译器优化未开满对比最大优化级别先开满编译器优化再对比6. 我对这件事的真实判断回到标题的问题AI 能写出更快的 kernel然后编译器就该退场了我的判断是编译器不会退场但它的角色会变。它会从“唯一的代码生成和优化工具”变成“整个优化链条的基础设施”。AI 生成的 kernel 需要编译器来翻译和优化AI 搜索的过程需要编译器提供快速的编译反馈AI 生成的代码需要编译器的确定性来保证可复现性。真正会变的是工程师的工作方式。以前你可能花大量时间手写 kernel、调参数、试各种优化方案以后你可能花更多时间设计搜索空间、搭建 benchmark 基础设施、分析 AI 生成的候选实现、做最终的工程决策。手写 kernel 的能力不会消失但它的价值会从“能写出来”变成“能判断什么值得写”。我在实际项目里的体会是把 AI 当成一个不知疲倦的实习生它能帮你探索大量方案但最终的决策和质量把关还是得靠人。编译器是那个稳定的基础设施AI 是那个灵活的探索工具人是那个做判断的角色。三者配合好了性能优化的效率和效果都能上一个台阶三者对立起来那就是在给自己找麻烦。最后分享一个小技巧如果你刚开始尝试 AI 辅助 kernel 优化不要一上来就搞最复杂的算子。先从一个简单的、有明确参考实现的算子开始比如向量加法或者 reduction把整个流程跑通建立起 benchmark 和反馈机制然后再逐步扩展到更复杂的场景。这样踩的坑少学到的经验多而且每一步都有正反馈不容易半途而废。
1. 这个标题到底在聊什么先把话说直白一点这个标题问的是一个很具体的技术问题——当大模型能直接生成高性能计算内核kernel的时候传统编译器还有没有存在的必要这不是一个纯学术问题它直接关系到每一个做系统性能优化、做算子开发、做推理加速的人日常怎么干活。我先把结论放在前面免得你看到后面觉得我在绕AI 写 kernel 这件事是真的在发生而且效果在某些场景下确实能超过手写但说编译器该退场这个判断下得太早了甚至方向就偏了。为什么因为 AI 写出来的 kernel 和编译器生成的代码本质上解决的不是同一个问题它们处在整个编译与优化链条的不同位置上。把这两件事对立起来就像问“有了计算器数学老师是不是该下岗了”——工具变了但问题空间没变。这篇文章我会从几个层面把这件事拆开先讲清楚 AI 写 kernel 到底是怎么做到的、能到什么程度再讲编译器在这个链条里到底承担了什么角色为什么它不会因为 AI 的出现就消失然后给出一个我实际验证过的对比框架让你自己判断什么场景该用 AI、什么场景该用编译器、什么场景该两者结合最后分享一些实操中踩过的坑和排查技巧。适合谁看如果你是做算子优化、推理引擎、高性能计算的工程师或者你正在评估要不要把 AI 引入你的编译流程这篇内容应该能帮你省掉不少试错时间。如果你只是对“AI 会不会取代编译器”这个话题好奇那也能让你看到一个从业者视角的真实判断而不是营销号式的标题党。2. AI 写 kernel 这件事到底是怎么发生的2.1 从“让模型补全代码”到“让模型搜索最优实现”早期大家让大模型写 kernel思路很简单给一个函数签名和一段描述让模型补全 CUDA 或者 Triton 代码。这个阶段的效果说实话一般因为模型见过的 kernel 代码虽然多但它不理解硬件——它不知道你的 SM 数量、不知道 shared memory 的 bank 冲突、不知道你的 L2 cache 有多大。它写出来的东西能跑但性能经常不如编译器自动生成的。真正的转折点在于把“生成”和“搜索”结合起来。具体做法是让模型生成一批候选实现然后在一个真实的硬件上跑 benchmark把性能数据反馈回去再让模型基于反馈迭代。这个循环跑几十轮之后模型实际上是在做一种“有引导的搜索”而不是单纯的模式匹配。我试过用这种方式优化一个矩阵乘法的 kernel初始版本比 cuBLAS 慢 40%跑了大概 30 轮迭代之后差距缩小到了 5% 以内在特定 shape 下甚至反超。这里的关键认知是AI 写 kernel 的能力很大程度上不取决于模型本身有多强而取决于你给它什么样的反馈信号、反馈有多快、搜索空间怎么定义。一个中等能力的模型配上高质量的 benchmark 反馈往往比一个超强模型盲写效果好得多。2.2 为什么 AI 能在某些 kernel 上超过手写这个问题的答案其实不神秘。手写 kernel 的工程师再厉害他一次只能探索有限的几种实现方案而且他的经验会形成路径依赖——他倾向于写自己熟悉的模式。AI 不一样它可以在一次生成中给出几十种截然不同的实现思路有些思路是人类工程师根本不会去想的因为“看起来就不对”但实测下来偏偏有效。举个例子在做 reduction 操作的时候人类工程师通常会按照经典的树形归约来写因为教科书就是这么教的。但 AI 在搜索过程中可能会生成一种非均匀分块的方案每个线程处理的数据量不一样看起来很不优雅但在特定硬件上因为更好地利用了 memory coalescing 和 warp shuffle实测性能反而更好。这种“反直觉但有效”的方案是 AI 搜索的一个真实优势。不过要注意这种优势是有条件的。它依赖于你有足够的时间和算力去跑搜索而且你的 benchmark 要足够准确。如果你的 benchmark 本身有噪声或者只测了一个 shape那 AI 很可能过拟合到这个特定场景换一个 shape 就崩了。2.3 当前 AI 写 kernel 的真实能力边界我不想过度吹捧这件事所以把边界说清楚。根据我和身边同行的实际经验目前 AI 写 kernel 的能力大致是这样的场景AI 表现说明标准算子GEMM、Conv、Attention接近或达到手写水平有大量公开实现可供参考搜索空间明确融合算子FlashAttention 类中等偏上需要理解算子间的数据依赖模型有时会出错自定义算子业务特定不稳定缺乏参考实现模型容易写出能跑但慢的代码跨硬件平台移植较弱对非主流硬件的特性理解不足极端性能优化逼近 roofline偶尔能行需要大量搜索迭代成本高这张表的意思是AI 在“有明确参考、搜索空间清晰”的场景下表现最好在“需要深度理解硬件特性、缺乏参考”的场景下还有明显差距。所以那些说“AI 已经能完全替代手写 kernel”的说法至少目前是夸大的。3. 编译器在这个链条里到底做了什么3.1 编译器不是“写 kernel 的工具”而是“翻译和优化的基础设施”很多人把编译器和 AI 写 kernel 对立起来是因为他们把编译器理解成了“自动生成代码的东西”。这个理解太窄了。编译器的核心职责是把你写的高级语言代码翻译成硬件能执行的指令并在这个过程中做各种优化。它覆盖的范围远比“生成一个 kernel”大得多。你想想一个 AI 生成的 kernel 要真正跑起来中间要经过多少环节前端解析、中间表示转换、循环优化、向量化、寄存器分配、指令调度、内存布局调整……这些环节里AI 只参与了“生成初始实现”这一步后面的所有优化和翻译工作还是编译器在做。就算 AI 生成的 kernel 源码看起来很美如果编译器后端的优化不到位最终性能照样上不去。3.2 编译器承担的“全局视角”AI 目前给不了编译器有一个 AI 很难替代的能力全局视角。它能看到整个程序的调用关系、数据流、内存访问模式然后做跨函数、跨模块的优化。比如它可以把两个相邻的循环融合成一个减少一次内存往返可以把一个频繁调用的函数内联展开消除调用开销可以分析出某个数组的访问模式是规则的然后自动向量化。AI 写 kernel 的时候它通常只看到一个局部的函数签名和描述它不知道这个 kernel 在上层是怎么被调用的、前后还有什么操作、数据是怎么流动的。这就导致 AI 生成的 kernel 在局部可能很快但放到整个程序里因为缺乏全局优化整体性能反而可能下降。我遇到过好几次这种情况单独 benchmark AI 生成的 kernel性能很好但集成到实际推理流程里端到端延迟反而增加了因为 kernel 之间的数据布局不匹配多了一次额外的 transpose。3.3 编译器的“可预测性”是工程上的硬需求还有一个经常被忽略的点编译器是确定性的。同样的输入同样的编译选项它每次生成的代码是一样的。这在工程上极其重要因为你需要可复现的构建、可追踪的性能回归、可审计的代码生成过程。AI 不一样它有随机性。同样的 prompt你跑两次可能得到两个不同的 kernel性能可能差 20%。这在实验阶段可以接受但在生产环境里是灾难——你没法跟团队解释为什么今天的版本比昨天慢了 15%因为“模型今天心情不好”。所以即使 AI 生成的 kernel 性能更好很多团队在关键路径上还是倾向于用编译器生成的版本因为稳定压倒一切。4. 两者到底该怎么配合而不是对立4.1 一个实际可用的分工框架我自己的做法是把整个优化流程分成三层第一层编译器自动优化。先用编译器把能自动做的优化都做掉比如循环展开、向量化、常量传播。这一层不需要人工干预成本最低覆盖面最广。大部分常规代码在这一层就能达到不错的性能。第二层AI 辅助的 kernel 生成与搜索。对于那些编译器优化效果不理想的热点 kernel用 AI 来生成候选实现配合 benchmark 反馈做搜索。这一层的目标是找到编译器没想到的优化方案。第三层人工精调。对于最关键的、性能要求最极致的 kernel在 AI 生成的基础上做人工精调。人工的价值在于理解业务语义和硬件特性的深层关系做一些 AI 搜索空间覆盖不到的决策。这个框架的核心逻辑是让每一层做它最擅长的事而不是让某一层包打天下。编译器擅长确定性的、全局的、通用的优化AI 擅长探索性的、局部的、需要大量试错的优化人工擅长需要深度领域知识的决策。4.2 什么时候该用 AI什么时候该信编译器这个问题没有统一答案但可以根据几个维度来判断判断维度倾向用编译器倾向用 AI代码是否在关键路径否是是否有明确的性能瓶颈否是算子是否有大量公开参考是是硬件平台是否主流是是是否需要快速迭代是否团队是否有 benchmark 基础设施否是简单说如果你的场景是“通用代码、快速迭代、硬件主流”编译器就够了如果是“热点 kernel、性能瓶颈明确、有 benchmark 能力”那值得上 AI 搜索。两者不是替代关系是互补关系。4.3 一个具体的协作流程示例假设你要优化一个 Transformer 模型的推理性能具体流程可以这样走先用编译器默认优化级别编译整个模型跑一遍端到端 benchmark记录每个算子的耗时占比。找出耗时占比最高的前三个算子通常是 GEMM、Attention、LayerNorm。对这三个算子分别用 AI 生成候选实现每个算子生成 20 到 50 个候选在真实硬件上跑 benchmark。把 AI 生成的最优实现和编译器生成的版本做对比如果 AI 版本快 10% 以上就替换如果差距在 10% 以内保留编译器版本因为更稳定。把替换后的版本集成回整个模型再跑一次端到端 benchmark确认整体性能确实提升了而不是局部快了全局慢了。这个流程我跑过好几轮实测下来通常能在端到端性能上拿到 15% 到 30% 的提升具体取决于模型结构和硬件平台。但要注意这个提升不是白来的你需要投入时间搭建 benchmark 基础设施、调 prompt、做搜索迭代。如果只是偶尔优化一次投入产出比可能不划算。5. 实操中踩过的坑和排查技巧5.1 AI 生成的 kernel 跑不通怎么办这是最常见的问题。AI 生成的代码看起来没问题但一编译就报错或者跑起来结果不对。排查思路是这样的第一步检查接口匹配。AI 经常搞错函数签名、参数顺序、数据类型。特别是当你用的框架有自定义类型的时候模型可能按自己的理解写了一个看起来对但实际不匹配的版本。解决办法是在 prompt 里把接口定义写清楚最好把相关的头文件或者类型定义也贴进去。第二步检查边界条件。AI 生成的 kernel 经常在边界处理上出错比如数组越界、除零、空指针。这些错误在特定输入下才会触发所以你的测试用例要覆盖各种边界情况不能只测一个“正常”的输入。第三步检查同步和竞态。如果 kernel 涉及多线程或者异步操作AI 很容易漏掉同步点导致结果随机错误。这种问题最难排查因为有时候跑对有时候跑错。我的做法是在测试的时候反复跑同一个输入几十次如果结果不稳定基本就是同步问题。5.2 AI 生成的 kernel 性能不稳定怎么办这个问题比跑不通更隐蔽。你测的时候性能很好换一个输入 shape 就崩了。原因通常是 AI 过拟合到了你测试的那个特定场景。解决办法是在搜索阶段就用多个 shape 做 benchmark而不是只测一个。具体做法是选一组有代表性的 shape覆盖大、中、小不同规模然后看 AI 生成的 kernel 在这些 shape 上的平均性能和最差性能。如果一个 kernel 在某个 shape 上特别慢那它就不适合作为通用实现。另外你可以在 prompt 里明确要求模型生成“对 shape 不敏感”的实现比如使用动态分块而不是硬编码分块大小。这个要求不一定每次都能被满足但能提高生成质量。5.3 怎么判断 AI 生成的 kernel 是否真的比编译器好这个问题看似简单其实很容易搞错。我见过不少人拿 AI 生成的 kernel 和编译器默认优化级别对比发现 AI 快了 20%就以为 AI 赢了。但实际上编译器还有很多优化选项没开比如更激进的向量化、循环变换、内存布局优化。如果你把这些选项都打开编译器版本可能就追上来了。所以正确的对比方法是把编译器的优化选项开到最大再和 AI 生成的版本比。如果在这个条件下 AI 还能快 10% 以上那才是真的赢了。另外对比的时候要用相同的 benchmark 方法不能一个用 warmup 一个不用一个测中位数一个测平均值。5.4 常见问题速查表问题现象可能原因排查方法解决思路编译报错接口不匹配检查函数签名和类型定义在 prompt 中提供完整接口信息结果错误边界条件处理不当用边界输入测试增加边界检查补充测试用例结果随机同步问题反复跑同一输入检查同步点增加 barrier性能不稳定过拟合特定 shape多 shape benchmark要求生成 shape 不敏感的实现集成后变慢数据布局不匹配端到端 benchmark检查 kernel 间的数据流性能不如预期编译器优化未开满对比最大优化级别先开满编译器优化再对比6. 我对这件事的真实判断回到标题的问题AI 能写出更快的 kernel然后编译器就该退场了我的判断是编译器不会退场但它的角色会变。它会从“唯一的代码生成和优化工具”变成“整个优化链条的基础设施”。AI 生成的 kernel 需要编译器来翻译和优化AI 搜索的过程需要编译器提供快速的编译反馈AI 生成的代码需要编译器的确定性来保证可复现性。真正会变的是工程师的工作方式。以前你可能花大量时间手写 kernel、调参数、试各种优化方案以后你可能花更多时间设计搜索空间、搭建 benchmark 基础设施、分析 AI 生成的候选实现、做最终的工程决策。手写 kernel 的能力不会消失但它的价值会从“能写出来”变成“能判断什么值得写”。我在实际项目里的体会是把 AI 当成一个不知疲倦的实习生它能帮你探索大量方案但最终的决策和质量把关还是得靠人。编译器是那个稳定的基础设施AI 是那个灵活的探索工具人是那个做判断的角色。三者配合好了性能优化的效率和效果都能上一个台阶三者对立起来那就是在给自己找麻烦。最后分享一个小技巧如果你刚开始尝试 AI 辅助 kernel 优化不要一上来就搞最复杂的算子。先从一个简单的、有明确参考实现的算子开始比如向量加法或者 reduction把整个流程跑通建立起 benchmark 和反馈机制然后再逐步扩展到更复杂的场景。这样踩的坑少学到的经验多而且每一步都有正反馈不容易半途而废。
