1. 从人翻手册到代理提方案kernel优化的玩法变了1.1 以前的优化流程是什么样的在把LLM代理接入优化闭环之前一个典型的GPU算子性能优化流程大概是这样的先用profiler拿到kernel的运行时间和各阶段硬件利用率看热点集中在哪一条循环上然后根据经验判断是访存受限还是计算受限接着动手调整线程块大小、循环展开、shared memory用量、向量加载宽度这些参数。每次改动之后都要重新编译、重新跑benchmark遇到不明原因的倒退还得把历史版本逐个拉出来对比才能定位是哪一行改动出了问题。这个过程非常依赖个人经验。很多人觉得kernel优化是一门玄学其实不是玄学而是搜索空间实在太大。一个GEMM类算子动辄有block尺寸、每线程计算粒度、寄存器上限、数据预取深度、向量宽度五六个维度的参数组合全排列下来就是上万种情况。手工根本试不完大家只能靠经验猜一个方向。有的方向收益明显有的方向在小shape上有效、换一个shape立刻倒退这种局部最优很容易把人带偏。LLM代理进入这个流程以后变化的关键不是自动改代码——改代码这件事早就有工具能完成关键的变化在于它会结合profiler输出和kernel结构主动生成瓶颈假设-修改方案-验证方法的完整链条。很多时候它给出的假设和团队里资深工程师的想法并不相同但它能靠快速试错把假设验证掉。这等于把过去靠资历积累的猜方向能力变成了一种可以并行执行、可以回滚的工程流程。1.2 一等优化手段到底是什么意思我理解一等优化手段不是说让LLM代理在边上当个辅助写代码的小助手而是把它当成和人工优化同等地位的方案来源。我们内部这个实验工程最开始也只是让代理帮忙写小工具、生成注释真正起变化是从它接入优化闭环那一刻开始的。接入之后状态变化可以从三个地方看出来代理拥有提案权。它会主动根据profiler数据提出kernel改动不再等人去问它。代理拥有验证权。它能自动执行benchmark脚本判断改动是否有效而不是把验证工作全丢给工程师。代理的提案和人工提案走同一套验证回归网。没有谁天然更可信收益和风险都被量化成一组数据谁的有效就采纳谁。这三个权里面第二和第三最重要。很多团队把模型当代码生成器生成完扔给工程师去测效果往往一般一旦让代理自己闭环验证它的定位就从代码助手变成了优化参与者。这也是标题里一等优化手段的含义——它不再躲在自然语言问答的界面后面而是直接参与算子的性能决策。注意我开放自动验证权限是在加了一堆限制之后才做的。第一步只允许它生成benchmark脚本并读取输出不直接允许它写回kernel仓库等误操作率降下来再逐步放开修改权限。安全边界永远先于效率。1.3 代理不是一个黑盒而是一条mini流水线我一直觉得LLM代理的难点不在模型本身而在于给它接上多少工具。我们的代理实际连接着profiler输出解析器、编译构建工具、benchmark运行器、git回滚脚本还有一份优化禁区清单。每个优化会话就是一个固定循环读取性能数据生成瓶颈摘要对照kernel源码和摘要提出两到三条候选优化路径对每个候选路径生成kernel补丁或参数配置编译运行收集耗时、寄存器用量、内存访问量等指标汇总结果决定采纳、调整参数还是直接回滚。这个流程跑通以后代理的价值就立刻体现出来了。过去人工完成一轮提出假设-写补丁-跑验证可能要半天到一天代理在计算资源充足的情况下小时级就能完成。但它也有非常明显的弱点上下文窗口有限时间长了会忘记早期结论生成补丁时会一本正经地给出看起来专业、实际上编译不过的代码。所以我的判断是代理负责效率人负责把最后一道关。2. 优化链路的重新分工代理快在哪、慢在哪2.1 分析结果先到代理手里而不是直接到工程师手里以我这几个月的观察效率提升最多的环节其实不是写kernel而是读profiler报告。一份报告动辄几十行指标人工读不是读不懂而是整理和判断需要时间。代理很快能把报告归纳成该算子的访存瓶颈在第二阶段shared memory等待占比过高这种直接结论并且能把十几个shape的报告一次性过完。过去我们一般只挑两三个主要shape看报告现在可以让代理把十几个shape的报告全部读一遍它会发现某些优化在主shape上无效、但在长尾shape上有效。这种覆盖广度的提升对最终性能收敛质量帮助很大。长尾场景的优化往往不是靠灵光一现而是靠把每个shape的瓶颈都摊开来看代理恰好擅长干这种批量归纳的活。2.2 代理和autotuner是互补关系有人说有了LLM代理就不需要autotuner了这是误解。autotuner解决的是给定一个改动方向后参数空间怎么枚举的问题LLM代理解决的是下一步该往哪个方向改的问题。实际使用中经常是代理先给方向然后autotuner在代理圈定的小范围里细跑。比如代理判断应该把block的M维度加大那autotuner就在BM等于96、128、160这几个值里搜最优而不是全空间乱扫。反过来如果autotuner在某个方向上搜索了很久都没有收益代理可以通过重新阅读kernel结构提出一个全新方向。这比在旧方向上继续枚举有效得多。所以这两个工具完全不冲突一个是战略层一个是战术层。2.3 上下文管理和记忆问题代理优化最头痛的问题是会话拉长以后它开始健忘。连续优化一个算子十几个版本后早期已经验证过的方案会被它重新提出来好像从来没试过一样。后来我们的办法是每轮优化结束时生成一份已试方案摘要里面包含改动内容、实验指标、结论采纳、回滚还是条件采纳然后把它作为下一轮会话的前缀。这等于给代理加了一个外部记忆。这个摘要文件本身不需要太长几百字就够但能显著减少重复劳动。我甚至觉得这项工程比单纯调模型参数更值得投入时间。模型参数怎么调是能力上限问题而外部记忆解决的是稳定发挥问题。在优化这种长周期任务里稳定发挥往往比偶尔超常更重要。3. 案例一GEMM算子的blocking搜索与向量化改造3.1 现场看到的瓶颈第一个让我觉得代理可用性超预期的算子是一个中等规模的GEMM类算子。初始版本跑在目标平台上的耗时处于中间水平profiler显示global memory load效率偏低L2命中率低于预期而计算单元利用率还不错。这类问题通常指向两个方向内层循环的数据复用不够或者加载宽度不够导致访存指令数量过多。放在以前我会先怀疑每个线程负责的M/N块尺寸是不是太小然后手动把向量宽度从2改成4顺便试试double buffer。这个路径本身没问题但需要好几轮实验才能确认。代理在拿到同样profiler摘要之后给的初始方向和我的判断差不多但它把block尺寸、寄存器上限和double buffer绑定在了一起让三组参数在同一轮里同时变化。这就不是人类习惯的调法人类倾向于一次只动一个变量代理更喜欢组合式探索。3.2 代理给出的第一版改动代理给出的第一版改动如下# GEMM blocking 候选配置第一版 candidate { BM: 128, # block 在 M 维的大小 BN: 64, # block 在 N 维的大小 BK: 32, # block 在 K 维的切片大小 TM: 8, # 每个线程负责的 M 向元素数 TN: 4, # 每个线程负责的 N 向元素数 vec_width: 4, # 向量加载宽度 double_buffer: True, }这些改动单独拆开看都算常见难得的是它一次性组合到了一个补丁里。编译跑下来主shape耗时下降了大约18%。当时组里一位同事不太相信把改动拆开逐个验证发现大部分收益来自向量宽度和BM提升的叠加double buffer只贡献了几个百分点而且在小shape下会由于寄存器压力增加产生倒退。3.3 回滚的那部分也有价值既然小shape下会倒退最终我们只回滚了double buffer其余保留。这个回滚一部分的决策在以前的人工流程里往往需要多花一到两天。因为人工分离变量要反复改代码、重新编译。代理的好处是它可以在一次会话里生成多个变体自动对比各变体在大shape和小shape上的表现直接定位到是哪个参数导致倒退。这比人肉分离变量快很多。这个案例给我的启发是代理生成的方案不要整体接受也不要整体拒绝。最好的做法是把一个补丁看成若干独立改动的集合让它逐项汇报预期收益和回归风险再做取舍。我们后来在提示词里明确要求每一个改动点单独给出预期收益与回归风险输出质量立刻又上了一个台阶。4. 案例二Attention算子的shared memory复用与bank conflict修复4.1 定位到shared memory访问冲突第二个值得记录的算子是Attention类算子。它的特征是包含大量分块计算和softmax拼接shared memory使用非常密集。最初版本的瓶颈不在global memory带宽而在shared memory访问冲突。简单来说当多个线程在同一拍访问shared memory里相同编号的分组时硬件只能串行服务这就等于把一次并行访问拖成了多次串行访问等待时间会被明显拉高。人工排查这类问题通常要对索引公式算半天看不同线程的地址在取模之后会不会撞到同一个位置。代理处理这类问题很擅长因为它能先读源码里的访存索引表达式再根据分组数量做取模推导。它很快列出了两处可疑的访问模式都发生在加载score矩阵分块的循环里。4.2 填充与索引重映射代理给出的方案也很经典在shared memory数组的每一行尾部填充若干元素让行的起始地址偏离原来的对齐位置同时对部分索引映射做线性变化使同一轮访问尽量落到不同的分组上。原理可以这样理解原本每行的起点都在同一个对齐位置连续访问就像所有人都涌向同一个门口填充几个元素后队伍被错开了每扇门都能同时进人。// 伪代码shared memory 行尾填充一个元素错开 bank 对齐 float s_score[BLOCK_M][BLOCK_N PAD]; // PAD 由 autotuner 在 0 / 1 / 2 之间选择这类改动的难点在于填充长度和索引映射必须和block尺寸严格匹配填错了性能可能比原来更差。代理的做法是把方案参数化然后让autotuner在小范围内扫填充偏移。最终选择的方案让耗时降低了约11%并且没有改变语义。值得一提的是它还顺带发现实现里有一处额外的数组拷贝在旧平台上这可能不明显但在新平台上占了将近3%的开销。这个发现比较意外因为人工看代码时注意力全在冲突问题上没人去管那个从诞生起就存在的冗余拷贝。4.3 精度与稳定性核验Attention算子对数值精度比较敏感代理的改动如果改变了累加顺序或者计算路径端到端输出就可能出现偏差。我们对这个算子做了比较严格的数值核验不只看最大绝对误差还看不同输入分布下的误差分布以及连续跑多个批次后的漂移情况。结论是改动前后累计误差在可接受范围内。这个环节也暴露了代理的一个明显局限它生成的benchmark代码经常使用固定随机种子导致回归结果过于理想。后来我们在验证脚本里强制要求多种随机种子和多种输入shape才避免看起来通过、一换数据就翻车的情况。这一点后面在避坑清单里还会详细说。5. 案例三Reduction算子的线程映射重写5.1 reduction为什么调起来麻烦Reduction算子看着简单就是把一组数据累加成更少数量的数据但它在GPU上非常容易做傻。常见错误包括线程数开得过大每个线程只加载一个元素就参与归约跨线程归约时同步次数过多最后用原子操作暴力收尾。这些问题的权衡在不同数据长度下的最优解不一样很难找到一个通吃的参数组合。我们处理的这个算子在跨批次维度做reduction输入长度在不同调用点可以相差几十倍。以前用固定线程策略凑合长输入时性能还行短输入时启动开销占比太高整段kernel都被拖慢。alt 这个算子属于那种看起来每个地方都不难但组合起来就是不够快的类型。5.2 代理发现的一种反直觉调度方式代理在给方案之前先要求跑了一组长度从短到长的benchmark。然后它的方案有点反直觉不采用能覆盖全部元素的线程数配置而是固定一个中等数量的block让每个线程串行处理多段数据。它把线程内累加做足之后再做线程间树形归约。这样做的逻辑是短输入时少开线程可以减少调度和初始化开销长输入时每个线程多做几次累加也能增加数据复用。代理还特别调整了最后归约阶段使用的shared memory槽位数把同步次数从三次降到两次。改动落地后短输入性能提升了超过30%长输入也有一小段收益整体方差小了很多。这个方案讲给同事听的时候很多人第一反应是线程开少了不是浪费并行度吗但测试数据摆出来之后大家很快就接受了。5.3 新平台老平台行为差异不过这个方案换到另一款偏老的回测平台上效果就打了不少折扣。因为老平台的计算单元数量和调度方式不同固定较少的block不一定能跑满所有单元线程内串行累加的收益也会被访存延迟覆盖掉。这件事让我学到一个重要教训代理在一个平台上学到的优化结论不能默认迁移到另一个平台。我们现在会把kernel结构和具体平台的参数同时喂给代理让它在提方案时就考虑平台差异。如果不同平台之间的行为差异很大宁可让代理针对同一个算子分别产出一套方案也不强行统一。性能优化这件事平台相关性的分量比很多人想象中要大。6. 与人工优化、传统autotuner的成本对比和取舍6.1 成本统计和实现收益如果只是拍脑袋说LLM代理效果好那没有说服力。我大致统计了一下内部一组算子的优化成本结果比较直观优化环节纯人工方式人工代理配合说明profiler报告解读约一到两小时十几到二十分钟代理直接生成瓶颈摘要候选方案设计数小时到一天半小时到两小时依赖上下文是否完整kernel补丁实现几小时十分钟到一小时编译失败率不低需复核benchmark回归手动脚本半天自动化小时级需要提前搭好验证网方案取舍与回滚靠经验判断代理给对比数据人复核人的判断仍然关键这些数字不精确但量级能说明问题。把代理接进闭环之后一个中等复杂度的算子从出profiler报告到拿到相对稳定的改进版本平均耗时大约是原来的三分之一。这是它被当作一等优化手段的最直接原因——不是因为它写出来的代码多漂亮而是整个决策循环被压缩了。6.2 不适合用LLM代理的场景代理也不是万能的。有几种情况我明确不建议上算子只会跑一次优化完就进存档库。这种投入产出比太低。kernel结构非常依赖专有硬件特性而代理的知识来自通用资料容易给出无效建议。工程上无法搭建自动benchmark环境。代理一旦失去快速验证能力和普通的代码生成器没有本质区别甚至更危险因为它会生成更多让人看了想采纳的候选方案。团队还没有建立起kernel仓库的版本回滚习惯。代理自动提补丁会产生大量废弃版本没有回滚能力的仓库很快会乱套。6.3 怎么控制代理产出质量控制质量的关键不是让代理少生成而是让坏改动过不了验证网。我们的做法是给每个kernel改动设定一组通过标准主shape和长尾shape的耗时不低于基线数值误差低于阈值寄存器用量不超限编译告警数量不增加。代理生成的任何补丁都必须先过这套标准之后才可能进入人工review。另外我会要求代理在每个补丁里用注释写清楚为什么这么改这是强制项。这个注释质量本身比补丁里的代码更能反映它是否真正理解了问题。如果代理只能给出改动、给不出理由那基本就是在猜直接驳回比反复review更省时间。7. 落地避坑清单验证、回归、上下文和版本7.1 性能回归要覆盖shape族不能只盯主shape这个坑我反复踩过。一个优化方案在主shape上收益很高但换一个shape就出现明显倒退。原因往往是指令调度或者shared memory分配策略在不同数据尺寸下走了完全不同的分支。所以现在任何优化至少要跑一组覆盖短、中、长的shape族并且把它们放进自动化回归里。代理也理解这个要求它会在提案阶段主动询问需要覆盖哪些shape范围相比以前手动补测试省事很多。7.2 数值误差不能只看最大误差对于涉及浮点累加顺序变化的kernel最大误差只是一个粗略指标。有时候最大误差很小但误差分布出现系统性偏移比如所有结果都比旧版本小一点点。这种事只有在跑多组数据、统计误差分布的时候才能看出来。我们在验证脚本里加了一条简单规则对多组输入统计误差的均值和标准差并要求均值的绝对值不超过某个阈值。单看max diff很容易被个别离群点欺骗。7.3 上下文膨胀会让代理优化健忘前面提过外部记忆摘要这里再强调一次。会话变长之后代理会把已经证明无效的方案重新提出来或者在新一轮里忽略早期确定的约束。不要指望模型自己能记得住。每个优化会话开始时都把已试方案摘要当前kernel版本约束清单作为前缀能省掉大量重复劳动。这个技巧是我们在实际使用中觉得最值得分享的一条。7.4 kernel、模型、提示词都要锁版本代理优化链路里的组件比人工流程多任何一个环节变化都可能影响最终结果。kernel源码有git管理但提示词和模型版本经常被忽略。后来我们把整套配置也当成代码来管理模型版本、框架版本、提示词、验证脚本、基准kernel的哈希值全部锁进同一个配置仓库。这样当某个优化结果出现异常时可以快速还原出当时的完整环境。对于需要复现和评审的优化报告来说这几乎是不能省的一步。8. 个人体会与下一步尝试8.1 从单算子优化到整链路优化这几个月跑下来我最大的体会是LLM代理的价值不在单算子而在它能串起一个完整的优化链路。当一个算子的改动被验证通过后代理可以把上下文带到下一个相关算子顺带检查调用侧有没有可以合并的kernel、布局转换能不能前置。过去我们一次优化一个点现在代理让我们有机会一次优化一个面。这条路的潜力还远远没有释放完。8.2 工程师的判断力变得更值钱了很多人担心代理会让kernel优化工程师失业。我的感受正相反它淘汰的是照手册拼配置的部分但强化了判断方案边界的部分。代理会生成很多看起来合理、但不宜采用的方案判断哪些改动会在长尾场景里埋雷这件事最终还是落在人身上。能做好这件事的人价值不但没降反而更高了。8.3 下一步想把方案的为什么沉淀下来最后说一个接下来想做的事。我打算把每次优化会话里代理产出的方案理由整理成一个可检索的知识库再反向用来改进提示词和验证标准。很多优化经验其实藏在对话历史里不沉淀就浪费了。这也是我继续把这个工程做下去的主要动力——不是让代理替代谁而是把过去靠经验传承的东西变成团队可以积累、可以迭代的技术资产。
