1. 从手写汇编到代理驱动算子优化范式正在发生什么变化2026年过半如果你还在用纯手工的方式去调一个LLM推理场景下的算子kernel大概率会在效率上吃大亏。这不是危言耸听而是我这半年在几个实际项目里反复验证过的结论。过去我们优化一个attention kernel或者一个fused MLP流程基本是固定的看profile、定位瓶颈、手写CUDA或Triton、反复调tile size和num_warps、跑benchmark、回归测试。这套流程本身没问题但它的天花板越来越明显——人力有限搜索空间巨大而模型结构迭代的速度远超个人调优的速度。标题里说的LLM代理成为一等优化手段核心意思就是把大语言模型驱动的智能代理从辅助写代码的玩具提升为优化流水线里的正式成员。它不再只是帮你补全几行Triton代码而是能自主提出优化假设、生成候选kernel、跑测试、分析结果、再迭代。这个转变的意义在于优化从人的经验驱动变成了人的经验加代理的搜索驱动。这篇文章适合谁看如果你是在做推理加速、算子库开发、或者模型部署的工程师尤其是经常和Triton、CUDA、TileLang这类东西打交道的人那这篇内容应该能给你一些可以直接抄作业的思路。如果你只是听说过kernel优化但没动过手也没关系我会把关键概念用生活化的方式讲清楚。整篇内容围绕一个核心问题展开在2026下半年怎么把LLM代理真正用进算子优化的工作流里而不是停留在demo阶段。先说一个我自己的观察。年初的时候我试过让代理直接生成一个fused softmax kernel结果生成的代码在数值上就有问题边界条件处理得一塌糊涂。但到了年中同样的任务代理生成的kernel不仅数值正确性能还超过了我手写的版本大约12%。这个变化不是模型变聪明了这么简单而是整个工作流的设计变了——代理有了测试反馈闭环有了性能剖析数据作为输入有了多轮迭代的机制。这才是一等优化手段的真正含义。2. 为什么代理优化在LLM算子场景下特别有效2.1 算子优化的搜索空间到底有多大要理解代理为什么有用先得理解算子优化的搜索空间有多恐怖。以一个典型的decoder层里的attention算子为例你需要决定的参数包括但不限于block sizeM、N、K三个维度、num_warps、num_stages、是否用shared memory、用什么精度的累加器、softmax的online算法怎么分块、是否融合RoPE、是否融合KV cache的读写。这些参数组合起来轻松就是上万种配置。传统做法是靠经验缩小范围比如block M一般取64或128但这就意味着你主动放弃了很多可能更优的区域。代理的价值在于它可以在你给定的搜索空间里做更聪明的探索。它不是暴力枚举而是基于对代码语义的理解和对性能反馈的分析提出下一步该试什么。我实测下来一个设计良好的代理在200次迭代内找到的配置往往比人工调优一整天找到的还要好。原因很简单人会有思维定势代理没有。2.2 代理相比传统auto-tuning工具的区别你可能会问那用传统的auto-tuning工具不就行了吗比如各种基于遗传算法或贝叶斯优化的调参器。这里有个关键区别传统auto-tuner只能调你预先定义好的参数它不能改变代码结构。而代理可以改代码本身。举个例子传统tuner只能在用不用shared memory这个维度上选但代理可以提出把两次global memory访问合并成一次这种结构性的改动。这是本质区别。另一个区别是代理能理解语义。你告诉它这个kernel在sequence length比较小的时候性能差它能推理出可能是因为并行度不够然后尝试调整grid的划分方式。传统tuner没有这种推理能力它只能看到数字。2.3 哪些算子最适合代理介入不是所有算子都值得上代理。根据我这半年的经验以下几类收益最明显融合算子比如attention加RoPE加KV cache写入的融合结构复杂人工调优耗时极长。形状多变的算子推理场景下batch size和sequence length变化频繁需要针对不同形状快速找到较优配置。新硬件适配每次换新卡之前的调优经验部分失效代理可以加速重新探索的过程。反过来那些结构极其简单、参数空间很小的算子比如单纯的element-wise add上代理就是杀鸡用牛刀没必要。3. 搭建代理优化闭环的四个核心组件3.1 组件一可执行的kernel生成环境代理要优化kernel首先得能生成并执行kernel。这里我推荐用Triton作为主要目标语言原因是它的抽象层级适中——比CUDA好生成比高层IR好控制。你需要准备一个沙箱环境代理生成的代码在里面编译、运行、测性能不会影响主工程。环境里必须包含的东西目标GPU、对应版本的Triton和CUDA驱动、一个标准的benchmark harness、以及数值正确性校验的参考实现。参考实现可以用PyTorch写虽然慢但保证正确。注意沙箱里的超时设置很关键。代理生成的代码有可能死循环或者编译极慢我一般设置单次编译加运行不超过60秒超时直接判失败让代理重新生成。3.2 组件二结构化的性能反馈代理要迭代就得知道上一轮哪里不好。光给一个耗时多少毫秒是不够的最好能给出分层的反馈编译是否成功、数值是否正确、如果正确那么耗时是多少、和baseline比是快是慢、瓶颈可能在哪比如通过简单的occupancy计算或者memory throughput估算。我通常会把反馈整理成一段结构化的文本喂给代理而不是让它自己去读日志。比如编译成功。数值校验通过最大相对误差1e-5。耗时0.42msbaseline为0.55ms。根据寄存器使用量推测occupancy约为50%可能存在提升空间。这种反馈比原始日志有用得多。3.3 组件三迭代策略与停止条件代理不能无限迭代你得定义什么时候停。我的做法是设置三个停止条件满足任一即停连续N轮没有性能提升、达到最大迭代次数、或者性能已经超过预设目标。N一般取5到8太小容易早停太大浪费算力。迭代策略上我倾向于让代理每轮只做一个主要改动而不是一次改一堆。这样反馈信号清晰代理能学到哪个改动带来了什么效果。如果一轮改五个地方性能变了你也不知道是哪个起的作用。3.4 组件四经验沉淀机制这是最容易被忽略但长期价值最高的部分。每一轮迭代的改动-反馈对都应该被记录下来。积累多了之后你可以把这些经验作为few-shot示例喂给代理让它在面对新算子时少走弯路。我现在的做法是维护一个结构化的经验库按算子类型和硬件类型分类每次新任务先检索相似经验注入prompt。4. 一个完整的代理优化实战流程拆解4.1 任务定义与baseline建立假设我们要优化一个decoder层的fused attention算子输入是query、key、value要求融合RoPE和causal mask输出attention结果并写入KV cache。第一步是写一个正确的PyTorch参考实现并测出它的耗时作为baseline。注意baseline要测多次取中位数避免噪声干扰。然后写一个初始的Triton kernel不需要很快但必须正确。这个初始版本作为代理迭代的起点。我一般会写一个能跑但很朴素的版本比如所有计算都在寄存器里做不做shared memory优化。4.2 给代理的初始prompt设计prompt里要包含任务描述、初始kernel代码、参考实现、性能反馈格式说明、以及优化目标。我通常还会加一段约束条件比如不要改变函数签名、必须保持数值误差在1e-4以内、只能使用Triton支持的操作。这里有个经验prompt里明确告诉代理你可以尝试哪些方向的优化比让它完全自由发挥效果更好。比如我会列出可以考虑shared memory、可以考虑调整block size、可以考虑改变softmax的分块方式但不强制它必须用哪个。4.3 迭代过程中的典型发现在实际跑的过程中代理提出过一些我自己没想到的优化。举几个例子它把RoPE的sin/cos计算提前到了kernel外部预计算减少了kernel内的计算量。这个改动我一开始觉得没必要因为预计算会增加内存访问但实测下来因为sin/cos计算被重复了很多次预计算反而更快。它调整了causal mask的处理方式从每个block都判断改成根据block位置决定是否跳过减少了分支判断。它发现当sequence length是64的倍数时可以用更激进的向量化加载于是加了一个特化分支。这些改动单独看都不复杂但组合起来带来了约35%的性能提升。4.4 结果验证与回归代理优化完之后必须做严格的回归测试。除了数值正确性还要测不同形状下的性能确保没有在某些形状下出现性能倒退。我一般会准备一组覆盖常见形状的测试用例包括batch size从1到32、sequence length从128到4096的各种组合。提示代理优化出来的kernel有可能在特定形状下性能极好但在其他形状下很差。一定要做形状扫描不要只看一个形状的结果。5. 代理优化中那些容易踩的坑5.1 数值正确性的隐蔽问题代理生成的代码有时候数值上看起来对但在边界条件下会出问题。我遇到过一次代理生成的kernel在sequence length小于block size时mask处理有误导致结果偏大。这种问题在常规测试形状下发现不了必须专门测小形状。解决办法是强制要求代理在生成代码时处理所有边界条件并且在测试集里加入极端形状。另外数值校验不能只看最大误差还要看误差的分布有时候最大误差不大但整体偏移明显。5.2 代理的过度自信问题代理有时候会声称自己优化了某个地方但实际上改动没有生效或者改动引入了新的瓶颈。我遇到过代理说通过减少shared memory使用提升了occupancy但实际上它只是删了一行注释。所以每一轮改动都要有实际的性能数据支撑不能只听代理的描述。我的做法是每轮迭代后自动对比新旧kernel的代码差异并且强制跑性能测试。如果性能没有变化就标记这轮为无效迭代在下一轮prompt里提醒代理。5.3 搜索陷入局部最优代理和人类一样容易陷入局部最优。比如它发现某个block size组合效果不错就一直在那附近微调不再尝试完全不同的结构。解决办法是定期注入探索性指令比如请尝试一个和当前结构完全不同的方案或者随机重置一部分参数。我一般每10轮迭代插入一次探索轮强制代理尝试一个较大的改动。虽然大部分探索轮不会带来提升但偶尔会有惊喜。5.4 算力成本与时间成本代理迭代是要烧GPU时间的。一个完整的优化流程跑几百轮迭代消耗的GPU小时数不少。所以要有成本意识不是所有算子都值得上代理也不是迭代越多越好。我的经验是对于中等复杂度的算子50到100轮迭代通常能拿到大部分收益再往后边际收益递减明显。6. 不同硬件与框架下的适配经验6.1 消费级卡与数据中心卡的区别消费级卡和数据中心卡在代理优化时的策略不一样。消费级卡显存带宽相对紧张代理更容易通过减少内存访问获得提升数据中心卡计算能力强代理需要更关注计算密集部分的优化。另外消费级卡的occupancy对性能影响更大代理在调block size时要更保守。6.2 Triton版本差异带来的影响Triton的版本迭代很快不同版本对某些操作的编译结果差异明显。我遇到过同一个kernel在某个版本上性能很好升级后反而变慢的情况。所以代理优化时要固定Triton版本并且在经验库里记录版本信息。换版本后之前的经验可能需要重新验证。6.3 与推理框架的集成优化好的kernel最终要集成到推理框架里。这里要注意的是框架可能有自己的内存管理策略和调度逻辑kernel的性能在框架里可能和在独立benchmark里不一样。我一般会在框架里也跑一遍性能测试确保优化效果能真正落地。7. 我对代理优化未来半年的判断从这半年的实践来看代理优化已经从能跑通进入到了能稳定产出收益的阶段。但它还不是全自动的人的角色从写kernel的人变成了设计优化流程的人。你需要定义搜索空间、设计反馈机制、处理边界情况、判断结果是否可信。这些工作目前还离不开人的经验。我觉得接下来半年最值得关注的方向是经验库的跨任务迁移。现在每个新算子基本还是从头开始优化如果能把之前积累的经验更有效地复用整体效率还能再上一个台阶。另外代理和传统auto-tuner的结合也值得尝试——让代理决定搜索空间的结构让传统tuner在给定空间里做精细搜索。如果你现在还没把代理引入到kernel优化流程里我的建议是从一个中等复杂度的算子开始试不要一上来就搞最难的。先把闭环跑通积累一些成功和失败的经验再逐步扩大应用范围。这个过程本身也是对你优化流程的一次梳理收获可能比单纯提升某个kernel的性能更大。