W&B 上のページを高速で応答性の高い状態に保つために、以下の推奨範囲内に収まるようログを記録してください。
実験のメトリクスを記録・追跡するには wandb.Run.log() を使用します。
パフォーマンスを向上させるには、1つのプロジェクトで使用するメトリクスの種類を合計で 10,000 未満に抑えてください。
import wandb
with wandb.init() as run:
run.log(
{
"a": 1, # "a" は個別のメトリクス
"b": {
"c": "hello", # "b.c" は個別のメトリクス
"d": [1, 2, 3], # "b.d" は個別のメトリクス
},
}
)
W&B はネストされた値を自動的にフラット化します。つまり、辞書を渡すと、W&B はそれをドット区切りの名前に変換します。config の値では、名前に含められるドットは最大 3 個までです。summary の値では、ドットは最大 4 個までサポートされます。
wandb.Run.log() の 1 回の呼び出しあたりの合計サイズは 25 MB 未満にしてください。この制限は、wandb.Image や wandb.Audio などの wandb.Media 型には適用されません。
import wandb
with wandb.init(project="wide-values") as run:
# 非推奨
run.log({"wide_key": range(10000000)})
# 非推奨
with open("large_file.json", "r") as f:
large_data = json.load(f)
run.log(large_data)
推奨される範囲を超える値をログしても、データは保存および追跡されます。ただし、プロットの読み込みが遅くなる場合があります。
- スカラー: メトリクスごとに 100,000 ポイント未満
- メディア: メトリクスごとに 50,000 ポイント未満
- ヒストグラム: メトリクスごとに 10,000 ポイント未満
import wandb
with wandb.init(project="metric-frequency") as run:
# 非推奨
run.log(
{
"scalar": 1, # 100,000 スカラー
"media": wandb.Image(...), # 100,000 画像
"histogram": wandb.Histogram(...), # 100,000 ヒストグラム
}
)
# 推奨
run.log(
{
"scalar": 1, # 100,000 スカラー
},
commit=True,
) # バッチ化されたステップごとのメトリクスをまとめてコミット
run.log(
{
"media": wandb.Image(...), # 50,000 画像
},
commit=False,
)
run.log(
{
"histogram": wandb.Histogram(...), # 10,000 ヒストグラム
},
commit=False,
)
ガイドラインを超過した場合でも、W&B はログしたデータを引き続き受け付けますが、ページの読み込みが遅くなる場合があります。
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)
- SaaS Cloud では 100,000 件
- Dedicated Cloud または Self-Managed では 10,000 件
run 数がこれらのしきい値を超えると、プロジェクトの Workspace や Runs テーブルに関わる操作が遅くなる可能性があります。特に run をグループ化している場合や、run 中に多数の異なるメトリクスを収集している場合に顕著です。あわせて、メトリクス数 のセクションも参照してください。
チームが同じ run セット（たとえば直近の run セットなど）に頻繁にアクセスする場合は、あまり使用しない run をまとめて移動する ことで、新しい「archive」プロジェクトに移し、作業用プロジェクトには少数の run だけを残すことを検討してください。
このセクションでは、ワークスペースのパフォーマンスを最適化するためのヒントを紹介します。
デフォルトでは、ワークスペースは 自動 モードで動作し、ログされた各キーに対して標準パネルを生成します。大規模なプロジェクトのワークスペースに多数のログ済みキーのパネルが含まれている場合、ワークスペースの読み込みや操作が遅くなることがあります。パフォーマンスを改善するには、次のようにします。
- ワークスペースを手動モードにリセットします（この場合、デフォルトではパネルは含まれません）。
- 必要なログ済みキーだけを可視化できるようにするため、Quick add を使って、必要なパネルのみを追加します。
未使用のパネルを 1 つずつ削除しても、パフォーマンスの改善効果はほとんどありません。代わりに、ワークスペースをリセットして、必要なパネルだけを選択的に追加し直してください。
... メニューをクリックし、Reset workspace をクリックします。ワークスペースをリセットしても、run に保存されているメトリクスには影響しません。詳しくは workspace panel management を参照してください。
1 つの run にアップロードするファイルの総数は 1,000 個未満にしてください。大量のファイルを記録する必要がある場合は、W&B Artifacts を使用してください。1 つの run で 1,000 個を超えるファイルを扱うと、run ページの表示が遅くなる可能性があります。
レポートは、パネル、テキスト、メディアを任意に配置して自由形式で構成でき、同僚とインサイトを簡単に共有できます。
これに対して、ワークスペースは、数十から数千のメトリクスを、数百から数十万の run にわたって高密度かつ高性能に分析できます。Reports と比較して、Workspaces ではキャッシュ、クエリ、読み込み機能が最適化されています。Workspaces は、プレゼンテーション用途よりも分析用途が主となるプロジェクトや、20 個以上のプロットをまとめて表示する必要がある場合に推奨されます。
Python スクリプトのパフォーマンスが低下する主な要因はいくつかあります。
- データサイズが大きすぎる。データサイズが大きいと、学習ループに 1 ms を超えるオーバーヘッドが発生する可能性があります。
- ネットワーク速度と、W&B のバックエンド構成
- 1 秒間に数回以上
wandb.Run.log() を呼び出している場合。これは、wandb.Run.log() が呼び出されるたびに、学習ループにわずかなレイテンシが追加されるためです。
頻繁なロギングが学習 run の速度低下の原因になっていませんか？ロギング戦略を変更してパフォーマンスを向上させる方法については、この Colab を確認してください。 429 Rate limit exceeded エラーが返され、レスポンスにはレート制限 HTTP ヘッダーが含まれます。
上の表では、レート制限に関する HTTP ヘッダーを説明しています。
| Header name | Description |
|---|
| RateLimit-Limit | 各時間ウィンドウで利用可能なクォータ量。0 から 1000 の範囲でスケーリングされます |
| RateLimit-Remaining | 現在のレート制限ウィンドウ内で残っているクォータ量。0 から 1000 の範囲でスケーリングされます |
| RateLimit-Reset | 現在のクォータがリセットされるまでの秒数 |
wandb.Run.log() は学習データを W&B にログとして記録します。この API はオンライン実行時または オフライン同期 を通じて利用されます。どちらの場合も、一定の時間幅（スライディングウィンドウ）に基づくレート制限のクオータが課されています。これには、リクエスト全体のサイズとリクエストレートに対する制限が含まれます。ここでリクエストレートとは、一定時間内に送信されるリクエスト数を指します。
W&B はレート制限を W&B の各プロジェクトごとに適用します。そのため、チーム内に 3 つのプロジェクトがある場合、それぞれのプロジェクトが独自のレート制限クオータを持ちます。有料プラン のユーザーには、無料プランよりも高いレート制限が設定されています。
レート制限に達した場合、HTTP 429 Rate limit exceeded エラーが返され、レスポンスにはレート制限 HTTP ヘッダーが含まれます。
メトリクスロギング API のレート制限内に収めるための推奨事項
run.finish() が遅延する可能性があります。これを避けるために、次のような対処方法を検討してください。
- W&B Python SDK のバージョンを更新する: 最新バージョンの W&B Python SDK を使用していることを確認してください。W&B Python SDK は定期的に更新されており、リクエストの優雅な再試行やクォータ使用量の最適化のための仕組みが強化されています。
- メトリクスのロギング頻度を減らす:
クォータを節約するために、メトリクスを記録する頻度をできるだけ抑えてください。たとえば、毎エポックではなく 5 エポックごとにメトリクスをロギングするようにコードを変更できます。
import wandb
import random
with wandb.init(project="basic-intro") as run:
for epoch in range(10):
# 学習と評価をシミュレート
accuracy = 1 - 2 ** -epoch - random.random() / epoch
loss = 2 ** -epoch + random.random() / epoch
# 5エポックごとにメトリクスを記録
if epoch % 5 == 0:
run.log({"acc": accuracy, "loss": loss})
- 手動でのデータ同期: レート制限に達した場合、W&B は run データをローカルに保存します。
wandb sync <run-file-path> コマンドを使用して、データを手動で同期できます。詳細については、wandb sync のリファレンスを参照してください。
W&B Models UI と SDK の public API は、データのクエリおよび変更のために GraphQL リクエストをサーバーに送信します。SaaS Cloud におけるすべての GraphQL リクエストに対して、W&B は認証されていないリクエストには IP アドレスごとに、認証済みのリクエストにはユーザーごとにレート制限を適用します。制限は固定された時間ウィンドウ内のリクエストレート（1 秒あたりのリクエスト数）に基づき、デフォルトの上限は契約している料金プランによって決まります。プロジェクトパスを指定する関連 SDK リクエスト（たとえば reports、runs、artifacts）の場合、W&B はデータベースクエリ時間を基準としてプロジェクトごとにレート制限を適用します。
Teams と Enterprise プラン の Users は、Free プランのユーザーよりも高いレート制限の上限が適用されます。
W&B Models SDK の public API を使用中にレート制限に達した場合、標準出力にエラー内容を示すメッセージが表示されます。
レート制限に達すると、HTTP 429 Rate limit exceeded エラーを受け取り、レスポンスにはレート制限に関する HTTP ヘッダーが含まれます。
GraphQL API のレート制限を超えないようにするための推奨事項
429 Rate limit exceeded エラーを受け取った場合、またはレスポンスヘッダーに RateLimit-Remaining=0 と表示されている場合は、RateLimit-Reset で指定された秒数だけ待機してから再試行してください。
W&B アプリはメモリ使用量が多く、Chrome で最も高いパフォーマンスを発揮します。PC に搭載されているメモリ容量によっては、W&B を同時に 3 つ以上のタブで開いていると、パフォーマンスが低下することがあります。想定よりも動作が遅いと感じた場合は、他のタブやアプリケーションを閉じることを検討してください。
W&B はパフォーマンスを重視しており、遅延に関するすべてのレポートを調査します。調査を迅速に進めるため、読み込みが遅いページで W&B にパフォーマンス問題を報告する際は、主要なメトリクスとパフォーマンスイベントを記録する W&B の組み込みパフォーマンスロガーを有効化してから報告するようにしてください。読み込みが遅いページの URL にパラメータ &PERF_LOGGING を追加し、その後コンソールの出力をアカウントチームまたは Support と共有してください。
プラットフォーム
W&B Models
W&B Weave
W&B 推論
W&B 学習
リリースノート
