2016-01-21 35 views
3

我有一些代碼從張量記錄中讀取圖像,對它們進行預處理(剪切,應用隨機色調/飽和度等,全部通過張量自身的方法),然後使用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的收斂行爲不同?我怎麼能進一步調查這種奇怪的行爲?

+1

這很奇怪。我的猜測是,GPU和其中一個圖像處理操作的CPU實現存在一個錯誤(或不一致)。爲了進行調查,我建議:(1)用'tf.Session(config = tf.ConfigProto(log_device_placement = True)')來構建會話,以查看工作版本中GPU實際調度哪些操作,然後有選擇地將它們移動到CPU以查看哪一個可能導致此問題。 – mrry

+0

@ mrry好主意,我會做到這一點,並在github上找到問題後再開啓一個問題。 – panmari

+2

你有沒有設法本地化這個問題?我遇到了類似的問題(使用TF 0.8.0),其中我的管道在GPU上運行良好,但在CPU上,它開始頻繁地生成NaN。 –

回答

0

我有一個非常類似的問題。在我的情況下,我將圖像轉換操作固定在GPU上,但數據是從CPU上的隊列中饋入的。對我來說,把操作系統固定到GPU是一個錯誤,所以我用with tf.device('/cpu:0')將它們固定在CPU上,我的數值不穩定性問題就消失了。

值得注意的是,我以前也在GPU上運行過這些圖像預處理步驟,但沒有使用隊列來加載數據。我只是通過佔位符將數據直接提供給GPU,一切都運行良好。

它只是當我開始使用隊列,並從獨立的線程加載這些隊列,我開始看到這個問題(當我沒有從單獨的線程加載它們時,我能夠按順序使用隊列)。

我還沒有確切的答案,但它似乎確保數據和圖像預處理操作始終放置在相同的設備上是非常關鍵的。