有人问我ops-transformer 和 ATB 到底是什么关系我把 FlashAttention 的代码改了ATB 的推理结果怎么也跟着变了这两个仓库在昇腾CANN生态里是上下游关系但它们的边界不是底层和上层那么简单。先搞清楚各自的定位ops-transformer算子的提供方。它的产出是 Ascend C 编写的算子 kernel注册到 CANN 的 AOL 算子库里。你通过torch_npu.npu.flash_attention这种底层 API 可以直接调用它但你得自己管理输入输出、内存布局、数据类型。ATBascend-transformer-boost算子的编排方。它把 ops-transformer 的算子封装成高层 API按 Transformer 模型的结构编排算子的执行顺序自动处理 KV Cache 管理、请求调度、batch 合并这些推理服务必须面对的问题。打个比方ops-transformer 是食材供应商ATB 是餐厅后厨。你可以自己买食材回家做直接调算子 API也可以去餐厅点菜用 ATB 搭建推理服务。食材的质量决定了菜的上限但后厨的火候和节奏决定了出品效率。ATB 怎么调用 ops-transformer 的算子ATB 内部有一个算子映射表。当 ATB 解析到模型的 Attention 层时它会检查当前 CANN 版本是否支持 FlashAttention检查输入的 head_dim 是否满足对齐要求16 的倍数如果满足调用 ops-transformer 的 FlashAttention kernel如果不满足fallback 到标准 Attention 实现这个映射过程对用户透明。你在 ATB 里加载一个 Llama 模型ATB 自动把所有 Attention 层替换成 FlashAttention把所有 MoE 层替换成 MoE 融合算子。你不需要改模型代码。# ATB 方式自动编排算子替换透明fromatbimportLLM modelLLM(meta-llama/Llama-2-7b-hf,devicenpu:0)outputmodel.generate(Hello, world)# 对比直接调算子 API需要自己管理importtorch_npu outtorch_npu.npu.flash_attention(q,k,v)# 你自己处理 KV Cache、batch 等数据流转一次完整的 Transformer 推理数据在 ops-transformer 和 ATB 之间的流转ATB 接收请求 → ATB Token EmbeddingATB 自己实现 → ATB 调用 ops-transformer 的 RotaryEmbedding 融合算子 → ATB 调用 ops-transformer 的 FlashAttention自动管理 KV Cache 传入传出 → ATB 调用 ops-nn 的 LayerNorm → ATB 调用 ops-transformer 的 MergedMatMulMoE 场景 → ATB 调用 ops-blas 的 MatMul普通 FFN → 循环 N 层 → ATB 输出 TokenATB 负责层与层之间的数据传递和内存管理ops-transformer 只管每个算子内部的高效计算。边界在哪里两者最容易出现混淆的地方是融合的归属算子内部融合FlashAttention 把 MatMulSoftmaxMatMul 融成一个 kernel→ ops-transformer 的事算子之间融合FlashAttention 的输出直接送入 LayerNorm中间不落显存→ graph-autofusion 在 GE 编译阶段处理模型级编排KV Cache 管理、请求调度、continuous batching→ ATB 的事如果你发现某个算子在 ATB 里跑的性能不如直接调 API大概率是 ATB 的编排没有触发 graph-autofusion。检查 GE 的编译日志看有没有 autofusion 的记录。一个实际场景你在 ATB 里跑 Llama2-70B 的推理发现 Attention 层比预期慢。怀疑 FlashAttention 没生效。排查步骤看 ATB 的初始化日志搜索FlashAttention关键字如果显示fallback to standard attention检查 head_dimLlama2 是 128满足要求检查 CANN 版本——ATB 0.7 之前对 FlashAttention V2 的支持有 bug升级到 0.8如果日志显示 FlashAttention 已启用但还是慢看 GE 编译日志里有没有 autofusion——FlashAttention 没跟前后算子融合每次都有额外的显存读写什么时候该直接调算子 API大部分场景用 ATB 就够了。但以下情况需要绕过 ATB 直接调 ops-transformer你在做算子开发需要隔离测试单个算子的性能你的模型结构不是标准 Transformer比如混合了 CNN 和 AttentionATB 的编排不支持你需要精细控制算子的 tiling 参数ATB 的默认值不够优如果你在 ATB 里遇到了算子性能问题先别急着优化算子——可能是 ATB 和 ops-transformer 之间的编排没对齐。查日志、查 CANN 版本、查 GE autofusion 记录这三步能解决 80% 的问题。两个仓库在这里https://atomgit.com/cann/ops-transformer
CANN-ops-transformer和ATB-昇腾NPU上算子和加速库怎么配合
有人问我ops-transformer 和 ATB 到底是什么关系我把 FlashAttention 的代码改了ATB 的推理结果怎么也跟着变了这两个仓库在昇腾CANN生态里是上下游关系但它们的边界不是底层和上层那么简单。先搞清楚各自的定位ops-transformer算子的提供方。它的产出是 Ascend C 编写的算子 kernel注册到 CANN 的 AOL 算子库里。你通过torch_npu.npu.flash_attention这种底层 API 可以直接调用它但你得自己管理输入输出、内存布局、数据类型。ATBascend-transformer-boost算子的编排方。它把 ops-transformer 的算子封装成高层 API按 Transformer 模型的结构编排算子的执行顺序自动处理 KV Cache 管理、请求调度、batch 合并这些推理服务必须面对的问题。打个比方ops-transformer 是食材供应商ATB 是餐厅后厨。你可以自己买食材回家做直接调算子 API也可以去餐厅点菜用 ATB 搭建推理服务。食材的质量决定了菜的上限但后厨的火候和节奏决定了出品效率。ATB 怎么调用 ops-transformer 的算子ATB 内部有一个算子映射表。当 ATB 解析到模型的 Attention 层时它会检查当前 CANN 版本是否支持 FlashAttention检查输入的 head_dim 是否满足对齐要求16 的倍数如果满足调用 ops-transformer 的 FlashAttention kernel如果不满足fallback 到标准 Attention 实现这个映射过程对用户透明。你在 ATB 里加载一个 Llama 模型ATB 自动把所有 Attention 层替换成 FlashAttention把所有 MoE 层替换成 MoE 融合算子。你不需要改模型代码。# ATB 方式自动编排算子替换透明fromatbimportLLM modelLLM(meta-llama/Llama-2-7b-hf,devicenpu:0)outputmodel.generate(Hello, world)# 对比直接调算子 API需要自己管理importtorch_npu outtorch_npu.npu.flash_attention(q,k,v)# 你自己处理 KV Cache、batch 等数据流转一次完整的 Transformer 推理数据在 ops-transformer 和 ATB 之间的流转ATB 接收请求 → ATB Token EmbeddingATB 自己实现 → ATB 调用 ops-transformer 的 RotaryEmbedding 融合算子 → ATB 调用 ops-transformer 的 FlashAttention自动管理 KV Cache 传入传出 → ATB 调用 ops-nn 的 LayerNorm → ATB 调用 ops-transformer 的 MergedMatMulMoE 场景 → ATB 调用 ops-blas 的 MatMul普通 FFN → 循环 N 层 → ATB 输出 TokenATB 负责层与层之间的数据传递和内存管理ops-transformer 只管每个算子内部的高效计算。边界在哪里两者最容易出现混淆的地方是融合的归属算子内部融合FlashAttention 把 MatMulSoftmaxMatMul 融成一个 kernel→ ops-transformer 的事算子之间融合FlashAttention 的输出直接送入 LayerNorm中间不落显存→ graph-autofusion 在 GE 编译阶段处理模型级编排KV Cache 管理、请求调度、continuous batching→ ATB 的事如果你发现某个算子在 ATB 里跑的性能不如直接调 API大概率是 ATB 的编排没有触发 graph-autofusion。检查 GE 的编译日志看有没有 autofusion 的记录。一个实际场景你在 ATB 里跑 Llama2-70B 的推理发现 Attention 层比预期慢。怀疑 FlashAttention 没生效。排查步骤看 ATB 的初始化日志搜索FlashAttention关键字如果显示fallback to standard attention检查 head_dimLlama2 是 128满足要求检查 CANN 版本——ATB 0.7 之前对 FlashAttention V2 的支持有 bug升级到 0.8如果日志显示 FlashAttention 已启用但还是慢看 GE 编译日志里有没有 autofusion——FlashAttention 没跟前后算子融合每次都有额外的显存读写什么时候该直接调算子 API大部分场景用 ATB 就够了。但以下情况需要绕过 ATB 直接调 ops-transformer你在做算子开发需要隔离测试单个算子的性能你的模型结构不是标准 Transformer比如混合了 CNN 和 AttentionATB 的编排不支持你需要精细控制算子的 tiling 参数ATB 的默认值不够优如果你在 ATB 里遇到了算子性能问题先别急着优化算子——可能是 ATB 和 ops-transformer 之间的编排没对齐。查日志、查 CANN 版本、查 GE autofusion 记录这三步能解决 80% 的问题。两个仓库在这里https://atomgit.com/cann/ops-transformer
