> ## Documentation Index
> Fetch the complete documentation index at: https://wb-21fd5541-docs-sandboxes-integrations-placement.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> このページでは、ログの取り方が W&B のパフォーマンスにどのように影響するかを説明し、大規模な project で実験管理をスケールさせるためのガイダンスを示します。

# 大規模な logging とパフォーマンス

パフォーマンスは通常、次の要素が組み合わさって左右されます。

* project 内の run の数
* 各 run のステップ数
* ログする異なるメトリクスの数
* `wandb.Run.log()` を呼び出す頻度
* 各ログ呼び出しで送信するデータ量
* Workspace の設定

ほとんどの場合、パフォーマンスの問題は、ステップを過剰にログすることよりも、異なるメトリクスを過剰にログすることによって発生します。

<div id="key-terms">
  ## 用語
</div>

このページでは、以下の用語を使用します。

<div id="steps">
  ### ステップ
</div>

**step** は、run におけるメトリクスの 1 つの論理的な行です。`wandb.Run.log()` を `commit=True` で呼び出したとき、または `commit` も `step` も指定しない場合は暗黙的に、step が確定されます。

```python theme={null}
import wandb

with wandb.init() as run:
    run.log({"loss": 0.42}, commit=True)
```

<div id="metric-cardinality">
  ### メトリクスのカーディナリティ
</div>

**メトリクスのカーディナリティ**とは、ネストされた辞書内のキーも含めて、project にログされた一意のメトリクスキーの数です。

たとえば、次の例では `a`、`b.c`、`b.d.e`、`b.d.f` の 4 つの異なるメトリクスキーがログされます。

```python theme={null}
import wandb

with wandb.init() as run:
    run.log(
        {
            "a": 1,
            "b": {
                "c": 2,
                "d": {
                    "e": 3,
                    "f": 4,
                },
            },
        }
    )
```

W\&B は、ネストされた辞書をドット区切りのメトリクス名に展開します。

<div id="logged-points">
  ### ログされたポイント
</div>

**ログされたポイント** とは、記録されたメトリクス値の総数を指します。

たとえば、次のどちらのコードサンプルでも、ログされたポイントは 3 つになります。

```python theme={null}
import wandb

with wandb.init() as run:
    run.log({"a": 1, "b": 2, "c": 3})
```

```python theme={null}
import wandb

with wandb.init() as run:
    run.log({"a": 1})
    run.log({"a": 2})
    run.log({"a": 3})
```

<div id="log-frequency">
  ### ログ頻度
</div>

**ログ頻度** は、1 分あたりの `wandb.Run.log()` の呼び出し回数です。

```text theme={null}
log frequency = wandb.Run.log() calls per minute
```

<div id="throughput">
  ### スループット
</div>

**スループット** は、1 分あたりに記録されるログされたポイントの総数です。

スループットは、次のように考えることができます。

```text theme={null}
throughput = logged points per minute
```

あるいは、同様に:

```text theme={null}
throughput = logged points × log frequency
```

<div id="recommendations-at-scale">
  ## 大規模運用時の推奨事項
</div>

<Warning>
  このセクションで説明する推奨事項は、W\&B Multi-tenant Cloud にのみ適用されます。別の W\&B デプロイメントタイプを使用している場合は、deployment 固有のガイダンスまたは制限について、管理者に確認してください。
</Warning>

次の表は、大規模な 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      |

<Note>
  これらの値は、大規模運用時に良好なパフォーマンスを維持するための目安です。W\&B はこれらの推奨値を超えるデータも引き続き受け付ける場合がありますが、ページの読み込みや操作が遅くなる可能性があります。
</Note>

<div id="throughput-examples">
  ## スループットの例
</div>

ログの記録方法が異なっていても、同じスループットになることがあります。

<div id="scalar-logging-examples">
  ### スカラーのログの例
</div>

<Warning>
  表に記載されている値は、W\&B Multi-tenant Cloud にのみ適用されます。別の W\&B デプロイメントタイプを使用している場合は、デプロイメント固有のガイダンスまたは制限について管理者に確認してください。
</Warning>

| 1 回のログ呼び出しあたりのメトリクス数 | ログ頻度 (1 分あたり) | スループット (1 分あたりの値数) |
| -------------------- | ------------- | ------------------ |
| 100                  | 1,000         | 100,000            |
| 1,000                | 100           | 100,000            |
| 10,000               | 10            | 100,000            |
| 20,000               | 5             | 100,000            |

<div id="video-logging-examples">
  ### 動画のログ記録の例
</div>

<Warning>
  表に記載されている値は、W\&B Multi-tenant Cloud にのみ適用されます。別の W\&B デプロイメントタイプを使用している場合は、デプロイメント固有のガイダンスまたは制限について管理者に確認してください。
</Warning>

| 動画サイズ (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                  |

<div id="logging-considerations">
  ## Logging に関する考慮事項
</div>

実験のメトリクスをトラッキングするには、`wandb.Run.log()` を使用します。

<div id="metric-cardinality">
  ### メトリクスのカーディナリティ
</div>

project 内のメトリクスの総カーディナリティ (異なるメトリクスの数) は、ワークロードに応じた推奨範囲内に収めてください。メトリクスのカーディナリティが高いことは、Workspace の動作が遅くなる最も一般的な原因の 1 つです。

<Tip>
  パフォーマンスの問題は、ステップを多くログしすぎることではなく、異なるメトリクスを多くログしすぎることが原因である場合がよくあります。
</Tip>

W\&B ではネストされたキーがドット区切りのメトリクス名にフラット化されるため、メトリクスのカーディナリティは想定以上に増えることがあります。

たとえば、次の例では `a`、`b.c`、`b.d` という 3 つの異なるメトリクスキーをログします。

```python theme={null}
import wandb

with wandb.init() as run:
    run.log(
        {
            "a": 1,
            "b": {
                "c": "hello",
                "d": [1, 2, 3],
            },
        }
    )
```

Workspace の動作が突然遅くなった場合は、最近の run で多数の新しいメトリクスキーが追加されていないか確認してください。これは、多くのプロットで 1 つまたは 2 つの run しか表示されない状態として現れることがよくあります。意図せずこの状態になった場合は、メトリクス名の数を減らして安定させたうえで、それらの run を削除して再作成することを検討してください。

<div id="value-size">
  ### 値のサイズ
</div>

1 つのログ値のサイズは 1 MB 未満、1 回の `wandb.Run.log()` 呼び出しの合計サイズは 25 MB 未満にしてください。

これらの推奨事項は、`wandb.Image` や `wandb.Audio` などの `wandb.Media` タイプには当てはまりません。これらは別の方法で処理されます。

```python theme={null}
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 全体のプロットの読み込みが遅くなる可能性があります。

<Note>
  W\&B では、これらの推奨値を超えるデータも引き続きログして保存されますが、ページの読み込みが遅くなる場合があります。
</Note>

<div id="log-frequency-and-throughput">
  ### ログ頻度とスループット
</div>

収集しているデータの価値に応じたログ頻度を選択してください。ログの頻度が高すぎると SDK のオーバーヘッドが増え、特にメトリクスのカーディナリティが高い場合やペイロードが大きい場合には、アプリの動作が遅くなることがあります。

まずは、ログを次のガイドラインの範囲内に収めることを推奨します。

* ログ頻度: 1 分あたり 1,000 回未満の `wandb.Run.log()` 呼び出し
* スループット: 1 分あたり 100,000 未満のログ値
* 動画スループット: 1 分あたり 40 MB 未満

可能であれば、関連するメトリクスは同じ step にまとめてください。たとえば、次のコード スニペットでは 3 つのメトリクスを同じ step でログしており、個別にログするよりも効率的です。

```python theme={null}
import wandb

with wandb.init(project="metric-frequency") as run:
    # 推奨: 関連するスカラーメトリクスをまとめてログする
    run.log(
        {
            "loss": 0.12,
            "accuracy": 0.98,
            "lr": 1e-4,
        },
        commit=True,
    )
```

<div id="config-size">
  ### 設定サイズ
</div>

run 設定 の合計サイズは 10 MB 未満に抑えてください。

大きな設定は、プロジェクトのWorkspaceやRuns tableでの操作を遅くする可能性があります。

```python theme={null}
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)
```

<div id="workspace-performance">
  ## Workspace のパフォーマンス
</div>

Workspace のパフォーマンスは、基盤となる project のデータと Workspace の設定の両方に左右されます。

<div id="runs-per-project">
  ### project ごとの Runs
</div>

大規模な project では、最適なパフォーマンスを得るため、1 つの project 内の Runs 数を 10,000 未満に保ってください。

チームで日常的に Runs の一部のみを使用する場合は、古い Runs や使用頻度の低い Runs を別のアーカイブ用 project に移すことを検討してください。[Runs の管理](/ja/models/runs/manage-runs/)を参照してください。

<div id="panel-count">
  ### パネル数
</div>

デフォルトでは、自動モードのWorkspaceでは、ログされた各キーに対して標準パネルが作成されます。大規模なProjectsでは、これによってパネル数が多くなりすぎ、Workspaceの動作が遅くなることがあります。

パフォーマンスを改善するには:

1. Workspaceを手動モードにリセットします。
2. [Quick add](/ja/models/app/features/panels/#quick-add) を使用して、必要なパネルだけを追加します。

<Note>
  未使用のパネルを1つずつ削除しても、通常はほとんど効果がありません。Workspaceをリセットして、必要なパネルだけを追加し直してください。
</Note>

詳しくは、[Panels](/ja/models/app/features/panels/) を参照してください。

<div id="section-count">
  ### セクション数
</div>

Workspace に何百ものセクションがあると、パフォーマンスに悪影響が出ることがあります。

メトリクスごとに 1 つのセクションを作成するのではなく、メトリクスを大まかなグループ単位でまとめてセクションを作成してください。セクションが多すぎる場合は、接尾辞ではなく接頭辞でセクションを作成することを検討してください。これにより、関連するメトリクスをより少ないセクションにまとめられます。

<Frame>
  <img src="https://mintcdn.com/wb-21fd5541-docs-sandboxes-integrations-placement/SNVYl3A1VGlNmCKT/images/track/section_prefix_toggle.gif?s=410c93aec75a1d1cb8b878d502343a2c" alt="セクション作成の切り替え" width="996" height="536" data-path="images/track/section_prefix_toggle.gif" />
</Frame>

<div id="many-metrics-per-run">
  ### 1 run あたり多数のメトリクス
</div>

1 run あたり数千件のメトリクスをログする場合は、可視化するメトリクスを選択できるように、手動 Workspace を使用してください。

表示するパネルを絞り込むと、読み込みが速くなります。プロットしていないメトリクスも、通常どおり収集・保存されます。

Workspace を手動モードにリセットするには、Workspace の **アクション (<Icon icon="ellipsis" iconType="solid" />)** メニューをクリックし、次に **Workspace をリセット** をクリックします。Workspace をリセットしても、run に保存済みのメトリクスには影響しません。[Workspace パネル管理](/ja/models/app/features/panels/) を参照してください。

<div id="file-count">
  ### ファイル数
</div>

1 回の run でアップロードするファイル数は、1,000 未満にしてください。

多数のファイルをログする必要がある場合は、代わりに W\&B Artifacts を使用してください。1 回の run で 1,000 ファイルを超えると、run ページの表示が遅くなることがあります。

<div id="reports-and-workspaces">
  ### Reports と Workspace
</div>

report は、共有やプレゼンテーションに適しています。Workspace は、多数の Runs とメトリクスをまたいで高密度かつ対話的に分析するためのものです。

大量の Runs を比較する必要がある場合や、多数の plot をまとめて確認したい場合は、Workspace を使用します。厳選した結果を提示したい場合は、report を使用します。

<div id="python-script-performance">
  ## Python スクリプトのパフォーマンス
</div>

ログ記録は、トレーニング スクリプトにオーバーヘッドを生じさせることがあります。主な要因は次のとおりです。

1. 大きなペイロード
2. ネットワーク速度とバックエンドの設定
3. `wandb.Run.log()` の非常に高頻度な呼び出し

`wandb.Run.log()` の呼び出し頻度が高すぎると、呼び出しのたびにトレーニング ループへわずかな遅延が加わることがあります。複数のメトリクスをまとめてログし、呼び出し回数を減らすことで、通常はパフォーマンスが向上します。

<Note>
  頻繁なログ記録によってトレーニング runs が遅くなっていませんか？ログ パターンを調整してパフォーマンスを改善する方法については、[この Colab](https://wandb.me/log-hf-colab) を参照してください。
</Note>

W\&B は、API のレート制限を除き、これらの推奨事項に関してプロダクト上の厳格な制限を設けていません。このページのガイダンスを超えた場合でも、W\&B は引き続きデータを受け付けることがありますが、アプリまたは SDK の動作が遅くなる可能性があります。

<div id="rate-limits">
  ## レート制限
</div>

W\&B Multi-tenant Cloud API では、サービスの信頼性と可用性を維持するためにレート制限を設けています。

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

レート制限に達すると、サーバーは HTTP `429 Rate limit exceeded` を返し、レスポンスにはレート制限ヘッダーが含まれます。

<div id="rate-limit-http-headers">
  ### レート制限の HTTP ヘッダー
</div>

| ヘッダー名                 | 説明                                             |
| --------------------- | ---------------------------------------------- |
| `RateLimit-Limit`     | 現在の時間ウィンドウで利用可能なクォータ量。値は 0～1000 の範囲にスケーリングされます |
| `RateLimit-Remaining` | 現在のウィンドウ内で残っているクォータ量。値は 0～1000 の範囲にスケーリングされます  |
| `RateLimit-Reset`     | 現在のクォータがリセットされるまでの秒数                           |

<div id="metric-logging-api-rate-limits">
  ### メトリクス logging API のレート制限
</div>

`wandb.Run.log()` は、トレーニング データを W\&B に送信します。オンラインで直接送信することも、[offline syncing](/ja/models/ref/cli/wandb-sync) を使用して後で送信することもできます。

メトリクス logging のレート制限は project レベルで適用され、一定時間のローリング ウィンドウ内でのリクエスト レートとリクエスト総サイズの両方が対象になります。有料プランは無料プランより高い制限が設定されています。

レート制限を超えると、W\&B SDK はバックオフを使用して自動的にリクエストを再試行します。場合によっては、レート制限のウィンドウがリセットされるまで `run.finish()` が遅延することがあります。

レート制限に達する可能性を減らすには:

* 最新版の W\&B SDK を使用してください。
* logging の頻度を下げてください。
* 関連するメトリクスをまとめて、log の Call 回数を減らしてください。
* 必要に応じてオフラインでログし、後で同期してください。

```python theme={null}
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`](/ja/models/ref/cli/wandb-sync)を参照してください。

<div id="graphql-api-rate-limits">
  ### GraphQL API のレート制限
</div>

W\&B App と [Public API](/ja/models/ref/python/public-api/api) は、GraphQL リクエストを使用してデータをクエリおよび変更します。

Multi-tenant Cloud の場合:

* 未認証のリクエストは、IP アドレスごとにレート制限されます
* 認証済みのリクエストは、ユーザーごとにレート制限されます
* project パスを指定する一部の SDK リクエストは、データベースのクエリ時間に応じて、project ごとに制限されることもあります

Teams および Enterprise プランは、Free プランより高い制限が設定されています。

多数の Public API リクエストを送信する場合は、可能であればリクエストの間隔を少なくとも 1 秒空けてください。HTTP `429 Rate limit exceeded` を受け取った場合、または `RateLimit-Remaining=0` が表示された場合は、`RateLimit-Reset` に示された秒数だけ待ってから再試行してください。

<div id="troubleshooting-slow-projects">
  ## 動作が遅い project のトラブルシューティング
</div>

project または Workspace の動作が遅いと感じる場合は、まず次の点を確認してください。

1. 最近の run で、新しいメトリクス名が大量に追加されていませんか？
2. ログする頻度が高すぎませんか？
3. 個々の `run.log()` Call が非常に大きくありませんか？
4. Workspace が自動モードになっていて、パネルやセクションが多すぎませんか？
5. project に、チームが実際に使用している以上の run が含まれていませんか？

多くの場合、メトリクスのカーディナリティを減らし、ログの Call をバッチ化し、大規模な Workspace を手動モードに切り替えることで、パフォーマンスは改善します。

<div id="browser-considerations">
  ## ブラウザに関する注意事項
</div>

W\&B App はメモリ消費が大きくなりやすく、Chrome で最も快適に動作します。お使いのコンピュータのメモリ容量によっては、W\&B を 3 つ以上のタブで同時に開いていると、パフォーマンスが低下することがあります。動作が予想以上に遅い場合は、他のタブやアプリケーションを閉じることを検討してください。

<div id="reporting-performance-issues-to-wb">
  ## W\&B へのパフォーマンス問題の報告
</div>

W\&B はパフォーマンスを重視しており、動作の遅さに関するすべての報告を調査しています。調査を迅速に進めるため、読み込み時間が遅いことを報告する際は、主要なメトリクスとパフォーマンスイベントを記録できる W\&B 組み込みのパフォーマンスロガーを有効にすることを検討してください。読み込みが遅いページの URL にパラメーター `&PERF_LOGGING` を追加し、その後、コンソールの出力をアカウント担当チームまたはサポートに共有してください。

<Frame>
  <img src="https://mintcdn.com/wb-21fd5541-docs-sandboxes-integrations-placement/gsiJ_BEkjRzibnDO/images/track/adding_perf_logging.gif?s=e9cdb4776056c7e311b60c6ba4c486c1" alt="PERF_LOGGING を追加" width="1504" height="590" data-path="images/track/adding_perf_logging.gif" />
</Frame>