做GPU算子优化这行真正让我觉得工作流被彻底重写的转折点是2026年下半年开始我们把LLM代理正式当成“一等优化手段”来用。以前提到优化kernel大家脑子里是Nsight Compute、SASS汇编、occupancy分析这些传统套路现在我的日常工作流里最核心的步骤变成了让LLM代理读一份完整的profile报告自己定位瓶颈生成候选kernel然后跑验证闭环。这件事放在两年前我不敢想放在半年前我觉得还不太成熟但到了2026年下半年它已经是我们在某个AI推理项目中实打实用起来的主力方案。这篇文章就围绕这个变化展开。我会把LLM代理为什么能在kernel优化里从“辅助工具”升级成“一等手段”讲清楚然后拆解一套完整的优化流程再给一个GQA算子优化的具体案例最后聊聊正确性验证、工程化集成和踩过的坑。适合正在做GPU算子优化、AI编译优化、推理引擎开发或者对LLM agent落地感兴趣的朋友。1. 变化从何而来LLM代理凭什么成为“一等优化手段”1.1 什么叫做“一等优化手段”先解释一下我说的“一等优化手段”。它不是指你打开一个对话框问一句“我这个kernel为什么慢”然后让模型给一堆泛泛的建议。那只是辅助连二等都算不上顶多是个人工智障答疑。我理解的“一等优化手段”是LLM代理被内嵌到优化闭环里它有自己的输入管道能读取性能分析器的原始输出、汇编代码、调度参数和源码它有自己的工具调用能力能编译、能跑测试、能收集反馈它还能基于前一轮跑出来的结果自我迭代直到性能或者正确性指标满足要求为止。换句话说它从一个“问答机器人”变成了优化流水线里的一个“决策节点”。这个节点可以对优化动作负责而且关键的是它可以解释自己的决策依据。1.2 传统优化流程到底哪里卡脖子要理解这个变化得先知道以前我们是怎么做kernel优化的。常规流程大概是跑一个benchmark拿到profile热点函数然后用GPU性能分析工具去看这个kernel的occupancy、访存带宽、bank conflict、指令吞吐这些指标。很多时候一眼就能看出来是访存瓶颈还是计算瓶颈但问题是当你要深入优化的时候你面对的是一个巨大的搜索空间。以一次典型优化为例同样一个GEMM kernel可能有十几种tiling策略、三五种子块尺寸、两种数据排布方式、若干共享内存padding方案。你怎么知道哪种组合最优很多团队靠经验、靠文档、靠试错。传统auto-tuning也能做但它是一个黑盒搜索代价高、可解释性差而且它不会告诉你“为什么这个方案好”。LLM代理的价值在于它把“从profile数据里读取线索”“回忆历史优化案例”“生成候选代码”“判断瓶颈类型”这些能力整合到了一起。它改变了优化动作的产生方式不再是一步步手查指标而是基于完整上下文的一次性综合诊断。1.3 为什么是2026年下半年才爆发其实LLM代理能读代码、能生成代码这件事并不新鲜但在2026年下半年几个条件终于凑齐了。第一个是上下文窗口和处理能力。优化一个kernel往往需要同时看几千行源码、几百行SASS、一份几MB的profile JSON。过去这些数据根本塞不进上下文现在可以了而且在结构化摘要之后重要信息不会丢。第二个是工具链的打通。GPU原厂分析器的输出格式越来越结构化编译器的中间表示也开始面向工具开放这让LLM代理都能直接解析原始数据不再需要人手工转述。第三个是验证闭环的成熟。LLM代理生成代码之后我们可以让它在沙箱里编译、跑数值校验、跑性能回归然后把结果反馈给它进行下一轮迭代。没有这个闭环代理的建议就永远是“建议”而有了闭环它就变成了一个真正能干活、能担责的优化执行者。我自己体会比较深的一点是在这个时间点劣化优化也就是用LLM代理做“分析到改代码的最后一公里”已经不是一个实验性玩法了它在工程上稳定到可以进CI、支持回滚、做灰度验证。这就是我决定把它当作一等手段的根本原因。2. 全流程重构LLM代理介入kernel优化的四个关键环节2.1 Profile数据预处理与瓶颈判定第一环也是最基础的一环是把原始的profile数据变成LLM代理能直接理解的结构化上下文。这个环节我以前做得非常痛苦。性能分析器导出的报告虽然很全但信息密度极低几千行指标只有几个是关键的。如果直接把原始报告全部塞给LLM代理它很容易被噪音干扰而且token消耗会很夸张。所以我们在前面加了一层预处理脚本从分析器输出里抽取最核心的信号包括kernel执行时间占比warp占用率与理论占用率的比值全局内存/共享内存的访存指令占比主要stalall或wait原因计数指令issue rate说明计算单元还是没有喂饱这些信号组合成一个压缩后的“瓶颈快照”和源码片段、编译选项一起交给LLM代理。代理拿到之后会先输出一个瓶颈分类结论比如“这是一个访存密集型瓶颈主要卡在L2 miss和global load延迟上”或者“这是指令延迟型瓶颈shared memory bank conflict导致stall”。这一步的输出质量直接决定后续优化方向对不对所以我们用了不少心思在快照的生成规则上。实践中我们还会让代理对“快照”给一个置信度。这个置信度不是它自己拍脑袋而是通过一个历史案例库做相似度匹配得到的。如果当前这个kernel的特征和之前某个成功优化的案例高度相似置信度就会高一些。有了这个机制我们敢让代理直接给出优化动作而不是只停留在分析层面。2.2 候选策略生成与kernel改写瓶颈判定完之后重头戏就来了让LLM代理基于诊断结果直接产生候选代码。这个环节和普通代码生成完全不是一回事。普通代码生成是“你给我一个描述我写一个实现”而kernel优化里的改写更像做一个高强度的代码迁移手术。它得读现有的SASS/PTX判断哪些循环该展开哪些内存访问可以合并哪些延迟可以通过异步拷贝掩盖然后把这些改动落到CUDA/Triton级别的源码上。举个例子在某个reduce类kernel里代理发现内核里有一段串行的原子操作导致整个block的吞吐被拖死。它会建议把原子操作替换成先warp内reduce再原子写的方式并且直接生成替换后的代码。这个建议放到以前需要一个人熟读CUDA编程指南、理解硬件执行模型之后才能给出来现在代理在几十秒内就能给出一版初稿。当然初稿不一定能直接通过编译。我们在工作中经常遇到的情况是代理改完的代码在语法上没问题但在某个边界条件上处理错了比如shared memory数组下标越界。这种情况我们不会直接弃用而是会把编译错误信息喂回给代理让它自己修复。多轮修复之后代码质量基本能接近熟练工程师的水平。这个环节里我们最看重的是“可解释的改动”。代理生成每一个改动时都要附带一段理由说明解释这个改动和瓶颈判定之间的因果关系。这段理由后面会成为优化记录的一部分方便我们审计。2.3 编译选项与启动参数联合搜索kernel优化不只是改代码很多时候启动配置比代码本身还重要。一个kernel最终的性能同时取决于block大小、grid大小、shared memory动态分配量、编译选项里的优化级别、ptxas选项。传统的做法是写一个Python脚本把这几个参数作为变量跑一遍网格搜索或者贝叶斯搜索。这个方法的问题是会陷入局部最优而且搜索次数上去了成本很高。LLM代理在这个环节的作用是把“内容特征”和“参数空间”连接起来。它会分析kernel访存模式和计算密度给出一个更聪明的启动配置起点。举例来说如果一个kernel的访存模式是连续广播式的代理会优先考虑使用较小的block配合较大的grid如果计算密度高它可能倾向用更高的寄存器上限来压低spill。然后它不会只给一组参数而是会生成一个参数矩阵交给底层搜索器去做局部验证。这样搜索空间被大幅缩减而且搜索方向有先验知识引导收敛效率高很多。我在实际项目里测过同样一个kernel、同样一个搜索预算用LLM代理给出的起点比随机起点快3-5倍收敛。更重要的是代理会在搜索过程中看中间结果如果某组参数虽然慢但在profile里显示某个指标明显改善它会把那组参数保留下来做进一步调查而不是简单丢掉。2.4 验证与迭代闭环最后一个环节也是让LLM代理真正“长跑”的关键验证与迭代闭环。我们把代理生成的候选kernel放进一个统一的验证流水线里。这个流水线会做四件事编译、数值校验、性能回归、细节指标收集。每一件事的结果都会被格式化成结构化的反馈再送回给代理。代理看到反馈之后会根据情况选择接受当前方案、继续微调某一处代码、或者完全推翻换一个思路。这套闭环机制让代理有了一种“干活”的感觉。它不是在一次性生成终极答案而是在一个可控的循环里逐步逼近目标。我见过代理一轮优化不满意第二轮加大了shared memory的复用粒度第三轮发现导致bank conflict又做了一次padding第四轮终于达到目标。整个过程大概两个多小时换作人工操作至少得一天。关于闭环我特别想强调一个经验反馈信息要分层。不要只把“性能提升了23%”这种笼统结果给代理要把具体指标也放进去比如“L2吞吐从XX提升到XX”“bank conflict计数从XX降到XX”“寄存器spill从XX降低到0”。代理只有看到这些细节才能在下一次改写时做出有针对性的决策而不是继续瞎试。3. 真实案例复盘一个GQA kernel的完整优化过程3.1 案例背景与基线数据我拿一个实际做过的案例来复盘这样看得更直观。项目背景是一个AI推理框架里面某一段GQAGrouped Query Attention算子在特定序列长度和batch配置下占据了端到端推理时间的19%左右。这个占比对注意力类算子来说偏高了我们团队决定对它做一轮深度优化。先看基线profile数据。我们跑了一组测试记录下来的关键指标如下表所示指标项基线数值单次kernel平均耗时472usSMEff流式多处理器实际利用率指标31%全局load执行占比24.5%L2 hit rate62.1%SM busy wait占比18.7%寄存器spill量112 bytes/thread从这组数据里基本能判断几个问题首先SM busy wait占比很高说明warp在等数据而不是在跑指令其次L2 hit rate不到65%说明访存局部性很差再加上全局load占比接近四分之一这是一个典型的访存等待型瓶颈。如果是过去的流程我会基于这些指标手工去翻源码找访存方式然后试几种方案。这一次我们把原始报告和源码直接交给了LLM代理。3.2 第一轮优化从访存路径和指令排布动手代理拿到数据之后第一轮给出来的诊断是这个kernel的主要延迟来源是KV cache读取阶段。它发现当时的实现里每个query会依次读取对应的多个KV头这个读取过程没有做向量化导致产生大量细粒度的非对齐loadL2请求次数被放大。代理给出的修改建议是把KV读取的指针访问改成float4对齐路径同时把读取KV数据的过程从query循环里拆出来用异步拷贝指令把数据预取到shared memory让计算和访存部分重叠。它还顺手帮我们调整了block内线程布局让相邻线程读取连续地址从而提升L2命中和DRAM burst效率。针对这一轮改动我们做了复测单次耗时从472us降到了331usSMEff提升到了38%L2 hit rate也提高到了71.4%。数字看起来不错但还没有达到我们预期的性能目标所以继续把它交给代理迭代。3.3 第二轮优化根据occupancy和shared memory容量调整第二轮代理没有直接改核心计算逻辑而是让我们跑了一组occupancy实验观察不同shared memory分配量下的实际占用率。跑完发现当前kernel为了预取KV数据把shared memory塞得很满导致一个SM上同时驻留的block数量少了一半warp级并行度不够数据等待的时间盖过了异步拷贝带来的收益。代理根据这个现象给出一个新方案不再为每个KV头分一块独立空间而是把KV头按组共享同一块预取缓冲区用索引标记区分不同组的位置。这样shared memory总量约下降了40%occupancy从50%提升到了75%以上。这个改动对代码结构的影响不小我们花了一些时间重构测试之后单次耗时降到了282us。这个成绩已经达到了项目预期我们决定就此收手不再做激进优化。优化完成后的最终数据如下表指标项基线数值优化后数值单次kernel平均耗时472us282usSMEff31%47%L2 hit rate62.1%79.3%SM busy wait占比18.7%9.2%寄存器spill量112 bytes/thread16 bytes/thread这个案例让我对LLM代理的实操价值有了更具体的认知。它两轮迭代分别解决了两个完全不同层次的问题第一轮是访存路径不合理第二轮是资源调配失衡。这两类问题在传统流程里可能需要两个工程师分别排查而且不一定能这么快给到可靠的修改方向。3.4 案例里我学到的取舍经验复盘这个案例有一个点是很值得说的代理第二轮建议重构shared memory分配策略时它在输出里特别标注了“这个改动会引入索引计算开销建议结合实测决定是否采用”。这个话术让我挺意外因为它体现出了一种妥协意识它知道自己推荐的方案不是免费的需要权衡。我后来在别的项目里也遇到过类似情况代理给出的最优方案A因为对代码侵入太大被我们拒绝了它随即生成了一个折中方案B性能只比A差一点但改动量小很多。这种“在约束条件下重新规划”的能力对工程落地来说特别重要。同时也得说一句公道话这个案例能顺利完成前提是我们有比较严格的验证机制。代理每一轮给的代码我们都跑了数值对比测试和单测确认逻辑没有偏掉。LLM代理生成代码的想象力是够的但约束性和边界条件依然是它的短板需要人来兜底。4. 正确性验证与性能回归让代理输出“可信”的工程保障4.1 正确性验证的三级围栏LLM代理再强它在本质上还是一个概率模型它可能给出结构漂亮但数值错误的代码。所以在所有流程里我最重视的是正确性验证。我们的做法是设置三级围栏。第一级是静态检查。在编译阶段用编译器和代码扫描工具检查明显的数组越界、未初始化变量、类型不匹配问题。这一级能拦住大部分低级错误。第二级是数值校验。我们会对代理生成的kernel跑一组随机输入和参考实现逐元素对比。对比时用相对误差和绝对误差双重判定。比如fp16的kernel我们一般设rtol1e-2、atol1e-2fp32设rtol1e-4。超过设定阈值就直接判失败不会进入性能测试。第三级是场景回归。某些算子在小输入下正确不代表在真实业务shape下也正确。所以我们会准备一组真实业务形状的测试样例跑端到端对比确保输出在可接受范围内。这套三级围栏跑一轮大概只需要几分钟成本可控但能极大减少代理代码引入线上问题的概率。4.2 性能回归看门狗正确性不是唯一的坑性能回退同样要重视。我们在CI里挂了一个“性能看门狗”每次代理提交新kernel版本都必须和当前最优版本跑同一组benchmark如果性能下降超过3%这个版本会自动标记为失败并附上详细对比数据。这个设计很关键因为代理在优化过程中可能会在某一步“改回去”导致性能倒挂又或者它在局部优化某项指标但整体性能变差了。比如有过一次代理把某个访存密集kernel的global load全部改成了 더宽的向量类型L2吞吐提升了不少但因为指令issue宽度也被占满计算效率反而下降了整体耗时涨了5%。如果没有性能看门狗我们很可能被L2吞吐这个“局部指标改善”误导。看门狗的逻辑我还想细化一下它不只看固定基准还会算一个“收益评估”。具体算法是对于每个优化版本记录它在不同shape下的耗时、带宽利用率和占用率然后和一个线性插值得到的期望曲线对比。如果某个shape下性能大幅偏离期望看门狗就会报警。这让我们能发现一些只有特定shape下才会暴露的问题。4.3 有效带宽与计算效率的计算逻辑验证性能时除了跑一下看耗时的秒表还要算两个硬指标有效内存带宽和FLOPs利用率。这两个指标能告诉我们一个kernel到底在硬件能力方面发挥了几成。有效内存带宽的计算公式很简单带宽 访存总量 / 实际耗时。比如一个kernel要读写的总数据量是8GB实际耗时0.002秒那有效带宽就是4000GB/s左右。把这个数值和硬件的理论峰值带宽做对比就能快速判断是不是访存瓶颈。FLOPs利用率也类似计算效率 实际计算量 /耗时 × 硬件峰值算力。举例来说一个kernel的访存量是2GB计算量是100TFLOPS实际耗时0.0004秒而硬件理论峰值是200TFLOPS那么它的计算效率就是100 /0.0004×200约等于125%说明有超额占用大概率是和其他kernel在争抢资源。这些指标看似基础但我发现很多团队在引入LLM代理之后反而容易忽略它们原因是代理给出的报告里已经写了结论大家懒得去验算。这绝对要不得。代理的结论只能作为参考硬指标才是唯一可信的事实依据。4.4 人类与代理的分工边界工程保障做足之后才到了人和代理怎么分工的问题。我的经验是不要全自动也不要完全人工走“半自动”路线。代理负责出分析和代码人负责审方案、卡准入、做最终决定。具体流程是代理生成一批候选版本每个版本附带详细说明工程师快速浏览说明挑出一个最合理的版本进入验证流水线验证通过后由工程师签字合并到主干。这里有一个容易被忽视的好处代理给出的“附带说明”可以作为改动的审计日志。以前我们做kernel优化经常出现“某天某个版本性能突变但没人记得改了什么”的情况。现在代理每改一处都会生成一个简洁的第一性原理说明长期积累下来这是非常宝贵的技术文档。我自己在项目中宁可让代理多花两分钟写清楚改动理由也不接受它像一个黑盒一样直接把代码丢出来。因为黑盒的代码没法评审、没法维护后面出了性能问题都无从查起。如果代理不解释我就会把它当普通auto-tuning工具用那就失去了“一等优化手段”的意义。5. 工程化集成套件、流程与踩坑后的最佳实践5.1 一套可复用的工具链分层LLM代理作为一等优化手段不是靠单个模型能力就能撑起来的它需要一整套工程设施。我们内部总结了一个工具链的分层设计大概分四层。数据层负责收集和格式化基础数据包括性能分析器的输出、SASS/PTX反汇编、源码、编译日志。这一层的核心工作是“把原始数据转化成结构化且易于检索的格式”。上下文组装层负责从数据层中抽取和当前优化目标最相关的信息组装成prompt。这个层是纯工程活但非常重要。组装得好不好直接决定代理分析质量。代理执行层负责调用LLM、处理工具调用、管理多轮对话状态。这个层会记住前面分析过什么、改过什么不需要每次从头讨论。验证层负责编译、测试、性能对比并把结果反馈回代理执行层。这个层充当了代理的“眼睛和手”让它能做闭环推理。这套分层设计最大的好处是各层可以独立替换。比如性能分析器换了一款只需要改数据层的解析逻辑不影响其他层。LLM模型要升级也只需要动代理执行层。5.2 离线优先与案例检索库说一个对落地影响巨大的经验离线优先与案例检索库。我们最初直接把每次优化任务都发到在线大模型API上去处理结果有几个问题一是token开销不低二是部分代码数据不适合频繁外传三是模型经常没有往年案例记忆每次遇到类似问题都要从零开始。后来我们改成了“离线优先”策略。本地维护一个轻量级代理环境历史优化案例、profile快照、成功方案全部沉淀到本地向量库和结构化案例库里。新任务进来时先做相似案例检索把最相关的3-5个历史案例作为参照上下文再让代理分析。这个改动带来的提升非常明显。以前代理第一次就给准方向的概率大概是40%到50%加入案例检索之后一次定位准的概率能到70%以上。尤其是同一个算子系列的优化比如对GEMM、attention、layernorm这一类常见算子历史案例的复用价值极高。我个人的观点是到了2026年下半年优化一个kernel的能力瓶颈已经不在于模型服务本身强不强而在于你的案例积累和检索工具有没有沉淀好。5.3 人工介入时机的判断还有一个经验是关于“什么时候该人工接管”。我们给代理设了一些触发条件代理连续三轮没有产出有效迭代方案或者连续两次在同一个问题上犯了同类型错误或者验证流水线连续三次失败时系统会自动向工程师发出求助信号。这个时候工程师必须介入而不是继续让代理自行尝试。为什么这么设计因为LLM代理在明确了错误信号的场景下是能自我修正的但在“方向错了但还没暴露”的情况下它会沿着错误方向重复试探浪费时间和计算资源。人工介入的临界点要设在“方向可疑”的时候而不是“彻底失败”的时候。举例来说有一次代理连续两轮都在调整block size但每次调整之后性能都在原地打转。工程师介入后发现它的优化方向完全被profile里的某个次要瓶颈带偏了真正的瓶颈是shared memory的bank conflict。这个信息一输入代理立刻切到了正确路径。如果没有人打断它可能还要多浪费几轮。5.4 从“能用”到“好用”的工程细节最后补充几个从“能用”到“好用”的工程细节。第一善用结构化输出。我们要求代理按统一JSON格式返回分析结论、改动说明和风险点而不是自由格式文本。这样后续验证层可以直接解析还能生成结构化报告。第二缓存历史验证结果。同一个kernel的同类优化任务如果验证结果已经存在就不用重复跑测试直接查缓存就能知道上次结果。这个机制在代理多轮迭代时特别高效。第三持久化中间产物。代理在优化过程里可能会生成一些被否掉的候选版本我们不会删掉而是保留下来作为负面案例。这些案例在后续训练检索模型、或者做自动评测时都很有价值。这些细节看起来不起眼但真正跑过几个项目之后你就会发现LLM代理能不能稳定发挥作用往往取决于这些工程地基而不是单一的大模型能力。6. 常见问题与排查实录6.1 代理给出的代码频繁编译失败怎么办这个问题几乎是100%会遇到的。代理生成的代码往往思路没问题但细节总有疏漏。我们的处理办法是把编译错误日志原样喂回给代理让它自己修改。这里有个关键点日志要完整包括具体的行号和错误消息不能只给个“编译失败”这种抽象信息。另外我们设置了编译错误次数上限。同一个任务里代理编译失败超过三次我们会强制它停下来反思让它重新读一遍自己之前生成的代码、对比正确的参考实现然后再提交。实测下来这个“反思”机制能明显降低连续编译失败的概率。6.2 代理生成的kernel数值误差超限怎么办数值误差超限的问题常见于浮点运算顺序被代理改变、或者归约逻辑重写后引入精度损失。我们的排查顺序是先缩小范围用相同输入分别跑代理代码和参考代码定位第一个误差超过容忍度的输出位置。然后把那一小段代码单独拿出来交给代理看让它分析误差来源。多数情况是因为它为了优化性能把求和顺序换成了树形归约或者增加了并行累加次数导致舍入误差变大。如果代理给的修复方案涉及牺牲一点性能换取精度我们一般会接受因为对于大多数推理场景稳定性和精度比那百分之一的性能提升重要得多。6.3 上下文太长关键信息丢失怎么办LLM代理处理大kernel时会遇到一个问题源码好几千行、汇编上万行全塞进上下文里不仅成本高而且关键信号被淹没。我们的解决思路是“先摘要再展开”。先让一个轻量脚本生成kernel的结构摘要包括主要循环、访存指令类型、共享内存使用情况、关键函数调用关系。代理基于摘要判断最可能的瓶颈区域然后只针对那个区域去读完整源码。这个机制几乎可以解决全部上下文长度问题。需要注意的是摘要的质量直接决定后续分析准确性所以我们对摘要脚本的要求是必须保留与性能相关的信息比如循环内是否有乘加链、是否有bank冲突风险这些要比代码的注释重要得多。6.4 代理自信地给出错误结论时怎么办LLM代理有时会以非常肯定的语气给出错误结论这是它作为概率模型的天性。我的经验是不要试图靠“话术”让它变得谦虚而是靠机制对冲风险。一个有效方法是引入“双模型对抗”。主代理负责出方案一个独立的评审模型负责挑毛病。评审模型不直接生成优化方案只负责检查现有方案的逻辑漏洞和风险点。如果评审模型提出了质疑主代理必须针对质疑做出回应并决定是否修改。这个“提议-反驳-修正”的结构实操下来效果不错可以把明显有逻辑漏洞的方案挡在验证流水线之前。6.5 关于“代理的一等化”最后想说的话做到这里回头看整个变化我最大的感触是LLM代理成为一等优化手段靠的不只是模型变聪明了而是我们把整个优化流程重新设计了一遍。让代理能在正确的时间、接触正确的数据、产生正确的动作、收到正确的反馈。我踩过不少坑也走过弯路但最终沉淀下来一套可复用的工作流。如果你也在尝试把LLM代理引入到自己的GPU/AI算子优化流程里我建议先别急着追求全自动而是从“代理生成建议 人工决策 自动验证”这种半自动模式开始。跑通闭环之后再逐步把更多决策权交给代理。更重要的是把每一轮优化的案例都沉淀下来形成自己的案例库。大模型本身没有记忆力案例库才是你和代理共同积累的长期记忆。有了这个记忆LLM代理才能真正从一个偶尔灵光的咨询顾问变成一个越来越靠谱的“一等优化手段”。
做GPU算子优化这行真正让我觉得工作流被彻底重写的转折点是2026年下半年开始我们把LLM代理正式当成“一等优化手段”来用。以前提到优化kernel大家脑子里是Nsight Compute、SASS汇编、occupancy分析这些传统套路现在我的日常工作流里最核心的步骤变成了让LLM代理读一份完整的profile报告自己定位瓶颈生成候选kernel然后跑验证闭环。这件事放在两年前我不敢想放在半年前我觉得还不太成熟但到了2026年下半年它已经是我们在某个AI推理项目中实打实用起来的主力方案。这篇文章就围绕这个变化展开。我会把LLM代理为什么能在kernel优化里从“辅助工具”升级成“一等手段”讲清楚然后拆解一套完整的优化流程再给一个GQA算子优化的具体案例最后聊聊正确性验证、工程化集成和踩过的坑。适合正在做GPU算子优化、AI编译优化、推理引擎开发或者对LLM agent落地感兴趣的朋友。1. 变化从何而来LLM代理凭什么成为“一等优化手段”1.1 什么叫做“一等优化手段”先解释一下我说的“一等优化手段”。它不是指你打开一个对话框问一句“我这个kernel为什么慢”然后让模型给一堆泛泛的建议。那只是辅助连二等都算不上顶多是个人工智障答疑。我理解的“一等优化手段”是LLM代理被内嵌到优化闭环里它有自己的输入管道能读取性能分析器的原始输出、汇编代码、调度参数和源码它有自己的工具调用能力能编译、能跑测试、能收集反馈它还能基于前一轮跑出来的结果自我迭代直到性能或者正确性指标满足要求为止。换句话说它从一个“问答机器人”变成了优化流水线里的一个“决策节点”。这个节点可以对优化动作负责而且关键的是它可以解释自己的决策依据。1.2 传统优化流程到底哪里卡脖子要理解这个变化得先知道以前我们是怎么做kernel优化的。常规流程大概是跑一个benchmark拿到profile热点函数然后用GPU性能分析工具去看这个kernel的occupancy、访存带宽、bank conflict、指令吞吐这些指标。很多时候一眼就能看出来是访存瓶颈还是计算瓶颈但问题是当你要深入优化的时候你面对的是一个巨大的搜索空间。以一次典型优化为例同样一个GEMM kernel可能有十几种tiling策略、三五种子块尺寸、两种数据排布方式、若干共享内存padding方案。你怎么知道哪种组合最优很多团队靠经验、靠文档、靠试错。传统auto-tuning也能做但它是一个黑盒搜索代价高、可解释性差而且它不会告诉你“为什么这个方案好”。LLM代理的价值在于它把“从profile数据里读取线索”“回忆历史优化案例”“生成候选代码”“判断瓶颈类型”这些能力整合到了一起。它改变了优化动作的产生方式不再是一步步手查指标而是基于完整上下文的一次性综合诊断。1.3 为什么是2026年下半年才爆发其实LLM代理能读代码、能生成代码这件事并不新鲜但在2026年下半年几个条件终于凑齐了。第一个是上下文窗口和处理能力。优化一个kernel往往需要同时看几千行源码、几百行SASS、一份几MB的profile JSON。过去这些数据根本塞不进上下文现在可以了而且在结构化摘要之后重要信息不会丢。第二个是工具链的打通。GPU原厂分析器的输出格式越来越结构化编译器的中间表示也开始面向工具开放这让LLM代理都能直接解析原始数据不再需要人手工转述。第三个是验证闭环的成熟。LLM代理生成代码之后我们可以让它在沙箱里编译、跑数值校验、跑性能回归然后把结果反馈给它进行下一轮迭代。没有这个闭环代理的建议就永远是“建议”而有了闭环它就变成了一个真正能干活、能担责的优化执行者。我自己体会比较深的一点是在这个时间点劣化优化也就是用LLM代理做“分析到改代码的最后一公里”已经不是一个实验性玩法了它在工程上稳定到可以进CI、支持回滚、做灰度验证。这就是我决定把它当作一等手段的根本原因。2. 全流程重构LLM代理介入kernel优化的四个关键环节2.1 Profile数据预处理与瓶颈判定第一环也是最基础的一环是把原始的profile数据变成LLM代理能直接理解的结构化上下文。这个环节我以前做得非常痛苦。性能分析器导出的报告虽然很全但信息密度极低几千行指标只有几个是关键的。如果直接把原始报告全部塞给LLM代理它很容易被噪音干扰而且token消耗会很夸张。所以我们在前面加了一层预处理脚本从分析器输出里抽取最核心的信号包括kernel执行时间占比warp占用率与理论占用率的比值全局内存/共享内存的访存指令占比主要stalall或wait原因计数指令issue rate说明计算单元还是没有喂饱这些信号组合成一个压缩后的“瓶颈快照”和源码片段、编译选项一起交给LLM代理。代理拿到之后会先输出一个瓶颈分类结论比如“这是一个访存密集型瓶颈主要卡在L2 miss和global load延迟上”或者“这是指令延迟型瓶颈shared memory bank conflict导致stall”。这一步的输出质量直接决定后续优化方向对不对所以我们用了不少心思在快照的生成规则上。实践中我们还会让代理对“快照”给一个置信度。这个置信度不是它自己拍脑袋而是通过一个历史案例库做相似度匹配得到的。如果当前这个kernel的特征和之前某个成功优化的案例高度相似置信度就会高一些。有了这个机制我们敢让代理直接给出优化动作而不是只停留在分析层面。2.2 候选策略生成与kernel改写瓶颈判定完之后重头戏就来了让LLM代理基于诊断结果直接产生候选代码。这个环节和普通代码生成完全不是一回事。普通代码生成是“你给我一个描述我写一个实现”而kernel优化里的改写更像做一个高强度的代码迁移手术。它得读现有的SASS/PTX判断哪些循环该展开哪些内存访问可以合并哪些延迟可以通过异步拷贝掩盖然后把这些改动落到CUDA/Triton级别的源码上。举个例子在某个reduce类kernel里代理发现内核里有一段串行的原子操作导致整个block的吞吐被拖死。它会建议把原子操作替换成先warp内reduce再原子写的方式并且直接生成替换后的代码。这个建议放到以前需要一个人熟读CUDA编程指南、理解硬件执行模型之后才能给出来现在代理在几十秒内就能给出一版初稿。当然初稿不一定能直接通过编译。我们在工作中经常遇到的情况是代理改完的代码在语法上没问题但在某个边界条件上处理错了比如shared memory数组下标越界。这种情况我们不会直接弃用而是会把编译错误信息喂回给代理让它自己修复。多轮修复之后代码质量基本能接近熟练工程师的水平。这个环节里我们最看重的是“可解释的改动”。代理生成每一个改动时都要附带一段理由说明解释这个改动和瓶颈判定之间的因果关系。这段理由后面会成为优化记录的一部分方便我们审计。2.3 编译选项与启动参数联合搜索kernel优化不只是改代码很多时候启动配置比代码本身还重要。一个kernel最终的性能同时取决于block大小、grid大小、shared memory动态分配量、编译选项里的优化级别、ptxas选项。传统的做法是写一个Python脚本把这几个参数作为变量跑一遍网格搜索或者贝叶斯搜索。这个方法的问题是会陷入局部最优而且搜索次数上去了成本很高。LLM代理在这个环节的作用是把“内容特征”和“参数空间”连接起来。它会分析kernel访存模式和计算密度给出一个更聪明的启动配置起点。举例来说如果一个kernel的访存模式是连续广播式的代理会优先考虑使用较小的block配合较大的grid如果计算密度高它可能倾向用更高的寄存器上限来压低spill。然后它不会只给一组参数而是会生成一个参数矩阵交给底层搜索器去做局部验证。这样搜索空间被大幅缩减而且搜索方向有先验知识引导收敛效率高很多。我在实际项目里测过同样一个kernel、同样一个搜索预算用LLM代理给出的起点比随机起点快3-5倍收敛。更重要的是代理会在搜索过程中看中间结果如果某组参数虽然慢但在profile里显示某个指标明显改善它会把那组参数保留下来做进一步调查而不是简单丢掉。2.4 验证与迭代闭环最后一个环节也是让LLM代理真正“长跑”的关键验证与迭代闭环。我们把代理生成的候选kernel放进一个统一的验证流水线里。这个流水线会做四件事编译、数值校验、性能回归、细节指标收集。每一件事的结果都会被格式化成结构化的反馈再送回给代理。代理看到反馈之后会根据情况选择接受当前方案、继续微调某一处代码、或者完全推翻换一个思路。这套闭环机制让代理有了一种“干活”的感觉。它不是在一次性生成终极答案而是在一个可控的循环里逐步逼近目标。我见过代理一轮优化不满意第二轮加大了shared memory的复用粒度第三轮发现导致bank conflict又做了一次padding第四轮终于达到目标。整个过程大概两个多小时换作人工操作至少得一天。关于闭环我特别想强调一个经验反馈信息要分层。不要只把“性能提升了23%”这种笼统结果给代理要把具体指标也放进去比如“L2吞吐从XX提升到XX”“bank conflict计数从XX降到XX”“寄存器spill从XX降低到0”。代理只有看到这些细节才能在下一次改写时做出有针对性的决策而不是继续瞎试。3. 真实案例复盘一个GQA kernel的完整优化过程3.1 案例背景与基线数据我拿一个实际做过的案例来复盘这样看得更直观。项目背景是一个AI推理框架里面某一段GQAGrouped Query Attention算子在特定序列长度和batch配置下占据了端到端推理时间的19%左右。这个占比对注意力类算子来说偏高了我们团队决定对它做一轮深度优化。先看基线profile数据。我们跑了一组测试记录下来的关键指标如下表所示指标项基线数值单次kernel平均耗时472usSMEff流式多处理器实际利用率指标31%全局load执行占比24.5%L2 hit rate62.1%SM busy wait占比18.7%寄存器spill量112 bytes/thread从这组数据里基本能判断几个问题首先SM busy wait占比很高说明warp在等数据而不是在跑指令其次L2 hit rate不到65%说明访存局部性很差再加上全局load占比接近四分之一这是一个典型的访存等待型瓶颈。如果是过去的流程我会基于这些指标手工去翻源码找访存方式然后试几种方案。这一次我们把原始报告和源码直接交给了LLM代理。3.2 第一轮优化从访存路径和指令排布动手代理拿到数据之后第一轮给出来的诊断是这个kernel的主要延迟来源是KV cache读取阶段。它发现当时的实现里每个query会依次读取对应的多个KV头这个读取过程没有做向量化导致产生大量细粒度的非对齐loadL2请求次数被放大。代理给出的修改建议是把KV读取的指针访问改成float4对齐路径同时把读取KV数据的过程从query循环里拆出来用异步拷贝指令把数据预取到shared memory让计算和访存部分重叠。它还顺手帮我们调整了block内线程布局让相邻线程读取连续地址从而提升L2命中和DRAM burst效率。针对这一轮改动我们做了复测单次耗时从472us降到了331usSMEff提升到了38%L2 hit rate也提高到了71.4%。数字看起来不错但还没有达到我们预期的性能目标所以继续把它交给代理迭代。3.3 第二轮优化根据occupancy和shared memory容量调整第二轮代理没有直接改核心计算逻辑而是让我们跑了一组occupancy实验观察不同shared memory分配量下的实际占用率。跑完发现当前kernel为了预取KV数据把shared memory塞得很满导致一个SM上同时驻留的block数量少了一半warp级并行度不够数据等待的时间盖过了异步拷贝带来的收益。代理根据这个现象给出一个新方案不再为每个KV头分一块独立空间而是把KV头按组共享同一块预取缓冲区用索引标记区分不同组的位置。这样shared memory总量约下降了40%occupancy从50%提升到了75%以上。这个改动对代码结构的影响不小我们花了一些时间重构测试之后单次耗时降到了282us。这个成绩已经达到了项目预期我们决定就此收手不再做激进优化。优化完成后的最终数据如下表指标项基线数值优化后数值单次kernel平均耗时472us282usSMEff31%47%L2 hit rate62.1%79.3%SM busy wait占比18.7%9.2%寄存器spill量112 bytes/thread16 bytes/thread这个案例让我对LLM代理的实操价值有了更具体的认知。它两轮迭代分别解决了两个完全不同层次的问题第一轮是访存路径不合理第二轮是资源调配失衡。这两类问题在传统流程里可能需要两个工程师分别排查而且不一定能这么快给到可靠的修改方向。3.4 案例里我学到的取舍经验复盘这个案例有一个点是很值得说的代理第二轮建议重构shared memory分配策略时它在输出里特别标注了“这个改动会引入索引计算开销建议结合实测决定是否采用”。这个话术让我挺意外因为它体现出了一种妥协意识它知道自己推荐的方案不是免费的需要权衡。我后来在别的项目里也遇到过类似情况代理给出的最优方案A因为对代码侵入太大被我们拒绝了它随即生成了一个折中方案B性能只比A差一点但改动量小很多。这种“在约束条件下重新规划”的能力对工程落地来说特别重要。同时也得说一句公道话这个案例能顺利完成前提是我们有比较严格的验证机制。代理每一轮给的代码我们都跑了数值对比测试和单测确认逻辑没有偏掉。LLM代理生成代码的想象力是够的但约束性和边界条件依然是它的短板需要人来兜底。4. 正确性验证与性能回归让代理输出“可信”的工程保障4.1 正确性验证的三级围栏LLM代理再强它在本质上还是一个概率模型它可能给出结构漂亮但数值错误的代码。所以在所有流程里我最重视的是正确性验证。我们的做法是设置三级围栏。第一级是静态检查。在编译阶段用编译器和代码扫描工具检查明显的数组越界、未初始化变量、类型不匹配问题。这一级能拦住大部分低级错误。第二级是数值校验。我们会对代理生成的kernel跑一组随机输入和参考实现逐元素对比。对比时用相对误差和绝对误差双重判定。比如fp16的kernel我们一般设rtol1e-2、atol1e-2fp32设rtol1e-4。超过设定阈值就直接判失败不会进入性能测试。第三级是场景回归。某些算子在小输入下正确不代表在真实业务shape下也正确。所以我们会准备一组真实业务形状的测试样例跑端到端对比确保输出在可接受范围内。这套三级围栏跑一轮大概只需要几分钟成本可控但能极大减少代理代码引入线上问题的概率。4.2 性能回归看门狗正确性不是唯一的坑性能回退同样要重视。我们在CI里挂了一个“性能看门狗”每次代理提交新kernel版本都必须和当前最优版本跑同一组benchmark如果性能下降超过3%这个版本会自动标记为失败并附上详细对比数据。这个设计很关键因为代理在优化过程中可能会在某一步“改回去”导致性能倒挂又或者它在局部优化某项指标但整体性能变差了。比如有过一次代理把某个访存密集kernel的global load全部改成了 더宽的向量类型L2吞吐提升了不少但因为指令issue宽度也被占满计算效率反而下降了整体耗时涨了5%。如果没有性能看门狗我们很可能被L2吞吐这个“局部指标改善”误导。看门狗的逻辑我还想细化一下它不只看固定基准还会算一个“收益评估”。具体算法是对于每个优化版本记录它在不同shape下的耗时、带宽利用率和占用率然后和一个线性插值得到的期望曲线对比。如果某个shape下性能大幅偏离期望看门狗就会报警。这让我们能发现一些只有特定shape下才会暴露的问题。4.3 有效带宽与计算效率的计算逻辑验证性能时除了跑一下看耗时的秒表还要算两个硬指标有效内存带宽和FLOPs利用率。这两个指标能告诉我们一个kernel到底在硬件能力方面发挥了几成。有效内存带宽的计算公式很简单带宽 访存总量 / 实际耗时。比如一个kernel要读写的总数据量是8GB实际耗时0.002秒那有效带宽就是4000GB/s左右。把这个数值和硬件的理论峰值带宽做对比就能快速判断是不是访存瓶颈。FLOPs利用率也类似计算效率 实际计算量 /耗时 × 硬件峰值算力。举例来说一个kernel的访存量是2GB计算量是100TFLOPS实际耗时0.0004秒而硬件理论峰值是200TFLOPS那么它的计算效率就是100 /0.0004×200约等于125%说明有超额占用大概率是和其他kernel在争抢资源。这些指标看似基础但我发现很多团队在引入LLM代理之后反而容易忽略它们原因是代理给出的报告里已经写了结论大家懒得去验算。这绝对要不得。代理的结论只能作为参考硬指标才是唯一可信的事实依据。4.4 人类与代理的分工边界工程保障做足之后才到了人和代理怎么分工的问题。我的经验是不要全自动也不要完全人工走“半自动”路线。代理负责出分析和代码人负责审方案、卡准入、做最终决定。具体流程是代理生成一批候选版本每个版本附带详细说明工程师快速浏览说明挑出一个最合理的版本进入验证流水线验证通过后由工程师签字合并到主干。这里有一个容易被忽视的好处代理给出的“附带说明”可以作为改动的审计日志。以前我们做kernel优化经常出现“某天某个版本性能突变但没人记得改了什么”的情况。现在代理每改一处都会生成一个简洁的第一性原理说明长期积累下来这是非常宝贵的技术文档。我自己在项目中宁可让代理多花两分钟写清楚改动理由也不接受它像一个黑盒一样直接把代码丢出来。因为黑盒的代码没法评审、没法维护后面出了性能问题都无从查起。如果代理不解释我就会把它当普通auto-tuning工具用那就失去了“一等优化手段”的意义。5. 工程化集成套件、流程与踩坑后的最佳实践5.1 一套可复用的工具链分层LLM代理作为一等优化手段不是靠单个模型能力就能撑起来的它需要一整套工程设施。我们内部总结了一个工具链的分层设计大概分四层。数据层负责收集和格式化基础数据包括性能分析器的输出、SASS/PTX反汇编、源码、编译日志。这一层的核心工作是“把原始数据转化成结构化且易于检索的格式”。上下文组装层负责从数据层中抽取和当前优化目标最相关的信息组装成prompt。这个层是纯工程活但非常重要。组装得好不好直接决定代理分析质量。代理执行层负责调用LLM、处理工具调用、管理多轮对话状态。这个层会记住前面分析过什么、改过什么不需要每次从头讨论。验证层负责编译、测试、性能对比并把结果反馈回代理执行层。这个层充当了代理的“眼睛和手”让它能做闭环推理。这套分层设计最大的好处是各层可以独立替换。比如性能分析器换了一款只需要改数据层的解析逻辑不影响其他层。LLM模型要升级也只需要动代理执行层。5.2 离线优先与案例检索库说一个对落地影响巨大的经验离线优先与案例检索库。我们最初直接把每次优化任务都发到在线大模型API上去处理结果有几个问题一是token开销不低二是部分代码数据不适合频繁外传三是模型经常没有往年案例记忆每次遇到类似问题都要从零开始。后来我们改成了“离线优先”策略。本地维护一个轻量级代理环境历史优化案例、profile快照、成功方案全部沉淀到本地向量库和结构化案例库里。新任务进来时先做相似案例检索把最相关的3-5个历史案例作为参照上下文再让代理分析。这个改动带来的提升非常明显。以前代理第一次就给准方向的概率大概是40%到50%加入案例检索之后一次定位准的概率能到70%以上。尤其是同一个算子系列的优化比如对GEMM、attention、layernorm这一类常见算子历史案例的复用价值极高。我个人的观点是到了2026年下半年优化一个kernel的能力瓶颈已经不在于模型服务本身强不强而在于你的案例积累和检索工具有没有沉淀好。5.3 人工介入时机的判断还有一个经验是关于“什么时候该人工接管”。我们给代理设了一些触发条件代理连续三轮没有产出有效迭代方案或者连续两次在同一个问题上犯了同类型错误或者验证流水线连续三次失败时系统会自动向工程师发出求助信号。这个时候工程师必须介入而不是继续让代理自行尝试。为什么这么设计因为LLM代理在明确了错误信号的场景下是能自我修正的但在“方向错了但还没暴露”的情况下它会沿着错误方向重复试探浪费时间和计算资源。人工介入的临界点要设在“方向可疑”的时候而不是“彻底失败”的时候。举例来说有一次代理连续两轮都在调整block size但每次调整之后性能都在原地打转。工程师介入后发现它的优化方向完全被profile里的某个次要瓶颈带偏了真正的瓶颈是shared memory的bank conflict。这个信息一输入代理立刻切到了正确路径。如果没有人打断它可能还要多浪费几轮。5.4 从“能用”到“好用”的工程细节最后补充几个从“能用”到“好用”的工程细节。第一善用结构化输出。我们要求代理按统一JSON格式返回分析结论、改动说明和风险点而不是自由格式文本。这样后续验证层可以直接解析还能生成结构化报告。第二缓存历史验证结果。同一个kernel的同类优化任务如果验证结果已经存在就不用重复跑测试直接查缓存就能知道上次结果。这个机制在代理多轮迭代时特别高效。第三持久化中间产物。代理在优化过程里可能会生成一些被否掉的候选版本我们不会删掉而是保留下来作为负面案例。这些案例在后续训练检索模型、或者做自动评测时都很有价值。这些细节看起来不起眼但真正跑过几个项目之后你就会发现LLM代理能不能稳定发挥作用往往取决于这些工程地基而不是单一的大模型能力。6. 常见问题与排查实录6.1 代理给出的代码频繁编译失败怎么办这个问题几乎是100%会遇到的。代理生成的代码往往思路没问题但细节总有疏漏。我们的处理办法是把编译错误日志原样喂回给代理让它自己修改。这里有个关键点日志要完整包括具体的行号和错误消息不能只给个“编译失败”这种抽象信息。另外我们设置了编译错误次数上限。同一个任务里代理编译失败超过三次我们会强制它停下来反思让它重新读一遍自己之前生成的代码、对比正确的参考实现然后再提交。实测下来这个“反思”机制能明显降低连续编译失败的概率。6.2 代理生成的kernel数值误差超限怎么办数值误差超限的问题常见于浮点运算顺序被代理改变、或者归约逻辑重写后引入精度损失。我们的排查顺序是先缩小范围用相同输入分别跑代理代码和参考代码定位第一个误差超过容忍度的输出位置。然后把那一小段代码单独拿出来交给代理看让它分析误差来源。多数情况是因为它为了优化性能把求和顺序换成了树形归约或者增加了并行累加次数导致舍入误差变大。如果代理给的修复方案涉及牺牲一点性能换取精度我们一般会接受因为对于大多数推理场景稳定性和精度比那百分之一的性能提升重要得多。6.3 上下文太长关键信息丢失怎么办LLM代理处理大kernel时会遇到一个问题源码好几千行、汇编上万行全塞进上下文里不仅成本高而且关键信号被淹没。我们的解决思路是“先摘要再展开”。先让一个轻量脚本生成kernel的结构摘要包括主要循环、访存指令类型、共享内存使用情况、关键函数调用关系。代理基于摘要判断最可能的瓶颈区域然后只针对那个区域去读完整源码。这个机制几乎可以解决全部上下文长度问题。需要注意的是摘要的质量直接决定后续分析准确性所以我们对摘要脚本的要求是必须保留与性能相关的信息比如循环内是否有乘加链、是否有bank冲突风险这些要比代码的注释重要得多。6.4 代理自信地给出错误结论时怎么办LLM代理有时会以非常肯定的语气给出错误结论这是它作为概率模型的天性。我的经验是不要试图靠“话术”让它变得谦虚而是靠机制对冲风险。一个有效方法是引入“双模型对抗”。主代理负责出方案一个独立的评审模型负责挑毛病。评审模型不直接生成优化方案只负责检查现有方案的逻辑漏洞和风险点。如果评审模型提出了质疑主代理必须针对质疑做出回应并决定是否修改。这个“提议-反驳-修正”的结构实操下来效果不错可以把明显有逻辑漏洞的方案挡在验证流水线之前。6.5 关于“代理的一等化”最后想说的话做到这里回头看整个变化我最大的感触是LLM代理成为一等优化手段靠的不只是模型变聪明了而是我们把整个优化流程重新设计了一遍。让代理能在正确的时间、接触正确的数据、产生正确的动作、收到正确的反馈。我踩过不少坑也走过弯路但最终沉淀下来一套可复用的工作流。如果你也在尝试把LLM代理引入到自己的GPU/AI算子优化流程里我建议先别急着追求全自动而是从“代理生成建议 人工决策 自动验证”这种半自动模式开始。跑通闭环之后再逐步把更多决策权交给代理。更重要的是把每一轮优化的案例都沉淀下来形成自己的案例库。大模型本身没有记忆力案例库才是你和代理共同积累的长期记忆。有了这个记忆LLM代理才能真正从一个偶尔灵光的咨询顾问变成一个越来越靠谱的“一等优化手段”。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
