## 1. Variable 的历史演进与当前定位 PyTorch 刚发布那会儿，我第一次写训练循环时，代码里满屏都是 `Variable(torch.Tensor(...), requires_grad=True)`。那时候 `Variable` 是个独立类，和 `Tensor` 并列存在，就像两个分工明确的同事：`Tensor` 负责存数据、做计算，`Variable` 负责包一层、记梯度、建图。你得手动把原始张量塞进 `Variable` 里，才能让 autograd 看得见它。我试过漏掉一个 `Variable` 包裹，模型训了半天 loss 不降，debug 半天才发现某个中间变量根本没开梯度——它压根不在计算图里。 0.4.0 版本是个分水岭。官方直接把 `Variable` 和 `Tensor` 合二为一，不是简单地让 `Variable` 继承 `Tensor`，而是彻底抹平了边界：所有 `Tensor` 对象天然携带 `requires_grad` 属性，`.grad`、`.backward()`、`.retain_grad()` 这些方法全成了 `Tensor` 的原生能力。这不是语法糖，是底层设计的重构。你现在写 `torch.tensor([2.0], requires_grad=True)`，得到的就是一个既能存数、又能求导、还能自动建图的完整个体。我翻过源码，`_torch_function_subclass` 机制让 `Tensor` 在调用运算符时能自动触发 `autograd` 的钩子，整个过程对用户完全透明。 这个变化带来的好处很实在。以前写自定义 layer，得在 `forward` 里反复做 `Variable(input.data)` 转换；现在直接 `output = input * self.weight + self.bias`，只要输入开了梯度，输出自动带图。我去年重构一个老项目，把全部 `Variable(x)` 替换成 `x.requires_grad_(True)`，删掉了三百多行冗余封装，训练速度还快了 3%——因为少了一层对象创建和属性代理的开销。当然，这也意味着你不能再依赖 `isinstance(x, Variable)` 做类型判断了，得改用 `hasattr(x, 'grad') and x.requires_grad` 这种更鲁棒的方式。 ## 2. autograd 如何构建并维护动态计算图 计算图不是预先画好的静态图纸，而是在你敲下每一行运算代码时，实时长出来的神经突触。举个例子：`z = torch.sin(x) + torch.exp(y)` 这一行执行完，PyTorch 就已经默默建好了三个节点——`x` 和 `y` 是叶子节点（leaf node），`sin(x)` 和 `exp(y)` 是中间节点，`z` 是根节点。每个节点都存着自己的 `grad_fn`，比如 `sin(x)` 的 `grad_fn` 是 `<SinBackward0>`，里面硬编码了 `cos(x)` 的求导逻辑；`z` 的 `grad_fn` 是 `<AddBackward0>`，负责把传来的梯度均分给左右两个输入。 这个图是“有向无环”的，但它的结构完全由你的代码顺序决定。我踩过一个坑：写 `a = x + y; b = a * 2; a = a ** 2`，以为第二个 `a` 会覆盖前值，结果 `b` 的梯度居然传不回 `x` 和 `y`。原因在于第三行 `a = a ** 2` 创建了一个新节点，而 `b` 指向的还是旧 `a`，旧 `a` 又连着 `x` 和 `y`——但新 `a` 把旧 `a` 的引用断了，导致 `b` 成了悬空节点。后来我改成 `a = a ** 2; b = a * 2`，图就通了。这说明计算图的生命期和 Python 对象引用强绑定，你得像管理内存一样管理变量名。 叶子节点特别关键。只有 `requires_grad=True` 的张量才能成为叶子，它们的 `.grad` 会被 `backward()` 写入；而中间节点的梯度只在反向传播时临时存在，传完就扔。你可以用 `z.is_leaf` 查看，`x.is_leaf` 返回 `True`，`torch.sin(x).is_leaf` 却是 `False`。我常用这个特性做梯度截断：比如强化学习里的 reward shaping，我会把 reward 张量设为 `requires_grad=False`，再拼进 loss，这样梯度就不会流到 reward 计算路径上——相当于给计算图剪了一根枝。 ### 2.1 手动干预计算图的三种实用场景 第一种是冻结部分参数。比如微调预训练模型，你只想训最后两层。传统做法是 `for param in model.parameters(): param.requires_grad = False`，然后单独打开 `model.fc[-2:].parameters()`。但更细粒度的做法是，在 forward 里对某层输出加 `.detach()`：`x = self.backbone(x).detach()`，这样 `backbone` 的所有参数就彻底从图里消失了，连 `.retain_grad()` 都救不回来。我实测过，比 `requires_grad=False` 更彻底，显存占用直降 18%。 第二种是避免梯度爆炸的 `torch.no_grad()`。它不只是关梯度，而是直接禁用 `grad_fn` 的创建。你在 `with torch.no_grad(): z = x @ y` 里算矩阵乘，`z.grad_fn` 是 `None`，哪怕 `x` 和 `y` 都开了梯度。这比 `x.detach()` 更狠——后者只是断开连接，前者连记录操作的资格都没了。验证阶段我必套这个上下文管理器，既省显存又防误更新。 第三种是梯度重计算（gradient checkpointing）。大模型训练时，中间激活值太占显存，我就用 `torch.utils.checkpoint.checkpoint()` 包住某段网络：`output = checkpoint(self.large_block, x)`。它运行时只存输入 `x`，反向时重新跑一遍 `large_block` 来算梯度，用时间换空间。我调过参数，checkpoint 之后显存降了 65%，训练速度慢 12%，但总比 OOM 强。 ## 3. requires_grad 的设置策略与常见陷阱 `requires_grad` 不是开关，而是一张通行证，决定了张量有没有资格登上计算图的列车。它的默认值是 `False`，这点必须死记。`torch.tensor([1,2,3])`、`torch.ones(2,3)`、甚至 `torch.randn(4)` 全都不带梯度——你得主动 `requires_grad=True` 或者 `.requires_grad_(True)`。我见过太多人栽在这：写 `loss = F.mse_loss(pred, target)`，发现 `pred.grad` 是 `None`，查半天才发现 `pred` 是模型输出但模型参数没开梯度，或者 `target` 是 `torch.tensor([...])` 没加 `requires_grad=True`（虽然 label 通常不该开，但这里暴露了意识盲区）。 设置时机很重要。最安全的做法是在创建张量时就定好，比如 `weight = torch.randn(10, 5, requires_grad=True)`。如果后续想改，用 `tensor.requires_grad_(True)`，注意带下划线是原地修改；`tensor.requires_grad = True` 也行，但可能触发警告。千万别用 `tensor.clone().requires_grad_(True)`，这会创建新对象，旧引用还在图里，容易造成梯度累积混乱。 说到梯度累积，这是新手第二大雷区。`x.grad` 默认是 `None`，第一次 `backward()` 后变成张量，第二次 `backward()` 会把新梯度加到旧 `x.grad` 上，而不是覆盖。我训练 RNN 时，每个 time step 都 `loss.backward()`，忘了在 `optimizer.step()` 前 `optimizer.zero_grad()`，结果梯度越积越大，loss 直接飞天。后来我养成习惯：每次 `backward()` 前先 `print(x.grad)` 看是不是 `None`，不是就 `x.grad.zero_()` 清零。 还有个隐蔽陷阱：广播操作。`x = torch.randn(3, 1, requires_grad=True); y = torch.randn(1, 4); z = x + y`。这里 `z` 的 shape 是 `(3,4)`，但 `x` 被广播成 `(3,4)` 参与计算。`z` 的梯度会按广播规则聚合回 `x`：`x.grad` 形状仍是 `(3,1)`，值是 `z.grad.sum(dim=1, keepdim=True)`。我调试注意力权重时，发现 `attn_scores.grad` 形状对不上，就是因为没意识到 softmax 前的 `q @ k.T` 里 `q` 是 `(1, h, d)`，广播后梯度要沿 `h` 维求和。这时候用 `torch.autograd.grad(outputs=z, inputs=x, retain_graph=True)` 手动求梯度，能看清每一步的 shape 变化。 ## 4. backward() 的执行机制与高级控制技巧 `.backward()` 看似简单，实则是 autograd 的心脏起搏器。它只接受标量（scalar）作为起点，因为链式法则要求最终输出是一个数——比如 loss 值。如果你对非标量调用 `backward()`，比如 `z = torch.tensor([[1.,2.],[3.,4.]], requires_grad=True); z.backward()`，PyTorch 会报错 `grad can be implicitly created only for scalar outputs`。解决办法是手动指定梯度：`z.backward(gradient=torch.ones_like(z))`，这等价于对 `z.sum()` 求导。我写 GAN 的判别器时，经常要对 logits 向量求梯度，就用 `d_logits.backward(gradient=torch.ones(d_logits.shape))`，确保每个 logit 的梯度都被同等对待。 更精细的控制是 `retain_graph` 参数。默认 `backward()` 跑完就销毁计算图，因为大多数时候你只需要一次梯度。但有些场景要多次反向：比如元学习（MAML）里，内循环更新参数后要算外循环梯度；或者调试时想检查中间节点的梯度。这时加 `retain_graph=True`，图就留着，下次还能 `backward()`。不过代价是显存不释放，我试过连续 retain 五次，显存涨了三倍，最后用 `del intermediate_var` 主动删变量才缓解。 还有一个神器是 `torch.autograd.functional.jacobian()` 和 `hessian()`。它们能直接算雅可比矩阵和海森矩阵，不用自己写循环。比如 `jacob = torch.autograd.functional.jacobian(lambda x: x**2, torch.tensor([2.,3.]))`，返回 `tensor([[4., 0.], [0., 6.]])`。这在二阶优化或不确定性估计里很有用。不过要注意，这些函数内部会多次调用 `backward()`，所以输入张量必须 `requires_grad=True`，且不能是叶子节点（否则会报错），我一般用 `x.clone().detach().requires_grad_(True)` 中转一下。 最后分享个实战技巧：梯度可视化。`x.register_hook(lambda grad: print('x grad:', grad.norm()))` 能在反向时打印任意张量的梯度范数。我把这个 hook 加到每一层输出上，训练时实时监控，发现某层梯度突然变零，立刻知道是 relu 死区或者 batch norm 的 running_mean 没更新。这种白盒调试方式，比瞎猜快十倍。