MLIR：一场还没来得及成功的统一梦

“有些系统不是为今天设计的，而是为一个尚未到来的世界预备的。

MLIR 是这样一个系统。 它想统一 AI 编译的碎片，却最终成了所有人都在用、没人能统一的工具。 不是它不够好，而是现实不允许它成功。

这是一个结构主义者造梦的故事，也是技术理想在产业逻辑中反复折叠的一次回声。

一、那年我们一起造框架

2018年，AI 世界像是一片野生雨林，繁茂、热闹，但也杂乱无章。

TensorFlow、PyTorch、JAX、ONNX、Glow、TVM、XLA、TFLite……几乎每一个新的 AI 项目背后，都在偷偷孵化自己的“编译器小怪兽”——不是重新发明中间表示（IR），就是造出一套别人看不懂的“图结构”，再配一套只在特定硬件上跑得动的 Pass 链。你要是没个自定义 op，连开会都不好意思举手发言。

每家都觉得自己做得最先进，最后拼成一幅奇观： 同一份模型，不同框架转换一次格式，不同芯片转换一次指令，不同团队还要“友情手动修图”，最终像在黑箱里扔飞镖，哪一步失败都不奇怪。

这不是技术进步，是“编译内卷”。

而在 Google 内部，情况其实也没好到哪里去。TensorFlow 一边拉着 TPU 项目狂奔，另一边还要支撑 Android、Web、云平台等一堆周边工程。你以为它是一套编译器系统？错。它更像是一堆堆工程师“临时扔上去能跑”的脚手架。

Chris Lattner，当时还在 Google Brain，负责支持 TPUs 和好几个内部定制的 AI 加速芯片。他不是个普通码农，而是 LLVM 的奠基人，你用的 Clang、Swift 编译器，全是他一手打造的。从 Apple 出走再入 Google，一方面是继续做工具链，另一方面，他也嗅到了 AI 编译器世界的“内爆危机”。

有一次 Chris 跟 Jeff Dean（当时的 TensorFlow 负责人，也是 Google 大脑的“总工程师”）一对一聊项目方向，Chris 直接摊牌了：“我们正在重复造轮子，而且造得还不咋地。”

这话说得不重，但听得人心里拔凉。Jeff Dean 一向温和，但听到这话时，眉头皱了皱，像是终于有人说出了他自己也憋了很久的那句话。两人当时站在 Google Brain 三楼的阳台上，喝着黑咖啡，脚下是工程师们拼命敲代码的开放工位——“每一行都可能是在修补某个框架的编译 bug。”

Jeff 看着远处，淡淡地说了一句：

““我同意我们确实有个编译器问题。那你干脆去造一个新编译器，把这摊子统一了吧。”

Chris 后来回忆说，那一刻他心里其实挺复杂的——这不像一个项目立项，更像一个“祝你好运”的托孤。他既得到了授权，也背上了锅。

Jeff 给的是空间，而不是资源。他没有立刻拨人、派 budget，也没有拉 Core Infra 入伙。这是典型的 Google 式放权：你自己看着办，但做得好我罩你，做砸了你自己背。

Chris 没怂。他没像传统方式那样先写 proposal 去排期，而是干了一件 “LLVM人” 最擅长的事：

拉了几个能打的核心开发者，进了个白板会议室，直接三天三夜锁门画图。

这几个人，有的做过 ASIC 编译工具，有的是 TensorFlow Lite 的主力，有的是 LLVM 的资深贡献者，全是那种“白板战士”：一边画着图一边骂工程流程烂，一边动手写原型。

他们不追潮流，只关心一件事：

““有没有一种表示法，可以同时服务 PyTorch、TensorFlow、JAX，也能跨越 TPU、GPU、NPU，甚至是未来还没发明出来的加速器？”

听起来像是白日梦。但他们当真了。

房间里写满了 IR 结构、数据流图、优化 Pass 的依赖关系、前后端接口模型。Chris 提出一个关键设想：

““我们要一个多层次、多方言（dialect）、模块化的 IR 框架，能在同一套架构里处理从高层 DSL 到底层指令的转换。” “每个子系统都可以定制自己的小语言，但最终都能汇聚到一个统一的优化平台上。”

这个想法后来被称作——MLIR：Multi-Level Intermediate Representation。

Chris 没有从 TensorFlow 出发去做兼容，也没有按 LLVM 的老思路去做统一，而是用了一个看似更复杂、实则更优雅的办法：允许复杂性自然存在，但让它们有秩序地共处。

他做的，不是“又一个编译器”，而是“一个造编译器的操作系统”。

那时没人知道，这个叫 MLIR 的玩意，几年后会撑起几乎整个 OpenXLA、Triton、甚至部分 CUDA 后端，也没人预料到，它会成为 LLVM 基金会接收的最重要开源项目之一。

那会大家只知道，Google 的编译器房间里，诞生了一个不安分的孩子——它不是来替代谁的，它是来让所有人少造点屎山的。

二、MLIR：不只是又一个中间表示

在编译器里，中间表示（Intermediate Representation）就像老小区楼里的下水管道：平时谁都不想动，一堵了，全楼都遭殃。

LLVM 的 IR，已经陪伴业界二十年。它稳、泛用、优化能力强，几乎成了编译界的“标准答案”。但也正因为如此，它显得太“硬”，太“统一”，也太不适合多样化的 AI 世界。

Chris Lattner 很清楚这一点。他自己就是 LLVM 的亲爹，哪怕别人不敢吐槽，他敢。他知道 LLVM IR 的问题根本不在于性能，而在于它没法优雅地表达 AI 的复杂性和层级感。

现代 AI 模型是分层的：高层是前端语言（Python、TorchScript）、中间是各种算子图（Graph IR）、底层是张量调度（Scheduling IR）和硬件调用（Codegen IR）。你不能用一套固定格式从头吃到尾，那就像拿个锤子修手机一样，除了砸碎，啥也干不了。

所以 MLIR 做了一个看似冒险、实则革命性的设计：“放弃统一格式，拥抱方言（Dialect）。”

✦ Dialect：不是妥协，是策略

MLIR 的核心概念，就是允许不同的子系统、不同的抽象层级，各自定义自己的语法、语义、算子集和优化规则。

你可以把一个 Dialect 理解为“一套规则自洽的小语言”，专门描述某一类操作，比如：

• linalg dialect：负责线性代数张量调度。
• tensor dialect：负责形状、类型推理和广播语义。
• arith dialect：基础算数运算，统一数值类型。
• tosa / mhlo：分别是 Android 和 XLA 系统自带的算子 IR。
• 自定义 dialect：你可以为你的 ASIC/NPU 写一套专属 dialect，跑得飞快谁也拦不住。

更重要的是，这些 dialect 不孤立，它们都可以“降级”到下一级，更底层的 dialect，最后再转换为 LLVM IR 或者直接代码生成。

这种设计的好处，是把编译器这个“大一统”的黑箱，拆成了一层层可以插拔、可组合的“模块”。你想自己重写某个环节，不用 fork 全套源码，也不用跟别人对齐优化策略，你只要造个 dialect 就行。

✦ 组合不是卖点，是生存方式

AI 框架碎片化、硬件百花齐放，其实是行业的常态，而不是意外。与其指望全世界统一规范，不如设计一套系统——允许大家“带着差异合作”。

Chris 在 MLIR 的设计文档里说过一句话：

““传统编译器是为稳定的硬件和语言设计的。但 AI 是不稳定的，永远有下一个模型、下一个芯片、下一个优化方向。” “所以 MLIR 的目标不是统一所有，而是支持多样性的秩序演化。”

这种“反统一”的统一，其实才是真正的工程理性。与其天天重造轮子，不如把轮子做成标准接口，谁家都能插进来跑几圈。

✦ 不是工具，是平台

MLIR 被称为 “a compiler framework for building compilers” 不是开玩笑。它不是为谁而生的，而是为所有人准备了一个抽象平台。

你可以用它做：

• AI 编译器（OpenXLA、Triton、Shark）
• 图形处理 DSL（RenderScript 的替代品）
• 硬件描述语言（CIRCT、FIRRTL）
• 量子计算编译（QIR）
• 自定义 DSL 的快速原型（像 Swift for TensorFlow 当年）

甚至，有人用它写了 FPGA 的逻辑合成工具链。

MLIR 没有说自己是“AI 专用 IR”，它从一开始就拒绝被锁定成“框架附庸”或者“语言附庸”。它做的是底座，是底层的“共识操作系统”。

✦ 技术理想的第一步，必须架构正确

技术界常说：“架构是你解决所有问题的方式。” 如果你一开始选错了抽象，就会在三年后写出一堆无法 refactor 的代码山。

Chris 和 MLIR 团队正是痛过 LLVM 的“硬统一”，也经历了 AI 编译器的一地鸡毛，所以他们赌了一把：与其为了性能牺牲结构，不如为了结构暂时牺牲性能。

这个赌注，在后来 OpenXLA 和 Triton 的演进中被证明是值得的。但真正的麻烦，也才刚刚开始。

下一节，我们要讲讲 MLIR 是怎么从一个技术理想，变成 Google 各大团队争相使用的“基础设施”，以及它是如何一步步走向“技术太成功、合作却越来越难”的悖论。

三、Google 式温床：从 TPU 到 TensorFlow Lite 的全面内化

MLIR 诞生之初，就不是给“用户”准备的——它更像是 Google 给自己解内伤的一帖药。

Chris Lattner 和团队做出的这个工具链底座，第一批用家根本不是框架工程师，而是那些天天在跟硬件编译痛苦搏斗的 Google 内部开发团队。尤其是几个——TPU backend 团队、TensorFlow Lite 团队、XLA 工程组，还有一堆为 Pixel 手机写 NN API 的前线工程师。

为什么他们急着上 MLIR？一句话总结就是：

““我们不想再写第二套 XLA。”

✦ XLA：不得不维护的“定制版编译器山寨王国”

XLA（Accelerated Linear Algebra）是 TensorFlow 为了支持高性能加速器（TPU、GPU、CPU）搞出来的一套子编译器系统。起初定位是优化矩阵乘法，后来逐渐变成了一个小型编译器框架，能干常见的 kernel fusion、layout 优化、buffer 重排等等。

听起来不错吧？问题在于：XLA 是为了 TensorFlow 的抽象层定制的，换个框架它就懵了；换个芯片它就卡了。

而且，它不 modular，Pass 链之间依赖巨多，优化策略又深度耦合前端语义。你想自己加一个硬件 Target 或者特殊 Op，得 fork 半个 XLA，手动灌入行为——搞到最后，一堆团队各自养了一套“魔改 XLA”。

这就是 Google 内部的“编译器塔楼”。每一个 TP 编译器工程师都在上面贴瓷砖、补水泥，哪一层塌了都能砸死人。

✦ MLIR 进场：不是替代 XLA，而是结构重构

MLIR 不是一刀切地“替换” XLA，而是作为一个更底层、更灵活、更抽象的通用框架，被一点点“塞进” XLA 和 TensorFlow 现有系统里。

最先开始的，是 TensorFlow Lite 的转换链。

TFLite 当时最大的问题是要从 TensorFlow Graph 转成优化过的 flatbuffer 模型，过程极为脆弱。量化流程、fuse pass、op lowering 全靠拼硬编码。

MLIR 则提供了一个天然的优势：你可以用 Dialect 方式精细建模模型中每一个计算步骤的“意图”（intent），再通过多个层级的 IR（比如 from TensorFlow Dialect → TOSA Dialect → Linalg → LLVM IR）来逐步转换优化，而不是一次性硬推。

于是，TensorFlow Lite 成为了 MLIR 的第一块“大规模落地”试验田。

接着是 TPU 编译器团队。他们当时正被一堆自定义指令和 on-device scheduling 烦得焦头烂额，用传统 IR 根本表达不了“硬件亲和性”的复杂调度需求。

MLIR 则允许他们直接造一个 TPU Dialect，写明特定算子和指令绑定，调度策略也可以 modular 插入。他们第一次觉得，写编译器不是一场负担，而是可以“搭积木”做定制的事情。

Chris 后来曾在一次内部 Tech Talk 上说：

““我们不是来告诉你怎么做编译器的，我们是来给你一堆构建编译器的工具。你要造城堡、修下水道、挖矿井都行，只要结构清楚，别人就能接得上。”

这话一下打通了 Google 内部很多编译器工程师的心结。尤其是那些为定制芯片写 Lowering Pass 的老工程师，他们第一次有了“用规范方式写屎山”的手段——结构感回来了，维护成本也能控了。

✦ 内化爆发：从研究工具到 Google Infra

MLIR 真正的爆发，不是某个产品线接入，而是变成了“Google Infra”里默认可调用的一部分。

• TensorFlow 全线开始接入 MLIR 架构，用作 TF Graph 到 XLA IR 的桥梁。
• TFLite 直接切到了 MLIR Pipelines 上。
• Android 团队用 MLIR 写 NNAPI 编译 Pass，提升了模型加载兼容性。
• Research 团队用 MLIR 做 JAX 实验性后端，还探索了 LLVM 后端的混合优化。

甚至连 Google Cloud Infra 也在某些加速服务中引用 MLIR 构建优化路径。

Google 没有正式宣布 MLIR 成为“统一编译工具链”，但工程师们知道——MLIR 是唯一一套“大家都能用、还能互相复用”的编译器组件。

这时候，Chris 和他的核心团队意识到：如果这套架构只停留在 Google 内部，那它终将还是成为另一个“巨头内部黑箱”。

他们决定把它捐出去，开源，并推动走向 LLVM 社区。

一场真正意义上的“工业级开源协作试验”，就此开始。

但他们没想到，技术的成功只是第一阶段，接下来的，是协作的地狱。

四、理想主义爆发：开源捐赠与行业狂欢

对于很多工程师来说，编译器只是工具，不是信仰。但对 Chris Lattner 来说，编译器是一种秩序，是用来统合混乱、缩短试错周期、避免重复发明的基础设施。

他做过 LLVM，知道“好架构”得有个“公共的家”——否则它只会在巨头公司内部自生自灭，被流程、KPI、遗留代码一点点吞掉。

所以，在 MLIR 被 Google 内部多个大项目接纳之后，Chris 做了一个大胆又纯粹的决定：把 MLIR 开源，捐赠给 LLVM 基金会。

不是挂在 Google GitHub 下面，不是 Apache 项目，也不是 TensorFlow 附属模块，而是——正式成为 LLVM 社区的一员。

这一步意味着什么？意味着 MLIR 不是“服务 TensorFlow 的编译模块”，而是被赋予了独立生命，是可以服务整个行业的中立技术基础设施。

“Chris 原话是：“If MLIR has a chance to unify the world, it must be free from any single company’s control.” ——“如果 MLIR 真能统一世界，它必须脱离任何一家公司控制。”

✦ LLVM 社区：技术人最后的庇护所？

LLVM 社区跟多数开源项目不同。它老、严、偏工程，不讲互联网“社区管理套话”，也不搞“基金会背书 PR 战”。它讲的是 meritocracy——谁写得好，谁就能说话。

MLIR 挂靠进 LLVM，最直接的好处是：工程上继承了 LLVM 的测试、基础组件、工具链环境；文化上继承了“开放协作、拒绝私货”的基本规则。

Chris 和核心团队也组织了开放的 “MLIR design meetings”，每周一次，不管你是 Google、Apple、Intel、初创公司，甚至独立黑客，只要你愿意做贡献，就能来参与设计讨论。

这在工业级编译器项目里，几乎是第一次。

✦ 开源第一波浪潮：一窝蜂的方言热潮

开源后半年，MLIR 社区进入“疯长阶段”。

各家公司纷纷 fork、改、扩展：

• Intel 搞了 OneAPI 后端和 VPU Dialect。
• AMD/Xilinx 造了 FPGA 专用 Dialect，用来描述时序电路行为。
• NVIDIA 开始内部评估 MLIR 用于 Triton 编译链替换。
• Meta 内部某 PyTorch 工程组也开始玩 MLIR 作为 IR Fusion 引擎。
• 一堆初创公司（包括后来 Modular 和 Cerebras 的前员工）都开始基于 MLIR 开发定制化 compiler stack。

那时候 MLIR 社区 Slack 一天 500 条消息，Pull Request 排队能排到下周，Design Review 文档成了最常刷的“开源剧本”。

每家公司都说：“我们不是重造轮子，我们只是造我们那一块。”

——听起来都很合理。但大家加起来，其实又开始了新一轮“轮子内卷”。

✦ 没有核心领导的开源，是种集体幻觉

Chris 当时还在 Google，不能长期做 MLIR 的“社区领袖”。LLVM 基金会也一贯不干预技术细节，只管法律和治理框架。

于是，MLIR 社区变成了一个“技术强者自治、目标随缘决定”的生态。也就是说：谁写得多、写得快，就能定方向。

这看起来民主，实则脆弱。

• 有人为了兼容 TensorFlow，写了很多 ML-specific Dialect。
• 有人搞硬件后端优化，写了一堆 Lowering Pass。
• 有人为了教育目的，用 MLIR 改造成教学用 compiler demo。

每一段代码都很有道理，但堆在一起就是一座迷宫。没有一条“主线”，没有一个“统一落地的 reference stack”。

Chris 后来回忆，那段时间就像回到了 LLVM 刚开源那几年：

““Everyone had a slightly different vision of what MLIR should be.” ——“每个人都有一个属于自己的 MLIR 梦。”

可梦多了，就容易碎。

✦ 从理想到混乱，只隔着一个“方言爆炸”

最开始 Dialect 是为了 modularity，为了复用。但当每个团队都写自己的 Dialect、加自己的 Type System、搞自己的 Pattern Matching，整个 MLIR 仓库就变成了一座“语法公园”。

而真正想“从模型直接跑到硬件”的开发者——傻眼了。

• 没有一套明确的 Reference Dialect Set。
• 没有官方推荐的 Pass Pipelines。
• 没有标准的 Graph → Lower → Codegen 路线图。
• 每家公司都说“我们自己写了一个 MLIR stack”，但都互不兼容。

就像当年的 OpenCL：都说自己开源、开放、中立，结果每家公司都偷偷加了扩展，最后没有人敢用“原生 OpenCL”。

Chris 那段时间做了一件挺感慨的事：

他提议把所有 AI 相关的 Dialect，从 MLIR 主树中 逻辑“拆分出去”，成立独立 area group，并建议重命名，例如叫做 “TensorIR” 或 “MLIR-AI”，以免混淆“MLIR Core”的纯粹性。

这是一次晚来的治理尝试——但已经有点晚了。

因为此时，所有人都在用 MLIR，却没有人能控制 MLIR 往哪里走。

五、分裂，从内部开始

一个技术项目的终点，往往不是“被放弃”，而是“被太多人使用”。

MLIR 就是这样一个项目：它没被冷落，恰恰是因为太受欢迎，最终被拉扯成了一张巨网，每个方向都有力量，但没有一个方向能带动整体。

而一切分裂的起点，来自一个看似积极的变化：

“Google 的 MLIR 原班开发者，陆续离职了。

插播宣传一下，MLIR书即将出版（2025年5月15日前出版，清华大学出版社），《MLIR编译器原理与实践》，打扰您了！或知乎链接：https://zhuanlan.zhihu.com/p/1898959048801509459

 

 

 

✦ “人才流散”还是“技术播种”？

从 2020 年开始，MLIR 的几位核心贡献者，陆续离开 Google——有的去了初创公司（如 Modular、Cerebras），有的加入硬件厂商（NVIDIA、Apple、Qualcomm、Tenstorrent），还有人回到学界或独立咨询。

乍看是人才流失，实际却是MLIR 技术影响力进入产业链全域的标志。

这批人带着对 MLIR 的深刻理解，开始在各自公司里推动基于 MLIR 的编译器架构。各家公司一边说“我们采用开源栈”，一边把 MLIR 当作内核，在上面建立自己的私有优化层和硬件调度器。

从表面看，这像是“技术播种”。但深入一点看，你就会发现：

“曾经在同一个白板前写 Dialect 的同事，现在成了不同芯片公司的“武器工程师”。

✦ “开放协作”变成了“编译内战”

早期 MLIR 设计的最大优势，是它让不同的编译器模块可以共存互通。但到了现实世界，“共存”变成了“借壳生子”，每家公司都在 MLIR 上长出了一个自己的私有帝国。

举个例子：

• 某 GPU 公司 fork 了 MLIR，加了一堆 gpu.x 前缀的私有 Dialect，并写了专用调度器，只在公司内部文档中说明。
• 某 AI 芯片厂用 MLIR 实现了整个推理链路，但只把中间几层开源，前后都封装成黑盒，避免其他公司“反向工程”。
• 还有人用 MLIR 改写了整个前端 parser，甚至在 Dialect 上做语义魔改，导致 MLIR 标准工具根本无法分析。

每个决定背后都有商业动机，合理、现实、合规。但这些私有扩展一多，原本应该是 “开源协作共建的技术栈”，最终变成了 “你有你的 MLIR，我有我的 TensorIR”。

Chris 曾私下吐槽过这种局面：

““MLIR 的代码被用了，但 MLIR 的精神已经消失了。” ——“The code lives, the culture fades.”

✦ Dialect 的战国时代

早期 MLIR 设计里有个基本假设：不同 Dialect 会通过官方协作机制整合到一起。但现实是：

• Dialect 写起来太容易（只要注册一下 op/type 就能跑），门槛低得像开便利店；
• 官方没有强制治理机制，也没有 Dialect Compatibility 测试；
• 公司之间在商业层面有“战略敌对”，根本没动力做合并或兼容。

结果是什么？一个词概括：爆炸。

社区里的 Dialect 数量在两年内翻了五倍，兼容性文档基本靠“看源代码”，许多项目一开始还对齐主干，后来就各走各的分支。

这让很多新进入者陷入迷惑：我到底该选哪几个 Dialect 来搭建我的 AI compiler？有没有推荐组合？有没有统一文档？

答案几乎总是——“这得看你目标硬件是谁，最好去看看某某公司有没有开源他们那套。”

MLIR 的最大优势“可组合性”，开始反噬自身。可组合性没有中央协调，就是兼容性灾难。

✦ 社区渐行渐远，方向逐渐模糊

随着核心开发者的离开、行业应用扩展，MLIR 社区进入了一个尴尬状态：

• 技术活跃度还在上涨，贡献者数量持续增长；
• 但项目愿景却越来越模糊，主线方向难以形成共识。

LLVM 社区试图靠“Area Governance”来理顺局面，成立了 MLIR Core 和 MLIR-AI 两个子组，希望清晰区分“基础设施”与“应用扩展”。

但治理是一回事，落地是另一回事。没有人能“强行合并”已经在战场上开火的商业代码库。

Chris 在一次 LLVM 会议上说了一句略带遗憾的话：

““我一直希望 MLIR 成为 LLVM 那样的奇迹，但现在它更像是一个交错的编译器宇宙。” ——“A multiverse of compilers, not a shared infrastructure.”

听起来很酷，实际意味着——MLIR，已经失去了“统一 AI 编译器生态”的可能性。

六、AI 编译器的“半失败”：不是 MLIR 不行，是没人能对抗 CUDA

讲 MLIR 的人很多，但真说它“失败”的人不多——因为大家都知道，这玩意技术真不差。

但问题不是“MLIR 技术好不好”，而是：

“在 AI 编译器这条路上，技术好是不是就够了？

答案写在现实里：不是。

你现在问一个工程师，“想跑一个 LLM，推荐哪套工具链最稳定？”

十有八九告诉你两个字：CUDA。

不是因为 NVIDIA 家大业大，而是因为——它 “能跑、能调、能量产”。

✦ MLIR：技术架构梦中情人，现实落地悲情角色

回头看，MLIR 几乎满足了理想编译器的一切美德：

• 抽象清晰
• 模块化强
• Dialect 灵活
• 可组合性极高
• 社区活跃
• 用的人越来越多

但它永远缺一样东西：统一的、官方的、开箱即用的 Reference Stack。

MLIR 更像是一堆“编译器乐高积木”，拼出来什么样，全靠你自己。你要写模型转换、调度优化、硬件后端，都得自己组装。

而 AI 工程师想要的是什么？

““我有个 PyTorch 模型，点两下，能在某个硬件上稳定跑、速度快、出错率低、调起来不崩。” 不是科研，不是写论文，是干活用的生产工具。

MLIR 做不到这一点，不是因为它技术不行，而是它太“中立”，太“底层”，太“开源文化”，太“有理想主义的洁癖”。

于是，AI 编译栈的现实就是：

• MLIR 被广泛用作构建框架，但最终交付产品的不是 MLIR 本身；
• 每个公司都“基于 MLIR”开发自己的 compiler stack，但彼此互不兼容；
• 没有一套你能下载、部署、推理、上线的“MLIR 全家桶”。

最后的结果是：MLIR 是所有人都用的技术，但没有人能靠它统一行业。

✦ 反观 CUDA：不是开源，不是优雅，但它就是能用

再来看 CUDA。

它不是开源的，也不开放，也没有所谓的“治理模型”，更别提什么 dialect、multiverse。它是垂直整合的产品线，从硬件、驱动、编译器、调度器、库、应用生态一路打穿。

CUDA 不追求“最美的 IR”，它追求的是——最快的 LLM 推理速度、最短的 Kernel 调试路径、最少的工程沟通成本。

NVIDIA 把这事干到了极致：

• cuBLAS、cuDNN、cuTensor、Triton、cuGraph、TensorRT，一个栈接一个栈；
• 工程师亲自下场，帮客户调 Kernel、看性能、上部署；
• 每一次 GPU 新品发布，软件 stack 已经提前半年准备好，Benchmark 跑到极致。

它不是技术洁癖党的最爱，但它是工程实用主义者的天堂。

CUDA 成了事实上的 “AI compiler OS”。

✦ 为什么其他硬件公司做不出 CUDA？

这个问题，已经被问过无数次。答案其实残酷又简单：

“CUDA 不只是软件，它是一个商业战略，是一个 技术闭环 + 应用闭环 + 客户成功闭环 的集合体。

而其他公司——无论是芯片厂、框架厂、系统厂、创业公司，都只在某一个环节努力，缺乏全局统一力。

再加上行业内的现状是：

• 工程师能写 compiler，但没人能管芯片线；
• 硬件团队懂 kernel，但不懂 PyTorch 生态；
• 软件团队想优化模型，但拿不到底层 Spec；
• 商业部门想卖方案，但没人愿意给客户修 bug。

于是，就算大家都用了 MLIR，最终做出来的也只是一个个“半残 compiler”，没一个能跟 CUDA 打正面硬仗。

Chris 在一次访谈里苦笑说：

““MLIR 成功地让每家公司都可以写一个编译器，但也让每家公司都在重复造 compiler，而没人写出能对抗 CUDA 的产品。” ——“A thousand compilers bloom, but none beat the king.”

✦ 所以 MLIR 是失败了吗？

这就像问“Linux 是不是失败了”，显然不是。

MLIR 成功地重塑了现代 compiler 的底层结构，是无数新 compiler 项目的技术基座，它让业界告别了“每家公司从 LLVM 开始写 Pass”的时代。

但它不是产品，不是解决方案，也不是行业生态整合器。它是一把锤子，不是一座房子。

而 CUDA，是早就盖好的别墅，你只需要搬进去——即使房型不能改、租金死贵。

对开发者来说，选择往往不是技术多好，而是谁的房子能先住。

七、新希望？MLIR 社区的治理重构尝试

在编译器世界，失败通常不是因为代码写得烂，而是因为方向失控、治理缺位、共识丧失。

MLIR 没有失败，但它离“共识破裂”只差一步。

Chris Lattner 离开 Google 之后，MLIR 社区进入了“无明确领袖、全靠工程惯性推进”的阶段。Pull request 依然源源不断，Dialect 依然百花齐放，但所有人都在问——我们到底在往哪走？

就在这种摇摇欲坠的时刻，LLVM 社区出手了。

✦ Area Governance：LLVM 老派治理哲学重启

LLVM 是老牌社区，治理方式不 fancy，但很稳。

不像 CNCF 或 Apache 基金会搞 Steering Committee、Technical Oversight Board 那一套，LLVM 的哲学很朴素：

“谁写得多，谁说了算。但写得多的人，必须对社区负责。

于是，在 2023 年，LLVM 为 MLIR 成立了一个新的治理框架：

• 拆分出两个主要子领域（Areas）：
• MLIR Core：专注基础 IR 结构、类型系统、Pass 管理、工具链；
• MLIR Dialects：负责各种领域特定的子 IR，尤其是 AI 编译相关的 linalg、tensor、arith 等。
• 每个 Area 组建 “Area Group”，设立 Maintainers（可类比核心 Committer）；
• 推出《MLIR Charter》文件，定义每个 Area 的目标、范围、变更流程和协作接口；
• 开放 Design Call，鼓励社区成员提交新 Dialect 规范、Pass 管线演进建议；
• 设置长期计划（RFC），以“愿景文档”的形式推进跨公司协作共识。

这一系列动作，看起来很“开源治理味儿”，但对于长期处于“自由生长、缺乏主线”的 MLIR 社区来说，这是一次集体重塑方向的尝试。

Chris 后来在一次社区公开信中写到：

““我希望大家不要把 MLIR 看成一个 compiler project，而是看成一个 platform project。平台的治理，不是靠谁聪明，而是靠大家愿意‘对齐’。” ——“Platform projects succeed when the community converges on constraints.”

✦ 技术对齐之外，命名也是治理

除了结构治理，社区还尝试解决一个长期以来的“语言污染问题”：

““MLIR”到底是指 core IR，还是指整个 AI 编译栈？

这个问题已经造成了广泛混乱——比如有开发者以为 MLIR 是 XLA 的别名，有公司内部把 “我们的 ML compiler” 简称叫 MLIR，实际是个魔改版本。

于是，有人提出：是不是该给“AI 编译相关的 Dialects”换个名字？比如叫 TensorIR 或 MLIR-AI？

这事没有最后定论，但在社区里被认真讨论。它代表了一种态度：

“与其混着用、不清不楚，不如割开来，保核心，放创新。

这种“命名治理”，看起来小事，实际是基础设施系统中最难的一环：定义边界。

你不定义清楚边界，合作的前提就不存在，规范就落不了地，生态也永远搭不起来。

✦ 开源社区的集体坚韧

更重要的是，MLIR 社区并没有像很多“红火一时”的项目那样，在关键节点散掉。相反，它的工程师群体仍在坚持维护和演进。

• Google 仍在投入人力，维护 OpenXLA 和 Core Dialects；
• Apple 开始用 MLIR 构建 Swift 编译链的一部分；
• 一些高校和研究组参与优化调度、多目标硬件映射研究；
• LLVM 社区的编译器老兵，依然每周在 MLIR Call 上点评 PR、修 bug。

你甚至可以说：MLIR 是在无商业公司主导的情况下，靠工程师集体意志撑下来的。

它没有老板，没有产品经理，没有“必须发布的 deadline”，但它活着，而且每个月都在进步。

✦ 但治理能修复生态吗？

这一点，哪怕是 Chris 自己，也说得很清楚：

““治理能防止恶化，但不能自动创造统一。” ——“Governance curbs entropy. It doesn’t create coherence.”

AI 编译器生态的问题，不只是 MLIR 的问题，而是整个行业共同的问题：

• 没有跨公司协作的强动力；
• 没有商业共赢的机制约束；
• 没有大厂愿意主导 reference stack；
• 更没有开发者认同“共建生态”的心智成本。

MLIR 的治理重构，可能让它重新稳住了“底层基建”的身份，但它能不能再往上搭建出统一的 AI 编译栈？还是个大大的问号。

Chris 曾说，如果时间能倒流，他希望当年把 AI Dialect 独立出来，给它取个新名字，单独治理。那样也许就不会让 MLIR 这么快“身份混乱”。

但时间不会倒流。技术治理，注定是在废墟上建秩序，在混乱中找平衡。

八、结语：美好设计不是梦，只是太早了

MLIR 从不是一个失败的项目。它甚至可以说，是现代编译器世界里最成功的技术创新之一。

但它也不是一个成功的“解决方案”。

它像一艘远航船，被极少数人提前造好、提前放入水中，企图带着整个产业穿越碎片化的编译海洋。但当它刚出港，甲板上就上来了太多公司、太多期望、太多不同方向的舵手——结果，它没有沉，却也没法走远。

从 2018 年那场白板会议开始，Chris Lattner 想要解决的，不是某个模型的性能瓶颈，而是一个更深层次的问题：

“AI 软件栈的复杂度，已经超过了人类组织架构的治理能力。

我们造了太多工具，但缺少底层统一逻辑； 我们推动了太多硬件，但每一个都想当生态主角； 我们开源了大量代码，但彼此之间互不理会、各走各的。

MLIR 的设计，试图以一种结构主义方式重新组织混乱世界：通过 Dialect、IR 层级、模块化，让每一个“局部理性”汇聚成“全局秩序”。

从技术上说，它做到了——LLVM 做不到的动态扩展性、TVM 做不到的多前端后端组合、XLA 做不到的解耦性，它都做到了。

但从产业上说，它也失败了——没能统一生态、没能凝聚共识、没能阻止新一轮的“AI 编译器割据战”。

Chris 在一次 MLIR 社区 AMA 里被问到：“如果能回到2018年，你还会选择做 MLIR 吗？”

他笑了笑，说：

““会。因为不做，就没人做了。” “但我会做得更小、更慢、更闭源，先把一整套 reference stack 打通，再开源。” “我太相信工程师的自律了，却忘了商业的焦虑和组织的本能。” ——“I overestimated developer discipline and underestimated organizational incentives.”

这其实是一切底层系统工程的通病。

我们都希望用架构解决问题，但架构不能替代治理； 我们都希望共建生态，但生态不能自发协调； 我们都希望“开源 + 产业协作”能打赢“封闭 + 垂直整合”，但现实往往反过来。

CUDA 成了事实标准，不是因为它技术多先进，而是它从头到尾有人兜底，有人主导，有人为性能结果负责。而 MLIR，只是一群技术人写给技术人的礼物——它干净、强大、优雅，但却太依赖使用者的理解和构建能力。

它不是错了，只是太早了。

也许十年后，当 AI 编译器终于不再是“每家公司都得养一队”的苦活累活时，MLIR 会像 LLVM 一样，悄无声息地站在底层，支撑起所有理所当然的“自动优化”。

那时候，我们才会真正理解：这不是一个失败的统一梦，而是一场延迟兑现的技术遗产。

 

最后，宣传一下，MLIR书即将出版（2025年5月15日前出版，清华大学出版社），《MLIR编译器原理与实践》，打扰您了！或知乎链接：https://zhuanlan.zhihu.com/p/1898959048801509459

 

 

 

添加图片注释，不超过 140 字（可选）

 

参考文献链接

MLIR：一场还没来得及成功的统一梦