用户甲在上一篇文章里，我们把 OpenPPL 的整体架构和计算图从加载到内存布局分配的过程梳理了一遍。当时有不少读者私信问我，优化器（Optimizer）那一层具体做了什么，尤其是算子融合（Operator Fusion）到底是怎么从一堆规则变成实际性能收益的。这篇文章就来填这个坑，专门聊 OpenPPL 优化器里的算子融合。
先说明一点，这里说的“优化器”不是训练时用的 Adam、AdamW 那类求解器。训练优化器解决的是非凸优化问题里 loss 怎么收敛的问题，而 OpenPPL 的优化器是“图优化器”，它解决的是计算图怎么改写才能让推理跑得更快的问题。两者名字一样，干的活完全不同，千万别混了。
1. 先搞清楚：OpenPPL 的“优化器”到底优化什么
1.1 推理引擎的优化器不等于 adam 优化器
我见过不少刚接触推理引擎的同学，一听到“优化器”三个字，脑子里浮现的是 Adam、AdamW、SGD 这些训练优化算法。但它们完全是两码事。
训练侧的优化器，核心目标是在非凸的损失函数曲面上去找一组能让 loss 足够低的参数，Adam 这类算法考虑的是梯度的一阶矩估计、二阶矩估计、学习率自适应这些事。它工作在高维参数空间里，处理的是浮点数的迭代更新。
推理引擎里的优化器，工作对象是一张计算图（Graph），输入是模型结构描述，输出是改写后的新图结构。它不碰任何权重数值的更新逻辑，只关注计算图的结构变换。OpenPPL 的优化器在导入模型之后、后端 kernel 执行之前运行，职责是把原始 ONNX、PaddlePaddle 或其他格式的模型图，转换成更适合底层 kernel 执行的形态。
打个比方，训练优化器像是一个登山运动员在琢磨怎么调整步伐翻过一座座山，而推理引擎的优化器像是修路工人，把原本要绕远路的山路直接打通成隧道。
1.2 图优化在整个推理链路里的位置
OpenPPL 的推理链路大致可以分成：模型解析 -> 图构建 -> 优化器优化 -> 分区调度 -> 编译执行。优化器处于图构建和分区调度之间。
模型解析阶段，ONNX 里的 Node 会原样转成 OpenPPL 的内部 IR 节点，什么 Conv、BatchNormalization、Relu、Add，一个个按拓扑顺序排好，这时候的图是非常“老实”的，每一个算子单独存在。但这个形态对执行来说是低效的。
优化器就在这个阶段介入，它通过注册好的各类 pass，对整个 IR 图做一遍又一遍的扫描和改写。一个 pass 解决一类问题，比如 Conv 和 BN 的折叠、相邻 elementwise 算子的合并、连续 reshape 的消除等。所有 pass 跑完之后，优化器输出的图相比输入图，算子数量明显变少，每个算子的计算粒度更大，数据的流动路径更短。
这之后，图才会进入分区调度器，按照设备类型拆分到 CPU、GPU 或自定义加速器上执行。所以优化器的质量直接决定了后续 kernel 执行时的天花板，如果图本身是低效的，kernel 再快也白搭。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 算子融合的本质：为什么要融合
2.1 访存瓶颈才是融合的核心逻辑
很多人以为算子融合是为了减少 kernel 启动开销。kernel 启动确实有开销，一条 kernel 启动指令的耗时大概在几微秒到几十微秒量级，GPU 上通常 3~5 微秒。但如果只是省启动开销，收益远没有这么大，融合真正解决的是访存瓶颈。
现代处理器（无论 CPU 还是 GPU）计算能力都远远超过内存带宽。以 GPU 为例，A100 的 FP16 算力可以到 312 TFLOPS，而显存带宽只有 1.5TB/s 左右，两者之间的差距是两个数量级。这意味着一个算子的执行时间，绝大多数情况下是花在等数据上，而不是真正在算。
不融合的 Conv + Relu，Conv kernel 算完之后，中间结果写到显存或者 L2，Relu kernel 再把它读出来，算完再写回去。这一写一读，数据在内存层级里转了一圈，白白消耗了带宽。融合之后，Relu 变成 Conv kernel 内部的一个 epilogue 操作，算完直接判断一下值是否小于 0，小于 0 就写 0，数据根本不出寄存器。
这里有个很直观的类比：不融合就像外卖员每一单都先回店里取餐再送，哪怕两单在同一个小区；融合就是把同一个小区的订单一起接上，一次性送完。
2.2 融合能省掉的远不止 kernel 启动开销
kernel 启动只是一个很小的一部分收益。融合真正带来的收益来自几个层面。
第一是减少中间张量的内存分配和释放。每个算子执行的前提是输入张量在显存或内存中可用，输出也需要一块新空间。频繁的 malloc/free（或者显存池里的 get/return）都是有锁开销和碎片风险的。融合之后中间张量消失了，内存峰值也随之降低。
第二是减少内存带宽消耗。这部分是最大的收益来源，能占到整个融合收益的 60% 以上。推理引擎在 elementwise 类算子上基本是访存密集型，带宽节省一点，端到端延迟就实打实地降低一点。
第三是减少 launch 开销和同步开销。特别在 GPU 上，多个 kernel 串行执行时，每一个 kernel 之间都有隐式的同步点。融合以后一个 kernel 做完所有事，这部分的调度和同步开销都省掉了。
第四是给 kernel 层更大的优化空间。融合后的算子是一个复合算子，kernel 实现可以做更激进的优化，比如把 Conv 的 implicit GEMM 和激活函数、残差加在一起处理，或者用寄存器缓存中间累加结果，直接在向量寄存器里完成激活，这些在分离算子形态下都做不到。
3. OpenPPL 优化器里的几类核心融合
3.1 Conv + BN + 激活：最经典的折叠
Conv + BN + ReLU 的融合是每个推理引擎的标配，OpenPPL 也不例外。它的原理不复杂，但细节很多。
BatchNormalization 在推理阶段是一个确定性的线性变换：y = (x - mean) / sqrt(var + eps) * gamma + beta。因为 Conv 也是线性变换，两个线性变换复合之后仍然是线性变换。所以可以把 BN 的参数折叠进 Conv 的 weight 和 bias 里。
具体公式是这样的。设 Conv 原始权重为 W，bias 为 b_conv，BN 的缩放系数为 scale = gamma / sqrt(var + eps)，偏移为 shift = beta - mean * scale。折叠后：
W_new = W * scale（按输出通道做广播乘法）
b_new = (b_conv - mean) * scale + beta
一旦折叠完成，计算图中 Conv 后面的 BN 节点就可以整个删掉。
激活函数一般不会折叠进权重里，因为 ReLU 不是线性变换。但 ReLU 可以作为 Conv kernel 的 epilogue 操作，即 Conv 算完一个 tile 的数据后，直接在寄存器或共享内存里做一次 ReLU，然后才写回显存。
OpenPPL 在这块的处理上有一个细节值得提：它对 BN 的 eps 参数非常敏感。如果原始模型里的 BN eps 值比较特殊（比如某些模型训练时用的 eps 是 1e-2 而不是默认的 1e-5），折叠后必须保证从数值结果上几乎不可察觉。这要求优化器在推导折叠后公式时严格按照表达式树走，不能直接用“经验公式”做近似。
折叠完还要处理一件事：如果 Conv 没有 bias，折叠后需要补充一个 bias；如果 BN 前面不是一个 Conv 而是别的算子，那不具备线性融合条件，就只能走别的融合路径。
3.2 Attention 结构的 QKV 与 FFN 融合
Transformer 类模型出来之后，OpenPPL 的算子融合重心很大一块转移到了 Attention 结构上。QKV 融合和 FFN 融合是这里面的重点。
原始 Attention 实现里，Q、K、V 是由同一个输入 X 分别乘三个权重矩阵得到的。对应的 ONNX 图里有三个 MatMul（或三个 Conv 1x1），之后还要分别做 reshape、transpose。如果不做融合，这三个 MatMul 是三个独立的 kernel 调用，X 这个输入张量要被读三遍。
OpenPPL 的做法是把三个 MatMul 合成一个大的 GeMM，输入还是 X，权重矩阵在模型加载时就预先做了拼接，变成一个 [3 * hidden_size, hidden_size] 的大矩阵。一次 GeMM 得到 QKV 全部结果，输出维度是 [batch, seq_len, 3 * head_dim * num_heads]，之后再通过一个专用的 SplitKernel 把结果切分成 Q、K、V 三个张量，或者干脆在后续的 kernel 里直接按内存偏移访问。
这个融合的收益非常可观。以 Bert-base 为例，hidden_size 是 768，三个 MatMul 的计算量都是 768 * 768 * seq_len * batch，合在一起做一次大 GEMM 之后，矩阵乘法的大小编排更合理，对 Tensor Core 的利用也更充分。
FFN 的融合类似，Transformer 的 FFN 层是两个全连接 + 中间一个激活。OpenPPL 会把第一个全连接、激活、第二个全连接融合成一个结构化的 kernel。中间激活后的张量不需要写回全局内存，而是保持在片上。对于 LLaMA、GPT 这类模型，FFN 占了模型大部分计算量，这个融合直接决定了推理性能的上限。
还有一个值得提的融合是 Attention 里的 Softmax 融合。传统实现是 QK^T 得到一个 score 矩阵，写回全局内存，然后 Softmax kernel 读回来算，再写回去。OpenPPL 会把 score 矩阵的计算、缩放、Softmax 的 max 和 sum 归约全部融合到同一个 kernel 里，score 矩阵只需要存在于寄存器或共享内存中。
3.3 残差与 elementwise 类融合
ResNet 系模型和 Transformer 系模型都有大量的残差连接，对应的图结构是 Add 节点。这类节点本身计算极简单，就是逐元素相加，但它的数据量很大，完全受限于内存带宽。
如果不融合，一个残差 Add 意味着前一个算子的输出要写一遍显存，Add kernel 读两个输入写一个输出，又是三遍显存流量。融合之后，Add 变成前一个算子的 epilogue 操作，数据还在寄存器里就直接加上残差分支的值，然后写回。
这里的关键是优化器要能识别出 Add 的一个输入来自另一个算子，且形状、步长都与当前输出匹配。OpenPPL 的算子融合 pass 里，有一个专门处理 elementwise 链的规则集合。除了 Add，还有 Mul、Sigmoid、Tanh、Gelu 这些，它们只要不破坏数据布局，都可以和主算子合并。
Elementwise 链的融合有一个常见误区：不是所有 elementwise 都能无脑融合。如果 elementwise 后面紧贴着一个改变布局的算子（比如 Transpose、Reshape 的大跨度变换），那上下两个算子的内存访问模式会对不上，融合后可能导致 kernel 的访存效率下降。OpenPPL 的处理策略是：先做布局分析，只有当两个算子的数据访问模式兼容时，才进行融合。
3.4 布局与 Format 类融合
这一块很多文章不会提，但它其实对性能影响很大。在 GPU 上，NCHW 布局和 NHWC 布局对访存局部性的影响是巨大的，尤其是 Conv 后接 Depthwise Conv、或者 Conv 后接 elementwise 的场景。
OpenPPL 的优化器会在图优化阶段做格式推断。比如 Conv 的输出如果是给下一个 Conv 用，可能保持 NCHW；如果是给 elementwise 用，NHWC 更友好。优化器会根据后续算子的类型，自动插入或消除格式转换节点，而在设计上，格式转换节点通常会和前面的算子融合。
举个例子，TensorRT 在 GPU 上经常把网络整体转换成 NHWC 甚至 NCHW4、NC1DHW4 之类的向量化格式。OpenPPL 支持类似的布局推断，但做得更保守一些，它会按子图做局部布局选择，而不是全图统一一种布局。
在 CPU 上，布局融合更常见的是和内存对齐有关。OpenPPL 的 X86 后端支持 AVX2、AVX512，某些融合后的算子会对通道维度做 padding 对齐，让 SIMD 加载不需要处理边界，这些 padding 操作也必须由优化器提前在图里写清楚，否则 kernel 层没法做到无分支设计。
4. 融合是怎么实现的：模式匹配与图重写
4.1 模式匹配的工程实现
OpenPPL 的优化器内部实现可以粗分成两层：模式匹配层和图重写层。模式匹配层做的事情是“找点”，图重写层做的事情是“改图”。
在源码里，每个融合规则本质上是一个 pattern，描述了一个子图的拓扑结构。比如 Conv + BN + Relu 这个融合的 pattern 可以简化为：
Node_0: type = Conv
Node_0.output -> Node_1.input[0]
Node_1: type = BatchNormalization
Node_1.output -> Node_2.input[0]
Node_2: type = Relu
匹配的过程就是在图的节点列表里做扫描。OpenPPL 使用的是基于节点类型和边关系的匹配方式，类似一个图上的子图同构匹配，只不过限定模式是“一条链”或者“一个小的扇状结构”。
工程实现上，为了性能，优化器会先把图上所有节点按照算子类型做索引，比如有一个 map<op_type, vector<Node*>>，匹配 Conv 开头的模式时直接取 index 里的 Conv 节点列表，而不是全图遍历。这是一个很容易被忽视但很关键的工程细节，模型规模大起来之后，全图扫描的性能损耗不能忽略。
我用一段简化的伪代码来说明这个匹配循环的核心逻辑：
cpp复制// 伪代码示意，非 OpenPPL 源码
void FuseConvBNReluPass::Run(Graph* graph) {
auto& conv_nodes = graph->GetNodesByType("Conv");
for (auto* conv_node : conv_nodes) {
// 取 Conv 的唯一输出消费者
Node* bn_node = GetUniqueConsumer(conv_node);
if (bn_node == nullptr || bn_node->type != "BatchNormalization") continue;
// BN 必须是 inference 模式（没有 training 分支）
if (!IsInferenceMode(bn_node)) continue;
Node* relu_node = GetUniqueConsumer(bn_node);
if (relu_node != nullptr && relu_node->type == "Relu") {
// 折叠 BN 到 Conv
FoldBNIntoConv(conv_node, bn_node);
// 把 ReLU 标记为 Conv 的 epilogue
SetEpilogue(conv_node, "Relu");
// 删除 BN 和 ReLU 节点
graph->RemoveNode(bn_node);
graph->RemoveNode(relu_node);
}
}
}
注意其中的 GetUniqueConsumer 函数。这是最容易被忽略的约束条件：如果一个节点的输出被多个消费者使用，这个算子不能随便融合，因为融合会改变其他分支的数据来源。
4.2 语义等价性验证与约束
融合不是“长得像就能合”，优化器必须保证改写前后，从计算图的角度看是语义等价的。OpenPPL 在每次图重写前会做几个检查。
第一个检查是消费者唯一性。输出节点只能有一个 consumer 才能融合，如果有多个 consumer，要么分裂成两份输出，要么放弃融合。OpenPPL 的策略是大多数情况放弃融合，因为分裂会引入额外的 layout 转换或内存拷贝，收益反而可能变负。
第二个检查是数据类型和形状一致性。Conv 的输出是 FP16，BN 节点的输入要求 FP32，这种情况在很多框架导出的模型里会出现。优化器不会强行把类型转换节点融合掉，而是会先判断是否可以安全地做类型提升。一般做法是把中间的 Cast 节点吸收进融合模式，前提是精度损失在可接受范围内。OpenPPL 默认对 FP16 的融合走“Fp16 累加转 Fp32 修正”的路径，避免低精度累加导致的精度漂移。
第三个检查是广播语义。BN、Add、Mul 等算子都支持广播，但融合进 Conv 的 epilogue 后，广播的语义必须能被 kernel 实现正确处理。如果广播模式太复杂（比如 Add 的另一个输入是高维的非连续切片），OpenPPL 会选择不融合，因为 kernel 实现的复杂度会急剧上升，而且访存模式大概率是不优的。
第四个检查是动态 shape 的支持。某些融合在有动态 batch 时会失效，比如依赖 batch size 进行静态内存规划的融合。OpenPPL 对这种情况会做两套方案：编译期 shape 已知走融合路径，shape 未知则保留拆分算子。这个设计是为了支持实际生产环境里常见的动态 batch 和变长输入。
4.3 融合算子的 kernel 落地
融合的最后一公里是 kernel 实现。优化器把多个算子融合成一个“复合算子”之后，需要有一个新的 kernel 来执行它。OpenPPL 在算子库层面为这类复合算子提供了一组可组合的 kernel 组件。
以 GPU 后端的 Conv + Bias + ReLU 融合为例，它本质上还是调用 Conv 的主计算逻辑——implicit GEMM 或者 Winograd——但会在输出阶段挂一个 epilogue 函数指针。每个 epilogue 都是一段轻量代码：
cpp复制// 伪代码示意：Conv 输出 epilogue 的抽象
template <typename T>
struct ConvEpilogue {
// 可选：加 bias
const T* bias;
// 可选：激活函数类型
int activation_type; // 0 = none, 1 = relu, 2 = gelu
// 可选：残差输入指针
const T* residual;
__device__ T Compute(T acc, int channel_id, int spatial_idx) {
if (bias) acc += bias[channel_id];
if (residual) acc += residual[spatial_idx];
if (activation_type == 1) acc = acc > 0 ? acc : 0;
else if (activation_type == 2) acc = 0.5f * acc * (1.0f + tanhf(0.7978845608f * (acc + 0.044715f * acc * acc * acc)));
return acc;
}
};
这个设计的好处是，优化器每新增一种融合模式，kernel 层只需要组合一个已有的 epilogue 即可，不需要从零写一个新的 CUDA kernel。OpenPPL 的卷积 kernel 本身是一个大而全的实现，它通过模板参数在编译期展开不同组合，避免了运行时的分支开销。
这里有一个工程上的取舍：epilogue 太多会导致模板实例数量指数膨胀。OpenPPL 的做法是只对常用的组合做模板实例化，比如 Conv+Bias+ReLU、Conv+Bias+GELU、Conv+Bias+Add+ReLU，其他冷门组合走运行时分发函数，虽然性能略差但保证功能完整。
5. 融合效果的验证与调优
5.1 怎么确认融合真的生效了
写完了融合规则，最重要的就是验证。OpenPPL 提供了一些工具和日志输出来帮助开发者确认算子融合是否真实生效。
最直接的方式是开启优化器的 debug 日志。在初始化 OpenPPL 时把日志级别设置成 debug，就会输出图优化的每个 pass 执行前后的算子数量变化。如果你看到 Conv 节点数量不变而 BatchNormalization 节点清零了，说明 Conv+BN 折叠走通了。
另一个手段是 dump 优化前后的图结构。OpenPPL 支持把优化后的 IR 导出成 ONNX 格式，用 Netron 直接打开看。我实际工作中经常这样干：
- 导出优化前图：由模型导入后直接 dump，能看到原始 ONNX 的完整结构
- 导出优化后图：跑完优化器后 dump，能看到各个融合点是否命中
两份图对比着看，哪里该融合没融合一目了然。如果 Conv 后面跟了一长串 Reshape、Transpose、Reshape 这类节点，大概率是布局优化没做干净，需要去查对应的 layout pass。
5.2 融合带来的性能收益怎么看
性能验证不能只看端到端的时间，因为端到端时间受很多因素影响，不容易归因。我的习惯是分层看。
第一层是图优化统计：优化前后算子总数、融合点数量、中间张量数量。算子数减少 30%，中间张量减少 50%，融合的效果一般就不会差。
第二层是 kernel profiling。用 ncu（NVIDIA Nsight Compute）去测单个融合 kernel 的指标，重点关注 DRAM Throughput、L2 命中率、Warp Occupancy 这三个指标。融合 kernel 的 DRAM Throughput 如果明显低于单独执行多个 kernel 的总和，说明数据在片上被复用了，这就是融合的功劳。
第三层才是端到端的延迟变化。拿一个包含大量 Conv+BN+ReLU 的 ResNet 模型来说，在我们内部的测试环境里，Conv+BN+ReLU 三合一融合能够比不融合快 15% 到 25%。对于 Attention 模型的 FFN 融合，收益通常更大，尤其是大 batch 下，QKV 拼接融合可以减少 30% 以上的 GeMM 调用次数。
这里要强调一点：融合收益不是线性的。模型已经很小、算子数量不多时，融合带来的收益可能被 kernel 本身的调度开销淹没，甚至由于复合 kernel 的寄存器占用更高、occupancy 下降而出现负优化。所以 OpenPPL 的优化器里不是所有融合都无条件开启，部分激进融合需要通过配置显式打开。
5.3 动态 shape 场景下的融合策略差异
前面提到过动态 shape 对融合的影响，这里展开说。
在动态 shape 场景下，优化器的角色发生了微妙变化。编译期 shape 已知时，优化器可以做一些重量级的改写，比如把多个算子重排、替换成静态形状版本；shape 未知时，优化器的策略必须保守得多。
OpenPPL 的动态 shape 路径有两种处理方式。一种是对每个新 shape 重新执行图优化，这在 shape 变化频率低的时候可行，但开销很大。另一种是预优化：在 compile 阶段同时对多个候选 shape 做优化，然后把优化后的图缓存起来，运行时按实际 shape 命中缓存。后者是生产环境里更常用的方案。
动态 shape 下的融合还有一个难点：一些算子（比如 Reshape、Transpose）在 shape 变化时可能改变内存布局，从而使原本融合的条件不成立。OpenPPL 的做法是在融合规则的约束条件中加入 shape 关系检查，只有形状关系在所有可能的 shape 下都成立时，才允许融合。
实际使用建议：如果你是做在线服务的，动态 batch 是常态，那最好在初始化阶段就把常见的 batch 值列表配好，让优化器为每个 batch 都生成一个专用的优化图。这比运行时动态调整明显更快。
6. 常见问题与排查技巧
6.1 融合没触发，先查 pattern 匹配条件
我排查融合失效问题的时候，第一步永远是检查 pattern 是否被意外打断。
最常见的打断原因是 Conv 的输出不只有一个 consumer。有些模型结构里，Conv 的输出除了给 BN，还有一个分支拿去做了别的计算，比如某种跨层连接。这时候 GetUniqueConsumer 返回为空，融合就会静默跳过。
这种问题的排查技巧是：画出优化前后的子图对比，看 Conv 后面是不是多了一个 Shape、Gather、Unsqueeze 之类的辅助节点。ONNX 模型导出时经常带上这类节点，它们不影响语义，但会打断 pattern 匹配。OpenPPL 里针对这些辅助节点有专门的清理 pass，但清理 pass 必须在融合 pass 之前执行。如果你改了 pass 的执行顺序，这类问题就会冒出来。
还有一种情况是 BN 节点带了 training 分支。ONNX 的 BatchNormalization 在训练模式下有多个输出（均值、方差等），很多训练框架导出的模型虽然只用了 output[0]，但节点本身还是有多个输出的定义。OpenPPL 在匹配时会严格检查输出数量，多一个输出就不认。这种情况可以通过 onnxsim 或者导出时设置 training=False 来解决。
6.2 BN 折叠精度对不齐
在实际部署中，BN 折叠后精度对不齐是一个高频问题，尤其是使用半精度推理时。
BN 折叠的数学公式推导是准确的，但在半精度下会有细微的数值差异。原因是折叠后的 W_new = W * scale，这里的 scale = gamma / sqrt(var + eps)，很可能是一个无限小数。W 用 FP16 存储时会舍入，乘完 scale 之后再存储又会舍入一次。两次舍入叠加，对某些极端通道来说，误差可能被放大。
OpenPPL 在这个问题上的经验是：优先在 FP32 下做折叠，折叠完成后再把 weight 转成 FP16。同时，kernel 内部累加器用 FP32，只在写回显存时转 FP16。这两个策略合在一起，基本能保证和未融合版本的结果在可接受误差范围内（FP16 推理一般要求相对误差在 1e-2 量级以内）。
如果你发现某个模型融合后精度掉得厉害，建议先关掉 BN 折叠单独跑一遍，定位是折叠问题还是其他问题。
6.3 融合后显存占用不降反升
按理说融合会减少中间张量，显存应该下降才对。但也有例外。
一种情况是融合后的复合 kernel 需要额外的 workspace。比如某些卷积融合实现使用 Winograd 变换，变换后的输入和权重需要额外的显存空间。这种情况下，融合虽然减少了中间张量，但增加了临时 workspace，整体显存不一定下降。
另一种情况是多个融合后的 kernel 并行度下降导致显存回收不及时。OpenPPL 有自己的显存池，正常情况下 kernel 输出张量的显存会被回收复用。但融合 kernel 的输出生命周期可能更长（因为后续有多个算子消费它），显存池里可复用的块数量减少，导致峰值上升。
解决方案是在初始化 OpenPPL 时显式配置显存池的块大小和重用策略。有些框架会开放一个 workspace 比例参数，这个值需要根据模型实际跑一遍 profiler 来定，不能拍脑袋。
6.4 实操中值得注意的细节
OpenPPL 的优化器还支持融合某些跨设备场景的特有结构。比如在异构执行时，CPU 和 GPU 之间会有数据拷贝算子，把这些拷贝算子和上下游的 elementwise 算子融合可以在一定程度上隐藏拷贝延迟。
另外，量化模型的融合有一个额外难点：量化参数的传递。当一个 Conv + Relu 被融合成一个量化算子时，Relu 的截断逻辑（clamp）需要感知量化 scale 和 zero_point。OpenPPL 的优化器会专门处理量化参数的传递规则，避免融合后量化误差扩大。如果你在用 INT8 模型，务必打开量化感知融合的开关，并保持量化校准参数不变。
7. 从融合到系统：一些延伸理解
算子融合不是孤立的优化手段，它和引擎里其他模块有耦合关系。
调度器方面，融合后算子数量减少，任务图更简单，调度器做的决策空间也更小，这有利于减少调度开销。但反过来，融合后单个算子的执行时间变长，如果算子内部并行度不足，反而可能导致设备利用率下降。所以 OpenPPL 的优化器在做融合时会参考后端提供的算子代价模型，预判融合后的执行时间不会比融合前长太多。
内存规划方面，融合减少了中间张量后，内存池可以更紧凑。OpenPPL 的内存规划器利用图优化后给出的生命周期信息做内存复用，融合与否直接影响着内存复用效果。
这些都说明，一个成熟的推理引擎，优化器不是一个独立的“规则包”，而是一个和底层 kernel、显存管理、调度器紧密配合的模块。理解这一点，比记住某一条融合规则更重要。
我在实际使用 OpenPPL 的过程中有一个很深刻的体验：大部分性能问题不是出在单个 kernel 不够快，而是出在计算图的结构上——数据来回搬运、算子边界太多、内存访问模式不连续。优化器的工作就是在图这一层先把这些问题解决掉，让 kernel 层能以一个更纯粹的形态去压榨硬件性能。所以，如果你想要给 OpenPPL 贡献一个新的融合规则，或者在上层业务里基于 OpenPPL 做定制优化，我建议你先从读懂现有 pass 的匹配约束和 epilogue 抽象入手，那是最快的一条路径。