陷阱二：内存墙的“隐形杀手”——融合后带宽不降反升
各位做AI芯片的朋友，咱们接着聊算子融合。上一章我们讲了融合的基本思路，看起来挺美对吧？但我要告诉你一个扎心的事实——融合做不好，带宽反而会涨。
我第一次遇到这个问题，是在一个边缘推理芯片的项目上。当时团队花了两周做融合优化，跑benchmark一看，延迟没降多少，带宽倒涨了30%。我当时就懵了。后来追查原因，才发现是内存访问模式被我们搞砸了。
为什么融合会导致带宽增加？
你可能会想：融合之后，中间结果不用写回DDR了，带宽应该降才对啊？
嗯，理论上没错。但现实往往更复杂。我总结下来，主要有三个原因：
- 数据复用率下降——融合后的算子，可能一次性需要加载更多输入数据
- 局部性被破坏——原本可以流水线处理的数据，现在要全部塞进buffer
- 中间结果膨胀——某些融合策略会产生更大的临时数据
说白了，融合是把双刃剑。用好了是神器，用不好就是给自己挖坑。
一个真实的案例：Conv+BN+ReLU融合
咱们拿最常见的Conv+BN+ReLU融合来说。很多教材都会告诉你，这三者可以合并成一个算子。但很少有人告诉你——融合后的内存布局怎么设计。
我在项目中遇到过这样一个场景：
// 原始实现：分步执行
conv_output = conv2d(input, weight); // 写回DDR
bn_output = batch_norm(conv_output); // 从DDR读，再写回
relu_output = relu(bn_output); // 从DDR读，再写回
// 融合实现：一步到位
fused_output = conv_bn_relu(input, weight); // 只写一次看起来融合后少了两写两读，对吧？但实际测试结果是这样的：
| 方案 | DDR读带宽 | DDR写带宽 | 总带宽 |
|---|---|---|---|
| 分步执行 | 12.4 GB/s | 8.1 GB/s | 20.5 GB/s |
| 融合执行（naive） | 18.7 GB/s | 5.3 GB/s | 24.0 GB/s |
| 融合执行（优化后） | 9.2 GB/s | 4.1 GB/s | 13.3 GB/s |
看到了吗？naive的融合方案，总带宽反而比分步执行高了17%。为什么会这样？
原因在于：分步执行时，conv的权重只需要加载一次，然后在片上buffer里反复用。但融合后的算子，为了保持数据流，不得不把权重和输入同时加载到更大的buffer里。如果片上SRAM不够大，就会频繁地换入换出——这就是带宽暴涨的根源。
核心问题：Tile大小的选择
你想想看，AI芯片的片上存储就那么点。融合后的算子，需要同时容纳：
- 输入feature map的一个tile
- 卷积核权重
- 中间计算结果
- BN的scale和bias参数
如果tile切得太小，计算单元吃不饱，效率低。如果tile切得太大，片上放不下，就得频繁搬数据。
关键结论：融合后的带宽优化，本质上是tile size和片上buffer大小的博弈。tile size选对了，带宽才能降下来。
避坑指南：我踩过的三个坑
坑一：忽视权重复用
我曾经在一个项目中，把Conv+Conv+Add做了融合。两个卷积的权重不同，但输入相同。我天真地以为，融合后输入只加载一次，肯定省带宽。结果呢？两个权重要轮流加载，片上buffer根本放不下，反而多了一倍的权重加载开销。
我的建议：融合前先算一笔账——融合后需要同时驻留的数据量是多少？如果超过片上SRAM的80%，就要重新考虑融合策略。
坑二：忽略channel维度的影响
我记得有一次做Depthwise Conv+Pointwise Conv融合。Depthwise是逐channel操作的，Pointwise是跨channel融合的。这两个算子的数据流模式完全不同。强行融合后，Depthwise的输出必须全部缓存下来，才能喂给Pointwise。对于channel数大的网络（比如MobileNet的最后一层），这个中间buffer大得吓人。
注意：不同计算模式的算子融合，一定要考虑中间结果的维度。特别是channel方向，很容易成为带宽的隐形杀手。
坑三：忽视数据排布格式
这个坑比较隐蔽。不同算子可能偏好不同的数据排布——Conv喜欢NHWC，有些加速器喜欢NCHW。融合后如果排布不统一，就需要做格式转换。这个转换本身就要消耗带宽。
我见过一个团队，融合后性能反而下降了15%，最后发现是数据排布转换导致的。他们花了三天才定位到这个问题。
实战建议：如何避免带宽不降反升
经过这些教训，我总结了一套检查清单：
- 先做带宽预算——融合前，估算片上buffer的容量和带宽需求
- 检查数据复用率——融合后，每个数据被使用的次数是否下降？
- 考虑tile策略——能不能通过分块来减少片上存储压力？
- 验证内存访问模式——用profiler看看DDR的读写模式是否连续
- 做A/B测试——融合版本和分步版本，实际跑一下带宽对比
一句话总结：融合不是为了融合而融合。如果融合后带宽不降反升，那还不如不融合。做AI芯片优化，数据流比计算量更重要。
知识体系图：融合与内存墙的关系
这张图把本章的核心逻辑串起来了。你仔细看看，算子融合不是简单的“合并代码”，它牵涉到数据流、存储层次、访问模式等多个维度。任何一个环节没想清楚，都可能掉进内存墙的陷阱。
最后一个小技巧：如果你不确定融合后带宽会不会涨，可以先做一个微基准测试——只融合两个小算子，看看带宽变化趋势。这个习惯帮我避免了好几次大坑。
好了，这一章就聊到这里。融合的陷阱不止这一个，下一章我们继续聊另一个常见的坑——计算密度失衡。