Как сделать так, чтобы этап обучения не столкнулся с OOM? - PullRequest
Новая
       42

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

0 голосов
/ 13 октября 2019

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

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

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

Я думаю, что некоторые пояснения в порядке. Прежде всего, я говорю о персональном компьютере с графическим процессором. А во-вторых, графический процессор предназначен для вычислений и не используется для отображения. Поправьте меня, если я ошибаюсь, но я считаю, что это означает, что учебный процесс требует разных объемов памяти в разные моменты времени. Как это может быть? И еще раз, как я могу убедиться, что моя фаза обучения не будет ориентирована на 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)

1 Ответ

1 голос
/ 14 октября 2019

Существует известная утечка памяти [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

...