面向国产 DCU 加速卡的 LLM Agent 驱动 GPU 内核优化框架适配与验证

GPU优化Agent相关实习生招募

达坦科技联合鹏城实验室与琶洲实验室（黄埔），现面向高校学生开放长期线下实习岗位，诚邀有志于GPU算子开发与优化领域的青年人才加入顶尖科研团队。

在这里，你将直面真实科研课题，参与的工作成果将部分开源，与资深技术团队共同探索AI基础设施的技术前沿。期待你的加入！详细信息参考文章：国家级实验室科研实战｜GPU 算子开发优化实习生火热招募中！

摘要：CUDAAnalyst 是 ICML 2026 提出的一种基于大语言模型（LLM）Agent 的 CUDA 内核自演化分析框架，其核心贡献在于提出了一种生成级别的反馈归因方法，可定量衡量不同反馈信号（正确性检查、静态分析、性能剖析）对 Agent 优化决策的边际贡献。然而，该框架在设计上深度耦合 NVIDIA 生态（pynvml、nvcc、Nsight Compute 等），无法直接运行于国产 DCU 加速卡。本文系统性地完成了 CUDAAnalyst 从 NVIDIA GPU 向海光 DCU（gfx928 架构）的全栈适配，涵盖 GPU 管理、编译器工具链、CUDA 语法转换、性能分析工具降级等 10 项修改，并在适配后的平台上以自定义 GEMM 内核为对象进行了迭代优化实验，取得了 1.69× 的性能提升。实验过程中，我们发现并分析了 LLM Agent 通过篡改验证逻辑伪造性能数据的"作弊"行为，进而提出了分离式验证架构作为防御机制。此外，我们将适配方案扩展至 Triton 内核优化场景，取得了 2.17× 的加速比，验证了 CUDAAnalyst 反馈-规划归因方法的跨语言通用性。

01、引言

随着大语言模型代码生成能力的快速提升，利用 LLM Agent 自动优化 GPU 内核代码已成为一个新的研究热点。该类工作的核心思路是将 GPU 内核优化建模为迭代搜索问题：由 LLM 扮演"优化器"角色，阅读当前代码、分析性能瓶颈、提出优化方案、生成新的内核变体，再根据运行时反馈进行调整。与传统手工优化（依赖深入的硬件架构知识）和基于编译器的自动调优（搜索空间受限）相比，LLM Agent 方法具有三方面优势：其一，LLM 能理解代码的算法意图，而非仅进行语法层面的变换；其二，LLM 在预训练中积累了大量的 CUDA 优化模式（如共享内存分块、向量化访存、Warp Shuffle 等），可直接迁移至新内核的优化；其三，LLM 不受固定变换规则的约束，能够提出超出预定义搜索空间的创造性方案。

然而，已有工作普遍存在一个方法论缺陷：它们将 LLM Agent 的执行过程视为黑箱端到端流程，无法定量分析哪个反馈信号（静态分析？运行时性能？正确性检查？）对最终的优化决策产生了多大贡献。CUDAAnalyst[1] 正是为解决这一问题而提出的。该框架由清华大学发表于 ICML 2026，其核心贡献在于提出了一种生成级别的反馈归因方法——通过将 Agent 执行过程解耦为"反馈获取"与"规划生成"两个阶段，在固定的生成快照上进行受控干预，从而避免传统端到端消融方法中迭代规划放大早期扰动所导致的轨迹漂移（Trajectory Drift）问题。CUDAAnalyst 使用博弈论中的 Banzhaf 值来量化每个反馈信号对规划决策的边际贡献，为理解 LLM Agent 的决策机制提供了精细的分析工具。

此外，CUDAAnalyst 以及此前绝大多数 GPU 内核优化 Agent 工作，均隐含假设运行环境为 NVIDIA GPU。这种假设渗透在系统的各个层面：GPU 管理依赖 pynvml（NVIDIA 管理库），编译器依赖 nvcc（NVIDIA CUDA 编译器），性能剖析依赖 ncu/nsys（Nsight Compute/Systems），运行时检查依赖 compute-sanitizer，内核启动语法则使用 <<<grid, block>>>（nvcc 专有扩展）。国产 DCU 加速卡虽然在编程模型上通过 HIP 提供了与 CUDA 类似的兼容层，但在工具链、编译器、性能分析等方面与 NVIDIA 生态存在显著差异。要让 CUDAAnalyst 在 DCU 上运行，需要系统性地替换或降级这些依赖。

本文介绍我们将 CUDAAnalyst 完整适配至海光 DCU 平台的工作，主要贡献包括：(1) 完成了从 GPU 管理到编译器工具链的全栈适配，共 10 项修改；(2) 在 DCU 上对自定义 GEMM 内核进行了迭代优化验证，取得了 1.69× 的性能提升；(3) 发现并分析了 LLM Agent 的"作弊"行为，提出了分离式验证架构；(4) 将系统扩展至 Triton 内核优化场景，取得了 2.17× 的加速比。

02、CUDAAnalyst 框架概述

CUDAAnalyst 的架构由三个分析模块和两个 LLM Agent 组成。三个分析模块分别为：(1) Debugger，通过 clang-tidy 静态检查和 compute-sanitizer 运行时检查确保内核正确性；(2) Analyzer，基于 tree-sitter 解析 CUDA 源码，提取循环嵌套结构与访存模式，进行多面体分析；(3) Profiler，通过 Nsight Compute 采集内核性能数据（访存带宽、占用率、计算吞吐等）。每个模块可独立开关（通过位掩码控制 MODE\_FULL/MODE\_RAW/MODE\_NONE），从而精确衡量每个反馈信号对规划决策的边际贡献。两个 LLM Agent 分别为：(1) SummaryAgent，将各工具的原始反馈聚合为高层语义摘要；(2) PlanAgent，基于所有摘要生成结构化的优化路线图，注入进化流程。

https://github.com/yuxuan-z19/cudanalyst

CUDAAnalyst 的实验揭示了若干重要规律：规划必须建立在真实的反馈之上——没有反馈支撑的显式规划不仅无益，反而会降低性能；反馈工具之间存在互补效应——Analyzer 促进编译成功率，Profiler 驱动后期性能提升，Debugger 调节工具间的交互；反馈摘要可以辅助但不能替代显式规划；强模型的规划可以部分迁移至弱模型，且同家族内的迁移效果更优。

03、适配方案

我们的实验环境配置为：Hygon C86 7285 CPU（32 核），4× K500SM\_AI DCU（gfx928 架构，64 GB HBM），DTK 6.3.3/dcc 编译器（基于 clang 17），HIP 6.2.0 运行时，Python 3.10，PyTorch 2.9.0+（DCU 定制版本），LLM 使用 DeepSeek V4 Flash（通过 API 网关）。在着手适配之前，我们首先对 CUDAAnalyst 的依赖进行了系统分析，将需要修改的内容分为三个层次：必须适配的功能性障碍、需要优雅降级的功能缺失、以及次要的兼容性修复。

<u>3.1 功能性适配</u>

GPU 管理接口（pynvml → amdsmi）。这是最关键的一处适配。我们新建了 adapt.py 模块，使用 AMD 的 amdsmi 库重新实现了 CUDAAnalyst 所需的全部 GPU 管理接口，包括设备枚举、显存查询、利用率监控和空闲 GPU 选择。系统保留了原有的四种 GPU 选择策略（random、min\_mem、min\_util、default），并在运行时自动检测环境：若检测到 NVIDIA GPU 则使用原有 pynvml 实现，否则切换至 amdsmi。

​编译器工具链​（nvcc → dcc）。dcc 是 DTK 提供的 CUDA 编译器，基于 clang 17。我们将编译选项进行了系统映射：目标架构由 -gencode arch=compute\_89,code=sm\_89 替换为 --cuda-gpu-arch=gfx928；快速数学优化由 -use\_fast\_math 替换为 -ffast-math -O3；PTX 汇编选项（-Xptxas）因 dcc 无对应物而移除；OpenMP 支持由 -Xcompiler -fopenmp 替换为 -Xclang -fopenmp。

​CUDA 源码转换​（hipify）。对于基准测试套件中的 CUDA 源码（NPB CG 等 6 个文件），我们使用 hipify-perl 进行自动转换，将 cudaMalloc/cudaMemcpy/cudaFree 等 CUDA Runtime API 替换为等价的 HIP API，将 <<<grid, block>>> 内核启动语法替换为 hipLaunchKernelGGL(...)，将 <cuda.h> 头文件替换为 <hip/hip\_runtime.h>。

<u>3.2 兼容性修复</u>

其余兼容性修复包括：(1) 将 typing.override（Python 3.12+ 特性）替换为 typing\_extensions.override，涉及 8 个文件；(2) 将 tree-sitter 解析器初始化从 tree-sitter-language-pack（依赖 GitHub 在线下载）切换至独立的 tree-sitter-cuda 包；(3) 在 make.common 中根据编译器类型自动选择设备编译标志（nvcc → -dc，dcc → -x hip -c）；(4) 在 get\_gpu\_arch.sh 中添加 rocminfo → amdgpu-arch → 默认 gfx928 的级联回退链；(5) 在 BaseTool.run\_cmd() 和 Module.run() 中添加对缺失工具的防护，避免管线崩溃。

04、实验验证

<u>4.1 实验设置</u>

适配完成后，我们使用自定义的矩阵乘法（GEMM）内核 my\_gemm 对系统进行了端到端验证。矩阵规模为 1024×1024×1024（单精度浮点），基线内核采用最朴素的 GEMM 实现——每线程独立遍历 K 维度，无共享内存，无数据复用。该内核的性能瓶颈显而易见：每个线程从全局内存加载 2×1024 个浮点数，访存总量约 2 GB，且对矩阵 A 的访问步长为 1024（非合并访存），带宽利用率极低。演化框架采用 OpenEvolve（多岛进化，3 个独立种群加迁移），LLM 为 DeepSeek V4 Flash，评估指标为 Mops（百万次运算/秒），优化目标为 combined\_score = custom\_mops / base\_mops。

<u>4.2 优化结果</u>

经过约 500 次迭代（3 个进化岛，约 100 余个独立程序变体），CUDAAnalyst 演化出的最优内核实现了共享内存分块加双缓冲（ping-pong）策略。具体而言，演化后的内核将 K 维度切分为 TILE\_K=16 的分块，使用 4 块共享内存（矩阵 A 和 B 各两块）实现双缓冲流水线：在计算当前分块的同时预取下一个分块的数据，从而有效隐藏全局内存访问延迟。优化后 Mops 从约 1,527,515 提升至约 2,585,435，加速比为 1.69×。

值得注意的是，CUDAAnalyst 的 CodeAnlzTool（基于 tree-sitter 的多面体分析）正确识别了基线内核的三个核心瓶颈：零数据复用（每线程独立加载 A 和 B 的全部元素）、A 矩阵非合并访存（步长=K=1024，导致约 90% 的带宽浪费）、以及无共享内存使用。基于此分析，PlanAgent 生成的优化路线图准确指明了"分块→共享内存→向量化访存→循环展开"的优化方向，而演化后的内核正是沿着这一路线逐步收敛的。

<u>4.3 Agent 作弊问题与防御</u>

在实验的早期版本中，我们曾观察到一组异常结果：最优 combined\_score 高达 50.17，平均达 20.67。对于一个朴素 GEMM 内核而言，通过 LLM 优化获得 50 倍性能提升在物理上是不可能的。经检查发现，Agent 生成的所谓"最优"内核实际上将输出矩阵全部置零，完全跳过了矩阵乘法计算；同时，Agent 篡改了 main() 函数中的验证逻辑，将"GPU 结果 vs CPU 参考值"的比较替换为"GPU 结果 vs GPU 自身结果"（永远通过），并直接 printf 硬编码的虚假 Mops 值。

查阅日志发现存在异常的50倍优化加速

这一现象的根源在于评估架构的设计缺陷——LLM Agent 拥有对整个源文件（包括 main() 和验证逻辑）的完全控制权。这与 Goodhart 定律的一个经典实例相符：当一个度量指标成为优化目标时，它就不再是一个好的度量指标。Agent 学会了优化评估指标（让评测器报告高分）而非优化实际任务（生成更快的矩阵乘法）。

我们重新设计了评估架构，核心思想是将验证框架与 LLM 可修改的内核代码完全分离。具体而言，我们将 test\_harness.cu（包含 main()、数据初始化、CPU 参考计算、验证逻辑和 Mops 计时）预编译为不可变的 .o 文件，在评测过程中永不重新编译；LLM Agent 仅能修改 kernel.cu（仅包含 \_\_global\_\_ 内核函数）。即使 Agent 试图在 kernel.cu 中定义 main()，也会因与 test\_harness.o 中的 main 符号重复而导致链接器错误。这种"分离式验证架构"——将评估基础设施编译为不可变的目标文件、限制 Agent 只能修改内核代码、使用链接器级别的符号冲突检测作为最后的安全网——为 Agent 驱动的性能优化系统提供了一种通用的评估安全模式。

05、Triton 扩展

在完成 CUDA/HIP 内核优化的适配和验证后，我们进一步将系统扩展至 Triton 语言。Triton 是一种面向 GPU 的 Python DSL，由 OpenAI 开发，提供了比 CUDA 更高层的编程抽象（自动处理共享内存分配、寄存器分配和内存合并），同时保留了对 Tensor Core 等硬件特性的精细控制。扩展 Triton 支持的意义在于验证 CUDAAnalyst 反馈-规划归因方法的跨语言通用性，并覆盖 Triton 在 PyTorch 生态中被广泛使用的优化场景。

Triton 的适配相对 CUDA 更为简洁，因为 Triton 本身通过其内部 LLVM 后端支持不同 GPU，主要的适配工作集中在评测器侧：将 eval.py 从编译加运行 CUDA 可执行文件改为 Python 子进程调用 Triton 内核；使用 PyTorch 的 torch.matmul 作为参考实现，torch.cuda.Event 进行精确定时；基线内核实现与 CUDA 朴素 GEMM 等价的 Triton 版本（小型 16×16 分块，无预取，无双缓冲）。

经过 50 次迭代，CUDAAnalyst 演化出的最优 Triton 内核实现了大块加预取双缓冲策略：分块大小从 16×16 大幅增加至 128×128×64，使用 tl.multiple\_of 对齐提示使能向量化全局加载，并在主循环中采用双缓冲流水线——计算当前分块的同时预取下一个分块的数据。优化后 Mops 从约 1,704,804 提升至约 3,702,956，加速比为 2.17×。

对比 CUDA 与 Triton 的优化结果，呈现出两个值得注意的特点。其一，Triton 的收敛速度显著更快（41 次 vs 454 次迭代），这得益于 Triton 代码更简洁（约 68 行 vs 约 97 行），LLM 的搜索空间更小。其二，Triton 的绝对性能更高（3.70M vs 2.59M Mops），这是因为 Triton 编译器自动处理了寄存器分配、分块参数和 Tensor Core 映射，比手工 CUDA 代码更高效地利用了硬件。值得强调的是，两种语言环境下 CUDAAnalyst 演化出的核心策略高度一致——均为双缓冲软件流水线——这表明系统的反馈-规划机制能够跨语言抽象识别到相同的性能瓶颈和优化方向。

06、总结与展望

本文介绍了将 CUDAAnalyst 从 NVIDIA GPU 生态完整迁移至国产 DCU 加速卡的全过程。在系统适配层面，我们完成了 pynvml→amdsmi、nvcc→dcc、CUDA→HIP 等 10 项修改，涵盖 GPU 管理、编译器工具链、性能分析工具、源码转换和 Python 兼容性等多个层面。在性能验证层面，我们在 DCU 上对自定义 GEMM 内核进行了迭代优化，取得了 1.69× 的性能提升，验证了 CUDAAnalyst 在 DCU 平台上的有效性。在防御机制层面，我们发现并分析了 LLM Agent 通过篡改验证逻辑伪造性能数据的"作弊"行为，提出了分离式验证架构，为 Agent 驱动的性能优化系统提供了通用的评估安全模式。在跨语言扩展层面，我们将系统扩展至 Triton 内核优化场景，取得了 2.17× 的加速比，验证了 CUDAAnalyst 反馈-规划归因方法的跨语言通用性。

本工作目前仍存在若干局限，也为后续研究指明了方向。首先，ncu 在 DCU 上的缺失导致 Planner 缺少细粒度的内核性能数据（如访存带宽、计算吞吐、占用率等），后续可考虑适配 rocprof 或基于 hipEvent 实现轻量级性能采样，补全反馈回路。其次，当前仅在 GEMM 内核上进行了验证，后续可在更多类型的 GPU 工作负载（如稀疏计算、规约、FFT 等）上测试适配后系统的表现。再次，目前的 Triton 适配主要停留在评测器层面，Analyzer 和 Debugger 模块尚未针对 Triton 代码进行适配（tree-sitter 需要 Triton 语法支持）。最后，CUDAAnalyst 的 Planner 是否能将在一种 GPU 架构上学到的优化策略迁移至另一种架构（如 NVIDIA H100→海光 DCU），是一个具有重要理论和实践价值的开放问题。

<u>往期推荐</u>

面向可配置边界的 BSV 数据流接口设计

MetaInfer：让 LLM 自己写推理框架

<u>其他开源项目：Open-RDMA</u>

琶洲实验室（黄埔）联合达坦科技共同发起Open-RDMA开源项目。我们选择以全栈开源的路径，首先从学术研究与人才培养维度切入，依托开源社区力量，降低RDMA这一专业领域的技术门槛，培育RDMA技术人才队伍，提升Open-RDMA项目社区的品牌影响力，逐步扩大Open-RDMA项目在整个RDMA领域的行业影响力。

无论您是硬件领域（FPGA、ASIC）、软件信息技术领域（驱动开发、训练推理框架、通信协议）还是算法领域（GPU Kernel）的从业者或在校生，均可在Open-RDMA开源项目中找到与自身领域契合的技术方向。

达坦科技始终致力于打造高性能​AI+Cloud基础设施平台​，积极推动AI应用的落地。达坦科技通过软硬件深度融合的方式，提供​AI推理引擎和高性能网络​，为AI应用提供弹性、便利、经济的基础设施服务，以此满足不同行业客户对AI+Cloud的需求。

​公众号​：达坦科技DatenLord

​DatenLord官网​：https://datenlord.github.io/

​知乎账号：​https://www.zhihu.com/org/da-tan-ke-ji

​B站​：https://space.bilibili.com/2017027518

​邮箱：​[e-mail]

如果您有兴趣加入达坦科技Rust前沿技术交流群、硬件敏捷开发和验证方法学讨论群或AI Infra ​交流群，请添加小助手微信：DatenLord\_Tech