torch.compile能显著加速模型，但需满足静态shape、避免动态Python操作等条件，否则易报错或变慢；启用fullgraph=True并合理划分编译范围是关键。
torch.compile 在 PyTorch 2.0+ 中确实能显著加速模型推理和训练，但不是“加一行就变快”——它对模型结构、输入 shape 稳定性、硬件后端（尤其是 Inductor）高度敏感；盲目启用反而可能变慢或报错。
torch.compile 调用时必须指定 fullgraph=True 才能触发 Inductor 后端
默认 torch.compile(model) 实际走的是 inductor 后端，但仅当所有控制流可静态推导时才真正生效。如果模型里有 if x.shape[0] > 1: 这类依赖运行时 shape 的分支，fullgraph=False（默认）会 fallback 到 eager 模式，编译形同虚设。
- 必须显式写成
torch.compile(model, fullgraph=True)，否则编译器不会尝试图融合 - 一旦启用
fullgraph=True，任何动态 shape 分支、Python list append、print 调试语句都会直接报torch._dynamo.exc.Unsupported错误 - 常见修复：把动态逻辑提到 compile 外（如提前判断 batch size），或改用
torch.where/torch.nn.functional.pad等可追踪算子替代 if/else
Inductor 编译失败常见错误：Unsupported: call_function aten._local_scalar_dense
这个错误本质是 Dynamo 捕获到某个算子返回了 Python scalar（比如 loss.item() 或 x.sum().item()），而 Inductor 无法将 Python 值嵌入计算图。它不是 bug，是设计限制。
- 检查训练 loop 中是否在
loss.backward()前/后调用了.item()、.cpu().numpy()、print(loss) - 解决方法：把指标收集移到 compile 范围外，例如只对
model和loss_fn编译，不编译整个 train_step 函数 - 更稳妥做法：
compiled_model = torch.compile(model); compiled_loss_fn = torch.compile(loss_fn)，但 train_step 保持 eager
为什么有时编译后反而更慢？关键看输入是否满足“静态 shape + 小 batch 变化”
Inductor 的优化（如 kernel fusion、shared memory reuse）依赖 shape 不变。如果每个 step 都喂不同 size 的 tensor（如 NLP 中变长序列 padding 不一致），Dynamo 会为每个新 shape 重新编译，开销远超收益。
立即学习“Python免费学习笔记（深入）”；
- 验证方式：启用
torch._dynamo.config.verbose = True，观察日志中是否频繁出现"compiling new graph" - 推荐做法：训练前用典型 shape（如
(8, 512)）预热一次，再固定 batch size 和 max_len；推理阶段务必用torch.compile(..., dynamic=False) - CUDA 架构影响大：A100 上 Inductor 生成的 Triton kernel 通常比 V100 快 2–3×，但若模型含大量小 conv（
Inductor 的图融合不是黑盒魔法，它把多个算子合并成一个 CUDA kernel，省去中间 tensor 的 global memory 读写。但 fusion 成败取决于算子间数据依赖是否紧凑、shape 是否对齐——这些细节在报错信息里藏得深，也最容易被忽略。
