陷阱一：忽略数据依赖的“伪融合”——你以为合了，其实没合

做AI芯片算子融合，我踩过的第一个大坑就是“伪融合”。

什么叫伪融合？说白了，就是你在编译器层面把两个算子写成了一个kernel，看起来代码合在一起了，但实际运行时，数据还在兜圈子，根本没享受到融合带来的带宽红利。

伪融合是怎么发生的？

先看一个典型场景。你有一个卷积层，后面跟着一个ReLU激活。直觉告诉你，这俩必须融合。于是你写了个融合算子，把卷积和ReLU塞进同一个循环里。

// 伪代码示例：看起来融合了
for (int i = 0; i < N; i++) {
    conv_out[i] = conv_compute(input, weight, i);
    relu_out[i] = max(0, conv_out[i]);
}

嗯，代码确实在一个循环里。但问题来了——conv_out[i] 这个中间结果，它存在哪里？

如果你的硬件没有足够的本地寄存器或共享内存，这个中间结果会被写回全局DRAM，然后下一行又从DRAM读出来。你想想看，这跟分开执行两个算子有什么区别？

我在项目中遇到过的真实案例

有一次，我们团队优化一个MobileNetV3的推理延迟。模型里有很多“卷积+BN+ReLU”的组合。我信心满满地做了算子融合，结果性能只提升了5%。

排查了一整天，最后发现：BN层的缩放因子和偏移量存在片外，每次计算都要从DRAM拉数据。虽然循环写在一起了，但数据依赖链上有个“断点”——BN的参数读取操作把流水线卡死了。

说白了，融合算子内部藏了一个隐式的全局内存访问。这个访问的延迟，把融合带来的好处全吃掉了。

如何识别伪融合？

我个人习惯用三个指标来检查：

你可以在编译器的中间表示（IR）层面，直接追踪每个张量的内存层级。如果融合后的IR中，某个中间张量依然被标记为“global”或“dram”，那基本就是伪融合。

避坑指南：我曾经犯过的错

我曾经在写融合pass时，只检查了算子之间的拓扑顺序，没检查数据依赖的内存别名。结果两个算子虽然计算上依赖，但其中一个算子的输出被另一个算子原地修改了——这导致融合后的结果完全错误。

所以我现在做融合时，一定会做三件事：

1. 画数据流图：把每个中间张量的生命周期标出来，看它是否跨越了内存层级边界。
2. 检查内存别名：确保融合后的读写操作不会互相覆盖。
3. 做微基准测试：单独测融合算子的带宽利用率，如果低于硬件峰值的80%，就要怀疑是不是伪融合。

核心逻辑：一张图看懂伪融合

下面这张图展示了伪融合和真融合在数据流上的本质区别：

从图上可以清楚看到：伪融合的中间数据绕了一圈全局内存，而真融合的数据直接在片上传递。这个差别，在延迟上可能是几十倍。

总结一下

伪融合是AI芯片优化里最容易犯的错误之一。它看起来很美，但实际收益微乎其微。

我个人建议，每次做完融合优化后，不要只看端到端的性能数字。一定要深入到数据流层面，确认中间结果没有“偷偷”经过全局内存。这个习惯，能帮你省下大量排查性能瓶颈的时间。