ログに関する考慮事項
wandb.log
を使用して実験のメトリクスを追跡します。ログに記録されたメトリクスは、チャートを生成し、テーブルに表示されます。ログに記録されるデータが多すぎると、アプリケーションが遅くなる可能性があります。
異なるメトリクスの数
より速いパフォーマンスのために、プロジェクト内の異なるメトリクスの合計数を10,000未満に抑えてください。W&Bは自動的にネストされた値をフラット化します。これは、辞書を渡すと、W&Bがそれをドットで区切られた名前に変えることを意味します。設定値については、W&Bは名前に3つのドットをサポートしています。要約値については、W&Bは4つのドットをサポートしています。
値の幅
単一のログに記録された値のサイズを1 MB未満に、単一のwandb.log
コールの合計サイズを25 MB未満に制限してください。この制限は wandb.Media
の型( wandb.Image
、 wandb.Audio
など)には適用されません。
たとえ推奨される量を超えた値を記録しても、データは保存され追跡されます。ただし、プロットの読み込みが遅くなるかもしれません。
メトリクスの頻度
記録するメトリクスに応じたログ頻度を選択してください。一つの目安として、メトリクスが広ければ、その分頻度を減らしてログを記録する必要があります。W&Bの推奨は次の通りです:- スカラー: メトリクスあたり < 100,000 ログポイント
- メディア: メトリクスあたり < 50,000 ログポイント
- ヒストグラム: メトリクスあたり < 10,000 ログポイント
W&Bはあなたのログに記録されたデータを受け入れ続けますが、ガイドラインを超えるとページの読み込みが遅くなる可能性があります。
設定のサイズ
runの設定の合計サイズを10 MB未満に制限してください。大きな値をログに記録すると、プロジェクトワークスペースとRunsテーブルの操作が遅くなる可能性があります。Workspaceに関する考慮事項
Runの数
読み込み時間を短縮するために、1つのプロジェクトでのRunsの総数を次のように抑えてください:- SaaSクラウド上で100,000以下
- 専用クラウドまたはセルフマネージドで10,000以下
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 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エポックごとにログに記録するためにコードを修正することができます:
- 手動データ同期:レート制限を受けた場合、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
を追加し、コンソールの出力をアカウントチームまたはサポートチームと共有してください。
