我有一些代碼從張量記錄中讀取圖像,對它們進行預處理(剪切,應用隨機色調/飽和度等,全部通過張量自身的方法),然後使用shuffle_batch_join
生成批次。如果在cpu上完成讀取/預處理,Tensorflow網絡會發散
with tf.variable_scope('dump_reader'):
all_files = glob.glob(dump_file + '*')
filename_queue = tf.train.string_input_producer(all_files, num_epochs=epochs)
example_list = [read_tensor_record(filename_queue, image_size)
for _ in range(read_threads)]
return tf.train.shuffle_batch_join(example_list, batch_size=batch_size,
capacity=min_queue_size + batch_size * 16,
min_after_dequeue=min_queue_size)
這個效果很好,並導致在將所有操作放在GPU上時聚合網絡。然而,這正是我的代碼的瓶頸,我想通過把它放在CPU上,並將它放在with tf.device('/cpu:0'):
中來加速它。有了這個,我有更快的迭代次數(大約1/5),但是網絡在大約10次迭代之後發散,導致NaN損失。當目視檢查張量板中產生的樣品時,沒有明顯的差異。
爲什麼cpu vs gpu的收斂行爲不同?我怎麼能進一步調查這種奇怪的行爲?
這很奇怪。我的猜測是,GPU和其中一個圖像處理操作的CPU實現存在一個錯誤(或不一致)。爲了進行調查,我建議:(1)用'tf.Session(config = tf.ConfigProto(log_device_placement = True)')來構建會話,以查看工作版本中GPU實際調度哪些操作,然後有選擇地將它們移動到CPU以查看哪一個可能導致此問題。 – mrry
@ mrry好主意,我會做到這一點,並在github上找到問題後再開啓一個問題。 – panmari
你有沒有設法本地化這個問題?我遇到了類似的問題(使用TF 0.8.0),其中我的管道在GPU上運行良好,但在CPU上,它開始頻繁地生成NaN。 –