ops-transformer 是什么：五句话让一个完全不懂的人听明白

我有个朋友是做后端的老程序员，最近想转大模型训练方向，跟我说想了解一下昇腾 NPU 的算子生态。他对 PyTorch 熟悉，但没接触过 CANN，问了我一个问题：“ops-transformer 这个仓库到底解决了什么问题？我给他讲了大概二十分钟，最后他跟我说："你能不能用五句话概括？"我试了一下，发现做不到——因为这个仓库解决的不是一个问题，而是串联起了一整条链路上的多个问题。但我可以换一种方式

解局易否结局

36人浏览 · 2026-05-22 16:33:40

解局易否结局 · 2026-05-22 16:33:40 发布

我有个朋友是做后端的老程序员，最近想转大模型训练方向，跟我说想了解一下昇腾 NPU 的算子生态。他对 PyTorch 熟悉，但没接触过 CANN，问了我一个问题：“ops-transformer 这个仓库到底解决了什么问题？”

我给他讲了大概二十分钟，最后他跟我说："你能不能用五句话概括？"我试了一下，发现做不到——因为这个仓库解决的不是一个问题，而是串联起了一整条链路上的多个问题。但我可以换一种方式，用五个比喻把这整条链路说清楚。

ops-transformer 是一个"后厨酱料包"

想象你要做一桌菜（训练一个大模型），你有两个选择：

第一个选择是你自己从零开始配调料——酱油、醋、糖、盐、鸡精，每一样都自己调。这个选择听起来很灵活，但实际上效率很低，而且每道菜之间的重复工作极多。

第二个选择是去买现成的酱料包，每个酱料包已经按最优比例配好了，直接拆开就能用。你只需要关注火候和摆盘，底下的调味不用管了。

ops-transformer 就是这个酱料包。它不是你自己从零写的算子实现，而是昇腾 NPU 官方优化好的算子集合，专门针对 Transformer 架构下的核心计算做了高性能实现。你把它集成进 PyTorch，调用方式跟你平时写 nn.functional.scaled_dot_product_attention 几乎一样，但实际跑的时候调用的就是昇腾 NPU 上的融合算子，性能差距可能有三到四倍。

GE 是一个"自动拼菜师傅"

光有酱料包还不够。后厨里还有一个问题：每个菜谱上写的步骤都是分步的——先炒 A、再加 B、最后焖 C。但在真实出餐的时候，把 A、B 合并成一步炒出来味道一样，但速度快很多。

GE 就是这个自动拼菜师傅。它在后台看你的整个计算图（由 PyTorch 框架发过来的），发现有好几个步骤可以合并成一个步骤执行，就自动把它们拼在一起。FlashAttention 里的 MatMul → Softmax → MatMul 三步，在 GE 的融合策略下会变成一个算子执行——这就是为什么你用 ops-transformer 的算子，性能会比手写逐个算子快很多的原因。

GE 的融合不是 ops-transformer 本身做的事情，而是 CANN 架构里第三层 GE 图引擎做的事情。ops-transformer 的算子必须能被 GE 识别才能发挥最大价值，所以 ops-transformer 的开发者在设计算子接口的时候，会让接口描述跟 GE 的融合规则完全对齐，确保算子从注册到融合到执行整条链路是顺畅的。

Runtime 是一个"调度催菜员"

菜拼好了，厨师也做了，但后厨还有一个角色必不可少——调度催菜员。TA 的工作是在前台客人催菜的时候，协调后厨的出餐顺序：哪些菜可以同时做、哪些菜必须按顺序做、哪些菜要先做因为后面还有几道在等。

Runtime 在 NPU 系统里就是类似的角色。当 GE 把融合后的算子图交给 Runtime 执行的时候，Runtime 负责决定每个算子的执行顺序、数据什么时候从显存搬到计算单元、计算完之后结果什么时候写回去、多个算子之间的依赖关系怎么处理。

ops-transformer 的算子在执行的时候，Runtime 会把它和数据搬运做成 pipeline——一边让当前 tile 的计算进行，一边把下一个 tile 的数据提前搬到计算单元旁边。这样计算单元基本上不会停下来等数据。这就是 FlashAttention 为什么在长序列场景下特别有效的原因之一。

CANN 是整条链路的底层基础设施

回到刚才那个朋友的问题——"ops-transformer 解决了什么问题？"这个问题如果用一句话回答就是：ops-transformer 让 PyTorch 开发者能无感地调用昇腾 NPU 上经过高度优化的 Transformer 算子，而这些算子之所以快，是因为 CANN 架构里 GE 的融合决策和 Runtime 的调度优化在背后共同发挥作用。

CANN 是昇腾异构计算架构的名字，它把整个 NPU 软件栈分成了五层：从上到下是 Framework Adaptor（框架适配层）、算子库（AOL，ops-transformer 所在的位置）、GE（图引擎）、Runtime（运行时）、最后是硬件驱动。ops-transformer 在第二层，GE 在第三层，Runtime 在第四层——它们互相协作，共同决定了一个算子最终在 NPU 上跑起来有多快。

这个仓库适合什么人用

如果你在用 PyTorch 训练 Transformer 架构的大模型（比如 LLaMA、BERT、ChatGLM），并且你的训练环境是昇腾 NPU，那 ops-transformer 基本上是你能拿到的性能最优的算子实现方案。它不需要你学新的 API，不需要你改训练代码，只需要把对应的 import 换掉、把 PyTorch 原生的 attention 实现替换成 ops-transformer 的版本，性能就会有明显的提升。

如果你是在做算子开发或者调优——比如你想理解一个融合算子是怎么设计出来的、GE 的融合规则是怎么匹配的、Runtime 是怎么处理 tile 级数据搬运的——ops-transformer 的源码也是一个很好的学习对象。它的代码结构相对清晰，而且背后有完整的 CANN 文档体系支撑，知道一个具体实现怎么嵌进整个系统里。