常见问题解答¶

我的模型报告“cuda runtime error(2): out of memory”¶

如错误消息所示，您的 GPU 内存已不足。由于我们在 PyTorch 中经常处理大量数据，微小的错误可能迅速导致程序耗尽 GPU 所有内存；幸运的是，这些情况下的修复方法通常很简单。这里有一些常见的检查项：

不要在训练循环中累积历史。默认情况下，涉及需要梯度的变量的计算会保留历史。这意味着您应避免在超出训练循环范围的计算中使用此类变量，例如，在跟踪统计信息时。相反，您应该分离变量或访问其底层数据。

有时，可微分变量何时出现可能不那么明显。考虑以下训练循环（摘自 source）

total_loss = 0
for i in range(10000):
    optimizer.zero_grad()
    output = model(input)
    loss = criterion(output)
    loss.backward()
    optimizer.step()
    total_loss += loss

这里，total_loss 在整个训练循环中累积了历史，因为 loss 是一个带有 autograd 历史的可微分变量。您可以通过改写 total_loss += float(loss) 来解决此问题。

此问题的其他示例：1。

不要持有不需要的张量和变量。如果您将 Tensor 或 Variable 赋值给局部变量，Python 在局部变量超出作用域之前不会释放内存。您可以使用 del x 释放此引用。类似地，如果您将 Tensor 或 Variable 赋值给对象的成员变量，它在对象超出作用域之前不会释放内存。如果您不持有不需要的临时变量，将获得最佳内存使用效果。

局部变量的作用域可能比您预期的要大。例如

for i in range(5):
    intermediate = f(input[i])
    result += g(intermediate)
output = h(result)
return output

这里，intermediate 仍然存活，即使在 h 执行期间，因为其作用域超出了循环的末尾。要提前释放它，您应该在使用完后 del intermediate。

避免在过长的序列上运行 RNN。通过 RNN 进行反向传播所需的内存量与 RNN 输入长度线性相关；因此，如果您尝试向 RNN 输入过长的序列，将导致内存不足。

这种现象的技术术语是 backpropagation through time（随时间反向传播），关于如何实现截断的 BPTT 有很多参考资料，包括在 word language model 示例中；截断由 repackage 函数处理，如 this forum post 中所述。

不要使用过大的线性层。一个线性层 nn.Linear(m, n) 使用 $O(nm)$ 内存：也就是说，权重的内存需求与特征数量呈平方关系。通过这种方式很容易耗尽内存（请记住，您至少需要权重的两倍大小，因为您还需要存储梯度）。

考虑检查点。您可以通过使用 checkpoint 来权衡内存和计算资源。

我的 GPU 内存没有正确释放¶

PyTorch 使用缓存内存分配器来加速内存分配。因此，nvidia-smi 中显示的值通常不能反映真实的内存使用情况。有关 GPU 内存管理的更多详细信息，请参阅内存管理。

如果您的 GPU 内存即使在 Python 退出后也没有释放，很可能是因为某些 Python 子进程仍然存活。您可以使用 ps -elf | grep python 找到它们，并使用 kill -9 [pid] 手动终止它们。

我的内存不足异常处理程序无法分配内存¶

您可能有一些尝试从内存不足错误中恢复的代码。

try:
    run_model(batch_size)
except RuntimeError: # Out of memory
    for _ in range(batch_size):
        run_model(1)

但发现当您确实遇到内存不足时，您的恢复代码也无法分配内存。这是因为 Python 异常对象持有引发错误的堆栈帧的引用。这会阻止原始张量对象被释放。解决方案是将您的 OOM 恢复代码移到 except 子句之外。

oom = False
try:
    run_model(batch_size)
except RuntimeError: # Out of memory
    oom = True

if oom:
    for _ in range(batch_size):
        run_model(1)

我的数据加载器工作进程返回相同的随机数¶

您可能正在使用其他库在数据集中生成随机数，并且工作子进程是通过 fork 启动的。有关如何使用 worker_init_fn 选项在工作进程中正确设置随机种子的信息，请参阅 torch.utils.data.DataLoader 的文档。

我的循环网络不适用于数据并行¶

在使用带有 Module 的 pack sequence -> recurrent network -> unpack sequence 模式时，存在一个微妙之处。每个设备上的 forward() 输入将仅是整个输入的一部分。由于解包操作 torch.nn.utils.rnn.pad_packed_sequence() 默认仅填充到它所看到的最长输入（即该特定设备上的最长输入），因此在收集结果时会发生大小不匹配。因此，您可以使用 pad_packed_sequence() 的 total_length 参数来确保 forward() 调用返回相同长度的序列。例如，您可以编写

from torch.nn.utils.rnn import pack_padded_sequence, pad_packed_sequence

class MyModule(nn.Module):
    # ... __init__, other methods, etc.

    # padded_input is of shape [B x T x *] (batch_first mode) and contains
    # the sequences sorted by lengths
    #   B is the batch size
    #   T is max sequence length
    def forward(self, padded_input, input_lengths):
        total_length = padded_input.size(1)  # get the max sequence length
        packed_input = pack_padded_sequence(padded_input, input_lengths,
                                            batch_first=True)
        packed_output, _ = self.my_lstm(packed_input)
        output, _ = pad_packed_sequence(packed_output, batch_first=True,
                                        total_length=total_length)
        return output


m = MyModule().cuda()
dp_m = nn.DataParallel(m)

此外，当批次维度是 dim 1（即 batch_first=False）并使用数据并行时，需要特别注意。在这种情况下，pack_padded_sequence 的第一个参数 padding_input 的形状将是 [T x B x *]，并且应该沿 dim 1 分散，但第二个参数 input_lengths 的形状将是 [B]，并且应该沿 dim 0 分散。这将需要额外的代码来操作张量形状。