torch.compile(model)不能直接套用，因首次前向才触发编译，含动态shape分支易graph break致退化；需预热、避控制流、慎选mode，并监控缓存命中。
torch.compile(model) 为什么不能直接套在任意模型上？
它不是装饰器，也不是“开箱即用”的开关。调用 torch.compile(model) 只是返回一个包装对象；真正触发图捕获和编译的是**第一次前向执行**。如果你的模型里有 if x.shape[0] > 16: 这类依赖输入 shape 的分支，Dynamo 默认会报 torch._dynamo.exc.Unsupported 或导致 graph break——此时它放弃整张图优化，退回到 eager 模式，白加这一行。
常见错误现象：
- 控制台没报错，但
compiled_model(input)跑得比原模型还慢（graph break 后 fallback 到解释执行） - 输入 batch_size=8 时正常，换成 batch_size=16 就卡住或报
Guard failure - 用了
torch.jit.script或torch.jit.trace的老代码，再套torch.compile容易冲突
实操建议：
- 先用
torch._dynamo.explain(model, input)查看是否 break、在哪 break - 避免在
forward中写 Python 控制流；改用torch.where、torch.nn.functional.pad等可追踪操作 - 不要对已
torch.jit.script过的模型再 compile，二者机制不兼容
不同 mode 参数对 ResNet/BERT 类模型的实际影响
mode 不是“越激进越好”。它决定编译阶段花多少时间做优化，直接影响首次延迟和缓存命中率。比如 max-autotune 会在编译时尝试几十种 kernel 实现并 benchmark，适合部署前离线预热；而 reduce-overhead 直接跳过大部分 autotune，适合在线服务中要求低首字延迟的场景。
使用场景与参数差异：
-
mode="default"：平衡编译时间和运行时性能，适合开发调试；ResNet-50 推理首帧约慢 2–3 倍，稳定后提速 1.4× -
mode="reduce-overhead"：禁用 kernel autotune，显存占用略升，但首次编译快 50%+；BERT base 小 batch 场景下吞吐提升更明显 -
mode="max-autotune"：编译耗时可能达分钟级，但生成 kernel 更贴近硬件极限；A100 上 vLLM 的 decode kernel 融合效果显著
注意：max-autotune 需要 CUDA_VISIBLE_DEVICES 固定，且无法在多进程子进程中生效（会报 nvrtc compilation failed）。
为什么第一次推理慢、中间某次又突然变慢？
第一次慢是必然的——Dynamo 捕获图 + Inductor 编译 CUDA kernel + PTX 缓存。但后续某次突然变慢，大概率是输入 shape 改变了，触发了隐式重编译。比如你喂了 (32, 3, 224, 224)，缓存 key 是 bs32_h224_w224；下一次喂 (16, 3, 224, 224)，key 不匹配，就得重新走一遍流程。
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
容易踩的坑：
- 没做 shape 预热：训练时 batch_size 动态变化，但没在服务启动时用典型尺寸预跑几轮
- 忽略 dtype 影响：
float32和float16输入会生成两套完全独立的缓存 - 用了
torch.compile(fullgraph=True)却没处理所有分支，反而让 graph break 更频繁
实操建议：
- 服务启动后，用线上真实分布的 shape/dtype 组合预热 3–5 次
compiled_model(input) - 对关键路径加
@torch.inference_mode()，避免 autograd 引入额外开销 - 监控
torch._dynamo.config.log_level = 2输出，确认缓存是否命中
Inductor 编译失败常见报错及绕过方式
Inductor 是默认后端，但它对某些算子组合或硬件配置敏感。比如在旧版驱动（NVIDIA driver ）上，<code>max-autotune 可能因 NVRTC 编译失败而 fallback；或者模型含 torch.fft + torch.compile，会触发 inductor not supported。
典型错误信息：
nvrtc compilation failed: error: unknown type name 'cudaStream_t'inductor not supported: aten.fft_rfftn.defaultRuntimeError: Triton requires CUDA >= 11.8
解决路径：
- 降级后端：
torch.compile(model, backend="aot_eager")（纯 Python fallback，用于 debug） - 禁用特定优化：
torch._inductor.config.fx_graph_cache = False（关闭 FX 图缓存，减小内存压力） - 手动 patch 算子：把不支持的
fft替换为torch.fft.rfftn的等效torch.nn.functional.conv1d实现（需验证数值一致性）
复杂点在于：编译失败不一定抛异常，有时只是静默 fallback。必须用 torch._dynamo.explain 或 torch.profiler.profile 看实际执行路径，否则你以为加速了，其实什么都没发生。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
