Experiments limits and performance

以下の推奨範囲内でログを記録することで、W&B 内のページをより高速かつ応答性の高い状態に保つことができます。

ログ記録に関する考慮事項

wandb.log を使用して実験 メトリクス を追跡します。記録された メトリクス は、グラフを生成し、 テーブル に表示されます。ログに記録するデータが多すぎると、アプリケーションの動作が遅くなる可能性があります。

個別のメトリクス数

パフォーマンスを向上させるには、 プロジェクト 内の個別の メトリクス の合計数を 10,000 未満に抑えてください。

import wandb

wandb.log(
    {
        "a": 1,  # "a" は個別のメトリクス
        "b": {
            "c": "hello",  # "b.c" は個別のメトリクス
            "d": [1, 2, 3],  # "b.d" は個別のメトリクス
        },
    }
)

ワークスペース の動作が突然遅くなった場合は、最近の runs が意図せずに数千もの新しい メトリクス を記録していないか確認してください。（これは、数千ものプロットがあるセクションで、表示されている run が 1 つまたは 2 つしかないことで簡単に見つけることができます。）記録されている場合は、それらの runs を削除し、目的の メトリクス で再作成することを検討してください。

値 の幅

ログに記録する単一の 値 のサイズを 1 MB 未満に、単一の wandb.log 呼び出しの合計サイズを 25 MB 未満に制限します。この制限は、wandb.Image、wandb.Audio などの wandb.Media タイプには適用されません。

# ❌ 推奨されません
wandb.log({"wide_key": range(10000000)})

# ❌ 推奨されません
with f as open("large_file.json", "r"):
    large_data = json.load(f)
    wandb.log(large_data)

幅の広い 値 は、幅の広い 値 を持つ メトリクス だけでなく、run 内のすべての メトリクス のプロットの読み込み時間に影響を与える可能性があります。

メトリクス の頻度

ログに記録する メトリクス に適切なログ記録頻度を選択してください。一般的な経験則として、 メトリクス の幅が広いほど、ログに記録する頻度を低くする必要があります。W&B は以下を推奨します。

• スカラー: メトリクス ごとに <100,000 ログポイント
• メディア: メトリクス ごとに <50,000 ログポイント
• ヒストグラム: メトリクス ごとに <10,000 ログポイント

# 合計 100 万ステップのトレーニングループ
for step in range(1000000):
    # ❌ 推奨されません
    wandb.log(
        {
            "scalar": step,  # 100,000 スカラー
            "media": wandb.Image(...),  # 100,000 画像
            "histogram": wandb.Histogram(...),  # 100,000 ヒストグラム
        }
    )

    # ✅ 推奨
    if step % 1000 == 0:
        wandb.log(
            {
                "histogram": wandb.Histogram(...),  # 10,000 ヒストグラム
            },
            commit=False,
        )
    if step % 200 == 0:
        wandb.log(
            {
                "media": wandb.Image(...),  # 50,000 画像
            },
            commit=False,
        )
    if step % 100 == 0:
        wandb.log(
            {
                "scalar": step,  # 100,000 スカラー
            },
            commit=True,
        )  # バッチ処理されたステップごとのメトリクスをまとめてコミット

Config サイズ

run config の合計サイズを 10 MB 未満に制限します。大きい 値 をログに記録すると、 プロジェクト ワークスペース と runs テーブル の操作が遅くなる可能性があります。

# ✅ 推奨
wandb.init(
    config={
        "lr": 0.1,
        "batch_size": 32,
        "epochs": 4,
    }
)

# ❌ 推奨されません
wandb.init(
    config={
        "steps": range(10000000),
    }
)

# ❌ 推奨されません
with f as open("large_config.json", "r"):
    large_config = json.load(f)
    wandb.init(config=large_config)

ワークスペース に関する考慮事項

Run count

読み込み時間を短縮するには、単一の プロジェクト 内の runs の合計数を以下に抑えてください。

• SaaS Cloud で 100,000
• 専用クラウド または 自己管理 で 10,000

これらのしきい値を超える run カウントは、 プロジェクト ワークスペース または runs テーブル を含む操作、特に runs の グルーピング 時、または runs 中に多数の個別の メトリクス を収集する場合に、速度が低下する可能性があります。メトリクス 数 セクションも参照してください。

チームが頻繁に同じ runs のセット（最近の runs のセットなど）に アクセス する場合は、あまり頻繁に使用されない runs をまとめて移動することを検討して、新しい「アーカイブ」 プロジェクト に移動し、作業 プロジェクト にはより少ない runs のセットを残します。

ワークスペース のパフォーマンス

このセクションでは、 ワークスペース のパフォーマンスを最適化するためのヒントを紹介します。

パネル 数

デフォルトでは、 ワークスペース は 自動 であり、ログに記録された キー ごとに標準 パネル を生成します。大規模な プロジェクト の ワークスペース に、ログに記録された多くの キー の パネル が含まれている場合、 ワークスペース の読み込みと使用に時間がかかる場合があります。パフォーマンスを向上させるには、次のことができます。

1. ワークスペース を手動モードにリセットします。これには、デフォルトで パネル が含まれていません。
2. クイック追加 を使用して、視覚化する必要があるログに記録された キー の パネル を選択的に追加します。

ワークスペース の構成の詳細については、パネルを参照してください。

セクション 数

ワークスペース 内に数百ものセクションがあると、パフォーマンスが低下する可能性があります。 メトリクス の高レベルの グルーピング に基づいてセクションを作成し、 メトリクス ごとに 1 つのセクションというアンチパターンを避けることを検討してください。

セクションが多すぎてパフォーマンスが低下している場合は、サフィックスではなくプレフィックスでセクションを作成するように ワークスペース 設定を検討してください。これにより、セクションの数が減り、パフォーマンスが向上する可能性があります。

メトリクス 数

run あたり 5000 ～ 100,000 個の メトリクス をログに記録する場合は、W&B は手動 ワークスペースを使用することをお勧めします。手動モードでは、さまざまな メトリクス のセットを探索するために、必要に応じて パネル を簡単に追加および削除できます。より集中的なプロットのセットを使用すると、 ワークスペース の読み込みが速くなります。プロットされていない メトリクス は、通常どおり収集および保存されます。

ワークスペース を手動モードにリセットするには、 ワークスペース のアクション ... メニューをクリックし、ワークスペース のリセット をクリックします。ワークスペース をリセットしても、runs の保存された メトリクス には影響しません。ワークスペース の管理の詳細をご覧ください。

ファイル 数

単一の run でアップロードされるファイルの総数を 1,000 未満に抑えてください。多数の ファイル をログに記録する必要がある場合は、W&B Artifacts を使用できます。単一の run で 1,000 個を超える ファイル があると、run ページ の速度が低下する可能性があります。

Reports と ワークスペース

レポート は、 パネル 、テキスト、 メディア の任意の配置を自由に構成できるため、同僚と洞察を簡単に共有できます。

対照的に、 ワークスペース では、数百から数十万もの runs にわたって、数十から数千もの メトリクス を高密度かつ高性能に 分析 できます。ワークスペース には、 Reports と比較して、最適化された キャッシュ 、クエリ、および読み込み機能があります。ワークスペース は、主に プレゼンテーション ではなく 分析 に使用される プロジェクト 、または 20 個以上のプロットをまとめて表示する必要がある場合にお勧めです。

Python スクリプト のパフォーマンス

Python スクリプト のパフォーマンスが低下する原因はいくつかあります。

1. データ のサイズが大きすぎる。データ サイズが大きいと、トレーニングループに 1 ミリ秒を超えるオーバーヘッドが発生する可能性があります。
2. ネットワーク の速度と、W&B バックエンド の構成方法
3. wandb.log を 1 秒間に数回以上呼び出す。これは、wandb.log が呼び出されるたびに、トレーニングループにわずかな遅延が追加されるためです。

W&B は、レート制限を超える制限は一切主張しません。W&B Python SDK は、制限を超える要求に対して、指数関数的な「バックオフ」および「再試行」要求を自動的に完了します。W&B Python SDK は、 コマンドライン で「ネットワーク 障害 」で応答します。無償アカウントの場合、W&B は、使用量が合理的なしきい値を超える極端な場合に連絡する場合があります。

レート制限

W&B SaaS Cloud API は、システムの整合性を維持し、可用性を確保するために、レート制限を実装しています。この対策により、単一の ユーザー が共有 インフラストラクチャー で利用可能なリソースを独占することを防ぎ、すべての ユーザー がサービスに アクセス できる状態を維持します。さまざまな理由で、より低いレート制限が発生する可能性があります。

レート制限 HTTP ヘッダー

上記の テーブル は、レート制限 HTTP ヘッダー を示しています。

メトリクス ログ記録 API のレート制限

スクリプト 内の wandb.log 呼び出しは、 メトリクス ログ記録 API を利用して、トレーニングデータ を W&B にログ記録します。この API は、オンラインまたはオフライン同期のいずれかを通じて実行されます。いずれの場合も、ローリングタイムウィンドウでレート制限 クォータ 制限が課されます。これには、合計リクエストサイズとリクエストレートの制限が含まれます。後者は、ある時間の長さにおけるリクエスト数を示します。

W&B は、W&B プロジェクト ごとにレート制限を適用します。したがって、チームに 3 つの プロジェクト がある場合、各 プロジェクト には独自のレート制限 クォータ があります。チーム および エンタープライズ プラン の ユーザー は、無料 プラン の ユーザー よりも高いレート制限があります。

メトリクス ログ記録 API の使用中にレート制限に達すると、標準出力に エラー を示す関連 メッセージ が表示されます。

メトリクス ログ記録 API レート制限を下回るための推奨事項

レート制限を超えると、レート制限がリセットされるまで run.finish() が遅延する可能性があります。これを回避するには、次の戦略を検討してください。

• W&B Python SDK バージョン を更新する: 最新バージョンの W&B Python SDK を使用していることを確認します。W&B Python SDK は定期的に更新され、要求を正常に再試行し、 クォータ の使用を最適化するための拡張 メカニズム が含まれています。
• メトリクス ログ記録頻度を下げる: クォータ を節約するために、 メトリクス のログ記録頻度を最小限に抑えます。たとえば、epoch ごとに メトリクス をログ記録するのではなく、5 epoch ごとにログ記録するように コード を変更できます。

if epoch % 5 == 0:  # 5 epoch ごとにメトリクスをログ記録する
    wandb.log({"acc": accuracy, "loss": loss})

• 手動データ 同期: レート制限されている場合、W&B は run データ をローカル に保存します。 コマンド wandb sync <run-file-path> を使用して、データを手動で同期できます。詳細については、wandb sync リファレンス を参照してください。

GraphQL API のレート制限

W&B Models UI および SDK のパブリック API は、GraphQL リクエスト を サーバー に送信して、データのクエリと変更を行います。SaaS Cloud 内のすべての GraphQL リクエスト について、W&B は、承認されていないリクエスト の場合は IP アドレス ごとに、承認されているリクエスト の場合は ユーザー ごとにレート制限を適用します。制限は、固定された時間枠内のリクエストレート（1 秒あたりのリクエスト数）に基づいており、料金 プラン によってデフォルトの制限が決定されます。 プロジェクト パス （たとえば、 Reports 、 runs 、 Artifacts ）を指定する関連 SDK リクエスト の場合、W&B は プロジェクト ごとにレート制限を適用します。これは、データベース のクエリ時間によって測定されます。

チーム および エンタープライズ プラン の ユーザー は、無料 プラン の ユーザー よりも高いレート制限を受け取ります。 W&B Models SDK のパブリック API の使用中にレート制限に達すると、標準出力に エラー を示す関連 メッセージ が表示されます。

GraphQL API レート制限を下回るための推奨事項

W&B Models SDK のパブリック API を使用して大量のデータを フェッチ する場合は、リクエスト の間に少なくとも 1 秒待機することを検討してください。429 ステータス コード を受信した場合、または応答ヘッダー に RateLimit-Remaining=0 が表示された場合は、再試行する前に RateLimit-Reset で指定された秒数待機します。

ブラウザ に関する考慮事項

W&B アプリ は メモリ を大量に消費する可能性があり、Chrome で最高のパフォーマンスを発揮します。コンピューター の メモリ に応じて、W&B を 3 つ以上の タブ で同時にアクティブにすると、パフォーマンスが低下する可能性があります。予期しないパフォーマンスの低下が発生した場合は、他の タブ または アプリケーション を閉じることを検討してください。

W&B へのパフォーマンス問題の報告

W&B はパフォーマンスを重視しており、遅延のすべての レポート を調査します。調査を迅速化するために、読み込み時間が遅いことを報告する場合は、主要な メトリクス とパフォーマンス イベント をキャプチャする W&B の組み込みパフォーマンスロガーの呼び出しを検討してください。読み込みが遅い ページ に URL パラメータ &PERF_LOGGING を追加し、コンソール の出力をアカウントチームまたは サポート と共有します。