PyTorch冻结层，设置requires_grad为False方法

本文深入解析了PyTorch中冻结网络层的核心机制与实战要点：关键在于精准将目标参数的`requires_grad`设为`False`，而非简单操作模块本身，并强调必须遍历`parameters()`逐个设置；同时警示常见陷阱——如忽略BN层的`track_running_stats`控制、未在构建优化器前筛选可训练参数导致严重性能损耗，以及字符串匹配层名时的重名风险；通过清晰示例（如只训练`fc`和`layer4`）、可验证的调试方法（检查梯度存在性、统计`param_groups`长度）和编译/分布式训练的前置要求，帮助开发者高效、稳定地实现分层训练，避免隐性bug和训练效率断崖式下降。

冻结PyTorch模型某几层：直接操作 requires_grad

冻结层的本质就是让对应参数的 requires_grad 为 False，这样反向传播时自动跳过这些参数，不更新也不占用梯度内存。关键不是“禁用层”，而是“禁用该层中所有 Parameter 的梯度”。

常见错误是只改了某一层的 .requires_grad = False，但忘了它内部可能有多个参数（比如 weight 和 bias），或者误以为设置模块本身属性就足够——其实必须遍历其 parameters()。

• 对单个层（如 model.layer2）：用 for param in model.layer2.parameters(): param.requires_grad = False
• 对模块内所有子模块递归冻结：用 model.layer2.apply(lambda m: setattr(m, 'requires_grad', False)) 不可靠，因为 apply 作用在模块上，不是参数上；正确写法是 for param in model.layer2.parameters(): param.requires_grad = False
• 冻结后记得调用 model.eval() 吗？不需要——eval() 只影响 Dropout、BatchNorm 等行为，和梯度无关；但如果你冻结了 BatchNorm 层又想保持其统计量不变，就得额外设 model.layer.bn.running_mean.requires_grad = False（默认已是 False），一般不用动

只训练最后两层：用 named_parameters() 精确控制

想放开最后几层、冻结前面大部分，靠硬编码层名容易出错（比如 ResNet 的 layer4 后还有 fc）。更稳的方式是按参数名或顺序筛选。

例如在 ResNet 中只训练 fc 和 layer4：

for name, param in model.named_parameters():
    if "layer4" not in name and "fc" not in name:
        param.requires_grad = False

注意：这种字符串匹配要小心重名（比如 layer4_1 也会被匹配），更健壮的做法是先打印 list(model.named_parameters())[:5] 看清结构。

• 冻结后务必检查：运行一次 loss.backward() 后，用 [p.grad is not None for p in model.parameters() if p.requires_grad] 确认只有目标层有梯度
• 如果用了 torch.compile() 或 DDP，冻结逻辑必须在模型包装前完成，否则编译器可能把已冻结参数仍纳入图中

冻结后 optimizer 里还包含这些参数？会报错或浪费内存

即使参数 requires_grad = False，只要它还在 optimizer.param_groups 里，optimizer.step() 就会尝试更新——虽然更新值不变（因为梯度为 None），但会触发冗余计算和 CUDA 同步，严重拖慢训练速度，甚至在 AMP 下引发 NaN。

正确做法是构造 optimizer 时只传入需要更新的参数：

params_to_update = [p for p in model.parameters() if p.requires_grad]
optimizer = torch.optim.Adam(params_to_update, lr=1e-4)

• 不要在冻结后用 optimizer.add_param_group() 动态加参数——这会让 optimizer 内部状态混乱
• 如果用了学习率分组（比如 backbone lr 小、head lr 大），记得冻结后重新组织 param_groups，否则未冻结层可能被错误地分配到高 lr 组
• 验证方式：打印 len(optimizer.param_groups[0]["params"])，应等于你手动统计的 requires_grad=True 参数数量

BatchNorm 层冻结的特殊处理：track_running_stats 和 eval()

冻结 BN 层时，光设 requires_grad=False 不够。BN 有两个关键行为：参数更新（weight/bias）和统计量更新（running_mean/running_var）。前者由 requires_grad 控制，后者由 track_running_stats 控制。

如果你冻结了 BN 层但没关统计更新，训练时它的 running_mean 还在变，会导致特征分布漂移，效果不稳定。

• 彻底冻结 BN：除设 param.requires_grad = False 外，还要 bn_layer.track_running_stats = False，并确保推理时用的是预计算好的统计量
• 更常用做法：保持 track_running_stats=True（即继续累积统计量），但把 BN 切到 eval() 模式——这样训练时仍更新统计量，但不使用 batch 统计做归一化（而是用 running 统计量），相当于“冻结归一化行为”
• 注意：model.eval() 会影响整个模型，如果只想冻结部分 BN，得单独调用 bn_layer.eval()

实际中最容易漏掉的是 optimizer 初始化那一步——参数冻结了，但 optimizer 还抱着全部参数不放。一旦模型变大，这个疏忽会让训练慢 20% 以上，且难以定位。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。