1. 内存带宽瓶颈的本质：为什么算子融合能救命？

做AI系统优化这些年，我见过太多团队在算子融合上栽跟头。说实话，很多人一开始根本没意识到内存带宽是个多大的坑。你想想看，GPU的计算能力每年翻倍，但内存带宽的增长却慢得像蜗牛爬。这中间的差距，就是我们今天要聊的核心问题。

1.1 内存墙：一个被低估的瓶颈

先看一组数据。我随便拿个常见的场景举例：

硬件指标	数值	增长趋势
GPU计算能力 (TFLOPS)	312	每年~1.5x
内存带宽 (GB/s)	2000	每年~1.1x
计算/带宽比	156	持续扩大

看到没？计算能力跑得飞快，带宽却跟不上。这意味着什么？你的GPU大部分时间都在等数据，而不是算数据。我在项目中遇到过好几次，明明买了最贵的卡，跑起来却跟中端卡差不多。查到最后，全是内存带宽在拖后腿。

1.2 为什么数据搬运这么贵？

说白了，从全局内存读一次数据，比做一次浮点运算要贵几百倍。我习惯用一个简单的比喻：

• 计算：就像在自家厨房里切菜，几秒钟搞定
• 内存访问：就像开车去超市买菜，来回半小时

你想想看，如果每切一刀都要去一趟超市，这顿饭得做到什么时候？算子融合要解决的，就是这个「来回跑」的问题。

具体到数字上，我给大家算一笔账：

// 一个简单的向量加法
// 不融合：每个操作都要读写一次全局内存
for (i = 0; i < N; i++) {
    temp[i] = a[i] + b[i];  // 读a,读b,写temp → 3次内存访问
}
for (i = 0; i < N; i++) {
    c[i] = temp[i] * 2.0;   // 读temp,写c → 2次内存访问
}
// 总计：5次内存访问

// 融合后：一次搞定
for (i = 0; i < N; i++) {
    c[i] = (a[i] + b[i]) * 2.0;  // 读a,读b,写c → 3次内存访问
}
// 总计：3次内存访问，节省40%

嗯，这里要注意。上面的例子虽然简单，但道理是一样的。实际模型中，一个融合操作可能省掉几十次甚至上百次全局内存访问。省下来的带宽，就是实打实的性能提升。

1.3 算子融合的三种救命姿势

我个人习惯把算子融合分成三个层次，每个层次解决不同的问题：

1. 水平融合：把多个相同形状的算子合并成一个。比如两个连续的ReLU可以合成一个。
2. 垂直融合：把计算图中前后依赖的算子合并。比如Conv+BN+ReLU这种经典组合。
3. 交叉融合：跨不同数据流的算子合并。这个比较复杂，但收益也最大。

1.4 一张图看懂内存带宽瓶颈

下面这张SVG图，是我自己画的一个简化版计算流。它展示了融合前后数据搬运次数的变化：

1.5 什么时候该用融合？

不是所有场景都适合算子融合。我总结了几条经验：

• 计算密集型算子（如大卷积）：融合收益有限，因为瓶颈在计算本身
• 带宽密集型算子（如逐元素操作、小卷积）：融合收益巨大，强烈推荐
• 有中间结果的算子链：只要中间结果不被复用，融合基本稳赚不赔

说白了，你只要看到模型里有「读数据→算一下→写回去→再读出来→再算一下→再写回去」这种模式，就赶紧考虑融合。我见过太多人把精力花在调优单个算子上，结果发现融合一下就能省掉一半的带宽开销。

嗯，今天就先聊到这。记住一句话：内存带宽是硬约束，算子融合是软解药。后面我们会深入具体的融合策略和代码实现，到时候再细聊。