论文解读：LLM 不直接改代码，也能让步伐跑快 3 倍？

本日这篇论文「[Agentic Auto-Scheduling: An Experimenta l Study of LLM-Guided Loop Optim ization」讲的是一个很详细的标题：LLM 能不能到场编译器优化，让步伐跑得更快？
这里的 Loop，指的是步伐里的循环结构，比如 for / while 循环，尤其是科学盘算、图像处置惩罚、呆板学习算子里常见的多层嵌套循环。论文提出了一个名为 COMPILOT 的实行框架，把现有 LLM 和编译器放进同一个优化闭环里：LLM 先提出循环结构的变动方案，编译器再查抄方案是否正当、可否编译，并实际运行代码，判定性能是提升还是降落。随后，体系把查抄和测速效果反馈给 LLM，让它继续调解下一轮方案。
LLM 和编译器的分工

在 COMPILOT 的设定中，LLM 并不直接改写完备代码。它输出的是一组面向编译器的优化指令，比如循环融合、循环交换、并行化、二维/三维 tiling、循环睁开（unrolling）、循环偏斜（skewing）等。而真正实行变动、做依赖分析、天生代码和测速的部分，仍然是编译器体系。

图 1：Fig. 1，COMPILOT 框架总览
这张架构图可以按从左到右的序次明确。
左侧是输入步伐、编译 / 运行情况，以及终极天生的优化后步伐。输入代码先辈入 COMPILOT，中心的 Context Initializer 会把任务分析、目标循环代码、可用变动、输特别式等信息整理成上下文，发送给右侧的 LLM Agent。
LLM Agent 根据这些上下文天生下一轮 schedule，也就是循环结构的变动方案。它的输出会回到中心的 Interaction Loop Handler，由 Response Parser 分析成编译器能实行的指令。
接下来，左侧的编译 / 运行情况会实行实行这些变动，查抄是否正当、可否编译，并实际运行代码得到性能效果。中心的 Feedback Generator 再把格式错误、非法变动、编译失败、运行时间厘革等信息整理成反馈，继续发给 LLM，举行下一轮优化。
如上所述，LLM 站在“提出候选方案”的位置上；编译器和运行情况负责验证、实行和测速；COMPILOT 中心这层负责把双方毗连起来，让这个过程可以反复迭代。
从多层循环到调理搜索

这篇论文关注的是 loop nest optimization，也就是多层循环结构的优化。
在科学盘算、图像处置惩罚、呆板学习底层算子里，性能瓶颈每每出现在这类循环结构上。多层循环怎么嵌套、哪个维度先跑、要不要分块、能不能并行，都会影响缓存掷中、线程利用率和终极运行时间。
这类优化难在搜索空间很大。同一段循环代码，可以有很多种变动方式；同一种变动，也大概由于参数、序次、硬件情况和输入规模差别，带来完全差别的性能效果。编译器按预设规则主动选择时，未必总能选到符合效果。
COMPILOT 要测试的，就是能不能让 LLM 在这个空间中充当“调理方案天生器”。它会根据目标循环代码提出一组 schedule，也就是循环结构的变动方案。每一组 schedule 都可以明确成一次候选实行：这次先交换循环序次，还是先做分块；并行化放在哪一层；tiling 参数该怎么选。
为了让模子进入这个任务，体系会把输入循环、可用变动、输特别式、硬件信息和错误处置惩罚规则整理成 prompt。接下来，模子会先读懂目标循环结构，再给出后续的 schedule 候选。

图 2：Fig. 2 展示体系 prompt 结构

图 3：Fig. 3 展示输入给 LLM 的循环代码

图 4：Fig. 4 展示 LLM 对循环的分析
如许看，COMPILOT 做的事变并不秘密：它把多层循环优化拆成一轮轮候选 schedule 的搜索。LLM 负责提出下一次实行，编译器和运行情况负责判定这次实行能不能建立、跑起来有没有更快。
3 倍加快是怎么测出来的

论文在 PolyBench/C 上做性能测试。它是编译器优化研究里常用的一组 C 语言基准步伐，包罗矩阵盘算、线性代数、stencil 等循环麋集型 kernel，适实用来测试多层循环优化效果。
这个基准包罗 30 个 benchmark，论文利用 5 种尺度数据规模，以是一共是 150 个 benchmark instance。本次论文的重要实行硬件是一台双路 Intel Xeon E5-2695 v2 呆板，总计 48 个线程，128 GB 内存。编译器侧，利用的是 Tiramisu。
这篇论文默认利用 Gemini-2.0-flash 作为重要 LLM，并在每个实例上运行多次，统计中位数加快，再用多少匀称聚合团体效果。
论文实行里最焦点的两个数字，是 2.66× 和 3.54×。
在单次运行设置下，也就是每个步伐最多迭代 30 轮优化，COMPILOT@30 相比原始代码到达 2.66× 多少匀称加快。如果答应同一个步伐独立运行 5 次，再从 5 次效果里选择最快的一次，也就是 best-of-5 设置，COMPILOT_5@30 的多少匀称加快到达 3.54×。
以是，标题里的“跑快 3 倍”须要带上实行条件：这是在 PolyBench/C 这组循环麋集型基准上，按照论文统计方式得到的汇总效果。单次运行靠近 3 倍，best-of-5 凌驾 3 倍。

图 5：Fig. 7 COMPILOT@30 在差别 benchmark 和差别输入规模上的加快效果。
如上图所示，从分布上看，这个加快并不匀称。有些 benchmark 险些没有提升，有些在 LARGE / XLARGE 这类数据规模下提升显着。这里的数据规模，指的是同一个步伐处置惩罚的矩阵、数组或循环迭代范围更大。数据变大后，并行化和 tiling 这类优化更容易摊开开销、改善缓存访问，因此收益也更容易显现。比如 correlation_XLARGE、trmm_XLARGE 等案例里，COMPILOT 找到的 schedule 带来了很高的加快。
以是，这里的 3 倍加快更得当明确为一个受控实行效果：在循环麋集型 benchmark 上，LLM 可以资助编译器搜索更好的 schedule。它不能直接推到平凡业务代码上。
更可控的代码优化

这篇论文比力值得注意的一点，是它没有让 LLM 直接天生优化后的 C 代码。
由于直接改代码有一个风险：LLM 大概会写出能编译、乃至能通过一部分测试的代码，但着实它的语义已经被改坏了。对于循环优化来说，这个标题会更敏感，由于很多变动涉及数据依赖关系。看起来只是调解循环序次，实际大概影响读写序次。
COMPILOT 的做法相对守旧。LLM 输出的是结构化的编译器变动下令，编译器再通过依赖分析判定这些变动是否正当。如许可以把 LLM 的自由度限定在一个更可控的动作空间里。
论文还做了一个对照实行：让 LLM 直接天生变动后的 C 代码。效果表现，这种方式的多少匀称加快比尺度 COMPILOT 低约 14% 到 16%。不但云云，一部分初看通过的代码在二次查抄中暴袒露错误输出或非法变动标题。论文还提到，直接天生完备代码会显着增长 token 斲丧，由于输出完备代码比输出简短的变动下令更贵。
多轮反馈带来的差别

COMPILOT 不是只让 LLM 猜一次。每一轮竣事后，体系都会把效果反馈给 LLM：这次 schedule 是格式错误、违背依赖、编译失败，还是乐成运行；如果乐成运行，速率提升了多少。
论文做了一个去掉反馈的溶解实行。没有反馈时，LLM 只能连续基于本身的判定提出 schedule。效果在 T=30 时，尺度 COMPILOT 的单次运行加快是 2.66×，无反馈版本是 2.01×；best-of-5 场景下，尺度版本也显着更高。
这分析反馈本身是体系能工作的关键部分。LLM 会犯错，尤其是在复杂循环依赖关系上。但只要编译器能把错误范例和性能效果举行反馈，LLM 就有时机在后续轮次里避开一些失败模式，继续探索新的组合。

图 6：Fig. 10 展示差别 benchmark 中 runnable / invalid / illegal schedule 的比例
这个效果也提示我们，COMPILOT 并没有让 LLM 酿成一个可靠的编译器专家。根据论文统计，在 30 轮对话范围内，LLM 提出的 schedule 中只有约 36.1% 能终极乐成编译并运行，31.4% 是 invalid，32.5% 是 illegal。看得出来，大量候选方案着实是会失败，只是失败被编译器拦住，并转化成下一轮反馈了。
COMPILOT vs Pluto

论文还把 COMPILOT 和 Pluto 如许的 polyhedral optimizer 做了比力。
在 best-of-5、每次 30 轮的设置下，COMPILOT_5@30 相比 Pluto 优化后的代码到达 2.94× 多少匀称加快。按论文统计，在 150 个 PolyBench instance 中，COMPILOT 优于 Pluto 的有 119 个，差距在 5% 以内的有 9 个，低于 Pluto 的有 22 个。
这里也须要看实行条件。论文分析以为，COMPILOT 的一部分上风来自实测反馈：如果某个优化方案实际运行后变慢，COMPILOT 有时机在后续迭代中避开它；而 Pluto 这类传统优化器更多依赖静态模子和预设规则，通常不会根据真实运行效果一轮轮调解。
论文也做了一个 “capped Pluto” 对照：如果 Pluto 的优化导致变慢，就退回原始代码。如许一来，COMPILOT 相对 Pluto 的团体上风从 2.94× 降到 1.78×。这个对照分析，COMPILOT 的一部分上风来自实测反馈：当某个优化方案实际跑起来变慢时，体系有时机在后续迭代中避开它；另一部分上风则来自它确实搜索到了更好的 schedule。

图 7：Fig. 11，COMPILOT_5@30 与 Pluto 的对比。红线表现与 Pluto 持平，高于红线表现 COMPILOT_5@30 更快，低于红线表现 Pluto 更快。
差别模子的表现差别

论文还比力了多个 LLM 在同一套流程里的表现，包罗 gemini-2.0-flash、gpt-4o、llama3.3、gpt-o3-mini、qwq、qwen2.5-coder、codestral 等。
从效果看，模子之间确实有差别，但差别不完全由“是不是推理模子”或“是不是代码模子”决定。gemini-2.0-flash、gpt-4o、gpt-o3-mini 的表现比力靠近；推理模子没有稳固压过非推理模子；专门面向代码的模子，在这个任务里也没有表现出显着上风。
这和 COMPILOT 的任务情势有关。模子须要服从固定输特别式，明确循环结构，提出高层变动下令，还要根据编译器反馈继续调解。它查验的不但是代码天生本领，还包罗结构化输出、规则服从和多轮反馈利用。

图 8：Table I，差别 LLM 在差别迭代次数下的 COMPILOT@T 多少匀称加快
界限与实用场景

团体来看，这篇论文的重点不在于证明 LLM 可以主动改好全部代码，而是把标题收在一个更详细的范围里：循环麋集型代码、编译器可验证的变动空间、多轮实测反馈。
在这个范围内，COMPILOT 展示了一种比力清晰的思绪：让 LLM 负责提出 schedule，让编译器负责验证、实行和测速。效果来自这个闭环，而不是模子一次性天生一段更快的代码。
以是，这篇论文更得当看作一个有界限的编译优化实行。它不能直接推到平凡业务代码上，但对于已有编译器底子办法、又须要反复调理搜索的性能优化场景，提供了一个值得参考的样本。
论文文献

• Agentic Auto-Scheduling: An Experimental Study of LLM-Guided Loop Optimization arxiv.org/pdf/2511.00592