论文：Agentic Auto-Scheduling — An Experimental Study of LLM-Guided Loop Optimization
作者：NYU Abu Dhabi | PACT 2025 | 解读：SuperOps
我最近在读 PACT 2025 的论文，NYU 阿布扎比分校的团队搞了个东西叫 COMPILOT，思路挺野的。
他们问了一个问题：能不能让大模型当编译器的「军师」，编译器当「工兵」，两个配合着把代码优化了？
背景写过 C/C++ 高性能计算的人都知道，循环嵌套是性能杀手。一个三重循环，你换一下顺序可能快 10 倍，加个分块可能再快 5 倍，但换错了直接慢成狗。编译器自带的 -O2、-O3 很多时候不够用，Pluto 这种顶级多面体优化器也经常翻车——它优化的是数学模型，不是真实执行时间。
NYU 这帮人的想法很简单：既然 LLM 能读代码、能推理、能从错误中学习，为什么不把它放进优化循环里？
做法先把循环嵌套代码扔给 LLM，让它分析结构。比如「这有个三层循环，最内层是做矩阵乘的，外层可以并行」。
然后 LLM 提一个优化方案。注意，不是让它直接写优化后的代码——那太容易出 bug 了。而是让它用一套预定义的变换命令，比如「把第 2 层和第 3 层交换，然后对第 1 层并行化，再加个 32×32 的分块」。
编译器拿到命令，先用依赖分析检查是否合法。合法就编译执行，测出实际加速比。然后把结果反馈给 LLM：「你上次的方案加速了 1.8 倍」或者「你这个方案非法，违反了数据依赖」。
LLM 看到反馈，调整策略，再提新方案。循环往复。
COMPILOT框架：LLM与编译器闭环交互
这个设计很关键：LLM 不碰代码生成。代码生成和正确性验证全部交给编译器。LLM 只负责高层策略——「交换这两层」、「并行化那一层」。论文里做了消融实验，直接让 LLM 写代码的方案，17.9% 的「通过」案例实际上有隐蔽 bug，输出比较根本查不出来。
效果PolyBench 全套基准，30 个程序 × 5 种数据规模。
单次运行平均加速 2.66 倍。跑 5 次取最佳，平均 3.54 倍。对比 Pluto 优化器，整体超越 2.94 倍。
最夸张的是 correlation_XLARGE，339 倍。LLM 自己摸索出了「激进并行化 + 分块 + 展开」的组合拳，把 48 个线程全部吃满。
也有翻车的。cholesky、ludcmp 几乎零提升，循环依赖太复杂，LLM 试来试去全是非法方案。
几个反直觉的发现第一，编程专用模型反而更差。他们测了 8 个模型，gemini-2.0-flash 和 gpt-4o 表现最好，codestral-2501（专门训来做代码生成的）垫底。这个任务需要的是「理解循环结构 + 提出变换策略」，不是写代码。
第二，推理模型没有明显优势。o3-mini、qwq 没跑赢普通模型。因为 COMPILOT 的反馈循环本身就在引导推理，不需要模型自带多强的推理能力。
第三，三分之二的提议是废的。LLM 提的方案只有 36% 能成功编译。31% 语法错误，33% 违反数据依赖。但好消息是——随着对话推进，非法比例明显下降，LLM 确实在从反馈中学习。
第四，给硬件信息没啥用。告诉 LLM「你用的是什么 CPU、多少核、多大缓存」，对最终性能没有统计显著影响。LLM 更依赖实测反馈来「感知」硬件，而不是从参数描述中推理。
代价呢？跑一次 30 轮迭代平均 8.9 分钟。大头不是 LLM 通信（只占 1-3 分钟），78.5% 的时间花在编译和执行上。
启示过去用 LLM 做代码优化，要么让它直接生成优化代码（容易出 bug），要么让它选编译器 flag（粒度太粗）。COMPILOT 走了第三条路：LLM 做策略，编译器做执行，实测性能做裁判。
不需要微调，不需要专用模型，现成的通用 LLM 就够了。
这事给我的启发挺大——LLM 不需要替代编译器，只需要引导编译器。
论文链接：https://arxiv.org/pdf/2511.00592
P.S. 代码没开源，不过思路完全可以复现。Tiramisu 编译器是开源的，LLM API 随便接一个就行。