ガイド
W&B とは何かの概要に加えて、初めてのユーザーの場合の開始方法へのリンクを提供します。
W&B とは？
Weights & Biases (W&B) は、AI 開発者向けのプラットフォームで、モデルのトレーニング、ファインチューニング、および基盤モデルの活用のためのツールを提供しています。
W&B は、3つの主要なコンポーネントで構成されています：Models 、Weave 、および Core :
W&B Models
W&B Weave
W&B Core
W&B はどのように機能しますか？
W&B を初めて使用するユーザーで、機械学習モデルと実験のトレーニング、トラッキング、可視化に興味がある場合、次のセクションをこの順番で読んでください。
W&B の基本的な計算単位である runs について学びます。
Experiments を使用して機械学習実験を作成し、トラッキングします。データセットとモデルのバージョン管理のための W&B の柔軟で軽量な構成要素を Artifacts で発見します。
ハイパーパラメータ検索を自動化し、可能性のあるモデルの空間を Sweeps で探索します。
モデルのライフサイクルをトレーニングからプロダクションまで管理する Registry 。
Data Visualization ガイドでモデルバージョン間の予測を可視化します。runs を整理し、可視化を埋め込み、自動化し、学びを説明し、共著者と更新を共有するために Reports を使用します。
VIDEO
W&B の初めてのユーザーですか？
W&B のインストール方法と W&B をコードに追加する方法を学ぶために、quickstart を試してみてください。
1 - W&B クイックスタート
W&B クイックスタート
W&B をインストールして、お好きな規模の機械学習実験をトラッキング、可視化、管理しましょう。
サインアップしてAPIキーを作成する
W&Bとマシンを認証するには、ユーザープロファイルまたはwandb.ai/authorize でAPIキーを生成します。APIキーをコピーして安全に保管してください。
wandb ライブラリをインストールしてログインする
コマンドライン
Python
Python ノートブック
WANDB_API_KEY 環境変数 を設定します。
export WANDB_API_KEY= <your_api_key>
wandb ライブラリをインストールしてログインします。
pip install wandb
wandb login
import wandb
wandb. login()
!pip install wandb
import wandb
wandb.login()
ランを開始してハイパーパラメーターをトラックする
Python スクリプトやノートブックで、wandb.init()config パラメータには辞書を使用してハイパーパラメーターの名前と値を指定します。
run = wandb. init(
project= "my-awesome-project" , # プロジェクトを指定する
config= { # ハイパーパラメーターとメタデータをトラックする
"learning_rate" : 0.01 ,
"epochs" : 10 ,
},
)
W&B のコア要素として ラン は使用され、メトリクスをトラックする 、ログを作成する など様々なことができます。
コンポーネントを組み立てる
この模擬トレーニングスクリプトは、W&Bにシミュレートされた精度と損失のメトリクスをログします:
# train.py
import wandb
import random
wandb. login()
epochs = 10
lr = 0.01
run = wandb. init(
project= "my-awesome-project" , # プロジェクトを指定する
config= { # ハイパーパラメーターとメタデータをトラックする
"learning_rate" : lr,
"epochs" : epochs,
},
)
offset = random. random() / 5
print(f "lr: { lr} " )
# トレーニングランをシミュレーション
for epoch in range(2 , epochs):
acc = 1 - 2 **- epoch - random. random() / epoch - offset
loss = 2 **- epoch + random. random() / epoch + offset
print(f "epoch= { epoch} , accuracy= { acc} , loss= { loss} " )
wandb. log({"accuracy" : acc, "loss" : loss})
# run.log_code()
wandb.ai/home にアクセスして、記録された精度や損失メトリクス、および各トレーニングステップでの変化を確認してください。次のイメージは、各ランからトラックされた損失と精度を示しています。各ランオブジェクトは、Runs 列に生成された名前と共に表示されます。
次のステップ
W&B エコシステムのさらなる機能を探求しましょう:
PyTorch や Hugging Face のライブラリ、および SageMaker のようなサービスと W&B を組み合わせた W&B インテグレーションチュートリアル を読んでみてください。
W&B Reports を使用して、ランを整理し、自動可視化し、学びを要約し、共同作業者と更新を共有します。W&B Artifacts を作成して、データセット、モデル、依存関係、および機械学習パイプライン全体の結果をトラックします。W&B Sweeps を使用してハイパーパラメーター検索を自動化し、モデルを最適化します。中央ダッシュボード でランを分析し、モデルの予測を可視化し、洞察を共有します。W&B AI Academy を訪れて、ハンズオンのコースを通じて LLMs、MLOps、W&B Models について学びましょう。
2 - W&B モデル
W&B Models は、モデルを整理し、生産性とコラボレーションを向上させ、プロダクション規模での機械学習を提供したい機械学習エンジニアのための SoR です。
W&B Models を使用すると、次のことが可能です:
機械学習エンジニアは、実験をトラッキングして視覚化し、モデルのバージョンとリネージを管理し、ハイパーパラメーターを最適化するための ML SoR として W&B Models に依存しています。
2.1 - 実験管理
W&B で機械学習実験を追跡する。
数行のコードで機械学習実験を追跡します。その後、インタラクティブなダッシュボード で結果をレビューしたり、Public API を使用してプログラムからアクセスできるようにPythonにデータをエクスポートすることができます。
人気のあるフレームワークを使用している場合は、W&Bのインテグレーションを活用してください。PyTorch 、Keras 、またはScikit のようなフレームワークがあります。インテグレーションの完全なリストや、W&Bをコードに追加する方法については、インテグレーションガイド をご覧ください。
上の画像は、複数のRuns でメトリクスを確認および比較できるダッシュボードの例を示しています。
仕組み
数行のコードで機械学習実験を追跡します:
W&B Run を作成します。学習率やモデルタイプなどのハイパーパラメーターを辞書として設定（run.config
トレーニングループ中に正確性や損失などのメトリクスをログ（run.log()
モデルの重みや予測のテーブルのようなRunの出力を保存します。
以下のコードは、一般的なW&B実験管理ワークフローを示しています:
# Run を開始します。
#
# このブロックから出ると、ログデータのアップロードが完了するのを待ちます。
# 例外が発生した場合、Run は失敗としてマークされます。
with wandb. init(entity= "" , project= "my-project-name" ) as run:
# モード入力とハイパーパラメーターを保存します。
run. config. learning_rate = 0.01
# 実験コードを実行します。
for epoch in range(num_epochs):
# トレーニングをします...
# モデルのパフォーマンスを可視化するためのメトリクスを時間と共にログします。
run. log({"loss" : loss})
# モデルの出力をアーティファクトとしてアップロードします。
run. log_artifact(model)
始めましょう
あなたのユースケースに応じて、W&B Experimentsの開始に役立つ次のリソースを探索してください:
ベストプラクティスとヒント
実験とログのベストプラクティスとヒントについては、ベストプラクティス： 実験とログ をご覧ください。
2.1.1 - 実験を作成する
W&B 実験を作成します。
W&B Python SDKを使用して、機械学習実験をトラックします。その後、インタラクティブなダッシュボードで結果を確認するか、データをPythonにエクスポートしてプログラムでアクセスできます（W&B Public API を参照）。
このガイドでは、W&Bのビルディングブロックを使用してW&B Experimentを作成する方法を説明します。
W&B Experimentの作成方法
W&B Experimentを次の4つのステップで作成します：
W&B Runを初期化 ハイパーパラメータの辞書をキャプチャ トレーニングループ内でメトリクスをログ アーティファクトをW&Bにログ
W&B Runを初期化
wandb.init()
以下のスニペットは、“cat-classification”という名前のW&Bプロジェクトで、“My first experiment”という説明を持つrunを作成し、これを識別するのに役立てます。タグ“baseline”と“paper1”は、このrunが将来的な論文の出版を意図したベースライン実験であることを思い出すために含まれています。
import wandb
with wandb. init(
project= "cat-classification" ,
notes= "My first experiment" ,
tags= ["baseline" , "paper1" ],
) as run:
...
wandb.init()は、Run オブジェクトを返します。
注意: wandb.init()を呼び出したときにプロジェクトが既に存在している場合、Runは既存のプロジェクトに追加されます。例えば、既に“cat-classification”という名前のプロジェクトがある場合、そのプロジェクトは既存のままで削除されず、新しいrunがそのプロジェクトに追加されます。
ハイパーパラメータの辞書をキャプチャ
学習率やモデルタイプといったハイパーパラメータの辞書を保存します。設定でキャプチャしたモデル設定は、後で結果の整理やクエリに役立ちます。
with wandb. init(
... ,
config= {"epochs" : 100 , "learning_rate" : 0.001 , "batch_size" : 128 },
) as run:
...
実験を設定する方法の詳細については、Configure Experiments を参照してください。
トレーニングループ内でメトリクスをログ
run.log()
model, dataloader = get_model(), get_data()
for epoch in range(run. config. epochs):
for batch in dataloader:
loss, accuracy = model. training_step()
run. log({"accuracy" : accuracy, "loss" : loss})
W&Bでログできるさまざまなデータタイプの詳細については、Log Data During Experiments を参照してください。
アーティファクトをW&Bにログ
オプションでW&Bアーティファクトをログします。アーティファクトは、データセットやモデルのバージョン管理を容易にします。
# 任意のファイルまたはディレクトリを保存できます。この例では、モデルがONNXファイルを出力するsave()メソッドを持つと仮定しています。
model. save("path_to_model.onnx" )
run. log_artifact("path_to_model.onnx" , name= "trained-model" , type= "model" )
Artifacts やRegistry でのモデルのバージョン管理について詳しく学んでください。
すべてをまとめる
前述のコードスニペットを使った完全なスクリプトは以下の通りです：
import wandb
with wandb. init(
project= "cat-classification" ,
notes= "" ,
tags= ["baseline" , "paper1" ],
# runのハイパーパラメータを記録
config= {"epochs" : 100 , "learning_rate" : 0.001 , "batch_size" : 128 },
) as run:
# モデルとデータをセットアップ
model, dataloader = get_model(), get_data()
# モデルのパフォーマンスを可視化するためにメトリクスをログしながらトレーニングを実行
for epoch in range(run. config["epochs" ]):
for batch in dataloader:
loss, accuracy = model. training_step()
run. log({"accuracy" : accuracy, "loss" : loss})
# 訓練済みモデルをアーティファクトとしてアップロード
model. save("path_to_model.onnx" )
run. log_artifact("path_to_model.onnx" , name= "trained-model" , type= "model" )
次のステップ：実験を可視化
W&Bダッシュボードを使用して、機械学習モデルの結果を整理し可視化する中央の場所として利用します。parallel coordinates plots 、parameter importance analyzes 、およびその他の ようなリッチでインタラクティブなグラフを数クリックで構築します。
実験や特定runの表示方法についての詳細は、Visualize results from experiments を参照してください。
ベストプラクティス
以下は、実験を作成する際に考慮すべきいくつかのガイドラインです：
Runを終了させる : wandb.init()をwith文で使用して、コードが完了したときや例外が発生したときにrunを自動的に終了させます。
Config : ハイパーパラメータ、アーキテクチャー、データセット、およびモデルの再現に使用したい他のすべてのものをトラックします。これらは列に表示され、アプリ内で動的にrunをグループ化、並べ替え、およびフィルタリングするためにconfig列を使用します。プロジェクト : プロジェクトは比較可能な一連の実験です。各プロジェクトは専用のダッシュボードページを持ち、異なるモデルバージョンを比較するrunの異なるグループを簡単にオンオフできます。ノート : スクリプトから直接クイックコミットメッセージを設定します。ノートを編集し、W&Bアプリのrunのオーバービューセクションでアクセスします。タグ : ベースラインrunとお気に入りのrunを識別します。タグを使用してrunをフィルタリングできます。タグは後で、プロジェクトのダッシュボードのオーバービューセクションで編集できます。実験を比較するために複数のrunセットを作成 : 実験を比較するときは、メトリクスを比較しやすくするために複数のrunセットを作成します。runセットを同じグラフまたは一連のグラフでオンオフできます。
以下のコードスニペットは、上記のベストプラクティスを使用してW&B Experimentを定義する方法を示しています：
import wandb
config = {
"learning_rate" : 0.01 ,
"momentum" : 0.2 ,
"architecture" : "CNN" ,
"dataset_id" : "cats-0192" ,
}
with wandb. init(
project= "detect-cats" ,
notes= "tweak baseline" ,
tags= ["baseline" , "paper1" ],
config= config,
) as run:
...
W&B Experimentを定義する際に利用可能なパラメータの詳細については、wandb.initAPIリファレンスガイド で参照してください。
2.1.2 - 実験を設定する
実験の設定を保存するために辞書のようなオブジェクトを使用します。
run の config プロパティを使用して、トレーニング設定を保存します:
ハイパーパラメーター
データセット名やモデルタイプなどの入力設定
実験のためのその他の独立変数
run.config プロパティを使用すると、実験を簡単に分析し、将来的に作業を再現できます。 W&B アプリで設定値ごとにグループ化し、さまざまな W&B Run の設定を比較し、各トレーニング設定が出力にどのように影響するかを評価できます。config プロパティは、複数の辞書のようなオブジェクトから構成できる辞書のようなオブジェクトです。
出力メトリクスや損失や精度のような従属変数を保存するには、run.config ではなく run.log を使用してください。
実験の設定を行う
設定は通常、トレーニングスクリプトの最初に定義されます。ただし、機械学習ワークフローは異なる場合があるため、トレーニングスクリプトの最初に設定を定義する必要はありません。
設定変数名にはピリオド (.) の代わりにダッシュ (-) またはアンダースコア (_) を使用してください。
スクリプトが run.config キーをルート以下でアクセスする場合は、属性アクセス構文 config.key.value の代わりに、辞書アクセス構文 ["key"]["value"] を使用してください。
以下のセクションでは、実験の設定を定義する一般的なシナリオをいくつか示します。
初期化時に設定を行う
wandb.init() API を呼び出して、バックグラウンドプロセスを生成し、W&B Run としてデータを同期してログに記録する際に、スクリプトの最初に辞書を渡します。
次に示すコードスニペットは、設定値を持つ Python の辞書を定義し、その辞書を引数として W&B Run を初期化する方法を示しています。
import wandb
# 設定辞書オブジェクトを定義する
config = {
"hidden_layer_sizes" : [32 , 64 ],
"kernel_sizes" : [3 ],
"activation" : "ReLU" ,
"pool_sizes" : [2 ],
"dropout" : 0.5 ,
"num_classes" : 10 ,
}
# W&B を初期化する際に設定辞書を渡す
with wandb. init(project= "config_example" , config= config) as run:
...
ネストされた辞書を config として渡す場合、W&B はドットを使用して名前をフラットにします。
Python の他の辞書にアクセスする方法と同様に、辞書から値にアクセスすることができます:
# インデックス値としてキーを使用して値にアクセスする
hidden_layer_sizes = run. config["hidden_layer_sizes" ]
kernel_sizes = run. config["kernel_sizes" ]
activation = run. config["activation" ]
# Python の辞書 get() メソッド
hidden_layer_sizes = run. config. get("hidden_layer_sizes" )
kernel_sizes = run. config. get("kernel_sizes" )
activation = run. config. get("activation" )
開発者ガイドと例全体で、設定値を別の変数にコピーします。このステップは任意です。読みやすさのために行われます。
argparse を使用して設定を行う
argparse オブジェクトで設定を行うことができます。argparse は、引数パーサの短縮形で、Python 3.2 以降の標準ライブラリモジュールであり、コマンドライン引数の柔軟性と強力さを活かしたスクリプトの記述を容易にします。
コマンドラインから起動されるスクリプトからの結果を追跡するのに便利です。
次の Python スクリプトは、実験設定を定義および設定するためのパーサーオブジェクトを定義する方法を示しています。train_one_epoch および evaluate_one_epoch 関数は、このデモの目的でトレーニングループをシミュレートするために提供されています:
# config_experiment.py
import argparse
import random
import numpy as np
import wandb
# トレーニングと評価デモのコード
def train_one_epoch (epoch, lr, bs):
acc = 0.25 + ((epoch / 30 ) + (random. random() / 10 ))
loss = 0.2 + (1 - ((epoch - 1 ) / 10 + random. random() / 5 ))
return acc, loss
def evaluate_one_epoch (epoch):
acc = 0.1 + ((epoch / 20 ) + (random. random() / 10 ))
loss = 0.25 + (1 - ((epoch - 1 ) / 10 + random. random() / 6 ))
return acc, loss
def main (args):
# W&B Run を開始する
with wandb. init(project= "config_example" , config= args) as run:
# 設定辞書から値をアクセスして、
# 可読性のために変数に格納する
lr = run. config["learning_rate" ]
bs = run. config["batch_size" ]
epochs = run. config["epochs" ]
# トレーニングをシミュレートし、値を W&B にログする
for epoch in np. arange(1 , epochs):
train_acc, train_loss = train_one_epoch(epoch, lr, bs)
val_acc, val_loss = evaluate_one_epoch(epoch)
run. log(
{
"epoch" : epoch,
"train_acc" : train_acc,
"train_loss" : train_loss,
"val_acc" : val_acc,
"val_loss" : val_loss,
}
)
if __name__ == "__main__" :
parser = argparse. ArgumentParser(
formatter_class= argparse. ArgumentDefaultsHelpFormatter
)
parser. add_argument("-b" , "--batch_size" , type= int, default= 32 , help= "バッチサイズ" )
parser. add_argument(
"-e" , "--epochs" , type= int, default= 50 , help= "トレーニングエポックの数"
)
parser. add_argument(
"-lr" , "--learning_rate" , type= int, default= 0.001 , help= "学習率"
)
args = parser. parse_args()
main(args)
スクリプト全体で設定を行う
スクリプト全体で、設定オブジェクトにさらにパラメータを追加できます。次に示すコードスニペットでは、設定オブジェクトに新しいキーと値のペアを追加する方法を示しています:
import wandb
# 設定辞書オブジェクトを定義する
config = {
"hidden_layer_sizes" : [32 , 64 ],
"kernel_sizes" : [3 ],
"activation" : "ReLU" ,
"pool_sizes" : [2 ],
"dropout" : 0.5 ,
"num_classes" : 10 ,
}
# W&B を初期化する際に設定辞書を渡す
with wandb. init(project= "config_example" , config= config) as run:
# W&B を初期化した後に設定を更新する
run. config["dropout" ] = 0.2
run. config. epochs = 4
run. config["batch_size" ] = 32
複数の値を一度に更新できます:
run. config. update({"lr" : 0.1 , "channels" : 16 })
Run終了後に設定を行う
W&B Public API を使用して、完了済みの run の設定を更新できます。
API に対して、エンティティ、プロジェクト名、および run の ID を提供する必要があります。これらの詳細は Run オブジェクトや W&B App UI で確認できます:
with wandb. init() as run:
...
# Run オブジェクトから以下の値を見つけます。
# これが現在のスクリプトまたはノートブックから初期化された場合、または W&B アプリUIからそれらをコピーできます。
username = run. entity
project = run. project
run_id = run. id
# api.run() は wandb.init() と異なるタイプのオブジェクトを返すことに注意してください。
api = wandb. Api()
api_run = api. run(f " { username} / { project} / { run_id} " )
api_run. config["bar" ] = 32
api_run. update()
absl.FLAGSabsl flags
flags. DEFINE_string("model" , None , "model to run" ) # name, default, help
run. config. update(flags. FLAGS) # absl flags を設定に追加します
ファイルベースの設定
config-defaults.yaml という名前のファイルを run スクリプトと同じディレクトリーに配置すると、run はファイルに定義されたキーと値のペアを自動的に取得し、それを run.config に渡します。
以下のコードスニペットは、サンプルの config-defaults.yaml YAML ファイルを示しています:
batch_size :
desc : サイズごとのミニバッチ
value : 32
config-defaults.yaml から自動的に読み込まれたデフォルト値を、新しい値を wandb.init の config 引数で設定して上書きできます。たとえば:
import wandb
# 独自の値を渡して config-defaults.yaml を上書きします
with wandb. init(config= {"epochs" : 200 , "batch_size" : 64 }) as run:
...
config-defaults.yaml 以外の設定ファイルを読み込むには、--configs command-line 引数を使用してファイルのパスを指定します:
python train.py --configs other-config.yaml
ファイルベースの設定のユースケースの例
Run のメタデータを含む YAML ファイルがあり、Python スクリプトでハイパーパラメーターの辞書を持っているとします。それらの両方をネストされた config オブジェクトに保存できます:
hyperparameter_defaults = dict(
dropout= 0.5 ,
batch_size= 100 ,
learning_rate= 0.001 ,
)
config_dictionary = dict(
yaml= my_yaml_file,
params= hyperparameter_defaults,
)
with wandb. init(config= config_dictionary) as run:
...
TensorFlow v1 フラグ
TensorFlow のフラグを wandb.config オブジェクトに直接渡すことができます。
with wandb. init() as run:
run. config. epochs = 4
flags = tf. app. flags
flags. DEFINE_string("data_dir" , "/tmp/data" )
flags. DEFINE_integer("batch_size" , 128 , "バッチサイズ" )
run. config. update(flags. FLAGS) # TensorFlow のフラグを設定に追加します
2.1.3 - プロジェクト
モデルのバージョンを比較し、スクラッチワークスペースで結果を探索し、ノートや可視化を保存するために学びをレポートにエクスポートする
A プロジェクト は、結果の可視化、実験の比較、アーティファクトの閲覧とダウンロード、オートメーションの作成などを行うための中央の場所です。
各プロジェクトには、その公開範囲を決定する公開設定があります。公開範囲についての詳細は、
プロジェクトの公開範囲 を参照してください。
各プロジェクトには、サイドバーからアクセスできる次の項目が含まれています:
Overview Workspace Runs Automations : プロジェクトで設定されたオートメーションSweeps Reports Artifacts
Overview タブ
Project name : プロジェクトの名前。W&B は、指定したプロジェクトフィールド名で run を初期化するときにプロジェクトを作成します。右上隅の Edit ボタンを選択することで、いつでもプロジェクト名を変更できます。Description : プロジェクトの説明。Project visibility : プロジェクトの公開範囲。それにアクセスできる人を決定する公開設定です。詳細はプロジェクトの公開範囲 を参照してください。Last active : このプロジェクトにデータが最後にログ記録された日時のタイムスタンプOwner : このプロジェクトを所有するエンティティContributors : このプロジェクトに貢献するユーザーの数Total runs : このプロジェクトの総 run 数Total compute : プロジェクト内のすべての run 時間を合計して得られるトータルUndelete runs : ドロップダウンメニューをクリックし、「Undelete all runs」をクリックしてプロジェクト内の削除された run を復元します。Delete project : 右上隅のドットメニューをクリックしてプロジェクトを削除
ライブ例を見る
Workspace タブ
プロジェクトのワークスペース は、実験を比較するための個人的なサンドボックスを提供します。プロジェクトを使用して、比較できるモデルを整理し、異なるアーキテクチャー、ハイパーパラメーター、データセット、プロセッシングなどで同じ問題に取り組みます。
Runs Sidebar : プロジェクト内のすべての run のリスト。
Dot menu : サイドバーの行にカーソルを合わせると、左側にメニューが表示されます。このメニューを使用して、run の名前を変更、run の削除、または active run の停止を行います。Visibility icon : グラフで run をオンまたはオフにするために目のアイコンをクリックします。Color : run の色を私たちのプリセットの1つまたはカスタムカラーに変更します。Search : 名前で run を検索します。これにより、プロットで表示される run もフィルタリングされます。Filter : サイドバーフィルターを使用して、表示される run のセットを絞り込みます。Group : 設定した列を選択して run を動的にグループ化します。例えば、アーキテクチャーでグループ化することができます。グループ化すると、プロットに平均値に沿った線が表示され、グラフ上のポイントの分散の地域を示す影が表示されます。Sort : 最小の損失や最大の精度を持つ run など、value で run をソートします。ソートは、どの run がグラフに表示されるかに影響します。Expand button : サイドバーを完全なテーブルに拡張します。Run count : 上部のかっこ内の数字は、プロジェクト内のすべての run 数です。数字 (N visualized) は、目のアイコンがオンになっていて、各プロットで可視化可能な run 数です。以下の例では、グラフは183 runのうち最初の10 runのみを表示しています。表示される run の最大数を増やすには、グラフを編集します。
Runs タブ で列をピン止め、非表示、または順序を変更すると、Runs サイドバーにもこれらのカスタマイズが反映されます。
Panels layout : このスクラッチスペースを使用して、結果を探索し、チャートを追加および削除し、異なるメトリクスに基づいてモデルのバージョンを比較します。
ライブ例を見る
Add a section of panels
セクションのドロップダウンメニューをクリックし、「Add section」をクリックして、セクションを作成します。セクションの名前を変更したり、ドラッグして順序を再編成したり、セクションを展開または折りたたむことができます。
各セクションには右上隅にオプションがあります:
Switch to custom layout : カスタムレイアウトでは、個々のパネルのサイズを変更できます。Switch to standard layout : 標準レイアウトでは、セクション内のすべてのパネルのサイズを一括で変更でき、ページネーションが利用できます。Add section : ドロップダウンメニューから上または下にセクションを追加するか、ページの下部のボタンをクリックして新しいセクションを追加します。Rename section : セクションのタイトルを変更します。Export section to report : このパネルのセクションを新しいレポートに保存します。Delete section : セクション全体とすべてのチャートを削除します。これは、ワークスペースバーのページ下部にあるアンドゥボタンで取り消すことができます。Add panel : プラスボタンをクリックしてセクションにパネルを追加します。
Move panels between sections
ドラッグアンドドロップしてセクションに整理します。また、パネルの右上隅にある「Move」ボタンをクリックしてセクションを選択し、パネルを移動します。
Resize panels
Standard layout : すべてのパネルは同じサイズに保たれ、ページがあります。セクションの右下隅をクリックアンドドラッグして、セクションのサイズを変更します。Custom layout : 各パネルは個別にサイズが設定されており、ページはありません。
Search for metrics
ワークスペースの検索ボックスを使用してパネルを絞り込みます。この検索はパネルのタイトルに一致し、デフォルトでは表示されているメトリクスの名前となります。
Runs タブ
Runs タブを使用して、run をフィルタリング、グループ化、およびソートします。
次のタブには、Runs タブで実行できる一般的な操作がいくつか示されています。
Customize columns
Sort
Filter
Group
Runs タブは、プロジェクト内の run の詳細を表示します。デフォルトで多数の列が表示されます。
すべての列を表示するには、ページを水平にスクロールします。
列の順序を変更するには、列を左右にドラッグします。
列をピン止めするには、列名にカーソルを合わせて、表示されるアクションメニュー ... をクリックし、次に Pin column をクリックします。ピン止めされた列は、ページの左側に、Name 列の後に表示されます。ピン止めされた列を取り除くには、Unpin column を選択します。
列を非表示にするには、列名にカーソルを合わせて、表示されるアクションメニュー ... をクリックし、次に Hide column をクリックします。現在非表示のすべての列を表示するには、Columns をクリックします。
複数の列を一度に表示、非表示、ピン止め、およびピン解除するには、Columns をクリックします。
非表示の列の名前をクリックして表示します。
表示列の名前をクリックして非表示にします。
表示列の横のピンアイコンをクリックしてピン止めします。
Runs タブをカスタマイズすると、そのカスタマイズはWorkspace タブ の Runs セレクタにも反映されます。
指定した列の値でテーブル内のすべての行をソートします。
列タイトルにマウスをホバーします。ケバブメニューが表示されます（三つの垂直ドット）。
ケバブメニュー（三つの垂直ドット）を選択します。
Sort Asc または Sort Desc を選択して、行を昇順または降順にソートします。
上の画像は、val_acc というテーブル列のソートオプションを表示する方法を示しています。
ダッシュボードの左上の Filter ボタンを使って、式に基づいてすべての行をフィルタリングします。
Add filter を選択して、行に1つ以上のフィルターを追加します。3つのドロップダウンメニューが表示され、左から右にかけて、フィルターのタイプは次のようになります: 列名、演算子、および値
列名
バイナリ関係
値
許可される値
String
=, ≠, ≤, ≥, IN, NOT IN,
整数, 浮動小数点数, 文字列, タイムスタンプ, null
式エディタは、オートコンプリートを使用して、列名と論理述語構造などの用語ごとのオプションのリストを表示します。複数の論理述部を使用して「ands」または「or」で式を組み合わせることができます（場合によっては括弧を使用します）。
上の画像は、`val_loss` 列に基づいたフィルターを示しています。このフィルターは、1以下の検証損失を持つ run を表示します。
特定の列の値で Group by ボタンを使い、すべての行をグループ化します。
デフォルトでは、これにより他の数値列がヒストグラムに変わり、グループ全体のその列の値の分布を示します。グループ化は、データ内の高レベルのパターンを理解するのに便利です。
Reports タブ
結果のスナップショットを一か所で確認し、チームと学びを共有します。
Sweeps タブ
スイープ をプロジェクトから新たに開始します。
Artifacts タブ
プロジェクトに関連付けられたすべてのArtifacts をトレーニングデータセットや ファインチューンされたモデル からメトリクスやメディアのテーブル まで表示します。
Overview パネル
概要パネルでは、アーティファクトの名前やバージョン、変更を検出し重複を防止するために使用されるハッシュダイジェスト、作成日、およびエイリアスなど、アーティファクトに関するさまざまな高レベル情報を見つけることができます。ここでエイリアスを追加または削除し、バージョンおよびアーティファクト全体に対してメモを取ることができます。
メタデータパネルは、アーティファクトが構築されたときに提供されるメタデータへのアクセスを提供します。このメタデータには、アーティファクトを再構築するために必要な設定引数、詳細情報を見つけるためのURL、またはアーティファクトをログする際に生成されたメトリクスが含まれている場合があります。さらに、アーティファクトを生成する run の設定や、アーティファクトをログする際の履歴メトリクスを見ることができます。
Usage パネル
Usage パネルは、ウェブアプリの外部で、例えばローカルマシン上で使用するためにアーティファクトをダウンロードするためのコードスニペットを提供します。このセクションはまた、アーティファクトを出力した run 及びアーティファクトを入力として使用する run へのリンクも示しています。
Files パネル
ファイルパネルは、アーティファクトに関連付けられたファイルとフォルダを一覧表示します。W&B は特定のファイルを run 用に自動的にアップロードします。例えば、requirements.txt は run が使用した各ライブラリのバージョンを示し、wandb-metadata.json および wandb-summary.json は run に関する情報を含みます。他のファイルもアーティファクトやメディアなど、run の設定に応じてアップロードされる場合があります。このファイルツリーをナビゲートし、W&B ウェブアプリで直接内容を確認することができます。
Artifacts に関連付けられたテーブル は、このコンテキストでは特にリッチでインタラクティブです。Artifacts で Tables を使用する方法についての詳細はこちら から学べます。
Lineage パネル
リネージパネルは、プロジェクトに関連付けられたすべてのアーティファクトとそれらをお互いに接続する run を表示します。run タイプはブロックとして、アーティファクトは円として表示され、与えられたタイプの run が与えられたタイプのアーティファクトを消費または生成するときに矢印で示されます。左側の列で選択された特定のアーティファクトのタイプが強調表示されます。
個々のアーティファクトバージョンとそれらを接続する特定の run を表示するには、爆発切り替えをクリックしてください。
Action History Audit タブ
アクションヒストリー監査タブは、コレクションのすべてのエイリアスアクションとメンバーシップの変更を示しており、リソースの進化全体を監査できます。
Versions タブ
バージョン タブは、アーティファクトのすべてのバージョンと、バージョンがログ記録された時点での Run History の各数値のカラムを示しています。これにより、パフォーマンスを比較し、興味のあるバージョンを迅速に特定することができます。
プロジェクトにスターを付ける
プロジェクトにスターを付けると、そのプロジェクトを重要としてマークします。あなたとあなたのチームがスター付きで重要としてマークしたプロジェクトは、組織のホームページの上部に表示されます。
たとえば、次の画像では、zoo_experiment と registry_demo の 2 つのプロジェクトが重要としてマークされています。これらのプロジェクトは、組織のホームページの上部の スター付きプロジェクト セクション内に表示されています。
プロジェクトを重要としてマークする方法は2つあります: プロジェクトのオーバービュータブ内またはチームのプロファイルページ内です。
Project overview
Team profile
W&B App の https://wandb.ai/<team>/<project-name> で W&B プロジェクトに移動します。
プロジェクトサイドバーから Overview タブを選択します。
右上隅の Edit ボタンの横にある星アイコンを選択します。
チームのプロファイルページにある https://wandb.ai/<team>/projects に移動します。
Projects タブを選択します。スターを付けたいプロジェクトの横にマウスをホバーし、表示された星アイコンをクリックします。
たとえば、次の画像は “Compare_Zoo_Models” プロジェクトの横にある星アイコンを示しています。
組織名を左上隅のアプリ内でクリックし、プロジェクトが組織のランディングページに表示されることを確認します。
プロジェクトを削除する
プロジェクトを削除するには、オーバービュータブの右の三点リーダーをクリックします。
プロジェクトが空の場合は、右上のドロップダウンメニューをクリックして Delete project を選択し、削除できます。
プロジェクトにメモを追加する
プロジェクトにメモを追加するには、説明オーバービューまたはワークスペース内のマークダウンパネルとして行います。
プロジェクトに説明オーバービューを追加
ページに追加した説明は、プロファイルの Overview タブに表示されます。
W&B プロジェクトに移動
プロジェクトサイドバーから Overview タブを選択
右上隅の Edit を選択
Description フィールドにメモを追加Save ボタンを選択
Create reports to create descriptive notes comparing runs W&B レポートを作成して、プロットやマークダウンを並べて追加することもできます。異なる run を示すために異なるセクションを使用し、取り組んだことについてのストーリーを語ります。
ワークスペースに run のメモを追加
W&B プロジェクトに移動
プロジェクトサイドバーから Workspace タブを選択
右上のコーナーから Add panels ボタンを選択
表示されるモーダルから TEXT AND CODE ドロップダウンを選択
Markdown を選択ワークスペース内に表示されるマークダウンパネルにメモを追加します。
2.1.4 - 実験管理の結果を見る
ランデータを対話的な可視化で探求するためのプレイグラウンド
W&B ワークスペースは、チャートをカスタマイズしモデル結果を探索するための個人のサンドボックスです。W&B ワークスペースは テーブル と パネルセクション で構成されています:
Tables : プロジェクトに記録されたすべてのRunがプロジェクトのテーブルに一覧表示されます。Runをオンオフしたり、色を変更したり、テーブルを拡張して各Runのノート、設定、およびサマリーメトリクスを表示することができます。Panel sections : 1つ以上の パネル を含むセクションです。新しいパネルを作成し、整理し、ワークスペースのスナップショットを保存するためにReportsにエクスポートすることができます。
Workspaceの種類
主に2つのWorkspaceカテゴリがあります: 個人用ワークスペース と 保存されたビュー です。
個人用ワークスペース: モデルとデータの可視化の詳細な分析のためのカスタマイズ可能なワークスペースです。ワークスペースの所有者のみが編集し、変更を保存できます。チームメイトは個人用ワークスペースを閲覧できますが、他の人の個人用ワークスペースには変更を加えることはできません。保存されたビュー: 保存されたビューは、ワークスペースの協力的なスナップショットです。チームの誰もが保存されたワークスペースビューを閲覧、編集、保存することができます。保存されたワークスペースビューを使用して、実験、Runなどをレビューおよび議論します。
次の画像は、Cécile-parkerのチームメイトによって作成された複数の個人用ワークスペースを示しています。このプロジェクトには保存されたビューがありません:
保存されたワークスペースビュー
チームのコラボレーションを向上させるために、カスタマイズされたワークスペースビューを作成します。保存されたビューを作成して、チャートとデータの好みのセットアップを整理します。
新しい保存されたワークスペースビューを作成する
個人用ワークスペースまたは保存されたビューに移動します。
ワークスペースを編集します。
ワークスペースの右上隅にある三つポチメニュー（三本の横線）をクリックし、新しいビューとして保存 をクリックします。
新しい保存されたビューはワークスペースナビゲーションメニューに表示されます。
保存されたワークスペースビューを更新する
保存された変更は、保存されたビューの以前の状態を上書きします。保存されていない変更は保持されません。W&Bで保存されたワークスペースビューを更新するには:
保存されたビューに移動します。
ワークスペース内のチャートとデータに必要な変更を加えます。
保存 ボタンをクリックして変更を確認します。
ワークスペースビューの更新を保存すると、確認ダイアログが表示されます。次回このプロンプトを表示しないようにするには、保存を確認する前に 今後このモーダルを表示しない オプションを選択します。
保存されたワークスペースビューを削除する
不要になった保存されたビューを削除します。
削除したい保存済みビューに移動します。
ビューの右上隅にある三本の横線（… ）を選択します。
ビューを削除 を選択します。削除を確認してワークスペースメニューからビューを削除します。
ワークスペースビューを共有する
ワークスペースのURLを直接共有することで、カスタマイズしたワークスペースをチームと共有します。ワークスペースプロジェクトにアクセスできるすべてのユーザーが、そのワークスペースの保存されたビューを見ることができます。
ワークスペースをプログラムで作成する
wandb-workspacesW&B のワークスペースとレポートをプログラムで操作するためのPythonライブラリです。
wandb-workspaceswandb-workspacesW&B のワークスペースとレポートをプログラムで操作するためのPythonライブラリです。
ワークスペースのプロパティを定義できます、例:
パネルのレイアウト、色、およびセクションの順序を設定します。
ワークスペース設定としてデフォルトのX軸、セクションの順序、および折りたたみ状態を設定します。
セクション内にパネルを追加してカスタマイズし、ワークスペースビューを整理します。
URLを使用して既存のワークスペースを読み込み、変更します。
既存のワークスペースに変更を保存するか、新しいビューとして保存します。
シンプルな式を使用してRunをプログラムでフィルタリング、グループ化、ソートします。
色や表示可否などの設定でRunの外観をカスタマイズします。
ワークスペース間でビューをコピーして、インテグレーションと再利用を行います。
Workspace API をインストール
wandbに加えて、wandb-workspacesをインストールすることを確認してください:
pip install wandb wandb-workspaces
プログラムでワークスペースビューを定義し保存する
import wandb_workspaces.reports.v2 as wr
workspace = ws. Workspace(entity= "your-entity" , project= "your-project" , views= [... ])
workspace. save()
既存のビューを編集する
existing_workspace = ws. Workspace. from_url("workspace-url" )
existing_workspace. views[0 ] = ws. View(name= "my-new-view" , sections= [... ])
existing_workspace. save()
ワークスペース 保存されたビュー を別のワークスペースにコピーする
old_workspace = ws. Workspace. from_url("old-workspace-url" )
old_workspace_view = old_workspace. views[0 ]
new_workspace = ws. Workspace(entity= "new-entity" , project= "new-project" , views= [old_workspace_view])
new_workspace. save()
包括的なワークスペースAPIの例として、wandb-workspace examplesProgrammatic Workspaces チュートリアルを参照してください。
2.1.5 - runs とは何ですか？
W&B の基本的な構成要素である Run について学びましょう。
W&B の run とは、W&B によってログ記録された単一の計算単位のことです。W&B の run をプロジェクト全体の原子要素として考えることができます。言い換えれば、各 run とは特定の計算の記録であり、モデルのトレーニング、結果のログ記録、ハイパーパラメータースイープなどを含みます。
run を開始する一般的なパターンには以下が含まれますが、これらに限定されません：
W&B はあなたが作成した run を projects に保存します。W&B App UI 上でプロジェクトのワークスペース内の run とそのプロパティを表示できます。また、wandb.Api.Run
run.log でログ記録したものは、その run に記録されます。次のコードスニペットを考えてみてください。
import wandb
run = wandb. init(entity= "nico" , project= "awesome-project" )
run. log({"accuracy" : 0.9 , "loss" : 0.1 })
最初の行は W&B Python SDK をインポートします。2 行目はエンティティ nico のプロジェクト awesome-project で run を初期化します。3 行目はその run に対するモデルの精度と損失をログ記録します。
ターミナル内で、W&B は次のように返します：
wandb: Syncing run earnest-sunset-1
wandb: ⭐️ View project at https://wandb.ai/nico/awesome-project
wandb: 🚀 View run at https://wandb.ai/nico/awesome-project/runs/1jx1ud12
wandb:
wandb:
wandb: Run history:
wandb: accuracy ▁
wandb: loss ▁
wandb:
wandb: Run summary:
wandb: accuracy 0.9
wandb: loss 0.5
wandb:
wandb: 🚀 View run earnest-sunset-1 at: https://wandb.ai/nico/awesome-project/runs/1jx1ud12
wandb: ⭐️ View project at: https://wandb.ai/nico/awesome-project
wandb: Synced 6 W&B file( s) , 0 media file( s) , 0 artifact file( s) and 0 other file( s)
wandb: Find logs at: ./wandb/run-20241105_111006-1jx1ud12/logs
W&B がターミナルで返す URL は、W&B App UI 上で run のワークスペースにリダイレクトします。ワークスペースで生成されたパネルは単一のポイントに対応していることに注意してください。
単一時点でメトリクスをログ記録することはあまり有用ではないかもしれません。識別モデルのトレーニングの場合、定期的な間隔でメトリクスをログ記録することがより現実的です。以下のコードスニペットを考慮してください：
epochs = 10
lr = 0.01
run = wandb. init(
entity= "nico" ,
project= "awesome-project" ,
config= {
"learning_rate" : lr,
"epochs" : epochs,
},
)
offset = random. random() / 5
# トレーニング run のシミュレーション
for epoch in range(epochs):
acc = 1 - 2 **- epoch - random. random() / (epoch + 1 ) - offset
loss = 2 **- epoch + random. random() / (epoch + 1 ) + offset
print(f "epoch= { epoch} , accuracy= { acc} , loss= { loss} " )
run. log({"accuracy" : acc, "loss" : loss})
これは次のような出力を返します：
wandb: Syncing run jolly-haze-4
wandb: ⭐️ View project at https://wandb.ai/nico/awesome-project
wandb: 🚀 View run at https://wandb.ai/nico/awesome-project/runs/pdo5110r
lr: 0.01
epoch= 0, accuracy= -0.10070974957523078, loss= 1.985328507123956
epoch= 1, accuracy= 0.2884687745057535, loss= 0.7374362314407752
epoch= 2, accuracy= 0.7347387967382066, loss= 0.4402409835486663
epoch= 3, accuracy= 0.7667969248039795, loss= 0.26176963846423457
epoch= 4, accuracy= 0.7446848791003173, loss= 0.24808611724405083
epoch= 5, accuracy= 0.8035095836268268, loss= 0.16169791827329466
epoch= 6, accuracy= 0.861349032371624, loss= 0.03432578493587426
epoch= 7, accuracy= 0.8794926436276016, loss= 0.10331872172219471
epoch= 8, accuracy= 0.9424839917077272, loss= 0.07767793473500445
epoch= 9, accuracy= 0.9584880427028566, loss= 0.10531971149250456
wandb: 🚀 View run jolly-haze-4 at: https://wandb.ai/nico/awesome-project/runs/pdo5110r
wandb: Find logs at: wandb/run-20241105_111816-pdo5110r/logs
トレーニングスクリプトは run.log を10回呼び出します。スクリプトが run.log を呼び出すたびに、W&B はそのエポックの精度と損失をログ記録します。前述の出力から W&B が出力する URL を選択すると、その run のワークスペースに直接アクセスできます。
W&B は、シミュレーションしたトレーニングループを jolly-haze-4 という単一の run 内にキャプチャします。これは、スクリプトが wandb.init メソッドを一度だけ呼び出しているためです。
別の例として、スイープ の際、W&B はあなたが指定したハイパーパラメーター探索空間を探索します。スイープが作成する各新しいハイパーパラメーターの組み合わせを、一意の run として実装します。
run を初期化する
W&B run は wandb.init()
角括弧 (< >) で囲まれた値をあなた自身の値に置き換えるようにしてください：
import wandb
run = wandb. init(entity= "<entity>" , project= "<project>" )
run を初期化すると、W&B は指定したプロジェクトに対して run をログに記録します (wandb.init(project="<project>"))。プロジェクトがまだ存在しない場合、W&B は新しいプロジェクトを作成します。プロジェクトが既に存在する場合、W&B はそのプロジェクトに run を保存します。
プロジェクト名を指定しない場合、W&B は run を Uncategorized というプロジェクトに保存します。
W&B の各 run には、run ID という一意の識別子一意の ID を指定することができます し、または W&B がランダムに生成してくれる ことも可能です。
各 run には、人間が読めるrun 名 という一意でない識別子
たとえば、次のコードスニペットを考えてみてください：
import wandb
run = wandb. init(entity= "wandbee" , project= "awesome-project" )
このコードスニペットは次の出力を生成します：
🚀 View run exalted-darkness-6 at:
https://wandb.ai/nico/awesome-project/runs/pgbn9y21
Find logs at: wandb/run-20241106_090747-pgbn9y21/logs
前のコードが id 引数を指定しなかったため、W&B は一意の run ID を作成します。ここで、nico は run を記録したエンティティであり、awesome-project は run が記録されるプロジェクトの名前、 exalted-darkness-6 は run の名前、pgbn9y21 は run ID です。
ノートブックユーザー run の末尾で run.finish() を指定して run を終了したことを示してください。これにより、run がプロジェクトに正しくログ記録され、バックグラウンドで継続されないようにするのに役立ちます。
import wandb
run = wandb. init(entity= "<entity>" , project= "<project>" )
# トレーニングコード、ログ記録など
run. finish()
各 run には、run の現在のステータスを示す状態があります。可能な run 状態の完全なリストについては Run states を参照してください。
Run states
次の表は、run がとりうる可能な状態を示しています：
状態
説明
Finished
Run が終了し、完全にデータを同期した、または wandb.finish() を呼び出した
Failed
Run が終了し、非ゼロの終了ステータス
Crashed
Run は内部プロセスでハートビートを送信するのを停止しました（マシンがクラッシュした場合など）
Running
Run がまだ実行中で、最近ハートビートを送信している
Unique run identifiers
Run ID は run のための一意の識別子です。デフォルトでは、新しい run を初期化する際に、W&B はランダムで一意の run ID を生成します 。また、run を初期化する際に独自の一意の run ID を指定することもできます 。
Autogenerated run IDs
run を初期化する際に run ID を指定しない場合、W&B はランダムな run ID を生成します。run の一意の ID は W&B App UI で確認できます。
https://wandb.ai/home の W&B App UI にアクセスします。run を初期化した際に指定した W&B プロジェクトに移動します。
プロジェクトのワークスペース内で、 Runs タブを選択します。
Overview タブを選択します。
W&B は Run path フィールドに一意の run ID を表示します。run path はチーム名、プロジェクト名、run ID で構成されています。一意の ID は run path の最後の部分です。
たとえば、以下の画像では、一意の run ID は 9mxi1arc です：
Custom run IDs
id 引数をwandb.init
import wandb
run = wandb. init(entity= "<project>" , project= "<project>" , id= "<run-id>" )
run の一意の ID を使用して W&B App UI の run の概要ページに直接移動できます。次のセルは特定の run の URL パスを示しています：
https://wandb.ai/<entity>/<project>/<run-id>
ここで、角括弧 (< >) で囲まれた値は、エンティティ、プロジェクト、および run ID の実際の値のためのプレースホルダーです。
Name your run
run の名前は、人間が読める非一意の識別子です。
デフォルトでは、W&B は新しい run を初期化する際にランダムな run 名を生成します。run の名前はプロジェクトのワークスペース内およびrun の概要ページ の上部に表示されます。
run の名前を使用してプロジェクトワークスペース内で run を素早く識別する方法として活用してください。
run の名前を指定するには、name 引数をwandb.init
import wandb
run = wandb. init(entity= "<project>" , project= "<project>" , name= "<run-name>" )
run にメモを追加
特定の run に追加したメモは、run ページの Overview タブやプロジェクトページの run 一覧表に表示されます。
あなたの W&B プロジェクトに移動します。
プロジェクトのサイドバーから Workspace タブを選択します。
run セレクタからメモを追加したい run を選択します。
Overview タブを選択します。Description フィールド隣の鉛筆アイコンを選択して、メモを追加します。
run を停止する
W&B App またはプログラムを使用して run を停止します。
run を初期化したターミナルまたはコードエディタに移動します。
Ctrl+D を押して run を停止します。
たとえば、前述の手順に従うと、ターミナルは次のような状態になるかもしれません：
KeyboardInterrupt
wandb: 🚀 View run legendary-meadow-2 at: https://wandb.ai/nico/history-blaster-4/runs/o8sdbztv
wandb: Synced 5 W&B file( s) , 0 media file( s) , 0 artifact file( s) and 1 other file( s)
wandb: Find logs at: ./wandb/run-20241106_095857-o8sdbztv/logs
W&B App UI に移動して run がもはやアクティブではないことを確認します：
run のログを記録していたプロジェクトに移動します。
run の名前を選択します。
停止した run の名前はターミナルまたはコードエディタの出力から見つけることができます。たとえば、前の例では、run の名前は legendary-meadow-2 です。
3. プロジェクトのサイドバーから **Overview** タブを選択します。
State フィールドの隣で、run の状態が running から Killed に変わります。
run のログを記録していたプロジェクトに移動します。
run セレクタ内で停止したい run を選択します。
プロジェクトのサイドバーから Overview タブを選択します。
State フィールドの隣の上部ボタンを選択します。
State フィールドの隣で、run の状態が running から Killed に変わります。
State fields を参照し、run の可能な状態の完全なリストを確認してください。
ログ記録された runs を見る
run の状態、run にログ記録されたアーティファクト、run 中に記録されたログファイルなど、特定の run に関する情報を表示します。
特定の run を表示するには：
https://wandb.ai/home の W&B App UI に移動します。
run を初期化した際に指定した W&B プロジェクトに移動します。
プロジェクトのサイドバー内で Workspace タブを選択します。
run セレクタ内で表示したい run をクリックするか、部分的な run 名を入力して一致する runs をフィルターします。
デフォルトでは、長い run 名は読みやすくするために途中で切り詰められます。run 名を最初または最後で切り詰めるには、run リストの上部のアクション ... メニューをクリックし、Run name cropping を最初、途中、または最後で切り取るように設定します。
特定の run の URL パスの形式は次のとおりです：
https://wandb.ai/<team-name>/<project-name>/runs/<run-id>
ここで、角括弧 (< >) で囲まれた値は、チーム名、プロジェクト名、および run ID の実際の値のためのプレースホルダーです。
Overview タブ
プロジェクト内で特定の run 情報を知るために Overview タブを使用してください。
Author : run を作成した W&B エンティティ。Command : run を初期化したコマンド。Description : 提供した run の説明。このフィールドは、run を作成する際に説明を指定しないと空になります。W&B App UI または Python SDK を使用して run に説明を追加できます。Duration : run が実際に計算を行っている時間またはデータをログ記録している時間。ただし、任意の中断または待機時間は含まれません。Git repository : run に関連付けられた git リポジトリ。このフィールドを見るためにはgit を有効にする 必要があります。Host name : W&B が run を計算する場所。ローカルマシンで run を初期化した場合、マシンの名前が表示されます。Name : run の名前。OS : run を初期化するオペレーティングシステム。Python executable : run を開始するためのコマンド。Python version : run を作成する Python バージョンを指定します。Run path : entity/project/run-ID 形式で一意の run ID を識別します。Runtime : run の開始から終了までの総時間を測定します。run の壁時計時間であり、run が中断したりリソースを待っている間の時間も含まれますが、duration は含みません。Start time : run を初期化した時点のタイムスタンプ。State : run の状態 。System hardware : W&B が run を計算するために使用するハードウェア。Tags : 文字列のリスト。タグは関連 run を一緒に整理したり、一時的なラベル（例：baseline や production）を適用するのに便利です。W&B CLI version : run コマンドをホストしたマシンにインストールされている W&B CLI バージョン。
W&B は概要セクションの下に次の情報を保存します：
Artifact Outputs : run が生成したアーティファクトの出力。Config : wandb.configSummary : wandb.log()
こちらでプロジェクトの概要の例を確認できます here 。
Workspace タブ
Workspace タブを使用して、生成されたプロットやカスタムプロット、システムメトリクスなどの可視化を表示、検索、グループ化、および配置してください。
こちらでワークスペースの例を確認できます here
Runs タブ
Runs タブを使用して、run をフィルタリング、グループ化、並べ替えます。
Runs タブで実行できる一般的なアクションを以下のタブで示しています。
Runs タブには、プロジェクト内の run の詳細が表示されます。デフォルトでは多くの列が表示されます。
表示されているすべての列を表示するには、ページを横にスクロールします。
列の順序を変更するには、列を左右にドラッグします。
列を固定するには、列名の上にカーソルを合わせ、表示されたアクションメニュー ... をクリックしてから Pin column をクリックします。固定された列はページの左側に近い位置に表示されます。固定列を解除するには、Unpin column を選択します。
列を非表示にするには、列名の上にカーソルを合わせ、表示されたアクションメニュー ... をクリックしてから Hide column をクリックします。現在非表示のすべての列を表示するには、Columns をクリックします。
一度に複数の列を表示、非表示、固定、または固定解除するには、Columns をクリックします。
非表示の列の名前をクリックして表示します。
表示されている列の名前をクリックして非表示にします。
表示された列の横にあるピンアイコンをクリックして固定します。
Runs タブをカスタマイズすると、そのカスタマイズは Workspace タブ の Runs セレクタにも反映されます。
Table のある列の値で全行を並べ替えます。
列タイトルにマウスを合わせます。ケバブメニュー（3つの垂直な点）が現れます。
ケバブメニュー（3つの垂直な点）を選択します。
並べ替え指定を選択して、降順または昇順で行を並べ替える。
上記の画像は、val_acc と呼ばれる Table 列の並べ替えオプションを表示する方法を示しています。
フィルターボタン上の式を使用したすべての行のフィルタリング、ダッシュボード上部のフィルターボタンを使用できます。
行に1つ以上のフィルターを追加するには、Add filter を選択します。3 つのドロップダウンメニューが表示されます。左から右へのフィルタータイプは、列名、オペレーター、値に基づいています。る。
列名
二項関係
値
受け入れ値
ストリング
=, ≠, ≤, ≥, IN, NOT IN,
整数、浮動小数点、ストリング、タイムスタンプ、null
行編集案では、列名と論理述語構造に基づいてオートコンプリートを行い、各項目のオプションを示します。複数の論理述語を使用して「and」または「or」（場合によっては括弧）で1つの式に接続できます。
上記の画像は、`val_loss` 列に基づいたフィルターを示しています。フィルターは、検証損失が1以下の run を表示します。
ダッシュボード上の Group by ボタンを使用して、特定の列の値で全行をグループ化します。
デフォルトでは、これにより他の数値列が、その列のグループ全体の値の分布を示すヒストグラムに変わります。グループ化は、データ内のより高水準のパターンを理解するのに役立ちます。
Logs タブ
Log tab には、標準出力 (stdout) や標準エラー (stderr) などのコマンドラインに出力されたものが表示されます。
右上の「ダウンロード」ボタンを選択してログファイルをダウンロードします。
ログタブの例はこちらから見ることができます here .
Files タブ
Files tab を使用して、特定の run に関連付けられたファイル（モデルチェックポイント、検証セット例など）を表示してください。
ファイルタブの例はこちらから見ることができます here .
Artifacts タブ
Artifacts タブには、指定した run の入力および出力 Artifacts が一覧表示されます。
Artifacts タブの例はこちらから見ることができます here .
Run を削除する
W&B App を使用してプロジェクトから 1 つ以上の run を削除します。
削除したい runs を含むプロジェクトに移動します。
プロジェクトのサイドバーから Runs タブを選択します。
削除したい runs の横のチェックボックスを選択します。
テーブルの上部に表示される Delete ボタン（ゴミ箱アイコン）を選択します。
表示されたモーダルで Delete を選択します。
特定の ID を持つ run が削除された場合、その ID は再び使用されないことに注意してください。削除された ID で run を開始しようとするとエラーが表示され、開始が防止されます。
多くの run を含むプロジェクトでは、検索バーを使用して削除したい run を正規表現を使用してフィルタリングするか、ステータス、タグ、または他のプロパティに基づいて run をフィルターするためのフィルターボタンを使用することができます。
Run を整理する
このセクションでは、グループとジョブタイプを使用して run を整理する方法についての手順を紹介します。 run をグループ（たとえば、実験名）に割り当て、ジョブタイプ（たとえば、前処理、トレーニング、評価、デバッグ）を指定することで、ワークフローを簡素化し、モデルの比較を改善できます。
Run にグループまたはジョブタイプを割り当てる
W&B の各 run は グループ と ジョブタイプ で分類できます：
グループ ：実験の広範なカテゴリで、run を整理およびフィルタリングするために使用されます。ジョブタイプ ：run の機能で、preprocessing や training、evaluation のようなものです。
次のワークスペースの例 では、Fashion-MNIST データセットからの増加するデータ量を使用してベースラインモデルをトレーニングしています。ワークスペースは使用されたデータ量を示すために色を使用します：
黄色から濃緑 は、ベースラインモデルのためのデータ量の増加を示しています。薄い青から紫、マゼンタ は、追加パラメーターを持つより複雑な「ダブル」モデルのためのデータ量を示しています。
W&B のフィルタリングオプションや検索バーを使用して、次のような特定の条件に基づいて run を比較します：
同じデータセットに対するトレーニング。
同じテストセットに対する評価。
フィルターを適用する際、Table ビューは自動的に更新されます。これにより、モデル間のパフォーマンスの違い（たとえば、どのクラスが他のモデルと比べてはるかに難しいか）を特定することができます。
2.1.5.1 - run をフィルタリングし検索する
プロジェクトページのサイドバーとテーブルの使い方
プロジェクトページを使用して、W&B にログされた run からインサイトを得ることができます。Workspace ページと Runs ページの両方で、run をフィルタリングおよび検索できます。
run をフィルタリングする
ステータス、タグ、またはその他のプロパティに基づいて、フィルター ボタンを使用して run をフィルタリングします。
タグで run をフィルタリングする
フィルター ボタンを使用して、タグに基づいて run をフィルタリングします。
正規表現で run をフィルタリングする
正規表現で望む結果が得られない場合は、タグ を使用して Runs Table で run をフィルタリングすることができます。タグは run 作成時、または完了後に追加できます。一旦タグが run に追加されると、以下の gif に示されているように、タグ フィルターを追加できます。
run を検索する
指定した正規表現を使用して run を見つけるには、regex を使用します。検索ボックスにクエリを入力すると、ワークスペースのグラフで表示される run がフィルタリングされ、テーブルの行もフィルタリングされます。
run をグループ化する
1 つまたは複数の列（隠し列を含む）で run をグループ化するには:
検索ボックスの下にある、罫線のついた紙のように見える Group ボタンをクリックします。
結果をグループ化する 1 つ以上の列を選択します。
グループ化された各 run セットはデフォルトで折りたたまれています。展開するには、グループ名の横にある矢印をクリックします。
最小値と最大値で run を並べ替える
ログされたメトリクスの最小値または最大値で run テーブルを並べ替えます。これは、記録された最良または最悪の値を表示したい場合に特に便利です。
次の手順は、記録された最小値または最大値に基づいて特定のメトリクスで run テーブルを並べ替える方法を説明します：
並べ替えたいメトリクスを含む列にマウスを合わせます。
ケバブ メニュー（三本の縦線）を選択します。
ドロップダウンから、Show min または Show max を選択します。
同じドロップダウンから、Sort by asc または Sort by desc を選択して、それぞれ昇順または降順で並べ替えます。
run の終了時間を検索する
クライアントプロセスからの最後のハートビートをログする End Time という名前の列を提供します。このフィールドはデフォルトでは非表示になっています。
run テーブルを CSV にエクスポートする
すべての run、ハイパーパラメーター、およびサマリーメトリクスのテーブルを、ダウンロード ボタンを使用して CSV にエクスポートします。
2.1.5.2 - run をフォークする
W&B run をフォークする
run をフォークする機能はプライベートプレビューです。この機能へのアクセスをリクエストするには、support@wandb.com まで W&B サポートにお問い合わせください。
run を初期化する際に fork_from を使用して、既存の W&B run から"フォーク"します。run をフォークすると、W&B はソース run の run ID と step を使用して新しい run を作成します。
run をフォークすることで、元の run に影響を与えずに、実験の特定のポイントから異なるパラメータやモデルを探索することができます。
run のフォークには wandb
run のフォークには、単調に増加するステップが必要です。define_metric()
フォークされた run を開始する
run をフォークするには、wandb.init()fork_from 引数を使用し、フォーク元としてのソース run ID と step を指定します:
import wandb
# 後でフォークするための run を初期化
original_run = wandb. init(project= "your_project_name" , entity= "your_entity_name" )
# ... トレーニングやログを実行 ...
original_run. finish()
# 特定のステップから run をフォーク
forked_run = wandb. init(
project= "your_project_name" ,
entity= "your_entity_name" ,
fork_from= f " { original_run. id} ?_step=200" ,
)
不変の run ID を使用する
不変の run ID を使用して、特定の run への一貫性のある変更不可能な参照を保証します。ユーザーインターフェースから不変の run ID を取得するには、次の手順に従います:
Overview タブにアクセスする: ソース run のページで Overview タブ
不変の Run ID をコピーする: Overview タブの右上隅にある ... メニュー（三点ドット）をクリックします。ドロップダウンメニューから Copy Immutable Run ID オプションを選択します。
これらの手順を追うことで、フォークされた run に使用できる安定した変更不可能な run への参照を得ることができます。
フォークされた run から続行する
フォークされた run を初期化した後、新しい run にログを続行することができます。同じメトリクスをログすることで連続性を持たせ、新しいメトリクスを導入することも可能です。
例えば、次のコード例では、最初に run をフォークし、次にトレーニングステップ 200 からフォークされた run にメトリクスをログする方法を示しています:
import wandb
import math
# 最初の run を初期化し、いくつかのメトリクスをログ
run1 = wandb. init("your_project_name" , entity= "your_entity_name" )
for i in range(300 ):
run1. log({"metric" : i})
run1. finish()
# 特定のステップから最初の run をフォークし、ステップ 200 からメトリクスをログ
run2 = wandb. init(
"your_project_name" , entity= "your_entity_name" , fork_from= f " { run1. id} ?_step=200"
)
# 新しい run でログを続行
# 最初のいくつかのステップで、run1 からそのままメトリクスをログ
# ステップ 250 以降、スパイキーなパターンをログする
for i in range(200 , 300 ):
if i < 250 :
run2. log({"metric" : i}) # スパイクなしで run1 からログを続行
else :
# ステップ 250 からスパイキーな振る舞いを導入
subtle_spike = i + (2 * math. sin(i / 3.0 )) # 微細なスパイキーパターンを適用
run2. log({"metric" : subtle_spike})
# さらに、すべてのステップで新しいメトリクスをログ
run2. log({"additional_metric" : i * 1.1 })
run2. finish()
巻き戻しとフォークの互換性 フォークは、あなたの run を管理し実験する上でより多くの柔軟性を提供することにより、巻き戻し
run をフォークする際、W&B は特定のポイントで run から新しいブランチを作成し、異なるパラメータやモデルを試みることができます。
run を巻き戻す際、W&B は run 履歴自体を修正または変更することができます。
2.1.5.3 - run を移動する
このページでは、run を別のプロジェクト間で、またはチーム内外、またはあるチームから別のチームへの移動方法を示します。現在の場所と新しい場所の両方で run へのアクセス権が必要です。
Runs タブをカスタマイズするには、Project page を参照してください。
プロジェクト間で run を移動する
run をあるプロジェクトから別のプロジェクトに移動するには:
移動したい run を含むプロジェクトに移動します。
プロジェクトのサイドバーから Runs タブを選択します。
移動したい run の横にあるチェックボックスを選択します。
テーブルの上にある Move ボタンを選択します。
ドロップダウンから移動先のプロジェクトを選択します。
チームに run を移動する
あなたがメンバーであるチームに run を移動するには:
移動したい run を含むプロジェクトに移動します。
プロジェクトのサイドバーから Runs タブを選択します。
移動したい run の横にあるチェックボックスを選択します。
テーブルの上にある Move ボタンを選択します。
ドロップダウンから移動先のチームとプロジェクトを選択します。
2.1.5.4 - run を巻き戻す
巻き戻す
runを巻き戻す
runを巻き戻すオプションはプライベートプレビューです。この機能へのアクセスをリクエストするには、W&Bサポート(support@wandb.com )までお問い合わせください。
現在、W&Bがサポートしていないもの:
ログの巻き戻し : 新しいrunセグメントでログがリセットされます。システムメトリクスの巻き戻し : W&Bは巻き戻しポイントの後にのみ新しいシステムメトリクスをログします。アーティファクトの関連付け : W&Bは生成されたアーティファクトをそのソースrunに関連付けます。
runを巻き戻して、元のデータを失うことなくrunの履歴を修正または変更します。さらに、runを巻き戻すと、その時点から新しいデータをログすることができます。W&Bは、新しい履歴に基づく巻き戻し対象のrunのサマリーメトリクスを再計算します。これは以下の振る舞いを意味します:
履歴の切断 : W&Bは巻き戻しポイントまで履歴を切断し、新しいデータのログを可能にします。サマリーメトリクス : 新しい履歴に基づいて再計算されます。設定の保持 : W&Bは元の設定を保持し、新しい設定をマージすることができます。
runを巻き戻すと、W&Bは指定されたステップにrunの状態をリセットし、元のデータを保持し、一貫したrun IDを維持します。これは次のことを意味します:
runのアーカイブ : W&Bは元のrunをアーカイブします。runはRun Overview アーティファクトの関連付け : アーティファクトを生成するrunと関連付けます。不変のrun ID : 正確な状態からフォークするための一貫性が導入されます。不変のrun IDをコピー : run管理を改善するために不変のrun IDをコピーするボタンがあります。
巻き戻しとフォークの互換性 フォークは巻き戻しと補完し合います。
runからフォークすると、W&Bは特定のポイントでrunを分岐させて異なるパラメータやモデルを試します。
runを巻き戻すと、W&Bはrun履歴そのものを修正または変更することを可能にします。
runを巻き戻す
resume_fromをwandb.init()
import wandb
import math
# 最初のrunを初期化していくつかのメトリクスをログする
# your_project_nameとyour_entity_nameを置き換えてください!
run1 = wandb. init(project= "your_project_name" , entity= "your_entity_name" )
for i in range(300 ):
run1. log({"metric" : i})
run1. finish()
# 最初のrunの特定のステップから巻き戻してステップ200からメトリクスをログする
run2 = wandb. init(project= "your_project_name" , entity= "your_entity_name" , resume_from= f " { run1. id} ?_step=200" )
# 新しいrunでログを続ける
# 最初のいくつかのステップでは、run1からメトリクスをそのままログする
# ステップ250以降、尖ったパターンのログを開始する
for i in range(200 , 300 ):
if i < 250 :
run2. log({"metric" : i, "step" : i}) # スパイクなしでrun1からログを続行
else :
# ステップ250から尖った振る舞いを導入
subtle_spike = i + (2 * math. sin(i / 3.0 )) # subtleなスパイクパターンを適用
run2. log({"metric" : subtle_spike, "step" : i})
# さらに新しいメトリクスをすべてのステップでログ
run2. log({"additional_metric" : i * 1.1 , "step" : i})
run2. finish()
アーカイブされたrunを見る
runを巻き戻した後、W&B App UIでアーカイブされたrunを探索できます。以下のステップに従ってアーカイブされたrunを表示します:
Overviewタブにアクセスする : runのページでOverviewタブ Forked Fromフィールドを見つける : Overview タブ内で、Forked Fromフィールドを見つけます。このフィールドは再開の履歴を記録します。Forked From フィールドにはソースrunへのリンクが含まれており、オリジナルのrunに遡り、全体の巻き戻し履歴を理解することができます。
Forked Fromフィールドを使用することで、アーカイブされた再開のツリーを簡単にナビゲートし、それぞれの巻き戻しの順序と起源についての洞察を得ることができます。
巻き戻されたrunからフォークする
巻き戻されたrunからフォークするには、wandb.init()のfork_from
import wandb
# 特定のステップからrunをフォークする
forked_run = wandb. init(
project= "your_project_name" ,
entity= "your_entity_name" ,
fork_from= f " { rewind_run. id} ?_step=500" ,
)
# 新しいrunでログを続ける
for i in range(500 , 1000 ):
forked_run. log({"metric" : i* 3 })
forked_run. finish()
2.1.5.5 - run を再開
一時停止または終了した W&B Run を再開する
実行が停止またはクラッシュした場合にどのように動作するべきかを指定します。実行を再開または自動的に再開するためには、その実行に関連付けられた一意の実行IDをidパラメータとして指定する必要があります。
run = wandb. init(entity= "<entity>" , \
project= "<project>" , id= "<run ID>" , resume= "<resume>" )
W&Bは、実行を保存したいW&B Projectの名前を指定することをお勧めします。
W&Bがどのように対応するかを決定するために、次の引数の1つをresumeパラメータに渡します。各場合において、W&Bは最初に実行IDが既に存在するかを確認します。
引数
説明
実行IDが存在する場合
実行IDが存在しない場合
ユースケース
"must"W&Bは実行IDで指定された実行を再開する必要があります。
同じ実行IDで実行を再開します。
W&Bがエラーを発生させます。
同じ実行IDを使用する必要がある実行を再開します。
"allow"実行IDが存在する場合、W&Bが実行を再開することを許可します。
同じ実行IDで実行を再開します。
指定された実行IDで新しい実行を初期化します。
既存の実行を上書きせずに実行を再開します。
"never"実行IDで指定された実行をW&Bが再開することを許可しない。
W&Bがエラーを発生させます。
指定された実行IDで新しい実行を初期化します。
resume="auto"を指定することで、W&Bが自動的にあなたの代わりに実行を再開しようとします。ただし、同じディレクトリーから実行を再開することを保証する必要があります。詳細は、実行を自動的に再開する設定を有効にする セクションを参照してください。
以下の例では、<>で囲まれた値をあなた自身のものに置き換えてください。
同じ実行IDを使用して実行を再開する
実行が停止、クラッシュ、または失敗した場合、同じ実行IDを使用して再開できます。これを行うには、実行を初期化し、以下を指定します。
resumeパラメータを"must"に設定します（resume="must"）。停止またはクラッシュした実行の実行IDを指定します。
以下のコードスニペットは、W&B Python SDKでこれを達成する方法を示しています。
run = wandb. init(entity= "<entity>" , \
project= "<project>" , id= "<run ID>" , resume= "must" )
複数のプロセスが同じidを同時に使用すると予期しない結果が発生します。
複数プロセスの管理方法については、分散トレーニング実験のログ を参照してください。
既存の実行を上書きせずに実行を再開する
停止またはクラッシュした実行を、既存の実行を上書きせずに再開します。これは、プロセスが正常に終了しない場合に特に役立ちます。次回W&Bを開始すると、W&Bは最後のステップからログを開始します。
W&Bで実行を初期化する場合、resumeパラメータを"allow"(resume="allow")で設定します。停止またはクラッシュした実行の実行IDを指定します。以下のコードスニペットは、W&B Python SDKでこれを達成する方法を示しています。
import wandb
run = wandb. init(entity= "<entity>" , \
project= "<project>" , id= "<run ID>" , resume= "allow" )
実行を自動的に再開するように設定を有効にする
以下のコードスニペットは、Python SDKまたは環境変数を使用して実行を自動的に再開する方法を示します。
以下のコードスニペットは、Python SDKでW&B実行IDを指定する方法を示しています。
<>で囲まれた値をあなた自身のものに置き換えてください。
run = wandb. init(entity= "<entity>" , \
project= "<project>" , id= "<run ID>" , resume= "<resume>" )
次の例は、bashスクリプトでW&B WANDB_RUN_ID変数を指定する方法を示しています。
RUN_ID= " $1"
WANDB_RESUME= allow WANDB_RUN_ID= " $RUN_ID" python eval.py
ターミナル内で、W&B実行IDと共にシェルスクリプトを実行できます。次のコードスニペットは実行ID akj172を渡します。
sh run_experiment.sh akj172
自動再開は、プロセスが失敗したプロセスと同じファイルシステムの上で再起動された場合にのみ機能します。
例えば、train.pyというPythonスクリプトをUsers/AwesomeEmployee/Desktop/ImageClassify/training/というディレクトリーで実行するとします。train.py内で、自動再開を有効にする実行が作成されます。次にトレーニングスクリプトが停止されたとします。この実行を再開するには、Users/AwesomeEmployee/Desktop/ImageClassify/training/内でtrain.pyスクリプトを再起動する必要があります。
ファイルシステムを共有できない場合は、
WANDB_RUN_ID環境変数を指定するか、W&B Python SDKで実行IDを渡します。実行IDの詳細は、“What are runs?“ページの
カスタム実行ID セクションを参照してください。
中断可能なSweepsの実行を再開する
中断されたスイープ実行を自動的に再キューします。これは、スイープエージェントを停止の対象となる計算環境（SLURMジョブの中断可能なキュー、EC2スポットインスタンス、Google Cloud中断可能VMなど）で実行する場合に特に役立ちます。
mark_preempting
run = wandb. init() # 実行を初期化
run. mark_preempting()
以下の表は、スイープ実行の終了ステータスに基づいてW&Bが実行をどのように扱うかを概説しています。
ステータス
振る舞い
ステータスコード0
実行は成功裏に終了したと見なされ、再キューされません。
非ゼロステータス
W&Bは自動的に実行をスイープに関連付けられたランキューに追加します。
ステータスなし
実行はスイープランキューに追加されます。スイープエージェントは、キューが空になるまでランキューから実行を消費します。キューが空になると、スイープキューはスイープ検索アルゴリズムに基づいて新しい実行の生成を再開します。
2.1.5.6 - run を実験にまとめる
トレーニングと評価 run をグループ化して大規模な Experiments を構成する
個々のジョブを実験としてグループ化するには、一意のグループ 名を**wandb.init()**に渡します。
ユースケース
分散トレーニング : 実験が異なるトレーニングや評価スクリプトに分割されている場合、グループ化を使用してそれらを一つの大きな全体として見ることができます。複数のプロセス : 複数の小さなプロセスを一つの実験としてグループ化します。K-分割交差検証 : 異なるランダムシードを持つrunをグループ化して、大きな実験を見ます。こちらがスイープとグループ化を使用したK-分割交差検証の例です 。
グループ化を設定する方法は3つあります:
1. スクリプトでグループを設定する
オプションで group と job_type を wandb.init() に渡します。これにより、各実験に対して専用のグループページが作成され、個々のrunが含まれます。例: wandb.init(group="experiment_1", job_type="eval")
2. グループ環境変数を設定する
WANDB_RUN_GROUP を使用して、runのグループを環境変数として指定します。詳細はEnvironment Variables Group はプロジェクト内で一意である必要があり、グループ内のすべてのrunで共有されます。wandb.util.generate_id() を使用して、すべてのプロセスで使用するための一意の8文字の文字列を生成することができます。例: os.environ["WANDB_RUN_GROUP"] = "experiment-" + wandb.util.generate_id()
3. UIでグループ化を切り替える
任意の設定列で動的にグループ化できます。例として、wandb.config を使用してバッチサイズまたは学習率をログすると、それらのハイパーパラメーターでWebアプリ内で動的にグループ化できます。
グループ化を伴う分散トレーニング
wandb.init()でグループ化を設定したと仮定すると、UIではデフォルトでrunがグループ化されます。テーブルの上部にあるGroup ボタンをクリックして、これをオン・オフすることができます。こちらはグループ化を設定したサンプルコード から生成された例のプロジェクト です。サイドバーの各「グループ」行をクリックすると、その実験の専用グループページにアクセスできます。
上記のプロジェクトページから、左サイドバーでGroup をクリックすると、このような専用ページ にアクセスできます。
UIでの動的なグループ化
任意の列でrunをグループ化できます。例として、ハイパーパラメーターでグループ化することができます。これがどのように見えるかの例です：
サイドバー : runがエポック数でグループ化されています。グラフ : 各線はグループの平均を表し、陰影は分散を示します。この振る舞いはグラフ設定で変更できます。
グループ化をオフにする
グループ化ボタンをクリックし、グループフィールドをいつでもクリアすることで、テーブルとグラフをグループ化されていない状態に戻します。
グループ化グラフの設定
グラフの右上にある編集ボタンをクリックし、Advanced タブを選択して線と陰影を変更します。各グループの線には平均、最小、最大値を選択できます。陰影については無効にしたり、最小と最大、標準偏差、標準誤差を表示することができます。
2.1.5.7 - runs にタグでラベルを追加する
特定の特徴を持つ runs にタグを追加して、ログされたメトリクスやアーティファクトデータからは見えない情報をラベル付けできます。
たとえば、ある run のモデルが in_production であること、run が preemptible であること、この run が baseline を表していることなどを示すためにタグを追加できます。
1つまたは複数の runs にタグを追加する
プログラムによって、または対話的に runs にタグを追加します。
あなたのユースケースに基づいて、以下のタブからニーズに最も合ったものを選択してください。
W&B Python SDK
Public API
Project page
Run page
run が作成されるときにタグを追加できます:
import wandb
run = wandb. init(
entity= "entity" ,
project= "<project-name>" ,
tags= ["tag1" , "tag2" ]
)
run を初期化した後でもタグを更新できます。たとえば、特定のメトリクスが事前に定義されたしきい値を超えた場合、タグを更新する方法を示すコードスニペットです:
import wandb
run = wandb. init(
entity= "entity" ,
project= "capsules" ,
tags= ["debug" ]
)
# モデルをトレーニングするための Python ロジック
if current_loss < threshold:
run. tags = run. tags + ("release_candidate" ,)
run を作成した後、Public API を使用してタグを更新することができます。例:
run = wandb. Api(). run(" {entity} / {project} /{run-id}" )
run. tags. append("tag1" ) # ここで run データに基づいてタグを選択できます
run. update()
このメソッドは、同じタグまたは複数のタグを大量の runs にタグ付けするのに最も適しています。
プロジェクトワークスペースに移動します。
プロジェクトのサイドバーから Runs を選択します。
テーブルから1つまたは複数の runs を選択します。
1つまたは複数の runs を選択すると、テーブルの上にある Tag ボタンを選択します。
追加したいタグを入力し、そのタグを追加するために Create new tag チェックボックスを選択します。
このメソッドは、1つの run に手動でタグを適用するのに最も適しています。
プロジェクトワークスペースに移動します。
プロジェクトのワークスペース内の runs リストから run を1つ選択します。
プロジェクトサイドバーから Overview を選択します。
Tags の横にある灰色のプラスアイコン (+ ) ボタンを選択します。追加したいタグを入力し、新しいタグを追加するためにテキストボックスの下にある Add を選択します。
1つまたは複数の runs からタグを削除する
W&B App の UI を使って、runs からタグを削除することもできます。
このメソッドは、大量の runs からタグを削除するのに最も適しています。
プロジェクトの Run サイドバーで、右上のテーブルアイコンを選択します。これにより、サイドバーがフルランズテーブルに展開されます。
テーブル内の run にカーソルを合わせると、左側にチェックボックスが表示されるか、すべての runs を選択するためのチェックボックスがヘッダー行に表示されます。
チェックボックスを選択して一括操作を有効にします。
タグを削除したい runs を選択します。
run の行の上にある Tag ボタンを選択します。
run から削除するために、タグの横にあるチェックボックスを選択します。
Run ページの左サイドバーで、上部の Overview タブを選択します。ここで run のタグが表示されます。
タグにカーソルを合せ、「x」を選択して run から削除します。
2.1.5.8 - アラートを送信する
Python コードからトリガーされたアラートを Slack またはメールに送信する
run がクラッシュしたり、カスタムトリガーで Slack やメールでアラートを作成します。例えば、トレーニングループの勾配が膨らみ始めた場合（NaNを報告）や、ML パイプライン内のステップが完了した場合などです。アラートは、個人およびチームプロジェクトの両方を含む、run を初期化するすべての Projects に適用されます。
その後、Slack（またはメール）で W&B Alerts メッセージを確認します。
アラートの作成方法
以下のガイドは、マルチテナントクラウドでのアラートにのみ適用されます。
プライベートクラウドまたは W&B 専用クラウドで W&B Server を使用している場合は、Slack アラートの設定についてはこちらのドキュメント を参照してください。
アラートを設定するための主なステップは2つあります。
W&B の User Settings で Alerts をオンにする
コードに run.alert() を追加する
アラートが正しく設定されているか確認する
1. W&B User Settings でアラートをオンにする
User Settings の中で：
Alerts セクションまでスクロールしますScriptable run alerts をオンにして run.alert() からのアラートを受け取りますConnect Slack を使用して、アラートを投稿する Slack チャンネルを選択します。アラートを非公開に保持するため、Slackbot チャンネルをお勧めします。Email は W&B にサインアップしたときに使用したメールアドレスに送られます。これらのアラートがフォルダに入り、受信トレイを埋めないようにメールにフィルターを設定することをお勧めします。
W&B Alerts を初めて設定する際、またはアラートの受け取り方を変更したい場合にのみ、これを行う必要があります。
2. コードに run.alert() を追加する
ノートブックや Python スクリプトのどこでトリガーしたいかに run.alert() をコードに追加します。
import wandb
run = wandb. init()
run. alert(title= "High Loss" , text= "Loss is increasing rapidly" )
3. Slack またはメールを確認する
アラートメッセージのために Slack またはメールをチェックします。受信していない場合は、User Settings で Scriptable Alerts 用のメールまたは Slack がオンになっていることを確認してください
例
このシンプルなアラートは、精度が閾値を下回ると警告を送信します。この例では、少なくとも 5 分おきにアラートを送信します。
import wandb
from wandb import AlertLevel
run = wandb. init()
if acc < threshold:
run. alert(
title= "Low accuracy" ,
text= f "Accuracy { acc} is below the acceptable threshold { threshold} " ,
level= AlertLevel. WARN,
wait_duration= 300 ,
)
ユーザーをタグ付けまたはメンションする方法
アットマーク @ に続けて Slack ユーザー ID を使用して、アラートのタイトルまたはテキストで自身または同僚をタグ付けします。Slack ユーザー ID は、彼らの Slack プロフィールページから見つけることができます。
run. alert(title= "Loss is NaN" , text= f "Hey <@U1234ABCD> loss has gone to NaN" )
チームアラート
チーム管理者は、チームの設定ページでチーム用のアラートを設定できます：wandb.ai/teams/your-team。
チームアラートは、チームの全員に適用されます。W&B は、アラートを非公開に保持するために Slackbot チャンネルを使用することをお勧めします。
アラート送信先の Slack チャンネルを変更する
アラートの送信先を変更するには、Disconnect Slack をクリックして、再接続してください。再接続後、別の Slack チャンネルを選択します。
2.1.6 - Jupyter ノートブックをトラッキングする
Jupyter を使用して W&B と連携し、ノートブックから離れることなくインタラクティブな可視化を得ましょう。
W&B を Jupyter と組み合わせることで、ノートブックを離れることなくインタラクティブな可視化を実現できます。カスタム分析、実験管理、プロトタイプをすべて完全にログしながら結合します。
Jupyter ノートブックにおける W&B のユースケース
反復実験 : 実験を実行および再実行して、パラメータを調整し、すべての実行を手動でメモを取ることなく自動的に W&B に保存します。コード保存 : モデルを再現する際、ノートブックのどのセルが実行されたか、どの順序で実行されたかを知るのは難しいです。各実験のセル実行の記録を保存するために、設定ページ でコード保存をオンにしてください。カスタム分析 : 実行が W&B にログされたら、APIからデータフレームを取得して、カスタム分析を行い、その結果を W&B にログしてレポートで保存し、共有できます。
ノートブックでの始め方
W&B をインストールしてアカウントをリンクするために、次のコードでノートブックを開始します：
!pip install wandb -qqq
import wandb
wandb.login()
次に、実験を設定してハイパーパラメーターを保存します：
wandb. init(
project= "jupyter-projo" ,
config= {
"batch_size" : 128 ,
"learning_rate" : 0.01 ,
"dataset" : "CIFAR-100" ,
},
)
wandb.init() を実行した後、新しいセルを %%wandb から開始して、ノートブックでライブグラフを表示します。このセルを複数回実行すると、データは run に追加されます。
%%wandb
# ここにトレーニングループ
この例のノートブック で試してみてください。
ノートブックでライブ W&B インターフェイスを直接レンダリング
既存のダッシュボード、スイープ、またはレポートをノートブック内で直接表示することも可能です。%wandb マジックを使います：
# プロジェクトワークスペースを表示
%wandb USERNAME/PROJECT
# 単一の run を表示
%wandb USERNAME/PROJECT/runs/RUN_ID
# スイープを表示
%wandb USERNAME/PROJECT/sweeps/SWEEP_ID
# レポートを表示
%wandb USERNAME/PROJECT/reports/REPORT_ID
# 埋め込まれた iframe の高さを指定
%wandb USERNAME/PROJECT -h 2048
%%wandb または %wandb マジックの代替として、wandb.init() を実行した後、任意のセルを wandb.run で終わらせてインライングラフを表示するか、私たちの API から返された任意のレポート、スイープ、または run オブジェクトに ipython.display(...) を呼び出すこともできます。
# まず wandb.run を初期化
wandb. init()
# セルが wandb.run を出力すれば、ライブグラフが見られます
wandb. run
W&B における追加の Jupyter 機能
Colab における簡単な認証 : Colab で最初に wandb.init を呼び出すと、ブラウザーで W&B にログインしている場合、ランタイムを自動的に認証します。run ページの Overviewタブに Colab へのリンクが表示されます。Jupyter マジック : ダッシュボード、スイープ、レポートをノートブック内で直接表示する機能です。%wandb マジックはプロジェクト、スイープ、またはレポートへのパスを受け取り、W&B インターフェイスをノートブック内に直接レンダリングします。Docker化された Jupyter のローンチ : wandb docker --jupyter を呼び出して、dockerコンテナを起動し、コードをマウントし、Jupyter がインストールされていることを確認し、ポート 8888 で起動します。順序を気にせずにセルを実行 : デフォルトでは、次に wandb.init が呼び出されるまで run を finished としてマークしません。それにより、複数のセル（例: データを設定するセル、トレーニングするセル、テストするセル）を任意の順序で実行し、すべて同じ run にログできます。設定 でコード保存をオンにすると、実行順序と状態で実行されたセルもログされ、最も非線形なパイプラインでさえ再現できます。Jupyter ノートブックで run を手動で完了としてマークするには、run.finish を呼び出してください。
import wandb
run = wandb. init()
# トレーニングスクリプトとログはここに
run. finish()
2.1.7 - ログ オブジェクト と メディア
メトリクス、ビデオ、カスタムプロットなどを追跡する
W&B Python SDK を使用して、メトリクス、メディア、またはカスタムオブジェクトの辞書をステップにログします。W&B は各ステップごとにキーと値のペアを収集し、wandb.log() でデータをログするたびにそれらを統一された辞書に格納します。スクリプトからログされたデータは、wandb と呼ばれるディレクトリにローカルに保存され、その後 W&B クラウドまたは プライベートサーバー に同期されます。
キーと値のペアは、各ステップに同じ値を渡した場合にのみ統一された辞書に保存されます。step に異なる値をログした場合、W&B はすべての収集されたキーと値をメモリに書き込みます。
デフォルトでは、wandb.log を呼び出すたびに新しい step になります。W&B は、チャートやパネルを作成する際にステップをデフォルトの x 軸として使用します。カスタムの x 軸を作成して使用するか、カスタムの要約メトリックをキャプチャすることも選択できます。詳細は、ログの軸をカスタマイズする を参照してください。
wandb.log() を使用して、各 step の連続する値をログします: 0, 1, 2, といった具合です。特定の履歴ステップに書き込むことは不可能です。W&B は「現在」と「次」のステップにのみ書き込みます。
自動でログされるデータ
W&B は、W&B Experiment 中に次の情報を自動でログします：
システムメトリクス : CPU と GPU の使用率、ネットワークなど。これらは run ページ のシステムタブに表示されます。GPU に関しては、nvidia-smiコマンドライン : stdout と stderr が取得され、run ページ のログタブに表示されます。
アカウントの Settings ページ でコードの保存 をオンにして、以下をログします：
Git コミット : 最新の git コミットを取得し、run ページの overview タブに表示されます。コミットされていない変更がある場合は diff.patch ファイルも表示されます。依存関係 : requirements.txt ファイルがアップロードされ、run ページのファイルタブに表示されます。run 用に wandb ディレクトリに保存したファイルも含まれます。
特定の W&B API 呼び出しでログされるデータ
W&B を使用することで、ログしたいものを正確に決定できます。次に、よくログされるオブジェクトのリストを示します：
Datasets : 画像や他のデータセットサンプルを W&B にストリームするためには、特にログする必要があります。Plots : グラフを追跡するために wandb.plot を wandb.log と一緒に使用します。詳細はログでのグラフ を参照してください。Tables : wandb.Table を使用してデータをログし、W&B でビジュアライズおよびクエリを行います。詳細はログでのテーブル を参照してください。PyTorch 勾配 : モデルの重みの勾配を UI にヒストグラムとして表示するために wandb.watch(model) を追加します。設定情報 : ハイパーパラメーター、データセットへのリンク、使用しているアーキテクチャーの名前などを設定パラメーターとしてログします。このように渡します：wandb.init(config=your_config_dictionary)。詳細はPyTorch インテグレーション ページをご覧ください。メトリクス : wandb.log を使用してモデルのメトリクスを表示します。トレーニングループ内で精度や損失のようなメトリクスをログすると、UI にライブ更新グラフが表示されます。
一般的なワークフロー
最高の精度を比較する : Runs 間でメトリクスの最高値を比較するには、そのメトリクスの要約値を設定します。デフォルトでは、各キーの最後にログした値が要約に設定されます。これは UI のテーブルで、要約メトリクスに基づいて run を並べ替えたりフィルタリングしたりするのに便利です。best の精度に基づいてテーブルまたは棒グラフで run を比較するのに役立ちます。例：wandb.run.summary["best_accuracy"] = best_accuracy複数のメトリクスを1つのチャートで表示 : wandb.log の同じ呼び出し内で複数のメトリクスをログすると、例えばこうなります: wandb.log({"acc": 0.9, "loss": 0.1})。UI ではどちらもプロットすることができます。x 軸をカスタマイズする : 同じログ呼び出しにカスタム x 軸を追加して、W&B ダッシュボードで別の軸に対してメトリクスを視覚化します。例：wandb.log({'acc': 0.9, 'epoch': 3, 'batch': 117})。特定のメトリクスに対するデフォルトの x 軸を設定するには、Run.define_metric() を使用してください。リッチメディアとチャートをログする : wandb.log は、画像やビデオのようなメディア からtables やcharts に至るまで、多様なデータタイプのログをサポートしています。
ベストプラクティスとヒント
Experiments やログのためのベストプラクティスとヒントについては、Best Practices: Experiments and Logging を参照してください。
2.1.7.1 - メディアとオブジェクトをログする
3D ポイント クラウドや分子から HTML、ヒストグラムまで、豊富なメディアをログする
私たちは画像、ビデオ、音声などをサポートしています。リッチメディアをログして、結果を探索し、Run、Models、Datasetsを視覚的に比較しましょう。例やハウツーガイドは以下をご覧ください。
メディアタイプの参考ドキュメントをお探しですか？この
ページ が必要です。
前提条件
W&B SDKを使用してメディアオブジェクトをログするためには、追加の依存関係をインストールする必要があるかもしれません。以下のコマンドを実行してこれらの依存関係をインストールできます：
画像
画像をログして、入力、出力、フィルター重み、活性化状態などを追跡しましょう。
画像はNumPy配列、PIL画像、またはファイルシステムから直接ログできます。
ステップごとに画像をログするたびに、UIに表示するために保存されます。画像パネルを拡大し、ステップスライダーを使用して異なるステップの画像を確認します。これにより、トレーニング中にモデルの出力がどのように変化するかを比較しやすくなります。
トレーニング中のログのボトルネックを防ぎ、結果を表示する際の画像読み込みのボトルネックを防ぐために、1ステップあたり50枚以下の画像をログすることをお勧めします。
配列を画像としてログする
PIL Imagesをログする
ファイルから画像をログする
配列を手動で画像として構築する際に、make_grid from torchvision
配列はPillow を使用してpngに変換されます。
images = wandb. Image(image_array, caption= "Top: Output, Bottom: Input" )
wandb. log({"examples" : images})
最後の次元が1の場合はグレースケール、3の場合はRGB、4の場合はRGBAと仮定します。配列が浮動小数点数を含む場合、それらを0から255の整数に変換します。異なる方法で画像を正規化したい場合は、mode"Logging PIL Images"タブで説明されているように、単にPIL.Image
配列から画像への変換を完全に制御するために、PIL.Image
images = [PIL. Image. fromarray(image) for image in image_array]
wandb. log({"examples" : [wandb. Image(image) for image in images]})
さらに制御したい場合は、任意の方法で画像を作成し、ディスクに保存し、ファイルパスを提供します。
im = PIL. fromarray(... )
rgb_im = im. convert("RGB" )
rgb_im. save("myimage.jpg" )
wandb. log({"example" : wandb. Image("myimage.jpg" )})
画像オーバーレイ
セマンティックセグメンテーションマスクをログし、W&B UIを通じて（不透明度の変更、時間経過による変化の確認など）それらと対話します。
オーバーレイをログするには、wandb.Imageのmasksキーワード引数に以下のキーと値を持つ辞書を提供する必要があります：
画像マスクを表す2つのキーのうちの1つ：
"mask_data"：各ピクセルの整数クラスラベルを含む2D NumPy配列"path"：（文字列）保存された画像マスクファイルへのパス
"class_labels"：（オプション）画像マスク内の整数クラスラベルを可読クラス名にマッピングする辞書
複数のマスクをログするには、以下のコードスニペットのように、複数のキーを含むマスク辞書をログします。
ライブ例を参照してください
サンプルコード
mask_data = np. array([[1 , 2 , 2 , ... , 2 , 2 , 1 ], ... ])
class_labels = {1 : "tree" , 2 : "car" , 3 : "road" }
mask_img = wandb. Image(
image,
masks= {
"predictions" : {"mask_data" : mask_data, "class_labels" : class_labels},
"ground_truth" : {
# ...
},
# ...
},
)
画像にバウンディングボックスをログし、UIで異なるセットのボックスを動的に可視化するためにフィルターや切り替えを使用します。
ライブ例を参照してください
バウンディングボックスをログするには、wandb.Imageのboxesキーワード引数に以下のキーと値を持つ辞書を提供する必要があります：
box_data：各ボックス用の辞書リスト。ボックス辞書形式は以下に説明します。
position：ボックスの位置とサイズを表す辞書で、以下で説明する2つの形式のいずれか。すべてのボックスが同じ形式を使用する必要はありません。
オプション 1: {"minX", "maxX", "minY", "maxY"}。各ボックスの次元の上下限を定義する座標セットを提供します。オプション 2: {"middle", "width", "height"}。middle座標を[x,y]として、widthとheightをスカラーとして指定します。
class_id：ボックスのクラス識別を表す整数。以下のclass_labelsキーを参照。scores：スコアの文字列ラベルと数値の辞書。UIでボックスをフィルタリングするために使用できます。domain：ボックス座標の単位/形式を指定してください。この値を"pixel"に設定 してください。ボックス座標が画像の次元内の整数のようにピクセル空間で表されている場合、デフォルトで、domainは画像の割合/百分率として表され、0から1までの浮動小数点数として解釈されます。box_caption：（オプション）このボックス上に表示されるラベルテキストとしての文字列
class_labels：（オプション）class_idを文字列にマッピングする辞書。デフォルトではclass_0、class_1などのクラスラベルを生成します。
この例をチェックしてください：
class_id_to_label = {
1 : "car" ,
2 : "road" ,
3 : "building" ,
# ...
}
img = wandb. Image(
image,
boxes= {
"predictions" : {
"box_data" : [
{
# デフォルトの相対/小数領域で表現された1つのボックス
"position" : {"minX" : 0.1 , "maxX" : 0.2 , "minY" : 0.3 , "maxY" : 0.4 },
"class_id" : 2 ,
"box_caption" : class_id_to_label[2 ],
"scores" : {"acc" : 0.1 , "loss" : 1.2 },
# ピクセル領域で表現された別のボックス
# （説明目的のみ、すべてのボックスは同じ領域/形式である可能性が高い）
"position" : {"middle" : [150 , 20 ], "width" : 68 , "height" : 112 },
"domain" : "pixel" ,
"class_id" : 3 ,
"box_caption" : "a building" ,
"scores" : {"acc" : 0.5 , "loss" : 0.7 },
# ...
# 必要に応じて多くのボックスをログします
}
],
"class_labels" : class_id_to_label,
},
# 意味のあるボックスのグループごとに一意のキーネームでログします
"ground_truth" : {
# ...
},
},
)
wandb. log({"driving_scene" : img})
テーブル内の画像オーバーレイ
テーブル内でセグメンテーションマスクをログするには、テーブルの各行に対してwandb.Imageオブジェクトを提供する必要があります。
以下のコードスニペットに例があります：
table = wandb. Table(columns= ["ID" , "Image" ])
for id, img, label in zip(ids, images, labels):
mask_img = wandb. Image(
img,
masks= {
"prediction" : {"mask_data" : label, "class_labels" : class_labels}
# ...
},
)
table. add_data(id, img)
wandb. log({"Table" : table})
テーブル内でバウンディングボックス付き画像をログするには、テーブルの各行にwandb.Imageオブジェクトを提供する必要があります。
以下のコードスニペットに例があります：
table = wandb. Table(columns= ["ID" , "Image" ])
for id, img, boxes in zip(ids, images, boxes_set):
box_img = wandb. Image(
img,
boxes= {
"prediction" : {
"box_data" : [
{
"position" : {
"minX" : box["minX" ],
"minY" : box["minY" ],
"maxX" : box["maxX" ],
"maxY" : box["maxY" ],
},
"class_id" : box["class_id" ],
"box_caption" : box["caption" ],
"domain" : "pixel" ,
}
for box in boxes
],
"class_labels" : class_labels,
}
},
)
ヒストグラム
基本ヒストグラムログ
柔軟なヒストグラムログ
Summary内のヒストグラム
リスト、配列、テンソルなどの数字のシーケンスが最初の引数として提供されると、自動的にnp.histogramを呼んでヒストグラムを構築します。すべての配列/テンソルはフラット化されます。num_binsキーワード引数を使用して64ビンのデフォルト設定を上書きできます。最大サポートビン数は512です。
UIでは、トレーニングステップがx軸に、メトリック値がy軸に、色で表現されたカウントでヒストグラムがプロットされ、トレーニング中にログされたヒストグラムを比較しやすくしています。詳細については、このパネルの"Summary内のヒストグラム"タブを参照してください。
wandb. log({"gradients" : wandb. Histogram(grads)})
もっと制御したい場合は、np.histogramを呼び出し、その返されたタプルをnp_histogramキーワード引数に渡します。
np_hist_grads = np. histogram(grads, density= True , range= (0.0 , 1.0 ))
wandb. log({"gradients" : wandb. Histogram(np_hist_grads)})
wandb. run. summary. update( # Summaryにのみある場合、Overviewタブにのみ表示されます
{"final_logits" : wandb. Histogram(logits)}
)
ファイルを形式 'obj', 'gltf', 'glb', 'babylon', 'stl', 'pts.json' でログすれば、runが終了した際にUIでそれらをレンダリングします。
wandb. log(
{
"generated_samples" : [
wandb. Object3D(open("sample.obj" )),
wandb. Object3D(open("sample.gltf" )),
wandb. Object3D(open("sample.glb" )),
]
}
)
ライブ例を見る
Summary内にあるヒストグラムは、Run Page のOverviewタブに表示されます。履歴にある場合、Chartsタブで時間経過によるビンのヒートマップをプロットします。
3D可視化
3Dポイントクラウドとバウンディングボックスを持つLidarシーンをログします。レンダリングするポイントの座標と色を含むNumPy配列を渡します。
point_cloud = np. array([[0 , 0 , 0 , COLOR]])
wandb. log({"point_cloud" : wandb. Object3D(point_cloud)})
:::info
W&B UIはデータを30万ポイントに制限します。
:::
NumPy配列フォーマット
色のスキームに柔軟性を持たせるために、3つの異なるデータ形式のNumPy配列がサポートされています。
[[x, y, z], ...] nx3[[x, y, z, c], ...] nx4, cは範囲[1, 14]内のカテゴリ （セグメンテーションに便利）[[x, y, z, r, g, b], ...] nx6 | r,g,b は赤、緑、青のカラー チャネルに対して範囲[0,255]の値
Pythonオブジェクト
このスキーマを使用して、Pythonオブジェクトを定義し、以下に示すように the from_point_cloud method に渡すことができます。
pointsは、単純なポイントクラウドレンダラーで上記に示されたのと同じフォーマットを使用してレンダリングするポイントの座標と色を含むNumPy配列です 。boxesは3つの属性を持つPython辞書のNumPy配列です：
corners - 8つのコーナーのリストlabel - ボックスにレンダリングされるラベルを表す文字列 (オプション)color - ボックスの色を表すrgb値score - バウンディングボックスに表示される数値で、表示するバウンディングボックスのフィルタリングに使用できます（例：score > 0.75のバウンディングボックスのみを表示する）。(オプション)
typeはレンダリングされるシーンタイプを表す文字列です。現在サポートされている値はlidar/betaのみです。
point_list = [
[
2566.571924017235 , # x
746.7817289698219 , # y
- 15.269245470863748 ,# z
76.5 , # red
127.5 , # green
89.46617199365393 # blue
],
[ 2566.592983606823 , 746.6791987335685 , - 15.275803826279521 , 76.5 , 127.5 , 89.45471117247024 ],
[ 2566.616361739416 , 746.4903185513501 , - 15.28628929674075 , 76.5 , 127.5 , 89.41336375503832 ],
[ 2561.706014951675 , 744.5349468458361 , - 14.877496818222781 , 76.5 , 127.5 , 82.21868245418283 ],
[ 2561.5281847916694 , 744.2546118233013 , - 14.867862032341005 , 76.5 , 127.5 , 81.87824684536432 ],
[ 2561.3693562897465 , 744.1804761656741 , - 14.854129178142523 , 76.5 , 127.5 , 81.64137897587152 ],
[ 2561.6093071504515 , 744.0287526628543 , - 14.882135189841177 , 76.5 , 127.5 , 81.89871499537098 ],
# ... and so on
]
run. log({"my_first_point_cloud" : wandb. Object3D. from_point_cloud(
points = point_list,
boxes = [{
"corners" : [
[ 2601.2765123137915 , 767.5669506323393 , - 17.816764802288663 ],
[ 2599.7259021588347 , 769.0082337923552 , - 17.816764802288663 ],
[ 2599.7259021588347 , 769.0082337923552 , - 19.66876480228866 ],
[ 2601.2765123137915 , 767.5669506323393 , - 19.66876480228866 ],
[ 2604.8684867834395 , 771.4313904894723 , - 17.816764802288663 ],
[ 2603.3178766284827 , 772.8726736494882 , - 17.816764802288663 ],
[ 2603.3178766284827 , 772.8726736494882 , - 19.66876480228866 ],
[ 2604.8684867834395 , 771.4313904894723 , - 19.66876480228866 ]
],
"color" : [0 , 0 , 255 ], # バウンディングボックスのRGB色
"label" : "car" , # バウンディングボックスに表示される文字列
"score" : 0.6 # バウンディングボックスに表示される数値
}],
vectors = [
{"start" : [0 , 0 , 0 ], "end" : [0.1 , 0.2 , 0.5 ], "color" : [255 , 0 , 0 ]}, # 色は任意
],
point_cloud_type = "lidar/beta" ,
)})
ポイントクラウドを表示するとき、Controlキーを押しながらマウスを使用すると、内部空間を移動できます。
ポイントクラウドファイル
the from_file method を使用して、ポイントクラウドデータが満載のJSONファイルをロードできます。
run. log({"my_cloud_from_file" : wandb. Object3D. from_file(
"./my_point_cloud.pts.json"
)})
ポイントクラウドデータのフォーマット方法の例を以下に示します。
{
"boxes" : [
{
"color" : [
0 ,
255 ,
0
],
"score" : 0.35 ,
"label" : "My label" ,
"corners" : [
[
2589.695869075582 ,
760.7400443552185 ,
-18.044831294622487
],
[
2590.719039645323 ,
762.3871153874499 ,
-18.044831294622487
],
[
2590.719039645323 ,
762.3871153874499 ,
-19.54083129462249
],
[
2589.695869075582 ,
760.7400443552185 ,
-19.54083129462249
],
[
2594.9666662674313 ,
757.4657929961453 ,
-18.044831294622487
],
[
2595.9898368371723 ,
759.1128640283766 ,
-18.044831294622487
],
[
2595.9898368371723 ,
759.1128640283766 ,
-19.54083129462249
],
[
2594.9666662674313 ,
757.4657929961453 ,
-19.54083129462249
]
]
}
],
"points" : [
[
2566.571924017235 ,
746.7817289698219 ,
-15.269245470863748 ,
76.5 ,
127.5 ,
89.46617199365393
],
[
2566.592983606823 ,
746.6791987335685 ,
-15.275803826279521 ,
76.5 ,
127.5 ,
89.45471117247024
],
[
2566.616361739416 ,
746.4903185513501 ,
-15.28628929674075 ,
76.5 ,
127.5 ,
89.41336375503832
]
],
"type" : "lidar/beta"
}
NumPy配列
上記で定義された配列フォーマット を使用して、numpy配列を直接 the from_numpy method でポイントクラウドを定義できます。
run. log({"my_cloud_from_numpy_xyz" : wandb. Object3D. from_numpy(
np. array(
[
[0.4 , 1 , 1.3 ], # x, y, z
[1 , 1 , 1 ],
[1.2 , 1 , 1.2 ]
]
)
)})
run. log({"my_cloud_from_numpy_cat" : wandb. Object3D. from_numpy(
np. array(
[
[0.4 , 1 , 1.3 , 1 ], # x, y, z, カテゴリ
[1 , 1 , 1 , 1 ],
[1.2 , 1 , 1.2 , 12 ],
[1.2 , 1 , 1.3 , 12 ],
[1.2 , 1 , 1.4 , 12 ],
[1.2 , 1 , 1.5 , 12 ],
[1.2 , 1 , 1.6 , 11 ],
[1.2 , 1 , 1.7 , 11 ],
]
)
)})
run. log({"my_cloud_from_numpy_rgb" : wandb. Object3D. from_numpy(
np. array(
[
[0.4 , 1 , 1.3 , 255 , 0 , 0 ], # x, y, z, r, g, b
[1 , 1 , 1 , 0 , 255 , 0 ],
[1.2 , 1 , 1.3 , 0 , 255 , 255 ],
[1.2 , 1 , 1.4 , 0 , 255 , 255 ],
[1.2 , 1 , 1.5 , 0 , 0 , 255 ],
[1.2 , 1 , 1.1 , 0 , 0 , 255 ],
[1.2 , 1 , 0.9 , 0 , 0 , 255 ],
]
)
)})
wandb. log({"protein" : wandb. Molecule("6lu7.pdb" )})
分子データはpdb、pqr、mmcif、mcif、cif、sdf、sd、gro、mol2、mmtf.のいずれかの10のファイル形式でログできます。
W&Bはまた、SMILES文字列、rdkitmolファイル、rdkit.Chem.rdchem.Molオブジェクトからの分子データのログをサポートします。
resveratrol = rdkit. Chem. MolFromSmiles("Oc1ccc(cc1)C=Cc1cc(O)cc(c1)O" )
wandb. log(
{
"resveratrol" : wandb. Molecule. from_rdkit(resveratrol),
"green fluorescent protein" : wandb. Molecule. from_rdkit("2b3p.mol" ),
"acetaminophen" : wandb. Molecule. from_smiles("CC(=O)Nc1ccc(O)cc1" ),
}
)
runが終了すると、UIで分子の3D可視化と対話できるようになります。
AlphaFoldを使用したライブ例を見る
PNG 画像
wandb.Imagenumpy配列やPILImageのインスタンスをデフォルトでPNGに変換します。
wandb. log({"example" : wandb. Image(... )})
# または複数の画像
wandb. log({"example" : [wandb. Image(... ) for img in images]})
ビデオ
ビデオはwandb.Video
wandb. log({"example" : wandb. Video("myvideo.mp4" )})
現在、メディアブラウザでビデオを見ることができます。 プロジェクトワークスペース、runワークスペース、またはレポートに移動し、Add visualization をクリックしてリッチメディアパネルを追加します。
分子の2Dビュー
wandb.Imagerdkit
molecule = rdkit. Chem. MolFromSmiles("CC(=O)O" )
rdkit. Chem. AllChem. Compute2DCoords(molecule)
rdkit. Chem. AllChem. GenerateDepictionMatching2DStructure(molecule, molecule)
pil_image = rdkit. Chem. Draw. MolToImage(molecule, size= (300 , 300 ))
wandb. log({"acetic_acid" : wandb. Image(pil_image)})
その他のメディア
W&Bは、さまざまな他のメディアタイプのログもサポートしています。
オーディオ
wandb. log({"whale songs" : wandb. Audio(np_array, caption= "OooOoo" , sample_rate= 32 )})
1ステップあたりの最大100のオーディオクリップをログできます。詳細な使い方については、audio-file
ビデオ
wandb. log({"video" : wandb. Video(numpy_array_or_path_to_video, fps= 4 , format= "gif" )})
numpy配列が供給された場合、時間、チャンネル、幅、高さの順であると仮定します。 デフォルトでは4fpsのgif画像を作成します（numpyオブジェクトを渡す場合、ffmpegmoviepy"gif"、"mp4"、"webm"、そして"ogg"です。wandb.Video に文字列を渡すと、ファイルが存在し、wandbにアップロードする前にサポートされたフォーマットであることを確認します。 BytesIOオブジェクトを渡すと、指定されたフォーマットを拡張子とする一時ファイルを作成します。
W&BのRun とProject ページで、メディアセクションにビデオが表示されます。
詳細な使い方については、video-file
テキスト
wandb.Tableを使用して、UIに表示するテーブルにテキストをログします。デフォルトで、列ヘッダーは["Input", "Output", "Expected"]です。最適なUIパフォーマンスを確保するために、デフォルトで最大行数は10,000に設定されています。ただし、ユーザーはwandb.Table.MAX_ROWS = {DESIRED_MAX}を使用して明示的に上限を超えることができます。
columns = ["Text" , "Predicted Sentiment" , "True Sentiment" ]
# メソッド 1
data = [["I love my phone" , "1" , "1" ], ["My phone sucks" , "0" , "-1" ]]
table = wandb. Table(data= data, columns= columns)
wandb. log({"examples" : table})
# メソッド 2
table = wandb. Table(columns= columns)
table. add_data("I love my phone" , "1" , "1" )
table. add_data("My phone sucks" , "0" , "-1" )
wandb. log({"examples" : table})
また、pandas DataFrameオブジェクトを渡すこともできます。
table = wandb. Table(dataframe= my_dataframe)
詳細な使い方については、string
HTML
wandb. log({"custom_file" : wandb. Html(open("some.html" ))})
wandb. log({"custom_string" : wandb. Html('<a href="https://mysite">Link</a>' )})
カスタムHTMLは任意のキーでログ可能で、runページ上にHTMLパネルを接続します。デフォルトではスタイルが注入されます。デフォルトスタイルをオフにするには、inject=Falseを渡します。
wandb. log({"custom_file" : wandb. Html(open("some.html" ), inject= False )})
詳細な使い方については、html-file
2.1.7.2 - モデルをログする
モデルをログする
以下のガイドでは、W&B run にモデルをログし、それと対話する方法を説明します。
以下の API は、実験管理ワークフローの一環としてモデルを追跡するのに便利です。このページに記載されている API を使用して、run にモデルをログし、メトリクス、テーブル、メディア、その他のオブジェクトにアクセスします。
モデル以外にも、データセットやプロンプトなど、シリアライズされたデータの異なるバージョンを作成し追跡したい場合は、W&B Artifacts を使用することをお勧めします。
モデルやその他のオブジェクトを W&B で追跡するための リネージグラフ を探索します。
これらのメソッドで作成されたモデル アーティファクトとの対話（プロパティの更新、メタデータ、エイリアス、説明など）を行います。
W&B Artifacts や高度なバージョン管理ユースケースの詳細については、Artifacts ドキュメントをご覧ください。
モデルを run にログする
log_modellog_model
モデルを W&B run の入力または出力としてマークすると、モデルの依存関係とモデルの関連付けを追跡できます。W&B アプリ UI 内でモデルのリネージを確認します。詳細については、Artifacts チャプターの アーティファクトグラフを探索して移動する ページを参照してください。
モデルファイルが保存されているパスを path パラメータに指定します。パスには、ローカルファイル、ディレクトリ、または s3://bucket/path などの外部バケットへの 参照 URI を指定できます。
<> 内に囲まれた値を自分のもので置き換えることを忘れないでください。
import wandb
W&B run を初期化
run = wandb.init(project="", entity="")
モデルをログする
run.log_model(path="", name="")
オプションで、name パラメータにモデルアーティファクトの名前を指定できます。name が指定されていない場合、W&B は入力パスのベース名に run ID をプレフィックスとして使用して名前を生成します。
モデルに W&B が割り当てた
name またはユーザーが指定した
nameを追跡してください。モデルのパスを取得するには、
use_model メソッドでモデルの名前が必要です。
log_model の詳細については、API リファレンスガイドを参照してください。
例: モデルを run にログする
import os
import wandb
from tensorflow import keras
from tensorflow.keras import layers
config = {"optimizer" : "adam" , "loss" : "categorical_crossentropy" }
# W&B run を初期化
run = wandb. init(entity= "charlie" , project= "mnist-experiments" , config= config)
# ハイパーパラメーター
loss = run. config["loss" ]
optimizer = run. config["optimizer" ]
metrics = ["accuracy" ]
num_classes = 10
input_shape = (28 , 28 , 1 )
# トレーニング アルゴリズム
model = keras. Sequential(
[
layers. Input(shape= input_shape),
layers. Conv2D(32 , kernel_size= (3 , 3 ), activation= "relu" ),
layers. MaxPooling2D(pool_size= (2 , 2 )),
layers. Conv2D(64 , kernel_size= (3 , 3 ), activation= "relu" ),
layers. MaxPooling2D(pool_size= (2 , 2 )),
layers. Flatten(),
layers. Dropout(0.5 ),
layers. Dense(num_classes, activation= "softmax" ),
]
)
# トレーニング用のモデルを設定
model. compile(loss= loss, optimizer= optimizer, metrics= metrics)
# モデルを保存
model_filename = "model.h5"
local_filepath = "./"
full_path = os. path. join(local_filepath, model_filename)
model. save(filepath= full_path)
# モデルを W&B run にログする
run. log_model(path= full_path, name= "MNIST" )
run. finish()
ユーザーが log_model を呼び出したとき、MNISTという名前のモデルアーティファクトが作成され、ファイル model.h5 がモデルアーティファクトに追加されました。あなたのターミナルまたはノートブックは、モデルがログされた run に関する情報を見つける場所についての情報を出力します。
View run different- surf- 5 at: https:// wandb. ai/ charlie/ mnist- experiments/ runs/ wlby6fuw
Synced 5 W& B file(s), 0 media file(s), 1 artifact file(s) and 0 other file(s)
Find logs at: ./ wandb/ run- 20231206_103511 - wlby6fuw/ logs
ログされたモデルをダウンロードして使用する
以前に W&B run にログされたモデルファイルにアクセスしてダウンロードするには、use_model
取得したいモデルファイルが保存されているモデルアーティファクトの名前を指定します。提供した名前は、既存のログされたモデルアーティファクトの名前と一致している必要があります。
最初に log_model でファイルをログした際に name を定義しなかった場合、割り当てられたデフォルト名は、入力パスのベース名にrun ID をプレフィックスとして付けたものになります。
<> 内に囲まれた他の値を自分のもので置き換えることを忘れないでください。
import wandb
# run を初期化
run = wandb. init(project= "<your-project>" , entity= "<your-entity>" )
# モデルにアクセスしてダウンロードする。ダウンロードされたアーティファクトのパスが返されます
downloaded_model_path = run. use_model(name= "<your-model-name>" )
use_modeldownloaded_model_path という変数に保存されています。
例: ログされたモデルをダウンロードして使用する
たとえば、以下のコードスニペットでは、ユーザーが use_model API を呼び出しています。彼らは取得したいモデルアーティファクトの名前を指定し、またバージョン/エイリアスも提供しています。そして、API から返されるパスを downloaded_model_path 変数に保存しました。
import wandb
entity = "luka"
project = "NLP_Experiments"
alias = "latest" # モデルバージョンのセマンティックなニックネームまたは識別子
model_artifact_name = "fine-tuned-model"
# run を初期化
run = wandb. init(project= project, entity= entity)
# モデルにアクセスしてダウンロードする。ダウンロードされたアーティファクトのパスが返されます
downloaded_model_path = run. use_model(name = f " { model_artifact_name} : { alias} " )
use_model
モデルを W&B モデルレジストリにログしリンクする
link_model メソッドは、現在のところレガシー W&B モデルレジストリとしか互換性がありませんが、これは間もなく廃止される予定です。モデルアーティファクトを新しいバージョンのモデルレジストリにリンクする方法については、レジストリの
ドキュメント をご覧ください。
link_modelW&B モデルレジストリ にリンクします。登録されたモデルが存在しない場合、W&B は registered_model_name パラメータにあなたが提供した名前で新しいものを作成します。
モデルをリンクすることは、他のチームメンバーが視聴および利用できる中央集権的なチームのリポジトリにモデルを「ブックマーク」または「公開」することに類似しています。
モデルをリンクすると、そのモデルは Registry に重複されることも、プロジェクトから移動してレジストリに入れられることもありません。リンクされたモデルは、プロジェクト内の元のモデルへのポインターです。
Registry を使用して、タスクごとに最高のモデルを整理したり、モデルのライフサイクルを管理したり、MLライフサイクル全体での追跡や監査を容易にしたり、Webhooks やジョブでの下流アクションを自動化 することができます。
Registered Model は、Model Registry にリンクされたモデルバージョンのコレクションまたはフォルダーです。登録されたモデルは通常、単一のモデリングユースケースまたはタスクの候補モデルを表します。
以下のコードスニペットは、link_model API を使用してモデルをリンクする方法を示しています。<> 内に囲まれた他の値を自分のもので置き換えることを忘れないでください。
import wandb
run = wandb. init(entity= "<your-entity>" , project= "<your-project>" )
run. link_model(path= "<path-to-model>" , registered_model_name= "<registered-model-name>" )
run. finish()
link_model API リファレンスガイドでは、オプションのパラメータに関する詳細情報が記載されています。
registered-model-name が Model Registry 内に既に存在する登録済みのモデル名と一致する場合、そのモデルはその登録済みモデルにリンクされます。そのような登録済みモデルが存在しない場合、新しいものが作成され、そのモデルが最初にリンクされます。
例えば、既に Model Registry に “Fine-Tuned-Review-Autocompletion"という名前の登録済みモデルが存在し、いくつかのモデルバージョンが既にリンクされていると仮定します: v0, v1, v2。link_model を registered-model-name="Fine-Tuned-Review-Autocompletion"を使用して呼び出した場合、新しいモデルは既存の登録済みモデルに v3 としてリンクされます。この名前の登録済みモデルが存在しない場合、新しいものが作成され、新しいモデルが v0 としてリンクされます。
例: モデルを W&B モデルレジストリにログしリンクする
例えば、以下のコードスニペットでは、モデルファイルをログし、登録済みのモデル名 "Fine-Tuned-Review-Autocompletion"にモデルをリンクする方法を示しています。
これを行うために、ユーザーは link_model API を呼び出します。API を呼び出す際に、モデルの内容を示すローカルファイルパス (path) と、リンクするための登録済みモデルの名前 (registered_model_name) を提供します。
import wandb
path = "/local/dir/model.pt"
registered_model_name = "Fine-Tuned-Review-Autocompletion"
run = wandb. init(project= "llm-evaluation" , entity= "noa" )
run. link_model(path= path, registered_model_name= registered_model_name)
run. finish()
リマインダー: 登録済みモデルは、ブックマークされたモデルバージョンのコレクションを管理します。
2.1.7.3 - ログ テーブル
W&B でテーブルをログします。
wandb.Table を使って、データをログに記録し W&B で視覚化・クエリできるようにします。このガイドでは次のことを学びます：
テーブルを作成する データを追加する データを取得する テーブルを保存する
テーブルを作成する
Table（テーブル）を定義するには、各データ行に表示したい列を指定します。各行はトレーニングデータセットの単一の項目、トレーニング中の特定のステップやエポック、テスト項目でのモデルの予測、モデルが生成したオブジェクトなどです。各列には固定の型があり、数値、テキスト、ブール値、画像、ビデオ、オーディオなどがあります。あらかじめ型を指定する必要はありません。各列に名前を付け、その型のデータのみをその列のインデックスに渡してください。より詳細な例については、このレポート を参照してください。
wandb.Table コンストラクタを次の2つの方法のいずれかで使用します：
行のリスト: 名前付きの列とデータの行をログに記録します。例えば、次のコードスニペットは 2 行 3 列のテーブルを生成します：
wandb. Table(columns= ["a" , "b" , "c" ], data= [["1a" , "1b" , "1c" ], ["2a" , "2b" , "2c" ]])
Pandas DataFrame: wandb.Table(dataframe=my_df) を使用して DataFrame をログに記録します。列の名前は DataFrame から抽出されます。
既存の配列またはデータフレームから
# モデルが4つの画像で予測を返したと仮定します
# 次のフィールドが利用可能です:
# - 画像ID
# - 画像ピクセル（wandb.Image() でラップ）
# - モデルの予測ラベル
# - 正解ラベル
my_data = [
[0 , wandb. Image("img_0.jpg" ), 0 , 0 ],
[1 , wandb. Image("img_1.jpg" ), 8 , 0 ],
[2 , wandb. Image("img_2.jpg" ), 7 , 1 ],
[3 , wandb. Image("img_3.jpg" ), 1 , 1 ],
]
# 対応する列で wandb.Table() を作成
columns = ["id" , "image" , "prediction" , "truth" ]
test_table = wandb. Table(data= my_data, columns= columns)
データを追加する
Tables は可変です。スクリプトが実行中に最大 200,000 行までテーブルにデータを追加できます。テーブルにデータを追加する方法は2つあります：
行を追加する : table.add_data("3a", "3b", "3c")。新しい行はリストとして表現されないことに注意してください。行がリスト形式の場合は * を使ってリストを位置引数に展開します: table.add_data(*my_row_list)。行にはテーブルの列数と同じ数のエントリが含まれている必要があります。列を追加する : table.add_column(name="col_name", data=col_data)。col_data の長さは現在のテーブルの行数と同じである必要があります。ここで col_data はリストデータや NumPy NDArray でも構いません。
データを段階的に追加する
このコードサンプルは、次第に W&B テーブルを作成し、データを追加する方法を示しています。信頼度スコアを含む事前定義された列でテーブルを定義し、推論中に行ごとにデータを追加します。また、run を再開するときにテーブルにデータを段階的に追加 することもできます。
# 各ラベルの信頼度スコアを含むテーブルの列を定義
columns = ["id" , "image" , "guess" , "truth" ]
for digit in range(10 ): # 各数字 (0-9) に対する信頼度スコア列を追加
columns. append(f "score_ { digit} " )
# 定義された列でテーブルを初期化
test_table = wandb. Table(columns= columns)
# テストデータセットを通過し、データを行ごとにテーブルに追加
# 各行は画像 ID、画像、予測されたラベル、正解ラベル、信頼度スコアを含みます
for img_id, img in enumerate(mnist_test_data):
true_label = mnist_test_data_labels[img_id] # 正解ラベル
guess_label = my_model. predict(img) # 予測ラベル
test_table. add_data(
img_id, wandb. Image(img), guess_label, true_label
) # テーブルに行データを追加
Run を再開した際にデータを追加
再開した Run において、既存のテーブルをアーティファクトから読み込み、最後のデータ行を取得して、更新されたメトリクスを追加することで W&B テーブルを段階的に更新できます。次に、互換性を保つためにテーブルを再初期化し、更新されたバージョンを W&B に再度ログに記録します。
# アーティファクトから既存のテーブルを読み込む
best_checkpt_table = wandb. use_artifact(table_tag). get(table_name)
# 再開のためにテーブルの最後のデータ行を取得
best_iter, best_metric_max, best_metric_min = best_checkpt_table. data[- 1 ]
# 必要に応じて最高のメトリクスを更新
# テーブルに更新されたデータを追加
best_checkpt_table. add_data(best_iter, best_metric_max, best_metric_min)
# 更新されたデータでテーブルを再初期化し、互換性を確保
best_checkpt_table = wandb. Table(
columns= ["col1" , "col2" , "col3" ], data= best_checkpt_table. data
)
# 更新されたテーブルを Weights & Biases にログする
wandb. log({table_name: best_checkpt_table})
データを取得する
データが Table にあるとき、列または行ごとにアクセスできます：
行イテレータ : ユーザーは Table の行イテレータを利用して、for ndx, row in table.iterrows(): ... のようにデータの行を効率的に反復処理できます。列を取得する : ユーザーは table.get_column("col_name") を使用してデータの列を取得できます。convert_to="numpy" を渡すと、列を NumPy のプリミティブ NDArray に変換できます。これは、列に wandb.Image などのメディアタイプが含まれている場合に、基になるデータに直接アクセスするのに便利です。
テーブルを保存する
スクリプトでモデルの予測のテーブルなどのデータを生成した後、それを W&B に保存して結果をリアルタイムで視覚化します。
Run にテーブルをログする
wandb.log() を使用してテーブルを Run に保存します：
run = wandb. init()
my_table = wandb. Table(columns= ["a" , "b" ], data= [["1a" , "1b" ], ["2a" , "2b" ]])
run. log({"table_key" : my_table})
同じキーにテーブルがログに記録されるたびに、新しいバージョンのテーブルが作成され、バックエンドに保存されます。これにより、複数のトレーニングステップにわたって同じテーブルをログに記録し、モデルの予測がどのように向上するかを確認したり、異なる Run 間でテーブルを比較したりすることができます。同じテーブルに最大 200,000 行までログに記録できます。
200,000 行以上をログに記録するには、以下のように制限をオーバーライドできます：
wandb.Table.MAX_ARTIFACT_ROWS = X
ただし、これにより UI でのクエリの速度低下などのパフォーマンス問題が発生する可能性があります。
プログラムによるテーブルへのアクセス
バックエンドでは、Tables は Artifacts として保存されています。特定のバージョンにアクセスする場合は、artifact API を使用して行うことができます：
with wandb. init() as run:
my_table = run. use_artifact("run-<run-id>-<table-name>:<tag>" ). get("<table-name>" )
Artifacts の詳細については、デベロッパーガイドの Artifacts チャプター を参照してください。
テーブルを視覚化する
この方法でログに記録されたテーブルは、Run ページと Project ページの両方でワークスペースに表示されます。詳細については、テーブルの視覚化と分析 を参照してください。
アーティファクトテーブル
artifact.add() を使用して、テーブルをワークスペースの代わりに Run の Artifacts セクションにログします。これは、データセットを1回ログに記録し、今後の Run のために参照したい場合に役立ちます。
run = wandb. init(project= "my_project" )
# 各重要なステップのために wandb Artifact を作成
test_predictions = wandb. Artifact("mnist_test_preds" , type= "predictions" )
# [上記のように予測データを構築]
test_table = wandb. Table(data= data, columns= columns)
test_predictions. add(test_table, "my_test_key" )
run. log_artifact(test_predictions)
画像データを使用した artifact.add() の詳細な例については、この Colab を参照してください: 画像データを使った artifact.add() の詳細な例 また Artifacts と Tables を使ったバージョン管理と重複排除データの例 に関してはこのレポートを参照してください。
アーティファクトテーブルを結合する
wandb.JoinedTable(table_1, table_2, join_key) を使用して、ローカルに構築したテーブルや他のアーティファクトから取得したテーブルを結合できます。
引数
説明
table_1
(str, wandb.Table, ArtifactEntry) アーティファクト内の wandb.Table へのパス、テーブルオブジェクト、または ArtifactEntry
table_2
(str, wandb.Table, ArtifactEntry) アーティファクト内の wandb.Table へのパス、テーブルオブジェクト、または ArtifactEntry
join_key
(str, [str, str]) 結合を行うキーまたはキーのリスト
以前にアーティファクトコンテキストでログに記録した2つのテーブルを結合するには、アーティファクトからそれらを取得し、新しいテーブルに結合した結果を格納します。この例では、'original_songs' という名前のオリジナルの曲のテーブルと 'synth_songs' という名前の同じ曲の合成バージョンのテーブルを結合する方法を示しています。以下のコード例は 2 つのテーブルを "song_id" で結合し、結果のテーブルを新しい W&B テーブルとしてアップロードします：
import wandb
run = wandb. init(project= "my_project" )
# オリジナルの曲のテーブルを取得
orig_songs = run. use_artifact("original_songs:latest" )
orig_table = orig_songs. get("original_samples" )
# 合成曲のテーブルを取得
synth_songs = run. use_artifact("synth_songs:latest" )
synth_table = synth_songs. get("synth_samples" )
# "song_id" でテーブルを結合
join_table = wandb. JoinedTable(orig_table, synth_table, "song_id" )
join_at = wandb. Artifact("synth_summary" , "analysis" )
# テーブルをアーティファクトに追加し W&B にログする
join_at. add(join_table, "synth_explore" )
run. log_artifact(join_at)
このチュートリアルを読む と、異なるアーティファクトオブジェクトに保存された 2 つのテーブルを組み合わせる方法の例が示されています。
2.1.7.4 - ログサマリーメトリクス
時間とともに変化する値に加えて、モデルや前処理ステップを要約する単一の値を追跡することも重要です。この情報を W&B Run の summary 辞書にログします。Run の summary 辞書は numpy 配列、PyTorch テンソル、TensorFlow テンソルを扱うことができます。値がこれらのタイプのいずれかの場合、バイナリファイルにテンソル全体を保存し、メトリクスを summary オブジェクトに保存します。たとえば最小値、平均、分散、パーセンタイルなどです。
最後に wandb.log でログされた値は、自動的に W&B Run の summary 辞書に設定されます。summary メトリクス辞書が変更されると、以前の値は失われます。
次のコードスニペットは、W&B にカスタムの summary メトリクスを提供する方法を示しています。
wandb. init(config= args)
best_accuracy = 0
for epoch in range(1 , args. epochs + 1 ):
test_loss, test_accuracy = test()
if test_accuracy > best_accuracy:
wandb. summary["best_accuracy" ] = test_accuracy
best_accuracy = test_accuracy
トレーニングが完了した後、既存の W&B Run の summary 属性を更新することができます。W&B Public API を使用して、summary 属性を更新してください。
api = wandb. Api()
run = api. run("username/project/run_id" )
run. summary["tensor" ] = np. random. random(1000 )
run. summary. update()
summary メトリクスをカスタマイズする
カスタム summary メトリクスは、トレーニングにおける最良のステップでのモデルのパフォーマンスを wandb.summary にキャプチャするのに便利です。たとえば、最終的な値の代わりに、最大精度や最小損失値をキャプチャしたいかもしれません。
デフォルトでは、summary は履歴からの最終的な値を使用します。summary メトリクスをカスタマイズするには、define_metric の中に summary 引数を渡します。以下の値を受け付けます。
"min""max""mean""best""last""none"
"best" を使用するには、任意の objective 引数を "minimize" または "maximize" に設定する必要があります。
次の例は、損失と精度の最小値と最大値を summary に追加する方法を示しています。
import wandb
import random
random. seed(1 )
wandb. init()
# 損失の最小値および最大値を summary に追加
wandb. define_metric("loss" , summary= "min" )
wandb. define_metric("loss" , summary= "max" )
# 精度の最小値および最大値を summary に追加
wandb. define_metric("acc" , summary= "min" )
wandb. define_metric("acc" , summary= "max" )
for i in range(10 ):
log_dict = {
"loss" : random. uniform(0 , 1 / (i + 1 )),
"acc" : random. uniform(1 / (i + 1 ), 1 ),
}
wandb. log(log_dict)
summary メトリクスを閲覧する
Run の Overview ページまたはプロジェクトの runs テーブルで summary 値を表示することができます。
Run Overview
Run Table
W&B Public API
W&B アプリに移動します。
Workspace タブを選択します。runs のリストから、summary 値をログした run の名前をクリックします。
Overview タブを選択します。Summary セクションで summary 値を表示します。
W&B アプリに移動します。
Runs タブを選択します。runs テーブル内で、summary 値の名前に基づいて列内の summary 値を表示することができます。
W&B Public API を使用して、run の summary 値を取得することができます。
次のコード例は、W&B Public API と pandas を使用して特定の run にログされた summary 値を取得する方法の一例を示しています。
import wandb
import pandas
entity = "<your-entity>"
project = "<your-project>"
run_name = "<your-run-name>" # summary 値を持つ run の名前
all_runs = []
for run in api. runs(f " { entity} / { project_name} " ):
print("Fetching details for run: " , run. id, run. name)
run_data = {
"id" : run. id,
"name" : run. name,
"url" : run. url,
"state" : run. state,
"tags" : run. tags,
"config" : run. config,
"created_at" : run. created_at,
"system_metrics" : run. system_metrics,
"summary" : run. summary,
"project" : run. project,
"entity" : run. entity,
"user" : run. user,
"path" : run. path,
"notes" : run. notes,
"read_only" : run. read_only,
"history_keys" : run. history_keys,
"metadata" : run. metadata,
}
all_runs. append(run_data)
# DataFrame に変換
df = pd. DataFrame(all_runs)
# 列名（run）に基づいて行を取得し、辞書に変換
df[df['name' ]== run_name]. summary. reset_index(drop= True ). to_dict()
2.1.7.5 - ログ軸をカスタマイズする
define_metric を使用してカスタム x 軸 を設定します。 カスタム x 軸は、トレーニング中に過去の異なるタイムステップに非同期でログを記録する必要がある場合に便利です。たとえば、RL ではエピソードごとの報酬やステップごとの報酬を追跡する場合に役立ちます。
Google Colab で define_metric を試す →
軸をカスタマイズする
デフォルトでは、すべてのメトリクスは同じ x 軸に対してログが記録されます。これは、 W&B 内部の step です。時には、以前のステップにログを記録したい場合や、別の x 軸を使用したい場合があります。
以下は、デフォルトのステップの代わりにカスタムの x 軸メトリクスを設定する例です。
import wandb
wandb. init()
# カスタム x 軸メトリクスを定義
wandb. define_metric("custom_step" )
# どのメトリクスがそれに対してプロットされるかを定義
wandb. define_metric("validation_loss" , step_metric= "custom_step" )
for i in range(10 ):
log_dict = {
"train_loss" : 1 / (i + 1 ),
"custom_step" : i** 2 ,
"validation_loss" : 1 / (i + 1 ),
}
wandb. log(log_dict)
x 軸はグロブを使用して設定することもできます。現在、文字列のプレフィックスを持つグロブのみが使用可能です。次の例では、プレフィックス "train/" を持つすべてのログされたメトリクスを、x 軸 "train/step" にプロットします:
import wandb
wandb. init()
# カスタム x 軸メトリクスを定義
wandb. define_metric("train/step" )
# 他のすべての train/ メトリクスをこのステップに使用するように設定
wandb. define_metric("train/*" , step_metric= "train/step" )
for i in range(10 ):
log_dict = {
"train/step" : 2 ** i, # W&B 内部ステップと指数的な成長
"train/loss" : 1 / (i + 1 ), # x 軸は train/step
"train/accuracy" : 1 - (1 / (1 + i)), # x 軸は train/step
"val/loss" : 1 / (1 + i), # x 軸は内部 wandb ステップ
}
wandb. log(log_dict)
2.1.7.6 - 実験からプロットを作成して追跡する
機械学習実験からプロットを作成し、追跡する。
Using the methods in wandb.plot, you can track charts with wandb.log, including charts that change over time during training. To learn more about our custom charting framework, check out this guide .
Basic charts
これらのシンプルなチャートにより、メトリクスと結果の基本的な可視化を簡単に構築できます。
Line
Scatter
Bar
Histogram
Multi-line
wandb.plot.line()
カスタムなラインプロット、任意の軸上で順序付けられたポイントのリストをログします。
data = [[x, y] for (x, y) in zip(x_values, y_values)]
table = wandb. Table(data= data, columns= ["x" , "y" ])
wandb. log(
{
"my_custom_plot_id" : wandb. plot. line(
table, "x" , "y" , title= "Custom Y vs X Line Plot"
)
}
)
これは任意の2次元軸に曲線をログするために使用できます。二つの値のリストをプロットする場合、リスト内の値の数は正確に一致する必要があります。例えば、それぞれのポイントはxとyを持っている必要があります。
See in the app
Run the code
wandb.plot.scatter()
カスタムな散布図をログします—任意の軸xとy上のポイント（x, y）のリスト。
data = [[x, y] for (x, y) in zip(class_x_scores, class_y_scores)]
table = wandb. Table(data= data, columns= ["class_x" , "class_y" ])
wandb. log({"my_custom_id" : wandb. plot. scatter(table, "class_x" , "class_y" )})
これは任意の2次元軸に散布ポイントをログするために使用できます。二つの値のリストをプロットする場合、リスト内の値の数は正確に一致する必要があります。例えば、それぞれのポイントはxとyを持っている必要があります。
See in the app
Run the code
wandb.plot.bar()
カスタムな棒グラフをログします—数行でバーとしてラベル付けされた値のリストをネイティブに：
data = [[label, val] for (label, val) in zip(labels, values)]
table = wandb. Table(data= data, columns= ["label" , "value" ])
wandb. log(
{
"my_bar_chart_id" : wandb. plot. bar(
table, "label" , "value" , title= "Custom Bar Chart"
)
}
)
これは任意の棒グラフをログするために使用できます。リスト内のラベルと値の数は正確に一致する必要があります。それぞれのデータポイントは両方を持たなければなりません。
See in the app
Run the code
wandb.plot.histogram()
カスタムなヒストグラムをログします—発生のカウント/頻度でリスト内の値をビンへソートします—数行でネイティブに。予測信頼度スコア（scores）のリストがあって、その分布を可視化したいとします。
data = [[s] for s in scores]
table = wandb. Table(data= data, columns= ["scores" ])
wandb. log({"my_histogram" : wandb. plot. histogram(table, "scores" , title= "Histogram" )})
これは任意のヒストグラムをログするために使用できます。dataはリストのリストで、行と列の2次元配列をサポートすることを意図しています。
See in the app
Run the code
wandb.plot.line_series()
複数の線、または複数の異なるx-y座標ペアのリストを一つの共有x-y軸上にプロットします：
wandb. log(
{
"my_custom_id" : wandb. plot. line_series(
xs= [0 , 1 , 2 , 3 , 4 ],
ys= [[10 , 20 , 30 , 40 , 50 ], [0.5 , 11 , 72 , 3 , 41 ]],
keys= ["metric Y" , "metric Z" ],
title= "Two Random Metrics" ,
xname= "x units" ,
)
}
)
xとyのポイントの数は正確に一致する必要があることに注意してください。複数のy値のリストに合ったx値のリストを一つ提供することも、または各y値のリストに対して個別のx値のリストを提供することもできます。
See in the app
Model evaluation charts
これらのプリセットチャートは、wandb.plotメソッド内蔵で、スクリプトからチャートを直接ログして、UIで正確に確認したい情報をすぐに把握できます。
Precision-recall curves
ROC curves
Confusion matrix
wandb.plot.pr_curve()
Precision-Recall curve を1行で作成します：
wandb. log({"pr" : wandb. plot. pr_curve(ground_truth, predictions)})
コードが以下のものにアクセスできるときに、これをログできます：
一連の例に対するモデルの予測スコア（predictions）
それらの例に対応する正解ラベル（ground_truth）
（オプションで）ラベル/クラス名のリスト（labels=["cat", "dog", "bird"...] で、ラベルインデックスが0はcat、1はdog、2はbirdを意味するなど）
（オプションで）プロットで可視化するラベルのサブセット
See in the app
Run the code
wandb.plot.roc_curve()
ROC curve を1行で作成します：
wandb. log({"roc" : wandb. plot. roc_curve(ground_truth, predictions)})
コードが以下のものにアクセスできるときに、これをログできます：
一連の例に対するモデルの予測スコア（predictions）
それらの例に対応する正解ラベル（ground_truth）
（オプションで）ラベル/クラス名のリスト（labels=["cat", "dog", "bird"...] で、ラベルインデックスが0はcat、1はdog、2はbirdを意味するなど）
（オプションで）プロットで可視化するラベルのサブセット（まだリスト形式）
See in the app
Run the code
wandb.plot.confusion_matrix()
マルチクラスの混同行列 を1行で作成します：
cm = wandb. plot. confusion_matrix(
y_true= ground_truth, preds= predictions, class_names= class_names
)
wandb. log({"conf_mat" : cm})
コードが以下のものにアクセスできるときに、これをログできます：
一連の例に対するモデルの予測ラベル（preds）または正規化された確率スコア（probs）。確率は（例の数、クラスの数）という形でなければなりません。確率または予測のどちらでも良いですが両方を提供することはできません。
それらの例に対応する正解ラベル（y_true）
文字列のラベル/クラス名のフルリスト（例：class_names=["cat", "dog", "bird"] で、インデックス0がcat、1がdog、2がbirdである場合）
See in the app
Run the code
Interactive custom charts
完全なカスタマイズを行う場合、内蔵のCustom Chart preset を調整するか、新しいプリセットを作成し、チャートを保存します。チャートIDを使用して、そのカスタムプリセットに直接スクリプトからデータをログします。
# 作成したい列を持つテーブルを作成
table = wandb. Table(data= data, columns= ["step" , "height" ])
# テーブルの列からチャートのフィールドへマップ
fields = {"x" : "step" , "value" : "height" }
# 新しいカスタムチャートプリセットにテーブルを使用
# 自分の保存したチャートプリセットを使用するには、vega_spec_nameを変更
# タイトルを編集するには、string_fieldsを変更
my_custom_chart = wandb. plot_table(
vega_spec_name= "carey/new_chart" ,
data_table= table,
fields= fields,
string_fields= {"title" : "Height Histogram" },
)
Run the code
Matplotlib and Plotly plots
W&BのCustom Charts をwandb.plotで使用する代わりに、matplotlib やPlotly で生成されたチャートをログすることができます。
import matplotlib.pyplot as plt
plt. plot([1 , 2 , 3 , 4 ])
plt. ylabel("some interesting numbers" )
wandb. log({"chart" : plt})
matplotlibプロットまたは図オブジェクトをwandb.log()に渡すだけです。デフォルトでは、プロットをPlotly プロットに変換します。プロットを画像としてログしたい場合はwandb.Imageにプロットを渡すことができます。Plotlyチャートを直接受け入れることもできます。
「空のプロットをログしようとしました」というエラーが発生した場合は、プロットとは別に図をfig = plt.figure()として保存してから、wandb.logでfigをログできます。
Log custom HTML to W&B Tables
W&Bでは、PlotlyやBokehからインタラクティブなチャートをHTMLとしてログし、Tablesに追加することをサポートしています。
インタラクティブなPlotlyチャートをwandb TablesにHTML形式でログできます。
import wandb
import plotly.express as px
# 新しいrunを初期化
run = wandb. init(project= "log-plotly-fig-tables" , name= "plotly_html" )
# テーブルを作成
table = wandb. Table(columns= ["plotly_figure" ])
# Plotly図のパスを作成
path_to_plotly_html = "./plotly_figure.html"
# 例のPlotly図
fig = px. scatter(x= [0 , 1 , 2 , 3 , 4 ], y= [0 , 1 , 4 , 9 , 16 ])
# Plotly図をHTMLに書き込み
# auto_playをFalseに設定すると、アニメーション付きのPlotlyチャートが自動的にテーブル内で再生されないようにします
fig. write_html(path_to_plotly_html, auto_play= False )
# Plotly図をHTMLファイルとしてTableに追加
table. add_data(wandb. Html(path_to_plotly_html))
# Tableをログ
run. log({"test_table" : table})
wandb. finish()
インタラクティブなBokehチャートをwandb TablesにHTML形式でログできます。
from scipy.signal import spectrogram
import holoviews as hv
import panel as pn
from scipy.io import wavfile
import numpy as np
from bokeh.resources import INLINE
hv. extension("bokeh" , logo= False )
import wandb
def save_audio_with_bokeh_plot_to_html (audio_path, html_file_name):
sr, wav_data = wavfile. read(audio_path)
duration = len(wav_data) / sr
f, t, sxx = spectrogram(wav_data, sr)
spec_gram = hv. Image((t, f, np. log10(sxx)), ["Time (s)" , "Frequency (hz)" ]). opts(
width= 500 , height= 150 , labelled= []
)
audio = pn. pane. Audio(wav_data, sample_rate= sr, name= "Audio" , throttle= 500 )
slider = pn. widgets. FloatSlider(end= duration, visible= False )
line = hv. VLine(0 ). opts(color= "white" )
slider. jslink(audio, value= "time" , bidirectional= True )
slider. jslink(line, value= "glyph.location" )
combined = pn. Row(audio, spec_gram * line, slider). save(html_file_name)
html_file_name = "audio_with_plot.html"
audio_path = "hello.wav"
save_audio_with_bokeh_plot_to_html(audio_path, html_file_name)
wandb_html = wandb. Html(html_file_name)
run = wandb. init(project= "audio_test" )
my_table = wandb. Table(columns= ["audio_with_plot" ], data= [[wandb_html], [wandb_html]])
run. log({"audio_table" : my_table})
run. finish()
2.1.7.7 - 実験管理で CSV ファイルを追跡する
W&B にデータをインポートしてログする方法
W&B Python ライブラリを使用して、CSV ファイルをログし、W&B ダッシュボード で可視化します。W&B ダッシュボードは、機械学習モデルからの結果を整理し可視化する中心的な場所です。これは、W&B にログされていない以前の機械学習実験の情報を含む CSV ファイル やデータセットを含む CSV ファイル がある場合に特に便利です。
データセットの CSV ファイルをインポートしてログする
W&B Artifacts を使用することをお勧めします。CSV ファイルの内容を再利用しやすくするためです。
まず、CSV ファイルをインポートします。以下のコードスニペットでは、iris.csv ファイル名をあなたの CSV ファイル名に置き換えてください:
import wandb
import pandas as pd
# CSV を新しい DataFrame に読み込む
new_iris_dataframe = pd. read_csv("iris.csv" )
CSV ファイルを W&B Table に変換し、W&B ダッシュボード を利用します。
# DataFrame を W&B Table に変換
iris_table = wandb. Table(dataframe= new_iris_dataframe)
次に、W&B Artifact を作成し、テーブルを Artifact に追加します:
# テーブルを Artifact に追加し、行制限を 200,000 に増やし、再利用しやすくする
iris_table_artifact = wandb. Artifact("iris_artifact" , type= "dataset" )
iris_table_artifact. add(iris_table, "iris_table" )
# データを保存するために、生の CSV ファイルを Artifact 内にログする
iris_table_artifact. add_file("iris.csv" )
W&B Artifacts についての詳細は、Artifacts チャプター を参照してください。
最後に、wandb.init を使用して W&B で追跡しログするために新しい W&B Run を開始します:
# データをログするために W&B run を開始
run = wandb. init(project= "tables-walkthrough" )
# テーブルをログして run で可視化
run. log({"iris" : iris_table})
# そして行制限を増やすためにアーティファクトとしてログ!
run. log_artifact(iris_table_artifact)
wandb.init() API は新しいバックグラウンドプロセスを開始し、データを Run にログし、デフォルトで wandb.ai に同期します。W&B ワークスペースダッシュボードでライブの可視化を表示します。以下の画像はコードスニペットのデモの出力を示しています。
以下は、前述のコードスニペットを含む完全なスクリプトです:
import wandb
import pandas as pd
# CSV を新しい DataFrame に読み込む
new_iris_dataframe = pd. read_csv("iris.csv" )
# DataFrame を W&B Table に変換
iris_table = wandb. Table(dataframe= new_iris_dataframe)
# テーブルを Artifact に追加し、行制限を 200,000 に増やし、再利用しやすくする
iris_table_artifact = wandb. Artifact("iris_artifact" , type= "dataset" )
iris_table_artifact. add(iris_table, "iris_table" )
# データを保存するために、生の CSV ファイルを Artifact 内にログする
iris_table_artifact. add_file("iris.csv" )
# データをログするために W&B run を開始
run = wandb. init(project= "tables-walkthrough" )
# テーブルをログして run で可視化
run. log({"iris" : iris_table})
# そして行制限を増やすためにアーティファクトとしてログ!
run. log_artifact(iris_table_artifact)
# run を終了する (ノートブックで便利)
run. finish()
実験の CSV をインポートしてログする
場合によっては、実験の詳細が CSV ファイルにあることがあります。そのような CSV ファイルに共通する詳細には次のようなものがあります:
実験
モデル名
ノート
タグ
層の数
最終トレイン精度
最終評価精度
トレーニング損失
実験 1
mnist-300-layers
トレーニングデータに過剰適合
[latest]
300
0.99
0.90
[0.55, 0.45, 0.44, 0.42, 0.40, 0.39]
実験 2
mnist-250-layers
現行の最良モデル
[prod, best]
250
0.95
0.96
[0.55, 0.45, 0.44, 0.42, 0.40, 0.39]
実験 3
mnist-200-layers
ベースラインモデルより悪かったため、デバッグ必要
[debug]
200
0.76
0.70
[0.55, 0.45, 0.44, 0.42, 0.40, 0.39]
…
…
…
…
…
…
…
実験 N
mnist-X-layers
ノート
…
…
…
…
[…, …]
W&B は実験の CSV ファイルを受け取り、W&B 実験 Run に変換することができます。次のコードスニペットとコードスクリプトで、実験の CSV ファイルをインポートしてログする方法を示しています:
最初に、CSV ファイルを読み込んで Pandas DataFrame に変換します。"experiments.csv" を CSV ファイル名に置き換えてください:
import wandb
import pandas as pd
FILENAME = "experiments.csv"
loaded_experiment_df = pd. read_csv(FILENAME)
PROJECT_NAME = "Converted Experiments"
EXPERIMENT_NAME_COL = "Experiment"
NOTES_COL = "Notes"
TAGS_COL = "Tags"
CONFIG_COLS = ["Num Layers" ]
SUMMARY_COLS = ["Final Train Acc" , "Final Val Acc" ]
METRIC_COLS = ["Training Losses" ]
# 作業を容易にするための Pandas DataFrame のフォーマット
for i, row in loaded_experiment_df. iterrows():
run_name = row[EXPERIMENT_NAME_COL]
notes = row[NOTES_COL]
tags = row[TAGS_COL]
config = {}
for config_col in CONFIG_COLS:
config[config_col] = row[config_col]
metrics = {}
for metric_col in METRIC_COLS:
metrics[metric_col] = row[metric_col]
summaries = {}
for summary_col in SUMMARY_COLS:
summaries[summary_col] = row[summary_col]
次に、wandb.init()
run = wandb. init(
project= PROJECT_NAME, name= run_name, tags= tags, notes= notes, config= config
)
実験が進行するにつれて、メトリクスのすべてのインスタンスをログし、W&B で表示、クエリ、および分析可能にすることをお勧めするかもしれません。これを実現するには、run.log()
また、run の結果を定義するために最終的なサマリーメトリクスをオプションでログすることもできます。これを実現するには、W&B define_metricrun.summary.update() によりサマリーメトリクスを run に追加します:
run. summary. update(summaries)
サマリーメトリクスの詳細については、Log Summary Metrics を参照してください。
以下は、上記のサンプルテーブルを W&B ダッシュボード に変換する完全な例のスクリプトです:
FILENAME = "experiments.csv"
loaded_experiment_df = pd. read_csv(FILENAME)
PROJECT_NAME = "Converted Experiments"
EXPERIMENT_NAME_COL = "Experiment"
NOTES_COL = "Notes"
TAGS_COL = "Tags"
CONFIG_COLS = ["Num Layers" ]
SUMMARY_COLS = ["Final Train Acc" , "Final Val Acc" ]
METRIC_COLS = ["Training Losses" ]
for i, row in loaded_experiment_df. iterrows():
run_name = row[EXPERIMENT_NAME_COL]
notes = row[NOTES_COL]
tags = row[TAGS_COL]
config = {}
for config_col in CONFIG_COLS:
config[config_col] = row[config_col]
metrics = {}
for metric_col in METRIC_COLS:
metrics[metric_col] = row[metric_col]
summaries = {}
for summary_col in SUMMARY_COLS:
summaries[summary_col] = row[summary_col]
run = wandb. init(
project= PROJECT_NAME, name= run_name, tags= tags, notes= notes, config= config
)
for key, val in metrics. items():
if isinstance(val, list):
for _val in val:
run. log({key: _val})
else :
run. log({key: val})
run. summary. update(summaries)
run. finish()
2.1.7.8 - 分散トレーニング実験をログする
W&B を使用して、複数の GPU を用いた分散トレーニング実験をログする。
分散トレーニングでは、複数の GPU を使ってモデルが並列にトレーニングされます。W&B は、分散トレーニング実験をトラッキングするための2つのパターンをサポートしています。
ワンプロセス : 単一のプロセスから W&B を初期化し（wandb.initwandb.logPyTorch Distributed Data Parallel （DDP）クラスを使った分散トレーニング実験のログに一般的なソリューションです。ユーザーは他のプロセスからメインのロギングプロセスにデータを送るために、多重処理キュー（または他の通信プリミティブ）を使用することもあります。多数のプロセス : 各プロセスで W&B を初期化し（wandb.initwandb.loggroup パラメータを使用して共有実験を定義し、W&B App UI のログした値を一緒にグループ化します。
次に示す例は、PyTorch DDP を使って単一のマシン上で2つの GPU でメトリクスを W&B でトラッキングする方法を示しています。PyTorch DDP （torch.nn の DistributedDataParallel）は、分散トレーニングのための人気のあるライブラリです。基本的な原則はどの分散トレーニングセットアップにも適用されますが、実装の詳細は異なる場合があります。
方法 1: ワンプロセス
この方法では、ランク 0 のプロセスのみをトラッキングします。この方法を実装するには、ランク 0 のプロセス内で W&B を初期化し（wandb.init）、W&B Run を開始し、メトリクスをログ（wandb.log）します。この方法はシンプルで堅牢ですが、他のプロセスからモデルメトリクス（例えば、ロス値や各バッチからの入力）をログしません。使用状況やメモリなどのシステムメトリクスは、すべての GPU に利用可能な情報であるため、引き続きログされます。
単一のプロセスで利用可能なメトリクスのみをトラッキングする場合、この方法を使用してください。 典型的な例には、GPU/CPU 使用率、共有 validation set 上の挙動、勾配とパラメータ、代表的なデータ例上の損失値が含まれます。
サンプル Python スクリプト (log-ddp.py) では、ランクが 0 かどうかを確認します。そのためには、まず torch.distributed.launch を使って複数のプロセスを開始します。次に、--local_rank コマンドライン引数を使用してランクを確認します。ランクが 0 に設定されている場合、train()wandb ロギングを設定します。Python スクリプト内では、次のように確認します。
if __name__ == "__main__" :
# 引数を取得
args = parse_args()
if args. local_rank == 0 : # メインプロセスでのみ
# wandb run を初期化
run = wandb. init(
entity= args. entity,
project= args. project,
)
# DDP でモデルをトレーニング
train(args, run)
else :
train(args)
W&B App UI を探索して、単一プロセスからトラッキングされたメトリクスの ダッシュボードの例 をご覧ください。ダッシュボードは、両方の GPU に対してトラッキングされた温度や使用率などのシステムメトリクスを表示します。
しかし、エポックとバッチサイズの関数としてのロス値は、単一の GPU からのみログされました。
方法 2: 多数のプロセス
この方法では、ジョブ内の各プロセスをトラッキングし、各プロセスから個別に wandb.init() と wandb.log() を呼び出します。トレーニングの終了時には wandb.finish() を呼び出して、run が完了したことを示し、すべてのプロセスが正常に終了するようにすることをお勧めします。
この方法では、さらに多くの情報がログにアクセス可能になりますが、W&B App UI に複数の W&B Runs が報告されます。複数の実験にわたって W&B Runs を追跡するのが困難になる可能性があります。これを軽減するために、W&B を初期化する際に group パラメータに値を与えて、どの W&B Run がどの実験に属しているかを追跡します。実験でのトレーニングと評価の W&B Runs の追跡方法の詳細については、Group Runs を参照してください。
個々のプロセスからメトリクスをトラッキングしたい場合はこの方法を使用してください。 典型的な例には、各ノードでのデータと予測（データ分散のデバッグ用）やメインノードの外側での個々のバッチのメトリクスが含まれます。この方法は、すべてのノードからのシステムメトリクスやメインノードで利用可能な要約統計データを取得するために必要ありません。
以下の Python コードスニペットは、W&B を初期化する際に group パラメータを設定する方法を示しています。
if __name__ == "__main__" :
# 引数を取得
args = parse_args()
# run を初期化
run = wandb. init(
entity= args. entity,
project= args. project,
group= "DDP" , # 実験のすべての run を1つのグループに
)
# DDP でモデルをトレーニング
train(args, run)
W&B App UI を探索して、複数のプロセスからトラッキングされたメトリクスの ダッシュボードの例 をご覧ください。左側のサイドバーに 2 つの W&B Runs が組み合わされたものが示されています。グループをクリックして、その実験専用のグループページを表示します。専用のグループページには、各プロセスから別々にログされたメトリクスが表示されます。
前の画像は W&B App UI ダッシュボードを示しています。サイドバーには2つの実験が表示されています。1つは「null」とラベル付けされ、黄色のボックスで囲まれた2つ目は「DPP」と呼ばれます。グループを展開すると（[Group] ドロップダウンを選択）、その実験に関連する W&B Runs を見ることができます。
共通の分散トレーニングの問題を避けるために W&B Service を使用
W&B と分散トレーニングを使用する場合、2つの一般的な問題に遭遇することがあります。
トレーニングの開始時のハング - wandb プロセスが、分散トレーニングからの多重処理と干渉するためにハングすることがあります。トレーニングの終了時のハング - トレーニングジョブが、wandb プロセスがいつ終了する必要があるかを知らない場合、ハングすることがあります。Python スクリプトの最後に wandb.finish() API を呼び出して、W&B に Run が終了したことを通知します。wandb.finish() API はデータのアップロードを完了し、W&B の終了を引き起こします。
wandb service を使用して、分散ジョブの信頼性を向上させることをお勧めします。上記のトレーニングの問題は、wandb service が利用できない W&B SDK のバージョンで一般的に見られます。
W&B Service の有効化
お使いのバージョンの W&B SDK に応じて、すでにデフォルトで W&B Service が有効になっているかもしれません。
W&B SDK 0.13.0 以上
W&B SDK バージョン 0.13.0 以上のバージョンでは、W&B Service がデフォルトで有効です。
W&B SDK 0.12.5 以上
W&B SDK バージョン 0.12.5 以上の場合は、Python スクリプトを修正して W&B Service を有効にします。wandb.require メソッドを使用し、メイン関数内で文字列 "service" を渡します。
if __name__ == "__main__" :
main()
def main ():
wandb. require("service" )
# スクリプトの残りがここに来る
最適な体験のために、最新バージョンへのアップグレードをお勧めします。
W&B SDK 0.12.4 以下
W&B SDK バージョン 0.12.4 以下を使用する場合は、マルチスレッドを代わりに使用するために、WANDB_START_METHOD 環境変数を "thread" に設定します。
マルチプロセスの例々
以下のコードスニペットは、高度な分散ユースケースの一般的なメソッドを示しています。
プロセスの生成
ワークスレッドを生成するプロセス内で W&B Run を開始する場合は、メイン関数で wandb.setup() メソッドを使用します。
import multiprocessing as mp
def do_work (n):
run = wandb. init(config= dict(n= n))
run. log(dict(this= n * n))
def main ():
wandb. setup()
pool = mp. Pool(processes= 4 )
pool. map(do_work, range(4 ))
if __name__ == "__main__" :
main()
W&B Run の共有
W&B Run オブジェクトを引数として渡して、プロセス間で W&B Runs を共有します。
def do_work (run):
run. log(dict(this= 1 ))
def main ():
run = wandb. init()
p = mp. Process(target= do_work, kwargs= dict(run= run))
p. start()
p. join()
if __name__ == "__main__" :
main()
記録の順序は保証できないことに注意してください。同期はスクリプトの作成者が行う必要があります。
2.1.8 - 実験を再現する
実験を再現し、チームメンバーが作成した結果を検証して確認します。
実験を再現する前に、以下の事項に注意する必要があります：
run がログされたプロジェクトの名前
再現したい run の名前
実験を再現するには：
run がログされたプロジェクトに移動します。
左のサイドバーで Workspace タブを選択します。
run のリストから再現したい run を選択します。
Overview をクリックします。
続けるには、指定されたハッシュで実験のコードをダウンロードするか、実験のリポジトリ全体をクローンします。
Python スクリプトまたはノートブックをダウンロード
GitHub
実験の Python スクリプトまたはノートブックをダウンロードします：
Command フィールドで、実験を作成したスクリプトの名前をメモしておきます。左のナビゲーションバーで Code タブを選択します。
スクリプトまたはノートブックに対応するファイルの横にある Download をクリックします。
チームメイトが実験を作成するときに使用した GitHub リポジトリをクローンします。以下の手順で行います：
必要に応じて、チームメイトが実験を作成する際に使用した GitHub リポジトリへのアクセス権を取得します。
GitHub リポジトリの URL を含む Git repository フィールドをコピーします。
リポジトリをクローンします:
git clone https://github.com/your-repo.git && cd your-repo
Git state フィールドをターミナルにコピー＆ペーストします。Git state は、チームメイトが実験を作成するときに使用した正確なコミットをチェックアウトする一連の Git コマンドです。以下のコードスニペットで指定されている値を自分の値に置き換えます：
git checkout -b "<run-name>" 0123456789012345678901234567890123456789
左のナビゲーションバーで Files を選択します。
requirements.txt ファイルをダウンロードし、作業ディレクトリーに保存します。このディレクトリーには、クローンした GitHub リポジトリまたはダウンロードした Python スクリプトまたはノートブックが含まれている必要があります。
（推奨）Python 仮想環境を作成します。
requirements.txt ファイルに指定された要件をインストールします。
pip install -r requirements.txt
これでコードと依存関係が揃ったので、スクリプトまたはノートブックを実行して実験を再現できます。リポジトリをクローンした場合は、スクリプトまたはノートブックが置かれているディレクトリーに移動する必要があるかもしれません。そうでなければ、作業ディレクトリーからスクリプトまたはノートブックを実行できます。
Python ノートブック
Python スクリプト
Python ノートブックをダウンロードした場合、ノートブックをダウンロードしたディレクトリーに移動して、以下のコマンドをターミナルで実行します:
Python スクリプトをダウンロードした場合、スクリプトをダウンロードしたディレクトリーに移動して、ターミナルで以下のコマンドを実行してください。<>で囲まれた値を自分のものに置き換えます：
python <your-script-name>.py
2.1.9 - 実験管理の制限とパフォーマンス
W&B のページを、これらの推奨範囲内でログを記録することにより、より速く反応がよい状態に保ちましょう。
ページを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 を追加し、コンソールの出力をアカウントチームまたはサポートチームと共有してください。
2.1.10 - データのインポートとエクスポート
MLFlow から データ をインポートし、保存した データ を W&B にエクスポートまたは更新します。
データをエクスポートまたはインポートするには、W&B パブリックAPIを使用します。
この機能には python>=3.8 が必要です
MLFlow からデータをインポート
W&B は、MLFlow からのデータのインポートをサポートしており、実験、runs、アーティファクト、メトリクス、その他のメタデータを含みます。
依存関係をインストール：
# 注意: これは py38+ が必要です
pip install wandb[ importers]
W&B にログインします。初めてログインする場合は、表示されるプロンプトに従ってください。
既存の MLFlow サーバーからすべての run をインポートします:
from wandb.apis.importers.mlflow import MlflowImporter
importer = MlflowImporter(mlflow_tracking_uri= "..." )
runs = importer. collect_runs()
importer. import_runs(runs)
デフォルトでは、importer.collect_runs() は MLFlow サーバーからすべての run を収集します。特定のサブセットをアップロードしたい場合は、自分で runs イテラブルを構築し、それをインポーターに渡すことができます。
import mlflow
from wandb.apis.importers.mlflow import MlflowRun
client = mlflow. tracking. MlflowClient(mlflow_tracking_uri)
runs: Iterable[MlflowRun] = []
for run in mlflow_client. search_runs(... ):
runs. append(MlflowRun(run, client))
importer. import_runs(runs)
アーティファクトのインポートをスキップするには、artifacts=False を渡します:
importer. import_runs(runs, artifacts= False )
特定の W&B エンティティとプロジェクトにインポートするには、Namespace を渡します:
from wandb.apis.importers import Namespace
importer. import_runs(runs, namespace= Namespace(entity, project))
データのエクスポート
パブリックAPIを使用して、W&B に保存したデータをエクスポートまたは更新します。このAPIを使用する前に、スクリプトからデータをログします。詳細はクイックスタート を確認してください。
パブリックAPIのユースケース
データのエクスポート : カスタム分析のために Jupyter ノートブックにデータフレームを取り込みます。データを探索した後、例えば wandb.init(job_type="analysis") のように新しい分析 run を作成し、結果を記録して学びを同期できます。既存の runs の更新 : W&B run に関連して記録されたデータを更新することができます。例えば、最初はログされていなかったアーキテクチャーやハイパーパラメーターの情報を追加するために設定を更新することがあるでしょう。
利用可能な関数の詳細については、生成されたリファレンスドキュメント を参照してください。
APIキーを作成する
APIキーは、マシンをW&Bに認証します。ユーザープロフィールからAPIキーを生成できます。
右上のユーザープロフィールアイコンをクリックします。
ユーザー設定 を選択し、APIキー セクションまでスクロールします。表示 をクリックします。表示されるAPIキーをコピーします。APIキーを非表示にするには、ページを再読み込みします。
run パスを見つける
パブリックAPIを使用するには、しばしば <entity>/<project>/<run_id> という形式の run パスが必要になります。アプリUIでrunページを開き、Overviewタブ をクリックしてrunパスを取得します。
run データをエクスポートする
完了済みまたはアクティブな run からデータをダウンロードします。一般的な用途には、カスタム分析のために Jupyter ノートブックにデータフレームをダウンロードしたり、カスタムロジックを使用して自動化された環境で利用したりすることが含まれます。
import wandb
api = wandb. Api()
run = api. run("<entity>/<project>/<run_id>" )
run オブジェクトで最もよく使用される属性は次のとおりです:
属性
意味
run.configrun の設定情報を保持する辞書。トレーニング run のハイパーパラメーターや、データセットアーティファクトを作成するためのrun に使用する前処理メソッドなどが含まれます。これらはrun の入力と考えてください。
run.history()モデルがトレーニングされている間に変化する値を保存することを意図した辞書のリスト。wandb.log() コマンドはこのオブジェクトに追記します。
run.summaryrun の結果を総括した情報の辞書。これには精度や損失のようなスカラー値や大きなファイルが含まれます。デフォルトでは、wandb.log()がログされた時系列の最終値をサマリーに設定します。サマリーの内容は直接設定することもできます。サマリーはrun の出力と考えてください。
過去の runs データも変更したり更新したりすることができます。デフォルトでは、APIオブジェクトのインスタンス1つにつき、すべてのネットワークリクエストがキャッシュされます。実行中のスクリプトでリアルタイム情報が必要な場合、api.flush() を呼び出して更新された値を取得してください。
属性の理解
以下のrunに対して:
n_epochs = 5
config = {"n_epochs" : n_epochs}
run = wandb. init(project= project, config= config)
for n in range(run. config. get("n_epochs" )):
run. log(
{"val" : random. randint(0 , 1000 ), "loss" : (random. randint(0 , 1000 ) / 1000.00 )}
)
run. finish()
これは上記のrunオブジェクトの属性に対する異なる出力です。
run.configrun.history() _step val loss _runtime _timestamp
0 0 500 0.244 4 1644345412
1 1 45 0.521 4 1644345412
2 2 240 0.785 4 1644345412
3 3 31 0.305 4 1644345412
4 4 525 0.041 4 1644345412
run.summary{
"_runtime" : 4 ,
"_step" : 4 ,
"_timestamp" : 1644345412 ,
"_wandb" : {"runtime" : 3 },
"loss" : 0.041 ,
"val" : 525 ,
}
サンプリング
デフォルトの history メソッドは、メトリクスを固定されたサンプル数（デフォルトは500）にサンプリングします。大規模なrunのすべてのデータをエクスポートしたい場合は、run.scan_history() メソッドを使用してください。詳細はAPIリファレンス を参照してください。
複数の runs のクエリ
このサンプルスクリプトはプロジェクトを検索し、CSVにrun の名前、設定、サマリーステータスを出力します。 <entity> と <project> をそれぞれあなたのW&Bエンティティとプロジェクト名に置き換えてください。
import pandas as pd
import wandb
api = wandb. Api()
entity, project = "<entity>" , "<project>"
runs = api. runs(entity + "/" + project)
summary_list, config_list, name_list = [], [], []
for run in runs:
# .summary には、精度のようなメトリクスの出力キー/値が含まれています。
# ._json_dict を呼び出して大きなファイルを省略します
summary_list. append(run. summary. _json_dict)
# .config にはハイパーパラメーターが含まれています。
# _ で始まる特別な値は削除します。
config_list. append({k: v for k, v in run. config. items() if not k. startswith("_" )})
# .name は、run の人間が読み取り可能な名前です。
name_list. append(run. name)
runs_df = pd. DataFrame(
{"summary" : summary_list, "config" : config_list, "name" : name_list}
)
runs_df. to_csv("project.csv" )
W&B API は、api.runs() を使用してプロジェクト内の runs を横断してクエリを実行する方法も提供しています。最も一般的なユースケースはカスタム分析のために runs データをエクスポートすることです。クエリインターフェースは MongoDB が使用するもの と同じです。
runs = api. runs(
"username/project" ,
{"$or" : [{"config.experiment_name" : "foo" }, {"config.experiment_name" : "bar" }]},
)
print(f "Found { len(runs)} runs" )
api.runs を呼び出すと、反復可能でリストのように動作する Runs オブジェクトが返されます。デフォルトでは、オブジェクトは要求に応じて1回に50のrunを順番にロードしますが、per_page キーワード引数を使用してページごとにロードする数を変更できます。
api.runs はorderキーワード引数も受け取ります。デフォルトの順序は -created_at です。昇順にするには +created_at を指定してください。設定やサマリーの値でソートすることもできます。例えば、summary.val_acc または config.experiment_name です。
エラーハンドリング
W&B サーバーと話す際にエラーが発生すると、wandb.CommErrorが発生します。元の例外は exc 属性を通じて調査できます。
API を通じて最新の git コミットを取得する
UIでは、runをクリックし、その run ページの Overview タブをクリックして最新の git コミットを見ることができます。それはまた、ファイル wandb-metadata.json の中にあります。パブリックAPIを使用して、run.commitを使用して git ハッシュを取得できます。
run 中の run の名前とIDを取得する
wandb.init() を呼び出した後、スクリプトからランダム run IDまたは人間読み書き可能なrun名にアクセスできます。
一意の run ID（8文字のハッシュ）：wandb.run.id
ランダム run 名前（人間読み書き可能）：wandb.run.name
run の識別子を効果的に設定する方法について考えている場合、以下を推奨します：
run ID ：生成されたハッシュのままにしておきます。これはプロジェクト内の run で一意である必要があります。run 名前 ：短く、読み書き可能で、おそらく一意であるべきです。そうすれば、チャートの異なる線間で違いをつけることができます。run ノート ：run内で何をしているかを簡単に説明するのに最適です。wandb.init(notes="your notes here") で設定できます。run タグ ：run タグで動的に追跡し、UIでフィルターを使用して興味のある run に絞り込みます。スクリプトからタグを設定し、runsテーブルやrunページのoverviewタブでUIからも編集できます。詳細な指示はこちら を参照してください。
公開APIの例
matplotlib または seaborn で視覚化するためにデータをエクスポート
一般的なエクスポートパターンについては、APIの例 を確認してください。また、カスタムプロットや拡張されたrunテーブルでダウンロードボタンをクリックして、ブラウザからCSVをダウンロードすることもできます。
run からメトリクスを読む
この例では、wandb.log({"accuracy": acc})で保存されたrunのタイムスタンプと精度を出力します。
import wandb
api = wandb. Api()
run = api. run("<entity>/<project>/<run_id>" )
if run. state == "finished" :
for i, row in run. history(). iterrows():
print(row["_timestamp" ], row["accuracy" ])
runs のフィルタリング
MongoDBクエリ言語を使用してフィルターできます。
日付
runs = api. runs(
"<entity>/<project>" ,
{"$and" : [{"created_at" : {"$lt" : "YYYY-MM-DDT##" , "$gt" : "YYYY-MM-DDT##" }}]},
)
特定の run のメトリクスを読む
run から特定のメトリクスを取り出すには、keys 引数を使用します。run.history() の場合、デフォルトのサンプル数は500です。特定のメトリクスを含まないログステップは、出力データフレームで NaN として表示されます。keys 引数を使用すると、APIは指定したメトリックキーを含むステップをより頻繁にサンプリングします。
import wandb
api = wandb. Api()
run = api. run("<entity>/<project>/<run_id>" )
if run. state == "finished" :
for i, row in run. history(keys= ["accuracy" ]). iterrows():
print(row["_timestamp" ], row["accuracy" ])
2つの run を比較する
これは run1 と run2 の間で異なる設定パラメーターを出力します。
import pandas as pd
import wandb
api = wandb. Api()
# `<entity>`, `<project>`, `<run_id>` で置き換える
run1 = api. run("<entity>/<project>/<run_id>" )
run2 = api. run("<entity>/<project>/<run_id>" )
df = pd. DataFrame([run1. config, run2. config]). transpose()
df. columns = [run1. name, run2. name]
print(df[df[run1. name] != df[run2. name]])
出力：
c_10_sgd_0.025_0.01_long_switch base_adam_4_conv_2fc
batch_size 32 16
n_conv_layers 5 4
optimizer rmsprop adam
run が完了した後に、run のメトリクスを更新する
この例では、以前のrunの精度を 0.9 に設定します。また、numpy_array のヒストグラムに以前のrunの精度ヒストグラムを変更します。
import wandb
api = wandb. Api()
run = api. run("<entity>/<project>/<run_id>" )
run. summary["accuracy" ] = 0.9
run. summary["accuracy_histogram" ] = wandb. Histogram(numpy_array)
run. summary. update()
完了した run でメトリクスをリネームする
この例ではテーブル内のサマリー列の名前を変更します。
import wandb
api = wandb. Api()
run = api. run("<entity>/<project>/<run_id>" )
run. summary["new_name" ] = run. summary["old_name" ]
del run. summary["old_name" ]
run. summary. update()
列のリネームはテーブルにのみ適用されます。チャートは元の名前でメトリクスを参照し続けます。
既存の run の設定を更新する
この例では設定のひとつを更新します。
import wandb
api = wandb. Api()
run = api. run("<entity>/<project>/<run_id>" )
run. config["key" ] = updated_value
run. update()
システムリソースの消費をCSVファイルにエクスポートする
以下のスニペットは、システムリソースの消費を見つけ、それらをCSVに保存します。
import wandb
run = wandb. Api(). run("<entity>/<project>/<run_id>" )
system_metrics = run. history(stream= "events" )
system_metrics. to_csv("sys_metrics.csv" )
サンプリングされていないメトリクスデータを取得する
history からデータを取得するとき、デフォルトでは500ポイントにサンプリングされます。run.scan_history()を使用すると全てのログデータポイントが取得できます。以下は、historyでログされたすべての loss データポイントをダウンロードする例です。
import wandb
api = wandb. Api()
run = api. run("<entity>/<project>/<run_id>" )
history = run. scan_history()
losses = [row["loss" ] for row in history]
history からページ分割されたデータを取得する
メトリクスがバックエンドでゆっくりと取得されている場合やAPIリクエストがタイムアウトしている場合、scan_history でページサイズを下げて、個々のリクエストがタイムアウトしないようにすることができます。デフォルトのページサイズは500なので、どのサイズが最適か試してみてください。
import wandb
api = wandb. Api()
run = api. run("<entity>/<project>/<run_id>" )
run. scan_history(keys= sorted(cols), page_size= 100 )
プロジェクト内のすべてのrun からメトリクスをCSVファイルにエクスポートする
このスクリプトは、プロジェクト内のrunを取得し、その名前、設定、およびサマリーステータスを含むデータフレームとCSVを生成します。 <entity> と <project> をそれぞれあなたのW&Bエンティティとプロジェクト名に置き換えます。
import pandas as pd
import wandb
api = wandb. Api()
entity, project = "<entity>" , "<project>"
runs = api. runs(entity + "/" + project)
summary_list, config_list, name_list = [], [], []
for run in runs:
# .summary には、精度のようなメトリクスの出力キー/値が含まれています。
# ._json_dict を呼び出して大きなファイルを省略します
summary_list. append(run. summary. _json_dict)
# .config にはハイパーパラメーターが含まれています。
# _ で始まる特別な値は削除します。
config_list. append({k: v for k, v in run. config. items() if not k. startswith("_" )})
# .name は、run の人間が読み取り可能な名前です。
name_list. append(run. name)
runs_df = pd. DataFrame(
{"summary" : summary_list, "config" : config_list, "name" : name_list}
)
runs_df. to_csv("project.csv" )
run の開始時間を取得する
このコードスニペットは、run が作成された時間を取得します。
import wandb
api = wandb. Api()
run = api. run("entity/project/run_id" )
start_time = run. created_at
完了した run にファイルをアップロードする
以下のコードスニペットは、選択したファイルを完了したrunにアップロードします。
import wandb
api = wandb. Api()
run = api. run("entity/project/run_id" )
run. upload_file("file_name.extension" )
run からファイルをダウンロードする
これは、cifar プロジェクトの run ID uxte44z7 に関連付けられたファイル “model-best.h5” を見つけ、ローカルに保存します。
import wandb
api = wandb. Api()
run = api. run("<entity>/<project>/<run_id>" )
run. file("model-best.h5" ). download()
run からすべてのファイルをダウンロードする
これはrunに関連付けられたすべてのファイルを見つけ、ローカルに保存します。
import wandb
api = wandb. Api()
run = api. run("<entity>/<project>/<run_id>" )
for file in run. files():
file. download()
特定のスイープから run を取得する
このスニペットは特定のスイープに関連するすべてのrunをダウンロードします。
import wandb
api = wandb. Api()
sweep = api. sweep("<entity>/<project>/<sweep_id>" )
sweep_runs = sweep. runs
スイープから最高の run を取得する
次のスニペットは、与えられたスイープから最高のrun を取得します。
import wandb
api = wandb. Api()
sweep = api. sweep("<entity>/<project>/<sweep_id>" )
best_run = sweep. best_run()
best_run は、スイープの設定の metric パラメータで定義されたメトリクスが最高のrunです。
スイープから最高のモデルファイルをダウンロードする
このスニペットは、runでmodel.h5にモデルファイルを保存したスイープから、最高の検証精度を持つモデルファイルをダウンロードします。
import wandb
api = wandb. Api()
sweep = api. sweep("<entity>/<project>/<sweep_id>" )
runs = sorted(sweep. runs, key= lambda run: run. summary. get("val_acc" , 0 ), reverse= True )
val_acc = runs[0 ]. summary. get("val_acc" , 0 )
print(f "Best run { runs[0 ]. name} with { val_acc} % val accuracy" )
runs[0 ]. file("model.h5" ). download(replace= True )
print("Best model saved to model-best.h5" )
run から特定の拡張子のすべてのファイルを削除する
このスニペットは、runの特定の拡張子を持つファイルを削除します。
import wandb
api = wandb. Api()
run = api. run("<entity>/<project>/<run_id>" )
extension = ".png"
files = run. files()
for file in files:
if file. name. endswith(extension):
file. delete()
システムメトリクスデータをダウンロードする
このスニペットは、run のすべてのシステムリソース消費メトリクスのデータフレームを生成し、CSVに保存します。
import wandb
api = wandb. Api()
run = api. run("<entity>/<project>/<run_id>" )
system_metrics = run. history(stream= "events" )
system_metrics. to_csv("sys_metrics.csv" )
サマリーメトリクスを更新する
サマリーメトリクスを更新する辞書を渡すことができます。
summary. update({"key" : val})
run を実行したコマンドを取得する
各runは、runの概要ページでそれを開始したコマンドをキャプチャします。このコマンドを API から取得するには次のように実行できます。
import wandb
api = wandb. Api()
run = api. run("<entity>/<project>/<run_id>" )
meta = json. load(run. file("wandb-metadata.json" ). download())
program = ["python" ] + [meta["program" ]] + meta["args" ]
2.1.11 - 環境変数
W&B 環境変数を設定します。
スクリプトを自動化された環境で実行するとき、スクリプトの実行前またはスクリプト内で設定された環境変数を使って wandb を制御できます。
# これは秘密であり、バージョン管理にチェックインするべきではありません
WANDB_API_KEY= $YOUR_API_KEY
# 名前とメモはオプションです
WANDB_NAME= "My first run"
WANDB_NOTES= "Smaller learning rate, more regularization."
# wandb/settingsファイルをチェックインしない場合にのみ必要です
WANDB_ENTITY= $username
WANDB_PROJECT= $project
# スクリプトをクラウドに同期したくなければ
os. environ["WANDB_MODE" ] = "offline"
# Sweep IDの追跡をRunオブジェクトと関連クラスに追加
os. environ["WANDB_SWEEP_ID" ] = "b05fq58z"
オプションの環境変数
これらのオプションの環境変数を使用して、リモートマシンでの認証をセットアップすることができます。
変数名
使用法
WANDB_ANONYMOUS allow, never, または must に設定して、ユーザーが秘密のURLで匿名のrunsを作成できるようにします。
WANDB_API_KEY あなたのアカウントに関連付けられた認証キーを設定します。キーは設定ページ で確認できます。このキーは、リモートマシンで wandb login が実行されていない場合に設定する必要があります。
WANDB_BASE_URL wandb/local を使用している場合、この環境変数を http://YOUR_IP:YOUR_PORT に設定してください。
WANDB_CACHE_DIR これはデフォルトで ~/.cache/wandb に設定されています。この環境変数を使用してこの場所を上書きすることができます。
WANDB_CONFIG_DIR これはデフォルトで ~/.config/wandb に設定されています。この環境変数を使用してこの場所を上書きすることができます。
WANDB_CONFIG_PATHS カンマで区切られたyamlファイルのリストをwandb.configにロードします。config を参照してください。
WANDB_CONSOLE stdout / stderr ロギングを無効にする場合はこれを “off” に設定します。これが機能する環境では、デフォルトで “on” に設定されています。
WANDB_DATA_DIR ステージングアーティファクトがアップロードされる場所。デフォルトの場所はプラットフォームに依存し、platformdirs Pythonパッケージからの user_data_dir の値を使用します。
WANDB_DIR すべての生成されたファイルを wandb ディレクトリーではなくここに保存するために絶対パスを設定します。このディレクトリーが存在しており、プロセスが実行されるユーザーが書き込めることを確認してください 。この設定は、ダウンロードされたアーティファクトの場所には影響しません、それらの場所を設定するには代わりに WANDB_ARTIFACT_DIR を使用してください。
WANDB_ARTIFACT_DIR すべてのダウンロードされたアーティファクトを artifacts ディレクトリーではなくここに保存するために絶対パスを設定します。このディレクトリーが存在しており、プロセスが実行されるユーザーが書き込めることを確認してください。この設定は、生成されたメタデータファイルの場所には影響しません、それらの場所を設定するには代わりに WANDB_DIR を使用してください。
WANDB_DISABLE_GIT gitリポジトリをプローブし、最新のコミット / 差分をキャプチャするのを防ぎます。
WANDB_DISABLE_CODE ノートブックやgit差分の保存を防ぐためにtrueに設定します。gitリポジトリ内にいる場合、依然として現在のコミットを保存します。
WANDB_DOCKER dockerイメージのダイジェストを設定してrunsの復元を有効にします。これはwandb dockerコマンドで自動的に設定されます。イメージダイジェストを取得するには wandb docker my/image/name:tag --digest を実行します。
WANDB_ENTITY あなたのrunに関連付けられたentityです。トレーニングスクリプトのディレクトリーで wandb init を実行した場合、wandb という名前のディレクトリーが作成され、デフォルトのentityが保存され、ソース管理にチェックインされます。このファイルを作成したくない場合やファイルを上書きしたい場合、環境変数を使用できます。
WANDB_ERROR_REPORTING wandbが致命的なエラーをエラートラッキングシステムにログするのを防ぎたい場合はfalseに設定します。
WANDB_HOST システムが提供するホスト名を使用せずにwandbインターフェースで表示したいホスト名を設定します。
WANDB_IGNORE_GLOBS 無視するファイルのグロブのカンマ区切りリストを設定します。これらのファイルはクラウドに同期されません。
WANDB_JOB_NAME wandb が作成するジョブに対する名前を指定します。
WANDB_JOB_TYPE ジョブタイプを指定します。「トレーニング」や「評価」など、異なるタイプのrunsを示します。詳細についてはgrouping を参照してください。
WANDB_MODE “offline” に設定すると、wandbはrunメタデータをローカルに保存し、サーバーに同期しなくなります。disabled に設定すると、wandbは完全にオフになります。
WANDB_NAME あなたのrunの人間が読める名前。設定されていない場合、ランダムに生成されます。
WANDB_NOTEBOOK_NAME jupyterで実行されている場合、この変数でノートブックの名前を設定できます。これを自動検出しようとします。
WANDB_NOTES あなたのrunに関する長いメモ。Markdownが許可されており、UIで後で編集できます。
WANDB_PROJECT あなたのrunに関連付けられたプロジェクトです。これも wandb init で設定できますが、環境変数は値を上書きします。
WANDB_RESUME デフォルトでは never に設定されています。auto に設定すると、wandbは自動的に失敗したrunsを再開します。must に設定すると、開始時に必ずrunが存在するように強制します。常に独自のユニークなIDを生成したい場合、allow に設定して常に WANDB_RUN_ID を設定してください。
WANDB_RUN_GROUP 自動的にrunsをまとめるためのexperiment nameを指定します。詳細についてはgrouping を参照してください。
WANDB_RUN_ID スクリプトの単一runに対応する、グローバルにユニークな文字列（プロジェクトごとに）を設定します。64文字以内でなければなりません。すべての非単語文字はダッシュに変換されます。失敗時の既存のrunを再開するために使用できます。
WANDB_SILENT wandbログステートメントを黙らせるために true に設定します。これを設定すると、すべてのログが WANDB_DIR /debug.log に書き込まれます。
WANDB_SHOW_RUN あなたのオペレーティングシステムがサポートしていれば、runのURLを自動的にブラウザで開くために true に設定します。
WANDB_SWEEP_ID Run オブジェクトおよび関連クラスにSweep IDの追跡を追加し、UIに表示します。
WANDB_TAGS runに適用されるタグのカンマ区切りリスト。
WANDB_USERNAME runに関連付けられたあなたのチームメンバーのユーザー名。これは、サービスアカウントAPIキーと共に使用して、自動化されたrunsをあなたのチームのメンバーに帰属させることができます。
WANDB_USER_EMAIL runに関連付けられたあなたのチームメンバーのメール。これはサービスアカウントAPIキーと共に使用して、自動化されたrunsをあなたのチームのメンバーに帰属させることができます。
Singularity 環境
Singularity でコンテナを実行している場合、上記の変数に SINGULARITYENV_ をプレフィックスとしてつけて環境変数を渡すことができます。Singularity環境変数に関する詳細はこちら で確認できます。
AWSでの実行
AWSでバッチジョブを実行している場合、W&Bのクレデンシャルでマシンを認証するのは簡単です。設定ページ からAPIキーを取得し、AWSバッチジョブ仕様 で WANDB_API_KEY 環境変数を設定します。
2.2 - テーブル
データセットを繰り返し、モデルの予測を理解する
W&B Tables を使用して、表形式のデータを視覚化し、クエリを実行します。 例:
同じテストセットで異なるモデルがどのように機能するかを比較する
データのパターンを特定する
サンプルモデルの予測を視覚的に確認する
よく誤分類される例を見つけるためにクエリを実行する
W&B ML Course のサンプルプロジェクト で見ることができます。
仕組み
Table は、各列が単一のデータ型を持つデータの 2 次元グリッドです。Tables はプリミティブ型と数値型、さらに入れ子リスト、辞書、およびリッチメディア型をサポートします。
Table をログする
数行のコードでテーブルをログします:
import wandb
run = wandb. init(project= "table-test" )
my_table = wandb. Table(columns= ["a" , "b" ], data= [["a1" , "b1" ], ["a2" , "b2" ]])
run. log({"Table Name" : my_table})
開始方法
2.2.1 - チュートリアル: テーブルをログして、データを視覚化し、クエリする方法
W&B Tables を 5 分で始めるクイックスタートで使い方を確認しましょう。
The following クイックスタート では、データ テーブルをログし、データを視覚化し、データをクエリする方法を示します。
以下のボタンを選択して、PyTorch クイックスタートの MNIST データの例のプロジェクト を試してください。
1. テーブルをログする
W&B を使用してテーブルをログします。新しいテーブルを作成するか、Pandas の Dataframe を渡すことができます。
テーブルを作成する
Pandas Dataframe
新しい Table を作成してログするには、次を使用します:
例はこちらです:
import wandb
run = wandb. init(project= "table-test" )
# 新しいテーブルを作成してログします。
my_table = wandb. Table(columns= ["a" , "b" ], data= [["a1" , "b1" ], ["a2" , "b2" ]])
run. log({"Table Name" : my_table})
Pandas Dataframe を wandb.Table() に渡して、新しいテーブルを作成します。
import wandb
import pandas as pd
df = pd. read_csv("my_data.csv" )
run = wandb. init(project= "df-table" )
my_table = wandb. Table(dataframe= df)
wandb. log({"Table Name" : my_table})
サポートされているデータ型の詳細については、W&B API リファレンス ガイドの wandb.Table
2. プロジェクトワークスペースでテーブルを視覚化する
ワークスペースで結果のテーブルを表示します。
W&B アプリでプロジェクトに移動します。
プロジェクト ワークスペースで run の名前を選択します。それぞれのユニークなテーブル キーに対して新しいパネルが追加されます。
この例では、my_table がキー "Table Name" の下にログされています。
3. モデル バージョン を比較する
複数の W&B Runs のサンプル テーブルをログし、プロジェクト ワークスペースで結果を比較します。この 例のワークスペース では、複数の異なるバージョンから同じテーブルに行を結合する方法を示しています。
モデルの結果を探索し評価するためにテーブルのフィルタ、ソート、グループ化の機能を使用してください。
2.2.2 - テーブルを視覚化して分析する
W&B テーブルを視覚化して分析する。
W&B Tables をカスタマイズして、機械学習モデルの性能に関する質問に答え、データを分析するなどの操作を行いましょう。
データを対話的に探索して、以下のことができます。
モデル、エポック、または個々の例を精密に比較
データ内の高次のパターンを理解
ビジュアルサンプルで洞察をキャプチャして伝える
W&B Tables には以下の振る舞いがあります:
アーティファクトコンテキストでのステートレス性 : アーティファクトバージョンと共にログされたテーブルは、ブラウザウィンドウを閉じるとデフォルト状態にリセットされます。ワークスペースまたはレポートコンテキストでのステートフル性 : シングルrunのワークスペース、マルチrunプロジェクトワークスペース、またはレポート内でテーブルに加えた変更は永続化されます。
現在の W&B Table ビューを保存する方法については、ビューを保存する を参照してください。
2つのテーブルを表示する方法
マージされたビュー または並列ビュー で2つのテーブルを比較します。以下の画像は、MNISTデータのテーブル比較を示しています。
2つのテーブルを比較する手順:
W&B Appでプロジェクトに移動します。
左のパネルでアーティファクトのアイコンを選択します。
アーティファクトバージョンを選択します。
以下の画像では、5 エポック後の各MNIST検証データにおけるモデルの予測を示しています（対話型の例はこちら を参照）。
サイドバー内で比較したい2つ目のアーティファクトバージョンにカーソルを合わせ、表示されたらCompare をクリックします。例えば、以下の画像では、同じモデルによる5 エポック後のMNIST予測と比較するために「v4」とラベル付けされたバージョンを選択しています。
マージされたビュー
最初は、両方のテーブルが一緒にマージされた状態が表示されます。選択した最初のテーブルはインデックス0で青色のハイライトがあり、2つ目のテーブルはインデックス1で黄色のハイライトがあります。ここでマージされたテーブルのライブ例を表示 することができます。
マージされたビューから、以下の操作を行うことができます。
結合キーを選択 : 左上のドロップダウンを使って、2つのテーブルに対する結合キーとして使用する列を設定します。通常、これは各行の一意の識別子であり、データセット内の特定の例のファイル名や生成されたサンプルのインクリメントインデックスなどです。任意の 列を選択することもできますが、これにより判読不可能なテーブルや遅いクエリが発生する可能性があります。結合の代わりに連結 : このドロップダウンで「すべてのテーブルを連結する」を選択して、両方のテーブルのすべての行を1つの大きなテーブルに_結合して_ 列を横断するようにします。各テーブルを明示的に参照 : フィルター式で0、1、*を使用して、1つまたは両方のテーブルインスタンスの列を明示的に指定します。ヒストグラムとして詳細な数値差分を可視化 : 任意のセルの値を一目で比較します。
並列ビュー
2つのテーブルを並べて表示するには、最初のドロップダウンを「Merge Tables: Table」から「List of: Table」に変更し、「Page size」をそれに応じて更新します。ここで選択された最初のテーブルは左側にあり、2つ目のテーブルは右側にあります。さらに、「Vertical」チェックボックスをクリックして、これらのテーブルを縦に比較することもできます。
テーブルを一目で比較 : 両方のテーブルに一緒に操作（並べ替え、フィルター、グループ化）を適用し、すばやく変更や違いを特定できます。たとえば、誤った予測を予測値ごとにグループ化したり、最も難しいネガティブを、真のラベルごとの信頼度スコア分布などを表示できます。2つのテーブルを独立して探索 : 関心のあるサイド/行をスクロールしてフォーカスします。
アーティファクトを比較
テーブルを時間で比較 したり、モデルバリアントを比較 することもできます。
テーブルを時間で比較
各トレーニングの意味のあるステップに対してアーティファクトにテーブルを記録し、トレーニング時間を通じてモデルの性能を分析します。たとえば、各検証ステップの終了時、毎50エポックのトレーニング後、またはパイプラインに意味を持つ任意の頻度でテーブルを記録できます。モデル予測の変更を可視化するために、並列ビューを使用します。
トレーニング時間を通じて予測を可視化するより詳細なウォークスルーについては、このレポート およびこの対話型ノートブックの例 を参照してください。
モデルバリアントを超えてテーブルを比較
2つの異なるモデルで同じステップでログされた2つのアーティファクトバージョンを比較して、異なる設定（ハイパーパラメーター、基本アーキテクチャーなど）全体でのモデル性能を分析します。
たとえば、baselineと新しいモデルバリアント2x_layers_2x_lrの予測を比較します。この場合、最初の畳み込み層が32から64に、2番目が128から256に、学習率が0.001から0.002に倍増します。このライブ例 から、並列ビューを使用して、1エポック後（左タブ）と5エポック後（右タブ）の誤った予測にフィルターをかけます。
1 トレーニングエポック
5 トレーニングエポック
ビューを保存
runワークスペース、プロジェクトワークスペース、またはレポート内で操作したテーブルは、ビュー状態を自動的に保存します。テーブル操作を適用し、その後ブラウザを閉じても、次にテーブルに戻ったときに最後に表示された設定が保持されます。
アーティファクトコンテキストで操作したテーブルはステートレスのままです。
特定の状態でワークスペースからテーブルを保存するには、W&B Report にエクスポートします。レポートにテーブルをエクスポートするには:
ワークスペースの可視化パネルの右上隅にあるケバブアイコン（縦に並んだ3つの点）を選択します。
Share panel または Add to report を選択します。
例
これらのレポートは、W&B Tables のさまざまなユースケースを強調しています:
2.2.3 - テーブル データをエクスポート
テーブルからデータをエクスポートする方法。
すべての W&B Artifacts 同様に、Tables は pandas データフレームに変換して、データのエクスポートを簡単に行うことができます。
table を artifact に変換するまず、テーブルをアーティファクトに変換する必要があります。これを行う最も簡単な方法は artifact.get(table, "table_name") を使用することです：
# 新しいテーブルを作成してログします。
with wandb. init() as r:
artifact = wandb. Artifact("my_dataset" , type= "dataset" )
table = wandb. Table(
columns= ["a" , "b" , "c" ], data= [(i, i * 2 , 2 ** i) for i in range(10 )]
)
artifact. add(table, "my_table" )
wandb. log_artifact(artifact)
# 作成したアーティファクトを使用してテーブルを取得します。
with wandb. init() as r:
artifact = r. use_artifact("my_dataset:latest" )
table = artifact. get("my_table" )
artifact をデータフレームに変換する次に、テーブルをデータフレームに変換します：
# 前のコード例から続けて：
df = table. get_dataframe()
データをエクスポート
現在、データフレームがサポートする任意のメソッドを使用してエクスポートできます：
# テーブルデータを .csv に変換
df. to_csv("example.csv" , encoding= "utf-8" )
次のステップ
2.2.4 - 例 テーブル
W&B テーブル の例
以下のセクションでは、テーブルの使用方法の一部を紹介します。
データを表示する
モデルのトレーニングまたは評価中にメトリクスやリッチメディアをログに記録し、それをクラウドに同期された永続的なデータベース、またはホスティングインスタンス で結果を視覚化します。
たとえば、このテーブルをご覧ください。写真データセットのバランスの取れた分割 を示しています。
データを対話的に探索する
テーブルを表示、ソート、フィルタ、グループ化、結合、クエリして、データとモデルのパフォーマンスを理解します。静的ファイルを閲覧したり、分析スクリプトを再実行する必要はありません。
たとえば、このレポートをご覧ください。スタイルが転送されたオーディオ について。
モデルバージョンを比較する
異なるトレーニングエポック、データセット、ハイパーパラメーターの選択、モデルアーキテクチャーなど、さまざまな結果を迅速に比較します。
たとえば、このテーブルを確認してください。同じテスト画像で2つのモデルを比較 しています。
すべての詳細を追跡し、大局を把握する
特定のステップでの特定の予測を視覚化するためにズームインします。ズームアウトして集計統計を確認し、エラーのパターンを識別し、改善の機会を理解します。このツールは、単一のモデルトレーニングからのステップを比較したり、異なるモデルバージョンの結果を比較するために使用されます。
たとえば、1回とその後5回のエポック後のMNISTデータセットでの結果を分析 する例のテーブルをご覧ください。
W&B Tablesを使用したプロジェクトの例
以下では、W&B Tablesを使用した実際のW&Bプロジェクトの例を紹介します。
画像分類
このレポート を読み、このcolab に従うか、このアーティファクトコンテキスト を探り、CNNがiNaturalist の写真から10種類の生物（植物、鳥、昆虫など）を識別する方法を見てみてください。
オーディオ
ティンバー転送に関するこのレポート でオーディオテーブルと対話します。録音されたクジラの歌と同じメロディをバイオリンやトランペットのような楽器で合成したバージョンを比較できます。このcolab で自分の曲を録音し、その合成バージョンをW&Bで探索することもできます。
テキスト
トレーニングデータや生成された出力からテキストサンプルを閲覧し、関連するフィールドで動的にグループ化し、モデルバリエーションや実験設定に合わせて評価を整えます。Markdownとしてテキストをレンダリングするか、ビジュアル差分モードを使用してテキストを比較します。このレポート でシェイクスピアを生成するためのシンプルな文字ベースのRNNを探ります。
ビデオ
モデルを理解するためにトレーニング中にログに記録されたビデオを閲覧および集約します。ここに、RLエージェントが副作用を最小化 しようとするためのSafeLife ベンチマーク を使用した初期の例があります。
表形式データ
バージョン管理とデータの重複排除を使用して表形式データを分割および前処理する 方法に関するレポートを参照してください。
モデルバリエーションの比較（セマンティックセグメンテーション）
セマンティックセグメンテーションのためのTablesをログに記録し、さまざまなモデルを比較する対話型ノートブック とライブ例 です。このTable で自分のクエリを試してみてください。
トレーニング時間の改善を分析する
予測を時間にわたって視覚化する方法についての詳細なレポート と、付随する対話型ノートブック です。
2.3 - スイープ
W&B スイープによるハイパーパラメーター探索とモデル最適化
W&B Sweeps を使用してハイパーパラメータ検索を自動化し、豊富でインタラクティブな実験管理を視覚化します。ベイズ、グリッド検索、ランダムなどの一般的な検索メソッドから選択して、ハイパーパラメータ空間を探索できます。スイープを 1 台以上のマシンにわたってスケールし、並列化します。
仕組み
2 つの W&B CLI コマンドで sweep を作成します:
スイープを初期化する
wandb sweep --project <propject-name> <path-to-config file>
スイープエージェントを開始する
上記のコードスニペットとこのページにリンクされている colab は、W&B CLI でスイープを初期化し作成する方法を示しています。W&B Python SDK コマンドを使用してスイープ設定を定義し、スイープを初期化・開始する手順については Sweeps の
ウォークスルー をご覧ください。
開始方法
ユースケースに応じて、W&B Sweeps の開始に役立つ次のリソースを探索してください:
スイープ設定を定義し、スイープを初期化・開始するための W&B Python SDK コマンドの手順については、スイープのウォークスルー をお読みください。
次のチャプターを探索して以下を学びます:
W&B Sweeps を使用したハイパーパラメータ最適化を探索する スイープ実験の厳選リスト を探索します。結果は W&B Reports に保存されます。
ステップバイステップのビデオについては、こちらをご覧ください: Tune Hyperparameters Easily with W&B Sweeps .
2.3.1 - チュートリアル: Sweep を定義、初期化、実行する
スイープ クイックスタートでは、スイープを定義、初期化、実行する方法を示します。主な手順は4つあります。
このページでは、スイープを定義、初期化、および実行する方法を示します。主に4つのステップがあります。
トレーニングコードをセットアップする スイープ設定で探索空間を定義する スイープを初期化する スイープエージェントを開始する
以下のコードを Jupyter ノートブックまたは Python スクリプトにコピーして貼り付けてください。
# W&B Python ライブラリをインポートして W&B にログインする
import wandb
wandb. login()
# 1: 目的/トレーニング関数を定義する
def objective (config):
score = config. x** 3 + config. y
return score
def main ():
wandb. init(project= "my-first-sweep" )
score = objective(wandb. config)
wandb. log({"score" : score})
# 2: 探索空間を定義する
sweep_configuration = {
"method" : "random" ,
"metric" : {"goal" : "minimize" , "name" : "score" },
"parameters" : {
"x" : {"max" : 0.1 , "min" : 0.01 },
"y" : {"values" : [1 , 3 , 7 ]},
},
}
# 3: スイープを開始する
sweep_id = wandb. sweep(sweep= sweep_configuration, project= "my-first-sweep" )
wandb. agent(sweep_id, function= main, count= 10 )
以下のセクションでは、そのコードサンプルの各ステップを分解し、説明します。
トレーニングコードをセットアップする
wandb.config からハイパーパラメーターの値を取り込み、それを使用してモデルをトレーニングし、メトリクスを返すトレーニング関数を定義します。
オプションとして、W&B Run の出力を保存したいプロジェクトの名前（wandb.init
スイープとrunは同じプロジェクト内にある必要があります。したがって、W&Bを初期化するときに指定する名前は、スイープを初期化するときに指定するプロジェクトの名前と一致する必要があります。
# 1: 目的/トレーニング関数を定義する
def objective (config):
score = config. x** 3 + config. y
return score
def main ():
wandb. init(project= "my-first-sweep" )
score = objective(wandb. config)
wandb. log({"score" : score})
スイープ設定で探索空間を定義する
探索するハイパーパラメーターを辞書で指定します。設定オプションについては、スイープ設定を定義する を参照してください。
次の例では、ランダム検索（'method':'random'）を使用するスイープ設定を示しています。スイープは、バッチサイズ、エポック、および学習率の設定にリストされているランダムな値を無作為に選択します。
W&Bは、"goal": "minimize"が関連付けられているときに metric キーで指定されたメトリクスを最小化します。この場合、W&Bはメトリクス score（"name": "score"）を最小化するように最適化します。
# 2: 探索空間を定義する
sweep_configuration = {
"method" : "random" ,
"metric" : {"goal" : "minimize" , "name" : "score" },
"parameters" : {
"x" : {"max" : 0.1 , "min" : 0.01 },
"y" : {"values" : [1 , 3 , 7 ]},
},
}
スイープを初期化する
W&Bは、クラウド（標準）またはローカル（ローカル）で複数のマシンを横断してスイープを管理するために、Sweep Controller を使用します。Sweep Controller についての詳細は、ローカルで探索と停止のアルゴリズムを確認する を参照してください。
スイープを初期化すると、スイープ識別番号が返されます。
sweep_id = wandb. sweep(sweep= sweep_configuration, project= "my-first-sweep" )
スイープの初期化に関する詳細は、スイープを初期化する を参照してください。
スイープを開始する
スイープを開始するには、wandb.agent
wandb. agent(sweep_id, function= main, count= 10 )
結果を視覚化する（オプション）
プロジェクトを開くと、W&Bアプリダッシュボードでライブ結果を確認できます。数回のクリックで豊富なインタラクティブグラフを構築します。例えば、並列座標プロット 、パラメータの重要度解析 、およびその他 です。
結果の視覚化方法に関する詳細は、スイープ結果を視覚化する を参照してください。サンプルのダッシュボードについては、このスイーププロジェクト を参照してください。
エージェントを停止する（オプション）
ターミナルで Ctrl+C を押して、現在のランを停止します。もう一度押すと、エージェントが終了します。
2.3.2 - コードに W&B (wandb) を追加する
Python コード スクリプトまたは Jupyter Notebook に W&B を追加します。
W&B Python SDKをスクリプトやJupyterノートブックに追加する方法は数多くあります。以下は、W&B Python SDKを独自のコードに統合するための「ベストプラクティス」の例です。
オリジナルトレーニングスクリプト
次のPythonスクリプトのコードを持っているとしましょう。main という関数を定義し、典型的なトレーニングループを模倣します。各エポックごとに、トレーニングおよび検証データセットに対して精度と損失が計算されます。この例の目的のために値はランダムに生成されます。
ハイパーパラメーター値を格納するための辞書 config を定義しました。セルの最後に、モックトレーニングコードを実行するために main 関数を呼び出します。
import random
import numpy as np
def train_one_epoch (epoch, lr, bs):
acc = 0.25 + ((epoch / 30 ) + (random. random() / 10 ))
loss = 0.2 + (1 - ((epoch - 1 ) / 10 + random. random() / 5 ))
return acc, loss
def evaluate_one_epoch (epoch):
acc = 0.1 + ((epoch / 20 ) + (random. random() / 10 ))
loss = 0.25 + (1 - ((epoch - 1 ) / 10 + random. random() / 6 ))
return acc, loss
# ハイパーパラメーター値を含む設定変数
config = {"lr" : 0.0001 , "bs" : 16 , "epochs" : 5 }
def main ():
# 固定値を定義する代わりに `wandb.config` から値を定義していることに注意
lr = config["lr" ]
bs = config["bs" ]
epochs = config["epochs" ]
for epoch in np. arange(1 , epochs):
train_acc, train_loss = train_one_epoch(epoch, lr, bs)
val_acc, val_loss = evaluate_one_epoch(epoch)
print("epoch: " , epoch)
print("training accuracy:" , train_acc, "training loss:" , train_loss)
print("validation accuracy:" , val_acc, "training loss:" , val_loss)
W&B Python SDKを用いたトレーニングスクリプト
以下のコード例は、W&B Python SDKをコードに追加する方法を示しています。CLIでW&B Sweepジョブを開始する場合、CLIタブを探索したいでしょう。JupyterノートブックやPythonスクリプト内でW&B Sweepジョブを開始する場合、Python SDKタブを探索してください。
Python スクリプトまたはノートブック
CLI
W&B Sweepを作成するために、コード例に以下を追加しました:
Weights & Biases Python SDKをインポートします。
キーと値のペアがスイープ設定を定義する辞書オブジェクトを作成します。次の例では、バッチサイズ (batch_size), エポック (epochs), および学習率 (lr) のハイパーパラメーターが各スイープで変化します。スイープ設定の作成方法についての詳細は、Define sweep configuration を参照してください。
スイープ設定辞書をwandb.sweepsweep_id) が返されます。スイープの初期化方法についての詳細は、Initialize sweeps を参照してください。
wandb.init()W&B Run として実行します。(オプション) 固定値を定義する代わりに wandb.config から値を定義します。
wandb.log を使用して最適化したいメトリクスをログします。設定で定義されたメトリクスを必ずログしてください。この例では、設定辞書 (sweep_configuration) で val_acc を最大化するスイープを定義しました。wandb.agentfunction=main)、および試行する最大run数を4に設定します (count=4)。W&B Sweepの開始方法についての詳細は、Start sweep agents を参照してください。
import wandb
import numpy as np
import random
# スイープ設定を定義
sweep_configuration = {
"method" : "random" ,
"name" : "sweep" ,
"metric" : {"goal" : "maximize" , "name" : "val_acc" },
"parameters" : {
"batch_size" : {"values" : [16 , 32 , 64 ]},
"epochs" : {"values" : [5 , 10 , 15 ]},
"lr" : {"max" : 0.1 , "min" : 0.0001 },
},
}
# 設定を渡してスイープを初期化します。
# (オプション) プロジェクト名を指定
sweep_id = wandb. sweep(sweep= sweep_configuration, project= "my-first-sweep" )
# `wandb.config` からハイパーパラメーターを受け取り、
# モデルをトレーニングしてメトリクスを返すトレーニング関数を定義
def train_one_epoch (epoch, lr, bs):
acc = 0.25 + ((epoch / 30 ) + (random. random() / 10 ))
loss = 0.2 + (1 - ((epoch - 1 ) / 10 + random. random() / 5 ))
return acc, loss
def evaluate_one_epoch (epoch):
acc = 0.1 + ((epoch / 20 ) + (random. random() / 10 ))
loss = 0.25 + (1 - ((epoch - 1 ) / 10 + random. random() / 6 ))
return acc, loss
def main ():
run = wandb. init()
# 固定値を定義する代わりに `wandb.config`
# から値を定義していることに注意
lr = wandb. config. lr
bs = wandb. config. batch_size
epochs = wandb. config. epochs
for epoch in np. arange(1 , epochs):
train_acc, train_loss = train_one_epoch(epoch, lr, bs)
val_acc, val_loss = evaluate_one_epoch(epoch)
wandb. log(
{
"epoch" : epoch,
"train_acc" : train_acc,
"train_loss" : train_loss,
"val_acc" : val_acc,
"val_loss" : val_loss,
}
)
# スイープジョブを開始
wandb. agent(sweep_id, function= main, count= 4 )
W&B Sweepを作成するために、最初にYAML設定ファイルを作成します。設定ファイルにはスイープが探索するハイパーパラメーターを含んでいます。次の例では、バッチサイズ (batch_size), エポック (epochs), および学習率 (lr) のハイパーパラメーターが各スイープで変化します。
# config.yaml
program : train.py
method : random
name : sweep
metric :
goal : maximize
name : val_acc
parameters :
batch_size :
values : [16 ,32 ,64 ]
lr :
min : 0.0001
max : 0.1
epochs :
values : [5 , 10 , 15 ]
W&B Sweep設定の作成方法についての詳細は、Define sweep configuration を参照してください。
YAMLファイルで program のキーにPythonスクリプトの名前を必ず指定してください。
次に、コード例に以下を追加します:
Weights & Biases Python SDK (wandb) と PyYAML (yaml) をインポートします。PyYAMLはYAML設定ファイルを読み込むために使用します。
設定ファイルを読み込みます。
wandb.init()W&B Run として実行します。configパラメーターに設定オブジェクトを渡します。固定値を使用する代わりに wandb.config からハイパーパラメーター値を定義します。
wandb.log を使用して最適化したいメトリクスをログします。設定で定義されたメトリクスを必ずログしてください。この例では、設定辞書 (sweep_configuration) で val_acc を最大化するスイープを定義しました。
import wandb
import yaml
import random
import numpy as np
def train_one_epoch (epoch, lr, bs):
acc = 0.25 + ((epoch / 30 ) + (random. random() / 10 ))
loss = 0.2 + (1 - ((epoch - 1 ) / 10 + random. random() / 5 ))
return acc, loss
def evaluate_one_epoch (epoch):
acc = 0.1 + ((epoch / 20 ) + (random. random() / 10 ))
loss = 0.25 + (1 - ((epoch - 1 ) / 10 + random. random() / 6 ))
return acc, loss
def main ():
# 標準のハイパーパラメーターをセットアップします
with open("./config.yaml" ) as file:
config = yaml. load(file, Loader= yaml. FullLoader)
run = wandb. init(config= config)
# 固定値を定義する代わりに `wandb.config`
# から値を定義していることに注意
lr = wandb. config. lr
bs = wandb. config. batch_size
epochs = wandb. config. epochs
for epoch in np. arange(1 , epochs):
train_acc, train_loss = train_one_epoch(epoch, lr, bs)
val_acc, val_loss = evaluate_one_epoch(epoch)
wandb. log(
{
"epoch" : epoch,
"train_acc" : train_acc,
"train_loss" : train_loss,
"val_acc" : val_acc,
"val_loss" : val_loss,
}
)
# メイン関数を呼び出します。
main()
CLIに移動します。CLI内で、スイープエージェントが試行する最大run数を設定します。これは任意のステップです。次の例では最大回数を5に設定しています。
次に、wandb sweep--project）のためにプロジェクト名を指定することもできます:
wandb sweep --project sweep-demo-cli config.yaml
これによりスイープIDが返されます。スイープの初期化方法についての詳細は、Initialize sweeps を参照してください。
スイープIDをコピーし、次のコードスニペットの sweepID を置き換えて、wandb agent
wandb agent --count $NUM your-entity/sweep-demo-cli/sweepID
スイープジョブの開始方法についての詳細は、Start sweep jobs を参照してください。
メトリクスをログする際の考慮事項
スイープ設定で指定したメトリクスを明示的にW&Bにログすることを確認してください。スイープのメトリクスをサブディレクトリ内でログしないでください。
例えば、以下の擬似コードを考えてみてください。ユーザーが検証損失 ("val_loss": loss) をログしたいとします。まず、ユーザーは辞書に値を渡しますが、wandb.log に渡される辞書は辞書内のキーと値のペアに明示的にアクセスしていません:
# W&B Pythonライブラリをインポートし、W&Bにログイン
import wandb
import random
def train ():
offset = random. random() / 5
acc = 1 - 2 **- epoch - random. random() / epoch - offset
loss = 2 **- epoch + random. random() / epoch + offset
val_metrics = {"val_loss" : loss, "val_acc" : acc}
return val_metrics
def main ():
wandb. init(entity= "<entity>" , project= "my-first-sweep" )
val_metrics = train()
# 不正確。辞書内のキーと値のペアに明示的にアクセスする必要があります。
# 次のコードブロックでメトリクスを正しくログする方法を参照してください。
wandb. log({"val_loss" : val_metrics})
sweep_configuration = {
"method" : "random" ,
"metric" : {"goal" : "minimize" , "name" : "val_loss" },
"parameters" : {
"x" : {"max" : 0.1 , "min" : 0.01 },
"y" : {"values" : [1 , 3 , 7 ]},
},
}
sweep_id = wandb. sweep(sweep= sweep_configuration, project= "my-first-sweep" )
wandb. agent(sweep_id, function= main, count= 10 )
代わりに、Python辞書内でキーと値のペアに明示的にアクセスしてください。例えば、次のコードは wandb.log メソッドに辞書を渡す際にキーと値のペアを指定しています:
# W&B Pythonライブラリをインポートし、W&Bにログイン
import wandb
import random
def train ():
offset = random. random() / 5
acc = 1 - 2 **- epoch - random. random() / epoch - offset
loss = 2 **- epoch + random. random() / epoch + offset
val_metrics = {"val_loss" : loss, "val_acc" : acc}
return val_metrics
def main ():
wandb. init(entity= "<entity>" , project= "my-first-sweep" )
val_metrics = train()
wandb. log({"val_loss" , val_metrics["val_loss" ]})
sweep_configuration = {
"method" : "random" ,
"metric" : {"goal" : "minimize" , "name" : "val_loss" },
"parameters" : {
"x" : {"max" : 0.1 , "min" : 0.01 },
"y" : {"values" : [1 , 3 , 7 ]},
},
}
sweep_id = wandb. sweep(sweep= sweep_configuration, project= "my-first-sweep" )
wandb. agent(sweep_id, function= main, count= 10 )
2.3.3 - sweep configuration を定義する
スイープの設定ファイルを作成する方法を学びましょう。
A W&B Sweep は、ハイパーパラメータの値を探索するための戦略と、それを評価するコードを組み合わせたものです。この戦略はすべてのオプションを試すというシンプルなものから、ベイズ最適化やハイパーバンド（BOHB ）のように複雑なものまであります。
Sweep configuration を Python 辞書 または YAML ファイルで定義します。Sweep configuration をどのように定義するかは、あなたが sweep をどのように管理したいかによって異なります。
スイープを初期化し、コマンドラインからスイープエージェントを開始したい場合は、YAMLファイルでスイープ設定を定義します。スイープを初期化し、完全にPythonスクリプトまたはJupyterノートブック内でスイープを開始する場合は、Python辞書でスイープを定義します。
以下のガイドでは、sweep configuration のフォーマット方法について説明します。Sweep configuration options で、トップレベルの sweep configuration キーの包括的なリストをご覧ください。
基本構造
両方のスイープ設定フォーマットオプション (YAML および Python 辞書) は、キーと値のペアおよびネストされた構造を利用します。
スイープ設定内でトップレベルキーを使用して、sweep 検索の特性を定義します。たとえば、スイープの名前（nameparametersmethod
例えば、以下のコードスニペットは、YAML ファイルと Python 辞書の両方で定義された同じスイープ設定を示しています。スイープ設定内には、program、name、method、metric、および parameters という5つのトップレベルキーが指定されています。
CLI
Python スクリプトまたは Jupyter ノートブック
スイープをコマンドライン (CLI) からインタラクティブに管理したい場合、YAML ファイルでスイープ設定を定義します。
program : train.py
name : sweepdemo
method : bayes
metric :
goal : minimize
name : validation_loss
parameters :
learning_rate :
min : 0.0001
max : 0.1
batch_size :
values : [16 , 32 , 64 ]
epochs :
values : [5 , 10 , 15 ]
optimizer :
values : ["adam" , "sgd" ]
Python スクリプトまたは Jupyter ノートブックでトレーニングアルゴリズムを定義する場合は、Python 辞書データ構造でスイープを定義します。
以下のコードスニペットは、sweep_configuration という変数名でスイープ設定を格納します：
sweep_configuration = {
"name" : "sweepdemo" ,
"method" : "bayes" ,
"metric" : {"goal" : "minimize" , "name" : "validation_loss" },
"parameters" : {
"learning_rate" : {"min" : 0.0001 , "max" : 0.1 },
"batch_size" : {"values" : [16 , 32 , 64 ]},
"epochs" : {"values" : [5 , 10 , 15 ]},
"optimizer" : {"values" : ["adam" , "sgd" ]},
},
}
トップレベルの parameters キーの中に、以下のキーがネストされています：learning_rate、batch_size、epoch、および optimizer。指定したネストされたキーごとに、1つ以上の値、分布、確率などを提供できます。詳細については、Sweep configuration options の parameters セクションを参照してください。
二重ネストパラメータ
Sweep configurations はネストされたパラメータをサポートします。ネストされたパラメータを区切るには、トップレベルのパラメータ名の下に追加の parameters キーを使用します。スイープ設定は多層ネストをサポートします。
ベイズまたはランダムなハイパーパラメータ検索を使用する場合、確率分布を指定します。各ハイパーパラメータについて：
スイープ設定でトップレベル parameters キーを作成します。
parameters キーの中に次のものをネストします：
最適化したいハイパーパラメータの名前を指定します。
distribution キーのために使用したい分布を指定します。ハイパーパラメータ名の下に distribution キーと値のペアをネストします。探索する1つ以上の値を指定します。その値（または値のリスト）は分布キーと整合している必要があります。
(オプション) トップレベルのパラメータ名の下に追加のパラメータキーを使用して、ネストされたパラメータを区切ります。
スイープ設定で定義されたネストされたパラメータは、W&B run 設定で指定されたキーを上書きします。
例として、次の設定で train.py Python スクリプト（行1-2で確認可能）で W&B run を初期化するとします。次に、sweep_configuration（行4-13）の辞書でスイープ設定を定義します。その後、スイープ設定辞書を wandb.sweep に渡してスイープ設定を初期化します（行16を確認）。
def main ():
run = wandb. init(config= {"nested_param" : {"manual_key" : 1 }})
sweep_configuration = {
"top_level_param" : 0 ,
"nested_param" : {
"learning_rate" : 0.01 ,
"double_nested_param" : {"x" : 0.9 , "y" : 0.8 },
},
}
# Initialize sweep by passing in config.
sweep_id = wandb. sweep(sweep= sweep_configuration, project= "<project>" )
# Start sweep job.
wandb. agent(sweep_id, function= main, count= 4 )
W&B run が初期化されたときに渡された nested_param.manual_key はアクセスできません。run.config は、スイープ設定辞書で定義されたキーと値のペアのみを持っています。
Sweep configuration テンプレート
次のテンプレートには、パラメータを構成し、検索制約を指定する方法を示しています。hyperparameter_name をあなたのハイパーパラメータの名前と、<> 内の任意の値で置き換えます。
program : <insert>
method : <insert>
parameter :
hyperparameter_name0 :
value : 0
hyperparameter_name1 :
values : [0 , 0 , 0 ]
hyperparameter_name :
distribution : <insert>
value : <insert>
hyperparameter_name2 :
distribution : <insert>
min : <insert>
max : <insert>
q : <insert>
hyperparameter_name3 :
distribution : <insert>
values :
- <list_of_values>
- <list_of_values>
- <list_of_values>
early_terminate :
type : hyperband
s : 0
eta : 0
max_iter : 0
command :
- ${Command macro}
- ${Command macro}
- ${Command macro}
- ${Command macro}
Sweep configuration の例
CLI
Python スクリプトまたは Jupyter ノートブック
program : train.py
method : random
metric :
goal : minimize
name : loss
parameters :
batch_size :
distribution : q_log_uniform_values
max : 256
min : 32
q : 8
dropout :
values : [0.3 , 0.4 , 0.5 ]
epochs :
value : 1
fc_layer_size :
values : [128 , 256 , 512 ]
learning_rate :
distribution : uniform
max : 0.1
min : 0
optimizer :
values : ["adam" , "sgd" ]
sweep_config = {
"method" : "random" ,
"metric" : {"goal" : "minimize" , "name" : "loss" },
"parameters" : {
"batch_size" : {
"distribution" : "q_log_uniform_values" ,
"max" : 256 ,
"min" : 32 ,
"q" : 8 ,
},
"dropout" : {"values" : [0.3 , 0.4 , 0.5 ]},
"epochs" : {"value" : 1 },
"fc_layer_size" : {"values" : [128 , 256 , 512 ]},
"learning_rate" : {"distribution" : "uniform" , "max" : 0.1 , "min" : 0 },
"optimizer" : {"values" : ["adam" , "sgd" ]},
},
}
ベイズハイパーバンドの例
program : train.py
method : bayes
metric :
goal : minimize
name : val_loss
parameters :
dropout :
values : [0.15 , 0.2 , 0.25 , 0.3 , 0.4 ]
hidden_layer_size :
values : [96 , 128 , 148 ]
layer_1_size :
values : [10 , 12 , 14 , 16 , 18 , 20 ]
layer_2_size :
values : [24 , 28 , 32 , 36 , 40 , 44 ]
learn_rate :
values : [0.001 , 0.01 , 0.003 ]
decay :
values : [1e-5 , 1e-6 , 1e-7 ]
momentum :
values : [0.8 , 0.9 , 0.95 ]
epochs :
value : 27
early_terminate :
type : hyperband
s : 2
eta : 3
max_iter : 27
以下のタブで early_terminate の最小または最大のイテレーション回数を指定する方法を示します：
最大のイテレーション回数
最小のイテレーション回数
この例のブラケットは [3, 3*eta, 3*eta*eta, 3*eta*eta*eta] で、結果として [3, 9, 27, 81] になります。
early_terminate :
type : hyperband
min_iter : 3
この例のブラケットは [27/eta, 27/eta/eta] で、[9, 3] になります。
early_terminate :
type : hyperband
max_iter : 27
s : 2
コマンドの例
program : main.py
metric :
name : val_loss
goal : minimize
method : bayes
parameters :
optimizer.config.learning_rate :
min : !!float 1e-5
max : 0.1
experiment :
values : [expt001, expt002]
optimizer :
values : [sgd, adagrad, adam]
command :
- ${env}
- ${interpreter}
- ${program}
- ${args_no_hyphens}
/usr/bin/env python train.py --param1= value1 --param2= value2
python train.py --param1= value1 --param2= value2
以下のタブで一般的なコマンドマクロを指定する方法を示します：
Python インタープリタの設定
追加のパラメータを追加
引数を省略
Hydra
{$interpreter} マクロを削除し、値を明示的に提供して Python インタプリタをハードコードします。例えば、以下のコードスニペットはその方法を示しています：
command :
- ${env}
- python3
- ${program}
- ${args}
次の例では、sweep configuration のパラメータで指定されていないコマンドライン引数を追加する方法を示します：
command :
- ${env}
- ${interpreter}
- ${program}
- "--config"
- "your-training-config.json"
- ${args}
あなたのプログラムが引数パースを使用しない場合、すべての引数を渡すのを避け、wandb.init がスイープパラメータを自動的に wandb.config に取り込むことを利用できます：
command :
- ${env}
- ${interpreter}
- ${program}
ツールのように引数を渡すコマンドを変更できます Hydra が期待する方法です。詳細については、Hydra with W&B を参照してください。
command :
- ${env}
- ${interpreter}
- ${program}
- ${args_no_hyphens}
2.3.3.1 - Sweep configuration オプション
スイープ設定は、ネストされたキーと値のペアで構成されます。スイープ設定内のトップレベルのキーを使用して、スイープ検索の特性を定義します。例えば、検索するパラメータ（parametermethod
以下のテーブルはトップレベルのスイープ設定キーとその簡単な説明を示しています。各キーについての詳細情報は、該当するセクションを参照してください。
トップレベルキー
説明
program（必須）実行するトレーニングスクリプト
entityこのスイープのエンティティ
projectこのスイープのプロジェクト
descriptionスイープのテキスト説明
nameW&B UIに表示されるスイープの名前。
method（必須）検索戦略
metric最適化するメトリック（特定の検索戦略と停止基準でのみ使用）
parameters（必須）検索するパラメータの範囲
early_terminate任意の早期停止基準
commandトレーニングスクリプトに引数を渡して呼び出すためのコマンド構造
run_capこのスイープの最大 run 数
スイープ設定の構造については、スイープ設定 の構造を参照してください。
metricmetric トップレベルスイープ設定キーを使用して、最適化するメトリックの名前、目標、そして対象のメトリックを指定します。
キー
説明
name最適化するメトリックの名前。
goalminimize または maximize のいずれか（デフォルトは minimize）。
target最適化するメトリックの目標値。このスイープは、指定した目標値に run が到達した場合や到達する場合、新しい run を作成しません。アクティブなエージェントが run を実行中の場合（runがターゲットに到達した場合）、エージェントが新しい run を作成するのを停止する前に、run が完了するのを待ちます。
parametersYAML ファイルまたは Python スクリプト内で、parameters をトップレベルキーとして指定します。parameters キーの中に、最適化したいハイパーパラメータの名前を提供します。一般的なハイパーパラメーターには、学習率、バッチサイズ、エポック数、オプティマイザーなどがあります。あなたのスイープ設定で定義された各ハイパーパラメータに対して、1つ以上の検索制約を指定します。
以下のテーブルは、サポートされているハイパーパラメータ検索制約を示しています。ハイパーパラメータとユースケースに基づいて、以下のサーチ制約のいずれかを使用して、スイープエージェントに検索する場所（分布の場合）または何を（value、valuesなど）検索または使用するかを指示します。
検索制約
説明
valuesこのハイパーパラメータのすべての有効な値を指定します。gridと互換性があります。
valueこのハイパーパラメータの単一の有効な値を指定します。gridと互換性があります。
distribution確率 分布 を指定します。この表の後の注記ではデフォルト値に関する情報について説明しています。
probabilitiesrandomを使用する際に、valuesのそれぞれの要素を選択する確率を指定します。
min, max（intまたはfloat）最大値と最小値。intの場合、int_uniform で分布されたハイパーパラメータ用。floatの場合、uniformで分布されたハイパーパラメータ用。
mu( float ) normal または lognormal で分布されたハイパーパラメータの平均パラメータ。
sigma( float ) normal または lognormal で分布されたハイパーパラメータの標準偏差パラメータ。
q( float ) 量子化されたハイパーパラメーターの量子化ステップサイズ。
parametersルートレベルのパラメーター内に他のパラメーターをネストします。
W&B は、distribution が指定されていない場合、以下の条件に基づいて以下の分布を設定します：
categorical：valuesが指定された場合int_uniform：maxとminが整数として指定された場合uniform：maxとminが浮動小数点数として指定された場合constant：valueにセットを提供した場合 methodmethodキーを使用して、ハイパーパラメータ検索戦略を指定します。選択できるハイパーパラメーター検索戦略は、グリッド検索、ランダム検索、およびベイズ探索です。
グリッド検索
ハイパーパラメータのすべての組み合わせを反復します。グリッド検索は、各反復で使用するハイパーパラメータ値のセットに対して無知な決定を下します。グリッド検索は計算的に高コストになる可能性があります。
グリッド検索は、連続的な検索空間内を検索している場合、永遠に実行されます。
ランダム検索
分布に基づいて、各反復でランダムかつ無知なハイパーパラメータ値のセットを選択します。ランダム検索は、コマンドラインやあなたの python スクリプト、または W&B アプリUI でプロセスを停止しない限り、永遠に実行されます。
ランダム(method: random)検索を選択した場合、metricキーで分布空間を指定します。
ベイズ探索
ランダム検索 とグリッド検索 とは対照的に、ベイズモデルを使用して情報に基づく決定を行います。ベイズ最適化は、確率モデルを使用して、代理関数の値をテストする反復プロセスを経て、どの値を使用するかを決定します。ベイズ探索は、少数の連続的なパラメータに対して効果的ですが、スケールがうまくいかないことがあります。ベイズ探索に関する詳細情報は、ベイズ最適化の入門書 を参照してください。
ベイズ探索は、コマンドラインやあなたの python スクリプト、または W&B アプリUI でプロセスを停止しない限り、永遠に実行されます。
ランダムおよびベイズ探索の分布オプション
parameter キー内で、ハイパーパラメーターの名前をネストします。次に、distributionキーを指定し、値の分布を指定します。
以下のテーブルでは、W&B がサポートする分布を示しています。
distributionキーの値説明
constant定数分布。使用する定数値（value）を指定する必要があります。
categoricalカテゴリ分布。このハイパーパラメータのすべての有効な値（values）を指定する必要があります。
int_uniform整数上の離散一様分布。max と min を整数として指定する必要があります。
uniform連続一様分布。max と min を浮動小数点数として指定する必要があります。
q_uniform量子化一様分布。X が一様である場合、round(X / q) * q を返します。q はデフォルトで 1。
log_uniform対数一様分布。exp(min) と exp(max) の間で X を返し、自然対数が min と max の間で一様に分布。
log_uniform_values対数一様分布。min と max の間で X を返し、log(X) が log(min) と log(max) の間で一様に分布。
q_log_uniform量子化対数一様分布。X が log_uniform である場合、round(X / q) * q を返します。q はデフォルトで 1。
q_log_uniform_values量子化対数一様分布。X が log_uniform_values である場合、round(X / q) * q を返します。q はデフォルトで 1。
inv_log_uniform逆対数一様分布。X を返し、log(1/X) が min と max の間で一様に分布。
inv_log_uniform_values逆対数一様分布。X を返し、log(1/X) が log(1/max) と log(1/min) の間で一様に分布。
normal正規分布。返される値は平均 mu（デフォルト 0）と標準偏差 sigma（デフォルト 1）で通常に分布。
q_normal量子化正規分布。X が normal である場合、round(X / q) * q を返します。q はデフォルトで 1。
log_normal対数正規分布。X の自然対数 log(X) が平均 mu（デフォルト 0）と標準偏差 sigma（デフォルト 1）で通常に分布する値 X を返します。
q_log_normal量子化対数正規分布。X が log_normal である場合、round(X / q) * q を返します。q はデフォルトで 1。
early_terminate実行のパフォーマンスが悪い場合に停止させるために早期終了（early_terminate）を使用します。早期終了が発生した場合、W&B は現在の run を停止し、新しいハイパーパラメータの値のセットで新しい run を作成します。
early_terminate を使用する場合、停止アルゴリズムを指定する必要があります。スイープ設定内で early_terminate 内に type キーをネストします。
停止アルゴリズム
Hyperband ハイパーパラメータ最適化は、プログラムが停止すべきか、先に進むべきかを、brackets と呼ばれるあらかじめ設定されたイテレーション数で評価します。
W&B run が bracket に到達したとき、sweep はその run のメトリックを過去に報告されたすべてのメトリック値と比較します。run のメトリック値が高すぎる場合（目標が最小化の場合）、または run のメトリックが低すぎる場合（目標が最大化の場合）、sweep は run を終了します。
ベースの反復数に基づいて bracket が設定されます。bracket の数は、最適化するメトリックをログした回数に対応します。反復はステップ、エポック、またはその中間に対応することができます。ステップカウンタの数値は bracket 計算に使用されません。
bracket スケジュールを作成するには、min_iter または max_iter のいずれかを指定してください。
キー
説明
min_iter最初の bracket の反復を指定
max_iter最大反復数を指定。
sbracket の合計数を指定（ max_iter に必要）
etabracket 倍数スケジュールを指定（デフォルト： 3）。
strictより厳格にオリジナルの Hyperband 論文に従って run を厳しく削減する「strict」モードを有効にします。デフォルトでは false。
Hyperband は数分ごとに終了する
W&B run を確認します。終了時刻は、run やイテレーションが短い場合、指定された bracket とは異なることがあります。
commandcommand キー内のネストされた値を使用して、形式と内容を修正できます。ファイル名などの固定コンポーネントを直接含めることができます。
Unix システムでは、/usr/bin/env は環境に基づいて OS が正しい Python インタープリターを選択することを保証します。
W&B は、コマンドの可変コンポーネントのために次のマクロをサポートしています：
コマンドマクロ
説明
${env}Unix システムでは /usr/bin/env、Windows では省略されます。
${interpreter}python に展開されます。
${program}スイープ設定 program キーで指定されたトレーニングスクリプトファイル名。
${args}--param1=value1 --param2=value2 の形式でのハイパーパラメーターとその値。
${args_no_boolean_flags}ハイパーパラメータとその値が --param1=value1 の形式であるが、ブールパラメータは True の場合を --boolean_flag_param の形にし、False の場合は省略します。
${args_no_hyphens}param1=value1 param2=value2 の形式でのハイパーパラメータとその値。
${args_json}JSON としてエンコードされたハイパーパラメーターとその値。
${args_json_file}JSON としてエンコードされたハイパーパラメータとその値を含むファイルへのパス。
${envvar}環境変数を渡す方法。${envvar:MYENVVAR} __ は MYENVVAR 環境変数の値に展開されます。 __
2.3.4 - sweep を初期化する
W&B で Sweep を初期化する
W&B は、Sweep Controller を使用して、クラウド (標準)、ローカル (ローカル) の 1 台以上のマシンで スイープを管理します。run が完了すると、sweep controller は新しい run を実行するための新しい指示を発行します。これらの指示は、実際に run を実行する agents によって受け取られます。典型的な W&B Sweep では、controller は W&B サーバー上に存在し、agents は_あなたの_マシン上に存在します。
以下のコードスニペットは、CLI、および Jupyter Notebook や Python スクリプト内でスイープを初期化する方法を示しています。
スイープを初期化する前に、スイープ設定が YAML ファイルまたはスクリプト内のネストされた Python 辞書オブジェクトで定義されていることを確認してください。詳細については、sweep configuration を定義する を参照してください。
W&B Sweep と W&B Run は同じ Project 内にある必要があります。そのため、W&B を初期化するときに指定する名前 (wandb.initwandb.sweep
Python script or notebook
CLI
W&B SDK を使用してスイープを初期化します。スイープ設定辞書を sweep パラメータに渡します。オプションで、W&B Run の出力を保存したい Project の名前を Project パラメータ (project) に指定することができます。Project が指定されていない場合は、run は「Uncategorized」Project に置かれます。
import wandb
# スイープ設定の例
sweep_configuration = {
"method" : "random" ,
"name" : "sweep" ,
"metric" : {"goal" : "maximize" , "name" : "val_acc" },
"parameters" : {
"batch_size" : {"values" : [16 , 32 , 64 ]},
"epochs" : {"values" : [5 , 10 , 15 ]},
"lr" : {"max" : 0.1 , "min" : 0.0001 },
},
}
sweep_id = wandb. sweep(sweep= sweep_configuration, project= "project-name" )
wandb.sweep
W&B CLI を使用してスイープを初期化します。設定ファイルの名前を指定します。オプションで、project フラグに Project の名前を指定することができます。Project が指定されていない場合、W&B Run は「Uncategorized」Project に配置されます。
wandb sweepsweeps_demo Project のスイープを初期化し、config.yaml ファイルを設定に使用しています。
wandb sweep --project sweeps_demo config.yaml
このコマンドはスイープ ID を出力します。スイープ ID には entity 名と Project 名が含まれます。スイープ ID をメモしておいてください。
2.3.5 - sweep エージェントを開始または停止する
1 台または複数のマシン上で W&B Sweep Agent を開始または停止します。
W&B Sweep を 1 台以上のマシン上の 1 台以上のエージェントで開始します。W&B Sweep エージェントは、ハイパーパラメーターを取得するために W&B Sweep を初期化したときにローンンチされた W&B サーバーにクエリを送り、それらを使用してモデル トレーニングを実行します。
W&B Sweep エージェントを開始するには、W&B Sweep を初期化したときに返された W&B Sweep ID を指定します。W&B Sweep ID の形式は次のとおりです。
ここで:
entity: W&B のユーザー名またはチーム名。
project: W&B Run の出力を保存したいプロジェクトの名前。プロジェクトが指定されていない場合、run は「未分類」プロジェクトに置かれます。
sweep_ID: W&B によって生成される疑似ランダムな一意の ID。
Jupyter ノートブックまたは Python スクリプト内で W&B Sweep エージェントを開始する場合、W&B Sweep が実行する関数の名前を指定します。
次のコードスニペットは、W&B でエージェントを開始する方法を示しています。ここでは、既に設定ファイルを持っており、W&B Sweep を初期化済みであると仮定しています。設定ファイルを定義する方法について詳しくは、Define sweep configuration を参照してください。
CLI
Python script or notebook
sweep agent コマンドを使用してスイープを開始します。スイープを初期化するときに返されたスイープ ID を指定します。以下のコードスニペットをコピーして貼り付け、sweep_id をスイープ ID に置き換えてください:
W&B Python SDK ライブラリを使用してスイープを開始します。スイープを初期化するときに返されたスイープ ID を指定します。さらに、スイープが実行する関数の名前も指定します。
wandb. agent(sweep_id= sweep_id, function= function_name)
W&B エージェントを停止
ランダムおよびベイズ探索は永遠に実行されます。プロセスをコマンドライン、Python スクリプト内、または
Sweeps UI から停止する必要があります。
オプションで、Sweep agent が試みるべき W&B Runs の数を指定します。以下のコードスニペットは、Jupyter ノートブック、Python スクリプト内で最大の W&B Runs 数を設定する方法を示しています。
Python script or notebook
CLI
まず、スイープを初期化します。詳細は Initialize sweeps を参照してください。
sweep_id = wandb.sweep(sweep_config)
次にスイープジョブを開始します。スイープ初期化から生成されたスイープ ID を提供します。試行する run の最大数を設定するために count パラメータに整数値を渡します。
sweep_id, count = "dtzl1o7u" , 10
wandb. agent(sweep_id, count= count)
スイープエージェントが終了した後に新しい run を同じスクリプトまたはノートブック内で開始する場合は、新しい run を開始する前に wandb.teardown() を呼び出す必要があります。
まず、wandb sweepInitialize sweeps を参照してください。
wandb sweep config.yaml
試行する run の最大数を設定するために、count フラグに整数値を渡します。
NUM= 10
SWEEPID= "dtzl1o7u"
wandb agent -- count $ NUM $ SWEEPID
2.3.6 - エージェントの並列化
マルチコアまたはマルチGPUマシンでW&B sweep agentを並列化します。
W&B スイープエージェントをマルチコアまたはマルチ GPU マシンで並列化しましょう。始める前に、W&B スイープが初期化されていることを確認してください。W&B スイープの初期化方法についての詳細は、Initialize sweeps をご覧ください。
マルチ CPU マシンで並列化
ユースケースに応じて、以下のタブを参照し、CLI や Jupyter ノートブック内で W&B スイープエージェントを並列化する方法を学びましょう。
wandb agentsweep を初期化したとき に返されたスイープ ID を提供してください。
ローカルマシンで複数のターミナルウィンドウを開きます。
以下のコードスニペットをコピーして貼り付け、sweep_id をあなたのスイープ ID に置き換えます:
W&B Python SDK ライブラリを使用して、Jupyter ノートブック内で W&B スイープエージェントを複数の CPU に渡って並列化します。sweep を初期化したとき に返されたスイープ ID を確認してください。さらに、スイープが実行する関数の名前を function パラメータに提供します。
複数の Jupyter ノートブックを開きます。
複数の Jupyter ノートブックに W&B スイープ ID をコピーして貼り付け、W&B スイープを並列化します。例えば、sweep_id という変数にスイープ ID が保存されていて、関数の名前が function_name である場合、以下のコードスニペットを複数の Jupyter ノートブックに貼り付けることができます:
wandb. agent(sweep_id= sweep_id, function= function_name)
マルチ GPU マシンで並列化
CUDA Toolkit を使用して、ターミナルで W&B スイープエージェントを複数の GPU に渡って並列化するための手順に従ってください。
ローカルマシンで複数のターミナルウィンドウを開きます。
W&B スイープジョブを開始するときに CUDA_VISIBLE_DEVICES を使用して使用する GPU インスタンスを指定します（wandb agentCUDA_VISIBLE_DEVICES に使用する GPU インスタンスに対応する整数値を割り当てます。
例えば、ローカルマシンに 2 つの NVIDIA GPU があると仮定します。ターミナルウィンドウを開き、CUDA_VISIBLE_DEVICES を 0（CUDA_VISIBLE_DEVICES=0）に設定します。以下の例で、sweep_ID を初期化したときに返された W&B スイープ ID に置き換えます:
ターミナル 1
CUDA_VISIBLE_DEVICES= 0 wandb agent sweep_ID
2 番目のターミナルウィンドウを開きます。CUDA_VISIBLE_DEVICES を 1（CUDA_VISIBLE_DEVICES=1）に設定します。次のコードスニペットで言及された sweep_ID に同じ W&B スイープ ID を貼り付けます:
ターミナル 2
CUDA_VISIBLE_DEVICES= 1 wandb agent sweep_ID
2.3.7 - sweep 結果を可視化する
W&B App UI で W&B スイープの結果を可視化します。
Visualize の結果を W&B Sweeps の W&B App UI で確認しましょう。https://wandb.ai/home にアクセスして、W&B App UI に移動します。W&B Sweep を初期化した際に指定したプロジェクトを選択します。プロジェクトのworkspace にリダイレクトされます。左側のパネルから Sweep アイコン （ほうきのアイコン）を選択します。 Sweep UI で、リストから Sweep の名前を選択します。
デフォルトでは、W&B は W&B Sweep ジョブを開始すると、パラレル座標プロット、パラメータの重要度プロット、そして散布図を自動的に作成します。
パラレル座標チャートは、多数のハイパーパラメーターとモデルメトリクスの関係を一目で要約します。パラレル座標プロットの詳細については、パラレル座標 を参照してください。
左の散布図は、Sweep の間に生成された W&B Runs を比較します。散布図の詳細については、散布図 を参照してください。
右のパラメータの重要度プロットは、メトリクスの望ましい値と高度に相関するハイパーパラメーターをリストアップします。パラメータの重要度プロットの詳細については、パラメータの重要度 を参照してください。
自動で使用される従属と独立の値（x と y 軸）を変更できます。各パネル内には Edit panel という鉛筆のアイコンがあります。Edit panel を選択します。モデルが表示されます。そのモデル内で、グラフの振る舞いを変更することができます。
すべてのデフォルトの W&B 可視化オプションの詳細については、パネル を参照してください。W&B Sweep の一部ではない W&B Runs からプロットを作成する方法については、Data Visualization docs を参照してください。
2.3.8 - スイープを CLI で管理する
W&B Sweep を CLI で一時停止、再開、キャンセルします。
W&B Sweep を CLI で一時停止、再開、キャンセルすることができます。W&B Sweep を一時停止すると、新しい W&B Runs を再開するまで実行しないよう W&B エージェントに指示します。Sweep を再開すると、エージェントに新しい W&B Run の実行を続けるよう指示します。W&B Sweep を停止すると、W&B Sweep エージェントに新しい W&B Run の作成や実行を停止するように指示します。W&B Sweep をキャンセルすると、現在実行中の W&B Run を強制終了し、新しい Runs の実行を停止するよう Sweep エージェントに指示します。
それぞれの場合に、W&B Sweep を初期化したときに生成された W&B Sweep ID を指定します。新しいターミナルウィンドウを開いて、以下のコマンドを実行します。新しいターミナルウィンドウを開くと、現在のターミナルウィンドウに W&B Sweep が出力ステートメントを表示している場合でも、コマンドをより簡単に実行できます。
スイープを一時停止、再開、およびキャンセルするための次のガイダンスを使用してください。
スイープを一時停止する
W&B Sweep を一時的に停止して新しい W&B Run の実行を一時停止します。wandb sweep --pause コマンドを使用して W&B Sweep を一時停止します。一時停止したい W&B Sweep ID を指定します。
wandb sweep --pause entity/project/sweep_ID
スイープを再開する
一時停止している W&B Sweep を wandb sweep --resume コマンドで再開します。再開したい W&B Sweep ID を指定します。
wandb sweep --resume entity/project/sweep_ID
スイープを停止する
W&B スイープを完了し、新しい W&B Runs の実行を停止し、現在実行中の Runs が終了するのを待ちます。
wandb sweep --stop entity/project/sweep_ID
スイープをキャンセルする
すべての実行中の run を強制終了し、新しい run の実行を停止するためにスイープをキャンセルします。wandb sweep --cancel コマンドを使用して W&B Sweep をキャンセルします。キャンセルしたい W&B Sweep ID を指定します。
wandb sweep --cancel entity/project/sweep_ID
CLI コマンドオプションの全リストについては、wandb sweep CLI リファレンスガイドを参照してください。
複数のエージェントにわたってスイープを一時停止、再開、停止、キャンセルする
単一のターミナルから複数のエージェントにわたって W&B Sweep を一時停止、再開、停止、またはキャンセルします。たとえば、マルチコアマシンを持っていると仮定します。W&B Sweep を初期化した後、ターミナルウィンドウを新たに開き、各新しいターミナルに Sweep ID をコピーします。
任意のターミナル内で、wandb sweep CLI コマンドを使用して W&B Sweep を一時停止、再開、停止、またはキャンセルします。たとえば、以下のコードスニペットは、CLI を使用して複数のエージェントにわたって W&B Sweep を一時停止する方法を示しています。
wandb sweep --pause entity/project/sweep_ID
--resume フラグと共に Sweep ID を指定して、エージェントにわたって Sweep を再開します。
wandb sweep --resume entity/project/sweep_ID
W&B エージェントを並列化する方法の詳細については、Parallelize agents を参照してください。
2.3.9 - アルゴリズムをローカルで管理する
W&B のクラウドホスティッドサービスを使用せずに、ローカルで検索およびストップアルゴリズムを実行します。
ハイパーパラメータコントローラは、デフォルトでウェイト＆バイアスによってクラウドサービスとしてホストされています。W&Bエージェントはコントローラと通信して、トレーニングに使用する次のパラメータセットを決定します。コントローラは、どのrunを停止するかを決定するための早期停止アルゴリズムの実行も担当しています。
ローカルコントローラ機能により、ユーザーはアルゴリズムをローカルで検索および停止することができます。ローカルコントローラは、ユーザーにコードを検査および操作する能力を与え、問題のデバッグやクラウドサービスに組み込むことができる新機能の開発を可能にします。
この機能は、Sweepsツールの新しいアルゴリズムの迅速な開発とデバッグをサポートするために提供されています。本来のハイパーパラメータ最適化のワークロードを目的としていません。
始める前に、W&B SDK (wandb) をインストールする必要があります。次のコマンドをコマンドラインに入力してください：
pip install wandb sweeps
以下の例では、既に設定ファイルとPythonスクリプトまたはJupyterノートブックで定義されたトレーニングループがあることを前提としています。設定ファイルの定義方法についての詳細は、Define sweep configuration を参照してください。
コマンドラインからローカルコントローラを実行する
通常、W&Bがホストするクラウドサービスのハイパーパラメータコントローラを使用する際と同様に、スイープを初期化します。ローカルコントローラをW&Bスイープジョブ用に使用することを示すために、コントローラフラグ (controller) を指定します：
wandb sweep --controller config.yaml
または、スイープを初期化することと、ローカルコントローラを使用することを指定することを2つのステップに分けることもできます。
ステップを分けるには、まず次のキーと値をスイープのYAML設定ファイルに追加します：
次に、スイープを初期化します：
スイープを初期化した後、wandb controller
# wandb sweep コマンドが sweep_id を出力します
wandb controller { user} /{ entity} /{ sweep_id}
ローカルコントローラを使用することを指定した後、スイープを実行するために1つ以上のSweepエージェントを開始します。通常のW&Bスイープを開始するのと同じようにしてください。Start sweep agents を参照してください。
W&B Python SDKを使用してローカルコントローラを実行する
以下のコードスニペットは、W&B Python SDKを使用してローカルコントローラを指定し、使用する方法を示しています。
Python SDKでコントローラを使用する最も簡単な方法は、wandb.controllerrun メソッドを使用してスイープジョブを開始します：
sweep = wandb. controller(sweep_id)
sweep. run()
コントローラループをより詳細に制御したい場合：
import wandb
sweep = wandb. controller(sweep_id)
while not sweep. done():
sweep. print_status()
sweep. step()
time. sleep(5 )
パラメータの提供に関してさらに詳細なコントロールが必要な場合：
import wandb
sweep = wandb. controller(sweep_id)
while not sweep. done():
params = sweep. search()
sweep. schedule(params)
sweep. print_status()
コードですべてのスイープを指定したい場合は、次のように実装できます：
import wandb
sweep = wandb. controller()
sweep. configure_search("grid" )
sweep. configure_program("train-dummy.py" )
sweep. configure_controller(type= "local" )
sweep. configure_parameter("param1" , value= 3 )
sweep. create()
sweep. run()
2.3.10 - スイープ UI
スイープ UI のさまざまなコンポーネントを説明します。
状態 (State )、作成時間 (Created )、スイープを開始したエンティティ (Creator )、完了した run の数 (Run count )、スイープの計算にかかった時間 (Compute time ) が Sweeps UI に表示されます。スイープが作成する予想 run の数 (Est. Runs ) は、離散探索空間でグリッド検索を行うと提供されます。インターフェースからスイープをクリックして、一時停止、再開、停止、または終了させることもできます。
2.3.11 - スイープについて詳しく学ぶ
役立つSweepsの情報源のコレクション。
Academic papers
Li, Lisha, et al. “Hyperband: A novel bandit-based approach to hyperparameter optimization. ” The Journal of Machine Learning Research 18.1 (2017): 6765-6816.
Sweep Experiments
次の W&B Reports では、W&B Sweeps を使用したハイパーパラメータ最適化を探るプロジェクトの例を紹介しています。
selfm-anaged
次のハウツーガイドでは、W&B を使用して現実世界の問題を解決する方法を示しています：
Sweep GitHub repository
W&B はオープンソースを推奨し、コミュニティからの貢献を歓迎します。GitHub リポジトリは https://github.com/wandb/sweeps で見つけることができます。W&B オープンソース リポジトリへの貢献方法については、W&B GitHub Contribution guidelines を参照してください。
2.3.12 - スイープのトラブルシューティング
一般的な W&B Sweep の問題をトラブルシュートする。
一般的なエラーメッセージのトラブルシューティングには、提案されたガイダンスを参照してください。
CommError, Run does not exist および ERROR Error uploadingこれら2つのエラーメッセージが返される場合、W&B Run ID が定義されている可能性があります。例えば、Jupyter Notebooks や Python スクリプトのどこかに類似のコードスニペットが定義されているかもしれません。
wandb. init(id= "some-string" )
W&B Sweeps では Run ID を設定することはできません。なぜなら、W&B が作成する Runs には、W&B が自動的にランダムで一意の ID を生成するからです。
W&B Run IDs は、プロジェクト内で一意である必要があります。
テーブルやグラフに表示するカスタム名を設定したい場合は、W&B を初期化するときに name パラメータに名前を渡すことをお勧めします。例えば：
wandb. init(name= "a helpful readable run name" )
Cuda out of memoryこのエラーメッセージが表示される場合は、プロセスベースの実行を使用するようにコードをリファクタリングしてください。具体的には、コードを Python スクリプトに書き換えてください。また、W&B Python SDK ではなく CLI から W&B Sweep Agent を呼び出してください。
例として、コードを train.py という名の Python スクリプトに書き直すとします。その際、トレーニングスクリプト (train.py) の名前を YAML Sweep 設定ファイル (config.yaml の例) に追加します。
program : train.py
method : bayes
metric :
name : validation_loss
goal : maximize
parameters :
learning_rate :
min : 0.0001
max : 0.1
optimizer :
values : ["adam" , "sgd" ]
次に、Python スクリプト train.py に以下を追加します。
if _name_ == "_main_" :
train()
CLI に移動して、wandb sweep を使用して W&B Sweep を初期化します。
返された W&B Sweep ID をメモします。次に、 Sweep のジョブを CLI で wandb agentwandb.agentsweep_ID を前のステップで返された Sweep ID に置き換えてください。
anaconda 400 errorこのエラーは通常、最適化しているメトリックをログしていない場合に発生します。
wandb: ERROR Error while calling W&B API: anaconda 400 error:
{ "code" : 400, "message" : "TypeError: bad operand type for unary -: 'NoneType'" }
YAML ファイルやネストされた辞書内で、最適化する「metric」 というキーを指定します。このメトリックをログ (wandb.log) することを確認してください。また、Python スクリプトや Jupyter Notebook 内で最適化するように定義した exact なメトリック名を必ず使用してください。設定ファイルについての詳細は、Define sweep configuration を参照してください。
2.3.13 - チュートリアル: プロジェクトから sweep ジョブを作成する
既存の W&B プロジェクトから sweep ジョブを作成する方法に関するチュートリアル。
このチュートリアルでは、既存の W&B プロジェクトからスイープジョブを作成する方法を説明します。PyTorch の畳み込みニューラルネットワークを用いて画像を分類するために Fashion MNIST dataset を使用します。必要なコードとデータセットは、W&B のリポジトリにあります：https://github.com/wandb/examples/tree/master/examples/pytorch/pytorch-cnn-fashion
この W&B ダッシュボード で結果を探索してください。
1. プロジェクトを作成する
最初にベースラインを作成します。W&B の GitHub リポジトリから PyTorch MNIST データセットの例モデルをダウンロードします。次に、モデルをトレーニングします。そのトレーニングスクリプトは examples/pytorch/pytorch-cnn-fashion ディレクトリーにあります。
このリポジトリをクローンします git clone https://github.com/wandb/examples.git
この例を開きます cd examples/pytorch/pytorch-cnn-fashion
run を手動で実行します python train.py
オプションとして、W&B アプリ UI ダッシュボードで例を探索します。
例のプロジェクトページを見る →
2. スイープを作成する
あなたのプロジェクトページから、サイドバーの Sweep tab を開き、Create Sweep を選択します。
自動生成された設定は、完了した run に基づいてスイープする値を推測します。試したいハイパーパラメーターの範囲を指定するために設定を編集します。スイープをローンチすると、ホストされた W&B スイープサーバー上で新しいプロセスが開始されます。この集中サービスは、トレーニングジョブを実行しているエージェント（機械）を調整します。
3. エージェントをローンチする
次に、ローカルでエージェントをローンチします。作業を分散してスイープジョブをより早く終わらせたい場合は、最大20のエージェントを異なるマシンで並行してローンチすることができます。エージェントは、次に試すパラメータのセットを出力します。
これで、スイープを実行しています。以下の画像は、例のスイープジョブが実行されているときのダッシュボードがどのように見えるかを示しています。例のプロジェクトページを見る →
既存の run で新しいスイープをシードする
以前にログした既存の run を使用して新しいスイープをローンチします。
プロジェクトテーブルを開きます。
表の左側のチェックボックスを使用して使用したい run を選択します。
新しいスイープを作成するためにドロップダウンをクリックします。
スイープはサーバー上に設定されます。run を開始するために、1つ以上のエージェントをローンチするだけです。
新しいスイープをベイジアンスイープとして開始すると、選択した run はガウスプロセスにもシードされます。
2.4 - W&B アプリ UI リファレンス
2.4.1 - パネル
ワークスペースパネルの可視化機能を使用して ログされたデータ をキーごとに探り、ハイパーパラメーターと出力メトリクスの関係を可視化することなどができます。
ワークスペースモード
W&B Projects は2つの異なるワークスペースモードをサポートしています。ワークスペース名の横のアイコンがそのモードを示しています。
アイコン
ワークスペースモード
Automated workspaces はプロジェクト内でログされたすべてのキーに対して自動的にパネルを生成します。自動ワークスペースを選ぶ理由:プロジェクトのすべての利用可能なデータを可視化してすぐに始めたい場合。 少数のキーをログする小規模プロジェクトの場合。 より広範な分析のため。 Quick add を使って再作成できます。
Manual workspaces は最初は空白で、ユーザーによって意図的に追加されたパネルのみが表示されます。手動ワークスペースを選ぶ理由:プロジェクトのログされたキーの一部だけを主に気にかけている場合。 より焦点を絞った分析が必要な場合。 ワークスペースのパフォーマンスを向上させるため、あまり役に立たないパネルを読み込まないようにする場合。 Quick add を使用して、手動ワークスペースとそのセクションを有用な可視化で迅速に埋めることができます。
ワークスペースがパネルを生成する方法を変更するには、ワークスペースをリセットする を行います。
ワークスペースの変更を元に戻す ワークスペースの変更を元に戻すには、Undo ボタン（左向きの矢印）をクリックするか、CMD + Z (macOS) または CTRL + Z (Windows / Linux) を入力します。
ワークスペースをリセットする方法
ワークスペースのリセット手順:
ワークスペースの上部でアクションメニュー ... をクリックします。
Reset workspace をクリックします。
ワークスペースレイアウトを設定するには、ワークスペースの上部近くにある Settings をクリックし、次に Workspace layout をクリックします。
検索時に空のセクションを隠す （デフォルトではオン）パネルをアルファベット順に並べ替え （デフォルトではオフ）セクションの編成 （デフォルトでは最初のプレフィックスでグループ化）。この設定を変更するには:
鍵アイコンをクリックします。
セクション内のパネルをどのようにグループ化するか選択します。
ワークスペース内のラインプロットのデフォルトを設定するには、Line plots を参照してください。
セクションのレイアウトを設定するには、その歯車アイコンをクリックし、次に Display preferences をクリックします。
ツールチップ内での色付き run 名前のオン/オフ （デフォルトではオン）仲間のチャートツールチップでハイライトされた run のみを表示 （デフォルトではオフ）ツールチップに表示される run の数 （単一の run、すべての run、または Default ）プライマリチャートツールチップでの run 名前の完全な表示 （デフォルトではオフ）
パネルを全画面表示する
全画面表示モードでは、run 選択が表示され、パネルは通常の1000バケツではなく、10,000バケツでの完全な精度のサンプリングモードプロットを使用します。
全画面表示モードでパネルを表示するには:
パネルの上にカーソルを合わせます。
パネルのアクションメニュー ... をクリックし、次に全画面ボタンをクリックします。これはビューファインダーまたは四角の四隅を示すアウトラインのように見えます。
全画面表示モードでパネルを表示している間に パネルを共有する と、生成されたリンクは自動的に全画面表示モードで開きます。
全画面表示モードからパネルのワークスペースに戻るには、ページ上部の左向き矢印をクリックします。
パネルを追加する
このセクションでは、ワークスペースにパネルを追加するさまざまな方法を示します。
パネルを手動で追加する
パネルをワークスペースに一度に1つずつ、グローバルまたはセクションレベルで追加できます。
グローバルにパネルを追加するには、パネル検索フィールドの近くにあるコントロールバーで Add panels をクリックします。
セクションに直接パネルを追加するには、セクションのアクション ... メニューをクリックし、次に + Add panels をクリックします。
追加するパネルの種類を選択します。例えばチャート。パネルの設定詳細が表示され、デフォルトが選択されます。
必要に応じて、パネルとその表示設定をカスタマイズします。設定オプションは選択したパネルのタイプに依存します。各パネルタイプのオプションについてもっと知るには、以下の関連セクションを参照してください。Line plots や Bar plots など。
Apply をクリックします。
クイック追加でパネルを追加する
Quick add を使用して、選択した各キーに対して自動的にパネルを追加できます。これをグローバルまたはセクションレベルで行うことができます。
削除されたパネルのない自動ワークスペースでは、Quick add オプションは表示されません。これは、ワークスペースがすでにログされたすべてのキー向けにパネルを含んでいるためです。削除したパネルを再追加するためにQuick add を使用できます。
グローバルに Quick add を使用してパネルを追加するには、パネル検索フィールド近くのコントロールバーで Add panels をクリックし、それから Quick add をクリックします。
セクションに直接 Quick add を使用してパネルを追加するには、セクションのアクション ... メニューをクリック、Add panels をクリックし、それから Quick add をクリックします。
パネルのリストが表示されます。チェックマークのある各パネルはすでにワークスペースに含まれています。
利用可能なすべてのパネルを追加するには、リストの上の Add panels ボタンをクリックします。Quick Add リストが閉じられ、新しいパネルがワークスペースに表示されます。
リストから個別にパネルを追加するには、そのパネルの行にカーソルを合わせ、それから Add をクリックします。追加したい各パネルについてこのステップを繰り返し、Quick Add リストの右上にある X をクリックして閉じます。新しいパネルがワークスペースに表示されます。
必要に応じて、パネルの設定をカスタマイズします。
パネルを共有する
このセクションでは、リンクを使ってパネルを共有する方法を示します。
リンクを使ってパネルを共有するには、次のどちらかを行います:
パネルを全画面表示モードで表示している間、ブラウザからURLをコピーします。
アクションメニュー ... をクリックし、Copy panel URL を選択します。
ユーザーまたはチームにリンクを共有します。リンクにアクセスすると、そのパネルは 全画面モード で開きます。
全画面表示モードからパネルのワークスペースに戻るには、ページ上部の左向き矢印をクリックします。
プログラムでパネルの全画面リンクを構成する
特定の状況、たとえば オートメーションを作成する 場合などに、パネルの全画面URLを含めると便利です。このセクションでは、パネルの全画面URLの形式を示します。以下の例では、ブラケット内の entity, project, panel, section 名を置き換えてください。
https://wandb.ai/ <ENTITY_NAME>/<PROJECT_NAME>?panelDisplayName=<PANEL_NAME>&panelSectionName=<SECTON_NAME>
同じセクション内の複数のパネルが同じ名前を持つ場合、このURLはその名前を持つ最初のパネルを開きます。
パネルを埋め込んでソーシャルメディアで共有する
ウェブサイトにパネルを埋め込んだり、ソーシャルメディアで共有するには、そのパネルがリンクを持つ誰でも閲覧できる状態でなければなりません。プロジェクトがプライベートであれば、そのプロジェクトのメンバーのみがパネルを閲覧できます。プロジェクトが公開されていれば、リンクを持つ誰でもそのパネルを閲覧できます。
ソーシャルメディアでパネルを埋め込んで共有するコードを取得する手順:
ワークスペースからパネルの上にカーソルを合わせ、そのアクションメニュー ... をクリックします。
Share タブをクリックします。招待した人だけにアクセス権 を リンクを持つ全員が閲覧可能 に変更します。そうしないと次のステップのオプションは使用できません。Twitterで共有 , Redditで共有 , LinkedInで共有 , または 埋め込みリンクをコピー を選択します。
パネルレポートをメールで送信する
単一のパネルをスタンドアロンのレポートとしてメールする手順:
パネルの上にカーソルを合わせ、パネルのアクションメニュー ... をクリックします。
Share panel in report をクリックします。Invite タブを選択します。メールアドレスまたはユーザー名を入力します。
必要に応じて、** can view** を can edit に変更します。
Invite をクリックします。W&B はユーザーに対し、共有するパネルのみを含むレポートのクリック可能なリンクをメールで送信します。
パネルを共有する 場合とは異なり、受信者はこのレポートからワークスペースにアクセスできません。
パネルを管理する
パネルを編集する
パネルを編集する手順:
鉛筆アイコンをクリックします。
パネルの設定を変更します。
パネルを別のタイプに変更するには、タイプを選択し、設定を構成します。
Apply をクリックします。
パネルを移動する
異なるセクションにパネルを移動するには、パネルのドラッグハンドルを使用します。リストから新しいセクションを選択するには:
必要に応じて、最後のセクションの後に Add section をクリックして新しいセクションを作成します。
パネルのアクション ... メニューをクリックします。
Move をクリックし、新しいセクションを選択します。
また、ドラッグハンドルを使用して、セクション内のパネルを並べ替えることもできます。
パネルを複製する
パネルを複製する手順:
パネルの上部でアクション ... メニューをクリックします。
Duplicate をクリックします。
必要に応じて、複製したパネルを カスタマイズ または 移動 することができます。
パネルを削除する
パネルを削除する手順:
パネルの上にマウスを移動します。
アクション ... メニューを選択します。
Delete をクリックします。
手動ワークスペースからすべてのパネルを削除するには、そのアクション ... メニューをクリックし、Clear all panels をクリックします。
自動または手動ワークスペースからすべてのパネルを削除するには、ワークスペースをリセット します。Automatic を選択すると、デフォルトのパネルセットから開始します。Manual を選択すると、パネルのない空のワークスペースから開始します。
セクションを管理する
デフォルトでは、ワークスペース内のセクションはキーのログ階層を反映しています。ただし、手動ワークスペースでは、一度パネルを追加し始めるとセクションが表示されます。
セクションを追加する
セクションを追加するには、最後のセクションの後に Add section をクリックします。
既存のセクションの前または後に新しいセクションを追加するには、セクションのアクション ... メニューをクリックし、New section below または New section above をクリックします。
セクションのパネルを管理する
多くのパネルを持つセクションは、Standard grid レイアウトを使用している場合デフォルトでページ分割されます。ページに表示されるパネルの数は、パネルの設定とセクション内のパネルのサイズによります。
セクションが使用しているレイアウトを確認するには、セクションのアクション ... メニューをクリックします。セクションのレイアウトを変更するには、Layout grid セクションで Standard grid または Custom grid を選択します。
パネルのサイズを変更するには、パネルの上にカーソルを合わせて、ドラッグハンドルをクリックし、パネルのサイズを調整します。
セクションが Standard grid を使用している場合、1つのパネルのサイズを変更すると、そのセクション内のすべてのパネルのサイズが変更されます。
セクションが Custom grid を使用している場合、それぞれのパネルのサイズを個別にカスタマイズできます。
ページに表示するパネルの数をカスタマイズするには:
セクションの上部で 1 to of をクリックします。ここで <X> は表示中のパネル数、<Y> はパネルの合計数です。
1ページに表示するパネルの数を最大100まで選択します。
多くのパネルがある場合にすべてのパネルを表示するには、パネルを Custom grid レイアウトを使用するように構成します。セクションのアクション ... メニューをクリックし、Layout grid セクションで Custom grid を選択します。
セクションからパネルを削除するには:
パネルにカーソルを合わせ、そのアクション ... メニューをクリックします。
Delete をクリックします。
ワークスペースを自動ワークスペースにリセットすると、削除されたすべてのパネルが再び表示されます。
セクション名を変更する
セクション名を変更するには、そのアクション ... メニューから Rename section をクリックします。
セクションを削除する
セクションを削除するには、その ... メニューをクリックして Delete section をクリックします。これにより、セクションとそのパネルも削除されます。
2.4.1.1 - 折れ線グラフ
メトリクスを可視化し、軸をカスタマイズし、プロット上で複数のラインを比較します
ラインプロットは、wandb.log() でメトリクスを時間経過とともにプロットするとデフォルトで表示されます。複数のラインを同じプロットで比較したり、カスタム軸を計算したり、ラベルをリネームしたりするために、チャート設定をカスタマイズできます。
ラインプロット設定を編集する
このセクションでは、個々のラインプロットパネル、セクション内のすべてのラインプロットパネル、またはワークスペース内のすべてのラインプロットパネルの設定を編集する方法を紹介します。
カスタムの x 軸を使用したい場合は、同じ wandb.log() の呼び出しで y 軸と一緒にログを取るようにしてください。
個別のラインプロット
個々のラインプロットの設定は、セクションまたはワークスペースのラインプロット設定を上書きします。ラインプロットをカスタマイズするには:
パネルの上にマウスをホバーさせ、ギアアイコンをクリックします。
表示されるモーダル内で、設定 を編集するタブを選択します。
適用 をクリックします。
ラインプロット設定
次の設定をラインプロットに設定できます:
データ : プロットのデータ表示の詳細を設定します。
X : X 軸に使用する値を選択します (デフォルトは Step です)。X 軸を 相対時間 に変更したり、W&B でログを取った値に基づいてカスタム軸を選択したりできます。
相対時間 (Wall) はプロセス開始以降の時計時間で、もし 1 日後に run を再開して何かをログした場合、それは 24 時間にプロットされます。相対時間 (プロセス) は実行中のプロセス内の時間で、もし 10 秒間 run を実行し、1 日後に再開した場合、そのポイントは 10 秒にプロットされます。ウォール時間 はグラフ上の最初の run 開始からの経過時間を示します。Step はデフォルトで wandb.log() が呼び出されるたびに増加し、モデルからログされたトレーニングステップの数を反映することになっています。
Y : メトリクスや時間経過とともに変化するハイパーパラメーターなど、ログに取られた値から1つ以上の y 軸を選択します。X軸 および Y軸 の最小値と最大値 (オプション)。ポイント集計メソッド . ランダムサンプリング (デフォルト) または フルフェデリティ 。詳細は サンプリング を参照。スムージング : ラインプロットのスムージングを変更します。デフォルトは 時間加重EMA です。その他の値には スムージングなし , ランニング平均 , および ガウシアン があります。外れ値 : 外れ値を除外して、デフォルトのプロット最小値および最大値スケールを再設定します。最大 run またはグループ数 : この数値を増やすことで、ラインプロットに一度により多くのラインを表示します。デフォルトは 10 run です。チャートの一番上に “最初の 10 run を表示中” というメッセージが表示され、利用可能な run が 10 個を超える場合、チャートが表示できる数を制約していることが分かります。チャートタイプ : ラインプロット、エリアプロット、および パーセンテージエリアプロットの中で切り替えます。
グルーピング : プロット内で run をどのようにグループ化し集計するかを設定します。
グループ化基準 : 列を選択し、その列に同じ値を持つすべての run がグループ化されます。Agg : 集計— グラフ上のラインの値です。オプションはグループの平均、中央値、最小、最大です。
チャート : パネル、X軸、Y軸のタイトルを指定し、凡例を表示または非表示に設定し、その位置を設定します。
凡例 : パネルの凡例の外観をカスタマイズします、もし有効化されている場合。
凡例 : プロットの各ラインに対する凡例のフィールド、それぞれのラインのプロット内の凡例。凡例テンプレート : テンプレートの上部に表示される凡例およびマウスオーバー時にプロットに表示される伝説で, 表示したい具体的なテキストおよび変数を定義します。
式 : パネルにカスタム計算式を追加します。
Y軸式 : グラフに計算されたメトリクスを追加。ログされたメトリクスやハイパーパラメーターのような設定値を使用してカスタムラインを計算することができます。X軸式 : 計算された値を使用して x 軸を再スケーリングします。有用な変数には、デフォルトの x 軸の step ${summary:value} です。
セクション内のすべてのラインプロット
ワークスペースの設定を上書きして、セクション内のすべてのラインプロットのデフォルトの設定をカスタマイズするには:
セクションのギアアイコンをクリックして設定を開きます。
表示されるモーダル内で、データ または 表示設定 タブを選択して、セクションのデフォルトの設定を構成します。各 データ 設定の詳細については、前述のセクション 個別のラインプロット を参照してください。各表示設定の詳細については、セクションレイアウトの構成 を参照してください。
ワークスペース内のすべてのラインプロット
ワークスペース内のすべてのラインプロットのデフォルト設定をカスタマイズするには:
設定 というラベルの付いたギアがあるワークスペースの設定をクリックします。ラインプロット をクリックします。表示されるモーダル内で、データ または 表示設定 タブを選択して、ワークスペースのデフォルト設定を構成します。
プロット上で平均値を可視化する
複数の異なる実験があり、その値の平均をプロットで見たい場合は、テーブルのグルーピング機能を使用できます。runテーブルの上部で “グループ化” をクリックし、“すべて” を選択してグラフに平均値を表示します。
以下は平均化する前のグラフの例です:
次の画像は、グループ化されたラインを使用して run における平均値を示すグラフです。
プロット上で NaN 値を可視化する
wandb.log を使用して、PyTorch テンソルを含む NaN 値をラインプロットでプロットすることもできます。例えば:
wandb. log({"test" : [... , float("nan" ), ... ]})
2 つのメトリクスを 1 つのチャートで比較する
ページの右上隅にある パネルを追加 ボタンを選択します。
表示される左側のパネルで評価のドロップダウンを展開します。
Run comparer を選択します。
ラインプロットの色を変更する
時々、run のデフォルトの色が比較には適していないことがあります。この問題を解決するために、wandb は手動で色を変更できる2つの方法を提供しています。
各 run は初期化時にデフォルトでランダムな色が割り当てられます。
どの色をクリックすると、手動で選択できるカラーパレットが表示されます。
設定を編集したいパネルにマウスをホバーさせます。
表示される鉛筆アイコンを選択します。
凡例 タブを選択します。
異なる x 軸で可視化する
実験がかかった絶対時間を見たい場合や、実験が実行された日を見たい場合は、x 軸を切り替えることができます。ここでは、ステップから相対時間、そして壁時間に切り替える例を示します。
エリアプロット
詳細設定タブでさまざまなプロットスタイルをクリックすると、エリアプロットまたはパーセンテージエリアプロットを取得できます。
ズーム
直線をクリックしてドラッグすると垂直および水平方向に同時にズームします。これにより、x軸とy軸のズームが変更されます。
チャートの凡例の非表示
この簡単なトグルでラインプロットの凡例をオフにできます:
2.4.1.1.1 - 折れ線グラフのリファレンス
X軸
折れ線グラフのX軸を、W&B.logで記録した任意の値に設定できます。ただし、それが常に数値として記録されている必要があります。
Y軸の変数
Y軸の変数は、wandb.logで記録した任意の値に設定できます。ただし、数値、数値の配列、または数値のヒストグラムを記録している必要があります。変数に対して1500点以上を記録した場合、W&Bは1500点にサンプリングします。
Y軸のラインの色は、runsテーブルでrunの色を変更することで変更できます。
X範囲とY範囲
プロットのXとYの最大値と最小値を変更できます。
X範囲のデフォルトは、X軸の最小値から最大値までです。
Y範囲のデフォルトは、メトリクスの最小値と0からメトリクスの最大値までです。
最大run/グループ数
デフォルトでは、10 runまたはrunのグループのみがプロットされます。runは、runsテーブルまたはrunセットの上位から取得されるため、runsテーブルやrunセットを並べ替えると、表示されるrunを変更できます。
凡例
チャートの凡例を制御して、任意のrunに対して記録した任意のconfig値やrunのメタデータ、例えば作成日時やrunを作成したユーザーを表示できます。
例:
${run:displayName} - ${config:dropout} は、各runの凡例名を royal-sweep - 0.5 のようにします。ここで royal-sweep はrun名で、0.5 は dropout という名前のconfigパラメータです。
グラフにカーソルを合わせたときにクロスヘアで特定の点の値を表示するために、[[ ]] 内に値を設定できます。例えば \[\[ $x: $y ($original) ]] は “2: 3 (2.9)” のように表示されます。
[[ ]] 内でサポートされる値は以下の通りです：
値
意味
${x}X値
${y}Y値（平滑化調整を含む）
${original}平滑化調整を含まないY値
${mean}グループ化されたrunの平均
${stddev}グループ化されたrunの標準偏差
${min}グループ化されたrunの最小値
${max}グループ化されたrunの最大値
${percent}全体のパーセント（積み上げ面チャート用）
グループ化
全てのrunをグループ化するか、個々の変数でグループをすることができます。また、テーブル内部でグループ化することによってグループを有効にすると、そのグループは自動的にグラフに反映されます。
スムージング
スムージング係数を0から1の間で設定できます。0はスムージングなし、1は最大スムージングを意味します。詳細はスムージング係数の設定について を参照してください。
外れ値を無視
デフォルトのプロットの最小値と最大値のスケールから外れ値を除外するようにプロットをリスケールします。この設定がプロットに与える影響は、プロットのサンプリングモードに依存します。
ランダムサンプリングモード を使用するプロットでは、外れ値を無視 を有効にすると、5%から95%の点のみが表示されます。外れ値が表示される場合、それらは他の点と異なるフォーマットでは表示されません。完全な忠実度モード を使用するプロットでは、全ての点が常に表示され、各バケットの最後の値まで凝縮されます。外れ値を無視 が有効になっている場合、各バケットの最小値と最大値の境界がシェーディングされます。それ以外の場合は、領域はシェーディングされません。
式の表現
式の表現を使用して、1-accuracyのようにメトリクスから派生した値をプロットできます。現在、単一のメトリクスをプロットしている場合にのみ機能します。+、-、*、/、%といった簡単な算術式、および**を使用してべき乗を行うことができます。
プロットスタイル
折れ線グラフのスタイルを選択します。
折れ線プロット：
面プロット：
パーセンテージエリアプロット：
2.4.1.1.2 - ポイント集約
Use point aggregation methods within your line plots for improved data visualization accuracy and performance. There are two types of point aggregation modes: full fidelity and random sampling . W&B uses full fidelity mode by default.
Full fidelity
Full fidelity modeを使用すると、W&Bはデータポイントの数に基づいてx軸を動的なバケットに分割します。そして、それぞれのバケット内の最小、最大、平均値を計算し、線プロットのポイント集約をレンダリングします。
フルフィデリティモードを使用する際のポイント集約の3つの主な利点は次のとおりです:
極値とスパイクを保持する: データ内の極値とスパイクを保持します。
最小値と最大値のレンダリングを設定する: W&Bアプリを使用して、極値（最小/最大）を影付きエリアとして表示するかどうかをインタラクティブに決定できます。
データの忠実度を失わずにデータを探索する: W&Bは特定のデータポイントにズームインするとx軸のバケットサイズを再計算します。これにより、正確さを失うことなくデータを探索できることを保証します。キャッシュを使用して以前に計算された集計を保存することで、ロード時間を短縮するのに役立ちます。これは、特に大規模なデータセットをナビゲートしている場合に便利です。
最小値と最大値のレンダリングの設定
線プロットの周囲に影付きのエリアを使って最小値と最大値を表示または非表示にします。
次の画像は、青い線プロットを示しています。薄い青の影付きエリアは各バケットの最小値と最大値を表しています。
線プロットで最小値と最大値をレンダリングする方法は3通りあります:
Never : 最小/最大値は影付きエリアとして表示されません。x軸のバケット全体に渡る集約された線だけを表示します。On hover : グラフにカーソルを合わせると、最小/最大値の影付きエリアが動的に表示されます。このオプションは、ビューをシンプルに保ちながら、範囲をインタラクティブに検査することを可能にします。Always : 最小/最大の影付きエリアは常にグラフのすべてのバケットで一貫して表示され、常に全範囲の値を視覚化するのに役立ちます。これにより、グラフに多くのrunsが視覚化されている場合、視覚的なノイズが発生する可能性があります。
デフォルトでは、最小値と最大値は影付きエリアとして表示されません。影付きエリアオプションの1つを表示するには、以下の手順に従ってください:
All charts in a workspace
Individual chart in a workspace
W&Bプロジェクトに移動します。
左のタブでWorkspace アイコンを選択します。
画面の右上隅にある歯車アイコンを、Add panels ボタンの左側に選択します。
表示されるUIスライダーからLine plots を選択します。
Point aggregation セクション内で、Show min/max values as a shaded area ドロップダウンメニューからOn hover またはAlways を選択します。
W&Bプロジェクトに移動します。
左のタブでWorkspace アイコンを選択します。
フルフィデリティモードを有効にしたい線プロットパネルを選択します。
表示されるモーダル内で、Show min/max values as a shaded area ドロップダウンメニューからOn hover またはAlways を選択します。
データの忠実度を失わずにデータを探索する
データセットの特定の領域を分析し、極値やスパイクなどの重要なポイントを見逃さないようにします。線プロットをズームインすると、W&Bは各バケット内の最小、最大、および平均値を計算するために使用されるバケットサイズを調整します。
W&Bはデフォルトでx軸を1000のバケットに動的に分割します。各バケットに対し、W&Bは以下の値を計算します:
Minimum : そのバケット内の最小値。Maximum : そのバケット内の最大値。Average : そのバケット内のすべてのポイントの平均値。
W&Bは、すべてのプロットでデータの完全な表現を保持し、極値を含める方法でバケット内の値をプロットします。1,000ポイント以下にズームインすると、フルフィデリティモードは追加の集約なしにすべてのデータポイントをレンダリングします。
線プロットをズームインするには、次の手順に従います:
W&Bプロジェクトに移動します。
左のタブでWorkspace アイコンを選択します。
必要に応じて、ワークスペースに線プロットパネルを追加するか、既存の線プロットパネルに移動します。
ズームインしたい特定の領域を選択するためにクリックしてドラッグします。
Line plot grouping and expressions Line Plot Groupingを使用すると、W&Bは選択されたモードに基づいて以下を適用します:
Non-windowed sampling (grouping) : x軸でrunsを超えてポイントを整列させます。複数のポイントが同じx値を共有する場合、平均が取られ、そうでない場合は離散的なポイントとして表示されます。Windowed sampling (grouping and expressions) : x軸を250のバケットまたは最も長い線のポイント数に分割します（いずれか小さい方）。W&Bは各バケット内のポイントの平均を取ります。Full fidelity (grouping and expressions) : 非ウィンドウ化サンプリングに似ていますが、パフォーマンスと詳細のバランスを取るためにrunごとに最大500ポイントを取得します。 Random sampling
Random samplingはラインプロットをレンダリングするために1,500のランダムにサンプリングされたポイントを使用します。大量のデータポイントがある場合、パフォーマンスの理由でランダムサンプリングが有用です。
Random samplingは非決定的にサンプリングします。これは、ランダムサンプリングが時々データ内の重要なアウトライヤーやスパイクを除外し、したがってデータの正確性を低下させることを意味します。
ランダムサンプリングを有効にする
デフォルトでは、W&Bはフルフィデリティモードを使用します。ランダムサンプリングを有効にするには、次の手順に従います:
All charts in a workspace
Individual chart in a workspace
W&Bプロジェクトに移動します。
左のタブでWorkspace アイコンを選択します。
画面の右上隅にある歯車アイコンを、Add panels ボタンの左側に選択します。
表示されるUIスライダーからLine plots を選択します。
Point aggregation セクションからRandom sampling を選択します。
W&Bプロジェクトに移動します。
左のタブでWorkspace アイコンを選択します。
ランダムサンプリングを有効にしたい線プロットパネルを選択します。
表示されるモーダル内で、Point aggregation method セクションからRandom sampling を選択します。
サンプリングされていないデータへのアクセス
W&B Run API を使用して、run中にログされたメトリクスの完全な履歴にアクセスできます。次の例は、特定のrunから損失値を取得し処理する方法を示しています:
# W&B APIを初期化
run = api. run("l2k2/examples-numpy-boston/i0wt6xua" )
# 'Loss'メトリクスの履歴を取得
history = run. scan_history(keys= ["Loss" ])
# 履歴から損失値を抽出
losses = [row["Loss" ] for row in history]
2.4.1.1.3 - スムーズなラインプロット
ノイズの多いデータにおけるトレンドを見るために、線グラフでスムージングを使用します。
W&B は 3 つのタイプの平滑化をサポートしています:
これらが インタラクティブな W&B レポート でどのように動作するかをご覧ください。
指数移動平均 (デフォルト)
指数平滑化は、時系列データを指数的に減衰させることで、過去のデータポイントの重みを滑らかにする手法です。範囲は 0 から 1 です。背景については 指数平滑化 をご覧ください。時系列の初期値がゼロに偏らないようにするためのデバイアス項が追加されています。
EMA アルゴリズムは、線上の点の密度（x 軸範囲の単位当たりの y 値の数）を考慮に入れます。これにより、異なる特性を持つ複数の線を同時に表示する際に、一貫した平滑化が可能になります。
これが内部でどのように動作するかのサンプルコードです:
const smoothingWeight = Math.min (Math.sqrt (smoothingParam || 0 ), 0.999 );
let lastY = yValues .length > 0 ? 0 : NaN ;
let debiasWeight = 0 ;
return yValues .map ((yPoint , index ) => {
const prevX = index > 0 ? index - 1 : 0 ;
// VIEWPORT_SCALE は結果をチャートの x 軸範囲にスケーリングします
const changeInX =
((xValues [index ] - xValues [prevX ]) / rangeOfX ) * VIEWPORT_SCALE ;
const smoothingWeightAdj = Math.pow (smoothingWeight , changeInX );
lastY = lastY * smoothingWeightAdj + yPoint ;
debiasWeight = debiasWeight * smoothingWeightAdj + 1 ;
return lastY / debiasWeight ;
});
これがアプリ内でどのように見えるかはこちらをご覧ください in the app :
ガウス平滑化
ガウス平滑化（またはガウスカーネル平滑化）は、標準偏差が平滑化パラメータとして指定されるガウス分布に対応する重みを用いてポイントの加重平均を計算します。入力 x 値ごとに平滑化された値が計算されます。
ガウス平滑化は、TensorBoard の振る舞いと一致させる必要がない場合の標準的な選択肢です。指数移動平均とは異なり、ポイントは前後の値に基づいて平滑化されます。
これがアプリ内でどのように見えるかはこちらをご覧ください in the app :
移動平均
移動平均は、与えられた x 値の前後のウィンドウ内のポイントの平均でそのポイントを置き換える平滑化アルゴリズムです。詳細は “Boxcar Filter” を参照してください https://en.wikipedia.org/wiki/Moving_average 。移動平均のために選択されたパラメータは、Weights and Biases に移動平均で考慮するポイントの数を伝えます。
ポイントが x 軸上で不均一に配置されている場合は、ガウス平滑化を検討してください。
次の画像は、アプリ内での移動アプリの表示例を示しています in the app :
指数移動平均 (非推奨)
TensorBoard EMA アルゴリズムは、同じチャート上で一貫したポイント密度を持たない複数の線を正確に平滑化することができないため、非推奨とされました。
指数移動平均は、TensorBoard の平滑化アルゴリズムと一致するように実装されています。範囲は 0 から 1 です。背景については 指数平滑化 をご覧ください。時系列の初期値がゼロに偏らないようにするためのデバイアス項が追加されています。
これが内部でどのように動作するかのサンプルコードです:
data .forEach (d => {
const nextVal = d ;
last = last * smoothingWeight + (1 - smoothingWeight ) * nextVal ;
numAccum ++ ;
debiasWeight = 1.0 - Math.pow (smoothingWeight , numAccum );
smoothedData .push (last / debiasWeight );
これがアプリ内でどのように見えるかはこちらをご覧ください in the app :
実装の詳細
すべての平滑化アルゴリズムはサンプリングされたデータで実行されます。つまり、1500 ポイント以上をログに記録した場合、平滑化アルゴリズムはサーバーからポイントがダウンロードされた後に実行されます。平滑化アルゴリズムの目的は、データ内のパターンを迅速に見つけることです。多くのログを持つメトリクスに対して正確な平滑化された値が必要な場合は、API を介してメトリクスをダウンロードし、自分自身の平滑化メソッドを実行する方が良いかもしれません。
元のデータを非表示にする
デフォルトでは、オリジナルの非平滑化データを背景として薄い線で表示します。この表示をオフにするには、Show Original トグルをクリックしてください。
2.4.1.2 - 棒グラフ
メトリクスを可視化し、軸をカスタマイズし、カテゴリー データをバーとして比較します。
棒グラフは、矩形のバーでカテゴリカルデータを表示し、縦または横にプロットできます。全てのログされた値が長さ1の場合、wandb.log() を使用するとデフォルトで棒グラフが表示されます。
チャートの設定をカスタマイズして、表示する run の最大数を制限したり、任意の設定で run をグループ化したり、ラベルの名前を変更したりできます。
棒グラフのカスタマイズ
Box または Violin プロットを作成して、多くの要約統計量を1つのチャートタイプに組み合わせることもできます。
run テーブルで run をグループ化します。
ワークスペースで ‘Add panel’ をクリックします。
標準の ‘Bar Chart’ を追加し、プロットする指標を選択します。
‘Grouping’ タブの下で ‘box plot’ や ‘Violin’ などを選択して、これらのスタイルのいずれかをプロットします。
2.4.1.3 - 並列座標
機械学習実験間で結果を比較する
大規模なハイパーパラメーターとモデルメトリクスの関係を一目で要約できるのがパラレル座標チャートです。
軸 : wandb.configwandb.logライン : 各ラインは単一の run を表します。ラインにマウスを合わせると、その run の詳細がツールチップで表示されます。現在のフィルターに一致するすべてのラインが表示されますが、目をオフにすると、ラインはグレー表示されます。
パラレル座標パネルを作成する
ワークスペースのランディングページへ移動
Add Panels をクリックParallel coordinates を選択
パネル設定
パネルを設定するには、パネルの右上にある編集ボタンをクリックします。
ツールチップ : ホバーすると、各 run の情報が表示されますタイトル : 軸のタイトルを編集して、より読みやすくします勾配 : グラデーションを好きな色の範囲にカスタマイズログスケール : 各軸は個別にログスケールで表示するように設定できます軸の反転 : 軸の方向を切り替え—正確性と損失を両方持つカラムがあるときに便利です
ライブのパラレル座標パネルと対話する
2.4.1.4 - 散布図
このページでは、W&B で散布図を使用する方法を示します。
ユースケース
散布図を使用して、複数の runs を比較し、実験のパフォーマンスを視覚化します。
最小値、最大値、および平均値のプロットラインを表示する。
メタデータのツールチップをカスタマイズする。
ポイントの色を制御する。
軸の範囲を調整する。
軸に対して対数スケールを使用する。
例
次の例では、異なるモデルの数週間にわたる実験による検証精度を表示する散布図を示しています。ツールチップには、バッチサイズ、ドロップアウト、および軸の値が含まれています。また、検証精度のランニング平均を示す線も表示されます。
ライブ例を見る →
散布図を作成する
W&B UI で散布図を作成するには：
Workspaces タブに移動します。Charts パネルで、アクションメニュー ... をクリックします。ポップアップメニューから、Add panels を選択します。
Add panels メニューで、Scatter plot を選択します。プロットしたいデータを表示するために x および y 軸を設定します。必要に応じて、軸の最大および最小範囲を設定するか、z 軸を追加してください。
Apply をクリックして散布図を作成します。新しい散布図を Charts パネルで確認します。
2.4.1.5 - コードを保存して差分を取る
デフォルトでは、W&Bは最新のgitコミットハッシュのみを保存します。UIで実験間のコードを動的に比較するためのより多くのコード機能を有効にできます。
wandb バージョン 0.8.28 から、W&Bは wandb.init() を呼び出すメインのトレーニングファイルからコードを保存することができます。
ライブラリコードを保存する
コード保存を有効にすると、W&Bは wandb.init() を呼び出したファイルからコードを保存します。追加のライブラリコードを保存するには、以下の3つのオプションがあります:
wandb.init を呼び出した後に wandb.run.log_code(".") を呼び出すimport wandb
wandb. init()
wandb. run. log_code("." )
code_dir を設定して wandb.init に設定オブジェクトを渡すimport wandb
wandb. init(settings= wandb. Settings(code_dir= "." ))
これにより、現在のディレクトリーおよびすべてのサブディレクトリー内のPythonソースコードファイルがアーティファクト としてキャプチャされます。保存されるソースコードファイルの種類と場所をより詳細に制御するには、リファレンスドキュメント を参照してください。
UIでコード保存を設定する
コード保存をプログラム的に設定する以外に、W&Bアカウントの設定でこの機能を切り替えることもできます。これを有効にすると、アカウントに関連付けられているすべてのチームでコード保存が有効になります。
デフォルトでは、W&Bはすべてのチームでコード保存を無効にします。
W&Bアカウントにログインします。
設定 > プライバシー に移動します。プロジェクトとコンテンツのセキュリティ の下で、デフォルトのコード保存を無効にする をオンにします。
コードコンペアラー
異なるW&B runで使用されたコードを比較する:
ページの右上隅にある パネルを追加 ボタンを選択します。
TEXT AND CODE ドロップダウンを展開し、コード を選択します。
Jupyterセッション履歴
W&BはJupyterノートブックセッションで実行されたコードの履歴を保存します。Jupyter内でwandb.init() を呼び出すと、W&Bは現在のセッションで実行されたコードの履歴を含むJupyterノートブックを自動的に保存するフックを追加します。
コードが含まれているプロジェクトワークスペースに移動します。
左ナビゲーションバーのArtifacts タブを選択します。
コード アーティファクトを展開します。ファイル タブを選択します。
これは、セッションで実行されたセルと、iPythonの表示メソッドを呼び出して作成された出力を表示します。これにより、指定されたrunのJupyter内でどのコードが実行されたかを正確に確認することができます。可能な場合、W&Bはノートブックの最新バージョンも保存し、コードディレクトリー内で見つけることができます。
2.4.1.6 - パラメータの重要度
モデルのハイパーパラメーターと出力メトリクスの関係を視覚化する
ハイパーパラメーターがどのようにメトリクスの望ましい値の予測に役立ったか、また高い相関があったかを発見しましょう。
相関 とは、ハイパーパラメーターと選択されたメトリクスの線形相関を意味します（この場合は val_loss）。したがって、高い相関はハイパーパラメーターの値が高いとき、メトリクスの値も高くなり、その逆もまた然りであることを示します。相関は注目すべき素晴らしいメトリクスですが、入力間の二次の相互作用を捉えることはできず、非常に異なる範囲の入力を比較することが煩雑になる可能性があります。
そのため、W&Bは 重要度 メトリクスも計算します。W&Bはハイパーパラメーターを入力として、ランダムフォレストをトレーニングし、メトリクスをターゲット出力として、ランダムフォレストの特徴重要度値をレポートします。
この手法のアイデアは、Jeremy Howard との会話からインスピレーションを受け、Fast.aiにおいてハイパーパラメータースペースを探るためのランダムフォレストの特徴重要度の使用を推進してきたことから生まれました。W&Bはこの分析の背後にある動機を学ぶために、この講義 （およびこれらのノート ）をチェックすることを強くお勧めします。
ハイパーパラメーター重要度パネルは、高い相関のハイパーパラメーター間の複雑な相互作用を解きほぐします。そして、モデルのパフォーマンスを予測する上で、どのハイパーパラメーターが最も重要であるかを示すことによって、ハイパーパラメーターの探索を調整するのに役立ちます。
ハイパーパラメーター重要度パネルの作成
W&B プロジェクトに移動します。
Add panels ボタンを選択します。CHARTS ドロップダウンを展開し、ドロップダウンから Parallel coordinates を選択します。
空のパネルが表示される場合、run がグループ化されていないことを確認してください
パラメーターマネージャーを使用して、表示および非表示のパラメーターを手動で設定できます。
ハイパーパラメーター重要度パネルの解釈
このパネルは、トレーニングスクリプト内で wandb.config オブジェクトに渡されたすべてのパラメーターを表示します。次に、これらのconfigパラメーターの特徴重要度と、それが選択されたモデルメトリクス（この場合は val_loss）との相関を示します。
重要度
重要度列は、選択したメトリクスを予測する際に、各ハイパーパラメーターがどの程度役立ったかを示します。多数のハイパーパラメーターを調整し始めて、それらの中からさらなる探索の価値があるものを特定するためにこのプロットを使用するシナリオを想像してみてください。その後の Sweeps は、最も重要なハイパーパラメーターに限定し、より良いモデルをより速く、安価に見つけることができます。
W&Bは、木構造モデルを使用して重要度を計算します。木構造モデルは、線形モデルと比べてカテゴリカルデータや正規化されていないデータに対してより寛容です。
上記の画像では、epochs, learning_rate, batch_size と weight_decay がかなり重要であることがわかります。
相関
相関は、個々のハイパーパラメーターとメトリクスの値との間の線形関係を捉えます。これにより、SGDオプティマイザーなどのハイパーパラメーターの使用と val_loss 間に有意な関係があるかどうかという問題に答えます（この場合、答えは「はい」です）。相関値は-1から1の範囲であり、正の値は正の線形相関を、負の値は負の線形相関を示し、0の値は相関がないことを示します。一般的に、どちらの方向でも0.7を超える値は強い相関を示します。
このグラフを使用して、メトリクスと高い相関のある値（この場合は確率的勾配降下法やadamを選択し、rmspropやnadamよりも優先することがあります）をさらに調査したり、より多くのエポックでトレーニングしたりすることができます。
相関は関連の証拠を示しますが、必ずしも因果関係を示すわけではありません。
相関は外れ値に敏感であり、特に試されたハイパーパラメーターのサンプルサイズが小さい場合は、強い関係を中程度のものに変える可能性があります。
最後に、相関はハイパーパラメーターとメトリクス間の線形関係のみを捉えます。強い多項式関係がある場合、相関ではそれを捉えられません。
重要度と相関の違いは、重要度がハイパーパラメーター間の相互作用を考慮に入れる一方で、相関は個々のハイパーパラメーターがメトリクスに与える影響のみを測定するという事実から生じます。第二に、相関は線形関係のみを捉えるのに対し、重要度はより複雑な関係を捉えることができます。
見てわかるように、重要度と相関はどちらもハイパーパラメーターがモデルのパフォーマンスにどのように影響するかを理解するための強力なツールです。
2.4.1.7 - run メトリクスを比較する
複数の run 間でメトリクスを比較する
Run Comparer を使用して、異なる run 間でメトリクスがどのように異なるかを確認します。
ページの右上にある Add panels ボタンを選択します。
表示される左側のパネルから Evaluation ドロップダウンを展開します。
Run comparer を選択します。
diff only オプションを切り替えて、 run 間で値が同じ行を非表示にします。
2.4.1.8 - クエリパネル
このページの一部の機能はベータ版であり、機能フラグの後ろに隠れています。関連するすべての機能をアンロックするには、プロフィールページの自己紹介に weave-plot を追加してください。
W&B Weaveをお探しですか？W&Bの生成AIアプリケーション構築のためのツール群ですか？weaveのドキュメントはここで見つけることができます:
wandb.me/weave .
クエリパネルを使用してデータをクエリし、インタラクティブに視覚化します。
クエリパネルを作成する
ワークスペースまたはレポート内にクエリを追加します。
Project workspace
W&B Report
プロジェクトのワークスペースに移動します。
右上のコーナーにある Add panel をクリックします。
ドロップダウンから Query panel を選択します。
/Query panel と入力して選択します。
または、一連の Runs とクエリを関連付けることができます。
レポート内で、/Panel grid と入力して選択します。
Add panel ボタンをクリックします。ドロップダウンから Query panel を選択します。
クエリコンポーネント
式
クエリ式を使用して、W&Bに保存されたデータ、例えば Runs、Artifacts、Models、Tables などをクエリします。
例: テーブルをクエリする
W&B Tableをクエリしたいとします。トレーニングコード内で "cifar10_sample_table" という名前のテーブルをログします:
import wandb
wandb. log({"cifar10_sample_table" :< MY_TABLE> })
クエリパネル内でテーブルをクエリするには次のようにします:
runs. summary["cifar10_sample_table" ]
これを分解すると:
runs は、ワークスペースに Query Panel があるときに自動的に Query Panel Expressions に注入される変数です。その値は、その特定のワークスペースに表示される Runs のリストです。Run内の利用可能な異なる属性についてはこちらをお読みください 。summary は、Run の Summary オブジェクトを返す操作です。Opsは マップされる ため、この操作はリスト内の各 Run に適用され、その結果として Summary オブジェクトのリストが生成されます。["cifar10_sample_table"] は Pick 操作（角括弧で示され）、predictions というパラメータを持ちます。Summary オブジェクトは辞書またはマップのように動作するため、この操作は各 Summary オブジェクトから predictions フィールドを選択します。
インタラクティブに独自のクエリの書き方を学ぶには、こちらのレポート を参照してください。
設定
パネルの左上コーナーにあるギアアイコンを選択してクエリ設定を展開します。これにより、ユーザーはパネルのタイプと結果パネルのパラメータを設定できます。
結果パネル
最後に、クエリ結果パネルは、選択したクエリパネル、設定によって設定された構成に基づいて、データをインタラクティブに表示する形式でクエリ式の結果をレンダリングします。次の画像は、同じデータのテーブルとプロットを示しています。
基本操作
次に、クエリパネル内で行える一般的な操作を示します。
ソート
列オプションからソートします:
フィルター
クエリ内で直接、または左上隅のフィルターボタンを使用してフィルターできます（2枚目の画像）。
マップ
マップ操作はリストを反復し、データ内の各要素に関数を適用します。これは、パネルクエリを使用して直接行うことも、列オプションから新しい列を挿入することによって行うこともできます。
グループ化
クエリを使用してまたは列オプションからグループ化できます。
連結
連結操作により、2つのテーブルを連結し、パネル設定から連結または結合できます。
結合
クエリ内でテーブルを直接結合することも可能です。次のクエリ式を考えてみてください:
project("luis_team_test" , "weave_example_queries" ). runs. summary["short_table_0" ]. table. rows. concat. join(\
project("luis_team_test" , "weave_example_queries" ). runs. summary["short_table_1" ]. table. rows. concat,\
(row) => row["Label" ],(row) => row["Label" ], "Table1" , "Table2" ,\
"false" , "false" )
左のテーブルは次のように生成されます:
project("luis_team_test" , "weave_example_queries" ). \
runs. summary["short_table_0" ]. table. rows. concat. join
右のテーブルは次のように生成されます:
project("luis_team_test" , "weave_example_queries" ). \
runs. summary["short_table_1" ]. table. rows. concat
ここで:
(row) => row["Label"] は各テーブルのセレクタであり、結合する列を決定します"Table1" と "Table2" は、結合された各テーブルの名前ですtrue と false は、左および右の内/外部結合設定です
Runsオブジェクト
クエリパネルを使用して runs オブジェクトにアクセスします。Runオブジェクトは、実験の記録を保存します。詳細については、こちらのレポート のセクションを参照してくださいが、簡単な概要として、runs オブジェクトには以下が含まれます:
summary: Runの結果を要約する情報の辞書です。精度や損失のようなスカラーや、大きなファイルを含むことができます。デフォルトでは、wandb.log()は記録された時系列の最終的な値をsummaryに設定します。直接summaryの内容を設定することもできます。summaryはRunの出力と考えてください。history: モデルがトレーニング中に変化する値を格納するための辞書のリストです。コマンド wandb.log() はこのオブジェクトに追加します。config: Runの設定情報を含む辞書で、トレーニングランのハイパーパラメーターやデータセットアーティファクトを作成するランの前処理方法などが含まれます。これらはRunの「入力」として考えてください。
Artifactsにアクセスする
Artifacts は W&B の中核概念です。これは、バージョン管理された名前付きファイルやディレクトリーのコレクションです。Artifacts を使用して、モデルの重み、データセット、およびその他のファイルやディレクトリーを追跡します。Artifacts は W&B に保存され、他の runs でダウンロードまたは使用できます。詳細と例は、こちらのセクション のレポートで確認できます。Artifacts は通常、project オブジェクトからアクセスします:
project.artifactVersion(): プロジェクト内の特定の名前とバージョンのアーティファクトバージョンを返しますproject.artifact(""): プロジェクト内の特定の名前のアーティファクトを返します。その後、.versions を使用してこのアーティファクトのすべてのバージョンのリストを取得できますproject.artifactType(): プロジェクト内の特定の名前の artifactType を返します。その後、.artifacts を使用して、このタイプを持つすべてのアーティファクトのリストを取得できますproject.artifactTypes: プロジェクト内のすべてのアーティファクトタイプのリストを返します
2.4.1.8.1 - オブジェクトを埋め込む
W&B の Embedding Projector を使用すると、ユーザー は PCA、UMAP、t-SNE などの一般的な次元削減アルゴリズムを用いて多次元埋め込みを 2D 平面上にプロットできます。
Embeddings はオブジェクト（人物、画像、投稿、単語など）を数字のリストで表現するために使用されます。これを ベクトル と呼ぶこともあります。機械学習やデータサイエンスのユースケースでは、Embeddings は様々な手法を用いて生成でき、幅広いアプリケーションで利用されます。このページでは、読者が Embeddings に精通しており、W&B 内でそれらを視覚的に分析することに関心があることを前提としています。
Embedding の例
ハローワールド
W&B を使用すると、wandb.Table クラスを使用して Embeddings をログできます。以下は、5 次元からなる 3 つの Embeddings の例です。
import wandb
wandb. init(project= "embedding_tutorial" )
embeddings = [
# D1 D2 D3 D4 D5
[0.2 , 0.4 , 0.1 , 0.7 , 0.5 ], # embedding 1
[0.3 , 0.1 , 0.9 , 0.2 , 0.7 ], # embedding 2
[0.4 , 0.5 , 0.2 , 0.2 , 0.1 ], # embedding 3
]
wandb. log(
{"embeddings" : wandb. Table(columns= ["D1" , "D2" , "D3" , "D4" , "D5" ], data= embeddings)}
)
wandb. finish()
上記のコードを実行すると、W&B ダッシュボードにデータを含む新しいテーブルが作成されます。右上のパネルセレクタから 2D Projection を選択して Embeddings を 2 次元でプロットすることができます。デフォルトで賢明な設定が自動的に選択されますが、設定メニューから簡単に上書きできます。この例では、利用可能な 5 つの数値次元をすべて自動的に使用しています。
数字のMNIST
上記の例では Embeddings の基本的なログ方法を示しましたが、通常はもっと多くの次元とサンプルを扱います。UCI の手書き数字データセット UCI ML hand-written digits dataset を使って、SciKit-Learn を通じて提供される MNIST 数字データセットを考えてみましょう。このデータセットには 64 次元を持つ 1797 のレコードが含まれています。この問題は10クラスの分類ユースケースです。また、可視化のために入力データを画像に変換することもできます。
import wandb
from sklearn.datasets import load_digits
wandb. init(project= "embedding_tutorial" )
# データセットをロードする
ds = load_digits(as_frame= True )
df = ds. data
# "target" カラムを作成する
df["target" ] = ds. target. astype(str)
cols = df. columns. tolist()
df = df[cols[- 1 :] + cols[:- 1 ]]
# "image" カラムを作成する
df["image" ] = df. apply(
lambda row: wandb. Image(row[1 :]. values. reshape(8 , 8 ) / 16.0 ), axis= 1
)
cols = df. columns. tolist()
df = df[cols[- 1 :] + cols[:- 1 ]]
wandb. log({"digits" : df})
wandb. finish()
上記のコードを実行した後、再び UI にテーブルが表示されます。 2D Projection を選択することで、Embedding の定義、色付け、アルゴリズム（PCA, UMAP, t-SNE）、アルゴリズムのパラメータ、さらにはオーバーレイ（この場合、点の上にマウスを置くと画像が表示されます）の設定を行うことができます。この特定のケースでは、すべて「スマートデフォルト」が設定されており、2D Projection をクリックするだけで非常に類似したものが見えるはずです。(この例を試してみてください )。
ログオプション
Embeddings はさまざまなフォーマットでログすることができます:
単一の埋め込みカラム: データがすでに「行列」形式になっていることが多いです。この場合、カラムのデータ型は list[int], list[float], または np.ndarray にすることができます。複数の数値カラム: 上記の2つの例では、各次元に対してカラムを作成するこの方法を使用します。現在、セルには Python の int または float が受け入れられます。
さらに、他のすべてのテーブルと同様に、テーブルを構築する方法について多くのオプションがあります:
データフレーム から直接 wandb.Table(dataframe=df) を使用してデータのリスト から直接 wandb.Table(data=[...], columns=[...]) を使用して行単位で段階的に テーブルを構築する（コード内にループがある場合に最適）。table.add_data(...) を使ってテーブルに行を追加します。テーブルに 埋め込みカラム を追加する（Embedding の形式で予測のリストがある場合に最適）: table.add_col("col_name", ...)
計算済みカラム を追加する（関数やモデルをテーブル全体に適用したい場合に最適）: table.add_computed_columns(lambda row, ndx: {"embedding": model.predict(row)})
プロットオプション
2D Projection を選択した後、ギアアイコンをクリックしてレンダリング設定を編集できます。上記のカラムの選択に加えて、興味のあるアルゴリズム（および必要なパラメータ）を選ぶことができます。以下に、UMAP と t-SNE の各パラメータが表示されています。
注: 現在、すべての 3 つのアルゴリズムに対して、ランダムなサブセット 1000 行と 50 次元にダウンサンプリングされます。
2.4.2 - カスタムチャート
W&Bプロジェクトでカスタムチャートを作成しましょう。任意のデータテーブルをログし、自由に可視化できます。フォント、色、ツールチップの詳細をVega の力でコントロールしましょう。
仕組み
データをログする : スクリプトから、config とサマリーデータをログします。チャートをカスタマイズする : GraphQL クエリを使ってログされたデータを呼び出します。Vega 、強力な可視化文法でクエリの結果を可視化します。チャートをログする : あなた自身のプリセットをスクリプトからwandb.plot_table()で呼び出します。
期待したデータが表示されない場合、選択した Runs に求めている列がログされていない可能性があります。チャートを保存し、Runsテーブルに戻って、選択した Runs を目のアイコン で確認してください。
スクリプトからチャートをログする
組み込みプリセット
W&Bにはスクリプトから直接ログできるいくつかの組み込みチャートプリセットがあります。これらには、ラインプロット、スキャッタープロット、バーチャート、ヒストグラム、PR曲線、ROC曲線が含まれます。
Line plot
Scatter plot
Bar chart
Histogram
PR curve
ROC curve
wandb.plot.line()
カスタムラインプロットをログします — 任意の軸xとy上の接続され順序付けされた点（x,y）のリストです。
data = [[x, y] for (x, y) in zip(x_values, y_values)]
table = wandb. Table(data= data, columns= ["x" , "y" ])
wandb. log(
{
"my_custom_plot_id" : wandb. plot. line(
table, "x" , "y" , title= "Custom Y vs X Line Plot"
)
}
)
ラインプロットは任意の2次元上に曲線をログします。もし2つのlistの値を互いにプロットする場合、listの値の数が完全に一致している必要があります（例えば、各点はxとyを持たなければなりません）。
例のレポートを確認 するか、例のGoogle Colabノートブックを試す ことができます。
wandb.plot.scatter()
カスタムスキャッタープロットをログします — 任意の軸xとy上の点（x, y）のリストです。
data = [[x, y] for (x, y) in zip(class_x_prediction_scores, class_y_prediction_scores)]
table = wandb. Table(data= data, columns= ["class_x" , "class_y" ])
wandb. log({"my_custom_id" : wandb. plot. scatter(table, "class_x" , "class_y" )})
任意の2次元上にスキャッターポイントをログするためにこれを使うことができます。もし2つのlistの値を互いにプロットする場合、listの値の数が完全に一致している必要があります（例えば、各点はxとyを持たなければなりません）。
例のレポートを確認 するか、例のGoogle Colabノートブックを試す ことができます。
wandb.plot.bar()
カスタムバーチャートをログします — ラベル付き値のリストをバーとして表示する — 数行でネイティブに:
data = [[label, val] for (label, val) in zip(labels, values)]
table = wandb. Table(data= data, columns= ["label" , "value" ])
wandb. log(
{
"my_bar_chart_id" : wandb. plot. bar(
table, "label" , "value" , title= "Custom Bar Chart"
)
}
)
任意のバーチャートをログするためにこれを使用することができます。list内のラベルと値の数は完全に一致している必要があります（例えば、各データポイントが両方を持つ必要があります）。
例のレポートを確認 するか、例のGoogle Colabノートブックを試す ことができます。
wandb.plot.histogram()
カスタムヒストグラムをログします — いくつかの行で値をカウントまたは出現頻度によってビンにソートします。予測信頼度スコア（scores）のリストがあるとしましょう。それらの分布を可視化したいとします。
data = [[s] for s in scores]
table = wandb. Table(data= data, columns= ["scores" ])
wandb. log({"my_histogram" : wandb. plot. histogram(table, "scores" , title= None )})
任意のヒストグラムをログするためにこれを使用することができます。注意として、 data は list of lists であり、2次元配列の行と列をサポートすることを意図しています。
例のレポートを確認 するか、例のGoogle Colabノートブックを試す ことができます。
wandb.plot.pr_curve()
Precision-Recall curve を1行で作成します。
plot = wandb. plot. pr_curve(ground_truth, predictions, labels= None , classes_to_plot= None )
wandb. log({"pr" : plot})
コードが次にアクセス可能なときにこれをログできます:
モデルの予測スコア (predictions) の一群の例
それらの例の対応する正解ラベル (ground_truth)
（オプション）ラベルまたはクラス名のリスト (labels=["cat", "dog", "bird"...] ラベルインデックス0はcat、1番目はdog、2番目はbird…)
（オプション）プロットに可視化するラベルのサブセット（リスト形式のまま）
例のレポートを確認 するか、例のGoogle Colabノートブックを試す ことができます。
wandb.plot.roc_curve()
ROC curve を1行で作成します。
plot = wandb. plot. roc_curve(
ground_truth, predictions, labels= None , classes_to_plot= None
)
wandb. log({"roc" : plot})
コードが次にアクセス可能なときにこれをログできます:
モデルの予測スコア (predictions) の一群の例
それらの例の対応する正解ラベル (ground_truth)
（オプション）ラベルまたはクラス名のリスト (labels=["cat", "dog", "bird"...] ラベルインデックス0はcat、1番目はdog、2番目はbird…)
（オプション）このプロットに可視化するラベルのサブセット（リスト形式のまま）
例のレポートを確認 するか、例のGoogle Colabノートブックを試す ことができます。
カスタムプリセット
組み込みプリセットを調整するか新しいプリセットを作成し、チャートを保存します。チャートIDを使ってそのカスタムプリセットに直接スクリプトからデータをログします。例のGoogle Colabノートブックを試す 。
# プロットする列を持つテーブルを作成します
table = wandb. Table(data= data, columns= ["step" , "height" ])
# テーブルの列からチャートのフィールドへのマッピング
fields = {"x" : "step" , "value" : "height" }
# 新しいカスタムチャートプリセットを埋めるためにテーブルを使用
# 保存した自身のチャートプリセットを使用するには、vega_spec_nameを変更します
my_custom_chart = wandb. plot_table(
vega_spec_name= "carey/new_chart" ,
data_table= table,
fields= fields,
)
データをログする
スクリプトから次のデータタイプをログし、カスタムチャートで使用できます。
Config : 実験の初期設定（独立変数）。これは実験の開始時に wandb.config にキーとしてログされた名前付きフィールドを含みます。例えば: wandb.config.learning_rate = 0.0001Summary : トレーニング中にログされた単一の値（結果や従属変数）。例えば、wandb.log({"val_acc" : 0.8})。トレーニング中に wandb.log() を使用してキーに複数回書き込んだ場合、サマリーはそのキーの最終的な値に設定されます。History : ログされたスカラーの時系列全体は、history フィールドを通じてクエリに利用可能です。summaryTable : 複数の値のリストをログする必要がある場合、wandb.Table() を使用してそのデータを保存し、それをカスタムパネルでクエリします。historyTable : 履歴データを確認したい場合、カスタムチャートパネルで historyTable をクエリします。 wandb.Table() の呼び出しごとまたはカスタムチャートのログごとに、そのステップにおける履歴に新しいテーブルが作成されます。
カスタムテーブルをログする方法
wandb.Table() を使ってデータを2次元配列としてログします。一般的にこのテーブルの各行は一つのデータポイントを表し、各列はプロットしたい各データポイントの関連フィールド/次元を示しています。カスタムパネルを設定する際、 wandb.log() に渡された名前付きキー（以下の custom_data_table）を通じてテーブル全体にアクセスでき、個別のフィールドには列の名前（x, y, z）を通じてアクセスできます。実験のさまざまなタイムステップでテーブルをログすることができます。各テーブルの最大サイズは10,000行です。例のGoogle Colabを試す 。
# データのカスタムテーブルをログする
my_custom_data = [[x1, y1, z1], [x2, y2, z2]]
wandb. log(
{"custom_data_table" : wandb. Table(data= my_custom_data, columns= ["x" , "y" , "z" ])}
)
チャートをカスタマイズする
新しいカスタムチャートを追加して開始し、次にクエリを編集して表示可能な Runs からデータを選択します。クエリはGraphQL を使用して、実行での設定、サマリー、履歴フィールドからデータを取得します。
カスタム可視化
右上のChart を選択してデフォルトプリセットから始めましょう。次に、Chart fields を選択してクエリから引き出したデータをチャートの対応するフィールドにマッピングします。
次の画像は、メトリックをどのように選択し、それを下のバーチャートフィールドにマッピングするかの一例を示しています。
Vegaを編集する方法
パネルの上部にあるEdit をクリックしてVega 編集モードに入ります。ここでは、Vega仕様 を定義して、UIでインタラクティブなチャートを作成することができます。チャートの任意の面を変更できます。例えば、タイトルを変更したり、異なるカラー スキームを選択したり、曲線を接続された線ではなく一連の点として表示したりできます。また、Vega変換を使用して値の配列をヒストグラムにビン分けするなど、データ自体にも変更を加えることができます。パネルプレビューはインタラクティブに更新されるため、Vega仕様やクエリを編集している間に変更の効果を確認できます。Vegaのドキュメントとチュートリアルを参照してください 。
フィールド参照
W&Bからチャートにデータを引き込むには、Vega仕様のどこにでも"${field:<field-name>}" 形式のテンプレート文字列を追加します。これによりChart Fields エリアにドロップダウンが作成され、ユーザーがクエリ結果の列を選択してVegaにマップできます。
フィールドのデフォルト値を設定するには、この構文を使用します:"${field:<field-name>:<placeholder text>}"
チャートプリセットの保存
モーダルの下部にあるボタンで、特定の可視化パネルに変更を適用します。または、プロジェクト内の他の場所で使用するためにVega仕様を保存できます。使い回しができるチャート定義を保存するには、Vegaエディタの上部にあるSave as をクリックしてプリセットに名前を付けます。
記事とガイド
The W&B Machine Learning Visualization IDE Visualizing NLP Attention Based Models Visualizing The Effect of Attention on Gradient Flow Logging arbitrary curves
共通のユースケース
誤差線のあるバープロットをカスタマイズする
モデル検証メトリクスの表示（PR曲線のようにカスタムx-y座標が必要なもの）
2つの異なるモデル/実験からのデータ分布をヒストグラムとして重ね合わせる
トレーニング中のスナップショットで複数のポイントにわたるメトリックの変化を示す
W&Bにまだないユニークな可視化を作成する（そして、できればそれを世界と共有する）
2.4.2.1 - チュートリアル: カスタムチャートの使用
W&B UI でのカスタムチャート機能の使用に関するチュートリアル
カスタムチャートを使用して、パネルに読み込むデータとその可視化を制御します。
1. データを W&B にログする
まず、スクリプトにデータをログします。ハイパーパラメーターのようなトレーニングの開始時に設定される単一のポイントには wandb.config を使用します。時間の経過に伴う複数のポイントには wandb.log() を使用し、wandb.Table() でカスタムの2D配列をログします。ログされたキーごとに最大10,000データポイントのログを推奨します。
# データのカスタムテーブルをログする
my_custom_data = [[x1, y1, z1], [x2, y2, z2]]
wandb. log(
{"custom_data_table" : wandb. Table(data= my_custom_data, columns= ["x" , "y" , "z" ])}
)
データテーブルをログするための短い例のノートブック を試してみてください。次のステップでカスタムチャートを設定します。生成されたチャートが ライブレポート でどのように見えるか確認できます。
2. クエリを作成する
データを視覚化するためにログしたら、プロジェクトページに移動し、新しいパネルを追加するために +Custom Chart を選びます。このワークスペース で案内に従うことができます。
クエリを追加する
summary をクリックして historyTable を選択し、run 履歴からデータを引き出す新しいクエリを設定します。wandb.Table() をログしたキーを入力します。上記のコードスニペットでは my_custom_table でした。例のノートブック では、キーは pr_curve と roc_curve です。
Vega フィールドを設定する
これらの列がクエリに読み込まれたので、Vega フィールドのドロップダウンメニューで選択オプションとして利用可能です：
x-axis: runSets_historyTable_r (recall)y-axis: runSets_historyTable_p (precision)color: runSets_historyTable_c (class label)
3. チャートをカスタマイズする
見た目はかなり良いですが、散布図から折れ線グラフに切り替えたいと思います。組み込みチャートの Vega スペックを変更するために Edit をクリックします。このワークスペース で案内に従うことができます。
Vega スペックを更新して可視化をカスタマイズしました：
プロット、凡例、x-axis、および y-axis のタイトルを追加 (各フィールドに「title」を設定)
「mark」の 値を「point」から「line」に変更
使用されていない「size」フィールドを削除
これを別の場所で使用できるプリセットとして保存するには、ページ上部の Save as をクリックします。結果は次の通り、ROC 曲線と共に次のようになります：
ボーナス: コンポジットヒストグラム
ヒストグラムは、数値の分布を可視化し、大きなデータセットを理解するのに役立ちます。コンポジットヒストグラムは、同じビンにまたがる複数の分布を示し、異なるモデルまたはモデル内の異なるクラス間で2つ以上のメトリクスを比較することができます。ドライブシーンのオブジェクトを検出するセマンティックセグメンテーションモデルの場合、精度最適化と Intersection over union (IOU) の効果を比較したり、異なるモデルが車（データの大きく一般的な領域）と交通標識（より小さく一般的でない領域）をどれだけよく検出するかを知りたいかもしれません。デモ Colab では、生命体の10クラスのうち2つのクラスの信頼スコアを比較できます。
カスタム合成ヒストグラムパネルのバージョンを作成するには：
ワークスペース または レポート で新しい Custom Chart パネルを作成します（「Custom Chart」可視化を追加することによって）。右上の「Edit」ボタンを押して、組み込みパネルタイプから始めて Vega スペックを変更します。
組み込みの Vega スペックを私の Vega におけるコンポジットヒストグラムの MVP コード に置き換えます。メインタイトル、軸タイトル、入力ドメイン、および Vega syntax](https://vega.github.io/ ) を使用して、他の詳細を直接変更できます（色を変更したり、3番目のヒストグラムを追加したりできます :)
正しいデータを wandb ログから読み込むために右側のクエリを修正します。 summaryTable フィールドを追加し、対応する ’tableKey’ を class_scores に設定して、run でログした wandb.Table を取得します。これにより、 wandb.Table のクラススコアとしてログされた列を使用して、ドロップダウン メニューから2つのヒストグラムビンセット (red_bins と blue_bins) を埋めることができます。私の例では、赤ビン の動物クラスの予測スコアと青ビン の植物の予測スコアを選びました。
プレビュー表示に表示されるプロットに満足するまで、Vega スペックとクエリを変更し続けることができます。完了したら、上部で Save as をクリックしてカスタムプロットに名前を付けて再利用できるようにします。 次に Apply from panel library をクリックしてプロットを終了します。
私の非常に短い実験の結果は次のようになりました：1,000エポックで1,000エグゼンプルだけでトレーニングすると、モデルはほとんどの画像が植物でないことに非常に自信を持ち、どの画像が動物かについては非常に不確かです。
2.4.3 - ワークスペース、セクション、パネル設定を管理する
Within a given workspace page there are three different setting levels: workspaces, sections, and panels. ワークスペース設定 は、ワークスペース全体に適用されます。セクション設定 は、セクション内のすべてのパネルに適用されます。パネル設定 は、個々のパネルに適用されます。
ワークスペース設定
ワークスペース設定は、すべてのセクションとそれらのセクション内のすべてのパネルに適用されます。編集できるワークスペース設定は次の2種類です: Workspace layout Line plots Workspace layouts はワークスペースの構造を決定し、Line plots 設定はワークスペース内のラインプロットのデフォルト設定を制御します。
このワークスペースの全体的な構造に適用される設定を編集するには:
プロジェクトワークスペースに移動します。
New report ボタンの横にある歯車のアイコンをクリックして、ワークスペース設定を表示します。ワークスペースのレイアウトを変更するには Workspace layout を選択するか、ワークスペース内のラインプロットのデフォルト設定を設定するには Line plots を選択します。
ワークスペースレイアウトオプション
ワークスペースのレイアウトを設定して、ワークスペースの全体的な構造を定義します。これには、セクションのロジックとパネルの配置が含まれます。
ワークスペースレイアウトオプションページでは、ワークスペースがパネルを自動か手動で生成するかが表示されます。ワークスペースのパネル生成モードを調整するには、Panels を参照してください。
この表は、各ワークスペースのレイアウトオプションについて説明しています。
ワークスペース設定
説明
検索中に空のセクションを非表示 パネルを検索するときにパネルを含まないセクションを非表示にします。
パネルをアルファベット順に並べ替え ワークスペース内のパネルをアルファベット順に並べ替えます。
セクションの組織化 既存のすべてのセクションとパネルを削除し、新しいセクション名で再配置します。また、新しく配置されたセクションを最初または最後のプレフィックスでグループ化します。
W&B は、最後のプレフィックスでグループ化するのではなく、最初のプレフィックスでセクションをグループ化することをお勧めします。最初のプレフィックスでグループ化することで、セクション数が少なくなり、パフォーマンスが向上します。
ラインプロットオプション
ワークスペースのLine plots 設定を変更して、ラインプロットのグローバルデフォルトとカスタムルールを設定します。
Line plots 設定内で編集できる主要な設定は2つあります: Data と Display preferences 。Data タブには次の設定が含まれています:
ラインプロット設定
説明
X軸 ラインプロットのx軸のスケール。x軸はデフォルトで Step に設定されています。x軸オプションのリストは次の表を参照してください。
範囲 x軸に表示する最小値と最大値の設定。
平滑化 ラインプロットの平滑化を変更します。平滑化の詳細については、Smooth line plots を参照してください。
異常値 異常値を除外するためにプロットの最小スケールと最大スケールを再設定します。
ポイント集計方法 Data Visualization の精度とパフォーマンスを向上させます。詳細については、Point aggregation を参照してください。
最大の runs またはグループの数 ラインプロットに表示する最大の runs またはグループ数を制限します。
Step 以外にも、x軸には他のオプションがあります:
X軸オプション
説明
相対時間 (Wall) プロセスが開始してからのタイムスタンプ。例えば、run を開始して次の日にその run を再開したとします。その場合、記録されたポイントは24時間後です。
相対時間 (Process) 実行中のプロセス内のタイムスタンプ。例えば、run を開始して10秒間続け、その後次の日に再開したとします。その場合、記録されたポイントは10秒です。
ウォールタイム グラフで最初の run が開始してから経過した時間（分）。
Step wandb.log() を呼び出すたびに増加します。
Display preferences タブ内で、以下の設定を切り替えることができます:
ディスプレイ設定
説明
すべてのパネルから凡例を削除 パネルの凡例を削除します
ツールチップ内でカラード run 名を表示 ツールチップ内で run をカラードテキストとして表示します
コンパニオンチャートツールチップで、ハイライトされた run のみを表示 チャートツールチップ内でハイライトされた run のみを表示します
ツールチップ内に表示される run の数 ツールチップ内で表示される run の数を表示します
プライマリチャートのツールチップにフル run 名を表示 チャートツールチップで run のフルネームを表示します
セクション設定
セクション設定は、そのセクション内のすべてのパネルに適用されます。ワークスペースセクション内では、パネルをソートしたり、並べ替えたり、セクション名を変更したりできます。
セクション設定を変更するには、セクションの右上隅にある3つの水平ドット (… ) を選択します。
ドロップダウンから、セクション全体に適用される次の設定を編集できます:
セクション設定
説明
セクションの名前を変更 セクションの名前を変更します
パネルを A-Z に並べ替え セクション内のパネルをアルファベット順に並べ替えます
パネルを並べ替え セクション内でパネルを手動で並べ替えるために、パネルを選択してドラッグします
以下のアニメーションは、セクション内でパネルを並べ替える方法を示しています:
この表で説明されている設定に加えて、ワークスペースでのセクションの表示方法も編集できます。たとえば、Add section below 、Add section above 、Delete section 、Add section to report などです。
パネル設定
個々のパネルの設定をカスタマイズして、同じプロットで複数のラインを比較したり、カスタム軸を計算したり、ラベルを変更したりすることができます。パネルの設定を編集するには:
編集したいパネルにマウスを乗せます。
現れる鉛筆アイコンを選択します。
表示されたモーダル内で、パネルのデータ、ディスプレイの設定などに関連する設定を編集できます。
パネルに適用できる設定の完全なリストについては、Edit line panel settings を参照してください。
2.4.4 - 設定
Weights and Biases の設定ページを使用して、個人のユーザープロファイルまたはチーム設定をカスタマイズします。
あなたの個別のユーザーアカウント内で編集できるのは、プロフィール写真、表示名、地理的な位置、経歴情報、アカウントに関連付けられたメール、および run のアラート管理です。また、設定ページを使用して GitHub リポジトリをリンクしたり、アカウントを削除したりできます。詳細はユーザー設定 をご覧ください。
チーム設定ページを使用して、新しいメンバーをチームに招待または削除したり、チームの run のアラートを管理したり、プライバシー設定を変更したり、ストレージ使用量を表示および管理したりできます。チーム設定の詳細については、チーム設定 をご覧ください。
2.4.4.1 - ユーザー設定を管理する
プロフィール情報、アカウントのデフォルト設定、アラート、ベータ版製品への参加、GitHub インテグレーション、ストレージ使用量、アカウントの有効化、チームの作成をユーザー設定で管理します。
ナビゲートして、 ユーザープロフィールページに移動し、右上のユーザーアイコンを選択します。 ドロップダウンメニューから、Settings を選択します。
Profile
Profile セクションでは、アカウント名と所属機関を管理および変更できます。オプションで、経歴、所在地、個人や所属機関のウェブサイトのリンクを追加したり、プロフィール画像をアップロードしたりできます。
イントロの編集
イントロを編集するには、プロフィールの上部にある Edit をクリックします。 開く WYSIWYG エディターは Markdown をサポートしています。
行を編集するには、それをクリックします。 時間を短縮するために、/ を入力し、リストから Markdown を選択できます。
アイテムのドラッグハンドルを使って移動します。
ブロックを削除するには、ドラッグハンドルをクリックしてから Delete をクリックします。
変更を保存するには、Save をクリックします。
SNS バッジの追加
@weights_biases アカウントのフォローバッジを X に追加するには、HTML の <img> タグを含む Markdown スタイルのリンクを追加します。そのバッジ画像にリンクさせます。
<img> タグでは、width、height、またはその両方を指定できます。どちらか一方だけを指定すると、画像の比率は維持されます。
Teams
Team セクションで新しいチームを作成します。 新しいチームを作成するには、New team ボタンを選択し、次の情報を提供します。
Team name - チームの名前。チーム名はユニークでなければなりません。チーム名は変更できません。Team type - Work または Academic ボタンを選択します。Company/Organization - チームの会社または組織の名前を提供します。 ドロップダウンメニューから会社または組織を選択します。 オプションで新しい組織を提供することもできます。
管理者アカウントのみがチームを作成できます。
ベータ機能
Beta Features セクションでは、開発中の新製品の楽しいアドオンやプレビューをオプションで有効にできます。有効にしたいベータ機能の横にある切り替えスイッチを選択します。
アラート
Runs がクラッシュしたり、終了したり、カスタムアラートを設定した際に通知を受け取ります。wandb.alert() を使用して電子メールまたは Slack 経由で通知を受け取ります。受け取りたいアラートイベントタイプの横にあるスイッチを切り替えます。
Runs finished : Weights and Biases の run が正常に完了したかどうか。Run crashed : run が終了しなかった場合の通知。
アラートの設定と管理方法の詳細については、Send alerts with wandb.alert を参照してください。
個人 GitHub インテグレーション
個人の Github アカウントを接続します。 Github アカウントを接続するには：
Connect Github ボタンを選択します。これにより、オープン認証（OAuth）ページにリダイレクトされます。Organization access セクションでアクセスを許可する組織を選択します。Authorize wandb を選択します。
アカウントの削除
アカウントを削除するには、Delete Account ボタンを選択します。
アカウントの削除は元に戻せません。
ストレージ
Storage セクションでは、Weights and Biases サーバーにおけるアカウントの総メモリ使用量について説明しています。 デフォルトのストレージプランは 100GB です。ストレージと料金の詳細については、Pricing ページをご覧ください。
2.4.4.2 - 請求設定を管理する
組織の請求設定を管理する
ナビゲートして ユーザー プロフィール ページ へ行き、右上隅の ユーザー アイコン を選択します。ドロップダウンから Billing を選択するか、Settings を選択してから Billing タブを選択してください。
プランの詳細
プランの詳細 セクションは、あなたの組織の現在のプラン、料金、制限、使用状況を要約します。
ユーザーの詳細とリストについては、Manage users をクリックしてください。
使用状況の詳細については、View usage をクリックしてください。
あなたの組織が使用するストレージの量（無料と有料の両方）。ここから追加のストレージを購入したり、現在使用中のストレージを管理したりできます。storage settings についての詳細を学んでください。
ここから、プランを比較したり、営業と話をすることができます。
プランの使用量
このセクションでは現在の使用状況を視覚的に要約し、今後の使用料金を表示します。使用量の月ごとの詳細を知るには、個々のタイルで View usage をクリックしてください。カレンダー月、チーム、プロジェクトごとの使用量をエクスポートするには、Export CSV をクリックしてください。
使用状況アラート
有料プランを使用している組織の場合、管理者は特定のしきい値に達したときに 1 回の請求期間ごとに 電子メールでアラートを受け取ります。billing admin である場合は組織の制限を増やす方法の詳細情報と、そうでない場合の billing admin への連絡方法を提供します。Pro plan では、billing admin のみが使用状況アラートを受け取ります。
これらのアラートは設定可能ではなく、以下の場合に送信されます：
組織が月ごとの使用カテゴリの制限に近づいたとき (85% の使用時間)、およびプランに基づいて 100% の制限に達したとき。
請求期間中の組織の累積平均料金が以下のしきい値を超えると、$200、$450、$700、$1000。これらの追加料金は、追跡時間、ストレージ、または Weave データの取り込みでプランに含まれる以上の使用が組織で積み重なると発生します。
使用状況や請求に関する質問については、アカウントチームまたはサポートにお問い合わせください。
支払い方法
このセクションでは、組織に登録されている支払い方法を表示します。支払い方法を追加していない場合、プランをアップグレードするか、有料ストレージを追加するときに追加を求められます。
Billing admin
このセクションでは、現在の billing admin を表示します。billing admin は組織の管理者であり、すべての請求関連メールを受信し、支払い方法を表示および管理することができます。
W&B Dedicated Cloud では、複数のユーザーが billing admins になることができます。W&B Multi-tenant Cloud では、一度に一人のユーザーのみが billing admin になることができます。
billing admin を変更するか、追加の users に役割を割り当てるには：
Manage roles をクリックします。ユーザーを検索します。
そのユーザーの行の Billing admin フィールドをクリックします。
要約を読んでから、Change billing user をクリックします。
請求書
クレジットカードによる支払いを行う場合、このセクションでは月ごとの請求書を表示できます。
銀行振込で支払う Enterprise アカウントの場合、このセクションは空白です。質問については、アカウントチームにお問い合わせください。
組織に請求がない場合、請求書は生成されません。
2.4.4.3 - チーム設定を管理する
チーム設定ページでチームのメンバー、アバター、アラート、プライバシー設定を管理します。
チーム設定
チームの設定を変更します。メンバー、アバター、通知、プライバシー、利用状況を含みます。組織の管理者およびチームの管理者は、チームの設定を表示および編集できます。
チーム設定を変更したり、チームからメンバーを削除できるのは、管理アカウントタイプのみです。
メンバー
メンバーセクションでは、保留中の招待と、チームに参加する招待を受け入れたメンバーのリストを表示します。各メンバーのリストには、メンバーの名前、ユーザー名、メール、チームの役割、および Models や Weave へのアクセス権限が表示されます。これらは組織から継承されます。標準のチーム役割 Admin 、Member 、View-only から選択できます。組織が カスタムロールの作成 をしている場合、カスタムロールを割り当てることもできます。
チームの作成、管理、およびチームのメンバーシップと役割の管理についての詳細は、Add and Manage Teams を参照してください。新しいメンバーを招待できる人や、チームの他のプライバシー設定を設定するには、プライバシー を参照してください。
アバター
Avatar セクションに移動して画像をアップロードすることで、アバターを設定します。
Update Avatar を選択し、ファイルダイアログを表示します。ファイルダイアログから使用したい画像を選択します。
アラート
run がクラッシュしたり、完了したり、カスタムアラートを設定したりしたときにチームに通知します。チームは、メールまたは Slack を通じてアラートを受け取ることができます。
受け取りたいイベントタイプの横にあるスイッチを切り替えます。Weights and Biases はデフォルトで以下のイベントタイプオプションを提供します:
Runs finished : Weights and Biases の run が正常に完了したかどうか。Run crashed : run が完了できなかった場合。
アラートの設定と管理についての詳細は、wandb.alert を使用したアラートの送信 を参照してください。
Slack 通知
Slack の送信先を設定し、チームのオートメーション が、新しいアーティファクトが作成されたときや、run のメトリックが設定された閾値に達したときなどに Registry やプロジェクトでイベントが発生すると通知を送信できるようにします。Slack オートメーションの作成 を参照してください。
This feature is available for all Enterprise licenses.
ウェブフック
チームのオートメーション が、新しいアーティファクトが作成されたときや、run のメトリックが設定された閾値に達したときなどに Registry やプロジェクトでイベントが発生すると動作するようにウェブフックを設定します。Webhook オートメーションの作成 を参照してください。
This feature is available for all Enterprise licenses.
プライバシー
Privacy セクションに移動してプライバシー設定を変更します。プライバシー設定を変更できるのは組織の管理者のみです。
今後のプロジェクトを公開したり、レポートを公開で共有したりする機能をオフにします。
チームの管理者だけでなく、どのチームメンバーも他のメンバーを招待できます。
デフォルトでコードの保存がオンになっているかどうかを管理します。
使用状況
Usage セクションでは、チームが Weights and Biases サーバーで消費した合計メモリ使用量について説明します。デフォルトのストレージプランは100GBです。ストレージと価格についての詳細は、Pricing ページを参照してください。
ストレージ
Storage セクションでは、チームのデータに対して使用されるクラウドストレージバケットの設定を説明します。詳細は Secure Storage Connector を参照するか、セルフホスティングしている場合は W&B Server ドキュメントをチェックしてください。
2.4.4.4 - メール設定を管理する
Settings ページからメールを管理します。
Add, delete, manage email types and primary email addresses in your W&B プロファイル 設定 ページ. Select your profile icon in the upper right corner of the W&B ダッシュボード. From the dropdown, select 設定 . Within the 設定 ページ, scroll down to the Emails ダッシュボード:
プライマリーメール の管理
プライマリーメール は 😎 絵文字でマークされています。プライマリーメール は、W&B アカウントを作成する際に提供したメールで自動的に定義されます。
Weights And Biases アカウント に関連付けられている プライマリーメール を変更するには、ケバブ ドロップダウン を選択します:
確認済みのメールのみを プライマリー として設定できます
メールを追加
+ Add Email を選択して、メールを追加します。これにより、Auth0 ページに移動します。新しいメールの資格情報を入力するか、シングル サインオン (SSO) を使用して接続できます。
メールを削除
ケバブ ドロップダウン を選択し、Delete Emails を選択して、W&B アカウント に登録されているメールを削除します
プライマリーメール は削除できません。削除する前に、別のメールを プライマリー として設定する必要があります。
ログイン メソッド
ログイン メソッド 列には、アカウントに関連付けられているログイン メソッド が表示されます。
W&B アカウントを作成すると、確認メールがアカウント に送信されます。メール アドレス を確認するまで、メール アカウント は確認されていないと見なされます。未確認のメールは赤で表示されます。
元の確認メールがメール アカウントに送信されていない場合、もう一度メール アドレスでログインを試みて、2 回目の確認メールを取得してください。
アカウントのログインの問題がある場合は、support@wandb.com にお問い合わせください。
2.4.4.5 - チームを管理する
チーム全体で同僚と共同作業を行い、結果を共有し、すべての実験を追跡します。
W&B Teams を使用して、あなたの ML チームのための中心的なワークスペースを作り、モデルをより迅速に構築しましょう。
チームが試した全ての実験管理を追跡 し、作業の重複を防ぎます。以前にトレーニングしたモデルを保存し再現 します。進捗や成果を上司やコラボレーターと共有 します。リグレッションをキャッチ し、パフォーマンスが低下したときにすぐに通知を受け取ります。モデルの性能をベンチマーク し、モデルのバージョンを比較します。
協力的なチームを作成する
サインアップまたはログイン ナビゲーションバーで チームを招待 をクリックします。
チームを作成し、コラボレーターを招待します。
チームの設定については、チーム設定の管理 を参照してください。
注意 : 組織の管理者のみが新しいチームを作成できます。
チームプロフィールを作成する
あなたのチームのプロフィールページをカスタマイズして、イントロダクションを示したり、公開されているまたはチームメンバーに表示されるレポートやプロジェクトを見せることができます。レポート、プロジェクト、外部リンクを提示します。
最良の研究を強調表示 し、訪問者にあなたの最良の公開レポートを見せる最もアクティブなプロジェクトを披露 し、チームメイトがそれらを見つけやすくするあなたの会社や研究室のウェブサイトや公開した論文への外部リンクを追加することで コラボレーターを見つける
チームメンバーを削除する
チーム管理者はチーム設定ページを開き、去るメンバーの名前の横にある削除ボタンをクリックします。チームにログされている run はユーザーが去った後も留まります。
チームの役割と権限を管理する
同僚をチームに招待するときにチームの役割を選択します。以下のチームの役割オプションがあります：
管理者 : チーム管理者は他の管理者やチームメンバーを追加および削除できます。すべてのプロジェクトを変更する権限と完全な削除権限を持っています。これには、run、プロジェクト、Artifacts、スイープの削除が含まれますが、これに限定されません。メンバー : チームの通常のメンバーです。デフォルトでは、管理者のみがチームメンバーを招待できます。この振る舞いを変更するには、チーム設定の管理 を参照してください。
チームメンバーは自分が作成した run のみを削除できます。メンバー A と B がいるとします。メンバー B が team B のプロジェクトからメンバー A が所有する別のプロジェクトに run を移動します。メンバー A は、メンバー B がメンバー A のプロジェクトに移動した run を削除できません。管理者は、チームメンバーによって作成された run およびスイープ run を管理できます。
閲覧のみ (エンタープライズ限定機能) : 閲覧のみのメンバーは、run、レポート、ワークスペースのようなチーム内のアセットを閲覧できます。彼らはレポートを追跡し、コメントを残すことができますが、プロジェクト概要、レポート、run を作成、編集、または削除することはできません。カスタム役割 (エンタープライズ限定機能) : カスタム役割は、組織管理者が 閲覧のみ または メンバー のいずれかの役割に基づいて新しい役割を作成し、より詳細なアクセス制御を実現するための追加の権限と共にそれを構成させます。その後、チーム管理者がそれぞれのチームのユーザーにこれらのカスタム役割を割り当てることができます。詳細については、Introducing Custom Roles for W&B Teams を参照してください。サービスアカウント (エンタープライズ限定機能) : Use service accounts to automate workflows を参照してください。
W&B は、チームに複数の管理者を持つことをお勧めします。主要な管理者が不在のときに管理操作を継続できることを保証するためのベストプラクティスです。
チーム設定
チーム設定では、チームとそのメンバーのための設定を管理できます。これらの特権により、W&B 内でチームを効果的に監督および整理できます。
権限
閲覧のみ
チームメンバー
チーム管理者
チームメンバーを追加
X
チームメンバーを削除
X
チーム設定を管理
X
レジストリ
以下の表は、特定のチーム全体で適用されるすべてのプロジェクトに関連する権限を示しています。
権限
閲覧のみ
チームメンバー
レジストリ管理者
チーム管理者
エイリアスを追加する
X
X
X
モデルをレジストリに追加する
X
X
X
レジストリ内のモデルを閲覧する
X
X
X
X
モデルをダウンロードする
X
X
X
X
レジストリ管理者を追加または削除する
X
X
保護されたエイリアスを追加または削除する
X
保護されたエイリアスの詳細については、レジストリアクセス制御 を参照してください。
レポート
レポート権限は、レポートの作成、閲覧、編集へのアクセスを許可します。以下の表は、特定のチーム全体でのすべてのレポートに適用される権限を列挙しています。
権限
閲覧のみ
チームメンバー
チーム管理者
レポートを閲覧する
X
X
X
レポートを作成する
X
X
レポートを編集する
X (チームメンバーは自分のレポートのみ編集できます)
X
レポートを削除する
X (チームメンバーは自分のレポートのみ編集できます)
X
実験管理
以下の表は、特定のチーム全体でのすべての実験に適用される権限を示しています。
権限
閲覧のみ
チームメンバー
チーム管理者
実験のメタデータを閲覧する（履歴メトリクス、システムメトリクス、ファイル、およびログを含む）
X
X
X
実験パネルとワークスペースを編集する
X
X
実験をログする
X
X
実験を削除する
X (チームメンバーは自分が作成した実験のみ削除できます)
X
実験を停止する
X (チームメンバーは自分が作成した実験のみ停止できます)
X
Artifacts
以下の表は、特定のチーム全体でのすべてのアーティファクトに適用される権限を示しています。
権限
閲覧のみ
チームメンバー
チーム管理者
アーティファクトを閲覧する
X
X
X
アーティファクトを作成する
X
X
アーティファクトを削除する
X
X
メタデータを編集する
X
X
エイリアスを編集する
X
X
エイリアスを削除する
X
X
アーティファクトをダウンロードする
X
X
システム設定 (W&B サーバーのみ)
システム権限を使用して、チームとそのメンバーを作成および管理し、システム設定を調整します。これらの特権により、W&B インスタンスを効果的に管理および維持することができます。
権限
閲覧のみ
チームメンバー
チーム管理者
システム管理者
システム設定を設定する
X
チームを作成/削除する
X
チームサービスアカウントの振る舞い
トレーニング環境でチームを設定すると、そのチームからのサービスアカウントを使用して、そのチーム内のプライベートまたはパブリックプロジェクトに run をログすることができます。さらに、環境内に WANDB_USERNAME または WANDB_USER_EMAIL 変数が存在し、参照されるユーザーがそのチームのメンバーである場合、その run をそのユーザーに割り当てることができます。
トレーニング環境でチームを 設定せず 、サービスアカウントを使用する場合、サービスアカウントの親チーム内の指定されたプロジェクトに run をログします。この場合も、環境内に WANDB_USERNAME または WANDB_USER_EMAIL 変数が存在し、参照されるユーザーがサービスアカウントの親チームのメンバーである場合、その run をそのユーザーに割り当てることができます。
サービスアカウントは親チームとは異なるチーム内のプライベートプロジェクトに run をログすることはできません。サービスアカウントは、プロジェクトが Open プロジェクトの可視性に設定されている場合にのみプロジェクトにログできます。
チームトライアル
W&B プランの詳細については、価格ページ を参照してください。ダッシュボード UI または Export API を利用して、いつでもすべてのデータをダウンロードできます。
プライバシー設定
チーム設定ページで、すべてのチームプロジェクトのプライバシー設定を見ることができます：
app.wandb.ai/teams/your-team-name
高度な設定
安全なストレージコネクタ
チームレベルの安全なストレージコネクタにより、チームは自分たちのクラウドストレージバケットを W&B とともに使用できます。これは、非常に機密性の高いデータまたは厳しいコンプライアンス要件を持つチームにとって、データアクセス制御およびデータ分離を向上させます。安全なストレージコネクタ を参照してください。
2.4.4.6 - ストレージを管理する
W&B データ ストレージを管理する方法。
If you are approaching or exceeding your storage limit, there are multiple paths forward to manage your data. The path that’s best for you will depend on your account type and your current project setup.
ストレージ消費の管理
W&B は、ストレージ消費を最適化するためのさまざまなメソッドを提供しています:
データの削除
ストレージ制限以下に留めるためにデータを削除することも選択できます。これを行う方法はいくつかあります:
アプリの UI を使って対話的にデータを削除します。
Artifacts に TTL ポリシーを設定 し、自動的に削除されるようにします。
2.4.4.7 - システム メトリクス
W&B によって自動的にログされるメトリクス。
このページでは、W&B SDKによって追跡されるシステムメトリクスについての詳細情報を提供します。
wandb は、15秒ごとに自動的にシステムメトリクスをログに記録します。
CPU
プロセスCPUパーセント (CPU)
プロセスによるCPU使用率を、利用可能なCPU数で正規化したものです。
W&Bは、このメトリクスに cpu タグを割り当てます。
プロセスCPUスレッド
プロセスによって利用されるスレッドの数です。
W&Bは、このメトリクスに proc.cpu.threads タグを割り当てます。
ディスク
デフォルトでは、/ パスの使用状況メトリクスが収集されます。監視するパスを設定するには、次の設定を使用します：
run = wandb. init(
settings= wandb. Settings(
x_stats_disk_paths= ("/System/Volumes/Data" , "/home" , "/mnt/data" ),
),
)
ディスク使用率パーセント
指定されたパスに対するシステム全体のディスク使用率をパーセントで表します。
W&Bは、このメトリクスに disk.{path}.usagePercent タグを割り当てます。
ディスク使用量
指定されたパスに対するシステム全体のディスク使用量をギガバイト（GB）で表します。
アクセス可能なパスがサンプリングされ、各パスのディスク使用量（GB）がサンプルに追加されます。
W&Bは、このメトリクスに disk.{path}.usageGB タグを割り当てます。
ディスクイン
システム全体のディスク読み込み量をメガバイト（MB）で示します。最初のサンプルが取られた時点で初期ディスク読み込みバイト数が記録されます。その後のサンプルは、現在の読み込みバイト数と初期値との差を計算します。
W&Bは、このメトリクスに disk.in タグを割り当てます。
ディスクアウト
システム全体のディスク書き込み量をメガバイト（MB）で示します。最初のサンプルが取られた時点で初期ディスク書き込みバイト数が記録されます。その後のサンプルは、現在の書き込みバイト数と初期値との差を計算します。
W&Bは、このメトリクスに disk.out タグを割り当てます。
メモリ
プロセスのためのメモリResident Set Size (RSS)をメガバイト（MB）で表します。RSSは、プロセスによって占有されるメモリの一部であり、主記憶（RAM）に保持されるものです。
W&Bは、このメトリクスに proc.memory.rssMB タグを割り当てます。
プロセスメモリパーセント
プロセスのメモリ使用率を、利用可能なメモリ全体に対するパーセントで示します。
W&Bは、このメトリクスに proc.memory.percent タグを割り当てます。
メモリパーセント
システム全体のメモリ使用率を、利用可能なメモリ全体に対するパーセントで表します。
W&Bは、このメトリクスに memory_percent タグを割り当てます。
メモリアベイラブル
システム全体の利用可能なメモリをメガバイト（MB）で示します。
W&Bは、このメトリクスに proc.memory.availableMB タグを割り当てます。
ネットワーク
ネットワーク送信
ネットワーク上で送信されたバイトの合計を示します。
最初にメトリクスが初期化された際に、送信されたバイトの初期値が記録されます。その後のサンプルでは、現在の送信バイト数と初期値との差を計算します。
W&Bは、このメトリクスに network.sent タグを割り当てます。
ネットワーク受信
ネットワーク上で受信されたバイトの合計を示します。
ネットワーク送信 と同様に、メトリクスが最初に初期化された際に、受信されたバイトの初期値が記録されます。後続のサンプルでは、現在の受信バイト数と初期値との差を計算します。
W&Bは、このメトリクスに network.recv タグを割り当てます。
NVIDIA GPU
以下に説明するメトリクスに加え、プロセスおよびその子孫が特定のGPUを使用する場合、W&Bは対応するメトリクスを gpu.process.{gpu_index}.{metric_name} としてキャプチャします。
GPUメモリ利用率
各GPUのGPUメモリ利用率をパーセントで表します。
W&Bは、このメトリクスに gpu.{gpu_index}.memory タグを割り当てます。
GPUメモリアロケート
各GPUの全利用可能メモリに対するGPUメモリの割り当てをパーセントで示します。
W&Bは、このメトリクスに gpu.{gpu_index}.memoryAllocated タグを割り当てます。
GPUメモリアロケートバイト
各GPUのGPUメモリ割り当てをバイト単位で指定します。
W&Bは、このメトリクスに gpu.{gpu_index}.memoryAllocatedBytes タグを割り当てます。
GPU利用率
各GPUのGPU利用率をパーセントで示します。
W&Bは、このメトリクスに gpu.{gpu_index}.gpu タグを割り当てます。
GPU温度
各GPUの温度を摂氏で示します。
W&Bは、このメトリクスに gpu.{gpu_index}.temp タグを割り当てます。
GPU電力使用ワット
各GPUの電力使用量をワットで示します。
W&Bは、このメトリクスに gpu.{gpu_index}.powerWatts タグを割り当てます。
GPU電力使用パーセント
各GPUの電力容量に対する電力使用をパーセントで示します。
W&Bは、このメトリクスに gpu.{gpu_index}.powerPercent タグを割り当てます。
GPU SMクロックスピード
GPUのストリーミングマルチプロセッサ (SM) のクロックスピードをMHzで表します。このメトリクスは、計算タスクを担当するGPUコア内のプロセッシング速度を示唆しています。
W&Bは、このメトリクスに gpu.{gpu_index}.smClock タグを割り当てます。
GPUメモリクロックスピード
GPUメモリのクロックスピードをMHzで表します。これは、GPUメモリと処理コア間のデータ転送速度に影響を与えます。
W&Bは、このメトリクスに gpu.{gpu_index}.memoryClock タグを割り当てます。
GPUグラフィックスクロックスピード
GPUでのグラフィックスレンダリング操作の基本クロックスピードをMHzで示します。このメトリクスは、可視化またはレンダリングタスク中のパフォーマンスを反映することが多いです。
W&Bは、このメトリクスに gpu.{gpu_index}.graphicsClock タグを割り当てます。
GPU訂正されたメモリエラー
W&Bが自動的にエラーチェックプロトコルを使用して訂正する、GPU上のメモリエラーのカウントを追跡します。これにより、回復可能なハードウェアの問題を示します。
W&Bは、このメトリクスに gpu.{gpu_index}.correctedMemoryErrors タグを割り当てます。
GPU訂正されていないメモリエラー
W&Bが訂正しない、GPU上のメモリエラーのカウントを追跡します。これにより、処理の信頼性に影響を与える可能性がある回復不可能なエラーを示します。
W&Bは、このメトリクスに gpu.{gpu_index}.unCorrectedMemoryErrors タグを割り当てます。
GPUエンコーダ利用率
GPUのビデオエンコーダの利用率をパーセントで表し、エンコーディングタスク（例えばビデオレンダリング）が実行されているときの負荷を示します。
W&Bは、このメトリクスに gpu.{gpu_index}.encoderUtilization タグを割り当てます。
AMD GPU
W&Bは、AMDが提供する rocm-smi ツールの出力からメトリクスを抽出します（rocm-smi -a --json）。
ROCm 6.x (最新) および 5.x フォーマットがサポートされています。AMD ROCm ドキュメンテーション でROCmフォーマットの詳細を確認できます。新しいフォーマットにはより詳細が含まれています。
AMD GPU利用率
各AMD GPUデバイスのGPU利用率をパーセントで表します。
W&Bは、このメトリクスに gpu.{gpu_index}.gpu タグを割り当てます。
AMD GPUメモリアロケート
各AMD GPUデバイスの全利用可能メモリに対するGPUメモリの割り当てをパーセントで示します。
W&Bは、このメトリクスに gpu.{gpu_index}.memoryAllocated タグを割り当てます。
AMD GPU温度
各AMD GPUデバイスの温度を摂氏で示します。
W&Bは、このメトリクスに gpu.{gpu_index}.temp タグを割り当てます。
AMD GPU電力使用ワット
各AMD GPUデバイスの電力使用量をワットで示します。
W&Bは、このメトリクスに gpu.{gpu_index}.powerWatts タグを割り当てます。
AMD GPU電力使用パーセント
各AMD GPUデバイスの電力容量に対する電力使用をパーセントで示します。
W&Bは、このメトリクスに gpu.{gpu_index}.powerPercent をこのメトリクスに割り当てます。
Apple ARM Mac GPU
Apple GPU利用率
特にARM Mac上のApple GPUデバイスにおけるGPU利用率をパーセントで示します。
W&Bは、このメトリクスに gpu.0.gpu タグを割り当てます。
Apple GPUメモリアロケート
ARM Mac上のApple GPUデバイスにおける全利用可能メモリに対するGPUメモリの割り当てをパーセントで示します。
W&Bは、このメトリクスに gpu.0.memoryAllocated タグを割り当てます。
Apple GPU温度
ARM Mac上のApple GPUデバイスの温度を摂氏で示します。
W&Bは、このメトリクスに gpu.0.temp タグを割り当てます。
Apple GPU電力使用ワット
ARM Mac上のApple GPUデバイスの電力使用量をワットで示します。
W&Bは、このメトリクスに gpu.0.powerWatts タグを割り当てます。
Apple GPU電力使用パーセント
ARM Mac上のApple GPUデバイスの電力容量に対する電力使用をパーセントで示します。
W&Bは、このメトリクスに gpu.0.powerPercent タグを割り当てます。
Graphcore IPU
Graphcore IPU（インテリジェンスポロセッシングユニット）は、機械知能タスクのために特別に設計されたユニークなハードウェアアクセラレータです。
IPUデバイスメトリクス
これらのメトリクスは、特定のIPUデバイスのさまざまな統計を表します。各メトリクスには、デバイスID（device_id）とメトリクスキー（metric_key）があり、それを識別します。W&Bは、このメトリクスに ipu.{device_id}.{metric_key} タグを割り当てます。
メトリクスは、Graphcore の gcipuinfo バイナリと相互作用する専用の gcipuinfo ライブラリを使用して抽出されます。sample メソッドは、プロセスID（pid）に関連する各IPUデバイスのこれらのメトリクスを取得します。時間の経過とともに変化するメトリクスまたはデバイスのメトリクスが最初に取得されたときにのみログに記録され、冗長なデータのログを回避します。
各メトリクスに対して、メトリクスの値をその生の文字列表現から抽出するために parse_metric メソッドが使用されます。メトリクスは、複数のサンプルを通じて aggregate メソッドを使用して集計されます。
利用可能なメトリクスとその単位は次のとおりです：
平均ボード温度 (average board temp (C)): IPUボードの温度を摂氏で示します。平均ダイ温度 (average die temp (C)): IPUダイの温度を摂氏で示します。クロックスピード (clock (MHz)): IPUのクロックスピードをMHzで示します。IPU電力 (ipu power (W)): IPUの電力消費量をワットで示します。IPU利用率 (ipu utilisation (%)): IPUの利用率をパーセントで示します。IPUセッション利用率 (ipu utilisation (session) (%)): 現在のセッションに特化したIPU利用率をパーセントで示します。データリンクスピード (speed (GT/s)): データ転送速度をGiga-transfers毎秒で示します。
Google クラウド TPU
テンソルプロセッシングユニット（TPU）は、Googleによって開発されたASIC（アプリケーション特定統合回路）で、機械学習のワークロードを加速するために使用されます。
TPUメモリ使用量
各TPUコアあたりの現在の高帯域幅メモリ使用量をバイト単位で示します。
W&Bは、このメトリクスに tpu.{tpu_index}.memoryUsageBytes タグを割り当てます。
TPUメモリ使用率
各TPUコアあたりの現在の高帯域幅メモリ使用率をパーセントで示します。
W&Bは、このメトリクスに tpu.{tpu_index}.memoryUsageBytes タグを割り当てます。
TPUデューティサイクル
TPUデバイスごとのTensorCoreデューティサイクルのパーセントです。サンプル期間中、アクセラレータTensorCoreが積極的に処理していた時間の割合を追跡します。大きな値は、より良いTensorCoreの利用率を意味します。
W&Bは、このメトリクスに tpu.{tpu_index}.dutyCycle タグを割り当てます。
AWS Trainium
AWS Trainium は、機械学習ワークロードの高速化に焦点を当てた、AWSが提供する特殊なハードウェアプラットフォームです。AWSの neuron-monitor ツールを使用して、AWS Trainiumメトリクスをキャプチャします。
Trainiumニューロンコア利用率
各ニューロンコアごとの利用率をパーセントで示します。
W&Bは、このメトリクスに trn.{core_index}.neuroncore_utilization タグを割り当てます。
Trainiumホストメモリ使用量、合計
ホストの総メモリ消費量をバイト単位で示します。
W&Bは、このメトリクスに trn.host_total_memory_usage タグを割り当てます。
Trainiumニューロンデバイス総メモリ使用量
ニューロンデバイス上の総メモリ使用量をバイト単位で示します。
W&Bは、このメトリクスに trn.neuron_device_total_memory_usage) タグを割り当てます。
Trainiumホストメモリ使用量の内訳：
以下はホストのメモリ使用量の内訳です：
アプリケーションメモリ (trn.host_total_memory_usage.application_memory): アプリケーションによって使用されるメモリ。定数 (trn.host_total_memory_usage.constants): 定数に使用されるメモリ。DMAバッファ (trn.host_total_memory_usage.dma_buffers): ダイレクトメモリアクセスバッファに使用されるメモリ。テンソル (trn.host_total_memory_usage.tensors): テンソルに使用されるメモリ。
Trainiumニューロンコアメモリ使用量の内訳
各ニューロンコアのメモリ使用に関する詳細情報：
定数 (trn.{core_index}.neuroncore_memory_usage.constants)モデルコード (trn.{core_index}.neuroncore_memory_usage.model_code)モデル共有スクラッチパッド (trn.{core_index}.neuroncore_memory_usage.model_shared_scratchpad)ランタイムメモリ (trn.{core_index}.neuroncore_memory_usage.runtime_memory)テンソル (trn.{core_index}.neuroncore_memory_usage.tensors)
OpenMetrics
カスタム正規表現ベースのメトリックフィルタを適用できるOpenMetrics / Prometheus互換データをエクスポートする外部エンドポイントからメトリクスをキャプチャし、ログに記録します。
特定のケースで NVIDIA DCGM-Exporter を使用してGPUクラスターのパフォーマンスを監視する方法の詳細な例については、このレポート を参照してください。
2.4.4.8 - 匿名モード
データをログし、W&B アカウントなしで可視化する
コードを誰でも簡単に実行できるように公開していますか？ 匿名モードを使用して、誰かがあなたのコードを実行し、W&B ダッシュボードを見て、W&B アカウントを作成することなく結果を視覚化できるようにします。
結果が匿名モードでログに記録されるようにするには、次のようにします：
import wandb
wandb. init(anonymous= "allow" )
例えば、次のコードスニペットは、W&B でアーティファクトを作成し、ログに記録する方法を示しています：
import wandb
run = wandb. init(anonymous= "allow" )
artifact = wandb. Artifact(name= "art1" , type= "foo" )
artifact. add_file(local_path= "path/to/file" )
run. log_artifact(artifact)
run. finish()
例のノートブックを試してみて 、匿名モードがどのように機能するかを確認してください。
3 - W&B Weave
Weave は、LLM アプリケーションを追跡および評価するための軽量ツールキットです。W&B Weave を使って、LLM の実行フローを視覚化および検査し、LLM の入力と出力を分析し、中間結果を表示し、プロンプトと LLM チェーン設定を安全に保存および管理できます。
W&B Weave を使用すると、次のことが可能です：
言語モデルの入力、出力、およびトレースをログし、デバッグ
言語モデルのユースケースに対する厳密な、比較可能な評価を構築
実験から評価、プロダクションまでの LLM ワークフローで生成されたすべての情報を整理
開始方法
ユースケースに応じて、W&B Weave を始めるために以下のリソースを探索してください：
4 - W&B コア
W&B Core は W&B Models と W&B Weave をサポートする基盤フレームワークであり、W&B Platform によってサポートされています。
W&B Core は、ML ライフサイクル全体にわたる機能を提供します。W&B Core を使用すると、次のことができます:
4.1 - Artifacts
W&B アーティファクトの概要、仕組み、および開始方法。
W&B Artifacts を使用して、W&B Runs の入力と出力としてデータをトラッキングし、バージョン管理します。たとえば、モデルトレーニングの run では、データセットを入力として受け取り、トレーニングされたモデルを出力として生成することがあります。ハイパーパラメーター、メタデータ、メトリクスを run にログし、アーティファクトを使用してモデルをトレーニングするために使用されるデータセットを入力としてログ、トラッキング、およびバージョン管理し、生成されたモデルのチェックポイントを出力として管理できます。
ユースケース
あなたの ML ワークフロー全体で、runs の入力と出力としてアーティファクトを使用することができます。データセット、モデル、または他のアーティファクトをプロセシングの入力として使用することができます。
ユースケース
入力
出力
モデルトレーニング
データセット (トレーニングおよび検証データ)
トレーニングされたモデル
データセットの前処理
データセット (生データ)
データセット (前処理済みデータ)
モデルの評価
モデル + データセット (テストデータ)
W&B Table
モデルの最適化
モデル
最適化されたモデル
続くコードスニペットは順番に実行されることを意図しています。
アーティファクトを作成する
4行のコードでアーティファクトを作成します:
W&B run を作成する。wandb.Artifactモデルファイルやデータセットなど、一つ以上のファイルをアーティファクトオブジェクトに追加する。
あなたのアーティファクトを W&B にログする。
例として、続くコードスニペットは example_artifact という名前のアーティファクトに dataset.h5 というファイルをログする方法を示しています:
import wandb
run = wandb. init(project= "artifacts-example" , job_type= "add-dataset" )
artifact = wandb. Artifact(name= "example_artifact" , type= "dataset" )
artifact. add_file(local_path= "./dataset.h5" , name= "training_dataset" )
artifact. save()
# アーティファクトのバージョン "my_data" を dataset.h5 のデータを持つデータセットとしてログします
外部オブジェクトストレージに保存されているファイルやディレクトリーへの参照の追加方法については、
外部ファイルのトラッキング ページを参照してください。
アーティファクトをダウンロードする
use_artifact
続くコードスニペットに続けて、この次のコードブロックは training_dataset アーティファクトの使用方法を示しています:
artifact = run. use_artifact(
"training_dataset:latest"
) # "my_data" アーティファクトを使用する run オブジェクトを返します
これはアーティファクトオブジェクトを返します。
次に、返されたオブジェクトを使用して、アーティファクトのすべての内容をダウンロードします:
datadir = (
artifact. download()
) # `my_data` アーティファクト全体をデフォルトのディレクトリにダウンロードします。
次のステップ
アーティファクトをバージョン管理 し、更新 する方法を学びます。
オートメーション を使用して、あなたのアーティファクトに対する変更に反応して下流のワークフローをトリガーしたり、Slack チャンネルに通知する方法を学びます。トレーニングされたモデルを収容するスペースであるレジストリ について学びます。
Python SDK と CLI リファレンスガイドを探索します。
4.1.1 - アーティファクトを作成する
W&B アーティファクトを作成し、構築します。ファイルや URI リファレンスをアーティファクトに追加する方法を学びましょう。
W&B Python SDK を使用して、W&B Runs から artifacts を構築します。ファイル、ディレクトリ、URI、並行実行からのファイルを artifacts に追加 できます。ファイルをアーティファクトに追加した後、W&B サーバーまたは自分のプライベートサーバー に保存します。
Amazon S3 に保存されているファイルなど、外部ファイルのトラッキング方法については、外部ファイルのトラッキング ページをご覧ください。
アーティファクトの構築方法
3 つのステップで W&B Artifact を構築します。
1. wandb.Artifact() でアーティファクト Python オブジェクトを作成する
wandb.Artifact()
Name : アーティファクトの名前を指定します。名前は一意で説明的、かつ記憶しやすいものにしてください。Artifacts の名前は、W&B アプリ UI でアーティファクトを識別するとき、またそのアーティファクトを使用したいときに使用します。Type : タイプを指定します。タイプはシンプルで説明的で、機械学習パイプラインの単一ステップに対応するものでなければなりません。一般的なアーティファクトタイプには 'dataset' や 'model' があります。
指定した「name」と「type」は、有向非循環グラフを作成するために使用されます。これは、W&B アプリでアーティファクトのリネージを見ることができることを意味します。
詳細については、アーティファクトグラフの探索とトラバース をご覧ください。
Artifacts は、たとえ異なる types パラメータを指定しても、同じ名前を持つことはできません。つまり、cats という名前のタイプ dataset のアーティファクトを作成し、同じ名前のタイプ model のアーティファクトを作成することはできません。
アーティファクトオブジェクトを初期化する際に、オプションで説明とメタデータを提供できます。利用可能な属性とパラメータの詳細については、Python SDK Reference Guide の wandb.Artifact
次の例は、データセットアーティファクトを作成する方法を示しています。
import wandb
artifact = wandb. Artifact(name= "<replace>" , type= "<replace>" )
先行のコードスニペット内の文字列の引数を、自分の 固有の名前とタイプで置き換えてください。
2. アーティファクトに 1 つ以上のファイルを追加する
ファイル、ディレクトリ、外部 URI リファレンス（例: Amazon S3）などをアーティファクトメソッドで追加します。たとえば、単一のテキストファイルを追加するには、add_file
artifact. add_file(local_path= "hello_world.txt" , name= "optional-name" )
また、複数のファイルを add_dirアーティファクトの更新 をご覧ください。
3. アーティファクトを W&B サーバーに保存する
最後に、アーティファクトを W&B サーバーに保存します。Artifacts は run に関連付けられます。したがって、run オブジェクトの log_artifact()
# W&B Run を作成します。'job-type' を置き換えます。
run = wandb. init(project= "artifacts-example" , job_type= "job-type" )
run. log_artifact(artifact)
W&B Run の外でアーティファクトを作成することもできます。詳細については、外部ファイルのトラッキング をご覧ください。
log_artifact の呼び出しは、パフォーマンスを向上させるために非同期で行われます。これにより、ループ内でアーティファクトをログする際に予期しない挙動が生じることがあります。たとえば、
for i in range(10 ):
a = wandb. Artifact(
"race" ,
type= "dataset" ,
metadata= {
"index" : i,
},
)
# ... アーティファクト a にファイルを追加 ...
run. log_artifact(a)
アーティファクトバージョン v0 は、そのメタデータにインデックス 0 があることを保証しません。アーティファクトは任意の順序でログされる可能性があるためです。
アーティファクトにファイルを追加
以下のセクションでは、異なるファイルタイプおよび並行実行からのアーティファクトを構築する方法を説明します。
以下の例では、複数のファイルとディレクトリ構造を持つプロジェクトディレクトリを前提とします。
project-directory
|-- images
| |-- cat.png
| +-- dog.png
|-- checkpoints
| +-- model.h5
+-- model.h5
単一ファイルを追加
以下のコードスニペットは、ローカルの単一ファイルをアーティファクトに追加する方法を示しています。
# 単一のファイルを追加
artifact. add_file(local_path= "path/file.format" )
たとえば、作業中のローカルディレクトリに 'file.txt' というファイルがあるとします。
artifact. add_file("path/file.txt" ) # `file.txt` として追加されました
アーティファクトは次の内容を持つようになります。
file.txt
オプションで、アーティファクト内の name パラメータの希望するパスを渡して下さい。
artifact. add_file(local_path= "path/file.format" , name= "new/path/file.format" )
アーティファクトは次のように保存されます。
new/path/file.txt
API Call
Resulting artifact
artifact.add_file('model.h5')model.h5
artifact.add_file('checkpoints/model.h5')model.h5
artifact.add_file('model.h5', name='models/mymodel.h5')models/mymodel.h5
複数ファイルを追加
以下のコードスニペットは、ローカルのディレクトリ全体をアーティファクトに追加する方法を示しています。
# ディレクトリを再帰的に追加
artifact. add_dir(local_path= "path/file.format" , name= "optional-prefix" )
以下の API 呼び出しは、以下のアーティファクトコンテンツを生成します。
API Call
Resulting artifact
artifact.add_dir('images')cat.png
dog.png
artifact.add_dir('images', name='images')images/cat.png
images/dog.png
artifact.new_file('hello.txt')hello.txt
URI リファレンスを追加
アーティファクトは、URI が W&B ライブラリが扱えるスキームを持つ場合、再現性のためにチェックサムやその他の情報をトラッキングします。
add_reference'uri' 文字列を自分の URI で置き換えてください。オプションで、アーティファクト内の name パラメータの希望するパスを渡して下さい。
# URI リファレンスを追加
artifact. add_reference(uri= "uri" , name= "optional-name" )
現在、アーティファクトは以下の URI スキームをサポートしています。
http(s)://: HTTP 上でアクセス可能なファイルへのパス。HTTP サーバーが ETag や Content-Length レスポンスヘッダーをサポートしている場合、アーティファクトはエタグとサイズメタデータの形でチェックサムをトラッキングします。s3://: S3 内のオブジェクトまたはオブジェクトプレフィックスへのパス。アーティファクトは、参照されたオブジェクトのためのチェックサムとバージョン管理情報（バケットにオブジェクトバージョン管理が有効になっている場合）をトラッキングします。オブジェクトプレフィックスは、プレフィックスの下にあるオブジェクトを最大 10,000 個まで含むように展開されます。gs://: GCS 内のオブジェクトまたはオブジェクトプレフィックスへのパス。アーティファクトは、参照されたオブジェクトのためのチェックサムとバージョン管理情報（バケットにオブジェクトバージョン管理が有効になっている場合）をトラッキングします。オブジェクトプレフィックスは、プレフィックスの下にあるオブジェクトを最大 10,000 個まで含むように展開されます。
以下の API 呼び出しは、以下のアーティファクトを生成します。
API call
Resulting artifact contents
artifact.add_reference('s3://my-bucket/model.h5')model.h5
artifact.add_reference('s3://my-bucket/checkpoints/model.h5')model.h5
artifact.add_reference('s3://my-bucket/model.h5', name='models/mymodel.h5')models/mymodel.h5
artifact.add_reference('s3://my-bucket/images')cat.png
dog.png
artifact.add_reference('s3://my-bucket/images', name='images')images/cat.png
images/dog.png
並行実行からアーティファクトにファイルを追加
大規模な datasets または分散トレーニングの場合、複数の並行 run が単一のアーティファクトに貢献する必要があるかもしれません。
import wandb
import time
# デモンストレーションのために、run を並行して起動するために ray を使用します。
# 並行 run は任意の方法で調整できます。
import ray
ray. init()
artifact_type = "dataset"
artifact_name = "parallel-artifact"
table_name = "distributed_table"
parts_path = "parts"
num_parallel = 5
# 並行ライターの各バッチは、その独自の
# グループ名を持つ必要があります。
group_name = "writer-group- {} " . format(round(time. time()))
@ray.remote
def train (i):
"""
各ライターは、アーティファクトに 1 つの画像を追加します。
"""
with wandb. init(group= group_name) as run:
artifact = wandb. Artifact(name= artifact_name, type= artifact_type)
# wandb テーブルにデータを追加します。この場合、例としてデータを使用します。
table = wandb. Table(columns= ["a" , "b" , "c" ], data= [[i, i * 2 , 2 ** i]])
# アーティファクト内のフォルダーにテーブルを追加します。
artifact. add(table, " {} /table_ {} " . format(parts_path, i))
# アーティファクトをアップサーティングすることで、アーティファクトにデータを作成または追加します。
run. upsert_artifact(artifact)
# 並行して run を起動
result_ids = [train. remote(i) for i in range(num_parallel)]
# ファイルがアーティファクトに追加されたことを確認するために
# すべてのライターを待機します。
ray. get(result_ids)
# すべてのライターが終了したら、アーティファクトを終了して
# 使用可能であることをマークします。
with wandb. init(group= group_name) as run:
artifact = wandb. Artifact(artifact_name, type= artifact_type)
# "PartitionTable" を作成し、フォルダーのテーブルを指すようにして
# アーティファクトに追加します。
artifact. add(wandb. data_types. PartitionedTable(parts_path), table_name)
# アーティファクトを終了することで、このバージョンへの
# 将来の"upserts"を禁止します。
run. finish_artifact(artifact)
4.1.2 - アーティファクトをダウンロードして使用する
複数の Projects から Artifacts をダウンロードして使用する。
すでに W&B サーバーに保存されているアーティファクトをダウンロードして使用するか、アーティファクト オブジェクトを構築して、必要に応じて重複排除のためにそれを渡します。
閲覧専用シートのチームメンバーは、アーティファクトをダウンロードできません。
W&B に保存されているアーティファクトをダウンロードして使用する
W&B に保存されているアーティファクトを W&B Run の内外でダウンロードして使用します。Public API（wandb.ApiPublic API Reference guide を参照してください。
During a run
Outside of a run
W&B CLI
まず、W&B Python SDK をインポートします。次に、W&B Run を作成します。
import wandb
run = wandb. init(project= "<example>" , job_type= "<job-type>" )
使用したいアーティファクトを use_artifact'bike-dataset' というアーティファクトを 'latest' というエイリアスで指定しています。
artifact = run. use_artifact("bike-dataset:latest" )
戻されたオブジェクトを使って、アーティファクトの内容をすべてダウンロードします。
datadir = artifact. download()
アーティファクトの内容を特定のディレクトリーにダウンロードするには、root パラメータにパスをオプションで渡すことができます。詳細については、Python SDK Reference Guide を参照してください。
get_path
path = artifact. get_path(name)
これにより、パス name のファイルのみが取得されます。次のメソッドを持つ Entry オブジェクトが返されます。
Entry.download: パス name のアーティファクトからファイルをダウンロードEntry.ref: add_reference がエントリーを参照として保存している場合、URI を返します。
W&B が処理方法を知っているスキームを持つ参照は、アーティファクトファイルと同様にダウンロードされます。詳細については、Track external files を参照してください。
まず、W&B SDK をインポートします。次に、Public API クラスからアーティファクトを作成します。エンティティ、プロジェクト、アーティファクト、およびエイリアスをそのアーティファクトに関連付けます。
import wandb
api = wandb. Api()
artifact = api. artifact("entity/project/artifact:alias" )
戻されたオブジェクトを使って、アーティファクトの内容をダウンロードします。
アーティファクトの内容を特定のディレクトリーにダウンロードするために root パラメータにパスをオプションで渡すことができます。詳細については、API Reference Guide を参照してください。
wandb artifact get コマンドを使用して、W&B サーバーからアーティファクトをダウンロードします。
$ wandb artifact get project/artifact:alias --root mnist/
アーティファクトの一部をダウンロード
プレフィックスを基にアーティファクトの一部をダウンロードすることができます。path_prefix パラメータを使用して、単一のファイルまたはサブフォルダーの内容をダウンロードします。
artifact = run. use_artifact("bike-dataset:latest" )
artifact. download(path_prefix= "bike.png" ) # bike.png のみをダウンロード
または、特定のディレクトリーからファイルをダウンロードすることもできます。
artifact. download(path_prefix= "images/bikes/" ) # images/bikes ディレクトリー内のファイルをダウンロード
別のプロジェクトからアーティファクトを使用する
アーティファクトの名前とともにそのプロジェクト名を指定して、アーティファクトを参照します。また、エンティティ名でアーティファクトの名前を指定して、エンティティを超えてアーティファクトを参照することもできます。
次のコード例は、現在の W&B run に他のプロジェクトからのアーティファクトを入力としてクエリする方法を示しています。
import wandb
run = wandb. init(project= "<example>" , job_type= "<job-type>" )
# 他のプロジェクトからアーティファクトを W&B でクエリして、それを入力として
# この run にマークします。
artifact = run. use_artifact("my-project/artifact:alias" )
# 別のエンティティからアーティファクトを使用し、それを入力として
# この run にマークします。
artifact = run. use_artifact("my-entity/my-project/artifact:alias" )
アーティファクトを同時に構築して使用する
アーティファクトを同時に構築して使用します。アーティファクト オブジェクトを作成して、それを use_artifact に渡します。これにより、W&B にアーティファクトが存在しない場合は作成されます。use_artifact
import wandb
artifact = wandb. Artifact("reference model" )
artifact. add_file("model.h5" )
run. use_artifact(artifact)
アーティファクトの構築に関する詳細については、Construct an artifact を参照してください。
4.1.3 - アーティファクトを更新する
既存のアーティファクトを W&B run の内外で更新します。
アーティファクトの description、metadata、および alias に希望する値を渡します。W&B サーバー上でアーティファクトを更新するには、save() メソッドを呼び出してください。W&B Run の間または Run の外でアーティファクトを更新することができます。
W&B Public API (wandb.Apiwandb.Artifact
Model Registry にリンクされたアーティファクトのエイリアスを更新することはできません。
During a run
Outside of a run
With collections
次のコード例は、wandb.Artifact
import wandb
run = wandb. init(project= "<example>" )
artifact = run. use_artifact("<artifact-name>:<alias>" )
artifact. description = "<description>"
artifact. save()
次のコード例は、wandb.Api API を使用してアーティファクトの説明を更新する方法を示しています。
import wandb
api = wandb. Api()
artifact = api. artifact("entity/project/artifact:alias" )
# 説明を更新する
artifact. description = "My new description"
# メタデータキーを選択的に更新する
artifact. metadata["oldKey" ] = "new value"
# メタデータを完全に置き換える
artifact. metadata = {"newKey" : "new value" }
# エイリアスを追加する
artifact. aliases. append("best" )
# エイリアスを削除する
artifact. aliases. remove("latest" )
# エイリアスを完全に置き換える
artifact. aliases = ["replaced" ]
# すべてのアーティファクトの変更を保存する
artifact. save()
詳細は、Weights and Biases Artifact API を参照してください。
コレクションも単一のアーティファクトと同様に更新することができます。
import wandb
run = wandb. init(project= "<example>" )
api = wandb. Api()
artifact = api. artifact_collection(type= "<type-name>" , collection= "<collection-name>" )
artifact. name = "<new-collection-name>"
artifact. description = "<This is where you'd describe the purpose of your collection.>"
artifact. save()
詳細は Artifacts Collection リファレンスを参照してください。
4.1.4 - アーティファクトのエイリアスを作成する
W&B アーティファクトのカスタムエイリアスを作成します。
エイリアスを特定のバージョンへのポインターとして使用します。デフォルトでは、Run.log_artifact はログされたバージョンに latest エイリアスを追加します。
アーティファクトバージョン v0 は、アーティファクトを初めてログする際に作成され、アーティファクトに付随します。W&B は、同じアーティファクトに再度ログを行うときにコンテンツのチェックサムを行います。アーティファクトが変更された場合、W&B は新しいバージョン v1 を保存します。
例えば、トレーニングスクリプトがデータセットの最新バージョンを取得する場合、そのアーティファクトを使用するときに latest を指定します。次のコード例は、エイリアス latest を持つデータセットアーティファクト bike-dataset をダウンロードする方法を示しています。
import wandb
run = wandb. init(project= "<example-project>" )
artifact = run. use_artifact("bike-dataset:latest" )
artifact. download()
アーティファクトバージョンにカスタムエイリアスを適用することもできます。例えば、モデルのチェックポイントがメトリック AP-50 で最高であることを示すために、文字列 'best-ap50' をエイリアスとしてモデルアーティファクトにログを記録する際に追加できます。
artifact = wandb. Artifact("run-3nq3ctyy-bike-model" , type= "model" )
artifact. add_file("model.h5" )
run. log_artifact(artifact, aliases= ["latest" , "best-ap50" ])
4.1.5 - アーティファクト バージョンを作成する
新しいアーティファクト バージョンを単一の run または分散プロセスから作成します。
新しいアーティファクトバージョンをシングル run で作成するか、分散 run を使って共同で作成します。以前のバージョンから新しいアーティファクトバージョンを作成することもできます。これを インクリメンタルアーティファクト と呼びます。
アーティファクト内のファイルの一部に変更を加える必要がある場合、元のアーティファクトのサイズがかなり大きい場合は、インクリメンタルアーティファクトを作成することをお勧めします。
新しいアーティファクトバージョンをゼロから作成する
新しいアーティファクトバージョンを作成する方法は、シングル run と分散 run による2つがあります。それぞれ次のように定義されています:
シングル run : シングル run が新しいバージョンのすべてのデータを提供します。これは最も一般的なケースで、run が必要なデータを完全に再現する場合に最適です。例: 保存されたモデルやモデル予測を分析用のテーブルに出力する。分散 run : 複数の run のセットが共同して新しいバージョンのすべてのデータを提供します。これは、複数の run が並行してデータを生成する分散ジョブに最適です。例: モデルを分散的に評価し、予測を出力する。
W&B は、プロジェクト内に存在しない名前を wandb.Artifact API に渡すと、新しいアーティファクトを作成し、それに v0 エイリアスを割り当てます。同じアーティファクトに再度ログを記録する際に内容をチェックサムします。アーティファクトが変更されている場合、W&B は新しいバージョン v1 を保存します。
プロジェクト内に既存のアーティファクトと一致する名前とアーティファクトタイプを wandb.Artifact API に渡すと、W&B は既存のアーティファクトを取得します。取得されたアーティファクトはバージョンが 1 より大きくなります。
シングル run
アーティファクト内のすべてのファイルを生成するシングル run によって、新しいバージョンのアーティファクトをログします。このケースは、シングル run がアーティファクト内のすべてのファイルを生成する場合に発生します。
ユースケースに基づいて、以下のタブのいずれかを選択して、run 内または run 外で新しいアーティファクトバージョンを作成してください:
Inside a run
Outside of a run
W&B run 内でアーティファクトバージョンを作成します:
wandb.init を使って run を作成。wandb.Artifact で新しいアーティファクトを作成するか、既存のアーティファクトを取得。.add_file を使用してファイルをアーティファクトに追加。.log_artifact を使ってアーティファクトを run にログ。
with wandb. init() as run:
artifact = wandb. Artifact("artifact_name" , "artifact_type" )
# Add Files and Assets to the artifact using
# `.add`, `.add_file`, `.add_dir`, and `.add_reference`
artifact. add_file("image1.png" )
run. log_artifact(artifact)
W&B run の外でアーティファクトバージョンを作成します:
wanb.Artifact で新しいアーティファクトを作成するか、既存のアーティファクトを取得。.add_file を使用してファイルをアーティファクトに追加。.save でアーティファクトを保存。
artifact = wandb. Artifact("artifact_name" , "artifact_type" )
# Add Files and Assets to the artifact using
# `.add`, `.add_file`, `.add_dir`, and `.add_reference`
artifact. add_file("image1.png" )
artifact. save()
分散 run
バージョンをコミットする前に、複数の run が共同で作業します。これは、上記のシングル run モードとは対照的です。こちらは1つの run が新しいバージョンのすべてのデータを提供します。
コレクション内の各 run は、同じバージョンで共同作業をするために、同じユニークな ID ( distributed_id と呼ばれる) を認識している必要があります。デフォルトでは、存在する場合、W&B は run の group を、wandb.init(group=GROUP) によって設定された distributed_id として使用します。
バージョンを「コミット」し、その状態を永続的にロックする最終 run が必要です。
協調的なアーティファクトに追加するには upsert_artifact を使用し、コミットを最終的にするには finish_artifact を使用します。
以下の例を考えてみてください。異なる run (以下で Run 1 、Run 2 、Run 3 とラベル付けされている) が upsert_artifact を使って同じアーティファクトに異なる画像ファイルを追加します。
Run 1
with wandb. init() as run:
artifact = wandb. Artifact("artifact_name" , "artifact_type" )
# Add Files and Assets to the artifact using
# `.add`, `.add_file`, `.add_dir`, and `.add_reference`
artifact. add_file("image1.png" )
run. upsert_artifact(artifact, distributed_id= "my_dist_artifact" )
Run 2
with wandb. init() as run:
artifact = wandb. Artifact("artifact_name" , "artifact_type" )
# Add Files and Assets to the artifact using
# `.add`, `.add_file`, `.add_dir`, and `.add_reference`
artifact. add_file("image2.png" )
run. upsert_artifact(artifact, distributed_id= "my_dist_artifact" )
Run 3
Run 1 と Run 2 が完了した後に実行する必要があります。finish_artifact を呼び出す Run は、アーティファクトにファイルを含めることができますが、必須ではありません。
with wandb. init() as run:
artifact = wandb. Artifact("artifact_name" , "artifact_type" )
# Add Files and Assets to the artifact
# `.add`, `.add_file`, `.add_dir`, and `.add_reference`
artifact. add_file("image3.png" )
run. finish_artifact(artifact, distributed_id= "my_dist_artifact" )
既存のバージョンから新しいアーティファクトバージョンを作成する
前のアーティファクトバージョンからファイルのサブセットを追加、変更、または削除して、変更されていないファイルを再インデックスする必要はありません。前のアーティファクトバージョンからファイルのサブセットを追加、変更、または削除すると、新しいアーティファクトバージョンが作成され、これをインクリメンタルアーティファクト と呼びます。
以下は、遭遇する可能性のあるインクリメンタルな変更の各タイプに対するシナリオです:
add: 新しいバッチを収集した後、定期的にデータセットに新しいファイルのサブセットを追加します。
remove: 重複ファイルをいくつか発見し、アーティファクトからそれらを削除することを希望します。
update: ファイルのサブセットに対する注釈を修正し、古いファイルを正しいものと置き換えます。
インクリメンタルアーティファクトとしての同じ機能を実行するためにアーティファクトをゼロから作成することもできます。しかし、アーティファクトをゼロから作成する場合、アーティファクトのすべての内容をローカルディスクに持っている必要があります。インクリメンタルな変更を行う場合、前のアーティファクトバージョンのファイルを変更せずに、個々のファイルを追加、削除、または変更できます。
単一の run で、または複数の run (分散モード) でインクリメンタルアーティファクトを作成できます。
以下の手順に従って、アーティファクトをインクリメンタルに変更します:
インクリメンタル変更を行いたいアーティファクトバージョンを取得します:
Inside a run
Outside of a run
saved_artifact = run. use_artifact("my_artifact:latest" )
client = wandb. Api()
saved_artifact = client. artifact("my_artifact:latest" )
以下の方法でドラフトを作成します:
draft_artifact = saved_artifact. new_draft()
次のバージョンで見たいインクリメンタルな変更を行います。既存のエントリーを追加、削除、または変更することができます。
各変更を行うための例については、以下のいずれかのタブを選択してください:
add_file メソッドで既存のアーティファクトバージョンにファイルを追加します:
draft_artifact. add_file("file_to_add.txt" )
add_dir メソッドを使用してディレクトリを追加することで、複数のファイルを追加することもできます。
remove メソッドで既存のアーティファクトバージョンからファイルを削除します:
draft_artifact. remove("file_to_remove.txt" )
remove メソッドにディレクトリパスを渡すことで、複数のファイルを削除することもできます。
ドラフトから古い内容を削除し、新しい内容を追加することで、内容を変更または置き換えます:
draft_artifact. remove("modified_file.txt" )
draft_artifact. add_file("modified_file.txt" )
最後に、変更をログまたは保存します。以下のタブは、W&B run の内外で変更を保存する方法を示しています。適切なユースケースに応じてタブを選択してください:
Inside a run
Outside of a run
run. log_artifact(draft_artifact)
以上のコード例をまとめると、以下のようになります:
Inside a run
Outside of a run
with wandb. init(job_type= "modify dataset" ) as run:
saved_artifact = run. use_artifact(
"my_artifact:latest"
) # fetch artifact and input it into your run
draft_artifact = saved_artifact. new_draft() # create a draft version
# modify a subset of files in the draft version
draft_artifact. add_file("file_to_add.txt" )
draft_artifact. remove("dir_to_remove/" )
run. log_artifact(
artifact
) # log your changes to create a new version and mark it as output to your run
client = wandb. Api()
saved_artifact = client. artifact("my_artifact:latest" ) # load your artifact
draft_artifact = saved_artifact. new_draft() # create a draft version
# modify a subset of files in the draft version
draft_artifact. remove("deleted_file.txt" )
draft_artifact. add_file("modified_file.txt" )
draft_artifact. save() # commit changes to the draft
4.1.6 - 外部ファイルをトラックする
W&B の外部に保存されたファイルも、Amazon S3 バケット、GCS バケット、HTTP ファイルサーバー、または NFS 共有内のファイルとしてトラックできます。
リファレンスアーティファクト を使用して、Amazon S3 バケット、GCS バケット、Azure blob、HTTP ファイルサーバー、または NFS シェアなど、W&B システムの外部に保存されたファイルをトラッキングします。 W&B CLI を使用して、W&B Run の外部でアーティファクトをログします。
Run の外部でアーティファクトをログする
W&B は、run の外部でアーティファクトをログするときに run を作成します。各アーティファクトは run に属し、run はプロジェクトに属します。アーティファクト (バージョン) もコレクションに属し、タイプを持ちます。
wandb artifact putproject/artifact_name) を指定します。必要に応じて、タイプ (TYPE) を指定します。以下のコードスニペットでは、アップロードしたいアーティファクトのファイルパスに PATH を置き換えてください。
$ wandb artifact put --name project/artifact_name --type TYPE PATH
指定したプロジェクトが存在しない場合、W&B は新しいプロジェクトを作成します。アーティファクトのダウンロード方法については、アーティファクトのダウンロードと使用 を参照してください。
W&B の外部でアーティファクトをトラッキングする
W&B Artifacts をデータセットのバージョン管理やモデルのリネージに使用し、リファレンスアーティファクト を使用して W&B サーバーの外部に保存されたファイルをトラッキングします。このモードでは、アーティファクトはファイルに関するメタデータ (例えば、URL、サイズ、チェックサム) のみを保存します。基礎データはシステムから離れることはありません。ファイルとディレクトリーを W&B サーバーに保存する方法については、クイックスタート を参照してください。
以下は、リファレンスアーティファクトを作成し、それをワークフローに最適に組み込む方法を説明します。
Amazon S3 / GCS / Azure Blob Storage リファレンス
W&B Artifacts をデータセットとモデルのバージョン管理に使用して、クラウドストレージバケットでのリファレンスをトラッキングします。アーティファクトリファレンスを使用すると、既存のストレージレイアウトに変更を加えることなく、バケットの上にシームレスにトラッキングをレイヤリングできます。
Artifacts は基礎となるクラウドストレージベンダー (AWS、GCP、Azure など) を抽象化します。次のセクションで説明される情報は、Amazon S3、Google Cloud Storage、Azure Blob Storage に共通して適用されます。
W&B Artifacts は、MinIO を含む任意の Amazon S3 互換インターフェースをサポートしています。 AWS_S3_ENDPOINT_URL 環境変数を MinIO サーバーを指すように設定すれば、以下のスクリプトはそのまま動作します。
次の構造を持つバケットがあると仮定します：
s3://my-bucket
+-- datasets/
| +-- mnist/
+-- models/
+-- cnn/
mnist/ の下には、私たちのデータセットである画像のコレクションがあります。アーティファクトでそれをトラッキングしましょう：
import wandb
run = wandb. init()
artifact = wandb. Artifact("mnist" , type= "dataset" )
artifact. add_reference("s3://my-bucket/datasets/mnist" )
run. log_artifact(artifact)
デフォルトでは、W&B はオブジェクトプリフィックスを追加する際に 10,000 オブジェクトの制限を課しています。この制限は、add_reference の呼び出しで max_objects= を指定することによって調整できます。
新しいリファレンスアーティファクト mnist:latest は、通常のアーティファクトと非常に似た外観と挙動を持っています。唯一の違いは、アーティファクトが S3/GCS/Azure オブジェクトに関するメタデータ (例えば、ETag、サイズ、バージョン ID) のみを含んでいることです (バケットにオブジェクトのバージョン管理が有効になっている場合)。
W&B は、使用するクラウドプロバイダーに基づいてクレデンシャルを探すデフォルトのメカニズムを使用します。クラウドプロバイダーからのドキュメントを読み、使用されるクレデンシャルについて詳しく学びましょう。
AWS では、バケットが設定されたユーザーのデフォルトリージョンに位置していない場合、AWS_REGION 環境変数をバケットリージョンに一致させる必要があります。
このアーティファクトを通常のアーティファクトのように扱うことができます。アプリ UI では、ファイルブラウザを使用してリファレンスアーティファクトの内容を閲覧したり、完全な依存関係グラフを探索したり、アーティファクトのバージョン履歴をスキャンしたりできます。
画像、オーディオ、ビデオ、ポイントクラウドといったリッチメディアは、バケットの CORS 設定によってアプリ UI で適切にレンダリングされない可能性があります。バケットの CORS 設定で app.wandb.ai を許可リストに追加することで、アプリ UI でこれらのリッチメディアが正しくレンダリングされるようになります。
パネルは、プライベートバケットの場合アプリ UI でレンダリングされないかもしれません。もし会社が VPN を使用している場合は、VPN 内の IP をホワイトリストに追加するようにバケットのアクセスポリシーを更新できます。
リファレンスアーティファクトをダウンロードする
import wandb
run = wandb. init()
artifact = run. use_artifact("mnist:latest" , type= "dataset" )
artifact_dir = artifact. download()
W&B は、リファレンスアーティファクトをダウンロードする際に、アーティファクトがログされたときに記録されたメタデータを使用して、基となるバケットからファイルを取得します。バケットにオブジェクトのバージョン管理が有効になっている場合、W&B はアーティファクトがログされた時点のファイルの状態に対応するオブジェクトバージョンを取得します。これは、バケットの内容が進化しても、アーティファクトがトレーニングされた特定の反復にあなたのデータを指し示すことができることを意味します。アーティファクトはトレーニング時点でのバケットのスナップショットとして機能します。
ワークフローの一環としてファイルを上書きする場合は、W&B はストレージバケットの「オブジェクトバージョン管理」を有効にすることを推奨します。バケットにバージョン管理が有効になっている場合、上書きされたファイルへのリファレンスを持つアーティファクトも依然として無傷であることになります。なぜなら、古いバージョンのオブジェクトが保持されるからです。
ユースケースに基づいて、オブジェクトバージョン管理を有効にする手順をお読みください。AWS 、GCP 、Azure 。
すべてを結び付ける
次のコード例は、トレーニングジョブに供給される Amazon S3、GCS、または Azure 上のデータセットをトラッキングするために使用できる単純なワークフローを示しています：
import wandb
run = wandb. init()
artifact = wandb. Artifact("mnist" , type= "dataset" )
artifact. add_reference("s3://my-bucket/datasets/mnist" )
# アーティファクトをトラッキングし、それを
# この run の入力としてマークします。
# バケット内のファイルが変更された場合にのみ、新しい
# アーティファクトバージョンがログされます。
run. use_artifact(artifact)
artifact_dir = artifact. download()
# トレーニングをここで実行...
モデルをトラッキングするために、トレーニングスクリプトがモデルファイルをバケットにアップロードした後に、モデルアーティファクトをログできます：
import boto3
import wandb
run = wandb. init()
# トレーニングをここで実行...
s3_client = boto3. client("s3" )
s3_client. upload_file("my_model.h5" , "my-bucket" , "models/cnn/my_model.h5" )
model_artifact = wandb. Artifact("cnn" , type= "model" )
model_artifact. add_reference("s3://my-bucket/models/cnn/" )
run. log_artifact(model_artifact)
GCP または Azure のリファレンスでのアーティファクトのトラッキング方法についてのエンドツーエンドのガイドを読むには、次のレポートをご覧ください：
ファイルシステムリファレンス
データセットへの高速アクセスのためのもう一つの一般的なパターンは、NFS マウントポイントをトレーニングジョブを実行するすべてのマシンでリモートファイルシステムに公開することです。これは、クラウドストレージバケットよりもさらに簡単なソリューションになる可能性があります。トレーニングスクリプトの視点からは、ファイルはちょうどローカルファイルシステムに置かれているかのように見えるからです。幸運にも、その使いやすさは、ファイルシステムへのリファレンスをトラッキングするために Artifacts を使用する場合にも当てはまります。ファイルシステムがマウントされているかどうかに関係なくです。
次の構造を持つファイルシステムが /mount にマウントされていると仮定します：
mount
+-- datasets/
| +-- mnist/
+-- models/
+-- cnn/
mnist/ の下には、私たちのデータセットである画像のコレクションがあります。アーティファクトでそれをトラッキングしましょう：
import wandb
run = wandb. init()
artifact = wandb. Artifact("mnist" , type= "dataset" )
artifact. add_reference("file:///mount/datasets/mnist/" )
run. log_artifact(artifact)
デフォルトでは、W&B はディレクトリへのリファレンスを追加する際に 10,000 ファイルの制限を課しています。この制限は、add_reference の呼び出しで max_objects= を指定することによって調整できます。
URL のトリプルスラッシュに注目してください。最初のコンポーネントは、ファイルシステムリファレンスの使用を示す file:// プレフィックスです。二番目は、データセットのパス /mount/datasets/mnist/ です。
結果として得られるアーティファクト mnist:latest は通常のアーティファクトのように見え、機能します。唯一の違いは、アーティファクトがファイルに関するメタデータ (サイズや MD5 チェックサムなど) のみを含んでいることです。ファイル自体はシステムから離れることはありません。
このアーティファクトを通常のアーティファクトのように操作できます。UI では、ファイルブラウザを使用してリファレンスアーティファクトの内容を閲覧したり、完全な依存関係グラフを探索したり、アーティファクトのバージョン履歴をスキャンしたりできます。ただし、アーティファクト自体にデータが含まれていないため、UI では画像、オーディオなどのリッチメディアをレンダリングできません。
リファレンスアーティファクトをダウンロードするのは簡単です：
import wandb
run = wandb. init()
artifact = run. use_artifact("entity/project/mnist:latest" , type= "dataset" )
artifact_dir = artifact. download()
ファイルシステムリファレンスの場合、download() 操作は参照されたパスからファイルをコピーして、アーティファクトディレクトリを構築します。上記の例では、/mount/datasets/mnist の内容がディレクトリ artifacts/mnist:v0/ にコピーされます。アーティファクトが上書きされたファイルへのリファレンスを含む場合、download() はエラーを投げます。アーティファクトがもはや再構築できないからです。
すべてをまとめると、ここにマウントされたファイルシステムの下のデータセットをトラッキングして、トレーニングジョブに供給するために使用できる簡単なワークフローがあります：
import wandb
run = wandb. init()
artifact = wandb. Artifact("mnist" , type= "dataset" )
artifact. add_reference("file:///mount/datasets/mnist/" )
# アーティファクトをトラッキングし、それを
# この run の入力としてマークします。ディレクトリ下の
# ファイルが変更された場合にのみ、新しいアーティファクト
# バージョンがログされます。
run. use_artifact(artifact)
artifact_dir = artifact. download()
# トレーニングをここで実行...
モデルをトラッキングするために、トレーニングスクリプトがモデルファイルをマウントポイントに書き込んだ後に、モデルアーティファクトをログできます：
import wandb
run = wandb. init()
# トレーニングをここで実行...
# モデルをディスクに書き込む
model_artifact = wandb. Artifact("cnn" , type= "model" )
model_artifact. add_reference("file:///mount/cnn/my_model.h5" )
run. log_artifact(model_artifact)
4.1.7 - データを管理する
4.1.7.1 - アーティファクトデータ保持の管理
存続期間 (TTL) ポリシー
W&B の Artifacts のタイム・トゥ・リブ（TTL）ポリシーを使用して、Artifacts が W&B から削除されるスケジュールを設定します。Artifact を削除すると、W&B はそのアーティファクトを ソフト削除 としてマークします。つまり、アーティファクトは削除対象としてマークされますが、ファイルはすぐにストレージから削除されるわけではありません。W&B がアーティファクトを削除する方法の詳細については、アーティファクトを削除 ページを参照してください。
W&B アプリで Artifacts TTL を使って データ保持を管理する方法を学ぶには、この ビデオチュートリアルをご覧ください。
W&B は、モデルレジストリにリンクされたモデルアーティファクトの TTL ポリシーを設定するオプションを非アクティブ化します。これは、生産ワークフローで使用されるリンクされたモデルが誤って期限切れにならないようにするためです。
チームの設定](/ja/guides/models/app/settings-page/team-settings/)と、(1) TTL ポリシーを設定または編集できる人を許可するか、(2) チームのデフォルト TTL を設定するかなどのチームレベルの TTL 設定は、チーム管理者のみが表示およびアクセスできます。
W&B アプリ UI のアーティファクトの詳細に TTL ポリシーを設定または編集するオプションが表示されない場合、またはプログラムで TTL を設定してもアーティファクトの TTL プロパティが正常に変更されない場合は、チーム管理者が権限を付与していません。
自動生成された Artifacts
ユーザー生成のアーティファクトのみが TTL ポリシーを使用できます。W&B によって自動生成されたアーティファクトには TTL ポリシーを設定することはできません。
自動生成されたアーティファクトを示すアーティファクトタイプは次のとおりです：
run_tablecodejobwandb-* で始まる種類のアーティファクト
アーティファクトの種類は、W&B プラットフォーム またはプログラムで確認できます：
import wandb
run = wandb. init(project= "<my-project-name>" )
artifact = run. use_artifact(artifact_or_name= "<my-artifact-name>" )
print(artifact. type)
含まれる <> で囲まれた値をあなたのものに置き換えてください。
TTL ポリシーを編集および設定できる人を定義する
チーム内で TTL ポリシーを設定および編集できる人を定義します。TTL 許可をチーム管理者のみに与えることもできますし、チーム管理者とチームメンバーの両方に TTL 許可を与えることもできます。
TTL ポリシーを設定または編集できる人を定義できるのはチーム管理者だけです。
チームのプロフィールページに移動します。
設定 タブを選択します。Artifacts のタイム・トゥ・リブ (TTL) セクション に移動します。TTL 許可のドロップダウン から、TTL ポリシーを設定および編集できる人を選択します。設定をレビューして保存 をクリックします。変更を確認し、設定を保存 を選択します。
TTL ポリシーを作成する
アーティファクトを作成するとき、または作成後に TTL ポリシーを設定します。
以下のコードスニペットすべてにおいて、 <> で包まれた内容をあなたの情報に置き換えてコードスニペットを使用してください。
アーティファクト作成時に TTL ポリシーを設定する
W&B Python SDK を使用してアーティファクトを作成する際に TTL ポリシーを定義します。TTL ポリシーは通常日数で定義されます。
アーティファクト作成時に TTL ポリシーを定義することは、通常の
アーティファクトを作成 する方法に似ています。例外は、アーティファクトの
ttl 属性に時間差を渡す点です。
手順は次のとおりです：
アーティファクトを作成 します。ファイル、ディレクトリ、または参照など、アーティファクトにコンテンツを追加 します。
Python の標準ライブラリの一部である datetime.timedelta
アーティファクトをログ します。
以下のコードスニペットはアーティファクトを作成し、TTL ポリシーを設定する方法を示しています。
import wandb
from datetime import timedelta
run = wandb. init(project= "<my-project-name>" , entity= "<my-entity>" )
artifact = wandb. Artifact(name= "<artifact-name>" , type= "<type>" )
artifact. add_file("<my_file>" )
artifact. ttl = timedelta(days= 30 ) # TTL ポリシーを設定
run. log_artifact(artifact)
上記のコードスニペットは、アーティファクトの TTL ポリシーを 30 日間に設定します。つまり、W&B は 30 日後にアーティファクトを削除します。
アーティファクト作成後に TTL ポリシーを設定または編集する
存在するアーティファクトに対して W&B アプリの UI または W&B Python SDK を使用して TTL ポリシーを定義します。
アーティファクトの TTL を変更する場合、アーティファクトの期限切れまでの時間は、アーティファクトの作成時刻 (createdAt タイムスタンプ) を基に計算されます。
あなたのアーティファクトを取得 します。アーティファクトの ttl 属性に時間差を渡します。
save
以下のコードスニペットは、アーティファクトに TTL ポリシーを設定する方法を示しています：
import wandb
from datetime import timedelta
artifact = run. use_artifact("<my-entity/my-project/my-artifact:alias>" )
artifact. ttl = timedelta(days= 365 * 2 ) # 2年後に削除
artifact. save()
上記のコード例では、TTL ポリシーを2年間に設定します。
W&B アプリ UI の W&B プロジェクトに移動します。
左のパネルでアーティファクトアイコンを選択します。
アーティファクトの一覧からアーティファクトタイプを展開します。
TTL ポリシーを編集したいアーティファクトバージョンを選択します。
バージョン タブをクリックします。ドロップダウンから TTL ポリシー編集 を選択します。
表示されるモーダル内で、TTL ポリシードロップダウンから カスタム を選択します。
TTL 期間 フィールドで、日数単位で TTL ポリシーを設定します。TTL 更新 ボタンを選択して変更を保存します。
チームのデフォルト TTL ポリシーを設定する
チームのデフォルト TTL ポリシーを設定できるのはチーム管理者だけです。
チームのデフォルト TTL ポリシーを設定します。デフォルトの TTL ポリシーは、既存と今後のアーティファクトすべてに、その作成日を基に適用されます。バージョンレベルで既に TTL ポリシーが存在するアーティファクトは、チームのデフォルト TTL に影響を受けません。
チームのプロフィールページに移動します。
設定 タブを選択します。Artifacts のタイム・トゥ・リブ (TTL) セクション に移動します。チームのデフォルト TTL ポリシー設定 をクリックします。期間 フィールドにおいて、日数単位で TTL ポリシーを設定します。設定をレビューして保存 をクリックします。変更を確認し、設定を保存 を選択します。
run 外で TTL ポリシーを設定する
公開 API を使って run を取得せずにアーティファクトを取得し、TTL ポリシーを設定します。TTL ポリシーは通常日数単位で定義されます。
以下のコードサンプルは、公開 API を使用してアーティファクトを取得し、TTL ポリシーを設定する方法を示しています。
api = wandb. Api()
artifact = api. artifact("entity/project/artifact:alias" )
artifact. ttl = timedelta(days= 365 ) # 1年後削除
artifact. save()
TTL ポリシーを非アクティブにする
W&B Python SDK または W&B アプリ UI を使用して、特定のアーティファクトバージョンの TTL ポリシーを非アクティブにします。
あなたのアーティファクトを取得 します。アーティファクトの ttl 属性を None に設定します。
save
以下のコードスニペットは、アーティファクトに対する TTL ポリシーをオフにする方法を示しています：
artifact = run. use_artifact("<my-entity/my-project/my-artifact:alias>" )
artifact. ttl = None
artifact. save()
W&B アプリ UI の W&B プロジェクトに移動します。
左パネルでアーティファクトアイコンを選択します。
アーティファクトのリストからアーティファクトタイプを展開します。
TTL ポリシーを編集したいアーティファクトバージョンを選択します。
バージョンタブをクリックします。
リンク先レジストリ ボタンの隣にある肉球 UI アイコンをクリックします。ドロップダウンから TTL ポリシー編集 を選択します。
表示されるモーダル内で、TTL ポリシードロップダウンから 非アクティブ を選択します。
変更を保存するために TTL 更新 ボタンを選択します。
TTL ポリシーを確認する
W&B Python SDK または W&B アプリ UI を使用して、アーティファクトの TTL ポリシーを確認します。
print 文を使用してアーティファクトの TTL ポリシーを表示します。以下の例では、アーティファクトを取得してその TTL ポリシーを表示する方法を示しています：
artifact = run. use_artifact("<my-entity/my-project/my-artifact:alias>" )
print(artifact. ttl)
W&B アプリ UI を使用してアーティファクトの TTL ポリシーを表示します。
W&B アプリの https://wandb.ai に移動します。
あなたの W&B プロジェクトに移動します。
プロジェクト内で、左のサイドバーの Artifacts タブを選択します。
コレクションをクリックします。
選択されたコレクション内のすべてのアーティファクトが表示されます。Time to Live 列にそのアーティファクトに割り当てられた TTL ポリシーが表示されます。
4.1.7.2 - アーティファクトのストレージとメモリの割り当てを管理する
W&B アーティファクトのストレージやメモリ割り当てを管理します。
W&B は、アーティファクトファイルを米国にある Google Cloud Storage のプライベートバケットにデフォルトで保存します。すべてのファイルは、静止時および転送中に暗号化されています。
機密性の高いファイルには、プライベートホスティング の設定や参照アーティファクト の使用をお勧めします。
トレーニング中、W&B はログ、アーティファクト、および設定ファイルを以下のローカルディレクトリーにローカル保存します：
File
Default location
To change default location set:
logs
./wandbwandb.init の dir または WANDB_DIR 環境変数を設定
artifacts
~/.cache/wandbWANDB_CACHE_DIR 環境変数を設定
configs
~/.config/wandbWANDB_CONFIG_DIR 環境変数を設定
ステージング用アーティファクトのアップロード
~/.cache/wandb-data/WANDB_DATA_DIR 環境変数を設定
ダウンロードされたアーティファクト
./artifactsWANDB_ARTIFACT_DIR 環境変数を設定
W&B を設定するための環境変数の完全なガイドについては、環境変数リファレンス を参照してください。
wandb が初期化されたマシンによっては、これらのデフォルトフォルダーがファイルシステムの書き込み可能な部分にない場合があります。これによりエラーが発生する可能性があります。
ローカルのアーティファクトキャッシュをクリーンアップする
W&B は、共通ファイルを共有するバージョン間でダウンロードを高速化するためにアーティファクトファイルをキャッシュします。時間の経過とともに、このキャッシュディレクトリーは大きくなる可能性があります。キャッシュを整理し、最近使用されていないファイルを削除するために、wandb artifact cache cleanup
以下のコードスニペットは、キャッシュサイズを1GBに制限する方法を示しています。コードスニペットをコピーしてターミナルに貼り付けてください：
$ wandb artifact cache cleanup 1GB
4.1.7.3 - アーティファクトを削除する
アプリ UI を使って対話的に、または W&B SDK を使用してプログラムでアーティファクトを削除します。
アーティファクトは、App UI でインタラクティブに削除するか、W&B SDK でプログラム的に削除できます。アーティファクトを削除すると、W&B はそのアーティファクトをソフト削除 としてマークします。つまり、そのアーティファクトは削除予定としてマークされますが、ファイルはすぐにはストレージから削除されません。
アーティファクトの内容は、定期的に実行されるガベージコレクション プロセスが削除対象としてマークされたすべてのアーティファクトをレビューするまで、ソフト削除または削除保留状態のままです。ガベージコレクションプロセスは、アーティファクトおよびその関連ファイルが以前または後のアーティファクトバージョンで使用されていない場合、関連ファイルをストレージから削除します。
このページのセクションでは、特定のアーティファクトバージョンの削除方法、アーティファクトコレクションの削除方法、エイリアスを持つアーティファクトの削除方法、エイリアスがないアーティファクトの削除方法などについて説明します。アーティファクトが W&B から削除される時間を TTL ポリシーでスケジュールできます。詳細については、Artifact TTL ポリシーによるデータ保持の管理 を参照してください。
TTL ポリシーで削除予定のアーティファクト、W&B SDK で削除されたアーティファクト、または W&B App UI で削除されたアーティファクトは、最初にソフト削除されます。ソフト削除されたアーティファクトは、最終的にハード削除される前にガベージコレクションを受けます。
アーティファクトバージョンの削除
アーティファクトバージョンを削除するには:
アーティファクトの名前を選択します。これにより、アーティファクトビューが拡張され、そのアーティファクトに関連付けられたすべてのアーティファクトバージョンが一覧表示されます。
アーティファクトのリストから、削除したいアーティファクトバージョンを選択します。
ワークスペースの右側にあるケバブドロップダウンを選択します。
「Delete」を選択します。
アーティファクトバージョンは、delete() メソッドを使用してプログラム的にも削除できます。以下の例を参照してください。
エイリアスを持つ複数のアーティファクトバージョンの削除
次のコード例は、エイリアスを持つアーティファクトを削除する方法を示しています。アーティファクトを作成したエンティティ、プロジェクト名、および run ID を指定してください。
import wandb
run = api. run("entity/project/run_id" )
for artifact in run. logged_artifacts():
artifact. delete()
アーティファクトに 1 つ以上のエイリアスがある場合、delete_aliases パラメータをブール値 True に設定してエイリアスを削除します。
import wandb
run = api. run("entity/project/run_id" )
for artifact in run. logged_artifacts():
# delete_aliases=True を設定して、
# エイリアスを 1 つ以上持つアーティファクトを削除します
artifact. delete(delete_aliases= True )
特定のエイリアスを持つ複数のアーティファクトバージョンを削除
以下のコードは、特定のエイリアスを持つ複数のアーティファクトバージョンを削除する方法を示しています。アーティファクトを作成したエンティティ、プロジェクト名、および run ID を指定します。削除ロジックは独自のものに置き換えてください:
import wandb
runs = api. run("entity/project_name/run_id" )
# 'v3' および 'v4' のエイリアスを持つアーティファクトを削除
for artifact_version in runs. logged_artifacts():
# 独自の削除ロジックに置き換えます。
if artifact_version. name[- 2 :] == "v3" or artifact_version. name[- 2 :] == "v4" :
artifact. delete(delete_aliases= True )
エイリアスを持たないアーティファクトのすべてのバージョンを削除
次のコードスニペットは、エイリアスを持たないアーティファクトのすべてのバージョンを削除する方法を示しています。wandb.Api の project および entity キーにプロジェクト名とエンティティの名前をそれぞれ指定してください。<> をアーティファクトの名前に置き換えてください:
import wandb
# wandb.Api メソッドを使用する際に、エンティティとプロジェクト名を指定してください。
api = wandb. Api(overrides= {"project" : "project" , "entity" : "entity" })
artifact_type, artifact_name = "<>" # タイプと名前を指定
for v in api. artifact_versions(artifact_type, artifact_name):
# 'latest' などのエイリアスを持たないバージョンをクリーンアップします。
# 注意: ここには任意の削除ロジックを置くことができます。
if len(v. aliases) == 0 :
v. delete()
アーティファクトコレクションの削除
アーティファクトコレクションを削除するには:
削除したいアーティファクトコレクションに移動し、その上にカーソルを合わせます。
アーティファクトコレクション名の横にあるケバブドロップダウンを選択します。
「Delete」を選択します。
アーティファクトコレクションは、delete() メソッドを使用してプログラムで削除することもできます。wandb.Api の project および entity キーにプロジェクト名とエンティティの名前を指定してください:
import wandb
# wandb.Api メソッドを使用する際に、エンティティとプロジェクト名を指定してください。
api = wandb. Api(overrides= {"project" : "project" , "entity" : "entity" })
collection = api. artifact_collection(
"<artifact_type>" , "entity/project/artifact_collection_name"
)
collection. delete()
W&B がホストされている方法に基づいたガベージコレクションの有効化方法
W&B の共有クラウドを使用している場合、ガベージコレクションはデフォルトで有効です。W&B をホストする方法に基づいて、ガベージコレクションを有効にするために追加の手順が必要な場合があります。これには以下が含まれます:
以下の表は、デプロイメントタイプに基づいてガベージコレクションを有効にするための要件を満たす方法を説明しています。
X は要件を満たす必要があることを示します:
注意
セキュアストレージコネクタは現在、Google Cloud Platform および Amazon Web Services のみで利用可能です。
4.1.8 - アーティファクトグラフの探索
W&B アーティファクト の自動生成された有向非巡回グラフを トラバース します。
W&B は、特定の run がログしたアーティファクトや、その run が利用したアーティファクトを自動で追跡します。これらのアーティファクトには、データセットやモデル、評価結果、その他が含まれることがあります。機械学習ライフサイクル全体で生成されたさまざまなアーティファクトを追跡および管理するために、アーティファクトのリネージを探索できます。
リネージ
アーティファクトのリネージを追跡することには、いくつかの主要な利点があります：
再現性: すべてのアーティファクトのリネージを追跡することで、チームは実験やモデル、結果を再現でき、デバッグ、実験、および機械学習モデルの検証に不可欠です。
バージョン管理: アーティファクトのリネージには、アーティファクトのバージョン管理とその変更の追跡が含まれます。必要に応じて、チームはデータやモデルの以前のバージョンに戻すことができます。
監査: アーティファクトとその変換の詳細な履歴を持つことで、組織は規制やガバナンスの要件に準拠できます。
コラボレーションと知識共有: アーティファクトのリネージは、試行された記録が明確に示されており、何がうまくいって何がうまくいかなかったかを提供することで、チームメンバー間のより良いコラボレーションを促進します。これにより、努力の重複を避け、開発プロセスを加速させます。
アーティファクトのリネージを見つける
Artifacts タブでアーティファクトを選択すると、アーティファクトのリネージを見ることができます。このグラフビューは、パイプラインの全体的な概要を示します。
アーティファクトグラフを見るには：
W&B App UI でプロジェクトに移動します。
左のパネルでアーティファクトアイコンを選びます。
Lineage を選択します。
リネージグラフのナビゲート
指定したアーティファクトやジョブタイプは、その名前の前に表示され、アーティファクトは青のアイコン、Runs は緑のアイコンで表されます。矢印は、グラフ上での run またはアーティファクトの入力と出力を示します。
アーティファクトのタイプと名前は、左のサイドバーと Lineage タブの両方で確認できます。
より詳細なビューを得るために、個別のアーティファクトまたは run をクリックして、特定のオブジェクトに関する詳細情報を取得します。
アーティファクトクラスター
グラフのあるレベルに run またはアーティファクトが5つ以上ある場合、クラスターが作成されます。クラスターには、特定のバージョンの run またはアーティファクトを見つけるための検索バーがあり、クラスター内のノードを個別にプルしてそのリネージを調査することができます。
ノードをクリックすると、そのノードのプレビューが表示され、概要が示されます。矢印をクリックすると、個別の run またはアーティファクトが抽出され、抽出されたノードのリネージを調べることができます。
API を使用してリネージを追跡する
W&B API を使用してグラフをナビゲートすることもできます。
まず run を wandb.init で作成します。次に、wandb.Artifact で新しいアーティファクトを作成するか、既存のアーティファクトを取得します。次に、.add_file を使用してアーティファクトにファイルを追加します。最後に、.log_artifact でアーティファクトを run にログします。完成したコードは次のようになります：
with wandb. init() as run:
artifact = wandb. Artifact("artifact_name" , "artifact_type" )
# `.add`, `.add_file`, `.add_dir`, `.add_reference` を使用して
# アーティファクトにファイルやアセットを追加します
artifact. add_file("image1.png" )
run. log_artifact(artifact)
アーティファクトオブジェクトの logged_byused_by
# アーティファクトからグラフを上下にたどります：
producer_run = artifact. logged_by()
consumer_runs = artifact. used_by()
次のステップ
4.1.9 - アーティファクトのデータプライバシーとコンプライアンス
デフォルトで W&B ファイルが保存される場所を学びましょう。機密情報の保存方法について探索します。
ファイルは、Artifacts をログするときに W&B が管理する Google Cloud バケットにアップロードされます。バケットの内容は、保存中および転送中の両方で暗号化されます。Artifact ファイルは、対応するプロジェクトへのアクセス権を持つユーザーにのみ表示されます。
アーティファクトのバージョンを削除すると、そのバージョンはデータベースでソフト削除としてマークされ、ストレージコストからも除外されます。アーティファクト全体を削除すると、それは完全削除のためにキューに入れられ、その内容はすべて W&B バケットから削除されます。ファイル削除に関する特定のニーズがある場合は、Customer Support にお問い合わせください。
マルチテナント環境に存在できない機密データセットには、クラウドバケットに接続されたプライベート W&B サーバーまたは reference artifacts を使用することができます。Reference artifacts は、ファイル内容を W&B に送信せずに、プライベートバケットへの参照を追跡します。Reference artifacts は、バケットやサーバー上のファイルへのリンクを維持します。つまり、W&B はファイルそのものではなく、ファイルに関連するメタデータのみを追跡します。
リファレンスアーティファクトは、通常のアーティファクトを作成する方法と似ています。
import wandb
run = wandb. init()
artifact = wandb. Artifact("animals" , type= "dataset" )
artifact. add_reference("s3://my-bucket/animals" )
代替案については、contact@wandb.com にお問い合わせいただき、プライベートクラウドおよびオンプレミスのインストールについてご相談ください。
4.1.10 - チュートリアル: データセットアーティファクトを作成、追跡、利用する方法
アーティファクト クイックスタートでは、W&B でデータセット アーティファクトを作成、追跡、使用する方法を示します。
このウォークスルーでは、W&B Runs からデータセットアーティファクトを作成、追跡、使用する方法を示します。
1. W&B にログイン
W&B ライブラリをインポートし、W&B にログインします。まだアカウントをお持ちでない場合は、無料の W&B アカウントにサインアップする必要があります。
import wandb
wandb. login()
2. Run を初期化
wandb.init()
# W&B Run を作成します。この例ではデータセットアーティファクトを作成する方法を示しているので、
# ジョブタイプとして 'dataset' を指定します。
run = wandb. init(project= "artifacts-example" , job_type= "upload-dataset" )
3. アーティファクト オブジェクトを作成
wandb.Artifact()name と type パラメータとして指定します。
例えば、次のコードスニペットは ‘bicycle-dataset’ という名前で、‘dataset’ というラベルのアーティファクトを作成する方法を示しています。
artifact = wandb. Artifact(name= "bicycle-dataset" , type= "dataset" )
アーティファクトの構築方法の詳細については、Construct artifacts を参照してください。
データセットをアーティファクトに追加
ファイルをアーティファクトに追加します。一般的なファイルタイプには Models や Datasets が含まれます。次の例では、ローカルマシンに保存されている dataset.h5 というデータセットをアーティファクトに追加します。
# ファイルをアーティファクトのコンテンツに追加
artifact. add_file(local_path= "dataset.h5" )
上記のコードスニペットのファイル名 dataset.h5 は、アーティファクトに追加したいファイルのパスに置き換えてください。
4. データセットをログ
W&B Run オブジェクトの log_artifact() メソッドを使用して、アーティファクトバージョンを保存し、アーティファクトを run の出力として宣言します。
# アーティファクトバージョンを W&B に保存し、
# この run の出力としてマークします
run. log_artifact(artifact)
アーティファクトをログする際、’latest’ エイリアスがデフォルトで作成されます。アーティファクトのエイリアスとバージョンに関する詳細については、Create a custom alias および Create new artifact versions をそれぞれ参照してください。
5. アーティファクトをダウンロードして使用
次のコード例では、ログされ保存されたアーティファクトを W&B サーバーで使用する手順を示します。
まず、wandb.init().
次に、run オブジェクトの use_artifact()
最後に、アーティファクトの download()
# W&B Run を作成します。ここでは 'training' を 'type' として指定します
# この run をトレーニングの追跡に使用するためです。
run = wandb. init(project= "artifacts-example" , job_type= "training" )
# W&B にアーティファクトを検索させ、この run の入力としてマークします
artifact = run. use_artifact("bicycle-dataset:latest" )
# アーティファクトの内容をダウンロードします
artifact_dir = artifact. download()
または、Public API (wandb.Api) を使用して、Run の外で W&B に既に保存されたデータをエクスポート（または更新）できます。詳細は Track external files を参照してください。
4.2 - Secrets
W&B のシークレットの概要、それらがどのように機能するか、そして使用を開始する方法。
W&B Secret Manager を使用すると、シークレット （アクセストークン、ベアラートークン、APIキー、またはパスワードなどの機密文字列）を安全かつ集中管理して注入することができます。W&B Secret Manager は、シークレットをコードや Webhook のヘッダー、または ペイロード に直接追加する必要をなくします。
シークレットは各チームの Secret Manager のチーム シークレット セクションで保存および管理されます。チーム設定 で確認できます。
W&B 管理者のみがシークレットを作成、編集、または削除することができます。
シークレットは W&B の主要部分として含まれており、Azure、GCP、または AWS でホストする W&Bサーバー デプロイメント にも含まれます。別のデプロイメント タイプを使用している場合、W&B アカウント チームに連絡して W&B でシークレットを使用する方法を相談してください。
W&B サーバーでは、セキュリティニーズを満たすセキュリティ対策を設定する責任があります。
W&B は、AWS、GCP、または Azure が提供するクラウドプロバイダーのシークレット マネージャーに W&B インスタンスでシークレットを保存することを強くお勧めします。これらは高度なセキュリティ機能で設定されています。
W&B は、Kubernetes クラスターをシークレットストアのバックエンドとして使用することをお勧めしません。唯一の選択肢であり、セキュリティ上の脆弱性を防ぐ方法を理解している場合を除き、AWS、GCP、または Azure のクラウドシークレット マネージャーの W&B インスタンスを使用することが推奨されます。
シークレットを追加
シークレットを追加するには:
受信サービスが受信 Webhook を認証するために必要な場合、必要なトークンや APIキーを生成します。必要に応じて、パスワードマネージャーなどを使用して機密文字列を安全に保存します。
W&B にログインし、チームの設定 ページに移動します。
チームシークレット のセクションで、新しいシークレット をクリックします。文字、数字、アンダースコア (_) を使用してシークレットの名前を付けます。
機密文字列をシークレット フィールドに貼り付けます。
シークレットを追加 をクリックします。
Webhook を設定するときに使用したいシークレットを指定します。詳しくは、Webhook の設定 セクションを参照してください。
シークレットをローテーション
シークレットをローテーションして値を更新するには:
シークレットの行の鉛筆アイコンをクリックして、シークレットの詳細を開きます。
シークレット を新しい値に設定します。必要に応じてシークレットを表示 して新しい値を確認します。シークレットを追加 をクリックします。シークレットの値が更新され、以前の値には解決されなくなります。
シークレットが作成または更新された後、その現在の値を表示することはできません。代わりに、新しい値にシークレットをローテーションしてください。
シークレットを削除
シークレットを削除するには:
シークレットの行のゴミ箱アイコンをクリックします。
確認ダイアログを読み、削除 をクリックします。シークレットは直ちに永久に削除されます。
シークレットへのアクセスを管理
チームのオートメーションはチームのシークレットを使用できます。シークレットを削除する前に、それを使用しているオートメーションを更新または削除して、それらが動作を停止しないようにしてください。
4.3 - レポート
機械学習プロジェクトのためのプロジェクト管理とコラボレーションツール
W&B Reportsを使って：
Runsを整理する。
可視化を埋め込み、自動化する。
学びを説明する。
LaTeXのzipファイルやPDFとして、共同作業者と更新を共有する。
次の画像は、トレーニング中にW&Bにログされたメトリクスから作成されたレポートの一部を示しています。
上記の画像が撮影されたレポートはこちら からご覧いただけます。
仕組み
簡単なクリック操作で共同レポートを作成することができます。
W&B App内のW&Bプロジェクトワークスペースに移動します。
ワークスペースの右上にあるCreate report ボタンをクリックします。
Create Report と題したモーダルが表示されます。レポートに追加したいチャートとパネルを選択してください。（後でチャートとパネルを追加または削除することができます）。Create report をクリックします。レポートを希望の状態に編集します。
Publish to project をクリックします。Share ボタンをクリックし、共同作業者とレポートを共有します。
W&B Python SDKを使用して、インタラクティブにまたプログラム的にReportsを作成する方法については、Create a report ページをご覧ください。
開始方法
ユースケースに応じて、W&B Reportsを開始するための以下のリソースを探索してください：
ベストプラクティスとヒント
Experimentsとログに関するベストプラクティスとヒントについては、Best Practices: Reports をご覧ください。
4.3.1 - レポートを作成する
W&B レポートは、App UI を使用するか Weights & Biases SDK を使ってプログラムで作成します。
レポートを作成するには、W&B App UI をインタラクティブに使用するか、W&B Python SDK を使用してプログラムで行います。
App UI
Report tab
W&B Python SDK
W&B App でプロジェクトワークスペースに移動します。
ワークスペースの右上隅にある Create report をクリックします。
モーダルが表示されます。最初に使用したいチャートを選択します。レポートのインターフェースから後でチャートを追加または削除することができます。
Filter run sets オプションを選択すると、新しい run がレポートに追加されるのを防げます。このオプションをオンまたはオフに切り替えることができます。Create report をクリックすると、レポートタブにドラフトレポートが表示され、作業を続けることができます。
W&B App でプロジェクトワークスペースに移動します。
プロジェクト内の Reports タブ（クリップボードの画像）を選択します。
レポートページで Create Report ボタンを選択します。
wandb ライブラリを使用してプログラムでレポートを作成します。
W&B SDK と Workspaces API をインストールします:
pip install wandb wandb-workspaces
次に、ワークスペースをインポートします。
import wandb
import wandb_workspaces.reports.v2 as wr
wandb_workspaces.reports.v2.Report を使用してレポートを作成します。Report Class Public API (wandb.apis.reports
report = wr. Report(project= "report_standard" )
レポートを保存します。レポートは、save() メソッドを呼び出すまで W&B サーバーにアップロードされません。
App UI を使用してインタラクティブに、またはプログラムでレポートを編集する方法については、Edit a report を参照してください。
4.3.2 - レポートを編集する
App UI を使用してインタラクティブに、または W&B SDK を使用してプログラムで レポート を編集します。
レポートを App UI でインタラクティブに、または W&B SDK を使ってプログラムで編集します。
Reports は ブロック で構成されます。ブロックはレポートの本体を構成します。これらのブロック内でテキスト、画像、組み込みの可視化、実験と run のプロット、パネルグリッドを追加できます。
パネルグリッド は、パネルと run セット を保持する特定の種類のブロックです。Run セットは W&B のプロジェクトにログされる run のコレクションです。パネルは run セット データの可視化を行います。
プログラムでレポートを編集する場合は、W&B Python SDK に加えて wandb-workspaces をインストールしてください：
pip install wandb wandb-workspaces
プロットを追加する
各パネルグリッドには一連の run セットと一連のパネルがあります。このセクションの下部にある run セットで、グリッド内のパネルに表示されるデータを制御します。異なる run セットからデータを取得するチャートを追加する場合は、新しいパネルグリッドを作成してください。
レポートにスラッシュ（/）を入力して、ドロップダウンメニューを表示します。Add panel を選択してパネルを追加します。W&B でサポートされている任意のパネルを追加できます。例えば、ラインプロット、散布図や並行座標チャートなどです。
SDK を使用してプログラムでレポートにプロットを追加します。PanelGrid Public API クラスの panels パラメータに、1つ以上のプロットまたはチャートのオブジェクトのリストを渡します。対応する Python クラスを使用してプロットまたはチャートのオブジェクトを作成します。
以下の例では、ラインプロットと散布図の作成方法を示しています。
import wandb
import wandb_workspaces.reports.v2 as wr
report = wr.Report(
project=“report-editing”,
title=“An amazing title”,
description=“A descriptive description.”,
)
blocks = [
wr.PanelGrid(
panels=[
wr.LinePlot(x=“time”, y=“velocity”),
wr.ScatterPlot(x=“time”, y=“acceleration”),
]
)
]
report.blocks = blocks
report.save()
プログラムでレポートに追加できるプロットやチャートの詳細については、wr.panels を参照してください。
Run セットを追加する
App UI または W&B SDK を使用して、プロジェクトから run セットを追加します。
レポートにスラッシュ（/）を入力して、ドロップダウンメニューを表示します。ドロップダウンから Panel Grid を選択します。これにより、レポートが作成されたプロジェクトから自動的に run セットがインポートされます。
wr.Runset() および wr.PanelGrid クラスを使用してプロジェクトから run セットを追加します。以下の手順で run セットの追加方法を示します：
wr.Runset() オブジェクト インスタンスを作成します。プロジェクト パラメータのために、run セットを含むプロジェクトの名前を指定し、エンティティ パラメータのためにプロジェクトを所有するエンティティを指定します。wr.PanelGrid() オブジェクト インスタンスを作成します。1つ以上の runset オブジェクトを runsets パラメータに渡します。1つ以上の wr.PanelGrid() オブジェクト インスタンスをリストに保存します。
パネルグリッド インスタンスのリストを使用して、レポート インスタンス ブロック属性を更新します。
import wandb
import wandb_workspaces.reports.v2 as wr
report = wr.Report(
project=“report-editing”,
title=“An amazing title”,
description=“A descriptive description.”,
)
panel_grids = wr.PanelGrid(
runsets=[wr.RunSet(project="", entity="")]
)
report.blocks = [panel_grids]
report.save()
ひとつの SDK 呼び出しで run セットとパネルを追加することもできます：
import wandb
report = wr.Report(
project=“report-editing”,
title=“An amazing title”,
description=“A descriptive description.”,
)
panel_grids = wr.PanelGrid(
panels=[
wr.LinePlot(
title=“line title”,
x=“x”,
y=[“y”],
range_x=[0, 100],
range_y=[0, 100],
log_x=True,
log_y=True,
title_x=“x axis title”,
title_y=“y axis title”,
ignore_outliers=True,
groupby=“hyperparam1”,
groupby_aggfunc=“mean”,
groupby_rangefunc=“minmax”,
smoothing_factor=0.5,
smoothing_type=“gaussian”,
smoothing_show_original=True,
max_runs_to_show=10,
plot_type=“stacked-area”,
font_size=“large”,
legend_position=“west”,
),
wr.ScatterPlot(
title=“scatter title”,
x=“y”,
y=“y”,
# z=‘x’,
range_x=[0, 0.0005],
range_y=[0, 0.0005],
# range_z=[0,1],
log_x=False,
log_y=False,
# log_z=True,
running_ymin=True,
running_ymean=True,
running_ymax=True,
font_size=“small”,
regression=True,
),
],
runsets=[wr.RunSet(project="", entity="")],
)
report.blocks = [panel_grids]
report.save()
Run セットをフリーズする
レポートはプロジェクトから最新のデータを表示するために run セットを自動的に更新します。しかし、レポート内の run セットを保持するには、その run セットをフリーズ することができます。Run セットをフリーズすると、特定の時点のレポート内の run セットの状態が保持されます。
レポートを表示する際に run セットをフリーズするには、Filter ボタンの近くにあるスノーフレーク アイコンをクリックします。
コード ブロックを追加する
レポートにコードブロックを App UI でインタラクティブに、または W&B SDK で追加します。
レポートにスラッシュ（/）を入力して、ドロップダウン メニューを表示します。ドロップダウンから Code を選択します。
コード ブロックの右側にあるプログラミング言語の名前を選択すると、ドロップダウンが展開されます。利用可能なプログラミング言語の構文を選択してください。Javascript、Python、CSS、JSON、HTML、Markdown、YAML から選べます。
wr.CodeBlock クラスを使用してコード ブロックをプログラムで作成します。言語とコードにそれぞれ表示したい言語名とコードを指定します。
たとえば、以下の例では、YAML ファイルのリストを示しています。
import wandb
import wandb_workspaces.reports.v2 as wr
report = wr.Report(project=“report-editing”)
report.blocks = [
wr.CodeBlock(
code=[“this:”, “- is”, “- a”, “cool:”, “- yaml”, “- file”], language=“yaml”
)
]
report.save()
これにより、次のようなコードブロックがレンダリングされます：
this:
以下の例では、Python コードブロックを示しています：
report = wr.Report(project=“report-editing”)
report.blocks = [wr.CodeBlock(code=[“Hello, World!”], language=“python”)]
report.save()
これにより、次のようなコードブロックがレンダリングされます：
Hello, World!
マークダウンを追加する
レポートにマークダウンを App UI でインタラクティブに、または W&B SDK で追加します。
レポートにスラッシュ（/）を入力して、ドロップダウン メニューを表示します。ドロップダウンから Markdown を選択します。
wandb.apis.reports.MarkdownBlock クラスを使用して、プログラムでマークダウンブロックを作成します。text パラメータに文字列を渡します：
import wandb
import wandb_workspaces.reports.v2 as wr
report = wr.Report(project=“report-editing”)
report.blocks = [
wr.MarkdownBlock(text=“Markdown cell with italics and bold and $e=mc^2$”)
]
これにより、次のようなマークダウン ブロックがレンダリングされます：
HTML要素を追加する
レポートに HTML 要素を App UI でインタラクティブに、または W&B SDK で追加します。
レポートにスラッシュ（/）を入力して、ドロップダウン メニューを表示します。ドロップダウンからテキスト ブロックの種類を選択します。例として、H2 見出しブロックを作成するには、Heading 2 のオプションを選択します。
1つ以上の HTML 要素のリストを wandb.apis.reports.blocks 属性に渡します。以下の例では、H1、H2、および無順リストを作成する方法を示しています：
import wandb
import wandb_workspaces.reports.v2 as wr
report = wr.Report(project=“report-editing”)
report.blocks = [
wr.H1(text=“How Programmatic Reports work”),
wr.H2(text=“Heading 2”),
wr.UnorderedList(items=[“Bullet 1”, “Bullet 2”]),
]
report.save()
これにより、次のような HTML 要素がレンダリングされます：
リッチメディアリンクを埋め込む
レポート内にリッチメディアを App UI で、または W&B SDK で埋め込みます。
URL をレポートにコピーアンドペーストして、リッチメディアをレポート内に埋め込みます。以下のアニメーションは、Twitter、YouTube、および SoundCloud からの URL をコピーアンドペーストする方法を示しています。
レポートにツイートリンク URL をコピーして貼り付け、ツイートをレポート内に表示します。
YouTube
レポート内にビデオを埋め込むために YouTube ビデオ URL リンクをコピーアンドペーストします。
SoundCloud
SoundCloud のリンクをコピーアンドペーストして、オーディオファイルをレポート内に埋め込みます。
1 つ以上の埋め込みメディア オブジェクトのリストを wandb.apis.reports.blocks 属性に渡します。以下の例では、ビデオと Twitter メディアをレポートに埋め込む方法を示しています：
import wandb
import wandb_workspaces.reports.v2 as wr
report = wr.Report(project=“report-editing”)
report.blocks = [
wr.Video(url=“https://www.youtube.com/embed/6riDJMI-Y8U”),
wr.Twitter(
embed_html=’
\n'
),
]
report.save()
パネルグリッドの複製と削除
再利用したいレイアウトがある場合は、パネルグリッドを選択してコピー＆ペーストすることで、同じレポート内に複製したり、別のレポートに貼り付けることができます。
パネルグリッドセクション全体を強調表示するには、右上隅のドラッグハンドルを選択します。パネルグリッド、テキスト、見出しなど、レポート内の領域をクリックしてドラッグして強調表示および選択します。
パネルグリッドを選択し、キーボードで delete を押してパネルグリッドを削除します。
レポート内のヘッダーを折りたたんで整理する
テキストブロック内のコンテンツを非表示にするために、レポート内のヘッダーを折りたたみます。レポートが読み込まれると、展開されているヘッダーのみがコンテンツを表示します。レポート内でヘッダーを折りたたむことで、コンテンツを整理し、過剰なデータの読み込みを防ぐことができます。以下の gif はその手順を示しています。
複数次元の関係を可視化する
複数次元の関係を効果的に可視化するために、変数の 1 つを示すためにカラーバリエーションを使用します。これにより明瞭さが向上し、パターンが解釈しやすくなります。
カラーグラデーションで表現する変数を選択します（例: 罰金スコア、学習率など）。これにより、罰金（色）がトレーニング時間 (x 軸) を経て報酬/副作用 (y 軸) とどのように相互作用するかをより明確に理解できます。
主要なトレンドを強調します。特定の run グループにカーソルを合わせると、それが可視化で強調表示されます。
4.3.3 - レポートを共同で作成する
W&B Reports を同僚やチームメンバーと共有してコラボレーションしましょう。
レポートを保存したら、Share ボタンを選択してコラボレーションできます。Edit ボタンを選択すると、レポートの下書きコピーが作成されます。下書きレポートは自動保存されます。変更を共有レポートに公開するには、Save to report を選択します。
編集の競合が発生すると警告通知が表示されます。これは、あなたと他のコラボレーターが同じレポートを同時に編集した場合に発生する可能性があります。警告通知は、編集の競合を解決するためのガイドとなります。
レポートにコメントする
レポート内のパネルにあるコメントボタンをクリックして、そのパネルに直接コメントを追加します。
4.3.4 - レポートをクローンしてエクスポートする
W&B レポートを PDF または LaTeX としてエクスポートします。
レポートをエクスポート
レポートを PDF または LaTeX としてエクスポートします。レポート内でケバブアイコンを選択し、ドロップダウンメニューを展開します。Download を選択し、PDF または LaTeX の出力形式を選択します。
レポートをクローン
レポート内でケバブアイコンを選択し、ドロップダウンメニューを展開します。Clone this report ボタンを選択します。モーダルでクローンされたレポートの保存先を選択します。Clone report を選択します。
プロジェクトのテンプレートと形式を再利用するためにレポートをクローンします。チームのアカウント内でプロジェクトをクローンした場合、クローンされたプロジェクトはチームに表示されます。個人のアカウント内でプロジェクトをクローンした場合、そのプロジェクトはそのユーザーのみに表示されます。
テンプレートとして使用するために URL からレポートをロードします。
report = wr. Report(
project= PROJECT, title= "Quickstart Report" , description= "That was easy!"
) # 作成
report. save() # 保存
new_report = wr. Report. from_url(report. url) # ロード
new_report.blocks 内のコンテンツを編集します。
pg = wr. PanelGrid(
runsets= [
wr. Runset(ENTITY, PROJECT, "First Run Set" ),
wr. Runset(ENTITY, PROJECT, "Elephants Only!" , query= "elephant" ),
],
panels= [
wr. LinePlot(x= "Step" , y= ["val_acc" ], smoothing_factor= 0.8 ),
wr. BarPlot(metrics= ["acc" ]),
wr. MediaBrowser(media_keys= "img" , num_columns= 1 ),
wr. RunComparer(diff_only= "split" , layout= {"w" : 24 , "h" : 9 }),
],
)
new_report. blocks = (
report. blocks[:1 ] + [wr. H1("Panel Grid Example" ), pg] + report. blocks[1 :]
)
new_report. save()
4.3.5 - レポートを埋め込む
W&B レポートを直接 Notion に埋め込むか、HTML IFrame 要素を使用します。
HTML iframe 要素
レポート内の右上にある Share ボタンを選択します。モーダルウィンドウが表示されます。このモーダルウィンドウ内で Copy embed code を選択します。コピーされたコードは、インラインフレーム (IFrame) HTML 要素内でレンダリングされます。コピーしたコードを任意の iframe HTML 要素に貼り付けます。
埋め込まれた場合、公開 レポートのみが表示可能です。
Confluence
次のアニメーションは、Confluence の IFrame セル内でレポートへの直接リンクを挿入する方法を示しています。
Notion
次のアニメーションは、Notion ドキュメント内で Embed ブロックを使ってレポートを挿入し、そのレポートの埋め込みコードを使用する方法を示しています。
Gradio
gr.HTML 要素を使用して、Gradio Apps 内で W&B Reports を埋め込み、Hugging Face Spaces で利用することができます。
import gradio as gr
def wandb_report (url):
iframe = f '<iframe src= { url} style="border:none;height:1024px;width:100%">'
return gr. HTML(iframe)
with gr. Blocks() as demo:
report = wandb_report(
"https://wandb.ai/_scott/pytorch-sweeps-demo/reports/loss-22-10-07-16-00-17---VmlldzoyNzU2NzAx"
)
demo. launch()
4.3.6 - プロジェクト間で run を比較する
異なる2つのプロジェクトのrunをプロジェクト間レポートで比較する。
クロスプロジェクト レポートを使用して、異なる 2 つのプロジェクトからの run を比較します。run セット テーブル内のプロジェクト セレクターを使用してプロジェクトを選択します。
このセクションの可視化は、最初のアクティブな run セットから列を引き出します。必要なメトリクスが線プロットに表示されない場合は、その列が利用可能であることを確認してください。
この機能は時系列線上の履歴データをサポートしていますが、異なるプロジェクトから異なるサマリー メトリクスを引き出すことはサポートしていません。つまり、別のプロジェクトでのみログに記録された列から散布図を作成することはできません。
2 つのプロジェクトからの run を比較する必要があるが、列が動作していない場合は、1 つのプロジェクトの run にタグを追加してから、それらの run を他のプロジェクトに移動します。各プロジェクトからの run のみをフィルタリングすることはできますが、レポートには両方の run セットのすべての列が含まれます。
ビュー専用レポートリンク
プライベートプロジェクトまたはチーム プロジェクトにあるレポートへのビュー専用リンクを共有します。
ビュー専用レポートリンクは、URL に秘密のアクセストークンを追加するため、リンクを開くと誰でもページを表示できます。誰でも最初にログインせずにマジックリンクを使用してレポートを表示できます。W&B Local プライベート クラウド インストールのお客様の場合、これらのリンクはファイアウォールの内側に残るため、プライベート インスタンスへのアクセス と ビュー専用リンクへのアクセスを持つチームのメンバーのみがレポートを表示できます。
ビュー専用モード では、ログインしていない人でもチャートを見たり、ツールチップを見たり、ズームイン・アウトしてチャートを閲覧したり、テーブル内の列をスクロールしたりすることができます。ビュー モードの場合、新しいチャートや新しいテーブル クエリを作成してデータを探ることはできません。レポートリンクのビュー専用訪問者は run をクリックして run ページに移動することはできません。また、ビュー専用訪問者は共有モーダルを見ることはできず、代わりに「ビュー専用アクセスでは共有できません」というツールチップがホバー中に表示されます。
マジックリンクは、「Private」および「Team」プロジェクトでのみ利用可能です。「Public」（誰でも閲覧可能）または「Open」（誰でも閲覧および run 提供可能）プロジェクトの場合、このプロジェクトは公開で、リンクを持つ誰でもすでに利用できるため、リンクをオン/オフできません。
グラフをレポートに送信
ワークスペースからレポートにグラフを送信して、進捗を追跡します。 レポートにコピーしたいチャートまたはパネルのドロップダウン メニューをクリックし、Add to report をクリックして送信先のレポートを選択します。
4.3.7 - 例のレポート
レポートギャラリー
ノート: 簡単なサマリーで可視化を追加
重要な観察結果や将来の作業に関するアイデア、プロジェクトの開発におけるマイルストーンを捉えましょう。レポート内のすべての実験の run は、そのパラメータ、メトリクス、ログ、コードにリンクされるため、作業の全体的な文脈を保存できます。
テキストを書き留め、関連するチャートを引き入れてインサイトを示しましょう。
トレーニング時間の比較を共有する方法については、What To Do When Inception-ResNet-V2 Is Too Slow W&B Report をご覧ください。
複雑なコードベースからの最高の例を保存し、簡単に参照したり、将来の対話のために保存します。Lyft のデータセットから LIDAR ポイントクラウドを可視化し、3D バウンディングボックスで注釈を付ける方法については、LIDAR point clouds W&B Report をご覧ください。
コラボレーション: 同僚と学びを共有する
プロジェクトの開始方法を説明し、これまでに観察したことを共有し、最新の学びを統合します。同僚は、任意のパネルやレポートの最後にコメントを記入して、詳細を提案したり議論したりすることができます。
同僚が自分で探索し、追加のインサイトを得て、次のステップをよりよく計画できるように、動的な設定を含めます。この例では、3 種類の実験を独立して可視化したり、比較したり、平均化したりできます。
初めての run とベンチマークの観察を共有する方法については、SafeLife benchmark experiments W&B Report をご覧ください。
スライダーや設定可能なメディアパネルを使用して、モデルの結果やトレーニングの進捗を示します。スライダーを使用した W&B Report の例については、Cute Animals and Post-Modern Style Transfer: StarGAN v2 for Multi-Domain Image Synthesis レポートをご覧ください。
作業ログ: 試したことを記録し、次のステップを計画する
実験に関する考えや学び、注意点、次のステップをプロジェクトを進めながら書き留め、一箇所に整理しておきましょう。これにより、スクリプトを超えた重要な部分をすべて"文書化"することができます。学びをレポートする方法についての例としては、Who Is Them? Text Disambiguation With Transformers W&B Report をご覧ください。
プロジェクトのストーリーを語り、後からモデルがどのように、そしてなぜ開発されたのかを理解するために参照することができます。The View from the Driver’s Seat W&B Report では、学びをレポートする方法をご覧いただけます。
OpenAI Robotics チームが W&B Reports を使用して大規模な機械学習プロジェクトを実行した方法を探るために、W&B Reports がどのように使用されたかの例については、Learning Dexterity End-to-End Using W&B Reports をご覧ください。
4.4 - レジストリ
W&B Registryは現在パブリックプレビュー中です。有効化の方法については、
こちら のセクションを参照してください。
W&B Registryは、組織内のアーティファクトバージョンの管理された中央リポジトリです。組織内で権限を持つ ユーザーは、すべてのアーティファクトのライフサイクルをダウンロード 、共有、共同管理できます。
Registryを使用して、アーティファクトバージョンを追跡 し、アーティファクトの使用履歴と変更履歴を監査し、アーティファクトのガバナンスとコンプライアンスを保証し、モデルCI/CDなどの下流プロセスを自動化 できます。
要約すると、W&B Registryを使用して以下を行うことができます：
前の画像は「Model」と「Dataset」のコアレジストリとカスタムレジストリがあるRegistryアプリを示しています。
基本を学ぶ
各組織には最初にモデルとデータセットのアーティファクトを整理するためのModels とDatasets と呼ばれる2つのレジストリが含まれています。組織のニーズに基づいて、他のアーティファクトタイプを整理するための追加のレジストリを作成する ことができます。
レジストリ は1つ以上のコレクション で構成されています。各コレクションは、異なるタスクまたはユースケースを表しています。
レジストリにアーティファクトを追加するには、最初に特定のアーティファクトバージョンをW&Bにログ します。アーティファクトをログすると、W&Bは自動的にそのアーティファクトにバージョンを割り当てます。アーティファクトバージョンは0から始まり、最初のバージョンはv0、2番目はv1というように続きます。
アーティファクトをW&Bにログしたら、その特定のアーティファクトバージョンをレジストリ内のコレクションにリンクできます。
「リンク」という用語は、W&Bがアーティファクトを保存している場所と、レジストリでアーティファクトにアクセスできる場所を接続するポインタを指します。アーティファクトをコレクションにリンクするときにW&Bはアーティファクトを重複しません。
例として、以下のコード例では、“my_model.txt"という名前のモデルアーティファクトをコアレジストリ 内の"first-collection"というコレクションにログしリンクする方法を示しています：
W&Bのrunを初期化します。
アーティファクトをW&Bにログします。
コレクションとレジストリの名前を指定して、アーティファクトバージョンをリンクします。
アーティファクトをコレクションにリンクします。
このPythonコードをスクリプトとして保存し実行してください。W&B Python SDKバージョン0.18.6以上が必要です。
import wandb
import random
# アーティファクトをトラックするためにW&Bのrunを初期化
run = wandb. init(project= "registry_quickstart" )
# シミュレートされたモデルファイルを作成してログします
with open("my_model.txt" , "w" ) as f:
f. write("Model: " + str(random. random()))
# アーティファクトをW&Bにログします
logged_artifact = run. log_artifact(
artifact_or_path= "./my_model.txt" ,
name= "gemma-finetuned" ,
type= "model" # アーティファクトタイプを指定
)
# 公開したいコレクションとレジストリの名前を指定
COLLECTION_NAME = "first-collection"
REGISTRY_NAME = "model"
# アーティファクトをレジストリにリンク
run. link_artifact(
artifact= logged_artifact,
target_path= f "wandb-registry- { REGISTRY_NAME} / { COLLECTION_NAME} "
)
指定したレジストリ内に存在しない場合、link_artifact(target_path = "")メソッドで返されるrunオブジェクトの指定したコレクションをW&Bが自動的に作成します。
ターミナルが出力するURLは、W&Bがあなたのアーティファクトを保存しているプロジェクトにリダイレクトされます。
他の組織メンバーと公開したアーティファクトバージョンを表示するためにRegistryアプリに移動します。まずW&Bに移動します。左側のサイドバーでApplications 以下のRegistry を選択します。「Model」レジストリを選択します。そのレジストリ内で、リンクしたアーティファクトバージョンを持つ「first-collection」コレクションが表示されるはずです。
アーティファクトバージョンをレジストリ内のコレクションにリンクすると、それを所有している組織メンバーは、適切な権限を持っていれば、あなたのアーティファクトバージョンを表示、ダウンロード、管理し、下流のオートメーションを作成できます。
もしアーティファクトバージョンがメトリクスをログする場合（たとえば
run.log_artifact()を使用して）、そのバージョンの詳細ページからメトリクスを表示できますし、コレクションのページからアーティファクトバージョン間でメトリクスを比較できます。参照：
レジストリ内のリンクされたアーティファクトを表示する 。
W&B Registryを有効にする
デプロイメントタイプに基づいて、以下の条件を満たしてW&B Registryを有効にします：
デプロイメントタイプ
有効にする方法
マルチテナントクラウド
アクションは必要ありません。W&B RegistryはW&Bアプリで利用可能です。
専用クラウド
アカウントチームに連絡してください。ソリューションアーキテクト(SA)チームがあなたのインスタンスのオペレーターコンソール内でW&B Registryを有効にします。インスタンスがサーバーリリースバージョン0.59.2以上であることを確認してください。
セルフマネージド
ENABLE_REGISTRY_UIと呼ばれる環境変数を有効にします。サーバーで環境変数を有効にする方法の詳細についてはこちらのドキュメント をご覧ください。セルフマネージドインスタンスでは、インフラストラクチャ管理者がこの環境変数を有効にしてtrueに設定する必要があります。インスタンスがサーバーリリースバージョン0.59.2以上であることを確認してください。
開始するためのリソース
ユースケースに応じて、W&B Registryの利用を開始するための以下のリソースを探索してください：
チュートリアルビデオをチェックしてください：
W&BのModel CI/CD コースを受講し、以下を学びましょう：
W&B Registryを使用してアーティファクトを管理し、バージョン管理、リネージトラッキング、および異なるライフサイクルステージへのモデルプロモートを行います。
Webhooksを使用してモデル管理ワークフローを自動化します。
外部MLシステムおよびツールとレジストリを統合して、モデル評価、モニタリング、デプロイメントを行います。
旧モデルレジストリからW&B Registryへの移行
旧モデルレジストリの廃止予定日は未定です。旧モデルレジストリを廃止する前に、W&Bは旧モデルレジストリの内容をW&B Registryに移行します。
旧モデルレジストリからW&B Registryへの移行プロセスについて詳しくは、旧モデルレジストリからの移行 を参照してください。
移行が行われるまで、W&Bは旧モデルレジストリと新しいレジストリの両方をサポートしています。
旧モデルレジストリを表示するには、W&BアプリでModel Registryに移動してください。ページの上部に、旧モデルレジストリアプリUIを使用できるバナーが表示されます。
質問がある場合や移行についての懸念がある場合は、support@wandb.comにお問い合わせいただくか、W&Bプロダクトチームとお話しください。
4.4.1 - レジストリの種類
W&B は 2 種類のレジストリをサポートしています: コア レジストリ と カスタム レジストリ 。
コアレジストリ
コアレジストリは、特定のユースケース、つまり Models と Datasets のためのテンプレートです。
デフォルトでは、Models レジストリは "model" アーティファクトタイプを受け入れるように設定されており、Dataset レジストリは "dataset" アーティファクトタイプを受け入れるように設定されています。管理者は、追加の受け入れ可能なアーティファクトタイプを追加することができます。
上記の画像は、W&B レジストリ アプリ UI における Models と Dataset のコアレジストリと、Fine_Tuned_Models というカスタムレジストリを示しています。
コアレジストリには 組織の公開範囲 があります。レジストリの管理者はコアレジストリの公開範囲を変更することはできません。
カスタムレジストリ
カスタムレジストリは、"model" アーティファクトタイプや "dataset" アーティファクトタイプに制限されません。
機械学習パイプラインの各ステップのために、初期データ収集から最終モデルデプロイメントまでのカスタムレジストリを作成することができます。
例えば、「Benchmark_Datasets」というレジストリを作成し、トレーニングされたモデルの性能評価のためにキュレーションされたデータセットを整理することができます。このレジストリ内には、トレーニング中にモデルが見たことのないユーザー質問と、それに対応する専門家によって検証された答えが含まれる「User_Query_Insurance_Answer_Test_Data」というコレクションを持つことができます。
カスタムレジストリは、組織または制限付きの公開範囲 のいずれかを持つことができます。レジストリの管理者は、組織の公開範囲を制限付きに変更することができます。ただし、レジストリ管理者はカスタムレジストリの公開範囲を制限付きから組織の公開範囲へ変更することはできません。
カスタムレジストリの作成方法については、カスタムレジストリを作成する を参照してください。
まとめ
以下の表は、コアレジストリとカスタムレジストリの違いをまとめています:
コア
カスタム
公開範囲
組織の公開範囲のみ。公開範囲は変更できません。
組織または制限付きのいずれか。公開範囲は組織から制限付きに変更できます。
メタデータ
あらかじめ設定され、ユーザーによる編集は不可。
ユーザーが編集可能。
アーティファクトタイプ
あらかじめ設定され、既存の受け入れられるアーティファクトタイプは削除できません。ユーザーは追加の受け入れ可能なアーティファクトタイプを追加可能。
管理者が受け入れられるタイプを定義できます。
カスタマイズ
既存のリストに追加のタイプを追加可能。
レジストリ名、説明、公開範囲、受け入れアーティファクトタイプを編集可能。
4.4.2 - カスタムレジストリを作成する
カスタムレジストリは、使用できるアーティファクトタイプに関して柔軟性とコントロールを提供し、レジストリの公開範囲を制限することができるなどの機能があります。
コアとカスタムレジストリの完全な比較は、Registry types の概要表をご覧ください。
カスタムレジストリを作成する
カスタムレジストリを作成するには:
https://wandb.ai/registry/ の Registry アプリに移動します。Custom registry 内で、Create registry ボタンをクリックします。Name フィールドにレジストリの名前を入力します。必要に応じてレジストリの説明を提供します。
Registry visibility ドロップダウンからレジストリを閲覧できる人を選択します。レジストリの公開範囲オプションの詳細については、Registry visibility types をご覧ください。All types または Specify types を Accepted artifacts type ドロップダウンから選択します。（Specify types を選択した場合）レジストリが受け入れる1つ以上のアーティファクトタイプを追加します。
Create registry ボタンをクリックします。
アーティファクトタイプは、一旦レジストリの設定に保存されるとそのレジストリから削除することはできません。
たとえば、以下の画像はユーザーが作成しようとしている Fine_Tuned_Models というカスタムレジストリを示しています。このレジストリは、手動でレジストリに追加されたメンバーのみに制限 されています。
公開範囲タイプ
レジストリの公開範囲 は、誰がそのレジストリにアクセスできるかを決定します。カスタムレジストリの公開範囲を制限すると、指定されたメンバーのみがそのレジストリにアクセスできるようにするのに役立ちます。
カスタムレジストリには2つの公開範囲オプションがあります:
公開範囲
説明
Restricted
招待された組織メンバーのみがレジストリにアクセスできます。
Organization
組織内の全員がレジストリにアクセスできます。
チーム管理者またはレジストリ管理者は、カスタムレジストリの公開範囲を設定できます。
Restricted公開範囲でカスタムレジストリを作成したユーザーは、自動的にそのレジストリの管理者として登録されます。
カスタムレジストリの公開範囲を設定する
チーム管理者またはレジストリ管理者は、カスタムレジストリの作成時または作成後に公開範囲を設定することができます。
既存のカスタムレジストリの公開範囲を制限するには:
https://wandb.ai/registry/ の Registry アプリに移動します。任意のレジストリを選択します。
右上隅の歯車アイコンをクリックします。
Registry visibility ドロップダウンから、希望するレジストリの公開範囲を選択します。Restricted visibility を選択した場合:
このレジストリにアクセスを許可したい組織のメンバーを追加します。 Registry members and roles セクションまでスクロールし、Add member ボタンをクリックします。
Member フィールドに追加したいメンバーのメールまたはユーザー名を入力します。Add new member をクリックします。
チーム管理者がそれを作成する際に、カスタムレジストリの公開範囲をどのように設定するかに関する詳細は Create a custom registry を参照してください。
4.4.3 - レジストリアクセスを設定する
レジストリ管理者は、レジストリの設定を設定することで、レジストリロールを設定 、ユーザーを追加 、またはユーザーを削除 することができます。
ユーザー管理
ユーザーまたはチームの追加
レジストリ管理者は、個々のユーザーまたは全チームをレジストリに追加できます。ユーザーまたはチームをレジストリに追加するには、次の手順を実行します。
https://wandb.ai/registry/ に移動します。ユーザーまたはチームを追加したいレジストリを選択します。
右上隅のギアアイコンをクリックして、レジストリの設定にアクセスします。
Registry access セクションで Add access をクリックします。Include users and teams フィールドに、追加したいユーザー名、メールアドレス、またはチーム名を指定します。Add access をクリックします。
レジストリでのユーザーロール設定 やレジストリロールの権限 についての詳細をご覧ください。
ユーザーまたはチームの削除
レジストリ管理者は、個々のユーザーまたはチーム全体をレジストリから削除できます。ユーザーまたはチームをレジストリから削除するには、次の手順を実行します。
https://wandb.ai/registry/ に移動します。ユーザーを削除したいレジストリを選択します。
右上隅のギアアイコンをクリックして、レジストリの設定にアクセスします。
Registry access セクションに移動し、削除したいユーザー名、メールアドレス、またはチームを入力します。Delete ボタンをクリックします。
チームからユーザーを削除すると、そのユーザーのレジストリへのアクセスも削除されます。
レジストリロール
レジストリ内の各ユーザーには レジストリロール があり、そのレジストリで何をできるかが決まります。
W&B は、レジストリにユーザーやチームが追加されると、自動的にデフォルトのレジストリロールを割り当てます。
Entity
Default registry role
Team
Viewer
User (non admin)
Viewer
Org admin
Admin
レジストリ管理者は、レジストリ内のユーザーやチームのロールを割り当てまたは変更することができます。詳細は レジストリでのユーザーロールの設定 を参照してください。
W&Bロールタイプ W&B には、チームロール とレジストリロール の2種類のロールがあります。
チームにおけるあなたのロールは、いかなるレジストリにおけるあなたのロールにも影響や関連を持ちません。
以下の表は、ユーザーが持つことのできる異なるロールとその権限を示しています：
Permission
Permission Group
Viewer
Member
Admin
コレクションの詳細を表示する
Read
X
X
X
リンクされたアーティファクトの詳細を表示する
Read
X
X
X
使用: レジストリ内で use_artifact を使用してアーティファクトを使用
Read
X
X
X
リンクされたアーティファクトをダウンロードする
Read
X
X
X
アーティファクトのファイルビューワーからファイルをダウンロードする
Read
X
X
X
レジストリを検索する
Read
X
X
X
レジストリの設定とユーザーリストを表示する
Read
X
X
X
コレクションの新しい自動化を作成する
Create
X
X
新しいバージョンが追加されたときの Slack 通知をオンにする
Create
X
X
新しいコレクションを作成する
Create
X
X
新しいカスタムレジストリを作成する
Create
X
X
コレクションカード (説明) を編集する
Update
X
X
リンクされたアーティファクトの説明を編集する
Update
X
X
コレクションのタグを追加または削除する
Update
X
X
リンクされたアーティファクトからエイリアスを追加または削除する
Update
X
X
新しいアーティファクトをリンクする
Update
X
X
レジストリ用の許可されたタイプ一覧を編集する
Update
X
X
カスタムレジストリ名を編集する
Update
X
X
コレクションを削除する
Delete
X
X
自動化を削除する
Delete
X
X
レジストリからアーティファクトのリンクを解除する
Delete
X
X
レジストリ用の承認されたアーティファクトタイプを編集する
Admin
X
レジストリの公開範囲を変更する（組織または制限付き）
Admin
X
ユーザーをレジストリに追加する
Admin
X
レジストリ内のユーザーのロールを割り当てるまたは変更する
Admin
X
継承された権限
レジストリ内のユーザーの権限は、そのユーザーに個別に、またはチームメンバーシップによって割り当てられた特権の最高レベルに依存します。
例えば、レジストリ管理者が Nico というユーザーをレジストリ A に追加し、Viewer レジストリロールを割り当てたとします。次に、レジストリ管理者が Foundation Model Team というチームをレジストリ A に追加し、Foundation Model Team に Member レジストリロールを割り当てたとします。
Nico は Foundation Model Team のメンバーであり、このチームは Registry の Member です。Member の権限は Viewer よりも高いため、W&B は Nico に Member ロールを付与します。
以下の表は、ユーザーの個別レジストリロールと、彼らが所属するチームのレジストリロールの間で矛盾が生じた場合の最高レベルの権限を示しています：
Team registry role
Individual registry role
Inherited registry role
Viewer
Viewer
Viewer
Member
Viewer
Member
Admin
Viewer
Admin
矛盾がある場合、W&B はユーザー名の横に最高レベルの権限を表示します。
例えば、以下の画像では、Alex は smle-reg-team-1 チームのメンバーであるため、Member ロールの特権を継承しています。
レジストリロールの設定
https://wandb.ai/registry/ に移動します。設定したいレジストリを選択します。
右上隅のギアアイコンをクリックします。
Registry members and roles セクションまでスクロールします。Member フィールド内で、権限を編集したいユーザーまたはチームを検索します。Registry role 列でユーザーのロールをクリックします。ドロップダウンから、ユーザーに割り当てたいロールを選択します。
4.4.4 - コレクションを作成する
A collection とは、レジストリ内でリンクされたアーティファクト バージョンのセットです。それぞれのコレクションは、個別のタスクやユースケースを表します。
例えば、コアデータセット レジストリ内に複数のコレクションを持つことができます。それぞれのコレクションには、MNIST、CIFAR-10、ImageNet などの異なるデータセットが含まれます。
別の例として、「chatbot」と呼ばれるレジストリがあり、そこにはモデル アーティファクトのコレクション、データセット アーティファクトのコレクション、およびファインチューンされたモデル アーティファクトのコレクションがあります。
レジストリとそのコレクションの整理方法は、あなた次第です。
W&B モデルレジストリに精通している場合は、登録されたモデルについても知識があるかもしれません。モデルレジストリ内の登録されたモデルは、今後は W&B レジストリのコレクションと呼ばれます。
コレクションのタイプ
それぞれのコレクションは、一種類だけのアーティファクトのタイプ を受け入れます。指定したタイプは、組織の他のメンバーと一緒にそのコレクションにリンクできるアーティファクトの種類を制限します。
アーティファクトのタイプは、プログラミング言語、例えば Python のデータタイプに似ています。この類推では、コレクションは文字列、整数、または浮動小数点数を格納できますが、これらのデータタイプの混合はできません。
例えば、「データセット」アーティファクトタイプを受け入れるコレクションを作成したとします。これにより、「データセット」タイプを持つ将来のアーティファクト バージョンのみをこのコレクションにリンクできます。同様に、「モデル」タイプのアーティファクトは、モデルアーティファクトタイプのみを受け入れるコレクションにのみリンクできます。
アーティファクトのタイプは、そのアーティファクト オブジェクトを作成するときに指定します。wandb.Artifact() 内の type フィールドに注意してください。
import wandb
# Run を初期化
run = wandb. init(
entity = "<team_entity>" ,
project = "<project>"
)
# アーティファクトオブジェクトを作成
artifact = wandb. Artifact(
name= "<artifact_name>" ,
type= "<artifact_type>"
)
コレクションを作成するとき、事前に定義されたアーティファクト タイプのリストから選択できます。使用可能なアーティファクト タイプは、そのコレクションが所属するレジストリによります。
アーティファクトをコレクションにリンクしたり新しいコレクションを作成する前に、そのコレクションが受け入れるアーティファクトのタイプを調査してください 。
コレクションが受け入れるアーティファクトのタイプを確認する
コレクションにリンクする前に、コレクションが受け入れるアーティファクトタイプを確認してください。W&B Python SDK を使用してプログラム的に、もしくは W&B アプリを使用してインタラクティブに、コレクションが受け入れるアーティファクトタイプを確認することができます。
そのアーティファクト タイプを受け入れないコレクションにアーティファクトをリンクしようとすると、エラーメッセージが表示されます。
W&B App
Python SDK (Beta)
ホームページまたはレジストリの設定ページで、受け入れられるアーティファクトタイプをレジストリカードで見つけることができます。
どちらのメソッドでも、まず W&B レジストリ アプリに移動します。
レジストリ アプリのホームページでは、そのレジストリのレジストリ カードにスクロールして、受け入れられたアーティファクト タイプを表示できます。レジストリカード内の灰色の水平オーバルには、レジストリが受け入れるアーティファクト タイプが記載されています。
例えば、前の図はレジストリ アプリのホームページに複数のレジストリ カードを示しています。Model レジストリカード内で、2つのアーティファクトタイプ: model と model-new を見ることができます。
レジストリの設定ページで受け入れられたアーティファクト タイプを表示するには:
設定を表示するレジストリカードをクリックします。
右上のギアアイコンをクリックします。
受け入れられたアーティファクト タイプ フィールドまでスクロールします。
W&B Python SDK を使用して、レジストリが受け入れるアーティファクト タイプをプログラム的に表示します。
import wandb
registry_name = "<registry_name>"
artifact_types = wandb. Api(). project(name= f "wandb-registry- { registry_name} " ). artifact_types()
print(artifact_type. name for artifact_type in artifact_types)
実験やアーティファクトの追跡をせず、W&B API に問い合わせるだけの場合は、実行を初期化する必要がないため、後述のコードスニペットで実行を初期化しないことに注意してください。
コレクションが受け入れるアーティファクトのタイプを知ったら、コレクションを作成します 。
コレクションを作成する
レジストリ内でインタラクティブまたはプログラムでコレクションを作成します。コレクションを作成した後、そのコレクションが受け入れるアーティファクトのタイプを変更することはできません。
プログラム的にコレクションを作成する
wandb.init.link_artifact() メソッドを使用して、アーティファクトをコレクションにリンクします。target_path フィールドに、次の形式のパスとしてコレクションとレジストリの両方を指定します。
f "wandb-registry- { registry_name} / { collection_name} "
ここで、registry_name はレジストリの名前で、collection_name はコレクションの名前です。必ずレジストリ名の前に wandb-registry- プレフィックスを追加してください。
存在しないコレクションにアーティファクトをリンクしようとすると、W&B は自動的にコレクションを作成します。存在するコレクションを指定した場合、W&B はそのアーティファクトを既存のコレクションにリンクします。
次のコードスニペットは、プログラムでコレクションを作成する方法を示しています。他の <> で囲まれた値を必ず自分の値で置き換えてください。
import wandb
# Run を初期化
run = wandb. init(entity = "<team_entity>" , project = "<project>" )
# アーティファクトオブジェクトを作成
artifact = wandb. Artifact(
name = "<artifact_name>" ,
type = "<artifact_type>"
)
registry_name = "<registry_name>"
collection_name = "<collection_name>"
target_path = f "wandb-registry- { registry_name} / { collection_name} "
# アーティファクトをコレクションにリンク
run. link_artifact(artifact = artifact, target_path = target_path)
run. finish()
インタラクティブにコレクションを作成する
以下のステップで、W&B レジストリ アプリ UI を使用してレジストリ内にコレクションを作成する方法を説明します。
W&B アプリ UI の Registry アプリに移動します。
レジストリを選択します。
右上の Create collection ボタンをクリックします。
Name フィールドにコレクションの名前を入力します。Type ドロップダウンからタイプを選択します。または、レジストリがカスタムアーティファクトタイプを有効にしている場合は、このコレクションが受け入れる1つ以上のアーティファクトタイプを提供します。オプションで、Description フィールドにコレクションの説明を追加します。
オプションで、Tags フィールドに1つ以上のタグを追加します。
Link version をクリックします。Project ドロップダウンから、アーティファクトが保存されているプロジェクトを選択します。Artifact コレクションのドロップダウンからアーティファクトを選択します。Version ドロップダウンから、コレクションにリンクしたいアーティファクトバージョンを選択します。Create collection ボタンをクリックします。
4.4.5 - レジストリにアーティファクトバージョンをリンクする
リンクアーティファクトのバージョンをコレクションに追加して、組織内の他のメンバーがアクセスできるようにします。
アーティファクトをレジストリにリンクすると、そのアーティファクトがそのレジストリに「公開」されます。 レジストリにアクセスできるユーザーは、コレクション内のリンクされたアーティファクトのバージョンにアクセスできます。
言い換えれば、アーティファクトをレジストリコレクションにリンクすることによって、アーティファクトのバージョンはプライベートなプロジェクトレベルのスコープから、共有される組織レベルのスコープになります。
アーティファクトをコレクションにリンクする
アーティファクトバージョンをインタラクティブまたはプログラム的にコレクションにリンクします。
レジストリにアーティファクトをリンクする前に、コレクションが許可しているアーティファクトのタイプを確認してください。 コレクションタイプの詳細については、
コレクションを作成する 内の「コレクションタイプ」を参照してください。
ユースケースに基づいて、以下のタブで説明されている手順に従ってアーティファクトバージョンをリンクしてください。
アーティファクトバージョンがメトリクスをログに記録している場合（
run.log_artifact()を使用するなど）、そのバージョンの詳細ページからメトリクスを閲覧することができ、アーティファクトのページからアーティファクトバージョン間のメトリクスを比較することができます。
レジストリでリンクされたアーティファクトを見る を参照してください。
Python SDK
Registry App
Artifact browser
プログラム的にアーティファクトバージョンをコレクションにリンクするには、wandb.init.Run.link_artifact()
アーティファクトをコレクションにリンクする前に、そのコレクションが所属するレジストリが既に存在することを確認してください。 レジストリが存在するかどうかを確認するには、W&B App UIのレジストリアプリにアクセスし、レジストリの名前を検索してください。
target_path パラメータを使用して、リンクするアーティファクトバージョンのコレクションとレジストリを指定します。ターゲットパスは、プレフィックス “wandb-registry”、レジストリの名前、コレクション名がフォワードスラッシュで区切られています。
wandb-registry-{REGISTRY_NAME}/{COLLECTION_NAME}
以下のコードスニペットをコピーして貼り付け、既存のレジストリ内のコレクションにアーティファクトバージョンをリンクしてください。<>で囲まれた値を自分の値に置き換えてください。
import wandb
# run を初期化
run = wandb. init(
entity = "<チームエンティティ>" ,
project = "<プロジェクト名>"
)
# アーティファクトオブジェクトの作成
# type パラメータは、アーティファクトオブジェクトとコレクションタイプの両方のタイプを指定します
artifact = wandb. Artifact(name = "<名前>" , type = "<type>" )
# アーティファクトオブジェクトにファイルを追加
# ファイルのパスをローカルマシンで指定します
artifact. add_file(local_path = "<アーティファクトのローカルパス>" )
# アーティファクトをリンクするコレクションとレジストリを指定
REGISTRY_NAME = "<registry_name>"
COLLECTION_NAME = "<collection_name>"
target_path= f "wandb-registry- { REGISTRY_NAME} / { COLLECTION_NAME} "
# アーティファクトをコレクションにリンク
run. link_artifact(artifact = artifact, target_path = target_path)
アーティファクトバージョンをモデルレジストリまたはデータセットレジストリにリンクする場合、アーティファクトのタイプをそれぞれ "model" または "dataset" に設定してください。
Registry App に移動します。
アーティファクトバージョンをリンクするコレクションの名前の隣にマウスをホバーさせます。
詳細を表示 の隣にあるミートボールメニューアイコン（三つの横に並んだ点）を選択します。ドロップダウンから、新しいバージョンをリンク を選択します。
サイドバーから、Team ドロップダウンからチームの名前を選択します。
Project ドロップダウンからアーティファクトを含むプロジェクトの名前を選択します。Artifact ドロップダウンからアーティファクトの名前を選択します。Version ドロップダウンからコレクションにリンクしたいアーティファクトのバージョンを選択します。
プロジェクトのアーティファクトブラウザに移動します。URLは: https://wandb.ai/<entity>/<project>/artifacts
左サイドバーでアーティファクトアイコンを選択します。
レジストリにリンクしたいアーティファクトバージョンをクリックします。
バージョン概要 セクション内で、Link to registry ボタンをクリックします。画面右側に表示されるモーダルで、Select a registered model メニューのドロップダウンからアーティファクトを選択します。
次のステップ をクリックします。(任意) Aliases ドロップダウンから別名を選択します。
Link to registry をクリックします。
リンクされたアーティファクトのメタデータ、バージョンデータ、使用状況、リネージ情報などをRegistry Appで表示します。
リンクされたアーティファクトをレジストリで表示する
Registry Appでメタデータ、リネージ、使用状況情報などのリンクされたアーティファクト情報を表示します。
Registry App に移動します。
アーティファクトをリンクしたレジストリの名前を選択します。
コレクションの名前を選択します。
コレクションのアーティファクトがメトリクスをログしている場合、メトリクスを表示 をクリックしてバージョンを比較します。
アーティファクトバージョンのリストから、アクセスしたいバージョンを選択します。バージョン番号は v0 から始まる増分で各リンクされたアーティファクトバージョンに割り当てられます。
アーティファクトバージョンの詳細を表示するには、そのバージョンをクリックします。このページのタブから、そのバージョンのメタデータ（ログされたメトリクスを含む）、リネージ、使用状況情報を表示できます。
バージョンタブ 内の フルネーム フィールドに注意してください。リンクされたアーティファクトのフルネームは、レジストリ、コレクション名、アーティファクトのバージョンのエイリアスまたはインデックスから構成されています。
wandb-registry-{REGISTRY_NAME}/{COLLECTION_NAME}:v{INTEGER}
プログラム的にアーティファクトバージョンにアクセスするには、リンクされたアーティファクトのフルネームが必要です。
トラブルシューティング
アーティファクトをリンクできない場合は、次のような一般的なチェックを確認してください。
個人アカウントからアーティファクトをログする
個人エンティティを使用してW&Bにログされたアーティファクトはレジストリにリンクすることができません。 アーティファクトを組織内のチームエンティティを使用してログに記録していることを確認してください。 組織のチーム内でログに記録されたアーティファクトのみが組織のレジストリにリンクされることができます。
アーティファクトをレジストリにリンクしたい場合は、チームエンティティを使用してアーティファクトをログしてください。
あなたのチームエンティティを見つける
W&B はあなたのチームの名前をチームのエンティティとして使用します。 例えば、あなたのチームが team-awesome と呼ばれている場合、あなたのチームエンティティは team-awesome です。
あなたのチームの名前を確認するには：
あなたのチームの W&B プロファイルページに移動します。
サイトの URL をコピーします。それはhttps://wandb.ai/<team>の形式です。ここで <team> はあなたのチームの名前とチームのエンティティの両方です。
チームエンティティからログする
wandb.init()entity を指定しなかった場合、run はあなたのデフォルトエンティティを使用しますが、それがチームエンティティであるとは限りません。
import wandb
run = wandb. init(
entity= '<team_entity>' ,
project= '<project_name>'
)
run にアーティファクトをログするには、run.log_artifact を使用するか、Artifact オブジェクトを作成してからファイルを追加します:
artifact = wandb. Artifact(name= "<artifact_name>" , type= "<type>" )
アーティファクトのログ方法についての詳細は、アーティファクトを構成する を参照してください。
個人エンティティにログされたアーティファクトがある場合、それを組織内のエンティティに再ログする必要があります。
W&B App UIでレジストリのパスを確認する
UIを使用してレジストリのパスを確認する方法は2つあります: 空のコレクションを作成してコレクションの詳細を表示するか、コレクションのホームページで自動生成されたコードをコピー＆ペーストすることです。
自動生成されたコードをコピーして貼り付ける
Registry app に移動します: https://wandb.ai/registry/ .
アーティファクトをリンクしたいレジストリをクリックします。
ページの上部に自動生成されたコードブロックが表示されます。
これをコピーしてコードに貼り付け、パスの最後の部分をコレクションの名前に置き換えてください。
空のコレクションを作成する
Registry app に移動します: https://wandb.ai/registry/ .
アーティファクトをリンクしたいレジストリをクリックします。
空のコレクションをクリックします。 空のコレクションが存在しない場合は、新しいコレクションを作成します。
表示されるコードスニペット内で、.link_artifact() 内の target_path フィールドを識別します。
(任意) コレクションを削除します。
例えば、上記の手順を完了した後、target_pathパラメータを持つコードブロックを見つけます：
target_path =
"smle-registries-bug-bash/wandb-registry-Golden Datasets/raw_images"
これを構成要素に分解すると、プログラム的にアーティファクトをリンクするために必要なパスを作成するために必要なものが見えます：
ORG_ENTITY_NAME = "smle-registries-bug-bash"
REGISTRY_NAME = "Golden Datasets"
COLLECTION_NAME = "raw_images"
一時コレクションのコレクション名を、リンクしたいアーティファクトのコレクション名に置き換えることを忘れないでください。
4.4.6 - レジストリからアーティファクトをダウンロードする
W&B Python SDK を使用して、レジストリにリンクされたアーティファクトをダウンロードします。アーティファクトをダウンロードして使用するには、レジストリ名、コレクション名、およびダウンロードしたいアーティファクトバージョンのエイリアスまたはインデックスを知る必要があります。
アーティファクトのプロパティを知ったら、リンクされたアーティファクトへのパスを構築 してアーティファクトをダウンロードできます。または、W&B アプリ UI から事前に生成されたコードスニペットをコピーして貼り付け することで、レジストリにリンクされたアーティファクトをダウンロードすることもできます。
リンクされたアーティファクトへのパスを構築
レジストリにリンクされたアーティファクトをダウンロードするには、そのリンクされたアーティファクトのパスを知っている必要があります。パスは、レジストリ名、コレクション名、およびアクセスしたいアーティファクトバージョンのエイリアスまたはインデックスで構成されます。
レジストリ、コレクション、およびアーティファクトバージョンのエイリアスまたはインデックスを手に入れたら、以下の文字列テンプレートを使用してリンクされたアーティファクトへのパスを構築できます。
# バージョンインデックスを指定したアーティファクト名
f "wandb-registry- { REGISTRY} / { COLLECTION} :v { INDEX} "
# エイリアスを指定したアーティファクト名
f "wandb-registry- { REGISTRY} / { COLLECTION} : { ALIAS} "
中括弧 {} 内の値を、アクセスしたいレジストリ、コレクション、およびアーティファクトバージョンのエイリアスまたはインデックスの名前で置き換えてください。
アーティファクトバージョンをコアモデルレジストリまたはコアデータセットレジストリにリンクするには、model または dataset を指定してください。
リンクされたアーティファクトのパスを取得したら、wandb.init.use_artifact メソッドを使用してアーティファクトにアクセスし、その内容をダウンロードします。以下のコードスニペットは、W&B レジストリにリンクされたアーティファクトを使用およびダウンロードする方法を示しています。<> 内の値を自分のものに置き換えてください。
import wandb
REGISTRY = '<registry_name>'
COLLECTION = '<collection_name>'
ALIAS = '<artifact_alias>'
run = wandb. init(
entity = '<team_name>' ,
project = '<project_name>'
)
artifact_name = f "wandb-registry- { REGISTRY} / { COLLECTION} : { ALIAS} "
# artifact_name = '<artifact_name>' # Registry App で指定されたフルネームをコピーして貼り付け
fetched_artifact = run. use_artifact(artifact_or_name = artifact_name)
download_path = fetched_artifact. download()
.use_artifact() メソッドは、run を作成するとともに、ダウンロードしたアーティファクトをその run の入力としてマークします。 アーティファクトを run の入力としてマークすることにより、W&B はそのアーティファクトのリネージを追跡できます。
runを作成したくない場合は、wandb.Api() オブジェクトを使用してアーティファクトにアクセスできます。
import wandb
REGISTRY = "<registry_name>"
COLLECTION = "<collection_name>"
VERSION = "<version>"
api = wandb. Api()
artifact_name = f "wandb-registry- { REGISTRY} / { COLLECTION} : { VERSION} "
artifact = api. artifact(name = artifact_name)
例: W&B レジストリにリンクされたアーティファクトを使用およびダウンロード
次のコード例は、ユーザーが Fine-tuned Models レジストリにある phi3-finetuned というコレクションにリンクされたアーティファクトをダウンロードする方法を示しています。アーティファクトバージョンのエイリアスは production に設定されています。
import wandb
TEAM_ENTITY = "product-team-applications"
PROJECT_NAME = "user-stories"
REGISTRY = "Fine-tuned Models"
COLLECTION = "phi3-finetuned"
ALIAS = 'production'
# 指定されたチームとプロジェクト内で run を初期化
run = wandb. init(entity= TEAM_ENTITY, project = PROJECT_NAME)
artifact_name = f "wandb-registry- { REGISTRY} / { COLLECTION} : { ALIAS} "
# アーティファクトにアクセスし、それをリネージ追跡のために run の入力としてマーク
fetched_artifact = run. use_artifact(artifact_or_name = name)
# アーティファクトをダウンロード。ダウンロードされたコンテンツのパスを返します
downloaded_path = fetched_artifact. download()
APIリファレンスガイドの use_artifactArtifact.download()
複数の組織に所属する個人エンティティを持つユーザー 複数の組織に所属する個人エンティティを持つユーザーは、レジストリにリンクされたアーティファクトにアクセスする際、組織名を指定するか、チームエンティティを使用する必要があります。
import wandb
REGISTRY = "<registry_name>"
COLLECTION = "<collection_name>"
VERSION = "<version>"
# API をインスタンス化する際に、自分のチームエンティティを使用していることを確認
api = wandb. Api(overrides= {"entity" : "<team-entity>" })
artifact_name = f "wandb-registry- { REGISTRY} / { COLLECTION} : { VERSION} "
artifact = api. artifact(name = artifact_name)
# パスに組織の表示名または組織エンティティを使用
api = wandb. Api()
artifact_name = f " { ORG_NAME} /wandb-registry- { REGISTRY} / { COLLECTION} : { VERSION} "
artifact = api. artifact(name = artifact_name)
ORG_NAME は組織の表示名です。マルチテナント SaaS ユーザーは、https://wandb.ai/account-settings/ の組織の設定ページで組織名を見つけることができます。専用クラウドおよび自己管理ユーザーの場合、組織の表示名を確認するには、アカウント管理者に連絡してください。
事前に生成されたコードスニペットのコピーと貼り付け
W&B は、レジストリにリンクされたアーティファクトをダウンロードするために、Pythonスクリプト、ノートブック、またはターミナルにコピーして貼り付けることができるコードスニペットを作成します。
レジストリアプリに移動します。
アーティファクトを含むレジストリの名前を選択します。
コレクションの名前を選択します。
アーティファクトバージョンのリストからアクセスするバージョンを選択します。
Usage タブを選択します。Usage API セクションに表示されたコードスニペットをコピーします。コピーしたコードスニペットを Python スクリプト、ノートブック、またはターミナルに貼り付けます。
4.4.7 - バージョンをタグで整理する
コレクションやコレクション内のアーティファクト バージョンを整理するためにタグを使用します。タグは、Python SDK または W&B アプリ UI で追加、削除、編集が可能です。
コレクションやアーティファクトバージョンをレジストリ内で整理するためにタグを作成し追加します。W&B アプリ UI または W&B Python SDK を使用して、コレクションまたはアーティファクトバージョンにタグを追加、変更、表示、削除できます。
エイリアスとタグの使い分け 特定のアーティファクトバージョンを一意に参照する必要がある場合は、エイリアスを使用します。例えば、artifact_name:alias が常に単一で特定のバージョンを指すように、「production」や「latest」といったエイリアスを使用します。
より自由にグループ化や検索をしたい場合は、タグを使用します。タグは複数のバージョンやコレクションが同じラベルを共有できるときに理想的で、特定の識別子に関連付けられるバージョンが一つだけである保証は必要ありません。
コレクションにタグを追加する
W&B アプリ UI または Python SDK を使用してコレクションにタグを追加します。
W&B アプリ UI を使用してコレクションにタグを追加します。
W&B レジストリに移動します: https://wandb.ai/registry
レジストリカードをクリックします
コレクション名の横にある View details をクリックします
コレクションカード内で、Tags フィールドの隣にあるプラスアイコン (+ ) をクリックし、タグの名前を入力します
キーボードの Enter を押します
import wandb
COLLECTION_TYPE = "<collection_type>"
ORG_NAME = "<org_name>"
REGISTRY_NAME = "<registry_name>"
COLLECTION_NAME = "<collection_name>"
full_name = f " { ORG_NAME} /wandb-registry- { REGISTRY_NAME} / { COLLECTION_NAME} "
collection = wandb. Api(). artifact_collection(
type_name = COLLECTION_TYPE,
name = full_name
)
collection. tags = ["your-tag" ]
collection. save()
コレクションに属するタグを更新する
tags 属性を再割り当てするか、変更することでプログラム上でタグを更新します。W&B は tags 属性をインプレースで変更するのではなく、再割り当てすることを推奨しており、これは良い Python の習慣でもあります。
例えば、以下のコードスニペットは、再割り当てを用いてリストを更新する一般的な方法を示しています。簡潔にするために、このコード例は コレクションにタグを追加するセクション から続いています。
collection. tags = [* collection. tags, "new-tag" , "other-tag" ]
collection. tags = collection. tags + ["new-tag" , "other-tag" ]
collection. tags = set(collection. tags) - set(tags_to_delete)
collection. tags = [] # すべてのタグを削除
次のコードスニペットは、インプレースでの変更を使用してアーティファクトバージョンに属するタグを更新する方法を示しています。
collection. tags += ["new-tag" , "other-tag" ]
collection. tags. append("new-tag" )
collection. tags. extend(["new-tag" , "other-tag" ])
collection. tags[:] = ["new-tag" , "other-tag" ]
collection. tags. remove("existing-tag" )
collection. tags. pop()
collection. tags. clear()
コレクションに属するタグを表示する
W&B アプリ UI を使用してコレクションに追加されたタグを表示します。
W&B レジストリに移動します: https://wandb.ai/registry
レジストリカードをクリックします
コレクション名の横にある View details をクリックします
コレクションに 1 つ以上のタグがある場合、それらのタグはコレクションカード内の Tags フィールドの隣に表示されます。
コレクションに追加されたタグは、コレクション名の隣にも表示されます。
例えば、以下の画像では、「zoo-dataset-tensors」コレクションに “tag1” というタグが追加されています。
コレクションからタグを削除する
W&B アプリ UI を使用してコレクションからタグを削除します。
W&B レジストリに移動します: https://wandb.ai/registry
レジストリカードをクリックします
コレクション名の横にある View details をクリックします
コレクションカード内で、削除したいタグの名前の上にマウスを移動してください
キャンセルボタン（X アイコン）をクリックします
アーティファクトバージョンにタグを追加する
W&B アプリ UI または Python SDK を使用して、コレクションにリンクされたアーティファクトバージョンにタグを追加します。
W&B レジストリに移動します: https://wandb.ai/registry
レジストリカードをクリックします
タグを追加したいコレクションの名前の横にある View details をクリックします
下にスクロールして Versions を表示します
アーティファクトバージョンの横にある View をクリックします
Version タブ内で、Tags フィールドの隣にあるプラスアイコン (+ ) をクリックし、タグの名前を入力しますキーボードの Enter を押します
タグを追加または更新したいアーティファクトバージョンを取得します。アーティファクトバージョンを取得したら、アーティファクトオブジェクトの tag 属性にアクセスして、そのアーティファクトのタグを追加または変更します。1 つ以上のタグをリストとして tag 属性に渡します。
他のアーティファクト同様、W&B からアーティファクトを取得するのに run を作成する必要はありませんが、run を作成し、その run の中でアーティファクトを取得することもできます。どちらの場合でも、W&B サーバー上でアーティファクトを更新するために、アーティファクトオブジェクトの save メソッドを呼び出すことを確認してください。
以下のコードセルをコピーして、アーティファクトバージョンのタグを追加または変更します。<> 内の値を自分のものに置き換えてください。
次のコードスニペットは、新しい run を作成せずにアーティファクトを取得してタグを追加する方法を示しています。
import wandb
ARTIFACT_TYPE = "<TYPE>"
ORG_NAME = "<org_name>"
REGISTRY_NAME = "<registry_name>"
COLLECTION_NAME = "<collection_name>"
VERSION = "<artifact_version>"
artifact_name = f " { ORG_NAME} /wandb-registry- { REGISTRY_NAME} / { COLLECTION_NAME} :v { VERSION} "
artifact = wandb. Api(). artifact(name = artifact_name, type = ARTIFACT_TYPE)
artifact. tags = ["tag2" ] # リストに 1 つ以上のタグを提供
artifact. save()
次のコードスニペットは、新しい run を作成してアーティファクトを取得し、タグを追加する方法を示しています。
import wandb
ORG_NAME = "<org_name>"
REGISTRY_NAME = "<registry_name>"
COLLECTION_NAME = "<collection_name>"
VERSION = "<artifact_version>"
run = wandb. init(entity = "<entity>" , project= "<project>" )
artifact_name = f " { ORG_NAME} /wandb-registry- { REGISTRY_NAME} / { COLLECTION_NAME} :v { VERSION} "
artifact = run. use_artifact(artifact_or_name = artifact_name)
artifact. tags = ["tag2" ] # リストに 1 つ以上のタグを提供
artifact. save()
アーティファクトバージョンに属するタグを更新する
tags 属性を再割り当てするか、変更することでプログラム上でタグを更新します。W&B は tags 属性をインプレースで変更するのではなく、再割り当てすることを推奨しており、これは良い Python の習慣でもあります。
例えば、以下のコードスニペットは、再割り当てを用いてリストを更新する一般的な方法を示しています。簡潔にするために、このコード例は アーティファクトバージョンにタグを追加するセクション から続いています。
artifact. tags = [* artifact. tags, "new-tag" , "other-tag" ]
artifact. tags = artifact. tags + ["new-tag" , "other-tag" ]
artifact. tags = set(artifact. tags) - set(tags_to_delete)
artifact. tags = [] # すべてのタグを削除
次のコードスニペットは、インプレースでの変更を使用してアーティファクトバージョンに属するタグを更新する方法を示しています。
artifact. tags += ["new-tag" , "other-tag" ]
artifact. tags. append("new-tag" )
artifact. tags. extend(["new-tag" , "other-tag" ])
artifact. tags[:] = ["new-tag" , "other-tag" ]
artifact. tags. remove("existing-tag" )
artifact. tags. pop()
artifact. tags. clear()
アーティファクトバージョンに属するタグを表示する
W&B アプリ UI または Python SDK を使用して、レジストリにリンクされたアーティファクトバージョンに属するタグを表示します。
W&B レジストリに移動します: https://wandb.ai/registry
レジストリカードをクリックします
タグを追加したいコレクションの名前の横にある View details をクリックします
下にスクロールして Versions セクションを表示します
アーティファクトバージョンに 1 つ以上のタグがある場合、それらのタグは Tags 列に表示されます。
アーティファクトバージョンを取得して、そのタグを表示します。アーティファクトバージョンを取得したら、アーティファクトオブジェクトの tag 属性を表示して、そのアーティファクトに属するタグを表示します。
他のアーティファクト同様、W&B からアーティファクトを取得するのに run を作成する必要はありませんが、run を作成し、その run の中でアーティファクトを取得することもできます。
以下のコードセルをコピーして、アーティファクトバージョンのタグを追加または変更します。<> 内の値を自分のものに置き換えてください。
次のコードスニペットは、新しい run を作成せずにアーティファクトバージョンを取得して表示する方法を示しています。
import wandb
ARTIFACT_TYPE = "<TYPE>"
ORG_NAME = "<org_name>"
REGISTRY_NAME = "<registry_name>"
COLLECTION_NAME = "<collection_name>"
VERSION = "<artifact_version>"
artifact_name = f " { ORG_NAME} /wandb-registry- { REGISTRY_NAME} / { COLLECTION_NAME} :v { VERSION} "
artifact = wandb. Api(). artifact(name = artifact_name, type = artifact_type)
print(artifact. tags)
次のコードスニペットは、新しい run を作成してアーティファクトバージョンのタグを取得して表示する方法を示しています。
import wandb
ORG_NAME = "<org_name>"
REGISTRY_NAME = "<registry_name>"
COLLECTION_NAME = "<collection_name>"
VERSION = "<artifact_version>"
run = wandb. init(entity = "<entity>" , project= "<project>" )
artifact_name = f " { ORG_NAME} /wandb-registry- { REGISTRY_NAME} / { COLLECTION_NAME} :v { VERSION} "
artifact = run. use_artifact(artifact_or_name = artifact_name)
print(artifact. tags)
アーティファクトバージョンからタグを削除する
W&B レジストリに移動します: https://wandb.ai/registry
レジストリカードをクリックします
タグを追加したいコレクションの名前の横にある View details をクリックします
下にスクロールして Versions を表示します
アーティファクトバージョンの横にある View をクリックします
Version タブ内でタグの名前の上にマウスを移動してくださいキャンセルボタン（X アイコン）をクリックします
既存のタグを検索する
W&B アプリ UI を使用して、コレクションやアーティファクトバージョン内の既存のタグを検索します。
W&B レジストリに移動します: https://wandb.ai/registry
レジストリカードをクリックします
検索バー内にタグの名前を入力します
特定のタグを持つアーティファクトバージョンを見つける
W&B Python SDK を使用して、特定のタグセットを持つアーティファクトバージョンを見つけます。
import wandb
api = wandb. Api()
tagged_artifact_versions = api. artifacts(
type_name = "<artifact_type>" ,
name = "<artifact_name>" ,
tags = ["<tag_1>" , "<tag_2>" ]
)
for artifact_version in tagged_artifact_versions:
print(artifact_version. tags)
4.4.8 - レジストリ項目を見つける
W&B レジストリアプリのグローバル検索バー を使用して、レジストリ、コレクション、アーティファクトバージョンタグ、コレクションタグ、またはエイリアスを見つけます。W&B Python SDK を使用して、特定の条件に基づいて レジストリ、コレクション、およびアーティファクトバージョンをフィルタリング するために、MongoDBスタイルのクエリを使用することができます。
表示権限がある項目のみが検索結果に表示されます。
レジストリ項目の検索
レジストリ項目を検索するには:
W&B レジストリアプリに移動します。
ページ上部の検索バーに検索語を指定します。Enter を押して検索します。
指定した語が既存のレジストリ、コレクション名、アーティファクトバージョンタグ、コレクションタグ、またはエイリアスと一致する場合、検索バーの下に検索結果が表示されます。
MongoDBスタイルのクエリでレジストリ項目をクエリ
wandb.Api().registries()query predicates を使用して、1つ以上の MongoDBスタイルクエリ に基づいて、レジストリ、コレクション、およびアーティファクトバージョンをフィルタリングします。
以下の表は、フィルタリングしたい項目の種類に基づいて使用できるクエリの名前を示しています。
クエリ名
registries
name, description, created_at, updated_at
collections
name, tag, description, created_at, updated_at
versions
tag, alias, created_at, updated_at, metadata
以下のコード例は、一般的な検索シナリオを示しています。
wandb.Api().registries() メソッドを使用するには、まず W&B Python SDK （wandb
import wandb
# （オプション）読みやすさのために、wandb.Api() クラスのインスタンスを作成します。
api = wandb. Api()
model という文字列を含むすべてのレジストリをフィルタリングします。
# `model` という文字列を含むすべてのレジストリをフィルタリングします。
registry_filters = {
"name" : {"$regex" : "model" }
}
# フィルタに一致するすべてのレジストリの反復可能なオブジェクトを返します
registries = api. registries(filter= registry_filters)
レジストリに関係なく、コレクション名に yolo という文字列を含むすべてのコレクションをフィルタリングします。
# レジストリに関係なく、コレクション名に
# `yolo` という文字列を含むすべてのコレクションをフィルタリングします。
collection_filters = {
"name" : {"$regex" : "yolo" }
}
# フィルタに一致するすべてのコレクションの反復可能なオブジェクトを返します
collections = api. registries(). collections(filter= collection_filters)
レジストリに関係なく、コレクション名に yolo という文字列を含み、cnn というタグを持つすべてのコレクションをフィルタリングします。
# レジストリに関係なく、コレクション名に
# `yolo` という文字列を含み、`cnn` というタグを持つすべてのコレクションをフィルタリングします。
collection_filters = {
"name" : {"$regex" : "yolo" },
"tag" : "cnn"
}
# フィルタに一致するすべてのコレクションの反復可能なオブジェクトを返します
collections = api. registries(). collections(filter= collection_filters)
model という文字列を含むすべてのアーティファクトバージョンを検索し、image-classification というタグまたは latest エイリアスを持っているもの：
# `model` という文字列を含むすべてのアーティファクトバージョンを検索し、
# `image-classification` というタグまたは `latest` エイリアスを持っているもの。
registry_filters = {
"name" : {"$regex" : "model" }
}
# 論理 $or 演算子を使用してアーティファクトバージョンをフィルタリングします
version_filters = {
"$or" : [
{"tag" : "image-classification" },
{"alias" : "production" }
]
}
# フィルタに一致するすべてのアーティファクトバージョンの反復可能なオブジェクトを返します
artifacts = api. registries(filter= registry_filters). collections(). versions(filter= version_filters)
詳細については、MongoDB ドキュメントの logical query operators を参照してください。
前述のコードスニペット内の artifacts の反復可能なオブジェクトの各項目は、Artifact クラスのインスタンスです。つまり、各アーティファクトの属性（name、collection、aliases、tags、created_at など）にアクセスできます。
for art in artifacts:
print(f "artifact name: { art. name} " )
print(f "collection artifact belongs to: { art. collection. name} " )
print(f "artifact aliases: { art. aliases} " )
print(f "tags attached to artifact: { art. tags} " )
print(f "artifact created at: { art. created_at} \n " )
アーティファクトオブジェクトの属性の完全なリストについては、API Reference docs の Artifacts Class を参照してください。
レジストリやコレクションに関係なく、2024-01-08 から 2025-03-04 の 13:10 UTC の間に作成されたすべてのアーティファクトバージョンをフィルタリングします。
# 2024-01-08 から 2025-03-04 の 13:10 UTC の間に作成された
# すべてのアーティファクトバージョンを検索します。
artifact_filters = {
"alias" : "latest" ,
"created_at" : {"$gte" : "2024-01-08" , "$lte" : "2025-03-04 13:10:00" },
}
# フィルタに一致するすべてのアーティファクトバージョンの反復可能なオブジェクトを返します
artifacts = api. registries(). collections(). versions(filter= artifact_filters)
日付と時刻は YYYY-MM-DD HH:MM:SS の形式で指定します。日付のみでフィルタリングしたい場合は、時間、分、秒を省略することができます。
詳細は、MongoDB ドキュメントの query comparisons を参照してください。
4.4.9 - コレクションに注釈を付ける
コレクションに人間が理解しやすいテキストを追加して、ユーザーがコレクションの目的とその中に含まれるアーティファクトを理解するのを助けます。
コレクションに応じて、トレーニングデータ、モデルアーキテクチャー、タスク、ライセンス、参考文献、デプロイメントに関する情報を含めることをお勧めします。以下は、コレクションで文書化する価値のあるトピックのリストです。
W&Bは少なくともこれらの詳細を含めることを推奨します。
概要 : コレクションの目的。機械学習実験に使用された機械学習フレームワーク。ライセンス : 機械学習モデルの使用に関連する法的条件と許可。モデルのユーザーがどの法的枠組みの下でモデルを利用できるかを理解するのに役立ちます。一般的なライセンスには、Apache 2.0、MIT、GPL などがあります。参考文献 : 関連する研究論文、データセット、または外部リソースへの引用または参考文献。
コレクションにトレーニングデータが含まれている場合は、以下の詳細を考慮してください。
トレーニングデータ : 使用したトレーニングデータの説明プロセッシング : トレーニングデータセットに対して行われたプロセッシング。データストレージ : そのデータがどこに保存されていて、どのようにアクセスするか。
コレクションに機械学習モデルが含まれている場合は、以下の詳細を考慮してください。
アーキテクチャー : モデルのアーキテクチャー、レイヤー、および特定のデザイン選択に関する情報。タスク : コレクションモデルが実行するように設計された特定のタスクまたは問題の種類。モデルの意図された能力のカテゴリ分けです。モデルをデシリアライズ : あなたのチームの誰かがモデルをメモリにロードする方法に関する情報を提供してください。タスク : 機械学習モデルが実行するように設計された特定のタスクまたは問題の種類。モデルの意図された能力のカテゴリ分けです。デプロイメント : モデルがどのように、どこでデプロイされるかに関する詳細、およびワークフローのオーケストレーションプラットフォームなどの他の企業システムにモデルを統合する方法に関するガイダンス。
コレクションに説明を追加する
W&B Registry UIまたはPython SDKを使用して、インタラクティブまたはプログラム的にコレクションに説明を追加します。
W&B Registry UI
Python SDK
https://wandb.ai/registry/ でW&B Registryにアクセスします。コレクションをクリックします。
コレクション名の横にある詳細を表示 を選択します。
説明 フィールド内で、コレクションに関する情報を提供します。Markdownマークアップ言語 でテキストをフォーマットします。
wandb.Api().artifact_collection()description プロパティを使用してコレクションに説明を追加または更新します。
type_nameパラメータにはコレクションのタイプを、nameパラメータにはコレクションの完全な名前を指定します。コレクションの名前は「wandb-registry」、レジストリの名前、およびコレクションの名前をスラッシュで区切ったものです:
wandb-registry-{REGISTRY_NAME}/{COLLECTION_NAME}
以下のコードスニペットをあなたのPythonスクリプトまたはノートブックにコピーペーストします。角括弧で囲まれた値 (<>) をあなた独自のものに置き換えてください。
import wandb
api = wandb. Api()
collection = api. artifact_collection(
type_name = "<collection_type>" ,
name = "<collection_name>"
)
collection. description = "This is a description."
collection. save()
例えば、以下の画像は、モデルのアーキテクチャー、意図された使用法、パフォーマンス情報などをドキュメントしているコレクションを示しています。
4.4.10 - リネージ マップを作成および表示する
W&B Registry でリネージ マップを作成する。
W&B レジストリ内のコレクションでは、ML 実験が使用するアーティファクトの履歴を確認することができます。この履歴は リネージグラフ と呼ばれます。
コレクションの一部ではないアーティファクトに対しても、W&Bにログを記録したリネージグラフを表示することができます。
リネージグラフは、アーティファクトをログする特定の run を表示できます。さらに、リネージグラフはどの run がアーティファクトを入力として使用したかも表示できます。言い換えると、リネージグラフはrun の入力と出力を表示できます。
例えば、次の画像は ML 実験全体で作成および使用されたアーティファクトを示しています。
左から右に、画像は以下を示しています。
複数の runs が split_zoo_dataset:v4 アーティファクトをログします。
“rural-feather-20” run は split_zoo_dataset:v4 アーティファクトをトレーニング用に使用します。
“rural-feather-20” run の出力は zoo-ylbchv20:v0 というモデルのアーティファクトです。
“northern-lake-21” という run はモデルを評価するために zoo-ylbchv20:v0 モデルアーティファクトを使用します。
run の入力をトラックする
wandb.init.use_artifact API を使用して、run の入力または依存関係としてアーティファクトをマークします。
次のコードスニペットは、use_artifact の使用方法を示しています。山括弧 (< >) で囲まれた値をあなたの値に置き換えてください。
import wandb
# run を初期化する
run = wandb. init(project= "<project>" , entity= "<entity>" )
# アーティファクトを取得し、依存関係としてマークする
artifact = run. use_artifact(artifact_or_name= "<name>" , aliases= "<alias>" )
run の出力をトラックする
作成したアーティファクトの出力を run の出力として宣言するには、(wandb.init.log_artifact
次のコードスニペットは、wandb.init.log_artifact API の使用方法を示しています。山括弧 (< >) で囲まれた値をあなたの値に置き換えるようにしてください。
import wandb
# run を初期化する
run = wandb. init(entity "<entity>" , project = "<project>" ,)
artifact = wandb. Artifact(name = "<artifact_name>" , type = "<artifact_type>" )
artifact. add_file(local_path = "<local_filepath>" , name= "<optional-name>" )
# アーティファクトをログとして run の出力にする
run. log_artifact(artifact_or_path = artifact)
アーティファクトの作成に関する詳細については、Create an artifact を参照してください。
コレクション内のリネージグラフを表示する
W&B レジストリ内のコレクションにリンクされたアーティファクトのリネージを表示します。
W&B レジストリに移動します。
アーティファクトを含むコレクションを選択します。
ドロップダウンから、リネージグラフを表示したいアーティファクトのバージョンをクリックします。
「Lineage」タブを選択します。
アーティファクトのリネージグラフのページに移動すると、そのリネージグラフ内の任意のノードに関する追加情報を表示できます。
run ノードを選択して、その run の詳細（run の ID、run の名前、run の状態など）を表示します。例として、次の画像は rural-feather-20 run に関する情報を示しています。
アーティファクトノードを選択して、そのアーティファクトの詳細（完全な名前、タイプ、作成時間、関連するエイリアスなど）を表示します。
4.4.11 - レガシー モデルレジストリ から移行する
W&B は旧 W&B モデルレジストリ から新しい W&B レジストリ への資産の移行を行います。この移行は W&B が完全に管理し、ユーザーの介入を必要としません。このプロセスは、既存のワークフローに最小限の影響を与えるよう、できる限りシームレスに行うよう設計されています。
移行は、新しい W&B レジストリが現在のモデルレジストリで利用可能なすべての機能を含んだ時点で行われます。W&B は、現在のワークフロー、コードベース、参照を維持するよう努めます。
このガイドは常に更新され、新しい情報が得られるたびに更新されます。質問やサポートが必要な場合は、support@wandb.com に問い合わせてください。
W&B レジストリが旧モデルレジストリと異なる点
W&B レジストリは、モデル、データセット、およびその他のアーティファクトを管理するための、より強力で柔軟な環境を提供するよう設計された新機能と強化を導入します。
旧モデルレジストリを表示するには、W&B アプリでモデルレジストリに移動します。ページの上部にバナーが表示され、旧モデルレジストリアプリの UI を使用できます。
組織の公開範囲
旧モデルレジストリにリンクされたアーティファクトはチームレベルの公開範囲を持っています。つまり、チームのメンバーだけが旧 W&B モデルレジストリでアーティファクトを閲覧できます。W&B レジストリは組織レベルの公開範囲を持っています。つまり、適切な権限を持つ組織全体のメンバーがレジストリにリンクされたアーティファクトを閲覧できます。
レジストリへの公開範囲の制限
カスタムレジストリの表示とアクセスを誰ができるかを制限します。カスタムレジストリの作成時または作成後に、レジストリへの公開範囲を制限できます。制限されたレジストリでは、選択したメンバーのみがコンテンツにアクセスでき、プライバシーとコントロールを維持します。レジストリの公開範囲の詳細については、レジストリの公開範囲の種類 を参照してください。
カスタムレジストリの作成
旧モデルレジストリとは異なり、W&B レジストリはモデルやデータセットレジストリに限定されません。特定のワークフローやプロジェクトニーズに合わせたカスタムレジストリを作成し、任意のオブジェクトタイプを保持できるようにします。この柔軟性により、チームは独自の要件に従ってアーティファクトを組織し、管理できるようになります。カスタムレジストリの作成方法について詳しくは、カスタムレジストリの作成 を参照してください。
カスタムアクセス制御
各レジストリは詳細なアクセス制御をサポートし、メンバーには管理者、メンバー、ビューアーなどの特定の役割を割り当てることができます。管理者はレジストリの設定を管理し、メンバーの追加や削除、役割の設定、公開範囲の設定を行います。これにより、チームはレジストリ内のアーティファクトを誰が表示、管理、操作できるかを制御する必要があります。
用語の更新
登録されたモデルは現在、コレクション と呼ばれています。
変更点の概要
旧 W&B モデルレジストリ
W&B レジストリ
アーティファクトの公開範囲
チームのメンバーのみがアーティファクトを閲覧またはアクセス可能
組織内のメンバーが、適切な権限を持ってレジストリにリンクされたアーティファクトを閲覧またはアクセス可能
カスタムアクセス制御
利用不可
利用可能
カスタムレジストリ
利用不可
利用可能
用語の更新
モデルバージョンへのポインタ (リンク) のセットは 登録されたモデル と呼ばれる。
アーティファクトバージョンへのポインタ (リンク) のセットは コレクション と呼ばれる。
wandb.init.link_modelモデルレジストリ固有のAPI
現在は旧モデルレジストリでのみ互換性あり
移行の準備
W&B は登録されたモデル（現在はコレクションと呼ばれる）と関連するアーティファクトバージョンを旧モデルレジストリから W&B レジストリに移行します。このプロセスは自動的に行われ、ユーザーからのアクションは不要です。
チーム公開範囲から組織公開範囲へ
移行後、モデルレジストリは組織レベルの公開範囲を持つようになります。レジストリへのアクセスを制限するには、役割の割り当て を行うことができます。これにより、特定のメンバーのみが特定のレジストリにアクセスできるようにするのに役立ちます。
この移行は、旧 W&B モデルレジストリでの現在のチームレベルの登録モデル（まもなくコレクションと呼ばれる）の既存の許可境界を維持します。旧モデルレジストリで定義された権限は新しいレジストリでも維持されます。つまり、特定のチームメンバーに制限されているコレクションは、移行中および移行後も引き続き保護されます。
アーティファクトのパスの連続性
現在、アクションは不要です。
移行中
W&B が移行プロセスを開始します。移行は W&B サービスへの影響を最小限に抑える時間枠で行われます。移行が開始されると、旧モデルレジストリは読み取り専用の状態に移行し、参照用にアクセス可能なままになります。
移行後
移行後、コレクション、アーティファクトバージョン、および関連する属性は、新しい W&B レジストリ内で完全にアクセス可能になります。現在のワークフローを維持することに重点を置いており、変更に対応するためのサポートも提供されています。
新しいレジストリの使用
ユーザーは W&B レジストリで利用可能な新機能と機能を探索することが奨励されています。レジストリは、現在依存している機能をサポートするだけでなく、カスタムレジストリ、改善された公開範囲、および柔軟なアクセス制御などの強化機能も導入しています。
W&B レジストリを早期に試してみたい方や、旧 W&B モデルレジストリではなくレジストリで始めたい新しいユーザーの方にはサポートが提供されています。サポート@wandb.comまたはセールス MLE に連絡して、この機能を有効にします。なお、早期移行は BETA バージョンへの移行となります。W&B レジストリの BETA バージョンには、旧モデルレジストリのすべての機能または機能が含まれていない場合があります。
詳細と W&B レジストリの完全な機能範囲について学ぶには、W&B レジストリガイド を訪れてください。
FAQ
なぜ W&B はモデルレジストリから W&B レジストリへの資産を移行するのですか？
W&B は、新しいレジストリでより高度な機能と能力を提供するために、そのプラットフォームを進化させています。この移行は、モデル、データセット、およびその他のアーティファクトを管理するための、より統合された強力なツールセットを提供するための一歩です。
移行前に何をすべきですか？
移行前にユーザーからのアクションは必要ありません。W&B が移行を処理し、ワークフローと参照を維持することを保証します。
モデルアーティファクトへのアクセスは失われますか？
いいえ、移行後もモデルアーティファクトへのアクセスは維持されます。旧モデルレジストリは読み取り専用の状態で維持され、すべての関連データは新しいレジストリに移行されます。
アーティファクトに関連するメタデータは維持されますか？
はい、アーティファクトの作成、リネージ、その他の属性に関連する重要なメタデータは移行中に維持されます。ユーザーは、移行後もすべての関連するメタデータにアクセスできるため、アーティファクトの完全性と追跡可能性が維持されます。
助けが必要な場合は誰に連絡すればよいですか？
質問や懸念がある場合のサポートは利用可能です。support@wandb.com に問い合わせてサポートを受けてください。
4.4.12 - モデルレジストリ
モデルレジストリでトレーニングからプロダクションまでのモデルライフサイクルを管理する
W&B は最終的に W&B Model Registry のサポートを停止します。ユーザーは代わりにモデルのアーティファクトバージョンをリンクして共有するために W&B Registry を使用することを推奨されます。W&B Registry は、旧 W&B Model Registry の機能を拡張します。W&B Registry について詳しくは、Registry docs をご覧ください。
W&B は近い将来、旧 Model Registry にリンクされた既存のモデルアーティファクトを新しい W&B Registry へ移行する予定です。移行プロセスに関する情報は、Migrating from legacy Model Registry をご覧ください。
W&B Model Registry は、チームのトレーニングされたモデルを収納し、MLプラクティショナーがプロダクションに向けた候補を公開し、下流のチームや関係者に消費させることができます。これは、ステージング/候補モデルを収容し、ステージングに関連するワークフローを管理するために使用されます。
W&B Model Registry を使用すると、以下が可能です：
仕組み
ステージングされたモデルを数ステップで追跡し、管理します。
モデルバージョンをログする ：トレーニングスクリプトに数行のコードを追加して、モデルファイルをアーティファクトとして W&B に保存します。パフォーマンスを比較する ：ライブチャートをチェックして、トレーニングと検証からのメトリクスやサンプル予測を比較します。どのモデルバージョンが最もよくパフォーマンスしたかを特定します。レジストリにリンクする ：ベストなモデルバージョンを登録済みモデルにリンクしてブックマークします。これは Python でプログラム的に、または W&B UI でインタラクティブに行うことができます。
以下のコードスニペットは、モデルを Model Registry にログし、リンクする方法を示しています：
import wandb
import random
# 新しい W&B run を開始
run = wandb. init(project= "models_quickstart" )
# モデルメトリクスをシミュレーションしてログする
run. log({"acc" : random. random()})
# シミュレートされたモデルファイルを作成
with open("my_model.h5" , "w" ) as f:
f. write("Model: " + str(random. random()))
# モデルを Model Registry にログし、リンクする
run. link_model(path= "./my_model.h5" , registered_model_name= "MNIST" )
run. finish()
モデルの移行を CI/CD ワークフローに接続する ：候補モデルをワークフローステージを通して移行し、下流のアクションをオートメーション化する ことを Webhook を使って行います。
開始方法
ユースケースに応じて、W&B Models を使い始めるための以下のリソースを探ります。
2 部構成のビデオシリーズを確認：
モデルのログと登録 モデルの消費と下流プロセスのオートメーション化 in the Model Registry.
モデルウォークスルー を読み、W&B Python SDK コマンドを使用してデータセットアーティファクトを作成、追跡、および使用する手順を確認します。以下について学ぶ：
Model Registry があなたの ML ワークフローにどのようにフィットし、モデル管理のためにそれを使用することの利点についての この レポートを確認します。
W&B の Enterprise Model Management コースを受講し、以下を学びます：
W&B Model Registry を使って、モデルを管理、バージョン化し、リネージを追跡し、様々なライフサイクルステージを通じてモデルを推進する方法。
Webhook を使ってモデル管理ワークフローをオートメーション化する方法。
モデル評価、監視、デプロイメントのために Model Registry が外部 ML システムやツールとどのように統合されているかを確認する。
4.4.12.1 - Tutorial: W&B を使ったモデル管理
W&B を活用したモデル管理の使い方を学ぶ
W&B にモデルをログする方法を示す次のウォークスルーに従ってください。このウォークスルーの終わりまでに次のことができるようになります：
MNIST データセットと Keras フレームワークを使用してモデルを作成およびトレーニングします。
トレーニングしたモデルを W&B プロジェクトにログします。
作成したモデルの依存関係として使用したデータセットをマークします。
モデルを W&B Registry にリンクします。
レジストリにリンクしたモデルのパフォーマンスを評価します。
モデルバージョンをプロダクション用に準備完了としてマークします。
このガイドで提示された順にコードスニペットをコピーしてください。
モデルレジストリに固有でないコードは折りたたみ可能なセルに隠されています。
セットアップ
始める前に、このウォークスルーに必要な Python の依存関係をインポートします：
import wandb
import numpy as np
from tensorflow import keras
from tensorflow.keras import layers
from wandb.integration.keras import WandbMetricsLogger
from sklearn.model_selection import train_test_split
entity 変数に W&B エンティティを指定します：
データセット アーティファクトを作成する
まず、データセットを作成します。次のコードスニペットは、MNIST データセットをダウンロードする関数を作成します：
def generate_raw_data (train_size= 6000 ):
eval_size = int(train_size / 6 )
(x_train, y_train), (x_eval, y_eval) = keras. datasets. mnist. load_data()
x_train = x_train. astype("float32" ) / 255
x_eval = x_eval. astype("float32" ) / 255
x_train = np. expand_dims(x_train, - 1 )
x_eval = np. expand_dims(x_eval, - 1 )
print("Generated {} rows of training data." . format(train_size))
print("Generated {} rows of eval data." . format(eval_size))
return (x_train[:train_size], y_train[:train_size]), (
x_eval[:eval_size],
y_eval[:eval_size],
)
# データセットを作成
(x_train, y_train), (x_eval, y_eval) = generate_raw_data()
次に、データセットを W&B にアップロードします。これを行うには、artifact オブジェクトを作成し、そのアーティファクトにデータセットを追加します。
project = "model-registry-dev"
model_use_case_id = "mnist"
job_type = "build_dataset"
# W&B run を初期化
run = wandb. init(entity= entity, project= project, job_type= job_type)
# トレーニングデータ用に W&B Table を作成
train_table = wandb. Table(data= [], columns= [])
train_table. add_column("x_train" , x_train)
train_table. add_column("y_train" , y_train)
train_table. add_computed_columns(lambda ndx, row: {"img" : wandb. Image(row["x_train" ])})
# 評価データ用に W&B Table を作成
eval_table = wandb. Table(data= [], columns= [])
eval_table. add_column("x_eval" , x_eval)
eval_table. add_column("y_eval" , y_eval)
eval_table. add_computed_columns(lambda ndx, row: {"img" : wandb. Image(row["x_eval" ])})
# アーティファクトオブジェクトを作成
artifact_name = " {} _dataset" . format(model_use_case_id)
artifact = wandb. Artifact(name= artifact_name, type= "dataset" )
# wandb.WBValue オブジェクトをアーティファクトに追加
artifact. add(train_table, "train_table" )
artifact. add(eval_table, "eval_table" )
# アーティファクトに加えられた変更を永続化
artifact. save()
# W&B にこの run が完了したことを知らせます
run. finish()
アーティファクトにファイル（データセットなど）を保存することは、モデルの依存関係を追跡できるため、モデルをログに記録するという文脈で便利です。
モデルのトレーニング
前のステップで作成したアーティファクトデータセットを使用してモデルをトレーニングします。
データセットアーティファクトを run の入力として宣言
前のステップで作成したデータセットアーティファクトを W&B run の入力として宣言します。これにより、特定のモデルをトレーニングするために使用されたデータセット（およびデータセットのバージョン）を追跡できるため、モデルをログに記録するという文脈で特に便利です。W&B は収集された情報を使用して、lineage map を作成します。
use_artifact API を使用して、データセットアーティファクトを run の入力として宣言し、アーティファクト自体を取得します。
job_type = "train_model"
config = {
"optimizer" : "adam" ,
"batch_size" : 128 ,
"epochs" : 5 ,
"validation_split" : 0.1 ,
}
# W&B run を初期化
run = wandb. init(project= project, job_type= job_type, config= config)
# データセットアーティファクトを取得
version = "latest"
name = " {} : {} " . format(" {} _dataset" . format(model_use_case_id), version)
artifact = run. use_artifact(artifact_or_name= name)
# データフレームから特定のコンテンツを取得
train_table = artifact. get("train_table" )
x_train = train_table. get_column("x_train" , convert_to= "numpy" )
y_train = train_table. get_column("y_train" , convert_to= "numpy" )
モデルの入力と出力を追跡する方法の詳細については、Create model lineage mapを参照してください。
モデルの定義とトレーニング
このウォークスルーでは、Keras を使用して MNIST データセットから画像を分類するための 2D 畳み込みニューラルネットワーク (CNN) を定義します。
MNIST データに対する CNN のトレーニング
# 設定辞書から値を取得して変数に格納（アクセスしやすくするため）
num_classes = 10
input_shape = (28 , 28 , 1 )
loss = "categorical_crossentropy"
optimizer = run. config["optimizer" ]
metrics = ["accuracy" ]
batch_size = run. config["batch_size" ]
epochs = run. config["epochs" ]
validation_split = run. config["validation_split" ]
# モデルアーキテクチャを作成
model = keras. Sequential(
[
layers. Input(shape= input_shape),
layers. Conv2D(32 , kernel_size= (3 , 3 ), activation= "relu" ),
layers. MaxPooling2D(pool_size= (2 , 2 )),
layers. Conv2D(64 , kernel_size= (3 , 3 ), activation= "relu" ),
layers. MaxPooling2D(pool_size= (2 , 2 )),
layers. Flatten(),
layers. Dropout(0.5 ),
layers. Dense(num_classes, activation= "softmax" ),
]
)
model. compile(loss= loss, optimizer= optimizer, metrics= metrics)
# トレーニングデータのラベルを生成
y_train = keras. utils. to_categorical(y_train, num_classes)
# トレーニングセットとテストセットを作成
x_t, x_v, y_t, y_v = train_test_split(x_train, y_train, test_size= 0.33 )
次に、モデルをトレーニングします：
# モデルをトレーニング
model. fit(
x= x_t,
y= y_t,
batch_size= batch_size,
epochs= epochs,
validation_data= (x_v, y_v),
callbacks= [WandbCallback(log_weights= True , log_evaluation= True )],
)
最後に、モデルをローカルマシンに保存します：
# モデルをローカルに保存
path = "model.h5"
model. save(path)
モデルを Model Registry にログし、リンクする
link_modelW&B Model Registry にリンクします。
path = "./model.h5"
registered_model_name = "MNIST-dev"
run. link_model(path= path, registered_model_name= registered_model_name)
run. finish()
指定した名前の registered-model-name がまだ存在しない場合、W&B は登録されたモデルを作成します。
オプションのパラメータに関する詳細は、API リファレンスガイドの link_model
モデルのパフォーマンスを評価する
複数のモデルのパフォーマンスを評価するのは一般的な手法です。
まず、前のステップで W&B に保存された評価データセットアーティファクトを取得します。
job_type = "evaluate_model"
# 初期化
run = wandb. init(project= project, entity= entity, job_type= job_type)
model_use_case_id = "mnist"
version = "latest"
# データセットアーティファクトを取得し、それを依存関係としてマーク
artifact = run. use_artifact(
" {} : {} " . format(" {} _dataset" . format(model_use_case_id), version)
)
# 必要なデータフレームを取得
eval_table = artifact. get("eval_table" )
x_eval = eval_table. get_column("x_eval" , convert_to= "numpy" )
y_eval = eval_table. get_column("y_eval" , convert_to= "numpy" )
評価したい W&B からのモデルバージョン をダウンロードします。use_model API を使用してモデルにアクセスし、ダウンロードします。
alias = "latest" # エイリアス
name = "mnist_model" # モデルアーティファクトの名前
# モデルにアクセスしダウンロードします。ダウンロードされたアーティファクトへのパスを返します
downloaded_model_path = run. use_model(name= f " { name} : { alias} " )
Keras モデルをロードし、損失を計算します：
model = keras. models. load_model(downloaded_model_path)
y_eval = keras. utils. to_categorical(y_eval, 10 )
(loss, _) = model. evaluate(x_eval, y_eval)
score = (loss, _)
最後に、損失のメトリクスを W&B run にログします：
# メトリクス、画像、テーブル、または評価に役立つデータをログします。
run. log(data= {"loss" : (loss, _)})
モデルバージョンを昇格する
モデルエイリアス
例えば、モデルのパフォーマンスを評価した後、そのモデルがプロダクションの準備が整ったと確信したとします。モデルバージョンを昇格させるために、特定のモデルバージョンに production エイリアスを追加します。
production エイリアスは、モデルをプロダクション対応としてマークするために使用される最も一般的なエイリアスの 1 つです。
W&B アプリ UI を使用してインタラクティブに、または Python SDK を使用してプログラムでモデルバージョンにエイリアスを追加できます。次のステップは、W&B Model Registry App を使用してエイリアスを追加する方法を示しています：
https://wandb.ai/registry/model の Model Registry App に移動します。登録されているモデルの名前の横にある View details をクリックします。
Versions セクション内で、プロモーションしたいモデルバージョンの名前の横にある View ボタンをクリックします。Aliases フィールドの隣にあるプラスアイコン (+ ) をクリックします。表示されるフィールドに production と入力します。
キーボードの Enter キーを押します。
4.4.12.2 - モデルレジストリの用語と概念
モデルレジストリの用語と概念
以下の用語は、W&B モデルレジストリの主要な構成要素を説明します: model version model artifact registered model
Model version
モデルバージョンは、単一のモデルチェックポイントを表します。モデルバージョンは、実験内のモデルとそのファイルのある時点でのスナップショットです。
モデルバージョンは、訓練されたモデルを記述するデータとメタデータの不変なディレクトリーです。W&B は、後でモデルのアーキテクチャーと学習されたパラメータを保存（および復元）できるように、ファイルをモデルバージョンに追加することを推奨しています。
モデルバージョンは、1つだけの model artifact に属します。モデルバージョンは、ゼロまたは複数の registered models に属する場合があります。モデルバージョンは、model artifact にログされる順序で格納されます。同じ model artifact にログされたモデルの内容が以前のモデルバージョンと異なる場合、W&B は自動的に新しいモデルバージョンを作成します。
モデリングライブラリによって提供されるシリアライズプロセスから生成されたファイルをモデルバージョン内に保存します（例：PyTorch と Keras ）。
Model alias
モデルエイリアスは、登録されたモデル内でモデルバージョンを一意に識別または参照するための可変文字列です。登録されたモデルのバージョンにだけエイリアスを割り当てることができます。これは、エイリアスがプログラム的に使用されたとき、一意のバージョンを指す必要があるためです。エイリアスは、モデルの状態（チャンピオン、候補、プロダクション）をキャプチャするためにも使用されます。
“best”、“latest”、“production”、“staging” のようなエイリアスを使用して、特定の目的を持つモデルバージョンにマークを付けることは一般的です。
たとえば、モデルを作成し、それに “best” エイリアスを割り当てたとします。その特定のモデルを run.use_model で参照できます。
import wandb
run = wandb. init()
name = f " { entity/ project/ model_artifact_name} : { alias} "
run. use_model(name= name)
モデルタグは、1つ以上の登録されたモデルに属するキーワードまたはラベルです。
モデルタグを使用して、登録されたモデルをカテゴリに整理し、モデルレジストリの検索バーでそれらのカテゴリを検索します。モデルタグは Registered Model Card の上部に表示されます。ML タスク、所有チーム、または優先順位に基づいて登録モデルをグループ化するために使用することもできます。同じモデルタグを複数の登録されたモデルに追加してグループ化を可能にします。
登録されたモデルに適用されるラベルで、グループ化と発見性のために使用されるモデルタグは、
model aliases とは異なります。モデルエイリアスは、一意の識別子またはニックネームで、プログラム的にモデルバージョンを取得するために使用します。モデルレジストリでタスクを整理するためのタグの使用について詳しくは、
Organize models を参照してください。
Model artifact
モデルアーティファクトは、ログされた model versions のコレクションです。モデルバージョンは、model artifact にログされた順序で保存されます。
モデルアーティファクトには1つ以上のモデルバージョンが含まれる場合があります。モデルバージョンがログされていない場合、モデルアーティファクトは空です。
たとえば、モデルアーティファクトを作成するとします。モデルのトレーニング中に、定期的にチェックポイントでモデルを保存します。各チェックポイントはその独自の model version に対応しています。トレーニングスクリプトの開始時に作成した同じモデルアーティファクトに、モデルトレーニング中とチェックポイント保存中に作成されたすべてのモデルバージョンが保存されます。
以下の画像は、3つのモデルバージョン v0、v1、v2 を含むモデルアーティファクトを示しています。
モデルアーティファクトの例はこちら をご覧ください。
Registered model
登録モデルは、モデルバージョンへのポインタ（リンク）のコレクションです。登録モデルを、同じ ML タスク用の候補モデルの「ブックマーク」フォルダーとして考えることができます。登録モデルの各「ブックマーク」は、model artifact に属する model version へのポインタです。model tags を使用して登録モデルをグループ化することができます。
登録モデルは、単一のモデリングユースケースやタスクに対する候補モデルを表すことがよくあります。たとえば、使用するモデルに基づいて異なる画像分類タスクの登録モデルを作成するかもしれません：ImageClassifier-ResNet50、ImageClassifier-VGG16、DogBreedClassifier-MobileNetV2 など。モデルバージョンは、登録モデルにリンクされた順にバージョン番号が割り当てられます。
登録モデルの例はこちら をご覧ください。
4.4.12.3 - モデルを追跡する
W&B Python SDK を使用して、モデル、モデルの依存関係、およびそのモデルに関連するその他の情報を追跡します。
モデル、モデルの依存関係、およびそのモデルに関連するその他の情報を W&B Python SDK を使用して追跡します。
内部的には、W&B は モデルアーティファクト のリネージを作成し、W&B アプリ UI で表示したり、W&B Python SDK を使用してプログラム的に確認することができます。詳細は モデルリネージマップの作成 を参照してください。
モデルをログする方法
run.log_model API を使用してモデルをログします。モデルファイルが保存されているパスを path パラメータに提供してください。このパスはローカルファイル、ディレクトリー、または s3://bucket/path のような外部バケットへのリファレンス URI のいずれかにすることができます。
オプションでモデルアーティファクトの名前を name パラメータに指定できます。name が指定されていない場合、W&B は入力パスのベース名を実行 ID を前に付けたものとして使用します。
以下のコードスニペットをコピーして貼り付けてください。<> で囲まれた値をあなた自身のものに置き換えてください。
import wandb
# W&B run を初期化
run = wandb. init(project= "<project>" , entity= "<entity>" )
# モデルをログする
run. log_model(path= "<path-to-model>" , name= "<name>" )
例: Keras モデルを W&B にログする
以下のコード例は、畳み込みニューラルネットワーク (CNN) モデルを W&B にログする方法を示します。
import os
import wandb
from tensorflow import keras
from tensorflow.keras import layers
config = {"optimizer" : "adam" , "loss" : "categorical_crossentropy" }
# W&B run を初期化
run = wandb. init(entity= "charlie" , project= "mnist-project" , config= config)
# トレーニングアルゴリズム
loss = run. config["loss" ]
optimizer = run. config["optimizer" ]
metrics = ["accuracy" ]
num_classes = 10
input_shape = (28 , 28 , 1 )
model = keras. Sequential(
[
layers. Input(shape= input_shape),
layers. Conv2D(32 , kernel_size= (3 , 3 ), activation= "relu" ),
layers. MaxPooling2D(pool_size= (2 , 2 )),
layers. Conv2D(64 , kernel_size= (3 , 3 ), activation= "relu" ),
layers. MaxPooling2D(pool_size= (2 , 2 )),
layers. Flatten(),
layers. Dropout(0.5 ),
layers. Dense(num_classes, activation= "softmax" ),
]
)
model. compile(loss= loss, optimizer= optimizer, metrics= metrics)
# モデルを保存
model_filename = "model.h5"
local_filepath = "./"
full_path = os. path. join(local_filepath, model_filename)
model. save(filepath= full_path)
# モデルをログする
run. log_model(path= full_path, name= "MNIST" )
# W&B に対して明示的に run の終了を通知します。
run. finish()
4.4.12.4 - 登録済みモデルを作成する
モデル作成のタスクのために、すべての候補モデルを保持する Registered Model を作成します。
registered model を作成し、モデリングタスクのすべての候補モデルを保持します。モデルレジストリ内でインタラクティブに、または Python SDK を使用してプログラム的に registered model を作成できます。
プログラムで registered model を作成する
W&B Python SDK を使用してモデルを登録します。registered model が存在しない場合、W&B は自動的に registered model を作成します。
<> で囲まれた他の値をあなた自身のもので置き換えてください:
import wandb
run = wandb. init(entity= "<entity>" , project= "<project>" )
run. link_model(path= "<path-to-model>" , registered_model_name= "<registered-model-name>" )
run. finish()
registered_model_name に指定した名前は Model Registry App に表示される名前です。
インタラクティブに registered model を作成する
Model Registry App でインタラクティブに registered model を作成します。
Model Registry App に移動します: https://wandb.ai/registry/model 。
Model Registry ページの右上にある New registered model ボタンをクリックします。
表示されたパネルから、registered model が属するエンティティを Owning Entity ドロップダウンから選択します。
Name フィールドにモデルの名前を入力します。Type ドロップダウンから、registered model とリンクするアーティファクトのタイプを選択します。(オプション) Description フィールドにモデルについての説明を追加します。
(オプション) Tags フィールドに1つ以上のタグを追加します。
Register model をクリックします。
モデルをモデルレジストリに手動でリンクすることは、一度だけのモデルに便利です。しかし、プログラムでモデルバージョンをモデルレジストリにリンクする こともよくあります。
例えば、毎晩のジョブがあるとします。毎晩作成されるモデルを手動でリンクするのは面倒です。代わりに、モデルを評価し、そのモデルがパフォーマンスを改善した場合にそのモデルを W&B Python SDK を使用してモデルレジストリにリンクするスクリプトを作成することができます。
4.4.12.5 - モデルバージョンをリンクする
モデル バージョンを登録されたモデルに、W&B アプリまたは Python SDK を使ってプログラム的にリンクします。
モデルのバージョンを W&B App または Python SDK を使用してプログラムで登録済みのモデルにリンクします。
プログラムでモデルをリンクする
link_modelW&B モデルレジストリ にリンクします。
<>で囲まれた値を自分のものに置き換えることを忘れないでください:
import wandb
run = wandb. init(entity= "<entity>" , project= "<project>" )
run. link_model(path= "<path-to-model>" , registered_model_name= "<registered-model-name>" )
run. finish()
指定した registered-model-name パラメータの名前が既に存在しない場合、W&B は登録済みのモデルを自動的に作成します。
例えば、既に “Fine-Tuned-Review-Autocompletion” という名前の登録済みモデル(registered-model-name="Fine-Tuned-Review-Autocompletion")がモデルレジストリにあり、それにいくつかのモデルバージョンがリンクされているとします: v0、v1、v2。新しいモデルをプログラムでリンクし、同じ登録済みモデル名を使用した場合（registered-model-name="Fine-Tuned-Review-Autocompletion"）、W&B はこのモデルを既存の登録済みモデルにリンクし、モデルバージョン v3 を割り当てます。この名前の登録済みモデルが存在しない場合、新しい登録済みモデルが作成され、モデルバージョン v0 を持ちます。
“Fine-Tuned-Review-Autocompletion” 登録済みモデルの一例をここでご覧ください .
インタラクティブにモデルをリンクする
インタラクティブにモデルレジストリまたはアーティファクトブラウザでモデルをリンクします。
Model Registry
Artifact browser
https://wandb.ai/registry/model のモデルレジストリアプリに移動します。新しいモデルをリンクしたい登録済みモデルの名前の横にマウスをホバーします。
View details の横のミートボールメニューアイコン（三つの水平な点）を選択します。ドロップダウンメニューから Link new version を選択します。
Project ドロップダウンからモデルを含むプロジェクトの名前を選択します。Model Artifact ドロップダウンからモデルアーティファクトの名前を選択します。Version ドロップダウンから登録済みモデルにリンクしたいモデルバージョンを選択します。
W&B App でプロジェクトのアーティファクトブラウザに移動します: https://wandb.ai/<entity>/<project>/artifacts
左側のサイドバーで Artifacts アイコンを選択します。
リストにあなたのモデルを表示したいプロジェクトを表示します。
モデルのバージョンをクリックして、モデルレジストリにリンクします。
画面右側に表示されるモーダルから、Select a register model メニュードロップダウンから登録済みモデルを選択します。
Next step をクリックします。（オプション）Aliases ドロップダウンからエイリアスを選択します。
Link to registry をクリックします。
リンクされたモデルのソースを表示する
リンクされたモデルのソースを表示する方法は2つあります: モデルがログされているプロジェクト内のアーティファクトブラウザと W&B モデルレジストリです。
モデルレジストリ内の特定のモデルバージョンを、（そのモデルがログされているプロジェクト内に位置する）ソースモデルアーティファクトと接続するポインタがあります。ソースモデルアーティファクトにもモデルレジストリへのポインタがあります。
Model Registry
Artifact browser
https://wandb.ai/registry/model でモデルレジストリに移動します。
登録済みモデルの名前の横で View details を選択します。
Versions セクション内で調査したいモデルバージョンの横にある View を選択します。右パネル内の Version タブをクリックします。
Version overview セクション内に Source Version フィールドを含む行があります。Source Version フィールドはモデルの名前とそのバージョンを示しています。
例えば、次の画像は v0 モデルバージョンである mnist_model （Source version フィールド mnist_model:v0 を参照）を登録済みモデル MNIST-dev にリンクしていることを示しています。
W&B App でプロジェクトのアーティファクトブラウザに移動します: https://wandb.ai/<entity>/<project>/artifacts
左側のサイドバーで Artifacts アイコンを選択します。
アーティファクトパネルから model ドロップダウンメニューを展開します。
モデルレジストリにリンクされたモデルの名前とバージョンを選択します。
右パネル内の Version タブをクリックします。
Version overview セクション内に Linked To フィールドを含む行があります。Linked To フィールドは、登録済みモデルの名前とそれに属するバージョンを示しています（registered-model-name:version）。
例えば、次の画像では、MNIST-dev という登録済みモデルがあります（Linked To フィールドを参照）。バージョン v0 のモデルバージョン mnist_model（mnist_model:v0）が MNIST-dev 登録済みモデルを指しています。
4.4.12.6 - モデルを整理する
モデルタグを使用して登録済みのモデルをカテゴリーに整理し、それらのカテゴリーを検索します。
https://wandb.ai/registry/model で W&B モデルレジストリアプリに移動します。
モデルタグを追加したい登録済みモデルの名前の横にある View details を選択します。
Model card セクションまでスクロールします。
Tags フィールドの横にあるプラスボタン (+ ) をクリックします。
タグの名前を入力するか、既存のモデルタグを検索します。
例えば、次の画像は FineTuned-Review-Autocompletion という登録済みモデルに複数のモデルタグが追加されている様子を示しています。
4.4.12.7 - モデルリネージ マップを作成する
このページでは、従来の W&B Model Registry でのリネージグラフの作成について説明します。W&B Registry でのリネージグラフについて学ぶには、リネージマップの作成と表示 を参照してください。
モデルアーティファクトを W&B にログする際の便利な機能の一つにリネージグラフがあります。リネージグラフは、run によってログされたアーティファクトと特定の run で使用されたアーティファクトを表示します。
つまり、モデルアーティファクトをログする際には、少なくともモデルアーティファクトを使用または生成した W&B run を表示するためのアクセスが可能です。依存関係を追跡する 場合、モデルアーティファクトで使用された入力も見ることができます。
例えば、以下の画像では、ML 実験全体で作成および使用されたアーティファクトが示されています。
画像は左から右に向かって次のように示しています。
jumping-monkey-1 W&B run によって mnist_dataset:v0 のデータセットアーティファクトが作成されました。vague-morning-5 W&B run は mnist_dataset:v0 データセットアーティファクトを使用してモデルをトレーニングしました。この W&B run の出力は mnist_model:v0 というモデルアーティファクトでした。serene-haze-6 という run は mnist_model:v0 のモデルアーティファクトを使用してモデルを評価しました。
アーティファクトの依存関係を追跡
データセットアーティファクトを W&B run の入力として宣言することで、use_artifact API を使用して依存関係を追跡できます。
以下のコードスニペットでは、use_artifact API の使用方法を示します。
# Run を初期化
run = wandb. init(project= project, entity= entity)
# アーティファクトを取得し、依存関係としてマーク
artifact = run. use_artifact(artifact_or_name= "name" , aliases= "<alias>" )
アーティファクトを取得した後、そのアーティファクトを使用して（例えば）、モデルのパフォーマンスを評価できます。
例: モデルを訓練し、データセットをモデルの入力として追跡
job_type = "train_model"
config = {
"optimizer" : "adam" ,
"batch_size" : 128 ,
"epochs" : 5 ,
"validation_split" : 0.1 ,
}
run = wandb. init(project= project, job_type= job_type, config= config)
version = "latest"
name = " {} : {} " . format(" {} _dataset" . format(model_use_case_id), version)
artifact = run. use_artifact(name)
train_table = artifact. get("train_table" )
x_train = train_table. get_column("x_train" , convert_to= "numpy" )
y_train = train_table. get_column("y_train" , convert_to= "numpy" )
# 設定辞書から変数に値を保存して簡単にアクセス
num_classes = 10
input_shape = (28 , 28 , 1 )
loss = "categorical_crossentropy"
optimizer = run. config["optimizer" ]
metrics = ["accuracy" ]
batch_size = run. config["batch_size" ]
epochs = run. config["epochs" ]
validation_split = run. config["validation_split" ]
# モデルアーキテクチャーの作成
model = keras. Sequential(
[
layers. Input(shape= input_shape),
layers. Conv2D(32 , kernel_size= (3 , 3 ), activation= "relu" ),
layers. MaxPooling2D(pool_size= (2 , 2 )),
layers. Conv2D(64 , kernel_size= (3 , 3 ), activation= "relu" ),
layers. MaxPooling2D(pool_size= (2 , 2 )),
layers. Flatten(),
layers. Dropout(0.5 ),
layers. Dense(num_classes, activation= "softmax" ),
]
)
model. compile(loss= loss, optimizer= optimizer, metrics= metrics)
# トレーニングデータのラベルを生成
y_train = keras. utils. to_categorical(y_train, num_classes)
# トレーニングセットとテストセットの作成
x_t, x_v, y_t, y_v = train_test_split(x_train, y_train, test_size= 0.33 )
# モデルのトレーニング
model. fit(
x= x_t,
y= y_t,
batch_size= batch_size,
epochs= epochs,
validation_data= (x_v, y_v),
callbacks= [WandbCallback(log_weights= True , log_evaluation= True )],
)
# モデルをローカルに保存
path = "model.h5"
model. save(path)
path = "./model.h5"
registered_model_name = "MNIST-dev"
name = "mnist_model"
run. link_model(path= path, registered_model_name= registered_model_name, name= name)
run. finish()
4.4.12.8 - モデルバージョンをダウンロードする
W&B Python SDK で モデル をダウンロードする方法
W&B Python SDK を使用して、Model Registry にリンクしたモデルアーティファクトをダウンロードします。
モデルを再構築し、逆シリアル化して作業可能な形式に変換するための Python 関数や API コールの提供はユーザーの責任です。
W&B はモデルカードを使って、モデルをメモリにロードする方法の情報を文書化することを推奨しています。詳細は、Document machine learning models ページをご覧ください。
<> の中の値を自身のものに置き換えてください：
import wandb
# Run を初期化
run = wandb. init(project= "<project>" , entity= "<entity>" )
# モデルへのアクセスとダウンロード。ダウンロードしたアーティファクトへのパスを返します
downloaded_model_path = run. use_model(name= "<your-model-name>" )
モデルバージョンを以下のいずれかの形式で参照します：
latest - 最も最近リンクされたモデルバージョンを指定するために latest エイリアスを使用します。v# - 特定のバージョンを取得するために v0、v1、v2 などを使用します。alias - モデルバージョンに対してチームが設定したカスタムエイリアスを指定します。
API リファレンスガイドの use_model
例：ログされたモデルをダウンロードして使用する
例えば、以下のコードスニペットでは、ユーザーが use_model API を呼び出しています。彼らは取得したいモデルアーティファクトの名前を指定し、さらにバージョン/エイリアスも提供しています。その後、API から返されたパスを downloaded_model_path 変数に格納しています。
import wandb
entity = "luka"
project = "NLP_Experiments"
alias = "latest" # モデルバージョンのセマンティックニックネームまたは識別子
model_artifact_name = "fine-tuned-model"
# Run を初期化
run = wandb. init()
# モデルへのアクセスとダウンロード。ダウンロードしたアーティファクトへのパスを返します
downloaded_model_path = run. use_model(name= f " { entity/ project/ model_artifact_name} : { alias} " )
2024年のW&B Model Registryの廃止予定について 以下のタブでは、近日廃止予定の Model Registry を使用してモデルアーティファクトを利用する方法を示しています。
W&B Registry を使用して、モデルアーティファクトを追跡、整理、利用します。詳細は Registry docs を参照してください。
<> の中の値を自身のものに置き換えてください：
import wandb
# Run を初期化
run = wandb. init(project= "<project>" , entity= "<entity>" )
# モデルへのアクセスとダウンロード。ダウンロードしたアーティファクトへのパスを返します
downloaded_model_path = run. use_model(name= "<your-model-name>" )
モデルバージョンを以下のいずれかの形式で参照します：
latest - 最も最近リンクされたモデルバージョンを指定するために latest エイリアスを使用します。v# - 特定のバージョンを取得するために v0、v1、v2 などを使用します。alias - モデルバージョンに対してチームが設定したカスタムエイリアスを指定します。
API リファレンスガイドの use_model
https://wandb.ai/registry/model の Model Registry App に移動します。ダウンロードしたいモデルを含む登録済みモデル名の隣にある 詳細を見る を選択します。
バージョンセクション内で、ダウンロードしたいモデルバージョンの隣にある表示ボタンを選択します。
ファイル タブを選択します。ダウンロードしたいモデルファイルの隣にあるダウンロードボタンをクリックします。
4.4.12.9 - 機械学習モデルを文書化する
モデル カードに説明を追加して、モデルをドキュメント化する
モデルレジストリに登録されたモデルのモデルカードに説明を追加して、機械学習モデルの側面を文書化します。文書化する価値があるトピックには以下のものがあります：
Summary : モデルの概要。モデルの目的。モデルが使用する機械学習フレームワークなど。Training data : 使用したトレーニングデータについて、トレーニングデータセットで行ったプロセッシング、そのデータがどこに保存されているかなどを説明します。Architecture : モデルのアーキテクチャー、レイヤー、および特定の設計選択に関する情報。Deserialize the model : チームの誰かがモデルをメモリにロードする方法についての情報を提供します。Task : 機械学習モデルが実行するよう設計された特定のタスクや問題のタイプ。モデルの意図された能力の分類です。License : 機械学習モデルの使用に関連する法的条件と許可。モデルユーザーが法的な枠組みのもとでモデルを利用できることを理解するのに役立ちます。References : 関連する研究論文、データセット、または外部リソースへの引用や参照。Deployment : モデルがどのように、そしてどこにデプロイメントされているのか、他の企業システムにどのように統合されているかに関するガイダンスを含む詳細。
モデルカードに説明を追加する
https://wandb.ai/registry/model で W&B モデルレジストリ アプリに移動します。モデルカードを作成したい登録済みモデル名の横にある View details を選択します。
Model card セクションに移動します。
Description フィールド内に、機械学習モデルに関する情報を入力します。モデルカード内のテキストは Markdown マークアップ言語 でフォーマットします。
例えば、次の画像は Credit-card Default Prediction という登録済みモデルのモデルカードを示しています。
4.4.12.10 - アラートと通知を作成する
新しいモデルバージョンがモデルレジストリにリンクされた時に Slack 通知を受け取る。
新しいモデルバージョンがモデルレジストリにリンクされたときに、Slack 通知を受け取る。
https://wandb.ai/registry/model で W&B Model Registry アプリを開きます。通知を受け取りたい登録済みモデルを選択します。
Connect Slack ボタンをクリックします。
OAuth ページに表示される Slack ワークスペースで W&B を有効にするための指示に従います。
チームのために Slack 通知を設定すると、通知を受け取る登録済みモデルを選択できます。
チームのために Slack 通知を設定した場合、Connect Slack ボタンの代わりに New model version linked to… と書かれたトグルが表示されます。
下のスクリーンショットは Slack 通知が設定された FMNIST 分類器の登録済みモデルを示しています。
新しいモデルバージョンが FMNIST 分類器の登録済みモデルにリンクされるたびに、接続された Slack チャンネルにメッセージが自動的に投稿されます。
4.4.12.11 - データ ガバナンスとアクセス コントロールを管理する
モデルレジストリのロールベース アクセス制御 (RBAC) を使用して、誰が保護されたエイリアスを更新できるかを制御します。
保護されたエイリアス を使用して、モデル開発パイプラインの主要なステージを表現します。モデルレジストリ管理者 のみが保護されたエイリアスを追加、変更、または削除できます。モデルレジストリ管理者は保護されたエイリアスを定義し、使用することができます。W&B は非管理ユーザーがモデルバージョンから保護されたエイリアスを追加または削除することをブロックします。
チーム管理者または現在のレジストリ管理者のみがレジストリ管理者のリストを管理できます。
例えば、staging と production を保護されたエイリアスとして設定したとします。チームのどのメンバーも新しいモデルバージョンを追加できますが、staging または production エイリアスを追加できるのは管理者のみです。
アクセス制御の設定
次の手順で、チームのモデルレジストリに対するアクセス制御を設定します。
W&B モデルレジストリアプリケーションに移動します：https://wandb.ai/registry/model
ページ右上のギアボタンを選択します。
Manage registry admins ボタンを選択します。Members タブ内で、モデルバージョンから保護されたエイリアスを追加および削除するアクセス権を付与したいユーザーを選択します。
保護されたエイリアスの追加
W&B モデルレジストリアプリケーションに移動します：https://wandb.ai/registry/model
ページ右上のギアボタンを選択します。
Protected Aliases セクションまでスクロールダウンします。プラスアイコン (+ ) をクリックして新しいエイリアスを追加します。
4.5 - オートメーション
This feature requires a Pro or Enterprise plan .
このページでは、W&B の オートメーション について説明します。ワークフローステップをトリガーする オートメーションの作成 は、W&B 内のイベント（例えば、アーティファクトバージョンが作成されたとき）に基づいて、自動モデルテストやデプロイメントなどを行います。
例えば、新しいバージョンが作成されたときに Slack のチャンネルに投稿したり、アーティファクトに production エイリアスが追加されたときに自動テストをトリガーするためにウェブフックを実行することができます。
概要
オートメーションは、レジストリやプロジェクトで特定のイベント が発生したときに実行できます。
レジストリ 内のアーティファクトの場合、オートメーションを設定して次の場合に実行することができます：
新しいアーティファクトバージョンがコレクションにリンクされたとき。例えば、新しい候補モデルに対するテストおよび検証ワークフローをトリガーします。
アーティファクトバージョンにエイリアスが追加されたとき。例えば、モデルバージョンにエイリアスが追加されたときにデプロイメントワークフローをトリガーします。
プロジェクト 内のアーティファクトの場合、オートメーションを設定して次の場合に実行することができます：
新しいバージョンがアーティファクトに追加されたとき。例えば、指定されたコレクションにデータセットアーティファクトの新しいバージョンが追加されたときにトレーニングジョブを開始します。
アーティファクトバージョンにエイリアスが追加されたとき。例えば、データセットアーティファクトにエイリアス「redaction」が追加されたときに PII 編集ワークフローをトリガーします。
詳細については、オートメーションイベントとスコープ を参照してください。
オートメーションを作成するには 、以下を行います：
必要に応じて、自動化に必要なアクセス トークン、パスワード、またはセンシティブな設定の詳細などの機密文字列のために、シークレット を設定します。シークレットは Team Settings で定義されます。シークレットは、資格情報やトークンをプレーン テキストで公開することなく、Webhook のペイロードにハードコードすることなく、安全に外部サービスに渡すために Webhook オートメーションで最も一般的に使用されます。
Webhook または Slack 通知を設定して、Slack に投稿したり、ユーザーに代わって Webhook を実行するように W&B を承認します。単一のオートメーションアクション（Webhookまたは Slack 通知）は、複数のオートメーションで使用できます。これらのアクションは、Team Settings で定義されます。
プロジェクトまたはレジストリでオートメーションを作成します：
新しいアーティファクトバージョンが追加されたときなど、監視するイベント を定義します。
イベントが発生したときに取るアクション（Slack チャンネルへの投稿またはウェブフックの実行）を定義します。ウェブフックの場合、必要に応じてペイロードと共に送信するアクセス トークンやシークレットを使用するためのシークレットを指定します。
次のステップ
4.5.1 - 自動化の作成
This feature requires a Pro or Enterprise plan .
このページでは、W&B の オートメーション を作成および管理する概要を示します。詳細な手順については Slack オートメーションを作成する または Webhook オートメーションを作成する を参照してください。
オートメーションに関するチュートリアルをお探しですか？
要件
チーム管理者は、チームの Projects やオートメーションのコンポーネント（Webhook、秘密情報、Slack 接続など）のオートメーションを作成および管理できます。チーム設定 を参照してください。
レジストリオートメーションを作成するには、レジストリへのアクセスが必要です。レジストリアクセスの設定 を参照してください。
Slack オートメーションを作成するには、選択した Slack インスタンスとチャンネルに投稿する権限が必要です。
オートメーションを作成する
プロジェクトまたはレジストリの Automations タブからオートメーションを作成します。オートメーションを作成するには、以下のステップに従います：
必要に応じて、オートメーションに必要な各機密文字列（アクセストークン、パスワード、SSH キーなど）のために W&B の秘密情報を作成する 。秘密情報は Team Settings で定義されます。秘密情報は主に Webhook オートメーションで使用されます。
Webhook または Slack 通知を設定して、W&B が Slack に投稿するか、代わりに Webhook を実行できるようにします。単一のオートメーションアクション（Webhook または Slack 通知）は、複数のオートメーションによって使用できます。これらのアクションは Team Settings で定義されます。
プロジェクトまたはレジストリで、監視するイベントと実行するアクション（Slack への投稿や Webhook の実行など）を指定するオートメーションを作成します。Webhook オートメーションを作成するときは、送信するペイロードを設定します。
詳細については、以下を参照してください：
オートメーションを表示および管理する
プロジェクトまたはレジストリの Automations タブからオートメーションを表示および管理します。
オートメーションの詳細を表示するには、その名前をクリックします。
オートメーションを編集するには、そのアクションの … メニューをクリックし、Edit automation をクリックします。
オートメーションを削除するには、そのアクションの … メニューをクリックし、Delete automation をクリックします。
次のステップ
4.5.1.1 - Slack 自動化の作成
This feature requires a Pro or Enterprise plan .
このページでは、Slack オートメーション を作成する方法を示します。ウェブフックオートメーションを作成するには、ウェブフックオートメーションの作成 を参照してください。
高レベルでは、Slackオートメーションを作成するには、以下の手順を行います:
Slackインテグレーションを追加 し、W&BがSlackインスタンスとチャンネルに投稿できるように認証します。Slackオートメーションを作成 し、監視するイベント と投稿するチャンネルを定義します。
Slackに接続
チーム管理者は、チームにSlack宛先を追加できます。
W&Bにログインし、チーム設定ページに移動します。
Slackチャンネルインテグレーション セクションで、Slackを接続 をクリックして新しいSlackインスタンスを追加します。既存のSlackインスタンスにチャンネルを追加するには、新しいインテグレーション をクリックします。
必要に応じて、ブラウザでSlackにサインインします。プロンプトが表示されたら、選択したSlackチャンネルにW&Bからの投稿を許可してください。ページを読み、チャンネルを検索 をクリックしてチャンネル名を入力し始めます。リストからチャンネルを選択し、許可 をクリックします。
Slackで、選択したチャンネルに移動します。[あなたのSlackハンドル]がこのチャンネルにインテグレーションを追加しました: Weights & Biasesという投稿が表示されれば、インテグレーションが正しく設定されています。
これで、設定したSlackチャンネルに通知するオートメーションを作成 できます。
Slack接続の表示と管理
チーム管理者は、チームのSlackインスタンスとチャンネルを表示および管理できます。
W&Bにログインし、チーム設定 に移動します。
Slackチャンネルインテグレーション セクションで各Slack宛先を表示します。宛先を削除するには、そのゴミ箱アイコンをクリックします。
オートメーションを作成する
W&BチームをSlackに接続した後 、Registry またはProject を選択し、Slackチャンネルに通知するオートメーションを作成する手順に従います。
Registry管理者は、そのregistry内でオートメーションを作成できます。
W&Bにログインします。
registryの名前をクリックして詳細を表示します。
registryに関連付けられたオートメーションを作成するには、Automations タブをクリックし、Create automation をクリックします。registryに関連付けられたオートメーションは、自動的にそのすべてのコレクションに適用されます（将来作成されるものも含む）。
registry内の特定のコレクションにのみ関連付けられたオートメーションを作成するには、コレクションのアクション...メニューをクリックし、Create automation をクリックします。あるいは、コレクションを閲覧しているときに、Automations セクションの詳細ページでCreate automation ボタンを使用して、そのためのオートメーションを作成します。
監視するEvent
イベントに応じた追加のフィールドが表示されるので、それを入力します。たとえば、An artifact alias is added を選択した場合は、Alias regex を指定する必要があります。
Next step をクリックします。
Slackインテグレーション を所有するチームを選択します。
Action type をSlack notification に設定します。Slackチャンネルを選択し、Next step をクリックします。
オートメーションの名前を提供します。必要に応じて、説明を追加します。
Create automation をクリックします。
W&B管理者は、プロジェクト内でオートメーションを作成できます。
W&Bにログインします。
プロジェクトページに移動し、Automations タブをクリックします。
Create automation をクリックします。
監視するEvent
イベントに応じた追加のフィールドが表示されるので、それを入力します。たとえば、An artifact alias is added を選択した場合は、Alias regex を指定する必要があります。
Next step をクリックします。
Slackインテグレーション を所有するチームを選択します。
Action type をSlack notification に設定します。Slackチャンネルを選択し、Next step をクリックします。
オートメーションの名前を提供します。必要に応じて、説明を追加します。
Create automation をクリックします。
オートメーションの表示と管理
registryのAutomations タブから対象のオートメーションを管理します。
コレクションの詳細ページのAutomations セクションからコレクションのオートメーションを管理します。
これらのページのいずれからも、Registry管理者は既存のオートメーションを管理できます:
オートメーションの詳細を表示するには、その名前をクリックします。
オートメーションを編集するには、そのアクション...メニューをクリックし、Edit automation をクリックします。
オートメーションを削除するには、そのアクション...メニューをクリックし、Delete automation をクリックします。確認が必要です。
W&B管理者は、プロジェクトのAutomations タブからプロジェクトのオートメーションを表示および管理できます。
オートメーションの詳細を表示するには、その名前をクリックします。
オートメーションを編集するには、そのアクション...メニューをクリックし、Edit automation をクリックします。
オートメーションを削除するには、そのアクション...メニューをクリックし、Delete automation をクリックします。確認が必要です。
4.5.1.2 - Webhook オートメーションを作成する
This feature requires a Pro or Enterprise plan .
このページでは、webhook のオートメーションを作成する方法を示します。Slack オートメーションを作成するには、代わりに Slack オートメーションの作成 を参照してください。
webhook オートメーションを作成するための大まかな手順は以下の通りです。
必要に応じて、オートメーションに必要なアクストークン、パスワード、またはSSHキーなどを含む機密文字列ごとにW&B シークレットを作成 します。シークレットはチーム設定で定義されます。
webhook を作成 し、エンドポイントと承認の詳細を定義し、必要なシークレットにアクセスするためのインテグレーションのアクセス権を付与します。オートメーションを作成 し、監視するevent と W&B が送信するペイロードを定義します。ペイロードのために必要なシークレットに対して、オートメーションにアクセスを許可します。
webhook の作成
チーム管理者は、チームに webhook を追加できます。
webhook が Bearer トークンを必要とする場合、またはペイロードが機密文字列を必要とする場合は、webhook を作成する前にそれを含む
シークレットを作成 してください。webhook には最大で1つのアクストークンと1つの他のシークレットを設定することができます。webhook の認証と承認の要件は、webhook のサービスによって決まります。
W&B にログインし、チーム設定ページに移動します。
Webhooks セクションで、New webhook をクリックします。
webhook に名前を提供します。
webhook のエンドポイント URL を提供します。
webhook が Bearer トークンを必要とする場合、Access token をそれを含む secret に設定します。webhook オートメーションを使用する際、W&B は Authorization: Bearer HTTP ヘッダーをアクストークンに設定し、${ACCESS_TOKEN} payload variable でトークンにアクセスできます。
webhook のペイロードにパスワードまたは他の機密文字列が必要な場合、Secret をその文字列を含むシークレットに設定します。webhook を使用するオートメーションを設定するとき、シークレットの名前に $ を付けて payload variable としてシークレットにアクセスできます。
webhook のアクセストークンがシークレットに保存されている場合は、アクセストークンとしてシークレットを指定するために次のステップを 必ず 完了してください。
W&B がエンドポイントに接続し、認証できることを確認するには：
オプションで、テスト用のペイロードを提供します。ペイロード内で webhook がアクセス可能なシークレットを参照するには、その名前に $ を付けます。このペイロードはテスト用であり保存されません。オートメーションのペイロードは create the automation で設定します。シークレットとアクセストークンが POST リクエストで指定されている場所を表示するには、Troubleshoot your webhook を参照してください。
Test をクリックします。W&B は、設定された認証情報を使用して webhook のエンドポイントに接続しようとします。ペイロードを提供した場合は、W&B がそれを送信します。
テストが成功しない場合は、webhook の設定を確認して再試行してください。必要に応じて、Troubleshoot your webhook を参照してください。
これで webhook を使用する オートメーションを作成する ことができます。
オートメーションの作成
webhook を設定 した後、Registry または Project を選択し、webhook をトリガーするオートメーションを作成するための手順に従います。
レジストリ管理者は、そのレジストリ内でオートメーションを作成できます。レジストリのオートメーションは、将来追加されるものを含めて、そのレジストリ内のすべてのコレクションに適用されます。
W&B にログインします。
詳細を確認するためにレジストリの名前をクリックします。
レジストリにスコープされているオートメーションを作成するには、Automations タブをクリックし、Create automation をクリックします。レジストリにスコープされているオートメーションは、そのすべてのコレクション（将来作成されるものを含む）に自動的に適用されます。
レジストリ内の特定のコレクションのみにスコープされたオートメーションを作成するには、コレクションのアクション ... メニューをクリックし、Create automation をクリックします。または、コレクションを表示しながら、コレクションの詳細ページの Automations セクションにある Create automation ボタンを使用してそれに対するオートメーションを作成します。
監視する Event An artifact alias is added を選択した場合、Alias regex を指定する必要があります。Next step をクリックします。
webhook を所有するチームを選択します。
Action type を Webhooks に設定し、使用する webhook を選択します。
webhook にアクセストークンを設定している場合、${ACCESS_TOKEN} payload variable でトークンにアクセスできます。webhook にシークレットを設定している場合、シークレットの名前に $ を付けてペイロード内でアクセスできます。webhook の要件は webhook のサービスによって決まります。
Next step をクリックします。
オートメーションに名前を付けます。オプションで説明を入力します。Create automation をクリックします。
W&B 管理者はプロジェクト内でオートメーションを作成できます。
W&B にログインし、プロジェクトページに移動します。
サイドバーの Automations をクリックします。
Create automation をクリックします。
監視する Event
表示される、追加フィールドを入力します。例えば、An artifact alias is added を選択した場合、Alias regex を指定する必要があります。
オプションでコレクションフィルタを指定します。それ以外の場合、オートメーションはプロジェクト内のすべてのコレクションに適用され、将来追加されるものも含まれます。
Next step をクリックします。
webhook を所有するチームを選択します。
Action type を Webhooks に設定し、使用する webhook を選択します。
webhook がペイロードを必要とする場合、それを構築し、Payload フィールドに貼り付けます。webhook にアクセストークンを設定している場合、${ACCESS_TOKEN} payload variable でトークンにアクセスできます。webhook にシークレットを設定している場合、シークレットの名前に $ を付けてペイロード内でアクセスできます。webhook の要件は webhook のサービスによって決まります。
Next step をクリックします。
オートメーションに名前を付けます。オプションで説明を入力します。Create automation をクリックします。
オートメーションの表示と管理
レジストリのオートメーションは、レジストリの Automations タブから管理します。
コレクションのオートメーションは、コレクションの詳細ページの Automations セクションから管理します。
これらのページのいずれかから、レジストリ管理者は既存のオートメーションを管理できます。
オートメーションの詳細を表示するには、その名前をクリックします。
オートメーションを編集するには、そのアクションの ... メニューをクリックし、Edit automation をクリックします。
オートメーションを削除するには、そのアクションの ... メニューをクリックし、Delete automation をクリックします。確認が必要です。
W&B 管理者はプロジェクトの Automations タブからプロジェクトのオートメーションを表示および管理できます。
オートメーションの詳細を表示するには、その名前をクリックします。
オートメーションを編集するには、そのアクションの ... メニューをクリックし、Edit automation をクリックします。
オートメーションを削除するには、そのアクションの ... メニューをクリックし、Delete automation をクリックします。確認が必要です。
ペイロードのリファレンス
以下のセクションを使用して、webhook のペイロードを構築します。webhook とそのペイロードのテストについての詳細は、Troubleshoot your webhook を参照してください。
ペイロード変数
このセクションでは、webhook のペイロードを構築するために使用できる変数について説明します。
Variable
Details
${project_name}アクションをトリガーした変更を所有するプロジェクトの名前。
${entity_name}アクションをトリガーした変更を所有する entity またはチームの名前。
${event_type}アクションをトリガーしたイベントのタイプ。
${event_author}アクションをトリガーしたユーザー。
${artifact_collection_name}アーティファクトバージョンがリンクされているアーティファクトコレクションの名前。
${artifact_metadata.<KEY>}アクションをトリガーしたアーティファクトバージョンのトップレベルのメタデータキーの任意の値。<KEY> をトップレベルのメタデータキーの名前に置き換えます。webhook のペイロードにはトップレベルのメタデータキーのみが利用可能です。
${artifact_version}アクションをトリガーしたアーティファクトバージョンの Wandb.Artifact
${artifact_version_string}アクションをトリガーしたアーティファクトバージョンのstring 表現。
${ACCESS_TOKEN}アクストークンが設定されている場合、webhook で設定されたアクセストークンの値。アクセストークンは自動的に Authorization: Bearer HTTP ヘッダーに渡されます。
${SECRET_NAME}設定されている場合、webhook に設定されたシークレットの値。SECRET_NAME をシークレットの名前に置き換えます。
ペイロードの例
このセクションでは、一般的なユースケースのための webhook ペイロードの例を示します。例は payload variables をどのように使用するかを示します。
GitHub repository dispatch
Microsoft Teams notification
Slack notifications
W&B からリポジトリディスパッチを送信して GitHub アクションをトリガーします。例えば、リポジトリディスパッチを on キーのトリガーとして受け入れる GitHub ワークフローファイルを持っているとしましょう。
on :
repository_dispatch :
types : BUILD_AND_DEPLOY
リポジトリ用のペイロードは次のようなものになるかもしれません。
{
"event_type" : "BUILD_AND_DEPLOY" ,
"client_payload" :
{
"event_author" : "${event_author}" ,
"artifact_version" : "${artifact_version}" ,
"artifact_version_string" : "${artifact_version_string}" ,
"artifact_collection_name" : "${artifact_collection_name}" ,
"project_name" : "${project_name}" ,
"entity_name" : "${entity_name}"
}
}
webhook ペイロードの event_type キーは GitHub ワークフローファイルの types フィールドと一致しなければなりません。
レンダリングされたテンプレート文字列の内容と位置は、オートメーションが設定されているイベントまたはモデルバージョンによって異なります。${event_type} は LINK_ARTIFACT または ADD_ARTIFACT_ALIAS としてレンダリングされます。以下に例のマッピングを示します。
${event_type} --> "LINK_ARTIFACT" または "ADD_ARTIFACT_ALIAS"
${event_author} --> "<wandb-user>"
${artifact_version} --> "wandb-artifact://_id/QXJ0aWZhY3Q6NTE3ODg5ODg3""
${artifact_version_string} --> "<entity>/model-registry/<registered_model_name>:<alias>"
${artifact_collection_name} --> "<registered_model_name>"
${project_name} --> "model-registry"
${entity_name} --> "<entity>"
テンプレート文字列を使用して W&B から GitHub Actions や他のツールにコンテキストを動的に渡します。これらのツールが Python スクリプトを呼び出すことができる場合、それらは W&B API を通じて登録されたモデルアーティファクトを使用することができます。
この例のペイロードは、webhook を使用して Teams チャンネルに通知する方法を示しています。
{
"@type" : "MessageCard" ,
"@context" : "http://schema.org/extensions" ,
"summary" : "New Notification" ,
"sections" : [
{
"activityTitle" : "Notification from WANDB" ,
"text" : "This is an example message sent via Teams webhook." ,
"facts" : [
{
"name" : "Author" ,
"value" : "${event_author}"
},
{
"name" : "Event Type" ,
"value" : "${event_type}"
}
],
"markdown" : true
}
]
}
実行時に W&B データをペイロードに挿入するためにテンプレート文字列を使用できます（上記の Teams の例に示したように）。
このセクションは歴史的な目的で提供されます。現在、webhook を使用して Slack と統合している場合は、[新しい Slack インテグレーション]({{ relref “#create-a-slack-automation”}}) を使用するように設定を更新することをお勧めします。
Slack アプリをセットアップし、Slack API ドキュメント で強調されている指示に従って、着信 webhook インテグレーションを追加します。Bot User OAuth Token の下で指定されているシークレットが W&B webhook のアクストークンであることを確認してください。
以下はペイロードの例です。
{
"text" : "New alert from WANDB!" ,
"blocks" : [
{
"type" : "section" ,
"text" : {
"type" : "mrkdwn" ,
"text" : "Registry event: ${event_type}"
}
},
{
"type" :"section" ,
"text" : {
"type" : "mrkdwn" ,
"text" : "New version: ${artifact_version_string}"
}
},
{
"type" : "divider"
},
{
"type" : "section" ,
"text" : {
"type" : "mrkdwn" ,
"text" : "Author: ${event_author}"
}
}
]
}
webhook のトラブルシューティング
W&B アプリ UI または Bash スクリプトを使用して、インタラクティブに webhook のトラブルシューティングを行います。新しい webhook を作成する際や既存の webhook を編集する際に webhook をトラブルシューティングできます。
チーム管理者は W&B アプリ UI を使用して webhook をインタラクティブにテストできます。
W&B チーム設定ページに移動します。
Webhooks セクションまでスクロールします。webhook の名前の横にある三点リーダー（ミートボールアイコン）をクリックします。
Test を選択します。現れた UI パネルから、表示されるフィールドに POST リクエストを貼り付けます。
Test webhook をクリックします。W&B アプリ UI 内で、W&B はエンドポイントからの応答を投稿します。
Testing Webhooks in Weights & Biases のビデオを見て、デモをご覧ください。
このシェルスクリプトは、W&B が webhook オートメーションに送信する POST リクエストを生成する1つの方法を示しています。
以下のコードをシェルスクリプトにコピーし、webhook のトラブルシューティングを行います。以下の値を指定してください。
ACCESS_TOKENSECRETPAYLOADAPI_ENDPOINT
webhook_test.sh
4.5.2 - 自動化イベントと範囲
This feature requires a Pro or Enterprise plan .
あるオートメーションは、プロジェクトやレジストリのスコープ内で特定のイベントが発生したときに開始されます。プロジェクトのスコープ は[スコープの技術的定義を挿入]を参照してください。このページでは、それぞれのスコープ内でオートメーションをトリガーするイベントについて説明します。
オートメーションの詳細は、オートメーション概要 またはオートメーションの作成 を参照してください。
レジストリ
このセクションでは、レジストリ でのオートメーションのスコープとイベントについて説明します。
レジストリアプリをhttps://wandb.ai/registry/で開きます。
レジストリの名前をクリックし、オートメーション タブでオートメーションを表示および作成します。
オートメーションの作成 の詳細をご覧ください。
スコープ
レジストリにおけるオートメーションは、これらのスコープで作成できます：
レジストリ レベル：オートメーションは、特定のレジストリ内のすべてのコレクション（将来追加されるコレクションを含む）で発生するイベントを監視します。コレクションレベル：特定のレジストリ内の単一のコレクション。
イベント
レジストリオートメーションは、これらのイベントを監視できます：
新しいアーティファクトをコレクションにリンク : 新しいモデルやデータセットがレジストリに追加されたときにテストと検証。アーティファクトのバージョンに新しいエイリアスを追加 : 新しいアーティファクトバージョンに特定のエイリアスが適用されたときに、ワークフローの特定のステップをトリガーします。たとえば、productionエイリアスが適用されたときにモデルをデプロイする。
プロジェクト
このセクションでは、プロジェクト でのオートメーションのスコープとイベントについて説明します。
W&Bアプリの https://wandb.ai/<team>/<project-name> にあるW&Bプロジェクトに移動します。
オートメーション タブでオートメーションを表示および作成します。
オートメーションの作成 の詳細をご覧ください。
スコープ
プロジェクト内でオートメーションを作成できるスコープ：
プロジェクトレベル：オートメーションは、プロジェクト内の任意のコレクションで発生するイベントを監視します。
コレクションレベル：指定したフィルタに一致するプロジェクト内のすべてのコレクション。
イベント
プロジェクト内でオートメーションは、これらのイベントを監視できます：
コレクションでアーティファクトの新しいバージョンが作成される : アーティファクトの各バージョンに繰り返しの処理を適用します。コレクションの指定はオプションです。たとえば、新しいデータセットアーティファクトバージョンが作成されたときにトレーニングジョブを開始します。アーティファクトエイリアスが追加される : プロジェクトやコレクション内の新しいアーティファクトバージョンに特定のエイリアスが適用されたときに、ワークフローの特定のステップをトリガーします。例えば、アーティファクトに test-set-quality-check エイリアスが適用されたときに一連の後処理ステップを実行します。
次のステップ
5 - W&B プラットフォーム
W&B Platformは、W&Bの製品であるCore 、Models 、およびWeave をサポートするための基本となるインフラストラクチャー、ツール、およびガバナンスの枠組みです。
W&B Platformは、以下の3つの異なるデプロイメントオプションで利用可能です:
以下の責任分担表は、いくつかの主な違いを示しています:
Multi-tenant Cloud
Dedicated Cloud
Customer-managed
MySQL / DB management
完全にW&Bがホストおよび管理
完全にW&Bが顧客が選択したクラウドまたはリージョンでホストおよび管理
完全に顧客がホストおよび管理
Object Storage (S3/GCS/Blob storage)
オプション 1 : W&Bが完全にホストオプション 2 : Secure Storage Connector を使用して、顧客がチームごとに独自のバケットを設定可能オプション 1 : W&Bが完全にホストオプション 2 : Secure Storage Connector を使用して、顧客がインスタンスまたはチームごとに独自のバケットを設定可能完全に顧客がホストおよび管理
SSO Support
Auth0を通じてW&Bが管理
オプション 1 : 顧客が管理オプション 2 : Auth0を通じてW&Bが管理完全に顧客が管理
W&B Service (App)
W&Bが完全に管理
W&Bが完全に管理
完全に顧客が管理
App security
W&Bが完全に管理
W&Bと顧客の共同責任
完全に顧客が管理
Maintenance (upgrades, backups, etc.)
W&Bが管理
W&Bが管理
顧客が管理
Support
サポートSLA
サポートSLA
サポートSLA
Supported cloud infrastructure
GCP
AWS, GCP, Azure
AWS, GCP, Azure, オンプレミスベアメタル
デプロイメントオプション
以下のセクションでは、各デプロイメントタイプの概要を示します。
W&B Multi-tenant Cloud
W&B Multi-tenant Cloudは、W&Bのクラウドインフラストラクチャーにデプロイされた完全管理型サービスで、希望の規模でW&Bの製品にシームレスにアクセスでき、価格設定のための費用対効果の高いオプションや、最新の機能と機能性のための継続的なアップデートを提供します。W&Bは、Multi-tenant Cloudを製品トライアルに使用することを推奨しています。また、プライベートデプロイメントのセキュリティが不要で、自己サービスのオンボーディングが重要であり、コスト効率が重要である場合には、プロダクションAIワークフローを管理するのに適しています。
詳細は、W&B Multi-tenant Cloud をご覧ください。
W&B Dedicated Cloud
W&B Dedicated Cloudは、W&Bのクラウドインフラストラクチャーにデプロイされるシングルテナントの完全管理型サービスです。データレジデンシーを含む厳格なガバナンス管理に準拠する必要があり、高度なセキュリティ機能を求め、セキュリティ、スケール、性能特性を備えた必要なインフラストラクチャーを構築・管理することなくAI運用コストを最適化しようとしている場合、W&Bを導入する最適な場所です。
詳細は、W&B Dedicated Cloud をご覧ください。
W&B Customer-Managed
このオプションでは、独自に管理するインフラストラクチャーにW&B Serverをデプロイし、管理することができます。W&B Serverは、W&B Platformとそのサポート製品を実行するための自己完結型パッケージメカニズムです。W&Bは、既存のすべてのインフラストラクチャーがオンプレミスである場合、またはW&B Dedicated Cloudでは満たされない厳格な規制ニーズがある場合、このオプションを推奨します。このオプションでは、W&B Serverをサポートするために必要なインフラストラクチャーのプロビジョニング、および継続的なメンテナンスとアップグレードを管理する完全な責任を負います。
詳細は、W&B Self Managed をご覧ください。
次のステップ
W&Bの製品を試したい場合、W&BはMulti-tenant Cloud の使用を推奨します。企業向けのセットアップを探している場合は、こちら からトライアルに適したデプロイメントタイプを選択してください。
5.1 - デプロイメントオプション
5.1.1 - W&B マルチテナント SaaS を使用する
W&B マルチテナントクラウドは、W&B の Google Cloud Platform (GCP) アカウントに展開されている完全管理型のプラットフォームで、GPC の北米リージョン で利用可能です。W&B マルチテナントクラウドは、GCP の自動スケーリングを利用しており、トラフィックの増減に応じて適切にプラットフォームがスケールします。
データのセキュリティ
非エンタープライズプランのユーザーの場合、すべてのデータは共有クラウドストレージにのみ保存され、共有クラウドコンピューティングサービスで処理されます。料金プランによっては、保存容量制限が適用される場合があります。
エンタープライズプランのユーザーは、セキュアストレージコネクタを使用して独自のバケット（BYOB）をチームレベルで使用する ことができ、モデルやデータセットなどのファイルを保存できます。複数のチームに対して単一のバケットを設定することも、W&B Teams の異なるために個別のバケットを使用することも可能です。チームにセキュアストレージコネクタを設定しない場合、データは共有クラウドストレージに保存されます。
アイデンティティとアクセス管理 (IAM)
エンタープライズプランの場合、W&B Organization における安全な認証と効果的な権限付与のためのアイデンティティとアクセス管理機能を使用できます。マルチテナントクラウドで利用可能な IAM の機能は以下の通りです：
OIDC または SAML を使用した SSO 認証。組織で SSO を設定したい場合は、W&B チームまたはサポートにお問い合わせください。
組織の範囲およびチーム内で適切なユーザーロールを設定 します。
プロジェクトを制限されたプロジェクトとして定義し、誰がそのプロジェクトを見る、編集する、または W&B Runs を送信できるかを制限します。制限付きプロジェクト を参照。
モニター
組織の管理者は、アカウントビューの Billing タブから使用状況と請求を管理できます。マルチテナントクラウドで共有クラウドストレージを使用している場合、管理者は組織内の異なるチーム間でストレージの使用を最適化することができます。
メンテナンス
W&B マルチテナントクラウドはマルチテナントの完全管理型プラットフォームです。W&B によって管理されているため、W&B プラットフォームのプロビジョニングや維持にかかるオーバーヘッドやコストは発生しません。
コンプライアンス
マルチテナントクラウドのセキュリティ管理は、定期的に内部および外部の監査を受けています。W&B セキュリティポータル を参照して、SOC2 レポートやその他のセキュリティおよびコンプライアンスに関する文書をリクエストしてください。
次のステップ
非エンタープライズ機能を探している場合は、マルチテナントクラウドに直接アクセス してください。エンタープライズプランを開始するには、このフォーム を提出してください。
5.1.2 - 自己管理
W&B をプロダクション環境に展開する
セルフ管理クラウドまたはオンプレインフラストラクチャーを使用
あなたの AWS, GCP, または Azure クラウドアカウント または オンプレミスのインフラストラクチャー に W&B Server をデプロイしてください。
あなたの IT/DevOps/MLOps チームが、デプロイメントのプロビジョニング、アップグレードの管理、セルフマネージド W&B Server インスタンスの継続的な保守を担当します。
セルフ管理クラウドアカウントに W&B Server をデプロイする
W&B は、公式の W&B Terraform スクリプトを使用して、AWS、GCP、または Azure のクラウドアカウントに W&B Server をデプロイすることを推奨します。
AWS 、GCP または Azure に W&B Server を設定する方法については、各クラウドプロバイダーのドキュメントを参照してください。
オンプレインフラストラクチャーに W&B Server をデプロイする
W&B Server をオンプレインフラストラクチャーに設定するには、いくつかのインフラストラクチャーコンポーネントを設定する必要があります。これらのコンポーネントには、以下が含まれますが、それに限定されません：
(強く推奨) Kubernetes クラスター
MySQL 8 データベースクラスター
Amazon S3 互換オブジェクトストレージ
Redis キャッシュクラスター
オンプレインフラストラクチャーに W&B Server をインストールする方法については、Install on on-prem infrastructure を参照してください。W&B はさまざまなコンポーネントに関する推奨事項を提供し、インストールプロセスをガイドします。
カスタムクラウドプラットフォームに W&B Server をデプロイする
AWS、GCP、または Azure ではないクラウドプラットフォームに W&B Server をデプロイすることができます。これには、オンプレインフラストラクチャー にデプロイする場合と同様の要件があります。
W&B Server ライセンスの取得
W&B server の設定を完了するには、W&B のトライアルライセンスが必要です。 Deploy Manager を開いて、無料のトライアルライセンスを生成してください。
まだ W&B アカウントをお持ちでない場合は、無料ライセンスを生成するためにアカウントを作成してください。
重要なセキュリティ & 企業向け機能のサポートを含む、W&B Server のエンタープライズライセンスが必要な場合は、このフォームを送信 するか、W&B チームに連絡してください。
URL は Get a License for W&B Local フォームにリダイレクトします。次の情報を提供してください:
Choose Platform ステップでデプロイタイプを選択します。Basic Information ステップでライセンスの所有者を選択するか、新しい組織を追加します。Get a License ステップでインスタンスの名前を入力し、任意で Description フィールドに説明を提供します。Generate License Key ボタンを選択します。
インスタンスに関連付けられたライセンスとともにデプロイメントの概要を示すページが表示されます。
5.1.2.1 - リファレンス アーキテクチャー
W&B リファレンス アーキテクチャー
このページでは、Weights & Biasesデプロイメントのためのリファレンスアーキテクチャについて説明し、プラットフォームのプロダクションデプロイメントをサポートするための推奨インフラストラクチャとリソースを示します。
Weights & Biases（W&B）のデプロイメント環境に応じて、デプロイメントのレジリエンスを高めるためのさまざまなサービスが利用できます。
たとえば、主要なクラウドプロバイダは、データベースの設定、保守、高可用性、レジリエンスの複雑さを軽減する堅牢な管理データベースサービスを提供しています。
このリファレンスアーキテクチャは、一般的なデプロイメントシナリオに対応し、クラウドベンダーのサービスとW&Bデプロイメントを統合する方法を示します。
始める前に
プロダクション環境でアプリケーションを実行するには、それぞれの課題が伴い、W&Bも例外ではありません。プロセスを簡素化しようとしていますが、個別のアーキテクチャや設計の決定に応じて、ある程度の複雑さが発生する場合があります。通常、プロダクションデプロイメントの管理には、ハードウェア、オペレーティングシステム、ネットワーキング、ストレージ、セキュリティ、W&Bプラットフォーム自体、およびその他の依存関係を含むさまざまなコンポーネントの監督が含まれます。この責任は、環境の初期セットアップとその継続的な保守の両方に及びます。
W&Bを自社で管理するアプローチが、あなたのチームが抱える特定の要件に適しているかどうかを慎重に検討してください。
プロダクションレベルのアプリケーションを実行および維持する方法についての強力な理解は、自己管理型のW&Bをデプロイする前の重要な前提条件です。あなたのチームが支援を必要とする場合、弊社のプロフェッショナルサービスチームとパートナーが、実装と最適化のサポートを提供します。
自分で管理する代わりに、W&Bの管理されたソリューションについて詳しく知るには、W&Bマルチテナントクラウド およびW&B専用クラウド を参照してください。
インフラストラクチャ
アプリケーション層
アプリケーション層は、ノード障害に対するレジリエンスを備えたマルチノードKubernetesクラスターで構成されます。Kubernetesクラスターは、W&Bのポッドを実行および管理します。
ストレージ層
ストレージ層は、MySQLデータベースとオブジェクトストレージで構成されます。MySQLデータベースはメタデータを保存し、オブジェクトストレージはモデルやデータセットなどのアーティファクトを保存します。
インフラストラクチャの要件
Kubernetes
W&Bサーバーアプリケーションは、複数のポッドをデプロイするKubernetesオペレーター としてデプロイされます。このため、W&Bには以下の要件を備えたKubernetesクラスターが必要です：
完全に設定され機能するインフラストラクチャコントローラ。
永続ボリュームをプロビジョニングする能力。
MySQL
W&BはメタデータをMySQLデータベースに保存します。データベースのパフォーマンスとストレージの要件は、モデルパラメータの形状と関連するメタデータに依存します。たとえば、トレーニングランをより多くトラッキングするにつれてデータベースはサイズが成長し、ランテーブル、ユーザーワークスペース、およびレポートにおけるクエリに基づいてデータベースの負荷は増加します。
自己管理型のMySQLデータベースをデプロイするときは、以下の点を考慮してください：
バックアップ . データベースを別の施設に周期的にバックアップするべきです。W&Bは、少なくとも1週間の保持で、毎日のバックアップを推奨します。パフォーマンス . サーバーが稼働しているディスクは高速であるべきです。W&Bは、データベースをSSDまたは加速されたNASで実行することを推奨しています。モニタリング . データベースは負荷に対して監視されるべきです。システムのCPU使用率が5分以上持続的に40%を超える場合、サーバーがリソース不足であることを示している可能性があります。可用性 . 可用性と耐久性の要件によって、プライマリサーバーからリアルタイムですべての更新をストリーミングし、プライマリサーバーがクラッシュするか破損するイベントに備えてフェイルオーバーできるホットスタンバイを別のマシンで設定することを検討するかもしれません。
オブジェクトストレージ
W&Bは、Pre-signed URLとCORSサポートのあるオブジェクトストレージを必要とし、次のいずれかにデプロイします：
Amazon S3
Azure Cloud Storage
Google Cloud Storage
Amazon S3互換のストレージサービス
バージョン
ソフトウェア
最小バージョン
Kubernetes
v1.29
MySQL
v8.0.0, “一般可用性"リリースのみ
ネットワーク
ネットワークデプロイメントの際、インストール中およびランタイム中にこれらのエンドポイントへのエージェントのアクセスが必要です:
エアギャップデプロイメントについて知るには、エアギャップインスタンス用Kubernetesオペレーター を参照してください。
トレーニングインフラストラクチャと実験のニーズを追跡する各システムにおいて、W&Bおよびオブジェクトストレージへのアクセスが必要です。
DNS
W&Bデプロイメントの完全修飾ドメイン名（FQDN）は、Aレコードを使用してインフラストラクチャのIPアドレスに解決する必要があります。
SSL/TLS
W&Bは、クライアントとサーバー間の安全な通信のために、有効な署名されたSSL/TLS証明書を必要とします。SSL/TLSの終端は、インフラストラクチャで行われる必要があります。W&Bサーバーアプリケーションは、SSLまたはTLS接続を終了しません。
ご注意: W&Bは自己署名証明書およびカスタムCAの使用を推奨していません。
対応するCPUアーキテクチャ
W&BはIntel（x86）CPUアーキテクチャ上で実行されます。ARMはサポートされていません。
インフラストラクチャのプロビジョニング
Terraformはプロダクション用にW&Bをデプロイするために推奨される方法です。Terraformを使用すると、必要なリソース、それらの他のリソースへの参照、および依存関係を定義できます。W&Bは主要なクラウドプロバイダ向けにTerraformモジュールを提供しています。詳細については、自己管理型クラウドアカウントでW&Bサーバーをデプロイする方法 を参照してください。
サイズ調整
デプロイメントを計画する際の出発点として、以下の一般的なガイドラインを使用してください。W&Bは、新しいデプロイメントのすべてのコンポーネントを厳密に監視し、観察された使用パターンに基づいて調整を行うことを推奨します。時間をかけてプロダクションデプロイメントを監視し、最適なパフォーマンスを維持するために必要に応じて調整を行い続けてください。
Modelsのみ
Kubernetes
環境
CPU
メモリ
ディスク
テスト・開発
2 cores
16 GB
100 GB
プロダクション
8 cores
64 GB
100 GB
数字はKubernetesワーカーノードごとです。
MySQL
環境
CPU
メモリ
ディスク
テスト・開発
2 cores
16 GB
100 GB
プロダクション
8 cores
64 GB
500 GB
数字はMySQLノードごとです。
Weaveのみ
Kubernetes
環境
CPU
メモリ
ディスク
テスト・開発
4 cores
32 GB
100 GB
プロダクション
12 cores
96 GB
100 GB
数字はKubernetesワーカーノードごとです。
MySQL
環境
CPU
メモリ
ディスク
テスト・開発
2 cores
16 GB
100 GB
プロダクション
8 cores
64 GB
500 GB
数字はMySQLノードごとです。
ModelsとWeave
Kubernetes
環境
CPU
メモリ
ディスク
テスト・開発
4 cores
32 GB
100 GB
プロダクション
16 cores
128 GB
100 GB
数字はKubernetesワーカーノードごとです。
MySQL
環境
CPU
メモリ
ディスク
テスト・開発
2 cores
16 GB
100 GB
プロダクション
8 cores
64 GB
500 GB
数字はMySQLノードごとです。
クラウドプロバイダーインスタンスの推奨
サービス
クラウド
Kubernetes
MySQL
オブジェクトストレージ
AWS
EKS
RDS Aurora
S3
GCP
GKE
Google Cloud SQL - Mysql
Google Cloud Storage (GCS)
Azure
AKS
Azure Database for Mysql
Azure Blob Storage
マシンタイプ
これらの推奨事項は、クラウドインフラストラクチャ内でのW&Bの自己管理型デプロイメントの各ノードに適用されます。
AWS
環境
K8s (Modelsのみ)
K8s (Weaveのみ)
K8s (Models&Weave)
MySQL
テスト・開発
r6i.large
r6i.xlarge
r6i.xlarge
db.r6g.large
プロダクション
r6i.2xlarge
r6i.4xlarge
r6i.4xlarge
db.r6g.2xlarge
GCP
環境
K8s (Modelsのみ)
K8s (Weaveのみ)
K8s (Models&Weave)
MySQL
テスト・開発
n2-highmem-2
n2-highmem-4
n2-highmem-4
db-n1-highmem-2
プロダクション
n2-highmem-8
n2-highmem-16
n2-highmem-16
db-n1-highmem-8
Azure
環境
K8s (Modelsのみ)
K8s (Weaveのみ)
K8s (Models&Weave)
MySQL
テスト・開発
Standard_E2_v5
Standard_E4_v5
Standard_E4_v5
MO_Standard_E2ds_v4
プロダクション
Standard_E8_v5
Standard_E16_v5
Standard_E16_v5
MO_Standard_E8ds_v4
5.1.2.2 - W&B サーバーを Kubernetes で実行する
W&B プラットフォーム を Kubernetes Operator でデプロイする
W&B Kubernetes オペレーター
W&B Kubernetes オペレーターを使用して、Kubernetes 上の W&B Server デプロイメントを展開、管理、トラブルシューティング、およびスケーリングを簡素化します。このオペレーターは、W&B インスタンス用のスマートアシスタントと考えることができます。
W&B Server のアーキテクチャと設計は、AI 開発者のツール提供能力を拡張し、高性能でより優れたスケーラビリティと簡易な管理を提供するために進化し続けています。この進化は、コンピューティングサービス、関連ストレージ、およびそれらの接続性に適用されます。デプロイメントタイプ全体での継続的な更新と改善を促進するために、W&B は Kubernetes オペレーターを使用しています。
W&B はオペレーターを使用して、AWS、GCP、および Azure のパブリッククラウド上で専用クラウドインスタンスをデプロイおよび管理します。
Kubernetes オペレーターに関する詳細情報は、Kubernetes のドキュメントにあるオペレーターパターン を参照してください。
アーキテクチャの変更理由
歴史的に、W&B アプリケーションは Kubernetes クラスター内の単一デプロイメントおよびポッド、または単一の Docker コンテナとしてデプロイされていました。W&B は引き続き、データベースおよびオブジェクトストアを外部化することを推奨しています。データベースとオブジェクトストアの外部化は、アプリケーションの状態を切り離します。
アプリケーションが成長するにつれて、モノリシックコンテナから分散システム（マイクロサービス）へ進化するニーズが明らかになりました。この変更はバックエンドロジックの処理を容易にし、組み込みの Kubernetes インフラストラクチャ能力をスムーズに導入します。分散システムはまた、新しいサービスの展開をサポートし、W&B が依存する追加の機能を提供します。
2024年以前、Kubernetes 関連の変更は、terraform-kubernetes-wandb Terraform モジュールを手動で更新する必要がありました。Terraform モジュールを更新することで、クラウドプロバイダー間の互換性が確保され、必要な Terraform 変数が設定され、すべてのバックエンドまたは Kubernetes レベルの変更ごとに Terraform を適用することが保証されました。
このプロセスはスケーラブルではありませんでした。なぜなら、W&B サポートが各顧客に対して Terraform モジュールのアップグレードを支援しなければならなかったからです。
その解決策は、中央の deploy.wandb.ai サーバーに接続するオペレーターを実装し、特定のリリースチャンネルに対する最新の仕様変更を要求して適用することでした。ライセンスが有効な限り、更新が受け取れます。Helm は、W&B オペレーターのデプロイメントメカニズムとして、また W&B Kubernetes スタックのすべての設定テンプレート処理を行う手段として使用され、Helm-セプションを実現します。
仕組み
オペレーターを helm でインストールするか、ソースからインストールすることができます。詳細な手順はcharts/operator を参照してください。
インストールプロセスは controller-manager という名前のデプロイメントを作成し、spec をクラスターに適用する weightsandbiases.apps.wandb.com (shortName: wandb) という名前のカスタムリソース 定義を使用します。
apiVersion : apiextensions.k8s.io/v1
kind : CustomResourceDefinition
metadata :
name : weightsandbiases.apps.wandb.com
controller-manager は、カスタムリソース、リリースチャンネル、およびユーザー定義の設定の spec に基づいて charts/operator-wandb をインストールします。設定の仕様の階層は、ユーザー側での最大限の設定の柔軟性を実現し、新しい画像、設定、機能、および Helm 更新を自動的にリリースすることが可能です。
設定オプションについては、設定仕様階層 および設定参照 を参照してください。
設定仕様階層
設定仕様は、上位レベルの仕様が下位レベルのものをオーバーライドする階層モデルに従います。以下はその仕組みです：
リリースチャンネル値 : これは基本レベルの設定で、デプロイメントに対する W&B によって設定されたリリースチャンネルに基づいてデフォルトの値と設定を設定します。ユーザー入力値 : システムコンソールを通じて、ユーザーはリリースチャンネル Spec によって提供されるデフォルト設定をオーバーライドすることができます。カスタムリソース値 : ユーザーから提供される最高レベルの仕様です。ここで指定された値は、ユーザー入力およびリリースチャンネルの仕様の両方をオーバーライドします。設定オプションの詳細な説明については、設定参照 を参照してください。
この階層モデルは、さまざまなニーズに合わせて柔軟でカスタマイズ可能な設定を保証し、管理可能で体系的なアップグレードと変更のアプローチを維持します。
W&B Kubernetes オペレーターを使用するための要件
W&B を W&B Kubernetes オペレーターでデプロイするために、次の要件を満たしてください:
リファレンスアーキテクチャ を参照してください。また、有効な W&B サーバーライセンスを取得 します。
セルフマネージドインストールのセットアップと構成方法についての詳細な説明は、こちらのガイド を参照してください。
インストール方法によっては、次の要件を満たす必要がある場合があります:
正しい Kubernetes クラスターコンテキストでインストール済みかつ構成済みの Kubectl。
Helm がインストールされていること。
エアギャップインストール
エアギャップ環境での W&B Kubernetes オペレーターのインストール方法については、Deploy W&B in airgapped environment with Kubernetes チュートリアルを参照してください。
W&B Server アプリケーションのデプロイ
このセクションでは、W&B Kubernetes オペレーターをデプロイするさまざまな方法を説明しています。
W&B Operator は、W&B Server のデフォルトで推奨されるインストール方法です
以下のいずれかを選択してください:
必要なすべての外部サービスをプロビジョニング済みで、Helm CLI を使用して W&B を Kubernetes にデプロイしたい場合はこちら を参照してください。
インフラストラクチャと W&B Server を Terraform で管理することを好む場合はこちら を参照してください。
W&B Cloud Terraform Modules を利用したい場合はこちら を参照してください。
Helm CLI で W&B をデプロイする
W&B は W&B Kubernetes オペレーターを Kubernetes クラスターにデプロイするための Helm Chart を提供しています。この方法により、Helm CLI または ArgoCD などの継続的デリバリーツールを使用して W&B Server をデプロイできます。上記の要件が満たされていることを確認してください。
次の手順に従って、Helm CLI を使用して W&B Kubernetes オペレーターをインストールします:
W&B Helm リポジトリを追加します。W&B Helm チャートは W&B Helm リポジトリで利用可能です。以下のコマンドでリポジトリを追加します:
helm repo add wandb https://charts.wandb.ai
helm repo update
Kubernetes クラスターにオペレーターをインストールします。以下をコピーして貼り付けます:
helm upgrade --install operator wandb/operator -n wandb-cr --create-namespace
W&B オペレーターのカスタムリソースを構成して W&B Server のインストールをトリガーします。この設定の例を operator.yaml というファイルにコピーし、W&B デプロイメントをカスタマイズできるようにします。設定参照 を参照してください。
apiVersion : apps.wandb.com/v1
kind : WeightsAndBiases
metadata :
labels :
app.kubernetes.io/instance : wandb
app.kubernetes.io/name : weightsandbiases
name : wandb
namespace : default
spec :
chart :
url : http://charts.yourdomain.com
name : operator-wandb
version : 0.18.0
values :
global :
host : https://wandb.yourdomain.com
license : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
bucket :
accessKey : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
secretKey : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
name: s3.yourdomain.com:port #Ex. : s3.yourdomain.com:9000
path : bucket_name
provider : s3
region : us-east-1
mysql :
database : wandb
host : mysql.home.lab
password : password
port : 3306
user : wandb
extraEnv :
ENABLE_REGISTRY_UI : 'true'
# Ensure it's set to use your own MySQL
mysql :
install : false
app :
image :
repository : registry.yourdomain.com/local
tag : 0.59.2
console :
image :
repository : registry.yourdomain.com/console
tag : 2.12.2
ingress :
annotations :
nginx.ingress.kubernetes.io/proxy-body-size : 64m
class : nginx
独自の設定でオペレーターを開始して、W&B Server アプリケーションをインストールおよび構成できるようにします。
kubectl apply -f operator.yaml
デプロイメントが完了するまで待ちます。これには数分かかります。
Web UI を使用してインストールを検証するには、最初の管理者ユーザーアカウントを作成し、インストールの検証 で説明されている検証手順に従います。
この方法は、特定の要件に合わせたカスタマイズされたデプロイメントを可能にし、Terraform のインフラストラクチャ-as-code アプローチを活用して一貫性と再現性を実現します。公式の W&B Helm ベースの Terraform Module はこちら にあります。
以下のコードを出発点として使用し、本番グレードのデプロイメントに必要な設定オプションをすべて含めることができます。
module "wandb" {
source = "wandb/wandb/helm"
spec = {
values = {
global = {
host = "https://<HOST_URI>"
license = "eyJhbGnUzaH...j9ZieKQ2x5GGfw"
bucket = {
< details depend on the provider >
}
mysql = {
< redacted >
}
}
ingress = {
annotations = {
"a" = "b"
"x" = "y"
}
}
}
}
}
設定オプションは設定参照 に記載されているものと同じですが、構文は HashiCorp Configuration Language (HCL) に従う必要があります。Terraform モジュールは、W&B カスタムリソース定義 (CRD) を作成します。
W&B&Biases 自身が「Dedicated cloud」インストールをデプロイするために Helm Terraform モジュールをどのように活用しているかを知るには、次のリンクをたどってください：
W&B は AWS、GCP、および Azure のための Terraform Modules を提供しています。これらのモジュールは、Kubernetes クラスター、ロードバランサー、MySQL データベースなどのインフラ全体と同様に W&B Server アプリケーションをデプロイします。これらの公式 W&B クラウド固有の Terraform Modules には、W&B Kubernetes オペレーターが既に組み込まれています。
この統合により、最小限のセットアップで W&B インスタンス用の W&B Kubernetes オペレーターの準備が整い、クラウド環境での W&B Server のデプロイと管理がスムーズに行えます。
これらのモジュールの使用方法の詳細な説明については、これをセクション のセルフマネージドインストールセクションのドキュメントを参照してください。
インストールを検証する
インストールを検証するには、W&B は W&B CLI を使用することを推奨しています。検証コマンドは、すべてのコンポーネントと設定を検証するいくつかのテストを実行します。
このステップは、最初の管理者ユーザーアカウントをブラウザで作成してあることを前提としています。
インストールを検証するために以下の手順に従います:
W&B CLI をインストールします:
W&B にログインします:
wandb login --host= https://YOUR_DNS_DOMAIN
例:
wandb login --host= https://wandb.company-name.com
インストールを検証します:
正常なインストールと完全に機能する W&B デプロイメントは、次の出力を示します:
Default host selected: https://wandb.company-name.com
Find detailed logs for this test at: /var/folders/pn/b3g3gnc11_sbsykqkm3tx5rh0000gp/T/tmpdtdjbxua/wandb
Checking if logged in...................................................✅
Checking signed URL upload..............................................✅
Checking ability to send large payloads through proxy...................✅
Checking requests to base url...........................................✅
Checking requests made over signed URLs.................................✅
Checking CORs configuration of the bucket...............................✅
Checking wandb package version is up to date............................✅
Checking logged metrics, saving and downloading a file..................✅
Checking artifact save and download workflows...........................✅
W&B 管理コンソールへのアクセス
W&B Kubernetes オペレーターには管理コンソールが付属しています。 ${HOST_URI}/console にあり、例えば https://wandb.company-name.com/ です。
管理コンソールにログインする方法は2つあります:
W&B アプリケーションをブラウザで開き、ログインします。W&B アプリケーションには ${HOST_URI}/ でログインします。例えば https://wandb.company-name.com/
コンソールにアクセスします。右上のアイコンをクリックし、次に System console をクリックします。管理者権限を持つユーザーだけが System console エントリを見ることができます。
W&B は、Option 1 が機能しない場合のみ、以下の手順を使用してコンソールにアクセスすることを推奨します。
ブラウザでコンソールアプリケーションを開きます。上記で説明されている URL を開くと、ログイン画面にリダイレクトされます:
インストールが生成する Kubernetes シークレットからパスワードを取得します:
kubectl get secret wandb-password -o jsonpath= '{.data.password}' | base64 -d
コンソールにログインします。コピーしたパスワードを貼り付け、次に Login をクリックします。
W&B Kubernetes オペレーターの更新
このセクションでは、W&B Kubernetes オペレーターを更新する方法を説明します。
W&B Kubernetes オペレーターを更新しても、W&B サーバーアプリケーションは更新されません。
W&B Kubernetes オペレーターを使用していない helm chart を使用している場合は、続いて W&B オペレーターを更新する手順を実行する前にこちら の指示を参照してください。
以下のコードスニペットをターミナルにコピーして貼り付けます。
まず、 helm repo update
次に、 helm upgrade
helm upgrade operator wandb/operator -n wandb-cr --reuse-values
W&B Server アプリケーションの更新
W&B Kubernetes オペレーターを使用する場合、W&B Server アプリケーションの更新は不要です。
オペレーターは、W&B のソフトウェアの新しいバージョンがリリースされると、W&B Server アプリケーションを自動的に更新します。
W&B オペレーターへのセルフマネージドインスタンスの移行
このセクションでは、自分自身で W&B Server インストールを管理することから、W&B オペレーターを使用してこれを実行するための移行プロセスを説明しています。移行プロセスは、W&B Server をインストールした方法によって異なります:
W&B オペレーターは、W&B Server のデフォルトで推奨されるインストール方法です。質問がある場合や不明点がある場合は、
カスタマーサポート または W&B チームに問い合わせてください。
移行プロセスの詳細な説明については、こちら here を参照してください。
質問がある場合や支援が必要な際は、カスタマーサポート または W&B チームにお問い合わせください。
質問がある場合や支援が必要な際は、カスタマーサポート または W&B チームにお問い合わせください。
オペレーターを基にした Helm チャートへの移行
オペレーターを基にした Helm チャートへの移行手順は次のとおりです:
現在の W&B 設定を取得します。W&B がオペレーターを基にしていないバージョンの Helm チャートでデプロイされている場合、次のように値をエクスポートします:
W&B が Kubernetes マニフェストでデプロイされている場合、次のように値をエクスポートします:
kubectl get deployment wandb -o yaml
これで、次のステップで必要なすべての設定値が手元にあります。
operator.yaml というファイルを作成します。設定参照 で説明されている形式に従ってください。ステップ 1 の値を使用します。
現在のデプロイメントを 0 ポッドにスケールします。このステップで現在のデプロイメントを停止します。
kubectl scale --replicas= 0 deployment wandb
Helm チャートのリポジトリを更新します:
新しい Helm チャートをインストールします:
helm upgrade --install operator wandb/operator -n wandb-cr --create-namespace
新しい helm チャートを構成し、W&B アプリケーションのデプロイメントをトリガーします。新しい設定を適用します。
kubectl apply -f operator.yaml
デプロイメントが完了するまでに数分かかります。
インストールを検証します。すべてが正常に動作することを確認するために、インストールの検証 の手順に従います。
古いインストールの削除。古い helm チャートをアンインストールするか、マニフェストで作成されたリソースを削除します。
オペレーターを基にした Helm チャートへの移行手順は次のとおりです:
Terraform 設定を準備します。Terraform 設定内の古いデプロイメントの Terraform コードを、こちら で説明されているものに置き換えます。以前と同じ変数を設定します。.tfvars ファイルがある場合、それを変更しないでください。
Terraform run を実行します。terraform init、plan、および apply を実行します。
インストールを検証します。すべてが正常に動作することを確認するために、インストールの検証 の手順に従います。
古いインストールの削除。古い helm チャートをアンインストールするか、マニフェストで作成されたリソースを削除します。
Configuration Reference for W&B Server
このセクションでは、W&B サーバーアプリケーションの設定オプションについて説明します。アプリケーションは、WeightsAndBiases というカスタムリソース定義としてその設定を受け取ります。一部の設定オプションは以下の設定で公開され、他は環境変数として設定する必要があります。
ドキュメントには環境変数が2つのリストに分かれています：basic および advanced 。必要な設定オプションが Helm Chart を使用して公開されていない場合にのみ環境変数を使用してください。
本番展開用の W&B サーバーアプリケーションの設定ファイルには、以下の内容が必要です。この YAML ファイルは、W&B デプロイメントの望ましい状態を定義し、バージョン、環境変数、データベースなどの外部リソース、およびその他必要な設定を含みます。
apiVersion : apps.wandb.com/v1
kind : WeightsAndBiases
metadata :
labels :
app.kubernetes.io/name : weightsandbiases
app.kubernetes.io/instance : wandb
name : wandb
namespace : default
spec :
values :
global :
host : https://<HOST_URI>
license : eyJhbGnUzaH...j9ZieKQ2x5GGfw
bucket :
<details depend on the provider>
mysql :
<redacted>
ingress :
annotations :
<redacted>
完全な値セットは W&B Helm リポジトリ にあります。オーバーライドする必要がある値のみを変更してください。
完全な例
これは、GCP Kubernetes を使用した GCP Ingress および GCS（GCP オブジェクトストレージ）を使用した設定例です：
apiVersion : apps.wandb.com/v1
kind : WeightsAndBiases
metadata :
labels :
app.kubernetes.io/name : weightsandbiases
app.kubernetes.io/instance : wandb
name : wandb
namespace : default
spec :
values :
global :
host : https://abc-wandb.sandbox-gcp.wandb.ml
bucket :
name : abc-wandb-moving-pipefish
provider : gcs
mysql :
database : wandb_local
host : 10.218.0.2
name : wandb_local
password : 8wtX6cJHizAZvYScjDzZcUarK4zZGjpV
port : 3306
user : wandb
license : eyJhbGnUzaHgyQjQyQWhEU3...ZieKQ2x5GGfw
ingress :
annotations :
ingress.gcp.kubernetes.io/pre-shared-cert : abc-wandb-cert-creative-puma
kubernetes.io/ingress.class : gce
kubernetes.io/ingress.global-static-ip-name : abc-wandb-operator-address
ホスト
# プロトコルと共に完全修飾ドメイン名を提供
global :
# ホスト名の例、独自のものに置き換え
host : https://wandb example com
オブジェクトストレージ (バケット)
AWS
global :
bucket :
provider : "s3"
name : ""
kmsKey : ""
region : ""
GCP
global :
bucket :
provider : "gcs"
name : ""
Azure
global :
bucket :
provider : "az"
name : ""
secretKey : ""
その他のプロバイダー（Minio、Ceph、など）
他の S3 互換プロバイダーの場合、バケットの設定は次のようにします：
global :
bucket :
# 例の値、独自のものに置き換え
provider : s3
name : storage.example.com
kmsKey : null
path : wandb
region : default
accessKey : 5WOA500...P5DK7I
secretKey : HDKYe4Q...JAp1YyjysnX
AWS 外部でホスティングされている S3 互換ストレージの場合、kmsKey は null にする必要があります。
accessKey および secretKey をシークレットから参照するには：
global :
bucket :
# 例の値、独自のものに置き換え
provider : s3
name : storage.example.com
kmsKey : null
path : wandb
region : default
secret :
secretName : bucket-secret
accessKeyName : ACCESS_KEY
secretKeyName : SECRET_KEY
MySQL
global :
mysql :
# 例の値、独自のものに置き換え
host : db.example.com
port : 3306
database : wandb_local
user : wandb
password : 8wtX6cJH...ZcUarK4zZGjpV
password をシークレットから参照するには：
global :
mysql :
# 例の値、独自のものに置き換え
host : db.example.com
port : 3306
database : wandb_local
user : wandb
passwordSecret :
name : database-secret
passwordKey : MYSQL_WANDB_PASSWORD
ライセンス
global :
# 例のライセンス、独自のものに置き換え
license : eyJhbGnUzaHgyQjQy...VFnPS_KETXg1hi
license をシークレットから参照するには：
global :
licenseSecret :
name : license-secret
key : CUSTOMER_WANDB_LICENSE
Ingress
Kubernetes ingress クラスを識別する方法については、FAQ エントリ を参照してください。
TLS なし
global :
# 重要: Ingress は YAML の `global` と同じレベルにあります（子ではありません）
ingress :
class : ""
TLS 使用
証明書が含まれるシークレットを作成します
kubectl create secret tls wandb-ingress-tls --key wandb-ingress-tls.key --cert wandb-ingress-tls.crt
Ingress 設定でシークレットを参照します
global :
# 重要: Ingress は YAML の `global` と同じレベルにあります（子ではありません）
ingress :
class : ""
annotations :
{}
# kubernetes.io/ingress.class: nginx
# kubernetes.io/tls-acme: "true"
tls :
- secretName : wandb-ingress-tls
hosts :
- <HOST_URI>
Nginx の場合、次の注釈を追加する必要があるかもしれません：
ingress:
annotations:
nginx.ingress.kubernetes.io/proxy-body-size: 64m
カスタム Kubernetes ServiceAccounts
W&B ポッドを実行するためにカスタム Kubernetes Service Account を指定します。
次のスニペットは、指定された名前でデプロイメントの一部としてサービスアカウントを作成します：
app :
serviceAccount :
name : custom-service-account
create : true
parquet :
serviceAccount :
name : custom-service-account
create : true
global :
...
サブシステム “app” および “parquet” は指定されたサービスアカウントの下で実行されます。他のサブシステムはデフォルトのサービスアカウントで実行されます。
サービスアカウントがクラスター上で既に存在する場合、create: false を設定します：
app :
serviceAccount :
name : custom-service-account
create : false
parquet :
serviceAccount :
name : custom-service-account
create : false
global :
...
app, parquet, console, その他の様々なサブシステム上にサービスアカウントを指定できます：
app :
serviceAccount :
name : custom-service-account
create : true
console :
serviceAccount :
name : custom-service-account
create : true
global :
...
サブシステム間でサービスアカウントを異なるものにすることができます：
app :
serviceAccount :
name : custom-service-account
create : false
console :
serviceAccount :
name : another-custom-service-account
create : true
global :
...
外部 Redis
redis :
install : false
global :
redis :
host : ""
port : 6379
password : ""
parameters : {}
caCert : ""
password をシークレットから参照するには：
kubectl create secret generic redis-secret --from-literal=redis-password=supersecret
下記の設定で参照します：
redis :
install : false
global :
redis :
host : redis.example
port : 9001
auth :
enabled : true
secret : redis-secret
key : redis-password
LDAP
TLS を使用しない場合
global :
ldap :
enabled : true
# LDAP サーバーアドレスには "ldap://" または "ldaps://" を含める
host :
# ユーザーを見つけるために使用する LDAP 検索ベース
baseDN :
# バインドに使用する LDAP ユーザー（匿名バインドを使用しない場合）
bindDN :
# バインドに使用する LDAP パスワードを含むシークレットの名前とキー（匿名バインドを使用しない場合）
bindPW :
# 電子メールおよびグループ ID 属性名の LDAP 属性をカンマ区切りの文字列で指定
attributes :
# LDAP グループ許可リスト
groupAllowList :
# LDAP TLS の有効化
tls : false
TLS 使用
LDAP TLS 証明書の設定には、証明書内容をプレ作成した config map が必要です。
config map を作成するには、次のコマンドを使用できます：
kubectl create configmap ldap-tls-cert --from-file=certificate.crt
そして、下記の例のように YAML 内で config map を使用します：
global :
ldap :
enabled : true
# LDAP サーバーアドレスには "ldap://" または "ldaps://" を含める
host :
# ユーザーを見つけるために使用する LDAP 検索ベース
baseDN :
# バインドに使用する LDAP ユーザー（匿名バインドを使用しない場合）
bindDN :
# バインドに使用する LDAP パスワードを含むシークレットの名前とキー（匿名バインドを使用しない場合）
bindPW :
# 電子メールおよびグループ ID 属性名の LDAP 属性をカンマ区切りの文字列で指定
attributes :
# LDAP グループ許可リスト
groupAllowList :
# LDAP TLS の有効化
tls : true
# LDAP サーバーの CA 証明書を含む ConfigMap の名前とキー
tlsCert :
configMap :
name : "ldap-tls-cert"
key : "certificate.crt"
OIDC SSO
global :
auth :
sessionLengthHours : 720
oidc :
clientId : ""
secret : ""
# IdP が要求する場合のみ含める。
authMethod : ""
issuer : ""
authMethod はオプションです。
SMTP
global :
email :
smtp :
host : ""
port : 587
user : ""
password : ""
環境変数
global :
extraEnv :
GLOBAL_ENV : "example"
カスタム証明書機関
customCACerts はリストであり、複数の証明書を含むことができます。customCACerts に指定された証明書機関は W&B サーバーアプリケーションのみに適用されます。
global :
customCACerts :
- |
-----BEGIN CERTIFICATE-----
MIIBnDCCAUKgAwIBAg.....................fucMwCgYIKoZIzj0EAwIwLDEQ
MA4GA1UEChMHSG9tZU.....................tZUxhYiBSb290IENBMB4XDTI0
MDQwMTA4MjgzMFoXDT.....................oNWYggsMo8O+0mWLYMAoGCCqG
SM49BAMCA0gAMEUCIQ.....................hwuJgyQRaqMI149div72V2QIg
P5GD+5I+02yEp58Cwxd5Bj2CvyQwTjTO4hiVl1Xd0M0=
-----END CERTIFICATE-----
- |
-----BEGIN CERTIFICATE-----
MIIBxTCCAWugAwIB.......................qaJcwCgYIKoZIzj0EAwIwLDEQ
MA4GA1UEChMHSG9t.......................tZUxhYiBSb290IENBMB4XDTI0
MDQwMTA4MjgzMVoX.......................UK+moK4nZYvpNpqfvz/7m5wKU
SAAwRQIhAIzXZMW4.......................E8UFqsCcILdXjAiA7iTluM0IU
aIgJYVqKxXt25blH/VyBRzvNhViesfkNUQ==
-----END CERTIFICATE-----
証明書機関を ConfigMap に保存することもできます：
global :
caCertsConfigMap : custom-ca-certs
ConfigMap は次のようになっている必要があります：
apiVersion : v1
kind : ConfigMap
metadata :
name : custom-ca-certs
data :
ca-cert1.crt : |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
ca-cert2.crt : |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
ConfigMap を使用する場合、ConfigMap 内の各キーは .crt で終わる必要があります（例：my-cert.crt または ca-cert1.crt）。この名前付け規約は、update-ca-certificates が各証明書をシステム CA ストアに解析して追加するために必要です。
カスタムセキュリティコンテキスト
各 W&B コンポーネントは、以下の形式のカスタムセキュリティコンテキスト設定をサポートしています：
pod :
securityContext :
runAsNonRoot : true
runAsUser : 1001
runAsGroup : 0
fsGroup : 1001
fsGroupChangePolicy : Always
seccompProfile :
type : RuntimeDefault
container :
securityContext :
capabilities :
drop :
- ALL
readOnlyRootFilesystem : false
allowPrivilegeEscalation : false
runAsGroup:には 0 だけが有効な値です。 他の値はエラーです。
アプリケーションポッドを設定するには、設定に app セクションを追加します：
global :
...
app :
pod :
securityContext :
runAsNonRoot : true
runAsUser : 1001
runAsGroup : 0
fsGroup : 1001
fsGroupChangePolicy : Always
seccompProfile :
type : RuntimeDefault
container :
securityContext :
capabilities :
drop :
- ALL
readOnlyRootFilesystem : false
allowPrivilegeEscalation : false
同じ概念は console、weave、weave-trace、parquet にも適用されます。
Configuration Reference for W&B Operator
このセクションでは、W&B Kubernetes オペレーター（wandb-controller-manager）の設定オプションを説明しています。オペレーターは、YAML ファイルの形式でその設定を受け取ります。
デフォルトでは、W&B Kubernetes オペレーターには設定ファイルは必要ありません。必要な場合にだけ設定ファイルを作成します。たとえば、カスタム証明書機関を指定したり、エアギャップ環境にデプロイしたりする必要がある場合などです。
仕様のカスタマイズの完全なリストは、Helm リポジトリ で確認できます。
カスタム CA
カスタム証明書機関（customCACerts）はリストであり、複数の証明書を含むことができます。それらの証明書機関が追加されると、W&B Kubernetes オペレーター（wandb-controller-manager）のみに適用されます。
customCACerts :
- |
-----BEGIN CERTIFICATE-----
MIIBnDCCAUKgAwIBAg.....................fucMwCgYIKoZIzj0EAwIwLDEQ
MA4GA1UEChMHSG9tZU.....................tZUxhYiBSb290IENBMB4XDTI0
MDQwMTA4MjgzMFoXDT.....................oNWYggsMo8O+0mWLYMAoGCCqG
SM49BAMCA0gAMEUCIQ.....................hwuJgyQRaqMI149div72V2QIg
P5GD+5I+02yEp58Cwxd5Bj2CvyQwTjTO4hiVl1Xd0M0=
-----END CERTIFICATE-----
- |
-----BEGIN CERTIFICATE-----
MIIBxTCCAWugAwIB.......................qaJcwCgYIKoZIzj0EAwIwLDEQ
MA4GA1UEChMHSG9t.......................tZUxhYiBSb290IENBMB4XDTI0
MDQwMTA4MjgzMVoX.......................UK+moK4nZYvpNpqfvz/7m5wKU
SAAwRQIhAIzXZMW4.......................E8UFqsCcILdXjAiA7iTluM0IU
aIgJYVqKxXt25blH/VyBRzvNhViesfkNUQ==
-----END CERTIFICATE-----
CA 証明書を ConfigMap に保存することもできます：
caCertsConfigMap : custom-ca-certs
ConfigMap は次のようになっている必要があります：
apiVersion : v1
kind : ConfigMap
metadata :
name : custom-ca-certs
data :
ca-cert1.crt : |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
ca-cert2.crt : |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
ConfigMap の各キーは .crt で終わる必要があります（例：my-cert.crt または ca-cert1.crt）。この命名規則は、update-ca-certificates が各証明書をシステム CA ストアに解析して追加するために必要です。
FAQ
各個別のポッドの役割/目的は何ですか？
wandb-appwandb-console/console を通じてアクセスできます。wandb-otelwandb-prometheuswandb-parquetwandb-app ポッドとは別のバックエンドマイクロサービスであり、データベースデータを Parquet 形式でオブジェクトストレージにエクスポートします。wandb-weavewandb-weave-tracewandb-app ポッドを介してアクセスできます。
W&B オペレーターコンソールパスワードの取得方法
W&B Kubernetes オペレーターマネジメントコンソールへのアクセス を参照してください。
Ingress が機能しない場合に W&B Operator Console にアクセスする方法
Kubernetes クラスターに到達可能なホストで以下のコマンドを実行してください：
kubectl port-forward svc/wandb-console 8082
https://localhost:8082/ console でブラウザからコンソールにアクセスしてください。
コンソールのパスワードの取得方法については、W&B Kubernetes オペレーターマネジメントコンソールへのアクセス （Option 2）を参照してください。
W&B Server のログを表示する方法
アプリケーションポッドの名前は wandb-app-xxx です。
kubectl get pods
kubectl logs wandb-XXXXX-XXXXX
Kubernetes ingress クラスを識別する方法
クラスターにインストールされている ingress クラスを取得するには、次のコマンドを実行します:
5.1.2.2.1 - エアギャップインスタンス用の Kubernetes オペレーター
Kubernetes Operator を使用して W&B プラットフォーム をデプロイする (Airgapped)
イントロダクション
このガイドは、顧客管理のエアギャップ環境で W&B プラットフォームをデプロイするためのステップバイステップの手順を提供します。
Helm チャートとコンテナイメージをホストするために内部のリポジトリーまたはレジストリーを使用します。Kubernetes クラスターへの適切なアクセスを備えたシェルコンソールで、すべてのコマンドを実行してください。
Kubernetes アプリケーションをデプロイするために使用している任意の継続的デリバリーツールで、同様のコマンドを利用できます。
ステップ 1: 前提条件
開始する前に、環境が次の要件を満たしていることを確認してください:
Kubernetes バージョン >= 1.28
Helm バージョン >= 3
必要な W&B イメージを備えた内部コンテナレジストリーへのアクセス
W&B Helm チャートのための内部 Helm リポジトリーへのアクセス
ステップ 2: 内部コンテナレジストリーの準備
デプロイメントを進める前に、以下のコンテナイメージが内部コンテナレジストリーに利用可能であることを確認する必要があります:
これらのイメージは、W&B コンポーネントの正常なデプロイメントに不可欠です。W&B はコンテナレジストリーを準備するために WSM を使用することをお勧めします。
もし組織がすでに内部コンテナレジストリーを使用している場合、イメージを追加することができます。そうでない場合は、次のセクションに進み、WSM と呼ばれるものを使用してコンテナリポジトリーを準備してください。
オペレーターの要件を追跡し、イメージのアップグレードを確認してダウンロードすることは、WSM を使用して または組織独自のプロセスを使用して行う責任があります。
WSM のインストール
WSM を次のいずれかのメソッドでインストールします。
WSM は、動作する Docker インストールを必要とします。
Bash
Bash スクリプトを GitHub から直接実行します:
curl -sSL https://raw.githubusercontent.com/wandb/wsm/main/install.sh | bash
スクリプトは、スクリプトを実行したフォルダーにバイナリをダウンロードします。別のフォルダーに移動するには、次を実行します:
sudo mv wsm /usr/local/bin
GitHub
W&B が管理する wandb/wsm GitHub リポジトリーから WSM をダウンロードまたはクローンします。最新リリースについては、wandb/wsm リリースノート を参照してください。
イメージとそのバージョンの一覧表示
wsm list を使用して最新のイメージバージョンのリストを取得します。
出力は次のようになります:
:package: デプロイメントに必要なすべてのイメージを一覧表示するプロセスを開始しています...
オペレーターイメージ:
wandb/controller:1.16.1
W&B イメージ:
wandb/local:0.62.2
docker.io/bitnami/redis:7.2.4-debian-12-r9
quay.io/prometheus-operator/prometheus-config-reloader:v0.67.0
quay.io/prometheus/prometheus:v2.47.0
otel/opentelemetry-collector-contrib:0.97.0
wandb/console:2.13.1
ここに W&B をデプロイするために必要なイメージがあります。これらのイメージが内部コンテナレジストリーで利用可能であることを確認し、`values.yaml` を適切に更新してください。
イメージのダウンロード
最新バージョンのイメージをすべて wsm download を使用してダウンロードします。
出力は次のようになります:
オペレーター Helm chart のダウンロード
wandb Helm chart のダウンロード
✓ wandb/controller:1.16.1
✓ docker.io/bitnami/redis:7.2.4-debian-12-r9
✓ otel/opentelemetry-collector-contrib:0.97.0
✓ quay.io/prometheus-operator/prometheus-config-reloader:v0.67.0
✓ wandb/console:2.13.1
✓ quay.io/prometheus/prometheus:v2.47.0
完了! 7 パッケージがインストールされました。
WSM は各イメージの .tgz アーカイブを bundle ディレクトリーにダウンロードします。
ステップ 3: 内部 Helm チャートリポジトリーの準備
コンテナイメージとともに、以下の Helm チャートが内部 Helm チャートリポジトリーに利用可能であることも確認する必要があります。前のステップで導入した WSM ツールは Helm チャートをダウンロードすることもできます。別の方法として、こちらでダウンロードしてください:
operator チャートは W&B Oyserator 、つまりコントローラーマネージャーをデプロイするために使用されます。platform チャートは、カスタムリソース定義 (CRD) に設定された値を使用して W&B プラットフォームをデプロイするために使用されます。
ステップ 4: Helm リポジトリーの設定
次に、W&B Helm チャートを内部リポジトリーからプルするために Helm リポジトリーを設定します。以下のコマンドを実行して、Helm リポジトリーを追加および更新します:
helm repo add local-repo https://charts.yourdomain.com
helm repo update
ステップ 5: Kubernetes オペレーターのインストール
W&B Kubernetes オペレーター、別名コントローラーマネージャーは、W&B プラットフォームのコンポーネントを管理する役割を果たします。エアギャップ環境でインストールするには、内部コンテナレジストリーを使用するように設定する必要があります。
そのためには、内部コンテナレジストリーを使用するためにデフォルトのイメージ設定をオーバーライドし、期待されるデプロイメントタイプを示すためにキー airgapped: true を設定する必要があります。以下のように values.yaml ファイルを更新します:
image :
repository : registry.yourdomain.com/library/controller
tag : 1.13.3
airgapped : true
タグを内部レジストリーで利用可能なバージョンに置き換えてください。
オペレーターと CRD をインストールします:
helm upgrade --install operator wandb/operator -n wandb --create-namespace -f values.yaml
サポートされている値の詳細については、Kubernetes オペレーター GitHub リポジトリー を参照してください。
ステップ 6: W&B カスタムリソースの設定
W&B Kubernetes オペレーターをインストールした後、内部 Helm リポジトリーおよびコンテナレジストリーを指すようにカスタムリソース (CR) を設定する必要があります。
この設定により、Kubernetes オペレーターが W&B プラットフォームに必要なコンポーネントをデプロイする際に、内部レジストリーとリポジトリーを使用することが保証されます。
この例の CR をコピーし、wandb.yaml という新しいファイルに名前を付けます。
apiVersion : apps.wandb.com/v1
kind : WeightsAndBiases
metadata :
labels :
app.kubernetes.io/instance : wandb
app.kubernetes.io/name : weightsandbiases
name : wandb
namespace : default
spec :
chart :
url : http://charts.yourdomain.com
name : operator-wandb
version : 0.18.0
values :
global :
host : https://wandb.yourdomain.com
license : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
bucket :
accessKey : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
secretKey : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
name: s3.yourdomain.com:port #Ex. : s3.yourdomain.com:9000
path : bucket_name
provider : s3
region : us-east-1
mysql :
database : wandb
host : mysql.home.lab
password : password
port : 3306
user : wandb
extraEnv :
ENABLE_REGISTRY_UI : 'true'
# インストール: true の場合、Helm はデプロイメントが使用するための MySQL データベースをインストールします。独自の外部 MySQL デプロイメントを使用するには `false` に設定してください。
mysql :
install : false
app :
image :
repository : registry.yourdomain.com/local
tag : 0.59.2
console :
image :
repository : registry.yourdomain.com/console
tag : 2.12.2
ingress :
annotations :
nginx.ingress.kubernetes.io/proxy-body-size : 64m
class : nginx
Kubernetes オペレーターは、CR の値を使用して内部リポジトリーから operator-wandb Helm チャートを設定し、W&B プラットフォームをデプロイします。
すべてのタグ/バージョンを内部レジストリーで利用可能なバージョンに置き換えてください。
前述の設定ファイルの作成に関する詳細情報はこちら にあります。
ステップ 7: W&B プラットフォームのデプロイ
Kubernetes オペレーターと CR が設定されたので、wandb.yaml 設定を適用して W&B プラットフォームをデプロイします:
kubectl apply -f wandb.yaml
FAQ
以下のよくある質問 (FAQs) およびデプロイメントプロセス中のトラブルシューティングのヒントを参照してください:
別のイングレスクラスがあります。それを使用できますか？
はい、values.yaml のイングレス設定を変更して、イングレスクラスを設定できます。
証明書バンドルに複数の証明書があります。それは機能しますか？
証明書を values.yaml の customCACerts セクションに複数のエントリに分割する必要があります。
Kubernetes オペレーターが無人更新を適用するのを防ぐ方法はありますか？それは可能ですか？
W&B コンソールから自動更新をオフにできます。サポートされているバージョンについて質問がある場合は、W&B チームにお問い合わせください。また、W&B は過去 6 か月以内にリリースされたプラットフォームバージョンをサポートしていることを確認してください。W&B は定期的なアップグレードを推奨しています。
環境がパブリックリポジトリーに接続されていない場合、デプロイメントは機能しますか？
設定が airgapped を true に設定している場合、Kubernetes オペレーターは内部リソースのみを使用し、パブリックリポジトリーに接続しようとしません。
5.1.2.3 - パブリック クラウドにインストールする
5.1.2.3.1 - AWS に W&B プラットフォーム をデプロイ
W&B サーバーの AWS 上でのホスティング。
W&B は AWS 上にプラットフォームをデプロイするために W&B サーバー AWS Terraform モジュール の使用を推奨しています。
始める前に、W&B は Terraform が 状態ファイル を保存するための利用可能なリモートバックエンド を選択することを推奨します。
状態ファイルは、全てのコンポーネントを再作成せずに、アップグレードを展開したりデプロイメントに変更を加えるために必要なリソースです。
Terraform モジュールは以下の 必須 コンポーネントをデプロイします：
ロードバランサー
AWS アイデンティティ & アクセスマネジメント (IAM)
AWS キーマネジメントシステム (KMS)
Amazon Aurora MySQL
Amazon VPC
Amazon S3
Amazon Route53
Amazon Certificate Manager (ACM)
Amazon Elastic Load Balancing (ALB)
Amazon Secrets Manager
他のデプロイメントオプションには、以下のオプションコンポーネントを含めることもできます：
前提条件の許可
Terraform を実行するアカウントは、イントロダクションで説明されたすべてのコンポーネントを作成できる必要があり、IAM ポリシー と IAM ロール を作成し、リソースにロールを割り当てる許可が必要です。
一般的なステップ
このトピックのステップは、このドキュメントでカバーされる任意のデプロイメントオプションに共通です。
開発環境を準備します。
Terraform をインストールします。W&B はバージョンコントロール用の Git リポジトリを作成することを推奨します。
terraform.tfvars ファイルを作成します。
tfvars ファイルの内容はインストールタイプに応じてカスタマイズできますが、推奨される最低限の内容は以下の例のようになります。
namespace = "wandb"
license = "xxxxxxxxxxyyyyyyyyyyyzzzzzzz"
subdomain = "wandb-aws"
domain_name = "wandb.ml"
zone_id = "xxxxxxxxxxxxxxxx"
allowed_inbound_cidr = [ "0.0.0.0/0" ]
allowed_inbound_ipv6_cidr = [ "::/0" ]
eks_cluster_version = "1.29"
変数をデプロイ前に tfvars ファイルで定義してください。namespace 変数は Terraform によって作成される全てのリソースのプレフィックスとして使用される文字列です。
subdomain と domain の組み合わせにより W&B が設定される FQDN が形成されます。上記の例では、W&B の FQDN は wandb-aws.wandb.ml となり、FQDN 記録が作成される DNS zone_id になります。
allowed_inbound_cidr と allowed_inbound_ipv6_cidr も設定が必要です。このモジュールでは、これは必須の入力です。進行例では、W&B インストールへのアクセスを任意のソースから許可します。
versions.tf ファイルを作成します。
このファイルは、AWS に W&B をデプロイするために必要な Terraformおよび Terraform プロバイダーのバージョンを含むものとします。
provider "aws" {
region = "eu-central-1"
default_tags {
tags = {
GithubRepo = "terraform-aws-wandb"
GithubOrg = "wandb"
Enviroment = "Example"
Example = "PublicDnsExternal"
}
}
}
AWS プロバイダーを設定するには Terraform 公式ドキュメント を参照してください。
オプションですが強く推奨されるのは、このドキュメントの最初で触れられているリモートバックエンド設定 を追加することです。
variables.tf ファイルを作成します。
terraform.tfvars で設定されたオプションごとに、Terraform は対応する変数宣言を必要とします。
variable "namespace" {
type = string
description = "リソースに使用される名前のプレフィックス"
}
variable "domain_name" {
type = string
description = "インスタンスにアクセスするために使用されるドメイン名。"
}
variable "subdomain" {
type = string
default = null
description = "Weights & Biases UI にアクセスするためのサブドメイン。"
}
variable "license" {
type = string
}
variable "zone_id" {
type = string
description = "Weights & Biases サブドメインを作成するためのドメイン。"
}
variable "allowed_inbound_cidr" {
description = "wandb-server にアクセスを許可される CIDR。"
nullable = false
type = list(string)
}
variable "allowed_inbound_ipv6_cidr" {
description = "wandb-server にアクセスを許可される CIDR。"
nullable = false
type = list(string)
}
variable "eks_cluster_version" {
description = "EKS クラスター用の Kubernetes バージョン"
nullable = false
type = string
}
推奨されるデプロイメントオプション
これは、全ての 必須 コンポーネントを作成し、最新バージョンの W&B を Kubernetes クラスター にインストールする最も簡単なデプロイメントオプションの設定です。
main.tf を作成します。
一般的なステップ で作成したファイルと同じディレクトリに、以下の内容を持つ main.tf ファイルを作成してください。
module "wandb_infra" {
source = "wandb/wandb/aws"
version = "~>7.0"
namespace = var.namespace
domain_name = var.domain_name
subdomain = var.subdomain
zone_id = var.zone_id
allowed_inbound_cidr = var.allowed_inbound_cidr
allowed_inbound_ipv6_cidr = var.allowed_inbound_ipv6_cidr
public_access = true
external_dns = true
kubernetes_public_access = true
kubernetes_public_access_cidrs = ["0.0.0.0/0"]
eks_cluster_version = var.eks_cluster_version
}
data "aws_eks_cluster" "eks_cluster_id" {
name = module.wandb_infra.cluster_name
}
data "aws_eks_cluster_auth" "eks_cluster_auth" {
name = module.wandb_infra.cluster_name
}
provider "kubernetes" {
host = data.aws_eks_cluster.eks_cluster_id.endpoint
cluster_ca_certificate = base64decode(data.aws_eks_cluster.eks_cluster_id.certificate_authority.0.data)
token = data.aws_eks_cluster_auth.eks_cluster_auth.token
}
provider "helm" {
kubernetes {
host = data.aws_eks_cluster.eks_cluster_id.endpoint
cluster_ca_certificate = base64decode(data.aws_eks_cluster.eks_cluster_id.certificate_authority.0.data)
token = data.aws_eks_cluster_auth.eks_cluster_auth.token
}
}
output "url" {
value = module.wandb_infra.url
}
output "bucket" {
value = module.wandb_infra.bucket_name
}
W&B をデプロイします。
W&B をデプロイするには、以下のコマンドを実行してください：
terraform init
terraform apply -var-file=terraform.tfvars
REDIS を有効にする
別のデプロイメントオプションでは、Redis を使用して SQL クエリをキャッシュし、実験のメトリクスを読み込む際のアプリケーションの応答をスピードアップさせます。
キャッシュを有効にするには、推奨されるデプロイメント Recommended deployment セクションで説明されている同じ main.tf ファイルに create_elasticache_subnet = true オプションを追加する必要があります。
module "wandb_infra" {
source = "wandb/wandb/aws"
version = "~>7.0"
namespace = var.namespace
domain_name = var.domain_name
subdomain = var.subdomain
zone_id = var.zone_id
**create_elasticache_subnet = true**
}
[...]
メッセージブローカー（キュー）を有効にする
デプロイメントオプション3は、外部の メッセージブローカー を有効にすることを目的としています。これはオプションですが、W&B 内にブローカーが埋め込まれているため、これによってパフォーマンスが向上するわけではありません。
AWS リソースが提供するメッセージブローカーは SQS です。これを有効にするには、推奨されるデプロイメント Recommended deployment セクションで説明されている同じ main.tf に use_internal_queue = falseオプションを追加する必要があります。
module "wandb_infra" {
source = "wandb/wandb/aws"
version = "~>7.0"
namespace = var.namespace
domain_name = var.domain_name
subdomain = var.subdomain
zone_id = var.zone_id
**use_internal_queue = false**
[...]
}
その他のデプロイメントオプション
同じファイルにすべての設定を追加することで、これらの3つのデプロイメントオプションを組み合わせることができます。 Terraform Module は、標準オプションと デプロイメント - 推奨 に見つかる最小限の構成と共に組み合わせることができるいくつかのオプションを提供します。
手動設定
Amazon S3 バケットを W&B のファイルストレージバックエンドとして使用する場合は：
バケットと、バケットからのオブジェクト作成通知を受け取るように設定された SQS キューを作成する必要があります。インスタンスにはこのキューを読み取る権限が必要です。
S3 バケットとバケット通知の作成
以下の手順を実行して Amazon S3 バケットを作成し、バケット通知を有効化します。
AWS コンソールの Amazon S3 に移動します。
バケットを作成 を選択します。詳細設定 の中で、イベント セクション内の 通知を追加 を選択します。すべてのオブジェクト作成イベントを、先に設定した SQS キューに送信するように構成します。
CORS アクセスを有効にします。あなたの CORS 設定は以下のようになるはずです：
<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
<AllowedOrigin>http://YOUR-W&B-SERVER-IP</AllowedOrigin>
<AllowedMethod>GET</AllowedMethod>
<AllowedMethod>PUT</AllowedMethod>
<AllowedHeader>*</AllowedHeader>
</CORSRule>
</CORSConfiguration>
SQS キューの作成
以下の手順に従って SQS キューを作成します：
AWS コンソールの Amazon SQS に移動します。
キューの作成 を選択します。詳細 セクションから 標準 キュータイプを選択します。アクセスポリシーセクション内で、以下の主体に許可を追加します：
SendMessageReceiveMessageChangeMessageVisibilityDeleteMessageGetQueueUrl
また、アクセスポリシー セクションで、高度なアクセスポリシーを追加することもできます。例えば、Amazon SQS へのアクセスを声明するポリシーは以下のようになります：
{
"Version" : "2012-10-17" ,
"Statement" : [
{
"Effect" : "Allow" ,
"Principal" : "*" ,
"Action" : ["sqs:SendMessage" ],
"Resource" : "<sqs-queue-arn>" ,
"Condition" : {
"ArnEquals" : { "aws:SourceArn" : "<s3-bucket-arn>" }
}
}
]
}
W&B を実行するノードへの権限付与
W&B サーバーが実行されているノードは、Amazon S3 および Amazon SQS へのアクセスを許可するように設定されている必要があります。選択したサーバーデプロイメントの種類に応じて、以下のポリシーステートメントをノードロールに追加する必要があります：
{
"Statement" :[
{
"Sid" :"" ,
"Effect" :"Allow" ,
"Action" :"s3:*" ,
"Resource" :"arn:aws:s3:::<WANDB_BUCKET>"
},
{
"Sid" :"" ,
"Effect" :"Allow" ,
"Action" :[
"sqs:*"
],
"Resource" :"arn:aws:sqs:<REGION>:<ACCOUNT>:<WANDB_QUEUE>"
}
]
}
W&B サーバーの設定
最後に、W&B サーバーを設定します。
W&B 設定ページに移動: http(s)://YOUR-W&B-SERVER-HOST/system-admin.
**外部ファイルストレージバックエンド使用 オプションを有効化
以下の形式であなたの Amazon S3 バケット、リージョン、および Amazon SQS キューに関する情報を提供します：
ファイルストレージバケット : s3://<bucket-name>ファイルストレージリージョン (AWS のみ) : <region>通知サブスクリプション : sqs://<queue-name>
設定の更新 を選択して新しい設定を適用します。
W&B のバージョンをアップグレードする
W&B を更新するための手順をここに従ってください：
wandb_app モジュール内の設定に wandb_version を追加します。アップグレード先の W&B のバージョンを指定します。例えば、次の行は W&B バージョン 0.48.1 を指定します：
module "wandb_app" {
source = "wandb/wandb/kubernetes"
version = "~>1.0"
license = var.license
wandb_version = "0.48.1"
または、wandb_version を terraform.tfvars に追加して、同じ名前の変数を作成し、リテラル値の代わりに var.wandb_version を使用することもできます。
設定を更新したら、推奨デプロイメントセクション で説明されている手順を完了します。
このセクションは、terraform-aws-wandb モジュールを使用して、プレオペレーター 環境から ポストオペレーター 環境へのアップグレードに必要な手順を詳細に説明します。
Kubernetes
オペレーター パターンへの移行は、W&B アーキテクチャーにとって必要です。アーキテクチャー変更の詳細な説明については
このセクション を参照してください。
アーキテクチャーのビフォーアフター
以前は、W&B アーキテクチャは以下のように使用されていました：
module "wandb_infra" {
source = "wandb/wandb/aws"
version = "1.16.10"
...
}
インフラストラクチャーを管理するために
そしてこのモジュールで W&B サーバーをデプロイしていました：
module "wandb_app" {
source = "wandb/wandb/kubernetes"
version = "1.12.0"
}
移行後、アーキテクチャーは以下のように使用されます：
module "wandb_infra" {
source = "wandb/wandb/aws"
version = "4.7.2"
...
}
これにより、インフラストラクチャーと W&B サーバーの Kubernetes クラスターへのインストールの両方を管理し、post-operator.tf で module "wandb_app" は不要となります。
このアーキテクチャーの変更により、OpenTelemetry、Prometheus、HPAs、Kafka、およびイメージの更新などの追加機能を、SRE/インフラストラクチャーチームによる手動の Terraform 操作なしで使用できるようになります。
W&B プレオペレーターの基本インストールを開始するには、post-operator.tf に .disabled ファイル拡張子が付いていることを確認し、pre-operator.tf が有効であることを確認してください（.disabled 拡張子が付いていないもの）。これらのファイルはこちら で確認できます。
前提条件
移行プロセスを開始する前に、次の前提条件が満たされていることを確認してください：
アウトゴーイング接続 : デプロイメントはエアギャップされていない必要があります。リリース チャンネル deploy.wandb.ai へのアクセスが必要です。AWS 資格情報 : AWS リソースと対話するために適切に構成された AWS 資格情報が必要です。Terraform のインストール : 最新バージョンの Terraform がシステムにインストールされている必要があります。Route53 ホステッドゾーン : アプリケーションが提供されるドメインに対応した既存の Route53 ホステッドゾーン。プレオペレーターTerraformファイル : pre-operator.tf と pre-operator.tfvars のような関連変数ファイルが正しく設定されていることを確認してください。
プリアペレーター セットアップ
プレオペレーター設定の構成を初期化および適用するには、次の Terraform コマンドを実行します：
terraform init -upgrade
terraform apply -var-file= ./pre-operator.tfvars
pre-operator.tf は次のようになっています：
namespace = "operator-upgrade"
domain_name = "sandbox-aws.wandb.ml"
zone_id = "Z032246913CW32RVRY0WU"
subdomain = "operator-upgrade"
wandb_license = "ey..."
wandb_version = "0.51.2"
pre-operator.tf の構成は二つのモジュールを呼び出します：
module "wandb_infra" {
source = "wandb/wandb/aws"
version = "1.16.10"
...
}
このモジュールはインフラストラクチャーを起動します。
module "wandb_app" {
source = "wandb/wandb/kubernetes"
version = "1.12.0"
}
このモジュールはアプリケーションをデプロイします。
ポストオペレーター設定
pre-operator.tf に .disabled 拡張子が付いていること、そして post-operator.tf がアクティブであることを確認してください。
post-operator.tfvars には追加の変数が含まれています：
...
# wandb_version = "0.51.2" はリリースチャンネル経由で管理されるか、ユーザースペックで設定されます。
# アップグレードのための必須オペレーター変数：
size = "small"
enable_dummy_dns = true
enable_operator_alb = true
custom_domain_filter = "sandbox-aws.wandb.ml"
以下のコマンドを実行してポストオペレーター設定を初期化および適用します：
terraform init -upgrade
terraform apply -var-file= ./post-operator.tfvars
計画および適用手順は、次のリソースを更新します：
actions :
create :
- aws_efs_backup_policy.storage_class
- aws_efs_file_system.storage_class
- aws_efs_mount_target.storage_class["0"]
- aws_efs_mount_target.storage_class["1"]
- aws_eks_addon.efs
- aws_iam_openid_connect_provider.eks
- aws_iam_policy.secrets_manager
- aws_iam_role_policy_attachment.ebs_csi
- aws_iam_role_policy_attachment.eks_efs
- aws_iam_role_policy_attachment.node_secrets_manager
- aws_security_group.storage_class_nfs
- aws_security_group_rule.nfs_ingress
- random_pet.efs
- aws_s3_bucket_acl.file_storage
- aws_s3_bucket_cors_configuration.file_storage
- aws_s3_bucket_ownership_controls.file_storage
- aws_s3_bucket_server_side_encryption_configuration.file_storage
- helm_release.operator
- helm_release.wandb
- aws_cloudwatch_log_group.this[0]
- aws_iam_policy.default
- aws_iam_role.default
- aws_iam_role_policy_attachment.default
- helm_release.external_dns
- aws_default_network_acl.this[0]
- aws_default_route_table.default[0]
- aws_iam_policy.default
- aws_iam_role.default
- aws_iam_role_policy_attachment.default
- helm_release.aws_load_balancer_controller
update_in_place :
- aws_iam_policy.node_IMDSv2
- aws_iam_policy.node_cloudwatch
- aws_iam_policy.node_kms
- aws_iam_policy.node_s3
- aws_iam_policy.node_sqs
- aws_eks_cluster.this[0]
- aws_elasticache_replication_group.default
- aws_rds_cluster.this[0]
- aws_rds_cluster_instance.this["1"]
- aws_default_security_group.this[0]
- aws_subnet.private[0]
- aws_subnet.private[1]
- aws_subnet.public[0]
- aws_subnet.public[1]
- aws_launch_template.workers["primary"]
destroy :
- kubernetes_config_map.config_map
- kubernetes_deployment.wandb
- kubernetes_priority_class.priority
- kubernetes_secret.secret
- kubernetes_service.prometheus
- kubernetes_service.service
- random_id.snapshot_identifier[0]
replace :
- aws_autoscaling_attachment.autoscaling_attachment["primary"]
- aws_route53_record.alb
- aws_eks_node_group.workers["primary"]
以下のような結果が表示されるはずです：
post-operator.tf では一つの以下があります：
module "wandb_infra" {
source = "wandb/wandb/aws"
version = "4.7.2"
...
}
ポストオペレーター構成の変更：
必要なプロバイダーの更新 : required_providers.aws.version を 3.6 から 4.0 に変更し、プロバイダー互換性を確保します。DNS およびロードバランサーの設定 : enable_dummy_dns および enable_operator_alb を統合して、DNS レコードおよび AWS ロードバランサー設定を Ingress 経由で管理します。ライセンスおよびサイズ構成 : 新しいオペレーション要件に合わせて、license および size パラメーターを直接 wandb_infra モジュールに転送します。カスタムドメインの処理 : 必要に応じて、custom_domain_filter を使用して kube-system 名前空間内の外部 DNS ポッドログをチェックし、DNS 問題のトラブルシューティングを行います。Helmプロバイダー構成 : 効果的に Kubernetes リソースを管理するためにHelm プロバイダーを有効にし、構成します：
provider "helm" {
kubernetes {
host = data .aws_eks_cluster .app_cluster .endpoint
cluster_ca_certificate = base64decode (data .aws_eks_cluster .app_cluster .certificate_authority [0 ].data )
token = data .aws_eks_cluster_auth .app_cluster .token
exec {
api_version = "client.authentication.k8s.io/v1beta1"
args = ["eks", "get-token", "--cluster-name" , data .aws_eks_cluster .app_cluster .name ]
command = "aws"
}
}
}
この包括的なセットアップにより、オペレーターモデルによって可能になった新しい効率性と機能を活用しながら、プレオペレーターからポストオペレーター構成への円滑な移行が可能になります。
5.1.2.3.2 - W&B プラットフォームを GCP にデプロイする
GCP で W&B サーバー をホスティングする。
W&B Server のセルフマネージドを選択した場合、W&B は W&B Server GCP Terraform Module を使用して GCP 上にプラットフォームをデプロイすることを推奨しています。
このモジュールのドキュメントは詳細で、使用可能なすべてのオプションが含まれています。
始める前に、Terraform 用の リモートバックエンド のいずれかを選択し、ステートファイル を保存することをお勧めします。
ステートファイルは、コンポーネントを再作成することなく、アップグレードを展開したり、デプロイメントに変更を加えたりするために必要なリソースです。
Terraform モジュールは以下の 必須 コンポーネントをデプロイします：
VPC
Cloud SQL for MySQL
Cloud Storage バケット
Google Kubernetes Engine
KMS 暗号キー
ロードバランサ
他のデプロイメントオプションには次のオプションコンポーネントが含まれることがあります：
Redis のためのメモリストア
Pub/Sub メッセージシステム
事前要件の許可
Terraform を実行するアカウントには、使用される GCP プロジェクトにおいて roles/owner の役割が必要です。
一般的な手順
このトピックの手順は、このドキュメントでカバーされている任意のデプロイメントオプションに共通です。
開発環境を準備します。
Terraform をインストールします。使用するコードを含む Git リポジトリを作成することをお勧めしますが、ファイルをローカルに保持することもできます。
Google Cloud Console でプロジェクトを作成します。GCP に認証します（gcloud をインストール しておくことを確認してください）
gcloud auth application-default login
terraform.tfvars ファイルを作成します。
tvfars ファイルの内容はインストールタイプに応じてカスタマイズできますが、最低限の推奨事項は以下の例のようになります。
project_id = "wandb-project"
region = "europe-west2"
zone = "europe-west2-a"
namespace = "wandb"
license = "xxxxxxxxxxyyyyyyyyyyyzzzzzzz"
subdomain = "wandb-gcp"
domain_name = "wandb.ml"
ここで定義する変数はデプロイメントの前に決定する必要があります。namespace 変数は、Terraform によって作成されたすべてのリソースにプレフィックスとして付ける文字列になります。
subdomain と domain の組み合わせが W&B が設定される FQDN を形成します。上記の例では、W&B FQDN は wandb-gcp.wandb.ml となります。
variables.tf ファイルを作成します。
terraform.tfvars で設定されたすべてのオプションに対して、Terraform は対応する変数宣言を求めます。
variable "project_id" {
type = string
description = "Project ID"
}
variable "region" {
type = string
description = "Google region"
}
variable "zone" {
type = string
description = "Google zone"
}
variable "namespace" {
type = string
description = "Namespace prefix used for resources"
}
variable "domain_name" {
type = string
description = "Domain name for accessing the Weights & Biases UI."
}
variable "subdomain" {
type = string
description = "Subdomain for access the Weights & Biases UI."
}
variable "license" {
type = string
description = "W&B License"
}
デプロイメント - 推奨 (~20 分)
これは Mandatory コンポーネントをすべて作成し、Kubernetes Cluster に W&B の最新バージョンをインストールする最も単純なデプロイメントオプション設定です。
main.tf を作成します。
一般的な手順 でファイルを作成したのと同じディレクトリに、次の内容の main.tf ファイルを作成します：
provider "google" {
project = var.project_id
region = var.region
zone = var.zone
}
provider "google-beta" {
project = var.project_id
region = var.region
zone = var.zone
}
data "google_client_config" "current" {}
provider "kubernetes" {
host = "https://${module.wandb.cluster_endpoint}"
cluster_ca_certificate = base64decode(module.wandb.cluster_ca_certificate)
token = data.google_client_config.current.access_token
}
# 必須サービスをすべて起動
module "wandb" {
source = "wandb/wandb/google"
version = "~> 5.0"
namespace = var.namespace
license = var.license
domain_name = var.domain_name
subdomain = var.subdomain
}
# プロビジョニングされた IP アドレスで DNS を更新する必要があります
output "url" {
value = module.wandb.url
}
output "address" {
value = module.wandb.address
}
output "bucket_name" {
value = module.wandb.bucket_name
}
W&B をデプロイします。
W&B をデプロイするには、次のコマンドを実行します：
terraform init
terraform apply -var-file=terraform.tfvars
REDIS キャッシュを使用したデプロイメント
別のデプロイメントオプションでは、Redis を使用して SQL クエリをキャッシュし、実験のメトリクスをロードする際のアプリケーションの応答速度を向上させます。
推奨される Deployment option section に示されている同じ main.tf ファイルに create_redis = true のオプションを追加する必要があります。
[...]
module "wandb" {
source = "wandb/wandb/google"
version = "~> 1.0"
namespace = var.namespace
license = var.license
domain_name = var.domain_name
subdomain = var.subdomain
allowed_inbound_cidrs = ["*"]
# Redis を有効化
create_redis = true
}
[...]
外部キューを使用したデプロイメント
デプロイメントオプション 3 は外部の メッセージブローカー を有効化することから成ります。これは W&B が組み込みのブローカーを提供しているため、オプションです。性能改善はもたらしません。
メッセージブローカーを提供する GCP リソースは Pub/Sub であり、これを有効にするには、推奨される Deployment option section に示されている同じ main.tf に use_internal_queue = false のオプションを追加する必要があります。
[...]
module "wandb" {
source = "wandb/wandb/google"
version = "~> 1.0"
namespace = var.namespace
license = var.license
domain_name = var.domain_name
subdomain = var.subdomain
allowed_inbound_cidrs = ["*"]
# Pub/Sub を作成して使用
use_internal_queue = false
}
[...]
その他のデプロイメントオプション
すべてのデプロイメントオプションを組み合わせて、すべての設定を同じファイルに追加することができます。 Terraform Module は、標準のオプションや Deployment - Recommended で見つかる最小限の設定と共に組み合わせることができる複数のオプションを提供しています。
手動設定
GCP ストレージバケットを W&B のファイルストレージバックエンドとして使用するには、以下を作成する必要があります：
PubSub Topic と Subscription の作成
以下の手順に従って、PubSub トピックとサブスクリプションを作成します：
GCP Console 内の Pub/Sub サービスに移動します。
Create Topic を選択してトピックに名前を付けます。ページの下部で、Create subscription を選択します。 Delivery Type が Pull に設定されていることを確認します。
Create をクリックします。
サービスアカウントまたはインスタンスが実行中のアカウントが、このサブスクリプションの pubsub.admin ロールを持っていることを確認します。 詳細については、https://cloud.google.com/pubsub/docs/access-control#console を参照してください。
ストレージバケットの作成
Cloud Storage バケット ページに移動します。Create bucket を選択してバケットに名前を付けます。 Standard の ストレージクラス を選択していることを確認します。
インスタンスが実行中のサービスアカウントまたはアカウントが、以下の条件をすべて満たしていることを確認してください：
前のステップで作成したバケットへのアクセス
このバケットに対する storage.objectAdmin ロール。 詳細については、https://cloud.google.com/storage/docs/access-control/using-iam-permissions#bucket-add を参照してください。
インスタンスは署名付きファイル URL を作成するために GCP で iam.serviceAccounts.signBlob の権限も必要です。 サービスアカウントまたはインスタンスが実行する IAM メンバーに サービスアカウントトークンクリエーター のロールを追加して、権限を有効にします。
CORS アクセスを有効化します。これはコマンドラインのみで実行できます。まず、以下の CORS 設定を含む JSON ファイルを作成します。
cors:
- maxAgeSeconds: 3600
method:
- GET
- PUT
origin:
- '<YOUR_W&B_SERVER_HOST>'
responseHeader:
- Content-Type
ここでの origin の値のスキーム、ホスト、およびポートが正確に一致していることを確認してください。
gcloud が正しくインストールされ、適切な GCP プロジェクトにログインしていることを確認してください。次に、以下を実行します：
gcloud storage buckets update gs://<BUCKET_NAME> --cors-file= <CORS_CONFIG_FILE>
PubSub 通知の作成
コマンドラインで以下の手順に従って、ストレージバケットから Pub/Sub トピックへの通知ストリームを作成します。
通知ストリームを作成するには CLI を使用する必要があります。gcloud がインストールされていることを確認してください。
GCP プロジェクトにログインします。
ターミナルで次の操作を実行します：
gcloud pubsub topics list # トピックの名前を参照用にリスト表示
gcloud storage ls # バケットの名前を参照用にリスト表示
# バケット通知を作成
gcloud storage buckets notifications create gs://<BUCKET_NAME> --topic= <TOPIC_NAME>
Cloud Storage のウェブサイトにさらに参考資料があります。
W&B サーバーの設定
最後に、W&B の System Connections ページに http(s)://YOUR-W&B-SERVER-HOST/console/settings/system を開きます。
プロバイダーとして Google Cloud Storage (gcs) を選択します。
GCS バケットの名前を提供します。
設定を更新 を押して、新しい設定を適用します。
W&B サーバーのアップグレード
ここに示された手順に従って W&B を更新します：
あなたの wandb_app モジュールに wandb_version を追加します。アップグレードしたい W&B のバージョンを指定します。例えば、以下の行は W&B バージョン 0.48.1 を指定します：
module "wandb_app" {
source = "wandb/wandb/kubernetes"
version = "~>5.0"
license = var.license
wandb_version = "0.58.1"
代わりに、wandb_version を terraform.tfvars に追加し、同じ名前の変数を作成して、リテラル値の代わりに var.wandb_version を使用することができます。
設定を更新した後、Deployment option section に記載されている手順を完了します。
5.1.2.3.3 - Azureで W&B プラットフォーム を展開する
Azure で W&B サーバー をホスティングする。
自己管理の W&B サーバーを選択した場合、W&B は W&B Server Azure Terraform Module を使用して Azure 上でプラットフォームをデプロイすることをお勧めします。
このモジュールのドキュメントは詳細で、使用可能なオプションがすべて含まれています。本書では、一部のデプロイメント オプションについて説明します。
開始する前に、Terraform の State File を保存するために利用可能な リモート バックエンド のいずれかを選択することをお勧めします。
State File は、アップグレードを展開したり、すべてのコンポーネントを再作成することなくデプロイメントの変更を行ったりするために必要なリソースです。
Terraform モジュールは、次の「必須」コンポーネントをデプロイします。
Azure リソース グループ
Azure 仮想ネットワーク (VPC)
Azure MySQL Flexible サーバー
Azure ストレージ アカウント & Blob ストレージ
Azure Kubernetes サービス
Azure アプリケーション ゲートウェイ
その他のデプロイメント オプションには、次のオプション コンポーネントが含まれる場合があります。
Azure Cache for Redis
Azure Event Grid
前提条件の権限 AzureRM プロバイダーを設定する最も簡単な方法は Azure CLI 経由ですが、Azure サービス プリンシパル を使用した自動化の場合も便利です。 使用される認証メソッドに関わらず、Terraform を実行するアカウントはイントロダクションで説明されているすべてのコンポーネントを作成できる必要があります。
一般的な手順
このトピックの手順は、このドキュメントでカバーされているいずれのデプロイメント オプションにも共通しています。
開発環境を準備します。
Terraform をインストールします。使用するコードで Git リポジトリを作成することをお勧めしますが、ファイルをローカルに保持することもできます。
terraform.tfvars ファイルを作成しますtvfars ファイルの内容はインストール タイプに応じてカスタマイズできますが、最低限の推奨事項は以下の例のようになります。
namespace = "wandb"
wandb_license = "xxxxxxxxxxyyyyyyyyyyyzzzzzzz"
subdomain = "wandb-aws"
domain_name = "wandb.ml"
location = "westeurope"
ここで定義されている変数は、デプロイメントの前に決定する必要があります。namespace 変数は、Terraform によって作成されるすべてのリソースの接頭辞となる文字列です。
subdomain と domain の組み合わせは、W&B が設定される FQDN を形成します。上記の例では、W&B の FQDN は wandb-aws.wandb.ml となり、FQDN レコードが作成される DNS zone_id が指定されます。
versions.tf ファイルを作成します
terraform {
required_version = "~> 1.3"
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "~> 3.17"
}
}
}
AWS プロバイダーを設定するには、Terraform Official Documentation を参照してください。
また、強く推奨される のは、ドキュメントの冒頭で言及された リモート バックエンド設定 を追加することです。
ファイル variables.tf を作成します。terraform.tfvars で構成されたすべてのオプションについて、Terraform は対応する変数宣言を必要とします。
variable "namespace" {
type = string
description = "リソースの接頭辞に使用される文字列。"
}
variable "location" {
type = string
description = "Azure リソース グループの場所"
}
variable "domain_name" {
type = string
description = "Weights & Biases UI へのアクセス用ドメイン。"
}
variable "subdomain" {
type = string
default = null
description = "Weights & Biases UI へのアクセス用サブドメイン。デフォルトは Route53 Route でレコードを作成します。"
}
variable "license" {
type = string
description = "あなたの wandb/local ライセンス"
}
推奨デプロイメント
これは、すべての「必須」コンポーネントを作成し、最新バージョンの W&B を Kubernetes クラスター にインストールする最も簡単なデプロイメント オプション設定です。
main.tf を作成しますGeneral Steps で作成したファイルと同じディレクトリに、次の内容で main.tf ファイルを作成します：
provider "azurerm" {
features {}
}
provider "kubernetes" {
host = module.wandb.cluster_host
cluster_ca_certificate = base64decode( module.wandb.cluster_ca_certificate)
client_key = base64decode( module.wandb.cluster_client_key)
client_certificate = base64decode( module.wandb.cluster_client_certificate)
}
provider "helm" {
kubernetes {
host = module.wandb.cluster_host
cluster_ca_certificate = base64decode( module.wandb.cluster_ca_certificate)
client_key = base64decode( module.wandb.cluster_client_key)
client_certificate = base64decode( module.wandb.cluster_client_certificate)
}
}
# 必要なすべてのサービスをスピンアップ
module "wandb" {
source = "wandb/wandb/azurerm"
version = "~> 1.2"
namespace = var.namespace
location = var.location
license = var.license
domain_name = var.domain_name
subdomain = var.subdomain
deletion_protection = false
tags = {
"Example" : "PublicDns"
}
}
output "address" {
value = module.wandb.address
}
output "url" {
value = module.wandb.url
}
W&B にデプロイ W&B にデプロイするには、次のコマンドを実行します：
terraform init
terraform apply -var-file=terraform.tfvars
REDIS キャッシュを使用したデプロイメント
別のデプロイメント オプションとして、Redis を使用して SQL クエリをキャッシュし、実験のメトリクスを読み込む際のアプリケーション応答を高速化します。
キャッシュを有効にするには、recommended deployment(#recommended-deployment) で使用したのと同じ main.tf ファイルに create_redis = true オプションを追加する必要があります。
# 必要なすべてのサービスをスピンアップ
module "wandb" {
source = "wandb/wandb/azurerm"
version = "~> 1.2"
namespace = var.namespace
location = var.location
license = var.license
domain_name = var.domain_name
subdomain = var.subdomain
create_redis = true # Redis を作成
[ ...]
外部キューを使用したデプロイメント
デプロイメント オプション 3 は、外部の message broker を有効にすることです。 これはオプションであり、W&B にはブローカーが組み込まれているため、パフォーマンスの向上はもたらされません。
message broker を提供する Azure リソースは Azure Event Grid であり、有効にするには、recommended deployment(#recommended-deployment) で使用したのと同じ main.tf に use_internal_queue = false オプションを追加する必要があります。
# 必要なすべてのサービスをスピンアップ
module "wandb" {
source = "wandb/wandb/azurerm"
version = "~> 1.2"
namespace = var.namespace
location = var.location
license = var.license
domain_name = var.domain_name
subdomain = var.subdomain
use_internal_queue = false # Azure Event Grid を有効にする
[ ...]
}
その他のデプロイメント オプション
3 つのデプロイメント オプションすべてを組み合わせて、すべての構成を同じファイルに追加できます。
Teraform モジュール は、標準オプションや recommended deployment に見られる最小構成と組み合わせることができるいくつかのオプションを提供します。
5.1.2.4 - W&B プラットフォームをオンプレミスで展開する
オンプレミス インフラストラクチャーでの W&B Server のホスティング
関連する質問については、W&B セールスチームにお問い合わせください: contact@wandb.com .
インフラストラクチャーガイドライン
W&B のデプロイメントを開始する前に、特にインフラストラクチャー要件を確認するために、リファレンスアーキテクチャー を参照してください。
MySQL データベース
W&B は MySQL 5.7 の使用を推奨しません。MySQL 5.7 を使用している場合は、最新バージョンの W&B Server との互換性を最大限にするために MySQL 8 へ移行してください。W&B Server は現在、MySQL 8 バージョン 8.0.28 以降のみをサポートしています。
スケーラブルな MySQL データベースの運用を簡素化するエンタープライズサービスがいくつかあります。W&B は次のソリューションのいずれかを検討することを推奨します:
https://www.percona.com/software/mysql-database/percona-server
https://github.com/mysql/mysql-operator
以下の条件を満たすようにしてください。W&B Server MySQL 8.0 を実行する場合、または MySQL 5.7 から 8.0 へのアップグレード時に以下を行います:
binlog_format = 'ROW'
innodb_online_alter_log_max_size = 268435456
sync_binlog = 1
innodb_flush_log_at_trx_commit = 1
binlog_row_image = 'MINIMAL'
MySQL 8.0 で sort_buffer_size の扱いにいくつか変更があったため、デフォルトの値である 262144 から sort_buffer_size パラメータを更新する必要があるかもしれません。W&B と MySQL が効率よく連携することを保証するために、値を 67108864 (64MiB) に設定することを推奨します。MySQL はこの設定を v8.0.28 からサポートしています。
データベースに関する考慮事項
次の SQL クエリを使用してデータベースとユーザーを作成します。SOME_PASSWORD を希望のパスワードに置き換えてください:
CREATE USER 'wandb_local' @ '%' IDENTIFIED BY 'SOME_PASSWORD' ;
CREATE DATABASE wandb_local CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
GRANT ALL ON wandb_local.* TO 'wandb_local' @ '%' WITH GRANT OPTION ;
これは SSL 証明書が信頼されている場合にのみ機能します。W&B は自己署名証明書をサポートしていません。
パラメータグループ設定
データベースのパフォーマンスを最適化するために、次のパラメータグループが設定されていることを確認してください:
binlog_format = 'ROW'
innodb_online_alter_log_max_size = 268435456
sync_binlog = 1
innodb_flush_log_at_trx_commit = 1
binlog_row_image = 'MINIMAL'
sort_buffer_size = 67108864
オブジェクトストレージ
オブジェクトストアは、Minio クラスター または署名付き URL をサポートする Amazon S3 互換のオブジェクトストアでホストできます。次のスクリプト を実行して、オブジェクトストアが署名付き URL をサポートしているか確認してください。
さらに、次の CORS ポリシーをオブジェクトストアに適用する必要があります。
<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns= "http://s3.amazonaws.com/doc/2006-03-01/" >
<CORSRule>
<AllowedOrigin> http://YOUR-W& B-SERVER-IP</AllowedOrigin>
<AllowedMethod> GET</AllowedMethod>
<AllowedMethod> PUT</AllowedMethod>
<AllowedMethod> HEAD</AllowedMethod>
<AllowedHeader> *</AllowedHeader>
</CORSRule>
</CORSConfiguration>
Amazon S3 互換のオブジェクトストアに接続する際、自分の資格情報を接続文字列で指定できます。たとえば、次のように指定します:
s3://$ACCESS_KEY:$SECRET_KEY@$HOST/$BUCKET_NAME
オブジェクトストア用の信頼された SSL 証明書を設定している場合、W&B が TLS 経由でのみ接続するように指示することもできます。それには、URL に tls クエリパラメータを追加します。たとえば、次の URL 例は、Amazon S3 URI に TLS クエリパラメータを追加する方法を示しています:
s3://$ACCESS_KEY:$SECRET_KEY@$HOST/$BUCKET_NAME?tls=true
これは SSL 証明書が信頼されている場合にのみ機能します。W&B は自己署名証明書をサポートしていません。
サードパーティのオブジェクトストアを使用している場合、BUCKET_QUEUE を internal:// に設定します。これにより、外部の SQS キューやそれに相当するものに依存せずに、W&B サーバーがすべてのオブジェクト通知を内部で管理できるようになります。
独自のオブジェクトストアを運用する際に考慮すべき最も重要なことは次のとおりです:
ストレージ容量とパフォーマンス 。磁気ディスクを使用しても構いませんが、これらのディスクの容量を監視している必要があります。平均的な W&B の使用量は 10 ギガバイトから 100 ギガバイトに達します。大量使用はペタバイトのストレージ消費を引き起こす可能性があります。フォールトトレランス 。最低限、オブジェクトを保存する物理ディスクは RAID アレイにあるべきです。minio を使用する場合は、分散モード での実行を検討してください。可用性 。ストレージが利用可能であることを確認するために監視を設定する必要があります。
独自のオブジェクトストレージサービスを運用するためのエンタープライズ代替策は多数存在します:
https://aws.amazon.com/s3/outposts/ https://www.netapp.com/data-storage/storagegrid/
MinIO 設定
minio を使用する場合、次のコマンドを実行してバケットを作成できます。
mc config host add local http://$MINIO_HOST:$MINIO_PORT " $MINIO_ACCESS_KEY" " $MINIO_SECRET_KEY" --api s3v4
mc mb --region= us-east1 local/local-files
W&B Server アプリケーションを Kubernetes にデプロイ
公式の W&B Helm チャートを使用することが推奨されるインストール方法です。こちらのセクション に従って W&B Server アプリケーションをデプロイしてください。
OpenShift
W&B は、OpenShift Kubernetes クラスター 内からの運用をサポートしています。
W&B は公式の W&B Helm チャートでのインストールをお勧めします。
コンテナを非特権ユーザーとして実行
デフォルトでは、コンテナは $UID 999 を使用します。オーケストレーターが非ルートユーザーでのコンテナ実行を要求する場合、$UID >= 100000 そして $GID を 0 に指定します。
W&B はファイルシステム権限が正しく機能するためにルートグループ ($GID=0) として開始する必要があります。
Kubernetes のセキュリティコンテキストの例は次のようになります:
spec:
securityContext:
runAsUser: 100000
runAsGroup: 0
ネットワーキング
ロードバランサー
適切なネットワーク境界でネットワークリクエストを停止するロードバランサーを実行します。
一般的なロードバランサーには以下があります:
Nginx Ingress Istio Caddy Cloudflare Apache HAProxy
機械学習のペイロードを実行するために使用されるすべてのマシンと、Web ブラウザを介してサービスにアクセスするために使用されるデバイスがこのエンドポイントと通信できることを確認してください。
SSL / TLS
W&B Server は SSL を停止しません。信頼されたネットワーク内での SSL 通信がセキュリティポリシーで求められている場合、Istio や サイドカーコンテナ などのツールを使用してください。ロードバランサー自体は有効な証明書で SSL を終了させる必要があります。自己署名証明書はサポートされておらず、ユーザーに多くの問題を引き起こします。可能であれば、Let’s Encrypt のようなサービスを使用してロードバランサーに信頼された証明書を提供することは素晴らしい方法です。Caddy や Cloudflare のようなサービスは SSL を自動的に管理します。
nginx 設定の例
以下は、nginx をリバースプロキシとして使用する例の設定です。
events {}
http {
# If we receive X-Forwarded-Proto, pass it through; otherwise, pass along the
# scheme used to connect to this server
map $http_x_forwarded_proto $proxy_x_forwarded_proto {
default $http_x_forwarded_proto;
'' $scheme;
}
# Also, in the above case, force HTTPS
map $http_x_forwarded_proto $sts {
default '' ;
"https" "max-age=31536000 ; includeSubDomains" ;
}
# If we receive X-Forwarded-Host, pass it though; otherwise, pass along $http_host
map $http_x_forwarded_host $proxy_x_forwarded_host {
default $http_x_forwarded_host;
'' $http_host;
}
# If we receive X-Forwarded-Port, pass it through; otherwise, pass along the
# server port the client connected to
map $http_x_forwarded_port $proxy_x_forwarded_port {
default $http_x_forwarded_port;
'' $server_port;
}
# If we receive Upgrade, set Connection to "upgrade"; otherwise, delete any
# Connection header that may have been passed to this server
map $http_upgrade $proxy_connection {
default upgrade ;
'' close ;
}
server {
listen 443 ssl ;
server_name www.example.com ;
ssl_certificate www.example.com.crt ;
ssl_certificate_key www.example.com.key ;
proxy_http_version 1 .1 ;
proxy_buffering off ;
proxy_set_header Host $http_host;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $proxy_connection;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $proxy_x_forwarded_proto;
proxy_set_header X-Forwarded-Host $proxy_x_forwarded_host;
location / {
proxy_pass http:// $YOUR_UPSTREAM_SERVER_IP:8080/;
}
keepalive_timeout 10 ;
}
}
インストールの確認
W&B Server が正しく設定されていることを確認してください。次のコマンドをターミナルで実行します:
pip install wandb
wandb login --host= https://YOUR_DNS_DOMAIN
wandb verify
開始時に W&B Server にヒットするエラーを表示するためにログファイルを確認してください。次のコマンドを実行します:
kubectl get pods
kubectl logs wandb-XXXXX-XXXXX
エラーが発生した場合は W&B サポートにお問い合わせください。
5.1.2.5 - W&B ライセンスと バージョン を更新する
W&B (Weights & Biases) のバージョンとライセンスを異なるインストールメソッドで更新するためのガイド。
W&B Server の バージョン と ライセンスのアップデートは、W&B Server のインストール方法と同じ方法で行います。次の表に、さまざまな デプロイメント メソッド に基づいたライセンスとバージョンのアップデート方法を示します。
Release Type
Description
Terraform W&B は、クラウド デプロイメント用に 3 つのパブリック Terraform モジュールをサポートしています: AWS , GCP , および Azure 。
Helm 既存の Kubernetes クラスターに W&B をインストールするために Helm Chart を使用できます。
Terraform を使ってライセンスと バージョン を更新します。以下の表に、クラウド プラットフォーム に基づく W&B 管理Terraform モジュールを示します。
まず、お使いの クラウド プロバイダー 用の W&B 管理の Terraform モジュールに移動します。前の表を参照して、クラウド プロバイダー に基づいた適切な Terraform モジュールを見つけてください。
Terraform 設定内で、Terraform wandb_app モジュールの設定で wandb_version と license を更新します:
module "wandb_app" {
source = "wandb/wandb/<cloud-specific-module>"
version = "new_version"
license = "new_license_key" # 新しいライセンス キー
= "new_wandb_version" # 希望する W&B バージョン
}
terraform plan および terraform apply コマンドで Terraform 設定を適用します。
terraform init
terraform apply
(オプション) terraform.tfvars またはその他の .tfvars ファイルを使用する場合。
新しい W&B バージョン と ライセンス キー を指定して terraform.tfvars ファイルを更新または作成します。
terraform plan -var-file= "terraform.tfvars"
設定を適用します。Terraform ワークスペース ディレクトリー で以下を実行します:
terraform apply -var-file= "terraform.tfvars"
Helm を使用してアップデート
Spec を使って W&B をアップデート
Helm チャート *.yaml 設定 ファイルで image.tag および/または license の 値 を変更して新しい バージョン を指定します:
license : 'new_license'
image :
repository : wandb/local
tag : 'new_version'
以下の コマンド で Helm アップグレード を実行します:
helm repo update
helm upgrade --namespace= wandb --create-namespace \
${ chart_version} \
${ wandb_install_spec.yaml}
ライセンスと バージョン を直接アップデート
新しい ライセンス キー と イメージ タグ を 環境 変数として設定します:
export LICENSE= 'new_license'
export TAG= 'new_version'
以下の コマンド で Helm リリース をアップグレードし、新しい 値 を既存の設定とマージします:
helm repo update
helm upgrade --namespace= wandb --create-namespace \
${ chart_version} \
= $LICENSE --set image.tag= $TAG
詳細については、パブリック リポジトリのアップグレード ガイド を参照してください。
管理者 UI を使用してアップデート
この方法は、通常、自己ホスト型 Docker インストール で、環境 変数 を使用して W&B サーバー コンテナ内に設定されていないライセンスを更新する場合にのみ使用されます。
W&B デプロイメント ページ から新しいライセンスを取得し、アップグレードしようとしている デプロイメント に対して正しい組織およびデプロイメント ID と一致することを確認します。W&B 管理者 UI に <host-url>/system-settings でアクセスします。
ライセンス管理セクションに移動します。
新しいライセンスキーを入力し、変更を保存します。
5.1.3 - 専用クラウド
専用クラウドの利用 (シングルテナント SaaS)
W&B 専用クラウドは、シングルテナントで完全に管理されたプラットフォームであり、W&B の AWS、GCP または Azure クラウドアカウントにデプロイされます。各専用クラウドインスタンスは、他の W&B 専用クラウドインスタンスと隔離されたネットワーク、コンピュート、ストレージを持っています。W&B 固有のメタデータとデータは、隔離されたクラウドストレージに保存され、隔離されたクラウドコンピュートサービスを使って処理されます。
W&B 専用クラウドは各クラウドプロバイダーにとって複数の世界各地域で利用可能です
データセキュリティ
セキュアストレージコネクタ を使用して、インスタンスおよびチームレベル で自分のバケット (BYOB) を持ち込むことで、モデル、データセットなどのファイルを保存できます。
W&B マルチテナントクラウドと同様に、複数のチーム用に 1 つのバケットを設定するか、異なるチームに対して別々のバケットを使用することができます。チーム用にセキュアストレージコネクタを設定しない場合、そのデータはインスタンスレベルのバケットに保存されます。
セキュアストレージコネクタを使用した BYOB に加えて、信頼できるネットワーク場所からのみ専用クラウドインスタンスにアクセスを制限するために IP 許可リスト を利用できます。
また、クラウドプロバイダーのセキュア接続ソリューション を使用して、専用クラウドインスタンスにプライベートに接続することもできます。
アイデンティティとアクセス管理 (IAM)
W&B 組織での安全な認証と効果的な認可のためのアイデンティティおよびアクセス管理機能を利用してください。専用クラウドインスタンスの IAM には、次の機能があります:
監視
監査ログ を使用して、チーム内でのユーザー活動を追跡し、企業ガバナンス要件に準拠します。また、専用クラウドインスタンス内の W&B 組織ダッシュボードを使用して、組織の利用状況を確認できます。
メンテナンス
W&B マルチテナントクラウドと同様に、専用クラウドを使用することで、W&B プラットフォームのプロビジョニングやメンテナンスに関するオーバーヘッドやコストを負担することはありません。
専用クラウドで W&B がどのようにアップデートを管理するかを理解するためには、サーバーリリースプロセス を参照してください。
コンプライアンス
W&B 専用クラウドのセキュリティ管理は、定期的に内部および外部で監査されています。セキュリティ評価演習のためのセキュリティとコンプライアンス文書をリクエストするには、W&B セキュリティポータル を参照してください。
移行オプション
セルフマネージドインスタンス またはマルチテナントクラウド から専用クラウドへの移行がサポートされています。
次のステップ
専用クラウドの利用に興味がある場合は、このフォーム を提出してください。
5.1.3.1 - 専用クラウドがサポートされている地域
AWS、GCP、Azure は世界中の複数の場所でクラウドコンピューティングサービスをサポートしています。グローバル地域は、データの居住地やコンプライアンス、レイテンシー、コスト効率などに関連する要件を満たすのに役立ちます。W&B は、Dedicated Cloud のために利用可能な多くのグローバル地域をサポートしています。
ご希望の AWS、GCP、Azure の地域がリストにない場合は、W&B サポートにご連絡ください。W&B は、該当する地域が Dedicated Cloud に必要なすべてのサービスを備えているかどうかを検証し、評価の結果に応じてサポートを優先することができます。
サポートされている AWS 地域
以下の表は、W&B が現在 Dedicated Cloud インスタンスについてサポートしている AWS 地域 の一覧です。
地域の場所
地域名
US East (Ohio)
us-east-2
US East (N. Virginia)
us-east-1
US West (N. California)
us-west-1
US West (Oregon)
us-west-2
Canada (Central)
ca-central-1
Europe (Frankfurt)
eu-central-1
Europe (Ireland)
eu-west-1
Europe (London)
eu-west-2
Europe (Milan)
eu-south-1
Europe (Stockholm)
eu-north-1
Asia Pacific (Mumbai)
ap-south-1
Asia Pacific (Singapore)
ap-southeast-1
Asia Pacific (Sydney)
ap-southeast-2
Asia Pacific (Tokyo)
ap-northeast-1
Asia Pacific (Seoul)
ap-northeast-2
AWS 地域についての詳細は、AWS ドキュメントの Regions, Availability Zones, and Local Zones を参照してください。
AWS 地域を選択する際に考慮すべき要素の概要については、What to Consider when Selecting a Region for your Workloads をご覧ください。
サポートされている GCP 地域
以下の表は、W&B が現在 Dedicated Cloud インスタンスについてサポートしている GCP 地域 の一覧です。
地域の場所
地域名
South Carolina
us-east1
N. Virginia
us-east4
Iowa
us-central1
Oregon
us-west1
Los Angeles
us-west2
Las Vegas
us-west4
Toronto
northamerica-northeast2
Belgium
europe-west1
London
europe-west2
Frankfurt
europe-west3
Netherlands
europe-west4
Sydney
australia-southeast1
Tokyo
asia-northeast1
Seoul
asia-northeast3
GCP 地域についての詳細は、GCP ドキュメントの Regions and zones を参照してください。
サポートされている Azure 地域
以下の表は、W&B が現在 Dedicated Cloud インスタンスについてサポートしている Azure 地域 の一覧です。
地域の場所
地域名
Virginia
eastus
Iowa
centralus
Washington
westus2
California
westus
Canada Central
canadacentral
France Central
francecentral
Netherlands
westeurope
Tokyo, Saitama
japaneast
Seoul
koreacentral
Azure 地域についての詳細は、Azure ドキュメントの Azure geographies を参照してください。
5.1.3.2 - 専用クラウドからデータをエクスポートする
専用クラウドからデータをエクスポートする
もし専用クラウドインスタンスで管理されているすべてのデータをエクスポートしたい場合、W&B SDK APIを使用して、インポートおよびエクスポートAPI を利用して runs、メトリクス、Artifacts などを抽出できます。以下の表は、いくつかの主要なエクスポートユースケースについて説明しています。
専用クラウドで保管されている Artifacts を Secure Storage Connector で管理している場合、W&B SDK APIを使用してアーティファクトをエクスポートする必要はないかもしれません。
大量の runs や Artifacts などがある場合、W&B SDK APIを使用してすべてのデータをエクスポートするのは遅くなる可能性があります。W&Bは、専用クラウドインスタンスを圧迫しないように、適切なサイズのバッチでエクスポートプロセスを実行することを推奨しています。
5.2 - アイデンティティとアクセス管理 (IAM)
W&B プラットフォームには、W&B 内での 3 つの IAM スコープがあります: Organizations 、Teams 、および Projects 。
Organization
Organization は、あなたの W&B アカウントまたはインスタンスのルートスコープです。ユーザー管理、チーム管理、チーム内のプロジェクト管理、使用状況の追跡など、アカウントまたはインスタンス内のすべてのアクションは、このルートスコープのコンテキスト内で行われます。
Multi-tenant Cloud を使用している場合、複数の組織を持っている可能性があります。それぞれが事業部門、個人のユーザー、他社との共同パートナーシップなどに対応する場合があります。
Dedicated Cloud または Self-managed instance を使用している場合、それは1つの組織に対応しています。あなたの会社は、異なる事業部門または部門に対応するために Dedicated Cloud または Self-managed インスタンスを複数持つことができますが、それは業務や部門全体にわたる AI 実践者を管理するためのオプションの方法に過ぎません。
詳細については、Manage organizations を参照してください。
Team
Team は、組織内のサブスコープであり、事業部門、機能、部門、または会社内のプロジェクトチームに対応する場合があります。デプロイメントタイプと価格プランに応じて、組織内に複数のチームを持つことができます。
AI プロジェクトはチームのコンテキスト内で編成されます。チーム内のアクセス制御は、親組織レベルで管理者であるかどうかに関係なく、チーム管理者によって管理されます。
詳細については、Add and manage teams を参照してください。
Project
Project は、特定の目標を持つ実際の AI プロジェクトに対応するチーム内のサブスコープです。チーム内に複数のプロジェクトを持つことができます。各プロジェクトには、誰がプロジェクトにアクセスできるかを決定する公開範囲モードがあります。
各プロジェクトは、Workspaces と Reports で構成され、関連する Artifacts 、Sweeps 、および Automations とリンクされています。
5.2.1 - 認証
5.2.1.1 - SDK でフェデレーテッドアイデンティティを使用する
W&B SDKを使用して、組織の資格情報を使用したサインインにアイデンティティ連携を利用します。W&Bの組織管理者が組織向けにSSOを設定している場合、すでに組織の資格情報を使用してW&BアプリのUIにサインインしています。この意味で、アイデンティティ連携はW&B SDKのためのSSOに似ていますが、JSON Web Tokens (JWTs) を直接使用しています。APIキーの代わりにアイデンティティ連携を使用できます。
RFC 7523 は、SDKを使用したアイデンティティ連携の基盤を形成しています。
アイデンティティ連携は、すべてのプラットフォームタイプの Enterprise プランで Preview として利用可能です - SaaS Cloud、Dedicated Cloud、およびセルフマネージドインスタンス。ご質問がある場合は、W&Bチームにお問い合わせください。
このドキュメントの目的のために、identity provider と JWT issuer という用語は交換可能に使われています。この機能のコンテキストでは、両方とも同じものを指します。
JWTイシュア設定
最初のステップとして、組織管理者はW&B組織とアクセス可能なJWTイシュアの間で連携を設定しなければなりません。
組織ダッシュボードの Settings タブに移動します。
Authentication オプションで Set up JWT Issuer をクリックします。テキストボックスにJWTイシュアのURLを追加し、Create を押します。
W&Bは、${ISSUER_URL}/.well-known/oidc-configuration パスでOIDCディスカバリードキュメントを自動的に探し、ディスカバリードキュメント内の関連URLでJSON Web Key Set (JWKS) を見つけようとします。JWKSは、JWTが関連するアイデンティティプロバイダーによって発行されたものであることを確認するために使用されるリアルタイム検証に利用されます。
W&BへのJWTを使用
JWTイシュアがW&B組織のために設定されると、ユーザーはそのアイデンティティプロバイダーによって発行されたJWTを使用して関連するW&B Projectsへのアクセスを開始できます。JWTを使用するメカニズムは次の通りです：
組織内で利用可能なメカニズムの1つを使用して、アイデンティティプロバイダーにサインインする必要があります。一部のプロバイダーはAPIやSDKを使用して自動化された方法でアクセスでき、他のプロバイダーは関連するUIを使用してのみアクセス可能です。詳細については、W&B組織管理者やJWTイシュアの所有者にお問い合わせください。
アイデンティティプロバイダーにサインインした後、JWTをセキュアな場所に保存し、環境変数 WANDB_IDENTITY_TOKEN_FILE に絶対ファイルパスを設定してください。
W&B SDKやCLIを使用してW&Bプロジェクトにアクセスします。SDKやCLIは自動的にJWTを検出し、JWTが正常に検証された後にそれをW&Bアクセストークンと交換します。W&Bアクセストークンは、AIワークフローを有効にするためにrun、メトリクス、アーティファクトのログを記録するための関連するAPIにアクセスするために使用されます。アクセストークンはデフォルトで ~/.config/wandb/credentials.json のパスに保存されます。環境変数 WANDB_CREDENTIALS_FILE を指定することでそのパスを変更することができます。
JWTは、APIキー、パスワードなどの長期間の資格情報の欠点に対処するための短期間の資格情報として意図されています。あなたのアイデンティティプロバイダーで設定されたJWTの有効期限に応じて、JWTを継続的にリフレッシュし、環境変数 WANDB_IDENTITY_TOKEN_FILE で参照されるファイルに保存されていることを確認する必要があります。
W&Bアクセストークンにもデフォルトの有効期限があり、SDKまたはCLIは、それがあなたのJWTを使用して自動的にリフレッシュしようとします。その時点でユーザーJWTが期限切れになってリフレッシュされていない場合、認証に失敗する可能性があります。可能であれば、W&B SDKやCLIを使用したAIワークロードの一部として、JWTの取得と有効期限後のリフレッシュメカニズムを実装するべきです。
JWT検証
JWTをW&Bアクセストークンと交換し、プロジェクトにアクセスするためのワークフローの一環として、JWTは以下の検証を受けます：
JWT署名はW&B組織レベルでJWKSを使用して検証されます。これが最初の防御線であり、これが失敗した場合、あなたのJWKSやJWTの署名に問題があることを意味します。
JWT内の iss クレームは、組織レベルで設定されたイシュアURLと等しいものである必要があります。
JWT内の sub クレームは、W&B組織で設定されたユーザーのメールアドレスと等しいものである必要があります。
JWT内の aud クレームは、AIワークフローの一部としてアクセスしているプロジェクトを保有しているW&B組織の名前と同じである必要があります。Dedicated Cloud または セルフマネージド インスタンスの場合、インスタンスレベルの環境変数 SKIP_AUDIENCE_VALIDATION を true に設定してオーディエンスクレームの検証をスキップするか、wandb をオーディエンスとして使用します。
JWT内の exp クレームは、トークンが有効で期限が切れていないか、リフレッシュが必要であるかを確認するためにチェックされます。
外部サービスアカウント
W&Bは長期間のAPIキーを持つ組み込みのサービスアカウントを長年にわたりサポートしてきました。SDKとCLIのアイデンティティ連携機能を使用すると、外部サービスアカウントを持ち込むことができ、JWTを使用して認証することも可能です。ただし、それらが組織レベルで設定されている同じイシュアによって発行されている限りです。チーム管理者は、組み込みのサービスアカウントのように、チームの範囲内で外部サービスアカウントを設定することができます。
外部サービスアカウントを設定するには：
チームの Service Accounts タブに移動します。
New service account を押します。サービスアカウントの名前を入力し、Authentication Method として Federated Identity を選択し、Subject を提供して Create を押します。
外部サービスアカウントのJWT内の sub クレームは、チーム管理者がチームレベルの Service Accounts タブでそのサブジェクトとして設定したものと同じである必要があります。このクレームは、JWT検証 の一環として検証されます。aud クレームの要件は、人間のユーザーJWTと同様です。
W&Bへの外部サービスアカウントのJWTを使用するとき 、通常、初期JWTを生成し、継続的にリフレッシュするワークフローを自動化する方が簡単です。外部サービスアカウントを使用してログに記録されたrunを人間ユーザーに帰属させる場合、組み込みサービスアカウントと同様に、AIワークフローのために環境変数 WANDB_USERNAME または WANDB_USER_EMAIL を設定することができます。
W&Bは、データの機密性が異なるAIワークロード全体で、柔軟性と簡潔さのバランスを取るために、組み込みおよび外部サービスアカウントの組み合わせを使用することをお勧めします。
5.2.1.2 - SSO を LDAP で設定
資格情報を W&B Server の LDAP サーバーで認証します。次のガイドは W&B Server の設定を行う方法を説明しています。必須およびオプションの設定、システム設定 UI から LDAP 接続を設定する手順をカバーしています。また、アドレス、ベース識別名、属性など、LDAP 設定のさまざまな入力についての情報を提供します。これらの属性は W&B アプリ UI から、または環境変数を使用して指定できます。匿名バインドを設定するか、管理者 DN とパスワードでバインドすることができます。
W&B 管理者ロールのみが LDAP 認証を有効化および設定できます。
LDAP 接続の設定
W&B アプリに移動します。
右上のプロフィールアイコンを選択します。ドロップダウンから System Settings を選択します。
Configure LDAP Client を切り替えます。フォームに詳細を追加します。各入力の詳細は、Configuring Parameters セクションを参照してください。
Update Settings をクリックして設定をテストします。これにより、W&B サーバーとのテストクライアント/接続が確立されます。接続が検証されたら、Enable LDAP Authentication を切り替え、Update Settings ボタンを選択します。
次の環境変数を使用して LDAP 接続を設定します。
環境変数
必須
例
LOCAL_LDAP_ADDRESSはい
ldaps://ldap.example.com:636
LOCAL_LDAP_BASE_DNはい
email=mail,group=gidNumber
LOCAL_LDAP_BIND_DNいいえ
cn=admin, dc=example,dc=org
LOCAL_LDAP_BIND_PWいいえ
LOCAL_LDAP_ATTRIBUTESはい
email=mail, group=gidNumber
LOCAL_LDAP_TLS_ENABLEいいえ
LOCAL_LDAP_GROUP_ALLOW_LISTいいえ
LOCAL_LDAP_LOGINいいえ
各環境変数の定義については Configuration parameters セクションを参照してください。明確さのために、環境変数の接頭辞 LOCAL_LDAP を定義名から省略しました。
設定パラメータ
以下の表には、必須およびオプションの LDAP 設定を一覧し説明しています。
環境変数
定義
必須
ADDRESSW&B Server をホストする VPC 内の LDAP サーバーのアドレスです。
はい
BASE_DNディレクトリ内で検索を開始するルートパスであり、クエリを行うために必要です。
はい
BIND_DNLDAP サーバーに登録された管理者ユーザーのパスです。LDAP サーバーが未認証のバインドをサポートしていない場合、これが必要です。指定された場合、W&B Server はこのユーザーとして LDAP サーバーに接続します。指定されていない場合、W&B Server は匿名バインドを使用して接続します。
いいえ
BIND_PW管理者ユーザーのパスワードで、バインドを認証するために使用されます。空白の場合、W&B Server は匿名バインドを使用して接続します。
いいえ
ATTRIBUTESメールとグループ ID 属性名をコンマ区切りの文字列値として提供します。
はい
TLS_ENABLETLS を有効にします。
いいえ
GROUP_ALLOW_LISTグループ許可リスト。
いいえ
LOGINW&B Server に LDAP を使用して認証するかどうかを指定します。True または False を設定します。オプションとして、LDAP の設定をテストするために false に設定することができます。LDAP 認証を開始するには true に設定します。
いいえ
5.2.1.3 - SSO を OIDC で設定
W&B サーバーは、OpenID Connect (OIDC) 互換のアイデンティティ プロバイダーをサポートしており、Okta、Keycloak、Auth0、Google、および Entra などの外部アイデンティティ プロバイダーを通じてユーザー アイデンティティとグループ メンバーシップを管理できます。
OpenID Connect (OIDC)
W&B サーバーは、外部アイデンティティプロバイダー (IdP) とのインテグレーションのために、次の OIDC 認証フローをサポートします。
フォームポストを使用したインプリシットフロー
コードエクスチェンジのための証明キーを使用した認可コードフロー (PKCE)
これらのフローはユーザーを認証し、必要なアイデンティティ情報 (ID トークンの形式) を W&B サーバーに提供してアクレス制御を管理します。
ID トークンは、ユーザーの名前、ユーザー名、メール、およびグループメンバーシップなど、ユーザーのアイデンティティ情報を含む JWT です。W&B サーバーはこのトークンを使用してユーザーを認証し、システム内で適切なロールやグループにマッピングします。
W&B サーバーのコンテキストでは、アクセストークンはユーザーを代表して API へのリクエストを認可しますが、W&B サーバーの主な関心はユーザー認証とアイデンティティであるため、ID トークンのみが必要です。
環境変数を使用して、Dedicated cloud の IAM オプションを設定 するか、Self-managed インスタンスを設定することができます。
Dedicated cloud または Self-managed W&B サーバーインストールのためにアイデンティティ プロバイダーを設定する際は、さまざまな IdP に関するこれらのガイドラインに従ってください。SaaS バージョンの W&B を使用している場合は、組織の Auth0 テナントを設定するための支援を求めるには support@wandb.com に連絡してください。
AWS Cognito を認証に設定する手順は以下の通りです：
最初に AWS アカウントにサインインし、AWS Cognito アプリに移動します。
IdP にアプリケーションを設定するための許可されたコールバック URL を入力します：
http(s)://YOUR-W&B-HOST/oidc/callback をコールバック URL として追加します。 YOUR-W&B-HOST を W&B ホストパスに置き換えます。
IdP がユニバーサルログアウトをサポートしている場合は、ログアウト URL を http(s)://YOUR-W&B-HOST に設定します。 YOUR-W&B-HOST を W&B ホストパスに置き換えます。
たとえば、アプリケーションが https://wandb.mycompany.com で実行されている場合、YOUR-W&B-HOST を wandb.mycompany.com に置き換えます。
下の画像は、AWS Cognito で許可されたコールバックとサインアウト URL を提供する方法を示しています。
wandb/local はデフォルトで implicit grant with the form_post response type
また、wandb/local を設定して、PKCE Code Exchange フローを使用する authorization_code grant を実行することもできます。
アプリにトークンを届ける方法を AWS Cognito で設定するために、1 つ以上の OAuth グラントタイプを選択します。
W&B は特定の OpenID Connect (OIDC) スコープを要求します。AWS Cognito App から以下を選択してください：
“openid”
“profile”
“email”
たとえば、AWS Cognito アプリの UI は以下の画像のようになります：
設定ページで Auth Method を選択するか、OIDC_AUTH_METHOD 環境変数を設定して、どのグラントが wandb/local に適しているかを指定します。
Auth Method を pkce に設定する必要があります。
クライアント ID および OIDC 発行者の URL が必要です。OpenID ディスカバリドキュメントは $OIDC_ISSUER/.well-known/openid-configuration で利用可能でなければなりません。
たとえば、ユーザープール ID を User Pools セクションの App Integration タブから、Cognito IdP URL に追加することで発行者 URL を生成できます：
IDP URL には「Cognito ドメイン」を使用しないでください。Cognito は https://cognito-idp.$REGION.amazonaws.com/$USER_POOL_ID でそのディスカバリドキュメントを提供します。
Okta を認証に設定する手順は以下の通りです：
https://login.okta.com/ で Okta ポータルにログインします。
左側のサイドバーで Applications 、そして再度 Applications を選択します。
“Create App integration” をクリックします。
“Create a new app integration” 画面で OIDC - OpenID Connect と Single-Page Application を選択し、次に「Next」をクリックします。
“New Single-Page App Integration” 画面で、次の内容を入力し「Save」をクリックします：
アプリ統合名、例として “Weights & Biases”
グラントタイプ: Authorization Code と Implicit (hybrid) の両方を選択
サインイン リダイレクト URI: https://YOUR_W_AND_B_URL/oidc/callback
サインアウト リダイレクト URI: https://YOUR_W_AND_B_URL/logout
割り当て: Skip group assignment for now を選択
作成したばかりの Okta アプリケーションの概要画面で、Client ID を Client Credentials の General タブの下に記録します：
Okta OIDC 発行者 URL を特定するには、左側のメニューで Settings そして Account を選択します。
Okta UI は Organization Contact の下に企業名を表示します。
OIDC 発行者 URL は https://COMPANY.okta.com の形式です。該当する値で COMPANY を置き換えて、注意してください。
https://portal.azure.com/ で Azure ポータルにログインします。
「Microsoft Entra ID」サービスを選択します。
左側のサイドバーで「App registrations」を選択します。
上部で「New registration」をクリックします。
「アプリケーションの登録」画面で次の値を入力します：
名前を指定します。例として「Weights and Biases application」
デフォルトでは選択されたアカウントタイプは「この組織ディレクトリ内のアカウントのみ (デフォルトディレクトリのみ - シングルテナント)」です。必要に応じて修正してください。
リダイレクト URI を Web タイプで設定し、値は https://YOUR_W_AND_B_URL/oidc/callback
「登録」をクリックします。
「アプリケーション (client) ID」と「ディレクトリ (テナント) ID」をメモしておいてください。
左側のサイドバーで、Authentication をクリックします。
左側のサイドバーで「Certificates & secrets」をクリックします。
「Client secrets」をクリックし、「New client secret」をクリックします。
「クライアントシークレットの追加」画面で次の値を入力します：
これで次の 3 つの値をメモしておいてください：
OIDC クライアント ID
OIDC クライアントシークレット
OIDC 発行者 URL に必要なテナント ID
OIDC 発行者 URL は次の形式です：https://login.microsoftonline.com/${TenantID}/v2.0
W&B サーバーでの SSO 設定
SSO を設定するには、管理者権限と次の情報が必要です：
OIDC クライアント ID
OIDC 認証方法（implicit または pkce）
OIDC 発行者 URL
OIDC クライアントシークレット (オプション; IdP の設定方法に依存します)
IdP が OIDC クライアントシークレットを要求する場合、環境変数 OIDC_CLIENT_SECRET で指定してください。
SSO の設定は、W&B サーバー UI を使用するか、wandb/local pod に環境変数 を渡して設定することができます。環境変数が UI よりも優先されます。
SSO を設定した後でインスタンスにログインできない場合、LOCAL_RESTORE=true 環境変数を設定してインスタンスを再起動できます。これにより、一時的なパスワードがコンテナのログに出力され、SSO が無効になります。SSO の問題を解決したら、環境変数を削除して SSO を再度有効化する必要があります。
System Console
System settings
System Console は System Settings ページの後継です。これは W&B Kubernetes Operator ベースのデプロイメントで利用可能です。
Access the W&B Management Console を参照してください。
Settings に移動し、次に Authentication を選択します。Type ドロップダウンで OIDC を選択します。
値を入力します。
Save をクリックします。
ログアウトし、IdP ログイン画面を使用して再度ログインします。
Weights&Biases インスタンスにサインインします。
W&B アプリに移動します。
ドロップダウンから System Settings を選択します:
発行者、クライアント ID、および認証方法を入力します。
Update settings を選択します。
SSO を設定した後でインスタンスにログインできない場合、LOCAL_RESTORE=true 環境変数を設定してインスタンスを再起動できます。これにより、一時的なパスワードがコンテナのログに出力され、SSO がオフになります。SSO の問題を解決したら、環境変数を削除して SSO を再度有効化する必要があります。
セキュリティ・アサーション・マークアップ言語 (SAML)
W&B サーバーは SAML をサポートしていません。
5.2.1.4 - ワークフローを自動化するためにサービスアカウントを使用する
組織およびチームスコープのサービスアカウントを使用して、自動または非対話型のワークフローを管理する
サービスアカウントは、チーム内のプロジェクト全体または複数チームにわたって、一般的なタスクを自動で実行できる人間でない（または機械の）ユーザーを表します。
組織の管理者は、組織のスコープでサービスアカウントを作成することができます。
チームの管理者は、そのチームのスコープでサービスアカウントを作成することができます。
サービスアカウントの APIキー により、呼び出し元はサービスアカウントのスコープ内のプロジェクトを読み書きできます。
サービスアカウントは、W&B Modelsの実験管理を自動化したり、W&B Weaveのトレースをログ記録したりするために、複数のユーザーやチームによるワークフローを集中管理することを可能にします。また、WANDB_USERNAMEまたはWANDB_USER_EMAILの環境変数 を使用することにより、サービスアカウントで管理されているワークフローに人間ユーザーのアイデンティティを関連付けるオプションもあります。
組織スコープのサービスアカウント
組織スコープのサービスアカウントは、チームに関係なく、組織内のすべてのプロジェクトを読み書きする権限を持ちます。ただし、制限付きプロジェクト は例外です。制限付きプロジェクトにアクセスする前に、そのプロジェクトの管理者は明示的にサービスアカウントをプロジェクトに追加する必要があります。
組織管理者は、組織またはアカウントダッシュボードの Service Accounts タブから組織スコープのサービスアカウントの APIキー を取得できます。
新しい組織スコープのサービスアカウントを作成するには：
組織ダッシュボードの Service Accounts タブで New service account ボタンをクリックします。
Name を入力します。サービスアカウントのデフォルトチームを選択します。
Create をクリックします。新しく作成されたサービスアカウントの横で Copy API key をクリックします。
コピーした APIキー を秘密管理マネージャーまたは他の安全でアクセス可能な場所に保存します。
組織スコープのサービスアカウントはデフォルトのチームが必要ですが、それでも組織内のすべてのチームが所有する非制限プロジェクトにアクセスできます。これは、 WANDB_ENTITY 変数が モデルトレーニング や生成AIアプリの環境に設定されていない場合に、ワークロードが失敗するのを防ぐのに役立ちます。異なるチームのプロジェクトに組織スコープのサービスアカウントを使用するには、そのチームに WANDB_ENTITY 環境変数を設定する必要があります。
チームスコープのサービスアカウント
チームスコープのサービスアカウントは、そのチーム内のすべてのプロジェクトを読み書きできますが、そのチーム内の制限付きプロジェクト は除きます。制限付きプロジェクトにアクセスする前に、そのプロジェクトの管理者は明示的にサービスアカウントをプロジェクトに追加する必要があります。
チームの管理者として、 <WANDB_HOST_URL>/<your-team-name>/service-accounts でチームスコープのサービスアカウントの APIキー を取得できます。あるいは、チームの Team settings で Service Accounts タブを参照してください。
チーム用の新しいチームスコープのサービスアカウントを作成するには：
チームの Service Accounts タブで New service account ボタンをクリックします。
Name を入力します。認証メソッドとして Generate API key (Built-in) を選択します。
Create をクリックします。新しく作成されたサービスアカウントの横で Copy API key をクリックします。
コピーした APIキー を秘密管理マネージャーまたは他の安全でアクセス可能な場所に保存します。
チームスコープのサービスアカウントを使用する モデルトレーニング や生成AIアプリの環境でチームを設定しないと、モデルのrunやweaveトレースがサービスアカウントの親チーム内の指定されたプロジェクトにログ記録されます。このようなシナリオでは、参照されているユーザーがサービスアカウントの親チームの一部でない限り、WANDB_USERNAME または WANDB_USER_EMAIL 変数を使用したユーザー帰属は 機能しません 。
チームスコープのサービスアカウントは、親チームとは異なるチーム内の
チームスコープか制限スコープのプロジェクト に runをログ記録することはできませんが、他のチーム内の公開範囲プロジェクトには runをログ記録できます。
外部サービスアカウント
Built-in サービスアカウントに加えて、W&B は アイデンティティのフェデレーション を使用して、JSON Web Tokens (JWTs) を発行できるアイデンティティプロバイダー (IdPs) とともに、W&B SDK と CLI を用いたチームスコープの 外部サービスアカウント もサポートしています。
5.2.2 - アクセス管理
組織内でのユーザーとチームの管理
ユニークな組織ドメインで W&B に初めてサインアップしたユーザーは、その組織のインスタンス管理者ロール に割り当てられます。組織管理者は特定のユーザーにチーム管理者ロールを割り当てます。
W&B は、組織に複数のインスタンス管理者を持つことを推奨しています。これは、主な管理者が不在の場合にも管理業務を継続できるようにするためのベストプラクティスです。
チーム管理者 は、チーム内で管理権限を持つ組織内のユーザーです。
組織管理者は、https://wandb.ai/account-settings/ の組織アカウント設定にアクセスして、ユーザーを招待したり、ユーザーの役割を割り当てたり更新したり、チームを作成したり、組織からユーザーを削除したり、請求管理者を割り当てたりすることができます。詳細については、ユーザーの追加と管理 を参照してください。
組織管理者がチームを作成すると、インスタンス管理者またはチーム管理者は次のことができます：
デフォルトでは、管理者のみがそのチームにユーザーを招待したり、チームからユーザーを削除したりできます。この振る舞いを変更するには、チーム設定 を参照してください。
チームメンバーの役割を割り当てたり更新したりします。
組織に参加した際に自動的に新しいユーザーをチームに追加します。
組織管理者とチーム管理者は、https://wandb.ai/<your-team-name> のチームダッシュボードを使用してチームを管理します。詳細とチームのデフォルトの公開範囲を設定するには、チームの追加と管理 を参照してください。
特定のプロジェクトへの公開範囲の制限
W&B プロジェクトの範囲を定義して、誰がそのプロジェクトを閲覧、編集、そして W&B の run をサブミットできるかを制限します。プロジェクトを閲覧できる人を制限することは、特にチームが機密または秘密のデータを扱う場合に役立ちます。
組織管理者、チーム管理者、またはプロジェクトの所有者は、プロジェクトの公開範囲を設定および編集することができます。
詳細については、プロジェクトの公開範囲 を参照してください。
5.2.2.1 - あなたの組織を管理する
組織の管理者として、組織内の個々のユーザーを管理 し、チームを管理 できます。
チーム管理者として、チームを管理 できます。
以下のワークフローは、インスタンス管理者の役割を持つユーザーに適用されます。インスタンス管理者の権限が必要だと思われる場合は、組織の管理者に問い合わせてください。
組織内のユーザー管理を簡素化したい場合は、ユーザーとチームの管理を自動化する を参照してください。
組織名の変更
以下のワークフローはW&BマルチテナントSaaSクラウドにのみ適用されます。
https://wandb.ai/home に移動します。ページの右上隅にある ユーザーメニュー のドロップダウンを選択します。ドロップダウン内の アカウント セクションで 設定 を選択します。
設定 タブ内で 一般 を選択します。名前を変更 ボタンを選択します。表示されるモーダル内に、新しい組織名を入力し、名前を保存 ボタンを選択します。
ユーザーの追加と管理
管理者として、組織のダッシュボードを使用して次のことを行います。
ユーザーを招待または削除する。
ユーザーの組織の役割を割り当てまたは更新し、カスタム役割を作成する。
請求管理者を割り当てる。
組織の管理者がユーザーを組織に追加する方法はいくつかあります。
招待によるメンバー
SSOによる自動プロビジョニング
ドメインキャプチャ
シートと価格
以下の表は、Models と Weave のシートの仕組みをまとめたものです。
製品
シート
費用基準
Models
セットごとの支払い
支払い済みの Models シートの数と、累積した使用量が総合的なサブスクリプション費用を決定します。各ユーザーには、3 つの利用可能なシートタイプのいずれかを割り当てることができます: Full, Viewer, No-Access
Weave
無料
使用量に基づく
ユーザーを招待する
管理者は、組織内の特定のチームに加えてユーザーを組織に招待できます。
Multi-tenant SaaS Cloud
Dedicated or Self-managed
https://wandb.ai/home に移動します。ページの右上隅にある ユーザーメニュー のドロップダウンを選択します。ドロップダウン内の アカウント セクションで ユーザー を選択します。
新しいユーザーを招待する を選択します。表示されるモーダルで、メールまたはユーザー名 フィールドにそのユーザーのメールまたはユーザー名を入力します。
(推奨) チームを選択 ドロップダウンメニューから、そのユーザーをチームに追加します。
役割を選択 ドロップダウンから、そのユーザーに割り当てる役割を選択します。ユーザーの役割は後で変更可能です。役割を割り当てる に記載されている表を参照して、可能な役割について更に詳しく知ってください。招待を送信 ボタンを選択します。
W&Bはサードパーティのメールサーバーを使って、招待を送信 ボタンを選択した後にユーザーのメールに招待リンクを送信します。ユーザーが招待を受け入れると、あなたの組織にアクセスできるようになります。
https://<org-name>.io/console/settings/ に移動します。<org-name> はあなたの組織の名前に置き換えてください。ユーザーを追加 ボタンを選択します。表示されるモーダルで、新しいユーザーのメールアドレスを メール フィールドに入力します。
役割 ドロップダウンからユーザーに割り当てる役割を選択します。ユーザーの役割は後で変更可能です。役割を割り当てる に記載されている表を参照して、可能な役割について更に詳しく知ってください。ユーザーのメールにサードパーティのメールサーバーを使って招待リンクを送信したい場合は、招待メールをユーザーに送信 ボックスにチェックを入れます。
新しいユーザーを追加 ボタンを選択します。
ユーザーの自動プロビジョニング
一致するメールドメインを持つW&Bユーザーは、SSOを設定し、SSOプロバイダーが許可した場合、SSOを使ってW&B組織にサインインすることができます。SSOはすべてのエンタープライズライセンスに利用可能です。
認証にSSOを有効にする W&Bは、ユーザーがSSOを使って認証することを強く推奨しています。組織のSSOを有効にするためには、W&Bチームに連絡してください。
Dedicated cloudまたはSelf-managedインスタンスでSSOを設定する方法についての詳細は、SSO with OIDC またはSSO with LDAP を参照してください。
W&Bはデフォルトで自動プロビジョニングされたユーザーに「メンバー」役割を割り当てます。自動プロビジョニングされたユーザーの役割はいつでも変更可能です。
Dedicated cloudインスタンスおよびSelf-managedデプロイメントでは、SSOを使ったユーザーの自動プロビジョニングがデフォルトでオンになっています。自動プロビジョニングをオフにすることができ、特定のユーザーを選んでW&B組織に追加することができます。
以下のタブでは、デプロイメントタイプに基づいてSSOをオフにする方法を説明します：
Dedicated cloud
Self-managed
Dedicated cloudインスタンスを使用している場合で、自動プロビジョニングをオフにしたい場合は、W&Bチームに連絡してください。
W&Bコンソールを使用してSSOを使った自動プロビジョニングをオフにします。
https://<org-name>.io/console/settings/ に移動します。<org-name> をあなたの組織名に置き換えてください。セキュリティ を選択します。SSOプロビジョニングを無効にする を選択して、SSOを使った自動プロビジョニングをオフにします。
SSOを使った自動プロビジョニングは、大規模にユーザーを組織に追加するのに役立ちます。なぜなら、組織の管理者が個別のユーザー招待を生成する必要がないからです。
カスタム役割を作成する
Dedicated cloudまたはSelf-managedデプロイメントでカスタム役割を作成または割り当てるには、エンタープライズライセンスが必要です。
組織の管理者は、View-Only または Member 役割に基づいて新しい役割を作成し、追加の許可を追加することで詳細なアクセス制御を実現できます。チーム管理者は、チームメンバーにカスタム役割を割り当てることができます。カスタム役割は組織レベルで作成され、チームレベルで割り当てられます。
カスタム役割を作成するには：
Multi-tenant SaaS Cloud
Dedicated or Self-managed
https://wandb.ai/home に移動します。ページの右上隅にある ユーザーメニュー のドロップダウンを選択します。ドロップダウン内の アカウント セクションで 設定 を選択します。
役割 をクリックします。カスタム役割 セクションで 役割を作成 をクリックします。役割の名前を入力します。必要に応じて説明を追加します。
カスタム役割のベースとする役割を Viewer または Member から選択します。
許可を追加するには、許可を検索 フィールドをクリックし、追加する1つ以上の許可を選択します。
役割が持つ許可を要約している カスタム役割の許可 セクションを確認します。
役割を作成 をクリックします。
W&Bコンソールを使ってカスタム役割を作成します：
https://<org-name>.io/console/settings/ に移動します。<org-name> をあなたの組織名に置き換えてください。カスタム役割 セクションで 役割を作成 をクリックします。役割の名前を入力します。必要に応じて説明を追加します。
カスタム役割のベースとする役割を Viewer または Member から選択します。
許可を追加するには、許可を検索 フィールドをクリックし、追加する1つ以上の許可を選択します。
役割が持つ許可を要約している カスタム役割の許可 セクションを確認します。
役割を作成 をクリックします。
チーム管理者は、今後、チーム設定 からチームのメンバーにカスタム役割を割り当てることができます。
ドメインキャプチャ
ドメインキャプチャは、従業員があなたの会社の組織に参加する手助けをし、新しいユーザーが会社の管轄外で資産を作成することがないようにします。
ドメインはユニークである必要があります ドメインは一意の識別子です。つまり、他の組織ですでに使用されているドメインは使用できません。
Multi-tenant SaaS Cloud
Dedicated or Self-managed
ドメインキャプチャを使用すると、@example.com のような会社のメールアドレスを持つ人々を自動的にW&B SaaSクラウド組織に追加できます。これにより、すべての従業員が適切な組織に参加し、新しいユーザーが会社の管轄外で資産を作成することを防ぎます。
この表は、ドメインキャプチャが有効か無効かによる、新しいユーザーと既存のユーザーの振る舞いを要約したものです。
ドメインキャプチャあり
ドメインキャプチャなし
新しいユーザー
確認済みドメインからW&Bに登録したユーザーは自動的に組織のデフォルトチームにメンバーとして追加されます。チーム参加を有効にしている場合、登録時に追加のチームを選択することができます。招待を受け入れて他の組織やチームにも参加することができます。
ユーザーは、集中化された組織があることを知らずにW&Bアカウントを作成することができます。
招待されたユーザー
招待を受け入れたときに招待されたユーザーは自動的にあなたの組織に参加します。招待されたユーザーは組織のデフォルトチームに自動的にメンバーとして追加されません。招待を受けて他の組織やチームにも参加できます。
招待を受け入れたときに招待されたユーザーは自動的にあなたの組織に参加します。招待を受けて他の組織やチームにも参加できます。
既存のユーザー
あなたのドメインからの確認済みメールアドレスを持つ既存のユーザーは、W&Bアプリ内の組織のチームに参加できます。組織に参加する前に既存のユーザーが作成したすべてのデータは残ります。W&Bは既存ユーザーのデータを移行しません。
既存のW&Bユーザーは、複数の組織やチームに分散している可能性があります。
招待されていない新しいユーザーを組織に参加した際にデフォルトチームに自動的に割り当てるには：
https://wandb.ai/home に移動します。ページの右上隅にある ユーザーメニュー のドロップダウンを選択します。ドロップダウンから 設定 を選択します。
設定 タブ内で 一般 を選択します。ドメインキャプチャ 内の ドメインを請求する ボタンを選択します。デフォルトチーム ドロップダウンから新しいユーザーが自動的に参加するチームを選択します。利用可能なチームがない場合は、チーム設定を更新する必要があります。チームを追加し管理する の指示を参照してください。メールドメインを請求する ボタンをクリックします。
招待されていない新しいユーザーを自動的にそのチームに割り当てる前に、チームの設定でドメインマッチングを有効にする必要があります。
https://wandb.ai/<team-name> にあるチームのダッシュボードに移動します。ここで <team-name> はドメインマッチングを有効にしたいチームの名前です。チームのダッシュボードの左側のグローバルナビゲーションで チーム設定 を選択します。
プライバシー セクションで、「一致するメールドメインを持つ新しいユーザーに、サインアップ時にこのチームに参加することを推奨する」オプションを切り替えます。
専用または自己管理のデプロイメントタイプを使用してドメインキャプチャを構成する際は、W&Bアカウントチームにご連絡ください。設定が完了すると、会社のメールアドレスでW&Bアカウントを作成したユーザーに対し、専用または自己管理のインスタンスへのアクセスを求めるために管理者に連絡するよう自動的に促されます。
ドメインキャプチャあり
ドメインキャプチャなし
新しいユーザー
確認済みドメインからSaaSクラウド上のW&Bにサインアップしたユーザーは、カスタマイズしたメールアドレスを持つ管理者に連絡するように自動的に促されます。プロダクトのトライアルのためにSaaSクラウド上に新しい組織を作成することもできます。
ユーザーは、会社に集中化された専用インスタンスがあることを知らないまま、W&B SaaSクラウドアカウントを作成することができます。
既存のユーザー
既存のW&Bユーザーは、複数の組織やチームに分散している可能性があります。
既存のW&Bユーザーは、複数の組織やチームに分散している可能性があります。
ユーザーの役割を割り当てまたは更新する
組織内のすべてのメンバーは、W&B Models および Weave のための組織役割とシートを持っています。彼らのシートタイプによって、彼らの請求状況と各製品ラインで取ることのできるアクションが決まります。
組織に招待する際に、ユーザーに組織の役割を初めて割り当てます。後でどのユーザーの役割も変更できます。
組織内のユーザーは、以下のいずれかの役割を持つことができます：
役割
説明
管理者
他のユーザーを組織に追加または削除し、ユーザーの役割を変更し、カスタム役割を管理し、チームを追加することができるインスタンス管理者。管理者が不在の場合に備えて、W&Bは複数の管理者がいることを推奨しています。
メンバー
インスタンス管理者によって招待された組織の通常のユーザー。組織メンバーは、他のユーザーを招待したり、組織内の既存のユーザーを管理したりすることはできません。
ビューアー (エンタープライズのみの機能)
インスタンス管理者によって招待された、組織のビュー専用ユーザー。ビューアーは、組織と彼らがメンバーである基盤となるチームに対して読み取り専用アクセスを持ちます。
カスタムロール (エンタープライズのみの機能)
カスタム役割は、組織の管理者が前述の View-Only または Member 役割を継承し、追加の許可を追加して微細かいアクセス制御を達成するために作成することができます。チーム管理者は、その役割をそれぞれのチーム内のユーザーに割り当てることができます。
ユーザーの役割を変更するには：
https://wandb.ai/home に移動します。ページの右上隅にある ユーザーメニュー ドロップダウンを選択します。ドロップダウンから ユーザー を選択します。
検索バーにユーザーの名前またはメールアドレスを入力します。
チーム役割 ドロップダウンからユーザー名の横にある役割を選択します。
ユーザーのアクセスを割り当てまたは更新する
組織内のユーザーは、以下のいずれかのモデルシートまたは Weave アクセスタイプを持っています：フル、ビューアー、またはアクセスなし。
シートタイプ
説明
フル
この役割タイプのユーザーは、Models または Weave のデータを書き込み、読み取り、およびエクスポートするための完全な権限を持ちます。
ビューアー
あなたの組織のビュー専用ユーザー。ビューアーは、組織とその基となるチームに対してのみ読み取りアクセスを持ち、Models または Weave に対してビュー専用アクセスを持ちます。
アクセスなし
この役割を持つユーザーは、Models または Weave 製品へのアクセスはありません。
モデルシートタイプと Weave アクセスタイプは組織レベルで定義され、チームに継承されます。ユーザーのシートタイプを変更したい場合は、組織の設定に移動し、次のステップに従ってください：
SaaS ユーザーの場合、https://wandb.ai/account-settings/<organization>/settings にある組織の設定に移動します。角括弧（<>）で囲まれた値を組織名に置き換えてください。他の専用または自己管理のデプロイメントの場合は、https://<your-instance>.wandb.io/org/dashboard に移動します。
ユーザー タブを選択します。役割 ドロップダウンからユーザーに割り当てたいシートタイプを選択します。
組織の役割とサブスクリプションタイプが、あなたの組織内で利用可能なシートタイプを決定します。
ユーザーを削除する
https://wandb.ai/home に移動します。ページの右上隅にある ユーザーメニュー のドロップダウンを選択します。ドロップダウンから ユーザー を選択します。
検索バーにユーザーの名前またはメールアドレスを提供します。
表示されたら、三点リーダーまたは3つの点のアイコン（… ）を選択します。
ドロップダウンから メンバーを削除 を選択します。
請求管理者を割り当てる
https://wandb.ai/home に移動します。ページの右上隅にある ユーザーメニュー のドロップダウンを選択します。ドロップダウンから ユーザー を選択します。
検索バーにユーザーの名前またはメールアドレスを入力します。
請求管理者 列の下で、請求管理者として割り当てたいユーザーを選択します。
チームを追加し管理する
組織のダッシュボードを使って、組織内でチームを作成し管理します。組織の管理者またはチーム管理者は、以下のことができます：
ユーザーをチームに招待したり、チームからユーザーを削除したりする。
チームメンバーの役割を管理する。
組織に参加した時にユーザーをチームに自動的に追加する。
https://wandb.ai/<team-name> にあるチームのダッシュボードでチームストレージを管理する。
チームを作成する
組織のダッシュボードを使用してチームを作成します：
https://wandb.ai/home に移動します。チーム の下の左側のナビゲーションパネルで コラボレーション用のチームを作成 を選択します。
表示されるモーダルで チーム名 フィールドにチームの名前を入力します。
ストレージタイプを選択します。
チームを作成 ボタンを選択します。
チームを作成 ボタンを選択すると、W&Bは https://wandb.ai/<team-name> の新しいチームページにリダイレクトします。<team-name> はチーム作成時に入力した名前を使用します。
チームを持ったら、そのチームにユーザーを追加することができます。
チームにユーザーを招待する
組織内のチームにユーザーを招待します。ユーザーがすでにW&Bアカウントを持っている場合は、メールアドレスまたはW&Bユーザー名を使用してチームのダッシュボードからユーザーを招待します。
https://wandb.ai/<team-name> に移動します。ダッシュボードの左側のグローバルナビゲーションで チーム設定 を選択します。
ユーザー タブを選択します。新しいユーザーを招待する を選びます。表示されるモーダルで、メールまたはユーザー名 フィールドにそのユーザーのメールを提供し、チームを選択する ドロップダウンからそのユーザーに割り当てる役割を選択します。チーム内でユーザーが持つことができる役割について詳しくは、チーム役割 を参照してください。
招待を送信 ボタンを選びます。
デフォルトでは、チームまたはインスタンスの管理者のみがメンバーをチームに招待できます。この動作を変更するには、チーム設定 を参照してください。
メール招待でユーザーを手動で招待することに加えて、新しいユーザーのメールがあなたの組織のドメインと一致する 場合は、自動的に新しいユーザーをチームに追加できます。
新メンバーを登録時にチーム組織と一致させる
新規ユーザーがサインアップ時に組織内のチームを発見できるようにします。新しいユーザーは、あなたの組織の確認済みメールドメインと一致する確認済みのメールドメインを持っている必要があります。確認済みの新規ユーザーは、W&Bアカウントに登録する際に組織に属する確認済みのチームの一覧を見ることができます。
組織の管理者はドメイン請求を有効にする必要があります。ドメインキャプチャを有効にするには、ドメインキャプチャ に記載されている手順を参照してください。
チームメンバーの役割を割り当てまたは更新する
チームメンバーの名前の横にあるアカウントタイプのアイコンを選択します。
ドロップダウンから、そのチームメンバーが持つことを望むアカウントタイプを選択します。
この表は、チームメンバーに割り当てることができる役割を示しています：
役割
定義
管理者
チーム内で他のユーザーを追加し削除したり、ユーザー役割を変更したり、チームの設定を構成できるユーザー。
メンバー
チーム管理者によってメールまたは組織レベルのユーザー名で招待された、チームの通常のユーザー。メンバー ユーザーは、他のユーザーをチームに招待できません。
ビュー専用 (エンタープライズのみの機能)
チーム管理者によってメールまたは組織レベルのユーザー名で招待された、チームのビュー専用ユーザー。ビュー専用ユーザーは、チームとそのコンテンツに対して読み取り専用アクセスしか持たない。
サービス (エンタープライズのみの機能)
サービスワーカーまたはサービスアカウントは、W&Bをあなたのrunオートメーションツールで利用するために役立つAPIキーです。チームのためにサービスアカウントからAPIキーを使用する場合は、環境変数 WANDB_USERNAME を設定して正しいユーザーにrunを紐付けることを確認してください。
カスタムロール (エンタープライズのみの機能)
カスタム役割は、組織管理者が前述の View-Only または Member 役割を継承し、追加の許可を追加して微細かいアクセス制御を達成するために作成することができます。チーム管理者は、その役割をそれぞれのチーム内のユーザーに割り当てることができます。詳細については、この記事 を参照してください。
専用クラウドまたは自己管理デプロイメントのエンタープライズライセンスのみが、チームメンバーにカスタム役割を割り当てることができます。
チームからユーザーを削除する
チームのダッシュボードを使用してユーザーをチームから削除します。メンバーが作成したrunは、そのメンバーがそのチームにいなくなった場合でもW&Bに保存されます。
https://wandb.ai/<team-name> に移動します。左側のナビゲーションバーで チーム設定 を選択します。
ユーザー タブを選択します。削除したいユーザーの名前の横にマウスをホバーします。表示されたら、三点リーダーまたは3つの点のアイコン（… ）を選択します。
ドロップダウンから ユーザーを削除 を選択します。
5.2.2.2 - プロジェクトのアクセス制御を管理する
プロジェクトの公開範囲スコープとプロジェクトレベルの役割を使用してプロジェクトのアクセスを管理する
W&B プロジェクトの範囲を設定し、誰が W&B の run を表示、編集、提出できるかを制限します。
W&B チーム内の任意のプロジェクトに対するアクセスレベルを設定するために、いくつかのコントロールを組み合わせて使用できます。 公開範囲 は、上位レベルのメカニズムです。これを使用して、どのユーザーグループがプロジェクト内の run を表示または提出できるかを制御します。Team または Restricted の公開範囲を持つプロジェクトでは、プロジェクトレベルの役割 を使用して、各ユーザーのプロジェクト内でのアクセスレベルを制御できます。
プロジェクトのオーナーやチーム管理者、組織の管理者は、プロジェクトの公開範囲を設定または編集できます。
公開範囲
選択できるプロジェクトの公開範囲は4つあります。最も公開されているものから最もプライベートなものの順に、それらは次のとおりです：
範囲
説明
Open
プロジェクトを知っている人は誰でもプロジェクトを表示し、run やレポートを提出できます。
Public
プロジェクトを知っている人は誰でもプロジェクトを表示できます。run やレポートを提出できるのはプロジェクトのチームだけです。
Team
親チームのメンバーのみがプロジェクトを表示でき、run やレポートを提出できます。チーム外の人はプロジェクトにアクセスできません。
Restricted
親チームから招待されたメンバーのみがプロジェクトを表示し、run やレポートを提出できます。
機密性や機密データに関連するワークフローでコラボレーションしたい場合は、プロジェクトの範囲を Restricted に設定します。Restricted プロジェクトをチーム内に作成するとき、チーム内の特定のメンバーを実験、アーティファクト、レポートなどにコラボレーションするために招待または追加することができます。
他のプロジェクト範囲とは異なり、チームの全メンバーが暗黙のうちにリストリクションプロジェクトにアクセスできるわけではありません。同時に、チーム管理者は必要に応じてリストリクションプロジェクトに参加できます。
新規または既存のプロジェクトの公開範囲を設定する
プロジェクトを作成するとき、または後で編集するときに、プロジェクトの公開範囲を設定します。
プロジェクトのオーナーやチーム管理者のみが公開範囲を設定または編集できます。
チーム管理者がチームのプライバシー設定内で Make all future team projects private (public sharing not allowed) を有効にすると、そのチームの Open および Public プロジェクトの公開範囲がオフになります。この場合、チームは Team および Restricted の範囲のみを使用できます。
新しいプロジェクトを作成するときに公開範囲を設定する
SaaS クラウド、専用クラウド、または自己管理インスタンスで W&B 組織に移動します。
左側のサイドバーの My projects セクションで Create a new project ボタンをクリックします。代わりに、チームの Projects タブに移動し、右上のコーナーの Create new project ボタンをクリックします。
親チームを選択し、プロジェクトの名前を入力した後、プロジェクトの公開範囲 ドロップダウンから希望の範囲を選択します。
Restricted の公開範囲を選択した場合、次のステップを完了します。
プロジェクトでコラボレーションするために必要な W&B チームメンバーの名前を 招待チームメンバー フィールドに入力します。
Users タブから、後でリストリクションプロジェクトにメンバーを追加または削除できます。
既存のプロジェクトの公開範囲を編集する
W&B プロジェクトに移動します。
左の列で Overview タブを選択します。
右上のコーナーで Edit Project Details ボタンをクリックします。
Project Visibility ドロップダウンから希望の範囲を選択します。
Restricted の公開範囲を選択した場合、次のステップを完了します。
プロジェクトの Users タブに移動し、特定のユーザーをリストリクションプロジェクトに招待するために ユーザーを追加 ボタンをクリックします。
プロジェクトの公開範囲を Team から Restricted に変更した場合、必要なチームメンバーをプロジェクトに招待しない限り、すべてのチームメンバーがプロジェクトのアクセスを失います。
プロジェクトの公開範囲を Restricted から Team に変更すると、すべてのメンバーがプロジェクトにアクセスできます。
リストリクションプロジェクトからユーザーリストを削除すると、そのプロジェクトへのアクセスを失います。
リストリクション範囲についてのその他の重要な注意事項
チームレベルのサービスアカウントをリストリクションプロジェクトで使用したい場合は、そのアカウントをプロジェクトに特に招待または追加する必要があります。そうでないと、デフォルトではチームレベルのサービスアカウントはリストリクションプロジェクトにアクセスできません。
リストリクションプロジェクトから run を移動することはできませんが、非リストリクションプロジェクトからリストリクションプロジェクトに run を移動することはできます。
プロジェクトの公開範囲をチーム にのみ変換することができ、その際、チームのプライバシー設定 Make all future team projects private (public sharing not allowed) に依存しません。
リストリクションプロジェクトのオーナーが親チームの一員でなくなった場合、チーム管理者はスムーズなプロジェクト運営のためにオーナーを変更する必要があります。
プロジェクトレベルの役割
チーム内の Team または Restricted 範囲のプロジェクトでは、ユーザーに特定の役割を割り当てることができ、その役割はそのユーザーのチームレベルの役割と異なる場合があります。例えば、ユーザーがチームレベルで Member 役割を持っている場合、そのユーザーに View-Only 、Admin 、または利用可能なカスタム役割をそのチーム内の Team あるいは Restricted 範囲のプロジェクトで割り当てることができます。
プロジェクトレベルの役割は、SaaS クラウド、専用クラウド、自己管理インスタンスでプレビュー中です。
ユーザーにプロジェクトレベルの役割を割り当てる
W&B プロジェクトに移動します。
左の列で Overview タブを選択します。
プロジェクトの Users タブに進みます。
関連するユーザーの Project Role フィールドに現在割り当てられている役割をクリックすると、他の利用可能な役割がリストされているドロップダウンが開きます。
ドロップダウンから別の役割を選択します。それは即座に保存されます。
プロジェクトレベル役割をユーザーのチームレベル役割と異なるものに変更すると、プロジェクトレベル役割には*****が含まれ、違いを示します。
プロジェクトレベルの役割についてのその他の重要な注意事項
デフォルトでは、チーム_または_リストリクション のプロジェクトにおける全ユーザーのプロジェクトレベルの役割は、それぞれのチームレベルの役割を継承 します。
チームレベルで View-Only 役割を持つユーザーのプロジェクトレベルの役割を変更することはできません 。
特定のプロジェクト内でのユーザーのプロジェクトレベル役割がチームレベルの役割と同じ である場合、チーム管理者がいつかチームレベルの役割を変更した場合、関連するプロジェクト役割も自動的にチームレベルの役割に追随して変更されます。
特定のプロジェクト内のユーザーのプロジェクトレベル役割をチームレベルの役割と異なるもの に変更した場合、チーム管理者がいつかチームレベルの役割を変更しても、関連するプロジェクトレベルの役割はそのままとなります。
プロジェクトレベルの役割がチームレベルの役割と異なる場合に、リストリクション プロジェクトからユーザーを削除し、その後しばらくしてユーザーをプロジェクトに戻した場合、デフォルトの振る舞いによりそのチームレベルの役割を継承します。必要であれば、プロジェクトレベルの役割を再度チームレベルの役割と異なるものに変更する必要があります。
5.2.3 - ユーザーとチームの管理を自動化する
SCIM API
SCIM API を使用して、ユーザーやその所属するチームを効率的かつ再現可能な方法で管理します。また、SCIM API を使用してカスタムロールを管理したり、 W&B 組織内のユーザーにロールを割り当てたりすることもできます。ロールエンドポイントは公式の SCIM スキーマの一部ではありません。 W&B はカスタムロールの自動管理をサポートするためにロールエンドポイントを追加しています。
SCIM API は特に以下の場合に役立ちます：
大規模なユーザーのプロビジョニングおよびプロビジョニング解除の管理
SCIMサポートのアイデンティティプロバイダーを使用してユーザーを管理
SCIM API には大きく分けて 3 つのカテゴリがあります - User 、 Group 、および Roles 。
User SCIM API
User SCIM API を使用すると、ユーザーの作成、無効化、詳細の取得、または W&B 組織内の全ユーザーの一覧を表示できます。この API は、組織内のユーザーに事前定義されたロールまたはカスタムロールを割り当てることもサポートしています。
DELETE User エンドポイントを使用して、W&B 組織内のユーザーを無効化します。無効化されたユーザーはサインインできなくなります。ただし、無効化されたユーザーは引き続き組織のユーザーリストに表示されます。
無効化されたユーザーをユーザーリストから完全に削除するには、 ユーザーを組織から削除 する必要があります。
必要に応じて無効化されたユーザーを再有効化することが可能です。
Group SCIM API
Group SCIM API は、組織内での W&B チームの作成や削除を含めた管理を行うことができます。 PATCH Group を使用して、既存のチームにユーザーを追加または削除します。
W&B には、 グループ内のユーザーが同じロールを持つ という概念はありません。 W&B チームはグループに非常に似ており、さまざまな役割を持った多様な個人が関連するプロジェクトで共同作業することができます。チームは異なるユーザーグループで構成されることができます。チーム内の各ユーザーに、チームの管理者、メンバー、閲覧者、またはカスタムロールのいずれかのロールを割り当てます。
グループと W&B チームの類似性のために、 W&B は Group SCIM API エンドポイントを W&B チームにマップしています。
Custom role API
Custom role SCIM API は、組織内でのカスタムロールの作成、一覧表示、更新を含めた管理を行うことができます。
カスタムロールを削除する際は注意してください。
DELETE Role エンドポイントを使用して W&B 組織内でカスタムロールを削除します。カスタムロールが継承する事前定義ロールは、操作が実行される前にカスタムロールに割り当てられたすべてのユーザーに割り当てられます。
PUT Role エンドポイントを使用してカスタムロールの継承ロールを更新します。この操作は、カスタムロールの既存の、つまり非継承のカスタム許可には影響しません。
W&B Python SDK API
SCIM API がユーザーとチームの管理を自動化するのと同様に、一部のメソッドを使用して W&B Python SDK API も同様の目的で使用できます。以下のメソッドに注意してください：
メソッド名
目的
create_user(email, admin=False)ユーザーを組織に追加し、オプションで組織の管理者に設定します。
user(userNameOrEmail)組織に既に存在するユーザーを返します。
user.teams()ユーザーのチームを返します。ユーザーオブジェクトは user(userNameOrEmail) メソッドを使用して取得できます。
create_team(teamName, adminUserName)新しいチームを作成し、オプションで組織レベルのユーザーをチーム管理者に設定します。
team(teamName)組織に既に存在するチームを返します。
Team.invite(userNameOrEmail, admin=False)ユーザーをチームに追加します。team(teamName) メソッドを使用してチームオブジェクトを取得できます。
Team.create_service_account(description)サービスアカウントをチームに追加します。team(teamName) メソッドを使用してチームオブジェクトを取得できます。
Member.delete()チームからメンバーを削除します。team オブジェクトの members 属性を使用してチーム内のメンバーオブジェクトのリストを取得できます。そして、 team(teamName) メソッドを使用してチームオブジェクトを取得できます。
5.2.4 - ユーザー、グループ、およびロールを SCIM で管理する
クロスドメイン・アイデンティティ管理システム (SCIM) API は、インスタンスまたは組織の管理者が W&B 組織内のユーザー、グループ、およびカスタムロールを管理できるようにします。SCIM グループは W&B のチームにマップされます。
SCIM API は <host-url>/scim/ でアクセス可能であり、RC7643 プロトコル に見られるフィールドのサブセットを持つ /Users と /Groups エンドポイントをサポートしています。さらに、公式の SCIM スキーマの一部ではない /Roles エンドポイントを含んでいます。W&B は /Roles エンドポイントを追加して、W&B 組織でのカスタムロールの自動管理をサポートしています。
複数の Enterprise SaaS Cloud 組織の管理者である場合、SCIM API リクエストが送信される組織を設定する必要があります。プロファイル画像をクリックし、User Settings をクリックします。設定名は Default API organization です。これは、Dedicated Cloud 、Self-managed instances 、および SaaS Cloud を含むすべてのホスティングオプションで必要です。SaaS Cloud では、組織の管理者は SCIM API リクエストが正しい組織に行くように、ユーザー設定でデフォルトの組織を設定する必要があります。
選択したホスティングオプションに応じて、このページの例で使用される <host-url> プレースホルダーの値が決まります。
さらに、例では abc や def のようなユーザー ID が使用されています。実際のリクエストとレスポンスでは、ユーザー ID はハッシュ化された値を持っています。
認証
組織またはインスタンスの管理者は、自分の API キーを使用した基本認証を利用して SCIM API にアクセスできます。HTTP リクエストの Authorization ヘッダーを文字列 Basic の後にスペースを置き、その後のベース64エンコードされた文字列を username:API-KEY 形式に設定します。つまり、ユーザー名と API キーを : 文字で区切った後、その結果をベース64エンコードします。例えば、demo:p@55w0rd として認証するには、ヘッダーは Authorization: Basic ZGVtbzpwQDU1dzByZA== であるべきです。
ユーザーリソース
SCIM ユーザーリソースは W&B のユーザーにマップされます。
ユーザーの取得
{
"active" : true ,
"displayName" : "Dev User 1" ,
"emails" : {
"Value" : "dev-user1@test.com" ,
"Display" : "" ,
"Type" : "" ,
"Primary" : true
},
"id" : "abc" ,
"meta" : {
"resourceType" : "User" ,
"created" : "2023-10-01T00:00:00Z" ,
"lastModified" : "2023-10-01T00:00:00Z" ,
"location" : "Users/abc"
},
"schemas" : [
"urn:ietf:params:scim:schemas:core:2.0:User"
],
"userName" : "dev-user1"
}
ユーザーのリスト
{
"Resources" : [
{
"active" : true ,
"displayName" : "Dev User 1" ,
"emails" : {
"Value" : "dev-user1@test.com" ,
"Display" : "" ,
"Type" : "" ,
"Primary" : true
},
"id" : "abc" ,
"meta" : {
"resourceType" : "User" ,
"created" : "2023-10-01T00:00:00Z" ,
"lastModified" : "2023-10-01T00:00:00Z" ,
"location" : "Users/abc"
},
"schemas" : [
"urn:ietf:params:scim:schemas:core:2.0:User"
],
"userName" : "dev-user1"
}
],
"itemsPerPage" : 9999 ,
"schemas" : [
"urn:ietf:params:scim:api:messages:2.0:ListResponse"
],
"startIndex" : 1 ,
"totalResults" : 1
}
ユーザーの作成
エンドポイント : <host-url>/scim/Usersメソッド : POST説明 : 新しいユーザーリソースを作成します。サポートされているフィールド :
フィールド
型
必要
emails
Multi-Valued Array
Yes (必ず primary email を設定してください)
userName
文字列型
Yes
{
"schemas" : [
"urn:ietf:params:scim:schemas:core:2.0:User"
],
"emails" : [
{
"primary" : true ,
"value" : "admin-user2@test.com"
}
],
"userName" : "dev-user2"
}
{
"active" : true ,
"displayName" : "Dev User 2" ,
"emails" : {
"Value" : "dev-user2@test.com" ,
"Display" : "" ,
"Type" : "" ,
"Primary" : true
},
"id" : "def" ,
"meta" : {
"resourceType" : "User" ,
"created" : "2023-10-01T00:00:00Z" ,
"location" : "Users/def"
},
"schemas" : [
"urn:ietf:params:scim:schemas:core:2.0:User"
],
"userName" : "dev-user2"
}
ユーザーの削除
ユーザーの無効化
フィールド
型
必要
op
文字列型
操作のタイプ。許可される唯一の値は replace です。
value
オブジェクト型
オブジェクト {"active": false} を示し、ユーザーが無効化されるべきことを示します。
{
"schemas" : ["urn:ietf:params:scim:api:messages:2.0:PatchOp" ],
"Operations" : [
{
"op" : "replace" ,
"value" : {"active" : false }
}
]
}
レスポンス例 :
この操作はユーザーオブジェクトを返します。
{
"active" : true ,
"displayName" : "Dev User 1" ,
"emails" : {
"Value" : "dev-user1@test.com" ,
"Display" : "" ,
"Type" : "" ,
"Primary" : true
},
"id" : "abc" ,
"meta" : {
"resourceType" : "User" ,
"created" : "2023-10-01T00:00:00Z" ,
"lastModified" : "2023-10-01T00:00:00Z" ,
"location" : "Users/abc"
},
"schemas" : [
"urn:ietf:params:scim:schemas:core:2.0:User"
],
"userName" : "dev-user1"
}
ユーザーの再有効化
エンドポイント : <host-url>/scim/Users/{id}メソッド : PATCH説明 : ユーザーの一意の ID を提供することにより、Dedicated Cloud または Self-managed インスタンス内で無効化されたユーザーを再有効化します。サポートされているフィールド :
フィールド
型
必要
op
文字列型
操作のタイプ。許可される唯一の値は replace です。
value
オブジェクト型
オブジェクト {"active": true} を示し、ユーザーが再有効化されるべきことを示します。
{
"schemas" : ["urn:ietf:params:scim:api:messages:2.0:PatchOp" ],
"Operations" : [
{
"op" : "replace" ,
"value" : {"active" : true }
}
]
}
レスポンス例 :
この操作はユーザーオブジェクトを返します。
{
"active" : true ,
"displayName" : "Dev User 1" ,
"emails" : {
"Value" : "dev-user1@test.com" ,
"Display" : "" ,
"Type" : "" ,
"Primary" : true
},
"id" : "abc" ,
"meta" : {
"resourceType" : "User" ,
"created" : "2023-10-01T00:00:00Z" ,
"lastModified" : "2023-10-01T00:00:00Z" ,
"location" : "Users/abc"
},
"schemas" : [
"urn:ietf:params:scim:schemas:core:2.0:User"
],
"userName" : "dev-user1"
}
組織レベルのロールをユーザーに割り当てる
エンドポイント : <host-url>/scim/Users/{id}メソッド : PATCH説明 : 組織レベルのロールをユーザーに割り当てます。このロールは、ここで説明されているように admin、viewer または member のいずれかになります (こちらを参照 )。 SaaS Cloud では、ユーザー設定で SCIM API の正しい組織を設定することを確認してください。サポートされているフィールド :
フィールド
型
必要
op
文字列型
操作のタイプ。許可される唯一の値は replace です。
path
文字列型
ロール割り当て操作が影響を及ぼすスコープ。許可される唯一の値は organizationRole です。
value
文字列型
ユーザーに割り当てる予定の定義済みの組織レベルのロール。それは admin、viewer または member のいずれかです。このフィールドは定義済みロールに対して大文字小文字を区別しません。
{
"schemas" : ["urn:ietf:params:scim:api:messages:2.0:PatchOp" ],
"Operations" : [
{
"op" : "replace" ,
"path" : "organizationRole" ,
"value" : "admin" // ユーザーの組織スコープのロールを admin に設定
]
}
レスポンス例 :
この操作はユーザーオブジェクトを返します。
{
"active" : true ,
"displayName" : "Dev User 1" ,
"emails" : {
"Value" : "dev-user1@test.com" ,
"Display" : "" ,
"Type" : "" ,
"Primary" : true
},
"id" : "abc" ,
"meta" : {
"resourceType" : "User" ,
"created" : "2023-10-01T00:00:00Z" ,
"lastModified" : "2023-10-01T00:00:00Z" ,
"location" : "Users/abc"
},
"schemas" : [
"urn:ietf:params:scim:schemas:core:2.0:User"
],
"userName" : "dev-user1" ,
"teamRoles" : [ // ユーザーが所属するすべてのチームでのロールを返します
"teamName" : "team1" ,
"roleName" : "admin"
}
],
"organizationRole" : "admin" // 組織スコープでのユーザーのロールを返します
チームレベルのロールをユーザーに割り当てる
エンドポイント : <host-url>/scim/Users/{id}メソッド : PATCH説明 : チームレベルのロールをユーザーに割り当てます。このロールは、ここで説明されているように admin、viewer、member またはカスタムロールのいずれかになります (こちらを参照 )。 SaaS Cloud では、ユーザー設定で SCIM API の正しい組織を設定することを確認してください。サポートされているフィールド :
フィールド
型
必要
op
文字列型
操作のタイプ。許可される唯一の値は replace です。
path
文字列型
ロール割り当て操作が影響を及ぼすスコープ。許可される唯一の値は teamRoles です。
value
オブジェクト配列型
1つのオブジェクトを持つ配列で、そのオブジェクトは teamName と roleName 属性を持ちます。teamName はユーザーがそのロールを持つチームの名前であり、roleName は admin、viewer、member またはカスタムロールのいずれかです。このフィールドは定義済みロールに対して大文字小文字を区別しませんが、カスタムロールに対しては区別します。
{
"schemas" : ["urn:ietf:params:scim:api:messages:2.0:PatchOp" ],
"Operations" : [
{
"op" : "replace" ,
"path" : "teamRoles" ,
"value" : [
{
"roleName" : "admin" , // 定義済みロールのロール名は大文字小文字を区別しませんが、カスタムロールでは区別します
"teamName" : "team1" // チームteam1でのユーザーのロールをadminに設定
]
}
]
}
レスポンス例 :
この操作はユーザーオブジェクトを返します。
{
"active" : true ,
"displayName" : "Dev User 1" ,
"emails" : {
"Value" : "dev-user1@test.com" ,
"Display" : "" ,
"Type" : "" ,
"Primary" : true
},
"id" : "abc" ,
"meta" : {
"resourceType" : "User" ,
"created" : "2023-10-01T00:00:00Z" ,
"lastModified" : "2023-10-01T00:00:00Z" ,
"location" : "Users/abc"
},
"schemas" : [
"urn:ietf:params:scim:schemas:core:2.0:User"
],
"userName" : "dev-user1" ,
"teamRoles" : [ // ユーザーが所属するすべてのチームでのロールを返します
"teamName" : "team1" ,
"roleName" : "admin"
}
],
"organizationRole" : "admin" // 組織スコープでのユーザーのロールを返します
グループリソース
SCIM グループリソースは W&B のチームにマップされます。つまり、W&B デプロイメントで SCIM グループを作成すると W&B チームが作成されます。その他のグループエンドポイントにも同様です。
チームの取得
エンドポイント : <host-url>/scim/Groups/{id}メソッド : GET説明 : チームの一意の ID を提供してチーム情報を取得します。リクエスト例 :
{
"displayName" : "wandb-devs" ,
"id" : "ghi" ,
"members" : [
{
"Value" : "abc" ,
"Ref" : "" ,
"Type" : "" ,
"Display" : "dev-user1"
}
],
"meta" : {
"resourceType" : "Group" ,
"created" : "2023-10-01T00:00:00Z" ,
"lastModified" : "2023-10-01T00:00:00Z" ,
"location" : "Groups/ghi"
},
"schemas" : [
"urn:ietf:params:scim:schemas:core:2.0:Group"
]
}
チームのリスト
エンドポイント : <host-url>/scim/Groupsメソッド : GET説明 : チームのリストを取得します。リクエスト例 :
{
"Resources" : [
{
"displayName" : "wandb-devs" ,
"id" : "ghi" ,
"members" : [
{
"Value" : "abc" ,
"Ref" : "" ,
"Type" : "" ,
"Display" : "dev-user1"
}
],
"meta" : {
"resourceType" : "Group" ,
"created" : "2023-10-01T00:00:00Z" ,
"lastModified" : "2023-10-01T00:00:00Z" ,
"location" : "Groups/ghi"
},
"schemas" : [
"urn:ietf:params:scim:schemas:core:2.0:Group"
]
}
],
"itemsPerPage" : 9999 ,
"schemas" : [
"urn:ietf:params:scim:api:messages:2.0:ListResponse"
],
"startIndex" : 1 ,
"totalResults" : 1
}
チームの作成
エンドポイント : <host-url>/scim/Groupsメソッド : POST説明 : 新しいチームリソースを作成します。サポートされているフィールド :
フィールド
型
必要
displayName
文字列型
Yes
members
Multi-Valued Array
Yes (value サブフィールドが必要で、ユーザー ID にマップされます)
wandb-support というチームを作成し、そのメンバーとして dev-user2 を設定します。
{
"schemas" : ["urn:ietf:params:scim:schemas:core:2.0:Group" ],
"displayName" : "wandb-support" ,
"members" : [
{
"value" : "def"
}
]
}
{
"displayName" : "wandb-support" ,
"id" : "jkl" ,
"members" : [
{
"Value" : "def" ,
"Ref" : "" ,
"Type" : "" ,
"Display" : "dev-user2"
}
],
"meta" : {
"resourceType" : "Group" ,
"created" : "2023-10-01T00:00:00Z" ,
"lastModified" : "2023-10-01T00:00:00Z" ,
"location" : "Groups/jkl"
},
"schemas" : [
"urn:ietf:params:scim:schemas:core:2.0:Group"
]
}
チームの更新
エンドポイント : <host-url>/scim/Groups/{id}メソッド : PATCH説明 : 既存のチームのメンバーシップリストを更新します。サポートされている操作 : メンバーの追加、メンバーの削除リクエスト例 :
wandb-devs に dev-user2 を追加する
{
"schemas" : ["urn:ietf:params:scim:api:messages:2.0:PatchOp" ],
"Operations" : [
{
"op" : "add" ,
"path" : "members" ,
"value" : [
{
"value" : "def" ,
}
]
}
]
}
{
"displayName" : "wandb-devs" ,
"id" : "ghi" ,
"members" : [
{
"Value" : "abc" ,
"Ref" : "" ,
"Type" : "" ,
"Display" : "dev-user1"
},
{
"Value" : "def" ,
"Ref" : "" ,
"Type" : "" ,
"Display" : "dev-user2"
}
],
"meta" : {
"resourceType" : "Group" ,
"created" : "2023-10-01T00:00:00Z" ,
"lastModified" : "2023-10-01T00:01:00Z" ,
"location" : "Groups/ghi"
},
"schemas" : [
"urn:ietf:params:scim:schemas:core:2.0:Group"
]
}
チームの削除
SCIM API では、チームには追加データがリンクされているため、現在チームの削除はサポートされていません。削除を確認するにはアプリからチームを削除してください。
ロールリソース
SCIM ロールリソースは W&B のカスタムロールにマップされます。前述したように、/Roles エンドポイントは公式 SCIM スキーマの一部ではありません。W&B は W&B 組織内のカスタムロールの自動管理をサポートするために /Roles エンドポイントを追加しています。
カスタムロールの取得
エンドポイント: <host-url>/scim/Roles/{id}メソッド : GET説明 : ロールの一意の ID を提供し、カスタムロールの情報を取得します。リクエスト例 :
{
"description" : "A sample custom role for example" ,
"id" : "Um9sZTo3" ,
"inheritedFrom" : "member" , // 定義済みロールを示します
"meta" : {
"resourceType" : "Role" ,
"created" : "2023-11-20T23:10:14Z" ,
"lastModified" : "2023-11-20T23:31:23Z" ,
"location" : "Roles/Um9sZTo3"
},
"name" : "Sample custom role" ,
"organizationID" : "T3JnYW5pemF0aW9uOjE0ODQ1OA==" ,
"permissions" : [
{
"name" : "artifact:read" ,
"isInherited" : true // member 定義済みロールから継承された
...
...
{
"name" : "project:update" ,
"isInherited" : false // 管理者によって追加されたカスタム権限
],
"schemas" : [
""
]
}
カスタムロールの一覧
エンドポイント: <host-url>/scim/Rolesメソッド : GET説明 : W&B 組織のすべてのカスタムロールの情報を取得しますリクエスト例 :
{
"Resources" : [
{
"description" : "A sample custom role for example" ,
"id" : "Um9sZTo3" ,
"inheritedFrom" : "member" , // 定義済みロールからカスタムロールが継承されていることを示します
"meta" : {
"resourceType" : "Role" ,
"created" : "2023-11-20T23:10:14Z" ,
"lastModified" : "2023-11-20T23:31:23Z" ,
"location" : "Roles/Um9sZTo3"
},
"name" : "Sample custom role" ,
"organizationID" : "T3JnYW5pemF0aW9uOjE0ODQ1OA==" ,
"permissions" : [
{
"name" : "artifact:read" ,
"isInherited" : true // member 定義済みロールから継承された
...
...
{
"name" : "project:update" ,
"isInherited" : false // 管理者によって追加されたカスタム権限
],
"schemas" : [
""
]
},
{
"description" : "Another sample custom role for example" ,
"id" : "Um9sZToxMg==" ,
"inheritedFrom" : "viewer" , // 定義済みロールからカスタムロールが継承されていることを示します
"meta" : {
"resourceType" : "Role" ,
"created" : "2023-11-21T01:07:50Z" ,
"location" : "Roles/Um9sZToxMg=="
},
"name" : "Sample custom role 2" ,
"organizationID" : "T3JnYW5pemF0aW9uOjE0ODQ1OA==" ,
"permissions" : [
{
"name" : "launchagent:read" ,
"isInherited" : true // viewer 定義済みロールから継承された
...
...
{
"name" : "run:stop" ,
"isInherited" : false // 管理者によって追加されたカスタム権限
],
"schemas" : [
""
]
}
],
"itemsPerPage" : 9999 ,
"schemas" : [
"urn:ietf:params:scim:api:messages:2.0:ListResponse"
],
"startIndex" : 1 ,
"totalResults" : 2
}
カスタムロールの作成
エンドポイント : <host-url>/scim/Rolesメソッド : POST説明 : W&B 組織内で新しいカスタムロールを作成します。サポートされているフィールド :
フィールド
型
必要
name
文字列型
カスタムロールの名前
description
文字列型
カスタムロールの説明
permissions
オブジェクト配列型
各オブジェクトが name 文字列フィールドを含む許可オブジェクトの配列で、そのフィールドは w&bobject:operation の形式を持ちます。例えば、W&B Run に対する削除操作の許可オブジェクトは name を run:delete として持ちます。
inheritedFrom
文字列型
カスタムロールが継承する定義済みロール。それは member または viewer のいずれかになります。
{
"schemas" : ["urn:ietf:params:scim:schemas:core:2.0:Role" ],
"name" : "Sample custom role" ,
"description" : "A sample custom role for example" ,
"permissions" : [
{
"name" : "project:update"
}
],
"inheritedFrom" : "member"
}
{
"description" : "A sample custom role for example" ,
"id" : "Um9sZTo3" ,
"inheritedFrom" : "member" , // 定義済みロールを示します
"meta" : {
"resourceType" : "Role" ,
"created" : "2023-11-20T23:10:14Z" ,
"lastModified" : "2023-11-20T23:31:23Z" ,
"location" : "Roles/Um9sZTo3"
},
"name" : "Sample custom role" ,
"organizationID" : "T3JnYW5pemF0aW9uOjE0ODQ1OA==" ,
"permissions" : [
{
"name" : "artifact:read" ,
"isInherited" : true // member 定義済みロールから継承された
...
...
{
"name" : "project:update" ,
"isInherited" : false // 管理者によって追加されたカスタム権限
],
"schemas" : [
""
]
}
カスタムロールの削除
エンドポイント : <host-url>/scim/Roles/{id}メソッド : DELETE説明 : W&B 組織内のカスタムロールを削除します。慎重に使用してください。 カスタムロールから継承される定義済みロールは、操作前にカスタムロールに割り当てられていたすべてのユーザーに再び割り当てられます。リクエスト例 :
カスタムロールの権限の更新
エンドポイント : <host-url>/scim/Roles/{id}メソッド : PATCH説明 : W&B 組織内のカスタムロールにカスタム権限を追加または削除します。サポートされているフィールド :
フィールド
型
必要
operations
オブジェクト配列型
操作オブジェクトの配列
op
文字列型
操作オブジェクト内の操作のタイプ。それは add または remove のいずれかになります。
path
文字列型
操作オブジェクト内の静的フィールド。許可される唯一の値は permissions です。
value
オブジェクト配列型
各オブジェクトが name 文字列フィールドを含む許可オブジェクトの配列で、そのフィールドは w&bobject:operation の形式を持ちます。例えば、W&B Run に対する削除操作の許可オブジェクトは name を run:delete として持ちます。
{
"schemas" : ["urn:ietf:params:scim:api:messages:2.0:PatchOp" ],
"Operations" : [
{
"op" : "add" , // 操作のタイプを示し、他の可能な値は `remove`
"path" : "permissions" ,
"value" : [
{
"name" : "project:delete"
}
]
}
]
}
{
"description" : "A sample custom role for example" ,
"id" : "Um9sZTo3" ,
"inheritedFrom" : "member" , // 定義済みロールを示します
"meta" : {
"resourceType" : "Role" ,
"created" : "2023-11-20T23:10:14Z" ,
"lastModified" : "2023-11-20T23:31:23Z" ,
"location" : "Roles/Um9sZTo3"
},
"name" : "Sample custom role" ,
"organizationID" : "T3JnYW5pemF0aW9uOjE0ODQ1OA==" ,
"permissions" : [
{
"name" : "artifact:read" ,
"isInherited" : true // member 定義済みロールから継承された
...
...
{
"name" : "project:update" ,
"isInherited" : false // 更新前に管理者によって追加された既存のカスタム権限
{
"name" : "project:delete" ,
"isInherited" : false // 更新の一部として管理者によって追加された新規のカスタム権限
],
"schemas" : [
""
]
}
カスタムロールメタデータの更新
エンドポイント : <host-url>/scim/Roles/{id}メソッド : PUT説明 : W&B 組織内のカスタムロールの名前、説明、または継承ロールを更新します。この操作は、既存の、つまり非継承のカスタム権限には影響しません。サポートされているフィールド :
フィールド
型
必要
name
文字列型
カスタムロールの名前
description
文字列型
カスタムロールの説明
inheritedFrom
文字列型
カスタムロールが継承する定義済みロール。それは member または viewer のいずれかになります。
{
"schemas" : ["urn:ietf:params:scim:schemas:core:2.0:Role" ],
"name" : "Sample custom role" ,
"description" : "A sample custom role for example but now based on viewer" ,
"inheritedFrom" : "viewer"
}
{
"description" : "A sample custom role for example but now based on viewer" , // リクエストに応じて説明を変更
"id" : "Um9sZTo3" ,
"inheritedFrom" : "viewer" , // リクエストに応じて変更された定義済みロールを示します
"meta" : {
"resourceType" : "Role" ,
"created" : "2023-11-20T23:10:14Z" ,
"lastModified" : "2023-11-20T23:31:23Z" ,
"location" : "Roles/Um9sZTo3"
},
"name" : "Sample custom role" ,
"organizationID" : "T3JnYW5pemF0aW9uOjE0ODQ1OA==" ,
"permissions" : [
{
"name" : "artifact:read" ,
"isInherited" : true // viewer 定義済みロールから継承された
... // 更新後に member 定義済みロールにあるが viewer にはない権限は継承されません
"name" : "project:update" ,
"isInherited" : false // 管理者によって追加されたカスタム権限
{
"name" : "project:delete" ,
"isInherited" : false // 管理者によって追加されたカスタム権限
],
"schemas" : [
""
]
}
5.2.5 - 高度な IAM 設定
基本的な環境変数 に加えて、環境変数を使用して、専用クラウド または自己管理 インスタンスの IAM オプションを設定できます。
お使いのインスタンスにおける IAM のニーズに応じて、以下の環境変数のいずれかを選んでください。
Environment variable
説明
DISABLE_SSO_PROVISIONING
W&B インスタンスでのユーザー自動プロビジョニングを無効にするには、これを true に設定します。
SESSION_LENGTH
デフォルトのユーザーセッション有効期限を変更したい場合は、この変数を希望する時間数に設定します。例えば、SESSION_LENGTH を 24 に設定すると、セッション有効期限が 24 時間に設定されます。デフォルト値は 720 時間です。
GORILLA_ENABLE_SSO_GROUP_CLAIMS
OIDC ベースの SSO を使用している場合、この変数を true に設定すると、OIDC グループに基づいて W&B チームメンバーシップが自動化されます。ユーザー OIDC トークンに groups クレームを追加してください。これは、ユーザーが所属するべき W&B チームの名前をそれぞれのエントリーとして含む文字列配列であるべきです。配列には、ユーザーが所属するすべてのチームを含める必要があります。
GORILLA_LDAP_GROUP_SYNC
LDAP ベースの SSO を使用している場合、これを true に設定すると、LDAP グループに基づいて W&B チームメンバーシップが自動化されます。
GORILLA_OIDC_CUSTOM_SCOPES
OIDC ベースの SSO を使用している場合、W&B インスタンスがアイデンティティプロバイダーから要求する追加のスコープ を指定できます。W&B は、これらのカスタムスコープによって SSO 機能をいかなる形でも変更しません。
GORILLA_USE_IDENTIFIER_CLAIMS
OIDC ベースの SSO を使用している場合、この変数を true に設定すると、特定の OIDC クレームを使用してユーザーのユーザー名とフルネームを強制します。設定する場合は、preferred_username と name の OIDC クレームで強制されるユーザー名とフルネームを設定してください。ユーザー名には、英数字とアンダースコア、ハイフンの特殊文字のみを含めることができます。
GORILLA_DISABLE_PERSONAL_ENTITY
W&B インスタンスでの個人用ユーザープロジェクトを無効にするには、これを true に設定します。設定すると、ユーザーは個人用 Entities 内で新しい個人用プロジェクトを作成できなくなり、既存の個人用プロジェクトへの書き込みも無効になります。
GORILLA_DISABLE_ADMIN_TEAM_ACCESS
これを true に設定すると、組織またはインスタンスの管理者が自分で W&B チームに参加したり、自分を追加したりすることを制限します。これにより、Data & AI の関係者のみがチーム内のプロジェクトにアクセスできるようになります。
W&B は、GORILLA_DISABLE_ADMIN_TEAM_ACCESS などの設定を有効にする前にあらゆる影響を理解し、注意を払うことを推奨します。ご質問があれば、W&B チームにお問い合わせください。
5.3 - データセキュリティ
5.3.1 - 独自の バケット を持ち込む (BYOB)
自分のバケットを持ち込む (BYOB) を使用することで、W&B Artifacts やその他の機密性の高いデータを、自分のクラウドやオンプレミスのインフラストラクチャーに保存することができます。専用クラウド またはSaaS クラウド の場合、バケットに保存したデータは W&B が管理するインフラストラクチャーにコピーされません。
W&B SDK / CLI / UI とあなたのバケットとの通信は、事前署名URL を使用して行われます。
W&B はガベージコレクションプロセスを使用して W&B Artifacts を削除します。詳細はArtifacts の削除 をご覧ください。
バケットを設定する際にサブパスを指定することができ、これにより W&B がバケットのルートフォルダにファイルを保存しないようにできます。これにより、組織のバケットガバナンスポリシーによりよく適合するのに役立つかもしれません。
中央データベースとバケットに保存されるデータ
BYOB 機能を使用すると、データの一部は W&B の中央データベースに保存され、その他のデータは自分のバケットに保存されます。
データベース
ユーザー、チーム、Artifacts、Experiments、および Projects のメタデータ
Reports
実験ログ
システムメトリクス
バケット
実験ファイルとメトリクス
Artifact ファイル
メディアファイル
Run ファイル
設定オプション
ストレージバケットを設定するには、インスタンスレベル またはチームレベル の二つのスコープがあります。
インスタンスレベル: 組織内で関連権限を持つユーザーがインスタンスレベルのストレージバケットに保存されたファイルにアクセスできます。
チームレベル: W&B チームのメンバーは、チームレベルで設定されたバケットに保存されたファイルにアクセスできます。チームレベルのストレージバケットは、機密性の高いデータや厳しいコンプライアンス要件を持つチームに対してより厳格なデータ アクセス制御とデータの分離を提供します。
バケットをインスタンスレベルで設定し、組織内の1つ以上のチームでそれぞれ設定することができます。
たとえば、組織内に Kappa というチームがあるとします。あなたの組織 (およびチーム Kappa) は、デフォルトでインスタンスレベルのストレージバケットを使用します。次に Omega というチームを作成します。チーム Omega を作成する際に、そのチームのためのチームレベルのストレージバケットを設定することができます。チーム Omega によって生成されたファイルはチーム Kappa によってアクセスすることはできません。ただし、チーム Kappa によって作成されたファイルはチーム Omega によってアクセスすることができます。チーム Kappa のデータを分離したい場合は、彼らのためにチームレベルのストレージバケットを設定する必要があります。
チームレベルのストレージバケットは、特に異なる事業部門や部門がインスタンスを共有してインフラストラクチャーや管理資源を効果的に利用するため、
セルフマネージド インスタンスにも同じ恩恵を提供します。これは、別々のプロジェクトチームが別々の顧客向けの AI ワークフローを管理する企業にも適用されます。
利用可能性マトリックス
以下の表は、異なる W&B サーバーデプロイメントタイプでの BYOB の利用可能性を示しています。 Xは、そのデプロイメントタイプで機能が利用可能であることを示します。
W&B サーバーデプロイメントタイプ
インスタンスレベル
チームレベル
追加情報
専用クラウド
X
X
Amazon Web Services、Google Cloud Platform、Microsoft Azure のいずれでもインスタンスとチームレベルの BYOB が利用可能です。チームレベルの BYOB については、クラウドネイティブのストレージバケットに同じクラウドまたは別のクラウド、またはあなたのクラウドやオンプレミスのインフラストラクチャーにホストされた MinIO のような S3 互換の安全なストレージにも接続できます。
SaaS クラウド
該当なし
X
チームレベルの BYOB は Amazon Web Services および Google Cloud Platform のみで利用可能です。W&B は Microsoft Azure のデフォルトで唯一のストレージバケットを完全に管理しています。
セルフマネージド
X
X
インスタンスレベルの BYOB がデフォルトです。なぜなら、インスタンスは完全にあなたによって管理が行われるためです。もしあなたのセルフマネージドインスタンスがクラウドにある場合、チームレベルの BYOB のために同じまたは別のクラウドにクラウドネイティブのストレージバケットに接続できます。また、インスタンスまたはチームレベルの BYOB のいずれかに MinIO のような S3 互換の安全なストレージを使用することもできます。
専用クラウドまたはセルフマネージドインスタンスの場合、インスタンスレベルまたはチームレベルのストレージバケットを一度設定すると、そのスコープのストレージバケットを変更したり再設定したりすることはできません。それにはデータを別のバケットに移行したり、主な製品ストレージの関連する参照をリマップしたりすることができないことも含まれます。W&B では、インスタンスおよびチームレベルのいずれかのスコープのストレージバケットを設定する前に、ストレージバケットのレイアウトを注意深く計画することをお勧めします。質問がある場合は、W&B チームにご連絡ください。
チームレベル BYOB のためのクロスクラウドまたは S3 互換ストレージ
専用クラウド または セルフマネージド インスタンスにおいて、別のクラウドのクラウドネイティブのストレージバケットまたは MinIO のような S3 互換のストレージバケットに接続して、チームレベル BYOB を利用することができます。
クロスクラウドまたは S3 互換のストレージの利用を有効にするには、次のフォーマットのいずれかを使用してストレージバケットを指定し、W&B インスタンス用のGORILLA_SUPPORTED_FILE_STORES 環境変数を設定します。
専用クラウドまたはセルフマネージドインスタンスでチームレベル BYOB のために S3 互換のストレージを設定する
次のフォーマットを使用してパスを指定します：
s3://<accessKey>:<secretAccessKey>@<url_endpoint>/<bucketName>?region=<region>?tls=true
regionパラメータは必須です。ただし、W&B インスタンスが AWS 内にあり、W&B インスタンスノードで設定されているAWS_REGION が S3 互換ストレージ用に設定されたリージョンと一致している場合を除きます。
専用クラウドまたはセルフマネージドインスタンスでチームレベル BYOB のためにクロスクラウドネイティブストレージを設定する
W&B インスタンスとストレージバケットの場所に特有のフォーマットでパスを指定します：
GCP または Azure にある W&B インスタンスから AWS にあるバケットへ：
s3://<accessKey>:<secretAccessKey>@<s3_regional_url_endpoint>/<bucketName>
GCP または AWS にある W&B インスタンスから Azure にあるバケットへ：
az://:<urlEncodedAccessKey>@<storageAccountName>/<containerName>
AWS または Azure にある W&B インスタンスから GCP にあるバケットへ：
gs://<serviceAccountEmail>:<urlEncodedPrivateKey>@<bucketName>
チームレベル BYOB 用の S3 互換ストレージへの接続は
SaaS クラウド では利用できません。また、
SaaS クラウド の場合、チームレベル BYOB 用の AWS バケットへの接続はクロスクラウドで行われます。これは、そのインスタンスが GCP に存在するためです。そのクロスクラウドの接続は、以前説明した専用クラウドやセルフマネージドインスタンスのようにアクセキーおよび環境変数ベースのメカニズムを使用しません。
詳しくは support@wandb.com までお問い合わせください。
W&B プラットフォームと同じクラウドのクラウドストレージ
ユースケースに基づいて、チームまたはインスタンスレベルにストレージバケットを設定します。ストレージバケットが調達または設定される方法は、それがどのレベルで設定されているかにかかわらず同じです。ただし、Azure のアクセスメカニズムに不一致があります。
W&B は、ストレージバケットをプロビジョニングするために W&B が管理する Terraform モジュールを使用して、必要なアクセスメカニズムと関連する IAM 権限と共に使用することをお勧めします：
KMS キーのプロビジョニング
W&B では、S3 バケット上のデータを暗号化および復号化するために KMS キーをプロビジョニングする必要があります。キーの使用タイプは ENCRYPT_DECRYPT である必要があります。キーに次のポリシーを割り当てます：
{
"Version" : "2012-10-17" ,
"Statement" : [
{
"Sid" : "Internal" ,
"Effect" : "Allow" ,
"Principal" : { "AWS" : "<Your_Account_Id>" },
"Action" : "kms:*" ,
"Resource" : "<aws_kms_key.key.arn>"
},
{
"Sid" : "External" ,
"Effect" : "Allow" ,
"Principal" : { "AWS" : "<aws_principal_and_role_arn>" },
"Action" : [
"kms:Decrypt" ,
"kms:Describe*" ,
"kms:Encrypt" ,
"kms:ReEncrypt*" ,
"kms:GenerateDataKey*"
],
"Resource" : "<aws_kms_key.key.arn>"
}
]
}
<Your_Account_Id> および <aws_kms_key.key.arn> を適宜置き換えてください。
SaaS クラウド または 専用クラウド を使用している場合は、<aws_principal_and_role_arn> を次の値で置き換えてください：
SaaS クラウド の場合: arn:aws:iam::725579432336:role/WandbIntegration専用クラウド の場合: arn:aws:iam::830241207209:root
このポリシーは、AWS アカウントに対してキーへの完全なアクセス権を与え、W&B プラットフォームをホスティングする AWS アカウントに必要な権限も割り当てます。KMS キーの ARN を記録してください。
S3 バケットのプロビジョニング
AWS アカウントに S3 バケットをプロビジョニングするために、以下の手順に従ってください：
お好みの名前で S3 バケットを作成します。必要に応じてフォルダーを作成し、サブパスとして設定して W&B のすべてのファイルを保存します。
バケットのバージョニングを有効にします。
前のステップで生成した KMS キーを使用して、サーバー側の暗号化を有効にします。
以下のポリシーで CORS を設定します：
[
{
"AllowedHeaders" : [
"*"
],
"AllowedMethods" : [
"GET" ,
"HEAD" ,
"PUT"
],
"AllowedOrigins" : [
"*"
],
"ExposeHeaders" : [
"ETag"
],
"MaxAgeSeconds" : 3600
}
]
W&B プラットフォームのホスティング先の AWS アカウントに必要な S3 権限を付与します。これにより、AI ワークロードがクラウドインフラストラクチャーやユーザーブラウザーでバケットにアクセスするための事前署名された URL が生成されます。
{
"Version" : "2012-10-17" ,
"Id" : "WandBAccess" ,
"Statement" : [
{
"Sid" : "WAndBAccountAccess" ,
"Effect" : "Allow" ,
"Principal" : { "AWS" : "<aws_principal_and_role_arn>" },
"Action" : [
"s3:GetObject*" ,
"s3:GetEncryptionConfiguration" ,
"s3:ListBucket" ,
"s3:ListBucketMultipartUploads" ,
"s3:ListBucketVersions" ,
"s3:AbortMultipartUpload" ,
"s3:DeleteObject" ,
"s3:PutObject" ,
"s3:GetBucketCORS" ,
"s3:GetBucketLocation" ,
"s3:GetBucketVersioning"
],
"Resource" : [
"arn:aws:s3:::<wandb_bucket>" ,
"arn:aws:s3:::<wandb_bucket>/*"
]
}
]
}
<wandb_bucket> を適宜置き換え、バケット名を記録してください。もし専用クラウドを使用している場合、インスタンスレベルの BYOB の場合は W&B チームとバケット名を共有してください。どのデプロイメントタイプにおいてもチームレベルの BYOB の場合、チーム作成時にバケットを設定してください 。
SaaS クラウド または 専用クラウド を使用している場合、<aws_principal_and_role_arn> を次の値で置き換えてください。
SaaS クラウド : arn:aws:iam::725579432336:role/WandbIntegration専用クラウド : arn:aws:iam::830241207209:root
詳細については、AWS セルフマネージドホスティングガイド をご覧ください。
GCS バケットのプロビジョニング
GCP プロジェクト内で GCS バケットをプロビジョニングするために、以下の手順に従います：
好みの名前で GCS バケットを作成します。必要に応じてフォルダーを作成し、サブパスとして設定して W&B のすべてのファイルを保存します。
ソフト削除を有効にします。
オブジェクトのバージョニングを有効にします。
暗号化タイプを Google-managed に設定します。
UI では不可能なので、gsutil を用いて CORS ポリシーを設定します。
cors-policy.json という名前のファイルをローカルに作成します。
ファイルに以下の CORS ポリシーをコピーして保存します。
[
{
"origin" : ["*" ],
"responseHeader" : ["Content-Type" ],
"exposeHeaders" : ["ETag" ],
"method" : ["GET" , "HEAD" , "PUT" ],
"maxAgeSeconds" : 3600
}
]
<bucket_name> を正しいバケット名で置き換えて gsutil を実行します。
gsutil cors set cors-policy.json gs://<bucket_name>
バケットのポリシーを確認します。<bucket_name> を正しいバケット名で置き換えます。
gsutil cors get gs://<bucket_name>
SaaS クラウド または 専用クラウド を使用している場合、W&B プラットフォームにリンクされた GCP サービスアカウントに Storage Admin ロールを付与します：
SaaS クラウド の場合、アカウントは: wandb-integration@wandb-production.iam.gserviceaccount.com専用クラウド の場合、アカウントは: deploy@wandb-production.iam.gserviceaccount.com
バケット名を記録してください。専用クラウドを使用している場合、インスタンスレベルの BYOB ではバケット名を W&B チームと共有してください。どのデプロイメントタイプにおいてもチームレベルの BYOB の場合、チーム作成時にバケットを設定してください 。
Azure Blob Storage のプロビジョニング
インスタンスレベルの BYOB の場合、この Terraform モジュール を使用していない場合は、以下のステップに従って Azure サブスクリプション内で Azure Blob Storage バケットをプロビジョニングします：
ストレージ アカウント アクセス キーを生成し、ストレージ アカウント名と共に記録します。専用クラウドを使用している場合、ストレージ アカウント名とアクセス キーを安全な共有方法で W&B チームと共有します。
チームレベルの BYOB の場合、W&B はTerraform を使用して、必要なアクセスメカニズムと権限と共に Azure Blob Storage バケットをプロビジョニングすることをお勧めします。専用クラウドを使用する場合、インスタンスのための OIDC 発行者 URL を提供します。バケットを設定する際に必要な詳細をメモしてください：
ストレージ アカウント名
ストレージ コンテナ名
マネージドアイデンティティ クライアント ID
Azure テナント ID
W&B での BYOB の設定
W&B チーム作成時にチームレベルでストレージバケットを設定するには：
チーム名 フィールドにチーム名を入力します。
ストレージタイプ オプションとして 外部ストレージ を選択します。
ドロップダウンから 新しいバケット を選択するか、既存のバケットを選択します。
複数の W&B チームが同じクラウドストレージバケットを使用できます。これを有効にするには、ドロップダウンから既存のクラウドストレージバケットを選択してください。
クラウドプロバイダー ドロップダウンからクラウドプロバイダーを選択します。
名前 フィールドにストレージバケットの名前を入力します。Azure で 専用クラウド または セルフマネージド インスタンスを持っている場合は、アカウント名 および コンテナ名 の値を入力してください。
(オプション) バケットのサブパスをオプションの パス フィールドに入力します。そうすることで、W&B がバケットのルートにあるフォルダにファイルを保存しないようにすることができます。
(AWS バケットを使用する場合はオプション) KMSキーARN フィールドに暗号化キーの ARN を入力します。
(Azure バケットを使用する場合はオプション) テナントID および マネージド アイデンティティ クライアント ID の値を入力します。
(SaaS クラウド でオプション) チームの作成時にオプションでチームメンバーを招待します。
チームを作成 ボタンを押します。
バケットにアクセスする際や設定が無効な場合、ページの下部にエラーや警告が表示されます。
専用クラウドまたはセルフマネージドインスタンスのインスタンスレベル BYOB を設定するには、support@wandb.com まで W&B サポートにお問い合わせください。
5.3.2 - BYOB に事前署名済みの URL を使用してアクセスする
W&B は事前署名付き URL を使用して、AI ワークロードやユーザー ブラウザからの blob ストレージへのアクセスを簡素化します。事前署名付き URL の基本情報については、AWS S3 の事前署名付き URL 、Google Cloud Storage の署名付き URL 、Azure Blob Storage の共有アクセス署名 を参照してください。
必要に応じて、ネットワーク内の AI ワークロードまたはユーザー ブラウザー クライアントが W&B プラットフォームから事前署名付き URL を要求します。その後、W&B プラットフォームは関連する blob ストレージにアクセスして、必要な権限で事前署名付き URL を生成し、クライアントに返します。クライアントは、事前署名付き URL を使用して blob ストレージにアクセスし、オブジェクトのアップロードまたは取得操作を行います。オブジェクトのダウンロードの URL は 1 時間で期限切れになり、巨大なオブジェクトをチャンクでアップロードするのに時間がかかる可能性があるため、オブジェクトのアップロードについては 24 時間有効です。
チームレベルのアクセス制御
各事前署名付き URL は、W&B プラットフォームのチームレベルのアクセス制御 に基づいて特定のバケットに限定されます。ユーザーがセキュア ストレージ コネクタ を使用して blob ストレージ バケットにマッピングされているチームの一員であり、そのユーザーがそのチームにのみ属している場合、彼らの要求に対して生成された事前署名付き URL には、他のチームにマッピングされている blob ストレージ バケットにアクセスする権限がありません。
W&B は、ユーザーを所属すべきチームのみに追加することを推奨します。
ネットワーク制限
W&B は、IAM ポリシーに基づくバケットの制限を使用して、事前署名付き URL を使用して blob ストレージにアクセスできるネットワークを制限することを推奨します。
AWS の場合、VPC または IP アドレスに基づくネットワーク制限 を使用できます。これにより、あなたの AI ワークロードが稼働しているネットワークから、または W&B UI を使用してアーティファクトにアクセスする場合にユーザーマシンにマッピングされるゲートウェイの IP アドレスから、のみ W&B に特化したバケットにアクセスできることが保証されます。
監査ログ
W&B は、blob ストレージ固有の監査ログに加えて、W&B 監査ログ を使用することを推奨します。後者については、AWS S3 のアクセスログ 、Google Cloud Storage の監査ログ 、Azure blob storage の監視 を参照してください。管理者とセキュリティ チームは、W&B 製品でどのユーザーが何をしているかを追跡し、特定のユーザーに対していくつかの操作を制限する必要があると判断した場合に必要な対策を講じるために監査ログを使用できます。
事前署名付き URL は、W&B でサポートされている唯一の blob ストレージ アクセス メカニズムです。W&B は、リスク許容度に応じて、セキュリティ制御の上記リストの一部またはすべてを設定することを推奨します。
5.3.3 - 専用クラウドのための IP 許可リストを設定する
You can restrict access to your Dedicated Cloud インスタンスを許可された IP アドレスのリストからのみとすることができます。これは、AI ワークロードから W&B API へのアクセスおよびユーザーのブラウザから W&B アプリの UI へのアクセスにも適用されます。Dedicated Cloud インスタンスに対して IP ホワイトリストが設定されると、W&B は他の許可されていない場所からの要求を拒否します。Dedicated Cloud インスタンスの IP ホワイトリスト設定については、W&B チームにお問い合わせください。
IP ホワイトリストは、AWS、GCP、Azure 上の Dedicated Cloud インスタンスで利用可能です。
セキュアなプライベート接続 とともに IP ホワイトリストを使用できます。セキュアなプライベート接続とともに IP ホワイトリストを使用する場合、W&B は AI ワークロードからのすべてのトラフィックおよび可能であればユーザーのブラウザからのトラフィックの大部分にセキュアなプライベート接続を使用し、特権のある場所からのインスタンス管理には IP ホワイトリストを使用することを推奨します。
W&B は、個々の
/32 IP アドレスではなく、企業または事業 egress ゲートウェイに割り当てられた
CIDR ブロック の使用を強く推奨します。個々の IP アドレスの使用は、スケーラブルではなく、クラウドごとに厳しい制限があります。
5.3.4 - 専用クラウドへのプライベート接続を設定します
クラウドプロバイダーの安全なプライベートネットワークを介して、Dedicated Cloud インスタンスに接続できます。これは、AI ワークロードから W&B API へのアクセス、およびオプションでユーザーのブラウザから W&B アプリ UI へのアクセスにも適用されます。プライベート接続を使用する場合、関連するリクエストとレスポンスはパブリックネットワークやインターネットを経由しません。
安全なプライベート接続は、専用クラウドの高度なセキュリティオプションとして間もなく利用可能になります。
安全なプライベート接続は、AWS、GCP、および Azure 上の専用クラウドインスタンスで利用可能です：
一度有効にすると、W&B はインスタンス用のプライベートエンドポイントサービスを作成し、接続するための関連する DNS URI を提供します。それにより、クラウドアカウント内にプライベートエンドポイントを作成し、関連するトラフィックをプライベートエンドポイントサービスにルーティングできます。プライベートエンドポイントは、クラウド VPC または VNet 内で動作する AI トレーニングワークロードに対して、設定が容易です。ユーザーブラウザから W&B アプリ UI へのトラフィックに対しても同じメカニズムを使用するには、企業ネットワークからクラウドアカウント内のプライベートエンドポイントへの適切な DNS ベースのルーティングを設定する必要があります。
この機能を使用したい場合は、W&B チームにご連絡ください。
IP allowlisting とともに安全なプライベート接続を使用できます。IP allowlisting のために安全なプライベート接続を使用する場合、W&B は可能であれば、IP allowlisting を特権的な場所からのインスタンス管理のために使用しつつ、AI ワークロードからのすべてのトラフィックと、ユーザーブラウザからのトラフィックの大部分に対して安全なプライベート接続を確保することをお勧めします。
5.3.5 - 専用クラウドでのデータ暗号化
W&B は、クラウドごとの customer-managed encryption key (CMEK) 機能を使用して、各 専用クラウド の W&B 管理データベースとオブジェクトストレージを暗号化するために、W&B 管理のクラウドネイティブキーを使用します。この場合、W&B はクラウドプロバイダの customer として機能し、W&B プラットフォームをサービスとして提供します。W&B 管理のキーを使用するということは、W&B がクラウドごとにデータを暗号化するために使用するキーを管理するということであり、これにより、すべての顧客に対して非常に安全でセキュアなプラットフォームを提供するという約束を強化します。
W&B は、各顧客インスタンスのデータを暗号化するために unique key を使用し、専用クラウドテナント間のもう一つの分離のレイヤーを提供します。この機能は AWS、Azure、GCP で利用可能です。
2024 年 8 月より前に W&B がプロビジョニングした GCP と Azure 上の専用クラウドインスタンスは、W&B 管理データベースとオブジェクトストレージを暗号化するためにデフォルトのクラウドプロバイダ管理キーを使用しています。2024 年 8 月以降に W&B が作成した新しいインスタンスのみが、関連する暗号化のために W&B 管理のクラウドネイティブキーを使用しています。
AWS 上の専用クラウドインスタンスは、2024 年 8 月より前から W&B 管理のクラウドネイティブキーを暗号化に使用しています。
W&B は、通常、顧客が自身のクラウドネイティブキーを持ち込んで専用クラウドインスタンス内の W&B 管理データベースとオブジェクトストレージを暗号化することを許可していません。なぜなら、複数のチームや人物が、さまざまな理由でそのクラウドインフラストラクチャーにアクセスできる可能性があるためです。これらのチームや人物の中には、組織のテクノロジースタックにおける重要なコンポーネントとして W&B を理解していないケースがあり、クラウドネイティブキーを完全に削除したり、W&B のアクセスを取り消したりする可能性があります。このような行動は、組織の W&B インスタンス内のすべてのデータを破損させ、回復不可能な状態にする可能性があります。
もし組織が専用クラウドを AI ワークフローで使用するために、W&B 管理データベースとオブジェクトストレージを暗号化するために独自のクラウドネイティブキーを使用する必要がある場合、W&B は例外的にレビューを行うことができます。承認された場合、暗号化に独自のクラウドネイティブキーを使用することは、W&B 専用クラウドの shared responsibility model に準拠します。専用クラウドインスタンスが稼働中に組織の任意のユーザーがキーを削除したり、W&B のアクセスを取り消したりした場合、W&B はそれに伴うデータの損失や破損に対して責任を負わず、そのデータの回復も行いません。
5.4 - プライバシー設定を設定する
組織およびチームの管理者は、それぞれのスコープでプライバシー設定を設定することができます。組織スコープで設定されると、組織の管理者はその組織内のすべてのチームに対してその設定を施行します。
W&Bは、組織の管理者が事前にすべてのチーム管理者やユーザーにそのことを伝えた上でプライバシー設定を施行することを推奨します。これは、ワークフローに予期しない変更が生じるのを避けるためです。
チームのプライバシー設定を設定する
チーム管理者は、チームの設定 タブのプライバシーセクション内でそれぞれのチームのプライバシー設定を行うことができます。各設定は、組織スコープで施行されていない限り、設定可能です。
このチームをすべての非メンバーから隠す
将来のチームプロジェクトをすべて非公開にする（公開共有は許可されません）
すべてのチームメンバーが他のメンバーを招待することを許可する（管理者のみでなく）
プライベートプロジェクトのReportsをチーム外に公開して共有することをオフにする。これにより既存のマジックリンクをオフにします。
組織のメールドメインが一致するユーザーがこのチームに参加することを許可する。
コードの保存をデフォルトで有効にする。
すべてのチームに対するプライバシー設定を施行する
組織の管理者は、アカウントまたは組織ダッシュボードの設定 タブのプライバシーセクションから、その組織内のすべてのチームに対してプライバシー設定を施行することができます。組織の管理者が設定を施行した場合、チーム管理者はそれぞれのチーム内でその設定を変更することはできません。
チームの公開範囲制限を施行する
このオプションを有効にして、すべてのチームを非メンバーから隠します
将来のプロジェクトに対するプライバシーを施行する
このオプションを有効にして、すべてのチームの将来のプロジェクトを非公開または制限付き にします
招待管理を施行する
このオプションを有効にして、管理者以外のメンバーが任意のチームに招待することを禁止します
レポート共有管理を施行する
このオプションを有効にして、プライベートプロジェクトのReportsの公開共有をオフにし、既存のマジックリンクを無効にします
チームの自己参加制限を施行する
デフォルトのコード保存制限を施行する
このオプションを有効にして、すべてのチームでのコード保存をデフォルトでオフにします
5.5 - 監視と利用状況
5.5.1 - ユーザーのアクティビティを監査ログで追跡する
W&B の監査ログを使用して、組織内のユーザー活動を追跡し、企業のガバナンス要件に準拠します。監査ログは JSON フォーマットで利用可能です。監査ログスキーマ を参照してください。
監査ログへのアクセス方法は、W&B プラットフォームのデプロイメントタイプによって異なります:
監査ログを取得した後、Pandas 、Amazon Redshift 、Google BigQuery 、Microsoft Fabric などのツールを使用して分析できます。監査ログの分析ツールによっては JSON をサポートしていないものもあります。分析ツールのドキュメントを参照して、分析前に JSON 形式の監査ログを変換するためのガイドラインと要件をご確認ください。
監査ログスキーマ
この表は、監査ログエントリに現れる可能性のあるすべてのキーをアルファベット順に示しています。アクションと状況によって、特定のログエントリには、可能なフィールドのサブセットのみが含まれる場合があります。
キー
定義
actionイベントのアクション 。
actor_emailアクションを開始したユーザーのメールアドレス（該当する場合）。
actor_ipアクションを開始したユーザーの IP アドレス。
actor_user_idアクションを実施したログインユーザーの ID（該当する場合）。
artifact_assetアクションに関連するアーティファクト ID（該当する場合）。
artifact_digestアクションに関連するアーティファクトダイジェスト（該当する場合）。
artifact_qualified_nameアクションに関連するアーティファクトの完全名（該当する場合）。
artifact_sequence_assetアクションに関連するアーティファクトシーケンス ID（該当する場合）。
cli_versionアクションを開始した Python SDK のバージョン（該当する場合）。
entity_assetアクションに関連するエンティティまたはチーム ID（該当する場合）。
entity_nameアクションに関連するエンティティまたはチーム名（該当する場合）。
project_assetアクションに関連するプロジェクト（該当する場合）。
project_nameアクションに関連するプロジェクトの名前（該当する場合）。
report_assetアクションに関連するレポート ID（該当する場合）。
report_nameアクションに関連するレポートの名前（該当する場合）。
response_codeアクションの HTTP レスポンスコード（該当する場合）。
timestampイベントの時間を RFC3339 形式 で示します。例えば、2023-01-23T12:34:56Z は 2023 年 1 月 23 日 12 時 34 分 56 秒 UTC を示します。
user_assetアクションが影響を与えるユーザーアセット（アクションを実行するユーザーではなく）（該当する場合）。
user_emailアクションが影響を与えるユーザーのメールアドレス（アクションを実行するユーザーのメールアドレスではなく）（該当する場合）。
個人を特定できる情報 (PII)
個人を特定できる情報 (PII) は API エンドポイントオプションを使用することによってのみ利用可能です。
監査ログの取得
W&B インスタンスの監査ログは、Audit Logging API を使用して、組織またはインスタンス管理者が取得できます。そのエンドポイントは audit_logs/ です。
インスタンスに対する正しい API エンドポイントを決定します：
次のステップで、<API-endpoint> を実際の API エンドポイントで置き換えてください。
基本エンドポイントから完全な API エンドポイントを構築し、必要に応じて URL パラメータを含めます：
anonymize: true に設定すると、PII を削除します。デフォルトは false です。監査ログ取得時の PII を除外 を参照してください。SaaS Cloud ではサポートされていません。
numDays: today - numdays から最新のログまで取得されます。デフォルトは 0 で、今日のログのみを返します。SaaS Cloud では過去最大 7 日分の監査ログを取得できます。
startDate: オプションの日付、YYYY-MM-DD 形式で指定します。 SaaS Cloud でのみサポートされています。
startDate と numDays の相互作用：
startDate と numDays の両方を設定すると、startDate から startDate + numDays の範囲でログが返されます。startDate を省略して numDays を含めると、today から numDays までの範囲でログが返されます。startDate と numDays のどちらも設定しないと、今日のログのみが返されます。
Web ブラウザーや Postman 、HTTPie 、cURL などのツールを使用して、構築した完全修飾 API エンドポイントに対して HTTP GET リクエストを実行します。
API レスポンスには、新しい行で区切られた JSON オブジェクトが含まれます。監査ログがインスタンスレベルのバケットに同期される場合と同じように、そのオブジェクトには スキーマ に記載されたフィールドが含まれます。その場合、監査ログはバケット内の /wandb-audit-logs ディレクトリー内に配置されます。
基本認証を使用する
Audit logs API に アクセスするために基本認証を API キーで使用するには、HTTP リクエストの Authorization ヘッダーを Basic という文字列の後にスペースを置き、 その後にフォーマット username:API-KEY で base-64 エンコードされた文字列を設定します。すなわち、ユーザー名と API キーを : 文字で区切って、その結果を base-64 エンコードします。例えば、demo:p@55w0rd として認証するには、ヘッダーは Authorization: Basic ZGVtbzpwQDU1dzByZA== となります。
監査ログ取得時の PII を除外する
Self-managed および Dedicated Cloud では、W&B の組織やインスタンス管理者が監査ログを取得する際に PII を除外できます。SaaS Cloud では、監査ログの関連フィールドを常に API エンドポイントが返します。この設定は変更できません。
PII を除外するには、URL パラメータ anonymize=true を渡します。例えば、W&B インスタンスの URL が https://mycompany.wandb.io で、過去 1 週間のユーザー活動の監査ログを取得し、PII を除外したい場合、以下のような API エンドポイントを使用します：
https://mycompany.wandb.io/admin/audit_logs?numDays=7&anonymize=true.
アクション
この表は、W&B によって記録される可能性のあるアクションをアルファベット順で説明しています。
アクション
定義
artifact:createアーティファクトが作成されます。
artifact:delete アーティファクトが削除されます。
artifact:readアーティファクトが読み取られます。
project:deleteプロジェクトが削除されます。
project:readプロジェクトが読み取られます。
report:readレポートが読み取られます。 1
run:delete_many複数の run が削除されます。
run:deleterun が削除されます。
run:stoprun が停止されます。
run:undelete_many複数の run がゴミ箱から復元されます。
run:update_many複数の run が更新されます。
run:updaterun が更新されます。
sweep:create_agentsweep agent が作成されます。
team:create_service_accountチーム用のサービスアカウントが作成されます。
team:createチームが作成されます。
team:deleteチームが削除されます。
team:invite_userユーザーがチームに招待されます。
team:uninviteユーザーまたはサービスアカウントがチームから招待取り消されます。
user:create_api_keyユーザーの API キーが作成されます。1
user:createユーザーが作成されます。 1
user:deactivateユーザーが無効化されます。1
user:delete_api_keyユーザーの API キーが削除されます。1
user:initiate_loginユーザーがログインを開始します。1
user:loginユーザーがログインします。1
user:logoutユーザーがログアウトします。1
user:permanently_deleteユーザーが完全に削除されます。1
user:reactivateユーザーが再活性化されます。1
user:readユーザーのプロフィールが読み取られます。1
user:updateユーザーが更新されます。1
1 : SaaS Cloud では、監査ログは次の項目で収集されません:
オープンまたはパブリックプロジェクトの場合。
report:read のアクション。特定の組織に関連付けられていない User のアクション。
5.5.2 - Prometheus モニタリングを使用する
Prometheus を W&B サーバーと一緒に使用します。Prometheus のインストールは Kubernetes ClusterIP サービス として公開されます。
以下の手順に従って、Prometheus メトリクスエンドポイント (/metrics) にアクセスします：
Kubernetes CLI ツールキットの kubectl を使用してクラスターに接続します。詳細については、Kubernetes の クラスターへのアクセス ドキュメントを参照してください。
クラスターの内部アドレスを見つけます：
kubectl describe svc prometheus
Kubernetes クラスターで実行中のコンテナ内でシェルセッションを開始し、kubectl exec<internal address>/metrics エンドポイントにアクセスします。
以下のコマンドをコピーしてターミナルで実行し、<internal address> を内部アドレスに置き換えます：
kubectl exec <internal address>/metrics
テストポッドが開始され、ネットワーク内の何かにアクセスするためだけに exec することができます：
kubectl run -it testpod --image= alpine bin/ash --restart= Never --rm
そこから、ネットワークへのアクセスを内部に保つか、kubernetes nodeport サービスで自分で公開するかを選択できます。
5.5.3 - Slack アラートの設定
Integrate W&B Server with Slack .
W&B 専用クラウドデプロイメントでの Slack アラートの設定を示した
ビデオを見る (6 分)。
Slack アプリケーションを作成する
以下の手順に従って Slack アプリケーションを作成してください。
https://api.slack.com/apps にアクセスし、Create an App を選択します。
App Name フィールドにアプリの名前を入力します。
アプリを開発したい Slack ワークスペースを選択します。アラートに使用する予定のワークスペースと同じワークスペースを使用していることを確認してください。
Slack アプリケーションを設定する
左側のサイドバーで OAth & Permissions を選択します。
Scopes セクションで、ボットに incoming_webhook スコープを追加します。スコープは、アプリに開発ワークスペースでのアクションを実行する権限を与えます。
Bot の OAuth スコープについての詳細は、Slack API ドキュメントの「Understanding OAuth scopes for Bots」チュートリアルを参照してください。
W&B インストールを指すようにリダイレクト URL を設定します。ローカルシステム設定で指定されたホスト URL と同じ URL を使用してください。インスタンスへの異なる DNS マッピングを持つ場合は、複数の URL を指定できます。
Save URLs を選択します。
Restrict API Token Usage で、オプションとして W&B インスタンスの IP または IP 範囲を許可リストに指定できます。許可された IP アドレスの制限は、Slack アプリケーションのセキュリティをより強化します。
Slack アプリケーションを W&B に登録する
W&B インスタンスの System Settings または System Console ページに移動します。デプロイメントに応じて異なります。
使用している System ページに応じて、以下のオプションのいずれかを実行します：
Slack client ID と Slack secret を入力し、Save をクリックします。設定の基本情報でアプリケーションのクライアント ID とシークレットを見つけることができます。
W&B アプリケーションで Slack インテグレーションを設定して、すべてが正常に動作していることを確認します。
5.5.4 - 組織のダッシュボードを表示する
組織の W&B 使用状況を確認する
組織のダッシュボードを使用して、組織の W&B 使用状況の全体像を把握できます。このダッシュボードはタブごとに整理されています。
Users : 各ユーザーの名前、メール、チーム、役割、最後の活動を含む詳細をリストします。Service accounts : サービスアカウントに関する詳細をリストし、サービスアカウントを作成することができます。Activity : 各ユーザーの活動に関する詳細をリストします。Teams : 各チームのユーザー数や追跡時間を含む詳細をリストし、管理者がチームに参加できるようにします。Billing : 組織の請求内容を要約し、請求レポートを実行およびエクスポートすることができ、ライセンスの期限などの詳細を示します。Settings : カスタムロールとプライバシーや認証に関連する設定を構成できます。
ユーザーのステータスを確認する
Users タブには、すべてのユーザーと各ユーザーに関するデータが一覧表示されます。Last Active 列は、ユーザーが招待を受け入れたかどうか、およびユーザーの現在のステータスを示します。
Invite pending : 管理者が招待を送信しましたが、ユーザーが招待を受け入れていない状態。Active : ユーザーが招待を受け入れ、アカウントを作成した状態。- : ユーザーは以前にアクティブでしたが、過去6カ月間活動していない状態。Deactivated : 管理者がユーザーのアクセスを取り消した状態。
アクティビティでユーザーのリストを並べ替えるには、Last Active 列の見出しをクリックします。
組織の W&B 利用方法を確認して共有する
Users タブから、組織の W&B 利用方法の詳細を CSV 形式で確認できます。
Invite new user ボタンの横にあるアクション ... メニューをクリックします。Export as CSV をクリックします。ダウンロードされた CSV ファイルには、組織の各ユーザーに関する詳細（ユーザー名、メールアドレス、最後のアクティブ時刻、役割など）が記載されています。
ユーザーのアクティビティを確認する
Users タブ内の Last Active 列を使用して、個々のユーザーの Activity summary を取得します。
Last Active でユーザーのリストを並べ替えるには、列名をクリックします。ユーザーの最後のアクティビティについての詳細を見るには、ユーザーの Last Active フィールドにマウスを重ねます。ツールチップが表示され、ユーザーが追加された日時と、ユーザーがアクティブであった総日数が示されます。
ユーザーが アクティブ であるとは以下の場合を指します:
W&B にログインする。
W&B アプリ内の任意のページを見る。
run をログする。
SDK を使用して実験を追跡する。
W&B サーバーと何らかの方法でやり取りする。
時間経過によるアクティブユーザーの確認
Activity タブのプロットを利用して、時間の経過とともに何人のユーザーがアクティブであったかの総合的なビューを取得できます。
Activity タブをクリックします。Total active users プロットは、一定期間（デフォルトでは3カ月）におけるアクティブユーザー数を示します。Users active over time プロットは、一定期間（デフォルトでは6カ月）におけるアクティブユーザー数の変動を示します。ポイントにマウスを重ねると、その日時のユーザー数が表示されます。
プロットの期間を変更するには、ドロップダウンを使用します。次のオプションから選択できます:
過去30日間
過去3カ月
過去6カ月
過去12カ月
すべての時間
5.6 - SMTP を設定
W&B server では、 インスタンスやチームにユーザーを追加すると、メール招待がトリガーされます。これらのメール招待を送信するために、 W&B はサードパーティのメールサーバーを使用します。場合によっては、企業ネットワークからのトラフィックを厳しく制限するポリシーがあり、その結果としてこれらのメール招待がエンドユーザーに送信されないことがあります。W&B server は、内部 SMTP サーバーを通じてこれらの招待メールを送信するオプションを提供しています。
設定手順は次の通りです：
dockerコンテナまたは kubernetes デプロイメント内で GORILLA_EMAIL_SINK 環境変数を smtp://<user:password>@smtp.host.com:<port> に設定します
username と password はオプションです認証不要な SMTP サーバーを使用している場合は、環境変数の値を GORILLA_EMAIL_SINK=smtp://smtp.host.com:<port> として設定します
SMTPで一般的に使用されるポート番号は 587, 465, 25 です。お使いのメールサーバーの種類に応じて異なる場合がありますので注意してください。
SMTP のデフォルト送信元メールアドレスを設定するには、 GORILLA_EMAIL_FROM_ADDRESS 環境変数を サーバー上であなたの望む送信元メールアドレスに設定することができます。初期設定は noreply@wandb.com になっていますが、これを変更することが可能です。
5.7 - 環境変数を設定する
W&B サーバー インストールの設定方法
インスタンスレベルの設定を System Settings 管理 UI 経由で設定することに加えて、W&B は環境変数を使用してこれらの値をコードで設定する方法も提供しています。また、IAM の高度な設定 も参照してください。
環境変数リファレンス
環境変数
説明
LICENSE
あなたの wandb/local ライセンス
MYSQL
MySQL 接続文字列
BUCKET
データを保存するための S3 / GCS バケット
BUCKET_QUEUE
オブジェクト作成イベントのための SQS / Google PubSub キュー
NOTIFICATIONS_QUEUE
run イベントを公開するための SQS キュー
AWS_REGION
バケットが存在する AWS リージョン
HOST
インスタンスの FQD、つまり https://my.domain.net
OIDC_ISSUER
Open ID Connect アイデンティティプロバイダーのURL、つまり https://cognito-idp.us-east-1.amazonaws.com/us-east-1_uiIFNdacd
OIDC_CLIENT_ID
あなたのアイデンティティプロバイダーにあるアプリケーションのクライアントID
OIDC_AUTH_METHOD
デフォルトは Implicit で、pkceも可能です。詳細は以下を参照してください。
SLACK_CLIENT_ID
アラートに使用したい Slack アプリケーションのクライアント ID
SLACK_SECRET
アラートに使用したい Slack アプリケーションの秘密キー
LOCAL_RESTORE
インスタンスにアクセスできない場合、一時的にこれをtrueに設定できます。コンテナのログを確認して一時的な資格情報を取得してください。
REDIS
W&B で外部の REDIS インスタンスを設定するために使用できます。
LOGGING_ENABLED
true に設定すると、アクセスログが stdout にストリームされます。また、この変数を設定しなくてもサイドカーコンテナをマウントし、/var/log/gorilla.log を追跡できます。
GORILLA_ALLOW_USER_TEAM_CREATION
true に設定すると、非管理者ユーザーが新しいチームを作成できるようになります。デフォルトは false です。
GORILLA_DATA_RETENTION_PERIOD
削除された run のデータを何時間保持するか。削除された run データは復元できません。入力値に h を付けてください。例えば、"24h"。
ENABLE_REGISTRY_UI
true に設定すると、新しい W&B Registry UI が有効になります。
GORILLA_DATA_RETENTION_PERIOD 環境変数は慎重に使用してください。環境変数が設定されるとすぐにデータは削除されます。また、このフラグを有効にする前に、データベースとストレージバケットの両方をバックアップすることをお勧めします。
高度な信頼性設定
Redis
外部の Redis サーバーを設定することはオプションですが、プロダクションシステムでは推奨されます。Redis はサービスの信頼性を向上させ、特に大規模プロジェクトでのロード時間を短縮するためのキャッシングを可能にします。ElastiCache などの高可用性 (HA) を備えた管理された Redis サービスを使用し、以下の仕様を備えています:
最小 4GB のメモリ、推奨 8GB
Redis バージョン 6.x
転送中の暗号化
認証が有効
W&B で Redis インスタンスを設定するには、http(s)://YOUR-W&B-SERVER-HOST/system-admin の W&B 設定ページに移動します。「外部 Redis インスタンスを使用する」オプションを有効にし、Redis 接続文字列を次の形式で入力します:
また、コンテナ上や Kubernetes デプロイメントで環境変数 REDIS を使って Redis を設定することもできます。あるいは、REDIS を Kubernetes シークレットとして設定することもできます。
このページは、Redis インスタンスがデフォルトのポート 6379 で動作していることを前提としています。異なるポートを設定した場合、認証をセットアップし、さらに Redis インスタンスで TLS を有効にしたい場合、接続文字列の形式は次のようになります: redis://$USER:$PASSWORD@$HOST:$PORT?tls=true
5.8 - W&B サーバーのリリースプロセス
W&B サーバーのリリース プロセス
Frequency and deployment types
W&B Server のリリースは、専用クラウド と 自己管理 デプロイメントに適用されます。サーバーリリースには 3 種類あります。
リリースの種類
説明
Monthly
月次リリースには、新機能、拡張機能、中程度および軽度のバグ修正が含まれます。
Patch
パッチリリースには、重大および高重要度のバグ修正が含まれます。パッチは必要に応じてまれにリリースされます。
Feature
機能リリースは、新しい製品機能のリリース日に特化しており、時折、通常の月次リリースの前に行われます。
すべてのリリースは、受け入れテストフェーズが完了次第、すぐにすべての 専用クラウド インスタンスにデプロイされます。これにより、管理されているインスタンスが完全に最新の状態に保たれ、関連する顧客が最新の機能と修正を利用できるようになります。自己管理 インスタンスを持つ顧客は、自分のスケジュールで更新プロセス を実行する責任があります。また、最新の Docker イメージ を使用することができます。リリースのサポートと終了時のポリシー を参照してください。
一部の高度な機能は、エンタープライズライセンスでのみ利用可能です。そのため、最新の Docker イメージを取得したとしても、エンタープライズライセンスを持っていない場合、関連する高度な機能を利用することはできません。
一部の新機能はプライベートプレビューで開始されます。これは、設計パートナーまたはアーリーアダプターにのみ利用可能であることを意味します。W&B チームがプライベートプレビュー機能を有効にする必要がありますので、インスタンスで使用する前にこれを行ってください。
Release notes
すべてのリリースのリリースノートは、W&B Server Releases on GitHub で確認できます。Slack を利用している顧客は、自分の W&B Slack チャンネルで自動リリース通知を受け取ることができます。これらの更新を有効にするよう、W&B チームに依頼してください。
Release update and downtime
サーバーリリースは通常、専用クラウド インスタンスや、適切なロールアップデートプロセスを実装した自己管理 デプロイメントの顧客にはダウンタイムを必要としません。
ダウンタイムが発生する可能性があるシナリオは次のとおりです：
新機能や拡張機能により、コンピュート、ストレージ、ネットワークなどの基盤 インフラストラクチャーへの変更が必要な場合。W&B は、専用クラウド の顧客に、関連する事前通知を送信するよう努めています。
特定のバージョンの サポート終了 を回避するため、またはセキュリティパッチによるインフラストラクチャーの変更。緊急の変更の場合、専用クラウド 顧客は事前通知を受け取らない可能性があります。ここでの優先事項は、艦隊を安全かつ完全にサポートされている状態に保つことです。
どちらのケースでも、更新プログラムは例外なくすべての 専用クラウド インスタンスに展開されます。自己管理 インスタンスを持つ顧客は、自分のスケジュールでこれらの更新を管理する責任があります。リリースのサポートと終了時のポリシー を参照してください。
Release support and end of life policy
W&B は、リリース日から 6 か月間すべてのサーバー リリースをサポートしています。専用クラウド インスタンスは自動的に更新されます。自己管理 インスタンスを持つ顧客は、サポートポリシーに従うためにタイムリーにデプロイメントを更新する責任があります。6 か月より古いバージョンにとどまることは、W&B のサポートを大幅に制限します。
W&B は、自己管理 インスタンスを持つ顧客に、少なくとも四半期に一度は最新のリリースでデプロイメントを更新することを強くお勧めします。これにより、最新の機能を利用できるだけでなく、リリース終了に先んじることができます。
6 - インテグレーション
W&B のインテグレーションを使えば、既存のプロジェクトで実験管理やデータのバージョン管理をすばやく簡単にセットアップできます。PyTorch のような ML フレームワーク、Hugging Face のような ML ライブラリ、または Amazon SageMaker のようなクラウドサービスのインテグレーションをご覧ください。
VIDEO
関連リソース
Examples : それぞれのインテグレーションのノートブックやスクリプト例でコードを試してください。動画チュートリアル : YouTube の動画チュートリアルで W&B の使い方を学びましょう。
6.1 - 任意のライブラリに wandb を追加する
任意のライブラリに wandb を追加する
このガイドでは、独自の Python ライブラリに W&B をインテグレーションするためのベストプラクティスを提供します。このことで、強力な実験管理、GPU およびシステム監視、モデルチェックポイントなどが利用可能になります。
W&B の使い方をまだ学んでいる場合は、読み進める前に
実験管理 など、他の W&B ガイドを探索することをお勧めします。
ここでは、作業しているコードベースが単一の Python トレーニングスクリプトや Jupyter ノートブックよりも複雑な場合のベストなヒントとベストプラクティスを紹介します。対象となるトピックは以下の通りです：
設定要件
ユーザーログイン
wandb Run の開始
Run Config の定義
W&B へのログ記録
分散トレーニング
モデルチェックポイントなど
ハイパーパラメータチューニング
高度なインテグレーション
設定要件
始める前に、ライブラリの依存関係に W&B を必須にするかどうかを決めてください：
インストール時に W&B を必須にする
W&B の Python ライブラリ（wandb）を requirements.txt ファイルなどに含めて依存関係ファイルに追加します：
torch== 1.8.0
...
wandb== 0.13 .*
インストール時に W&B をオプションにする
W&B SDK（wandb）をオプションにする方法は2つあります：
A. ユーザーが手動でインストールせずに wandb 機能を使用しようとしたときにエラーメッセージを表示してエラーを発生させる：
try :
import wandb
except ImportError :
raise ImportError (
"You are trying to use wandb which is not currently installed."
"Please install it using pip install wandb"
)
B. Python パッケージをビルドする場合は wandb をオプションの依存関係として pyproject.toml ファイルに追加する：
[project ]
name = "my_awesome_lib"
version = "0.1.0"
dependencies = [
"torch" ,
"sklearn"
]
[project .optional-dependencies ]
dev = [
"wandb"
]
ユーザーログイン
API キーの作成
API キーはクライアントまたはマシンを W&B に認証するものです。ユーザープロフィールから API キーを生成できます。
右上隅のユーザープロフィールアイコンをクリックします。
User Settings を選択し、API Keys セクションまでスクロールします。Reveal をクリックします。表示された API キーをコピーします。API キーを非表示にするには、ページをリロードします。
wandb ライブラリのインストールとログインローカルに wandb ライブラリをインストールしてログインします：
Command Line
Python
Python notebook
WANDB_API_KEY 環境変数 にあなたの API キーを設定します。
export WANDB_API_KEY= <your_api_key>
wandb ライブラリをインストールしてログインします。
pip install wandb
wandb login
import wandb
wandb. login()
!pip install wandb
import wandb
wandb.login()
ユーザーが上記のいずれの手順も行わずに初めて wandb を使用する場合、あなたのスクリプトが wandb.init を呼び出す際に自動的にログインを求められます。
Run の開始
W&B Run は、W&B によってログ記録された計算の単位です。通常、トレーニング実験ごとに1つの W&B Run を関連付けます。
以下のコードで W&B を初期化して Run を開始します：
オプションとして、プロジェクトの名前をつけることができます。また、コード内で wandb_project といったパラメータを使ってユーザーに設定してもらうこともできます。エンティティのパラメータについては wandb_entity などのユーザー名やチーム名を使用します：
run = wandb. init(project= wandb_project, entity= wandb_entity)
Run を終了するには run.finish() を呼び出す必要があります。次のように Run をコンテキストマネージャとして使うこともできます：
# このブロックが終了すると、自動的に run.finish() が呼び出されます。
# 例外によって終了した場合、run.finish(exit_code=1) を使用して
# Run を失敗とマークします。
with wandb. init() as run:
...
wandb.init を呼び出すタイミング？ライブラリは、W&B Run を可能な限り早く作成するべきです。なぜなら、コンソール出力に含まれるエラーメッセージなどの内容が W&B Run の一部としてログされ、デバッグが容易になるからです。
wandb をオプション依存関係として使用するユーザーがライブラリを使うときに wandb をオプションにしたい場合、以下のいずれかの方法を使用できます：
trainer = my_trainer(... , use_wandb= True )
python train.py ... --use-wandb
または、wandb.init で wandb を disabled に設定する：
wandb. init(mode= "disabled" )
export WANDB_MODE= disabled
または
または、wandb をオフラインに設定します - これは wandb を実行はしますが、インターネットを介して W&B に通信を試みません：
Environment Variable
Bash
export WANDB_MODE= offline
または
os. environ['WANDB_MODE' ] = 'offline'
Run Config の定義
wandb の Run Config を使って、W&B Run を作成する際にモデルやデータセットに関するメタデータを提供できます。この情報を利用して、異なる実験を比較し、その主な違いをすばやく理解することができます。
ログ可能な一般的な設定パラメータには以下が含まれます：
モデル名、バージョン、アーキテクチャパラメータなど
データセット名、バージョン、トレイン/バルの例数など
学習パラメータ（学習率、バッチサイズ、オプティマイザーなど）
以下のコードスニペットは設定をログする方法を示しています：
config = {"batch_size" : 32 , ... }
wandb. init(... , config= config)
Run Config の更新
run.config.update を使用して設定を更新します。設定辞書の更新は、辞書が定義された後にパラメータが取得された場合に役立ちます。たとえば、モデルがインスタンス化された後にモデルのパラメータを追加したい場合などです。
run. config. update({"model_parameters" : 3500 })
設定ファイルを定義する方法の詳細については、実験を設定する を参照してください。
W&B へのログ記録
メトリクスのログ記録
キーがメトリクス名となる辞書を作成し、この辞書オブジェクトを run.log
for epoch in range(NUM_EPOCHS):
for input, ground_truth in data:
prediction = model(input)
loss = loss_fn(prediction, ground_truth)
metrics = { "loss" : loss }
run. log(metrics)
メトリクスが多い場合、メトリクス名にプレフィックスを使用して UI 上で自動的にグループ化することができます。例えば、train/... と val/... を使用することで、トレーニングや検証メトリクス、その他のメトリクスを分けたセクションが W&B ワークスペースに作られます：
metrics = {
"train/loss" : 0.4 ,
"train/learning_rate" : 0.4 ,
"val/loss" : 0.5 ,
"val/accuracy" : 0.7
}
run. log(metrics)
run.log の詳細を学ぶ
x軸の非整合を防ぐ
同じトレーニングステップで run.log を複数回呼び出すと、wandb SDK は run.log を呼び出すたびに内部のステップカウンタを増加させます。このカウンタはトレーニングループ内のトレーニングステップと一致しないことがあります。
このような状況を避けるために、wandb.init を呼び出した直後に run.define_metric を使用して x 軸のステップを明示的に定義してください：
with wandb. init(... ) as run:
run. define_metric("*" , step_metric= "global_step" )
グロブパターンの * は、すべてのメトリクスがチャートの x 軸として global_step を使用することを意味します。特定のメトリクスのみを global_step に対してログする場合は、代わりにそれらを指定できます：
run. define_metric("train/loss" , step_metric= "global_step" )
その後、メトリクス、step メトリクス、および global_step を run.log を呼び出すたびにログします：
for step, (input, ground_truth) in enumerate(data):
...
run. log({"global_step" : step, "train/loss" : 0.1 })
run. log({"global_step" : step, "eval/loss" : 0.2 })
独立したステップ変数にアクセスできない場合、たとえば「global_step」が検証ループ中に利用できない場合、 wandb は自動的に以前にログされた「global_step」 の値を使用します。この場合、メトリクスの初期値をログして、その値が必要なときに定義されるようにしてください。
画像、テーブル、オーディオなどのログ記録
メトリクスに加えて、プロット、ヒストグラム、テーブル、テキスト、画像、動画、オーディオ、3D などのメディアをログすることができます。
データをログする際の考慮事項には以下が含まれます：
メトリクスはどのくらいの頻度でログされるべきか？ オプション化すべきか？
視覚化に役立つデータの種類は何か？
画像の場合、サンプル予測、セグメンテーションマスクなどのログを記録して、時間の経過を見て進化を追うことができます。
テキストの場合、後で検討できるサンプル予測のテーブルをログすることができます。
メディア、オブジェクト、プロットなどのログ記録について詳しく学ぶ 。
分散トレーニング
分散環境をサポートするフレームワークでは、以下のワークフローのいずれかを適用することができます：
「メイン」のプロセスを検出し、そこでのみ wandb を使用してください。他のプロセスから必要なデータは最初にメインプロセスにルーティングされなければなりません（このワークフローが推奨されます）。
すべてのプロセスで wandb を呼び出し、それらすべてに同じ一意の group 名を与えて自動グループ化します。
詳細については 分散トレーニング実験のログ記録 を参照してください。
モデルチェックポイントとその他のログ記録
フレームワークがモデルまたはデータセットを使用または生成する場合、W&B Artifacts を通じて wandb で完全なトレース可能性を持ってそれらをログし、パイプライン全体を自動的に監視させることができます。
Artifacts を使用しているとき、ユーザーに次のことを定義させることは有用ですが必須ではありません：
モデルチェックポイントまたはデータセットをログする機能を有すること（任意にする場合）。
使用されるアーティファクトのパス/参照を入力として使用する場合。たとえば、user/project/artifact のような指定。
Artifacts をログする頻度。
モデルチェックポイントのログ記録
モデルチェックポイントを W&B にログすることができます。ユニークな wandb Run ID を使用して出力モデルチェックポイントに名前を付け、Run 間でそれらを区別するのが有効です。また、有用なメタデータを追加することもできます。さらに、以下のようにモデルごとにエイリアスを追加することもできます：
metadata = {"eval/accuracy" : 0.8 , "train/steps" : 800 }
artifact = wandb. Artifact(
name= f "model- { run. id} " ,
metadata= metadata,
type= "model"
)
artifact. add_dir("output_model" ) # モデルの重みが保存されているローカルディレクトリ
aliases = ["best" , "epoch_10" ]
run. log_artifact(artifact, aliases= aliases)
カスタムエイリアスの作成方法については カスタムエイリアスを作成する を参照してください。
Artifacts は任意の頻度で出力ログが可能（例えば、各エポックごと、各500ステップごとなど）であり、これらは自動的にバージョン管理されます。
学習済みモデルまたはデータセットのログと追跡
トレーニングの入力として使用されるアーティファクト（学習済みモデルやデータセットなど）をログすることができます。以下のスニペットでは、アーティファクトをログし、上記のグラフのように進行中の Run の入力として追加する方法を示しています。
artifact_input_data = wandb. Artifact(name= "flowers" , type= "dataset" )
artifact_input_data. add_file("flowers.npy" )
run. use_artifact(artifact_input_data)
アーティファクトをダウンロードする
アーティファクト（データセット、モデルなど）を再利用する場合、 wandb はローカルにコピー（およびキャッシュ）をダウンロードします：
artifact = run. use_artifact("user/project/artifact:latest" )
local_path = artifact. download("./tmp" )
Artifacts は W&B の Artifacts セクションで見つかり、自動で生成されるエイリアス（latest, v2, v3）またはログ時に手動で生成されるエイリアス（best_accuracy など）で参照できます。
たとえば分散環境や単純な推論のために wandb Run（wandb.init を通して）を作成せずに Artifact をダウンロードしたい場合、代わりに wandb API を使用してアーティファクトを参照できます：
artifact = wandb. Api(). artifact("user/project/artifact:latest" )
local_path = artifact. download()
詳細については、Artのダウンロードと使用 を参照してください。
ハイパーパラメータのチューニング
ライブラリが W&B ハイパーパラメータチューニングを活用したい場合、W&B Sweeps もライブラリに追加できます。
高度なインテグレーション
以下のインテグレーションで高度な W&B インテグレーションがどのように見えるか見ることができます。ただし、ほとんどのインテグレーションはこれほど複雑ではありません：
6.2 - Azure OpenAI ファインチューニング
Azure OpenAI モデルを Fine-Tune する方法とW&Bの使用方法。
イントロダクション
Microsoft Azureを使用してGPT-3.5やGPT-4モデルをファインチューニングすることで、W&Bはメトリクスを自動的にキャプチャし、W&Bの実験管理および評価ツールを通じて系統的な評価を促進することで、モデルの性能を追跡し、分析し、改善します。
前提条件
公式のAzureドキュメント に従ってAzure OpenAIサービスをセットアップします。APIキーを使用してW&Bアカウントを設定します。
ワークフローの概要
1. ファインチューニングのセットアップ
Azure OpenAIの要件に従ってトレーニングデータを準備します。
Azure OpenAIでファインチューニングジョブを設定します。
W&Bはファインチューニングプロセスを自動的に追跡し、メトリクスとハイパーパラメーターをログします。
2. 実験管理
ファインチューニング中、W&Bは以下をキャプチャします：
トレーニングと検証のメトリクス
モデルのハイパーパラメーター
リソースの利用状況
トレーニングアーティファクト
3. モデルの評価
ファインチューニング後、W&B Weave を使用して以下を行います：
モデルの出力を参照データセットと比較評価します。
異なるファインチューニングのrun間で性能を比較します。
特定のテストケースでモデルの振る舞いを分析します。
モデル選択のためのデータドリブンの意思決定を行います。
実際の例
追加リソース
6.3 - Catalyst
Catalyst、PyTorch フレームワークに W&B を統合する方法。
Catalyst は、再現性、迅速な実験、およびコードベースの再利用に焦点を当てたディープ ラーニング R&D のための PyTorch フレームワークです。これにより、新しいものを創り出すことができます。
Catalyst には、パラメータ、メトリクス、画像、その他のアーティファクトをログするための W&B インテグレーションが含まれています。
Python と Hydra を使用した例を含むインテグレーションの ドキュメント をチェックしてください。
インタラクティブな例
Catalyst と W&B インテグレーションを実際に見るために、Colab の例 を実行してください。
6.4 - Cohere fine-tuning
Cohere モデルをファインチューンする方法（W&B を使用）。
Weights & Biases を使用すると、Cohere モデルのファインチューニングメトリクスや設定をログに記録し、モデルのパフォーマンスを分析・理解し、その結果を同僚と共有することができます。
この Cohere のガイド では、ファインチューニング run を開始する方法の完全な例が示されています。また、Cohere API ドキュメントはこちら で確認できます。
Cohere ファインチューニング結果のログ
Cohere のファインチューニングログを W&B ワークスペースに追加するには:
W&B APIキー、W&B entity と project 名を用いて WandbConfig を作成します。W&B APIキーは https://wandb.ai/authorize で取得できます。
この設定を FinetunedModel オブジェクトとともに、モデル名、データセット、ハイパーパラメーターとともに渡して、ファインチューニング run を開始します。
from cohere.finetuning import WandbConfig, FinetunedModel
# W&B の詳細で設定を作成します
wandb_ft_config = WandbConfig(
api_key= "<wandb_api_key>" ,
entity= "my-entity" , # 提供された API キーに関連した有効な entity である必要があります
project= "cohere-ft" ,
)
... # データセットとハイパーパラメーターを設定します
# cohere でファインチューニング run を開始します
cmd_r_finetune = co. finetuning. create_finetuned_model(
request= FinetunedModel(
name= "command-r-ft" ,
settings= Settings(
base_model=...
dataset_id=...
hyperparameters=...
wandb= wandb_ft_config # ここに W&B の設定を渡します
),
),
)
作成した W&B プロジェクトで、モデルのファインチューニングトレーニングと検証のメトリクスやハイパーパラメーターを確認します。
Runsの整理
W&B の runs は自動的に整理され、ジョブタイプ、ベースモデル、学習率、その他のハイパーパラメータなど、任意の設定パラメータに基づいてフィルタリングやソートが可能です。
さらに、runs の名前を変更したり、メモを追加したり、タグを作成してグループ化したりすることができます。
リソース
6.5 - Databricks
W&B を Databricks と統合する方法。
W&B は、Databricks 環境での W&B Jupyter ノートブック体験をカスタマイズすることにより、Databricks と統合します。
Databricks の設定
クラスターに wandb をインストール
クラスター設定に移動し、クラスターを選択し、Libraries をクリックします。Install New をクリックし、PyPI を選択してパッケージ wandb を追加します。
認証の設定
あなたの W&B アカウントを認証するために、ノートブックが照会できる Databricks シークレットを追加することができます。
# databricks cli をインストール
pip install databricks-cli
# databricks UIからトークンを生成
databricks configure --token
# 2つのコマンドのいずれかでスコープを作成します（databricksでセキュリティ機能が有効かどうかによります）：
# セキュリティ追加機能あり
databricks secrets create-scope --scope wandb
# セキュリティ追加機能なし
databricks secrets create-scope --scope wandb --initial-manage-principal users
# こちらから api_key を追加します: https://app.wandb.ai/authorize
databricks secrets put --scope wandb --key api_key
例
簡単な例
import os
import wandb
api_key = dbutils. secrets. get("wandb" , "api_key" )
wandb. login(key= api_key)
wandb. init()
wandb. log({"foo" : 1 })
Sweeps
ノートブックが wandb.sweep() または wandb.agent() を使用しようとする際に必要な設定（暫定的）です。
import os
# これらは将来的には不要になります
os. environ["WANDB_ENTITY" ] = "my-entity"
os. environ["WANDB_PROJECT" ] = "my-project-that-exists"
6.6 - DeepChecks
W&B を DeepChecks と統合する方法。
DeepChecks は、データの整合性の検証、分布の確認、データ分割の検証、モデルの評価、および異なるモデル間の比較など、機械学習モデルとデータの検証を最小限の労力で行うことができます。
DeepChecks と wandb のインテグレーションについて詳しく読む ->
はじめに
DeepChecks を Weights & Biases と共に使用するには、まず こちら で Weights & Biases のアカウントにサインアップする必要があります。DeepChecks における Weights & Biases のインテグレーションにより、以下のように素早く始めることができます。
import wandb
wandb. login()
# deepchecks からチェックをインポート
from deepchecks.checks import ModelErrorAnalysis
# チェックを実行
result = ModelErrorAnalysis()
# 結果を wandb にプッシュ
result. to_wandb()
また、Weights & Biases に DeepChecks のテストスイート全体をログすることもできます。
import wandb
wandb. login()
# deepchecks から full_suite テストをインポート
from deepchecks.suites import full_suite
# DeepChecks テストスイートを作成して実行
suite_result = full_suite(). run(... )
# 結果を wandb にプッシュ
# ここで必要な wandb.init の設定や引数を渡すことができます
suite_result. to_wandb(project= "my-suite-project" , config= {"suite-name" : "full-suite" })
例
``このレポート
この Weights & Biases インテグレーションに関して質問や問題がある場合は、DeepChecks github リポジトリ にイシューを開いてください。対応し、ご回答いたします :)
6.7 - DeepChem
DeepChem ライブラリ と W&B の統合方法について
The DeepChem library は、創薬、材料科学、化学、生物学におけるディープラーニングの利用を民主化するオープンソースツールを提供します。この W&B インテグレーションは、DeepChem を使用してモデルをトレーニングする際に、シンプルで使いやすい実験管理とモデルチェックポイントを追加します。
DeepChem のロギングを 3 行のコードで
logger = WandbLogger(… )
model = TorchModel(… , wandb_logger= logger)
model. fit(… )
Report と Google Colab
W&B DeepChem インテグレーションを使用して生成されたチャートの例として、Using W&B with DeepChem: Molecular Graph Convolutional Networks の記事を参照してください。
すぐに動作するコードを見たい場合は、この Google Colab
実験管理のトラッキング
KerasModel またはTorchModel タイプの DeepChem モデルに W&B を設定します。
サインアップと API キーの作成
APIキーは、あなたのマシンを W&B に認証します。APIキーはユーザープロフィールから生成できます。
右上のユーザープロフィールアイコンをクリックします。
User Settings を選択し、API Keys セクションまでスクロールします。Reveal をクリックします。表示されたAPIキーをコピーします。APIキーを隠すには、ページを再読み込みします。
wandb ライブラリのインストールとログインwandb ライブラリをローカルにインストールしてログインするには：
Command Line
Python
Python notebook
WANDB_API_KEY 環境変数 をあなたのAPIキーに設定します。
export WANDB_API_KEY= <your_api_key>
wandb ライブラリをインストールし、ログインします。
pip install wandb
wandb login
import wandb
wandb. login()
!pip install wandb
import wandb
wandb.login()
トレーニングと評価データを W&B にログする
トレーニング損失と評価メトリクスは、W&Bに自動的に記録されます。オプションの評価は、DeepChem の ValidationCallback を使用して有効化できます。WandbLogger は ValidationCallback コールバックを検出し、生成されたメトリクスをログします。
from deepchem.models import TorchModel, ValidationCallback
vc = ValidationCallback(… ) # optional
model = TorchModel(… , wandb_logger= logger)
model. fit(… , callbacks= [vc])
logger. finish()
from deepchem.models import KerasModel, ValidationCallback
vc = ValidationCallback(… ) # optional
model = KerasModel(… , wandb_logger= logger)
model. fit(… , callbacks= [vc])
logger. finish()
6.8 - Docker
W&B を Docker と統合する方法。
Docker インテグレーション
W&B は、コードが実行された Docker イメージへのポインターを保存することで、以前の実験を正確に実行された環境に復元することができます。wandbライブラリは、この状態を永続化するために WANDB_DOCKER 環境変数を探します。私たちは、この状態を自動的に設定するいくつかのヘルパーを提供しています。
ローカル開発
wandb docker は、dockerコンテナを起動し、wandbの環境変数を渡し、コードをマウントし、wandb がインストールされていることを確認するコマンドです。デフォルトでは、TensorFlow、PyTorch、Keras、そして Jupyter がインストールされた docker イメージを使用します。wandb docker my/image:latest のようにして、同じコマンドで独自の docker イメージを開始することもできます。コマンドは現在のディレクトリーをコンテナの “/app” ディレクトリーにマウントしますが、これは “–dir” フラグで変更できます。
プロダクション
wandb docker-run コマンドは、プロダクションのワークロードに提供されます。これは nvidia-docker の代替として使用されることを想定しています。これは、docker run コマンドにあなたの資格情報と WANDB_DOCKER 環境変数を追加する単純なラッパーです。"–runtime" フラグを渡さず、nvidia-docker がマシンにインストールされている場合、ランタイムが nvidia に設定されていることも確認されます。
Kubernetes
トレーニングワークロードを Kubernetes 上で実行し、k8s API がポッドに公開されている場合（デフォルトでそうです）、wandb は API に対して docker イメージのダイジェストを問い合わせ、WANDB_DOCKER 環境変数を自動的に設定します。
復元
WANDB_DOCKER 環境変数を使用して run が計測されている場合、wandb restore username/project:run_id を呼び出すと、新しいブランチがチェックアウトされ、コードが復元され、トレーニングに使用された正確な docker イメージが、元のコマンドで事前に設定された状態で起動されます。
6.9 - Farama Gymnasium
W&B を Farama Gymnasium と統合する方法。
Farama Gymnasium を使用している場合、 gymnasium.wrappers.Monitor によって生成された環境のビデオを自動的にログします。 キーワード引数 monitor_gym を wandb.initTrue と設定するだけです。
私たちの Gymnasium インテグレーションは非常に軽量です。 単に gymnasium からログされるビデオファイルの名前を見る だけで、それにちなんで名前を付けるか、一致するものが見つからない場合はデフォルトで "videos" とします。 より細かい制御が必要な場合は、いつでも手動でビデオをログする ことができます。
Gymnasium と CleanRL ライブラリを使用する方法について詳しく知りたい方は、このレポート をご覧ください。
6.10 - fastai
もしあなたが fastai を使ってモデルを訓練しているなら、W&B には WandbCallback を使用した簡単なインテグレーションがあります。インタラクティブなドキュメントと例についてはこちらをご覧ください →
登録と APIキー の作成
APIキー は、あなたのマシンを W&B に認証します。APIキー は、ユーザープロフィールから生成できます。
右上のユーザープロフィールアイコンをクリックします。
User Settings を選択し、API Keys セクションまでスクロールします。Reveal をクリックします。表示された APIキー をコピーします。APIキー を非表示にするには、ページを再読み込みしてください。
wandb ライブラリのインストールとログインwandb ライブラリをローカルにインストールしログインするには:
Command Line
Python
Python notebook
WANDB_API_KEY 環境変数 をあなたの APIキー に設定します。
export WANDB_API_KEY= <your_api_key>
wandb ライブラリをインストールしログインします。
pip install wandb
wandb login
import wandb
wandb. login()
!pip install wandb
import wandb
wandb.login()
learner または fit メソッドに WandbCallback を追加するimport wandb
from fastai.callback.wandb import *
# wandb run を開始してログをとる
wandb. init(project= "my_project" )
# トレーニングフェーズの一部のみログする場合
learn. fit(... , cbs= WandbCallback())
# すべてのトレーニングフェーズで継続的にログをとる場合
learn = learner(... , cbs= WandbCallback())
WandbCallback 引数
WandbCallback は以下の引数を受け入れます:
Args
説明
log
モデルをログするかどうか: gradients 、parameters, all 、または None (デフォルト)。損失とメトリクスは常にログされます。
log_preds
予測サンプルをログしたいかどうか (デフォルトは True)。
log_preds_every_epoch
予測をエポックごとにログするか、最後にログするか (デフォルトは False)
log_model
モデルをログしたいかどうか (デフォルトは False)。これには SaveModelCallback も必要です。
model_name
保存する file の名前、SaveModelCallback をオーバーライドします。
log_dataset
False (デフォルト)True は learn.dls.path が参照するフォルダをログします。ログするフォルダを参照するパスを明示的に定義できます。 注: サブフォルダ “models” は常に無視されます。
dataset_name
ログされたデータセットの名前 (デフォルトは フォルダ名)。
valid_dl
予測サンプルに使用する DataLoaders (デフォルトは learn.dls.valid からランダムなアイテム)
n_preds
ログする予測の数 (デフォルトは 36)。
seed
ランダムサンプルを定義するために使用します。
カスタムワークフローのために、データセットとモデルを手動でログすることができます:
log_dataset(path, name=None, metadata={})log_model(path, name=None, metadata={})
注: サブフォルダ “models” は無視されます。
分散トレーニング
fastai はコンテキストマネージャー distrib_ctx を使用して分散トレーニングをサポートしています。W&B はこれを自動的にサポートし、マルチGPU実験をすぐにトラッキングできるようにします。
この簡単な例を確認してください:
import wandb
from fastai.vision.all import *
from fastai.distributed import *
from fastai.callback.wandb import WandbCallback
wandb. require(experiment= "service" )
path = rank0_first(lambda : untar_data(URLs. PETS) / "images" )
def train ():
dls = ImageDataLoaders. from_name_func(
path,
get_image_files(path),
valid_pct= 0.2 ,
label_func= lambda x: x[0 ]. isupper(),
item_tfms= Resize(224 ),
)
wandb. init("fastai_ddp" , entity= "capecape" )
cb = WandbCallback()
learn = vision_learner(dls, resnet34, metrics= error_rate, cbs= cb). to_fp16()
with learn. distrib_ctx(sync_bn= False ):
learn. fit(1 )
if __name__ == "__main__" :
train()
そして、ターミナルで以下を実行します:
$ torchrun --nproc_per_node 2 train.py
この場合、マシンには 2 つの GPU があります。
ノートブック内で直接分散トレーニングを実行することができます。
import wandb
from fastai.vision.all import *
from accelerate import notebook_launcher
from fastai.distributed import *
from fastai.callback.wandb import WandbCallback
wandb. require(experiment= "service" )
path = untar_data(URLs. PETS) / "images"
def train ():
dls = ImageDataLoaders. from_name_func(
path,
get_image_files(path),
valid_pct= 0.2 ,
label_func= lambda x: x[0 ]. isupper(),
item_tfms= Resize(224 ),
)
wandb. init("fastai_ddp" , entity= "capecape" )
cb = WandbCallback()
learn = vision_learner(dls, resnet34, metrics= error_rate, cbs= cb). to_fp16()
with learn. distrib_ctx(in_notebook= True , sync_bn= False ):
learn. fit(1 )
notebook_launcher(train, num_processes= 2 )
メインプロセスのみでログを取る
上記の例では、wandb はプロセスごとに1 つの run を起動します。トレーニングの終了時には、2 つの run ができます。これが混乱を招くこともあり、メインプロセスだけでログを取りたい場合があります。そのためには、手動でどのプロセスにいるかを検出し、他のプロセスでは run (すなわち wandb.init の呼び出し) を作成しないようにする必要があります。
import wandb
from fastai.vision.all import *
from fastai.distributed import *
from fastai.callback.wandb import WandbCallback
wandb. require(experiment= "service" )
path = rank0_first(lambda : untar_data(URLs. PETS) / "images" )
def train ():
cb = []
dls = ImageDataLoaders. from_name_func(
path,
get_image_files(path),
valid_pct= 0.2 ,
label_func= lambda x: x[0 ]. isupper(),
item_tfms= Resize(224 ),
)
if rank_distrib() == 0 :
run = wandb. init("fastai_ddp" , entity= "capecape" )
cb = WandbCallback()
learn = vision_learner(dls, resnet34, metrics= error_rate, cbs= cb). to_fp16()
with learn. distrib_ctx(sync_bn= False ):
learn. fit(1 )
if __name__ == "__main__" :
train()
ターミナルで以下を実行します:
$ torchrun --nproc_per_node 2 train.py
import wandb
from fastai.vision.all import *
from accelerate import notebook_launcher
from fastai.distributed import *
from fastai.callback.wandb import WandbCallback
wandb. require(experiment= "service" )
path = untar_data(URLs. PETS) / "images"
def train ():
cb = []
dls = ImageDataLoaders. from_name_func(
path,
get_image_files(path),
valid_pct= 0.2 ,
label_func= lambda x: x[0 ]. isupper(),
item_tfms= Resize(224 ),
)
if rank_distrib() == 0 :
run = wandb. init("fastai_ddp" , entity= "capecape" )
cb = WandbCallback()
learn = vision_learner(dls, resnet34, metrics= error_rate, cbs= cb). to_fp16()
with learn. distrib_ctx(in_notebook= True , sync_bn= False ):
learn. fit(1 )
notebook_launcher(train, num_processes= 2 )
例
6.10.1 - fastai v1
このドキュメントは fastai v1 向けです。
現在のバージョンの fastai を使用している場合は、
fastai ページ を参照してください。
fastai v1 を使用するスクリプトの場合、モデルのトポロジー、損失、メトリクス、重み、勾配、サンプル予測、および最適な訓練モデルを自動的にログすることができるコールバックがあります。
import wandb
from wandb.fastai import WandbCallback
wandb. init()
learn = cnn_learner(data, model, callback_fns= WandbCallback)
learn. fit(epochs)
ログされるデータは、コールバックのコンストラクタを介して設定可能です。
from functools import partial
learn = cnn_learner(
data, model, callback_fns= partial(WandbCallback, input_type= "images" )
)
また、トレーニングを開始するときにのみ WandbCallback を使用することも可能です。この場合、それをインスタンス化する必要があります。
learn. fit(epochs, callbacks= WandbCallback(learn))
その段階でカスタムパラメータを与えることもできます。
learn. fit(epochs, callbacks= WandbCallback(learn, input_type= "images" ))
コード例
インテグレーションがどのように機能するかを見るために、いくつかの例を作成しました：
Fastai v1
オプション
WandbCallback() クラスは多くのオプションをサポートしています：
キーワード引数
デフォルト
説明
learn
N/A
フックする fast.ai learner。
save_model
True
モデルが各ステップで改善されれば保存します。また、トレーニング終了時に最適なモデルをロードします。
mode
auto
min、max、または auto: ステップ間で指定されたトレーニングメトリクスをどのように比較するか。
monitor
None
最適なモデルを保存するために使用されるトレーニングメトリクス。None はデフォルトで検証損失になります。
log
gradients
gradients、parameters、all、または None。損失とメトリクスは常にログされます。
input_type
None
images または None。サンプル予測を表示するために使用されます。
validation_data
None
input_type が設定されている場合にサンプル予測に使用されるデータ。
predictions
36
input_type が設定され、validation_data が None の場合に行う予測の数。
seed
12345
input_type が設定され、validation_data が None の場合にサンプル予測のためのランダムジェネレータを初期化します。
6.11 - Hugging Face Transformers
Hugging Face Transformers ライブラリは、BERTのような最先端のNLPモデルや、混合精度、勾配チェックポイントなどのトレーニング手法を簡単に使用できるようにします。W&B integration により、その使いやすさを損なうことなく、柔軟な実験管理とモデルのバージョン管理をインタラクティブな集中ダッシュボードに追加します。
数行で次世代のロギング
os. environ["WANDB_PROJECT" ] = "<my-amazing-project>" # W&Bプロジェクトの名前を指定
os. environ["WANDB_LOG_MODEL" ] = "checkpoint" # すべてのモデルチェックポイントをログ
from transformers import TrainingArguments, Trainer
args = TrainingArguments(... , report_to= "wandb" ) # W&Bのログを有効化
trainer = Trainer(... , args= args)
始める： 実験をトラックする
サインアップしてAPIキーを作成する
APIキーは、あなたのマシンをW&Bに認証します。ユーザープロフィールからAPIキーを生成できます。
右上のユーザーアイコンをクリックします。
ユーザー設定 を選択し、APIキー セクションまでスクロールします。Reveal をクリックします。表示されたAPIキーをコピーします。APIキーを非表示にするには、ページを再読み込みします。
wandbライブラリをインストールしてログインするwandbライブラリをローカルにインストールし、ログインするには：
Command Line
Python
Python notebook
WANDB_API_KEY 環境変数 をAPIキーに設定します。
export WANDB_API_KEY= <your_api_key>
wandbライブラリをインストールしてログインします。
pip install wandb
wandb login
import wandb
wandb. login()
!pip install wandb
import wandb
wandb.login()
初めてW&Bを使用する場合、クイックスタート
プロジェクトの名前を付ける
W&B Projectは、関連するRunsからログされたすべてのチャート、データ、モデルを保存する場所です。プロジェクト名をつけることで、作業を整理し、1つのプロジェクトに関するすべての情報を一ヶ所にまとめることができます。
プロジェクトにrunを追加するには、単にWANDB_PROJECT 環境変数をプロジェクト名に設定するだけです。WandbCallbackは、このプロジェクト名の環境変数を拾い上げ、runを設定する際にそれを使用します。
Command Line
Python
Python notebook
WANDB_PROJECT= amazon_sentiment_analysis
import os
os. environ["WANDB_PROJECT" ]= "amazon_sentiment_analysis"
%env WANDB_PROJECT=amazon_sentiment_analysis
プロジェクト名はTrainerを初期化する前に設定することを確認してください。
プロジェクト名が指定されていない場合、プロジェクト名はhuggingfaceにデフォルト設定されます。
トレーニングRunsをW&Bにログする
これは、コード内またはコマンドラインからトレーニング引数を定義する際の最も重要なステップ です。report_toを"wandb"に設定することで、W&Bログを有効にします。
TrainingArgumentsのlogging_steps引数は、トレーニング中にW&Bにトレーニングメトリクスがプッシュされる頻度を制御します。run_name引数を使用して、W&B内でトレーニングrunに名前を付けることもできます。
これで終了です。トレーニング中は、モデルが損失、評価メトリクス、モデルトポロジー、勾配をW&Bにログします。
python run_glue.py \ # Pythonスクリプトを実行
--report_to wandb \ # W&Bにログを有効化
--run_name bert-base-high-lr \ # W&B runの名前 (オプション)
# その他のコマンドライン引数をここに
from transformers import TrainingArguments, Trainer
args = TrainingArguments(
# 他の引数やキーワード引数をここに
report_to= "wandb" , # W&Bにログを有効化
run_name= "bert-base-high-lr" , # W&B runの名前 (オプション)
logging_steps= 1 , # W&Bにログする頻度
)
trainer = Trainer(
# 他の引数やキーワード引数をここに
args= args, # トレーニング引数
)
trainer. train() # トレーニングとW&Bへのログを開始
TensorFlowを使用していますか？ PyTorchのTrainerをTensorFlowのTFTrainerに置き換えるだけです。
モデルのチェックポイントをオンにする
Artifacts を使用すると、最大100GBのモデルやデータセットを無料で保存し、その後Weights & BiasesのRegistry を使用できます。Registryを使用して、モデルを登録し、それらを探索・評価したり、ステージングの準備をしたり、プロダクション環境にデプロイできます。
Hugging FaceモデルのチェックポイントをArtifactsにログするには、WANDB_LOG_MODEL 環境変数を以下のいずれかに設定します：
checkpointTrainingArgumentsargs.save_stepsごとにチェックポイントをアップロードします。endload_best_model_at_endが設定されている場合です。false
Command Line
Python
Python notebook
WANDB_LOG_MODEL= "checkpoint"
import os
os. environ["WANDB_LOG_MODEL" ] = "checkpoint"
%env WANDB_LOG_MODEL="checkpoint"
これ以降に初期化するすべてのTransformers Trainerは、モデルをW&Bプロジェクトにアップロードします。ログされたモデルチェックポイントはArtifacts UIを通じて表示可能で、完全なモデルリネージを含みます（UIでのモデルチェックポイントの例はこちらをご覧ください here )。
デフォルトでは、
WANDB_LOG_MODELが
endに設定されているときは
model-{run_id}として、
WANDB_LOG_MODELが
checkpointに設定されているときは
checkpoint-{run_id}として、モデルがW&B Artifactsに保存されます。しかし、
TrainingArgumentsに
run_nameを渡すと、モデルは
model-{run_name}または
checkpoint-{run_name}として保存されます。
W&B Registry
チェックポイントをArtifactsにログしたら、最良のモデルチェックポイントを登録して、**Registry **でチーム全体に中央集約できます。Registryを使用すると、タスクごとに最良のモデルを整理し、モデルライフサイクルを管理し、機械学習ライフサイクル全体を追跡および監査し、オートメーション ダウンストリームアクションを自動化できます。
モデルのアーティファクトをリンクするには、Registry を参照してください。
トレーニング中に評価出力を視覚化する
トレーニングや評価中にモデル出力を視覚化することは、モデルがどのようにトレーニングされているかを理解するためにしばしば重要です。
Transformers Trainerのコールバックシステムを使用すると、モデルのテキスト生成出力や他の予測などの役立つデータをW&B Tablesにログできます。
トレーニング中にW&B Tableに評価出力をログする方法については、以下の**カスタムログセクション **をご覧ください:
W&B Runを終了させる（ノートブックのみ）
トレーニングがPythonスクリプトでカプセル化されている場合、スクリプトが終了するとW&B runも終了します。
JupyterまたはGoogle Colabノートブックを使用している場合は、トレーニングが終了したことをwandb.finish()を呼び出して知らせる必要があります。
trainer. train() # トレーニングとW&Bへのログを開始
# トレーニング後の分析、テスト、他のログ済みコード
wandb. finish()
結果を視覚化する
トレーニング結果をログしたら、W&B Dashboard で結果を動的に探索できます。複数のrunを一度に比較したり、興味深い知見にズームインしたり、柔軟でインタラクティブな可視化を用いて複雑なデータから洞察を引き出すのが簡単です。
高度な機能とFAQ
最良のモデルを保存する方法は？
Trainerにload_best_model_at_end=TrueのTrainingArgumentsを渡すと、W&Bは最良のパフォーマンスを示すモデルチェックポイントをアーティファクトに保存します。
モデルチェックポイントをアーティファクトとして保存すれば、それらをRegistry に昇格させることができます。Registryでは以下のことが可能です：
MLタスクによって最良のモデルバージョンを整理する。
モデルを集約してチームと共有する。
モデルをステージングしてプロダクションに展開するか、さらに評価するためにブックマークする。
下流のCI/CDプロセスをトリガーする。
保存したモデルをロードするには？
WANDB_LOG_MODELでW&B Artifactsにモデルを保存した場合、追加トレーニングや推論のためにモデルウェイトをダウンロードできます。同じHugging Faceアーキテクチャーにモデルを読み戻すだけです。
# 新しいrunを作成
with wandb. init(project= "amazon_sentiment_analysis" ) as run:
# アーティファクトの名前とバージョンを指定
my_model_name = "model-bert-base-high-lr:latest"
my_model_artifact = run. use_artifact(my_model_name)
# フォルダーにモデルウェイトをダウンロードし、パスを返す
model_dir = my_model_artifact. download()
# 同じモデルクラスを使用して、そのフォルダーからHugging Faceモデルをロード
model = AutoModelForSequenceClassification. from_pretrained(
model_dir, num_labels= num_labels
)
# 追加のトレーニングを行うか、推論を実行
チェックポイントからトレーニングを再開するには？
WANDB_LOG_MODEL='checkpoint'を設定していた場合、model_dirをTrainingArgumentsのmodel_name_or_path引数として使用し、Trainerにresume_from_checkpoint=Trueを渡すことでトレーニングを再開できます。
last_run_id = "xxxxxxxx" # wandb workspaceからrun_idを取得
# run_idからwandb runを再開
with wandb. init(
project= os. environ["WANDB_PROJECT" ],
id= last_run_id,
resume= "must" ,
) as run:
# アーティファクトをrunに接続
my_checkpoint_name = f "checkpoint- { last_run_id} :latest"
my_checkpoint_artifact = run. use_artifact(my_model_name)
# フォルダーにチェックポイントをダウンロードし、パスを返す
checkpoint_dir = my_checkpoint_artifact. download()
# モデルとトレーナーを再初期化
model = AutoModelForSequenceClassification. from_pretrained(
"<model_name>" , num_labels= num_labels
)
# 素晴らしいトレーニング引数をここに
training_args = TrainingArguments()
trainer = Trainer(model= model, args= training_args)
# チェックポイントディレクトリを使用してトレーニングをチェックポイントから再開することを確かにする
trainer. train(resume_from_checkpoint= checkpoint_dir)
トレーニング中に評価サンプルをログして表示するには？
Transformers Trainerを介してW&Bにログすることは、TransformersライブラリのWandbCallbackWandbCallbackをサブクラス化し、Trainerクラスから追加のメソッドを利用する追加機能を追加することにより、このコールバックを変更できます。
以下は、HF Trainerにこの新しいコールバックを追加する際の一般的なパターンであり、さらに下にはW&B Tableに評価出力をログするコード完備の例があります：
# 通常通りTrainerをインスタンス化
trainer = Trainer()
# Trainerオブジェクトを渡して新しいログコールバックをインスタンス化
evals_callback = WandbEvalsCallback(trainer, tokenizer, ... )
# Trainerにコールバックを追加
trainer. add_callback(evals_callback)
# 通常通りTrainerトレーニングを開始
trainer. train()
トレーニング中に評価サンプルを表示
以下のセクションでは、WandbCallbackをカスタマイズして、モデルの予測を実行し、トレーニング中にW&B Tableに評価サンプルをログする方法を示します。on_evaluateメソッドを使用してeval_stepsごとにログします。
ここでは、トークナイザーを使用してモデル出力から予測とラベルをデコードするためのdecode_predictions関数を書いています。
その後、予測とラベルからpandas DataFrameを作成し、DataFrameにepoch列を追加します。
最後に、DataFrameからwandb.Tableを作成し、それをwandbにログします。
さらに、freqエポックごとに予測をログすることで、ログの頻度を制御できます。
注意 : 通常のWandbCallbackとは異なり、このカスタムコールバックはTrainerの初期化時ではなく、Trainerがインスタンス化された後でトレーナーに追加する必要があります。これは、Trainerインスタンスが初期化中にコールバックに渡されるためです。
from transformers.integrations import WandbCallback
import pandas as pd
def decode_predictions (tokenizer, predictions):
labels = tokenizer. batch_decode(predictions. label_ids)
logits = predictions. predictions. argmax(axis=- 1 )
prediction_text = tokenizer. batch_decode(logits)
return {"labels" : labels, "predictions" : prediction_text}
class WandbPredictionProgressCallback (WandbCallback):
"""トレーニング中にモデルの予測をログするカスタムWandbCallback。
このコールバックは、トレーニング中の各ログステップでモデルの予測とラベルをwandb.Tableにログします。トレーニングの進行に応じたモデルの予測を視覚化することができます。
Attributes:
trainer (Trainer): Hugging Face Trainerインスタンス。
tokenizer (AutoTokenizer): モデルに関連付けられたトークナイザー。
sample_dataset (Dataset): 予測を生成するための
検証データセットのサブセット。
num_samples (int, optional): 検証データセットから選択するサンプルの数。
デフォルトは100。
freq (int, optional): ログの頻度。デフォルトは2。
"""
def __init__(self, trainer, tokenizer, val_dataset, num_samples= 100 , freq= 2 ):
"""WandbPredictionProgressCallbackインスタンスを初期化します。
Args:
trainer (Trainer): Hugging Face Trainerインスタンス。
tokenizer (AutoTokenizer): モデルに関連付けられたトークナイザー。
val_dataset (Dataset): 検証データセット。
num_samples (int, optional): 予測を生成するために
検証データセットから選択するサンプルの数。
デフォルトは100。
freq (int, optional): ログの頻度。デフォルトは2。
"""
super(). __init__()
self. trainer = trainer
self. tokenizer = tokenizer
self. sample_dataset = val_dataset. select(range(num_samples))
self. freq = freq
def on_evaluate (self, args, state, control, ** kwargs):
super(). on_evaluate(args, state, control, ** kwargs)
# `freq`エポックごとに予測をログすることにより、ログの頻度を制御
if state. epoch % self. freq == 0 :
# 予測を生成
predictions = self. trainer. predict(self. sample_dataset)
# 予測とラベルをデコード
predictions = decode_predictions(self. tokenizer, predictions)
# 予測をwandb.Tableに追加
predictions_df = pd. DataFrame(predictions)
predictions_df["epoch" ] = state. epoch
records_table = self. _wandb. Table(dataframe= predictions_df)
# テーブルをwandbにログ
self. _wandb. log({"sample_predictions" : records_table})
# まずはTrainerをインスタンス化
trainer = Trainer(
model= model,
args= training_args,
train_dataset= lm_datasets["train" ],
eval_dataset= lm_datasets["validation" ],
)
# WandbPredictionProgressCallbackをインスタンス化
progress_callback = WandbPredictionProgressCallback(
trainer= trainer,
tokenizer= tokenizer,
val_dataset= lm_dataset["validation" ],
num_samples= 10 ,
freq= 2 ,
)
# コールバックをトレーナーに追加
trainer. add_callback(progress_callback)
詳細な例については、このcolab を参照してください。
利用可能な追加のW&B設定は？
Trainerでログされる内容のさらなる設定は、環境変数を設定することで可能です。W&B環境変数の完全なリストはこちらにあります 。
環境変数
使用法
WANDB_PROJECTプロジェクト名を付けます（デフォルトはhuggingface）
WANDB_LOG_MODELモデルチェックポイントをW&Bアーティファクトとしてログします（デフォルトはfalse）
false（デフォルト）：モデルチェックポイントは行われません checkpoint：args.save_stepsごとにチェックポイントがアップロードされます（TrainerのTrainingArgumentsで設定） end：トレーニングの終了時に最終モデルチェックポイントがアップロードされます。
WANDB_WATCHモデルの勾配、パラメータ、またはそのいずれもログするかどうかを設定します
false（デフォルト）：勾配やパラメータのログは行わない gradients：勾配のヒストグラムをログ all：勾配とパラメータのヒストグラムをログ
WANDB_DISABLEDtrueに設定すると、ログが完全にオフになります（デフォルトはfalse）
WANDB_SILENTtrueに設定すると、wandbによって印刷される出力が消音されます（デフォルトはfalse）
WANDB_WATCH= all
WANDB_SILENT= true
%env WANDB_WATCH=all
%env WANDB_SILENT=true
wandb.initをカスタマイズする方法は？Trainerが使用するWandbCallbackは、Trainerが初期化される際に内部的にwandb.initを呼び出します。代わりに、Trainerが初期化される前にwandb.initを手動で呼び出してrunを設定することもできます。これにより、W&Bのrun設定を完全にコントロールできます。
以下は、initに何を渡すかの例です。wandb.initの使用方法の詳細については、リファレンスドキュメントを参照してください 。
wandb. init(
project= "amazon_sentiment_analysis" ,
name= "bert-base-high-lr" ,
tags= ["baseline" , "high-lr" ],
group= "bert" ,
)
追加のリソース
以下は、6つのTransformersとW&Bに関連する記事で楽しめるかもしれないものです。
Hugging Face Transformersのハイパーパラメータ最適化
Hugging Face Transformersのハイパーパラメータ最適化のための3つの戦略：グリッド検索、ベイズ最適化、population based trainingが比較されています。
Hugging Face transformersの標準的なベースラインモデルを使用し、SuperGLUEベンチマークからRTEデータセットを使用してファインチューニングしたいと考えています。
結果は、population based trainingがHugging Face transformerモデルのハイパーパラメータ最適化に最も効果的なアプローチであることを示しています。
詳細なレポートはこちら をご覧ください。
Hugging Tweets: ツイートを生成するモデルをトレーニング
記事では、著者が任意の人のツイートを5分で再学習するようにGPT2 HuggingFace Transformerモデルをファインチューニングする方法を実演します。
モデルは以下のパイプラインを使用します：ツイートのダウンロード、データセットの最適化、初期実験、ユーザー間の損失の比較、モデルのファインチューニング。
詳細なレポートはこちら をご覧ください。
Hugging Face BERTとWBによる文の分類
この記事では、自然言語処理の最近のブレークスルーの力を活用した文分類器の構築について説明します。NLPへの転移学習の適用に焦点を当てています。
文法的に正しいかどうかをラベル付けした文のセットである、単一文分類用のThe Corpus of Linguistic Acceptability (CoLA) データセットを使用します。このデータセットは2018年5月に初めて公開されました。
GoogleのBERTを使用して、最小限の努力で様々なNLPタスクで高性能なモデルを作成します。
詳細なレポートはこちら をご覧ください。
Hugging Faceモデルパフォーマンスをトラックするためのステップバイステップガイド
W&Bと Hugging Face transformers を使って、BERT の97%の精度を維持しつつ、40%小さいTrasformerであるDistilBERTをGLUEベンチマークでトレーニングします。
GLUEベンチマークは、NLPモデルをトレーニングするための9つのデータセットとタスクのコレクションです。
詳細なレポートはこちら をご覧ください。
HuggingFaceにおけるEarly Stoppingの例
Early Stopping正則化を使用して、Hugging Face Transformerをファインチューニングすることは、PyTorchやTensorFlowでネイティブに実行できます。
TensorFlowでEarlyStoppingコールバックを使用する方法は、tf.keras.callbacks.EarlyStopping コールバックを使って簡単にできます。
PyTorchでは、オフの早期停止メソッドはありませんが、GitHub Gistで利用可能な早期停止フックがあります。
詳細なレポートはこちら をご覧ください。
カスタムデータセットでHugging Face Transformersをファインチューニングする方法
カスタムIMDBデータセットでセンチメント分析（二項分類）のためにDistilBERT transformerをファインチューニングします。
詳細なレポートはこちら をご覧ください。
ヘルプを受けたり、機能をリクエストする
Hugging Face W&Bインテグレーションに関する問題、質問、または機能のリクエストについては、Hugging Faceフォーラムのこのスレッド に投稿するか、Hugging FaceTransformers GitHubリポジトリ で問題を開いてください。
6.12 - Hugging Face Diffusers
Hugging Face Diffusers は、画像、オーディオ、さらには分子の3D構造を生成するための最先端の学習済み拡散モデルのためのライブラリです。W&B インテグレーションは、柔軟な実験管理、メディア可視化、パイプライン アーキテクチャー、および設定管理をインタラクティブで集中化されたダッシュボードに追加し、使いやすさを損ないません。
たった2行で次世代のログ
実験に関連するすべてのプロンプト、ネガティブプロンプト、生成されたメディア、および設定を、たった2行のコードを含めるだけでログできます。ログを始めるためのコードはこちらの2行です:
# autolog 関数をインポート
from wandb.integration.diffusers import autolog
# パイプラインを呼び出す前に autolog を呼ぶ
autolog(init= dict(project= "diffusers_logging" ))
実験の結果がどのようにログされるかの例です。
始め方
diffusers, transformers, accelerate, および wandb をインストールします。
コマンドライン:
pip install --upgrade diffusers transformers accelerate wandb
ノートブック:
!pip install --upgrade diffusers transformers accelerate wandb
autolog を使用して Weights & Biases の run を初期化し、すべてのサポートされているパイプライン呼び出し からの入出力を自動的に追跡します。
init パラメータを持つ autolog() 関数を呼び出すことができ、このパラメータは wandb.init()
autolog() を呼び出すと、Weights & Biases の run が初期化され、すべてのサポートされているパイプライン呼び出し からの入力と出力が自動的に追跡されます。
各パイプライン呼び出しはその run のワークスペース内の独自の table に追跡され、パイプライン呼び出しに関連する設定はその run のワークフローリストに追加されます。
プロンプト、ネガティブプロンプト、生成されたメディアは wandb.Table
シードやパイプライン アーキテクチャーを含む実験に関連するすべての他の設定は、その run の設定セクションに保存されます。
各パイプライン呼び出しの生成されたメディアは run の media panels にもログされます。
サポートされているパイプライン呼び出しのリストは[こちら](https://github.com/wandb/wandb/blob/main/wandb/integration/diffusers/autologger.py#L12-L72)から見つけることができます。このインテグレーションの新機能をリクエストしたり、関連するバグを報告したりする場合は、[https://github.com/wandb/wandb/issues](https://github.com/wandb/wandb/issues)で問題をオープンしてください。
例
Autologging
ここでは、autolog の動作を示す簡単なエンドツーエンドの例を示します。
import torch
from diffusers import DiffusionPipeline
# autolog 関数をインポート
from wandb.integration.diffusers import autolog
# パイプラインを呼び出す前に autolog を呼ぶ
autolog(init= dict(project= "diffusers_logging" ))
# 拡散パイプラインを初期化
pipeline = DiffusionPipeline. from_pretrained(
"stabilityai/stable-diffusion-2-1" , torch_dtype= torch. float16
). to("cuda" )
# プロンプト、ネガティブプロンプト、種を定義
prompt = ["a photograph of an astronaut riding a horse" , "a photograph of a dragon" ]
negative_prompt = ["ugly, deformed" , "ugly, deformed" ]
generator = torch. Generator(device= "cpu" ). manual_seed(10 )
# パイプラインを呼び出して画像を生成
images = pipeline(
prompt,
negative_prompt= negative_prompt,
num_images_per_prompt= 2 ,
generator= generator,
)
import torch
from diffusers import DiffusionPipeline
import wandb
# autolog 関数をインポート
from wandb.integration.diffusers import autolog
# パイプラインを呼び出す前に autolog を呼ぶ
autolog(init= dict(project= "diffusers_logging" ))
# 拡散パイプラインを初期化
pipeline = DiffusionPipeline. from_pretrained(
"stabilityai/stable-diffusion-2-1" , torch_dtype= torch. float16
). to("cuda" )
# プロンプト、ネガティブプロンプト、種を定義
prompt = ["a photograph of an astronaut riding a horse" , "a photograph of a dragon" ]
negative_prompt = ["ugly, deformed" , "ugly, deformed" ]
generator = torch. Generator(device= "cpu" ). manual_seed(10 )
# パイプラインを呼び出して画像を生成
images = pipeline(
prompt,
negative_prompt= negative_prompt,
num_images_per_prompt= 2 ,
generator= generator,
)
# 実験を終了
wandb. finish()
単一の実験の結果:
複数の実験の結果:
実験の設定:
パイプラインを呼び出した後、IPython ノートブック環境でコードを実行する際には
wandb.finish()を明示的に呼び出す必要があります。Python スクリプトを実行する際は必要ありません。
マルチパイプライン ワークフローの追跡
このセクションでは、StableDiffusionXLPipelineStable Diffusion XL + Refiner ワークフローを使用した autolog のデモンストレーションを行います。
import torch
from diffusers import StableDiffusionXLImg2ImgPipeline, StableDiffusionXLPipeline
from wandb.integration.diffusers import autolog
# SDXL ベース パイプラインを初期化
base_pipeline = StableDiffusionXLPipeline. from_pretrained(
"stabilityai/stable-diffusion-xl-base-1.0" ,
torch_dtype= torch. float16,
variant= "fp16" ,
use_safetensors= True ,
)
base_pipeline. enable_model_cpu_offload()
# SDXL リファイナー パイプラインを初期化
refiner_pipeline = StableDiffusionXLImg2ImgPipeline. from_pretrained(
"stabilityai/stable-diffusion-xl-refiner-1.0" ,
text_encoder_2= base_pipeline. text_encoder_2,
vae= base_pipeline. vae,
torch_dtype= torch. float16,
use_safetensors= True ,
variant= "fp16" ,
)
refiner_pipeline. enable_model_cpu_offload()
prompt = "a photo of an astronaut riding a horse on mars"
negative_prompt = "static, frame, painting, illustration, sd character, low quality, low resolution, greyscale, monochrome, nose, cropped, lowres, jpeg artifacts, deformed iris, deformed pupils, bad eyes, semi-realistic worst quality, bad lips, deformed mouth, deformed face, deformed fingers, deformed toes standing still, posing"
# 乱数を制御することで実験を再現可能にします。
# シードは自動的に WandB にログされます。
seed = 42
generator_base = torch. Generator(device= "cuda" ). manual_seed(seed)
generator_refiner = torch. Generator(device= "cuda" ). manual_seed(seed)
# WandB Autolog を Diffusers に呼び出します。これにより、
# プロンプト、生成された画像、パイプライン アーキテクチャー、すべての
# 関連する実験設定が Weights & Biases に自動的にログされ、
# 画像生成実験を簡単に再現、共有、分析できるようになります。
autolog(init= dict(project= "sdxl" ))
# ベースパイプラインを呼び出して潜在変数を生成
image = base_pipeline(
prompt= prompt,
negative_prompt= negative_prompt,
output_type= "latent" ,
generator= generator_base,
). images[0 ]
# リファイナーパイプラインを呼び出して調整された画像を生成
image = refiner_pipeline(
prompt= prompt,
negative_prompt= negative_prompt,
image= image[None , :],
generator= generator_refiner,
). images[0 ]
import torch
from diffusers import StableDiffusionXLImg2ImgPipeline, StableDiffusionXLPipeline
import wandb
from wandb.integration.diffusers import autolog
# SDXL ベース パイプラインを初期化
base_pipeline = StableDiffusionXLPipeline. from_pretrained(
"stabilityai/stable-diffusion-xl-base-1.0" ,
torch_dtype= torch. float16,
variant= "fp16" ,
use_safetensors= True ,
)
base_pipeline. enable_model_cpu_offload()
# SDXL リファイナー パイプラインを初期化
refiner_pipeline = StableDiffusionXLImg2ImgPipeline. from_pretrained(
"stabilityai/stable-diffusion-xl-refiner-1.0" ,
text_encoder_2= base_pipeline. text_encoder_2,
vae= base_pipeline. vae,
torch_dtype= torch. float16,
use_safetensors= True ,
variant= "fp16" ,
)
refiner_pipeline. enable_model_cpu_offload()
prompt = "a photo of an astronaut riding a horse on mars"
negative_prompt = "static, frame, painting, illustration, sd character, low quality, low resolution, greyscale, monochrome, nose, cropped, lowres, jpeg artifacts, deformed iris, deformed pupils, bad eyes, semi-realistic worst quality, bad lips, deformed mouth, deformed face, deformed fingers, deformed toes standing still, posing"
# 乱数を制御することで実験を再現可能にします。
# シードは自動的に WandB にログされます。
seed = 42
generator_base = torch. Generator(device= "cuda" ). manual_seed(seed)
generator_refiner = torch. Generator(device= "cuda" ). manual_seed(seed)
# WandB Autolog を Diffusers に呼び出します。これにより、
# プロンプト、生成された画像、パイプライン アーキテクチャー、すべての
# 関連する実験設定が Weights & Biases に自動的にログされ、
# 画像生成実験を簡単に再現、共有、分析できるようになります。
autolog(init= dict(project= "sdxl" ))
# ベースパイプラインを呼び出して潜在変数を生成
image = base_pipeline(
prompt= prompt,
negative_prompt= negative_prompt,
output_type= "latent" ,
generator= generator_base,
). images[0 ]
# リファイナーパイプラインを呼び出して調整された画像を生成
image = refiner_pipeline(
prompt= prompt,
negative_prompt= negative_prompt,
image= image[None , :],
generator= generator_refiner,
). images[0 ]
# 実験を終了
wandb. finish()
Stable Diffusion XL + Refiner の実験の例:
追加リソース
6.13 - Hugging Face AutoTrain
Hugging Face AutoTrain は、自然言語処理 (NLP) タスク、コンピュータビジョン (CV) タスク、スピーチ タスク、さらには表形式のタスクのための最先端モデルをトレーニングするノーコードツールです。
Weights & Biases は Hugging Face AutoTrain に直接インテグレーションされています。実験管理と設定管理を提供します。実験には CLI コマンド内の単一パラメータを使用するだけで簡単です。
必要条件をインストールする
autotrain-advanced と wandb をインストールします。
pip install --upgrade autotrain-advanced wandb
!pip install --upgrade autotrain-advanced wandb
これらの変更を示すために、このページでは数学データセット上での LLM の微調整を行い、GSM8k Benchmarks での pass@1 での最先端の結果を達成します。
データセットを準備する
Hugging Face AutoTrain は、独自の CSV データセットが適切に動作するために特定の形式を持つことを期待しています。
トレーニングファイルには、トレーニングで使用される text カラムが含まれている必要があります。最良の結果を得るために、text カラムのデータは ### Human: Question?### Assistant: Answer. 形式に準拠している必要があります。timdettmers/openassistant-guanaco
しかし、MetaMathQA データセット には、query、response、type のカラムが含まれています。まず、このデータセットを前処理します。typeカラムを削除し、queryとresponseカラムの内容を ### Human: Query?### Assistant: Response. 形式で新しい text カラムに結合します。トレーニングは、結果のデータセット、rishiraj/guanaco-style-metamath
autotrain を使用したトレーニングコマンドラインまたはノートブックから autotrain の高度な機能を使用してトレーニングを開始できます。--log 引数を使用するか、--log wandb を使用して、W&B run に結果をログします。
autotrain llm \
\
\
\
\
\
\
\
4 \
3 \
1024 \
\
16 \
32 \
\
\
4 \
10 \
\
\
\
\
\
\
# ハイパーパラメーターを設定する
learning_rate = 2e-5
num_epochs = 3
batch_size = 4
block_size = 1024
trainer = "sft"
warmup_ratio = 0.03
weight_decay = 0.
gradient_accumulation = 4
lora_r = 16
lora_alpha = 32
lora_dropout = 0.05
logging_steps = 10
# トレーニングを実行する
!autotrain llm \
--train \
--model "HuggingFaceH4/zephyr-7b-alpha" \
--project-name "zephyr-math" \
--log "wandb" \
--data-path data/ \
--text-column text \
--lr str(learning_rate) \
--batch-size str(batch_size) \
--epochs str(num_epochs) \
--block-size str(block_size) \
--warmup-ratio str(warmup_ratio) \
--lora-r str(lora_r) \
--lora-alpha str(lora_alpha) \
--lora-dropout str(lora_dropout) \
--weight-decay str(weight_decay) \
--gradient-accumulation str(gradient_accumulation) \
--logging-steps str(logging_steps) \
--fp16 \
--use-peft \
--use-int4 \
--merge-adapter \
--push-to-hub \
--token str(hf_token) \
--repo-id "rishiraj/zephyr-math"
追加のリソース
6.14 - Hugging Face Accelerate
大規模なトレーニングと推論がシンプルで効率的、かつ適応可能に
Hugging Face Accelerate は、同じ PyTorch コードを任意の分散設定で実行できるようにするライブラリで、モデルトレーニングとスケールでの推論を簡素化します。
Accelerate は Weights & Biases Tracker を含んでおり、以下でその使用方法を示します。また、Accelerate Trackers について詳しくは こちらのドキュメント
Accelerate を使ってログを開始する
Accelerate と Weights & Biases を使用するには、以下の疑似コードに従ってください。
from accelerate import Accelerator
# Accelerator オブジェクトに wandb でログを記録するように伝える
accelerator = Accelerator(log_with= "wandb" )
# wandb run を初期化し、wandb のパラメータと任意の設定情報を渡す
accelerator. init_trackers(
project_name= "my_project" ,
config= {"dropout" : 0.1 , "learning_rate" : 1e-2 }
init_kwargs= {"wandb" : {"entity" : "my-wandb-team" }}
)
...
# `accelerator.log`を呼び出して wandb にログを記録する、`step` はオプション
accelerator. log({"train_loss" : 1.12 , "valid_loss" : 0.8 }, step= global_step)
# wandb トラッカーが正しく終了するようにする
accelerator. end_training()
さらに説明すると、以下の手順が必要です。
Accelerator クラスを初期化するときに log_with="wandb" を渡す
init_trackers
project_name よりプロジェクト名wandb.initinit_kwargs にwandb run にログ記録したい任意の実験設定情報を config で
Weights & Biases にログを記録するために .log メソッドを使用する; step 引数はオプション
トレーニングが終了したら .end_training を呼び出す
W&B トラッカーへのアクセス
W&B トラッカーにアクセスするには、Accelerator.get_tracker() メソッドを使用します。トラッカーの.name属性に対応する文字列を渡すと、main プロセスのトラッカーが返されます。
wandb_tracker = accelerator. get_tracker("wandb" )
そこから、通常通り wandb の run オブジェクトと対話できます:
wandb_tracker. log_artifact(some_artifact_to_log)
Accelerate にビルトインされたトラッカーは、正しいプロセスで自動的に実行されるので、トラッカーがメインプロセスでのみ実行するように設定されている場合、それが自動的に行われます。
Accelerate のラッピングを完全に削除したい場合は、次の方法で同じ結果を得ることができます:
wandb_tracker = accelerator. get_tracker("wandb" , unwrap= True )
with accelerator. on_main_process:
wandb_tracker. log_artifact(some_artifact_to_log)
Accelerate 記事
以下は Accelerate 記事で、お楽しみいただけるかもしれません。
HuggingFace Accelerate Super Charged With Weights & Biases
この記事では、HuggingFace Accelerate が提供するものと、Weights & Biases に結果を記録しながら分散トレーニングと評価を簡単に行う方法を紹介します。
完全なレポートは こちら をご覧ください。
6.15 - Hydra
W&B を Hydra と統合する方法。
Hydra は、研究やその他の複雑なアプリケーションの開発を簡素化するオープンソースの Python フレームワークです。重要な機能は、構成を合成して階層的に動的に作成し、それを構成ファイルやコマンドラインを介してオーバーライドする能力です。
W&B の機能を活用しながら、Hydra を使った設定管理を引き続き利用できます。
メトリクスの追跡
通常通り、wandb.init と wandb.log を用いてメトリクスを追跡します。ここでは、wandb.entity と wandb.project は hydra 設定ファイル内で定義されています。
import wandb
@hydra.main (config_path= "configs/" , config_name= "defaults" )
def run_experiment (cfg):
run = wandb. init(entity= cfg. wandb. entity, project= cfg. wandb. project)
wandb. log({"loss" : loss})
ハイパーパラメーターの追跡
Hydra は設定辞書を操作するためのデフォルト手段として omegaconf を利用しています。OmegaConf の辞書は基本的な辞書のサブクラスではないため、Hydra の Config を直接 wandb.config に渡すとダッシュボードで予期せぬ結果を引き起こします。omegaconf.DictConfig を基本的な dict 型に変換してから wandb.config に渡す必要があります。
@hydra.main (config_path= "configs/" , config_name= "defaults" )
def run_experiment (cfg):
wandb. config = omegaconf. OmegaConf. to_container(
cfg, resolve= True , throw_on_missing= True
)
wandb. init(entity= cfg. wandb. entity, project= cfg. wandb. project)
wandb. log({"loss" : loss})
model = Model(** wandb. config. model. configs)
マルチプロセッシングのトラブルシューティング
プロセスの開始時にハングアップする場合、この既知の問題 による可能性があります。これを解決するには、次のように wandb.init に追加の設定パラメータを追加することで、wandb のマルチプロセッシングプロトコルを変更してみてください。
wandb. init(settings= wandb. Settings(start_method= "thread" ))
または、シェルからグローバルな環境変数を設定することで:
$ export WANDB_START_METHOD= thread
ハイパーパラメーターの最適化
W&B Sweeps は高度にスケーラブルなハイパーパラメーター探索プラットフォームで、最低限のコードスペースで W&B 実験に関する興味深い洞察と可視化を提供します。 Sweeps は Hydra プロジェクトにノーコーディングでシームレスに統合されます。必要なのは、通常のようにスイープの対象となる様々なパラメータを説明する設定ファイルです。
単純な例としての sweep.yaml ファイルは以下の通りです:
program : main.py
method : bayes
metric :
goal : maximize
name : test/accuracy
parameters :
dataset :
values : [mnist, cifar10]
command :
- ${env}
- python
- ${program}
- ${args_no_hyphens}
スイープを呼び出します:
wandb sweep sweep.yaml` \
W&B は自動的にプロジェクト内にスイープを作成し、各マシンでスイープを実行するための wandb agent コマンドを返します。
Hydra デフォルトに存在しないパラメーターを渡す
Hydra はデフォルトの設定ファイルに存在しない追加のパラメーターをコマンドラインを通して渡すことをサポートしており、コマンド前に + を付けることで可能です。例えば、一部の値とともに追加のパラメーターを渡すには、以下のように単に呼び出します:
$ python program.py +experiment= some_experiment
このような + 設定に対して、Hydra Experiments の設定時と同様にスイープすることはできません。この問題を回避するために、実験パラメーターをデフォルトの空ファイルで初期化し、W&B Sweep を用いて各呼び出し時にこれらの空の設定をオーバーライドすることができます。詳細については、この W&B Report
6.16 - Keras
Keras コールバック
W&B は Keras 用に3つのコールバックを提供しています。wandb v0.13.4から利用可能です。レガシーな WandbCallback は下にスクロールしてください。
WandbMetricsLoggerExperiment Tracking に使用します。トレーニングと検証のメトリクス、システムメトリクスを Weights and Biases にログします。
WandbModelCheckpointArtifacts にログするためにこのコールバックを使用します。
WandbEvalCallbackTables にログして、インタラクティブな可視化を行います。
これらの新しいコールバックは以下の特徴を持っています：
Keras のデザイン哲学に従います。
すべての機能に対して単一のコールバック (WandbCallback) を使用する際の認知負荷を減らします。
Keras ユーザーがコールバックをサブクラス化してニッチなユースケースをサポートできるように簡単に改修できます。
WandbMetricsLogger を使用して実験を追跡WandbMetricsLogger は、on_epoch_end や on_batch_end などのコールバックメソッドが引数として取得する Keras の logs 辞書を自動的にログします。
これにより次の項目が追跡されます：
model.compile に定義されたトレーニングと検証のメトリクス。システム (CPU/GPU/TPU) のメトリクス。
学習率（固定値または学習率スケジューラ）。
import wandb
from wandb.integration.keras import WandbMetricsLogger
# 新しい W&B run を初期化
wandb. init(config= {"bs" : 12 })
# WandbMetricsLogger を model.fit に渡す
model. fit(
X_train, y_train, validation_data= (X_test, y_test), callbacks= [WandbMetricsLogger()]
)
WandbMetricsLogger リファレンス
パラメータ
説明
log_freq(epoch, batch, または int): epoch の場合、各エポック終了時にメトリクスをログします。batch の場合、各バッチ終了時にメトリクスをログします。int の場合、その数のバッチ終了時にメトリクスをログします。デフォルトは epoch。
initial_global_step(int): 初期エポックからトレーニングを再開し、かつ学習率スケジューラを使用する場合、学習率を正しくログするためにこの引数を使用します。step_size * initial_step として計算できます。デフォルトは 0。
WandbModelCheckpoint を使用してモデルをチェックポイントWandbModelCheckpoint コールバックを使用して、Keras モデル (SavedModel 形式) またはモデルの重みを定期的に保存し、モデルのバージョン管理のために W&B アーティファクトとしてアップロードします。
このコールバックは tf.keras.callbacks.ModelCheckpoint
このコールバックが保存するもの：
モニターに基づいて最高のパフォーマンスを達成したモデル。
パフォーマンスに関係なく各エポック終了時のモデル。
エポックまたは一定のトレーニングバッチ数後のモデル。
モデルの重みのみ、またはモデル全体。
SavedModel 形式または .h5 形式いずれかのモデル。
このコールバックは WandbMetricsLogger と併用してください。
import wandb
from wandb.integration.keras import WandbMetricsLogger, WandbModelCheckpoint
# 新しい W&B run を初期化
wandb. init(config= {"bs" : 12 })
# WandbModelCheckpoint を model.fit に渡す
model. fit(
X_train,
y_train,
validation_data= (X_test, y_test),
callbacks= [
WandbMetricsLogger(),
WandbModelCheckpoint("models" ),
],
)
WandbModelCheckpoint リファレンス
パラメータ
説明
filepath(str): モードファイルを保存するパス。
monitor(str): モニターするメトリクスの名前。
verbose(int): 冗長モード。0 または 1。モード 0 は静かに動作し、モード 1 はコールバックがアクションをとるときにメッセージを表示します。
save_best_only(Boolean): save_best_only=True の場合、monitor と mode 属性で定義された要件に基づいて最新のモデルまたはベストとみなされるモデルのみを保存します。
save_weights_only(Boolean): True の場合、モデルの重みのみを保存します。
mode(auto, min, or max): val_acc の場合は max に設定し、val_loss の場合は min に設定してください。
save_freq(“epoch” or int): epoch を使用する場合、コールバックは各エポック後にモデルを保存します。整数を使用する場合、指定されたバッチ数の終了時にモデルを保存します。val_acc や val_loss などの検証メトリクスを監視する場合、save_freq は “epoch” に設定する必要があります。
options(str): save_weights_only が真の場合はオプションの tf.train.CheckpointOptions オブジェクト、save_weights_only が偽の場合はオプションの tf.saved_model.SaveOptions オブジェクト。
initial_value_threshold(float): 監視するメトリクスの初期 “ベスト” 値。
N エポック後にチェックポイントをログ
デフォルト (save_freq="epoch") では、コールバックは各エポック後にアーティファクトとしてチェックポイントを作成し、アップロードします。特定のバッチ数後にチェックポイントを作成するには、save_freq を整数に設定します。N エポック後にチェックポイントを作成するには、train データローダーの基数を計算し、それを save_freq に渡します。
WandbModelCheckpoint(
filepath= "models/" ,
save_freq= int((trainloader. cardinality()* N). numpy())
)
TPU アーキテクチャーで効率的にチェックポイントをログ
TPU 上でチェックポイントを作成する際に、UnimplementedError: File system scheme '[local]' not implemented エラーメッセージが発生することがあります。これは、モデルディレクトリー (filepath) がクラウドストレージバケットパス (gs://bucket-name/...) を使用しなければならないためであり、このバケットは TPU サーバーからアクセス可能でなければなりません。ただし、ローカルパスを使用してチェックポイントを行い、それを Artifacts としてアップロードすることは可能です。
checkpoint_options = tf. saved_model. SaveOptions(experimental_io_device= "/job:localhost" )
WandbModelCheckpoint(
filepath= "models/,
options= checkpoint_options,
)
モデル予測を WandbEvalCallback で可視化
WandbEvalCallback は、モデル予測のための Keras コールバックを主に構築するための抽象基底クラスであり、副次的にデータセットの可視化にも使われます。
この抽象コールバックは、データセットやタスクに対してはアグノスティックです。これを使用するには、このベース WandbEvalCallback コールバッククラスを継承し、add_ground_truth と add_model_prediction メソッドを実装します。
WandbEvalCallback は、以下のメソッドを提供するユーティリティクラスです：
データと予測の wandb.Table インスタンスを作成します。
データと予測のテーブルを wandb.Artifact としてログします。
on_train_begin 時にデータテーブルをログします。on_epoch_end 時に予測テーブルをログします。
以下の例では、画像分類タスクのために WandbClfEvalCallback を使用しています。この例のコールバックは検証データ (data_table) を W&B にログし、推論を行い、各エポック終了時に予測 (pred_table) を W&B にログします。
import wandb
from wandb.integration.keras import WandbMetricsLogger, WandbEvalCallback
# モデル予測可視化用コールバックを実装
class WandbClfEvalCallback (WandbEvalCallback):
def __init__(
self, validation_data, data_table_columns, pred_table_columns, num_samples= 100
):
super(). __init__(data_table_columns, pred_table_columns)
self. x = validation_data[0 ]
self. y = validation_data[1 ]
def add_ground_truth (self, logs= None ):
for idx, (image, label) in enumerate(zip(self. x, self. y)):
self. data_table. add_data(idx, wandb. Image(image), label)
def add_model_predictions (self, epoch, logs= None ):
preds = self. model. predict(self. x, verbose= 0 )
preds = tf. argmax(preds, axis=- 1 )
table_idxs = self. data_table_ref. get_index()
for idx in table_idxs:
pred = preds[idx]
self. pred_table. add_data(
epoch,
self. data_table_ref. data[idx][0 ],
self. data_table_ref. data[idx][1 ],
self. data_table_ref. data[idx][2 ],
pred,
)
# ...
# 新しい W&B run を初期化
wandb. init(config= {"hyper" : "parameter" })
# コールバックを Model.fit に追加
model. fit(
X_train,
y_train,
validation_data= (X_test, y_test),
callbacks= [
WandbMetricsLogger(),
WandbClfEvalCallback(
validation_data= (X_test, y_test),
data_table_columns= ["idx" , "image" , "label" ],
pred_table_columns= ["epoch" , "idx" , "image" , "label" , "pred" ],
),
],
)
W&B の
Artifact ページ には、デフォルトでテーブルログが含まれており、
Workspace ページには含まれていません。
WandbEvalCallback リファレンス
パラメータ
説明
data_table_columns(list) data_table の列名のリスト
pred_table_columns(list) pred_table の列名のリスト
メモリ使用量の詳細
data_table は on_train_begin メソッドが呼び出されたときに W&B にログされます。一度 W&B アーティファクトとしてアップロードされると、data_table_ref クラス変数を使用してこのテーブルにアクセスすることができます。data_table_ref は 2D リストで、self.data_table_ref[idx][n] のようにインデックスを付けてアクセスできます。この例では、idx は行番号で、n は列番号です。
コールバックのカスタマイズ
on_train_begin や on_epoch_end メソッドをオーバーライドして、より細かい制御を行うことができます。N バッチ後にサンプルをログしたい場合、on_train_batch_end メソッドを実装することができます。
💡
WandbEvalCallback を継承してモデル予測可視化のコールバックを実装している場合、何か明確にすべき点や修正が必要な場合は、問題を報告してお知らせください。
issue を開いてください。
WandbCallback [レガシー]WandbCallback クラスを使用して、model.fit で追跡されるすべてのメトリクスと損失値を自動的に保存します。
import wandb
from wandb.integration.keras import WandbCallback
wandb. init(config= {"hyper" : "parameter" })
... # Keras でモデルをセットアップするためのコード
# コールバックを model.fit に渡す
model. fit(
X_train, y_train, validation_data= (X_test, y_test), callbacks= [WandbCallback()]
)
短いビデオ Get Started with Keras and Weights & Biases in Less Than a Minute をご覧ください。
より詳細なビデオは Integrate Weights & Biases with Keras をご覧ください。Colab Jupyter Notebook を確認できます。
WandbCallback クラスは、広範なロギング設定オプションをサポートしています：監視するメトリクスの指定、重みや勾配の追跡、トレーニングデータと検証データ上の予測のログなど。
keras.WandbCallback の参考文献のドキュメントも確認してください。より詳細な情報があります。
WandbCallback
Keras によって収集された任意のメトリクスの履歴データを自動的にログします：keras_model.compile() に渡された損失とその他の項目。
monitor と mode 属性によって定義された “最良” のトレーニングステップに関連付けられたサマリーメトリクスを設定します。これはデフォルトでは最小の val_loss を持つエポックとなります。WandbCallback はデフォルトで最も良い epoch に関連付けられたモデルを保存します。勾配とパラメータのヒストグラムをオプションでログします。
オプションで wandb に視覚化するためのトレーニングおよび検証データを保存します。
WandbCallback リファレンス
引数
monitor(str) monitor するメトリックの名前。デフォルトは val_loss。
mode(str) {auto, min, max} のいずれか。min - モニターが最小化されるときにモデルを保存 max - モニターが最大化されるときにモデルを保存 auto - モデル保存のタイミングを推測（デフォルト）。
save_modelTrue - monitor が過去のすべてのエポックを上回った場合にモデルを保存 False - モデルを保存しない
save_graph(boolean) True の場合、wandb にモデルグラフを保存します（デフォルトは True）。
save_weights_only(boolean) True の場合、モデルの重みのみを保存します（model.save_weights(filepath)）。そうでなければ、完全なモデルを保存します。
log_weights(boolean) True の場合、モデルのレイヤーの重みのヒストグラムを保存します。
log_gradients(boolean) True の場合、トレーニング勾配のヒストグラムをログします
training_data(tuple) model.fit に渡される (X,y) と同じ形式。勾配を計算するために必要で、log_gradients が True の場合必須です。
validation_data(tuple) model.fit に渡される (X,y) と同じ形式。Wandb が視覚化するためのデータセット。フィールドを設定すると、各エポックで wandb が少数の予測を行い、視覚化のための結果を保存します。
generator(generator) wandb が視覚化するための検証データを返すジェネレータ。このジェネレータはタプル (X,y) を返すべきです。validate_data またはジェネレータのいずれかをセットすることで、wandb は特定のデータ例を視覚化できます。
validation_steps(int) validation_data がジェネレータの場合、完全な検証セットのためにジェネレータを実行するステップ数。
labels(list) wandb でデータを視覚化する場合、複数クラスの分類器を構築する際の数値出力を理解しやすい文字列に変換するラベルのリスト。バイナリ分類器の場合、2つのラベル [label for false, label for true] を渡すことができます。validate_data と generator の両方がfalseの場合は何も行いません。
predictions(int) 各エポックの視覚化のために行う予測の数。最大は 100 です。
input_type(string) 視覚化を助けるためのモデル入力の型。image、images、segmentation_mask のいずれか。
output_type(string) 視覚化を助けるためのモデル出力の型。image、images、segmentation_mask のいずれか。
log_evaluation(boolean) True の場合、各エポックで検証データとモデルの予測を含むテーブルを保存します。詳細は validation_indexes、validation_row_processor、output_row_processor を参照してください。
class_colors([float, float, float]) 入力または出力がセグメンテーションマスクの場合、各クラスのための RGB タプル（範囲 0-1）を含む配列。
log_batch_frequency(integer) None の場合、コールバックは各エポックをログします。整数を設定する場合、コールバックは log_batch_frequency バッチごとにトレーニングメトリクスをログします。
log_best_prefix(string) None の場合、追加のサマリーメトリクスを保存しません。文字列が設定されている場合、プレフィックスとともに監視されたメトリクスとエポックを毎回保存し、サマリーメトリクスとして保存します。
validation_indexes([wandb.data_types._TableLinkMixin]) 各検証例に関連付けるインデックスキーの順序付きリスト。log_evaluation が True で validation_indexes を提供する場合、検証データのテーブルを作成しません。その代わり、各予測を TableLinkMixin で表される行に関連付けます。行のキーを取得するには、Table.get_index() を使用します。
validation_row_processor(Callable) 検証データに適用される関数で、一般にデータを視覚化するのに使用します。関数には ndx (int) と row (dict) が渡されます。モデルに単一の入力がある場合、row["input"] はその行の入力データを含みます。そうでない場合、入力スロットの名前を含みます。fit フィット関数が単一のターゲットを取り込む場合、row["target"] はその行のターゲットデータを含みます。異なるアウトプットスロットの名前を含んでいます。たとえば、入力データが単一の配列で、そのデータをImageとして視覚化するためには、lambda ndx, row: {"img": wandb.Image(row["input"])} をプロセッサとして提供します。log_evaluation がFalseの場合や validation_indexes が存在する場合は無視されます。
output_row_processor(Callable) validation_row_processor と同様だが、モデルの出力に適用されます。row["output"] はモデルの出力結果を含みます。
infer_missing_processors(Boolean) validation_row_processor と output_row_processor が欠落している場合にそれを推測するかどうかを決定します。デフォルトでは True。labels を提供すると、W&B は適切な場合に分類タイプのプロセッサを推測しようとします。
log_evaluation_frequency(int) 評価結果の記録頻度を決定します。デフォルトは 0 で、トレーニングの終了時にのみログします。1に設定すると各エポックごとにログします。2ならば隔エポックでログします。log_evaluation が False のときには効果がありません。
よくある質問
Keras のマルチプロセッシングを wandb でどのように使用しますか？use_multiprocessing=True を設定したときにこのエラーが発生する場合があります：
Error("You must call wandb.init() before wandb.config.batch_size" )
それを回避する方法：
Sequence クラスの構築時に、これを追加：wandb.init(group='...')。main で、if __name__ == "__main__": を使用して、スクリプトロジックの残りをその中に置くようにしてください。
6.17 - Kubeflow パイプライン (kfp)
W&B を Kubeflow パイプラインと統合する方法。
https://www.kubeflow.org/docs/components/pipelines/overview/ は、Dockerコンテナに基づいて、移植性がありスケーラブルな機械学習（ML）ワークフローを構築およびデプロイするためのプラットフォームです。
このインテグレーションにより、ユーザーは kfp のPython機能コンポーネントにデコレーターを適用して、パラメータとArtifactsを自動的にW&Bにログすることができます。
この機能は wandb==0.12.11 で有効になり、kfp<2.0.0 が必要です。
登録してAPIキーを作成する
APIキーは、あなたのマシンをW&Bに認証します。APIキーは、ユーザープロファイルから生成できます。
右上隅のユーザープロファイルアイコンをクリックします。
User Settings を選択し、API Keys セクションまでスクロールします。Reveal をクリックします。表示されたAPIキーをコピーします。APIキーを隠すには、ページをリロードしてください。
wandb ライブラリをインストールしてログインローカルに wandb ライブラリをインストールしてログインするには：
Command Line
Python
Python notebook
WANDB_API_KEY 環境変数 をAPIキーに設定します。
export WANDB_API_KEY= <your_api_key>
wandb ライブラリをインストールしてログインします。
pip install wandb
wandb login
import wandb
wandb. login()
!pip install wandb
import wandb
wandb.login()
コンポーネントをデコレートする
@wandb_log デコレーターを追加し、通常通りコンポーネントを作成します。これにより、パイプラインを実行するたびに入力/出力パラメータとArtifactsがW&Bに自動的にログされます。
from kfp import components
from wandb.integration.kfp import wandb_log
@wandb_log
def add (a: float, b: float) -> float:
return a + b
add = components. create_component_from_func(add)
環境変数をコンテナに渡す
環境変数 をコンテナに明示的に渡す必要があるかもしれません。双方向リンクのためには、WANDB_KUBEFLOW_URL 環境変数をKubeflow Pipelinesインスタンスの基本URLに設定する必要があります。例えば、https://kubeflow.mysite.comです。
import os
from kubernetes.client.models import V1EnvVar
def add_wandb_env_variables (op):
env = {
"WANDB_API_KEY" : os. getenv("WANDB_API_KEY" ),
"WANDB_BASE_URL" : os. getenv("WANDB_BASE_URL" ),
}
for name, value in env. items():
op = op. add_env_variable(V1EnvVar(name, value))
return op
@dsl.pipeline (name= "example-pipeline" )
def example_pipeline (param1: str, param2: int):
conf = dsl. get_pipeline_conf()
conf. add_op_transformer(add_wandb_env_variables)
データへのプログラムによるアクセス
Kubeflow Pipelines UI から
W&Bでログされた任意の Run を Kubeflow Pipelines UI でクリックします。
Input/Output と ML Metadata タブで入力と出力の詳細を見つけます。Visualizations タブからW&Bウェブアプリを表示します。
ウェブアプリ UI から
ウェブアプリ UI は Kubeflow Pipelines の Visualizations タブと同じコンテンツを持っていますが、より多くのスペースがあります。ここでウェブアプリ UI についてもっと学びましょう 。
公開APIを通じて（プログラムによるアクセス）
Kubeflow Pipelines と W&B の概念マッピング
ここに、Kubeflow Pipelines の概念を W&B にマッピングしたものがあります。
細かいログ
ログのコントロールを細かくしたい場合は、コンポーネントに wandb.log と wandb.log_artifact の呼び出しを追加できます。
明示的な wandb.log_artifacts 呼び出しと共に
以下の例では、モデルをトレーニングしています。@wandb_log デコレーターは関連する入力と出力を自動的に追跡します。トレーニングプロセスをログに追加したい場合は、以下のようにそのログを明示的に追加できます。
@wandb_log
def train_model (
train_dataloader_path: components. InputPath("dataloader" ),
test_dataloader_path: components. InputPath("dataloader" ),
model_path: components. OutputPath("pytorch_model" ),
):
...
for epoch in epochs:
for batch_idx, (data, target) in enumerate(train_dataloader):
...
if batch_idx % log_interval == 0 :
wandb. log(
{"epoch" : epoch, "step" : batch_idx * len(data), "loss" : loss. item()}
)
...
wandb. log_artifact(model_artifact)
暗黙的な wandb インテグレーションを使用
もしサポートする フレームワークインテグレーションを使用 している場合は、コールバックを直接渡すこともできます。
@wandb_log
def train_model (
train_dataloader_path: components. InputPath("dataloader" ),
test_dataloader_path: components. InputPath("dataloader" ),
model_path: components. OutputPath("pytorch_model" ),
):
from pytorch_lightning.loggers import WandbLogger
from pytorch_lightning import Trainer
trainer = Trainer(logger= WandbLogger())
... # トレーニングを行う
6.18 - LightGBM
W&B でツリーをトラッキングする。
wandb ライブラリには、LightGBM 用の特別なコールバックが含まれています。また、Weights & Biases の一般的なログ機能を使用して、大規模な実験やハイパーパラメータ探索を追跡することも簡単です。
from wandb.integration.lightgbm import wandb_callback, log_summary
import lightgbm as lgb
# メトリクスを W&B にログ
gbm = lgb. train(... , callbacks= [wandb_callback()])
# 特徴量のインポータンスプロットをログし、モデルのチェックポイントを W&B にアップロード
log_summary(gbm, save_model_checkpoint= True )
ハイパーパラメーターの調整と Sweeps
モデルから最大のパフォーマンスを引き出すには、ツリーの深さや学習率のようなハイパーパラメーターを調整する必要があります。Weights & Biases は、大規模なハイパーパラメータのテスト実験を設定、調整、分析するための強力なツールキットである Sweeps を含んでいます。
これらのツールについて学び、XGBoost で Sweeps を使用する方法の例を確認するには、この対話型 Colab ノートブックをチェックしてください。
6.19 - Metaflow
W&B と Metaflow を統合する方法。
概要
Metaflow は、Netflixが開発したMLワークフローを作成し実行するためのフレームワークです。
このインテグレーションにより、ユーザーはMetaflowのステップとフローにデコレータを適用して、W&Bにパラメータとアーティファクトを自動的にログすることができます。
ステップをデコレートすると、そのステップ内の特定のタイプに対してログのオンまたはオフが適用されます。
フローをデコレートすると、フロー内のすべてのステップに対してログのオンまたはオフが適用されます。
クイックスタート
サインアップしてAPIキーを作成する
APIキーはあなたのマシンをW&Bに認証します。ユーザープロフィールからAPIキーを生成することができます。
右上のユーザープロフィールアイコンをクリックします。
User Settings を選択し、API Keys セクションまでスクロールします。Reveal をクリックし、表示されたAPIキーをコピーします。ページをリロードするとAPIキーを隠すことができます。
wandbライブラリをインストールしてログインするローカルにwandbライブラリをインストールし、ログインするためには次の手順を行います。
Command Line
Python
Python notebook
WANDB_API_KEY 環境変数 をAPIキーに設定します。
export WANDB_API_KEY= <your_api_key>
wandbライブラリをインストールしてログインします。
pip install -Uqqq metaflow fastcore wandb
wandb login
pip install -Uqqq metaflow fastcore wandb
import wandb
wandb. login()
!pip install -Uqqq metaflow fastcore wandb
import wandb
wandb.login()
フローとステップをデコレートする
ステップをデコレートすることで、そのステップ内の特定のタイプに対してログのオンまたはオフが適用されます。
この例では、startにおける全てのデータセットとモデルがログされます。
from wandb.integration.metaflow import wandb_log
class WandbExampleFlow (FlowSpec):
@wandb_log (datasets= True , models= True , settings= wandb. Settings(... ))
@step
def start (self):
self. raw_df = pd. read_csv(... ). # pd.DataFrame -> データセットとしてアップロード
self. model_file = torch. load(... ) # nn.Module -> モデルとしてアップロード
self. next(self. transform)
フローをデコレートすることは、すべての構成ステップをデフォルトでデコレートすることに相当します。
この場合、WandbExampleFlowのすべてのステップは、各ステップを @wandb_log(datasets=True, models=True)でデコレートするのと同様に、デフォルトでデータセットとモデルをログします。
from wandb.integration.metaflow import wandb_log
@wandb_log (datasets= True , models= True ) # すべての@stepをデコレート
class WandbExampleFlow (FlowSpec):
@step
def start (self):
self. raw_df = pd. read_csv(... ). # pd.DataFrame -> データセットとしてアップロード
self. model_file = torch. load(... ) # nn.Module -> モデルとしてアップロード
self. next(self. transform)
フローをデコレートすることは、すべてのステップをデフォルトでデコレートすることを意味します。つまり、後でステップを別の@wandb_logでデコレートすると、フローレベルのデコレーションが上書きされます。
この例では:
startとmidは両方、データセットとモデルをログします。endは、データセットもモデルもログしません。
from wandb.integration.metaflow import wandb_log
@wandb_log (datasets= True , models= True ) # startとmidをデコレートするのと同じ
class WandbExampleFlow (FlowSpec):
# このステップはデータセットとモデルをログします
@step
def start (self):
self. raw_df = pd. read_csv(... ). # pd.DataFrame -> データセットとしてアップロード
self. model_file = torch. load(... ) # nn.Module -> モデルとしてアップロード
self. next(self. mid)
# このステップもデータセットとモデルをログします
@step
def mid (self):
self. raw_df = pd. read_csv(... ). # pd.DataFrame -> データセットとしてアップロード
self. model_file = torch. load(... ) # nn.Module -> モデルとしてアップロード
self. next(self. end)
# このステップは上書きされており、データセットもモデルもログしません
@wandb_log (datasets= False , models= False )
@step
def end (self):
self. raw_df = pd. read_csv(... ).
self. model_file = torch. load(... )
データへプログラムでアクセスする
キャプチャされた情報には3つの方法でアクセスできます: wandbクライアントライブラリウェブアプリUI 、あるいはパブリックAPI をプログラムで使用する方法です。パラメータはW&BのconfigOverviewタブ で見つけることができます。datasets、models、およびその他はW&B Artifacts に保存され、Artifactsタブ で見つけることができます。基本的なPythonタイプはW&BのsummaryパブリックAPIのガイド をご覧ください。
クイックリファレンス
データ
クライアントライブラリ
UI
Parameter(...)wandb.configOverviewタブ, Config
datasets, models, otherswandb.use_artifact("{var_name}:latest")Artifactsタブ
基本的なPython型 (dict, list, str, etc.)
wandb.summaryOverviewタブ, Summary
wandb_log引数
kwarg
オプション
datasetsTrue: インスタンス変数がデータセットの場合にログするFalse
modelsTrue: インスタンス変数がモデルの場合にログするFalse
othersTrue: pickleとしてシリアライズ可能なその他のものをログするFalse
settingswandb.Settings(…): このステップまたはフローのために独自のwandb設定を指定するNone: wandb.Settings()を渡すのと同じデフォルトでは、もし:
settings.run_groupがNoneであれば、{flow_name}/{run_id}に設定されますsettings.run_job_typeがNoneであれば、{run_job_type}/{step_name}に設定されます
よくある質問
正確には何をログしますか？すべてのインスタンスとローカル変数をログしますか？
wandb_logはインスタンス変数のみをログします。ローカル変数は決してログされません。これは不要なデータをログしないために役立ちます。
どのようなデータ型がログされますか？
現在、以下のタイプをサポートしています：
ログ設定
型
デフォルト(常にオン)
dict, list, set, str, int, float, bool
datasets
modelsnn.Modulesklearn.base.BaseEstimator
others
どのようにログの振る舞いを設定できますか？
変数の種類
振る舞い
例
データ型
インスタンス
自動ログされる
self.accuracyfloat
インスタンス
datasets=Trueの場合にログself.dfpd.DataFrame
インスタンス
datasets=Falseの場合はログされないself.dfpd.DataFrame
ローカル
ログされない
accuracyfloat
ローカル
ログされない
dfpd.DataFrame
アーティファクトのリネージは追跡されますか？
はい。ステップAの出力であり、ステップBの入力であるアーティファクトがあれば、リネージDAGを自動的に構築します。
この振る舞いの例については、このノートブック および対応する W&B Artifactsページ をご覧ください。
6.20 - MMEngine
MMEngine by OpenMMLab は、PyTorch に基づくディープラーニングモデルのトレーニングのための基盤ライブラリです。MMEngine は OpenMMLab のアルゴリズムライブラリ用の次世代のトレーニングアーキテクチャーを実装し、OpenMMLab 内の30以上のアルゴリズムライブラリに対して統一された実行基盤を提供します。そのコアコンポーネントには、トレーニングエンジン、評価エンジン、モジュール管理が含まれます。
Weights and Biases は、専用のWandbVisBackend
トレーニングおよび評価メトリクスをログする。
実験設定をログおよび管理する。
グラフ、画像、スカラーなどの追加記録をログする。
はじめに
openmim および wandb をインストールします。
pip install -q -U openmim wandb
!pip install -q -U openmim wandb
次に、mim を使用して mmengine および mmcv をインストールします。
mim install -q mmengine mmcv
!mim install -q mmengine mmcv
WandbVisBackend を MMEngine Runner で使用するこのセクションでは、mmengine.runner.RunnerWandbVisBackend の典型的なワークフローを示します。
可視化設定から visualizer を定義します。
from mmengine.visualization import Visualizer
# 可視化の設定を定義する
visualization_cfg = dict(
name= "wandb_visualizer" ,
vis_backends= [
dict(
type= 'WandbVisBackend' ,
init_kwargs= dict(project= "mmengine" ),
)
],
save_dir= "runs/wandb"
)
# 可視化設定から visualizer を取得する
visualizer = Visualizer. get_instance(** visualization_cfg)
[W&B run 初期化](/ja/ref/python/init/)の入力パラメータ用引数の辞書を `init_kwargs` に渡します。
visualizer とともに runner を初期化し、runner.train() を呼び出します。
from mmengine.runner import Runner
# PyTorch のトレーニングヘルパーである mmengine Runner を構築する
runner = Runner(
model,
work_dir= 'runs/gan/' ,
train_dataloader= train_dataloader,
train_cfg= train_cfg,
optim_wrapper= opt_wrapper_dict,
visualizer= visualizer, # visualizer を渡す
)
# トレーニングを開始する
runner. train()
WandbVisBackend を OpenMMLab コンピュータビジョンライブラリで使用するWandbVisBackend は、MMDetection のような OpenMMLab コンピュータビジョンライブラリを使って実験管理を追跡するためにも簡単に使用できます。
# デフォルトのランタイム設定から基本設定を継承する
_base_ = ["../_base_/default_runtime.py" ]
# base configs から `visualizer` の `vis_backends` に
# `WandbVisBackend` の設定辞書を割り当てる
_base_. visualizer. vis_backends = [
dict(
type= 'WandbVisBackend' ,
init_kwargs= {
'project' : 'mmdet' ,
'entity' : 'geekyrakshit'
},
),
]
6.21 - MMF
W&B を Meta AI の MMF と統合する方法。
WandbLogger クラスは、Meta AI の MMF ライブラリで Weights & Biases を使用して、トレーニング/検証メトリクス、システム (GPU および CPU) メトリクス、モデルチェックポイント、設定パラメータをログすることを可能にします。
現行の機能
以下の機能は、MMF の WandbLogger によりサポートされています:
トレーニング & 検証メトリクス
時間に応じた学習率
モデル チェックポイントを W&B Artifacts に保存
GPU および CPU システムメトリクス
トレーニング設定パラメータ
設定パラメータ
wandb ロギングを有効にしカスタマイズするために MMF 設定で利用可能なオプションは次のとおりです:
training:
wandb:
enabled: true
# エンティティは、run を送信するユーザー名またはチーム名です。
# デフォルトでは、run はユーザー アカウントにログされます。
entity: null
# wandb で実験をログする際に使用するプロジェクト名
project: mmf
# プロジェクト内で実験をログする際に使用する実験/ run 名。
# デフォルトの実験名は: ${training.experiment_name}
name: ${training.experiment_name}
# モデル チェックポイントを有効にし、チェックポイントを W&B Artifacts に保存します
log_model_checkpoint: true
# wandb.init() に渡したい追加の引数値。
# 使用可能な引数を確認するには、ドキュメント /ref/python/init をチェックしてください。
# 例えば:
# job_type: 'train'
# tags: ['tag1', 'tag2']
env:
# wandb メタデータが保存されるディレクトリへのパスを変更するには（デフォルト: env.log_dir）:
wandb_logdir: ${env:MMF_WANDB_LOGDIR,}
6.22 - MosaicML Composer
最先端のアルゴリズムでニューラルネットワークをトレーニングする
Composer は、ニューラルネットワークをより良く、より速く、より安価にトレーニングするためのライブラリです。ニューラルネットワークのトレーニングを加速し、一般化能力を向上させるための最新のメソッドが多数含まれており、多様な強化を容易に組み合わせるためのオプションの Trainer API も用意されています。
W&B は、あなたの ML 実験をログするための軽量なラッパーを提供します。しかし、自分でそれらを組み合わせる必要はありません：W&B は WandBLogger を介して Composer ライブラリに直接組み込まれています。
W&B へのログの開始
from composer import Trainer
from composer.loggers import WandBLogger
trainer = Trainer(... , logger= WandBLogger())
Composer の WandBLogger を使用する
Composer ライブラリは、Trainer 内の WandBLogger クラスを使用して、Weights & Biases へのメトリクスをログします。ロガーをインスタンス化し、それを Trainer に渡すだけです。
wandb_logger = WandBLogger(project= "gpt-5" , log_artifacts= True )
trainer = Trainer(logger= wandb_logger)
ロガーの引数
WandbLogger のパラメータは以下です。完全な一覧と説明については Composer のドキュメント を参照してください
パラメータ
説明
projectW&B プロジェクト名 (str, optional)
groupW&B グループ名 (str, optional)
nameW&B run 名。指定されていない場合は State.run_name が使用されます (str, optional)
entityW&B エンティティ名。ユーザー名や W&B チーム名など (str, optional)
tagsW&B タグ (List[str], optional)
log_artifactsチェックポイントを wandb にログするかどうか。デフォルト: false (bool, optional)
rank_zero_onlyランクゼロのプロセスでのみログするかどうか。アーティファクトをログする場合、すべてのランクでログすることが強く推奨されます。ランク 1 以上のアーティファクトは保存されないため、関連する情報が失われる可能性があります。例えば、Deepspeed ZeRO を使用する場合、すべてのランクからのアーティファクトがなければチェックポイントから復元することはできません。デフォルト: True (bool, optional)
init_kwargswandb.init に渡すパラメータ、config など。このリストについては完全な一覧をこちら から確認できます。
典型的な使用法は次のとおりです：
init_kwargs = {"notes":"この実験での学習率の向上をテストしています",
"config":{"arch":"Llama",
"use_mixed_precision":True
}
}
wandb_logger = WandBLogger(log_artifacts=True, init_kwargs=init_kwargs)
予測サンプルをログする
Composer のコールバック システムを使用して、WandBLogger を通じて Weights & Biases へのログを制御できます。この例では、バリデーション画像と予測のサンプルがログされています：
import wandb
from composer import Callback, State, Logger
class LogPredictions (Callback):
def __init__(self, num_samples= 100 , seed= 1234 ):
super(). __init__()
self. num_samples = num_samples
self. data = []
def eval_batch_end (self, state: State, logger: Logger):
"""バッチごとの予測を計算し、それを self.data に保存します"""
if state. timer. epoch == state. max_duration: # 最後のバリデーションエポックで
if len(self. data) < self. num_samples:
n = self. num_samples
x, y = state. batch_pair
outputs = state. outputs. argmax(- 1 )
data = [[wandb. Image(x_i), y_i, y_pred] for x_i, y_i, y_pred in list(zip(x[:n], y[:n], outputs[:n]))]
self. data += data
def eval_end (self, state: State, logger: Logger):
"wandb.Table を作成してログします"
columns = ['image' , 'ground truth' , 'prediction' ]
table = wandb. Table(columns= columns, data= self. data[:self. num_samples])
wandb. log({'sample_table' :table}, step= int(state. timer. batch))
...
trainer = Trainer(
...
loggers= [WandBLogger()],
callbacks= [LogPredictions()]
)
6.23 - OpenAI API
OpenAI API で W&B を使用する方法
W&B OpenAI API インテグレーションを使用して、リクエスト、レスポンス、トークンカウント、モデルメタデータをすべての OpenAI Models、ファインチューニングされた Models を含めてログします。
API 入出力をログに記録することで、異なるプロンプトの性能を迅速に評価し、異なるモデル設定（例えば温度）を比較し、トークン使用量などの他の使用メトリクスを追跡することができます。
OpenAI Python API ライブラリをインストール
W&B オートログ インテグレーションは OpenAI version 0.28.1 以下で動作します。
OpenAI Python API version 0.28.1 をインストールするには、次を実行します：
pip install openai== 0.28.1
OpenAI Python API を使用
1. autolog をインポートし、初期化
最初に、wandb.integration.openai から autolog をインポートし、初期化します。
import os
import openai
from wandb.integration.openai import autolog
autolog({"project" : "gpt5" })
オプションで、wandb.init() が受け入れる引数の辞書を autolog に渡すことができます。これにはプロジェクト名、チーム名、エンティティなどが含まれます。wandb.init
2. OpenAI API を呼び出す
OpenAI API への各呼び出しは、W&B に自動的にログされます。
os. environ["OPENAI_API_KEY" ] = "XXX"
chat_request_kwargs = dict(
model= "gpt-3.5-turbo" ,
messages= [
{"role" : "system" , "content" : "You are a helpful assistant." },
{"role" : "user" , "content" : "Who won the world series in 2020?" },
{"role" : "assistant" , "content" : "The Los Angeles Dodgers" },
{"role" : "user" , "content" : "Where was it played?" },
],
)
response = openai. ChatCompletion. create(** chat_request_kwargs)
3. OpenAI API 入力とレスポンスを確認
ステップ 1 で autolog により生成された W&B run リンクをクリックしてください。これにより、W&B App のプロジェクトワークスペースにリダイレクトされます。
作成した run を選択すると、トレーステーブル、トレースタイムライン、使用した OpenAI LLM のモデルアーキテクチャーを確認することができます。
オートログをオフにする
W&B は、OpenAI API の使用を終了した際に、disable() を呼び出してすべての W&B プロセスを閉じることを推奨します。
これで入力と補完が W&B にログされ、分析や同僚との共有の準備が整います。
6.24 - OpenAI Fine-Tuning
OpenAI モデルを W&B でファインチューンする方法
OpenAI GPT-3.5 や GPT-4 モデルのファインチューニングのメトリクスと設定を W&B にログします。 W&B エコシステムを活用してファインチューニング 実験、Models、Datasets を追跡し、結果を同僚と共有できます。
ファインチューニングのために W&B と OpenAI を統合する方法についての追加情報は、OpenAI ドキュメントの Weights and Biases Integration セクションを参照してください。
OpenAI Python API のインストールまたは更新
W&B の OpenAI ファインチューニング インテグレーションは、OpenAI バージョン 1.0 以上で動作します。 最新バージョンの OpenAI Python API ライブラリに関する情報は、PyPI ドキュメントを参照してください。
OpenAI Python API をインストールするには、次のコマンドを実行してください:
既に OpenAI Python API をインストールしている場合は、次のコマンドで更新できます:
OpenAI ファインチューニング結果を同期する
W&B を OpenAI のファインチューニング API と統合して、ファインチューニングのメトリクスと設定を W&B にログします。これには、wandb.integration.openai.fine_tuning モジュールの WandbLogger クラスを使用します。
from wandb.integration.openai.fine_tuning import WandbLogger
# ファインチューニングのロジック
WandbLogger. sync(fine_tune_job_id= FINETUNE_JOB_ID)
ファインチューニングを同期する
スクリプトからの結果を同期
from wandb.integration.openai.fine_tuning import WandbLogger
# ワンラインコマンド
WandbLogger. sync()
# オプションパラメータを渡す
WandbLogger. sync(
fine_tune_job_id= None ,
num_fine_tunes= None ,
project= "OpenAI-Fine-Tune" ,
entity= None ,
overwrite= False ,
model_artifact_name= "model-metadata" ,
model_artifact_type= "model" ,
** kwargs_wandb_init
)
リファレンス
引数
説明
fine_tune_job_id
client.fine_tuning.jobs.create を使用してファインチューンジョブを作成すると取得する OpenAI ファインチューン ID です。 この引数が None（デフォルト）の場合、まだ同期されていないすべての OpenAI ファインチューン ジョブが W&B に同期されます。
openai_client
初期化された OpenAI クライアントを sync に渡します。クライアントが提供されない場合、ログは自動的にクライアントを初期化します。 デフォルトでは None です。
num_fine_tunes
ID が提供されない場合、未同期のファインチューンはすべて W&B にログされます。この引数を使用して、同期する最新のファインチューンの数を選択できます。num_fine_tunes が 5 の場合、最新のファインチューン 5 つを選択します。
project
ファインチューニングのメトリクス、Models、Data などがログされる Weights and Biases プロジェクト名。 デフォルトでは、プロジェクト名は “OpenAI-Fine-Tune” です。
entity
W&B ユーザー名またはチーム名。実行結果を送信するエンティティです。 デフォルトでは、通常はユーザー名であるデフォルトエンティティが使用されます。
overwrite
ロギングを強制し、同一ファインチューンジョブの既存の wandb run を上書きします。デフォルトでは False です。
wait_for_job_success
OpenAI ファインチューニングジョブが開始されると、通常少し時間がかかります。ファインチューニングジョブが終了すると、メトリクスが W&B にすぐにログされるように、この設定は 60 秒ごとにファインチューニングジョブのステータスが succeeded に変わるかどうかを確認します。ファインチューニングジョブが成功したと検出されると、自動的にメトリクスが W&B に同期されます。 デフォルトで True に設定されています。
model_artifact_name
ログされるモデル アーティファクトの名前。デフォルトは "model-metadata" です。
model_artifact_type
ログされるモデル アーティファクトのタイプ。デフォルトは "model" です。
**kwargs_wandb_init
直接 wandb.init()
データセットのバージョン管理と可視化
バージョン管理
ファインチューニングのために OpenAI にアップロードしたトレーニングおよび検証データは、バージョン管理を容易にするために自動的に W&B Artifacts としてログされます。 以下に、この アーティファクト 内のトレーニングファイルのビューを示します。ここでは、このファイルをログした W&B run、ログされた時期、このデータセットのバージョン、メタデータ、およびトレーニングデータから学習済みモデルまでの DAG リネージを確認できます。
可視化
データセットは W&B Tables として可視化され、データセットを探索、検索、および対話することができます。以下に、 W&B Tables を使用して可視化されたトレーニングサンプルをチェックしてください。
ファインチューニング済みモデルとモデルのバージョン管理
OpenAI はファインチューニングされたモデルの ID を提供します。モデルの重みにはアアクセスできないため、WandbLogger はモデルのすべての詳細（ハイパーパラメーター、データファイルの ID など）と fine_tuned_model ID を含む model_metadata.json ファイルを作成し、 W&B アーティファクトとしてログします。
このモデル（メタデータ）アーティファクトは、W&B Registry のモデルにさらにリンクすることができます。
よくある質問
チームとファインチューン結果を W&B で共有するにはどうすればよいですか？
以下を使用してファインチューンジョブをチームアカウントにログします:
WandbLogger. sync(entity= "YOUR_TEAM_NAME" )
自分の runs をどのように整理できますか？
あなたの W&B runs は自動的に整理され、ジョブ タイプ、ベースモデル、学習率、トレーニングファイル名、その他のハイパーパラメーターなど、任意の設定パラメーターに基づいてフィルタリングやソートができます。
さらに、run の名前を変更したり、メモを追加したり、タグを作成してグループ化することができます。
満足したら、ワークスペースを保存し、run および保存されたアーティファクト（トレーニング/検証ファイル）からデータをインポートしてレポートを作成できます。
ファインチューンされたモデルにアクセスするにはどうすればよいですか？
ファインチューンされたモデル ID は、アーティファクト (model_metadata.json) として W&B にログされます。
import wandb
ft_artifact = wandb. run. use_artifact("ENTITY/PROJECT/model_metadata:VERSION" )
artifact_dir = artifact. download()
ここで VERSION は次のいずれかです:
v2 などのバージョン番号ft-xxxxxxxxx などのファインチューン ID自動的または手動で追加されたエイリアス、例えば latest
ダウンロードした model_metadata.json ファイルを読み取ることで fine_tuned_model ID にアクセスできます。
ファインチューンが正常に同期されなかった場合はどうすればよいですか？
ファインチューンが W&B に正常にログされなかった場合は、overwrite=True を使用し、ファインチューン ジョブ ID を渡すことができます:
WandbLogger. sync(
fine_tune_job_id= "FINE_TUNE_JOB_ID" ,
overwrite= True ,
)
W&B で自分の Datasets と Models を追跡できますか？
トレーニングと検証データは自動的に アーティファクト として W&B にログされます。ファインチューンされたモデルの ID を含むメタデータも アーティファクト としてログされます。
wandb.Artifact、wandb.log などの低レベルの wandb API を使用してパイプラインを常に制御できます。これにより、データとモデルの完全なトレーサビリティが可能になります。
リソース
6.25 - OpenAI Gym
W&B を OpenAI Gym と統合する方法。
「2021 年から Gym を維持しているチームは、将来のすべての開発を Gymnasium に移しました。Gym の代替である Gymnasium (import gymnasium as gym) を利用できるようにするため、Gym は今後更新を受けることはありません。」（出典 )
Gym はもはや積極的に維持されているプロジェクトではないため、Gymnasium とのインテグレーションを試してみてください。
もし OpenAI Gym を使用している場合、Weights & Biases は自動的に gym.wrappers.Monitor によって生成された環境のビデオをログします。ただし、wandb.initmonitor_gym キーワード引数を True に設定するか、wandb.gym.monitor() を呼び出してください。
私たちの gym インテグレーションは非常に軽量です。単に gym からログされるビデオファイルの名前を見て 、それにちなんで名前を付けるか、一致しない場合は「videos」にフォールバックします。より細かい制御をしたい場合は、いつでも手動でビデオをログする ことができます。
OpenRL ベンチマーク は、CleanRL によって、OpenAI Gym の例でこのインテグレーションを使用しています。gym を使用する方法を示すソースコード（特定の run に使用された特定のコード を含む）を見つけることができます。
6.26 - PaddleDetection
W&B を PaddleDetection と統合する方法。
PaddleDetection は、PaddlePaddle に基づくエンドツーエンドの物体検出開発キットです。ネットワークコンポーネント、データ拡張、損失などの設定可能なモジュールを使用して、さまざまな主流オブジェクトを検出し、インスタンスをセグメント化し、キーポイントを追跡および検出します。
PaddleDetection には、トレーニングと検証のメトリクス、モデルチェックポイント、およびそれに対応するメタデータをログするための W&B インテグレーションが組み込まれています。
PaddleDetection WandbLogger は、トレーニングと評価のメトリクスを Weights & Biases にログし、トレーニング中にモデルチェックポイントも記録します。
W&B ブログ記事を読む COCO2017 データセットのサブセットで PaddleDetectionと統合する方法を示しています。
サインアップして API キーを作成する
APIキーは、あなたのマシンをW&Bに認証します。APIキーはユーザープロフィールから生成できます。
画面右上のユーザープロフィールアイコンをクリックします。
ユーザー設定 を選び、API キー セクションまでスクロールします。表示 をクリックし、表示された API キーをコピーします。API キーを非表示にするには、ページをリロードします。
wandb ライブラリをインストールしログインするwandb ライブラリをローカルにインストールしてログインする方法:
コマンドライン
Python
Pythonノートブック
WANDB_API_KEY 環境変数 をあなたのAPIキーに設定します。
export WANDB_API_KEY= <your_api_key>
wandb ライブラリをインストールしてログインします。
pip install wandb
wandb login
import wandb
wandb. login()
!pip install wandb
import wandb
wandb.login()
トレーニングスクリプトで WandbLogger を有効にする
PaddleDetection の train.py に引数を渡して wandb を使用するには:
--use_wandb フラグを追加します最初の wandb 引数の前に -o を付けます（これは一度だけで結構です）
個々の wandb 引数にはすべて wandb- プレフィックスを含める必要があります。例えば、wandb.initwandb- プレフィックスが追加されます
python tools/train.py
-c config.yml \
--use_wandb \
\
wandb-project= MyDetector \
= MyTeam \
= ./logs
config.yml ファイルの wandb キーの下に wandb 引数を追加します:
wandb:
project: MyProject
entity: MyTeam
save_dir: ./logs
train.py ファイルを実行すると、W&B ダッシュボードへのリンクが生成されます。
フィードバックや問題
Weights & Biases インテグレーションに関するフィードバックや問題がある場合は、PaddleDetection GitHub に issue を作成するか、support@wandb.com にメールしてください。
6.27 - PaddleOCR
PaddleOCR と W&B を統合する方法。
PaddleOCR は、多言語対応で素晴らしく、実用的でユーザーがより良いモデルをトレーニングし、PaddlePaddleで実践的に適用できるOCRツールの作成を目指しています。PaddleOCRはOCRに関連するさまざまな最先端のアルゴリズムをサポートし、産業用ソリューションを開発しました。PaddleOCRにはWeights & Biasesのインテグレーションがあり、トレーニングと評価メトリクスをログに記録し、対応するメタデータとともにモデルのチェックポイントを保存できます。
例: ブログ & Colab
PaddleOCRでICDAR2015データセットを使ってモデルをトレーニングする方法を知るには、こちらをお読みください Google Colab こちら W&B对您的OCR模型进行训练和调试
サインアップしてAPIキーを作成する
APIキーは、W&Bへの認証に使われます。APIキーはユーザーのプロファイルから生成できます。
右上のユーザープロファイルアイコンをクリックします。
User Settings を選択し、API Keys セクションまでスクロールします。Reveal をクリックします。表示されたAPIキーをコピーします。APIキーを非表示にするには、ページを再読み込みします。
wandbライブラリをインストールしてログインするwandbライブラリをローカルにインストールしてログインするには:
Command Line
Python
Python notebook
WANDB_API_KEY 環境変数 を自分のAPIキーに設定します。
export WANDB_API_KEY= <your_api_key>
wandbライブラリをインストールしてログインします。
pip install wandb
wandb login
import wandb
wandb. login()
!pip install wandb
import wandb
wandb.login()
config.ymlファイルにwandbを追加するPaddleOCRでは設定変数をyamlファイルで提供する必要があります。設定yamlファイルの最後に次のスニペットを追加することで、すべてのトレーニングおよびバリデーションメトリクスをW&Bダッシュボードに自動的にログ記録するとともに、モデルのチェックポイントも保存されます:
wandb.initwandbヘッダーの下に追加することもできます:
wandb:
project: CoolOCR # (optional) これはwandbプロジェクト名です
entity: my_team # (optional) wandbチームを使っている場合、ここでチーム名を渡すことができます
name: MyOCRModel # (optional) これはwandb runの名前です
config.ymlファイルをtrain.pyに渡すyamlファイルは、PaddleOCRリポジトリ内で利用可能なトレーニングスクリプト への引数として提供されます。
python tools/train.py -c config.yml
Weights & Biasesをオンにしてtrain.pyファイルを実行するとき、W&Bダッシュボードへのリンクが生成されます:
フィードバックや問題点
Weights & Biasesのインテグレーションに関するフィードバックや問題がある場合は、PaddleOCR GitHub で問題を報告するか、support@wandb.com にメールしてください。
6.28 - プロディジー
W&B を Prodigy と統合する方法。
Prodigy は、機械学習モデルのトレーニングと評価用データを作成するためのアノテーションツールであり、エラー分析、データの調査とクリーニングにも使用されます。W&B Tables を使用すると、W&B 内でデータセットのログ、可視化、分析、共有（およびそれ以上！）が可能です。
W&B の Prodigy とのインテグレーション により、Prodigy でアノテーションされたデータセットを W&B に直接アップロードし、Tables と一緒に使用するシンプルで使いやすい機能が追加されます。
このようにいくつかのコードを実行します：
import wandb
from wandb.integration.prodigy import upload_dataset
with wandb. init(project= "prodigy" ):
upload_dataset("news_headlines_ner" )
すると、このような視覚的でインタラクティブな共有可能なテーブルが得られます:
クイックスタート
wandb.integration.prodigy.upload_dataset を使用して、アノテーション済みの prodigy データセットをローカルの Prodigy データベースから直接 W&B の Table 形式でアップロードできます。Prodigy の詳細、インストール & セットアップを含む情報は、Prodigy ドキュメント を参照してください。
W&B は自動的に画像と固有表現フィールドをそれぞれ wandb.Imagewandb.Html
詳細な例を読む
W&B Prodigy インテグレーションを使用して生成された可視化例については、Visualizing Prodigy Datasets Using W&B Tables を参照してください。
spaCy も使用していますか？
W&B は spaCy とのインテグレーションも備えています。ドキュメントはこちら を参照してください。
6.29 - PyTorch
PyTorch は、特に研究者の間で、Python におけるディープラーニングの最も人気のあるフレームワークの一つです。W&B は、PyTorch に対して一流のサポートを提供し、勾配のログから CPU と GPU 上でのコードのプロファイリングまで対応しています。
Colab ノートブックで私たちのインテグレーションを試してみてください。
また、example repo では、スクリプトや Fashion MNIST を使用した Hyperband によるハイパーパラメータ最適化などの例を含むものがあります。それが生成する W&B Dashboard もご覧いただけます。
wandb.watch を使った勾配のログ勾配を自動的にログするには、wandb.watch
import wandb
wandb. init(config= args)
model = ... # モデルをセットアップする
# マジック
wandb. watch(model, log_freq= 100 )
model. train()
for batch_idx, (data, target) in enumerate(train_loader):
output = model(data)
loss = F. nll_loss(output, target)
loss. backward()
optimizer. step()
if batch_idx % args. log_interval == 0 :
wandb. log({"loss" : loss})
同じスクリプト内で複数のモデルを追跡する必要がある場合は、それぞれのモデルに対して wandb.watch を個別に呼び出すことができます。この関数の参照ドキュメントはこちら 。
勾配、メトリクス、およびグラフは、フォワード および バックワードパスの後に wandb.log が呼び出されるまでログされません。
画像とメディアのログ
画像データを持つ PyTorch Tensors を wandb.Imagetorchvision
images_t = ... # PyTorch Tensors として画像を生成またはロードする
wandb. log({"examples" : [wandb. Image(im) for im in images_t]})
PyTorch や他のフレームワークにおけるリッチメディアのログについての詳細は、メディアログガイド をご覧ください。
メディアと一緒にモデルの予測や派生メトリクスなどの情報も含めたい場合は、wandb.Table を使用します。
my_table = wandb. Table()
my_table. add_column("image" , images_t)
my_table. add_column("label" , labels)
my_table. add_column("class_prediction" , predictions_t)
# Table を W&B にログ
wandb. log({"mnist_predictions" : my_table})
データセットやモデルのログと視覚化についての詳細は、W&B Tables のガイド をご覧ください。
PyTorch コードのプロファイリング
W&B は PyTorch Kineto の Tensorboard プラグイン と直接統合されており、PyTorch コードのプロファイリング、CPU と GPU の通信の詳細の検査、ボトルネックや最適化を識別するためのツールを提供します。
profile_dir = "path/to/run/tbprofile/"
profiler = torch. profiler. profile(
schedule= schedule, # スケジュールの詳細はプロファイラードキュメントを参照
on_trace_ready= torch. profiler. tensorboard_trace_handler(profile_dir),
with_stack= True ,
)
with profiler:
... # プロファイルしたいコードをここで実行
# 詳細な使用情報はプロファイラードキュメントを参照
# wandb アーティファクトを作成
profile_art = wandb. Artifact("trace" , type= "profile" )
# pt.trace.json ファイルをアーティファクトに追加
profile_art. add_file(glob. glob(profile_dir + ".pt.trace.json" ))
# アーティファクトをログ
profile_art. save()
こちらの Colab で作業中の例コードを見て実行できます。
インタラクティブなトレースビューツールは、Chrome Trace Viewer に基づいており、Chrome ブラウザで最も良好に動作します。
6.30 - PyTorch Geometric
PyTorch Geometric または PyG は、最も人気のある幾何学的ディープラーニングのためのライブラリの1つであり、W&B はそれと非常に良く連携し、グラフの可視化と実験の追跡を行うことができます。
PyTorch Geometric をインストールした後、以下の手順に従ってください。
サインアップとAPI キーの作成
APIキーは、あなたのマシンをW&Bに認証します。APIキーはユーザープロフィールから生成できます。
右上のユーザープロフィールアイコンをクリックします。
ユーザー設定 を選択し、API キー セクションまでスクロールします。Reveal をクリックします。表示されたAPIキーをコピーします。APIキーを隠すには、ページをリロードしてください。
wandb ライブラリのインストールとログインwandb ライブラリをローカルにインストールし、ログインするには:
Command Line
Python
Python notebook
WANDB_API_KEY 環境変数 をAPIキーに設定します。
export WANDB_API_KEY= <your_api_key>
wandb ライブラリをインストールし、ログインします。
pip install wandb
wandb login
import wandb
wandb. login()
!pip install wandb
import wandb
wandb.login()
グラフの可視化
入力グラフの詳細（エッジ数、ノード数など）を保存できます。W&B は plotly グラフと HTML パネルのログ記録をサポートしているため、グラフのために作成したあらゆる可視化を W&B にログすることができます。
PyVis を使用する
以下のスニペットは、PyVis と HTML を使ってそれを行う方法を示しています。
from pyvis.network import Network
import wandb
wandb. init(project= ’ graph_vis’ )
net = Network(height= "750px" , width= "100%" , bgcolor= "#222222" , font_color= "white" )
# PyG グラフから PyVis ネットワークへのエッジを追加
for e in tqdm(g. edge_index. T):
src = e[0 ]. item()
dst = e[1 ]. item()
net. add_node(dst)
net. add_node(src)
net. add_edge(src, dst, value= 0.1 )
# PyVisの可視化をHTMLファイルに保存
net. show("graph.html" )
wandb. log({"eda/graph" : wandb. Html("graph.html" )})
wandb. finish()
Plotly を使用する
Plotly を使用してグラフの可視化を作成するには、まず PyG グラフを networkx オブジェクトに変換する必要があります。その後、ノードとエッジのために Plotly スキャッタープロットを作成する必要があります。このタスクには以下のスニペットが使用できます。
def create_vis (graph):
G = to_networkx(graph)
pos = nx. spring_layout(G)
edge_x = []
edge_y = []
for edge in G. edges():
x0, y0 = pos[edge[0 ]]
x1, y1 = pos[edge[1 ]]
edge_x. append(x0)
edge_x. append(x1)
edge_x. append(None )
edge_y. append(y0)
edge_y. append(y1)
edge_y. append(None )
edge_trace = go. Scatter(
x= edge_x, y= edge_y,
line= dict(width= 0.5 , color= '#888' ),
hoverinfo= 'none' ,
mode= 'lines'
)
node_x = []
node_y = []
for node in G. nodes():
x, y = pos[node]
node_x. append(x)
node_y. append(y)
node_trace = go. Scatter(
x= node_x, y= node_y,
mode= 'markers' ,
hoverinfo= 'text' ,
line_width= 2
)
fig = go. Figure(data= [edge_trace, node_trace], layout= go. Layout())
return fig
wandb. init(project= ’ visualize_graph’ )
wandb. log({‘ graph’ : wandb. Plotly(create_vis(graph))})
wandb. finish()
メトリクスのログ化
損失関数、精度などのメトリクスを含む実験を追跡するためにW&Bを使用することができます。トレーニングループに次の行を追加してください：
wandb. log({
‘ train/ loss’ : training_loss,
‘ train/ acc’ : training_acc,
‘ val/ loss’ : validation_loss,
‘ val/ acc’ : validation_acc
})
その他のリソース
6.31 - Pytorch チューニングする torchtune
torchtune は、大規模言語モデル（LLM）の作成、ファインチューニング、実験プロセスを効率化するために設計された PyTorch ベースのライブラリです。さらに、torchtune は W&B でのログ記録 をサポートしており、トレーニングプロセスの追跡と可視化を強化します。
torchtune を使用した Mistral 7B のファインチューニング に関する W&B ブログ記事をチェックしてください。
W&B のログ記録が手の届くところに
Command line
Recipe’s config
ローンチ時にコマンドライン引数をオーバーライドします:
tune run lora_finetune_single_device --config llama3/8B_lora_single_device \
= torchtune.utils.metric_logging.WandBLogger \
= "llama3_lora" \
= 5
レシピの設定で W&B ログ記録を有効にします:
# inside llama3/8B_lora_single_device.yaml
metric_logger :
_component_ : torchtune.utils.metric_logging.WandBLogger
project : llama3_lora
log_every_n_steps : 5
W&B メトリックロガーの使用
metric_logger セクションを変更して、レシピの設定ファイルで W&B ログ記録を有効にします。_component_ を torchtune.utils.metric_logging.WandBLogger にクラスを変更します。また、project 名と log_every_n_steps を渡してログ記録の振る舞いをカスタマイズすることもできます。
wandb.init メソッドに渡すのと同様に、他の kwargs を渡すこともできます。例えば、チームで作業している場合、WandBLogger クラスに entity 引数を渡してチーム名を指定することができます。
Recipe’s Config
Command Line
# inside llama3/8B_lora_single_device.yaml
metric_logger :
_component_ : torchtune.utils.metric_logging.WandBLogger
project : llama3_lora
entity : my_project
job_type : lora_finetune_single_device
group : my_awesome_experiments
log_every_n_steps : 5
tune run lora_finetune_single_device --config llama3/8B_lora_single_device \
= torchtune.utils.metric_logging.WandBLogger \
= "llama3_lora" \
= "my_project" \
= "lora_finetune_single_device" \
= "my_awesome_experiments" \
= 5
何がログされますか？
W&B ダッシュボードを探索して、ログされたメトリックを見ることができます。デフォルトでは、W&B は設定ファイルとローンチのオーバーライドからすべてのハイパーパラメーターをログします。
W&B は Overview タブで解決された設定をキャプチャします。W&B は YAML 形式で設定を Files タブ にも保存します。
ログされたメトリック
各レシピにはそれぞれのトレーニングループがあります。個別のレシピを確認して、そのログされたメトリックを見ることができます。これにはデフォルトで以下が含まれています:
Metric
説明
lossモデルのロス
lr学習率
tokens_per_secondモデルのトークン毎秒
grad_normモデルの勾配ノルム
global_stepトレーニングループの現在のステップに対応します。勾配の累積を考慮に入れ、オプティマイザーステップが取られるたびにモデルが更新され、勾配が累積され、gradient_accumulation_steps ごとに1回モデルが更新されます。
global_step はトレーニングステップの数と同じではありません。トレーニングループの現在のステップに対応します。勾配の累積を考慮に入れ、オプティマイザーステップが取られるたびに global_step が1増加します。例えば、データローダーに10バッチあり、勾配の累積ステップが2で3エポック走行する場合、オプティマイザーは15回ステップし、この場合 global_step は1から15までの範囲になります。
torchtune の効率的な設計により、カスタムメトリクスを簡単に追加したり、既存のものを変更することができます。対応する レシピファイル を変更し、例えば以下のように current_epoch を全エポック数のパーセンテージとして記録するだけで十分です。
# inside `train.py` function in the recipe file
self. _metric_logger. log_dict(
{"current_epoch" : self. epochs * self. global_step / self. _steps_per_epoch},
step= self. global_step,
)
これは急速に進化しているライブラリであり、現在のメトリクスは変更される可能性があります。カスタムメトリクスを追加したい場合は、レシピを変更し、対応する self._metric_logger.* 関数を呼び出す必要があります。
チェックポイントの保存とロード
torchtune ライブラリは様々な チェックポイントフォーマット をサポートしています。使用しているモデルの出所に応じて、適切な チェックポインタークラス に切り替えるべきです。
もしモデルのチェックポイントを W&B Artifacts に保存したい場合は、対応するレシピ内の save_checkpoint 関数をオーバーライドするのが最も簡単です。
ここにモデルのチェックポイントを W&B Artifacts に保存するために save_checkpoint 関数をオーバーライドする方法の例を示します。
def save_checkpoint (self, epoch: int) -> None :
...
## Let's save the checkpoint to W&B
## depending on the Checkpointer Class the file will be named differently
## Here is an example for the full_finetune case
checkpoint_file = Path. joinpath(
self. _checkpointer. _output_dir, f "torchtune_model_ { epoch} "
). with_suffix(".pt" )
wandb_artifact = wandb. Artifact(
name= f "torchtune_model_ { epoch} " ,
type= "model" ,
# description of the model checkpoint
description= "Model checkpoint" ,
# you can add whatever metadata you want as a dict
metadata= {
utils. SEED_KEY: self. seed,
utils. EPOCHS_KEY: self. epochs_run,
utils. TOTAL_EPOCHS_KEY: self. total_epochs,
utils. MAX_STEPS_KEY: self. max_steps_per_epoch,
},
)
wandb_artifact. add_file(checkpoint_file)
wandb. log_artifact(wandb_artifact)
6.32 - PyTorch Ignite
How to integrate W&B with PyTorch Ignite.
IgniteはWeights & Biasesハンドラーをサポートしており、トレーニングおよび検証中にメトリクス、モデル/オプティマイザーパラメータ、勾配をログできます。また、モデルのチェックポイントをWeights & Biasesクラウドにログするためにも使用できます。このクラスはwandbモジュールのラッパーでもあります。つまり、このラッパーを使用して任意のwandb関数を呼び出すことができます。モデルパラメータと勾配を保存する方法の例を参照してください。
基本設定
from argparse import ArgumentParser
import wandb
import torch
from torch import nn
from torch.optim import SGD
from torch.utils.data import DataLoader
import torch.nn.functional as F
from torchvision.transforms import Compose, ToTensor, Normalize
from torchvision.datasets import MNIST
from ignite.engine import Events, create_supervised_trainer, create_supervised_evaluator
from ignite.metrics import Accuracy, Loss
from tqdm import tqdm
class Net (nn. Module):
def __init__(self):
super(Net, self). __init__()
self. conv1 = nn. Conv2d(1 , 10 , kernel_size= 5 )
self. conv2 = nn. Conv2d(10 , 20 , kernel_size= 5 )
self. conv2_drop = nn. Dropout2d()
self. fc1 = nn. Linear(320 , 50 )
self. fc2 = nn. Linear(50 , 10 )
def forward (self, x):
x = F. relu(F. max_pool2d(self. conv1(x), 2 ))
x = F. relu(F. max_pool2d(self. conv2_drop(self. conv2(x)), 2 ))
x = x. view(- 1 , 320 )
x = F. relu(self. fc1(x))
x = F. dropout(x, training= self. training)
x = self. fc2(x)
return F. log_softmax(x, dim=- 1 )
def get_data_loaders (train_batch_size, val_batch_size):
data_transform = Compose([ToTensor(), Normalize((0.1307 ,), (0.3081 ,))])
train_loader = DataLoader(MNIST(download= True , root= "." , transform= data_transform, train= True ),
batch_size= train_batch_size, shuffle= True )
val_loader = DataLoader(MNIST(download= False , root= "." , transform= data_transform, train= False ),
batch_size= val_batch_size, shuffle= False )
return train_loader, val_loader
igniteでのWandBLoggerの使用はモジュラーなプロセスです。まず、WandBLoggerオブジェクトを作成します。次に、トレーナーまたは評価者にアタッチしてメトリクスを自動的にログします。この例では：
トレーニング損失をログし、トレーナーオブジェクトにアタッチします。
検証損失をログし、評価者にアタッチします。
学習率などのオプションのパラメータをログします。
モデルをウォッチします。
from ignite.contrib.handlers.wandb_logger import *
def run (train_batch_size, val_batch_size, epochs, lr, momentum, log_interval):
train_loader, val_loader = get_data_loaders(train_batch_size, val_batch_size)
model = Net()
device = 'cpu'
if torch. cuda. is_available():
device = 'cuda'
optimizer = SGD(model. parameters(), lr= lr, momentum= momentum)
trainer = create_supervised_trainer(model, optimizer, F. nll_loss, device= device)
evaluator = create_supervised_evaluator(model,
metrics= {'accuracy' : Accuracy(),
'nll' : Loss(F. nll_loss)},
device= device)
desc = "ITERATION - loss: {:.2f} "
pbar = tqdm(
initial= 0 , leave= False , total= len(train_loader),
desc= desc. format(0 )
)
#WandBlogger オブジェクトの作成
wandb_logger = WandBLogger(
project= "pytorch-ignite-integration" ,
name= "cnn-mnist" ,
config= {"max_epochs" : epochs,"batch_size" :train_batch_size},
tags= ["pytorch-ignite" , "mninst" ]
)
wandb_logger. attach_output_handler(
trainer,
event_name= Events. ITERATION_COMPLETED,
tag= "training" ,
output_transform= lambda loss: {"loss" : loss}
)
wandb_logger. attach_output_handler(
evaluator,
event_name= Events. EPOCH_COMPLETED,
tag= "training" ,
metric_names= ["nll" , "accuracy" ],
global_step_transform= lambda * _: trainer. state. iteration,
)
wandb_logger. attach_opt_params_handler(
trainer,
event_name= Events. ITERATION_STARTED,
optimizer= optimizer,
param_name= 'lr' # 任意のオプション
)
wandb_logger. watch(model)
任意でigniteのEVENTSを利用してメトリクスを直接ターミナルにログできます
@trainer.on (Events. ITERATION_COMPLETED(every= log_interval))
def log_training_loss (engine):
pbar. desc = desc. format(engine. state. output)
pbar. update(log_interval)
@trainer.on (Events. EPOCH_COMPLETED)
def log_training_results (engine):
pbar. refresh()
evaluator. run(train_loader)
metrics = evaluator. state. metrics
avg_accuracy = metrics['accuracy' ]
avg_nll = metrics['nll' ]
tqdm. write(
"Training Results - Epoch: {} Avg accuracy: {:.2f} Avg loss: {:.2f} "
. format(engine. state. epoch, avg_accuracy, avg_nll)
)
@trainer.on (Events. EPOCH_COMPLETED)
def log_validation_results (engine):
evaluator. run(val_loader)
metrics = evaluator. state. metrics
avg_accuracy = metrics['accuracy' ]
avg_nll = metrics['nll' ]
tqdm. write(
"Validation Results - Epoch: {} Avg accuracy: {:.2f} Avg loss: {:.2f} "
. format(engine. state. epoch, avg_accuracy, avg_nll))
pbar. n = pbar. last_print_n = 0
trainer. run(train_loader, max_epochs= epochs)
pbar. close()
if __name__ == "__main__" :
parser = ArgumentParser()
parser. add_argument('--batch_size' , type= int, default= 64 ,
help= 'トレーニングの入力バッチサイズ (デフォルト: 64)' )
parser. add_argument('--val_batch_size' , type= int, default= 1000 ,
help= '検証の入力バッチサイズ (デフォルト: 1000)' )
parser. add_argument('--epochs' , type= int, default= 10 ,
help= 'トレーニングのエポック数 (デフォルト: 10)' )
parser. add_argument('--lr' , type= float, default= 0.01 ,
help= '学習率 (デフォルト: 0.01)' )
parser. add_argument('--momentum' , type= float, default= 0.5 ,
help= 'SGDモメンタム (デフォルト: 0.5)' )
parser. add_argument('--log_interval' , type= int, default= 10 ,
help= 'トレーニング状況をログするまでに待機するバッチ数' )
args = parser. parse_args()
run(args. batch_size, args. val_batch_size, args. epochs, args. lr, args. momentum, args. log_interval)
このコードは以下の可視化を生成します:
詳細はIgnite Docs を参照してください。
6.33 - PyTorch Lightning
PyTorch Lightning は、PyTorch コードを整理し、分散トレーニングや 16 ビット精度のような高度な機能を簡単に追加するための軽量ラッパーを提供します。 W&B は、あなたの ML 実験を記録するための軽量ラッパーを提供します。しかし、自分でそれらを組み合わせる必要はありません。Weights & Biases は、WandbLogger
Lightning との統合
PyTorch Logger
Fabric Logger
from lightning.pytorch.loggers import WandbLogger
from lightning.pytorch import Trainer
wandb_logger = WandbLogger(log_model= "all" )
trainer = Trainer(logger= wandb_logger)
wandb.log() を使用する際の注意点: WandbLogger は Trainer の global_step を使用して W&B にログを記録します。コード内で直接 wandb.log を追加で呼び出す場合、wandb.log() の step 引数を使用しないでください。
代わりに、Trainer の global_step を他のメトリクスと同様に記録してください：
wandb. log({"accuracy" :0.99 , "trainer/global_step" : step})
import lightning as L
from wandb.integration.lightning.fabric import WandbLogger
wandb_logger = WandbLogger(log_model= "all" )
fabric = L. Fabric(loggers= [wandb_logger])
fabric. launch()
fabric. log_dict({"important_metric" : important_metric})
サインアップして APIキーを作成する
APIキー は、あなたのマシンを W&B に認証するためのものです。あなたのユーザープロフィールから APIキー を生成できます。
右上のユーザープロフィールアイコンをクリックします。
User Settings を選択し、API Keys セクションまでスクロールします。Reveal をクリックします。表示された APIキー をコピーします。APIキー を非表示にするには、ページをリロードします。
wandb ライブラリをインストールしてログインするローカルに wandb ライブラリをインストールしてログインする方法：
コマンドライン
Python
Python notebook
あなたの APIキー に WANDB_API_KEY 環境変数 を設定します。
export WANDB_API_KEY= <your_api_key>
wandb ライブラリをインストールしてログインします。
pip install wandb
wandb login
import wandb
wandb. login()
!pip install wandb
import wandb
wandb.login()
PyTorch Lightning の WandbLogger を使用する
PyTorch Lightning には、メトリクスやモデルの重み、メディアなどを記録するための複数の WandbLogger クラスがあります。
Lightning と統合するには、WandbLogger をインスタンス化し、Lightning の Trainer または Fabric に渡してください。
PyTorch Logger
Fabric Logger
trainer = Trainer(logger= wandb_logger)
fabric = L. Fabric(loggers= [wandb_logger])
fabric. launch()
fabric. log_dict({
"important_metric" : important_metric
})
よく使用されるロガーの引数
以下に、WandbLogger でよく使用されるパラメータを示します。すべてのロガー引数の詳細については PyTorch Lightning のドキュメントを確認してください。
Parameter
Description
project記録する wandb Project を定義します
nameあなたの wandb run に名前を付けます
log_modellog_model="all" の場合はすべてのモデルを記録し、log_model=True の場合はトレーニングの最後に記録します
save_dirデータが保存されるパス
ハイパーパラメーターを記録する
PyTorch Logger
Fabric Logger
class LitModule (LightningModule):
def __init__(self, * args, ** kwarg):
self. save_hyperparameters()
wandb_logger. log_hyperparams(
{
"hyperparameter_1" : hyperparameter_1,
"hyperparameter_2" : hyperparameter_2,
}
)
追加の設定パラメータを記録する
# パラメータを1つ追加する
wandb_logger. experiment. config["key" ] = value
# 複数のパラメータを追加する
wandb_logger. experiment. config. update({key1: val1, key2: val2})
# 直接 wandb モジュールを使用する
wandb. config["key" ] = value
wandb. config. update()
勾配、パラメータヒストグラム、モデルトポロジーを記録する
モデルのオブジェクトを wandblogger.watch() に渡すことで、トレーニング中のモデルの勾配とパラメータを監視できます。PyTorch Lightning の WandbLogger ドキュメントを参照してください。
メトリクスを記録する
PyTorch Logger
Fabric Logger
WandbLogger を使用しているときは、LightningModule 内で self.log('my_metric_name', metric_value) を呼び出すことで W&B にメトリクスを記録できます。たとえば、training_step や validation_step メソッド内でこれを行います。
以下のコードスニペットは、メトリクスとハイパーパラメーターを記録するための LightningModule を定義する方法を示しています。この例では、torchmetrics
import torch
from torch.nn import Linear, CrossEntropyLoss, functional as F
from torch.optim import Adam
from torchmetrics.functional import accuracy
from lightning.pytorch import LightningModule
class My_LitModule (LightningModule):
def __init__(self, n_classes= 10 , n_layer_1= 128 , n_layer_2= 256 , lr= 1e-3 ):
"""モデルパラメータを定義するためのメソッド"""
super(). __init__()
# mnist 画像は (1, 28, 28) (チャンネル、幅、高さ) です
self. layer_1 = Linear(28 * 28 , n_layer_1)
self. layer_2 = Linear(n_layer_1, n_layer_2)
self. layer_3 = Linear(n_layer_2, n_classes)
self. loss = CrossEntropyLoss()
self. lr = lr
# ハイパーパラメーターを self.hparams に保存します (W&B によって自動でログされます)
self. save_hyperparameters()
def forward (self, x):
"""推論のための入力 -> 出力 メソッド"""
# (b, 1, 28, 28) -> (b, 1*28*28)
batch_size, channels, width, height = x. size()
x = x. view(batch_size, - 1 )
# 3 * (線形 + ReLU)
x = F. relu(self. layer_1(x))
x = F. relu(self. layer_2(x))
x = self. layer_3(x)
return x
def training_step (self, batch, batch_idx):
"""1つのバッチからの損失を返す必要があります"""
_, loss, acc = self. _get_preds_loss_accuracy(batch)
# 損失とメトリクスを記録する
self. log("train_loss" , loss)
self. log("train_accuracy" , acc)
return loss
def validation_step (self, batch, batch_idx):
"""メトリクスを記録するために使用されます"""
preds, loss, acc = self. _get_preds_loss_accuracy(batch)
# 損失とメトリクスを記録する
self. log("val_loss" , loss)
self. log("val_accuracy" , acc)
return preds
def configure_optimizers (self):
"""モデルオプティマイザーを定義します"""
return Adam(self. parameters(), lr= self. lr)
def _get_preds_loss_accuracy (self, batch):
"""train/valid/test ステップが類似しているための便利な機能"""
x, y = batch
logits = self(x)
preds = torch. argmax(logits, dim= 1 )
loss = self. loss(logits, y)
acc = accuracy(preds, y)
return preds, loss, acc
import lightning as L
import torch
import torchvision as tv
from wandb.integration.lightning.fabric import WandbLogger
import wandb
fabric = L. Fabric(loggers= [wandb_logger])
fabric. launch()
model = tv. models. resnet18()
optimizer = torch. optim. SGD(model. parameters(), lr= lr)
model, optimizer = fabric. setup(model, optimizer)
train_dataloader = fabric. setup_dataloaders(
torch. utils. data. DataLoader(train_dataset, batch_size= batch_size)
)
model. train()
for epoch in range(num_epochs):
for batch in train_dataloader:
optimizer. zero_grad()
loss = model(batch)
loss. backward()
optimizer. step()
fabric. log_dict({"loss" : loss})
メトリクスの最小/最大値を記録する
wandb の define_metricdefine_metric が使用されていない場合、最後に記録された値が要約メトリクスに表示されます。詳細な define_metric の ドキュメントはこちら と ガイドはこちら を参照してください。
W&B の要約メトリクスで最大の検証精度を追跡するよう W&B に指示するには、トレーニングの開始時に一度だけ wandb.define_metric を呼び出します：
PyTorch Logger
Fabric Logger
class My_LitModule (LightningModule):
...
def validation_step (self, batch, batch_idx):
if trainer. global_step == 0 :
wandb. define_metric("val_accuracy" , summary= "max" )
preds, loss, acc = self. _get_preds_loss_accuracy(batch)
# 損失とメトリクスを記録する
self. log("val_loss" , loss)
self. log("val_accuracy" , acc)
return preds
wandb. define_metric("val_accuracy" , summary= "max" )
fabric = L. Fabric(loggers= [wandb_logger])
fabric. launch()
fabric. log_dict({"val_accuracy" : val_accuracy})
モデルチェックポイントを作成する
モデルのチェックポイントを W&B の Artifacts として保存するには、Lightning の ModelCheckpointWandbLogger の log_model 引数を設定します。
PyTorch Logger
Fabric Logger
trainer = Trainer(logger= wandb_logger, callbacks= [checkpoint_callback])
fabric = L. Fabric(loggers= [wandb_logger], callbacks= [checkpoint_callback])
最新 及び 最良 のエイリアスは、W&B の Artifact からモデルのチェックポイントを簡単に取得できるように自動的に設定されます：
# アーティファクトパネルでリファレンスを取得できます
# "VERSION" はバージョン (例: "v2") またはエイリアス ("latest" または "best") です
checkpoint_reference = "USER/PROJECT/MODEL-RUN_ID:VERSION"
# チェックポイントをローカルにダウンロードする（既にキャッシュされていない場合）
wandb_logger. download_artifact(checkpoint_reference, artifact_type= "model" )
# チェックポイントをローカルにダウンロードする（既にキャッシュされていない場合）
run = wandb. init(project= "MNIST" )
artifact = run. use_artifact(checkpoint_reference, type= "model" )
artifact_dir = artifact. download()
PyTorch Logger
Fabric Logger
# チェックポイントをロードする
model = LitModule. load_from_checkpoint(Path(artifact_dir) / "model.ckpt" )
# 生のチェックポイントをリクエストする
full_checkpoint = fabric. load(Path(artifact_dir) / "model.ckpt" )
model. load_state_dict(full_checkpoint["model" ])
optimizer. load_state_dict(full_checkpoint["optimizer" ])
記録されたモデルのチェックポイントは W&B Artifacts UI を通じて表示可能で、完全なモデルリネージも含まれます（UIでのモデルチェックポイントの例はこちら (https://wandb.ai/wandb/arttest/artifacts/model/iv3_trained/5334ab69740f9dda4fed/lineage?_gl=1 yyql5q _gaMTQxOTYyNzExOS4xNjg0NDYyNzk1 _ga_JH1SJHJQXJ*MTY5MjMwNzI2Mi4yNjkuMS4xNjkyMzA5NjM2LjM3LjAuMA..))。
最良のモデルチェックポイントをブックマークし、チーム全体でそれらを一元化するために、W&B Model Registry にリンクすることができます。
これにより、タスクごとに最良のモデルを整理し、モデルのライフサイクルを管理し、MLライフサイクル全体で簡単な追跡と監査を可能にし、Webhooksやジョブでのダウンストリームアクションを自動化 することができます。
画像やテキストなどを記録する
WandbLogger は、メディアを記録するための log_image、log_text、log_table メソッドを持っています。
他にも、音声、分子、ポイントクラウド、3Dオブジェクトなどのメディアタイプを記録するために、直接的に wandb.log や trainer.logger.experiment.log を呼び出すことができます。
Log Images
Log Text
Log Tables
# テンソル、NumPy 配列、または PIL 画像を使用
wandb_logger. log_image(key= "samples" , images= [img1, img2])
# キャプションを追加
wandb_logger. log_image(key= "samples" , images= [img1, img2], caption= ["tree" , "person" ])
# ファイルパスを使用
wandb_logger. log_image(key= "samples" , images= ["img_1.jpg" , "img_2.jpg" ])
# トレーナで .log を使用
trainer. logger. experiment. log(
{"samples" : [wandb. Image(img, caption= caption) for (img, caption) in my_images]},
step= current_trainer_global_step,
)
# データはリストのリストであるべきです
columns = ["input" , "label" , "prediction" ]
my_data = [["cheese" , "english" , "english" ], ["fromage" , "french" , "spanish" ]]
# カラムとデータを使用
wandb_logger. log_text(key= "my_samples" , columns= columns, data= my_data)
# pandas データフレームを使用
wandb_logger. log_text(key= "my_samples" , dataframe= my_dataframe)
# テキストキャプション、画像、およびオーディオを含む W&B テーブルを記録
columns = ["caption" , "image" , "sound" ]
# データはリストのリストであるべきです
my_data = [
["cheese" , wandb. Image(img_1), wandb. Audio(snd_1)],
["wine" , wandb. Image(img_2), wandb. Audio(snd_2)],
]
# テーブルを記録
wandb_logger. log_table(key= "my_samples" , columns= columns, data= data)
Lightning のコールバックシステムを使用して、WandbLogger を介して Weights & Biases にログを記録するタイミングを制御することができます。この例では、検証画像と予測のサンプルをログします：
import torch
import wandb
import lightning.pytorch as pl
from lightning.pytorch.loggers import WandbLogger
# または
# from wandb.integration.lightning.fabric import WandbLogger
class LogPredictionSamplesCallback (Callback):
def on_validation_batch_end (
self, trainer, pl_module, outputs, batch, batch_idx, dataloader_idx
):
"""検証バッチの終了時に呼び出されます。"""
# `outputs` は `LightningModule.validation_step` からのもので、今回はモデルの予測に相当します
# 最初のバッチから20のサンプル画像予測をログします
if batch_idx == 0 :
n = 20
x, y = batch
images = [img for img in x[:n]]
captions = [
f "Ground Truth: { y_i} - Prediction: { y_pred} "
for y_i, y_pred in zip(y[:n], outputs[:n])
]
# オプション1: `WandbLogger.log_image` で画像をログ
wandb_logger. log_image(key= "sample_images" , images= images, caption= captions)
# オプション2: 画像と予測をW&B テーブルとしてログ
columns = ["image" , "ground truth" , "prediction" ]
data = [
[wandb. Image(x_i), y_i, y_pred] or x_i,
y_i,
y_pred in list(zip(x[:n], y[:n], outputs[:n])),
]
wandb_logger. log_table(key= "sample_table" , columns= columns, data= data)
trainer = pl. Trainer(callbacks= [LogPredictionSamplesCallback()])
複数の GPU を使用して Lightning と W&B を使用する
PyTorch Lightning は DDP インターフェースを通じてマルチGPUをサポートしています。ただし、PyTorch Lightning のデザインは GPU をインスタンス化する際に注意が必要です。
Lightning は、トレーニングループ内の各 GPU (またはランク) がまったく同じ方法で、同じ初期条件でインスタンス化されなければならないと仮定しています。ただし、ランク0のプロセスだけが wandb.run オブジェクトに アクセスでき、非ゼロランクのプロセスには wandb.run = None となります。これが原因で、非ゼロプロセスが失敗する可能性があります。このような状況になると、ランク0のプロセスが非ゼロランクのプロセスに参加を待つことになり、既にクラッシュしてしまうため、デッドロック に陥る可能性があります。
このため、トレーニングコードのセットアップに注意する必要があります。推奨される方法は、コードを wandb.run オブジェクトに依存しないようにすることです。
class MNISTClassifier (pl. LightningModule):
def __init__(self):
super(MNISTClassifier, self). __init__()
self. model = nn. Sequential(
nn. Flatten(),
nn. Linear(28 * 28 , 128 ),
nn. ReLU(),
nn. Linear(128 , 10 ),
)
self. loss = nn. CrossEntropyLoss()
def forward (self, x):
return self. model(x)
def training_step (self, batch, batch_idx):
x, y = batch
y_hat = self. forward(x)
loss = self. loss(y_hat, y)
self. log("train/loss" , loss)
return {"train_loss" : loss}
def validation_step (self, batch, batch_idx):
x, y = batch
y_hat = self. forward(x)
loss = self. loss(y_hat, y)
self. log("val/loss" , loss)
return {"val_loss" : loss}
def configure_optimizers (self):
return torch. optim. Adam(self. parameters(), lr= 0.001 )
def main ():
# 同じ値にランダムシードをすべて設定します。
# これは分散トレーニングの設定で重要です。
# 各ランクは自身の初期重みセットを取得します。
# 一致しない場合、勾配も一致せず、
# トレーニングが収束しない可能性があります。
pl. seed_everything(1 )
train_loader = DataLoader(train_dataset, batch_size= 64 , shuffle= True , num_workers= 4 )
val_loader = DataLoader(val_dataset, batch_size= 64 , shuffle= False , num_workers= 4 )
model = MNISTClassifier()
wandb_logger = WandbLogger(project= "<project_name>" )
callbacks = [
ModelCheckpoint(
dirpath= "checkpoints" ,
every_n_train_steps= 100 ,
),
]
trainer = pl. Trainer(
max_epochs= 3 , gpus= 2 , logger= wandb_logger, strategy= "ddp" , callbacks= callbacks
)
trainer. fit(model, train_loader, val_loader)
例
Colab のビデオチュートリアルに従うことができます。こちら をクリックしてください。
よくある質問 (FAQ)
W&B は Lightning とどのように統合されていますか？
コアなインテグレーションは、Lightning loggers API に基づいており、ログのコードをフレームワークに依存しない方法で多く書かせることができます。Logger は Lightning Trainer に渡され、この API の豊富な フックとコールバックシステム に基づいてトリガーされます。これにより、研究コードがエンジニアリングやログのコードと完全に分離されます。
追加のコードなしでインテグレーションがログする内容は？
モデルのチェックポイントを W&B に保存し、今後のRunsで使用するために閲覧またはダウンロードできるようにします。また、GPU使用量やネットワークI/Oなどのシステムメトリクス 、ハードウェア情報やOS情報などの環境情報、gitコミットやdiffパッチ、ノートブックコンテンツやセッション履歴を含むコードの状態 、標準出力に印刷されるものをキャプチャします。
トレーニングセットアップで wandb.run を使用する必要がある場合はどうすればいいですか？
アクセスが必要な変数のスコープを自分で拡張する必要があります。言い換えれば、初期条件がすべてのプロセスで同じであることを確認してください。
if os. environ. get("LOCAL_RANK" , None ) is None :
os. environ["WANDB_DIR" ] = wandb. run. dir
条件が同じならば、os.environ["WANDB_DIR"] を使用してモデルのチェックポイントディレクトリをセットアップできます。これにより、非ゼロランクプロセスでも wandb.run.dir にアクセスできます。
6.34 - Ray チューニング
W&B を Ray Tune と統合する方法。
W&B は、2 つの軽量なインテグレーションを提供することで Ray と統合します。
WandbLoggerCallback 関数は、Tune に報告されたメトリクスを Wandb API に自動的にログします。setup_wandb() 関数は、関数 API で使用でき、Tune のトレーニング情報を使用して Wandb API を自動的に初期化します。通常どおり Wandb API を使用できます。例えば、wandb.log() を使用してトレーニングプロセスをログすることができます。
インテグレーションを設定
from ray.air.integrations.wandb import WandbLoggerCallback
Wandb の設定は、tune.run() の config 引数に wandb キーを渡すことで行います（以下の例を参照）。
wandb の設定エントリの内容は、wandb.init() にキーワード引数として渡されます。以下の設定は例外で、WandbLoggerCallback 自体を設定するために使用されます:
パラメータ
project (str): Wandb プロジェクトの名前。必須。
api_key_file (str): Wandb API キーを含むファイルへのパス。
api_key (str): Wandb API キー。api_key_file の設定に代わるものです。
excludes (list): ログから除外するメトリクスのリスト。
log_config (bool): 結果辞書の設定パラメータをログするかどうか。デフォルトは False です。
upload_checkpoints (bool): True の場合、モデルのチェックポイントがアーティファクトとしてアップロードされます。デフォルトは False です。
例
from ray import tune, train
from ray.air.integrations.wandb import WandbLoggerCallback
def train_fc (config):
for i in range(10 ):
train. report({"mean_accuracy" : (i + config["alpha" ]) / 10 })
tuner = tune. Tuner(
train_fc,
param_space= {
"alpha" : tune. grid_search([0.1 , 0.2 , 0.3 ]),
"beta" : tune. uniform(0.5 , 1.0 ),
},
run_config= train. RunConfig(
callbacks= [
WandbLoggerCallback(
project= "<your-project>" , api_key= "<your-api-key>" , log_config= True
)
]
),
)
results = tuner. fit()
setup_wandb
from ray.air.integrations.wandb import setup_wandb
このユーティリティ関数は、Ray Tune で Wandb を使用するための初期化を支援します。基本的な使用法として、トレーニング関数内で setup_wandb() を呼び出します:
from ray.air.integrations.wandb import setup_wandb
def train_fn (config):
# Wandb を初期化
wandb = setup_wandb(config)
for i in range(10 ):
loss = config["a" ] + config["b" ]
wandb. log({"loss" : loss})
tune. report(loss= loss)
tuner = tune. Tuner(
train_fn,
param_space= {
# 検索スペースをここに定義
"a" : tune. choice([1 , 2 , 3 ]),
"b" : tune. choice([4 , 5 , 6 ]),
# wandb の設定
"wandb" : {"project" : "Optimization_Project" , "api_key_file" : "/path/to/file" },
},
)
results = tuner. fit()
例コード
インテグレーションがどのように機能するかを見るためにいくつかの例を作成しました：
6.35 - SageMaker
W&B を Amazon SageMaker と統合する方法。
W&B は Amazon SageMaker とインテグレーションしており、ハイパーパラメーターを自動で読み取り、分散 run をグループ化し、チェックポイントから run を再開します。
認証
W&B はトレーニングスクリプトと相対的な位置にある secrets.env という名前のファイルを探し、wandb.init() が呼び出されたときにそれを環境にロードします。wandb.sagemaker_auth(path="source_dir") を実行することで、secrets.env ファイルを生成できます。このファイルを .gitignore に追加することを忘れないでください！
既存の推定器
SageMaker の事前設定された推定器を使用している場合、ソースディレクトリーに wandb を含む requirements.txt を追加する必要があります。
Python 2 を実行している推定器を使用している場合、wandb をインストールする前に wheel から直接 psutil をインストールする必要があります。
https://wheels.galaxyproject.org/packages/psutil-5.4.8-cp27-cp27mu-manylinux1_x86_64.whl
wandb
GitHub で完全な例を確認し、ブログ でさらに詳しく読んでください。
また、SageMaker と W&B を使用した感情分析器のデプロイに関するチュートリアル を読むこともできます。
W&B sweep agent は SageMaker インテグレーションがオフになっている場合のみ SageMaker ジョブで期待通りに動作します。wandb.init の呼び出しを変更して SageMaker インテグレーションをオフにしてください。
wandb. init(... , settings= wandb. Settings(sagemaker_disable= True ))
6.36 - Scikit-Learn
wandbを使って、scikit-learn モデルの性能を数行のコードで視覚化し比較することができます。 例を試す →
始めに
サインアップしてAPIキーを作成
APIキーは、あなたのマシンをW&Bに認証するためのものです。ユーザーのプロフィールからAPIキーを生成できます。
右上のユーザープロフィールアイコンをクリック。
User Settings を選択し、API Keys セクションまでスクロール。Reveal をクリック。表示されたAPIキーをコピーします。APIキーを非表示にするには、ページを再読み込みしてください。
wandb ライブラリをインストールしてログインローカルでwandb ライブラリをインストールし、ログインするには:
Command Line
Python
Python notebook
WANDB_API_KEY 環境変数 をあなたのAPIキーに設定します。
export WANDB_API_KEY= <your_api_key>
wandb ライブラリをインストールし、ログインします。
pip install wandb
wandb login
import wandb
wandb. login()
!pip install wandb
import wandb
wandb.login()
メトリクスをログする
import wandb
wandb. init(project= "visualize-sklearn" )
y_pred = clf. predict(X_test)
accuracy = sklearn. metrics. accuracy_score(y_true, y_pred)
# メトリクスを時間でログする場合、wandb.logを使用
wandb. log({"accuracy" : accuracy})
# またはトレーニングの最後にメトリクスをログするには、wandb.summaryを使用することもできます
wandb. summary["accuracy" ] = accuracy
プロットを作成する
ステップ1: wandbをインポートして新しいrunを初期化
import wandb
wandb. init(project= "visualize-sklearn" )
ステップ2: プロットを可視化する
個別のプロット
モデルをトレーニングし、予測を行った後、wandbでプロットを生成して予測を分析することができます。サポートされているチャートの完全なリストについては、以下のSupported Plots セクションを参照してください。
# 単一のプロットを可視化
wandb. sklearn. plot_confusion_matrix(y_true, y_pred, labels)
すべてのプロット
W&B には plot_classifier などの関数があり、関連する複数のプロットを描画します。
# すべての分類器プロットを可視化
wandb. sklearn. plot_classifier(
clf,
X_train,
X_test,
y_train,
y_test,
y_pred,
y_probas,
labels,
model_name= "SVC" ,
feature_names= None ,
)
# すべての回帰プロット
wandb. sklearn. plot_regressor(reg, X_train, X_test, y_train, y_test, model_name= "Ridge" )
# すべてのクラスタリングプロット
wandb. sklearn. plot_clusterer(
kmeans, X_train, cluster_labels, labels= None , model_name= "KMeans"
)
既存のMatplotlibプロット
Matplotlibで作成されたプロットも、W&B ダッシュボードにログすることができます。そのためには、最初に plotly をインストールする必要があります。
最後に、以下のようにW&Bのダッシュボードにプロットをログすることができます。
import matplotlib.pyplot as plt
import wandb
wandb. init(project= "visualize-sklearn" )
# plt.plot(), plt.scatter() などをここで行います。
# ...
# plt.show()の代わりに:
wandb. log({"plot" : plt})
サポートされているプロット
学習曲線
モデルを様々な長さのデータセットでトレーニングし、交差検証スコアとデータセットサイズのプロットを生成します。トレーニングセットとテストセット両方に対して。
wandb.sklearn.plot_learning_curve(model, X, y)
model (clf or reg): 学習済みの回帰器または分類器を受け取ります。
X (arr): データセットの特徴。
y (arr): データセットのラベル。
ROC
ROC曲線は、真陽性率 (y軸) 対 偽陽性率 (x軸) をプロットします。理想的なスコアは、TPR = 1 かつ FPR = 0で、グラフの左上の点です。通常、ROC曲線の下面積 (AUC-ROC) を計算し、AUC-ROC が大きいほど良いです。
wandb.sklearn.plot_roc(y_true, y_probas, labels)
y_true (arr): テストセットのラベル。
y_probas (arr): テストセットの予測確率。
labels (list): 目標変数 (y) の名前付きラベル。
クラスの割合
トレーニングセットとテストセット内のターゲットクラスの分布をプロットします。非バランスなクラスを検出し、1つのクラスがモデルに過度の影響を与えないようにするために役立ちます。
wandb.sklearn.plot_class_proportions(y_train, y_test, ['dog', 'cat', 'owl'])
y_train (arr): トレーニングセットのラベル。
y_test (arr): テストセットのラベル。
labels (list): 目標変数 (y) の名前付きラベル。
精度-再現率曲線
異なる閾値に対する精度と再現率のトレードオフを計算します。曲線下面積が高いということは、再現率も精度も高いことを表しており、高精度は低誤報率に、高再現率は低漏れ率に関連しています。
精度と再現率の両方が高いことは、分類器が正確な結果（高精度）を返していること、さらに全ての陽性結果の大半を返していること（高再現率）を示しています。クラスが非常に不均衡な時に、PR曲線は役立ちます。
wandb.sklearn.plot_precision_recall(y_true, y_probas, labels)
y_true (arr): テストセットのラベル。
y_probas (arr): テストセットの予測確率。
labels (list): 目標変数 (y) の名前付きラベル。
特徴の重要度
分類タスクにおける各特徴の重要度を評価しプロットします。ツリーのような feature_importances_ 属性を持つ分類器でのみ動作します。
wandb.sklearn.plot_feature_importances(model, ['width', 'height', 'length'])
model (clf): 学習済みの分類器を受け取ります。
feature_names (list): 特徴の名前。プロット中の特徴のインデックスを対応する名前で置き換えることで読みやすくします。
キャリブレーション曲線
分類器の予測確率がどれだけキャリブレーションされているか、そしてどのように未キャリブレーションの分類器をキャリブレーションするかをプロットします。ロジスティック回帰ベースラインモデル、引数として渡されたモデル、およびそのアイソトニックキャリブレーションとシグモイドキャリブレーションによって、推定された予測確率を比較します。
キャリブレーション曲線が対角線に近いほど良好です。転写されたシグモイド型の曲線は過適合した分類器を表し、シグモイド型の曲線は学習不足の分類器を表します。モデルのアイソトニックおよびシグモイドキャリブレーションをトレーニングし、その曲線を比較することで、モデルがオーバーフィットかアンダーフィットしているかを判断し、どのキャリブレーション（シグモイドまたはアイソトニック）が問題を修正するのに役立つかを理解できます。
詳細については、sklearnのドキュメント を参照してください。
wandb.sklearn.plot_calibration_curve(clf, X, y, 'RandomForestClassifier')
model (clf): 学習済みの分類器を受け取ります。
X (arr): トレーニングセットの特徴。
y (arr): トレーニングセットのラベル。
model_name (str): モデル名。デフォルトは’Classifier’です。
混同行列
分類の精度を評価するために混同行列を計算します。モデルの予測の質を評価し、モデルが間違ってしまう予測のパターンを見つけるのに役立ちます。対角線は、実際のラベルと予測ラベルが一致する正しい予測を表します。
wandb.sklearn.plot_confusion_matrix(y_true, y_pred, labels)
y_true (arr): テストセットのラベル。
y_pred (arr): テストセットの予測ラベル。
labels (list): 目標変数 (y) の名前付きラベル。
サマリーメトリクス
mse、mae、r2スコアなどの分類のサマリーメトリクスを計算します。f1、精度、再現率などの回帰のサマリーメトリクスを計算します。
wandb.sklearn.plot_summary_metrics(model, X_train, y_train, X_test, y_test)
model (clf or reg): 学習済みの回帰器または分類器を受け取ります。
X (arr): トレーニングセットの特徴。
y (arr): トレーニングセットのラベル。
y_test (arr): テストセットのラベル。
エルボープロット
クラスターの数に対する分散の説明率をトレーニング時間とともに測定しプロットします。クラスター数の最適値を選ぶのに役立ちます。
wandb.sklearn.plot_elbow_curve(model, X_train)
model (clusterer): 学習済みのクラスタリングアルゴリズムを受け取ります。
X (arr): トレーニングセットの特徴。
シルエットプロット
1つのクラスター内の各ポイントが、隣接するクラスターポイントにどれだけ近いかを測定しプロットします。クラスターの厚みはクラスターサイズに対応します。垂直線は全ポイントの平均シルエットスコアを示します。
+1に近いシルエット係数は、サンプルが隣接クラスターから遠いことを示します。0の値は、サンプルが隣接クラスター間の意思決定境界にあることを示しています。負の値は、これらのサンプルが誤ってクラスターに割り当てられた可能性があることを示します。
一般的に私たちは、すべてのシルエットクラスター スコアが、平均以上（赤線を超えたところ）そして1にできるだけ近いことを望みます。また、データ中の基礎パターンを反映したクラスターサイズを好みます。
wandb.sklearn.plot_silhouette(model, X_train, ['spam', 'not spam'])
model (clusterer): 学習済みのクラスタリングアルゴリズムを受け取ります。
X (arr): トレーニングセットの特徴。
cluster_labels (list): クラスターラベルの名前。プロット中のクラスターインデックスを対応する名前で置き換え、読みやすくします。
外れ値候補プロット
Cookの距離を使用して、回帰モデルの各データポイントの影響を評価します。大きく偏った影響を持つインスタンスは外れ値である可能性があります。外れ値検出に役立ちます。
wandb.sklearn.plot_outlier_candidates(model, X, y)
model (regressor): 学習済みの分類器を受け取ります。
X (arr): トレーニングセットの特徴。
y (arr): トレーニングセットのラベル。
残差プロット
予測された目標値 (y軸) 対 実際の目標値と予測された目標値の差 (x軸) 、さらに残差誤差の分布を測定しプロットします。
一般的に、適切にフィットされたモデルの残差はランダムに分布しているべきです。というのも、良いモデルは、データセット中のほとんどの現象を説明するからです。ランダムな誤差を除いて。
wandb.sklearn.plot_residuals(model, X, y)
model (regressor): 学習済みの分類器を受け取ります。
X (arr): トレーニングセットの特徴。
y (arr): トレーニングセットのラベル。
ご質問がある場合は、私たちのslackコミュニティ でお答えしますので、お気軽にどうぞ。
例
6.37 - Simple Transformers
Hugging Face の Transformers ライブラリと W&B を統合する方法。
このライブラリは、Hugging Face の Transformers ライブラリに基づいています。Simple Transformers を使用すると、Transformer モデルを迅速にトレーニングおよび評価できます。モデルの初期化、モデルのトレーニング、およびモデルの評価には、わずか 3 行のコードで済みます。Sequence Classification、Token Classification (NER)、Question Answering、Language Model Fine-Tuning、Language Model Training、Language Generation、T5 Model、Seq2Seq Tasks、Multi-Modal Classification、Conversational AI をサポートしています。
モデル トレーニング の可視化に Weights & Biases を使用するには、args 辞書の wandb_project 属性に W&B のプロジェクト名を設定します。これにより、すべてのハイパーパラメーター 値、トレーニング ロス、および評価メトリクスが指定されたプロジェクトにログされます。
model = ClassificationModel('roberta' , 'roberta-base' , args= {'wandb_project' : 'project-name' })
wandb.init に渡す追加の引数は、wandb_kwargs として渡すことができます。
構造
このライブラリは、すべての NLP タスクに対して個別のクラスを持つように設計されています。類似の機能を提供するクラスは、グループ化されています。
simpletransformers.classification - すべての Classification モデルを含みます。
ClassificationModelMultiLabelClassificationModel
simpletransformers.ner - すべての Named Entity Recognition モデルを含みます。
simpletransformers.question_answering - すべての Question Answering モデルを含みます。
以下は、いくつかの最小限の例です。
MultiLabel Classification
model = MultiLabelClassificationModel("distilbert","distilbert-base-uncased",num_labels=6,
args={"reprocess_input_data": True, "overwrite_output_dir": True, "num_train_epochs": epochs, 'learning_rate': learning_rate,
'wandb_project': "simpletransformers"},
)
# モデルをトレーニングする
model.train_model(train_df)
# モデルを評価する
result, model_outputs, wrong_predictions = model.eval_model(eval_df)
Question Answering
train_args = {
'learning_rate': wandb.config.learning_rate,
'num_train_epochs': 2,
'max_seq_length': 128,
'doc_stride': 64,
'overwrite_output_dir': True,
'reprocess_input_data': False,
'train_batch_size': 2,
'fp16': False,
'wandb_project': "simpletransformers"
}
model = QuestionAnsweringModel('distilbert', 'distilbert-base-cased', args=train_args)
model.train_model(train_data)
SimpleTransformers は、すべての一般的な自然言語タスクのためのクラスとトレーニングスクリプトを提供します。ここでは、ライブラリでサポートされているグローバル引数の完全なリストと、そのデフォルト引数を示します。
global_args = {
"adam_epsilon": 1e-8,
"best_model_dir": "outputs/best_model",
"cache_dir": "cache_dir/",
"config": {},
"do_lower_case": False,
"early_stopping_consider_epochs": False,
"early_stopping_delta": 0,
"early_stopping_metric": "eval_loss",
"early_stopping_metric_minimize": True,
"early_stopping_patience": 3,
"encoding": None,
"eval_batch_size": 8,
"evaluate_during_training": False,
"evaluate_during_training_silent": True,
"evaluate_during_training_steps": 2000,
"evaluate_during_training_verbose": False,
"fp16": True,
"fp16_opt_level": "O1",
"gradient_accumulation_steps": 1,
"learning_rate": 4e-5,
"local_rank": -1,
"logging_steps": 50,
"manual_seed": None,
"max_grad_norm": 1.0,
"max_seq_length": 128,
"multiprocessing_chunksize": 500,
"n_gpu": 1,
"no_cache": False,
"no_save": False,
"num_train_epochs": 1,
"output_dir": "outputs/",
"overwrite_output_dir": False,
"process_count": cpu_count() - 2 if cpu_count() > 2 else 1,
"reprocess_input_data": True,
"save_best_model": True,
"save_eval_checkpoints": True,
"save_model_every_epoch": True,
"save_steps": 2000,
"save_optimizer_and_scheduler": True,
"silent": False,
"tensorboard_dir": None,
"train_batch_size": 8,
"use_cached_eval_features": False,
"use_early_stopping": False,
"use_multiprocessing": True,
"wandb_kwargs": {},
"wandb_project": None,
"warmup_ratio": 0.06,
"warmup_steps": 0,
"weight_decay": 0,
}
詳細なドキュメントについては、github の simpletransformers を参照してください。
最も人気のある GLUE ベンチマークデータセットでのトランスフォーマーのトレーニングをカバーしている こちらの Weights & Biases レポート をご覧ください。 ぜひ自分で colab で試してみてください 。
6.38 - Skorch
W&B を Skorch と統合する方法。
Weights & Biases を Skorch と一緒に使うことで、各エポックの後に最もパフォーマンスの良いモデルを自動的にログし、すべてのモデルパフォーマンスメトリクス、モデルトポロジー、計算リソースを記録することができます。wandb_run.dir に保存されたすべてのファイルは、自動的に W&B サーバーにログされます。
example run を参照してください。
Parameters
Parameter
Type
Description
wandb_runwandb.wandb_run. Runデータをログするために使用される wandb run。
save_modelbool (default=True)
最良のモデルのチェックポイントを保存し、W&B サーバー上の Run にアップロードするかどうか。
keys_ignoredstr or list of str (default=None)
tensorboard にログされるべきでないキーまたはキーのリスト。ユーザーが提供するキーに加え、event_ で始まるか _best で終わるキーはデフォルトで無視されます。
Example Code
インテグレーションがどのように機能するかを見るためのいくつかの例を作成しました:
# wandb をインストールする
... pip install wandb
import wandb
from skorch.callbacks import WandbLogger
# wandb Run を作成
wandb_run = wandb. init()
# 代わりの方法: W&B アカウントなしで wandb Run を作成
wandb_run = wandb. init(anonymous= "allow" )
# ハイパーパラメータをログ (オプション)
wandb_run. config. update({"learning rate" : 1e-3 , "batch size" : 32 })
net = NeuralNet(... , callbacks= [WandbLogger(wandb_run)])
net. fit(X, y)
Method reference
Method
Description
initialize()コールバックの初期状態を（再）設定する。
on_batch_begin(net[, X, y, training])各バッチの開始時に呼び出される。
on_batch_end(net[, X, y, training])各バッチの終了時に呼び出される。
on_epoch_begin(net[, dataset_train, …])各エポックの開始時に呼び出される。
on_epoch_end(net, **kwargs)最後の履歴ステップの値をログし、最良のモデルを保存する。
on_grad_computed(net, named_parameters[, X, …])勾配が計算された後、更新ステップが行われる前に、各バッチごとに一度呼び出される。
on_train_begin(net, **kwargs)モデルトポロジーをログし、勾配に対するフックを追加する。
on_train_end(net[, X, y])トレーニングの終了時に呼び出される。
6.39 - spaCy
spaCy は人気のある「産業強度」のNLPライブラリで、迅速かつ高精度なモデルを手間なく利用できます。spaCy v3からは、Weights & Biasesをspacy train
サインアップしてAPIキーを作成
APIキーは、あなたのマシンをW&Bに認証します。ユーザープロフィールからAPIキーを生成できます。
右上のユーザープロフィールアイコンをクリック。
ユーザー設定 を選択し、APIキー セクションまでスクロール。表示 をクリックし、表示されたAPIキーをコピーします。APIキーを非表示にするには、ページを再読み込みしてください。
wandbライブラリをインストールしてログインwandbライブラリをローカルにインストールし、ログインするには:
Command Line
Python
Python notebook
WANDB_API_KEY 環境変数 をあなたのAPIキーに設定します。
export WANDB_API_KEY= <your_api_key>
wandbライブラリをインストールしてログインします。
pip install wandb
wandb login
import wandb
wandb. login()
!pip install wandb
import wandb
wandb.login()
WandbLoggerをspaCyの設定ファイルに追加spaCyの設定ファイルは、ロギングだけでなく、GPUの割り当て、オプティマイザーの選択、データセットのパスなど、トレーニングのすべての側面を指定するために使用されます。[training.logger]の下に、キー @loggers を 値 “spacy.WandbLogger.v3” で、さらに project_name を指定する必要があります。
spaCyのトレーニング設定ファイルの仕組みや、トレーニングをカスタマイズするために渡すことができるその他のオプションについては、
spaCyのドキュメント を参照してください。
[training. logger]
@loggers = "spacy.WandbLogger.v3"
project_name = "my_spacy_project"
remove_config_values = ["paths.train" , "paths.dev" , "corpora.train.path" , "corpora.dev.path" ]
log_dataset_dir = "./corpus"
model_log_interval = 1000
名前
説明
project_namestr型。W&Bプロジェクトの名前。存在しない場合は、自動的にプロジェクトが作成されます。
remove_config_valuesList[str]型。W&Bにアップロードする前に設定から除外する値のリスト。デフォルトは[]です。
model_log_intervalOptional int型。デフォルトはNoneです。設定すると、モデルのバージョン管理 がArtifacts とともに有効になります。モデルチェックポイントをログに記録する間隔のステップ数を渡します。デフォルトはNoneです。
log_dataset_dirOptional str型。パスを渡すと、トレーニング開始時にデータセットはArtifactsとしてアップロードされます。デフォルトはNoneです。
entityOptional str型。指定した場合、run は指定したエンティティで作成されます。
run_nameOptional str型。指定された場合、run は指定された名前で作成されます。
トレーニングを開始
WandbLoggerをspaCyのトレーニング設定に追加したら、通常通り spacy train を実行できます。
Command Line
Python
Python notebook
python - m spacy train \
config. cfg \
-- output ./ output \
-- paths. train ./ train \
-- paths. dev ./ dev
python - m spacy train \
config. cfg \
-- output ./ output \
-- paths. train ./ train \
-- paths. dev ./ dev
!python -m spacy train \
config.cfg \
--output ./output \
--paths.train ./train \
--paths.dev ./dev
トレーニングが始まると、トレーニングrun のW&Bページ へのリンクが出力され、このrun の実験管理ダッシュボード にWeights & BiasesのウェブUIでアクセスできます。
6.40 - Stable Baselines 3
W&B を Stable Baseline 3 と統合する方法。
Stable Baselines 3 (SB3) は、PyTorch による強化学習アルゴリズムの信頼性のある実装セットです。W&B の SB3 インテグレーション:
損失やエピソードごとのリターンなどのメトリクスを記録します。
ゲームをプレイするエージェントのビデオをアップロードします。
トレーニング済みモデルを保存します。
モデルのハイパーパラメーターをログします。
モデルの勾配ヒストグラムをログします。
W&B を用いた SB3 トレーニング run の例 をレビューしてください。
SB3 実験をログする
from wandb.integration.sb3 import WandbCallback
model. learn(... , callback= WandbCallback())
WandbCallback 引数
引数
使用法
verbosesb3 出力の詳細度
model_save_pathモデルが保存されるフォルダーへのパス。デフォルト値は None で、モデルはログされません。
model_save_freqモデルを保存する頻度
gradient_save_freq勾配をログする頻度。デフォルト値は 0 で、勾配はログされません。
基本的な例
W&B SB3 インテグレーションは、TensorBoard から出力されたログを使用してメトリクスをログします。
import gym
from stable_baselines3 import PPO
from stable_baselines3.common.monitor import Monitor
from stable_baselines3.common.vec_env import DummyVecEnv, VecVideoRecorder
import wandb
from wandb.integration.sb3 import WandbCallback
config = {
"policy_type" : "MlpPolicy" ,
"total_timesteps" : 25000 ,
"env_name" : "CartPole-v1" ,
}
run = wandb. init(
project= "sb3" ,
config= config,
sync_tensorboard= True , # sb3 の tensorboard メトリクスを自動アップロード
monitor_gym= True , # ゲームをプレイするエージェントのビデオを自動アップロード
save_code= True , # オプション
)
def make_env ():
env = gym. make(config["env_name" ])
env = Monitor(env) # リターンなどの統計を記録
return env
env = DummyVecEnv([make_env])
env = VecVideoRecorder(
env,
f "videos/ { run. id} " ,
record_video_trigger= lambda x: x % 2000 == 0 ,
video_length= 200 ,
)
model = PPO(config["policy_type" ], env, verbose= 1 , tensorboard_log= f "runs/ { run. id} " )
model. learn(
total_timesteps= config["total_timesteps" ],
callback= WandbCallback(
gradient_save_freq= 100 ,
model_save_path= f "models/ { run. id} " ,
verbose= 2 ,
),
)
run. finish()
6.41 - TensorBoard
W&B は、W&B マルチテナント SaaS のために埋め込まれた TensorBoard をサポートしています。
あなたの TensorBoard ログをクラウドにアップロードし、同僚やクラスメートと迅速に結果を共有し、分析を一元化された場所に保つことができます。
始めましょう
import wandb
# `sync_tensorboard=True` で wandb run を開始
wandb. init(project= "my-project" , sync_tensorboard= True )
# TensorBoard を使用した トレーニング コード
...
# [オプション]wandb run を終了して tensorboard ログを W&B にアップロード（ノートブックの場合）
wandb. finish()
例 を確認してください。
run が終了すると、W&B で TensorBoard イベントファイルに アクセス でき、W&B ネイティブチャートでメトリクスを視覚化できます。システムの CPU や GPU の利用状況、git の状態、run が使用したターミナルコマンドなどの追加情報と一緒に表示されます。
W&B はすべての バージョン の TensorFlow を使用した TensorBoard をサポートしています。また、W&B は TensorFlow 1.14 以上の バージョン で PyTorch および TensorBoardX もサポートしています。
よくある質問
TensorBoard に ログ されていないメトリクスを W&B に ログ するにはどうすればよいですか？
TensorBoard にログされていないカスタムメトリクスを追加でログする必要がある場合、wandb.logをコード内で呼び出すことができます。wandb.log({"custom": 0.8})
Tensorboard を同期する際、wandb.log でステップ引数を設定することはできません。異なるステップ数を設定したい場合は、次のようにステップメトリクスを使ってメトリクスをログできます。
wandb.log({"custom": 0.8, "global_step": global_step})
wandb で Tensorboard を使用する場合、どのように設定すれば良いですか？TensorBoard のパッチに対する制御をもっと持ちたい場合、wandb.init に sync_tensorboard=True を渡す代わりに wandb.tensorboard.patch を呼び出すことができます。
import wandb
wandb. tensorboard. patch(root_logdir= "<logging_directory>" )
wandb. init()
# ノートブックの場合、wandb run を終了して tensorboard ログを W&B にアップロード
wandb. finish()
このメソッドに tensorboard_x=False を渡すことで、バニラ TensorBoard がパッチされるように確保できます。PyTorch で TensorBoard > 1.14 を使用している場合は、 pytorch=True を渡して確保することができます。これらのオプションは、インポートされたこれらのライブラリの バージョン に応じて、賢いデフォルトを持っています。
デフォルトでは、tfevents ファイルと .pbtxt ファイルを同期します。これによりあなたのために TensorBoard インスタンスをローンンチできるようになります。run ページには TensorBoard タブ が表示されます。この振る舞いは、wandb.tensorboard.patch に save=False を渡すことで無効にできます。
import wandb
wandb. init()
wandb. tensorboard. patch(save= False , tensorboard_x= True )
# ノートブックの場合、wandb run を終了して tensorboard ログを W&B にアップロード
wandb. finish()
tf.summary.create_file_writer または torch.utils.tensorboard 経由で SummaryWriter を構築する前 に、wandb.init または wandb.tensorboard.patch のいずれかを呼び出す必要があります。
過去の TensorBoard runs を同期するにはどうすればよいですか?
ローカルに保存されている既存の tfevents ファイルを W&B にインポートしたい場合は、wandb sync log_dir を実行できます。ここで log_dir は tfevents ファイルを含むローカルディレクトリーです。
Google Colab や Jupyter を TensorBoard で使用するにはどうすればよいですか？
Jupyter または Colab ノートブックでコードを実行する場合、トレーニングの終了時に wandb.finish() を呼び出してください。これにより wandb run は完了し、tensorboard ログを W&B にアップロードして視覚化できるようになります。 .py スクリプトを実行する場合、スクリプトが終了すると自動的に wandb も終了するため、これは必要ありません。
ノートブック 環境 でシェル コマンド を実行するには、! を先頭に付ける必要があります。例：!wandb sync directoryname。
PyTorch を TensorBoard で使用するにはどうすればよいですか？
もし PyTorch の TensorBoard インテグレーションを使用している場合、PyTorch Profiler JSON ファイルを手動でアップロードする必要があります。
wandb. save(glob. glob(f "runs/*.pt.trace.json" )[0 ], base_path= f "runs" )
6.42 - TensorFlow
始めましょう
すでにTensorBoardを使用している場合は、wandbと簡単に統合できます。
import tensorflow as tf
import wandb
wandb. init(config= tf. flags. FLAGS, sync_tensorboard= True )
カスタムメトリクスをログする
TensorBoardにログされていない追加のカスタムメトリクスをログする必要がある場合、コード内で wandb.log を呼び出せます wandb.log({"custom": 0.8})
Tensorboardとの同期時には、wandb.log のステップ引数はオフになっています。異なるステップカウントを設定したい場合、次のようにステップメトリクスとしてメトリクスをログできます：
wandb. log({"custom" : 0.8 , "global_step" :global_step}, step= global_step)
TensorFlowエスティメーターフック
ログする内容をより詳細に制御したい場合、wandbはTensorFlowエスティメーター用のフックも提供しています。これにより、グラフ内のすべての tf.summary 値をログします。
import tensorflow as tf
import wandb
wandb. init(config= tf. FLAGS)
estimator. train(hooks= [wandb. tensorflow. WandbHook(steps_per_log= 1000 )])
手動でログする
TensorFlowでメトリクスをログする最も簡単な方法は、TensorFlowロガーで tf.summary をログすることです：
import wandb
with tf. Session() as sess:
# ...
wandb. tensorflow. log(tf. summary. merge_all())
TensorFlow 2 においてカスタムループでモデルをトレーニングする推奨方法は、tf.GradientTape を使用することです。詳しくはこちら で読むことができます。TensorFlowのカスタムトレーニングループに wandb を組み込んでメトリクスをログしたい場合、次のコードスニペットに従ってください：
with tf. GradientTape() as tape:
# 確率を取得
predictions = model(features)
# 損失を計算
loss = loss_func(labels, predictions)
# メトリクスをログ
wandb. log("loss" : loss. numpy())
# 勾配を取得
gradients = tape. gradient(loss, model. trainable_variables)
# 重みを更新
optimizer. apply_gradients(zip(gradients, model. trainable_variables))
完全な例はこちら で入手可能です。
W&BはTensorBoardとどう違うのか？
共同創業者がW&Bの開発を始めたとき、OpenAIのフラストレーションを抱えたTensorBoardユーザーのためのツールを作ることにインスパイアされました。ここに、私たちが改善に注力したいくつかのポイントがあります：
モデルの再現 : Weights & Biasesは実験管理、探査、およびモデルを後で再現するのに優れています。私たちはメトリクスだけでなく、ハイパーパラメーターやコードのバージョンもキャプチャし、プロジェクトが再現可能であるように、バージョン管理の状態やモデルのチェックポイントを保存できます。自動整理 : コラボレーターからプロジェクトを引き継いだり、休暇から戻ったり、古いプロジェクトを再開する際に、W&Bは試されたすべてのモデルを見るのを簡単にします。こうして、誰も何時間も無駄にせず、GPUサイクルや二酸化炭素を消費して実験をやり直すことを避けられます。迅速で柔軟なインテグレーション : あなたのプロジェクトに5分でW&Bを追加できます。オープンソースのPythonパッケージを無料でインストールし、コードに数行追加することで、モデルを実行するたびに素晴らしいログメトリクスと記録が得られます。持続可能で中央集権的なダッシュボード : どこでモデルをトレーニングしても、あなたのローカルマシン、共有ラボクラスター、クラウドのスポットインスタンスであっても結果は同じ中央ダッシュボードに共有されます。異なるマシンからTensorBoardファイルをコピーして整理するのに時間を費やす必要はありません。強力なテーブル : 異なるモデルの結果を検索、フィルタ、ソートし、グループ化できます。数千のモデルバージョンを簡単に見渡し、異なるタスクに対して最もパフォーマンスの良いモデルを見つけることができます。TensorBoardは大規模なプロジェクトに対してはうまく機能しません。コラボレーションのためのツール : 複雑な機械学習プロジェクトを整理するためにW&Bを利用できます。W&Bへのリンクを簡単に共有でき、プライベートチームを活用して皆が共通のプロジェクトに結果を送信できるようにできます。また、レポートを通じてのコラボレーションもサポートされています— インタラクティブな可視化を追加したり、仕事の内容をmarkdownで説明できます。これにより、作業ログを保持したり、上司と学びを共有したり、研究室やチームに学びを提示したりするのに最適です。
無料アカウント で始めましょう
例
インテグレーションがどのように機能するかを見るためにいくつかの例を作成しました：
6.43 - W&B for Julia
Julia との W&B 統合方法。
機械学習実験をJuliaプログラミング言語で行う場合、コミュニティの貢献者によって作成された非公式なJuliaバインディングセット、wandb.jl を使用できます。
例は、wandb.jlリポジトリのドキュメント で見つけることができます。彼らの「Getting Started」例は以下の通りです。
using Wandb, Dates, Logging
# 新しいrunを開始し、ハイパーパラメーターをconfigでトラッキング
lg = WandbLogger(project = "Wandb.jl" ,
name = "wandbjl-demo- $ (now())" ,
config = Dict ("learning_rate" => 0.01 ,
"dropout" => 0.2 ,
"architecture" => "CNN" ,
"dataset" => "CIFAR-100" ))
# LoggingExtras.jlを使用して、複数のロガーに同時にログを記録
global_logger(lg)
# トレーニングまたは評価ループのシミュレーション
for x ∈ 1 : 50
acc = log(1 + x + rand() * get_config(lg, "learning_rate" ) + rand() + get_config(lg, "dropout" ))
loss = 10 - log(1 + x + rand() + x * get_config(lg, "learning_rate" ) + rand() + get_config(lg, "dropout" ))
# スクリプトからW&Bにメトリクスをログする
@info "metrics" accuracy= acc loss= loss
end
# runを終了
close(lg)
6.44 - XGBoost
ツリーを W&B でトラッキングしましょう。
wandb ライブラリには、XGBoost のトレーニングからメトリクス、設定、保存されたブースターをログするための WandbCallback コールバックがあります。ここでは、XGBoost WandbCallback の出力を含む ライブ Weights & Biases ダッシュボード
始めに
XGBoost で収集したメトリクス、設定、ブースターモデルを Weights & Biases にログするのは、XGBoost に WandbCallback を渡すだけで簡単です。
from wandb.integration.xgboost import WandbCallback
import xgboost as XGBClassifier
...
# wandb run を開始
run = wandb. init()
# モデルに WandbCallback を渡す
bst = XGBClassifier()
bst. fit(X_train, y_train, callbacks= [WandbCallback(log_model= True )])
# wandb run を終了
run. finish()
このノートブック
WandbCallback リファレンス機能
WandbCallback を XGBoost モデルに渡すと、以下のことが行えます:
ブースターモデルの設定を Weights & Biases にログする
XGBoost によって収集された評価メトリクス（例: rmse, accuracy）を Weights & Biases にログする
XGBoost で収集されたトレーニングメトリクスをログする（eval_set にデータを提供する場合）
最良のスコアと最良のイテレーションをログする
トレーニング済みモデルを Weights & Biases Artifacts に保存およびアップロードする（log_model = True の場合）
log_feature_importance=True（デフォルト）の場合、特徴重要度のプロットをログするdefine_metric=True（デフォルト）の場合、wandb.summary に最良の評価メトリックをキャプチャする
引数
log_model: (boolean) True の場合、モデルを Weights & Biases Artifacts に保存しアップロードする
log_feature_importance: (boolean) True の場合、特徴重要度の棒グラフをログする
importance_type: (str) {weight, gain, cover, total_gain, total_cover} のいずれかでツリーモデルに適用。重みは線形モデルに対応。
define_metric: (boolean) True（デフォルト）の場合、トレーニングの最良のステップでモデルのパフォーマンスを wandb.summary にキャプチャする（最後のステップではなく）。
WandbCallback のソースコード を確認できます。
追加の例は、GitHub の例のリポジトリ をチェックしてください。
Sweep でハイパーパラメーターをチューニングする
モデルの最大パフォーマンスを引き出すには、ツリーの深さや学習率など、ハイパーパラメーターをチューニングする必要があります。Weights & Biases には、大規模なハイパーパラメーターテスト実験を設定、編成、分析するための強力なツールキットである Sweeps が含まれています。
この XGBoost & Sweeps Python スクリプト も試すことができます。
6.45 - YOLOv5
Ultralytics’ YOLOv5 (“You Only Look Once”) モデルファミリーは、畳み込みニューラルネットワークを使用したリアルタイムのオブジェクト検出を、苦痛なく実現します。
Weights & Biases は YOLOv5 に直接インテグレーションされており、実験のメトリクス追跡、モデルとデータセットのバージョン管理、リッチなモデル予測の可視化などを提供します。YOLO の実験を実行する前に pip install 一行を実行するだけで始められます。
すべての W&B ログ機能は、
PyTorch DDP などのデータ並列マルチGPUトレーニングと互換性があります。
コア実験の追跡
wandb をインストールするだけで、システムメトリクス、モデルメトリクス、インタラクティブなダッシュボード にログされるメディアといった、ビルトインの W&B ログ機能 が有効になります。
pip install wandb
git clone https:// github. com/ ultralytics/ yolov5. git
python yolov5/ train. py # 小さなデータセットで小さなネットワークをトレーニングします
wandb によって標準出力に表示されるリンクをただフォローするだけです。
インテグレーションのカスタマイズ
YOLO にいくつかの簡単なコマンドライン引数を渡すことで、さらに多くの W&B 機能を活用できます。
--save_period に数値を渡すと、W&B は各 save_period エポックの終わりにモデルバージョン を保存します。モデルバージョンにはモデルの重みが含まれ、検証セットで最もパフォーマンスの良いモデルにタグ付けされます。--upload_dataset フラグをオンにすると、データセットがデータバージョン管理のためにアップロードされます。--bbox_interval に数値を渡すと、データ可視化 が有効になります。各 bbox_interval エポックの終わりに、モデルの出力が検証セットに対して W&B にアップロードされます。
Model Versioning Only
Model Versioning and Data Visualization
python yolov5/ train. py -- epochs 20 -- save_period 1
python yolov5/ train. py -- epochs 20 -- save_period 1 \
-- upload_dataset -- bbox_interval 1
すべての W&B アカウントには、データセットとモデル用に 100 GB の無料ストレージが付属しています。
これがどのように見えるかを示します。
6.46 - ウルトラリティクス
Ultralytics は、画像分類、オブジェクト検出、画像セグメンテーション、ポーズ推定などのタスクにおける最先端のコンピュータビジョンモデルのホームです。リアルタイムオブジェクト検出モデルのYOLOシリーズの最新バージョンである YOLOv8 をホストするだけでなく、他にも SAM (Segment Anything Model) 、RT-DETR 、YOLO-NAS などの強力なコンピュータビジョンモデルも備えています。これらのモデルの実装を提供するだけでなく、Ultralytics は、これらのモデルを使ったトレーニング、ファインチューニング、適用のための使いやすい API を使ったエンドツーエンドのワークフローも提供しています。
始めましょう
ultralytics と wandb をインストールします。
```shell
pip install --upgrade ultralytics==8.0.238 wandb
# または
# conda install ultralytics
```
```bash
!pip install --upgrade ultralytics==8.0.238 wandb
```
開発チームは ultralyticsv8.0.238 以下とのインテグレーションをテストしました。インテグレーションに関する問題を報告するには、タグ yolov8 を付けて GitHub issue を作成してください。
実験管理とバリデーション結果の可視化
このセクションでは、Ultralytics モデルを使ったトレーニング、ファインチューニング、バリデーションの典型的なワークフローと、実験管理、モデルのチェックポイント、モデルのパフォーマンスの可視化を W&B を使用して行う方法を示します。
このインテグレーションについては、次のレポートで確認することもできます：Supercharging Ultralytics with W&B
Ultralytics と W&B のインテグレーションを使用するには、wandb.integration.ultralytics.add_wandb_callback 関数をインポートします。
import wandb
from wandb.integration.ultralytics import add_wandb_callback
from ultralytics import YOLO
選択した YOLO モデルを初期化し、推論を行う前に add_wandb_callback 関数を呼び出します。これにより、トレーニング、ファインチューニング、バリデーション、または推論を行うときに、実験ログと、地上真実とそれぞれの予測結果を重ね合わせた画像が、自動的に コンピュータビジョンタスクの対話型オーバーレイ で保存され、追加の洞察が wandb.Table
# YOLO モデルを初期化
model = YOLO("yolov8n.pt" )
# Ultralytics 用に W&B コールバックを追加
add_wandb_callback(model, enable_model_checkpointing= True )
# モデルをトレーニング/ファインチューニング
# 各エポックの終わりに、バリデーションバッチでの予測が
# コンピュータビジョンタスク用の洞察に満ちた対話型オーバーレイと共に
# W&B テーブルに記録されます
model. train(project= "ultralytics" , data= "coco128.yaml" , epochs= 5 , imgsz= 640 )
# W&B run を終了
wandb. finish()
Ultralytics のトレーニングまたはファインチューニングワークフローで W&B により実験管理された様子は次のとおりです。
YOLO Fine-tuning Experiments エポックごとのバリデーション結果が W&B Table を使用してどのように可視化されるかは次のとおりです。
WandB Validation Visualization Table 予測結果の可視化
このセクションでは、Ultralytics モデルを使った推論と結果の可視化の典型的なワークフローを W&B を使用して示します。
Google Colab でコードを試すことができます: Open in Colab .
このインテグレーションについては、次のレポートで確認することもできます：Supercharging Ultralytics with W&B
Ultralytics と W&B のインテグレーションを使用するには、wandb.integration.ultralytics.add_wandb_callback 関数をインポートする必要があります。
import wandb
from wandb.integration.ultralytics import add_wandb_callback
from ultralytics.engine.model import YOLO
インテグレーションをテストするためにいくつかの画像をダウンロードします。静止画像、ビデオ、またはカメラソースを使用できます。推論ソースの詳細については、Ultralytics のドキュメント を確認してください。
!wget https://raw.githubusercontent.com/wandb/examples/ultralytics/colabs/ultralytics/assets/img1.png
!wget https://raw.githubusercontent.com/wandb/examples/ultralytics/colabs/ultralytics/assets/img2.png
!wget https://raw.githubusercontent.com/wandb/examples/ultralytics/colabs/ultralytics/assets/img4.png
!wget https://raw.githubusercontent.com/wandb/examples/ultralytics/colabs/ultralytics/assets/img5.png
次に、wandb.init を使って W&B の run を初期化します。
# W&B run を初期化
wandb. init(project= "ultralytics" , job_type= "inference" )
次に、希望する YOLO モデルを初期化し、推論を行う前に add_wandb_callback 関数を呼び出します。これにより、推論を実行すると、コンピュータビジョンタスク用の対話型オーバーレイ で画像が自動的にログに記録され、追加の洞察が wandb.Table
# YOLO モデルを初期化
model = YOLO("yolov8n.pt" )
# Ultralytics 用に W&B コールバックを追加
add_wandb_callback(model, enable_model_checkpointing= True )
# 予測を実行し、自動的に W&B テーブルにログを記録
# バウンディングボックス、セグメンテーションマスク用の対話型オーバーレイ付き
model(
[
"./assets/img1.jpeg" ,
"./assets/img3.png" ,
"./assets/img4.jpeg" ,
"./assets/img5.jpeg" ,
]
)
# W&B run を終了
wandb. finish()
トレーニングまたはファインチューニングワークフローの場合、wandb.init() を使用して明示的に run を初期化する必要はありません。ただし、コードが予測のみを含む場合は、明示的に run を作成する必要があります。
対話型の bbox オーバーレイは次のように表示されます。
WandB Image Overlay W&B 画像オーバーレイに関する詳細情報は こちら で取得できます。
その他のリソース
6.47 - YOLOX
W&B を YOLOX と統合する方法。
YOLOX は、オブジェクト検出において優れたパフォーマンスを持つ、アンカーフリー版のYOLOです。YOLOX W&Bインテグレーションを使用すると、トレーニング、検証、およびシステムに関連するメトリクスのログをオンにすることができ、単一のコマンドライン引数で予測をインタラクティブに検証することができます。
サインアップしてAPIキーを作成する
APIキーは、W&Bに対してマシンを認証します。APIキーはユーザープロファイルから生成できます。
右上のユーザープロファイルアイコンをクリックします。
User Settings を選択し、API Keys セクションまでスクロールします。Reveal をクリックします。表示されたAPIキーをコピーします。APIキーを非表示にするには、ページをリロードしてください。
wandb ライブラリをインストールしてログインするローカルに wandb ライブラリをインストールしてログインする方法:
Command Line
Python
Python notebook
WANDB_API_KEY environment variable をAPIキーに設定します。
export WANDB_API_KEY= <your_api_key>
wandb ライブラリをインストールしてログインします。
pip install wandb
wandb login
import wandb
wandb. login()
!pip install wandb
import wandb
wandb.login()
メトリクスをログする
--logger wandb コマンドライン引数を使用して、wandbでのロギングを有効にします。また、wandb.initwandb- を前置します。
num_eval_imges は、モデルの評価のためにW&Bテーブルにログされる検証セット画像と予測の数を制御します。
# wandb にログイン
wandb login
# `wandb` ロガー引数を使って yolox のトレーニングスクリプトを呼び出します
python tools/train.py .... --logger wandb \
\
wandb-name <run-name> \
\
\
\
例
YOLOX のトレーニングと検証メトリクスを含むダッシュボードの例 ->
このW&Bインテグレーションに関する質問や問題がありますか？ YOLOXリポジトリ でissueを開いてください。
上の画像は、`val_loss` 列に基づいたフィルターを示しています。このフィルターは、1以下の検証損失を持つ run を表示します。
上の画像は、セマンティックセグメンテーションとカスタムメトリクスを含むテーブルを示しています。このテーブルはこちらの 
