AscendNPU IR 并不是面向终端开发者的另一门编程语言,而是华为毕昇(BiSheng)编译器体系中的开源编译基础。2026 年 8 月 1 日,在 HyperAI 主办的 Meet AI Compiler 第九期技术沙龙上,华为 AscendNPU IR 架构师海丽娟介绍了这一基于 MLIR 的编译栈,以及它如何把 Triton 等算子生态接入昇腾硬件。
3
7
它要解决的核心问题是:让前端开发者不必在每个算子中手动处理 Tile 切分、片上内存分配、数据搬运、同步、Cube 与 Vector 计算协同,以及最终的设备指令生成。
AscendNPU IR 在毕昇编译器中的位置
AscendNPU IR 是面向昇腾亲和算子编译的 MLIR 中间表示,提供从高层张量语义到硬件相关指令之间的多级抽象。一方面,高层接口可以屏蔽计算、搬运和同步指令的细节;另一方面,开发者仍可在较低层级精细控制片上内存位置、流水同步以及乒乓流水优化。
4
11
它支持多种接入路径:Triton、TileLang 等 DSL 可以直接下沉到 AscendNPU IR;PyTorch 等框架则可以通过 Torch IR、Linalg/HFusion IR 或 HIVM IR 接入。不同层级在易用性与控制粒度之间提供不同取舍,高层路径可自动完成算子融合、切分和调度,而 HIVM 则允许开发者更直接地控制昇腾存储层级与计算流水线。
5
22
Triton、TileLang 或框架 IR
↓
基于 MLIR 的 AscendNPU IR
↓
HFusion → HIVM 逐级下沉
↓
昇腾设备指令与二进制文件
官方示例显示,开发者可以使用 bishengir-compile 将 MLIR 编译为设备端目标文件,再通过 CANN runtime 完成算子注册、调用和上板执行。
6
为什么要采用 Tile 级抽象
Tile 可以理解为一块可管理的张量数据及其计算任务。与其让每个前端分别描述每一次数据搬运、内存层级选择、同步点和硬件指令,AscendNPU IR 不如提供一个共同的 Tile 表达,让不同语言和框架能够面向同一套编译基础生成代码。
这种抽象采用分层设计。高层开发者可以用接近张量运算的方式表达算子;在需要深度调优时,编译器或专家开发者则可以进一步指定或推导 GM、UB、L1、L0 等存储层级,以及 Vector、Cube 和数据搬运资源的使用方式。
5
22
因此,AscendNPU IR 试图在可移植性与硬件调优之间取得平衡:Triton、TileLang 和框架 IR 可以共享同一个编译入口,同时对性能敏感的算子也能下沉到更贴近硬件的表示。官方架构文档将这一过程描述为逐层解耦的抽象,分别刻画昇腾指令、核内资源、核间资源和系统级资源。
11
HFusion 与 HIVM:分工不同的两层优化
HFusion:在较高层完成融合与调度
HFusion 是相对硬件无关的层,主要以较高层次表达张量操作,并在生成具体硬件指令前完成融合、Buffer 化、Tile 切分和调度等变换。
11
22
在这一层,多个操作可以被合并为更大的计算单元,整体任务也可以被切分为适合昇腾执行模型的 Tiles。它尽量保留高层语义,同时为后续的昇腾相关 lowering 做准备。
HIVM:把 Tile 映射到真实硬件
HIVM 是硬件感知层,负责把 Tile 表达转换为能够反映昇腾执行单元、存储层级和流水行为的操作,主要包括:
- 将矩阵计算映射到 Cube 核,将向量计算映射到 Vector 核;
- 自动补齐两类计算单元之间的数据通信与同步;
- 管理中间 Workspace;
- 将逻辑张量映射到物理片上内存;
- 处理 Cube 相关的分形矩阵布局;
- 执行向量化、张量化、流水化和指令级变换。
2
14
换句话说,HFusion 更关注“哪些张量操作可以合并、如何切分和调度”,HIVM 则进一步回答“这些 Tiles 应该放在哪里、由哪个计算单元执行,以及它们何时搬运和同步”。
Ascend 950 带来了哪些变化
HFusion 与 HIVM 的总体分工没有改变,但面向 Ascend 950 的 HIVM 需要覆盖比早期基于内存的 SIMD 更丰富的执行模式,包括基于寄存器的 SIMD 和 SIMT。
2
基于寄存器的 SIMD
在这一模式下,数据可以从片上内存加载到寄存器,在寄存器中完成计算后再写回。当算子结构允许时,寄存器级融合还可以让中间结果在多个操作之间保持在寄存器中,从而减少重复加载和存储。
2
SIMT 处理不规则计算
SIMT 为适合这一模型的不规则访存或存在分支发散的计算部分提供了另一种执行方式。编译器可以将适合 SIMT 的部分与密集、适合 SIMD 的部分区分开来,分别进行变换,再将结果重新纳入整体向量计算。
2
更紧密的 Cube–Vector 数据交互
在部分 A2/A3 流程中,Cube 与 Vector 之间的计算交互需要经过全局内存。面向 Ascend 950 的描述显示,Cube 结果可以从 L0C 传递到 Vector 片上内存,Vector 结果也可以返回 Cube 使用的存储区域,从而缩短两个执行域之间的数据路径。
2
这对矩阵计算之后紧接向量处理的算子尤其重要。不过,编译器仍需判断张量所在位置和传输时机;当 Cube 与 Vector 操作位于不同控制流分支时,分析难度会明显增加。
让模型落地的关键编译 Pass
InsertCVLoadStore
增强后的 InsertCVLoadStore 不再只依赖简单的局部模式匹配,而是通过跨复杂控制流的全局分析来补齐 Cube–Vector 数据交互。它首先建立确定性的内存位置锚点,例如将矩阵输入放在 L1、矩阵输出放在 L0C、向量数据放在 UB;随后在程序中传播这些约束,并在不同内存域发生冲突时插入转换或复制操作。
2
对于 A2/A3,部分跨域传输可以使用全局内存的加载与存储;在 Ascend 950 支持的路径中,则可以采用更短的片上数据通路。
2
MultiBuffer
MultiBuffer 为已有 Tensor 创建多个缓冲副本,可用于乒乓缓冲,并在内存预算和调度条件允许时,让数据搬运与计算重叠执行。
17
18
AutoBlockify 与 DynamicCVPipeline
AutoBlockify 和 DynamicCVPipeline 是 Triton-Ascend 编译栈中的昇腾专用 Pass,分别对应计算块划分,以及 Cube–Vector 流水行为的构建。
19 相关文档还列出了自动内存规划、同步、调度和 CV 优化等能力。
24
CV 1:2 切分
针对相关昇腾配置中“一颗 Cube 核对应两个 Vector 核”的关系,AutoSubTiling 可以把 Vector 工作拆分为两部分,使两个 Vector 核并行处理各自的任务。
2
14
开源对开发者意味着什么
华为已将 AscendNPU IR 与 Triton-Ascend 开源,用于社区协同开发。Triton-Ascend 是面向昇腾平台的 Triton 编译框架,在保留 Triton 核心语法的同时,增加了针对昇腾 A2、A3 和 950 系列产品的编译与部署支持。
30
37
这为开发者参与编译 Pass、前端接入、算子 lowering 和硬件感知优化提供了更直接的入口。相关社区计划包括与代码仓库关联的实习项目和任务制奖励;开发者可按照项目规则认领列出的任务并提交成果。
31
没有本地昇腾硬件的开发者,据报道可以使用昇腾社区的 HiDevLab 云环境,并获得 100 个免费算力小时。不过,现有信息没有明确说明具体的资格、验证、有效期或地区可用性,注册时仍应以平台页面公布的条件为准。
31
结语:把硬件复杂度留给编译器
AscendNPU IR 的核心主张并非再创造一种孤立的算子语言,而是提供一个统一的编译接入层:Triton、TileLang 和框架 IR 可以从高层进入,HFusion 负责更广泛的融合与调度,HIVM 则把 Tiles 进一步落实为昇腾设备所需的内存、核心、通信和流水线决策。
5
11
Ascend 950 通过基于寄存器的 SIMD、SIMT 以及更直接的 Cube–Vector 片上路径,扩大了可优化空间。但这些能力能否转化为实际性能,仍取决于算子形状、内存压力、控制流、编译器成熟度和具体芯片。开源则让这些权衡更容易被观察、调试和改进,也为编译器与算子开发者参与昇腾生态建设提供了入口。