加 torch.compile 不一定提速，甚至可能更慢——关键看是否满足静态 shape、纯张量计算、合理分层编译这三个硬条件；Dynamo 频繁重编译、fullgraph=False、混入 Python 标量操作或控制流、未预热等均会导致性能下降。
加 torch.compile 不一定提速，甚至可能更慢——关键看是否满足静态 shape、纯张量计算、合理分层编译这三个硬条件。
为什么有时加了 torch.compile 反而变慢？
根本原因是 Dynamo 频繁重编译：只要输入 shape 变动（比如 NLP 中每个 batch 的 max_length 不同），就会触发新图编译，开销远超执行收益。
- 用
torch._dynamo.config.verbose = True开日志，看到反复出现"compiling new graph"就是典型信号 - 训练前必须用典型 shape（如
(8, 512)）预热一次，否则首次运行卡住几秒不是 bug，是正常编译开销 - batch size 和 sequence length 必须固定；动态 padding 要改用
torch.nn.functional.pad，不能靠 Python if 判断长度再 pad - A100 上 Inductor 生成的 Triton kernel 比 V100 快 2–3×，硬件不匹配时收益会打折扣
fullgraph=True 是提速前提，不是可选项
默认 torch.compile(model) 实际是 fullgraph=False，遇到不可追踪分支（比如 if x.shape[0] > 1:）就 fallback 回 eager 模式，编译形同虚设。
- 必须显式写成
torch.compile(model, fullgraph=True)，才能真正触发 Inductor 图融合 - 启用后所有 Python 标量操作都会直接报错：
Unsupported: call_function aten._local_scalar_dense - 常见雷区：loss.item()、
.cpu().numpy()、print(loss)、list.append()—— 全部得移出编译范围 - 控制流必须可静态推导：把
if提到编译外，或用torch.where替代
训练 loop 里哪些该编译、哪些坚决不能碰？
Inductor 只适合纯张量计算路径。optimizer.step()、loss.backward()、log 指标这些混杂 Python 逻辑的环节，塞进 torch.compile 几乎必败。
立即学习“Python免费学习笔记（深入）”；
- 正确做法是分层编译：
compiled_model = torch.compile(model, fullgraph=True)+compiled_loss_fn = torch.compile(loss_fn, fullgraph=True) -
train_step函数保持 eager 模式：只调用编译后的 model 和 loss_fn，其余逻辑（zero_grad、step、print）全在外层 - 梯度累积必须和 compile 分开做：不能把
loss.backward()和optimizer.step()包进同一个编译函数 - 推理阶段建议加
dynamic=False，避免 runtime shape 推断开销
真正难的不是加那一行 torch.compile，而是让整个数据流和控制流都“对编译器友好”——shape 稳定、无标量、无副作用、分层干净。一旦某个环节漏掉，整条链路就退化回 eager 执行。
