很高兴这次能跟 DeepMind AlphaEvolve team 合作将 AI 里两个经典的范式 search 和 learning 推向更多领域。AlphaEvolve在去年五月发布的时候引起一阵轰动,那时更多还是关注在经典的数学算法问题上;而这次我们则是成功将其大规模应用到工程领域,让狗家的编译器开启自我进化之路。
编译器从计算机诞生的那一刻起就存在了,它将人类编写的高级语言转化为机器能够执行的低级语言,可以说是这个星球上最复杂的软件系统之一。编译器在 Google 属于非常核心的位置,也是 scaling 不可或缺的一环。因为采用 monorepo,所以所有程序都不可避免需要经过编译器优化,哪怕提升一点点效率,对整个集群的影响都是巨大的。
目前用有很多 LLM4Compiler 的工作,大致可以分为两个方向:一个是取代编译器,直接生成 kernel 代码如 CUDA/Triton;另一个则是去生成优化或者调度序列,典型例子如Autocomp,再借用编译器去实现这些优化的变换。因为我们还是针对大规模应用的优化,所以并不可能完全替代编译器,我们更倾向于选择后者保留原有编译器的存在。编译器的好处还在于能够保证转换代码的正确性,同时也能够相对比较 token-efficient 地生成程序。但是我们也不希望为每个应用都跑一次LLM生成序列,这太耗时也没有办法 scale,所以在这个项目中我们更想做的是去进化编译器本身。更具体地,我们希望去优化编译器里面的优化变换策略(pass),很多经典问题包括函数内联(function inlining)、寄存器分配(register allocation)等问题都是 NP-hard 的,大部分都是基于启发式算法来保证在合理时间内获得足够好的解。这些启发式规则凝结了专家数十年积累的工程直觉,用于权衡各种复杂决策,但这些手工启发式规则有着明显的局限性:它们难以适应快速演进的硬件架构,难以维护,且在面对庞大的、异构的现代软件生态时,往往捉襟见肘。
所以在这个工作中我们尝试去理解 LLM 能不能设计真正可用的启发式算法,并能够将其运用到现代的编译器之中。
Hongzheng Chen, Alexander Novikov, Ngân Vũ, Hanna Alam, Zhiru Zhang, Aiden Grossman, Mircea Trofin, Amir Yazdanbakhsh, “Magellan: Autonomous Discovery of Novel Compiler Optimization Heuristics with AlphaEvolve”, arXiv preprint arXiv:2601.21096, 2026.
我在 Google 的团队此前在机器学习与编译器交叉领域也有不少探索,最出名的工作是 MLGO,可以算是工业界第一个将神经网络大规模部署进编译器优化的团队。而利用机器学习进行编译器优化主要有两个方向:
所以在设计 Magellan 时,我们选择了一条不同的道路:直接进化编译器 Pass 本身的 C++ 实现代码。我们不想生成最终的目标代码,也不为每个程序寻找临时策略,而是合成紧凑、可部署、人类可读的启发式函数,这些函数可以像手写代码一样被插入编译器代码库,长期复用。这直接带来了几个关键优势:
Magellan 则是基于 AlphaEvolve 的进化搜索框架,在它基础上增加了额外的黑盒调优器(autotuner)。这里核心的想法是关注点分离:LLM 只需要关注高层 idea 的实现,而底层的参数调整则交给黑盒调优器。这主要注意到 LLM 其实对数字并不敏感,很多时候在算法里给出的超参数其实只是随机生成的,并没有实际意义,所以超参数的部分不如就交由外部工具来处理。Magellan 的核心是一个四阶段的自动化闭环:

EVOLVE-BLOCK注释标记的区域)进行修改。LLM 的任务是生成一个”启发式模板”——一段合法的C++代码,但其中的关键数值常数被替换为符号化的超参数(例如BASE_THRESHOLD)。这迫使LLM专注于高层的决策逻辑结构,而非具体的数字。这种”LLM 管代码结构,调优器管超参数”的分层策略是 Magellan 高效的关键。我们发现它极大提升了搜索效率,将无效代码率从 LLM 直接搜索时的超过65%降低到了结合调优器后的仅13%。
这是我接手的第一个问题,也是最开始 MLGO 尝试做的第一个问题。函数内联(function inlining)很好理解,就是把函数体直接插入到调用点,从而减少函数调用开销。但是内联有着大量的 tradeoff,比如内联一些小的函数可以利于后续优化如常量传递的进行,但把所有函数都内联的话会导致代码体积变得非常巨大,执行速度也非常慢,所以这是一个(被证明了的)NP-hard问题。我们在这个问题上的第一个目标是减小最终二进制文件大小,这是一个非常确定性的目标,没有额外的噪音,所以非常适合作为第一个问题来验证 Magellan 的性能。
为了更好地跟之前的方法进行比较,我们设计了两组不同的设置(参见下图):

我们让 Magellan 从零开始(一个始终拒绝内联的策略),以 Google 内部的搜索引擎作为测试程序,测试了两种不同设置下的结果(见下图)。对于部分启发式算法设置,Magellan 用了1.5天的自动搜索,就合成出了比 LLVM 上游手工启发式算法多减少4.27%代码体积的新规则;而让 LLM 生成完整启发式算法设置下,用同样的搜索时间,它可以最终减少5.23%代码体积。注意这里的基线程序已经是 LLVM 上游最好的启发式算法,并且开了-Oz进行优化。可以看到更加开放的搜索空间,可以给 LLM 更大的自由度去设计启发式算法,最终实现更好的效果。

另外一组试验则是进一步开启了调优器,可以看到它大大提升了 Magellan 的搜索效率,大概只需100个程序的采样评估,它就可以达到超过5%的内联体积缩小。
我们也对 LLM 生成的代码进行了分析:它极其简洁,仅143行核心逻辑,比LLVM原有的2000多行实现精简了15倍,但效果更好。其核心洞见在于:激进地内联”单次使用”的函数,使得调用点和整个函数体都可能在后继优化中消失;并为那些在内联后能触发大量死代码消除的函数提供奖励。

我们还测试了这份代码的泛化能力:我们将该规则应用到不同时间点快照的代码库以及十多个不同的生产级二进制程序(涵盖搜索、嵌入式等不同领域)上,其优化效果依然稳健,平均减少代码体积8.79%,与一个需要大量数据训练和集成的神经网络策略效果相当,且好处在于无需重新训练。
本来我们对 AlphaEvolve 能够优化编译器这件事情并没有报太大的期待,但是有了前面一个问题的成功案例,我们尝试将其运用在更加困难的问题上面。所以我们还是选择了函数内联,但是这次优化目标变成提升程序的运行性能。这是一个更具挑战性的任务,因为性能评估噪音更大、成本更高。

为了更快的迭代速度,在这个任务上我们选择直接优化 clang 编译器本身。我从暑假开始尝试了大量不同的设置,包括不同的 prompt 技巧、不同的 feedback、不同的初始程序、增加调优器的力度等等,但是最终都没有办法超越 LLVM 上游高度优化过的基线程序(开了ThinLTO和-O3优化,见上图)。
而真正的转机是11月底的时候 Gemini 3 对外发布,一开始我们也没有觉得模型提升会带来多大帮助,但我们低估了基模提升对整个领域的创造性改变。当我们把 Gemini-2.5-Pro 生成的最好程序喂给 Gemini-3-Pro 作为初始程序后,Gemini 3迭代了一夜,竟然发现了更好的内联算法,直接超过了 LLVM 开满优化的设置(这也是整个社区二十几年来维护的成果),最终达到0.61%的提升。虽然只是不到1%的性能提升,但是这是之前传统方法(包括使用神经网络)都从未达到过的突破。非常底层的通用优化、大规模数据集、非常强大的基线程序都说明这一点点提升的来之不易。
这条规则采用轻量级 cost model,智能地为常量参数、循环嵌套、向量化代码提供奖励,并为热点调用动态调整阈值,完整代码可以在论文中找到。
这个实验也说明即便是非常底层基础的科学和工程问题,在agentic时代依然有很大的机会能够获得提升。而新时代的摩尔定律或许是坐等新模型出来,之前的没解决的问题就能迎刃而解。
Magellan 的通用性在其他编译器优化任务上也得到了验证,因为生成的算法还未完全整合进 XLA 中,所以在这里不做过多的叙述:
后两个问题也可以在我们的 HeuriGym benchmark 里面找到。
Magellan 的工作标志着编译器自动化进程中的一个重要里程碑:
当然,挑战依然存在。每次候选规则的评估都需要重新编译编译器并运行大规模基准测试,计算成本不菲。如何为更复杂、噪音更大的优化目标(如多目标权衡、功耗)设计高效的搜索策略,仍是我们需要探索的开放问题。展望未来,我们相信 Magellan 有望成为一个通用的”编译器自我进化的平台”:
这项工作其实也不仅仅关于编译器,它更是一份关于如何利用 LLM 自动化那些高度复杂、基于知识的工程设计蓝图。当机器开始学会编写优化它自身工具的规则时,我们正步入一个软件系统自我进化时代的前夜。
特别感谢我的 cohost Mircea 和 Amir 对这个 project 的极力推动并在内部广泛宣传,让 AlphaEvolve 以及我们的工作都能在更多的场景下落地。这个工作我在内部讲过不下五次,某种程度上也是让大家看到 agent 对自身工作流程的改变。在现在这种 AI 军备竞赛的环境下在公司里发 paper 已经成了一种非常奢侈的事情,因此我也要感谢 Google 很多很多同事对这个 project 的支持,最后才得以让这个工作这么快发布。在 Google 的半年时间是我这几段实习里非常快乐并且享受的一段,希望之后有机会还会再回来!