必须禁用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 组合。
- 推荐组合：
batch_size=32+ResNet18或ViT-Tiny，输入分辨率设为224x224 - 避免用
nn.Sequential(nn.Conv2d(...), nn.ReLU(), nn.BatchNorm2d(...))这种显式链式写法——它容易被旧版图优化 pass 忽略；改用torchvision.models.resnet18()这类标准实现 - CUDA 版本要一致（比如都用 12.1），不同 driver 对 fusion 支持程度差异很大
真正难控的不是代码怎么写，而是 fusion 是否发生——它不暴露 API，只在 backend 内部决策。哪怕所有条件都对齐，同一份模型在 A100 和 RTX 4090 上的融合效果也可能完全不同。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
