CUDA Tile IR 接入 FlagOS 多芯片统一编译器 FlagTree，加速 AI 芯片生态迈向“开放计算”

近两年来，AI 算力需求持续膨胀，但硬件生态的碎片化却让开发者头疼。一个在 NVIDIA GPU 上精心调优的算子，往往无法直接在其他主流芯片上高效运行。这种"锁仓"效应，正成为制约 AI 创新的一大瓶颈。

与此同时，编译器技术也迎来了新变革。基于 MLIR 构建的中间表示层，凭借其可移植性和可组合性，正逐步成为主流方向。CUDA Tile IR 与面向多芯片的统一编译框架 FlagTree（FlagOS 社区重要组件），便是这一趋势下的代表。2026年7月，NVIDIA 团队正式将 CUDA Tile IR 接入 FlagTree。这一举措不仅使基于 FlagTree 开发的算子在 NVIDIA 新一代GPU上获得了显著性能提升，更为行业观察编译器生态的演进提供了一个关键样本，标志着整个产业加速迈向"生态开放"的新阶段。

01 CUDA Tile IR 接入 FlagTree 的生态逻辑分析

NVIDIA****编译器的两条技术路线

理解这次接入的意义，要先看懂 NVIDIA 自身的编译器布局。目前，NVIDIA 在 GPU 编译器领域已形成两条并行的技术路线。

• **传统****CUDA C/C++****路线：**NVIDIA 编译器最早、也最为人熟知的一条技术路线，是基于 CUDA C/C++ 语言、采用 SIMT 编程模型的编译路径。在这条路线中，开发者需要以单个线程为单位编写 GPU 内核代码，精确控制线程层级、内存访问和指令调度。代码经编译器生成 PTX（并行线程执行）虚拟指令集，最终映射至 SASS（流汇编器）硬件指令。这条路线历经近二十年发展，生态最为成熟、应用最为广泛，但也存在两个固有特点：一是编程门槛较高，开发者需深入理解 GPU 微架构；二是生成的代码与 NVIDIA 硬件指令集深度耦合，难以直接迁移至其他芯片平台。

• CUDA Tile语言+ CUDA Tile IR****路线：近年来，NVIDIA 推出了基于数据块的 CUDA Tile 编程模型。开发者不再以单个线程为编程单元，而是操作数据块来表达计算意图，线程调度和硬件映射由编译器自动完成，显著降低了编程复杂度。该路线的核心技术支撑是 CUDA Tile IR，一个基于 MLIR 的中间表示层，位于上层编程语言（CUDA Tile C++, cuTile Python, cuTile Rust）与底层 GPU 硬件之间，承担着编译优化和代码生成的关键作用。

与直接面向 PTX/SASS 指令集的传统路径不同，CUDA Tile IR 在设计上具备更高的语义抽象层级，不局限特定硬件的指令集细节 。这意味着 CUDA Tile IR 所承载的 Tile 级计算语义，具备向不同芯片架构进行映射的理论基础 。正是这一特性，使得 CUDA Tile IR 能够与 FlagOS 开源异构芯片软件栈及其核心组件 FlagTree 统一编译器形成良好的技术协同，FlagTree 作为面向多芯片后端的编译框架，可以将 CUDA Tile IR 纳入其多后端编译流程。此次 CUDA Tile IR 后端正式接入 FlagTree，正是 CUDA Tile IR 与统一编译器栈实现适配的具体体现。

NVIDIA****生态在软件兼容性上的布局

FlagTree 是 FlagOS 社区打造的开源统一 AI 编译器，已原生适配 12+ 款芯片后端，核心目标是实现算子一次编写、多硬件部署。此次 CUDA Tile IR 接入 FlagTree，是一次技术集成，也在一定程度上反映了 NVIDIA 在生态层面的若干考量：

1. 从硬件单一化走向接口开放

传统 CUDA C/C++ 路线生成的 PTX 指令集与 NVIDIA 硬件深度耦合，代码难以迁移至其他平台。而 CUDA Tile IR 不局限于具体硬件的指令集细节，具备更高的语义抽象程度。当 CUDA Tile IR 接入 FlagTree 后，开发者使用 Triton/Triton-TLE 等语言编写的 Tile 级代码，可以在 FlagTree 的多后端体系中选择 CUDA Tile IR 编译后端。这一变化可以理解为 NVIDIA 在保持自身硬件优势的同时，以更加开放的姿态面对日益多元化的算力软件生态。

2. 融入 Triton/Triton-TLE 开源生态，布局下一代编程范式

Triton/Triton-TLE 正在成为 AI 算子编写领域的重要语言。NVIDIA 将 Triton-to-Tile IR 作为开源项目孵化，并接入 FlagTree，使 Triton/Triton-TLE 在获得高效 NVIDIA 后端支持的同时，也能通过 FlagTree 适配更多其它厂商 AI 芯片， 让 AI 开发者更好利用全球多元开放计算资源。

3. 降低 GPU 编程门槛，为未来架构做软件储备

Tile 编程模型屏蔽了线程调度的复杂度，让不熟悉 CUDA C/C++ 的研究人员也能较为便捷地编写高性能 GPU 内核。CUDA Tile IR 通过 FlagTree 被更多开发者接触，将推动这一低门槛范式进一步普及。同时，CUDA Tile IR 支持从 Ampere 到 Blackwell 等多代架构，是 NVIDIA 面向未来硬件的核心中间表示。接入 FlagTree 这样活跃的开源社区，有助于 CUDA Tile IR 在更广泛场景中验证和优化，为下一代硬件提前做好软件栈准备。

02 FlagOS 统一编译器 FlagTree 的开放架构设计

从技术层面上，CUDA Tile IR 究竟是如何接入 FlagTree 的呢？下面会重点讲解 FlagTree 作为统一编译器的技术设计原理和开放架构。

2.1 FlagTree 设计目标与原则

CUDA Tile IR 面向 NVIDIA GPU，但采用不同于原生 NVIDIA 后端的 IR、工具链和执行模型。集成需要解决的核心问题是：让同一硬件同时使用多个编译后端，并按 Triton/Triton-TLE kernel 选择编译路径。FlagTree 通过一套通用多后端架构完成解耦适配，整套设计遵循四大核心原则：

1. CUDA Tile IR 作为独立后端扩展，不全局替换 NVIDIA 后端。

2. 复用前端、编译缓存和运行时框架。

3. CUDA Tile IR 特有的路由、语义、工具链和 ABI 封装在后端内部。

4. 仅将已确认兼容的 Triton/Triton-TLE kernel 路由到 CUDA Tile IR，其余保留原生路径。

2.2 单硬件多后端机制

在上述原则下，FlagTree 需要解决的一个基础问题是：同一块 NVIDIA GPU 上，如何让两个不同的编译后端同时存在且互不干扰？

CUDA Tile IR 与 NVIDIA 后端并列存在：

同一个 NVIDIA GPU    ├── cuda target   → NVIDIA compiler → CudaDriver    └── tileir target → TileIR compiler → TileIRDriver

全局 active driver 仍由 CUDA driver 承担，负责设备和 stream 查询。kernel 创建编译 binder 时，路由层可以把初始 cuda target 改写为 tileir；编译产物再依据最终 target 选择对应 driver。

为实现这一机制，FlagTree 对通用后端框架增加了三类能力：后端可为单个kernel请求替代target****；编译产物可以按最终target选择并延迟创建driver；后端可以向统一语言扩展命名空间提供builtin和类型。****

值得留意的是，通用框架只负责后端发现、冲突检查和 target 传递。这意味着单硬件多后端机制是一个可复用的通用能力，而不是 CUDA Tile IR 专用分支。构建 CUDA Tile IR 时同时安装 NVIDIA 和 CUDA Tile IR 后端，构建、后端发现和运行时启用相互独立。

2.3 路由与编译

有了多后端机制，接下来需要明确 CUDA Tile IR 的编译路径**。**与原生 NVIDIA 后端从 Triton/Triton-TLE GPU/LLVM/PTX 到 cubin 的编译路径不同，CUDA Tile IR 编译链为：

Triton AST → TTIR → CUDA Tile IR → tileiras → cubin

TTIR 继续作为公共前端 IR。CUDA Tile IR 阶段完成控制流适配、操作转换、memory token 建模和目标优化，并在调用 tileiras 前检查是否仍有非法方言残留。

CUDA Tile IR cubin 仍通过 CUDA Driver API 加载，但其 launch 模型以 Tile grid 表达工作量，在 CUDA launch config 中将 blockDim 设置为(1,1,1)，并处理 CUDA Tile IR 特有的参数 ABI 和 launch attributes，因此使用独立的 CUDA Tile IR Launcher。

TensorDescriptor 在 CUDA Tile IR ABI 中被展开为占位参数、data pointer、shape 和 stride。编译期签名与运行时实参采用相同展开规则，用户无需感知这一底层参数转换。CUDA Tile IR driver 不声明为全局 active，仅在执行 CUDA Tile IR 编译产物时延迟创建。

2.4 CUDA Tile IR****提供的核心能力

CUDA Tile IR 接入 FlagTree 的技术价值，很大程度上来自其有别于传统后端的语言能力。理解这些能力，有助于理解为什么 CUDA Tile IR 不只是另一条编译路径，而是一种更高层级的编程范式。

CUDA Tile IR 当前提供的核心能力包括：

• 将地址、形状和步长封装为 tensor view；

• 将逻辑张量进一步映射为按 Tile 访问的 partition view；

• 通过 Tile 坐标而非逐元素指针计算完成 TKO load/store；

• 以一等类型表达 memory token，并显式描述内存操作间的依赖；

• 为 load/store 指定内存顺序、作用域和优化代价提示；

• 在前端直接构造 CUDA Tile 类型与操作，而不是先模拟为普通 Triton/Triton-TLE pointer 操作。

这些能力与 Triton/Triton-TLE 中多数传统后端的主要区别，是它们暴露的不是另一组硬件 intrinsic，而是一套更高层的 Tile数据视图和显式依赖模型**** **。**传统 Triton/Triton-TLE kernel 通常由程序显式计算每个元素的 pointer、offset 和 mask，再由后端推导数据如何分块、搬运和同步；CUDA Tile IR 扩展则允许程序先声明"数据是什么视图、如何分 Tile、访问哪个 Tile、访问之间有什么依赖"，再由 CUDA Tile IR 和 tileiras 决定底层实现。

表：通过 Triton-TLE 扩展实现的 CUDA Tile IR 的特性

2.4.1 Tensor view****：描述逻辑张量****

把基地址、元素类型、各维 shape 和各维 stride 组合成有类型的逻辑对象。shape 和 stride 可以同时包含编译期常量与运行时值，因此同一套 view 抽象既能表达静态张量，也能表达部分动态的布局。相比普通 pointer，tensor view 保留了完整的多维布局信息，使后续编译阶段不必从已经展开的地址算术中重新恢复 shape 和 stride。内存对象不再只是"某个元素类型的地址"，而是"具有逻辑维度和布局的张量视图"。这为 CUDA Tile IR 在更高层完成数据搬运、边界处理和访问优化提供了基础。

2.4.2 Partition view**：描述Tile划分**

在 tensor view 之上增加每个 Tile 的形状、Tile 维度到原张量维度的映射，以及越界区域的填充值策略。它将"张量的物理布局"和"kernel 如何按 Tile 消费该张量"分离。相同 tensor view 可以采用不同的 Tile 形状和维度映射，而无需改写底层指针计算。这种设计特别适合 Tile 编程模型：kernel 使用 Tile 坐标访问 partition view，编译器负责将逻辑 Tile 映射到实际数据区域。与显式构造 offset 和 mask 相比，partition view 保留了更多可供后端优化的结构信息。make_view 是 tensor view 与 partition view 的组合入口。当前实现要求每个源维度在 Tile 映射中恰好出现一次，并支持指定 padding；更复杂的 traversal stride 尚未纳入当前支持范围。

2.4.3 TKO load/store**：以Tile为单位访问数据**

TKO load/store 直接对 partition view 操作。调用者提供的是 Tile 坐标，而不是一组逐元素地址。一次 TKO load 的结果是具有确定 shape 和元素类型的 Triton/Triton-TLE block tensor；一次 TKO store 则把 block tensor 写回指定 Tile。用户程序选择逻辑 view 和 Tile 坐标，CUDA Tile IR 决定 Tile 数据的具体寻址、搬运和目标指令。这与传统 load/store(pointer + offsets, mask) 的核心差异在于，边界、布局和 Tile 形状仍以结构化信息存在于 IR 中，而不是提前降低为标量地址计算。TKO load/store 还可以携带 cost。该值会结合目标架构转换为优化提示，让后端在编译阶段评估操作代价，但不改变用户可见的数据语义。

2.4.4 Memory token**：显式表达副作用依赖**

CUDA Tile IR 将 memory token 定义为一等语言类型。程序可以创建起始 token，把 token 作为 load/store 的依赖输入，请求内存操作返回新 token，合并多个 token，并将结果传给后续内存操作。这使内存操作之间的先后关系直接出现在数据流中。例如，一个 store 使用前一个 store 返回的 token，表示后者依赖前者完成；合并 token 则表示后续操作同时依赖多条内存操作链。传统后端主要依赖程序顺序、barrier、内存语义以及编译器副作用分析推断约束。memory token 则把依赖显式编码为 SSA value，使优化器在移动、合并或调度 Tile 操作时仍能保留必要顺序。Token 不等同于 CUDA event，也不是运行时对象。它只存在于编译 IR 中，用于描述 kernel 内部内存副作用的依赖关系。

2.4.5 内存顺序与作用域

TKO load 支持 weak、relaxed 和 acquire；store 支持 weak、relaxed 和release。非 weak 操作还可以指定 Tile block、device 或 system 作用域。Memory token 表达"哪些操作存在依赖"，ordering 和 scope 则表达"该依赖需要满足多强的可见性保证"。二者组合后，CUDA Tile IR 可以同时描述编译器调度约束和硬件内存模型约束。

2.4.6 直接构造****CUDA Tile IR

上述 view、token 和 TKO 操作不是先转换为普通 Triton/Triton-TLE pointer load/store，再依赖后端模式匹配恢复，而是由 CUDA Tile IR 专用语义层直接创建 CUDA Tile IR 类型和操作。这样既避免 view、Tile 划分、token 和内存顺序在 lowering 中丢失，也能让无法表达或尚未支持的组合尽早报错。普通算术、控制流和张量运算仍沿用 Triton/Triton-TLE 通用语义。

2.4.7 兼容能力与当前边界

扩展层还提供少量兼容操作，例如特定形状下的 slice 和末维拼接。这些操作复用现有 Triton/Triton-TLE 语义，不代表新的 CUDA Tile IR 抽象。CUDA Tile IR 已提供一条结构化 view、Tile 访问和 token 依赖链路，但尚未覆盖所有内存与原子操作。路由白名单依据这一实际能力边界进行保守选择。

总体来看，CUDA Tile IR 接入 FlagTree 在技术层面建立了一套相对完整的通路------从 Triton/Triton-TLE 前端到 CUDA Tile IR再到cubin，从路由机制到运行时加载，从高层视图到显式内存依赖。这套通路的建立，也为下一部分将要讨论的行业影响提供了技术基础。

2.5 CUDA Tile IR****带来的性能提升

为评估 CUDA Tile IR 编译路径的性能，FlagTree 选取 BMM、FMHA、LinearBiasAct、MLA、MLA Decoding、Matmul 和 RoPE 七类算子，在 Hopper 和 Blackwell 架构 GPU 上分别测试 142 组配置，并与原生 NVIDIA 编译路径进行对比。两条路径均通过全部正确性验证。

测试基于 FlagTree/Triton-TLE 3.6.0、PyTorch 2.9.1、CUDA Tile IR assembler 13.3.36 和 cuda-tile v13.3.0，开启 autotune，并使用 CUPTI 统计 kernel 执行时间。每组配置的加速比定义为"原生 NVIDIA 路径耗时 / CUDA Tile IR 路径耗时"，图中展示各算子所有测试配置加速比的算术平均值。

图1：CUDA Tile IR 相对原生 NVIDIA 路径的平均加速比。横坐标采用对数刻度，1.0x 表示两条路径性能相当，数值越大表示 CUDA Tile IR 性能提升越明显。

在 Hopper 架构 GPU 上，CUDA Tile IR 在 BMM、FMHA、MLA、MLA Decoding 和 Matmul 上获得了 1.26x 至 1.45x 的平均加速，LinearBiasAct 和 RoPE 与原生路径性能基本相当。在 Blackwell 架构 GPU 上，性能提升进一步扩大：BMM 和 MLA Decoding 分别达到 2.06x 和 1.86x，Matmul 最高达到 7.17x。

这些结果表明，在保持 Triton/Triton-TLE 编程接口和计算结果不变的前提下，CUDA Tile IR 可以利用更高层的 Tile 语义和目标优化能力，为 FlagTree 算子提供新的性能优化空间。实际收益会随算子类型、输入形状和目标架构而变化。

03 一次集成，多重变局------ CUDA Tile IR 接入 FlagTree 的深远影响

CUDA Tile IR 主动接入 FlagOS 社区编译器项目 FlagTree，影响的不仅是 NVIDIA 自身的编译器布局，也不仅是 FlagTree 多后端支持列表的又一次扩充。沿着"开发者---技术生态---行业格局"这三层维度来看，这一事件的价值变得更加立体和清晰。

3.1 对开发者：体验提升与迁移便利

对于 AI 开发者而言，CUDA Tile IR 接入 FlagTree 带来的变化较为直接。首先是代码复用的便利 ，使用 Triton/Triton-TLE 编写的算子无需重写，在 FlagTree 上切换编译后端即可在 NVIDIA GPU 上执行，这在很大程度上减少了针对不同平台进行重复开发的工作量。同时，FlagTree 提供的混合路由机制保证了迁移过程的平稳 ：对于暂不支持 CUDA Tile IR 的内核，系统可自动回退至原生 NVIDIA 编译路径，同一进程中两者可协同工作，开发者不必担心因部分算子不兼容而导致整体流程中断。在性能方面 ，Tile 语义直接面向 CUDA Tile IR 进行编译，保留了数据块级的计算结构信息，避免了传统 SIMT 路径中因降维为线程级代码而产生的信息损失，这为矩阵乘、FlashAttention 等关键算子的进一步性能优化提供了新的空间，也为开发者在调试和调优过程中提供更清晰的语义层级。总体而言，CUDA Tile IR 接入 FlagTree 让开发者朝着"编写一次、多平台部署 "的目标更近了一步，减少了硬件生态单一化的顾虑，可以将更多精力集中在算法创新本身，而非在不同硬件平台之间反复适配。

3.2 对技术生态：编译器中间表示走向标准化

CUDA Tile IR 与 FlagTree 均基于 MLIR 构建，技术底层的一致性为集成提供了良好的先天条件。此次接入的意义不止于一次具体的集成实践，更在于它从一个侧面印证了基于 MLIR 构建可移植编译器中间层的技术可行性 ，CUDA Tile IR 可由 CUDA 驱动在目标 GPU 上重新编译/映射，从而面向后续 NVIDIA 架构保持可移植性，能够在 FlagTree 的多后端框架中被正确编译并生成高效的 NVIDIA GPU 代码，这本身就是对 MLIR 跨平台编译能力的一次有力验证。与此同时，KTIR 等新兴中间表示规范也在向块级表示方向靠拢，表明数据块级计算语义正在成为编译器中间层设计的共同技术选择 ，而非某一家厂商的独有路线。CUDA Tile IR 与 FlagTree 的实际协作，为这种技术共识的落地提供了一个从理论到实践的参考案例，也为更多芯片厂商参与统一编译框架的建设降低了后续接入成本。

3.3 对行业格局：从单一编译优化到开放编译器生态协同

FlagTree 目前已支持 12+ 芯片后端，CUDA Tile IR 的接入使 NVIDIA GPU 正式成为这一多后端矩阵中的一员。短期来看，这一事件传递了一个值得关注的信号：即便是 GPU 领域的头部厂商，也在以更加兼容的姿态面对多芯片并存 的现实，在 AI 算力需求日趋多样化的当下，开放与互联正在成为新的行业共识。CUDA Tile IR 与 FlagTree 的适配过程也为其他芯片厂商提供了一个可参照的技术范式。长期来看，当更多芯片厂商将自身的编译器后端接入统一编译框架，整个行业的编程抽象层将趋于标准化，竞争将更多回归到硬件性能、能效比和成本控制等本质维度。随着 Tile 编程模型在 FlagTree 等平台上被更广泛地采用，数据块级的编程范式有望从个别厂商的技术特色逐步演变为行业共同的基础设施，推动 AI 算力生态朝着更加开放、互联的方向演进。

04 结语

从单一 CUDA 线程编程到开放 Tile 分块中间表示，从厂商私有编译链到 FlagTree 统一跨芯编译器，CUDA Tile IR 接入 FlagTree 是 AI 软件生态演进的关键里程碑。在 AI 算力需求持续增长、芯片多元化趋势日益明显的背景下，开放、协作、标准化的编译器基础设施正在成为支撑下一代 AI 应用的重要基础，也正在消解软硬件之间的生态壁垒。未来，FlagOS 将继续携手全球合作伙伴，推动 AI 芯片生态走向更加互联互通的格局，让开发者离"编写一次、多平台部署"的目标更近一步，推动全球 AI 算力产业走向开放、协同、标准化的全新阶段。