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 下一步想把方案的"为什么"沉淀下来最后说一个接下来想做的事。我打算把每次优化会话里代理产出的"方案理由"整理成一个可检索的知识库，再反向用来改进提示词和验证标准。很多优化经验其实藏在对话历史里，不沉淀就浪费了。这也是我继续把这个工程做下去的主要动力——不是让代理替代谁，而是把过去靠经验传承的东西变成团队可以积累、可以迭代的技术资产。
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 下一步想把方案的"为什么"沉淀下来最后说一个接下来想做的事。我打算把每次优化会话里代理产出的"方案理由"整理成一个可检索的知识库，再反向用来改进提示词和验证标准。很多优化经验其实藏在对话历史里，不沉淀就浪费了。这也是我继续把这个工程做下去的主要动力——不是让代理替代谁，而是把过去靠经验传承的东西变成团队可以积累、可以迭代的技术资产。