加 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 模式，编译形同虚设。

提示词大师-python版

图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍

下载

• 必须显式写成 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 几乎必败。

• 正确做法是分层编译：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 执行。

Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！