算子融合推荐

UB算子融合

模型转换过程中，存在各种原因，造成算子融合失败。如：

• 算子计算的数据超过UB大小。
• 当前算子融合规则未覆盖（参见《图融合和UB融合规则参考》）。

当OM模型非常复杂时，如包含几千个计算节点时，靠肉眼定位到可融合算子耗时耗力。模型转换工具规则不能匹配所有场景，融合规则有遗漏。

UB算子融合推荐功能以OM离线模型文件作为输入数据，自动发现OM模型中的可融合算子，发现算子融合遗漏的场景，提供算子融合建议。

首层算子融合

在load3dv2支持输入通道非16/32对齐的场景，可以直接支持4通道卷积，极大减少MTE2与cube运算。该模式在非AIPP场景下，算子首层需要cast和trans_data算子进行图片的数据类型转换和数据排布格式转换，在C0=4的场景下，trans_data算子性能恶化严重，此时整网性能恶化严重。若改为AIPP场景，此时网络首层会进行AIPP+conv融合或AIPP+conv+maxpooling融合，由于一般首层16通道卷积的耗时占比整网的10%左右，此时开启small channel模式会大幅提升整网性能。

首层算子融合以OM离线模型文件作为输入数据，自动发现OM模型中可优化的数据预处理算子，使能AIPP，提升性能。

L2融合（动态Batch切分）

在整网中，由于某些算子层为L2融合，数据量较大（包含输入和输出数据），超出L2的空间，会引发DDR（DDR主要统计读写带宽，在Analysis Summary中以表格形式呈现）写回的操作；而DDR的带宽远小于L2，造成MTE2 bound严重，同时可能进一步引发流水问题。

以resnet50_int8_8batch为例：

理论上8batch的单算子计算耗时小于等于2倍4batch单算子计算耗时，但如果8batch各层的算子为L2融合，导致数据量变大，造成L2 cache空间不足，产生DDR写回情况，引发算子性能恶化。

如表1所示，可以看到8batch的算子计算耗时远超过4batch算子的2倍，算子性能恶化较严重。

专家系统工具通过分析OM模型中的各层算子，以及读取op_summary.csv数据，识别并输出L2融合且未达到性能瓶颈的算子。需要对这些算子进行切分以实现每层算子的数据均不超过L2的范围，防止DDR写回的情况发生。