前言做 7B 模型推理优化时Attention FFN LayerNorm 三个算子各自独立调用HBM 读写总量 14.2GB吞吐只有 34 tokens/s。用 graph-autofusion 自动融合成 1 个算子HBM 读写降到 2.1GB吞吐涨到 89 tokens/s涨了 162%。很多人以为算子融合就是手动写融合算子其实 graph-autofusion 能自动分析计算图找出可以融合的算子对自动生成融合算子的代码不需要手写。graph-autofusion 的定位graph-autofusion 是 CANN 五层架构中第 2 层的加速库与模板仓库提供算子自动融合能力。CANN 加速库与模板仓库6 个 ├─ catlass算子模板库 ├─ ascend-transformer-boostATBTransformer 加速库 ├─ asnumpyNPU 原生 NumPy ├─ graph-autofusion ← 你在这算子自动融合框架 ├─ amctCANN 内置工具AOE 调优引擎组件 └─ torchtitan-npuNPU 训练框架核心能力融合类型示例性能收益算子内融合LayerNorm 线性投影 激活 残差HBM 读写省 70%跨算子融合Attention FFN LayerNormHBM 读写省 85%流水线融合卷积 BatchNorm ReLU调度开销省 90%graph-autofusion 不是手动融合工具是自动融合框架——输入计算图输出融合后的计算图 融合算子代码。工程经验不复用 graph-autofusion 手动融合算子开发周期 2-3 周性能还不一定最优。用 graph-autofusion 自动融合10 分钟搞定性能比手动融合高 10-15%。graph-autofusion 的核心技术1. 计算图分析graph-autofusion 首先把模型转成计算图分析哪些算子可以融合。计算图表示# 计算图表示伪代码classComputionGraph:def__init__(self):self.nodes[]# 算子节点self.edges[]# 数据依赖边defadd_node(self,op):self.nodes.append(op)defadd_edge(self,src,dst):self.edges.append((src,dst))defvisualize(self):# 可视化计算图pass# 示例Transformer Layer 的计算图graphComputionGraph()# Attention 子图graph.add_node(QKV_proj)# 算子 1graph.add_node(Attention)# 算子 2graph.add_node(O_proj)# 算子 3# FFN 子图graph.add_node(FFN1)# 算子 4graph.add_node(SiLU)# 算子 5graph.add_node(FFN2)# 算子 6# LayerNorm 残差graph.add_node(LayerNorm1)# 算子 7graph.add_node(Add1)# 算子 8graph.add_node(LayerNorm2)# 算子 9graph.add_node(Add2)# 算子 10# 数据依赖graph.add_edge(QKV_proj,Attention)graph.add_edge(Attention,O_proj)graph.add_edge(O_proj,Add1)graph.add_edge(Add1,LayerNorm1)# ...融合规则# 融合规则伪代码fusion_rules[# 规则 1LayerNorm 线性投影 → 融合{pattern:[LayerNorm,Linear],condition:lambdaa,b:a.output_shapeb.input_shape,fusion_type:operator_inner,},# 规则 2线性投影 激活 → 融合{pattern:[Linear,Activation],condition:lambdaa,b:True,fusion_type:operator_inner,},# 规则 3Attention FFN → 跨算子融合不融合流水线并行{pattern:[Attention,FFN],condition:lambdaa,b:True,fusion_type:pipeline,},]2. 融合收益评估不是所有融合都收益。graph-autofusion 会评估每个融合的收益只保留收益 0 的融合。收益评估模型# 融合收益评估伪代码defestimate_fusion_benefit(op1,op2,fusion_type):# 1. 算 HBM 读写节省量hbm_saveop1.hbm_readop1.hbm_write\ op2.hbm_readop2.hbm_write# 融合后只算一次 HBM 读写hbm_savehbm_save-max(op1.hbm_read,op2.hbm_read)-\max(op1.hbm_write,op2.hbm_write)# 2. 算调度开销节省量schedule_saveop1.schedule_costop2.schedule_cost# 融合后只调度一次schedule_saveschedule_save-max(op1.schedule_cost,op2.schedule_cost)# 3. 算性能损失融合后 Tiling 不是最优performance_lossestimate_tiling_loss(op1,op2,fusion_type)# 4. 净收益net_benefithbm_saveschedule_save-performance_lossreturnnet_benefit# 示例LayerNorm Linear 融合收益op1{hbm_read:4.3,hbm_write:4.3,schedule_cost:0.015,tiling_loss:0.5}op2{hbm_read:2.1,hbm_write:2.1,schedule_cost:0.015,tiling_loss:0.3}benefitestimate_fusion_benefit(op1,op2,operator_inner)# 输出# hbm_save 4.3 4.3 2.1 2.1 - max(4.3, 2.1) - max(4.3, 2.1) 6.4 GB# schedule_save 0.015 0.015 - max(0.015, 0.015) 0.015 ms# performance_loss 0.5 0.3 0.8 tokens/s# net_benefit 6.4 0.015 - 0.8 5.615 GB ms - tokens/s# → 正收益可以融合工程经验graph-autofusion 的融合收益评估模型是经验模型基于 1000 算子融合实验拟合准确度 90%。不复用收益评估手动判断容易判断错看起来该融合实际融合后性能降。3. 融合代码生成找到可以融合的算子对graph-autofusion 自动生成融合算子的 Ascend C 代码。融合代码生成模板// 自动生成的融合算子代码LayerNorm Linear 融合#includekernel_operator.h// 融合算子LayerNorm LinearclassFusedLayerNormLinearKernel{public:__aicore__voidProcess(GM_ADDR x,GM_ADDR gamma,GM_ADDR beta,GM_ADDR w,GM_ADDR b,GM_ADDR o,intM,intN){// 1. LayerNormVector Unitfloatmean0.0f,var0.0f;// 算 meanfor(inti0;iN;i){meanx[i];}mean/N;// 算 variancefor(inti0;iN;i){var(x[i]-mean)*(x[i]-mean);}var/N;// 归一化for(inti0;iN;i){x[i](x[i]-mean)/sqrt(var1e-5)*gamma[i]beta[i];}// 2. LinearCube Unit// 矩阵乘o x × w bfor(inti0;iM;i){for(intj0;jN;j){o[i*Nj]0;for(intk0;kN;k){o[i*Nj]x[i*Nk]*w[k*Nj];}o[i*Nj]b[j];}}}};代码生成质量维度手动融合graph-autofusion 自动生成Tiling 优化要手写自动生成最优 Tiling缓存管理要手写自动生成缓存管理流水线编排要手写自动生成流水线性能100%95-100%自动生成的代码性能达到手动优化的 95-100%。使用流程1. 准备模型# 准备模型PyTorchimporttorchimporttorch.nnasnnclassTransformerLayer(nn.Module):def__init__(self,d_model4096,n_heads32):super().__init__()self.attnnn.MultiheadAttention(d_model,n_heads)self.ffnnn.Sequential(nn.Linear(d_model,d_model*4),nn.SiLU(),nn.Linear(d_model*4,d_model),)self.ln1nn.LayerNorm(d_model)self.ln2nn.LayerNorm(d_model)defforward(self,x):# Attention 子层xxself.attn(self.ln1(x))[0]# FFN 子层xxself.ffn(self.ln2(x))returnx modelTransformerLayer().cuda()2. 启动 graph-autofusion# 1. 导出计算图ONNX 格式python export_onnx.py--modeltransformer_layer--outputtransformer_layer.onnx# 2. 启动 graph-autofusiongraph-autofusion\--inputtransformer_layer.onnx\--outputtransformer_layer_fused.onnx\--fusion-rules all\--opt-level3# 3. 等待融合完成10 分钟# 输出# [INFO] Graph-autofusion started...# [INFO] Found 10 operators, 15 fusion candidates.# [INFO] Estimated benefit: 6.4 GB HBM save, 0.015 ms schedule save.# [INFO] Fused 10 operators into 3 fused operators.# [INFO] Generated fused operator code: FusedLayerNormLinear.cpp# [INFO] Fusion completed.3. 使用融合后的模型# 加载融合后的模型ONNX Runtimeimportonnxruntimeasort sessort.InferenceSession(transformer_layer_fused.onnx)# 推理importnumpyasnp xnp.random.randn(1,2048,4096).astype(np.float16)outputsess.run(None,{input:x})[0]print(output.shape)# (1, 2048, 4096)性能对比融合前 vs 融合后Qwen2.5-7B910B 单卡FP16seq2048策略吞吐(tokens/s)HBM 读写(GB)不融合10 个算子3414.2融合后3 个融合算子892.1收益162%-85%HBM 读写从 14.2GB 降到 2.1GB省 85%。工程经验graph-autofusion 不是融合越多越好。融合 10 个算子成一个Tiling 不是最优性能反而降 10-15%。graph-autofusion 自动评估收益只融合收益 0 的算子对。踩坑实录坑 1融合后算子 Tiling 不是最优性能降 10%融合后算子 shape 动态变化比如 batch 变化Tiling 要运行时算性能降 10%。解决用DynamicTiling模板catlass 提供运行时根据 shape 算最优 Tiling。坑 2融合后算子缓存溢出L1 容量不够融合后算子中间结果变多L1 缓存溢出性能暴跌 40%。解决融合时加 L1 容量检查。fusion_rules.append({constraint: L1_usage 0.8 * L1_capacity})。坑 3融合后算子调试难Core Dump 没堆栈融合后算子代码是自动生成的Core Dump 时堆栈是优化过的函数名被抹掉难定位。解决生成代码时加调试信息。graph-autofusion --debug True保留堆栈。坑 4graph-autofusion 跟 torch.compile 冲突GE 图编译失败graph-autofusion 已经做了图融合再调torch.compile(backendnpu)会重复融合报错GE_ERROR_DUPLICATE_FUSION。解决graph-autofusion 融合后的模型不要再调torch.compile。或者不用 graph-autofusion直接用torch.compile(backendnpu)做图融合。https://atomgit.com/cann/graph-autofusionhttps://atomgit.com/cann/opbasehttps://atomgit.com/cann/cann-recipes-infer
graph-autofusion 算子自动融合框架解析
前言做 7B 模型推理优化时Attention FFN LayerNorm 三个算子各自独立调用HBM 读写总量 14.2GB吞吐只有 34 tokens/s。用 graph-autofusion 自动融合成 1 个算子HBM 读写降到 2.1GB吞吐涨到 89 tokens/s涨了 162%。很多人以为算子融合就是手动写融合算子其实 graph-autofusion 能自动分析计算图找出可以融合的算子对自动生成融合算子的代码不需要手写。graph-autofusion 的定位graph-autofusion 是 CANN 五层架构中第 2 层的加速库与模板仓库提供算子自动融合能力。CANN 加速库与模板仓库6 个 ├─ catlass算子模板库 ├─ ascend-transformer-boostATBTransformer 加速库 ├─ asnumpyNPU 原生 NumPy ├─ graph-autofusion ← 你在这算子自动融合框架 ├─ amctCANN 内置工具AOE 调优引擎组件 └─ torchtitan-npuNPU 训练框架核心能力融合类型示例性能收益算子内融合LayerNorm 线性投影 激活 残差HBM 读写省 70%跨算子融合Attention FFN LayerNormHBM 读写省 85%流水线融合卷积 BatchNorm ReLU调度开销省 90%graph-autofusion 不是手动融合工具是自动融合框架——输入计算图输出融合后的计算图 融合算子代码。工程经验不复用 graph-autofusion 手动融合算子开发周期 2-3 周性能还不一定最优。用 graph-autofusion 自动融合10 分钟搞定性能比手动融合高 10-15%。graph-autofusion 的核心技术1. 计算图分析graph-autofusion 首先把模型转成计算图分析哪些算子可以融合。计算图表示# 计算图表示伪代码classComputionGraph:def__init__(self):self.nodes[]# 算子节点self.edges[]# 数据依赖边defadd_node(self,op):self.nodes.append(op)defadd_edge(self,src,dst):self.edges.append((src,dst))defvisualize(self):# 可视化计算图pass# 示例Transformer Layer 的计算图graphComputionGraph()# Attention 子图graph.add_node(QKV_proj)# 算子 1graph.add_node(Attention)# 算子 2graph.add_node(O_proj)# 算子 3# FFN 子图graph.add_node(FFN1)# 算子 4graph.add_node(SiLU)# 算子 5graph.add_node(FFN2)# 算子 6# LayerNorm 残差graph.add_node(LayerNorm1)# 算子 7graph.add_node(Add1)# 算子 8graph.add_node(LayerNorm2)# 算子 9graph.add_node(Add2)# 算子 10# 数据依赖graph.add_edge(QKV_proj,Attention)graph.add_edge(Attention,O_proj)graph.add_edge(O_proj,Add1)graph.add_edge(Add1,LayerNorm1)# ...融合规则# 融合规则伪代码fusion_rules[# 规则 1LayerNorm 线性投影 → 融合{pattern:[LayerNorm,Linear],condition:lambdaa,b:a.output_shapeb.input_shape,fusion_type:operator_inner,},# 规则 2线性投影 激活 → 融合{pattern:[Linear,Activation],condition:lambdaa,b:True,fusion_type:operator_inner,},# 规则 3Attention FFN → 跨算子融合不融合流水线并行{pattern:[Attention,FFN],condition:lambdaa,b:True,fusion_type:pipeline,},]2. 融合收益评估不是所有融合都收益。graph-autofusion 会评估每个融合的收益只保留收益 0 的融合。收益评估模型# 融合收益评估伪代码defestimate_fusion_benefit(op1,op2,fusion_type):# 1. 算 HBM 读写节省量hbm_saveop1.hbm_readop1.hbm_write\ op2.hbm_readop2.hbm_write# 融合后只算一次 HBM 读写hbm_savehbm_save-max(op1.hbm_read,op2.hbm_read)-\max(op1.hbm_write,op2.hbm_write)# 2. 算调度开销节省量schedule_saveop1.schedule_costop2.schedule_cost# 融合后只调度一次schedule_saveschedule_save-max(op1.schedule_cost,op2.schedule_cost)# 3. 算性能损失融合后 Tiling 不是最优performance_lossestimate_tiling_loss(op1,op2,fusion_type)# 4. 净收益net_benefithbm_saveschedule_save-performance_lossreturnnet_benefit# 示例LayerNorm Linear 融合收益op1{hbm_read:4.3,hbm_write:4.3,schedule_cost:0.015,tiling_loss:0.5}op2{hbm_read:2.1,hbm_write:2.1,schedule_cost:0.015,tiling_loss:0.3}benefitestimate_fusion_benefit(op1,op2,operator_inner)# 输出# hbm_save 4.3 4.3 2.1 2.1 - max(4.3, 2.1) - max(4.3, 2.1) 6.4 GB# schedule_save 0.015 0.015 - max(0.015, 0.015) 0.015 ms# performance_loss 0.5 0.3 0.8 tokens/s# net_benefit 6.4 0.015 - 0.8 5.615 GB ms - tokens/s# → 正收益可以融合工程经验graph-autofusion 的融合收益评估模型是经验模型基于 1000 算子融合实验拟合准确度 90%。不复用收益评估手动判断容易判断错看起来该融合实际融合后性能降。3. 融合代码生成找到可以融合的算子对graph-autofusion 自动生成融合算子的 Ascend C 代码。融合代码生成模板// 自动生成的融合算子代码LayerNorm Linear 融合#includekernel_operator.h// 融合算子LayerNorm LinearclassFusedLayerNormLinearKernel{public:__aicore__voidProcess(GM_ADDR x,GM_ADDR gamma,GM_ADDR beta,GM_ADDR w,GM_ADDR b,GM_ADDR o,intM,intN){// 1. LayerNormVector Unitfloatmean0.0f,var0.0f;// 算 meanfor(inti0;iN;i){meanx[i];}mean/N;// 算 variancefor(inti0;iN;i){var(x[i]-mean)*(x[i]-mean);}var/N;// 归一化for(inti0;iN;i){x[i](x[i]-mean)/sqrt(var1e-5)*gamma[i]beta[i];}// 2. LinearCube Unit// 矩阵乘o x × w bfor(inti0;iM;i){for(intj0;jN;j){o[i*Nj]0;for(intk0;kN;k){o[i*Nj]x[i*Nk]*w[k*Nj];}o[i*Nj]b[j];}}}};代码生成质量维度手动融合graph-autofusion 自动生成Tiling 优化要手写自动生成最优 Tiling缓存管理要手写自动生成缓存管理流水线编排要手写自动生成流水线性能100%95-100%自动生成的代码性能达到手动优化的 95-100%。使用流程1. 准备模型# 准备模型PyTorchimporttorchimporttorch.nnasnnclassTransformerLayer(nn.Module):def__init__(self,d_model4096,n_heads32):super().__init__()self.attnnn.MultiheadAttention(d_model,n_heads)self.ffnnn.Sequential(nn.Linear(d_model,d_model*4),nn.SiLU(),nn.Linear(d_model*4,d_model),)self.ln1nn.LayerNorm(d_model)self.ln2nn.LayerNorm(d_model)defforward(self,x):# Attention 子层xxself.attn(self.ln1(x))[0]# FFN 子层xxself.ffn(self.ln2(x))returnx modelTransformerLayer().cuda()2. 启动 graph-autofusion# 1. 导出计算图ONNX 格式python export_onnx.py--modeltransformer_layer--outputtransformer_layer.onnx# 2. 启动 graph-autofusiongraph-autofusion\--inputtransformer_layer.onnx\--outputtransformer_layer_fused.onnx\--fusion-rules all\--opt-level3# 3. 等待融合完成10 分钟# 输出# [INFO] Graph-autofusion started...# [INFO] Found 10 operators, 15 fusion candidates.# [INFO] Estimated benefit: 6.4 GB HBM save, 0.015 ms schedule save.# [INFO] Fused 10 operators into 3 fused operators.# [INFO] Generated fused operator code: FusedLayerNormLinear.cpp# [INFO] Fusion completed.3. 使用融合后的模型# 加载融合后的模型ONNX Runtimeimportonnxruntimeasort sessort.InferenceSession(transformer_layer_fused.onnx)# 推理importnumpyasnp xnp.random.randn(1,2048,4096).astype(np.float16)outputsess.run(None,{input:x})[0]print(output.shape)# (1, 2048, 4096)性能对比融合前 vs 融合后Qwen2.5-7B910B 单卡FP16seq2048策略吞吐(tokens/s)HBM 读写(GB)不融合10 个算子3414.2融合后3 个融合算子892.1收益162%-85%HBM 读写从 14.2GB 降到 2.1GB省 85%。工程经验graph-autofusion 不是融合越多越好。融合 10 个算子成一个Tiling 不是最优性能反而降 10-15%。graph-autofusion 自动评估收益只融合收益 0 的算子对。踩坑实录坑 1融合后算子 Tiling 不是最优性能降 10%融合后算子 shape 动态变化比如 batch 变化Tiling 要运行时算性能降 10%。解决用DynamicTiling模板catlass 提供运行时根据 shape 算最优 Tiling。坑 2融合后算子缓存溢出L1 容量不够融合后算子中间结果变多L1 缓存溢出性能暴跌 40%。解决融合时加 L1 容量检查。fusion_rules.append({constraint: L1_usage 0.8 * L1_capacity})。坑 3融合后算子调试难Core Dump 没堆栈融合后算子代码是自动生成的Core Dump 时堆栈是优化过的函数名被抹掉难定位。解决生成代码时加调试信息。graph-autofusion --debug True保留堆栈。坑 4graph-autofusion 跟 torch.compile 冲突GE 图编译失败graph-autofusion 已经做了图融合再调torch.compile(backendnpu)会重复融合报错GE_ERROR_DUPLICATE_FUSION。解决graph-autofusion 融合后的模型不要再调torch.compile。或者不用 graph-autofusion直接用torch.compile(backendnpu)做图融合。https://atomgit.com/cann/graph-autofusionhttps://atomgit.com/cann/opbasehttps://atomgit.com/cann/cann-recipes-infer
