企业官网建设流程全解析

以resnet50 的网络结构为例，解析为什么有些算子不能融合

为什么 op1 和 op2 不能融合？

快速答案

op1 = BatchNorm + ReLU
op2 = MaxPool2D

它们不能融合的核心原因是：MaxPool2D 的复杂访问模式与 BatchNorm 的顺序写入不兼容。

详细分析

op1 的特征（BatchNorm + ReLU）

op1: SchedulerNode(ComputedBuffer) ├── 输入: buf0 [2, 64, 112, 112] ← 来自 Conv2D ├── 输出: buf1 [2, 64, 112, 112] ├── 操作: BatchNorm + ReLU │ ├── sub (减去均值) │ ├── sqrt, reciprocal (标准化) │ ├── mul (缩放) │ ├── add (偏移) │ └── relu (激活) └── 访问模式: 顺序访问，一对一映射 每个输入元素 → 计算 → 一个输出元素

关键代码（第40-60行）：

load=ops.load('buf0',get_index)# 读取输入# ... BatchNorm 计算 ...relu=ops.relu(add_1)# ReLUstore=ops.store('buf1',get_index,relu)# 写入输出

特点：

• 简单的逐元素计算
• 顺序访问内存
• 输入输出尺寸相同

op2 的特征（MaxPool2D）

op2: SchedulerNode(ComputedBuffer) ├── 输入: buf1 [2, 64, 112, 112] ← 来自 op1 ├── 输出: buf2 [2, 64, 56, 56] ← 尺寸减半！ ├── 操作: MaxPool2D (kernel=3x3, stride=2) └── 访问模式: 复杂的窗口访问 每个输出需要读取 9 个输入元素（3x3窗口）

关键依赖（第68-77行）：

op2.unmet_dependencies=[# 9 个不同的内存位置！MemoryDep('buf1',...,+64),# 右MemoryDep('buf1',...,+7104),# 右下MemoryDep('buf1',...,+7168),# 下MemoryDep('buf1',...,+7232),# 右下MemoryDep('buf1',...,-64),# 左MemoryDep('buf1',...,-7104),# 左上MemoryDep('buf1',...,-7168),# 上MemoryDep('buf1',...,-7232),# 左上MemoryDep('buf1',...,0)# 中心]

关键代码（第118-200+行）：

# 读取 9 个位置的值masked_subblock1=...# 左上masked_subblock2=...# 上masked_subblock3=...# 右上# ... 更多子块 ...# 取最大值maximum=ops.maximum(masked_subblock1,masked_subblock2)maximum_1=ops.maximum(maximum,masked_subblock3)# ...

问题：

• 随机访问：每个输出需要读取 9 个不同位置的输入
• 跨行访问：stride=7168 表示跨行读取
• 条件判断：大量边界检查（ge, lt, and_）
• 尺寸不匹配：输出是输入的 1/4

不能融合的 4 个核心原因

1. 迭代空间不匹配（最关键）

# op1op1.group.iteration=(1605632,1)# 2*64*112*112 = 1,605,632 元素op1.sizes=([25088,64],[])# op2op2.group.iteration=(401408,1)# 2*64*56*56 = 401,408 元素op2.sizes=([2,56,56,64],[])

问题：

• op1 产生 1,605,632 个元素
• op2 只需要 401,408 个元素
• 比例 4:1（因为 MaxPool stride=2, 尺寸减半，面积变为 1/4）

如果融合会怎样？

• 无法在一个统一的循环中同时计算
• op1 需要循环 1,605,632 次
• op2 只需要循环 401,408 次
• 无法对齐！

2. 复杂的访问模式（最关键）

op1 的输出（顺序写入）： ┌─────┬─────┬─────┬─────┐ │ 0 │ 1 │ 2 │ 3 │ → 顺序写入 buf1[0], buf1[1], buf1[2], ... ├─────┼─────┼─────┼─────┤ │ 4 │ 5 │ 6 │ 7 │ └─────┴─────┴─────┴─────┘ op2 的读取（窗口访问）： ┌─────┬─────┬─────┐ │ -64 │ 0 │ +64 │ ← 每次需要读取 3x3=9 个位置 ├─────┼─────┼─────┤ │-7168│ │+7168│ ├─────┼─────┼─────┤ │-7232│ │+7232│ └─────┴─────┴─────┘

问题：

• op1 每次只写一个位置
• op2 每次需要读取 9 个位置
• 如果融合，op1 需要等待 9 个相邻元素都计算完成
• 破坏了并行性！

3. 数据依赖复杂

# op1 的输出 buf1 的第 0 个元素会被 op2 的多个输出使用buf1[0]被以下 op2 的输出位置使用：-buf2[0](作为中心)-buf2[相邻位置1](作为窗口的一部分)-buf2[相邻位置2](作为窗口的一部分)-...

问题：

• 一对多的关系
• 需要额外的同步机制
• 增加融合的复杂度

4. 内存重用模式不同

# op1op1.users=[NodeUser(node=op2,can_inplace=False)]# ^^^^^^^^^^^^^^^^# 不能原地操作！

为什么 can_inplace=False？

• MaxPool 需要读取窗口内的多个值
• 如果原地修改，会破坏后续读取的数据
• 必须先读取所有需要的输入，再写入输出

如果 can_inplace=True（如 Add + ReLU）：

# 可以边读边写x=load(buf0,i)y=relu(add(x,bias))store(buf0,i,y)# 原地写回

但 MaxPool 不行：

# 必须先读完再写values=[load(buf1,i-64),load(buf1,i),load(buf1,i+64),...]result=max(values)store(buf2,j,result)# 不能写回 buf1

对比：能融合的例子（op9 + op10）

让我们对比一个能融合的例子：

# 假设 op9 = Add, op10 = ReLUop9:y=x+bias ├── 输入:[2,256,56,56]├── 输出:[2,256,56,56]← 尺寸相同！ └── 访问:y[i]=x[i]+bias op10:z=relu(y)├── 输入:[2,256,56,56]├── 输出:[2,256,56,56]← 尺寸相同！ └── 访问:z[i]=relu(y[i])← 一对一！

可以融合！

# 融合后fused:z[i]=relu(x[i]+bias)

为什么能融合？

1. 迭代空间相同
2. 访问模式简单（一对一）
3. 可以原地操作
4. 没有复杂依赖

总结

op1 (BatchNorm + ReLU) vs op2 (MaxPool2D) 不能融合

能融合的典型模式

不能融合的典型模式

如何验证？

方法 1: 查看 IR 文件

# 搜索融合节点grep"FusedSchedulerNode"ir_post_fusion.txt# 如果 op1 和 op2 融合了，你会看到：# fused_op1_op2: FusedSchedulerNode([op1, op2])# 但实际上它们是分开的：# op1: SchedulerNode(ComputedBuffer)# op2: SchedulerNode(ComputedBuffer)

方法 2: 使用分析工具

python analyze_fusion_diff.py# 输出会显示：# ✓ 找到 X 个融合节点# ✓ 但 op1 和 op2 不在其中

方法 3: 查看 pre-fusion vs post-fusion

# 如果融合了，post-fusion 中会少一个节点# 但这里 op1 和 op2 在两个文件中都存在diffir_pre_fusion.txt ir_post_fusion.txt|grep-A5"op1\|op2"

能否强制融合？

理论上可以，但不推荐

# 如果强制融合，需要：1.在 op1 中生成所有1,605,632个元素2.每4个 op1 输出对应1个 op2 输出3.在融合的 kernel 中插入复杂的窗口读取逻辑4.处理边界条件和同步# 结果：-代码复杂度暴增-寄存器压力增加-可能反而变慢

正确做法

让它们分开！

• op1 (BatchNorm + ReLU) 已经融合了，很好
• op2 (MaxPool) 单独执行，使用硬件优化的 kernel
• 中间结果 buf1 通过 L2 cache 传递，开销很小

关键要点

1. op1 和 op2 不融合是正确的决策
2. MaxPool 的复杂访问模式是主要原因
3. 迭代空间不匹配（4:1）无法克服
4. 分开执行反而更高效
5. 这是 PyTorch Inductor 的智能决策

不是所有相邻操作都应该融合！