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