摘要：
Linux内核开发者Lorenzo Stoakes提交了一组由23个补丁组成的构建优化方案。公开测试显示，在不同配置和构建状态下，allmodconfig完整构建最多加速约36%，增量构建最多约70%，无实际变更的noop构建最多约90%。更引人关注的是工作方法：开发者利用大语言模型帮助定位瓶颈、提出候选改进并生成初始代码，但明确表示模型产出的相当一部分代码质量不佳，最终经过大量人工审计、重写和基准验证。这个案例的价值不在于证明模型可以替代内核开发者，而在于展示AI如何把长期缺少人力关注的“工程摩擦”变成可系统搜索、可量化验证的优化对象。
为什么编译Linux内核仍然值得优化
在云端算力充足的今天，缩短几分钟构建时间看似不是最性感的技术突破，但内核开发的真实成本由大量重复构建累积而成。开发者修改一个子系统后，要在不同架构、不同编译器、不同配置和不同警告级别下验证；维护者需要持续集成测试大量补丁组合；发行版和硬件厂商还要构建通用内核、调试内核、实时内核与定制版本。一次完整构建节省10%，乘以数千名开发者和每日数万次流水线，就是显著的算力、电力与等待时间。
构建速度还影响迭代方式。反馈越慢，开发者越倾向于一次积累较多改动再测试，出错后定位范围更大；反馈越快，越容易形成“小改动—快速验证—立即修正”的循环。noop构建尤其值得注意：理论上源代码没有变化时，构建系统应迅速确认无需工作，但复杂依赖检查、特性探测和元数据处理仍可能消耗时间。若noop场景加速接近90%，说明大量日常等待并非编译器真正生成机器码，而是构建系统在重复确认已经知道的事实。
Linux内核的构建链条经过数十年演化，包含Kbuild规则、编译器探测、依赖生成、模块处理、符号表生成、链接和镜像封装。每一个环节单看都有历史理由，组合后却可能产生重复I/O、多余排序、大型中间文件和按字节执行的低效算法。传统性能工程的难点，是很少有人同时理解所有环节；修改构建系统又风险很高，因为一个只在小众架构或特殊配置下触发的错误，可能比节省的时间更昂贵。
23个补丁到底在优化什么
Horizon汇总提到的第一组改动集中在kallsyms。内核需要保存大量符号名称，用于调试、堆栈解析和部分运行时功能。符号数量可能超过十五万，为减少体积，kallsyms使用面向高频子串的压缩策略。旧流程在寻找替换机会时会做大量尝试，新方案记录特定token出现在哪些符号中，只在可能成功的位置执行替换。这个思路本质上是建立倒排索引：先花较小成本维护“候选位置”，再避免对完整集合进行重复扫描。公开数据称其可带来约2%至6%的改进。
另一项显著改动，是避免生成体积可达数十兆字节的汇编文本，再让汇编器把文本解析回二进制对象。文本汇编是便于传统工具链衔接的中间表示，却会产生格式化、写盘、读盘、词法分析和重新编码的成本。如果生成程序已经掌握最终数据布局，直接输出汇编器或链接器可用的二进制形式，就能跳过“二进制信息变成文本、文本再变回二进制”的往返。Horizon记录的最好情况提升约11%，Linus Torvalds则进一步建议直接输出ELF对象，把优化推得更彻底。
补丁还涉及关闭不必要的nm排序、减少中间链接阶段的重定位数据、用kallsyms直接读取ELF以替代mksysmap中的文本处理流程、缓存编译器能力探测结果、减少不需要的.modinfo分配、缓存对象是否属于模块的信息，以及优化modpost哈希计算。这些变化没有一个看起来像宏大的算法革命，它们更像多年沉积在构建链里的小摩擦。正是这种“每处节省一点”的组合，最终在增量和noop构建中产生非常醒目的结果。
depcheck工具则指向依赖检查这一核心问题。构建系统必须知道哪些目标因源文件、头文件、配置或工具变化而需要重建。检查过少会留下陈旧产物，检查过多则会反复扫描海量文件。高效做法通常需要缓存、内容摘要、时间戳、依赖图与规则语义之间的平衡。内核构建系统历史悠久，一些检查可能是为早期工具限制而存在；当现代编译器和文件系统行为已经变化时，旧机制仍在每次构建中付费。Torvalds提出某些陈旧检查也许可以直接删除，反映出性能优化常常不是“把旧步骤写得更快”，而是重新证明它是否还有存在必要。
LLM在这个过程中真正做了什么
从开发者说明看，LLM首先扮演了搜索助手。面对陌生而庞大的构建系统，人类可以让模型解释文件关系、列出可能重复的工作、生成分析脚本或提出替代实现。模型阅读代码的速度快，能够在多个目录和工具之间建立初步联系，这降低了进入历史代码的门槛。它还可以快速生成多个候选补丁，使开发者不用从空白文件开始，而把精力集中在判断和测量上。
但候选代码不等于可合并代码。Stoakes直言模型生成了大量“很丑”的代码，随后自己做了大量审计与重写，并重写提交信息、封面信和注释。这一点极其关键。内核代码需要满足的不只是当前测试通过，还包括跨架构正确性、工具链兼容、可维护性、风格一致性、错误处理、性能回归控制和长期语义稳定。模型容易给出局部看似有效的实现，却不了解某段怪异代码背后的兼容历史；也可能通过缓存提速，却遗漏缓存失效条件，制造难以复现的错误。
因此，这项工作更接近“AI扩大探索宽度，人类收紧证据标准”。模型帮助快速提出假设，性能剖析和基准测试淘汰无效假设，资深开发者检查语义与边界，邮件列表评审再从维护视角挑战设计。最终成果的可信度来自验证链，而不是来自模型身份。若只保留“LLM帮助内核提速90%”这个标题，就会错过案例最有价值的部分：模型输出质量并不稳定，恰当的人机流程却能把不稳定输出转化为可靠工程改进。
如何证明一次构建优化真的有效
性能数字最容易制造误解。完整构建、增量构建和noop构建的瓶颈不同；allmodconfig打开大量模块，与发行版常用配置也不同；高速服务器、开发者笔记本和共享CI环境的I/O、CPU核心数、内存和缓存状态各不相同。一个优化在热缓存下节省解析时间，在冷缓存下可能被磁盘访问掩盖；在32核机器上减少串行阶段价值很大，在低核设备上表现又可能变化。
严谨评估至少需要明确硬件、内核配置、编译器版本、并行参数、缓存状态和测量次数。单次最快结果不能代表稳定收益，应报告中位数、波动范围和异常值。补丁系列还应逐项测量，防止多个改动之间相互抵消或某个补丁实际造成回退。更重要的是正确性验证：不同架构交叉编译、不同链接器、模块装载、符号解析、调试工具和可复现构建都需要覆盖。构建结果更快但二进制内容发生非预期变化，不能算成功。
对于缓存类优化，必须设计失效测试。例如更换编译器、修改配置、移动源码目录、改变环境变量、更新生成工具或只调整一个间接头文件时，系统是否会正确重建？构建系统最危险的错误不是明确失败，而是错误地告诉开发者“一切都是最新的”。这种陈旧产物可能让测试基于旧代码通过，直到发布后才暴露。因此，noop加速越大，越要证明它没有省略必要检查。
能源与成本也可以成为第二组指标。大型开源项目和企业CI每天执行海量构建，CPU时间下降意味着云账单和碳排放下降。若优化进入主线，它的收益会在全球开发基础设施上长期累积。相较于一次性的模型训练演示，这类“小百分比、超大规模、长期复用”的改进，可能产生更实际的经济价值。
这为AI编程评测提供了新方向
现有编码模型基准大量使用独立题目或修复单个Issue，容易鼓励模型生成短期可通过测试的补丁。内核构建优化案例展示了更接近真实工程的评测维度：模型能否理解跨文件系统，能否提出可测量假设，能否识别不再需要的历史步骤，能否在性能、兼容性和维护成本之间权衡，以及能否根据评审意见持续修订。
一个更好的“AI系统工程基准”应包含性能剖析、补丁生成、基准设计、回归分析和解释文档。模型不仅要交代码，还要说明测量条件、潜在风险、缓存失效逻辑和替代方案。测试集应包含隐藏架构与工具链，防止模型只针对公开环境过拟合。最终评分也不能只看速度，而应把正确性作为硬门槛，把代码复杂度、可维护性和评审通过率纳入评价。
这类任务适合多智能体，但需要明确角色。有的智能体负责阅读构建日志和火焰图，有的负责查找历史提交，有的生成候选实现，有的专门反驳缓存假设，还有的构造回归测试。人类维护者位于决策闭环中，控制目标、接受标准与合并权限。相比让一群智能体直接向公共仓库提交海量补丁，这种受控分工更能提高信噪比。
企业软件团队可以如何复制这种方法
企业不必等待模型具备“资深架构师水平”才开始受益。大量遗留系统都存在类似的工程摩擦：构建缓慢、测试重复、依赖扫描低效、日志解析耗时、数据转换来回落盘、相同特性在每次启动时重新探测。可以先选择有明确指标、可自动验证、失败可回滚的优化任务，让AI帮助扩展候选空间。
推荐流程是先建立基线，再让模型参与。没有基线，模型很容易把偶然波动当成成果。团队应保存构建时间分布、CPU与I/O占用、缓存命中率、关键阶段耗时和失败率。随后让模型阅读剖析数据与代码，输出“瓶颈假设—预计收益—风险—验证方法”，而不是直接要求“把系统提速30%”。候选补丁进入隔离分支，由自动测试和基准流水线筛选，最后由熟悉系统历史的人审阅。
对工业软件而言，这种方法尤其适合求解器前后处理、模型转换、网格缓存、批量仿真调度、CAD格式导入和报告生成。很多工业软件的核心算法很难轻易替换，但外围流程存在大量可优化等待。AI不需要理解全部物理理论，也可以帮助发现同一模型被重复解析、相同材料参数被重复加载、结果文件多次转换等问题。只要把数值一致性和工程约束设为硬门槛，就能把风险控制在可接受范围。
不要忽视维护成本
性能补丁会增加状态、缓存或专用工具，而每一项新机制都可能成为未来维护负担。优化是否值得合并，要看节省的总成本能否覆盖代码复杂度。某个只加速罕见配置、却引入数百行难懂代码的方案可能不划算；相反，删除旧步骤既提速又简化系统，通常价值更高。模型倾向于“添加解决方案”，维护者应主动追问能否删除、合并或利用现有工具完成。
提交说明也不是附属品。内核开发依赖邮件列表和长期版本历史，未来维护者需要从提交信息理解当时的问题、测量方法、取舍与已知限制。Stoakes重写模型生成的提交信息和注释，说明工程知识必须被准确固化。企业使用AI编程时也应保存决策记录，否则几年后只剩下“这段缓存是AI写的”，没人知道为何存在以及何时可以移除。
结语
Linux内核构建优化给出了一个比“模型一次写对多少代码”更成熟的AI工程叙事。LLM的优势是快速阅读、联想和生成候选，人类的优势是设定目标、理解历史约束、设计证据、承担责任并维护长期质量。两者结合后，过去因为枯燥、分散而长期无人处理的性能债务，终于有机会被系统清理。真正的突破不是让AI接管内核，而是让顶尖开发者用更低成本审视复杂系统，同时让每一个性能主张都接受可重复基准和同行评审。