Launch を設定する

• 1: ローンンチエージェントを設定する
• 2: ローンンチキューを設定する
• 3: チュートリアル: Docker を使用して W&B ローンンチを設定する
• 4: チュートリアル: Kubernetes上でW&B ローンンチ を設定する
• 5: チュートリアル: SageMaker で W&B Launch を設定する
• 6: チュートリアル: Vertex AI で W&B Launch を設定する

このページでは、W&B Launch を設定するために必要な上位レベルの手順について説明しています。

1. キューのセットアップ: キューはFIFOであり、キュー設定を持っています。キューの設定は、ジョブがどこでどのように対象リソースで実行されるかを制御します。
2. エージェントのセットアップ: エージェントはあなたのマシン/インフラストラクチャー上で実行され、1つ以上のキューからローンチジョブをポールします。ジョブがプルされると、エージェントはイメージがビルドされ、利用可能であることを確認します。その後、エージェントはジョブを対象リソースに送信します。

キューのセットアップ

Launch キューは、特定の対象リソースとそのリソースに特有の追加設定を指すように設定する必要があります。例えば、Kubernetes クラスターを指すローンチキューは、環境変数を含めたり、カスタムネームスペースのローンチキュー設定を設定したりします。キューを作成する際には、使用したい対象リソースとそのリソースに使用する設定の両方を指定します。

エージェントがキューからジョブを受け取ると、キュー設定も受け取ります。エージェントがジョブを対象リソースに送信する際には、キュー設定とジョブ自体のオーバーライドを含めます。例えば、ジョブ設定を使用して、特定のジョブインスタンスのみの Amazon SageMaker インスタンスタイプを指定することができます。この場合、エンドユーザーインターフェースとして queue config templates を使用することが一般的です。

キューの作成

1. wandb.ai/launch で Launch App へ移動します。
2. 画面の右上にあるcreate queueボタンをクリックします。

3. Entity のドロップダウンメニューから、そのキューが所属する エンティティ を選択します。
4. Queue フィールドにキューの名前を入力します。
5. Resource のドロップダウンから、ジョブをこのキューに追加する際に使用する計算リソースを選択します。
6. このキューのPrioritizationを許可するかどうかを選択します。優先度が有効になっている場合、チームのユーザーは起動ジョブをエンキューする際にその優先度を定義できます。優先度が高いジョブは、優先度が低いジョブより先に実行されます。
7. Configuration フィールドに、JSON または YAML 形式でリソース設定を提供します。設定ドキュメントの構造とセマンティクスは、キューが指すリソースタイプに依存します。詳細については、対象リソースに関する専用の設定ページを参照してください。

ローンチエージェントのセットアップ

ローンチエージェントは、ジョブのための1つ以上のローンチキューをポールする長時間実行されるプロセスです。ローンチエージェントは、FIFO 順序または優先順序でジョブをデキューし、ポールするキューに依存します。エージェントがキューからジョブをデキューすると、そのジョブのためにイメージをオプションでビルドします。その後、エージェントはジョブをキュー設定で指定された設定オプションとともに対象リソースに送信します。

エージェントは非常に柔軟で、さまざまなユースケースをサポートするように設定できます。エージェントに必要な設定は、特定のユースケースに依存します。Docker、Amazon SageMaker、Kubernetes、または Vertex AI に関する専用ページを参照してください。

W&B は、特定のユーザーの APIキー ではなく、サービスアカウントの APIキー でエージェントを起動することをお勧めします。サービスアカウントの APIキー を使用することには次の2つの利点があります。

1. エージェントは、特定のユーザーに依存しません。
2. Launch によって作成された run に関連付けられた作成者が、エージェントに関連付けられたユーザーではなく、ローンチジョブを送信したユーザーとして Launch に表示されます。

エージェントの設定

launch-config.yaml という名前の YAML ファイルでローンチエージェントを設定します。デフォルトでは、W&B は ~/.config/wandb/launch-config.yaml に設定ファイルを確認します。ローンチエージェントをアクティブにするときに、異なるディレクトリーを指定することもできます。

ローンチエージェントの設定ファイルの内容は、ローンチエージェントの環境、ローンチキューの対象リソース、Dockerビルダ要件、クラウドレジストリ要件などに依存します。

ユースケースに関係なく、ローンチエージェントにはコア設定可能なオプションがあります。

• max_jobs: エージェントが並行して実行できるジョブの最大数
• entity: キューが所属するエンティティ
• queues: エージェントが監視する1つ以上のキューの名前

W&B CLI を使用して、ローンチエージェントのためのユニバーサル設定可能オプションを指定できます（設定 YAMLファイルの代わりに）。最大ジョブ数、W&B エンティティ、およびローンチキューです。詳細については、wandb launch-agent コマンドを参照してください。

次の YAML スニペットは、コアローンチエージェント設定キーを指定する方法を示しています。

# 最大同時 run 数を指定します。-1 = 無制限
max_jobs: -1

entity: <entity-name>

# ポールするキューのリスト
queues:
  - <queue-name>

コンテナビルダーの設定

ローンチエージェントをイメージ構築に使用するように設定できます。Git リポジトリまたはコードアーティファクトから作成されたローンチジョブを使用する場合、コンテナビルダーを使用するようにエージェントを設定する必要があります。Create a launch job を参照して、ローンチジョブの作成方法について詳しく学んでください。

W&B Launch は3つのビルダーオプションをサポートしています：

• Docker: DockerビルダーはローカルのDockerデーモンを使用してイメージをビルドします。
• Kaniko: Kaniko は、Dockerデーモンが利用できない環境でのイメージ構築を可能にする Google のプロジェクトです。
• Noop: エージェントはジョブをビルドしようとせず、代わりに事前にビルドされたイメージをプルするだけです。

エージェントが Dockerデーモンが利用できない環境でポールしている場合（例えば、Kubernetesクラスター）、Kanikoビルダーを使用してください。

Kanikoビルダーの詳細については、Set up Kubernetes を参照してください。

イメージビルダーを指定するには、エージェント設定にビルダーキーを含めます。例えば、次のコードスニペットは、DockerまたはKanikoを使用することを指定するローンチ設定（launch-config.yaml）の一部を示しています。

builder:
  type: docker | kaniko | noop

コンテナレジストリの設定

場合によっては、ローンチエージェントをクラウドレジストリに接続したいかもしれません。ローンチエージェントをクラウドレジストリに接続したい一般的なシナリオは次のとおりです：

• ジョブをビルドした場所以外の環境（強力なワークステーションやクラスターなど）でジョブを実行したい場合。
• エージェントを使用してイメージをビルドし、Amazon SageMakerやVertexAIでこれらのイメージを実行したい場合。
• エージェントにイメージリポジトリからプルするための資格情報を提供してもらいたい場合。

コンテナレジストリと対話するようにエージェントを設定する方法の詳細については、Advanced agent set ページを参照してください。

ローンチエージェントのアクティブ化

launch-agent W&B CLIコマンドを使用してローンチエージェントをアクティブ化します：

wandb launch-agent -q <queue-1> -q <queue-2> --max-jobs 5

いくつかのユースケースでは、ローンチエージェントをKubernetesクラスター内からキューをポールするように設定したいかもしれません。Advanced queue set up page を参照して、詳細情報を得てください。

1 - ローンンチエージェントを設定する

高度なエージェント設定

このガイドでは、W&B ローンチエージェントを設定して、さまざまな環境でコンテナイメージを作成する方法について情報を提供します。

ビルダー

ローンチエージェントは、Docker または Kaniko を使用してイメージをビルドできます。

• Kaniko: Kubernetes で特権コンテナとしてビルドを実行せずにコンテナイメージをビルドします。
• Docker: ローカルで docker build コマンドを実行してコンテナイメージをビルドします。

ビルダータイプは、ローンチエージェントの設定で builder.type キーを使用して、docker、kaniko、またはビルドをオフにするための noop に制御できます。デフォルトでは、エージェントの Helm チャートは builder.type を noop に設定します。builder セクションの追加キーは、ビルドプロセスを設定するために使用されます。

エージェントの設定でビルダーが指定されていない場合、有効な docker CLI が見つかると、エージェントは自動的に Docker を使用します。Docker が利用できない場合、エージェントは noop をデフォルトとします。

コンテナレジストリへのプッシュ

ローンチエージェントは、ビルドするすべてのイメージに一意のソースハッシュでタグを付けます。エージェントは、builder.destination キーで指定されたレジストリにイメージをプッシュします。

たとえば、builder.destination キーが my-registry.example.com/my-repository に設定されている場合、エージェントはイメージに my-registry.example.com/my-repository:<source-hash> というタグを付けてプッシュします。イメージがすでにレジストリに存在する場合、ビルドはスキップされます。

エージェント設定

Helm チャートを経由してエージェントをデプロイする場合、エージェント設定は values.yaml ファイルの agentConfig キーに提供する必要があります。

自分で wandb launch-agent を使用してエージェントを呼び出す場合、エージェント設定を --config フラグを使用して YAML ファイルのパスとして提供できます。デフォルトでは、設定は ~/.config/wandb/launch-config.yaml から読み込まれます。

ローンチエージェントの設定 (launch-config.yaml) 内で、ターゲットリソース環境とコンテナレジストリの名前をそれぞれ environment と registry キーに提供します。

環境とレジストリに基づいてローンチエージェントを設定する方法を、以下のタブで示します。

• AWS
• GCP
• Azure

environment:
  type: aws
  region: <aws-region>
builder:
  type: <kaniko|docker>
  # エージェントがイメージを保存する ECR レポジトリの URI。
  # リージョンが環境に設定した内容と一致することを確認してください。
  destination: <account-id>.ecr.<aws-region>.amazonaws.com/<repository-name>
  # Kaniko を使用する場合、エージェントがビルドコンテキストを保存する S3 バケットを指定します。
  build-context-store: s3://<bucket-name>/<path>

environment:
  type: gcp
  region: <gcp-region>
  project: <gcp-project-id>
builder:
  type: <kaniko|docker>
  # エージェントがイメージを保存するアーティファクトリポジトリとイメージ名の URI。
  # リージョンとプロジェクトが環境に設定した内容と一致することを確認してください。
  uri: <region>-docker.pkg.dev/<project-id>/<repository-name>/<image-name>
  # Kaniko を使用する場合、エージェントがビルドコンテキストを保存する GCS バケットを指定します。
  build-context-store: gs://<bucket-name>/<path>

environment:
  type: azure
builder:
  type: <kaniko|docker>
  # エージェントがイメージを保存する Azure コンテナレジストリレポジトリの URI。
  destination: https://<registry-name>.azurecr.io/<repository-name>
  # Kaniko を使用する場合、エージェントがビルドコンテキストを保存する Azure Blob Storage コンテナを指定します。
  build-context-store: https://<storage-account-name>.blob.core.windows.net/<container-name>

エージェント権限

エージェントの必要な権限はユースケースによって異なります。

クラウドレジストリ権限

ローンチエージェントがクラウドレジストリと対話するために通常必要な権限は以下の通りです。

• AWS
• GCP
• Azure

{
  'Version': '2012-10-17',
  'Statement':
    [
      {
        'Effect': 'Allow',
        'Action':
          [
            'ecr:CreateRepository',
            'ecr:UploadLayerPart',
            'ecr:PutImage',
            'ecr:CompleteLayerUpload',
            'ecr:InitiateLayerUpload',
            'ecr:DescribeRepositories',
            'ecr:DescribeImages',
            'ecr:BatchCheckLayerAvailability',
            'ecr:BatchDeleteImage',
          ],
        'Resource': 'arn:aws:ecr:<region>:<account-id>:repository/<repository>',
      },
      {
        'Effect': 'Allow',
        'Action': 'ecr:GetAuthorizationToken',
        'Resource': '*',
      },
    ],
}

artifactregistry.dockerimages.list;
artifactregistry.repositories.downloadArtifacts;
artifactregistry.repositories.list;
artifactregistry.repositories.uploadArtifacts;

Kaniko のためのストレージ権限

ローンチエージェントは、Kaniko ビルダーを使用している場合、クラウドストレージにプッシュする権限が必要です。Kaniko はビルドジョブを実行するポッドの外にコンテキストストアを使用します。

• AWS
• GCP
• Azure

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListObjectsInBucket",
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": ["arn:aws:s3:::<BUCKET-NAME>"]
    },
    {
      "Sid": "AllObjectActions",
      "Effect": "Allow",
      "Action": "s3:*Object",
      "Resource": ["arn:aws:s3:::<BUCKET-NAME>/*"]
    }
  ]
}

storage.buckets.get;
storage.objects.create;
storage.objects.delete;
storage.objects.get;

Kaniko ビルドのカスタマイズ

Kaniko ジョブが使用する Kubernetes ジョブ仕様をエージェント設定の builder.kaniko-config キーに指定します。例えば：

builder:
  type: kaniko
  build-context-store: <my-build-context-store>
  destination: <my-image-destination>
  build-job-name: wandb-image-build
  kaniko-config:
    spec:
      template:
        spec:
          containers:
          - args:
            - "--cache=false" # 引数は "key=value" の形式でなければなりません
            env:
            - name: "MY_ENV_VAR"
              value: "my-env-var-value"

Launch エージェントを CoreWeave にデプロイ

オプションとして、W&B Launch エージェントを CoreWeave クラウドインフラストラクチャにデプロイできます。CoreWeave は GPU 加速ワークロード専用に構築されたクラウドインフラストラクチャです。

CoreWeave に Launch エージェントをデプロイする方法については、CoreWeave ドキュメント を参照してください。

2 - ローンンチキューを設定する

以下のページでは、ローンチキューオプションの設定方法について説明します。

キュー設定テンプレートのセットアップ

Queue Config Templates を使用して、計算リソースの消費に関するガードレールを管理します。メモリ消費量、GPU、実行時間などのフィールドに対して、デフォルト、最小値、および最大値を設定します。

config templates を使用してキューを設定した後、チームのメンバーは、あなたが定義した範囲内のフィールドのみを変更することができます。

キューテンプレートの設定

既存のキューでキューテンプレートを設定するか、新しいキューを作成することができます。

1. https://wandb.ai/launch のローンチアプリに移動します。
2. テンプレートを追加したいキューの名前の横にある View queue を選択します。
3. Config タブを選択します。これにより、キューの作成日時、キュー設定、および既存のローンチタイムオーバーライドに関する情報が表示されます。
4. Queue config セクションに移動します。
5. テンプレートを作成したい設定キー-値を特定します。
6. 設定内の値をテンプレートフィールドに置き換えます。テンプレートフィールドは {{variable-name}} の形式をとります。
7. Parse configuration ボタンをクリックします。設定を解析すると、W&B は作成した各テンプレートの下にキュー設定タイルを自動的に作成します。
8. 生成された各タイルに対して、キュー設定が許可できるデータ型 (文字列、整数、浮動小数点数) を最初に指定する必要があります。これを行うために、Type ドロップダウンメニューからデータ型を選択します。
9. データ型に基づいて、各タイル内に表示されるフィールドを完成させます。
10. Save config をクリックします。

例えば、チームが使用できる AWS インスタンスを制限するテンプレートを作成したい場合、テンプレートフィールドを追加する前のキュー設定は次のようになります：

RoleArn: arn:aws:iam:region:account-id:resource-type/resource-id
ResourceConfig:
  InstanceType: ml.m4.xlarge
  InstanceCount: 1
  VolumeSizeInGB: 2
OutputDataConfig:
  S3OutputPath: s3://bucketname
StoppingCondition:
  MaxRuntimeInSeconds: 3600

InstanceType にテンプレートフィールドを追加すると、設定は次のようになります：

RoleArn: arn:aws:iam:region:account-id:resource-type/resource-id
ResourceConfig:
  InstanceType: "{{aws_instance}}"
  InstanceCount: 1
  VolumeSizeInGB: 2
OutputDataConfig:
  S3OutputPath: s3://bucketname
StoppingCondition:
  MaxRuntimeInSeconds: 3600

次に、Parse configuration をクリックします。新しいタイル aws-instance が Queue config の下に表示されます。

そこで、Type ドロップダウンからデータ型として String を選択します。これにより、ユーザーが選択できる値を指定できるフィールドが表示されます。例えば、次の画像では、チームの管理者がユーザーが選べる 2 つの異なる AWS インスタンスタイプ (ml.m4.xlarge と ml.p3.xlarge) を設定しています：

ローンチジョブを動的に設定する

キュー設定は、エージェントがキューからジョブをデキューするときに評価されるマクロを使用して動的に設定できます。以下のマクロを設定できます：

アクセラレータ (GPU) で実行されるイメージをビルドするためのローンチエージェントの使用

アクセラレータ環境で実行されるイメージをビルドするためにローンチを使用する場合、アクセラレータベースイメージを指定する必要があります。

このアクセラレータベースイメージは次の要件を満たしている必要があります：

• Debian 互換 (Launch Dockerfile は python を取得するために apt-get を使用します)
• CPU & GPU ハードウェアインストラクションセットとの互換性 (使用する GPU がサポートする CUDA バージョンであることを確認してください)
• あなたが提供するアクセラレータバージョンと ML アルゴリズムにインストールされたパッケージ間の互換性
• ハードウェアとの互換性を確立するために必要な追加ステップを要求するパッケージのインストール

TensorFlow で GPU を使用する方法

TensorFlow が GPU を適切に利用することを確認してください。これを達成するために、キューリソース設定の builder.accelerator.base_image キーで Docker イメージとそのイメージタグを指定します。

例えば、tensorflow/tensorflow:latest-gpu ベースイメージは、TensorFlow が GPU を適切に使用することを保証します。これはキュー設定でリソース設定を使用して設定できます。

以下の JSON スニペットは、キュー設定で TensorFlow ベースイメージを指定する方法を示しています：

{
    "builder": {
        "accelerator": {
            "base_image": "tensorflow/tensorflow:latest-gpu"
        }
    }
}

3 - チュートリアル: Docker を使用して W&B ローンンチを設定する

以下のガイドでは、ローカルマシンでドッカーを使用してW&B Launchを設定し、ローンンチエージェントの環境とキューの対象リソースとして使用する方法を説明します。

ドッカーを使用してジョブを実行し、同じローカルマシン上でローンンチエージェントの環境として使用することは、クラスター管理システム（Kubernetesなど）がインストールされていないマシンにコンピュートがある場合に特に役立ちます。

また、強力なワークステーションでのワークロードを実行するためにドッキューを使用することもできます。

ドッカーをW&B Launchと一緒に使用する場合、W&Bはまずイメージをビルドし、そのイメージからコンテナをビルドして実行します。イメージはDockerの docker run <image-uri> コマンドでビルドされます。キュー設定は、docker run コマンドに渡される追加の引数として解釈されます。

Dockerキューの設定

Dockerの対象リソースのためのローンンチキュー設定は、docker run CLIコマンドで定義された同じオプションを受け入れます。

エージェントはキュー設定で定義されたオプションを受け取り、その後、受け取ったオプションをローンンチジョブの設定からのオーバーライドとマージし、対象リソース（この場合はローカルマシン）で実行される最終的な docker run コマンドを生成します。

次の2つの構文変換が行われます：

1. 繰り返しオプションは、キュー設定でリストとして定義されます。
2. フラグオプションは、キュー設定で true の値を持つブール値として定義されます。

例えば、以下のキュー設定：

{
  "env": ["MY_ENV_VAR=value", "MY_EXISTING_ENV_VAR"],
  "volume": "/mnt/datasets:/mnt/datasets",
  "rm": true,
  "gpus": "all"
}

結果として以下の docker run コマンドになります：

docker run \
  --env MY_ENV_VAR=value \
  --env MY_EXISTING_ENV_VAR \
  --volume "/mnt/datasets:/mnt/datasets" \
  --rm <image-uri> \
  --gpus all

ボリュームは文字列のリストまたは単一の文字列として指定できます。複数のボリュームを指定する場合はリストを使用してください。

ドッカーは値が割り当てられていない環境変数をローンンチエージェントの環境から自動的に渡します。これは、ローンンチエージェントが環境変数 MY_EXISTING_ENV_VAR を持っている場合、その環境変数がコンテナ内で利用可能であることを意味します。これは、キュー設定で公開せずに他の設定キーを使用したい場合に便利です。

docker run コマンドの --gpus フラグを使って、ドッカーコンテナで利用可能なGPUを指定できます。gpus フラグの使用方法について詳しくは、Dockerのドキュメントをご覧ください。

キューの作成

W&B CLIを使用して、ドッカーをコンピュートリソースとして使用するキューを作成します：

1. Launchページに移動します。
2. Create Queue ボタンをクリックします。
3. キューを作成したい Entity を選択します。
4. Name フィールドにキューの名前を入力します。
5. Resource として Docker を選択します。
6. Configuration フィールドにドッカーキューの設定を定義します。
7. Create Queue ボタンをクリックしてキューを作成します。

ローカルマシンでローンンチエージェントを設定する

ローンンチエージェントを launch-config.yaml という名前の YAML 設定ファイルで設定します。デフォルトでは、W&B は ~/.config/wandb/launch-config.yaml で設定ファイルをチェックします。ローンンチエージェントをアクティベートするときに異なるディレクトリをオプションとして指定できます。

コアエージェント設定オプション

以下のタブは、W&B CLIとYAML設定ファイルを使用して、コアエージェント設定オプションを指定する方法を示しています：

• W&B CLI
• Config file

wandb launch-agent -q <queue-name> --max-jobs <n>

max_jobs: <n concurrent jobs>
queues:
	- <queue-name>

ドッカーイメージビルダー

マシン上のローンンチエージェントは、ドッカーイメージをビルドするように設定できます。デフォルトでは、これらのイメージはマシンのローカルイメージリポジトリに保存されます。ローンンチエージェントがドッカーイメージをビルドできるようにするには、ローンンチエージェント設定で builder キーを docker に設定します：

builder:
	type: docker

エージェントがドッカーイメージをビルドせず、代わりにレジストリからの事前ビルドイメージを使用したい場合は、ローンンチエージェント設定で builder キーを noop に設定します：

builder:
  type: noop

コンテナレジストリ

Launch は Dockerhub、Google Container Registry、Azure Container Registry、Amazon ECR などの外部コンテナレジストリを使用します。 異なる環境でジョブを実行したい場合は、コンテナレジストリから引き出せるようにエージェントを設定してください。

ローンンチエージェントをクラウドレジストリと接続する方法について詳しくは、Advanced agent setup ページを参照してください。

4 - チュートリアル: Kubernetes上でW&B ローンンチ を設定する

W&B Launch を使用して、ML エンジニアが Kubernetes ですでに管理しているリソースを簡単に利用できるようにし、Kubernetes クラスターに ML ワークロードをプッシュできます。

W&B は、あなたのクラスターにデプロイできる公式の Launch agent イメージ を提供しており、これは W&B が管理する Helm チャート を使用します。

W&B は Kaniko ビルダーを使用して、Launch agent が Kubernetes クラスター内で Docker イメージをビルドできるようにします。Launch agent のための Kaniko のセットアップ方法や、ジョブビルディングをオフにしてプレビルドした Docker イメージのみを使用する方法については、Advanced agent set up を参照してください。

Kubernetes のキューを設定する

Kubernetes のターゲットリソースに対する Launch キューの設定は、Kubernetes Job スペック または Kubernetes Custom Resource スペック のいずれかに似ています。

Launch キューを作成する際に、Kubernetes ワークロードリソーススペックの任意の側面を制御できます。

• Kubernetes job spec
• Custom resource spec

spec:
  template:
    spec:
      containers:
        - env:
            - name: MY_ENV_VAR
              value: some-value
          resources:
            requests:
              cpu: 1000m
              memory: 1Gi
metadata:
  labels:
    queue: k8s-test
namespace: wandb

kubernetes:
  kind: PyTorchJob
  spec:
    pytorchReplicaSpecs:
      Master:
        replicas: 1
        template:
          spec:
            containers:
              - name: pytorch
                image: '${image_uri}'
                imagePullPolicy: Always
        restartPolicy: Never
      Worker:
        replicas: 2
        template:
          spec:
            containers:
              - name: pytorch
                image: '${image_uri}'
                imagePullPolicy: Always
        restartPolicy: Never
    ttlSecondsAfterFinished: 600
  metadata:
    name: '${run_id}-pytorch-job'
  apiVersion: kubeflow.org/v1

セキュリティ上の理由から、W&B は、Launch キューに指定されていない場合、次のリソースを注入します：

• securityContext
• backOffLimit
• ttlSecondsAfterFinished

次の YAML スニペットは、これらの値が Launch キューにどのように現れるかを示しています：

spec:
  template:
    `backOffLimit`: 0
    ttlSecondsAfterFinished: 60
    securityContext:
      allowPrivilegeEscalation: False,
      capabilities:
        drop:
          - ALL,
      seccompProfile:
        type: "RuntimeDefault"

キューを作成する

Kubernetes を計算リソースとして使用する W&B アプリでキューを作成します：

1. Launch page に移動します。
2. Create Queue ボタンをクリックします。
3. キューを作成したい Entity を選択します。
4. Name フィールドにキューの名前を入力します。
5. Resource として Kubernetes を選択します。
6. Configuration フィールドに、前のセクションで設定した Kubernetes Job ワークフロースペックまたは Custom Resource スペックを入力します。

Helm を使って Launch agent を設定する

W&B が提供する Helm チャート を使用して、Launch agent を Kubernetes クラスターにデプロイします。values.yaml ファイルを使って、Launch agent の振る舞いを制御します。

Launch agent の設定ファイル (~/.config/wandb/launch-config.yaml) に通常定義されるコンテンツを values.yaml ファイルの launchConfig キーに指定します。

例えば、Kaniko Docker イメージビルダーを使用する EKS での Launch agent ルーンを可能にする Launch agent 設定があるとします：

queues:
	- <queue name>
max_jobs: <n concurrent jobs>
environment:
	type: aws
	region: us-east-1
registry:
	type: ecr
	uri: <my-registry-uri>
builder:
	type: kaniko
	build-context-store: <s3-bucket-uri>

values.yaml ファイル内では、次のようになります：

agent:
  labels: {}
  # W&B API key.
  apiKey: ''
  # Container image to use for the agent.
  image: wandb/launch-agent:latest
  # Image pull policy for agent image.
  imagePullPolicy: Always
  # Resources block for the agent spec.
  resources:
    limits:
      cpu: 1000m
      memory: 1Gi

# Namespace to deploy launch agent into
namespace: wandb

# W&B api url (Set yours here)
baseUrl: https://api.wandb.ai

# Additional target namespaces that the launch agent can deploy into
additionalTargetNamespaces:
  - default
  - wandb

# This should be set to the literal contents of your launch agent config.
launchConfig: |
  queues:
    - <queue name>
  max_jobs: <n concurrent jobs>
  environment:
    type: aws
    region: <aws-region>
  registry:
    type: ecr
    uri: <my-registry-uri>
  builder:
    type: kaniko
    build-context-store: <s3-bucket-uri>  

# The contents of a git credentials file. This will be stored in a k8s secret
# and mounted into the agent container. Set this if you want to clone private
# repos.
gitCreds: |

# Annotations for the wandb service account. Useful when setting up workload identity on gcp.
serviceAccount:
  annotations:
    iam.gke.io/gcp-service-account:
    azure.workload.identity/client-id:

# Set to access key for azure storage if using kaniko with azure.
azureStorageAccessKey: ''

レジストリ、環境、および必要なエージェント権限に関する詳細は、Advanced agent set up を参照してください。

5 - チュートリアル: SageMaker で W&B Launch を設定する

W&B Launch を使用して、提供されたアルゴリズムやカスタムアルゴリズムを使用して SageMaker プラットフォーム上で機械学習モデルをトレーニングするための ラーンンチ ジョブを Amazon SageMaker に送信できます。SageMaker はコンピュート リソースの立ち上げとリリースを担当するため、EKS クラスターを持たないチームには良い選択肢となります。

Amazon SageMaker に接続された W&B Launch キューに送信された ラーンンチ ジョブは、CreateTrainingJob API を使用して SageMaker トレーニング ジョブとして実行されます。 CreateTrainingJob API に送信される引数を制御するには、 ラーンンチ キュー設定 を使用します。

Amazon SageMaker は トレーニング ジョブを実行するために Docker イメージを使用しています。SageMaker によってプルされるイメージは、Amazon Elastic Container Registry (ECR) に保存する必要があります。 つまり、トレーニングに使用するイメージは ECR に保存する必要があります。

前提条件

始める前に、以下の前提条件を確認してください:

• Docker イメージを作成するかどうかを決定します。
• AWS リソースを設定し、S3、ECR、および Sagemaker IAM ロールに関する情報を収集します。
• Launch エージェントのための IAM ロールを作成します。

Docker イメージを作成するかどうかを決定する

W&B Launch エージェントに Docker イメージを作成させるかどうかを決定します。選択肢は 2 つあります。

• ローンンチ エージェントに Docker イメージの構築を許可し、Amazon ECR にイメージをプッシュし、SageMaker Training ジョブの送信を許可します。このオプションは、トレーニング コードを迅速に反復する ML エンジニアにいくらかの簡素化を提供できます。
• ローンンチ エージェントが、トレーニングまたは推論スクリプトを含む既存の Docker イメージを使用します。このオプションは既存の CI システムに適しています。このオプションを選択する場合は、Amazon ECR のコンテナ レジストリに Docker イメージを手動でアップロードする必要があります。

AWS リソースを設定する

お好みの AWS リージョンで次の AWS リソースが設定されていることを確認してください :

1. コンテナ イメージを保存するための ECR リポジトリ。
2. SageMaker トレーニング ジョブの入力と出力を保存するための 1 つまたは複数の S3 バケット。
3. Amazon SageMaker がトレーニング ジョブを実行し、Amazon ECR と Amazon S3 と対話することを許可する IAM ロール。

これらのリソースの ARN をメモしておいてください。SageMaker 用に Launch キュー設定 を定義するときに ARN が必要になります。

Launch エージェント用の IAM ポリシーを作成する

1. AWS の IAM 画面から、新しいポリシーを作成します。
2. JSON ポリシーエディターに切り替え、以下のポリシーをケースに基づいて貼り付けます。<> で囲まれた値を実際の値に置き換えてください:

• エージェントが事前構築された Docker イメージを送信
• エージェントが Docker イメージを構築して送信

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:DescribeLogStreams",
        "SageMaker:AddTags",
        "SageMaker:CreateTrainingJob",
        "SageMaker:DescribeTrainingJob"
      ],
      "Resource": "arn:aws:sagemaker:<region>:<account-id>:*"
    },
    {
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": "arn:aws:iam::<account-id>:role/<RoleArn-from-queue-config>"
    },
  {
      "Effect": "Allow",
      "Action": "kms:CreateGrant",
      "Resource": "<ARN-OF-KMS-KEY>",
      "Condition": {
        "StringEquals": {
          "kms:ViaService": "SageMaker.<region>.amazonaws.com",
          "kms:GrantIsForAWSResource": "true"
        }
      }
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:DescribeLogStreams",
        "SageMaker:AddTags",
        "SageMaker:CreateTrainingJob",
        "SageMaker:DescribeTrainingJob"
      ],
      "Resource": "arn:aws:sagemaker:<region>:<account-id>:*"
    },
    {
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": "arn:aws:iam::<account-id>:role/<RoleArn-from-queue-config>"
    },
    {
    "Effect": "Allow",
    "Action": [
      "ecr:CreateRepository",
      "ecr:UploadLayerPart",
      "ecr:PutImage",
      "ecr:CompleteLayerUpload",
      "ecr:InitiateLayerUpload",
      "ecr:DescribeRepositories",
      "ecr:DescribeImages",
      "ecr:BatchCheckLayerAvailability",
      "ecr:BatchDeleteImage"
    ],
    "Resource": "arn:aws:ecr:<region>:<account-id>:repository/<repository>"
  },
  {
    "Effect": "Allow",
    "Action": "ecr:GetAuthorizationToken",
    "Resource": "*"
  },
  {
      "Effect": "Allow",
      "Action": "kms:CreateGrant",
      "Resource": "<ARN-OF-KMS-KEY>",
      "Condition": {
        "StringEquals": {
          "kms:ViaService": "SageMaker.<region>.amazonaws.com",
          "kms:GrantIsForAWSResource": "true"
        }
      }
    }
  ]
}

3. 次へ をクリックします。
4. ポリシーに名前と説明を付けます。
5. ポリシー作成 をクリックします。

Launch エージェント用の IAM ロールを作成する

Launch エージェントには、Amazon SageMaker トレーニング ジョブを作成する権限が必要です。以下の手順に従って IAM ロールを作成します:

1. AWS の IAM 画面から、新しいロールを作成します。
2. 信頼されたエンティティ として AWS アカウント (または組織のポリシーに適したオプション) を選択します。
3. 権限画面をスクロールし、上で作成したポリシー名を選択します。
4. ロールに名前と説明を付けます。
5. ロールの作成 を選択します。
6. ロールの ARN を記録します。これを設定するときに Launch エージェント用に ARN を指定します。

IAM ロールの作成方法について詳しくは、AWS Identity and Access Management ドキュメント を参照してください。

SageMaker 用に Launch キューを設定する

次に、W&B アプリで SageMaker をコンピュート リソースとして使用するキューを作成します:

1. Launch アプリ に移動します。
2. キューを作成 ボタンをクリックします。
3. キューを作成する エンティティ を選択します。
4. 名前 フィールドにキューの名前を入力します。
5. リソース として SageMaker を選択します。
6. 設定 フィールド内で、SageMaker ジョブに関する情報を提供します。デフォルトでは、W&B は YAML および JSON の CreateTrainingJob リクエストボディを自動生成します:

{
  "RoleArn": "<REQUIRED>",
  "ResourceConfig": {
      "InstanceType": "ml.m4.xlarge",
      "InstanceCount": 1,
      "VolumeSizeInGB": 2
  },
  "OutputDataConfig": {
      "S3OutputPath": "<REQUIRED>"
  },
  "StoppingCondition": {
      "MaxRuntimeInSeconds": 3600
  }
}

少なくとも以下を指定する必要があります :

• RoleArn : SageMaker 実行 IAM ロールの ARN (前提条件 を参照してください)。Launch agent IAM ロールとは混同しないでください。
• OutputDataConfig.S3OutputPath : SageMaker の出力が保存される Amazon S3 URI を指定します。
• ResourceConfig: リソース設定の必須仕様です。リソース設定のオプションはこちらに記載されています。
• StoppingCondition: トレーニング ジョブの停止条件の必須仕様です。オプションはこちらに記載されています。

8. キューを作成 ボタンをクリックします。

Launch エージェントをセットアップする

次のセクションでは、エージェントをデプロイする場所と、デプロイ場所に基づいてエージェントをどのように設定するかを説明します。

Amazon SageMaker キューに Launch エージェントをデプロイする方法にはいくつかのオプションがあります: ローカルマシン、EC2 インスタンス、または EKSクラスターで。エージェントをデプロイする場所に基づいてアプリケーション エージェントを適切に構成します。

ローンンチ エージェントを実行する場所を決定する

プロダクション ワークロードおよび既に EKS クラスターを持つ顧客には、この Helm チャートを使用して EKS クラスターに ラーンンチ エージェント をデプロイすることをお勧めします。

現在の EKS クラスターがないプロダクション ワークロードには、EC2 インスタンスが適したオプションです。Launch エージェント インスタンスは常に稼働していますが、t2.micro サイズの EC2 インスタンスという比較的手頃なインスタンスで十分です。

実験的または個人のユースケースには、ローカルマシンに Launch エージェントを実行するのがすばやく始める方法です。

選択したユースケースに基づいて、以下のタブに記載されている指示に従って Launch エージェントを適切に設定してください:

• EKS
• EC2
• ローカルマシン

sudo yum install python311 -y && python3 -m ensurepip --upgrade && pip3 install wandb && pip3 install wandb[launch]

sudo yum update -y && sudo yum install -y docker python3 && sudo systemctl start docker && sudo systemctl enable docker && sudo usermod -a -G docker ec2-user

newgrp docker

[profile SageMaker-agent]
role_arn = arn:aws:iam::<account-id>:role/<agent-role-name>
source_profile = default                                                                   

[default]
aws_access_key_id=<access-key-id>
aws_secret_access_key=<secret-access-key>
aws_session_token=<session-token>

Launch エージェントを設定する

launch-config.yaml という名前の YAML 設定ファイルで Launch エージェントを設定します。

デフォルトでは、W&B は ~/.config/wandb/launch-config.yaml にある設定ファイルを確認します。エージェントをアクティブにする際に -c フラグで別のディレクトリを指定することも可能です。

以下の YAML スニペットは、コア設定エージェントオプションを指定する方法を示しています:

max_jobs: -1
queues:
  - <queue-name>
environment:
  type: aws
  region: <your-region>
registry:
  type: ecr
  uri: <ecr-repo-arn>
builder: 
  type: docker

エージェントは wandb launch-agent で開始します。

(オプション) Docker イメージを Amazon ECR にプッシュする

Launch ジョブを含む Docker イメージを Amazon ECR レポジトリにアップロードします。画像ベースのジョブを使用している場合、Docker イメージは新しい Launch ジョブを送信する前に ECR レジストリに存在している必要があります。

6 - チュートリアル: Vertex AI で W&B Launch を設定する

W&B Launch を使用して、Vertex AI トレーニングジョブとしてジョブを実行するために送信することができます。Vertex AI トレーニングジョブでは、Vertex AI プラットフォーム上の提供されたアルゴリズムまたはカスタムアルゴリズムを使用して機械学習モデルをトレーニングすることができます。ローンチジョブが開始されると、Vertex AI が基盤となるインフラストラクチャー、スケーリング、およびオーケストレーションを管理します。

W&B Launch は、google-cloud-aiplatform SDK の CustomJob クラスを介して Vertex AI と連携します。CustomJob のパラメータは、ローンチキュー設定で制御できます。Vertex AI は、GCP 外のプライベートレジストリからイメージをプルするように設定することはできません。つまり、Vertex AI と W&B Launch を使用したい場合、コンテナイメージを GCP またはパブリックレジストリに保存する必要があります。コンテナイメージを Vertex ジョブでアクセス可能にするための詳細は、Vertex AI ドキュメントを参照してください。

前提条件

1. Vertex AI API が有効になっている GCP プロジェクトを作成またはアクセスしてください。 API を有効にする方法については、GCP API コンソールドキュメント を参照してください。
2. Vertex で実行したいイメージを保存するための GCP Artifact Registry リポジトリを作成してください。 詳細については、GCP Artifact Registry ドキュメント を参照してください。
3. Vertex AI がメタデータを保存するステージング GCS バケットを作成してください。 このバケットは、Vertex AI ワークロードと同じリージョンにある必要があります。ステージングおよびビルドコンテキストには同じバケットを使用できます。
4. Vertex AI ジョブを立ち上げるために必要な権限を持つサービスアカウントを作成してください。 サービスアカウントに権限を割り当てる方法については、GCP IAM ドキュメント を参照してください。
5. サービスアカウントに Vertex ジョブを管理する権限を付与してください。

Vertex AI 用キューを設定

Vertex AI リソース用のキュー設定は、Vertex AI Python SDK の CustomJob コンストラクタと run メソッドへの入力を指定します。リソース設定は spec および run キーに格納されます。

• spec キーには、Vertex AI Python SDK の CustomJob コンストラクタ の名前付き引数の値が含まれています。
• run キーには、Vertex AI Python SDK の CustomJob クラスの run メソッドの名前付き引数の値が含まれています。

実行環境のカスタマイズは主に spec.worker_pool_specs リストで行われます。ワーカープール仕様は、ジョブを実行する作業者グループを定義します。デフォルトの設定のワーカー仕様は、アクセラレータのない n1-standard-4 マシンを 1 台要求します。必要に応じてマシンタイプ、アクセラレータタイプ、数を変更することができます。

利用可能なマシンタイプやアクセラレータタイプについての詳細は、Vertex AI ドキュメント を参照してください。

キューを作成

Vertex AI を計算リソースとして使用するキューを W&B アプリで作成する:

1. Launch ページ に移動します。
2. Create Queue ボタンをクリックします。
3. キューを作成したい Entity を選択します。
4. Name フィールドにキューの名前を入力します。
5. Resource として GCP Vertex を選択します。
6. Configuration フィールドに、前のセクションで定義した Vertex AI CustomJob についての情報を入力します。デフォルトで、W&B は次のような YAML および JSON のリクエストボディを自動入力します：

spec: worker_pool_specs: - machine_spec: machine_type: n1-standard-4 accelerator_type: ACCELERATOR_TYPE_UNSPECIFIED accelerator_count: 0 replica_count: 1 container_spec: image_uri: ${image_uri} staging_bucket: run: restart_job_on_worker_restart: false

7. キューを設定したら、Create Queue ボタンをクリックします。

最低限指定する必要があるのは以下です：

• spec.worker_pool_specs : 非空のワーカープール仕様リスト。
• spec.staging_bucket : Vertex AI アセットとメタデータのステージングに使用する GCS バケット。

ローンチエージェントを設定

ローンチエージェントは、デフォルトでは ~/.config/wandb/launch-config.yaml にある設定ファイルを介して設定可能です。

max_jobs: queues:

Vertex AI で実行されるイメージをローンチエージェントに構築してもらいたい場合は、Advanced agent set up を参照してください。

エージェント権限を設定

このサービスアカウントとして認証する方法は複数あります。Workload Identity、ダウンロードされたサービスアカウント JSON、環境変数、Google Cloud Platform コマンドラインツール、またはこれらのメソッドの組み合わせを通じて実現できます。