8 月 1 日，Meet AI Compiler 技术沙龙第 9 期在北京圆满落幕，多位 AI 编译器领域的专家与学者齐聚北京中关村，围绕技术创新、落地经验带来了精彩分享，力图呈现 AI 编译器在语言表达、算子计算、推理执行与场景应用等多个层面上的协同演进图景。

卡内基梅隆大学机器学习系与计算机科学系的助理教授，英伟达杰出工程师、全球知名开源项目 XGBoost 、 Apache TVM 和 MLC LLM 的核心开发者与创始人陈天奇，作为特邀嘉宾出席了本次活动。这位 AI Compiler 领域的鼻祖级人物分享了 TVM 开源社区当前的发展方向，并与在场观众进行了深度交流。

HyperAI 在不违原意的前提下，对陈天奇教授的分享进行了整理汇总。

大家好，很高兴参与本次活动并与大家交流分享。我是陈天奇。我们在 AI 编译器领域已经探索了很多年，今年是 AI 编译器领域非常有意思的一年。从年初开始，AI Agent 浪潮快速兴起，行业开始出现一些新的问题：

第一个问题：AI 编译器还有没有价值？当 Agent 可以直接编程时，我们是否还需要编译器？

第二个问题：有了自动化之后，我们能够做的事情也变多了。过去，小团队最大的瓶颈主要在工程资源；随着 Agent 到来之后，我们可能用更小规模的团队完成更多事情。

所以今天我想分享的是：在 AI Agent 时代，我们应该如何重新思考 AI 编译器？未来 AI 编译器应该朝什么方向发展？

加速 Agent 专用迭代

一个很明显的特点是，Agent 需要比较快速的、专用的迭代，因为 Agent 有有限的上下文。过去，我们比较倾向于做大项目开发，也就是大型 monorepo（单体代码仓库）的开发方式，但是现在 Agent 的专用迭代会成为一个非常重要的方向。

第一，为了加速 Agent 专用迭代，我们发现项目边界的稳定性、可组合性和模块化非常重要。

以我们的 TVM FFI 项目为例，其目标是把 TVM 大组件里面的一个核心组件——也就是函数之间如何互相调用——定义清楚，包括从框架 DSL 到后端，比如 cuteDSL 、 FlashInfer 等不同组件之间，它们的函数边界应该长成什么样。过去，我们比较关注的是能不能做一个端到端的解决方案，但是现在我们越来越发现，我们需要定义一个更加有机的边界，使得我可以很容易地把算子或者其中一些模块切换实现，这个时候把边界本身定义清楚、规范化，就变得非常重要。

TVM FFI 从去年发布到现在，我们已经有包括 cuteDSL 、 FlashInfer，以及最近 TensorRT 等等的整合。它的作用就是定义这个边界规范应该长成什么样，当边界定义清楚之后，中间模块就可以更加灵活地替换。

第二，为了让 Agent 快速完成专用迭代，未来大家会看到更多跨语言支持。

如果 Agent 的反馈时间是一个小时或者两个小时，那么它能够试错的时间就会越来越长，所以编译器本身需要支持更多语言，所以我们会推动基础设施层面对更多语言的支持。

过去，用户对应的操作对象通常是编写一个程序，这个程序本身就是你的操作对象。但是因为 AI 本身可以更加智能，我们可能会发现，很多时候人们不会直接完成所有计算，而是会创造工具，比如你做数学计算的时候，不一定要心算，而是可以使用工具。同样的道理，我们认为编译器内部本身的分析能力和基础设施，也会逐渐走到台前。我们希望能够把编译器模块化，让 AI 可以自己搭建针对当前需求的分析和迭代。

为了实现这一点，我们最近在进行关于 TIRx 的工作，同时，我们也发布了一个教程，叫 Modern GPU Programming，当然，它不仅限于 GPU，而是在尝试介绍更加通用的加速器编程概念。最近半年，我跟冯思远交流的时候提到，我大概有一半时间花在写代码上。因为有了 Agent 之后，确实可以让我们重新回过头来，对整个项目的代码进行重构。我们去年一年已经把 TVM FFI 这个模块相对独立并稳定下来，接下来也会进一步推动 TIRx 的独立和稳定化。

Agent 时代，编译器可以做什么？

我们发现，传统编译器有一个比较大的特点：它通常会把两类东西放在同一个 Stack 里面，一类是高层的、需要比较聪明的部分，比如自动调度； 另一类是底层的、比较笨的部分，比如纯规则化的东西。但是未来，我们认为趋势会发生变化：我们越来越需要把稳定化的部分和需要快速迭代的部分分开。也就是说，未来会有一个核心模块，它是比较稳定的；在这个基础之上，我们可以更加灵活地加入很多 Agent 相关的能力，让 Agent 根据需求去构建专用编译器和优化流程。

再回到主题：Agent 时代，编译器可以做什么？

我觉得明年的这个时候，甚至今年年底，我们讨论的 AI 编译器肯定会和今年之前的 AI 编译器不一样。这是一个非常有趣的机会，我们可以一起重新思考这个事情。

反过来说：有工具的人类，相比只有肉体的人类，肯定会更强。 AI 编译器本身，就是工具的一种。所以只要我们有能力让 AI 更好地参与编译器相关模块的设计和开发，这里面仍然会有很多有趣的机会。

以上就是我想分享的，谢谢大家。

Q&A 环节

问题 1：随着越来越多硬件不断出现，未来编译器应该走通用化架构适配，还是走特化某种硬件的适配？

陈天奇：有了 Agent 之后，很多事情会发生变化。传统情况下，当我们能够在不同后端之间共享代码时，大家肯定会倾向于共享代码。这也是为什么早期我们会倾向于做比较大的 monorepo，进行统一开发。但是有了 Agent 之后，开发代码的成本会降低，所以未来肯定会出现更多特化的部分。特别是在共享代码的抽象不足以支撑硬件本身能力的时候，这种情况经常发生。比如，即使是在 GPU 上，你为 Hopper 设计的编译器，到 Blackwell 之后，可能就完全不能用了，经常会发生这种情况，所以未来一定需要特化。

但是反过来说，问题在于：哪些东西仍然可以保持共同？我们还是需要一个比较稳定的 foundation，让 Agent 能够在这个基础上进一步构建硬件特化的编译器。比如我们最近的 TIRx 相关工作，就是希望允许不同硬件注册自己的 dispatch rule，然后让 Agent 根据硬件特点生成相关知识。

未来，我们会越来越多看到这种可以被特化的编译器。它可能会被分成两部分——第一部分是比较稳定的部分，比如 ABI  需求，核心的 IR 数据结构，以及跨语言相关能力，它对于稳定性的要求比较高；第二部分是针对具体场景进行特化的部分，这一部分未来可能更多由 Agent 驱动。我觉得后面会出现越来越多这种情况。

问题 2：我在学习过程中有一个感受，对于 IR 来说，很多传统抽象边界正在被打破、融合，以前很多区分比较明确的东西，似乎都逐渐被 IR 吸收进去。如果从这个角度看，您认为 AI 编译器未来的发展方向是什么？

陈天奇：我觉得会分成两部分——第一部分，虽然现在大家看到不同 IR 之间可能不一样，但很多时候它们其实长得还是比较接近的，基本上可以分成几个层级：Kernel 级别、图级别，以及它们之间的联动。 经过几年演化之后，可能会逐渐 converge 到几个比较稳定的层级。分层太多其实没有好处，因为层和层之间转换的时候，往往会丢失信息。所以当我们 converge 到几个主要层级之后，核心问题可能变成：我们怎么样把需要的信息 encode 进去。

第二部分，过去很多需要依靠强化编译器完成的事情，是不是可以直接交给外部的人或者 Agent 来控制？也就是说：能不能把编译器做薄？或者说让编译器分层。分层的意思是：你需要有一层相对稳定，可以持续维护；同时也需要有另外一层，可以快速迭代——至少未来一定会有这两层。

问题 3：从 AI 编译器角度来看，未来是否会出现 AI 编写 AI 编译器？从短期来看，哪些编译器组件适合由 AI 编写？其中主要挑战是什么？

陈天奇：首先，我相信在座很多从业者已经开始使用 AI 来写 Compiler 了，所以这不是一个未来可能性的问题，而是一个正在发生的事情。

这里面比较重要的还是模块化。如果你希望 AI 完整托管一个大型项目，这肯定是比较困难的；但如果你只是把其中某些模块交给 AI，让它快速进行迭代和试错，这是完全有可能的。关键是你需要把问题拆解成一个比较好的子问题，所以这个时候比较重要的是边界定义，我们做 TVM FFI，就是希望能够把这个边界定义清楚。

同样的道理，好的 IR Infrastructure 也非常重要。比如现在如果你想写一个 Compiler IR，同时支持 Python 、 Rust 、 C++ 等语言，其实目前还没有一个非常完善的方案。未来，如果我们能够提供这样的基础设施，会对开发效率产生很大的提升。

那在基建以上可以做什么东西呢？我觉得取决于我们还能不能提炼出一些共同的需求。比如过去我们讨论过一个问题：Compiler 里面一个比较大的部分，是 Host Side 的 Cost Reduction，这个问题其实和 GPU 加速、硬件加速本身是相对独立的。但是 Host Side 优化本身，仍然存在很多可以自动化的空间。如果我们能够提炼出这些共同需求，未来 AI 在 Compiler 开发里面会发挥更大作用。

问题 4：对于不同层次的 Compiler，比如 low-level DSL 和 high-level DSL，它们未来在产业和开发生态中会占据什么位置？

陈天奇：我觉得不同 level 都会有自己的需求。总的来说，能够把 Low level 暴露出来，可以兼具 Low level 和 High level 本身的表示也是好的。就比如说我们最近做的 TIRx，它本身也会有 level 的表示，以及直接有 Native partner level 的表示，这样的话你可以在两个之间可以做一些灵活的过渡。但是有一个原则：就是应该让 Agent 用尽可能少的 token 来表示这些东西，同时不要限制它发挥能力。

问题 5：过去我们讨论 Compiler，更多关注 Kernel level，但实际上很多东西都可以用 IR 表示。所以未来除了 Kernel level IR，Micro level IR，甚至调度级别 IR，是否也会成为 AI Compiler 的研究方向？

陈天奇：这个其实非常正常，因为图级别的 Compiler 一直存在，只是过去很多时候，Kernel 和图级别之间的联动比较弱，图级别 Compiler 主要解决图级别的问题，Kernel 级别 Compiler 主要解决 Kernel 级别的问题，但是未来我们会越来越需要两者之间的联动。

最近比较大的一个方向是 MegaKernel，就需要跨 Kernel 之间进行联动。所以我们也一直在思考：怎么样能够在一个 IR 里面，同时 encapsulate  这两类信息？如果未来能够做到这一点，我觉得会产生一些比较有趣的东西。比如之前 MegaKernel 的工作，本质上就是利用 Graph level 和 Kernel level 之间的联动完成优化。

问题 6：Agentic-friendly Compiler 是真命题吗？

陈天奇：未来可能存在一种情况：我们不需要 Compiler，Agent 可以直接生成 Assembly 。区别在于：我们可以让 Agent 直接完成这个事情；也可以让 Agent 写 Compiler，让 Agent 自己制造工具。我个人还是比较相信 Compiler 仍然是有价值的，因为它在很多情况下能够提高开发效率。

那么 Agent-friendly 是一个伪命题，还是真命题？我觉得关键可能不在于你的软件一开始是不是具有这个特性，而在于我们是不是把它作为一个目标去设计。当 Agent 参与之后，我们会不断观察：哪些地方 Agent 做得比较好，哪些地方 Agent 做得不好，然后根据这些反馈继续迭代。

比如跨语言需求，就是一个非常实际的问题。 Agent 一开始可能可以快速使用 Python 开发一个 Compiler Pass，但是当它需要加速时，它可能需要切换到 C++ 或 Rust 。如果我们把这些问题作为目标去解决，我相信这不会是一件坏事情，因为现在很多代码已经有相当比例是由 Agent 编写的。未来，Compiler 也会成为 Agent 可以帮助构建和优化的工具。

以上就是陈天奇老师出席 Meet AI Compiler 技术沙龙所带来的精彩分享，本场活动的其他精彩演讲也将陆续以演讲实录的形式进行报道，敬请期待！