Experiments の制限とパフォーマンス

推奨される制限の範囲内で ログ を記録することで、W&B のページをより高速でレスポンシブな状態に保つことができます。

W&B のページを高速かつレスポンシブに保つために、以下の推奨制限範囲内でのログ記録を心がけてください。

​

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

実験のメトリクスを追跡するには wandb.Run.log() を使用します。

​

個別のメトリクス数

パフォーマンスを向上させるために、プロジェクト内の個別のメトリクスの総数は 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 値の場合、W&B は名前の中で 3 つのドットまでサポートします。summary 値の場合、W&B は 4 つのドットまでサポートします。

メトリクス名は GraphQL による特定の命名制約に従う必要があります。詳細は メトリクス命名制約 を参照してください。

Workspace が急に重くなった場合は、最近の Runs が意図せず数千の新しいメトリクスを記録していないか確認してください。（これは、表示されている Runs が 1 つか 2 つしかないのに、数千のプロットがあるセクションを見つけることで簡単に特定できます。）もしそうなっている場合は、それらの Runs を削除し、必要なメトリクスのみで再作成することを検討してください。

​

値のサイズ（Width）

1 つのログ記録値のサイズは 1 MB 未満に、1 回の wandb.Run.log() 呼び出しの合計サイズは 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)

サイズの大きい値は、そのメトリクスだけでなく、その Run 内のすべてのメトリクスのプロット読み込み時間に影響を与える可能性があります。

推奨量を超えるサイズの値をログに記録しても、データは保存され追跡されます。ただし、プロットの読み込みが遅くなる可能性があります。

​

メトリクスの頻度

記録するメトリクスに適したログ記録頻度を選択してください。一般的な目安として、サイズの大きい値（Wide values）は、小さい値よりも頻度を下げて記録してください。W&B の推奨値は以下の通りです：

• スカラー：1 メトリクスあたり 100,000 ポイント未満
• メディア：1 メトリクスあたり 50,000 ポイント未満
• ヒストグラム：1 メトリクスあたり 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 はログデータの受け入れを継続しますが、ページの読み込みが遅くなる可能性があります。

​

Config のサイズ

Run config の合計サイズを 10 MB 未満に制限してください。大きな値を記録すると、プロジェクトの Workspace や Runs テーブルの操作が遅くなる可能性があります。

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 に関する考慮事項

​

Run の数

読み込み時間を短縮するために、単一プロジェクト内の Runs の総数を以下の範囲内に抑えてください。

• SaaS Cloud の場合：100,000 未満
• 専用クラウド または セルフマネージドの場合：10,000 未満

これらのしきい値を超えると、プロジェクトの Workspace や Runs テーブルに関連する操作（特に Runs のグループ化や、Run 実行中の多数の個別メトリクスの収集など）が遅くなる可能性があります。メトリクス数 のセクションも参照してください。

チームが同じ Runs のセット（最近の Runs など）に頻繁にアクセスする場合は、使用頻度の低い Runs をまとめて 新しい “アーカイブ” プロジェクトに移動 し、作業中のプロジェクト内の Runs セットを小さく保つことを検討してください。

​

Workspace のパフォーマンス

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

​

パネル数

デフォルトでは、Workspace は automatic モードになっており、ログに記録された各キーに対して標準パネルを生成します。大規模なプロジェクトの Workspace に多数のキーのパネルが含まれていると、読み込みや使用が遅くなることがあります。パフォーマンスを向上させるには、以下の操作が可能です。

1. Workspace を manual モードにリセットします。このモードでは、デフォルトでパネルは含まれません。
2. Quick add を使用して、可視化が必要なキーのパネルのみを選択的に追加します。

未使用のパネルを 1 つずつ削除しても、パフォーマンスへの影響はほとんどありません。代わりに、Workspace をリセットして、必要なパネルだけを再度追加してください。

Workspace の設定の詳細については、Panels を参照してください。

​

セクション数

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

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

​

メトリクス数

1 Run あたり 5,000 から 100,000 のメトリクスをログに記録する場合、W&B は manual workspace の使用を推奨します。Manual モードでは、異なるメトリクスのセットを探索する際に、パネルをまとめて簡単に追加・削除できます。プロットのセットを絞り込むことで、Workspace の読み込みが速くなります。プロットされていないメトリクスも、通常どおり収集・保存されます。

Workspace を manual モードにリセットするには、Workspace のアクションメニュー ... をクリックし、Reset workspace をクリックします。Workspace をリセットしても、保存されている Runs のメトリクスには影響しません。Workspace パネル管理 を参照してください。

​

ファイル数

1 つの Run でアップロードされるファイルの総数を 1,000 未満に抑えてください。大量のファイルをログに記録する必要がある場合は、W&B Artifacts を使用できます。1 つの Run で 1,000 ファイルを超えると、Run ページの表示が遅くなる可能性があります。

​

Reports vs. Workspaces

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

対照的に、Workspace は、数百から数十万の Runs にわたる数十から数千のメトリクスを、高密度かつパフォーマンス高く分析することを可能にします。Workspace は、Reports と比較してキャッシュ、クエリ、読み込み機能が最適化されています。プレゼンテーションよりも分析が主な目的であるプロジェクトや、20 以上のプロットを同時に表示する必要がある場合には、Workspace が推奨されます。

​

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

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

1. データのサイズが大きすぎる場合。データサイズが大きいと、トレーニングループに 1 ms 以上のオーバーヘッドが生じる可能性があります。
2. ネットワークの速度と、W&B バックエンドの設定。
3. wandb.Run.log() を 1 秒間に数回以上呼び出す場合。これは、wandb.Run.log() が呼び出されるたびにトレーニングループに小さなレイテンシが加わるためです。

頻繁なログ記録によってトレーニング Run が遅くなっていますか？ログ記録戦略を変更してパフォーマンスを向上させる方法については、こちらの Colab を確認してください。

W&B はレート制限以外の制限は設けていません。W&B Python SDK は、制限を超えたリクエストに対して自動的にエクスポネンシャル「バックオフ」と「リトライ」を実行します。W&B Python SDK は、コマンドラインに 「Network failure」 と表示します。無料アカウントの場合、使用量が妥当な基準を大幅に超える極端なケースでは、W&B から連絡させていただくことがあります。

​

レート制限

W&B SaaS Cloud API は、システムの整合性を維持し、可用性を確保するためにレート制限を実装しています。この措置により、特定のユーザーが共有インフラストラクチャの使用可能なリソースを独占することを防ぎ、すべてのユーザーがサービスにアクセスし続けられるようにしています。さまざまな理由により、低いレート制限が適用される場合があります。

レート制限は変更される可能性があります。

レート制限に達すると、HTTP 429 Rate limit exceeded エラーが発生し、レスポンスには レート制限 HTTP ヘッダー が含まれます。

​

レート制限 HTTP ヘッダー

以下の表は、レート制限 HTTP ヘッダーについて説明しています：

ヘッダー名	説明
RateLimit-Limit	タイムウィンドウごとに利用可能なクォータの量（0 から 1000 の範囲でスケール）
RateLimit-Remaining	現在のレート制限ウィンドウ内の残りのクォータ量（0 から 1000 の範囲でスケール）
RateLimit-Reset	現在のクォータがリセットされるまでの秒数

​

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

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 リファレンスを参照してください。

​

GraphQL API のレート制限

W&B Models UI および SDK の Public API は、データの照会や変更のためにサーバーに GraphQL リクエストを送信します。SaaS Cloud におけるすべての GraphQL リクエストに対して、W&B は、未認証のリクエストについては IP アドレスごとに、認証済みのリクエストについてはユーザーごとにレート制限を適用します。制限は固定タイムウィンドウ内のリクエストレート（1 秒あたりのリクエスト数）に基づいており、料金プランによってデフォルトの制限が決まります。プロジェクトパスを指定する関連 SDK リクエスト（レポート、Runs、アーティファクトなど）の場合、W&B はプロジェクトごとにデータベースのクエリ時間で測定されるレート制限を適用します。

Teams および Enterprise プラン のユーザーは、無料プランよりも高いレート制限が適用されます。 W&B Models SDK の Public API の使用中にレート制限に達すると、標準出力にエラーを示す関連メッセージが表示されます。

レート制限に達すると、HTTP 429 Rate limit exceeded エラーが発生し、レスポンスには レート制限 HTTP ヘッダー が含まれます。

​

GraphQL API のレート制限内に収めるための提案

W&B Models SDK の Public API を使用して大量のデータを取得する場合は、リクエスト間に少なくとも 1 秒の間隔を置くことを検討してください。HTTP 429 Rate limit exceeded エラーが発生した場合、またはレスポンスヘッダーに RateLimit-Remaining=0 が表示された場合は、RateLimit-Reset で指定された秒数待機してから再試行してください。

​

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

W&B アプリはメモリを多く消費する可能性があり、Chrome での動作が最適です。コンピュータのメモリ量にもよりますが、W&B を 3 つ以上のタブで同時に開くとパフォーマンスが低下することがあります。予期せずパフォーマンスが低下した場合は、他のタブやアプリケーションを閉じることを検討してください。

​

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

W&B はパフォーマンスを重視しており、ラグの報告はすべて調査します。調査を迅速に進めるために、読み込みが遅い問題を報告する際は、主要なメトリクスとパフォーマンスイベントをキャプチャする W&B 内蔵のパフォーマンスロガーの起動を検討してください。読み込みが遅いページの URL パラメータに &PERF_LOGGING を追加し、コンソールの出力をアカウントチームまたはサポート担当者と共有してください。