torch.compile()对LLM推理有用但有条件：prefill或固定长度batch decode可提效1.2–1.8倍，动态shape或control flow会fallback致性能降20%+；bfloat16比float16更稳因动态范围大；SDPA自动启用FlashAttention需满足is_causal=True等条件；卡顿主因是CPU-GPU数据搬运未对齐。
PyTorch 2.x 的 torch.compile() 对大模型推理到底有没有用？
直接说结论：对大多数 LLM 推理场景，torch.compile() 在 PyTorch 2.0+ 中默认启用 inductor 后端后，能带来 1.2–1.8 倍吞吐提升，但前提是模型结构稳定、输入 shape 固定（如 batch size 和 seq len 不变），且未使用动态 control flow（比如条件分支依赖 token 内容）。一旦触发 fallback（例如在 decode 阶段做逐 token 判断），性能反而可能下降 20%+。
实操建议：
- 只对 prefill 阶段 或 固定长度 batch decode 编译，避免在 while 循环内调用
model()时反复编译 - 显式指定
mode="reduce-overhead"（而非默认"default"），它会更激进地融合算子、减少 kernel launch 开销，适合高吞吐场景 - 禁用
dynamic=True—— 大模型推理中 shape 变化通常来自 padding 或不同 batch，不如提前 pad 到统一 shape 更可控 - 检查是否触发 fallback：设置
os.environ["TORCHDYNAMO_VERBOSE"] = "1"，看到"backend='eager'"就说明没编译成功
为什么 torch.amp.autocast(dtype=torch.bfloat16) 比 float16 更稳？
不是精度越高越好。LLM 的 attention score 和 residual add 容易因 float16 动态范围小（约 6×10⁴）导致 overflow 或 underflow，尤其在长上下文或大 batch 场景下，inf 或 nan 会悄悄传播，最终输出乱码。
bfloat16 保留了 float32 的 exponent 位宽（8 bit），动态范围与 float32 一致（≈1.8×10³⁸），只是牺牲了 mantissa 精度（7 bit vs 23 bit），对 LLM 权重和激活值足够友好。
实操建议：
- 必须配合
torch.backends.cuda.matmul.allow_bf16_reduced_precision_reduction = True，否则某些 matmul 仍走 fp32 - 不要仅靠
autocast—— 权重需提前转成bfloat16：model.to(torch.bfloat16)，否则 autocast 只影响 forward，grad 计算仍可能出错（即使 inference 也不建议留 fp32 权重） - 注意 CUDA 设备支持：A100 / H100 / RTX4090 支持原生 bfloat16，但 T4 / V100 不支持，强行启用会 fallback 到 fp32
如何用 torch.nn.attention.sdpa 替代手动实现的 attention？
自己写 q @ k.T / sqrt(d) + mask 再 softmax，不仅慢，还容易漏掉 flash attention 优化路径。PyTorch 2.2+ 提供的 torch.nn.functional.scaled_dot_product_attention（简称 SDPA）会自动 dispatch 到最优后端：FlashAttention-2（CUDA）、xformers（fallback）或朴素实现。
关键点在于：只有当输入满足 is_causal=True 且 attn_mask 是上三角（或 None）时，才会启用 FlashAttention；若传入自定义 dense mask，大概率 fallback 到 slow path。
大模型 Token 成本节约工具。在请求到达大模型之前自动压缩 prompt 和上下文，减少 60-95% 的 token 消耗，直接降低 API 成本。支持 Claude/OpenAI/Gemini 等主流模型，提供代理模式、CLI 包装、Python SDK 和 MCP Server 四种接入方式。内置一键安...
实操建议：
- 把自回归 decode 的 causal mask 拆成两步：prefill 用
is_causal=True，decode 单 token 时也保持is_causal=True，别拼接 mask - 确保
q/k/v是 contiguous 且 dtype 匹配（bfloat16 或 float16），否则 SDPA 内部会 copy - 禁用
enable_math=True（默认 False）—— 它强制走参考实现，完全绕过硬件加速 - 验证是否生效：设
os.environ["PYTORCH_CUDA_ALLOC_CONF"] = "max_split_size_mb:128"并观察 GPU memory pattern，FlashAttention 显著降低显存碎片
batch decode 时为什么 torch.compile() + sdpa 还卡在 CPU？
常见现象：吞吐不升反降，nvidia-smi 显示 GPU 利用率长期低于 30%，torch.profiler 显示大量时间花在 aten::copy_ 或 aten::to 上。根本原因不是模型慢，而是数据加载/预处理没对齐 GPU pipeline。
PyTorch 2.x 的编译器对 host-device 数据搬运极其敏感：只要有一个 tensor 在 CPU 上做 reshape、cat、pad，整个 graph 就无法 fully offload。
实操建议：
- 所有 tokenizer 输出（
input_ids,attention_mask）必须在 GPU 上完成 padding —— 用tokenizer(..., return_tensors="pt", device="cuda")，而不是先 on CPU 再.to("cuda") - 避免在 model forward 内部做
torch.cat([kv_cache, new_kv], dim=2)—— 改用kv_cache.narrow(2, 0, new_kv.size(2)).copy_(new_kv)实现 inplace 更新 - prefill 和 decode 使用同一套 tensor layout（比如都用
[bs, seq_len, d]），别让编译器为两种 shape 生成两套 kernel
真正卡点往往不在模型本身，而在 data movement 和 memory layout —— 这些地方改对了，torch.compile() 才能真正“看见”可优化的完整图。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
