理解 ops-transformer 在昇腾NPU架构中的位置把大模型算子放进厨房里讲有个做后端的朋友问我“我装了 CANN跑了 PyTorch 模型NPU 也认到了但我不理解 ops-transformer 到底在哪一层——它是我的模型代码的一部分还是 CANN 的一部分还是昇腾硬件的一部分”这个问题太常见了。我当时是这么跟他解释的。先把整个系统想象成一个厨房你的大模型比如 LLaMA就是一份菜谱。菜谱上写着先炒鸡蛋再加西红柿最后出锅——这对应模型代码里的 forward 计算图。昇腾 NPU 是厨房里的灶台。灶台本身只认一种指令——“点火”“调火”“关火”不认把鸡蛋炒到七分熟这种人类语言。那问题来了菜谱怎么变成灶台能懂的操作昇腾异构计算架构 CANN 就是中间那层翻译。它把你的模型代码翻译成 NPU 能执行的指令再调度算子真正在硬件上跑起来。ops-transformer 是这整套流程里专门负责炒蛋那个步骤的专用锅具。FlashAttention、MoE、MC2 这些算子就是这个锅具里的核心功能。五层架构的通俗版解释CANN 五层架构听起来吓人但其实每层干的事情一句话就能说清楚第一层AscendCL——这是给应用层用的接口。你可以把它理解为厨房的控制面板上面有开火“调温”定时几个按钮。你写 Python 代码调用torch.npu()的时候其实就是在按这个控制面板。第二层AOL 算子库——这是真正能干活的地方。算子库里有几百个现成的算子每个算子对应一种常见的计算操作。ops-transformer 就在这一层它提供 FlashAttention、MoE 这些大模型训练里用得最多的算子。第三层Graph CompilerGE——这是灶台旁边的自动炒菜机。它把你的整个计算图所有算子的组合做一个全局优化哪里可以合并、哪里可以跳过、哪里需要重新排顺序让整个流程跑得更快。GE 会做算子融合——本来要分三步走的计算合并成一步直接在芯片上跑省掉中间来回搬数据的时间。第四层Runtime——这是调度员。它负责把计算任务分配到具体的 NPU 计算单元上决定谁先跑谁后跑多个任务怎么排队怎么管理显存。第五层硬件驱动——这是灶台的底层电路。ops-transformer 在第二层处于一个承上启下的位置上层被 GE 的算子融合优化调用下层依赖 opbase 提供的基础算子组件。算子从模型代码到 NPU 执行的全过程用一个具体例子说清楚这个流程。当你用 PyTorch 写一行output attention(q, k, v)时背后发生的事情大概是这个顺序第一步Framework Adaptor 注册算子。PyTorch 的npu()调用会通过 CANN 的框架适配层把 ops-transformer 里的 FlashAttention 算子注册到系统中。这一步做的是告诉系统我需要这个算子它在哪里。第二步GE 图编译。CANN 的图编译器拿到完整的计算图开始做优化。它发现 FlashAttention 这个算子可以用 ops-transformer 里的融合版本实现不需要分别调用 MatMul → Softmax → MatMul 三个算子于是把三个算子合并成一次调用。这就是 GE 做的事——全局视角的算子融合和调度优化。第三步Runtime 调度。优化后的算子被拆分成具体的计算任务按时间片分配给 NPU 的 Cube 计算单元矩阵乘专用和 Vector 计算单元向量操作专用。算子的输入数据从 HBM 加载到片上统一缓冲区UB计算在 UB 内完成结果写回 HBM。第四步ops-transformer 执行。具体到 FlashAttention 的实现它在 UB 内完成 tile 级别的 QK^T → Softmax → 乘 V 的全部计算利用昇腾 NPU 的异步搬运能力把下一个 tile 的数据提前预加载进来数据搬运和计算并行。这四步中ops-transformer 只负责第四步——真正的计算执行。前三步由其他组件完成但正是这种分层设计让系统可以分别优化、灵活组合。理解这个分层有什么实际用处知道 ops-transformer 在第二层不是为了考试是为了解决实际问题。当你发现训练速度不达预期时你不会直接去看 ops-transformer 的源码而是先用 CANN Profiler 抓一次 trace看 GE 的算子融合有没有生效、AOE 调优引擎有没有把瓶颈算子做特殊优化。等你确认问题出在 FlashAttention 本身没被正确调用时再去看 ops-transformer 的实现。反过来如果你发现某个算子在 ops-transformer 里没有对应的融合实现而你需要手动改一个融合策略那你需要往 GE 层去了解算子融合的规则是什么、怎么注册自定义融合 pass——这是另一个层级的事情。分层架构的核心价值在于每一层都有自己的关注点定位清晰出了问题知道往哪找。ge 和 runtime 在 ops-transformer 场景里的实际角色有人问ops-transformer 跟 GE 是什么关系跟 Runtime 又是什么关系简单说ops-transformer 是被调用的对象GE 是优化器Runtime 是调度员。当你没有 GE 时ops-transformer 的算子还是能跑——一次调一个按顺序执行。但加了 GE 之后GE 会把你的模型里所有算子做一个全局视图的优化决定 ops-transformer 里的哪些算子可以被合并、哪些可以跳过、哪些需要重排执行顺序。Runtime 则负责把这些决策变成具体的时间片分配让多个算子在不同计算单元上并行。GE 和 Runtime 属于 CANN 第三层和第四层的基础设施不属于 ops-transformer 本身。但你在学习 ops-transformer 时需要了解它们是怎么影响算子执行的——不然你调 API 的时候完全不知道背后发生了什么。为什么这整套架构值得学说一个实际的理由。过去要搞懂这套东西要么参加华为的官方培训要么有内部渠道才能接触文档。2025年8月昇腾CANN 全面开源之后整个体系全部在 AtomGit 上公开了——GE 的源码、Runtime 的实现、ops-transformer 的算子代码、cann-learning-hub 的全套教程。也就是说现在你完全可以通过自学搞清楚一条从应用层到硬件层的完整链路。以前这是需要内部权限才能做到的事情。你现在缺的只是时间和耐心不是资源。怎么开始学建议从 cann-learning-hub 的架构概览开始先把五层架构搞清楚。然后选一个你关心的具体场景比如大模型训练顺着 cann-samples 的 FlashAttention 示例跑通一次调用。再往后是读 ops-transformer 的源码理解融合算子的内部实现。学完这一圈你会对整个系统有完全不同的理解——不再是一个调用 PyTorch 的黑盒而是一套有层次、有逻辑、有分工的工程体系。相关仓库https://atomgit.com/cann/ops-transformerhttps://atomgit.com/cann/cann-learning-hubhttps://atomgit.com/cann/ge
理解 ops-transformer 在昇腾NPU架构中的位置：把大模型算子放进厨房里讲
理解 ops-transformer 在昇腾NPU架构中的位置把大模型算子放进厨房里讲有个做后端的朋友问我“我装了 CANN跑了 PyTorch 模型NPU 也认到了但我不理解 ops-transformer 到底在哪一层——它是我的模型代码的一部分还是 CANN 的一部分还是昇腾硬件的一部分”这个问题太常见了。我当时是这么跟他解释的。先把整个系统想象成一个厨房你的大模型比如 LLaMA就是一份菜谱。菜谱上写着先炒鸡蛋再加西红柿最后出锅——这对应模型代码里的 forward 计算图。昇腾 NPU 是厨房里的灶台。灶台本身只认一种指令——“点火”“调火”“关火”不认把鸡蛋炒到七分熟这种人类语言。那问题来了菜谱怎么变成灶台能懂的操作昇腾异构计算架构 CANN 就是中间那层翻译。它把你的模型代码翻译成 NPU 能执行的指令再调度算子真正在硬件上跑起来。ops-transformer 是这整套流程里专门负责炒蛋那个步骤的专用锅具。FlashAttention、MoE、MC2 这些算子就是这个锅具里的核心功能。五层架构的通俗版解释CANN 五层架构听起来吓人但其实每层干的事情一句话就能说清楚第一层AscendCL——这是给应用层用的接口。你可以把它理解为厨房的控制面板上面有开火“调温”定时几个按钮。你写 Python 代码调用torch.npu()的时候其实就是在按这个控制面板。第二层AOL 算子库——这是真正能干活的地方。算子库里有几百个现成的算子每个算子对应一种常见的计算操作。ops-transformer 就在这一层它提供 FlashAttention、MoE 这些大模型训练里用得最多的算子。第三层Graph CompilerGE——这是灶台旁边的自动炒菜机。它把你的整个计算图所有算子的组合做一个全局优化哪里可以合并、哪里可以跳过、哪里需要重新排顺序让整个流程跑得更快。GE 会做算子融合——本来要分三步走的计算合并成一步直接在芯片上跑省掉中间来回搬数据的时间。第四层Runtime——这是调度员。它负责把计算任务分配到具体的 NPU 计算单元上决定谁先跑谁后跑多个任务怎么排队怎么管理显存。第五层硬件驱动——这是灶台的底层电路。ops-transformer 在第二层处于一个承上启下的位置上层被 GE 的算子融合优化调用下层依赖 opbase 提供的基础算子组件。算子从模型代码到 NPU 执行的全过程用一个具体例子说清楚这个流程。当你用 PyTorch 写一行output attention(q, k, v)时背后发生的事情大概是这个顺序第一步Framework Adaptor 注册算子。PyTorch 的npu()调用会通过 CANN 的框架适配层把 ops-transformer 里的 FlashAttention 算子注册到系统中。这一步做的是告诉系统我需要这个算子它在哪里。第二步GE 图编译。CANN 的图编译器拿到完整的计算图开始做优化。它发现 FlashAttention 这个算子可以用 ops-transformer 里的融合版本实现不需要分别调用 MatMul → Softmax → MatMul 三个算子于是把三个算子合并成一次调用。这就是 GE 做的事——全局视角的算子融合和调度优化。第三步Runtime 调度。优化后的算子被拆分成具体的计算任务按时间片分配给 NPU 的 Cube 计算单元矩阵乘专用和 Vector 计算单元向量操作专用。算子的输入数据从 HBM 加载到片上统一缓冲区UB计算在 UB 内完成结果写回 HBM。第四步ops-transformer 执行。具体到 FlashAttention 的实现它在 UB 内完成 tile 级别的 QK^T → Softmax → 乘 V 的全部计算利用昇腾 NPU 的异步搬运能力把下一个 tile 的数据提前预加载进来数据搬运和计算并行。这四步中ops-transformer 只负责第四步——真正的计算执行。前三步由其他组件完成但正是这种分层设计让系统可以分别优化、灵活组合。理解这个分层有什么实际用处知道 ops-transformer 在第二层不是为了考试是为了解决实际问题。当你发现训练速度不达预期时你不会直接去看 ops-transformer 的源码而是先用 CANN Profiler 抓一次 trace看 GE 的算子融合有没有生效、AOE 调优引擎有没有把瓶颈算子做特殊优化。等你确认问题出在 FlashAttention 本身没被正确调用时再去看 ops-transformer 的实现。反过来如果你发现某个算子在 ops-transformer 里没有对应的融合实现而你需要手动改一个融合策略那你需要往 GE 层去了解算子融合的规则是什么、怎么注册自定义融合 pass——这是另一个层级的事情。分层架构的核心价值在于每一层都有自己的关注点定位清晰出了问题知道往哪找。ge 和 runtime 在 ops-transformer 场景里的实际角色有人问ops-transformer 跟 GE 是什么关系跟 Runtime 又是什么关系简单说ops-transformer 是被调用的对象GE 是优化器Runtime 是调度员。当你没有 GE 时ops-transformer 的算子还是能跑——一次调一个按顺序执行。但加了 GE 之后GE 会把你的模型里所有算子做一个全局视图的优化决定 ops-transformer 里的哪些算子可以被合并、哪些可以跳过、哪些需要重排执行顺序。Runtime 则负责把这些决策变成具体的时间片分配让多个算子在不同计算单元上并行。GE 和 Runtime 属于 CANN 第三层和第四层的基础设施不属于 ops-transformer 本身。但你在学习 ops-transformer 时需要了解它们是怎么影响算子执行的——不然你调 API 的时候完全不知道背后发生了什么。为什么这整套架构值得学说一个实际的理由。过去要搞懂这套东西要么参加华为的官方培训要么有内部渠道才能接触文档。2025年8月昇腾CANN 全面开源之后整个体系全部在 AtomGit 上公开了——GE 的源码、Runtime 的实现、ops-transformer 的算子代码、cann-learning-hub 的全套教程。也就是说现在你完全可以通过自学搞清楚一条从应用层到硬件层的完整链路。以前这是需要内部权限才能做到的事情。你现在缺的只是时间和耐心不是资源。怎么开始学建议从 cann-learning-hub 的架构概览开始先把五层架构搞清楚。然后选一个你关心的具体场景比如大模型训练顺着 cann-samples 的 FlashAttention 示例跑通一次调用。再往后是读 ops-transformer 的源码理解融合算子的内部实现。学完这一圈你会对整个系统有完全不同的理解——不再是一个调用 PyTorch 的黑盒而是一套有层次、有逻辑、有分工的工程体系。相关仓库https://atomgit.com/cann/ops-transformerhttps://atomgit.com/cann/cann-learning-hubhttps://atomgit.com/cann/ge
