深度学习推理优化：算子融合原理与Conv+BN+ReLU实战

上个月我在团队内部做技术分享的时候，有人问了我一个特别实在的问题：“模型训练完上生产，推理阶段你们一般先动哪里？”我的回答几乎没犹豫：先把计算图里的算子融合做好。很多人一开始觉得算子融合就是把几个函数硬绑在一起，听起来没什么技术含量。可真到性能瓶颈浮出来的时候，恰恰是这些不起眼的中间张量搬运，把整个推理任务拖慢了好几倍。这篇实战记录，就是围绕深度学习推理优化里的算子融合展开的，适合正在做模型部署、推理提速、边缘端落地的工程师，也适合那些已经看过不少优化理论、但还没有亲手把一条算子链融合起来的读者。

我不会只讲概念，也不会只喊“融合有奇效”，而是把思路拆开，把“为什么省时间”“怎么挑融合对象”“代码大概怎么写”“性能怎么度量”全部过一遍，顺带把这几年踩过的坑一并复盘。

1. 算子融合到底在解决什么问题

1.1 先理解两个基本概念：访存密集与计算密集

深度学习推理过程中，每个算子做的事无非两大类：一类是纯粹在搬运数据，比如 reshape、transpose、concat、elementwise 的 add、mul、激活函数；另一类是在做大量乘加运算，比如卷积、矩阵乘。

前一类算子通常叫访存密集算子，它们的耗时主要花在从显存或者内存里把数据读进来、算一下、再写回去。这类算子的特点是：运算本身很简单，但数据的进出量非常大。后一类是计算密集算子，真正卡时间的是那些乘加循环，数据量相对而言倒不是主要矛盾。

这里有个经典类比：计算密集就像是烤箱里烤面包，面包在炉子里不管放多久，你只需要把它放进去和取出来。访存密集更像是外卖配送，大部分时间都花在路上，真正把餐盒从袋子里拿出来放进去的动作只占一小段。如果一个流程里每一步都要把半成品先存进仓库、再从仓库取出来运到下一道工序，那整个流程的时间就被“配送”吃掉了。

推理优化里的算子融合，本质上就是把这些“从仓库取出来再存进去”的多余动作砍掉，让数据尽量待在手边，算完一步紧接着算下一步。

1.2 算子融合是把哪些时间省下来的

融合之后，时间主要省在三个地方。

第一个是减少内核启动开销。每个算子在硬件上跑，都需要一次内核启动。启动本身有固定成本，包括参数解析、任务调度、上下文准备。单个算子的启动开销可能只有几微秒，看起来不多，但一个模型里几百个算子累加起来，这部分开销就非常可观了。尤其在小模型、低延迟场景里，内核启动开销甚至能占到总耗时的两到三成。我见过一个极端的轻量分类模型，计算量本身很小，结果大部分时间都花在了几十个连续小算子的启动上，把几个相邻的 elementwise 算子融合之后，延迟直接下降了一个档次。

第二个是减少中间张量的分配、读写和释放。没有融合时，前一个算子要把结果写进一整块张量，后一个算子再把这块张量读回来。每一次“写结果”和“读结果”都要经过内存，而且很多时候还要经历一次显存分配。显存分配并不是免费的操作，分配、使用、释放这条链路的开销往往被大家忽略。融合之后，中间结果不再落到显存里，而是留在寄存器或缓存中，甚至根本不产生这个中间张量。

第三个是提升数据局部性。融合让多个算子在同一段循环里完成，数据被读取之后能立刻被使用，后续计算可能还会再次使用同一块数据，这时候数据还在缓存里，访问速度比回主存快得多。局部性改善带来的收益在大多数场景下比直觉上大很多，尤其是网络很深、通道数很大、中间特征图很厚重的时候。

1.3 一个反直觉的提醒：融合不是万能的

我见过不少新手拿到项目，第一反应是把整张计算图里能看到的算子全揉进一个大内核里，结果性能不升反降，最后还找不到原因。

这里需要有一个正确的认知：融合的目标不是“把所有算子合并成一个”，而是“把多余的搬运成本去掉”。如果两个算子本身都是计算密集型的重型算子，把它们硬合在一起，会让单个内核变得非常复杂，寄存器数量不够用，数据就得溢出到局部内存，反而拖慢速度。GPU 上的并行度也可能下降，因为一个超大的内核会让调度器很难保持高占用率。

所以，融合是典型的“有舍有得”工程，选对算子链，收益明显；选错对象，亏得也快。后面我会详细说怎么判断一条算子链该不该融合。

2. 融合方案的分类与选型思路

2.1 垂直融合、水平融合与跨算子拼接

算子融合在工程上通常分三类来讨论。

垂直融合是沿着数据流方向把不同阶段合并，最常见的模式就是“卷积 + 批归一化 + 激活函数”，还有“矩阵乘 + 归一化 + 激活函数”这种结构。这类融合最直观，因为它们在逻辑上是同一个计算单元的不同环节，中间结果只被后一个算子使用一次，合并后收益最大。

水平融合则是把多个输入输出形状相同的并行算子合并，比如多个 elementwise 操作同时对同一个张量做变换，或者几个分支对同一份数据做不同处理然后相加。水平融合的意义不在于减少中间读写，毕竟这些算子本来就各自处理自己的数据，而是减少对同一输入张量的重复读取。一个张量如果同时被三个 elementwise 算子读三遍，从内存读取的角度看就是三倍带宽消耗。水平融合可以只读一次输入，在寄存器里完成三路处理，各写各的输出。

跨算子拼接是更进阶的玩法，典型就是注意力结构里的 Q、K、V 投影和 softmax、矩阵乘的组合。这类融合不局限于相邻算子，而是把一段子图整体重写。比如做自注意力时，可以把 Q 和 K 的矩阵乘、缩放、mask、softmax、跟 V 的矩阵乘都规划在同一轮循环里，减少多次显存往返。不过这种融合实现成本高，风险也大，一般在大规模推理引擎里才会做系统性支持。

2.2 在哪个层面做融合：前端图优化还是后端内核级

算子融合可以在不同层级实现，选哪一层，直接关系到代码量、可移植性和收益上限。

前端图优化属于“计算图层面的模式匹配”。拿到一个模型的计算图之后，通过规则匹配去识别“这一段可以合并”。前端优化的好处是跟硬件无关，通用性强，任何后端都能复用同一套图优化逻辑。缺点是只能做结构层面的合并，真正到硬件上跑的时候，是否真的在同一个内核里完成计算，还要看后端的实现情况。有些框架的图优化会把多个算子标记为一个融合算子，但如果后端算子库没有对应实现，这个标记就形同虚设。

后端内核级融合则是把多个算子的计算逻辑写进同一个硬件内核。这种方式最贴近硬件，能拿到最大收益，但代价也很明显：针对不同硬件要写不同的融合内核，维护成本高，而且需要非常熟悉硬件体系结构。实际工程里最理想的做法是分层配合：前端图优化负责把有融合潜质的算子链找出来，后端负责真正执行“物理融合”。

2.3 工具与手写怎么选，我给出一张对比表

我把常见的三种姿势摆出来对比一下，方便你根据自己项目的实际情况做决定。

我个人的选型心法是：先让框架的自动优化跑一轮，看收益够不够。如果不够，再用编译工具链定制规则，把那些框架没有覆盖到的融合模式补上。只有当整条链已经是模型性能的核心瓶颈、自动手段试完仍然不满意时，我才会手写融合内核。直接上手写内核的诱惑很大，但它在工程上的隐性成本很容易被低估。

3. 实战：把卷积、批归一化、ReLU 融成一个算子

3.1 第一步：拿到模型图，找出可以融合的链条

要融合，先得知道自己手里的模型长什么样。通常做法是把训练好的模型导出成通用的计算图表示，然后用可视化工具把网络结构打出来。这一步不要偷懒，很多时候模型看起来结构规整，实际导出之后会发现很多小算子已经被拆开了，比如批归一化层可能被表示成多个基础算子的组合，如果不看实际图结构，融合规则根本匹配不上。

我在处理一个“模拟项目X”的图像分类模型时，第一眼就看到图上有一段非常经典的链条：卷积层后面紧跟着批归一化，再接 ReLU 激活。这就是教科书式的垂直融合对象。判断依据也很简单：这段链路的中间结果只被后一个算子使用一次，没有分支，没有旁路，完全符合“数据流动单向、中间张量生命周期极短”的特征。

还要注意一个细节：确认模型已经切到推理模式。训练模式下批归一化的行为完全不同，它会把当前 batch 的统计量揉进计算里，导致整条链多出不少额外节点，也会让折叠参数的方式彻底失效。这块如果搞错了，后面所有步骤都会跟着错。

3.2 第二步：把批归一化的参数折叠进卷积权重

融合的第一个关键点，是把批归一化完全折叠进卷积的权重和偏置。这样在运行阶段就不存在一个独立的批归一化算子。

假设卷积层的输出是 y = W * x + b，这里的 W 是卷积权重，x 是输入，b 是卷积偏置。批归一化在推理阶段的操作相当于：对 y 做标准化，再缩放平移，公式可以写成 z = gamma * (y - mu) / sqrt(var + epsilon) + beta。其中 gamma、beta 是批归一化的仿射参数，mu 和 var 是在训练集上累计得到的均值与方差，epsilon 是防止除零的小常数。

把 y 的表达式代入 z 的计算式，整理一下就能得到一个新的线性变换：

z = (gamma * W / sqrt(var + epsilon)) * x + gamma * (b - mu) / sqrt(var + epsilon) + beta

于是新的卷积权重 W' = gamma * W / sqrt(var + epsilon)，新的卷积偏置 b' = gamma * (b - mu) / sqrt(var + epsilon) + beta。整个过程就是先逐通道算出 scale 因子和 shift 因子，再把 scale 乘到原卷积权重上，把 shift 加到原卷积偏置上。

这一步我用过很多次，核心提醒只有两个。第一，epsilon 千万不要丢，尤其是在做逐层数值对齐的时候，少一个 epsilon 就可能造成百分之几的相对偏差。第二，折叠后的权重和偏置需要保存成新的模型文件，而不是在运行时动态计算，否则就白折叠了。

3.3 第三步：写一个融合内核，用类C伪代码实现

把批归一化折叠进卷积权重之后，ReLU 可以直接在卷积计算的循环里做掉。原理很直接：卷积累加循环算出来的结果，不先写回显存，而是紧接着做一次线性变换，再过一个 max(0, x)，最后才写结果。

下面这段是类 C 伪代码，示意的是“卷积 + 折叠后的归一化 + ReLU”在一个内核里的计算流程：

// fused_conv_bn_relu kernel（一维示意，实际卷积涉及多维循环） __global__ void fused_conv_bn_relu( const float* input, const float* weight, const float* scale, const float* shift, float* output, int C_out, int C_in, int H_in, int W_in, int H_out, int W_out, int K) { // 卷积核尺寸 int oh = blockIdx.y * blockDim.y + threadIdx.y; int ow = blockIdx.x * blockDim.x + threadIdx.x; int oc = blockIdx.z; if (oh < H_out && ow < W_out) { float acc = 0.0f; // 标准卷积累加 for (int ic = 0; ic < C_in; ++ic) { for (int kh = 0; kh < K; ++kh) { for (int kw = 0; kw < K; ++kw) { int ih = oh + kh; int iw = ow + kw; // 边界检查省略 acc += input[((ic * H_in + ih) * W_in) + iw] * weight[((oc * C_in + ic) * K + kh) * K + kw]; } } } // 折叠后的归一化 acc = acc * scale[oc] + shift[oc]; // ReLU 激活 acc = fmaxf(acc, 0.0f); output[((oc * H_out + oh) * W_out) + ow] = acc; } }

这段代码的核心目的是展示“顺序”：卷积算完、立刻做 scale + shift、立刻做 ReLU，最后才触碰输出内存。中间没有 acc 写回显存、再读回来、再做激活的过程。真实现实里的高性能实现会用到 tiling、shared memory、向量化加载、多级并行，但那属于后续打磨，核心思想是一致的。

3.4 第四步：验证数值一致性与推理收益

融合内核写完，第一件事是数值一致性验证，而不是直接测速度。我通常的做法是取一组固定随机输入，分别跑融合前模型和融合后内核，把输出张量存下来做对比。因为浮点运算顺序不同，微小误差是正常的，但最大绝对误差一般应该在 1e-5 量级附近。如果误差到了 1e-3 甚至更大，那基本就是实现逻辑出了问题。

一个很容易藏雷的点是：批归一化折叠时用的 mu、var 必须是在全量统计口径下得到的值，而不是某个 batch 的临时统计量。框架在推理模式下导出模型时，这些值一般是正确的，但如果中间经过了其他工具再导出，就得自己再核一次。

数值验证通过之后，再跑性能测试。不要一上来就套真实业务模型，先用一个简单的固定 shape 场景验证内核本身有没有收益，再把整套逻辑接入真实推理链路。

4. 性能收益如何度量，以及收益从哪里来

4.1 用访存量估算判断优化空间

我习惯在动手融合之前，先做一次访存量的粗略估算。算出来的数字虽然不一定等于实际耗时，但它能告诉你“这段链路到底值不值得花力气”。

举个例子，假设某段融合链路的输入特征图是 32×32×128，float32 占 4 字节。那么一个中间结果张量的大小就是 32×32×128×4 = 512KB。如果不做融合，卷积结果要先写进这块 512KB，批归一化再读一次，批归一化结果又写进另一块 512KB，ReLU 再读一次、再写一次。光是这几进几出，额外访存量就是好几个 512KB。在 batch 为 1 的场景下，这是 1MB 到几 MB 的数据搬运。看起来不大，但在低功耗设备上，这几 MB 的搬运时间可能比卷积本身还长。如果 batch 放大到 16，这个数字会直接乘 16，数据搬运量就很可观了。

再用内核启动开销来估算：假设一个算子的内核启动成本大约在 5 到 10 微秒，如果一个模型里有上百个算子，光是启动开销就是 0.5 到 1 毫秒。对一些原本整体延迟就只要几毫秒的模型来说，这已经占了巨大比例。融合能把这些启动次数砍掉一部分，收益是立竿见影的。

4.2 实测数据与逐项拆解

还是在“模拟项目X”这个图像分类模型上，我记录过一组比较典型的实测数据，用相对耗时表示，基线设为 1.00。

这个提升幅度放在卷积层占大头的模型里很正常。没有出现“直接翻倍”的效果，是因为卷积计算本身依然是主要耗时，融合解决的是从访存和启动开销里省出来的那一部分。这也反过来印证了一个结论：融合的收益高低，取决于模型里访存密集算子的占比，而不是融合动作本身有多花哨。

4.3 什么时候融合反而会亏

我见过最典型的一个反例，是在一个高分辨率输入的任务里，试图把一串 elementwise 算子全部合并进一个大型卷积内核。理论上这串 elementwise 运算占比不高，融合进去似乎也不坏，结果实测推理耗时反而上涨了大约百分之十。

排查到最后，发现原因是单个内核里的寄存器压力过大，变量装不进寄存器，只能溢写到局部内存。局部内存虽然在逻辑上像寄存器，但物理上是在显存里，访问延迟比真正的寄存器高很多。这样一来，原本想省掉的访存反而以另一种形式回来了，还拖累了整体执行效率。

这时候我判断融合对象是否合理的经验法则非常简单：看算子链的算术强度，也就是“每读取一个单位数据，能做多少次计算”。算术强度很低的算子，例如 elementwise、标准化、激活函数，融合进去非常划算，因为它们几乎不做计算，纯粹在搬运数据。算术强度已经很高的重型卷积，尤其是大卷积核、大通道数场景，融合进去就要非常小心，能不动就不动。

5. 常见问题与排查技巧实录

5.1 融合后输出对不上，先从这一步查

不少人融合完之后跑推理，结果跟原模型对不上，第一反应是怀疑自己内核写错了。根据我自己的经验，大部分这类问题其实出在批归一化折叠这一步。

有一个案例我记得很清楚：当时融合完 Conv+BN+ReLU，单测结果最大误差到了 1e-2 量级。我盯着公式查了半天，最后发现是模型导出时把批归一化标记成了训练状态，导致导出文件里的统计量是动态 batch 统计量。重新导出一次推理模式模型之后，误差立刻回到了 1e-6 量级。

所以检查顺序很重要：先确认模型处于推理模式，再确认折叠参数是最终统计量，最后才去检查内核索引计算。很多人第一步就跳过，直接啃内核，浪费一整天。

5.2 自动优化没有触发，怎么盯出原因

如果你的项目主要依赖框架自带的优化能力，最心累的场景是：日志里显示优化开启，但实测速度纹丝不动。这通常不是框架撒谎，而是融合规则根本没匹配上目标子图。

常见原因包括：输入张量的形状包含动态维度，导致模式匹配不敢触发；某个算子上挂着自定义属性，阻碍了规则识别；模型图里的小算子已经被拆得七零八落，匹配不到完整链条。另外，编译缓存在某些场景下会保留旧优化策略，让你误以为新改动没生效。

我的建议是：打开优化日志，去看匹配过程里的具体跳过原因，而不是隔空猜。只要日志里把“为什么这条链没被融合”说清楚，问题基本就解决了一半。如果日志不够详细，把目标子图缩小，单独做一个小模型去测试融合规则，定位会快很多。

5.3 我踩过最深的坑：寄存器压力把收益吃掉了

前面提到的“融合反亏”案例，后来我复盘得很彻底。当时用的策略是把整段链路分成两个融合内核而不是一个超大内核，每个内核的寄存器占用立刻降了下来，流程重新恢复正常，最终收益也比原始版本高了不少。

这个过程给我留下两条教训。第一，融合的“粒度过大”也是一种事故，收益不能只看表面少了几次内核启动，还要关心单个内核的寄存器占用、缓存命中率、并行度这些底层指标。第二，如果不确定融合边界在哪，就做渐进式实验：先融合最核心的链，测性能；再把相邻算子加进去，再测一次；每次只变一步，这样即使性能倒退，也能立刻定位是哪一步引入的。

5.4 折腾多次后的工程级建议

做了几轮推理优化之后，我总结出一套比较稳妥的工程流程，现在基本每次接手新模型都会这样做。

第一，动手融合前，先把未优化的推理结果和耗时曲线完整存一份，作为后续任何改动的对照基准。第二，折叠参数、融合规则、内核实现都要纳入版本管理，模型文件的改动要能追溯到是哪一次优化引入的。第三，融合前后不仅要对比单个样例的输出误差，还要在完整的验证集上跑一遍精度对比，别让数值偏差在个别样本上被掩盖。第四，不要迷信某个设备上的最优结果，融合策略往往跟硬件强相关，换一个平台之后，之前收益很大的融合可能变得平平无奇，重新测基准比什么都重要。

最后再分享一个我个人的体会。做了这么多优化，真正让我对算子融合有质变理解的，不是某个性能数字大幅提升的瞬间，而是一次集成测试时盯着显存带宽曲线看了半个小时。那时候我突然意识到，深度学习推理的大部分时间，其实不是在“算”，而是在“搬”。算子融合能做到的，就是让数据能少出门就少出门，能不出门就不出门。如果你刚开始接触这个方向，别一上来就去碰那些炫酷的图级重写，找一个最常见、最长的算子链，把它融合掉，量化收益，再考虑更复杂的改造。这条路看起来保守，但走起来几乎每步都有扎实回报。