几个时期后的 tensorflow-GPU OOM 问题

Question

我使用 tensorflow 通过 Nvidia Geforce 1060（6G 内存）训练 CNN，但遇到了 OOM 异常。

前两个 epoch 的训练过程很好，但在第三个 epoch 出现 OOM 异常。

============================= 2017-10-27 11:47:30.219130: W tensorflow/core/common_runtime/bfc_allocator.cc:277] ************************** ****************************************************** ******************xxxxxx 2017-10-27 11:47:30.265389：W tensorflow/core/framework/op_kernel.cc:1192] 资源耗尽：分配具有形状的张量时出现 OOM [10,10,48,48,48] 回溯（最近一次通话最后）： _do_call 中的文件“/anaconda3/lib/python3.6/sitepackages/tensorflow/python/client/session.py”，第 1327 行 返回 fn(*args) _run_fn 中的文件“/anaconda3/lib/python3.6/site-packages/tensorflow/python/client/session.py”，第 1306 行 状态，运行元数据） exit 中的文件“/anaconda3/lib/python3.6/contextlib.py”，第 88 行 下一个（self.gen） 文件“/anaconda3/lib/python3.6/site-packages/tensorflow/python/framework/errors_impl.py”，第 466 行，在 raise_exception_on_not_ok_status pywrap_tensorflow.TF_GetCode（状态）） tensorflow.python.framework.errors_impl.ResourceExhaustedError：OOM 分配具有形状[10,10,48,48,48] 的张量时 [[节点：gradients_4/global/detector_scope/maxpool_conv3d_2/MaxPool3D_grad/MaxPool3DGrad = MaxPool3DGrad[T=DT_FLOAT, TInput=DT_FLOAT, data_format="NDHWC", ksize=[1, 2, 2, 2, 1], padding="VALID ", strides=[1, 2, 2, 2, 1], _device="/job:localhost/replica:0/task:0/gpu:0"](global/detector_scope/maxpool_conv3d_2/transpose, global/detector_scope/ maxpool_conv3d_2/MaxPool3D, gradients_4/global/detector_scope/maxpool_conv3d_2/transpose_1_grad/transpose)]] [[节点：Momentum_4/update/_540 = _Recvclient_terminated=false, recv_device="/job:localhost/replica:0/task:0/cpu:0", send_device="/job:localhost/replica:0/task:0 /gpu:0", send_device_incarnation=1, tensor_name="edge_1540_Momentum_4/update", tensor_type=DT_FLOAT, _device="/job:localhost/replica:0/task:0/cpu:0"]]

==============================

所以，我很困惑为什么在处理完前两个 epoch 后在第三个 epoch 得到这个 OOM 异常。

鉴于每个时期的数据集都是相同的，如果我用完了 GPU 内存，我应该在第一个时期得到异常。但我确实成功地完成了两个时代。那么，为什么后来会发生这种情况？

有什么建议吗？

Answer 1

在您第一次开始训练和至少一个 epoch 完成后，您可能会看到两次 OOM 错误。

第一种情况仅仅是由于模型的内存大小。为此，最简单的方法是减少批量大小。如果你的模型真的很大并且你的批量现在减少到一个，你仍然有几个选择：减少隐藏层的大小或移动到具有足够 GPU 甚至 CPU 执行的云实例，以便内存的静态分配起作用.

对于第二种情况，您可能会遇到某种内存泄漏。许多训练实现在保留数据集上使用回调来获得验证分数。这个执行，比如说如果被 Keras 调用，可能会保留 GPU 会话资源。如果未发布，这些会累积起来，并可能导致 GPU 实例在几个 epoch 后报告 OOM。其他人建议使用第二个 GPU 实例进行验证会话，但我认为更好的方法是使用更智能的验证回调会话处理（特别是在每个验证回调完成时释放 GPU 会话资源。）

这是说明回调问题的伪代码。这个回调导致OOM：

my_models_validation_score = tf.get_some_v_score

这个回调不会导致OOM：

with tf.Session() as sess: 
    sess.run(get_some_v_score)

我邀请其他人帮助添加此回复...