デフォルト構成で AI に最適化された GKE クラスタを作成する

このページでは、A4X、A4、A3 Ultra、A3 Mega、A3 High（8 個の GPU）仮想マシン（VM）を使用して AI と ML のワークロードをサポートする、AI 最適化された独自の Google Kubernetes Engine（GKE）クラスタを作成する方法について説明します。

A4X、A4、A3 Ultra、A3 Mega、A3 High（8 個の GPU）マシンシリーズは、ターゲットを絞ったワークロード配置、高度なクラスタ メンテナンス制御、トポロジーを考慮したスケジューリングなどの機能を備えた大規模な AI/ML クラスタを実行できるように設計されています。詳細については、クラスタ管理の概要をご覧ください。

GKE は、組織のニーズに合わせてさまざまなワークロードを実行するための単一のプラットフォーム サーフェスを提供します。これには、高性能の分散事前トレーニング、モデルのファインチューニング、モデルの推論、アプリケーションのサービング、サポート サービスが含まれます。GKE は、複数のプラットフォームの管理に伴う運用上の負担を軽減します。

AI 最適化 GKE クラスタの作成方法を選択する

クラスタ作成の次の各オプションでは、クラスタ構成とワークロード スケジューリングの容易さと柔軟性が異なります。

始める前に

作業を始める前に、次のタスクが完了していることを確認してください。

  • Google Kubernetes Engine API を有効にする。
    • Google Kubernetes Engine API を有効化
  • このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。gcloud CLI をインストール済みの場合は、gcloud components update コマンドを実行して最新のバージョンを取得します。以前のバージョンの gcloud CLI では、このドキュメントのコマンドを実行できない場合があります。
  • GKE クラスタと関連付けられたサービス アカウントの作成と管理に必要な権限があることを確認します。
    • Kubernetes Engine 管理者（roles/container.admin）
    • Compute 管理者（roles/compute.admin）
    • ストレージ管理者（roles/storage.admin）
    • プロジェクト IAM 管理者（roles/resourcemanager.projectIamAdmin）
    • サービス アカウント管理者（roles/iam.serviceAccountAdmin）
    • サービス アカウント ユーザー（roles/iam.serviceAccountUser）
    • Service Usage ユーザー（roles/serviceusage.serviceUsageConsumer）
    • ロール管理者（roles/iam.roleAdmin）
    • Secret Manager のシークレット バージョン マネージャー（roles/secretmanager.secretVersionManager）

使用オプションを選択して容量を取得する

  1. 使用オプションを選択します。GPU リソースの取得方法と使用方法に基づいて選択します。詳細については、使用オプションを選択するをご覧ください。

    GKE の場合、消費オプションを選択する際は、次の追加情報を考慮してください。

  2. 容量を取得する。容量を取得するプロセスは、使用オプションごとに異なります。

    選択した使用オプションのプロセスについては、容量の概要をご覧ください。

要件

AI 最適化 GKE クラスタには、次の要件が適用されます。

  • A4X の場合は、1.33 以降で GKE バージョン 1.33.4-gke.1036000 以降を使用していることを確認します。または、1.32 の場合は、GKE バージョン 1.32.8-gke.1108000 以降を使用します。これらのバージョンにより、A4X で次のものが使用されます。

    • R580: A4X の最小 GPU ドライバ バージョン。
    • デフォルトで有効になっている Coherent Driver-based Memory Management（CDMM）。NVIDIA は、メモリの過剰なレポートを解決するために、Kubernetes クラスタでこのモードを有効にすることを推奨しています。CDMM を使用すると、オペレーティング システム（OS）ではなくドライバを介して GPU メモリを管理できます。このアプローチにより、GPU メモリの OS オンライン化を回避し、GPU メモリを不均一メモリアクセス（NUMA）ノードとして OS に公開できます。CDMM が有効になっている場合、マルチインスタンス GPU はサポートされていません。CDMM について詳しくは、ハードウェアとソフトウェアのサポートをご覧ください。
    • GPUDirect RDMA。A4X ノードプールで A4X のネットワーキング機能を使用できるようにするために有効にすることをおすすめします。

  • マシンタイプに応じて、最小 GPU ドライバ バージョンを使用していることを確認します。

    • A4X: A4X VM の GB200 GPU には、R580 GPU ドライバ バージョン以上が必要です。前述のバージョン要件をご覧ください。
    • A4: A4 VM の B200 GPU には、R570 GPU ドライバ バージョン以上が必要です。GKE は、デフォルトで、A4 の最小要件バージョンである 1.32.1-gke.1729000 以降を実行しているすべての A4 ノードに、このドライバ バージョンを自動的にインストールします。
    • A3 Ultra: A3 Ultra VM の H200 GPU には、最小 R550 GPU ドライバ バージョンが必要です。これは、GKE 1.31 で latest ドライバ バージョンとして使用できます。A3 Ultra の場合は、GKE 1.31 で gpu-driver-version=latest を設定する必要があります。GKE バージョン 1.31.5-gke.1169000 以降の場合、GKE はデフォルトで A3 Ultra ノードに R550 GPU ドライバ バージョンを自動的にインストールします。

  • A3 Ultra ノードプールの場合、ディスクタイプを hyperdisk-balanced に設定する必要があります。

  • GPUDirect RDMA を使用するには、マシンタイプに応じて次の最小バージョンを使用します。

    • A4X: 前述のバージョン要件を参照してください。
    • A4: 1.32.2-gke.1475000 以降を使用します。
    • A3 Ultra: 1.31.4-gke.1183000 以降を使用します。

  • GPUDirect RDMA を使用するには、GKE ノードで Container-Optimized OS ノードイメージを使用する必要があります。Ubuntu と Windows のノードイメージはサポートされていません。

  • A4X を使用してクラスタを作成するには、予約バインド プロビジョニング モデルを使用する必要があります。他のプロビジョニング モデルはサポートされていません。

クラスタの作成

次の手順に沿って、 Cluster Toolkit または XPK を使用してクラスタを作成します。

Cluster Toolkit を使用してクラスタを作成する

このセクションでは、クラスタの作成プロセスについて説明します。このプロセスでは、プロジェクトがベスト プラクティスに準拠し、AI 最適化 GKE クラスタの要件を満たしていることを確認します。

A4X

  1. Cloud Shell を起動します。別の環境を使用することもできますが、依存関係が Cluster Toolkit にすでにプリインストールされているため、Cloud Shell をおすすめします。Cloud Shell を使用しない場合は、依存関係をインストールするの手順に沿って別の環境を準備します。

  2. git リポジトリから Cluster Toolkit のクローンを作成します。

    cd ~
git clone https://github.com/GoogleCloudPlatform/cluster-toolkit.git

  3. Cluster Toolkit をインストールします。

    cd cluster-toolkit && git checkout main && make

  4. Terraform デプロイの状態を保存する Cloud Storage バケットを作成します。

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    次の変数を置き換えます。

    • BUCKET_NAME: 新しい Cloud Storage バケットの名前。
    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
    • COMPUTE_REGION_TERRAFORM_STATE: Terraform デプロイの状態を保存するコンピューティング リージョン。

  5. GitHub リポジトリの examples/gke-a4x/gke-a4x-deployment.yaml ブループリントで、terraform_backend_defaults セクションと vars セクションに次の設定を入力して、デプロイの特定の値と一致させます。

    • DEPLOYMENT_NAME: デプロイの一意の名前。長さは 6～30 文字にする必要があります。デプロイ名がプロジェクト内で一意でない場合、クラスタの作成は失敗します。デフォルト値は gke-a4x です。
    • BUCKET_NAME: 前の手順で作成した Cloud Storage バケットの名前。
    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
    • COMPUTE_REGION: クラスタのコンピューティング リージョン。
    • COMPUTE_ZONE: A4X マシンのノードプールのコンピューティング ゾーン。このゾーンは、予約に対して使用可能なマシンがあるゾーンと一致する必要があります。
    • NODE_COUNT: クラスタのノードプール内の A4X ノードの数。18 個以下のノードにする必要があります。NVLink ドメインを使用して 1 つのサブブロックで 1x72 の GPU トポロジを取得するには、18 個のノードを使用することをおすすめします。
    • IP_ADDRESS/SUFFIX: クラスタへの接続を許可する IP アドレス範囲。この CIDR ブロックには、Terraform の呼び出しに使用するマシンの IP アドレスを含める必要があります。詳細については、承認済みネットワークの仕組みをご覧ください。

    • extended_reservation フィールドには、ノードプールのプロビジョニング時に、予約の特定のブロックをターゲットにするかどうかに応じて、次のいずれかを使用します。

      • ノードプールを予約の任意の場所に配置するには、予約の名前（RESERVATION_NAME）を指定します。

      • 予約の特定のブロックをターゲットにするには、予約名とブロック名を次の形式で使用します。

        RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      予約で使用可能なブロックが不明な場合は、予約トポロジを表示するをご覧ください。

    • システム ノードプールと A4X ノードプールの各ノードのブートディスク サイズを設定します。必要なディスクサイズはユースケースによって異なります。たとえば、ディスクをキャッシュとして使用して、イメージの繰り返し pull のレイテンシを短縮する場合は、フレームワーク、モデル、コンテナ イメージに対応するようにディスクサイズを大きく設定できます。

      • SYSTEM_NODE_POOL_DISK_SIZE_GB: システム ノードプールの各ノードのブートディスクのサイズ。最小ディスクサイズは 10 です。デフォルト値は 200 です。
      • A4X_NODE_POOL_DISK_SIZE_GB: A4X ノードプールの各ノードのブートディスクのサイズ。最小ディスクサイズは 10 です。デフォルト値は 100 です。

    詳細設定を変更するには、examples/gke-a4x/gke-a4x.yaml ファイルを編集します。

  6. 必要に応じて、クラスタで Cluster Health Scanner（CHS）を有効にできます。CHS は、テストを実行してクラスタでワークロードを実行する準備ができていることを確認することで、GPU クラスタの健全性をチェックします。CHS を有効にするには、examples/gke-a4x/gke-a4x-deployment.yaml ファイルで次の変更を行います。

    • vars ブロックで、enable_periodic_health_checks フィールドを true に設定します。

    • デフォルトでは、ヘルスチェックは毎週日曜日の午前 12 時（太平洋標準時）に実行されます。この設定を変更する場合は、vars ブロックで、health_check_schedule フィールドを適切な値（cron 形式）に設定します。
      cron 形式のスケジュール: none * * * * * # | | | | | # | | | | day of the week (0-6) (Sunday to Saturday) # | | | month (1-12) # | | day of the month (1-31) # | hour (0-23) # minute (0-59)

  7. アプリケーションのデフォルト認証情報（ADC）を生成して、Terraform にアクセスできるようにします。Cloud Shell を使用している場合は、次のコマンドを実行します。

    gcloud auth application-default login

  8. ブループリントをデプロイして、A4X マシンタイプを使用して GKE インフラストラクチャをプロビジョニングします。

    cd ~/cluster-toolkit
./gcluster deploy -d \
examples/gke-a4x/gke-a4x-deployment.yaml \
examples/gke-a4x/gke-a4x.yaml

  9. プロンプトが表示されたら、[(A)pply] を選択してブループリントをデプロイします。

    • ブループリントは、VPC ネットワーク、GPU RDMA VPC ネットワーク、サービス アカウント、クラスタ、ノードプールを作成します。
    • ブループリントで fio-bench-job-template ジョブ テンプレートをサポートするために、Google Cloud バケット、ネットワーク ストレージ、永続ボリューム リソースが作成されます。

A4

  1. Cloud Shell を起動します。別の環境を使用することもできますが、依存関係が Cluster Toolkit にすでにプリインストールされているため、Cloud Shell をおすすめします。Cloud Shell を使用しない場合は、依存関係をインストールするの手順に沿って別の環境を準備します。

  2. git リポジトリから Cluster Toolkit のクローンを作成します。

    cd ~
git clone https://github.com/GoogleCloudPlatform/cluster-toolkit.git

  3. Cluster Toolkit をインストールします。

    cd cluster-toolkit && git checkout main && make

  4. Terraform デプロイの状態を保存する Cloud Storage バケットを作成します。

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    次の変数を置き換えます。

    • BUCKET_NAME: 新しい Cloud Storage バケットの名前。
    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
    • COMPUTE_REGION_TERRAFORM_STATE: Terraform デプロイの状態を保存するコンピューティング リージョン。

  5. クラスタの作成に必要な編集ファイルは、デプロイで使用している使用オプションによって異なります。使用オプションのプロビジョニング モデルに対応するタブを選択します。

    予約で制限

    GitHub リポジトリの examples/gke-a4/gke-a4-deployment.yaml ブループリントで、terraform_backend_defaults セクションと vars セクションに次の設定を入力して、デプロイの特定の値と一致させます。

    • DEPLOYMENT_NAME: デプロイの一意の名前。長さは 6～30 文字にする必要があります。デプロイ名がプロジェクト内で一意でない場合、クラスタの作成は失敗します。デフォルト値は gke-a4 です。
    • BUCKET_NAME: 前の手順で作成した Cloud Storage バケットの名前。
    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
    • COMPUTE_REGION: クラスタのコンピューティング リージョン。
    • COMPUTE_ZONE: A4 マシンのノードプールのコンピューティング ゾーン。このゾーンは、予約に対して使用可能なマシンがあるゾーンと一致する必要があります。
    • NODE_COUNT: クラスタ内の A4 ノードの数。
    • IP_ADDRESS/SUFFIX: クラスタへの接続を許可する IP アドレス範囲。この CIDR ブロックには、Terraform の呼び出しに使用するマシンの IP アドレスを含める必要があります。詳細については、承認済みネットワークの仕組みをご覧ください。

    • reservation フィールドには、ノードプールのプロビジョニング時に、予約の特定のブロックをターゲットにするかどうかに応じて、次のいずれかを使用します。

      • ノードプールを予約の任意の場所に配置するには、予約の名前（RESERVATION_NAME）を指定します。

      • 予約の特定のブロックをターゲットにするには、予約名とブロック名を次の形式で使用します。

        RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      予約で使用可能なブロックが不明な場合は、予約トポロジを表示するをご覧ください。

    • システム ノードプールと A4 ノードプールの各ノードのブートディスク サイズを設定します。必要なディスクサイズはユースケースによって異なります。たとえば、ディスクをキャッシュとして使用して、イメージの繰り返し pull のレイテンシを短縮する場合は、フレームワーク、モデル、コンテナ イメージに対応するようにディスクサイズを大きく設定できます。

      • SYSTEM_NODE_POOL_DISK_SIZE_GB: システム ノードプールの各ノードのブートディスクのサイズ。最小ディスクサイズは 10 です。デフォルト値は 100 です。
      • A4_NODE_POOL_DISK_SIZE_GB: A4 ノードプールの各ノードのブートディスクのサイズ。最小ディスクサイズは 10 です。デフォルト値は 100 です。

    詳細設定を変更するには、examples/gke-a4/gke-a4.yaml を編集します。

    Flex Start

    1. GitHub リポジトリの examples/gke-a4/gke-a4-deployment.yaml ブループリントで、terraform_backend_defaults セクションと vars セクションに次の設定を入力して、デプロイの特定の値と一致させます。

      • DEPLOYMENT_NAME: デプロイの一意の名前。長さは 6 ～ 30 文字にする必要があります。デプロイ名がプロジェクト内で一意でない場合、クラスタの作成は失敗します。デフォルト値は gke-a4 です。
      • BUCKET_NAME: 前の手順で作成した Cloud Storage バケットの名前。
      • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
      • COMPUTE_REGION: クラスタのコンピューティング リージョン。
      • COMPUTE_ZONE: A4 マシンのノードプールのコンピューティング ゾーン。
      • static_node_count を削除します。
      • IP_ADDRESS/SUFFIX: クラスタへの接続を許可する IP アドレス範囲。この CIDR ブロックには、Terraform の呼び出しに使用するマシンの IP アドレスを含める必要があります。詳細については、承認済みネットワークの仕組みをご覧ください。
      • reservation フィールドを削除し、フィールドを enable_flex_start: true に置き換えます。キューに登録されたプロビジョニングも使用する場合は、次の行に enable_queued_provisioning: true を追加します。詳細については、キューに格納されたプロビジョニングでの Flex Start を使用するノードプールをご覧ください。

      • システム ノードプールと A4 ノードプールの各ノードのブートディスク サイズを設定します。必要なディスクサイズはユースケースによって異なります。たとえば、ディスクをキャッシュとして使用して、イメージの繰り返し pull のレイテンシを短縮する場合は、フレームワーク、モデル、コンテナ イメージに対応するようにディスクサイズを大きく設定できます。

        • SYSTEM_NODE_POOL_DISK_SIZE_GB: システム ノードプールの各ノードのブートディスクのサイズ。最小ディスクサイズは 10 です。デフォルト値は 100 です。
        • A4_NODE_POOL_DISK_SIZE_GB: A4 ノードプールの各ノードのブートディスクのサイズ。最小ディスクサイズは 10 です。デフォルト値は 100 です。

    2. GitHub リポジトリの examples/gke-a4/gke-a4.yaml ブループリントで、次の変更を行います。

      • vars ブロックで static_node_count を削除します。
      • vars ブロックで、version_prefix の番号が "1.32." 以上であることを確認します。GKE で Flex Start を使用するには、クラスタでバージョン 1.32.2-gke.1652000 以降を使用する必要があります。
      • vars ブロックで、reservation ブロック全体（reservation 行自体を含む）を enable_flex_start: true に置き換えます。必要に応じて、enable_queued_provisioning: true に置き換えます。
      • vars ブロックで、キューに登録されたプロビジョニングが不要な場合は、kueue_configuration_path: $(ghpc_stage("./kueue-configuration.yaml.tftpl")) という行を削除します。
      • id: a4-pool で、static_node_count: $(vars.static_node_count) という行を削除します。

      • id: a4-pool で、reservation_affinity ブロックを削除します。このブロックを次の行に置き換えます。

        • enable_flex_start: $(vars.enable_flex_start)
        • auto_repair: false
        • キューに登録されたプロビジョニングを有効にする場合は、次の行を追加します。
          • enable_queued_provisioning: $(vars.enable_queued_provisioning)
          • autoscaling_total_min_nodes: 0

      • id: workload-manager-install で、次のブロックを削除します。

         kueue:
    install: true
    config_path: $(vars.kueue_configuration_path)
    config_template_vars:
       num_gpus: $(a3-ultragpu-pool.static_gpu_count)
       accelerator_type: $(vars.accelerator_type)

        • キューに格納されたプロビジョニングでの Flex Start の場合は、次の操作を行います。

          1. vars ブロックに gpu_nominal_quota: NOMINAL_QUOTA を追加します。gpu_nominal_quota 値は、ClusterQueue 仕様の GPU の nominalQuota を設定するために使用されます（次の ClusterQueue を設定する手順をご覧ください）。この例では、GPU リクエストの合計が NOMINAL_QUOTA 値以下の場合にのみ、ClusterQueue がワークロードを許可します。ClusterQueue の詳細については、クラスタキューの Kueue ドキュメントをご覧ください。

          2. kueue ブロックを次のように更新します。

            kueue:
   install: true
   config_path: $(vars.kueue_configuration_path)
   config_template_vars:
      num_gpus: $(vars.gpu_nominal_quota)

          3. kueue-configuration.yaml.tftpl ファイルの内容を次のように置き換えます。

            apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
   name: "default-flavor"
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: AdmissionCheck
metadata:
   name: dws-prov
spec:
   controllerName: kueue.x-k8s.io/provisioning-request
   parameters:
      apiGroup: kueue.x-k8s.io
      kind: ProvisioningRequestConfig
      name: dws-config
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ProvisioningRequestConfig
metadata:
   name: dws-config
spec:
   provisioningClassName: queued-provisioning.gke.io
   managedResources:
   - nvidia.com/gpu
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
   name: "dws-cluster-queue"
spec:
   namespaceSelector: {}
   resourceGroups:
   - coveredResources: ["nvidia.com/gpu"]
      flavors:
      - name: "default-flavor"
      resources:
      - name: "nvidia.com/gpu"
         nominalQuota: ${num_gpus}
   admissionChecks:
   - dws-prov
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: LocalQueue
metadata:
   namespace: "default"
   name: "dws-local-queue"
spec:
   clusterQueue: "dws-cluster-queue"
---

      • id: job-template で、node_count 変数を 2 に置き換えます。

    スポット

    1. GitHub リポジトリの examples/gke-a4/gke-a4-deployment.yaml ブループリントで、terraform_backend_defaults セクションと vars セクションに次の設定を入力して、デプロイの特定の値と一致させます。

      • DEPLOYMENT_NAME: デプロイの一意の名前。長さは 6 ～ 30 文字にする必要があります。デプロイ名がプロジェクト内で一意でない場合、クラスタの作成は失敗します。デフォルト値は gke-a4 です。
      • BUCKET_NAME: 前の手順で作成した Cloud Storage バケットの名前。
      • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
      • COMPUTE_REGION: クラスタのコンピューティング リージョン。
      • COMPUTE_ZONE: A4 マシンのノードプールのコンピューティング ゾーン。
      • STATIC_NODE_COUNT: クラスタ内の A4 ノードの数。
      • IP_ADDRESS/SUFFIX: クラスタへの接続を許可する IP アドレス範囲。この CIDR ブロックには、Terraform の呼び出しに使用するマシンの IP アドレスを含める必要があります。詳細については、承認済みネットワークの仕組みをご覧ください。
      • reservation ブロック全体（reservation 行自体を含む）を spot: true に置き換えます。

      • システム ノードプールと A4 ノードプールの各ノードのブートディスク サイズを設定します。必要なディスクサイズはユースケースによって異なります。たとえば、ディスクをキャッシュとして使用して、イメージの繰り返し pull のレイテンシを短縮する場合は、フレームワーク、モデル、コンテナ イメージに対応するようにディスクサイズを大きく設定できます。

        • SYSTEM_NODE_POOL_DISK_SIZE_GB: システム ノードプールの各ノードのブートディスクのサイズ。最小ディスクサイズは 10 です。デフォルト値は 100 です。
        • A4_NODE_POOL_DISK_SIZE_GB: A4 ノードプールの各ノードのブートディスクのサイズ。最小ディスクサイズは 10 です。デフォルト値は 100 です。

    2. GitHub リポジトリの examples/gke-a4/gke-a4.yaml ブループリントで、次の変更を行います。

      • vars ブロックで、reservation ブロック全体（reservation 行自体を含む）を spot: true に置き換えます。

      • id: a4-pool で、reservation_affinity ブロックを削除します。このブロックを次の行に置き換えます。

        • spot: $(vars.spot)

  6. 必要に応じて、クラスタで Cluster Health Scanner（CHS）を有効にできます。CHS は、テストを実行してクラスタでワークロードを実行する準備ができていることを確認することで、GPU クラスタの健全性をチェックします。CHS を有効にするには、examples/gke-a4/gke-a4-deployment.yaml ファイルで次の変更を行います。

    • vars ブロックで、enable_periodic_health_checks フィールドを true に設定します。

    • デフォルトでは、ヘルスチェックは毎週日曜日の午前 12 時（太平洋標準時）に実行されます。この設定を変更する場合は、vars ブロックで、health_check_schedule フィールドを適切な値（cron 形式）に設定します。
      cron 形式のスケジュール: none * * * * * # | | | | | # | | | | day of the week (0-6) (Sunday to Saturday) # | | | month (1-12) # | | day of the month (1-31) # | hour (0-23) # minute (0-59)

  7. アプリケーションのデフォルト認証情報（ADC）を生成して、Terraform にアクセスできるようにします。Cloud Shell を使用している場合は、次のコマンドを実行します。

    gcloud auth application-default login

  8. ブループリントをデプロイして、A4 マシンタイプを使用して GKE インフラストラクチャをプロビジョニングします。

    cd ~/cluster-toolkit
./gcluster deploy -d \
examples/gke-a4/gke-a4-deployment.yaml \
examples/gke-a4/gke-a4.yaml

  9. プロンプトが表示されたら、[(A)pply] を選択してブループリントをデプロイします。

    • このブループリントは、VPC ネットワーク、GPU RDMA VPC ネットワーク、サービス アカウント、クラスタ、ノードプールを作成します。
    • ブループリントで fio-bench-job-template ジョブ テンプレートをサポートするために、Google Cloud バケット、ネットワーク ストレージ、永続ボリューム リソースが作成されます。

A3 Ultra

  1. Cloud Shell を起動します。別の環境を使用することもできますが、依存関係が Cluster Toolkit にすでにプリインストールされているため、Cloud Shell をおすすめします。Cloud Shell を使用しない場合は、依存関係をインストールするの手順に沿って別の環境を準備します。

  2. git リポジトリから Cluster Toolkit のクローンを作成します。

    cd ~
git clone https://github.com/GoogleCloudPlatform/cluster-toolkit.git

  3. Cluster Toolkit をインストールします。

    cd cluster-toolkit && git checkout main && make

  4. Terraform デプロイの状態を保存する Cloud Storage バケットを作成します。

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    次の変数を置き換えます。

    • BUCKET_NAME: 新しい Cloud Storage バケットの名前。
    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
    • COMPUTE_REGION_TERRAFORM_STATE: Terraform デプロイの状態を保存するコンピューティング リージョン。

  5. クラスタの作成に必要な編集ファイルは、デプロイで使用している使用オプションによって異なります。使用オプションのプロビジョニング モデルに対応するタブを選択します。

    予約で制限

    GitHub リポジトリの examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml ブループリントで、terraform_backend_defaults セクションと vars セクションの次の変数を、デプロイの特定の値と一致するように置き換えます。

    • DEPLOYMENT_NAME: デプロイの一意の名前。長さは 6～30 文字にする必要があります。デプロイ名がプロジェクト内で一意でない場合、クラスタの作成は失敗します。
    • BUCKET_NAME: 前の手順で作成した Cloud Storage バケットの名前。
    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
    • COMPUTE_REGION: クラスタのコンピューティング リージョン。
    • COMPUTE_ZONE: A3 Ultra マシンのノードプールのコンピューティング ゾーン。このゾーンは、予約に対して使用可能なマシンがあるゾーンと一致する必要があります。
    • NODE_COUNT: クラスタ内の A3 Ultra ノードの数。
    • IP_ADDRESS/SUFFIX: クラスタへの接続を許可する IP アドレス範囲。この CIDR ブロックには、Terraform の呼び出しに使用するマシンの IP アドレスを含める必要があります。詳細については、承認済みネットワークの仕組みをご覧ください。

    • reservation フィールドには、ノードプールのプロビジョニング時に、予約の特定のブロックをターゲットにするかどうかに応じて、次のいずれかを使用します。

      • ノードプールを予約の任意の場所に配置するには、予約の名前（RESERVATION_NAME）を指定します。

      • 予約の特定のブロックをターゲットにするには、予約名とブロック名を次の形式で使用します。

        RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      予約で使用可能なブロックが不明な場合は、予約トポロジを表示するをご覧ください。

    • システム ノードプールと A3 Ultra ノードプールの各ノードのブートディスク サイズを設定します。必要なディスクサイズはユースケースによって異なります。たとえば、ディスクをキャッシュとして使用して、イメージの繰り返し pull のレイテンシを短縮する場合は、フレームワーク、モデル、コンテナ イメージに対応するようにディスクサイズを大きく設定できます。

      • SYSTEM_NODE_POOL_DISK_SIZE_GB: システム ノードプールの各ノードのブートディスクのサイズ。最小ディスクサイズは 10 です。デフォルト値は 100 です。
      • A3ULTRA_NODE_POOL_DISK_SIZE_GB: A3 Ultra ノードプールの各ノードのブートディスクのサイズ。最小ディスクサイズは 10 です。デフォルト値は 100 です。

    詳細設定を変更するには、examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml を編集します。

    Flex Start

    1. GitHub リポジトリの examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml ブループリントで、terraform_backend_defaults セクションと vars セクションの次の変数を、デプロイの特定の値と一致するように置き換えます。

      • DEPLOYMENT_NAME: デプロイの一意の名前。長さは 6 ～ 30 文字にする必要があります。デプロイ名がプロジェクト内で一意でない場合、クラスタの作成は失敗します。
      • BUCKET_NAME: 前の手順で作成した Cloud Storage バケットの名前。
      • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
      • COMPUTE_REGION: クラスタのコンピューティング リージョン。
      • COMPUTE_ZONE: A3 Ultra マシンのノードプールのコンピューティング ゾーン。
      • static_node_count を削除します。
      • IP_ADDRESS/SUFFIX: クラスタへの接続を許可する IP アドレス範囲。この CIDR ブロックには、Terraform の呼び出しに使用するマシンの IP アドレスを含める必要があります。詳細については、承認済みネットワークの仕組みをご覧ください。
      • reservation フィールドを削除し、フィールドを enable_flex_start: true に置き換えます。キューに登録されたプロビジョニングも使用する場合は、次の行に enable_queued_provisioning: true を追加します。詳細については、キューに格納されたプロビジョニングでの Flex Start を使用するノードプールをご覧ください。

      • システム ノードプールと A3 Ultra ノードプールの各ノードのブートディスク サイズを設定します。必要なディスクサイズはユースケースによって異なります。たとえば、ディスクをキャッシュとして使用して、イメージの繰り返し pull のレイテンシを短縮する場合は、フレームワーク、モデル、コンテナ イメージに対応するようにディスクサイズを大きく設定できます。

        • SYSTEM_NODE_POOL_DISK_SIZE_GB: システム ノードプールの各ノードのブートディスクのサイズ。最小ディスクサイズは 10 です。デフォルト値は 100 です。
        • A3ULTRA_NODE_POOL_DISK_SIZE_GB: A3 Ultra ノードプールの各ノードのブートディスクのサイズ。最小ディスクサイズは 10 です。デフォルト値は 100 です。

    2. GitHub リポジトリの examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml ブループリントで、次の変更を行います。

      • vars ブロックで static_node_count を削除します。
      • vars ブロックで、version_prefix の数値を "1.32." 以上に更新します。GKE で Flex Start を使用するには、クラスタでバージョン 1.32.2-gke.1652000 以降を使用する必要があります。
      • vars ブロックで、reservation ブロック全体（reservation 行自体を含む）を enable_flex_start: true に置き換えます。必要に応じて、enable_queued_provisioning: true に置き換えます。
      • vars ブロックで、kueue_configuration_path: $(ghpc_stage("./kueue-configuration.yaml.tftpl")) の行を削除します。
      • id: a3-ultragpu-pool で、static_node_count: $(vars.static_node_count) という行を削除します。

      • id: a3-ultragpu-pool で、reservation_affinity ブロックを削除します。このブロックを次の行に置き換えます。

        • enable_flex_start: $(vars.enable_flex_start)
        • auto_repair: false
        • キューに登録されたプロビジョニングを有効にする場合は、次の行を追加します。
          • enable_queued_provisioning: $(vars.enable_queued_provisioning)
          • autoscaling_total_min_nodes: 0

      • id: workload-manager-install で、次のブロックを削除します。

        config_path: $(vars.kueue_configuration_path)
config_template_vars:
  num_gpus: $(a4-pool.static_gpu_count)
  accelerator_type: $(vars.accelerator_type)

        • キューに格納されたプロビジョニングの Flex Start では、次の 3 つの手順を行います。

          1. vars ブロックに gpu_nominal_quota: NOMINAL_QUOTA を追加します。gpu_nominal_quota 値は、ClusterQueue 仕様で GPU の nominalQuota を設定するために使用されます。この例では、GPU リクエストの合計が NOMINAL_QUOTA 値以下の場合にのみ、ClusterQueue はワークロードを許可します。ClusterQueue の詳細については、クラスタキューの Kueue ドキュメントをご覧ください。

          2. kueue ブロックを次のように更新します。

            kueue:
   install: true
   config_path: $(vars.kueue_configuration_path)
   config_template_vars:
      num_gpus: $(vars.gpu_nominal_quota)

          3. kueue-configuration.yaml.tftpl ファイルの内容を次のように置き換えます。

            apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
   name: "default-flavor"
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: AdmissionCheck
metadata:
   name: dws-prov
spec:
   controllerName: kueue.x-k8s.io/provisioning-request
   parameters:
      apiGroup: kueue.x-k8s.io
      kind: ProvisioningRequestConfig
      name: dws-config
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ProvisioningRequestConfig
metadata:
   name: dws-config
spec:
   provisioningClassName: queued-provisioning.gke.io
   managedResources:
   - nvidia.com/gpu
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
   name: "dws-cluster-queue"
spec:
   namespaceSelector: {}
   resourceGroups:
   - coveredResources: ["nvidia.com/gpu"]
      flavors:
      - name: "default-flavor"
      resources:
      - name: "nvidia.com/gpu"
         nominalQuota: ${num_gpus}
   admissionChecks:
   - dws-prov
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: LocalQueue
metadata:
   namespace: "default"
   name: "dws-local-queue"
spec:
   clusterQueue: "dws-cluster-queue"
---

        • id: job-template フィールドで、node_count 変数を 2 に置き換えます。

    スポット

    1. GitHub リポジトリの examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml ブループリントで、terraform_backend_defaults セクションと vars セクションに次の設定を入力して、デプロイの特定の値と一致させます。

      • DEPLOYMENT_NAME: デプロイの一意の名前。長さは 6 ～ 30 文字にする必要があります。デプロイ名がプロジェクト内で一意でない場合、クラスタの作成は失敗します。
      • BUCKET_NAME: 前の手順で作成した Cloud Storage バケットの名前。
      • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
      • COMPUTE_REGION: クラスタのコンピューティング リージョン。
      • COMPUTE_ZONE: A3 Ultra マシンのノードプールのコンピューティング ゾーン。
      • STATIC_NODE_COUNT: クラスタ内の A3 Ultra ノードの数。
      • IP_ADDRESS/SUFFIX: クラスタへの接続を許可する IP アドレス範囲。この CIDR ブロックには、Terraform の呼び出しに使用するマシンの IP アドレスを含める必要があります。詳細については、承認済みネットワークの仕組みをご覧ください。
      • reservation ブロック全体（reservation 行自体を含む）を spot: true に置き換えます。

      • システム ノードプールと A3 Ultra ノードプールの各ノードのブートディスク サイズを設定します。必要なディスクサイズはユースケースによって異なります。たとえば、ディスクをキャッシュとして使用して、イメージの繰り返し pull のレイテンシを短縮する場合は、フレームワーク、モデル、コンテナ イメージに対応するようにディスクサイズを大きく設定できます。

        • SYSTEM_NODE_POOL_DISK_SIZE_GB: システム ノードプールの各ノードのブートディスクのサイズ。最小ディスクサイズは 10 です。デフォルト値は 100 です。
        • A3ULTRA_NODE_POOL_DISK_SIZE_GB: A3 Ultra ノードプールの各ノードのブートディスクのサイズ。最小ディスクサイズは 10 です。デフォルト値は 100 です。

    2. GitHub リポジトリの examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml ブループリントで、次の変更を行います。

      • vars ブロックで、reservation ブロック全体（reservation 行自体を含む）を spot: true に置き換えます。

      • id: a3-ultragpu-pool で、reservation_affinity ブロックを削除します。このブロックを次の行に置き換えます。

        • spot: $(vars.spot)

  6. 必要に応じて、クラスタで Cluster Health Scanner（CHS）を有効にできます。CHS は、テストを実行してクラスタでワークロードを実行する準備ができていることを確認することで、GPU クラスタの健全性をチェックします。CHS を有効にするには、examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml ファイルで次の変更を行います。

    • vars ブロックで、enable_periodic_health_checks フィールドを true に設定します。

    • デフォルトでは、ヘルスチェックは毎週日曜日の午前 12 時（太平洋標準時）に実行されます。この設定を変更する場合は、vars ブロックで、health_check_schedule フィールドを適切な値（cron 形式）に設定します。
      cron 形式のスケジュール: none * * * * * # | | | | | # | | | | day of the week (0-6) (Sunday to Saturday) # | | | month (1-12) # | | day of the month (1-31) # | hour (0-23) # minute (0-59)

  7. アプリケーションのデフォルト認証情報（ADC）を生成して、Terraform にアクセスできるようにします。Cloud Shell を使用している場合は、次のコマンドを実行します。

    gcloud auth application-default login

  8. ブループリントをデプロイして、A3 Ultra マシンタイプを使用して GKE インフラストラクチャをプロビジョニングします。

    cd ~/cluster-toolkit
./gcluster deploy -d \
examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml \
examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml

  9. プロンプトが表示されたら、[(A)pply] を選択してブループリントをデプロイします。

    • このブループリントは、VPC ネットワーク、GPU RDMA VPC ネットワーク、サービス アカウント、クラスタ、ノードプールを作成します。
    • ブループリントで fio-bench-job-template ジョブ テンプレートをサポートするために、Google Cloud バケット、ネットワーク ストレージ、永続ボリューム リソースが作成されます。

XPK を使用してクラスタを作成し、ワークロードを実行する

Accelerated Processing Kit（XPK）を使用すると、クラスタをすばやくプロビジョニングして利用できます。XPK は、ワークロードの実行が主な目的の場合に最適な、事前構成されたトレーニングに最適化されたインフラストラクチャを生成します。

XPK を使用してクラスタを作成し、A3 Ultra VM でワークロードを実行します。

  1. XPK の前提条件を満たすために、必要なツールをインストールします。
  2. XPK の最新のタグ付きリリースのバージョン番号（「v0.8.0」など）をコピーします。次のコマンドで、XPK_TAG を最新の XPK バージョン番号に置き換えます。

  3. Linux マシンでシェル ウィンドウを開き、次のコマンドを入力して、Git リポジトリから XPK のクローンを作成し、必要なパッケージをインストールします。

      ## Setup virtual environment.
  VENV_DIR=~/venvp3
  python3 -m venv $VENV_DIR
  source $VENV_DIR/bin/activate
  ## Clone the repository.
  git clone --branch XPK_TAG https://github.com/google/xpk.git
  cd xpk
  ## Install required packages
  make install && export PATH=$PATH:$PWD/bin

  4. A3 Ultra VM を使用して Standard クラスタを作成します。予約済み容量を使用してクラスタのノードをプロビジョニングできます。

      python3 xpk.py cluster create \
     --cluster=CLUSTER_NAME \
     --device-type=h200-141gb-8 \
     --zone=COMPUTE_ZONE  \
     --project=PROJECT_ID \
     --num-nodes=NUM_NODES \
     --reservation=RESERVATION_NAME

    次の変数を置き換えます。

    • CLUSTER_NAME: クラスタの名前。
    • COMPUTE_ZONE: A3 Ultra マシンのノードプールのコンピューティング ゾーン。予約済み容量を使用するには、容量を予約したゾーンを使用していることを確認してください。通常は、レイテンシを最小限に抑えるために、ユーザーに近いゾーンを選択することをおすすめします。
    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
    • NUM_NODES: ノードプール内のワーカーノードの数。

    • RESERVATION_NAME: 予約の名前。

      XPK には、限定公開クラスタの作成、Vertex AI Tensorboard の作成、ノードの自動プロビジョニングの使用など、クラスタ作成用の追加の引数が用意されています。詳細については、XPK のクラスタ作成ガイドをご覧ください。

  5. クラスタが正常に作成されたことを確認します。

      python3 xpk.py cluster list --zone=COMPUTE_ZONE --project=PROJECT_ID

  6. 省略可: ワークロードを実行してクラスタ環境をテストします。

      python3 xpk.py workload create \
     --workload WORKLOAD_NAME --command "echo goodbye" \
     --cluster CLUSTER_NAME \
     --device-type=h200-141gb-8 \
     --num-nodes=WORKLOAD_NUM_NODES \
     --zone=COMPUTE_ZONE \
     --project=PROJECT_ID

    次の変数を置き換えます。

    • WORKLOAD_NAME: ワークロードの名前。
    • CLUSTER_NAME: クラスタの名前。
    • WORKLOAD_NUM_NODES: ワークロードの実行に使用されるワーカーノードの数。
    • COMPUTE_ZONE: A3 Ultra マシンのノードプールのコンピューティング ゾーン。
    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。

ネットワーク パフォーマンスをテストする

プロビジョニングされたクラスタの機能を検証することをおすすめします。これを行うには、Google 環境向けに最適化された NVIDIA Collective Communications Library（NCCL）テストである NCCL/gIB テストを使用します。

再現可能なベンチマークを実行する

GKE の A4 VM と A3 Ultra VM で、大規模な ML オープンモデルの事前トレーニング ベンチマークを再現できます。

各レシピには、次のタスクを完了するための手順が記載されています。

  • 環境を準備します。
  • ベンチマークを実行します。
  • ベンチマークの結果を分析します。これには、ベンチマーク結果と、詳細な分析のためのログが含まれます。

使用可能なすべてのレシピを表示するには、GPU レシピの GitHub リポジトリをご覧ください。

モデル フレームワーク レシピ
Llama-3.1-70B MaxText 32 ノードのワークロード
Llama-3.1-70B NeMo 32 ノードのワークロード
Mixtral-8-7B NeMo 32 ノードのワークロード

Cluster Toolkit で作成されたリソースをクリーンアップする

このページで使用したリソースの課金が繰り返されないようにするには、Cluster Toolkit によってプロビジョニングされたリソース（VPC ネットワークや GKE クラスタなど）をクリーンアップします。

   cd ~/cluster-toolkit
   ./gcluster destroy CLUSTER_NAME/

CLUSTER_NAME は、使用するクラスタの名前に置き換えます。Cluster Toolkit で作成されたクラスタの場合、クラスタ名は DEPLOYMENT_NAME に基づいています。

次のステップ