PyTorch推理耗时波动主因包括cuDNN benchmark动态选型、输入尺寸不固定、计时混入IO/预处理、no_grad未生效、CUDA上下文冷启动及CPU干扰；应关闭benchmark（尺寸固定时）、热身模型、严格使用no_grad、同步GPU、隔离混合负载。
PyTorch模型推理耗时波动大，先看torch.backends.cudnn.benchmark是否开启
开启torch.backends.cudnn.benchmark = True后，cuDNN会在首次运行时自动选择当前输入尺寸下最快的卷积算法，但这个“选型”过程本身会引入不可预测的延迟，且后续若输入尺寸变化（如batch size动态调整、图像resize不一致），cuDNN可能反复触发重新搜索，导致单次推理耗时跳变几十毫秒甚至上百毫秒。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 若输入尺寸固定（如统一
224x224、batch_size=1），设为False可消除首次/切换时的抖动 - 若必须支持多尺寸，避免在推理循环内反复调用
model(input)前修改benchmark开关 - 用
torch.cuda.synchronize()确保计时不含GPU异步排队开销，否则测出的“延迟”包含调度噪声
数据加载和预处理混在推理路径里，容易掩盖真实模型耗时
常见错误是把cv2.imread、PIL.Image.open、transforms.Compose甚至numpy.array转换全塞进model.forward()同一时间线里计时，结果把磁盘IO、解码、CPU tensor搬运都算成“模型延迟”。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 单独对
model(input_tensor.cuda())这段做多次计时（至少50轮），排除前后置操作干扰 - 检查
input_tensor是否已位于GPU：若每次还走.to('cuda')，而tensor未持久化，会触发重复显存分配+拷贝 - 预处理尽量用
torchvision.transforms.v2（支持Tensor原生操作）或提前转好torch.uint8张量缓存，避免每帧重解码
torch.no_grad()没生效或被意外退出，导致计算图残留
哪怕只做推理，如果漏写with torch.no_grad():，或在no_grad块内调用了带梯度的函数（如torch.nn.functional.cross_entropy未设reduction='none'），PyTorch仍会构建计算图并保留中间变量，引发显存增长、GC压力和不可预测的延迟毛刺。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 确认推理代码严格处于
with torch.no_grad():作用域内，且无任何.requires_grad_(True)调用 - 禁用
torch.autograd.set_detect_anomaly(True)——这玩意只该调试时开，运行时必拖慢 - 用
torch.cuda.memory_allocated()监控单次推理后显存是否稳定；若持续上涨，大概率有计算图泄漏
CPU线程数、CUDA上下文初始化、NUMA绑定都会影响首帧和长稳表现
第一次model(input)往往比后续慢2–5倍：CUDA上下文创建、kernel JIT编译、cuBLAS/cuDNN句柄初始化全挤在这一次。更隐蔽的是，Python多线程/GIL切换、非绑定CPU核心跑推理线程、跨NUMA节点访问GPU，都会让延迟标准差飙升。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 上线前务必“热身”：用dummy input执行3–5次
model()，再开始计时 - 设置
torch.set_num_threads(1)防多线程争抢，尤其在容器或CPU配额受限环境 - Linux下用
numactl --cpunodebind=0 --membind=0 python infer.py绑定CPU和内存节点（根据nvidia-smi -L和lscpu匹配GPU所在NUMA）
真正难搞的是混合负载场景：比如同时跑日志采集、指标上报、后台心跳，这些看似无关的操作会偷偷抢占CPU周期或触发内核调度抖动——此时延迟不是模型的问题，而是你没把推理进程真正“隔离”出来。
