范围：Triton / TileLang 两类 Python DSL，对已有 kernel 做结构级优化（算子融合、流水线、tiling/布局策略）。不含 CUDA 底层扩展，不含从 PyTorch 出发生成。 结论先行：Agent 已能对结构清晰、参考实现明确的算子稳定拿到 2-5x 加速；量化与复杂融合仍未解决（量化 0/30、融合 72% 任务全方法失败）；论文报告的问题集中在数值契约误解与融合全局协调，两者都不是语法层问题。

场景与核心问题

拿到一个 Triton 或 TileLang kernel，它跑得不够快。想优化的不只是把 block size 从 128 改成 256——那是 autotuner 的活（TileLang 内置 autotuner 和 Carver 已覆盖参数级搜索，不需要 Agent）。真正值得 Agent 做的是结构级改动：把两个算子融合成一个 kernel、换流水线深度、改 tiling 和布局策略。

核心问题：让 Agent 对 DSL 算子做结构级优化，现在能做到什么程度？哪些算子能优化，哪些不能，不能的卡在哪？

现状与难点

现状分三层：参数级搜索由 autotuner 覆盖（成熟）；结构级改动目前靠人工或 Agent 循环（正在探索）；把优化能力写进模型权重（训练路线，早期）。本报告聚焦后两层。

难点集中出现在两类任务上，先讲清楚这两类任务本身。

量化 kernel：难在数值契约

量化 kernel 指把计算放在低精度（int8/fp16/bf16）下完成，需要手动实现量化逻辑。KernelBenchX 的定义：W8A8 和 W4A16 设置下，实现 scale 计算、显式 casting 和反量化，不允许依赖高层 API（arXiv 2605.04956）。验证同时要求三个指标达标：cosine similarity ≥ 0.90-0.95、L1 相对误差 ≤ 0.05-0.10、RMSE ≤ 0.10-0.15。

难点不是语法：KernelBenchX 统计里量化类任务的编译通过率 41.7%，不低。但正确率 0/30，Correct/Compile = 0.0%。论文原文的归因：“systematic misunderstanding of numerical computation contracts rather than surface-level syntax errors”——模型系统性误解数值计算契约（scale 怎么算、何时 casting、累积用什么精度、反量化时机），而不是表层写错。

融合 kernel：难在全局协调

融合 kernel 指把多个算子合成一个 kernel（比如 exp + mean 合成 fused_exp_mean），省掉中间结果的显存读写和 kernel 启动开销。KernelBenchX 的统计：融合类编译通过率 43.8%，但正确率只有 10.8%（Correct/Compile 24.8%）；72% 的 Fusion 任务在全部 5 种方法下都失败。

难点不是单个片段写错。KernelBenchX 给出了一个具体案例（fused_exp_mean）：GEAK 生成的 kernel 能编译，但数值错。代码每个局部片段单独看都是对的——带 mask 的 load、exp、按轴求和、atomic_add——但组合起来错：padding 用 other=0.0 填充，经过 exp 后变成 1，污染了全局归约的结果。论文原话：“The failure is not a syntax error, but a subtle interaction among padding semantics, a nonlinear transform, and a global reduction.” 每个局部 idiom 都对，错在跨算子的全局语义。

路线调研

A. 评测与归因：问题是怎么被定义和量化的

KernelBench（arXiv 2502.10517，ICML'25）定义了问题：250 个 PyTorch 到 kernel 的任务（L1 单算子 100 / L2 融合 100 / L3 全模型 50），用 fast_p 指标（正确且加速比超过 p 才算通过）。数据：前沿模型零样本匹配 PyTorch baseline 的不到 20%；100 个生成 kernel 中 50 正确、17 编译错误、10 运行时错误、19 值不匹配、4 shape 不匹配。迭代 10 轮后 L1/L2 正确率能到 90%+，剩余失败几乎全是功能不正确——原文：“correctness feedback is less granular than execution failure messages”（正确性反馈比编译报错粒度粗）。

KernelBenchX（arXiv 2605.04956）做了失败归因：176 任务 x 15 类 x 5 方法，统一评测管线 + 两阶段正确性协议（防输出比较偶然通过）+ 多精度（fp16/bf16/int8）和量化任务扩展。三大发现：

  • 任务结构比方法更能解释正确性：类别解释方差 9.4% vs 方法 3.3%——失败主要由任务结构决定，不是方法不够好
  • 迭代细化只救正确率不救性能：GEAK 迭代编译率 52.3%→68.8%，但平均加速比 1.58x→1.44x，新救回的 kernel 弱于持续正确的（1.16x vs 1.58x）
  • 正确不等于快：46.6% 的正确 kernel 比 PyTorch eager 慢，跨硬件加速比方差 21.4x

它还检验了“失败是不是代码复杂度问题”：静态复杂度指标（中间变量数、融合调用数）与语义失败仅弱相关（r≈0.21/0.15），且更能预测编译失败而非语义失败。论文收尾判断：“Prompt engineering and iterative refinement are well-suited to compilability but structurally insufficient for the rest. Progress will likely require mechanisms for reasoning about global tensor contracts and parallel reduction semantics, training signals that reward numerical fidelity rather than surface resemblance”——提示工程和迭代细化只能解决“能编译”，解决不了“数值对”，需要推理全局张量契约和并行归约语义的能力。

KernelBench-Verified（arXiv 2607.16241）指出评测被 reward hacking 污染：模型硬编码绕过特定张量值、利用 TF32 基线低估。换真实基线 + 四分布隐藏测试后，GPT-5.5 从标准协议 1.43x 掉到 0.88x——没有任何模型在真实基线下稳定超过 PyTorch。28% 的生成 kernel 增加峰值显存。

The Correctness Illusion（arXiv 2606.20128）说明标准评测太弱：固定 shape 小样本 allclose 会把转写错误判为正确。24 个 kernel 语料中 9/9 有意的 buggy kernel 通过标准测试（softmax 尾块 mask 处理错、matmul 用 acc= 覆盖累加、attention 漏 1/√D scale、flash-attention 在 max 更新后漏 acc*alpha 重缩放——这些 bug 只在特定 shape 下暴露）。26-op 语料在 5 类 GPU 上复现：10/10 illusion 被抓、16/16 对照通过。

TritonBench（arXiv 2502.14752）定义了 Triton 专属评测：184 个真实 GitHub 算子（G 通道）+ 166 个 PyTorch 接口对齐算子（T 通道）。动机原文：LLM 生成 Triton 代码“lack awareness of its specifications and the complexities of GPU programming”——SOTA 代码模型生成高效 Triton 算子仍困难。

B. Agent 路线（不改权重，推理时循环优化）

AutoKernel（arXiv 2603.21331）把 autoresearch 循环用于 kernel：profiling 找瓶颈 → Amdahl 定律排序 → 迭代改 Triton/CUDA C++ → 五阶段验证（smoke / shape sweep / 数值稳定 / 确定性 / 边界）→ 每个实验绑定 git commit。数据：H100 上 RMSNorm 5.29x、softmax 2.82x、cross-entropy 2.21x over PyTorch eager，多数配置也超 torch.compile max-autotune。

PRAGMA（arXiv 2511.06345）解决反馈粒度问题：现有系统只有正确性和时间反馈，“lacking the ability to reason about low-level performance bottlenecks”。做法：profiling 模块把细粒度硬件指标解析成自然语言建议。数据：CPU 2.81x / GPU 2.30x over Torch，始终优于不带 profiling 的基线。

KernelSkill（arXiv 2603.10085）解决隐式启发式低效：“opaque, implicitly learned heuristics… leads to inefficient trial-and-error and weakly interpretable optimizations”。做法：双级记忆——长期记忆存可复用专家 skill，短期记忆防重复回溯。数据：KernelBench L1-L3 100% 成功率，平均加速 5.44x / 2.82x / 1.92x over Torch Eager。

STARK（arXiv 2510.16996）解决单 agent 全包不可靠：Plan-Code-Debug 三段分工 + 树状搜索。数据：KernelBench 上基线失败的任务它能产出正确解，最高 16x 运行加速。

KernelFoundry（arXiv 2603.12440）解决搜索多样性：多数方法“simple prompting and feedback loops, incorporating hardware awareness only indirectly”。做法：MAP-Elites 质量多样性搜索（同时保留多种优化策略）+ meta-prompt 与 kernel 共同进化 + 模板参数优化。数据：KernelBench 上 SYCL 平均加速 2.3x。

GEAK（GitHub，AMD 官方）是目前唯一明确列出 TileLang 生成路径的 agent 系统：多 agent（generator/reflector/evaluator/optimizer）+ 演化知识库，覆盖 Triton / FlyDSL / TileLang / HIP。README 未给单 kernel 数字（论文 arXiv 2507.23194 有 benchmark，待补）。

QiMeng-Attention（综述 arXiv 2601.15727 4.3 节）是融合算子的正面案例：把目标 GPU 架构和指令集注入 prompt，把高层思考语言转成低层 CUDA，在多个 GPU 上生成 FlashAttention（FlashAttention 本身就是 softmax 与 matmul 融合的算子）。具体数字待补（未精读原文）。

C. 训练路线（把优化能力写进模型权重）

AutoTriton（arXiv 2507.05687）动机：DSL 简化编程但“developers must still manually tune critical parameters such as tile sizes and memory access patterns through iterative experimentation”。做法：SFT（高质量数据管线）+ GRPO（规则 reward + 执行 reward 结合）。数据：8B 模型在 TritonBench/KernelBench 五通道达到与 Claude-4-Sonnet、DeepSeek-R1-0528 相当的水平。

TritonRL（arXiv 2510.17891）动机：Triton 数据稀缺（ICLR/OpenReview 投稿版摘要：“CUDA benefits from abundant programming data, high-performance Triton kernels are scarce and typically require costly crawling or manual authoring”；arXiv v2 表述为 “CUDA benefits from decades of development and abundant training data”）+ 评测不成熟 + reward hacking 风险。做法：KernelBook 数据 + DeepSeek 蒸馏 + Qwen3-8B SFT，分层 reward 分解 + 显式检测 hacking。数据：KernelBench 正确率和加速比 SOTA，超越其他 Triton 专用模型。

Kernel-Smith（arXiv 2603.28342）动机：“current LLM-based approaches still struggle to sustain reliable optimization beyond one-shot code generation”。做法：评测驱动的进化 agent + 面向进化的 post-training 配方。数据：KernelBench L1 fast_1 70%（综述口径）。

CUDA Agent（arXiv 2602.24286）动机：agentic RL 训 kernel 需要可靠 reward 信号并防作弊。做法：可扩展数据合成 + skill 增强环境（验证/profiling 脚本权限锁死防 reward hacking）+ 多阶段 warm-up 稳定训练。数据：KernelBench L1/L2/L3 对 torch.compile 的 faster rate 100% / 100% / 92%；训练 150 步、150 turns/样本、128 张 H20 沙箱池。

调研结论

能优化到什么程度

  • 能优化的：结构清晰、参考实现明确、模型见过大量同类代码的算子——GEMM、softmax、RMSNorm、attention 类。Agent 循环能发现结构级改动（融合、流水线、tiling），AutoKernel 在 Triton 上过夜跑出 2-5x，KernelSkill 用双级记忆在 KernelBench L1-L3 全部正确并平均加速 1.9-5.4x。
  • 不能优化的：量化类（KernelBenchX：0/30 全失败）和复杂融合类（72% 任务全方法失败、正确率 10.8%）。

不能优化的原因

  • 量化 = 数值契约误解：编译率 41.7% 不低，正确率 0——模型对 scale 计算、casting 时机、累积精度、反量化的数学语义系统性理解错，代码“看起来对”但数值上错（KernelBenchX）。
  • 融合 = 全局协调失败：每个局部片段单独都对（load/exp/sum/atomic_add），组合起来错——padding 语义、非线性变换、全局归约三者交互，模型没有跨算子的全局视野（KernelBenchX 的 fused_exp_mean 案例）。
  • 共同点：这两类失败都不是语法层问题，编译都能过；失败集中在“数值对不对”这一层，而正确性反馈恰好不指向错误位置（KernelBench：“correctness feedback is less granular”）。
  • 次要问题：评测脆弱（Correctness Illusion 的 9/9、KernelBench-Verified 的 1.43x→0.88x）让“通过”不等于“真的对真的快”；反馈粒度（PRAGMA 的动机）让“慢”不指向“哪慢”。

边界与下一步

边界：只覆盖 Triton/TileLang 的已有 kernel 结构级优化；不含 CUDA 底层扩展、不含从 PyTorch 出发生成（QiMeng-Attention 仅作为融合算子的正面证据引用）、不含昇腾等非 NVIDIA/AMD 平台。评测问题只在影响结论可信度时涉及，不展开评测方法学。GEAK 与 QiMeng-Attention 的具体数字未精读原文，标注待补。

下一步（针对结论中的两类核心问题）：

  1. 数值契约误解 → 验证层先行加固：shape 扫描 + fp64 高精度参考 + 多分布隐藏测试（KernelBench-Verified 和 Correctness Illusion 已给出做法），让“通过”可信，再谈优化。
  2. 融合全局协调 → 反馈层补定位能力：profiling 语义化（PRAGMA 思路）+ 正确性失败定位（哪个 tile/循环错），让模型知道错在哪；融合是最难的一类，先单算子闭环跑通再扩展。
  3. 知识覆盖 → 知识注入：硬件规格 RAG + 同类算子最优 kernel 做 few-shot（QiMeng 思路），给模型“代码之外的知识”；进化搜索 + 防回溯记忆（KernelFoundry/KernelSkill）补搜索效率。