PyTorch循环处理数据时第二轮及后续迭代运行耗时异常升高

这个1s额外耗时不是动态图清理、显存清理操作本身的性能问题，本质是CUDA异步执行机制带来的耗时统计错位。

• CUDA默认采用异步执行逻辑：你在Python侧调用的张量计算、.backward()等所有GPU相关操作，CPU提交完指令到GPU任务队列后就会立刻返回，不会等待GPU实际执行完成。你观察到的第一轮循环Python侧代码跑完时，GPU侧还有大量收尾任务在后台运行，包括反向传播末尾的计算kernel、计算图析构触发的显存标记回收工作，这些任务不会阻塞Python代码往下走。
• 当你进入下一轮循环执行第一行代码时，只要这行代码涉及CUDA显存申请、或者隐式触发CPU/GPU同步（比如新的计算任务启动、CUDA张量转CPU、打印CUDA张量数值），就会强制CPU阻塞等待GPU把队列里所有积压的前置任务全部执行完成，你测到的1s额外耗时本质是在补上一轮没等完的GPU收尾工作的账，和这行代码本身的逻辑没有关系——这也是为什么你调整循环内代码顺序后，永远是第一行（准确说是下一轮第一个触发CUDA同步的代码）会拿到这个耗时，代码换到后面就正常。
• 断点调试时等待1-2秒再启动下一轮就没有额外耗时，刚好符合这个逻辑：等待的时间里GPU已经在后台把所有积压任务、显存回收工作全部做完了，下一轮代码执行时没有待完成的前置任务，自然不会产生阻塞。

你可以做两个简单测试直接确认：

1. 在每轮循环的末尾，也就是.backward()调用完成后，显式添加torch.cuda.synchronize()强制CPU等待GPU所有任务跑完，再统计耗时，你会发现这1s的耗时会从下一轮第一行转移到这句同步代码上，整个循环的总耗时不会发生任何变化。
2. 把循环第一行替换为完全不涉及CUDA的纯CPU操作（比如普通Python变量赋值、整数计算），你会发现这行代码完全没有额外耗时，阻塞只会出现在本轮第一个触发CUDA操作的代码位置。

• 如果只是做耗时统计，不需要额外修复：这个阻塞不是凭空多出来的性能损耗，只是你之前统计耗时的位置没有算上GPU异步执行的部分，只要把同步点放在每轮循环末尾再统计单轮时长，就能得到真实的分片处理耗时。
• 如果要优化整体吞吐，不要在循环里随意调用torch.cuda.empty_cache()，这个操作会强制触发显存块整理，反而会增加额外开销；你可以在每轮反向传播、参数更新完成后，显式del掉不再需要的中间张量、分片数据、损失值对象，提前给CUDA标记可回收的显存块，减少下一轮申请显存时的阻塞等待。
• 注意检查代码逻辑，不要把单轮的中间张量、计算结果绑定到全局变量或者循环外的列表/字典里，这种写法会导致对应轮次的计算图一直被引用无法回收，不仅会拉长每轮GPU收尾任务的时间，还会导致显存占用持续上涨。

内容的提问来源于stack exchange，提问作者EnglishM