上个月我做了一次不算严谨但很有代表性的测试把一份 STREAM benchmark 的perf stat原始输出丢给一个接了函数调用的 AI Agent让它分析内存带宽瓶颈并给出可执行的优化建议。不到三十秒它给出了三条结论两条关于 NUMA 和内存页大小的判断是对的但第三条建议我“打开超线程提升内存带宽”这在我那台双路机器上几乎等于教人往反方向踩油门。这个场景基本回答了标题里的问题AI Agent 现在确实能做 HPC 性能优化但说“独立”还差了一大截。这篇文章不打算做概念科普而是把我最近的实测过程、翻车现场和沉淀下来的可靠用法完整记录一遍。如果你正在考虑把 Agent 引入性能优化日常工作或者只是好奇大模型在超算场景里到底能扛多少活这篇应该能给你一份相对真实的参考。1. 先说结论独立优化还有距离但“会话式分析”已经可用1.1 我实测后的总体判断先把观点放前面。经过最近几轮实验我的判断是AI Agent 在 HPC 性能优化中的角色已经从“完全不能用”进化到了“能当靠谱的初级分析员”但距离“独立完成优化闭环”还很远。这里说的独立指的是它能自己完成从性能数据采集、瓶颈定位、方案设计、实施优化到回归验证的全流程。目前卡住它的不是单点能力而是缺少对特定系统的深度感知以及一个可靠的验证闭环。当前表现最稳定的场景是“会话式分析”。你把一份 profile 输出、一段热点代码、一个作业脚本丢给它让它提炼关键信息、解释瓶颈、给出方向性建议这个层级的任务它完成得相当好。尤其是面对大型应用几万行的 profile 输出时它快速归纳热点的能力已经超过不少初级工程师。但一旦进入需要改动代码、重新编译、上机压测、对比收益的循环它就容易在半路走偏。为什么会出现这种分化我的理解是大模型擅长处理“文本层面的模式”而性能优化最终要落回到“物理层面的行为”。它能看出来热点在哪但不知道这台机器上 NUMA 拓扑具体长什么样不知道当前编译器版本对这个循环生成了什么指令更不知道跑完一次 Allreduce 实际要多少微秒。这些都需要外部工具和测试闭环来补问题恰恰出在这部分集成还很不成熟。1.2 为什么 HPC 性能优化是 AI Agent 最不该轻视的考题我见过不少人把 HPC 性能优化和普通的“代码提速”混为一谈这是个大误区。手游性能优化、Windows 游戏优化这类场景大部分瓶颈是显性的比如掉帧、卡顿、内存占用过高工具链也成熟Agent 很容易从海量教程里检索到现成方案。移动端性能优化甚至有一套标准动作看 CPU 占用、查内存泄漏、降绘制负载。这些确实是 Agent 的舒适区。但 HPC 不一样。HPC 应用通常跑在异构、分布式的集群上瓶颈可能出现在 CPU 微架构、内存层级、网络互连、MPI 运行时、并行算法、数值稳定性等多个层面。而且同一个优化手段在这台机器上是蜜糖换到另一台机器可能就是毒药。比如 SIMD 向量化在支持 AVX-512 的处理器上是利器换到 Arm 平台就完全不适用MPI 通信参数在 InfiniBand 和以太网上需要完全不同的设置。这种平台相关性和性能可移植性问题让“网上搜答案”的策略变得很不靠谱而这恰恰是 AI Agent 最喜欢走的捷径。所以说 HPC 是 AI Agent 的试金石不是劝退大家而是想说明如果要做真正的“AI Agent 做性能优化”HPC 是最能暴露问题、也最能逼出真实能力的场景。在这个领域踩过的坑回头拿到普通软件优化里基本都是降维打击。2. 性能优化不是“语言题”而是“系统题”2.1 瓶颈分五层硬件、系统软件、运行时、算法、业务我在带新人做性能分析时习惯先让他们建立一张五层视图。每一层都有自己的工具和语言也会产生完全不同的瓶颈特征。这五层是层次典型瓶颈常用工具硬件缓存未命中、NUMA 远端访问、向量化率低、频率受限perf、VTune、likwid系统软件内核调度、内存页大小、文件系统 IO、驱动perf、strace、iostat并行运行时MPI 通信、OpenMP 同步、GPU 数据传输HPCToolkit、mpiP、Nsight算法负载不均衡、通信次数多、算法复杂度高代码审查、trace 分析业务精度需求过高、重复计算、数据格式不合理领域知识、日志分析这套视图对理解 AI Agent 的价值与局限特别有帮助。Agent 很擅长从文本工具输出里识别出“这一层有问题”但它很难自主地把问题归因到正确的层。我见过一个很典型的例子Agent 看到cache-misses高直接建议“优化循环访问模式”但实际上瓶颈在另一颗 NUMA 节点上的远端内存访问单纯改变循环顺序根本没用得改数据分布和线程绑定策略。这种跨层归因恰恰是经验型工程师的看家本领也是当前 Agent 最薄弱的地方。另一个常见问题是“层间混淆”。Agent 可能把应用层的时间开销归到 MPI 通信层或者把存储 IO 的延迟误判为计算瓶颈。根本原因在于它缺少同时读多层数据的能力只凭单一 profile 输出在猜。所以我现在给 Agent 设计任务时会刻意要求它交叉验证至少两类数据比如perf stat和mpiP报告一起看再下结论。这个习惯非常管用。2.2 同一份代码换台机器就翻车平台感知是硬门槛举一个我在实验里反复撞墙的例子。同一个矩阵乘法内核在 Intel 平台用icc编译开-xCORE-AVX2效果很好同样的源码放到 AMD EPYC 上还套用同一组编译选项性能直接掉一截因为编译器后端和微架构对自动向量化的处理完全不同。AI Agent 如果不知道当前是什么 CPU、什么编译器、什么 MPI 版本给出的建议就是在真空里做推理。这不是小问题。HPC 生态强调“性能可移植性”一份代码往往要跑在多种架构的集群上就像一个接口要兼容各种调用方一样。Agent 对平台信息的感知决定了它的建议是“对的理论”还是“对的实践”。我在后面的实验里会给系统提示词强行注入平台清单要求 Agent 在给建议前先执行几个采集命令确认真实环境。这个简单动作直接把建议的可用率提升了一个档次。具体来说我让 Agent 在回答任何性能问题前必须先调用一组命令拿到环境快照。命令很简单比如lscpu、numactl --hardware、cc --version、mpirun --version、scontrol show node。这套“先取证再说”的流程本质上是把工程师日常的习惯固化到了 Agent 的工作流里。它不会让 Agent 变成专家但能明显减少“瞎猜”的比例。2.3 AI Agent 与 AutoTuner 的分工边界这里要区分一个很多人混淆的概念传统自动调优工具AutoTuner和 AI Agent。OpenTuner、Bayesian optimization 这类工具早就在帮 HPC 做参数搜索但它们不理解程序语义只做黑盒采样。AI Agent 恰好相反它理解语义和模式但缺少对物理性能的采样能力。我一直在强调一个观点不要把两者对立起来。最靠谱的路线是让 AutoTuner 负责“跑”让 Agent 负责“想”。Agent 根据 profile 和源码提出可能的关键参数和优化策略AutoTuner 在给定范围内做密集搜索验证Agent 再根据验证结果迭代。在我实验过的组合里这样配合后调参效率比单纯用 AutoTuner 高不少因为 Agent 能把搜索空间从几千维缩到几十维减掉大量无效组合。这不叫“AI Agent 独立优化”但这确实是当前最接近实用的路径。对 HPC 团队来说与其等 Agent 完全成熟不如现在就把传统调优工具的数据接口和 Agent 的推理能力打通先享受一部分自动化红利。3. 我自己搭的一套“Agent 优化 HPC”最小实验3.1 工具链选型模型、代理框架、沙箱与性能工具为了验证上面的判断我搭了一套最小可用的实验环境你也可以照抄。模型我混用过云端 API 和本地部署的 Qwen 系模型。代理框架没有用太重的东西直接用支持函数调用的 Python SDK再写一层白名单命令封装避免 Agent 能随便执行危险操作。性能工具用的是最常见的perf、likwid和HPCToolkit测试程序选了 STREAM benchmark、一个简单 MPI pingpong外加一个手写的矩阵乘法。这里有一个很重要的设计原则给 Agent 一个受控的沙箱。它不是直接拿到集群所有权限而是只能运行我预先授权的命令比如perf stat、mpirun -n 4 ./app、cat /proc/cpuinfo、lscpu这类。所有修改代码的操作都由它生成 diff再回到我的工作目录确认后才执行。这样既保留了 Agent 的自主性又不会让它把测试节点搞挂。沙箱还应该做资源限制。我在作业提交命令外面套了一层timeout和ulimit防止 Agent 写了个死循环或者把内存跑满。很多人觉得这些细节无所谓但如果你真让 Agent 自主跑过实验就知道这两个限制能救命。HPC 集群是共享环境一个失控的作业会波及整个队列这个风险不值得冒。3.2 三个实验任务从 profile 解读到调参建议我设计了三个难度递增的任务Profile 解读给它一份 STREAM 的perf stat输出要求它指出瓶颈类型并给出验证方法。循环优化建议给它一段三重循环的矩阵乘法源码让它提出编译指示pragma和循环变换建议。MPI 进程数推荐给它节点配置和 pingpong 延迟数据让它推荐 MPI 测试的进程数量和绑定策略。每个任务都要求它必须说明依据和可验证的预期收益不能只说结论。这个“必须附验证方案”的约束对过滤幻觉极其有效。你会发现一旦要求 Agent 写出“我怎么验证这条建议”它自己就会先卡掉一半不靠谱的想法因为那些想法根本设计不出验证实验。任务之间也刻意做了难度梯度。第一个任务只需要对已有文本做归纳类似“读完报告写摘要”第二个任务需要结合代码语义和环境信息做推理第三个任务需要对分布式系统的运行时有真实理解还要有“预防资源失控”的常识。这样梯度设计能清楚地看出 Agent 在哪个层级开始掉链子。3.3 实验结果哪个成功了哪个把机器搞挂了结果非常有意思我整理成了一张表任务结果主要问题Profile 解读基本成功正确识别访存受限但给出的验证步骤有一半多余循环优化部分成功提出的#pragma omp simd有效但同时建议了一个对非连续访存无用的 unroll 参数MPI 进程数推荐危险失败忽略了绑定策略按它的建议跑测试节点直接负载失控任务被调度器杀掉第三个任务最值得反思。它知道应该用多少进程但对“绑定到哪些核心”完全没概念直接把进程都扔到了同一个 NUMA 节点上内存带宽被打满整个节点响应变慢。好在沙箱里我限制了作业时长和资源上限否则可能影响其他人。这也是我坚持要加资源限制的原因AI Agent 的自主性越大安全护栏就越要提前做好。第二任务也很有代表性。它推荐的 unroll 参数来自一个公开的 benchmark 调优案例在连续内存访问的场景下确实有效我们这段代码是非连续访存unroll 不仅没用还增加了寄存器压力。Agent 的问题不是不懂 unroll而是没有认真检查我们的访存模式。这再次印证了“平台/场景感知”的重要性。4. 复盘四类翻车现场Agent 最常犯的错误这章是全文最值得反复看的部分。把这些错误统称为“幻觉”并不准确里面至少能拆出四类不同根源的问题。4.1 幻觉式优化建议看似专业实则误导第一类是最经典的。Agent 给出的建议在句式上非常专业但内容经不起验证。比如它在编译选项上推荐了一个“-ipo提升跨文件内联”听起来头头是道但在我们这套 CMake 构建里-ipo与既有链接器插件冲突反而把构建搞挂了。还有一次它建议用cudaMemcpyAsync优化一个根本没有 CUDA 数据的 CPU 程序完全是把通用知识张冠李戴。这类幻觉的根源是语言模型在训练时见过了太多优化文章学会的是“这段话看起来像优化建议”而不是“这个建议在当前代码里能成立”。要减少这类错误最有效的不是换更大模型而是在提示词里强制它给出建议成立的前提条件并让它引用 profile 数据作为证据。如果某个建议的前提条件和当前环境不匹配它至少会犹豫而不是直接输出。我还试过一招让 Agent 给自己的建议打“置信度分”并写一句“这个建议在什么条件下不成立”。这个反过来的约束比单纯让它“自信”有效得多。它迫使 Agent 去思考边界条件很多幻觉建议在这个过程中就被自己推翻了。4.2 上下文太短只看摘要就下结论第二类问题让我意识到给 Agent 喂数据的方式比选什么模型更重要。HPC 的 profile 输出动辄几万行Agent 一次根本读不完。我之前直接把全量HPCToolkit数据库导出成文本塞进去结果它只看到了前面几千行热点得出结论说“整个程序瓶颈在解析输入文件”完全忽略了后面更严重的 MPI 通信热点。后来我改成两段式先用hpcprof汇总出一个“热点摘要表”只把 Top 20 热点函数和相关调用栈喂给 Agent让它判断下一步要深挖哪个函数再按需展开调用栈详情。效果立竿见影。这个经验说白了很简单把 Agent 当成一个必须看重点汇报的同事而不是能自己读几百页年报的机器人。你喂给它的信息质量直接决定它判断的质量。这个思路也可以反向用。如果 Agent 说“信息不足”与其强行让它回答不如把缺失的信息类型列出来让它提交一份“数据采集请求清单”。它想看哪部分 profile、哪段调用栈、哪些环境信息我们再针对性提供。这样做虽然多一两轮交互但最终结论的扎实程度完全不同。4.3 缺失验证闭环优化完不看疗效第三类是最隐蔽的。Agent 提出一条优化建议在逻辑上完全正确代码改得也没错但它不会主动去跑一次回归测试导致你根本不知道这条优化是不是真的有效。我实验里让它给矩阵乘法加 unroll pragma效果是正的但它同时也改了#pragma omp parallel for的调度方式结果在线程数少时反而变慢。因为 Agent 只做了离线推荐没有执行“编译-运行-对比时间”的闭环。解决办法是在工具链里强制把“效果验证”变成 Agent 工作流的一环。我让 Agent 每次输出建议时必须同时生成一个验证命令并且在下一轮对话里把验证结果作为输入之一。我这里把这种模式叫“带反馈回路的 Agent”。一旦加上这个环节它的建议质量会明显提升因为它能看到自己的推荐真实的性能数字形成自我纠正。要实现这个闭环光靠提示词还不够最好在代码层面做一套工具函数。比如定义好“编译并运行基准测试”的函数Agent 可以直接调用拿到 stdout 里的耗时结果。这样反馈不是靠人转述而是 Agent 亲眼看到的“观测数据”说服力强得多。4.4 平台差异感知弱拿通用规律套特殊硬件第四类是所有 HPC 场景落地时绕不开的坑。Agent 的知识来自互联网上的通用内容对它来说“Intel Ice Lake”和“AMD Milan”可能都只是字符串不知道它们的 L3 缓存大小、核心拓扑和 SIMD 宽度差异。于是它会把针对 Intel 的调优经验直接套用到 AMD 上或者在 Slurm 集群上使用非标准的mpirun参数。我现在的做法是在系统提示词里放一份“平台档案”包括 CPU 型号、核心数、NUMA 节点分布、编译器版本、MPI 实现、作业调度器然后要求 Agent 在做任何平台相关建议前先执行lscpu、mpirun --version、scontrol show node之类的命令确认环境。说白了就是给 Agent 装上一副“看环境的眼镜”。没这副眼镜它相当于在黑暗的房间里调参数偶尔能蒙对但长期看不可依赖。平台档案不是一份静态文件而应该是 Agent 启动时自动生成的一屏文字。我还建议团队把硬件变更记录也喂给它比如“上个月这台机器从双路 Xeon 升级到了 EPYC”这能帮 Agent 避免用过时的硬件假设。虽然这些操作看起来像是在“伺候”Agent但回报是建议质量肉眼可见的上升。5. 哪些环节 Agent 已经能顶半边天说完翻车也得公平地讲在我最近的实践中有几个环节 Agent 已经能实实在在顶半边天值得在日常工作中铺开。5.1 profile 初筛与日志踩坑把几千行 profile 输出快速压缩成“Top 热点 可疑点清单”这个活 Agent 干得又快又好。比如下面这段 STREAM 的perf stat输出它能马上指出cache-misses率偏高、访存受限并建议进一步用likwid-perfctr看实际带宽。这种初筛工作以前要新人花半天现在十分钟能出一版像样的报告。perf stat -e cycles,instructions,cache-misses,cache-references ./stream它还能从报错日志里筛出常见问题比如 MPI 版本不匹配、依赖库缺失、ulimit设置过小。虽然这些都是“查文档能解决”的问题但 Agent 让你省掉了查文档的时间这个价值已经足够在日常工作中常态化使用。我在团队里已经把这个环节固化成一条流水线半夜的批处理作业失败第二天一早 Agent 自动汇总日志摘要和可能原因工程师上班只消看一份报告就能定位问题。这不惊艳但很实用。5.2 编译器选项与循环变换建议在明确给定平台型号和编译器版本的前提下Agent 对循环优化、编译选项的建议也有一定实战价值。它能根据循环体内访存模式提出#pragma omp simd、#pragma GCC unroll 4、交换循环顺序等建议而且给出的理由基本能站住脚。我用它推荐过矩阵乘法里的一处#pragma omp simd实测凑效。但要注意这些建议必须经过“编译-运行-对比”验证不能直接合入主干。因为 Agent 推荐的参数经常是它记忆中“对同类问题有效”的某个值而不是经过当前机器实测的最优值。把它当“优化点探测器”用正合适。我通常的做法是把 Agent 提出的五条建议全部列进一个实验矩阵跑一遍小规模基准留下收益为正的那一两条再上全量数据验证。这样既利用了 Agent 快速产出候选方案的优点又不会让未经证实的优化进入正式代码。5.3 可读性重构与优化文档生成很多人低估了这部分的价值。HPC 老代码里充满了晦涩的变量名和几万行的巨型函数人工读起来非常耗时。Agent 把一段代码重构得更清晰、生成注释和模块文档虽然不直接提升性能但让工程师更容易发现可优化点也为后续性能分析提供了良好的代码基础。我在一次调试 MPI 死锁时就是靠 Agent 把复杂通信流程整理成清晰的时序描述才快速定位到问题。这个方向我认为值得所有 HPC 团队认真铺开。因为 HPC 领域有一个被长期忽视的痛点大量老代码的文档严重缺失性能优化往往要先花大量时间读懂代码。Agent 至少能把这个前置时间压缩一半。5.4 自动生成基准测试与回归脚本最后一个好用的场景是写脚本。Agent 很擅长根据你的需求生成sbatch提交脚本、批量测试脚本和性能回归脚本比如#!/bin/bash #SBATCH --nodes1 #SBATCH --ntasks4 #SBATCH --cpus-per-task8 #SBATCH --time00:10:00 perf stat -e cache-misses,cache-references ./mpi_app 2 profile.log我以前写这类脚本要反复查文档现在直接把需求描述给它基本一次就能跑通。这为后续“让 Agent 自动跑回归”打下了基础——脚本化程度越高闭环验证就越容易自动化。目前我已经把常用的回归测试脚本模板交给 Agent 管理它能在每次代码变更后生成对应的对比报告。虽然还做不到完全自动决策但已经把工程师从“重复写脚本、重复看报告”的琐事里解放出来了。6. 人机协作的可落地模式Agent 当侦察兵工程师当指挥官6.1 一套可复用的工作流经过几次试错我沉淀出一套简洁的工作流不是让 Agent 单干而是把它放在“侦察兵”的位置信息采集Agent 先读取环境信息和 profile 摘要汇总成要点报告。方向确认人类工程师根据报告圈定优化方向决定是否授权 Agent 深入分析。深入分析与方案生成Agent 针对指定热点展开调用栈、提出多个优化方案标注预期收益和风险。人类审批工程师审核方案挑出值得试的方向要求 Agent 生成具体改法和验证脚本。自动回归Agent 在沙箱里执行编译和性能测试输出前后对比。结果汇报Agent 汇总数据人类决定是否合入版本。这个流程的关键是把“人类审批”放在“实施优化”之前而不是之后。HPC 集群是共享资源一份没有验证的优化建议直接上生产环境风险太高。而有了这个审批点Agent 既可以放开探索又不会失控。我在团队里把这个流程做成了一张 checklist挂在项目看板上。每个 Agent 产出的优化项都对应一条卡片卡片上的字段包括问题陈述、依据数据、建议方案、预期收益、实际收益、最终结论。这样不仅流程清晰还顺带积累了团队自己的优化知识库。6.2 让 Agent 的产出变得可验证的三个技巧在反复调教 Agent 的过程中有三个技巧值得单独说。第一强制它写“验证方案”。在提示词里明确要求任何优化建议必须附带“如何验证、预期提速、风险等级”三项。没写就追问直到它写为止。这个约束能过滤掉大量只顾说得漂亮不保证实操的建议。第二要求它先输出“不建议做的事情”。我在一次实验里让 Agent 先列出当前代码里“不值得优化的方向”它给出的答案相当有洞察力。因为 Agent 对“不做什么”的顾虑更少反而能帮工程师避开沉没成本。这个技巧建议大家直接试试。第三用 git diff 管理 Agent 的修改。所有代码改动都通过 Agent 生成 diff再在独立分支上应用。好处是出问题随时回滚而且每次 diff 都有记录久了就能建立起团队自己的“Agent 建议效果库”哪些类型的建议可靠一目了然。这三个技巧都不是什么高深招数但每一招都解决一个真实的落地痛点不写验证方案的建议没法信不说不做什么的建议会带偏方向没有 diff 管理的改动没法回滚。工具链不复杂复杂的是把这些约束固化到流程里。6.3 团队落地前需要划清的红线最后说点组织层面的经验。把 Agent 引入 HPC 优化工作技术上是次要难点真正的难点是边界的划分。我建议团队至少划清这几条红线Agent 只能访问测试节点和沙箱环境生产集群和共享存储必须隔离。资源上限要写死在调度器层作业时长、内存、核数都限死防住 Agent 的失控操作。所有建议都要留痕方便事后复盘是模型问题还是环境问题。不要指望 Agent 替代性能工程师的分析责任它只能扩大工程师的视野最终判断还得人来负。我个人的体会是把 Agent 当同事而不是工具反而容易用好它。同事会犯错所以你要复核它的工作同事有盲区所以你要给它补足信息同事能力在成长所以每隔几周你会惊喜地发现它又能干点新活了。AI Agent 做 HPC 性能优化的现状也是这个状态离独立还远但已经值得你认真开始和它配合。我自己现在的习惯是每次拿到新的性能问题先让 Agent 跑一遍“侦察流程”然后逼着它先讲“哪些事不要做”。这个听起来有点反直觉的做法反而帮我避开过好几次无效优化。如果你也在试 Agent 做性能优化我建议你也从这一步开始。