如何修复Python代码中PyTorch评估模式下Dropout层仍在运行的问题？

PyTorch评估模式下Dropout还在活跃，说明model.eval()没真正生效，或者后续又被某个train()覆盖了。核心得盯住model.training是不是False，再配合torch.no_grad()，最后逐层检查子模块的训练状态。

PyTorch评估模式下Dropout还在运行，说明模型根本没进eval()，或者你在推理时误用了训练时的模型实例。这事儿其实挺常见的，但排查起来有章可循。

确认模型是否真的调用了 eval()

最常见的坑是：只对模型某一层调了eval()，或者调完之后又意外触发了train()。Dropout起不起作用，全看self.training属性——它必须是False。

• 推理前确认执行了model.eval()，并且后面没有被model.train()覆盖掉。
• 验证状态：print(model.training) 应该输出False。如果是True，说明还在训练模式。
• 注意：eval()默认会递归设置所有子模块，除非你手动重写了eval()方法。

检查是否在 torch.no_grad() 外执行了前向传播

torch.no_grad()和model.eval()是两回事：前者禁用梯度计算，后者控制Dropout/BatchNorm的行为。如果漏了eval()，就算加了no_grad，Dropout依然会随机丢弃神经元。

• 正确姿势：model.eval() + with torch.no_grad():
• 错误写法：with torch.no_grad(): model(input) 但没提前调model.eval()
• 另外，DataLoader的shuffle=True之类的参数不会影响Dropout，但它容易让人产生错觉：“反正用了no_grad，够了”。

排查自定义模块或第三方封装中的隐式 train()

某些模型包装器——比如Hugging Face的Trainer、LightningModule的predict_step——可能在内部自动切换模式，也可能在predict前没显式切到eval。

• 如果你写了model = MyModel().cuda().eval()，然后把它传给了某个wrapper（比如torch.nn.DataParallel），得确认wrapper里还保持着training=False。
• 检查是否有子模块被单独设成了训练模式，比如model.encoder.train()——这会覆盖整体的eval()，导致encoder内的Dropout继续生效。
• 打印各子模块状态：for name, m in model.named_modules(): print(name, m.training)，重点盯着那些含Dropout的模块。

验证 Dropout 是否真被跳过：用固定输入+固定 seed 观察输出稳定性

Dropout在eval模式下应该完全静默——同样输入反复forward，输出必须一模一样。这是最直接的验证方法。

• 设置torch.manual_seed(42)和torch.backends.cudnn.deterministic = True
• 运行两次model(input)，对比输出张量是否torch.equal(out1, out2)
• 如果输出不一样，说明至少有一个Dropout层没进eval模式；这时候再逐层检查m.training
• 注意：BatchNorm在eval模式下也会冻结running stats，但它的行为变化不像Dropout那么明显，别拿它当判断依据。

最容易被忽略的是：模型对象被多次实例化，或者被wrapper重新包装，导致你以为自己调了eval()，实际作用在另一个对象上。建议在推理入口处加一行断言：assert not model.training, "Model is still in training mode"。