メインコンテンツへスキップ
wandb.init()resume パラメーターを設定して、run が停止またはクラッシュした場合に W&B がどのように処理するかを指定します。run を初期化すると、W&B は run ID がすでに存在するかどうかを確認し、resume の値で定義された動作を適用します。 次の表は、resume パラメーターに渡す引数と、run ID の有無に応じた W&B の動作を示しています。
autoallow の使い分けW&B では、resume="allow" を使用し、再開したい特定の run ID を指定することを推奨しています。resume="auto" オプションでは run ID を指定する必要はありませんが、同じディレクトリで複数の run が失敗した場合や、ファイルのディレクトリ構造が変更された場合に、予期しない動作につながる可能性があります。また、resume="auto" を使用する場合は、失敗したプロセスと同じディレクトリから run を再起動する必要があります。
以下のすべての例では、<> で囲まれた値を実際の値に置き換えてください。

同じ run ID を使用して再開する必要がある run を再開する

run が停止、クラッシュ、または失敗した場合は、同じ run ID を使用して再開できます。これを行うには、run を初期化し、次を指定します。
  • resume パラメーターを "must" に設定します (resume="must")
  • 停止またはクラッシュした run の run ID を指定します
次のコードスニペットは、W&B Python SDK でこれを実現する方法を示しています。
複数のプロセスが同じ id を同時に使用すると、予期しない結果が発生します。複数のプロセスを管理する方法の詳細については、分散トレーニングの実験をログする を参照してください。

既存の run を上書きせずに run を再開する

既存の run を上書きせずに、停止またはクラッシュした run を再開できます。これは、プロセスが正常に終了しない場合に特に便利です。次回 W&B を起動すると、W&B は最後のステップからログを開始します。 W&B で run を初期化するときに、resume パラメーターを "allow" (resume="allow") に設定します。停止またはクラッシュした run の run ID を指定してください。次のコード例は、W&B Python SDK でこれを実現する方法を示しています。

Runs の自動再開を有効にする

次のコードスニペットは、Python SDK または環境変数を使用して、Runs の自動再開を有効にする方法を示しています。
run を初期化するときに、resume パラメーターの引数として auto を渡します。失敗したプロセスと同じディレクトリから run を再起動してください。次のコードスニペットをコピー&ペーストし、<> で囲まれた値をご自身の値に置き換えてください。
自動再開が機能するのは、失敗したプロセスと同じファイルシステム上でプロセスを再起動した場合のみです。
たとえば、Users/AwesomeEmployee/Desktop/ImageClassify/training/ というディレクトリで train.py という Python スクリプトを実行するとします。train.py 内では、自動再開を有効にした run が作成されます。その後、トレーニングスクリプトが停止したとします。この run を再開するには、Users/AwesomeEmployee/Desktop/ImageClassify/training/ 内で train.py スクリプトを再起動する必要があります。
ファイルシステムを共有できない場合は、WANDB_RUN_ID 環境変数を指定するか、W&B Python SDK で run ID を渡してください。run ID の詳細については、「What are runs?」ページの Custom run IDs セクションを参照してください。

プリエンプト可能な Sweeps の run を再開する

プリエンプションを正しく処理すると、中断された sweep run は自動的にキューに入れ直され、別のエージェントが引き継げるようになります。このパターンは、sweep エージェントをプリエンプト可能な環境で実行している場合に特に有効です。たとえば、プリエンプト可能なキュー上の SLURM ジョブ、EC2 Spot インスタンス、Google Cloud のプリエンプト可能 VM などが該当します。 以下の動作は、wandb agent CLI を使用して sweep エージェントを実行し、トレーニングプログラムを サブプロセス として起動する場合に適用されます。Python API の wandb.agent() だけを使用する場合は、完全には当てはまりません。この経路では、トレーニング関数は別プロセスではなくスレッド内で実行されるため、OS シグナルの配信や転送のされ方が CLI エージェントのモデルとは一致しないためです。 推奨パターン: スケジューラーまたはプラットフォームで使用されるプリエンプションシグナル (たとえば SIGUSR1SIGTERM) に対するシグナルハンドラーを登録します。ハンドラー内では、run がアクティブであれば mark_preempting() を呼び出し、必要なクリーンアップ (チェックポイントの保存など) を行ってから、非ゼロのコードで終了してください (一般的な慣例として、シグナルによる終了では 128 + signum が使われます) 。wandb.init() の直後に、無条件で mark_preempting() を呼び出しては いけません。そうすると、コードのバグを含むすべての失敗がプリエンプションとして扱われ、run が繰り返しキューに入れ直される可能性があります。 実行可能な例、CLI エージェントの --forward-signals、および mark_preempting() のさまざまな使い方についての完全なリファレンス表は、Signal handling and sweep runs を参照してください。 このパターンに従うと、W&B は run の状態をおおむね次のように記録します。 Sweep エージェントは、sweep が検索アルゴリズムに基づいて新しいハイパーパラメーターの組み合わせを生成する前に、まず run キューを処理します。キューが空になると、sweep は通常のスケジューリングを再開します。