PyTorch中网络中间nn.Module调用detach后前序模块是否无法计算梯度？

你的判断是对的，只要detach操作是针对net B本身的参数、没有切断A-B-C之间的张量计算链路，就不会丢失net A的梯度信息。

detach的实际作用逻辑 #

detach本质是张量级别的操作：被detach的张量会和生成它的计算图断开连接，反向传播时梯度不会再往生成这个张量的上游节点传，但张量本身的数值不会变，也完全不影响它作为输入喂给后续模块做计算。

日常开发里说的“对net B做detach”，一般指两种操作，梯度表现完全不一样：

• 第一种是把net B内部的所有权重、偏置参数做detach（或者直接把参数的requires_grad设为False），也就是把B本身变成参数固定的常量模块，不参与后续的参数更新。
  这种情况下前向传播和没做detach时完全一致：X输入A得到A_out，A_out输入B得到B_out，B_out输入C算出最终损失。反向传梯度的时候，梯度从C往回走，能正常穿过B传到A的输出端，正常算出A所有参数的梯度——唯一的区别是梯度不会落到B的参数上，B不会被更新，完全符合你说的“B作为接在A后面的常量参与计算”的效果，A的梯度一点都不会丢。

  这也是迁移学习里最常见的操作：把预训练好的backbone冻住当固定特征提取器，训练下游的分类头，完全不会影响梯度传到backbone前面的可训练层（如果backbone全冻了也就不需要更新它的参数，但梯度通路本身是通的）。

• 第二种是把net B的输出张量做detach之后再喂给C，这时候detach断开的是B的输出和它上游所有节点（包括B自己、A）的计算图连接，反向传播时梯度走到B的输出位置就停了，既不会更新B的参数，也传不到A，这时候A确实收不到来自C的梯度。但这种操作本质是切断了B和C之间的梯度通路，不是“把B当成常量节点”，和你描述的detach效果不是一回事。

容易搞混的点 #

很多人会把「模块参数不更新」和「梯度不能穿过模块」搞混：
只要模块的输入输出之间的计算关系还保留在计算图里，哪怕模块的参数全冻住了，梯度照样能穿过这个模块传到更上游的可训练层；只有在模块的输入或者输出端对张量做detach，才会彻底堵死梯度穿过模块的路径。

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