加 torch.compile 不一定提速，甚至可能更慢——关键看是否满足 eval 模式、静态 shape、纯张量计算这三项硬条件；Dynamo 频繁重编译、fallback 到 eager 模式、未设 fullgraph=True 和 mode="reduce-overhead" 是主因。
加 torch.compile 不一定提速，甚至可能更慢——关键看是否满足 eval 模式、静态 shape、纯张量计算这三项硬条件。
为什么模型编译后反而变慢？
根本原因是 Dynamo 频繁重编译：只要输入 shape 变动（比如 batch size 从 8 变成 16，或 sequence length 每次不同），就会触发新图编译，开销远超执行收益。常见信号包括：
- 日志中反复出现
"compiling new graph"（需设torch._dynamo.config.verbose = True） - 首次调用卡住几秒，后续却没明显加速
- 推理吞吐不升反降，GPU 利用率波动剧烈
这不是 bug，是编译器在“被迫 fallback”——遇到不可追踪分支（如 if x.shape[0] > 1:）、Python 标量操作（loss.item()、print()）、动态 padding（靠 if 判断长度再 pad）时，会退回到 eager 模式执行，编译形同虚设。
必须显式启用的两个关键参数
fullgraph=True 和 mode="reduce-overhead" 不是可选项，而是推理提速的前提：
python-docx Skill功能概述python-docx Skill是一项面向实际任务的技能，主要用于本Skill提供使用python-docx生成专业Word文档的标准方法和最佳实践；生成安全服务方案文档；核心要点生成技术架构设计文档；生成任何需要专业排版的Word文档；核心库 : python-docx；使用与执行辅助库 : docx.shared , docx.enum , docx.oxml.ns；标准代码模板；1. 文档初始化；2. 字体设置（必须！它将相关步骤、工具调用和结果整理方式集
立即学习“Python免费学习笔记（深入）”；
-
fullgraph=True强制整个 forward 路径必须能被 Dynamo 完整捕获；默认fullgraph=False会容忍 graph break，但代价是无法触发 Inductor 的图融合和 Triton kernel 生成 -
mode="reduce-overhead"专为推理优化：跳过部分 runtime shape 推断，启用更多算子融合，减少 CPU 调度开销——这对 LLM / diffusion 类模型尤其关键 - 必须搭配
model.eval()使用；model.train()下 dropout/batch norm 行为不可预测，编译器会拒绝或生成低效 kernel
正确写法示例：
model = model.eval() compiled_model = torch.compile(model, fullgraph=True, mode="reduce-overhead", backend="inductor")
哪些代码绝对不能放进编译范围？
Inductor 只处理纯张量计算路径。以下操作一旦混入 forward 或编译函数内部，必然导致 graph break 或报错：
- 任何 Python 标量交互：
tensor.item()、tensor.cpu().numpy()、len(tensor)、print() - 运行时修改结构：
if控制子模块调用、动态插入nn.Linear、for循环展开层数依赖输入长度 - 隐式控制流：
Hugging Face的generate()中的whileloop，必须改造成torch.nn.functional.scaled_dot_product_attention+ 静态 KV cache 才能进图 - 非张量 I/O：
json.load()、open()、logging.info()—— 全部移到编译函数外部
典型错误写法：
@torch.compile
def bad_forward(x):
out = model(x)
print(f"shape: {out.shape}") # ❌ graph break
return out.cpu().numpy() # ❌ 报错 Unsupported: call_function aten._local_scalar_dense
真正难的是让数据流“对编译器友好”
不是加一行 torch.compile 就完事。你得把动态逻辑全挪到编译边界外：固定 batch size 和 max_length，用 torch.nn.functional.pad 替代 if-padding，把 logging/metrics 收集、device transfer、结果 postprocess 全部放在编译函数调用之后。硬件也得匹配——backend="inductor" 在 Windows/macOS 不可用，A100 上的 Triton kernel 比 V100 快 2–3×，而 4090 因内存带宽限制，收益可能打折扣。最常被忽略的一点：预热。不拿典型 shape（如 (1, 512)）先跑一次，首次推理延迟高是必然的，不是性能问题。
