很多刚上手 PyTorch 的人在写完loss.backward()之后都会愣一下梯度到底存到哪了为什么我第二次 backward 就报错了为什么有的张量.grad是 None有的却是实打实的数值这些问题看起来零碎其实都指向同一件事——PyTorch 的自动微分机制到底是怎么运转的。张量的梯度计算是 PyTorch 整个训练体系的发动机搞不清它后面写优化器、写自定义损失、做梯度裁剪、调学习率全是照葫芦画瓢出了问题根本无从下手。这篇内容面向的是已经能跑通一个简单训练脚本、但对梯度机制还停留在“会调用 API”层面的读者。我会从张量为什么需要梯度讲起把计算图、叶子节点、梯度累加、detach与no_grad的区别、梯度检查这些容易混淆的点一个个拆开配上可以直接复现的代码和实测结果。看完之后你应该能对着任意一段 PyTorch 代码准确说出每个张量的梯度会流向哪里、什么时候被清空、为什么有时候需要手动干预。下面这些内容都是我在实际调试和带人过程中反复验证过的踩过的坑也会一并写出来。1. 梯度这件事先搞清楚张量在记录什么1.1 requires_grad 不是开关而是“记账标记”很多人把requires_gradTrue理解成一个“开启梯度计算”的开关这个理解不算错但太浅了。更准确的说法是它给这个张量打上了一个“记账标记”从此之后所有以它为输入的运算PyTorch 都会在后台记一笔账把运算关系记录下来形成一张有向无环图也就是常说的计算图。import torch x torch.tensor([2.0, 3.0], requires_gradTrue) y x * x 1 print(y.requires_grad) # True print(y.grad_fn) # AddBackward0 object注意y.grad_fn这个属性。只要一个张量的requires_grad是 True并且它不是用户直接创建的而是运算产生的它就一定带一个grad_fn指向产生它的那个运算的反向函数。这个grad_fn就是计算图上的一个节点反向传播时 PyTorch 正是顺着这些节点一路往回走的。这里有个特别容易被忽略的点只有浮点类型和复数类型的张量才能设置requires_gradTrue。整数张量不行会直接报错。原因是梯度本质上是导数整数没有连续可导的概念。我见过有人用torch.tensor([1, 2, 3], requires_gradTrue)然后困惑为什么报错其实就是类型问题加上dtypetorch.float32就好了。1.2 计算图是动态搭出来的不是提前定义好的和某些静态图框架不同PyTorch 的计算图是在前向计算的过程中一边算一边搭的。你每执行一行涉及需要梯度的张量的运算图就长出一个节点。这意味着两件事第一图的结构完全取决于你代码的实际执行路径if分支走哪边图就是哪样第二前向算完图就在那了反向传播就是沿着这张已经搭好的图往回走。a torch.tensor(1.0, requires_gradTrue) b a * 2 c b ** 2 # 此时图的结构: a - MulBackward - b - PowBackward - c c.backward() print(a.grad) # 8.0因为 dc/da 2 * (2a) 4a 4我特意把中间变量b写出来是想强调图是跟着变量走的。如果你写成c (a * 2) ** 2中间那个b就不存在了但图照样会记录乘法节点和幂运算节点只是你拿不到中间变量的引用了。这个区别在做梯度调试的时候很关键——想检查中间层梯度就得把中间结果赋给变量留住。1.3 叶子节点梯度最终落脚的地方计算图里的张量分两类叶子节点和非叶子节点。用户直接创建的、requires_gradTrue的张量就是叶子节点比如模型里的权重参数由运算产生的张量是非叶子节点比如中间激活值。默认情况下反向传播只会把梯度累加到叶子节点的.grad上非叶子节点的梯度算完就丢了。w torch.tensor([1.0, 2.0], requires_gradTrue) # 叶子 h w * 3 # 非叶子 loss h.sum() loss.backward() print(w.grad) # tensor([3., 3.])叶子有梯度 print(h.grad) # None非叶子默认不保留这个设计不是偷懒而是出于内存考虑。一个深层网络里中间激活值成千上万如果每个都保留梯度显存瞬间就爆了。真要看非叶子节点的梯度得手动调用h.retain_grad()这个后面会细说。理解“梯度只落在叶子节点”这一条能解释掉一大半“为什么我的.grad是 None”的困惑。2. backward 到底做了什么梯度又是怎么累加的2.1 一次 backward 的完整链路调用loss.backward()时PyTorch 做的事情可以拆成几步从loss这个标量出发沿着grad_fn链反向遍历计算图每到一个节点就调用该节点对应的反向函数用链式法则把上游传来的梯度乘以本地的导数得到传给下游的梯度一直传到叶子节点把结果累加到它们的.grad属性上。这里有个硬性约束backward()默认只能对标量调用。如果你的 loss 是个向量直接 backward 会报 “grad can be implicitly created only for scalar outputs”。解决办法有两个要么先loss.sum()或loss.mean()变成标量要么给backward()传一个和输出同形状的gradient参数相当于指定每个输出分量的权重。v torch.tensor([1.0, 2.0, 3.0], requires_gradTrue) out v * 2 # out.backward() # 报错 out.backward(torch.tensor([1.0, 0.0, 0.0])) # 只对第一个分量求导 print(v.grad) # tensor([2., 0., 0.])传gradient参数这个用法在写自定义损失或者多任务学习时很有用它等价于给输出乘上一个权重向量再求和。理解这一点你就明白为什么标量能直接 backward——标量相当于天然带了一个权重 1。2.2 梯度是累加的不是覆盖的这是新手最容易栽的坑没有之一。PyTorch 的.grad属性是累加语义每次 backward 都会把新算出来的梯度加到已有的值上而不是替换掉。x torch.tensor(1.0, requires_gradTrue) y x ** 2 y.backward() print(x.grad) # 2.0 y x ** 2 y.backward() print(x.grad) # 4.0不是 2.0累加了为什么会这样设计因为在某些场景下累加是有意义的比如一个参数在多个地方被用到参数共享一次 backward 里它的梯度本来就该是各路径梯度之和。但放到常规的训练循环里如果你不在每轮迭代开始时清零梯度上一轮的梯度就会污染这一轮模型直接训飞。所以标准训练循环里一定有这一行optimizer.zero_grad()它的作用就是把优化器管理的所有参数的.grad置零或者置为 None取决于set_to_none参数。我个人的习惯是把它放在loss.backward()之前、前向计算之后逻辑上更顺先清账再算新账。放的位置其实不影响结果只要在 backward 之前就行但保持固定位置能避免自己看花眼。2.3 第二次 backward 报错的真正原因跑过这段代码的人应该都见过这个报错RuntimeError: Trying to backward through the graph a second time...原因在于反向传播走完一遍之后为了省内存PyTorch 会把计算图里保存的中间结果释放掉。你第二次对同一个 loss 调 backward图已经残缺了自然走不通。x torch.tensor(2.0, requires_gradTrue) y x ** 3 y.backward() print(x.grad) # 12.0 # y.backward() # 报错图已被释放要重复利用同一张图得在第一次 backward 时加retain_graphTruey.backward(retain_graphTrue) y.backward() print(x.grad) # 24.0两次累加但我要提醒一句retain_graphTrue不是随便加的。它会让中间结果不被释放显存占用上升。真正需要它的场景其实不多主要是同一张图要算多次梯度比如某些 GAN 的训练技巧、或者对同一 loss 求高阶导。如果你只是想在训练循环里反复 backward那正确做法是每轮重新做前向计算而不是保留旧图。3. detach、no_grad 和 inference_mode三个容易混的家伙3.1 detach 是“剪断”计算图detach()返回一个和原张量共享数据、但脱离计算图的新张量。它不再有grad_fnrequires_grad也变成 False。用它参与后续运算不会在图上留下任何痕迹。a torch.tensor([1.0, 2.0], requires_gradTrue) b a * 2 c b.detach() * 3 print(c.requires_grad) # False print(c.grad_fn) # None这个操作在几个场景下是刚需。一是你想拿某个中间结果做记录或打印不希望它牵扯进梯度计算二是实现某些自定义逻辑比如目标网络target network的更新需要把参数值拷过来但不建立梯度关系三是做梯度截断把某条路径的梯度人为切断。有个细节值得说detach()出来的张量和原张量共享底层存储。也就是说如果你原地修改了 detach 后的张量原张量的数据也会变。这个特性有时候会被利用来做一些原地操作但也容易埋雷改之前想清楚。3.2 no_grad 是“整段关灯”torch.no_grad()是一个上下文管理器它管辖范围内的所有运算都不记录梯度不管张量的requires_grad是什么。with torch.no_grad(): y a * 2 print(y.requires_grad) # False它和detach()的区别在于作用范围detach()作用于单个张量no_grad()作用于一段代码。推理阶段、评估阶段、参数手动更新都该包在no_grad()里。原因很实在——不记录梯度能省下大量显存和计算推理速度也会快一些。我见过有人在评估循环里忘了加no_grad()结果显存一路涨跑到一半 OOM。排查半天以为是模型太大其实是评估时还在默默搭图。这种问题加一行上下文就解决了。3.3 inference_mode 比 no_grad 更彻底较新版本的 PyTorch 提供了torch.inference_mode()它比no_grad()更激进不仅不记录梯度连版本计数等推理用不上的元信息都不维护因此开销更低。with torch.inference_mode(): y a * 2代价是它产生的张量不能再参与需要梯度的运算也不能做某些原地操作。纯推理场景下优先用它如果代码里还有需要梯度的逻辑混着那就退回no_grad()。我一般的判断标准很简单这段代码只做前向、结果只用来出预测就用inference_mode如果拿不准用no_grad更保险。下面这张表把三者的差异摆在一起方便对照特性detach()no_grad()inference_mode()作用对象单个张量代码块代码块是否共享存储是不涉及不涉及开销低中最低产生张量能否再求导否否否典型场景切断单条路径评估、手动更新参数纯推理部署4. 非叶子节点的梯度以及 retain_grad 的正确用法4.1 为什么默认不保留中间梯度前面提过非叶子节点的.grad默认是 None。这个设计的核心动机是内存。设想一个 50 层的网络每层激活值都是几 MB 的张量如果每个都保留梯度显存需求会翻好几倍。而训练时我们真正需要的只是参数叶子节点的梯度中间激活的梯度算完即用、用完即弃是最经济的做法。但调试的时候我们恰恰想看中间层的梯度是否正常——梯度消失、梯度爆炸往往就发生在中间某几层。这时候retain_grad()就派上用场了。4.2 retain_grad 的实操与代价w torch.tensor([1.0, 2.0], requires_gradTrue) h w * 3 h.retain_grad() # 关键一步必须在 backward 之前调用 loss h.sum() loss.backward() print(h.grad) # tensor([1., 1.])调用顺序很重要retain_grad()必须在反向传播之前执行因为它是给这个张量打标记告诉引擎“算到我的时候把梯度留下来”。backward 之后再调就没意义了。代价是显存。每保留一个中间张量的梯度就多占一份和它同形状的存储。所以我的建议是调试阶段针对性地对少数几个关心的层调retain_grad()定位完问题就删掉别留在正式训练代码里。曾经有人图省事给所有中间变量都加了retain_grad()结果显存直接翻倍训练 batch size 被迫砍半得不偿失。4.3 用 hook 做更灵活的梯度观测如果只是想观测梯度、不想改张量的保留行为注册 hook 是更优雅的方式。register_hook可以在某个张量的梯度算出来时插入一个回调拿到梯度值做记录或修改。grads {} def save_grad(name): def hook(grad): grads[name] grad return hook h w * 3 h.register_hook(save_grad(h)) loss h.sum() loss.backward() print(grads[h]) # tensor([1., 1.])hook 的好处是不改变计算图本身的行为观测完自动失效如果不手动移除的话会一直挂着这点要注意。做梯度监控、画梯度分布图的时候这套机制比retain_grad更干净。不过 hook 里别做太重的操作它是在反向传播过程中同步执行的写复杂逻辑会拖慢训练。5. 梯度检查与常见异常排查5.1 用 gradcheck 验证自定义函数的梯度如果你自己实现了某个运算的反向传播通过继承torch.autograd.Function那必须验证梯度算得对不对。PyTorch 提供了torch.autograd.gradcheck它用数值微分有限差分来对比你解析计算的梯度。from torch.autograd import gradcheck class MyFunc(torch.autograd.Function): staticmethod def forward(ctx, x): return x ** 2 staticmethod def backward(ctx, grad_out): x, ctx.saved_tensors return grad_out * 2 * x f MyFunc.apply x torch.randn(3, dtypetorch.double, requires_gradTrue) print(gradcheck(f, (x,))) # True 表示梯度正确注意这里必须用double类型因为数值微分对精度敏感float32 的误差容易导致误判。gradcheck 跑起来比较慢只在开发自定义算子时用别塞进训练循环。5.2 梯度为 None 的几种典型情况排查梯度问题时.grad是 None 是最常见的现象。我整理了几种高频原因按出现频率排序现象可能原因排查方法参数 .grad 为 None参数没设 requires_grad检查p.requires_grad参数 .grad 为 None参数没参与前向计算打印计算图或用 hook 确认参数 .grad 为 None被 detach 或包在 no_grad 里检查上下文和 detach 调用中间张量 .grad 为 None非叶子节点默认不保留调retain_grad()梯度全为 0激活函数饱和或路径被切断检查激活值分布其中“参数没参与前向计算”这条最隐蔽。比如你定义了一个分支网络某个 batch 里这个分支没被走到那它的参数这一轮就没有梯度.grad保持 None 或旧值。这种情况在条件计算、MoE 结构里很常见排查时得结合前向逻辑一起看。5.3 梯度爆炸与消失的快速定位梯度爆炸表现为 loss 突然变成 NaN 或者参数值飞掉梯度消失表现为深层参数几乎不更新。定位手段是打印各层梯度的范数total_norm 0 for p in model.parameters(): if p.grad is not None: param_norm p.grad.data.norm(2) total_norm param_norm.item() ** 2 total_norm total_norm ** 0.5 print(fgrad norm: {total_norm})如果这个范数在训练中持续增大到几百上千基本就是爆炸了可以考虑梯度裁剪torch.nn.utils.clip_grad_norm_。如果它一直很小甚至趋近于零那要检查是不是网络太深、激活函数选得不对或者初始化有问题。我习惯在训练脚本里每隔若干步打印一次这个范数成本很低但出问题时能第一时间发现苗头。6. 几个实战中反复踩到的坑6.1 在 loss 上做 in-place 操作对需要梯度的张量做原地操作比如x 1、x.relu_()很容易触发 “a leaf Variable that requires grad is being used in an in-place operation” 或者版本计数相关的报错。原因是原地修改会破坏反向传播所需的前向值。解决办法是改用非原地版本x x 1、x x.relu()。这个坑在写自定义损失时特别容易踩因为很多人习惯用累加。6.2 优化器更新参数时忘了 no_grad手动更新参数不通过优化器时如果直接p - lr * p.grad会报错因为这行运算本身会被记录进计算图。正确写法是包在no_grad()里with torch.no_grad(): for p in model.parameters(): p - lr * p.grad用优化器的话它内部已经处理好了不用操心。但自己写更新逻辑时这个上下文不能漏。6.3 混合精度下的梯度缩放用混合精度训练时梯度可能因为 float16 表示范围小而下溢成 0。标准做法是配一个 GradScaler 做梯度缩放backward 时用scaler.scale(loss).backward()更新前scaler.unscale_(optimizer)再裁剪最后scaler.step(optimizer)和scaler.update()。这套流程顺序不能乱乱了梯度要么没缩放要么没还原训练效果直接崩。我见过有人把scaler.step和optimizer.step混着调结果参数更新了两次loss 曲线诡异得很。6.4 多卡训练下的梯度同步数据并行训练时各卡各自算梯度然后做 all-reduce 求平均。如果你在单卡上调试好的梯度裁剪逻辑直接搬到多卡要注意裁剪应该发生在梯度同步之后否则每张卡按自己的局部梯度裁剪同步后的整体梯度范数就不受控了。这个细节在分布式训练里很关键但单卡调试时完全暴露不出来。7. 把梯度机制用进日常调试7.1 一个可复用的梯度健康检查函数我把前面零散的手段整合成一个函数训练时定期调用能覆盖大部分梯度异常def check_gradients(model, step): report {} for name, p in model.named_parameters(): if p.grad is None: report[name] None else: report[name] round(p.grad.norm(2).item(), 6) print(f[step {step}] {report})输出里如果某个参数长期是 None说明它没被训练到如果某个范数异常大就是爆炸信号。这个函数本身开销不大但信息量足够定位问题。我一般在前几百步每 50 步调一次稳定后拉长间隔。7.2 理解梯度流比记住 API 更重要写到这里我想强调一个观点PyTorch 的梯度 API 就那么几个backward、zero_grad、detach、no_grad、retain_grad背下来不难。真正拉开差距的是你能不能在心里画出梯度流——给定一段代码说出每个张量的梯度从哪来、到哪去、在哪被截断、在哪被累加。这个能力不是靠记 API 得来的是靠反复调试、反复看.grad和grad_fn练出来的。我个人的习惯是遇到任何梯度相关的疑惑第一反应是打印grad_fn和requires_grad把计算图在脑子里重建一遍。大部分“莫名其妙”的报错打印两行就能定位。比如那个经典的“backward second time”报错只要看一眼 loss 的grad_fn还在不在就知道图是不是被释放了。7.3 关于性能的一点经验最后分享一个容易被忽视的点梯度计算本身是有成本的。前向时保存中间结果、反向时逐节点求导这些都要时间和显存。所以推理、评估、特征提取这些不需要梯度的场景务必用no_grad或inference_mode包起来。我实测过一个中等规模的模型评估阶段加上no_grad后显存占用降了将近四成吞吐也提升了一截。这个优化几乎零成本但很多人写评估代码时就是会忘。另外zero_grad(set_to_noneTrue)比默认的置零方式略快因为它省去了写零的操作直接把.grad设成 None下次 backward 时再分配。较新版本的 PyTorch 默认就是set_to_noneTrue如果你用的是老版本可以手动打开这个选项积少成多也是收益。梯度计算这套机制初看是一堆 API用熟了会发现它其实是一套很自洽的设计用计算图记录运算、用叶子节点收拢梯度、用累加语义支持参数共享、用释放机制控制内存。把这几个核心概念串起来剩下的都是细节。真正吃透之后你写训练代码会从“照着模板填”变成“知道每一步为什么这么写”遇到问题也能自己顺着梯度流排查而不是到处搜报错信息。 
长河君 · 2026/10/26 4:20:05 · 阅读 1.2k PyTorch自动微分机制详解：计算图、梯度累加与调试技巧
很多刚上手 PyTorch 的人在写完loss.backward()之后都会愣一下梯度到底存到哪了为什么我第二次 backward 就报错了为什么有的张量.grad是 None有的却是实打实的数值这些问题看起来零碎其实都指向同一件事——PyTorch 的自动微分机制到底是怎么运转的。张量的梯度计算是 PyTorch 整个训练体系的发动机搞不清它后面写优化器、写自定义损失、做梯度裁剪、调学习率全是照葫芦画瓢出了问题根本无从下手。这篇内容面向的是已经能跑通一个简单训练脚本、但对梯度机制还停留在“会调用 API”层面的读者。我会从张量为什么需要梯度讲起把计算图、叶子节点、梯度累加、detach与no_grad的区别、梯度检查这些容易混淆的点一个个拆开配上可以直接复现的代码和实测结果。看完之后你应该能对着任意一段 PyTorch 代码准确说出每个张量的梯度会流向哪里、什么时候被清空、为什么有时候需要手动干预。下面这些内容都是我在实际调试和带人过程中反复验证过的踩过的坑也会一并写出来。1. 梯度这件事先搞清楚张量在记录什么1.1 requires_grad 不是开关而是“记账标记”很多人把requires_gradTrue理解成一个“开启梯度计算”的开关这个理解不算错但太浅了。更准确的说法是它给这个张量打上了一个“记账标记”从此之后所有以它为输入的运算PyTorch 都会在后台记一笔账把运算关系记录下来形成一张有向无环图也就是常说的计算图。import torch x torch.tensor([2.0, 3.0], requires_gradTrue) y x * x 1 print(y.requires_grad) # True print(y.grad_fn) # AddBackward0 object注意y.grad_fn这个属性。只要一个张量的requires_grad是 True并且它不是用户直接创建的而是运算产生的它就一定带一个grad_fn指向产生它的那个运算的反向函数。这个grad_fn就是计算图上的一个节点反向传播时 PyTorch 正是顺着这些节点一路往回走的。这里有个特别容易被忽略的点只有浮点类型和复数类型的张量才能设置requires_gradTrue。整数张量不行会直接报错。原因是梯度本质上是导数整数没有连续可导的概念。我见过有人用torch.tensor([1, 2, 3], requires_gradTrue)然后困惑为什么报错其实就是类型问题加上dtypetorch.float32就好了。1.2 计算图是动态搭出来的不是提前定义好的和某些静态图框架不同PyTorch 的计算图是在前向计算的过程中一边算一边搭的。你每执行一行涉及需要梯度的张量的运算图就长出一个节点。这意味着两件事第一图的结构完全取决于你代码的实际执行路径if分支走哪边图就是哪样第二前向算完图就在那了反向传播就是沿着这张已经搭好的图往回走。a torch.tensor(1.0, requires_gradTrue) b a * 2 c b ** 2 # 此时图的结构: a - MulBackward - b - PowBackward - c c.backward() print(a.grad) # 8.0因为 dc/da 2 * (2a) 4a 4我特意把中间变量b写出来是想强调图是跟着变量走的。如果你写成c (a * 2) ** 2中间那个b就不存在了但图照样会记录乘法节点和幂运算节点只是你拿不到中间变量的引用了。这个区别在做梯度调试的时候很关键——想检查中间层梯度就得把中间结果赋给变量留住。1.3 叶子节点梯度最终落脚的地方计算图里的张量分两类叶子节点和非叶子节点。用户直接创建的、requires_gradTrue的张量就是叶子节点比如模型里的权重参数由运算产生的张量是非叶子节点比如中间激活值。默认情况下反向传播只会把梯度累加到叶子节点的.grad上非叶子节点的梯度算完就丢了。w torch.tensor([1.0, 2.0], requires_gradTrue) # 叶子 h w * 3 # 非叶子 loss h.sum() loss.backward() print(w.grad) # tensor([3., 3.])叶子有梯度 print(h.grad) # None非叶子默认不保留这个设计不是偷懒而是出于内存考虑。一个深层网络里中间激活值成千上万如果每个都保留梯度显存瞬间就爆了。真要看非叶子节点的梯度得手动调用h.retain_grad()这个后面会细说。理解“梯度只落在叶子节点”这一条能解释掉一大半“为什么我的.grad是 None”的困惑。2. backward 到底做了什么梯度又是怎么累加的2.1 一次 backward 的完整链路调用loss.backward()时PyTorch 做的事情可以拆成几步从loss这个标量出发沿着grad_fn链反向遍历计算图每到一个节点就调用该节点对应的反向函数用链式法则把上游传来的梯度乘以本地的导数得到传给下游的梯度一直传到叶子节点把结果累加到它们的.grad属性上。这里有个硬性约束backward()默认只能对标量调用。如果你的 loss 是个向量直接 backward 会报 “grad can be implicitly created only for scalar outputs”。解决办法有两个要么先loss.sum()或loss.mean()变成标量要么给backward()传一个和输出同形状的gradient参数相当于指定每个输出分量的权重。v torch.tensor([1.0, 2.0, 3.0], requires_gradTrue) out v * 2 # out.backward() # 报错 out.backward(torch.tensor([1.0, 0.0, 0.0])) # 只对第一个分量求导 print(v.grad) # tensor([2., 0., 0.])传gradient参数这个用法在写自定义损失或者多任务学习时很有用它等价于给输出乘上一个权重向量再求和。理解这一点你就明白为什么标量能直接 backward——标量相当于天然带了一个权重 1。2.2 梯度是累加的不是覆盖的这是新手最容易栽的坑没有之一。PyTorch 的.grad属性是累加语义每次 backward 都会把新算出来的梯度加到已有的值上而不是替换掉。x torch.tensor(1.0, requires_gradTrue) y x ** 2 y.backward() print(x.grad) # 2.0 y x ** 2 y.backward() print(x.grad) # 4.0不是 2.0累加了为什么会这样设计因为在某些场景下累加是有意义的比如一个参数在多个地方被用到参数共享一次 backward 里它的梯度本来就该是各路径梯度之和。但放到常规的训练循环里如果你不在每轮迭代开始时清零梯度上一轮的梯度就会污染这一轮模型直接训飞。所以标准训练循环里一定有这一行optimizer.zero_grad()它的作用就是把优化器管理的所有参数的.grad置零或者置为 None取决于set_to_none参数。我个人的习惯是把它放在loss.backward()之前、前向计算之后逻辑上更顺先清账再算新账。放的位置其实不影响结果只要在 backward 之前就行但保持固定位置能避免自己看花眼。2.3 第二次 backward 报错的真正原因跑过这段代码的人应该都见过这个报错RuntimeError: Trying to backward through the graph a second time...原因在于反向传播走完一遍之后为了省内存PyTorch 会把计算图里保存的中间结果释放掉。你第二次对同一个 loss 调 backward图已经残缺了自然走不通。x torch.tensor(2.0, requires_gradTrue) y x ** 3 y.backward() print(x.grad) # 12.0 # y.backward() # 报错图已被释放要重复利用同一张图得在第一次 backward 时加retain_graphTruey.backward(retain_graphTrue) y.backward() print(x.grad) # 24.0两次累加但我要提醒一句retain_graphTrue不是随便加的。它会让中间结果不被释放显存占用上升。真正需要它的场景其实不多主要是同一张图要算多次梯度比如某些 GAN 的训练技巧、或者对同一 loss 求高阶导。如果你只是想在训练循环里反复 backward那正确做法是每轮重新做前向计算而不是保留旧图。3. detach、no_grad 和 inference_mode三个容易混的家伙3.1 detach 是“剪断”计算图detach()返回一个和原张量共享数据、但脱离计算图的新张量。它不再有grad_fnrequires_grad也变成 False。用它参与后续运算不会在图上留下任何痕迹。a torch.tensor([1.0, 2.0], requires_gradTrue) b a * 2 c b.detach() * 3 print(c.requires_grad) # False print(c.grad_fn) # None这个操作在几个场景下是刚需。一是你想拿某个中间结果做记录或打印不希望它牵扯进梯度计算二是实现某些自定义逻辑比如目标网络target network的更新需要把参数值拷过来但不建立梯度关系三是做梯度截断把某条路径的梯度人为切断。有个细节值得说detach()出来的张量和原张量共享底层存储。也就是说如果你原地修改了 detach 后的张量原张量的数据也会变。这个特性有时候会被利用来做一些原地操作但也容易埋雷改之前想清楚。3.2 no_grad 是“整段关灯”torch.no_grad()是一个上下文管理器它管辖范围内的所有运算都不记录梯度不管张量的requires_grad是什么。with torch.no_grad(): y a * 2 print(y.requires_grad) # False它和detach()的区别在于作用范围detach()作用于单个张量no_grad()作用于一段代码。推理阶段、评估阶段、参数手动更新都该包在no_grad()里。原因很实在——不记录梯度能省下大量显存和计算推理速度也会快一些。我见过有人在评估循环里忘了加no_grad()结果显存一路涨跑到一半 OOM。排查半天以为是模型太大其实是评估时还在默默搭图。这种问题加一行上下文就解决了。3.3 inference_mode 比 no_grad 更彻底较新版本的 PyTorch 提供了torch.inference_mode()它比no_grad()更激进不仅不记录梯度连版本计数等推理用不上的元信息都不维护因此开销更低。with torch.inference_mode(): y a * 2代价是它产生的张量不能再参与需要梯度的运算也不能做某些原地操作。纯推理场景下优先用它如果代码里还有需要梯度的逻辑混着那就退回no_grad()。我一般的判断标准很简单这段代码只做前向、结果只用来出预测就用inference_mode如果拿不准用no_grad更保险。下面这张表把三者的差异摆在一起方便对照特性detach()no_grad()inference_mode()作用对象单个张量代码块代码块是否共享存储是不涉及不涉及开销低中最低产生张量能否再求导否否否典型场景切断单条路径评估、手动更新参数纯推理部署4. 非叶子节点的梯度以及 retain_grad 的正确用法4.1 为什么默认不保留中间梯度前面提过非叶子节点的.grad默认是 None。这个设计的核心动机是内存。设想一个 50 层的网络每层激活值都是几 MB 的张量如果每个都保留梯度显存需求会翻好几倍。而训练时我们真正需要的只是参数叶子节点的梯度中间激活的梯度算完即用、用完即弃是最经济的做法。但调试的时候我们恰恰想看中间层的梯度是否正常——梯度消失、梯度爆炸往往就发生在中间某几层。这时候retain_grad()就派上用场了。4.2 retain_grad 的实操与代价w torch.tensor([1.0, 2.0], requires_gradTrue) h w * 3 h.retain_grad() # 关键一步必须在 backward 之前调用 loss h.sum() loss.backward() print(h.grad) # tensor([1., 1.])调用顺序很重要retain_grad()必须在反向传播之前执行因为它是给这个张量打标记告诉引擎“算到我的时候把梯度留下来”。backward 之后再调就没意义了。代价是显存。每保留一个中间张量的梯度就多占一份和它同形状的存储。所以我的建议是调试阶段针对性地对少数几个关心的层调retain_grad()定位完问题就删掉别留在正式训练代码里。曾经有人图省事给所有中间变量都加了retain_grad()结果显存直接翻倍训练 batch size 被迫砍半得不偿失。4.3 用 hook 做更灵活的梯度观测如果只是想观测梯度、不想改张量的保留行为注册 hook 是更优雅的方式。register_hook可以在某个张量的梯度算出来时插入一个回调拿到梯度值做记录或修改。grads {} def save_grad(name): def hook(grad): grads[name] grad return hook h w * 3 h.register_hook(save_grad(h)) loss h.sum() loss.backward() print(grads[h]) # tensor([1., 1.])hook 的好处是不改变计算图本身的行为观测完自动失效如果不手动移除的话会一直挂着这点要注意。做梯度监控、画梯度分布图的时候这套机制比retain_grad更干净。不过 hook 里别做太重的操作它是在反向传播过程中同步执行的写复杂逻辑会拖慢训练。5. 梯度检查与常见异常排查5.1 用 gradcheck 验证自定义函数的梯度如果你自己实现了某个运算的反向传播通过继承torch.autograd.Function那必须验证梯度算得对不对。PyTorch 提供了torch.autograd.gradcheck它用数值微分有限差分来对比你解析计算的梯度。from torch.autograd import gradcheck class MyFunc(torch.autograd.Function): staticmethod def forward(ctx, x): return x ** 2 staticmethod def backward(ctx, grad_out): x, ctx.saved_tensors return grad_out * 2 * x f MyFunc.apply x torch.randn(3, dtypetorch.double, requires_gradTrue) print(gradcheck(f, (x,))) # True 表示梯度正确注意这里必须用double类型因为数值微分对精度敏感float32 的误差容易导致误判。gradcheck 跑起来比较慢只在开发自定义算子时用别塞进训练循环。5.2 梯度为 None 的几种典型情况排查梯度问题时.grad是 None 是最常见的现象。我整理了几种高频原因按出现频率排序现象可能原因排查方法参数 .grad 为 None参数没设 requires_grad检查p.requires_grad参数 .grad 为 None参数没参与前向计算打印计算图或用 hook 确认参数 .grad 为 None被 detach 或包在 no_grad 里检查上下文和 detach 调用中间张量 .grad 为 None非叶子节点默认不保留调retain_grad()梯度全为 0激活函数饱和或路径被切断检查激活值分布其中“参数没参与前向计算”这条最隐蔽。比如你定义了一个分支网络某个 batch 里这个分支没被走到那它的参数这一轮就没有梯度.grad保持 None 或旧值。这种情况在条件计算、MoE 结构里很常见排查时得结合前向逻辑一起看。5.3 梯度爆炸与消失的快速定位梯度爆炸表现为 loss 突然变成 NaN 或者参数值飞掉梯度消失表现为深层参数几乎不更新。定位手段是打印各层梯度的范数total_norm 0 for p in model.parameters(): if p.grad is not None: param_norm p.grad.data.norm(2) total_norm param_norm.item() ** 2 total_norm total_norm ** 0.5 print(fgrad norm: {total_norm})如果这个范数在训练中持续增大到几百上千基本就是爆炸了可以考虑梯度裁剪torch.nn.utils.clip_grad_norm_。如果它一直很小甚至趋近于零那要检查是不是网络太深、激活函数选得不对或者初始化有问题。我习惯在训练脚本里每隔若干步打印一次这个范数成本很低但出问题时能第一时间发现苗头。6. 几个实战中反复踩到的坑6.1 在 loss 上做 in-place 操作对需要梯度的张量做原地操作比如x 1、x.relu_()很容易触发 “a leaf Variable that requires grad is being used in an in-place operation” 或者版本计数相关的报错。原因是原地修改会破坏反向传播所需的前向值。解决办法是改用非原地版本x x 1、x x.relu()。这个坑在写自定义损失时特别容易踩因为很多人习惯用累加。6.2 优化器更新参数时忘了 no_grad手动更新参数不通过优化器时如果直接p - lr * p.grad会报错因为这行运算本身会被记录进计算图。正确写法是包在no_grad()里with torch.no_grad(): for p in model.parameters(): p - lr * p.grad用优化器的话它内部已经处理好了不用操心。但自己写更新逻辑时这个上下文不能漏。6.3 混合精度下的梯度缩放用混合精度训练时梯度可能因为 float16 表示范围小而下溢成 0。标准做法是配一个 GradScaler 做梯度缩放backward 时用scaler.scale(loss).backward()更新前scaler.unscale_(optimizer)再裁剪最后scaler.step(optimizer)和scaler.update()。这套流程顺序不能乱乱了梯度要么没缩放要么没还原训练效果直接崩。我见过有人把scaler.step和optimizer.step混着调结果参数更新了两次loss 曲线诡异得很。6.4 多卡训练下的梯度同步数据并行训练时各卡各自算梯度然后做 all-reduce 求平均。如果你在单卡上调试好的梯度裁剪逻辑直接搬到多卡要注意裁剪应该发生在梯度同步之后否则每张卡按自己的局部梯度裁剪同步后的整体梯度范数就不受控了。这个细节在分布式训练里很关键但单卡调试时完全暴露不出来。7. 把梯度机制用进日常调试7.1 一个可复用的梯度健康检查函数我把前面零散的手段整合成一个函数训练时定期调用能覆盖大部分梯度异常def check_gradients(model, step): report {} for name, p in model.named_parameters(): if p.grad is None: report[name] None else: report[name] round(p.grad.norm(2).item(), 6) print(f[step {step}] {report})输出里如果某个参数长期是 None说明它没被训练到如果某个范数异常大就是爆炸信号。这个函数本身开销不大但信息量足够定位问题。我一般在前几百步每 50 步调一次稳定后拉长间隔。7.2 理解梯度流比记住 API 更重要写到这里我想强调一个观点PyTorch 的梯度 API 就那么几个backward、zero_grad、detach、no_grad、retain_grad背下来不难。真正拉开差距的是你能不能在心里画出梯度流——给定一段代码说出每个张量的梯度从哪来、到哪去、在哪被截断、在哪被累加。这个能力不是靠记 API 得来的是靠反复调试、反复看.grad和grad_fn练出来的。我个人的习惯是遇到任何梯度相关的疑惑第一反应是打印grad_fn和requires_grad把计算图在脑子里重建一遍。大部分“莫名其妙”的报错打印两行就能定位。比如那个经典的“backward second time”报错只要看一眼 loss 的grad_fn还在不在就知道图是不是被释放了。7.3 关于性能的一点经验最后分享一个容易被忽视的点梯度计算本身是有成本的。前向时保存中间结果、反向时逐节点求导这些都要时间和显存。所以推理、评估、特征提取这些不需要梯度的场景务必用no_grad或inference_mode包起来。我实测过一个中等规模的模型评估阶段加上no_grad后显存占用降了将近四成吞吐也提升了一截。这个优化几乎零成本但很多人写评估代码时就是会忘。另外zero_grad(set_to_noneTrue)比默认的置零方式略快因为它省去了写零的操作直接把.grad设成 None下次 backward 时再分配。较新版本的 PyTorch 默认就是set_to_noneTrue如果你用的是老版本可以手动打开这个选项积少成多也是收益。梯度计算这套机制初看是一堆 API用熟了会发现它其实是一套很自洽的设计用计算图记录运算、用叶子节点收拢梯度、用累加语义支持参数共享、用释放机制控制内存。把这几个核心概念串起来剩下的都是细节。真正吃透之后你写训练代码会从“照着模板填”变成“知道每一步为什么这么写”遇到问题也能自己顺着梯度流排查而不是到处搜报错信息。