", job_type="worker", group="experiment_1") as run:
# トレーニングコード
```
ノードに `job_type` を設定したら、Workspace で [保存済みビュー](/ja/models/track/workspaces/#create-a-new-saved-workspace-view) を作成して runs を整理できます。右上の **action ()** メニューをクリックし、**Save as new view** をクリックします。
たとえば、次のような保存済みビューを作成できます。
* **Default view**: worker ノードを除外してノイズを減らす
* **フィルター** をクリックし、**Job Type** を `worker` に設定します。
* レポート用ノードのみが表示されます
* **Debug view**: トラブルシューティングのために worker ノードに絞り込む
* **フィルター** をクリックし、**Job Type** を `==` `worker` に設定し、**State** を `IN` `crashed` に設定します。
* クラッシュした worker ノード、またはエラー状態の worker ノードのみが表示されます
* **All nodes view**: すべてをまとめて表示する
* フィルターなし
* 全体を監視する際に便利です
保存済みビューを開くには、プロジェクトのサイドバーで **Workspaces** をクリックし、次にメニューをクリックします。Workspaces はリストの上部に、保存済みビューは下部に表示されます。
### すべてのプロセスを単一の run にトラッキングする
`x_` 接頭辞が付いたパラメーター (`x_label` など) はパブリックプレビューです。フィードバックを提供するには、[W\&B リポジトリの GitHub issue](https://github.com/wandb/wandb) を作成してください。
**要件**
複数のプロセスを単一の run にトラッキングするには、以下が必要です。
* W\&B Python SDK バージョン `v0.19.9` 以降
* W\&B Server v0.68 以降
この方法では、プライマリノードと 1 つ以上のワーカーノードを使用します。プライマリノード内で W\&B run を初期化します。各ワーカーノードでは、プライマリノードで使用している run ID を使って run を初期化します。トレーニング中、各ワーカーノードはプライマリノードと同じ run ID にログします。W\&B はすべてのノードのメトリクスを集約し、W\&B App UI に表示します。
プライマリノードでは、[`wandb.init()`](/ja/models/ref/python/functions/init) を使って W\&B run を初期化します。`settings` パラメーターに `wandb.Settings` オブジェクト (`wandb.init(settings=wandb.Settings()`) を渡し、以下を設定します。
1. 共有モードを有効にするため、`mode` パラメーターを `"shared"` に設定します。
2. [`x_label`](https://github.com/wandb/wandb/blob/main/wandb/sdk/wandb_settings.py#L638) に一意のラベルを設定します。`x_label` に指定した値は、ログおよび W\&B App UI のシステムメトリクスで、データがどのノードから送られてきたかを識別するために使用されます。指定しない場合、W\&B はホスト名とランダムなハッシュを使ってラベルを作成します。
3. これがプライマリノードであることを示すため、[`x_primary`](https://github.com/wandb/wandb/blob/main/wandb/sdk/wandb_settings.py#L660) パラメーターを `True` に設定します。
4. 必要に応じて、W\&B がどの GPU のメトリクスをトラッキングするかを指定するため、GPU インデックスのリスト (\[0,1,2]) を `x_stats_gpu_device_ids` に指定します。リストを指定しない場合、W\&B はそのマシン上のすべての GPU のメトリクスをトラッキングします。
プライマリノードの run ID を控えておいてください。各ワーカーノードで、プライマリノードの run ID が必要になります。
`x_primary=True` は、プライマリノードとワーカーノードを区別するための設定です。設定ファイルやテレメトリーなど、ノード間で共有されるファイルを upload できるのはプライマリノードだけです。ワーカーノードはこれらのファイルを upload しません。
各ワーカーノードでは、[`wandb.init()`](/ja/models/ref/python/functions/init) で W\&B run を初期化し、以下を指定します。
1. `settings` パラメーターに `wandb.Settings` オブジェクト (`wandb.init(settings=wandb.Settings()`) を渡し、次を設定します。
* 共有モードを有効にするため、`mode` パラメーターを `"shared"` に設定します。
* `x_label` に一意のラベルを設定します。`x_label` に指定した値は、ログおよび W\&B App UI のシステムメトリクスで、データがどのノードから送られてきたかを識別するために使用されます。指定しない場合、W\&B はホスト名とランダムなハッシュを使ってラベルを作成します。
* これがワーカーノードであることを示すため、`x_primary` パラメーターを `False` に設定します。
2. プライマリノードで使用している run ID を `id` パラメーターに渡します。
3. 必要に応じて、[`x_update_finish_state`](https://github.com/wandb/wandb/blob/main/wandb/sdk/wandb_settings.py#L772) を `False` に設定します。これにより、非プライマリノードが [run の状態](/ja/models/runs/run-states#run-states) を早い段階で `finished` に更新してしまうのを防ぎ、run の状態を一貫してプライマリノードで管理できます。
* すべてのノードで同じ entity とプロジェクトを使用してください。これにより、正しい run ID を確実に見つけやすくなります。
* プライマリノードの run ID を設定するために、各ワーカーノードで環境変数を定義することを検討してください。
以下のサンプルコードは、複数のプロセスを単一の run にトラッキングするための大まかな要件を示しています。
```python theme={null}
import wandb
entity = ""
project = ""
# プライマリノードで run を初期化する
run = wandb.init(
entity=entity,
project=project,
settings=wandb.Settings(
x_label="rank_0",
mode="shared",
x_primary=True,
x_stats_gpu_device_ids=[0, 1], # (オプション) GPU 0 と 1 のメトリクスのみをトラッキングする
)
)
# プライマリノードの run ID を記録する。
# 各ワーカーノードにはこの run ID が必要。
run_id = run.id
# プライマリノードの run ID を使用してワーカーノードで run を初期化する
run = wandb.init(
entity=entity, # プライマリノードと同じ entity を使用する
project=project, # プライマリノードと同じ project を使用する
settings=wandb.Settings(x_label="rank_1", mode="shared", x_primary=False),
id=run_id,
)
# プライマリノードの run ID を使用してワーカーノードで run を初期化する
run = wandb.init(
entity=entity, # プライマリノードと同じ entity を使用する
project=project, # プライマリノードと同じ project を使用する
settings=wandb.Settings(x_label="rank_2", mode="shared", x_primary=False),
id=run_id,
)
```
実際の環境では、各ワーカーノードがそれぞれ別のマシン上にある場合があります。
GKE 上のマルチノードかつマルチ GPU の Kubernetes クラスターでモデルを
トレーニングする方法をエンドツーエンドで示した例については、[Distributed Training with Shared Mode](https://wandb.ai/dimaduev/simple-cnn-ddp/reports/Distributed-Training-with-Shared-Mode--VmlldzoxMTI0NTE1NA) report を参照してください。
run がログを送信する project で、マルチノードプロセスのコンソールログを表示するには、次の手順に従います。
1. run を含む project にアクセスします。
2. プロジェクトのサイドバーで **Runs** タブをクリックします。
3. 表示したい run をクリックします。
4. プロジェクトのサイドバーで **Logs** タブをクリックします。
コンソールログページ上部にある UI の検索バーでは、`x_label` に指定したラベルに基づいてコンソールログをフィルターできます。たとえば、次の画像は、`rank0`、`rank1`、`rank2`、`rank3`、`rank4`、`rank5`、`rank6` の各値を `x_label` に指定した場合に、コンソールログのフィルターに使用できるオプションを示しています。\`
詳細は [Console logs](/ja/models/app/console-logs/) を参照してください。
W\&B はすべてのノードのシステムメトリクスを集約し、W\&B App UI に表示します。たとえば、次の画像は、複数ノードのシステムメトリクスを含むサンプルダッシュボードを示しています。各ノードには、`x_label` パラメーターで指定する一意のラベル (`rank_0`、`rank_1`、`rank_2`) があります。
ラインプロットパネルをカスタマイズする方法については、[Line plots](/ja/models/app/features/panels/line-plot/) を参照してください。
## 使用例
以下のコードスニペットは、高度な分散処理の利用でよくあるシナリオを示しています。
### プロセスの生成
spawn されたプロセスで run を開始する場合は、メイン関数内で `wandb.setup()` method を使用します。
```python theme={null}
import multiprocessing as mp
def do_work(n):
with wandb.init(config=dict(n=n)) as run:
run.log(dict(this=n * n))
def main():
wandb.setup()
pool = mp.Pool(processes=4)
pool.map(do_work, range(4))
if __name__ == "__main__":
main()
```
### run を共有する
プロセス間で run を共有するには、run オブジェクトを引数として渡します。
```python theme={null}
def do_work(run):
with wandb.init() as run:
run.log(dict(this=1))
def main():
run = wandb.init()
p = mp.Process(target=do_work, kwargs=dict(run=run))
p.start()
p.join()
run.finish() # run を完了としてマークする
if __name__ == "__main__":
main()
```
W\&B ではログの順序は保証されません。同期はスクリプトの作成者側で行ってください。
## トラブルシューティング
W\&B と分散トレーニングを使用する際に発生しやすい一般的な問題は、主に 2 つあります。
1. **トレーニング開始時にハングする** - 分散トレーニングのマルチプロセッシングと `wandb` のマルチプロセッシングが干渉すると、`wandb` プロセスがハングすることがあります。
2. **トレーニング終了時にハングする** - `wandb` プロセスがいつ終了すべきかを認識できない場合、トレーニング ジョブがハングすることがあります。Python スクリプトの最後で `wandb.Run.finish()` API を呼び出して、run が終了したことを W\&B に通知してください。`wandb.Run.finish()` API はデータのアップロードを完了し、W\&B を終了させます。
W\&B では、分散ジョブの信頼性を向上させるために `wandb service` コマンドを使用することを推奨しています。前述の 2 つのトレーニングの問題は、wandb service を利用できないバージョンの W\&B SDK でよく見られます。
### W\&B Service を有効にする
使用している W\&B SDK のバージョンによっては、W\&B Service はデフォルトで既に有効になっている場合があります。
#### W\&B SDK 0.13.0 以降
W\&B SDK `0.13.0` 以降では、W\&B Service はデフォルトで有効です。
#### W\&B SDK 0.12.5 以降
W\&B SDK バージョン 0.12.5 以降で W\&B Service を有効にするには、Python スクリプトを修正します。メイン関数内で `wandb.require()` method を使用し、文字列 `"service"` を渡してください。
```python theme={null}
if __name__ == "__main__":
main()
def main():
wandb.require("service")
# 残りのスクリプトをここに記述
```
快適に利用するため、最新バージョンへのアップグレードをお勧めします。
**W\&B SDK 0.12.4 以下**
W\&B SDK バージョン 0.12.4 以下を使用している場合は、代わりにマルチスレッドを使用できるよう、`WANDB_START_METHOD` 環境変数を `"thread"` に設定します。
ただし、エポックとバッチサイズに対する損失値は、1基のGPUからのみログされていました。
上の画像は、W\&B App UI のダッシュボードを示しています。サイドバーには 2 つの実験が表示されています。1 つは 'null' というラベルで、もう 1 つは 'DPP' です (黄色の枠で囲まれています) 。グループを展開すると (Group ドロップダウンを選択) 、その実験に関連付けられた W\&B Runs を確認できます。