PyTorch动态图机制与工程化训练全解析：从原理到多卡实践的避坑指南

说到PyTorch，很多人的第一印象是“写起来比别的框架舒服”。但这个“舒服”背后到底是什么机制在起作用，为什么它既能成为研究人员的首选，又在生产环境里越来越能打，其实值得重新算一笔账。

这篇文章我不想讲那种“PyTorch是什么、怎么安装、跑个mnist”的入门教程，而是想从一个用过它踩了无数坑、最后把它当主力框架来用的角度，把动态图的取舍、工程化环境搭建、训练循环的细节、多卡并行和常见Bug的排查链路一次讲清楚。适合谁看？已经跑过简单模型的初学者，以及准备把一个PyTorch项目往工程化、生产化方向推进的人。如果你只是想快速看个API用法，可能去翻文档更快；但如果你想理解“为什么PyTorch这样设计”“为什么我的训练又慢又不稳”，这篇文章应该有你要的答案。

1. 为什么PyTorch值得花力气搞懂：动态图的底层账要算清

1.1 动态图到底“动”在哪

很多人刚学PyTorch时，会把它理解成“能自动求导的numpy”。这个说法不算错，但它忽略了一个最关键的设计——动态图机制，也就是常说的define-by-run。

从字面看，define-by-run的意思很简单：计算图不是预先定义好的，而是随着代码运行现场构建的。你写x = torch.randn(4, 4)，这一行本身不产生任何图结构；等你执行y = x @ w，乘法算子被调用的时候，计算图才在框架内部把x、w、y关联起来。每跑一次前向，就有一张新的图被画出来。

这个“动”，最直接的好处是普通Python的控制流可以原样写进模型。比如你的模型里需要根据样本长度决定循环次数，可以直接for i in range(length)；需要根据某个条件分支，可以直接用if condition。这些在静态图时代都是让人头疼的事，要么得学会框架专用的控制流API，要么得接受“先定义图再执行”的割裂体验。用动态图写模型，本质上就是在写Python，大脑不需要在“代码逻辑”和“图结构”两套语言之间来回切换。

真正用过静态图框架再回到PyTorch的人，体会最深的其实是调试体验。在静态图框架里，你先define一个计算图，写完一大堆符号化描述，最后compile再run。如果某个中间变量和你预期不符，你得在图的定义里翻来覆去找。而PyTorch的前向代码就是普通Python代码，你可以随时打印中间变量、加断点、甚至临时改一行逻辑看看效果。这种调试自由度，对深度学习这种“试错密集型”工作来说，价值远远大于API本身。

1.2 它比静态图到底多付出了什么代价

天下没有白拿的舒服。动态图机制的代价，就是“每次建图都要额外开销”。

当一个模型很小、算子很多、单次计算量不大时，Python层的调度、张量绑定、图节点创建这些开销会非常抢眼——GPU可能还没开始干活，CPU已经在这里消耗了很大一块时间。我见过一个小模型在单卡上跑推理，PyTorch原生动态图比优化后的静态图慢一倍还多的情况。这不是版本缺陷，而是在小算子密集场景下，动态图确实天然吃亏。

为了追回这部分性能，PyTorch后续给出了自己的答案：TorchScript和torch.compile。TorchScript可以先把模型从一个支持动态Python特性的私有方言染成一个静态可执行表示，再交给底层运行时高效执行。torch.compile更激进，它在你第一次调用时分析模型结构，将其导出为中间图表示，然后生成针对当前硬件的高效代码。这个思路本质上就是“动态图捕获 + 静态优化”，算是把两个阵营的优点往一起揉。

我建议你把torch.compile当成一个现在就应该习惯使用的能力。新手阶段可以先不管，但当你发现某个模型在GPU上利用率很低、算子很小的时候，试试torch.compile(model, mode="reduce-overhead")，往往能白捡不小的性能提升。

1.3 什么时候该用它，什么时候不该硬上

学了动态图的原理和代价，“什么时候用谁”基本就清晰了。

如果你的工作以研究、快速验证、模型结构频繁改动为主，那PyTorch动态图几乎是最省心的选择。你可以把精力花在数据、特征、损失函数这些真正影响效果的事情上，而不是跟框架搏斗。即便后续要换到更高效的部署方案，也可以先跑通实验，再用ONNX或TorchScript做转换，路径是通着的。

但也有两类场景需要谨慎：一类是超大规模分布式训练，对通信、内存、算子融合都做了极其细致的静态优化诉求极强，这时可以和更专门的方案做对比测试，不能想当然；另一类是极低延迟推理场景，单算子级别的调度开销都会被放大，这时候也不能只看“PyTorch能跑”，还得看整体延时到底能不能达标。

我的个人倾向是：除非你清楚知道自己在做什么，否则不要因为“听说另一个框架部署更快”就放弃PyTorch。先让它帮你把模型本身做出来，部署的问题放到部署那一步去评估。大多数情况下，动态图带来的开发效率提升，远比那部分性能差异更重要。

2. 从环境到第一行代码：最省心的工程化起手式

2.1 环境到底怎么锁

在PyTorch项目里，环境问题排得上“最容易让人莫名其妙卡住”的前三名。很多人一句pip install torch装完就跑，过两天发现CUDA不可用、某算子报undefined symbol，然后开始怀疑人生。这些问题的根源八成是版本不匹配。

我建议从头就养成“锁环境”的习惯。第一步，先确认你的显卡驱动支持的CUDA版本。命令行里输入nvidia-smi，右上角能看到CUDA Version，这个是驱动能兼容的上限。第二步，根据这个上限去选择PyTorch的CUDA构建版本。PyTorch每个正式发布版本都有对应的CUDA版本组合，不是越新越好，而是“驱动支持 + 框架也提供”才稳。

基本的选择逻辑可以参考这个示意：

安装时也不要混着来。我见过太多人conda装一半、pip装一半，最后底层库被local覆盖，跑起来报一堆奇奇怪怪的错。用conda创建环境没问题，但装PyTorch时最好选一种包管理器一路装到底。创建独立环境这件事不是洁癖，是为了让不同项目的依赖互相隔离。一个稳妥的起手命令大概是：

conda create -n pt_env python=3.10 -y conda activate pt_env pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

装完别急着训练，先跑一个快速验证脚本：

import torch print(torch.__version__) print(torch.cuda.is_available()) print(torch.cuda.device_count()) print(torch.cuda.get_device_name(0))

如果torch.cuda.is_available()返回False，不用慌，按顺序查三件事：是不是装了CPU版PyTorch，驱动版本是否老到不被当前CUDA运行时支持，以及是否把GPU相关的系统库覆盖坏了。大多数情况都能在前两步定位。

2.2 一个能直接抄的PyTorch项目骨架

项目如果只躺在Notebook里，怎么折腾都没问题。但一旦要跑多组实验、记录模型版本、和同学或同事协作，一个清晰的项目结构就能省下大量时间。我常用且推荐的结构长这样：

project/ ├── configs/ # 实验配置，推荐yaml或dataclass ├── data/ # 数据集、预处理脚本 ├── models/ # 模型定义 ├── engine/ # 训练、验证、预测循环 ├── utils/ # seed设置、指标计算、可视化工具 ├── scripts/ # 启动脚本，例如 train.sh ├── experiments/ # 每个实验的日志、checkpoint、可视化结果 ├── requirements.txt └── main.py

这个骨架的核心思想是“各司其职”。models里只放模型结构，不放训练逻辑；engine里只放训练和验证循环，不放数据解析；configs里统一管理超参数，避免散落在代码各处。这样做的直接收益是：一个实验跑完，你能清晰看到“这个实验用了什么配置”“哪个checkpoint对应什么模型”“日志在哪里”，而不是翻遍磁盘找文件。

配置管理方面，比起堆一堆argparse参数，我更喜欢dataclass，因为它可以用Python语法写默认值、继承、类型校验，还非常容易序列化：

from dataclasses import dataclass, asdict @dataclass class TrainConfig: lr: float = 3e-4 batch_size: int = 32 epochs: int = 100 warmup_ratio: float = 0.05 seed: int = 42 log_dir: str = "./experiments/demo"

入口脚本保持短小，只负责解析配置、组装组件、启动训练。训练逻辑全在engine里，模型定义全在models里。这样后续换模型、换数据集，就不需要动训练主体代码。

2.3 随机种子与可复现性：第一步就要做对

深度学习的随机性来自很多层：Python的random、numpy的随机数、PyTorch的CPU和GPU随机数、以及cuDNN内部的自动调优。只设一个torch.manual_seed远远不够，标准做法是全部设一遍：

import random import numpy as np import torch def set_seed(seed: int): random.seed(seed) np.random.seed(seed) torch.manual_seed(seed) torch.cuda.manual_seed_all(seed) torch.backends.cudnn.deterministic = True torch.backends.cudnn.benchmark = False

cudnn.deterministic = True意味着框架会强制使用具有确定性结果的算法；benchmark = False则禁止cuDNN在运行时根据输入尺寸自动选择最优算法。这两项一起设，能显著提高可复现性，代价是某些模型会变慢一些。如果项目对速度要求高，而且不追求完全复现，可以把benchmark改回True，节省的性能相当可观。

但要泼一盆冷水：完全可复现在多卡和复杂数据流水线里是非常难做到的。DataLoader多进程加载数据的顺序、某些GPU算子的非确定性、DDP下梯度聚合顺序，都会带来微小差异。设置种子不是为了“每次结果逐比特一致”，而是为了让实验对比的时候，随机噪声被压到最低，让效果好坏真正来自你的改动。

3. 训练循环里看不见的三件事：Tensor、Autograd、DataLoader

3.1 Tensor不只是“能上GPU的numpy”

Tensor是PyTorch的数据核心，但它的身份比numpy数组复杂得多。一个Tensor身上除了数值和形状，还包含设备（CPU或GPU）、dtype、是否requires_grad、以及它在自动求导图里的位置。同样是一个二维数组，在numpy里它就是数据；在PyTorch里，它同时是“数值容器”和“求导节点”。

新手经常写出这样的代码：

numpy_array = tensor.cpu().detach().numpy()

这段链式操作每个环节都不能省：cpu()把张量从GPU搬到CPU，因为numpy数组不能直接对应显存；detach()把张量从梯度计算图中摘出来，避免之后对张量的修改被自动求导追踪；.numpy()才是真正转换为numpy数组。如果你图省事，直接对requires_grad=True的张量调用.numpy()，会直接报错——这个设计不是故意刁难，而是为了避免“带着梯度语义的数值”被当普通数组操作。

反向方向同样要注意。torch.from_numpy()创建的Tensor和原numpy数组共享底层内存，改了一方，另一方也会变。这在数据预处理时很高效，但也意味着如果你之后改变了numpy数组的内容，已经创建的Tensor数值会同步变化。把握一个原则：数据加载阶段可以玩共享内存，训练阶段请保持拷贝独立。

3.2 autograd的计算图：你写出的每一行代码都在给它画一张现场草图

动态图的另一层本质，就是自动求导的实现方式。看一段最简单的代码：

x = torch.tensor([2.0], requires_grad=True) y = x * 3 z = y.sum() z.backward() print(x.grad) # tensor([3.])

当y = x * 3被执行时，Python确实算出了结果，但同时在内部记录了一个求导节点，它知道“y是由x乘以3得到的”。z = y.sum()也会记录另一个节点，知道“z是由y求和得到的”。backward()从z出发，沿着这些节点反向走回去，最终把dz/dx算出来写到x.grad里。

这套机制最反直觉的地方是：它默认梯度会累积在叶子节点的grad属性上。这意味着如果你每个batch都直接loss.backward()，却不把优化器梯度清零，那上一个batch的梯度就会和下一个batch的梯度叠加，参数更新方向完全错乱。所以标准训练循环里，optimizer.zero_grad()、loss.backward()、optimizer.step()这个顺序不是随便定的，而是必须严格遵守的契约。

还有一个容易被忽略的点：对requires_grad=True的张量做in-place修改，是默认不允许的。原因很直接——计算图里的节点一旦被原地改动，后续反向传播就拿不到“当初这个值长什么样”了，梯度信息就废了。如果你发现代码报错说“a leaf Variable that requires grad is being used in an in-place operation”，别尝试绕过它，顺着报错去找那个被原地修改的张量，把它换个变量名或重新赋值才是正确做法。

3.3 DataLoader：训练快不快的隐藏功臣

很多人一提到训练慢，第一反应是“GPU不行”“模型太大”。但在真实项目里，数据加载跟不上导致GPU饿死的情况要多得多。让GPU的利用率被数据读取卡住，是最亏的事——GPU在跑空闲等待，电费还在烧。

DataLoader里有几个关键参数值得认真对待。num_workers控制数据加载的子进程数量，0表示在主进程里同步加载，最慢；设大了能并行读取，但也不能无限大，因为子进程创建、进程间通信和内存开销都会反噬性能。pin_memory=True会把数据放进锁页内存，CPU到GPU的拷贝会更快，适合训练，但会占用更多主机内存。shuffle在每个epoch重新打乱数据，训练集必须开，验证集不需要。collate_fn则负责把一个batch的样本组织成张量——如果你的样本是变长文本、变长序列、或者混合类型，这个函数是必须定制的。

一个经验参考表：

判断数据加载是不是瓶颈，有个很土但有效的办法：把模型前向和反向注释掉，只跑DataLoader，看它每秒能产出多少batch。如果它在空跑时都跟不上训练速度，那问题不在模型，在数据管道。一个__getitem__里如果有图片读取、随机裁剪、标准化，请一定把这些操作放在Dataset里而不是训练循环里，否则每次迭代都干等。

4. 从入门到能生产：训练脚本里真正不能省的细节

4.1 优化器和学习率调度：不是“Adam一把梭”就完事

Adam之所以流行，是因为它对学习率不那么敏感，能自动调整每个参数步长，新手也能跑得动。但Adam并不是万金油：它的权值衰减实现方式从一开始就和L2正则不完全等价，这在Transformer类模型里容易体现出来；而且Adam在训练后期往往收敛不够犀利。

更通用的做法是：视觉Transformer类任务，直接用AdamW，这是目前实践中最稳的选择之一；传统CNN分类任务，SGD加momentum往往有更好的泛化性，但学习率和warmup要调得更仔细。可以简单参考：

学习率调度同样不能忽略。我推荐组合scheduler的思路：先用一个线性warmup在前几百步把学习率从很小抬到目标值，再用余弦退火在训练后期缓慢降低。warmup不是花架子——训练初期模型参数离良好状态很远，梯度方向噪声大，此时如果直接用大招学习率，很容易把参数推到陡峭的坏区域里。

常见的学习率调度器在PyTorch里都是现成的：

from torch.optim.lr_scheduler import CosineAnnealingLR scheduler = CosineAnnealingLR(optimizer, T_max=total_steps, eta_min=1e-6)

要注意调度器是按epoch还是按step调用。有些scheduler在每个epoch后step()，有些（比如带warmup的自定义调度）需要在每个optimizer.step()之后step()。我踩过的坑是：明明scheduler配好了，却忘了在循环里调用step()，导致学习率从头到尾没变过。排这种问题，最好的办法是定期打印或记录当前学习率，看到实际数值，远比记忆API用法可靠。

4.2 自动混合精度：显存不够时先别急着换显卡

显存OOM几乎是每个训练深度学习的人都会遇到的事。换更大显存的显卡成本太高，其实先算一笔账：用自动混合精度 AMP，很多模型可以立刻把显存占用降到原来的一半左右，收益非常可观。

AMP的思路是让模型计算时用float16，因为半精度天然只有float32一半的显存占用，同时很多新GPU有专门加速半精度矩阵运算的硬件单元。但float16的数值范围太窄，小梯度容易直接下溢到0。所以PyTorch用一个GradScaler，在反向传播前给loss乘一个大数，把梯度放大到float16能表示的范围内；更新参数前再缩小回去。这套流程在PyTorch里几乎透明：

scaler = torch.cuda.amp.GradScaler() for batch in loader: optimizer.zero_grad() with torch.autocast(device_type="cuda", dtype=torch.float16): loss = model(batch) scaler.scale(loss).backward() scaler.step(optimizer) scaler.update()

使用AMP的最大经验教训是：不要一上来就开。先用纯float32把代码跑通，验证数据和模型无误，再加上AMP。如果加了之后loss出现NaN，先排查一下是不是学习率过大把梯度冲爆了，然后再怀疑AMP本身。因为float16的范围限制，有些本来在float32下没事的大梯度，在float16下更容易溢出。必要的时候再给一些数值敏感的层换成float32计算。GradScaler有个很好的机制：一旦发现loss出现Inf或NaN，它会自动降低scale因子并跳过这次参数更新，这也是为什么AMP通常不会让训练直接崩掉，而只是“默默跳步”，损失曲线偶尔会跳一下。

4.3 checkpoint与断点恢复：断电暴怒的次数是这么降下来的

训练跑了两天，一个断电全没了，这个痛我太懂了。所以checkpoint保存一定要把“恢复训练所需的一切”都存下来，而不是只存一个模型权重。

一个推荐的保存字典结构：

torch.save({ "epoch": epoch, "model": model.state_dict(), "optimizer": optimizer.state_dict(), "scheduler": scheduler.state_dict(), "scaler": scaler.state_dict() if use_amp else None, "best_metric": best_metric, "config": train_config, # 你定义的dataclass/yaml }, f"{save_dir}/checkpoint.pt")

有人问为什么保存optimizer和scheduler的状态？因为恢复训练时如果只有模型权重，学习率状态、momentum的累积速度、Adam的一阶二阶矩估计全丢了，等于从零重开优化器，训练的连续性大打折扣。保存scaler则能保证AMP的scale因子不重置，避免恢复后因为梯度scale过小导致长时间训练无效。

断点恢复时的逻辑也很简单：如果checkpoint存在，加载它，从epoch+1继续，并把best_metric带回比较。

写checkpoint时还有一个效率细节：先写到临时文件，比如checkpoint.pt.tmp，确认写完后用os.replace()改名成正式文件。因为直接写正式文件一旦中途出错，那个文件就损坏了，整个训练成果瞬间成灰。别看这个动作小，真到关键时刻能救你一次。

5. 多卡训练与分布式：单卡模型跑通后，路往哪走

5.1 DP和DDP都叫多卡，但差距不是一点点

PyTorch里有两个常见多卡方案：DataParallel和DistributedDataParallel。名字很像，实际上差距巨大。

DataParallel是单进程多线程模型。它在每次前向时，把一个batch拆成几份，分别分发到多张GPU上，再把结果聚合到主卡上。问题也出在这：主卡既要负责数据分发，又要负责结果汇总，通信量大，多卡之间的利用率经常严重不均衡；更别提BN和随机种子在单进程多线程下的坑。

而DistributedDataParallel走的是多进程路线：每张GPU一个独立进程，每个进程拿到独立的batch，独立做前向和反向，最后通过集合通信把梯度过一遍。它没有主卡聚合的瓶颈，扩展性要好得多。在正式环境里，DDP已经是事实标准。我的建议是：别在DP上花太多时间，直接学DDP，一劳永逸。

5.2 一个最小可用的DDP训练循环

在PyTorch里跑DDP并不玄乎，先初始化进程组，再把模型包一层DDP，用torchrun启动即可。核心代码骨架大概是这样的：

import torch import torch.distributed as dist from torch.nn.parallel import DistributedDataParallel as DDP def train(): dist.init_process_group(backend="nccl") rank = dist.get_rank() local_rank = rank % torch.cuda.device_count() torch.cuda.set_device(local_rank) model = build_model().to(local_rank) model = DDP(model, device_ids=[local_rank]) model.train() sampler = torch.utils.data.distributed.DistributedSampler(dataset, shuffle=True) loader = torch.utils.data.DataLoader(dataset, batch_size=32, sampler=sampler) for epoch in range(num_epochs): sampler.set_epoch(epoch) # 这个不能省 for batch in loader: ... optimizer.zero_grad() loss.backward() optimizer.step() if __name__ == "__main__": train()

启动命令用torchrun：

torchrun --nproc_per_node=4 train.py

--nproc_per_node表示几张卡开几个进程。torchrun会自动帮你设置RANK、WORLD_SIZE、LOCAL_RANK这些环境变量，代码里直接读就好，不要自己手动去绑端口和设分配。

DDP最容易踩的坑有几个。第一个是忘记sampler.set_epoch(epoch)，这会导致每个epoch数据都被同样切分，shuffle形同虚设。第二个是全局batch_size的含义变了：DDP下每张卡独立取样，实际全局batch是per_gpu_batch_size * world_size，如果每卡32、用了4卡，全局batch就是128，学习率通常也要相应放大，否则收敛行为会变。第三个是用了DistributedSampler之后，DataLoader里不要再设shuffle=True，两者会冲突。第四个是日志输出，如果不限制只在某个rank打印，你会看到每个进程都把日志刷一遍，所以我一般只在rank == 0的进程里写日志和保存checkpoint。

BN在DDP里也有讲究。不同进程的数据是独立分布的，默认BN的running mean只在各自进程里更新，最后不完全一致；如果任务对BN统计量敏感，可以用torch.nn.SyncBatchNorm.convert_sync_batchnorm(model)把所有BN层转成跨进程同步版本。代价是会增加通信量，小模型可能会拖慢训练，需要自己权衡。

5.3 多卡不加速？先算算账

很多人一跑到DDP就兴奋地以为“从1卡到4卡，速度应该翻四倍”，实际一测发现只快了1.5倍，甚至更慢。这不是DDP坏了，而是训练过程里除了计算，还有数据加载、梯度同步、日志写盘这些环节，它们不全是能被并行加速的。

如果模型非常小，单卡上GPU利用率本来就不高，那加再多卡，通信开销反而会成为主导。建议先做一次简单的吞吐测试：同样一个epoch，记录单卡和多卡每秒处理的样本数。如果多卡吞吐只提升了不到1.5倍，先排查数据加载是否已经打满，再看batch是否设得太小——batch越小，通信与计算的比值越差。

更深层的并行方式并不是越多越好。模型太大装不进单卡时，可以走模型并行，把网络的不同层分配到不同卡；Transformer类超大模型还会用流水线并行，让不同层在不同卡上接力计算；更极端的场景甚至会做张量并行。但这些技巧的共同前提是“你的模型真的需要这个复杂度”。对绝大多数应用，数据并行+DDP就够用了，先把单卡和DDP吃透，比盲目追求几百亿参数的低效模仿有意义得多。

6. 调试与性能排查：那些让你怀疑人生的Bug怎么快速定位

6.1 先看症状，再按优先级排查

训练深度学习模型，调试占了很大一部分时间。与其每次遇到问题都从头猜，不如建立一张问题速查表，把自己可能的错误方向提前排除。

关键是在定位问题之前，先想清楚“最可疑的三天”。不要一行行代码去读，先用这个表格排除掉80%的常见问题，再把精力花在真正可疑的20%上。

6.2 loss不降：按“数据-模型-优化器”的顺序排查

有次我在做一个语义分割Demo，训练loss从一开始就几乎是一条水平线。我一度怀疑是模型容量不够，调了两天模型结构，毫无变化。最后漫不经心抽了一张训练的图出来看，才发现数据集的标签和图像内容大约有四分之一是对不上的——数据错了，后面再折腾模型都是在浪费时间。

从那以后，我形成了一个固定习惯：loss不降，第一件事不是改模型，而是验证数据。随机抽几对样本，看一眼图像内容和标签是否匹配，统计一下标签分布是否异常；再用一个很小的模型在很小的子集上过拟合试试，如果连过拟合都做不到，那大概率是数据管道出的问题。数据没问题，才去看模型的输出是不是始终是恒定值，再看学习率是不是过小导致更新完全不够。

一个特别实用的调试手段是：在训练最开始就固定随机种子，分别用“未初始化的模型”和“一个很浅的初始化模型”跑几个step，对比loss的变化。如果两个条件下loss都不动，说明这个问题既不是模型容量也不是初始化，很可能是优化器设置的问题——比如学习率设成了0，或者optimizer.zero_grad()放错了位置。

6.3 显存泄漏的完整排查链路

显存OOM不一定是你batch太大，也可能是因为“显存泄漏”——某个变量一直占着GPU内存不释放，随着epoch增加，占用缓缓上涨，最后在某一个epoch爆掉。

我遇到过的一个典型场景：验证阶段为了最后画图把预测结果都存到一个列表里，而这个列表的生命周期贯穿整个训练循环，于是每跑一个epoch就多存一批预测值，显存不断上涨。这种问题最烦的地方在于：它不是一开始就炸，而是“稳定训练到第N个epoch才炸”，特别迷惑。

排查显存泄漏，不要用肉眼看nvidia-smi，要看趋势。在代码里定期记录这两项：

allocated = torch.cuda.memory_allocated() max_allocated = torch.cuda.max_memory_allocated()

如果memory_allocated在每次epoch结束后没有回落，而是逐步走高，几乎可以断定有变量被长期持有。常见的持有方式有：把每个batch的Tensor追加进一个大list；把中间层的输出保存到self.xxx；checkpoint或日志里直接引用了整个Tensor而不是标量。

torch.cuda.empty_cache()并不会“解决”泄漏，它只是把碎片化的缓存内存回收释放，治标不治本。真正要做的，是找到那个被长期持有的引用并删掉。如果找不到，就沿着所有.append()和self.赋值去搜，基本跑不掉。一个很好的习惯是：需要保存历史值时，把它转换成CPU上的Python标量再存，不要直接把Tensor留在GPU上过夜。

6.4 AMP下的NaN：别急着骂框架，先找出路

混合精度训练最容易出现的怪现象是：前面正常，跑着跑着loss突然变成NaN，然后又好了；或者干脆隔几个batch就出现一次。

我的排查路线是这样的：先确定是不是AMP带来的问题——把autocast关掉，纯float32跑几十个step，如果NaN消失，说明问题基本定位在AMP。接下来检查几个地方：

• 输入数据里有没有NaN或Inf，这种脏数据在float32下可能侥幸撑过去，但经过float16的缩小后更容易暴露。
• 学习率是否过大，导致部分参数的梯度在float16下溢出。一个直接的办法是打印GradScaler.get_scale()，如果它频繁缩小再回升，说明溢出事件一直在发生。
• 是否有某些层的输出范围天生很大或很小，这些层如果对数值敏感，可以单独放在float32区域计算，比如with torch.cuda.amp.autocast(enabled=False):。

AMP出现NaN时有一个常识要记住：fp16能表示的数值范围比fp32窄得多，所以同样是学习率太大导致的梯度爆炸，在AMP下会表现得更加明显。这不是AMP本身有缺陷，而是它把本来就存在的问题提前暴露了。把学习率降低，或者加入梯度裁剪clip_grad_norm_，往往比花时间深挖古怪的框架行为更直接有效。

6.5 调试辅助手段与我的最后一点经验

如果问题实在诡异，可以用torch.autograd.set_detect_anomaly(True)打开异常检测，它会在反向传播过程的算子里定位到疑似出错的那一层。说真的，这个功能很香，但代价是训练会明显变慢。我只在debug阶段开，定位到问题后立刻关掉。

还有一个经验值得分享：新项目起步时，先用最小可行配置跑通——单卡、纯float32、不开AMP、不加多卡、不搞复杂的数据增强。跑通之后再一个个叠加新特性。这个方法看似慢，实则快：它把“我改了数据增强”和“我加了AMP”和“我换了多卡”这些变量分隔开，让偶发的Bug可以被快速归因。反过来，如果一开始就全堆上去，出了问题根本分不清是哪个环节的功劳还是锅。

以我目前的使用体会来说，这套“先跑通，再加细节”的思路比任何框架技巧都重要。PyTorch本身并不复杂，复杂的是使用过程中不断累积的变量和交互。把每一步可能的差异性控制在一个可控的范围内，你的训练流程自然就会从“总是有点问题”变成“大部分时候平稳运行”。