1. 这场实验是怎么开始的让 AI 接管 GPU 内核优化1.1 基线数据才是整个账本的第一行上个季度我给某个图像处理链路过内核调优对象是一段运行在 GPU 上的图像预处理算子主要做缩放、归一化、色彩空间转换外加一轮 3x3 卷积。这套链路本身不复杂但当时性能已经让人头疼单看这段 GPU 内核真机实测平均耗时 108ms而整个端到端流程要 352ms。注意这里用的是真机实测不是模拟器估算也不是用 CPU 上的时间戳随便掐一下——后面我会专门讲测量方法。当时我手里有一个很诱人的选项让 AI 来写 GPU 内核。很多人觉得 AI 写代码只是辅助真到了 CUDA kernel 这种需要抠内存访问、抠线程组织、抠寄存器压力的场景AI 生成的代码根本不能看。我一开始也这么想但后来发现这个判断有点过期了。现在的模型对 CUDA 的理解已经深入到可以跟你讨论 L2 缓存命中率、bank conflict 和指令级并行这种层面。于是我把这段算子的基线数据、源码、还有硬件参数一起喂给了 AI让它做一轮内核级重写。结果有点出乎意料AI 重写后的内核在真机上跑到 16.4ms算下来是 6.6 倍的加速。但接下来才是真正打脸的地方。我把新内核接回完整流程端到端时间从 352ms 降到 281ms只有 1.25 倍。这就是标题里说的那笔账。内核级 6.6 倍是真实的端到端 1.25 倍也是真实的两者相差 5 倍以上的收益都在整个系统链路里被悄悄吃掉了。1.2 为什么我会想到把优化任务交给 AI而不是继续手写先说背景。这段图像预处理算子不是学术界玩具而是跑在真实业务里的代码要求数值鲁棒、边界完整、能在不同代际的 GPU 上稳定运行。正常情况下我会自己动手优化比如把循环展开、用向量化加载、调 block 大小、改共享内存策略。但这类手动优化有个问题人的惯性思维会把你锁死在某几种固定写法里。你翻来覆去调参数其实是在同一套思路里面打转。AI 不一样。它没有“我一直这么写”的包袱给的候选方案往往来自训练语料里各种开源项目、各种厂商 demo、各种竞赛代码的组合。特别是当你把 profiler 输出丢给它的时候它经常能指出一些你想不到的优化角度。比如这次它就没有按我预期去调 block 尺寸而是直接重写了数据加载路径把整个算子的内存访问模式换掉了。我不是说 AI 今天就能完全替代内核工程师但它完全可以当做一个非常激进、又不需要情绪的结对程序员。你负责验证和兜底它负责出奇招。1.3 把任务边界划清楚AI 写内核我负责验收用 AI 写 GPU 内核和用 AI 写普通业务代码有个本质区别正确性验证的成本完全不一样。普通代码跑坏了日志马上告诉你GPU 内核跑错了可能是数据错乱、可能是静默的数值偏移、也可能是特定输入下才崩溃甚至某些错误只在特定 GPU 架构上出现。所以我的工作流是AI 负责生成候选内核我负责搭验证环境。具体就是三件事随机输入回归测试、边界条件检查、以及用 profiler 做真机性能复测。AI 写不出一个可信的 6.6 倍只有真机数据能。这也是为什么我把这篇文章叫做“真机账本”——整篇文章我不讲玄学只讲账每个耗时是怎么测的、每个优化消耗了什么、收益最后落在哪里。2. AI 生成 GPU 内核的完整工作流与提示词策略2.1 我用的提示词结构约束、目标、硬件、容忍度如果你也想让 AI 写 GPU 内核第一件事不是写“给我优化一下这段 CUDA”这种提问只能得到泛泛而谈的答案。我的提示词结构分四块硬件环境、优化目标、约束条件、评估标准。缺一块AI 输出的质量就会明显下降。硬件环境要写清楚 GPU 型号、显存带宽、算力版本、L2 缓存大小甚至编译器的版本和编译选项。不同架构的优化策略差异非常大比如老架构上 shared memory 规模比较小AI 如果不知道就可能在共享内存方案上翻车。优化目标可以写“目标是将内核耗时降低至少 3 倍在不改变数值接口的前提下”。注意不要只写“优化”要给出可验证的量化目标。约束条件里我会写保持数值精度可容忍的误差范围、不引入非标准库依赖、兼容目标算力版本。还有一个容易被忽略的点让 AI 明确说明它希望我用哪条 profiler 数据来验证它的优化假设。我见过很多人用 AI 优化内核拿到的第一版代码跑起来反而更慢然后就得出结论说 AI 不行。但实际上往往是因为提示词里没给硬件细节AI 只能按通用最优来写结果在你特定的卡上不适合。2.2 “内核医生”模式让 AI 直接读 profiler 输出这里我想重点分享一个我觉得效率最高的用法——不是让 AI 凭空生成内核而是把内核的 profiler 输出喂给 AI让它像医生看体检报告一样定位问题。这个模式我称之为“内核医生”模式。操作上很简单先用 Nsight Compute对 NVIDIA 卡或 rocprof对 AMD 卡采一轮数据导出关键指标表格然后把表格和源码一起发给 AI要求它基于指标逐条解释瓶颈并给出具体的代码修改建议。这次优化最有价值的转折点就在这里。第一轮 AI 生成的代码只跑到了 67ms比基线好但远没到惊艳。我把它实测的 profiler 数据丢回去指出 DRAM 吞吐率很高但 L2 命中率偏低AI 看到这个数据后重新写了数据分块策略把输入从全局内存加载改为按 tile 预取到 shared memory并调整了 block 的遍历顺序。这一版才真正掉到了 16.4ms。关键不是 AI 会读 profiler而是你要会用 profiler 逼出有价值的数据然后让 AI 在这些数据的约束下做决策。换句话说AI 是医生你是那个送病人去做检查的人。检查做不做得准直接影响诊断质量。2.3 正确性验证数值误差、边界条件、随机数据回归AI 生成的 GPU 内核性能再漂亮过不了验证就是废代码。我踩过坑所以这里多啰嗦几句。第一道验证是数值误差。GPU 浮点运算本身就不是完全确定的尤其是涉及不同归约顺序、不同 fma 合并策略结果会有一点点差异。所以不能用“完全相等”来验证而应该用相对误差和绝对误差的阈值。我的标准是跟原始 C 实现逐元素对比相对误差控制在 1e-4 以内。第二道验证是边界条件。图像处理场景里最容易被忽略的是图像宽高不是 block 尺寸的整数倍。这时边界线程必须做钳位或者跳过否则要么越界读内存要么输出图边缘出现黑线。AI 生成的代码需要特别检查这个点因为它很可能默认了输入能被 block 整除。第三道验证是随机数据回归。我会准备几组不同尺寸、不同数值分布的数据集包括全零、全一、随机小数值、接近溢出的极大值分别跑旧内核和新内核再对比输出。这一步能筛掉大多数“碰巧能跑通”的错误实现。老实说这三道验证跑完之后我才会把效率数字写进账本。3. 6.6 倍内核加速是怎么测出来的基准测量里的坑3.1 计时到底该用什么工具CPU clock 与 GPU event 的差别“内核跑了 108ms 变成 16.4ms”这个结论背后如果不是严谨的测量方法那么所谓 6.6 倍就只是个笑话。我见过太多人拿 std::chrono 或者 CPU 时间戳直接包住内核调用然后得出一个离谱的数字。问题在于现代 GPU 是异步调度。CPU 发出内核启动命令后并不会等内核结束而是马上返回继续执行。如果用 CPU 的时钟去量“启动到返回”的时间量到的只是命令提交所花的时间跟内核真实执行时间几乎没有关系。更麻烦的是在默认情况下后端驱动会做命令合并这会让 CPU 端计时结果更不可信。我用的方法是 event 计时也就是在 CUDA 流里插入两个事件分别卡在内核启动前和内核结束后再调用事件同步函数去读取 GPU 端的时间戳。这样量出来的是内核在 GPU 上实际执行的时长。类似的做法在 HIP 里也有对应的事件 API。文章前面说的 108ms 和 16.4ms全部来自这种 GPU event 测量。另外还有一点要跑多轮取稳定值。GPU 内核第一次调用往往有编译缓存、驱动 JIT、显存页面调用的开销所以不能只跑一次。我的习惯是每轮内核预热 10 次然后正式计时跑 100 轮去掉最大最小值后取中位数。中位数比平均数更能抗噪音我以前用平均数结果被偶尔出现的调度毛刺骗了好几次。3.2 隔离测量环境频率、随机性、后台任务一个都不能少这段是账本里非常容易被人忽略的行。GPU 内核的真实性能跟你把机器放在什么状态下测有很大关系。我这次实验是在某型数据中心卡上跑的这种卡散热和供电都比较稳定但我还是犯了新手才会犯的错第一次测新内核是在开发机上跑的旁边还挂着几个浏览器页面和 IDE结果数字忽高忽低。后来我把测试挪到一个专门用来跑压测的环境同时用 NVIDIA 的时钟管理工具把 GPU 频率锁到了固定档位数据才真正稳定下来。桌面级 GPU 更要注意这个问题。笔记本 GPU 有功耗墙冷机和热机状态下跑同一个内核性能可以差 30% 以上。共享 GPU 的云环境也要小心同一块卡上如果还有其他人的任务DRAM 带宽会被抢占这时测出来的数据根本不代表你的内核真实水平。我建议的做法是测之前用查询工具确认 GPU 上只有你自己的进程然后把 GPU 工作频率锁在基准档再开始正式计账。如果你的场景连频率锁定的权限都没有那至少要保证测试环境前后一致这样对比基线和新内核时依然能得出相对准确的加速比。3.3 内核本身的数据账本从 108ms 到 16.4ms钱花在哪里了终于说到最核心的那笔账6.6 倍到底从哪里来。基线版本 108msAI 第一版本只有 67ms。这一版的主要改动是把逐像素处理的代码改成了向量化加载也就是一次读取 4 个像素或 8 个像素。原来每条线程单独处理一个像素每次加载都需要一次内存事务向量化之后单位内存事务搬运的数据量变大访问次数显著降低DRAM 效率就上来了。这个改动解释了 108ms 到 67ms 的大部分收益。真正让内核进入 16.4ms 的第二轮改动是前面提到的 tile 预取加共享内存复用。具体来说AI 把整张图像按照 block 大小切成 tile每个 block 先把对应的 tile 从全局内存搬进 shared memory然后在 shared memory 里做卷积和色彩转换。这样每个像素只访问一次全局内存剩下的计算全部在片上完成。3x3 卷积需要访问邻域像素原本每个像素周围 8 个邻居会被重复读取很多遍现在 tile 里的邻居都被一次性搬到了共享内存里重复访问变成了片上访问。这两个改动加在一起最终把内核从 108ms 干到了 16.4ms。准确说实测中位数是 16.4ms相对基线加速比正好是 6.6 倍。这里我还想提一个容易被忽视的点AI 在这两轮改动里并没有依赖什么奇技淫巧也没有用魔法参数它的每一步都有明确的硬件层面的依据。这也是为什么我愿意持续花时间给它反馈数据——它能基于实测数据做出合理的工程决策。4. 端到端只剩 1.25 倍收益耗散在哪里4.1 实测账本352ms → 281ms差的 91ms 去哪了内核从 108ms 降到 16.4ms理论上端到端应该节省大约 91.6ms。实测下来端到端从 352ms 降到 281ms恰好省了 71ms。咦怎么不是 91.6ms因为端到端时间不是简单地把各个内核时间相加。流程里还有其他 GPU 算子、有 CPU 端的前处理、有数据在 CPU 和 GPU 之间的搬运、有同步等待。这些部分的时间没有变但新的内核改变了整个流水线的节奏导致一部分时间被新的开销吞掉了。具体拆账如下环节优化前优化后变化目标内核108.0ms16.4ms-91.6msCPU 端预处理38.0ms38.0ms0主机到设备拷贝42.0ms46.0ms4.0ms其他 GPU 内核118.0ms118.0ms0同步与调度开销26.0ms25.0ms-1.0ms设备到主机拷贝20.0ms22.0ms2.0ms总计352.0ms265.4ms?注意表里加起来是 265.4ms但实测是 281ms。这中间还有 15.6ms 的差距主要是显存分配、API 调用、驱动层调度这些不容易逐项拆清楚的开销。总之内核省下来的 91.6ms有一部分被拷贝环节、调度环节的轻微恶化抵消了最终只表现出 71ms 的端到端收益。这里有一个很反直觉的点目标内核 6.6 倍加速之后它在整个流水线里的耗时占比从 108/35230.7% 降到了 16.4/2815.8%。换句话说一个原本占了三分之一时间的重头戏优化完之后变成了无足轻重的配角。剩下的大头反而变成了 CPU 预处理、数据拷贝和其他内核。这些环节在原来的优化方案里根本没被照顾到。4.2 Amdahl 定律在这里不是理论是算术我一直觉得 Amdahl 定律不应该只在操作系统课本里出现它应该刻在每个做性能优化的人脑子里。这个定律说得很简单系统加速比取决于你在优化上花力气的那个部分原本占总体时间的比例。如果某部分只占总时间的 20%那你把它优化到无限快整个系统最多也只能快 25%。我们可以直接算一下这次实验的账。假设优化前目标内核占端到端时间的比例大约是 30%352ms 里占 108ms。即使这个内核被优化到完全免费也就是耗时变成 0端到端理论上的极限也只是从 352ms 降到 244ms加速比也就 1.44 倍。现在实测做到了 281ms1.25 倍加速说明这个内核优化带来的收益基本都被系统链路接住了没有更进一步的浪费。这个算术让我清醒了很多。内核级 6.6 倍写出来很好看但如果你站在业务角度用户感受到的只是整个任务快了 25%感觉“好像没那么神”。两者都是对的区别只在于你从哪个层面看这件事。做 GPU 优化的人如果只盯内核时间很容易自我感觉良好然后被端到端数据打回原形。4.3 流水线瓶颈转移内核优化反而暴露了其他短板优化完内核后我重新用系统级的 profiler 扫了一遍整个链路发现了一个很有意思的现象瓶颈位置发生了转移。以前看一眼 Nsight Systems 的结果最大的长条是那个 108ms 的图像预处理内核时间戳图上非常扎眼。现在再看最大的长条变成了 CPU 端的预处理函数和主机到设备的数据拷贝其次是另一个原本不起眼的 GPU 内核——它现在占据了相对较大的时间比重因为整个流程里只有它还在慢吞吞地跑。这其实是一件好事。瓶颈转移说明前一个瓶颈被打破了但也意味着你必须立刻把注意力移到新的瓶颈上否则端到端收益就会停滞。很多人做完一次内核优化就收工了觉得已经大功告成但按这次实验的经验看优化工序里应该永远有一条循环逻辑优化某个热点 → 重新端到端测量 → 找新的热点 → 继续优化。直到你发现无论再怎么优化收益都小到不值得投入为止。从这次账本来看下一步真正该开刀的对象已经很清楚要么把 CPU 端预处理合并到 GPU 端一次性完成省掉一部分 H2D 拷贝要么把另外那个耗时 118ms 的 GPU 内核也交给 AI 优化一轮。前者是把数据搬运砍掉后者是继续压内核时间。两条线都有得做但都不是这一篇文章的账本范围了。5. 让端到端收益不缩水的链路级优化实操清单5.1 数据搬移才是大头H2D/D2H 优化手法回到这个项目本身如果我要再往深处做一轮优化目标会非常明确把主机到设备的拷贝时间砍掉。现在 46ms 的 H2D 拷贝时间已经超过了优化后的主内核是一个价值很高的新目标。最直接的思路不是优化拷贝本身而是减少拷贝的数据量。原来的链路里CPU 端会先做一轮图像缩放然后把缩放后的图像传上 GPU。这个步骤其实完全可以合并把原始图像的数据直接丢给 GPU让设备端的内核同时做缩放和归一化。这样做有两个好处一是省掉了一次 CPU 端的图像缩放预计算二是不需要把原始尺寸的数据来回搬只搬一次就行。这个思路在图像处理流水线里很常见只不过以前没人愿意冒险改流程现在性能压力逼着你必须改。另一个思路是固定显存缓冲池。如果你每次处理一帧图像都重新分配显存、再用完释放驱动层会反复做页表映射和内存清零这些开销在端到端时间里也会积累。项目里可以预分配一块足够大的显存池整个生命周期里重复使用避开分配和释放的抖动。这个做法对视频流场景尤其值得因为帧率恒定意味着每一帧都有相似的内存需求池化能稳定减少每帧的延迟。5.2 多 Stream 与事件同步把内核和传输叠起来端到端时间还有一个重要来源同步等待。默认流模式下内核执行、H2D 拷贝、D2H 拷贝是严格串行的前一步做完了才走下一步。但实际上 GPU 引擎是可以并行工作的拷贝引擎和计算引擎互相独立只要数据依赖不冲突它们完全可以同时干活。用多个 CUDA 流可以把流程改成生产者-消费者模式。比如把数据切成两半第一个半帧的 H2D 拷贝和第二个半帧的 H2D 拷贝可以在不同流上交替执行同时第一个半帧的计算也能在拷贝第二个半帧时启动。理论上只要数据宽度足够这种流水线结构可以把传输时间和计算时间重叠端到端时间接近“max(传输时间, 计算时间)”而不是“传输时间 计算时间”。实现方面要注意用事件来卡依赖不要用流同步函数去傻等。每个流的内部顺序天然保证依赖但跨流依赖必须手动插入事件标记否则会出现数据还没拷完就跑计算的竞争条件。这个坑我踩过跑出来的结果一会儿对一会儿错最后发现是跨流同步漏了事件。5.3 一次“收益率”联调的过程回顾最后想记录一下这次联调给我的整体感受。AI 写 GPU 内核这件事不能只看最终有没有跑出 6.6 倍还得看整个投入产出比。算时间账的话我这次从准备数据到拿到一个可用的优化内核总共花了大概三天时间。其中真正“打字”的时间很少大部分时间是花在验证正确性和测量性能上。作为对比如果让我手写优化这段内核我估计要一到两周而且大概率不会想到换掉整个内存访问模式。这种效率提升的来源不完全是 AI 的代码生成能力更关键的是它能把 profiler 数据直接转换成代码修改动作。传统工作流里profiler 数据出来之后你得自己理解瓶颈、想方案、写代码、重新测量。而现在很多环节可以交给 AI 去迭代人只负责把关。这个模式我在其他场景试过几次包括写矩阵乘法的分块内核、优化归约操作效果都很稳定。当然也有翻车的时候。AI 在某些隐含并行语义非常复杂的算子比如稀疏计算、动态形状的注意力内核上给出的方案经常不够稳。这种场景我会上手改。但总体来看AI 写 GPU 内核算力已经过了“图一乐”的阶段可以在真实项目里作为正式优化手段来使用。5.4 如果你想复现这套流程建议从这几个环节开始说了这么多给一份可以直接照着做的清单方便你下次遇到类似的 GPU 内核优化任务时直接抄作业。第一步先把基准数据测准。用 GPU 事件计时预热十轮再正式测一百轮取中位数。这一步不做好后面所有收益数字都不可信。第二步收集 profiler 数据。对 NVIDIA GPU 用 Nsight Compute 拉 L2 命中率、DRAM 吞吐率、寄存器压力、bank conflict 这几项关键指标AMD GPU 对应使用 ROCm 生态的分析工具。记下数据不要直接看默认的“速度得分”那些综合分数解释性很差。第三步构造高质量的提示词。把硬件型号、编译命令、内核源码、profiler 表格原样贴给 AI要求它列出每条瓶颈和对应的代码修改而不是直接要求它给一版优化代码。两轮迭代能覆盖大部分常见场景。第四步验证正确性。随机数据回归加边界输入是底线数值误差阈值按你的业务场景定。我习惯用相对误差阈值。一定不要跳过这步就直接上线AI 生成的代码在边界条件下最容易出事。第五步接回完整链路用系统级工具测端到端。如果发现收益缩水就按 Amdahl 定律的视角找下一个瓶颈看看剩余时间里哪个环节占比最大再去优化那个环节。反复循环直到收益曲线明显变平。这套流程最后沉淀下来的不只是一个快了很多倍的内核更是一套可以重复使用的方法论。做性能优化的人最怕的不是优化不动而是优化完之后发现整条链路根本没变得好用。真机账本的意义就在于每一次优化到底有没有给最终用户带来体验上的提升要拿数据说话。至少这一次实验账是算得清的内核级 6.6 倍加速是真的端到端 1.25 倍也是真的而这两者之间的距离正是下一步工程该补上的短板。
1. 这场实验是怎么开始的让 AI 接管 GPU 内核优化1.1 基线数据才是整个账本的第一行上个季度我给某个图像处理链路过内核调优对象是一段运行在 GPU 上的图像预处理算子主要做缩放、归一化、色彩空间转换外加一轮 3x3 卷积。这套链路本身不复杂但当时性能已经让人头疼单看这段 GPU 内核真机实测平均耗时 108ms而整个端到端流程要 352ms。注意这里用的是真机实测不是模拟器估算也不是用 CPU 上的时间戳随便掐一下——后面我会专门讲测量方法。当时我手里有一个很诱人的选项让 AI 来写 GPU 内核。很多人觉得 AI 写代码只是辅助真到了 CUDA kernel 这种需要抠内存访问、抠线程组织、抠寄存器压力的场景AI 生成的代码根本不能看。我一开始也这么想但后来发现这个判断有点过期了。现在的模型对 CUDA 的理解已经深入到可以跟你讨论 L2 缓存命中率、bank conflict 和指令级并行这种层面。于是我把这段算子的基线数据、源码、还有硬件参数一起喂给了 AI让它做一轮内核级重写。结果有点出乎意料AI 重写后的内核在真机上跑到 16.4ms算下来是 6.6 倍的加速。但接下来才是真正打脸的地方。我把新内核接回完整流程端到端时间从 352ms 降到 281ms只有 1.25 倍。这就是标题里说的那笔账。内核级 6.6 倍是真实的端到端 1.25 倍也是真实的两者相差 5 倍以上的收益都在整个系统链路里被悄悄吃掉了。1.2 为什么我会想到把优化任务交给 AI而不是继续手写先说背景。这段图像预处理算子不是学术界玩具而是跑在真实业务里的代码要求数值鲁棒、边界完整、能在不同代际的 GPU 上稳定运行。正常情况下我会自己动手优化比如把循环展开、用向量化加载、调 block 大小、改共享内存策略。但这类手动优化有个问题人的惯性思维会把你锁死在某几种固定写法里。你翻来覆去调参数其实是在同一套思路里面打转。AI 不一样。它没有“我一直这么写”的包袱给的候选方案往往来自训练语料里各种开源项目、各种厂商 demo、各种竞赛代码的组合。特别是当你把 profiler 输出丢给它的时候它经常能指出一些你想不到的优化角度。比如这次它就没有按我预期去调 block 尺寸而是直接重写了数据加载路径把整个算子的内存访问模式换掉了。我不是说 AI 今天就能完全替代内核工程师但它完全可以当做一个非常激进、又不需要情绪的结对程序员。你负责验证和兜底它负责出奇招。1.3 把任务边界划清楚AI 写内核我负责验收用 AI 写 GPU 内核和用 AI 写普通业务代码有个本质区别正确性验证的成本完全不一样。普通代码跑坏了日志马上告诉你GPU 内核跑错了可能是数据错乱、可能是静默的数值偏移、也可能是特定输入下才崩溃甚至某些错误只在特定 GPU 架构上出现。所以我的工作流是AI 负责生成候选内核我负责搭验证环境。具体就是三件事随机输入回归测试、边界条件检查、以及用 profiler 做真机性能复测。AI 写不出一个可信的 6.6 倍只有真机数据能。这也是为什么我把这篇文章叫做“真机账本”——整篇文章我不讲玄学只讲账每个耗时是怎么测的、每个优化消耗了什么、收益最后落在哪里。2. AI 生成 GPU 内核的完整工作流与提示词策略2.1 我用的提示词结构约束、目标、硬件、容忍度如果你也想让 AI 写 GPU 内核第一件事不是写“给我优化一下这段 CUDA”这种提问只能得到泛泛而谈的答案。我的提示词结构分四块硬件环境、优化目标、约束条件、评估标准。缺一块AI 输出的质量就会明显下降。硬件环境要写清楚 GPU 型号、显存带宽、算力版本、L2 缓存大小甚至编译器的版本和编译选项。不同架构的优化策略差异非常大比如老架构上 shared memory 规模比较小AI 如果不知道就可能在共享内存方案上翻车。优化目标可以写“目标是将内核耗时降低至少 3 倍在不改变数值接口的前提下”。注意不要只写“优化”要给出可验证的量化目标。约束条件里我会写保持数值精度可容忍的误差范围、不引入非标准库依赖、兼容目标算力版本。还有一个容易被忽略的点让 AI 明确说明它希望我用哪条 profiler 数据来验证它的优化假设。我见过很多人用 AI 优化内核拿到的第一版代码跑起来反而更慢然后就得出结论说 AI 不行。但实际上往往是因为提示词里没给硬件细节AI 只能按通用最优来写结果在你特定的卡上不适合。2.2 “内核医生”模式让 AI 直接读 profiler 输出这里我想重点分享一个我觉得效率最高的用法——不是让 AI 凭空生成内核而是把内核的 profiler 输出喂给 AI让它像医生看体检报告一样定位问题。这个模式我称之为“内核医生”模式。操作上很简单先用 Nsight Compute对 NVIDIA 卡或 rocprof对 AMD 卡采一轮数据导出关键指标表格然后把表格和源码一起发给 AI要求它基于指标逐条解释瓶颈并给出具体的代码修改建议。这次优化最有价值的转折点就在这里。第一轮 AI 生成的代码只跑到了 67ms比基线好但远没到惊艳。我把它实测的 profiler 数据丢回去指出 DRAM 吞吐率很高但 L2 命中率偏低AI 看到这个数据后重新写了数据分块策略把输入从全局内存加载改为按 tile 预取到 shared memory并调整了 block 的遍历顺序。这一版才真正掉到了 16.4ms。关键不是 AI 会读 profiler而是你要会用 profiler 逼出有价值的数据然后让 AI 在这些数据的约束下做决策。换句话说AI 是医生你是那个送病人去做检查的人。检查做不做得准直接影响诊断质量。2.3 正确性验证数值误差、边界条件、随机数据回归AI 生成的 GPU 内核性能再漂亮过不了验证就是废代码。我踩过坑所以这里多啰嗦几句。第一道验证是数值误差。GPU 浮点运算本身就不是完全确定的尤其是涉及不同归约顺序、不同 fma 合并策略结果会有一点点差异。所以不能用“完全相等”来验证而应该用相对误差和绝对误差的阈值。我的标准是跟原始 C 实现逐元素对比相对误差控制在 1e-4 以内。第二道验证是边界条件。图像处理场景里最容易被忽略的是图像宽高不是 block 尺寸的整数倍。这时边界线程必须做钳位或者跳过否则要么越界读内存要么输出图边缘出现黑线。AI 生成的代码需要特别检查这个点因为它很可能默认了输入能被 block 整除。第三道验证是随机数据回归。我会准备几组不同尺寸、不同数值分布的数据集包括全零、全一、随机小数值、接近溢出的极大值分别跑旧内核和新内核再对比输出。这一步能筛掉大多数“碰巧能跑通”的错误实现。老实说这三道验证跑完之后我才会把效率数字写进账本。3. 6.6 倍内核加速是怎么测出来的基准测量里的坑3.1 计时到底该用什么工具CPU clock 与 GPU event 的差别“内核跑了 108ms 变成 16.4ms”这个结论背后如果不是严谨的测量方法那么所谓 6.6 倍就只是个笑话。我见过太多人拿 std::chrono 或者 CPU 时间戳直接包住内核调用然后得出一个离谱的数字。问题在于现代 GPU 是异步调度。CPU 发出内核启动命令后并不会等内核结束而是马上返回继续执行。如果用 CPU 的时钟去量“启动到返回”的时间量到的只是命令提交所花的时间跟内核真实执行时间几乎没有关系。更麻烦的是在默认情况下后端驱动会做命令合并这会让 CPU 端计时结果更不可信。我用的方法是 event 计时也就是在 CUDA 流里插入两个事件分别卡在内核启动前和内核结束后再调用事件同步函数去读取 GPU 端的时间戳。这样量出来的是内核在 GPU 上实际执行的时长。类似的做法在 HIP 里也有对应的事件 API。文章前面说的 108ms 和 16.4ms全部来自这种 GPU event 测量。另外还有一点要跑多轮取稳定值。GPU 内核第一次调用往往有编译缓存、驱动 JIT、显存页面调用的开销所以不能只跑一次。我的习惯是每轮内核预热 10 次然后正式计时跑 100 轮去掉最大最小值后取中位数。中位数比平均数更能抗噪音我以前用平均数结果被偶尔出现的调度毛刺骗了好几次。3.2 隔离测量环境频率、随机性、后台任务一个都不能少这段是账本里非常容易被人忽略的行。GPU 内核的真实性能跟你把机器放在什么状态下测有很大关系。我这次实验是在某型数据中心卡上跑的这种卡散热和供电都比较稳定但我还是犯了新手才会犯的错第一次测新内核是在开发机上跑的旁边还挂着几个浏览器页面和 IDE结果数字忽高忽低。后来我把测试挪到一个专门用来跑压测的环境同时用 NVIDIA 的时钟管理工具把 GPU 频率锁到了固定档位数据才真正稳定下来。桌面级 GPU 更要注意这个问题。笔记本 GPU 有功耗墙冷机和热机状态下跑同一个内核性能可以差 30% 以上。共享 GPU 的云环境也要小心同一块卡上如果还有其他人的任务DRAM 带宽会被抢占这时测出来的数据根本不代表你的内核真实水平。我建议的做法是测之前用查询工具确认 GPU 上只有你自己的进程然后把 GPU 工作频率锁在基准档再开始正式计账。如果你的场景连频率锁定的权限都没有那至少要保证测试环境前后一致这样对比基线和新内核时依然能得出相对准确的加速比。3.3 内核本身的数据账本从 108ms 到 16.4ms钱花在哪里了终于说到最核心的那笔账6.6 倍到底从哪里来。基线版本 108msAI 第一版本只有 67ms。这一版的主要改动是把逐像素处理的代码改成了向量化加载也就是一次读取 4 个像素或 8 个像素。原来每条线程单独处理一个像素每次加载都需要一次内存事务向量化之后单位内存事务搬运的数据量变大访问次数显著降低DRAM 效率就上来了。这个改动解释了 108ms 到 67ms 的大部分收益。真正让内核进入 16.4ms 的第二轮改动是前面提到的 tile 预取加共享内存复用。具体来说AI 把整张图像按照 block 大小切成 tile每个 block 先把对应的 tile 从全局内存搬进 shared memory然后在 shared memory 里做卷积和色彩转换。这样每个像素只访问一次全局内存剩下的计算全部在片上完成。3x3 卷积需要访问邻域像素原本每个像素周围 8 个邻居会被重复读取很多遍现在 tile 里的邻居都被一次性搬到了共享内存里重复访问变成了片上访问。这两个改动加在一起最终把内核从 108ms 干到了 16.4ms。准确说实测中位数是 16.4ms相对基线加速比正好是 6.6 倍。这里我还想提一个容易被忽视的点AI 在这两轮改动里并没有依赖什么奇技淫巧也没有用魔法参数它的每一步都有明确的硬件层面的依据。这也是为什么我愿意持续花时间给它反馈数据——它能基于实测数据做出合理的工程决策。4. 端到端只剩 1.25 倍收益耗散在哪里4.1 实测账本352ms → 281ms差的 91ms 去哪了内核从 108ms 降到 16.4ms理论上端到端应该节省大约 91.6ms。实测下来端到端从 352ms 降到 281ms恰好省了 71ms。咦怎么不是 91.6ms因为端到端时间不是简单地把各个内核时间相加。流程里还有其他 GPU 算子、有 CPU 端的前处理、有数据在 CPU 和 GPU 之间的搬运、有同步等待。这些部分的时间没有变但新的内核改变了整个流水线的节奏导致一部分时间被新的开销吞掉了。具体拆账如下环节优化前优化后变化目标内核108.0ms16.4ms-91.6msCPU 端预处理38.0ms38.0ms0主机到设备拷贝42.0ms46.0ms4.0ms其他 GPU 内核118.0ms118.0ms0同步与调度开销26.0ms25.0ms-1.0ms设备到主机拷贝20.0ms22.0ms2.0ms总计352.0ms265.4ms?注意表里加起来是 265.4ms但实测是 281ms。这中间还有 15.6ms 的差距主要是显存分配、API 调用、驱动层调度这些不容易逐项拆清楚的开销。总之内核省下来的 91.6ms有一部分被拷贝环节、调度环节的轻微恶化抵消了最终只表现出 71ms 的端到端收益。这里有一个很反直觉的点目标内核 6.6 倍加速之后它在整个流水线里的耗时占比从 108/35230.7% 降到了 16.4/2815.8%。换句话说一个原本占了三分之一时间的重头戏优化完之后变成了无足轻重的配角。剩下的大头反而变成了 CPU 预处理、数据拷贝和其他内核。这些环节在原来的优化方案里根本没被照顾到。4.2 Amdahl 定律在这里不是理论是算术我一直觉得 Amdahl 定律不应该只在操作系统课本里出现它应该刻在每个做性能优化的人脑子里。这个定律说得很简单系统加速比取决于你在优化上花力气的那个部分原本占总体时间的比例。如果某部分只占总时间的 20%那你把它优化到无限快整个系统最多也只能快 25%。我们可以直接算一下这次实验的账。假设优化前目标内核占端到端时间的比例大约是 30%352ms 里占 108ms。即使这个内核被优化到完全免费也就是耗时变成 0端到端理论上的极限也只是从 352ms 降到 244ms加速比也就 1.44 倍。现在实测做到了 281ms1.25 倍加速说明这个内核优化带来的收益基本都被系统链路接住了没有更进一步的浪费。这个算术让我清醒了很多。内核级 6.6 倍写出来很好看但如果你站在业务角度用户感受到的只是整个任务快了 25%感觉“好像没那么神”。两者都是对的区别只在于你从哪个层面看这件事。做 GPU 优化的人如果只盯内核时间很容易自我感觉良好然后被端到端数据打回原形。4.3 流水线瓶颈转移内核优化反而暴露了其他短板优化完内核后我重新用系统级的 profiler 扫了一遍整个链路发现了一个很有意思的现象瓶颈位置发生了转移。以前看一眼 Nsight Systems 的结果最大的长条是那个 108ms 的图像预处理内核时间戳图上非常扎眼。现在再看最大的长条变成了 CPU 端的预处理函数和主机到设备的数据拷贝其次是另一个原本不起眼的 GPU 内核——它现在占据了相对较大的时间比重因为整个流程里只有它还在慢吞吞地跑。这其实是一件好事。瓶颈转移说明前一个瓶颈被打破了但也意味着你必须立刻把注意力移到新的瓶颈上否则端到端收益就会停滞。很多人做完一次内核优化就收工了觉得已经大功告成但按这次实验的经验看优化工序里应该永远有一条循环逻辑优化某个热点 → 重新端到端测量 → 找新的热点 → 继续优化。直到你发现无论再怎么优化收益都小到不值得投入为止。从这次账本来看下一步真正该开刀的对象已经很清楚要么把 CPU 端预处理合并到 GPU 端一次性完成省掉一部分 H2D 拷贝要么把另外那个耗时 118ms 的 GPU 内核也交给 AI 优化一轮。前者是把数据搬运砍掉后者是继续压内核时间。两条线都有得做但都不是这一篇文章的账本范围了。5. 让端到端收益不缩水的链路级优化实操清单5.1 数据搬移才是大头H2D/D2H 优化手法回到这个项目本身如果我要再往深处做一轮优化目标会非常明确把主机到设备的拷贝时间砍掉。现在 46ms 的 H2D 拷贝时间已经超过了优化后的主内核是一个价值很高的新目标。最直接的思路不是优化拷贝本身而是减少拷贝的数据量。原来的链路里CPU 端会先做一轮图像缩放然后把缩放后的图像传上 GPU。这个步骤其实完全可以合并把原始图像的数据直接丢给 GPU让设备端的内核同时做缩放和归一化。这样做有两个好处一是省掉了一次 CPU 端的图像缩放预计算二是不需要把原始尺寸的数据来回搬只搬一次就行。这个思路在图像处理流水线里很常见只不过以前没人愿意冒险改流程现在性能压力逼着你必须改。另一个思路是固定显存缓冲池。如果你每次处理一帧图像都重新分配显存、再用完释放驱动层会反复做页表映射和内存清零这些开销在端到端时间里也会积累。项目里可以预分配一块足够大的显存池整个生命周期里重复使用避开分配和释放的抖动。这个做法对视频流场景尤其值得因为帧率恒定意味着每一帧都有相似的内存需求池化能稳定减少每帧的延迟。5.2 多 Stream 与事件同步把内核和传输叠起来端到端时间还有一个重要来源同步等待。默认流模式下内核执行、H2D 拷贝、D2H 拷贝是严格串行的前一步做完了才走下一步。但实际上 GPU 引擎是可以并行工作的拷贝引擎和计算引擎互相独立只要数据依赖不冲突它们完全可以同时干活。用多个 CUDA 流可以把流程改成生产者-消费者模式。比如把数据切成两半第一个半帧的 H2D 拷贝和第二个半帧的 H2D 拷贝可以在不同流上交替执行同时第一个半帧的计算也能在拷贝第二个半帧时启动。理论上只要数据宽度足够这种流水线结构可以把传输时间和计算时间重叠端到端时间接近“max(传输时间, 计算时间)”而不是“传输时间 计算时间”。实现方面要注意用事件来卡依赖不要用流同步函数去傻等。每个流的内部顺序天然保证依赖但跨流依赖必须手动插入事件标记否则会出现数据还没拷完就跑计算的竞争条件。这个坑我踩过跑出来的结果一会儿对一会儿错最后发现是跨流同步漏了事件。5.3 一次“收益率”联调的过程回顾最后想记录一下这次联调给我的整体感受。AI 写 GPU 内核这件事不能只看最终有没有跑出 6.6 倍还得看整个投入产出比。算时间账的话我这次从准备数据到拿到一个可用的优化内核总共花了大概三天时间。其中真正“打字”的时间很少大部分时间是花在验证正确性和测量性能上。作为对比如果让我手写优化这段内核我估计要一到两周而且大概率不会想到换掉整个内存访问模式。这种效率提升的来源不完全是 AI 的代码生成能力更关键的是它能把 profiler 数据直接转换成代码修改动作。传统工作流里profiler 数据出来之后你得自己理解瓶颈、想方案、写代码、重新测量。而现在很多环节可以交给 AI 去迭代人只负责把关。这个模式我在其他场景试过几次包括写矩阵乘法的分块内核、优化归约操作效果都很稳定。当然也有翻车的时候。AI 在某些隐含并行语义非常复杂的算子比如稀疏计算、动态形状的注意力内核上给出的方案经常不够稳。这种场景我会上手改。但总体来看AI 写 GPU 内核算力已经过了“图一乐”的阶段可以在真实项目里作为正式优化手段来使用。5.4 如果你想复现这套流程建议从这几个环节开始说了这么多给一份可以直接照着做的清单方便你下次遇到类似的 GPU 内核优化任务时直接抄作业。第一步先把基准数据测准。用 GPU 事件计时预热十轮再正式测一百轮取中位数。这一步不做好后面所有收益数字都不可信。第二步收集 profiler 数据。对 NVIDIA GPU 用 Nsight Compute 拉 L2 命中率、DRAM 吞吐率、寄存器压力、bank conflict 这几项关键指标AMD GPU 对应使用 ROCm 生态的分析工具。记下数据不要直接看默认的“速度得分”那些综合分数解释性很差。第三步构造高质量的提示词。把硬件型号、编译命令、内核源码、profiler 表格原样贴给 AI要求它列出每条瓶颈和对应的代码修改而不是直接要求它给一版优化代码。两轮迭代能覆盖大部分常见场景。第四步验证正确性。随机数据回归加边界输入是底线数值误差阈值按你的业务场景定。我习惯用相对误差阈值。一定不要跳过这步就直接上线AI 生成的代码在边界条件下最容易出事。第五步接回完整链路用系统级工具测端到端。如果发现收益缩水就按 Amdahl 定律的视角找下一个瓶颈看看剩余时间里哪个环节占比最大再去优化那个环节。反复循环直到收益曲线明显变平。这套流程最后沉淀下来的不只是一个快了很多倍的内核更是一套可以重复使用的方法论。做性能优化的人最怕的不是优化不动而是优化完之后发现整条链路根本没变得好用。真机账本的意义就在于每一次优化到底有没有给最终用户带来体验上的提升要拿数据说话。至少这一次实验账是算得清的内核级 6.6 倍加速是真的端到端 1.25 倍也是真的而这两者之间的距离正是下一步工程该补上的短板。
