Как убедиться, что этап обучения не столкнется с OOM?

Вопрос в заголовке завершен. «Как убедиться, что этап обучения не столкнется с OOM?»

Просто некоторые примечания, основанные на моем опыте, есть два случая OOM. Во-первых, память, необходимая для вашей модели и мини-пакета, больше, чем у вас есть. В таких случаях фаза обучения никогда не начнется. И решение исправить это — использовать меньшие размеры пакетов. Хотя было бы здорово, если бы я мог рассчитать максимальный размер партии, с которым мое оборудование может справиться для какой-то конкретной модели. Но даже если я не могу найти самый большой размер пакета с первой попытки, я всегда могу найти его методом проб и ошибок (поскольку процесс сразу дает сбой).

Второй сценарий, с которым я сталкиваюсь OOM, — это когда начинается процесс обучения, и он продолжается какое-то время. Может быть, даже несколько эпох. Но затем по какой-то неизвестной причине он сталкивается с OOM. Для меня этот сценарий является разочаровывающим. Потому что это может произойти в любое время, и вы никогда не узнаете, закончится ли текущая тренировка или нет. До сих пор я потерял дни тренировок, хотя я думал, что все идет хорошо.

Думаю, необходимы некоторые пояснения. Прежде всего, я говорю о персональном компьютере с графическим процессором. А во-вторых, GPU предназначен для вычислений и не используется для отображения. Поправьте меня, если я ошибаюсь, но я считаю, что это означает, что тренировочный процесс требует разного объема памяти в разные моменты времени. Как это могло быть? И еще раз, как я могу убедиться, что мой этап обучения не столкнется с OOM?

Возьмем, к примеру, этот пробег:

3150/4073 [======================>.......] - ETA: 53:39 - loss: 0.3323
2019-10-13 21:41:13.096320: W tensorflow/core/common_runtime/bfc_allocator.cc:314] Allocator (GPU_0_bfc) ran out of memory trying to allocate 60.81MiB (rounded to 63766528).  Current allocation summary follows.

После трех часов обучения TensorFlow запросил больше памяти, чем могло предоставить мое оборудование. Мой вопрос: почему это увеличение выделения памяти в этот момент, а не в начале процесса?

[ОБНОВЛЕНИЕ]

В свете известных проблем с нетерпеливым режимом я добавлю некоторые пояснения к моему делу. Я не кодирую в нетерпеливом режиме. А вот как выглядит мой тренировочный код:

strategy = tf.distribute.OneDeviceStrategy(device="/gpu:0")
training_dataset = tf.data.Dataset.from_tensor_slices(...)
validation_dataset = tf.data.Dataset.from_tensor_slices(...)

with strategy.scope():
    model = create_model()

    model.compile(optimizer='adam', loss='categorical_crossentropy')

    pocket = EarlyStopping(monitor='val_loss', min_delta=0.001,
                           patience=5, verbose=1,
                           restore_best_weights = True)

    history = model.fit(training_dataset.shuffle(buffer_size=1000).batch(30),
                        epochs=3,
                        callbacks=[pocket],
                        validation_data=validation_dataset.shuffle(buffer_size=1000).batch(30),
                        workers=3, use_multiprocessing=True)

person Mehran    schedule 13.10.2019    source источник


Ответы (1)


Существует известная утечка памяти [1], которая происходит, если вы постоянно тренируетесь в цикле. Решением этого является вызов tf.keras.backend.clear_session() и, возможно, gc.collect() время от времени в цикле.

Похоже, что в TF 1.15 и 2.0 поведение отличается, и этого может быть недостаточно, чтобы исправить это. Я обнаружил, что tf.keras.backend.clear_session() в моем тренировочном цикле на ЦП сбрасывает постепенную утечку памяти, не нанося вреда обучению.

[1] https://github.com/tensorflow/tensorflow/issues/30324

person user1318499    schedule 13.10.2019
comment
Спасибо. Я постараюсь использовать вашу информацию, чтобы посмотреть, смогу ли я найти что-нибудь в Интернете. Но что касается ссылки, которую вы предоставили, она находится в активном режиме. Мой нет. Я должен упомянуть об этом в стебле. Кроме того, у меня нет цикла или чего-то еще, это просто вызов mdoel.fit. Я добавлю больше информации в свой пост. Спасибо еще раз. - person Mehran; 14.10.2019