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

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

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

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

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

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

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

怎么理解"无感替换"？看这段代码：

# 老程序员熟悉的 PyTorch 原生写法
import torch.nn.functional as F

output = F.scaled_dot_product_attention(
    q, k, v,
    attn_mask=None,
    dropout_p=0.0,
    is_causal=True
)

这段代码在 CPU 和 CUDA 上都能跑，但到了昇腾 NPU，如果只用原生实现，它走的是一个个独立的 MatMul → Softmax → MatMul 算子。换成 ops-transformer 的方式，只需要改一个 import：

# 换成 ops-transformer 的算子（调用方式几乎一样）
from torch.nn.functional import scaled_dot_product_attention as sdpa

# 实际上 PyTorch 会通过 Framework Adaptor 把这个调用路由到
# ops-transformer 的融合 FlashAttention 算子
output = sdpa(q, k, v, is_causal=True)

# 验证算子是否走的是融合路径（Profiler 里看）
# 如果 timeline 上出现 FlashAttentionKernel 的大色块 → 融合已生效
# 如果看到三个小色块 MatMul / Softmax / MatMul 紧挨着 → 没有融合

这就是"酱料包"的含义：你不用自己调底层的调味，官方已经按最优比例配好了，直接拆开用就行。调用接口和你平时的习惯几乎一样，但底层执行的已经是高度优化的融合算子。

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

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

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

怎么验证 GE 在"拼菜"？开启融合日志看看：

# 开启 GE 的详细融合日志
export ASCEND_GLOBAL_LOG_LEVEL=3
export GE_OP_TRACE=1

# 跑一次训练脚本，看日志输出
python train_llama.py 2>&1 | grep -E "(Fusion|merge|combine|flash_attention)"

# 成功的日志长这样：
# [GE] 检测到算子序列: MatMul → Softmax → MatMul
# [GE] 匹配融合规则: flash_attention_fusion_pass
# [GE] 融合为单一算子: FlashAttentionKernel (耗时节省 3.2ms)

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

对比有融合和没有融合的 timeline：

# 没有 GE 融合的 timeline（每个算子单独执行）
# MatMul[qkt]  ████████
# Softmax      ██████
# MatMul[pvt]  ██████████
# 总耗时 = 三个算子时间之和 + HBM 读写开销（每个算子读一次、写一次）

# 有 GE 融合的 timeline（三个算子合并为一个）
# FlashAttentionKernel  ████████████████████████████
# 总耗时 = 一个融合算子时间 + 一次 HBM 读 + 一次 HBM 写
# 中间结果不用写回 HBM，直接在 UB 内传递 → 节省两次 HBM 读写

Runtime 是一个"调度催菜员"

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

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

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

Runtime 的调度效率怎么看：

# 用 npu-smi 实时看 NPU 利用率和数据搬运占比
watch -n 1 npu-smi dmon -c 0 -s puc,mem

# 计算占比高（>80%）→ Runtime 的 overlap 做得好，数据搬运和计算并行
# 搬运占比高、计算占比低 → 数据等待时间太长，Runtime 调度效率差

# 另一个指标：显存使用是否稳定
npu-smi dmon -c 0 -s mem

# 如果显存一直在 70%~95% 之间小幅波动 → Runtime 的内存复用正常
# 如果显存频繁接近 100% 然后突然下降 → 频繁分配/释放，Runtime 在做内存整理

Runtime 在 tile 级计算里的具体分工：

# ops-transformer 的 FlashAttention 在 UB 上做 tile 级计算
# Runtime 的工作是把每一个 tile 的流程排好

# tile 级执行的时序（Runtime 调度）：
# tile_0: 数据 HBM→UB（Runtime 发起） → 计算（Cube 执行） → 结果 UB→HBM（Runtime 发起）
# tile_1: 数据 HBM→UB（Runtime 在 tile_0 计算时预加载） → 计算（Cube 执行）
#         ↑ Runtime 的 overlap：tile_0 计算时，tile_1 的数据已经开始搬运

# 验证 overlap 是否生效：用 Profiler 看 timeline
with profile(activities=[ProfilerActivity.NPU], export_name="tile_overlap.json"):
    output = sdpa(q, k, v)

# 在 Profiler GUI 的 timeline 里看：
# 如果搬运色块和计算色块有重叠区域 → Runtime overlap 在工作
# 如果搬运色块和计算色块完全分开 → 数据搬运阻塞了计算

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

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

CANN 是昇腾异构计算架构的名字，它把整个 NPU 软件栈分成了五层：

# 用代码验证这五层的实际存在
# 想象成后厨的五个工种

# 第一层：AscendCL（控制面板）
import acl
ret = acl.init()
print("控制面板已开启，厨师知道灶台可以用")  # 第一层

# 第二层：ops-transformer（AOL 算子库）
from flash_attention_ops import flash_attention_npu
print("酱料包已就位，核心调料已配好")  # 第二层

# 第三层：GE（图融合引擎）
# GE 在后台自动把多个算子拼成一个，算子本身感觉不到
print("拼菜师傅在后台协调，厨师不需要管")
# 第二层和第三层的关系：算子不知道自己被融合了，是 GE 自动做的

# 第四层：Runtime（调度催菜员）
# Runtime 在运行时决定谁先做、数据什么时候搬、结果什么时候写回去
torch.npu.synchronize()  # Runtime 把所有任务排好序，现在等着收结果
print("催菜员已经协调好出餐顺序，厨房运转有序")

# 第五层：硬件驱动（NPU 芯片）
# 灶台本身，酱油醋糖盐鸡精，最后都在这里变成菜
# 这一层 ops-transformer 的开发者通常不需要直接接触

从第一层到第五层，你只需要关心两层：第二层（ops-transformer 算子）和第四层（Runtime 调度）——其余的 GE、硬件驱动、系统适配都已经封装好了。

# 快速验证你的环境里五层是否都正常
python -c "
import torch, acl

# 检查五层
print('第一层 AscendCL:', acl.__version__ if hasattr(acl, '__version__') else '可用')
print('第二层 ops-transformer:', end=' ')
try:
    from flash_attention_ops import flash_attention_npu
    print('已注册')
except: print('未注册（执行 pip install -e .）')

print('第三层 GE: 通过 Profiler 的 [GE Fusion] 日志验证')
print('第四层 Runtime: torch.npu.is_available() =', torch.npu.is_available())
print('第五层硬件:', end=' ')
import subprocess
r = subprocess.run(['npu-smi', 'info'], capture_output=True, text=True)
print('NPU 可用' if r.returncode == 0 else 'NPU 不可用')
"

这个仓库适合什么人用

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

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

相关仓库：

https://atomgit.com/cann/ops-transformer

https://atomgit.com/cann/cann-learning-hub

https://atomgit.com/cann/ge