実験管理の制限とパフォーマンス

W&B のページを、これらの推奨範囲内でログを記録することにより、より速く反応がよい状態に保ちましょう。

2 minute read

ページをW&Bで速く、応答性を高めるために、以下の推奨範囲内でログを記録してください。

ログに関する考慮事項

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

異なるメトリクスの数

より速いパフォーマンスのために、プロジェクト内の異なるメトリクスの合計数を10,000未満に抑えてください。

import wandb

wandb.log(
    {
        "a": 1,  # "a" は異なるメトリクスです
        "b": {
            "c": "hello",  # "b.c" は異なるメトリクスです
            "d": [1, 2, 3],  # "b.d" は異なるメトリクスです
        },
    }
)

W&Bは自動的にネストされた値をフラット化します。これは、辞書を渡すと、W&Bがそれをドットで区切られた名前に変えることを意味します。設定値については、W&Bは名前に3つのドットをサポートしています。要約値については、W&Bは4つのドットをサポートしています。

ワークスペースが突然遅くなった場合、最近のRunsが意図せず何千もの新しいメトリクスを記録していないか確認してください。もしそのような場合があれば、それらのRunsを削除し、望ましいメトリクスでそれらを再作成することを検討してください。

値の幅

単一のログに記録された値のサイズを1 MB未満に、単一の wandb.log コールの合計サイズを25 MB未満に制限してください。この制限は wandb.Media の型（ wandb.Image 、 wandb.Audio など）には適用されません。

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

# ❌ 推奨されません
with open("large_file.json", "r") as f:
    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,
        )  # ステップごとにまとめてメトリクスをコミットします

W&Bはあなたのログに記録されたデータを受け入れ続けますが、ガイドラインを超えるとページの読み込みが遅くなる可能性があります。

設定のサイズ

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

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

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

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

Workspaceに関する考慮事項

Runの数

読み込み時間を短縮するために、1つのプロジェクトでのRunsの総数を次のように抑えてください：

SaaSクラウド上で100,000以下
専用クラウドまたはセルフマネージドで10,000以下

これらの閾値を超えるRunの数は、プロジェクトのワークスペースやRunsテーブルの操作を遅くする可能性があります。特に次のRunsをグループ化する際や、Run中に大量の異なるメトリクスを収集する際に影響を与えます。メトリクスの数セクションも参照してください。

チームが頻繁に同じRunsセットにアクセスする場合、たとえば最近のRunsセットなど、使用頻度が低いRunsを一括で新しい「アーカイブ」プロジェクトに移動することを考慮してください。動作中のプロジェクトに小さなRunsセットだけを残してください。

Workspaceのパフォーマンス

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

パネルの数

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

ワークスペースを手動モードにリセットし、デフォルトでパネルを含まないようにします。
Quick addを使用して、可視化する必要があるログされたキーのパネルを選択的に追加します。

一度に一つずつ使われていないパネルを削除しても、パフォーマンスへの影響はほとんどありません。代わりに、ワークスペースをリセットし、選択的に必要なパネルだけを追加してください。

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

セクションの数

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

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

メトリクスの数

1つのRunで5,000から100,000のメトリクスをログに記録する場合、W&Bでは手動ワークスペースの使用をお勧めします。手動モードでは、異なるメトリクスセットを探索する際に、まとめてパネルを追加および削除することが容易です。より集中されたプロットセットにより、ワークスペースの読み込みが速くなります。プロットされていないメトリクスも通常どおり収集および保存されます。

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

ファイルの数

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

Reportsとワークスペース

レポートは、パネル、テキスト、メディアの任意の配置の自由な組み合わせで構成されており、洞察を容易に同僚と共有することができます。

対照的に、ワークスペースは、数十から数十万のRunsにわたる数十から数百のメトリクスの高密度で性能の高い分析を可能にします。ワークスペースは、Reportsと比較してキャッシュ、クエリ、および読み込み機能が最適化されています。ワークスペースは主に分析に使用されるプロジェクト、または20以上のプロットを一緒に表示する必要がある場合に推奨されます。

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

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

データのサイズが大きすぎること。大きなデータサイズは、トレーニングループに>1 msのオーバーヘッドを導入する可能性があります。
ネットワークの速度と、W&Bのバックエンドがどのように構成されているか
1秒あたり数回 wandb.log を呼び出すこと。これは、 wandb.log が呼び出されるたびにトレーニングループに小さな遅延が追加されるためです。

頻繁なログがトレーニングのRunsを遅くしている場合、このColabを参照し、ログ戦略を変更することでより良いパフォーマンスを得る方法を確認してください。

W&Bはレート制限以外の制限を主張しません。W&B Python SDKは、制限を超えるリクエストに対して指数関数的な「バックオフ」と「リトライ」を自動的に完了します。W&B Python SDKは、コマンドラインで「ネットワーク障害」と応答します。無償アカウントの場合、W&Bは合理的な閾値を超える使用が極端な場合に連絡することがあります。

レート制限

W&B SaaSクラウドAPIは、システムの整合性を保ち、利用可能性を確保するためにレート制限を実施しています。この対策により、共有インフラストラクチャで利用可能なリソースを特定のユーザーが独占することを防ぎ、サービスがすべてのユーザーにとってアクセス可能であることを保証します。いくつかの理由で、レート制限が低くなることがあります。

レート制限は変更される場合があります。

レート制限HTTPヘッダー

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

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

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

あなたのスクリプトの wandb.log の呼び出しは、トレーニングデータをW&Bに記録するためのメトリクスログAPIを使用します。このAPIは、オンラインまたはオフライン同期を通じて利用されます。いずれの場合でも、ローリング時間枠でのレート制限クォータ制限を課しています。これには、合計リクエストサイズとリクエストレート（時間内のリクエスト数）に対する制限が含まれます。

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

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

メトリクスログAPIのレート制限を超えないための提案

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

W&B Python SDKのバージョンを更新する：W&B Python SDKの最新バージョンを使用していることを確認してください。W&B Python SDKは定期的に更新され、リクエストのリトライやクォータの使用を最適化するための強化されたメカニズムが含まれています。
メトリクスログ頻度を減らす：クォータを節約するためにメトリクスのログ頻度を最小限に抑えます。たとえば、メトリクスを毎エポックではなく、5エポックごとにログに記録するためにコードを修正することができます：

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

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

GraphQL APIのレート制限

W&B モデル UI と SDK のパブリック APIは、データのクエリと修正のためにサーバーにGraphQLリクエストを行います。SaaSクラウドのすべてのGraphQLリクエストに対して、W&Bは認証されていないリクエストに対してIPアドレスごと、認証されたリクエストに対してユーザーごとにレート制限を適用します。制限は、固定された時間枠内のリクエストレート（1秒あたりのリクエスト）に基づいており、あなたのプライシングプランがデフォルトの制限を決定します。プロジェクトパスを指定する関連SDKリクエスト（レポート、Runs、Artifactsなど）については、W&Bはプロジェクトごとにレート制限を適用し、データベースクエリ時間で測定します。

Teams and Enterprise plansのユーザーは、無料プランのユーザーよりも高いレート制限を受け取ります。 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 を追加し、コンソールの出力をアカウントチームまたはサポートチームと共有してください。

フィードバック

このページは役に立ちましたか?

Glad to hear it! If you have further feedback, please let us know.

Sorry to hear that. Please tell us how we can improve.

最終更新 May 8, 2025

ページの編集ドキュメントのissueを作成セクション全体を印刷