AI学术圈和Linux内核工程圈的gap是非常大的!

笔者前几天摘要Paper摘要：Linux内核调度器的LLM Agent框架这篇paper的时候，也有童鞋在留言区抱怨这里面的工作都是KPI工程。这个抱怨我不太认可，因为学术圈和工程圈比较评价和价值体系都一样。但是我认可学术圈和内核社区工程圈在这块的GAP真地是非常大的。

比如说，2021年，学术界诞生了一篇非常有影响力的paper：

https://arxiv.org/abs/2111.11554

KML: Using Machine Learning to Improve Storage Systems

它提出了一种kernel space的机器学习框架，在内核态做推理，用于改善I/O预读、NFS rsize等。

那么五年过去了，它仍然是一篇好paper而不是一个主线工程。主线合入通常需要：

• 长期 patch review

• 子系统接收

• 社区共识（性能 + 安全 + 可维护性）

社区共识有时候是非常难的，比如社区会质疑，为嘛不直接对现在的启发式预读算法进行优化而是引入machine learning到内核？真实的意义究竟有多大？各种开销多大？通用性如何？可维护性如何？

所以，什么东西能进入社区，怎么能进入社区，有多大的难度，作为一个工作了很多年的内核码农，我们需要有一些基本的直觉。不能看到一篇paper就好兴奋，毕竟“花繁柳密处拨得开方见手段”。

我的感觉是，如果长远无法进入mainline的东西，就不要花太多精力去折腾了，因为折腾完的结果，它长远也是死。out-of-tree的维护成本都能直接杀死进不了mainline的东西，未来进入mainline的你的代码的替代品也能杀死你的代码。内核码农写出来的代码的寿命是与能进mainline的可能性成正比的。

但是不能说，“AI改造kernel”这个方向它就错了，目前这个方向它可以说还是有成果的，比如用AI自适应调Linux的参数，或者我们可以进一步研究强化学习来提升文件readahead、swap-in readahead的准确度等，这个还是需要探索的，也需要强有力的社区投入才可能看到未来。

对于内核工程师来说，现阶段更紧迫、也更容易产生成果的方向，或许不是“用 AI 改造 kernel”，而是“为 AI 改造 kernel”。

因为大模型要真正跑起来，就必然会对系统资源提出全新的要求：CPU、GPU、NPU 之间如何更合理地调配；在大模型负载下，怎样降低内存占用、减少内存拷贝；I/O 的加载路径如何加速——这些地方都蕴含着大量优化机会。

内核工程师完全可以和 AI framework 以及应用侧工程师协同起来，在端到端链路中挖掘优化点。一方面类似豆包搞agent、Google搞Gemini、各种手机厂商搞各种智能助手搞地如火如荼，上层的工程师每天都在卷，我们内核码农也不能闲着。要跟他们打成一片，上下左右都打通。比如 agent /LLM运行时，在整条 AI pipeline 上，不同大模型与 camera、屏幕、GPU、NPU、DMA 引擎等多类硬件资源如何协同运转，怎么合理地使用内存带宽，进行零拷贝，进行存储I/O优化等，才能既更快、又更省电——这里面其实大有可为。

所以总结起来就是说：

1. 抛开AI不谈，kernel仍有无数工作可以卷，不能放弃了对基本功的持续追求，毕竟“风狂雨骤时立得定才是脚跟”；

2. 引入AI后，创造了kernel很多新机会——打造一个更适合AI跑的kernel，这个里面可以大胆地冲了；

3. AI优化kernel，有机会，但是别太兴奋乱冲，看准了再冲。

一会我要去bay里面搞烧烤，今天就随便聊到这里了。观点浅薄之处，还望读者朋友们海涵。