PyTorch 0.4（Python2.7）应用修复后仍报FileNotFoundError求助

我来帮你梳理下这个棘手的问题——你在PyTorch 0.4+Python2.7环境中调用binary_cross_entropy时，触发了RuntimeError: cudaEventSynchronize in future::wait: device-side assert triggered错误，而且尝试过相关问题的修复方案后依然无解，咱们从设备端断言错误的核心原因入手，一步步排查：

先明确核心：设备端断言错误的本质 #

这类错误几乎都和输入数据的合法性直接相关，而非函数调用语法问题，哪怕你的代码看起来逻辑通顺，数据层面的隐形问题也会触发GPU端的断言检查。

具体排查步骤 #

• 检查输入张量的shape完全匹配
  binary_cross_entropy要求输入（sigmoid输出）和目标张量的shape必须完全一致，包括batch维度、特征维度。比如如果out0是(batch_size, 10)，那all0也必须是同样的shape，不能有维度缺失或错位。
  建议在计算损失前添加打印验证：

  sigmoid_out = F.sigmoid(out0)
  print("Sigmoid输出shape:", sigmoid_out.shape)
  print("目标张量shape:", all0.shape)
  

  确保两者的每个维度数值都完全相同。

• 验证目标值all0的取值范围
  二分类交叉熵要求目标值必须落在[0, 1]区间内（和sigmoid的输出范围对应），如果all0里存在小于0或大于1的数值，GPU端会直接触发断言。
  可以打印目标值的极值快速验证：

  print("目标张量最小值:", all0.min().item())
  print("目标张量最大值:", all0.max().item())
  

  若超出范围，需要先通过torch.clamp(all0, 0, 1)修正，或者回溯标签生成逻辑找出问题。

• 确认输入和目标的设备一致性
  PyTorch 0.4的设备管理逻辑还比较基础，如果out0在GPU上，而all0在CPU上（反之亦然），会触发隐性的设备不兼容问题，最终表现为断言错误。
  打印设备信息确认：

  print("输出张量设备:", out0.device)
  print("目标张量设备:", all0.device)
  

  若不一致，用.cuda()或.cpu()将两者统一到同一设备。

• 排查张量中是否存在NaN/Inf值
  如果网络前向传播中出现梯度爆炸、数值溢出，会导致out0出现NaN或Inf，经过sigmoid后依然会保留这些异常值，进而触发损失计算的断言错误。
  添加检查代码：

  print("输出张量是否含NaN:", torch.isnan(out0).any().item())
  print("输出张量是否含Inf:", torch.isinf(out0).any().item())
  print("Sigmoid输出是否含NaN:", torch.isnan(F.sigmoid(out0)).any().item())
  

  若存在异常值，需要调整学习率、检查网络层初始化，或者添加梯度裁剪（torch.nn.utils.clip_grad_norm_）来稳定训练。

• 针对PyTorch 0.4+Python2.7的特殊适配
  这个版本组合存在一些兼容性细节，试试调整损失计算的写法：

  • 避免连续嵌套计算，拆分步骤：

    loss0 = F.binary_cross_entropy(F.sigmoid(out0), all0)
    loss += loss0
    

    连续运算可能导致张量的设备或shape发生隐性变化。
  • 手动控制size_average和reduce参数：PyTorch 0.4还未使用reduction参数，如果你的batch大小不固定（比如最后一个batch样本数不足），size_average=True可能引发问题，可以尝试设置reduce=False后手动计算均值：

    loss0 = F.binary_cross_entropy(F.sigmoid(out0), all0, reduce=False)
    loss += loss0.mean()
    

另外，你提到已经尝试过类似问题的修复方案，能不能补充下具体做了哪些修改？比如是否已经检查过shape或取值范围？这会帮助进一步缩小问题范围。

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