Это довольно сложно диагностировать, не зная дополнительных подробностей (серверная часть хранилища, размер записи, количество записей в файле, количество файлов, любые операции ввода-вывода в _parse_image_function ?, ....)
My Первое подозрение относится к tf.data.TFRecordDataset (имена файлов) - открытие одного файла после следующего может привести к пикам задержки, которые могут временно привести к истощению конвейера процессора набора данных. (Несколько небольших файлов также могут иметь меньшие преимущества от автоматического c опережающего чтения)
Я бы попытался добавить дополнительную предварительную выборку сразу после tf.data.TFRecordDataset (имена файлов), чтобы отделить IO (и, возможно, чередовать записи из разные файлы (аргумент num_parallel_reads)).
Если предварительная выборка не помогла, я попытался бы жестко кодировать num_parallel_calls (главным образом потому, что я еще не прочитал код автонастройки - и, возможно, использовать частный пул потоков, если вам нужен конвейер больше, чем параллелизм по умолчанию).
В зависимости от серверной части хранилища - повторное обучение возобновляется после замедления обучения (для проверки / оптимизации набора данных) может просто извлекать данные из различных кэшей и может замедляться, когда превышается используемый набор данных кеши.