我使用tensorflow來訓練DNN，我的網絡結構非常簡單，每個小型機器只有一臺參數服務器和一名工人時需要大約50ms。爲了處理大量樣本，我使用了分佈式ASGD培訓，但是，我發現增加的工人數量不能提高吞吐量，例如，在參數服務器機器數量和工人機器數量增加一倍之後，有40臺機器每秒可以達到150萬個樣本集羣仍然只能每秒處理150萬個樣本，甚至更糟。原因是當羣集很大時，每個步驟需要更長的時間。 tensorflow是否具有良好的可塑性，並提供加速培訓的建議？Tensorflow可擴展性
解決這些問題的一般方法是找出瓶頸在哪裏。您可能會遇到軟件或硬件的瓶頸。
做數學運算的一般示例 - 假設您有250M個參數，每個反向過程需要1秒。這意味着每個工作人員將發送1GB /秒的數據並接收1GB /秒的數據。如果你有40臺機器，那麼工人和參數服務器之間的傳輸速度將爲80GB /秒。假設參數服務器機器只有1GB /秒的全雙工NIC卡。這意味着如果你有少於40個參數服務器碎片，那麼你的NIC卡速度將成爲瓶頸。
經過判斷，你應該考慮互連速度。您的羣集中可能有N個網卡，但羣集很可能無法處理將數據發送到所有其他網卡的所有網卡。您的集羣可以處理80臺機器之間80GB /秒的數據流量嗎？谷歌設計自己的網絡硬件來處理他們的互連需求，所以這是一個重要的問題約束。
一旦你檢查你的網絡硬件可以處理負載，我會檢查軟件。 IE，假設你有一個工作人員，「發送時間」與參數服務器分片的數量有什麼關係？如果縮放強度是次線性的，則表明存在瓶頸，可能是某些線程的低效調度或某些其他問題。
作爲查找和修復軟件瓶頸的示例，請參閱grpc RecvTensor is slow問題。如果您嘗試發送超過100MB的消息，則該問題涉及gRPC層變得效率低下。這個問題在上游gRPC版本中得到修復，但尚未集成到TensorFlow版本中，所以目前的解決方法是將消息分解爲100MB或更小的碎片。
找到這些的一般方法是編寫大量的基準來驗證您對速度的假設。
下面是一些例子：
我的猜測是，I/O或者更普遍的輸入管道是瓶頸。你如何閱讀數據？你的隊列滿了嗎？ –
@AllenLavoie我沒有使用任何隊列，除了文件名隊列。我的圖形使用SSD中的tfrecord讀取器讀取原始數據，然後使用自定義運算符解析原始數據。文件IO和自定義操作符不是瓶頸。有沒有人使用非常大的集羣進行培訓？ –
什麼是輸入管道的無訓練吞吐量？同樣，您可以獲得每秒多少個樣本的合成數據？每個工人的CPU/GPU的利用率如何？ –