- project 内の run の数
- 各 run のステップの数
- ログする一意なメトリクスの数
wandb.Run.log()を呼び出す頻度- 各ログ呼び出しで送信するデータ量
- Workspace の設定方法
Key terms
このページでは、以下の用語を使用します。ステップ
ステップ は、run 内のメトリクスの単一の論理行です。ステップは、commit=True を指定して wandb.Run.log() を呼び出すと確定します。また、commit も step も指定しない場合は暗黙的に確定します。
メトリクスのカーディナリティ
メトリクスのカーディナリティは、project にログされた一意のメトリクスキーの数で、ネストされた辞書内のキーも含みます。 例えば、以下では4つの一意のメトリクスキーa、b.c、b.d.e、b.d.f をログします。
ログされたポイント
ログされたポイントは、記録されたメトリクス値の総数です。 例えば、以下のコード例はいずれも 3 つのログされたポイントを生成します:ログ頻度
ログ頻度は、1 分あたりのwandb.Run.log() の Call 回数です。
スループット
スループットは、1 分あたりにログされたポイントの総数です。 スループットは、次のように考えることができます。大規模での推奨事項
次の表は、大規模にログする際の推奨動作範囲をまとめたものです。これらの値は、大規模で良好なパフォーマンスを維持するためのガイドラインです。W&B はこれらの推奨事項を超えてデータを受け入れる場合がありますが、ページの読み込みと使用が遅くなる可能性があります。
スループットのサンプル
ログするパターンが異なっていても、スループットが同じになる場合があります。スカラー値をログするサンプル
動画をログするサンプル
ログする際の考慮事項
wandb.Run.log() を使用して実験のメトリクスをトラッキングします。
メトリクスのカーディナリティ
project 内のメトリクスの総カーディナリティ (一意のメトリクス数) を、ワークロードに推奨される範囲内に収めてください。メトリクスのカーディナリティが高いことは、Workspace が遅くなる最も一般的な原因の一つです。 W&B はネストされたキーをドット区切りのメトリクス名に展開するため、メトリクスのカーディナリティが想定以上に増えることがあります。 たとえば、以下ではa、b.c、b.d という3つの一意のメトリクスキーをログします。
値のサイズ
ログする単一の値のサイズは 1 MB 未満に、1 回のwandb.Run.log() 呼び出しの合計サイズは 25 MB 未満に抑えてください。
これらの推奨事項は、処理方法が異なる wandb.Image や wandb.Audio などの wandb.Media タイプには適用されません。
W&B は、これらの推奨値を超えるログしたデータも保存しますが、ページの読み込みが遅くなる場合があります。
ログ頻度とスループット
収集するデータの価値に見合ったログ頻度を選択してください。ログする頻度が高すぎると、SDK のオーバーヘッドが増え、アプリの動作が遅くなることがあります。特に、メトリクスのカーディナリティが高い場合やペイロードが大きい場合に影響が大きくなります。 まずは、次のガイドラインの範囲内でログしてください。- ログ頻度: 1 分あたりの
wandb.Run.log()Call が 1,000 回未満 - スループット: 1 分あたりのログされた値が 100,000 個未満
- 動画スループット: 1 分あたり 40 MB 未満
設定サイズ
run 設定の合計サイズを 10 MB 未満に保ってください。 大規模な設定は、プロジェクトの Workspace や run テーブルの操作を遅くする可能性があります。Workspace パフォーマンス
Workspace のパフォーマンスは、基盤となる project データと Workspace の設定の両方に依存します。project あたりの run 数
大規模な project で最適なパフォーマンスを得るには、project 内の run 数を 10,000 未満に保ってください。 チームが普段、一部の run のみを使用している場合は、古い run や使用頻度の低い run を別のアーカイブ用 project に移動することを検討してください。run の管理を参照してください。パネル数
デフォルトでは、自動モードの Workspace はログされた各 key に対して標準的なパネルを作成します。大規模な project では、これによりパネルが多すぎて Workspace が遅くなることがあります。 パフォーマンスを改善するには:- Workspace を手動モードにリセットします。
- 必要なパネルのみを追加するために Quick add を使用します。
使用していないパネルを1つずつ削除しても、通常はほとんど効果がありません。Workspace をリセットして、必要なパネルだけを追加し直してください。
セクション数
Workspace 内のセクションが数百に及ぶと、パフォーマンスが低下する可能性があります。 メトリクスごとに 1 つずつセクションを作成するのではなく、高レベルのメトリクスグループに基づいてセクションを作成してください。セクションが多すぎる場合は、接尾辞ではなく接頭辞に基づいてセクションを作成することを検討してください。そうすることで、関連するメトリクスをより少ないセクションにまとめられます。
run あたりの多数のメトリクス
run あたり数千のメトリクスをログする場合、手動の Workspace を使用して、視覚化するメトリクスを選択できます。 フォーカスされたパネルのセットは読み込みが高速です。プロットされていないメトリクスも収集および保存されます。 Workspace を手動モードにリセットするには、Workspace の action () メニューをクリックし、Reset workspace をクリックします。Workspace のリセットは、run の保存済みメトリクスに影響しません。Workspace パネル管理 を参照してください。ファイル数
単一の run にアップロードするファイル数は 1,000 未満に抑えてください。 大量のファイルをログする必要がある場合は、代わりに W&B Artifacts を使用してください。単一の run のファイル数が 1,000 を超えると、Run page の表示が遅くなることがあります。Reports とワークスペース
report は情報共有とプレゼンテーションのために設計されています。ワークスペースは、多数の run とメトリクスを対象に、情報密度の高い対話的な分析を行うために設計されています。 多数の run を比較したり、多くのグラフをまとめて表示したりする必要がある場合は、ワークスペースを使用します。厳選した結果を提示する場合は、report を使用します。Python スクリプトのパフォーマンス
ログすると、トレーニングスクリプトにオーバーヘッドが発生する可能性があります。主な要因は次のとおりです:- 大きなペイロード
- ネットワーク速度とバックエンドの設定
wandb.Run.log()への非常に頻繁な Call
wandb.Run.log() を呼び出しすぎると、各 Call がトレーニングループにわずかなレイテンシーを追加する可能性があります。複数のメトリクスをバッチ処理してログする Call を減らすと、通常パフォーマンスが向上します。
頻繁なログがトレーニング run を遅くしていますか?ログのパターンを調整してパフォーマンスを向上させる戦略については、この Colab を参照してください。
レート制限
W&B Multi-tenant Cloud の API では、サービスの信頼性と可用性を維持するためにレート制限を使用しています。レート制限は変更される場合があります。
429 Rate limit exceeded を返し、応答にレート制限ヘッダーを含めます。
レート制限の HTTP ヘッダー
メトリクスをログする API のレート制限
wandb.Run.log() は、オンラインで直接、または後からオフライン同期を通じて、トレーニングデータを W&B に送信します。
メトリクスをログする際のレート制限は project 単位で適用され、ローリング時間ウィンドウ内のリクエスト頻度とリクエストの合計サイズの両方が対象となります。有料プランの制限は無料プランよりも高く設定されています。
レート制限を超えると、W&B SDK はバックオフを使用してリクエストを自動的に再試行します。場合によっては、レート制限のウィンドウがリセットされるまで run.finish() が遅延することがあります。
レート制限に達する可能性を減らすには、次の対策を行ってください。
- 最新バージョンの W&B SDK を使用します。
- ログする頻度を減らします。
- 関連するメトリクスをバッチにまとめ、ログする Call の回数を減らします。
- 必要に応じてオフラインでログし、後から同期します。
wandb sync <run-file-path> を使用します。wandb sync を参照してください。
GraphQL API のレート制限
W&B アプリと Public API は、GraphQL リクエストを使用してデータをクエリしたり変更したりします。 Multi-tenant Cloud では、以下の制限が適用されます。- 未認証のリクエストは、IP アドレスごとにレート制限されます
- 認証済みのリクエストは、ユーザーごとにレート制限されます
- プロジェクトパスを指定する一部の SDK リクエストは、データベースのクエリ時間に基づいて project ごとに制限される場合もあります
429 Rate limit exceeded を受信した場合、または RateLimit-Remaining=0 が表示された場合は、RateLimit-Reset に指定された秒数だけ待ってから再試行してください。
動作が遅い project のトラブルシューティング
project や Workspace の動作が遅いと感じる場合は、まず次の点を確認してください。- 最近の run で多数の新しいメトリクス名が追加されましたか?
- ログする頻度が高すぎませんか?
- 個々の
run.log()Call のデータ量が非常に大きくありませんか? - Workspace が自動モードで、パネルやセクションが多すぎませんか?
- project に、チームが実際に使用する数を超える run が含まれていませんか?
ブラウザーに関する考慮事項
W&B アプリはメモリを大量に使用する場合があり、Chrome で最も高いパフォーマンスを発揮します。コンピューターのメモリ容量によっては、3 つ以上のタブで W&B を同時に使用すると、パフォーマンスが低下することがあります。予想以上に動作が遅い場合は、他のタブやアプリケーションを閉じることを検討してください。パフォーマンスの問題を W&B に報告する
W&B はパフォーマンスを重視し、遅延に関するすべての報告を調査します。調査を迅速に進めるため、読み込みの遅さを報告する際は、主要なメトリクスとパフォーマンスイベントを取得する W&B の組み込みパフォーマンスロガーの使用をご検討ください。読み込みが遅いページの URL にパラメーター&PERF_LOGGING を追加し、コンソールの出力をアカウント担当チームまたはサポートチームに共有してください。
