パフォーマンスは通常、次の要素が組み合わさって左右されます。
project 内の run の数
各 run のステップ数
ログする異なるメトリクスの数
wandb.Run.log() を呼び出す頻度各ログ呼び出しで送信するデータ量
Workspace の設定
ほとんどの場合、パフォーマンスの問題は、ステップを過剰にログすることよりも、異なるメトリクスを過剰にログすることによって発生します。
このページでは、以下の用語を使用します。
step は、run におけるメトリクスの 1 つの論理的な行です。wandb.Run.log() を commit=True で呼び出したとき、または commit も step も指定しない場合は暗黙的に、step が確定されます。import wandb with wandb.init() as run: run.log({ "loss" : 0.42 }, commit = True )
メトリクスのカーディナリティ とは、ネストされた辞書内のキーも含めて、project にログされた一意のメトリクスキーの数です。たとえば、次の例では a、b.c、b.d.e、b.d.f の 4 つの異なるメトリクスキーがログされます。
import wandb with wandb.init() as run: run.log( { "a" : 1 , "b" : { "c" : 2 , "d" : { "e" : 3 , "f" : 4 , }, }, } )
W&B は、ネストされた辞書をドット区切りのメトリクス名に展開します。
ログされたポイント とは、記録されたメトリクス値の総数を指します。たとえば、次のどちらのコードサンプルでも、ログされたポイントは 3 つになります。
import wandb with wandb.init() as run: run.log({ "a" : 1 , "b" : 2 , "c" : 3 })
import wandb with wandb.init() as run: run.log({ "a" : 1 }) run.log({ "a" : 2 }) run.log({ "a" : 3 })
ログ頻度 は、1 分あたりの wandb.Run.log() の呼び出し回数です。log frequency = wandb.Run.log() calls per minute
スループット は、1 分あたりに記録されるログされたポイントの総数です。スループットは、次のように考えることができます。
throughput = logged points per minute
あるいは、同様に:
throughput = logged points × log frequency
以下のセクションは W&B SaaS Cloud に適用されます。別の W&B デプロイメント タイプを使用している場合は、デプロイメント固有のガイダンスや制限について管理者に確認してください。
次の表は、大規模な logging における推奨運用範囲をまとめたものです。
Dimension Guidance at scale project あたりの Runs 数 10,000 run あたりの step 数 500,000 project あたりのメトリクス カーディナリティ 100,000 ログ頻度 1 分あたり 1,000 行 スループット 1 分あたり 100,000 値 動画スループット 1 分あたり 40 MB
これらの値は、大規模運用時に良好なパフォーマンスを維持するための目安です。W&B はこれらの推奨値を超えるデータも引き続き受け付ける場合がありますが、ページの読み込みや操作が遅くなる可能性があります。
ログの記録方法が異なっていても、同じスループットになることがあります。
1 回のログ呼び出しあたりのメトリクス数 ログ頻度 (1 分あたり) スループット (1 分あたりの値数) 100 1,000 100,000 1,000 100 100,000 10,000 10 100,000 20,000 5 100,000
動画サイズ (MB) ログ頻度 (1分あたり) 動画スループット (1分あたりのMB) 1 46 46 5 8 40 10 4 40 50 1 50 100 0.3 30 250 0.1 25 500 0.07 35
実験のメトリクスをトラッキングするには、wandb.Run.log() を使用します。
project 内のメトリクスの総カーディナリティ (異なるメトリクスの数) は、ワークロードに応じた推奨範囲内に収めてください。メトリクスのカーディナリティが高いことは、Workspace の動作が遅くなる最も一般的な原因の 1 つです。
パフォーマンスの問題は、ステップを多くログしすぎることではなく、異なるメトリクスを多くログしすぎることが原因である場合がよくあります。
W&B ではネストされたキーがドット区切りのメトリクス名にフラット化されるため、メトリクスのカーディナリティは想定以上に増えることがあります。
たとえば、次の例では a、b.c、b.d という 3 つの異なるメトリクスキーをログします。
import wandb with wandb.init() as run: run.log( { "a" : 1 , "b" : { "c" : "hello" , "d" : [ 1 , 2 , 3 ], }, } )
Workspace の動作が突然遅くなった場合は、最近の run で多数の新しいメトリクスキーが追加されていないか確認してください。これは、多くのプロットで 1 つまたは 2 つの run しか表示されない状態として現れることがよくあります。意図せずこの状態になった場合は、メトリクス名の数を減らして安定させたうえで、それらの run を削除して再作成することを検討してください。
1 つのログ値のサイズは 1 MB 未満、1 回の wandb.Run.log() 呼び出しの合計サイズは 25 MB 未満にしてください。
これらの推奨事項は、wandb.Image や wandb.Audio などの wandb.Media タイプには当てはまりません。これらは別の方法で処理されます。
import json import wandb with wandb.init( project = "wide-values" ) as run: # 非推奨 run.log({ "wide_key" : list ( range ( 10000000 ))}) # 非推奨 with open ( "large_file.json" , "r" ) as f: large_data = json.load(f) run.log(large_data)
大きな値があると、その値を含むメトリクスだけでなく、run 全体のプロットの読み込みが遅くなる可能性があります。
W&B では、これらの推奨値を超えるデータも引き続きログして保存されますが、ページの読み込みが遅くなる場合があります。
収集しているデータの価値に応じたログ頻度を選択してください。ログの頻度が高すぎると SDK のオーバーヘッドが増え、特にメトリクスのカーディナリティが高い場合やペイロードが大きい場合には、アプリの動作が遅くなることがあります。
まずは、ログを次のガイドラインの範囲内に収めることを推奨します。
ログ頻度: 1 分あたり 1,000 回未満の wandb.Run.log() 呼び出し
スループット: 1 分あたり 100,000 未満のログ値
動画スループット: 1 分あたり 40 MB 未満
可能であれば、関連するメトリクスは同じ step にまとめてください。たとえば、次のコード スニペットでは 3 つのメトリクスを同じ step でログしており、個別にログするよりも効率的です。
import wandb with wandb.init( project = "metric-frequency" ) as run: # 推奨: 関連するスカラーメトリクスをまとめてログする run.log( { "loss" : 0.12 , "accuracy" : 0.98 , "lr" : 1e-4 , }, commit = True , )
run 設定 の合計サイズは 10 MB 未満に抑えてください。
大きな設定は、プロジェクトのWorkspaceやRuns tableでの操作を遅くする可能性があります。
import json import wandb # 推奨 with wandb.init( project = "config-size" , config = { "lr" : 0.1 , "batch_size" : 32 , "epochs" : 4 , }, ) as run: pass # 非推奨 with wandb.init( project = "config-size" , config = { "large_list" : list ( range ( 10000000 )), "large_string" : "a" * 10000000 , }, ) as run: pass # 非推奨 with open ( "large_config.json" , "r" ) as f: large_config = json.load(f) wandb.init( config = large_config)
Workspace のパフォーマンスは、基盤となる project のデータと Workspace の設定の両方に左右されます。
大規模な project では、最適なパフォーマンスを得るため、1 つの project 内の Runs 数を 10,000 未満に保ってください。
チームで日常的に Runs の一部のみを使用する場合は、古い Runs や使用頻度の低い Runs を別のアーカイブ用 project に移すことを検討してください。Runs の管理 を参照してください。
デフォルトでは、自動モードのWorkspaceでは、ログされた各キーに対して標準パネルが作成されます。大規模なProjectsでは、これによってパネル数が多くなりすぎ、Workspaceの動作が遅くなることがあります。
パフォーマンスを改善するには:
Workspaceを手動モードにリセットします。
Quick add を使用して、必要なパネルだけを追加します。
未使用のパネルを1つずつ削除しても、通常はほとんど効果がありません。Workspaceをリセットして、必要なパネルだけを追加し直してください。
詳しくは、Panels を参照してください。
Workspace に何百ものセクションがあると、パフォーマンスに悪影響が出ることがあります。
メトリクスごとに 1 つのセクションを作成するのではなく、メトリクスを大まかなグループ単位でまとめてセクションを作成してください。セクションが多すぎる場合は、接尾辞ではなく接頭辞でセクションを作成することを検討してください。これにより、関連するメトリクスをより少ないセクションにまとめられます。
1 run あたり数千件のメトリクスをログする場合は、可視化するメトリクスを選択できるように、手動 Workspace を使用してください。
表示するパネルを絞り込むと、読み込みが速くなります。プロットしていないメトリクスも、通常どおり収集・保存されます。
Workspace を手動モードにリセットするには、Workspace の アクション ( メニューをクリックし、次に Workspace をリセット をクリックします。Workspace をリセットしても、run に保存済みのメトリクスには影響しません。Workspace パネル管理 を参照してください。
1 回の run でアップロードするファイル数は、1,000 未満にしてください。
多数のファイルをログする必要がある場合は、代わりに W&B Artifacts を使用してください。1 回の run で 1,000 ファイルを超えると、run ページの表示が遅くなることがあります。
report は、共有やプレゼンテーションに適しています。Workspace は、多数の Runs とメトリクスをまたいで高密度かつ対話的に分析するためのものです。
大量の Runs を比較する必要がある場合や、多数の plot をまとめて確認したい場合は、Workspace を使用します。厳選した結果を提示したい場合は、report を使用します。
ログ記録は、トレーニング スクリプトにオーバーヘッドを生じさせることがあります。主な要因は次のとおりです。
大きなペイロード
ネットワーク速度とバックエンドの設定
wandb.Run.log() の非常に高頻度な呼び出し
wandb.Run.log() の呼び出し頻度が高すぎると、呼び出しのたびにトレーニング ループへわずかな遅延が加わることがあります。複数のメトリクスをまとめてログし、呼び出し回数を減らすことで、通常はパフォーマンスが向上します。頻繁なログ記録によってトレーニング runs が遅くなっていませんか？ログ パターンを調整してパフォーマンスを改善する方法については、この Colab を参照してください。 W&B は、API のレート制限を除き、これらの推奨事項に関してプロダクト上の厳格な制限を設けていません。このページのガイダンスを超えた場合でも、W&B は引き続きデータを受け付けることがありますが、アプリまたは SDK の動作が遅くなる可能性があります。
W&B SaaS Cloud API では、サービスの信頼性と可用性を維持するためにレート制限を設けています。
レート制限に達すると、サーバーは HTTP 429 Rate limit exceeded を返し、レスポンスにはレート制限ヘッダーが含まれます。
ヘッダー名 説明 RateLimit-Limit現在の時間ウィンドウで利用可能なクォータ量。値は 0～1000 の範囲にスケーリングされます RateLimit-Remaining現在のウィンドウ内で残っているクォータ量。値は 0～1000 の範囲にスケーリングされます RateLimit-Reset現在のクォータがリセットされるまでの秒数
wandb.Run.log() は、トレーニング データを W&B に送信します。オンラインで直接送信することも、offline syncing を使用して後で送信することもできます。メトリクス logging のレート制限は project レベルで適用され、一定時間のローリング ウィンドウ内でのリクエスト レートとリクエスト総サイズの両方が対象になります。有料プランは無料プランより高い制限が設定されています。
レート制限を超えると、W&B SDK はバックオフを使用して自動的にリクエストを再試行します。場合によっては、レート制限のウィンドウがリセットされるまで run.finish() が遅延することがあります。
レート制限に達する可能性を減らすには:
最新版の W&B SDK を使用してください。
logging の頻度を下げてください。
関連するメトリクスをまとめて、log の Call 回数を減らしてください。
必要に応じてオフラインでログし、後で同期してください。
import random import wandb with wandb.init( project = "basic-intro" ) as run: for epoch in range ( 10 ): accuracy = 1 - 2 ** - epoch - random.random() / (epoch + 1 ) loss = 2 ** - epoch + random.random() / (epoch + 1 ) if epoch % 5 == 0 : run.log({ "acc" : accuracy, "loss" : loss})
手動で同期するには、wandb sync <run-file-path> を使用してください。wandb sync
W&B App と Public API は、GraphQL リクエストを使用してデータをクエリおよび変更します。
SaaS Cloud の場合:
未認証のリクエストは、IP アドレスごとにレート制限されます
認証済みのリクエストは、ユーザーごとにレート制限されます
project パスを指定する一部の SDK リクエストは、データベースのクエリ時間に応じて、project ごとに制限されることもあります
Teams および Enterprise プランは、Free プランより高い制限が設定されています。
多数の Public API リクエストを送信する場合は、可能であればリクエストの間隔を少なくとも 1 秒空けてください。HTTP 429 Rate limit exceeded を受け取った場合、または RateLimit-Remaining=0 が表示された場合は、RateLimit-Reset に示された秒数だけ待ってから再試行してください。
動作が遅い project のトラブルシューティング project または Workspace の動作が遅いと感じる場合は、まず次の点を確認してください。
最近の run で、新しいメトリクス名が大量に追加されていませんか？
ログする頻度が高すぎませんか？
個々の run.log() Call が非常に大きくありませんか？
Workspace が自動モードになっていて、パネルやセクションが多すぎませんか？
project に、チームが実際に使用している以上の run が含まれていませんか？
多くの場合、メトリクスのカーディナリティを減らし、ログの Call をバッチ化し、大規模な Workspace を手動モードに切り替えることで、パフォーマンスは改善します。
W&B App はメモリ消費が大きくなりやすく、Chrome で最も快適に動作します。お使いのコンピュータのメモリ容量によっては、W&B を 3 つ以上のタブで同時に開いていると、パフォーマンスが低下することがあります。動作が予想以上に遅い場合は、他のタブやアプリケーションを閉じることを検討してください。
W&B はパフォーマンスを重視しており、動作の遅さに関するすべての報告を調査しています。調査を迅速に進めるため、読み込み時間が遅いことを報告する際は、主要なメトリクスとパフォーマンスイベントを記録できる W&B 組み込みのパフォーマンスロガーを有効にすることを検討してください。読み込みが遅いページの URL にパラメーター &PERF_LOGGING を追加し、その後、コンソールの出力をアカウント担当チームまたはサポートに共有してください。
