PyTorch Python端推理慢的根本原因是默认eager mode未启用torch.jit.trace或torch.compile等优化，且常遗漏module.eval()与torch.inference_mode()、设备不一致导致隐式同步。
Python环境下的PyTorch模型推理速度慢于C++版本，根本原因不是“Python天生慢”，而是Python端默认未启用关键优化路径，而C++（libtorch）只要正确配置就能逼近硬件极限——但前提是开发者手动补全所有缺失环节。
为什么torch.jit.trace或torch.compile没开，Python就跑不快
PyTorch Python端默认是eager mode，每次forward都重建计算图、做动态调度、触发Python解释器开销。这和C++里加载torch::jit::Module后直接执行优化过的静态图有本质区别。
-
torch.jit.trace能固化控制流和张量形状，消除Python层调度，但只适用于输入shape固定场景；torch.compile(model, mode="reduce-overhead")在2.0+中更通用，会自动做图融合和内核选择 - 没调用这些，哪怕模型本身简单，也会被GIL锁住多线程，且每个算子调用都要穿越Python C API边界
- 常见错误：只导出
.pt文件但没在Python端用torch.jit.load加载，仍走eager路径
module.eval()和torch.inference_mode()漏掉一个，性能就掉一截
训练模式下PyTorch会保留梯度、记录中间变量、启用dropout/batchnorm训练分支——这些对推理全是冗余开销。C++端常被强制要求写module.eval()，而Python端很多人忘了加，或者只加了model.eval()却没配合torch.no_grad()或torch.inference_mode()。
-
torch.inference_mode()比torch.no_grad()更轻量，禁用更多autograd基础设施，推荐用于纯推理 - batchnorm和dropout层在
train=True时行为完全不同，实测延迟可能高出40%以上 - 注意：
model.eval()必须在torch.inference_mode()作用域内调用才生效
CPU/GPU设备不一致导致隐式同步，拖慢整条流水线
Python端容易出现输入张量在CPU、模型在GPU、输出又转回CPU的“三段跳”，每次.to(device)或.cpu()都触发同步等待。C++端通常从加载起就明确指定device_type，全程内存连续。
立即学习“Python免费学习笔记（深入）”；
- 检查
input.device、model.device、output.device是否全一致，不一致立刻报warning但不中断，却悄悄引入同步点 - 避免在循环里反复调用
input.to("cuda")，应预分配GPU张量并复用 - 使用
pin_memory=True+non_blocking=True组合加速H2D传输，但仅当DataLoader和tensor创建都在同一进程时有效
真正卡住性能的往往不是模型结构本身，而是Python里那些“看起来无关紧要”的上下文切换、设备跳转和模式遗漏——这些在C++里要么编译时报错，要么文档强提醒，但在Python里只是静默变慢。
