MXNetによる分散ニューラルネットワークトレーニング。 パート1

今日は、「 MXNetのコンテキストでの分散学習はどのように機能しますか？」という簡単な質問に答えます。

MXNet v0.10.0でテストされたすべてのコード例は、他のバージョンでは動作しない（または異なる動作をする）場合がありますが、一般的な概念は長い間変更されないと思います。

さて、最後に、主要部分に進む前に、この記事を書くことができなかった同僚に記事を書く手助けをしてくれたことに感謝したいと思います。

• マダンジャンパニ;
• スニール・マルティ;

また、 DLAMIを使用してマシンを上げて、記事のすべての例を完了することをお勧めします。特に非常に簡単です。 コードを実行するには、無料のAWSマシンが非常に適しています。

前文が終わり、猫の下に登り......

MXNetの見方を分散学習

MXNetでは、学習プロセスのすべての参加者は3つの論理グループに分けられます。

• スケジューラー
• サーバー
• 労働者

これは純粋に論理的な配布であるため、すべての参加者が同じマシンで作業できます。

最初に、各参加者が何であるかの表面的な説明を見てみましょう。

プランナー

スケジューラーはクラスターの中央ノードであり、クラスターの初期構成を担当し、学習プロセスの各参加者に必要な情報を提供します。 クラスタがトレーニングを開始する準備ができたらすぐに、彼がどのようにサスペンドアニメーションに落ちるかを確認します。 また、クラスターがトレーニングを終了しても、そのタスクは自動的にオフになります。

誰もが、クラスターにはスケジューラーが1つしか存在できないことをすでに推測していると思います。

サーバー

サーバーは、トレーニングモデルパラメーターのリポジトリとして機能します。 つまり、モデルがスタイルY = AX + Bでトレーニングされている場合、サーバーはベクトルAとBを格納します。また、モデルの正しい更新も担当します。 複数のサーバーが存在する可能性があるため、複数のサーバーにモデルを配布するルールがあります。 しかし、これは別の記事のトピックです。

労働者

これらは、実際にモデルトレーニングを直接実行するクラスターメンバーです。 各ワーカーは、トレーニングが必要なデータの一部を受け取り、勾配ステップを検討し、それをサーバーに送信してモデルを更新します。

クラスターの例

偽のクラスターの例を取り上げましょう：

• 別のマシンのスケジューラー。
• 2つのサーバー。
• 労働者がいる3台のマシン。

クラスター自体は次のようになります。

この図は、説明されている構成と同様に、データストリームを視覚化するためにのみ使用されます。

クラスターの初期化

上記のような大きなクラスターは実際には作成しませんが、1台の物理マシン上に3つのノードがあるはるかに小さなクラスターで管理します。 これにはいくつかの理由があります。

• よりシンプルで安価。
• すべてのログが1つの場所にあるため、説明が簡単になります。

続行する前に、1つの詳細を明確にする必要があります。 MXNetの場合、分散学習とは本質的にKVStoreの使用を意味します。 この名前は、Key Value Storageの頭字語です。 そして本質的に、サーバー上で実行され、いくつかの追加機能を備えた分散ストレージです（たとえば、動作中のモデルから勾配ステップを受け取って、モデルを正確に更新する方法を知っています）。

また、KVStoreサポートは、次の2つの方法のいずれかでのみ使用できます。

• MXNetは手動でビルドされ、フラグUSE_DIST_KVSTORE = 1が有効になっているか、
• DLAMIが使用された（フレームワークはUSE_DIST_KVSTORE = 1フラグを有効にして手動で構築されたため）

この記事では、Jun / Jul DLAMI（MXNet 0.10.0）リリースのMXNetが使用されることを想定しています。

読み取り時に、公式のMXNet pipパッケージがKVStoreをサポートする可能性はまだゼロではありません。

論理クラスタメンバーの作成を開始します。 参加者を作成するには、いくつかの環境変数を作成してからmxnetモジュールをインポートするだけです。

プランナー

まず、スケジューラーを実行します。

ubuntu:~$ python >>> import subprocess >>> import os >>> scheduler_env = os.environ.copy() >>> scheduler_env.update({ … "DMLC_ROLE": "scheduler", … "DMLC_PS_ROOT_PORT": "9000", … "DMLC_PS_ROOT_URI": "127.0.0.1", … "DMLC_NUM_SERVER": "1", … "DMLC_NUM_WORKER": "1", … "PS_VERBOSE": "2" … }) >>> subprocess.Popen("python -c 'import mxnet'", shell=True, env=scheduler_env) <subprocess.Popen object at 0x7facb0622850>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで少し停止して、何が起こっているのかを理解しましょう。 コードの最初の4行は、Pythonプログラマーに多くの質問を引き起こさないはずです。依存関係をインポートして、OS環境を作成するだけです。 ここで興味深いのは、環境変数にどのような更新が行われるかです。

DMLC_ROLEを見てみましょう。 それが使用されている場所、つまりps-liteパッケージで正確に見てみましょう。 公式のREADMEに従って（無料翻訳）：

パラメータを保存するための簡単で効率的なサーバー実装。

さて、環境変数がここで読み取られる正確な場所（ところで、特定のコミットへのすべての参照）。

 val = CHECK_NOTNULL(Environment::Get()->find("DMLC_ROLE")); // here std::string role(val); is_worker_ = role == "worker"; is_server_ = role == "server"; is_scheduler_ = role == "scheduler"; // and later here verbose_ = GetEnv("PS_VERBOSE", 0);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで何が起きているのかを理解するために、C ++の第一人者であってはいけません。 ノードの論理的な役割は、この変数「DMLC_ROLE」の行によって決定されます。 おかしいですが、この変数に許可された値の1つが含まれているかどうかはチェックされていないようです。 これにより、興味深い問題が発生する可能性があります。

2番目に興味深いのは、変数が読み取られる場所だけでなく、変数が使用される場所です。 これについて話すには、van.ccファイルに目を向ける必要があります。van.ccファイルは2回以上表示されます。変数が使用され、変数 "is_scheduler"が作成される特定の行を次に示します。

 scheduler_.hostname = std::string(CHECK_NOTNULL(Environment::Get()->find("DMLC_PS_ROOT_URI"))); scheduler_.port = atoi(CHECK_NOTNULL(Environment::Get()->find("DMLC_PS_ROOT_PORT"))); scheduler_.role = Node::SCHEDULER; scheduler_.id = kScheduler; is_scheduler_ = Postoffice::Get()->is_scheduler(); // here
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コードをすばやく調べてそこで何が起こるかを確認すると、次の興味深い場所を見ることができます。

 // get my node info if (is_scheduler_) { my_node_ = scheduler_; } else { auto role = is_scheduler_ ? Node::SCHEDULER : (Postoffice::Get()->is_worker() ? Node::WORKER : Node::SERVER);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この特定の例では、変数「role」はNode :: SCHEDULERと決して等しくなりません。 そのため、これを修正するためのプルリクエストを作成する機会があります（誰も修正していない場合）。

この場所を見るだけで、プランナーにはあまり仕事がないことがわかります。 これは、動作中のサーバーやサーバーとは異なり、スケジューラは転送されたIPアドレスとポートを使用し、システム内の空きポートを検索しないためです。

さらに進んで、パラメーター：DMLC_PS_ROOT_PORT。 既存の知識を考慮して、これに迅速に対処します。 すでに見たコードは次のとおりです。

 scheduler_.hostname = std::string(CHECK_NOTNULL(Environment::Get()->find("DMLC_PS_ROOT_URI"))); scheduler_.port = atoi(CHECK_NOTNULL(Environment::Get()->find("DMLC_PS_ROOT_PORT"))); // here scheduler_.role = Node::SCHEDULER; scheduler_.id = kScheduler; is_scheduler_ = Postoffice::Get()->is_scheduler();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

繰り返しますが、これはvan.ccのものです。 ご想像のとおり、これはスケジューラがメッセージをリッスンするポートです。

この段階で、DMLC_PS_ROOT_URIがスケジューラのIPアドレスに過ぎないことは明らかです。 それでは、DMLC_NUM_SERVERとDMLC_NUM_WORKERの説明にすぐに飛び込みましょう。

そのため、クラスター内のすべてのMXNet論理ノードが他のすべてのノードを認識している必要がありました。 そのため、各ノードの起動前に、環境変数はクラスター内のワーカーとサーバーの数を記録します（スケジューラーの数は常に1であるため、不要です）。 ところで、この情報は（他のクラスター情報とともに） Postofficeクラスに保存されます。

さて、最後のパラメータですが、おそらく最も重要なアーキテクチャの1つであるPS_VERBOSEです。 これにより、新しく作成されたプロセスがデバッグ情報を出力するようになりますが、これは今では非常に重要です。

偽の図の観点から見ると、クラスターは次のようになります。

サーバーを起動します

スケジューラーができたので、サーバーを上げましょう。 1台のマシンですべての論理ノードを上げるため、サーバーを起動するには、環境パラメーターのコピーを作成し、そこで必要な変更を再度行う必要があります。

 >>> server_env = os.environ.copy() >>> server_env.update({ … "DMLC_ROLE": "server", … "DMLC_PS_ROOT_URI": "127.0.0.1", … "DMLC_PS_ROOT_PORT": "9000", … "DMLC_NUM_SERVER": "1", … "DMLC_NUM_WORKER": "1", … "PS_VERBOSE": "2" … }) >>> subprocess.Popen(“python -c 'import mxnet'”, shell=True, env=server_env) <subprocess.Popen object at 0x7facb06228d0>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私は今、コードで何が起こっているかが質問を引き起こさないことを望みますが、念のために：

• 新しいプロセスはサーバー（DMLC_ROLE）です。
• スケジューラのIP（DMLC_PS_ROOT_URI）を示します。
• スケジューラが着信接続をリッスンするポート（DMLC_PS_ROOT_PORT）について話します。
• サーバーにクラスター内のワーカーの数を伝えます（DMLC_NUM_WORKER）
• クラスター内のサーバーの数（DMLC_NUM_SERVER）をサーバーに伝えます
• さて、出力をデバッグモードに設定します（2）

それから誰かが尋ねるかもしれません：待って、DMLC_PS_ROOT_PORTとDMLC_PS_ROOT_URIが、開始している論理ノードのIPとポートを示すと思ったのですか？ 答えはノーです。これはスケジューラのアドレスとポートですが、他の全員がアドレスを把握し、システムで使用可能なポートを見つける必要があります。 彼らは彼をノックしてスケジューラーをクラスターに追加するように頼むためにスケジューラーについての情報を必要とします。

サーバーを起動すると、図は次のようになります。

ワーカーを起動します

実際に、ワーカー自身を起動してKVStoreを作成します。

 >>> os.environ.update({ … "DMLC_ROLE": "worker", … "DMLC_PS_ROOT_URI": "127.0.0.1", … "DMLC_PS_ROOT_PORT": "9000", … "DMLC_NUM_SERVER": "1", … "DMLC_NUM_WORKER": "1", … "PS_VERBOSE": "2" … }) >>> worker_env = os.environ.copy() >>> import mxnet >>> kv_store = mxnet.kv.create('dist_async')
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ところで、KVStoreは次の2つのモードで動作できます。

• dist_sync
• dist_async

これらのモードがどのように異なるかについては、好奇心reader盛な読者に質問を任せます 。 それについてはこちらで読むことができます 。

ワーカーを開始すると、図は次のようになります。

ノードのライフサイクル（Van）

KVStoreの作成時に何が起こるかを急いで議論する前に、各ノードには次のイベントを含むライフサイクルがあるという事実について話す必要があります。

• スタート -スタート
• 停止 -停止
• 受信 -メッセージの受信

また、これらのイベントの処理を担当する同じクラス（ Van ）には、他にも重要なメソッドがいくつかあります。 それらのいくつかについては、他の記事で後ほど詳しく説明しますが、今は次のようにリストします。

• 送信 -メッセージを送信します
• PackMeta-モデルをプロトメッセージに変換します
• UnpackMeta-プロトメッセージをアンパックし、モデルを作成します
• HeartBeat-彼がまだ生きているというメッセージを送信します

これは、開始信号が到着したときに各ノードが行うことです。

• スケジューラに関するすべてのデータをメモリにロードします
• ノード（ワーカー、スケジューラ、サーバー）に割り当てられたロールに関する情報をメモリにロードします
• 計画者以外の場合- 空きポートを見つけて、スケジューラに送信する必要がある自分に関するすべてのデータを収集します （必要に応じて、ポートは環境変数を介して設定できます）
• 見つかったポートに身を縛る
• 着信メッセージをリッスンするスレッドを開始します
• プランナー以外の場合-スケジューラーにメッセージを送信して、クラスターに自分自身を追加するように依頼します（少し後で説明します）
• ノードが生きているというシグナルを送信するスレッドを実行します

クラスターの初期化

上記のすべてのコマンドが完了するとすぐに、以前に起動した3つのプロセスから同時に取得された多くのデバッグ情報が画面に表示されます。 次に、各行を見て、各段階で何が起こっているのか、図がどのように見えるのかを詳しく説明します。

[00:33:12] src / van.cc：75：ロール=ワーカーにバインド、ip = 1.1.1.1、ポート= 37350、is_recovery = 0

これにより、ワーカープロセスが開始されます。 この場合、それはStartメソッドであり、アドレスが1.1.1.1であり、ロールが「worker」であり、見つかったポートが37350であることを示します。アドレスとポートを示すことにより、すぐにスケジューラーにクラスターに追加する準備ができたことを通知しよう：

[00:33:12] src / van.cc：136：？ => 1.メタ：リクエスト= 0、タイムスタンプ= 3、コントロール= {cmd = ADD_NODE、ノード= {role = worker、ip = 1.1.1.1、ポート= 37350、is_recovery = 0}}

この特定のメッセージは、ここでSendメソッドで生成されます。 その中で、いくつかのことに注意する必要があります。

• is_recovery = 0-復旧モードではないことを報告します。この部分はこの記事の範囲外です
• cmd = ADD_NODE-ワーカーをクラスターに追加するスケジューラーへのコマンド
• ？ => 1-各ノードには独自のランクがあります。 ランクはプランナーによって割り当てられます。 スケジューラー自体のランクは1です。この場合、ランクのないノードは、ランク1（スケジューラー）のノードにメッセージを送信します。

図では、このメッセージングは​​次のようになります。

さらに進む

[00:33:13] src / van.cc：75：ロール=サーバーへのバインド、IP = 2.2.2.2、ポート= 54160、is_recovery = 0

これによりサーバーが起動しました。 ポート（54160）を見つけましたが、プランナーはすぐにそのことを通知しようとします：

[00:33:13] src / van.cc：136：？ => 1. Meta：request = 0、timestamp = 0、control = {cmd = ADD_NODE、node = {role = server、ip = 2.2.2.2、port = 54160、is_recovery = 0}}

チャートでは、次のようになります。

ワーカーの場合と同様に、サーバーはコマンド「ADD_NODE」を送信してクラスターに登録します。 サーバーはまだクラスターに登録されておらず、ランクがないため、「？=> 1」が表示されます。

[00:33:13] src / van.cc：75：ロールにバインド=スケジューラー、ID = 1、IP = 127.0.0.1、ポート= 9000、is_recovery = 0

最後に、スケジューラーが実行されています。 ローカルIPとポート9000を使用します（クラスター内のすべてのノードは、そのアドレスとポートを既に知っている必要があります）。 スケジューラが提起されたので、その瞬間に彼が彼に送信されたすべての着信メッセージを受信することを期待することは論理的です...そして出来上がり：

[00:33:13] src / van.cc：161：？ => 1. Meta：request = 0、timestamp = 0、control = {cmd = ADD_NODE、node = {role = server、ip = 2.2.2.2、port = 54160、is_recovery = 0}}

サーバーからのメッセージ。 ログのこの部分は、 Receiveメソッドによって生成されますが、 ここではさらに正確です 。 スケジューラーはすぐに2番目のメッセージを受信します。今回はワーカーからです：

[00:33:13] src / van.cc：161：？ => 1.メタ：リクエスト= 0、タイムスタンプ= 3、コントロール= {cmd = ADD_NODE、ノード= {role = worker、ip = 1.1.1.1、ポート= 37350、is_recovery = 0}}

プランナーが最初に行うことは、最初にワーカーにランクを割り当てることです（9）：

[00:33:13] src / van.cc：235：ランク= 9をノードロールに割り当てます= worker、ip = 1.1.1.1、ポート= 37350、is_recovery = 0

サーバー（8）へ：

[00:33:13] src / van.cc：235：ランク= 8をノードロール=サーバーに割り当て、IP = 2.2.2.2、ポート= 54160、is_recovery = 0

その後、非常に重要な部分があります。

[00:33:13] src / van.cc：136：？ => 9. Meta：request = 0、timestamp = 0、control = {cmd = ADD_NODE、node = {role = worker、id = 9、ip = 1.1.1.1、port = 37350、is_recovery = 0 role = server、id = 8、ip = 2.2.2.2、port = 54160、is_recovery = 0 role = scheduler、id = 1、ip = 127.0.0.1、port = 9000、is_recovery = 0}}

これらのメッセージは、スケジューラーがすべてのクラスターノード（この場合、最初の作業サーバーと最初のサーバー）からADD_NODEコマンドを受信し、すべてのノードにランクとクラスター内の他のすべてのノードに関する情報を通知し始めたことを示しています。 つまり、スケジューラは、すべてのクラスターノードに関するすべての情報をすべてのクラスターノードに送信します。

この特定のメッセージでは、クラスターに関するすべてのデータが表示され、このメッセージはランク9（これは従業員です）でノードに送信されます。 クラスターに関する情報は、たとえば、どのサーバーにモデルの更新を送信するかを理解するために必要なため、重要です。

図では、このプロセスは次のようになります。

次の結論：

[00:33:13] src / van.cc：136：？ => 8. Meta：request = 0、timestamp = 1、control = {cmd = ADD_NODE、node = {role = worker、id = 9、ip = 1.1.1.1、port = 37350、is_recovery = 0 role = server、id = 8、ip = 2.2.2.2、port = 54160、is_recovery = 0 role = scheduler、id = 1、ip = 127.0.0.1、port = 9000、is_recovery = 0}}

スケジューラーは、同じ確認をランク8（サーバー）のノードに送信します。 図は次のようになります。

[00:33:13] src / van.cc：251：スケジューラーは1つのワーカーと1つのサーバーに接続されています

スケジューラは、1つのワーカーと1つのサーバー（すべてのクラスターノード）に接続されていることを喜んで発表しました。

リマインダー-実際のクラスターで実行する場合、これらのログはすべて異なるマシン上にあるため、必要以上の情報があるように見えるかもしれません。

[00:33:13] src / van.cc：161：1 =>2147483647。メタ：リクエスト= 0、タイムスタンプ= 0、コントロール= {cmd = ADD_NODE、ノード= {role = worker、id = 9、ip = 1.1.1.1、ポート= 37350、is_recovery = 0ロール=サーバー、id = 8、ip = 2.2.2.2、ポート= 54160、is_recovery = 0ロール=スケジューラー、id = 1、ip = 127.0.0.1、ポート= 9000、 is_recovery = 0}}

[00:33:13] src / van.cc：281：W [9]は他のユーザーに接続されています

このワーカーは、スケジューラーからメッセージを受信し、クラスターに接続していることを報告します。 「2147483647」とは何かを尋ねるかもしれません。 答えはわからない=）おそらくバグであり、「1 => 9」が表示されることを期待しています。 したがって、ワーカーは自分のランク「W [9]」を正しく認識しているため、バグはログ記録のプロセスのどこかに存在する可能性が高いため、修正してプロジェクトの貢献者になります。

[00:33:13] src / van.cc：161：1 =>2147483647。メタ：リクエスト= 0、タイムスタンプ= 1、コントロール= {cmd = ADD_NODE、ノード= {ロール=ワーカー、id = 9、ip = 1.1.1.1、ポート= 37350、is_recovery = 0ロール=サーバー、id = 8、ip = 2.2.2.2、ポート= 54160、is_recovery = 0ロール=スケジューラー、id = 1、ip = 127.0.0.1、ポート= 9000、 is_recovery = 0}}

[00:33:13] src / van.cc：281：S [8]は他のユーザーに接続されています

サーバーについても同じです。彼はメッセージを受け取り、この世界について喜んで伝えました。

[00:33:13] src / van.cc：136：？ => 1.メタ：リクエスト= 1、タイムスタンプ= 4、コントロール= {cmd = BARRIER、barrier_group = 7}

[00:33:13] src / van.cc：136：？ => 1.メタ：リクエスト= 1、タイムスタンプ= 2、コントロール= {cmd = BARRIER、barrier_group = 7}

[00:33:13] src / van.cc：136：？ => 1.メタ：リクエスト= 1、タイムスタンプ= 1、コントロール= {cmd = BARRIER、barrier_group = 7}

別の重要な部分。 これまで、ADD_NODEコマンドは1つしか見ていません。 ここでは、新しい「BARRIER」を確認します。 要するに、これはバリアの概念であり、マルチスレッドプログラミングの読者にはおなじみであり、「誰もがこのバリアに達するまで停止する」ことを願っています。 計画担当者は、正確に全員がバリアに到達したことをいつでも通知する責任があり、それを継続することができます。 最初の障壁は、クラスターが開始された直後、ただしトレーニングが開始される前に配置されます。 3つのノードすべて（スケジューラー自体を含む）がメッセージを送信しました。これは基本的に「障壁に到達したので、次に進むことができることを知らせてください」という意味です。

また、メッセージからわかるように、バリアグループ（barrier_group）の概念があります。 バリアグループは、特定のバリアに関係するノードのグループです。 これらのグループは次のとおりです。

1-スケジューラー

2-サーバー

4-労働者

ご想像のとおり、これは2の累乗であるため、グループ7は4 + 2 + 1です。本質的に、この障壁はすべての人に及んでいます。

もちろん、ログでは3つのメッセージが送信されたので、スケジューラによるこれらのメッセージの受信について3行を期待するのは当然です。

[00:33:13] src / van.cc：161：1 => 1.メタ：リクエスト= 1、タイムスタンプ= 2、コントロール= {cmd = BARRIER、barrier_group = 7}

[00:33:13] src / van.cc：291：7：1のバリアカウント

[00:33:13] src / van.cc：161：9 => 1.メタ：リクエスト= 1、タイムスタンプ= 4、コントロール= {cmd = BARRIER、barrier_group = 7}

[00:33:13] src / van.cc：291：7：2のバリアカウント

[00:33:13] src / van.cc：161：8 => 1.メタ：リクエスト= 1、タイムスタンプ= 1、コントロール= {cmd = BARRIER、barrier_group = 7}

[00:33:13] src / van.cc：291：7：3のバリアカウント

チャートで行われていることは次のようになります。

ここで、ノードが特定のグループのバリアに到達したという新しいメッセージを受信したときにスケジューラが何を行うかを議論します。

• 特定のグループでBARRIERコマンドを送信したノードの数のカウンターを増やします （ こちら ）
• カウンターがグループ内のノードの数に等しい場合、通常の操作を続行できることを確認するメッセージを全員に送信します

上記のログでは、新しいメッセージが受信されるたびにカウンターがどのように増加したかを確認できます。 さて、彼が予想サイズ（3）に達した瞬間に、スケジューラーは確認を送信し始めました。

[00:33:13] src / van.cc：136：？ => 9.メタ：リクエスト= 0、タイムスタンプ= 3、コントロール= {cmd = BARRIER、barrier_group = 0}

[00:33:13] src / van.cc：136：？ => 8.メタ：リクエスト= 0、タイムスタンプ= 4、コントロール= {cmd = BARRIER、barrier_group = 0}

[00:33:13] src / van.cc：136：？ => 1.メタ：リクエスト= 0、タイムスタンプ= 5、コントロール= {cmd = BARRIER、barrier_group = 0}

この図では、次のようになっています。

ご覧のとおり、スケジューラは自分自身に確認を送信します。 もちろん、スケジューラからメッセージが送信されたため（最大3つ）、 これらのメッセージが受信されたログを確認する必要があります 。

[00:33:13] src / van.cc：161：1 => 9. Meta：request = 0、timestamp = 3、control = {cmd = BARRIER、barrier_group = 0}

[00:33:13] src / van.cc：161：1 => 8.メタ：リクエスト= 0、タイムスタンプ= 4、コントロール= {cmd = BARRIER、barrier_group = 0}

[00:33:13] src / van.cc：161：1 => 1. Meta：request = 0、timestamp = 5、control = {cmd = BARRIER、barrier_group = 0}

さて、最後のタッチ。 現在、スケジューラーはトレーニングの終了後にすべてのノードが到達する2番目の障壁に到達していますが、スケジューラーはトレーニングに参加していないため、すでに同じ障壁に到達しています。 そのため、彼は障壁に到達したbarrier_group = 7グループを送信し、メッセージの受信を即座に確認し、障壁グループカウンター7を1に設定します。

[00:33:13] src / van.cc：136：？ => 1.メタ：リクエスト= 1、タイムスタンプ= 6、コントロール= {cmd = BARRIER、barrier_group = 7}

[00:33:13] src / van.cc：161：1 => 1.メタ：リクエスト= 1、タイムスタンプ= 6、コントロール= {cmd = BARRIER、barrier_group = 7}

[00:33:13] src / van.cc：291：7：1のバリアカウント

この段階で、クラスターの初期化が完了し、学習を開始できます...

トレーニング

すべてのコードを実行したら、KVstoreを初期化しました。 今何？ 直接学習に使用しましょう。 ここから 、線形リグレッサーの非常に単純な例を使用します 。 続行する前に、例を読んで、何が起こっているのかを理解してください。 説明した例のトレーニングを配布するには、コードの1行のみを変更する必要があります。 代わりに：

 model.fit(train_iter, eval_iter, optimizer_params={ 'learning_rate':0.005, 'momentum': 0.9}, num_epoch=50, eval_metric='mse', batch_end_callback = mx.callback.Speedometer(batch_size, 2))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

書く必要がある：

 model.fit(train_iter, eval_iter, optimizer_params={ 'learning_rate':0.005, 'momentum': 0.9}, num_epoch=50, eval_metric='mse', batch_end_callback = mx.callback.Speedometer(batch_size, 2), kvstore=kv_store) # updated line
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

とても簡単 要するに、はい。

少し結論

読者が、MXNetクラスターの発売時に何が起こっているかについて、より詳細に理解していただければ幸いです。 また、問題が発生した場合にこの記事がクラスターのデバッグに役立つことを願っています。 さらに、この知識があれば、クラスターのネットワークの特性についていくつかの結論を引き出すことができます。

• スケジューラが他の人と迅速に接続することは重要ではありません
• サーバー同士が高速で接続することは重要ではありません
• すべてのワーカーは各サーバーにすばやく接続する必要があります
• 労働者は互いに迅速なつながりを持つことは重要ではありません

Mediumに関する元の記事の推奨に非常に感謝します。 また、MXNetを使用して分散型のAWSベースの機械学習システムを突然構築していて、質問がある場合は、お気軽にお問い合わせください（viacheslav@kovalevskyi.com）。

参照：

• 記事のコードの完全版
• Draw.IO 、図を描くためのサービス
• MXNet ps-liteリポジトリ