私は Distributed Tensorflow、特に次の論文https://github.com/Russell91/TensorBoxに記載されている Distributed Tensorflow を使用した再検査モデルの実装に取り組んでいます。
Distributed tensorflow 設定の Between-graph-Asynchronous 実装を使用していますが、結果は非常に驚くべきものです。ベンチ マーキング中に、分散型トレーニングは、単一のマシン トレーニングよりもほぼ 2 倍以上のトレーニング時間がかかることがわかりました。何が起こっているのか、他に何を試すことができるのかについてのリードは本当にありがたいです. ありがとう
注: 投稿に訂正があります。グラフ内実装ではなく、グラフ間実装を使用しています。間違いをお詫びします
一般に、モデルの単一プロセス実装から複数マシン実装への移行が速度低下につながるとしても、私は驚かないでしょう。あなたの質問からは、何が起こっているのかは明らかではありませんが、ここにいくつかの一般的な指針があります:
モデルが計算量に対して多数のパラメーターを持っている場合 (たとえば、畳み込みではなく大規模な行列乗算を主に実行する場合)、ネットワークがボトルネックであることがわかる場合があります。ネットワーク接続の帯域幅は?
おそらく不適切なデバイスの配置が原因で、プロセス間に多数のコピーがありますか? タイムラインを収集して視覚化して、モデルの実行時に何が起こっているかを確認してください。
スケーラビリティのために現在推奨されていない「グラフ内レプリケーション」を使用しているとのことです。グラフ内レプリケーションは、特に多数のレプリカを含む大規模なモデル グラフがある場合に、単一のマスターでボトルネックを作成する可能性があります。
レプリカ全体で単一の入力パイプラインを使用していますか、それとも複数の入力パイプラインを使用していますか? 単一の入力パイプラインを使用すると、入力パイプラインを実行するプロセスでボトルネックが発生します。(ただし、イングラフ レプリケーションでは、1 つの Python プロセスが多数のスレッドで I/O を駆動するため、複数の入力パイプラインを実行するとボトルネックが生じる可能性があります。)
または、フィード機構を使用していますか? レプリケートされた設定の場合と同様に、プロセスの境界を越える必要がある場合、データのフィードは非常に遅くなります。グラフ間レプリケーションを使用すると、少なくとも単一のクライアント プロセスでのボトルネックが解消されますが、パフォーマンスを向上させるには、入力パイプラインを使用する必要があります。( Yaroslav が観察したように、データが RPC 経由で転送されるため、分散バージョンでは大きなテンソル値のフィードとフェッチが遅くなります。単一のプロセスでは、memcpy()代わりに単純なものが使用されます。)
いくつのプロセスを使用していますか? スケーリング曲線はどのように見えますか? パラメータ サーバーと単一のワーカー レプリカを使用するように切り替えると、すぐに速度が低下しますか? (単一の組み合わせたプロセスと比較して) レプリカを追加すると、パフォーマンスが良くなったり悪くなったりしますか?
最近似たようなことを調べていて、grpc から Python ランタイムへのデータの移動が予想よりも遅いことに気付きました。特に次のパターンを検討してください
add_op = params.assign_add(update)
...
sess.run(add_op)
add_op別のプロセスにある場合は、50 ～ sess.run100 MB/秒の速度で発生するデコード ステップを追加します。