tf.estimator的分佈式培訓導致更多的培訓步驟

Question

我正在試驗Cloud ML Engine上的分佈式培訓選項，並觀察了一些特殊的結果。我基本上改變了人口普查定製估算例子，以包含稍微不同的模型，並將我的損失函數更改爲AdamOptimizer作爲唯一真正的變化。基於其他thread，我的理解是，任何分佈式培訓都應該是數據並行異步培訓，這將提示「如果您在10個工作節點中分發10,000個批次，則每個節點的工作量大約爲1,000個批次。」在我的實驗中，我有〜650k個訓練實例，並且我正在運行下列實驗，批處理量爲128個1個時期。給定650k個訓練實例和128個批處理大小，我預計會有~5.1k個步驟時代。下面是我看到的性能不同--scale-tier的

尚未發放

• BASIC：8步/秒，5.1K步驟，11分鐘掛鐘時間
• BASIC_GPU：24步/秒，5.1K步驟，3.5分鐘壁時間

分佈式

• 標準_1：14.5步/秒 - 26K步驟（26K * 128 =〜3.3M比所述訓練樣本實際上是在數據多路），29分鐘壁時間

• CUSTOM - 5 complex_model_m工人，2 large_model參數服務器：27步/秒，31K的步驟（128 * 31K =〜3.9M其比650K訓練樣本實際上是在數據路以上），壁時間20分鐘

我期望的是，基於該文章的數據平行分佈式培訓將在所有工人中分配批次，所以如果我有5名工人在〜5k蝙蝠那麼每個工人就會執行〜1,000個批次。然而，我觀察到的實際行爲是，似乎更接近每5個工人進行1個時代的每一個人。在分佈式環境下進行訓練時，在一個時代中所採用的步數是訓練樣例的6倍 - 我知道每次梯度的更新都會對步驟的真實定義產生影響，但我對數據並行訓練的理解是：這只是分割批次，所以應該有相同數量的梯度更新 - 有什麼理由可以預期這種行爲？在數據並行異步培訓分佈式環境中需要更多的培訓步驟是否合理？任何人都可以解釋我正在觀察的行爲嗎？

Answer 1

以前的答案是解釋性能瓶頸的工作做得很好。讓我解釋一下「時代」以及TensorFlow如何處理數據集。

，在TensorFlow分佈式訓練的工作方式是，每個工人獨立完成整個數據集進行迭代。這是一種常見的誤解，認爲訓練集是在工人之間進行分配的，但事實並非如此。

與隊列（見this tutorial）一個典型的設置，會發生什麼情況是每個勞動者創造它自己的隊列。該隊列中充滿了所有訓練文件的所有文件名列表（通常列表被混洗，每當隊列耗盡時，它就會被重新填充並重新組合）。每個文件在逐個實例中讀取，數據被解析，預處理，然後被饋送到另一個隊列中，在該隊列中進行混洗和批處理。一旦讀取了任何文件的最後一個實例，下一個文件名就會從文件名隊列中彈出。如果沒有更多文件可以彈出，則「紀元」已經完成。

這裏重要的一點是，所有這些隊列默認爲本地 - 不共享。所以每個工作人員都獨立地重複相同的工作 - 爲所有文件創建隊列並遍歷整個數據集。那麼，一個完整的時代大致等於完整數據集中的實例數*工人數。 （我不確定你的standard_1結果，但CUSTOM的結果意味着你的主人+5名工人= 6名工人* 650K個例子*（1批/ 128個例子）= 31K步）。

僅供參考使用時期的，不鼓勵使用參數化的分佈式訓練，因爲它太混亂，甚至有可能出現在一般與它的問題。只要堅持max_steps。

請注意，由於TensorFlow的設計，「批量大小」是指每個工人的批量大小。但是每個工作人員將以大致相同的速率向參數服務器發送更新，因此在一段時間內大致相當於處理一個「批量」所需的時間，參數發生更新的次數大致爲batch_size * num_workers。這就是我們所說的有效的批量大小。這反過來有一些實際後果：

1. 您傾向於使用更小的batch_sizes，特別是如果你有大量的工人，使有效批量大小保持理智。
2. 如果增加工人的數量，你的有效批量大小的增加，因此你需要降低你的學習速度，使用「香草」隨機梯度下降時，至少。具有自適應學習速率的優化器（如Adagrad，Adam等）往往對最初的學習速率很穩健，但是如果添加足夠多的工作人員，您仍然可能需要調整學習速率。

你也許會奇怪，爲什麼TensorFlow處理以這種方式訓練數據。這是因爲在分佈式系統中，不能依賴於速度相同的機器，或者甚至是可靠的機器。如果您將訓練數據劃分爲不相交的集合，並將其分配給每個工作人員，然後一臺或多臺機器相對於另一臺機器較慢，或者網絡出現故障等，則您的訓練過程將從「快速」/「可靠的工人比「慢」/不可靠的工人更頻繁。這將結果偏向於這些情況（或者在極端情況下，一起忽略它）。

Answer 2

有兩種類型西弗斯的：

• 工人：它執行圖形計算
• 參數服務器：用來存儲參數，使所有的工人都能分享和更新參數

你可以在參數服務器中有一個瓶頸。如果模型非常大並且參數服務器很少，則需要在工作者和參數服務器之間進行更多通信。例如，如果您有2個參數服務器，則您將在一臺服務器中擁有該模型的一半參數，而在另一臺服務器中擁有另一半參數。如果你有很多的工人，他們必須得到並向不同的工人發送很多參數，而工人們將會有很大的滯後。如果增加參數服務器的數量，則由於每個參數服務器與工作人員之間的通信較少，所以滯後將會減少。

由於批量大小爲128（相當大），並且您只能在CPU中每秒執行8個步驟，所以我認爲您的模型速度如此之快，以致共享服務器參數比運行一次迭代需要更多時間。所以你也可以嘗試增加批量。