必须禁用torch.compile才能测出真实算子融合差异,因其在2.x中隐式触发会掩盖底层优化效果;不能仅用model(input)总耗时评估,需用torch.cuda.Event精准打点GPU执行段并同步,固定随机种子、禁用cudnn、显式初始化、统一输入与模型结构,每组跑50轮取中位数。

torch.compile 默认开启会掩盖真实算子融合差异,必须禁用才能测出底层优化效果。
为什么不能直接跑 model(input) 就算性能?
PyTorch 2.x 在调用 model() 时可能隐式触发 torch.compile,而 1.x 完全不走这条路——你测的不是“算子融合”,而是“有没有编译器兜底”。更麻烦的是,torch.compile 会把多个小算子自动融合成大 kernel,但这个过程不可控、不可复现,且依赖输入 shape 和硬件驱动版本。
- 实操建议:所有测试前加
os.environ["TORCHDYNAMO"] = "disable",并在 PyTorch 2.x 环境中显式调用torch._dynamo.reset() - PyTorch 1.x 环境也要检查是否误装了
torchdynamo包(它不兼容 1.x,装了反而报错) - 只靠
time.time()测总耗时没意义——数据搬运、host 同步、Python 解释器开销全混在一起
怎么打点才真正反映算子融合效果?
GPU 上的算子融合(如 conv + relu + bn)只有在 kernel 层面被合并后,才能减少 launch 开销和内存读写。想验证这点,必须绕过 host-side 时间测量,用 torch.cuda.Event 锁定纯 device 执行段。
-
start.record()放在input.to(device)之后、model()之前 -
end.record()放在loss.backward()之后(反向融合也得算) - 必须调用
start.synchronize(); end.synchronize(),否则返回的是未完成的时间戳 - 预热至少 3 轮,避免首次 kernel 编译抖动干扰中位数统计
哪些算子行为差异会干扰对比结果?
PyTorch 2.x 对 nn.Dropout、nn.LayerNorm 等算子做了默认行为微调,即使固定 torch.manual_seed(42),输出也可能有微小浮点差异——这会导致 CUDA kernel 路径切换,进而影响融合决策和计时稳定性。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac,无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启:辅助功能 + 屏幕录制权限
- 务必统一禁用非确定性加速:
torch.backends.cudnn.enabled = False - 模型权重初始化用显式方式,比如
torch.nn.init.xavier_uniform_(m.weight),别依赖构造函数默认逻辑 - 输入张量用
torch.randn(..., dtype=torch.float32)生成,避免 dtype 自动推导引入隐式 cast - 每组实验跑满 50 轮,取中位数而非平均值,排除 outlier 干扰
batch size 和模型结构怎么选才贴近真实融合场景?
小 batch 或单层 MLP 很难触发深度学习框架的算子融合策略——现代 fusion 引擎(如 TorchInductor)通常只对计算密集、访存规律的 subgraph 启动融合,比如 ResNet 的 bottleneck block 或 Transformer 的 attn+mlp 组合。
立即学习“Python免费学习笔记(深入)”;
- 推荐组合:
batch_size=32+ResNet18或ViT-Tiny,输入分辨率设为224x224 - 避免用
nn.Sequential(nn.Conv2d(...), nn.ReLU(), nn.BatchNorm2d(...))这种显式链式写法——它容易被旧版图优化 pass 忽略;改用torchvision.models.resnet18()这类标准实现 - CUDA 版本要一致(比如都用 12.1),不同 driver 对 fusion 支持程度差异很大


















