A4X を使用するカスタム AI 最適化 GKE クラスタを作成する

このページでは、A4X 仮想マシン（VM）を使用して AI と ML のワークロードをサポートする AI 最適化 Google Kubernetes Engine（GKE）クラスタを作成する方法について説明します。A4X の詳細については、A4X シリーズをご覧ください。

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

GKE は、組織の多様なワークロードを実行するための単一のプラットフォームサーフェスを提供し、複数のプラットフォームを管理する運用上の負担を軽減します。高性能な分散型事前トレーニング、モデルのファインチューニング、モデルの推論、アプリケーションのサービング、サポートサービスなどのワークロードを実行できます。

このページでは、ワークロードのニーズに基づいてクラスタを構成する際に最大限の柔軟性を確保するために、Google Cloud CLI を使用して GKE クラスタを作成する方法について説明します。または、Cluster Toolkit を使用して、多くのユースケースのベストプラクティスを反映したデフォルト設定でクラスタを迅速にデプロイすることもできます。

詳細については、デフォルト構成で AI に最適化された GKE クラスタを作成するをご覧ください。
A4 または A3 Ultra を使用するクラスタを作成するには、A4 または A3 Ultra を使用する AI によって最適化されたカスタム GKE クラスタを作成するをご覧ください。

GPUDirect RDMA を使用したクラスタ構成オプション

Google Cloud CLI を使用してクラスタを作成するには、次のクラスタ構成オプションのいずれかを選択します。

分散 AI ワークロードを実行する予定がある場合: このページの手順に沿って、GPUDirect RDMA を使用して GKE クラスタを作成します。
分散 AI ワークロードを実行する予定がない場合: GPUDirect RDMA を使用せずに GKE クラスタを作成します。詳細については、GPUDirect RDMA を使用しないクラスタを作成するをご覧ください。

始める前に

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

Google Kubernetes Engine API を有効にする。

Google Kubernetes Engine API を有効化

このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。gcloud CLI をインストール済みの場合は、gcloud components update コマンドを実行して最新のバージョンを取得します。以前のバージョンの gcloud CLI では、このドキュメントのコマンドを実行できない場合があります。
注: gcloud CLI がすでにインストールされている場合には、必ず compute/region プロパティを設定してください。主にゾーンクラスタを使用する場合は、代わりに compute/zone を設定します。デフォルトのロケーションを設定することで、gcloud CLI のエラー（One of [--zone, --region] must be supplied: Please specify location など）を防止できます。クラスタのロケーションが設定したデフォルトと異なる場合は、特定のコマンドでロケーションの指定が必要になることがあります。

必要なロール

GKE クラスタの作成と管理に必要な権限を取得するには、プロジェクトに対する次の IAM ロールの付与を管理者に依頼してください。

Kubernetes Engine 管理者（roles/container.admin）
Cloud Build 編集者（roles/cloudbuild.builds.editor）
Compute 管理者（roles/compute.admin）
プロジェクト IAM 管理者（roles/resourcemanager.projectIamAdmin）
サービスアカウント管理者（roles/iam.serviceAccountAdmin）
サービスアカウントユーザー（roles/iam.serviceAccountUser）
Service Usage ユーザー（roles/serviceusage.serviceUsageConsumer）
ストレージ管理者（roles/storage.admin）

ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。

必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。

容量を取得する

A4X VM の容量は、将来の予約を作成することで取得できます。将来の予約の詳細については、使用オプションを選択するの表の AI Hypercomputer の将来の予約列をご覧ください。

将来の予約で容量を取得するには、容量を取得する方法の表の AI Hypercomputer の将来の予約の行をご覧ください。

要件

A4X VM を使用する 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 のネットワーキング機能を使用できるようにするために有効にすることをおすすめします。
GKE ノードで Container-Optimized OS ノードイメージが使用されている必要があります。Ubuntu と Windows のノードイメージはサポートされません。
GKE ワークロードでは、使用可能なすべての GPU を使用し、Pod では単一の GKE ノードで使用可能なすべてのセカンダリ NIC を使用する必要があります。複数の Pod が単一の GKE ノードで RDMA を共有することはできません。
この設定では、NCCL テストが実行されます。この NCCL テストを実行するには、最小 VM 割り当てが 2（a4x-highgpu-4g または a4x-highgpu-4g-nolssd を使用する場合はそれぞれ 4 個の GPU）である必要があります。
A4X を使用してクラスタを作成するには、予約バインドプロビジョニングモデルを使用する必要があります。他のプロビジョニングモデルはサポートされていません。
GPUDirect RDMA は、NCCL Fast Socket または GPUDirect TCPX/TCPXO と互換性がありません。GPUDirect RDMA を使用するクラスタで、NCCL Fast Socket を有効にしたり、TCPX/TCPXO プラグインをインストールしたりしないでください。

クラスタの作成に関する考慮事項

クラスタを作成する際は、次の情報を考慮してください。

クラスタのロケーションを選択する:
- 選択したマシンタイプが使用可能なロケーションを使用していることを確認します。詳細については、GPU のロケーションをご覧ください。
- 高密度予約の場合は、ゾーンクラスタを作成できます。この場合は、--region フラグを --zone=COMPUTE_ZONE フラグに置き換えます。ここで、COMPUTE_ZONE はコントロールプレーンのゾーンです。
- リージョンクラスタでノードプールを作成するときに、--node-locations フラグを使用して GKE ノードのゾーンを指定できます。
ドライバのバージョンを選択する:
- ドライバのバージョンは、次のいずれかの値になります。
  - default: GKE ノードバージョンのデフォルトのドライババージョンをインストールします。デフォルトのドライババージョンの要件について詳しくは、要件セクションをご覧ください。
  - latest: GKE バージョンに対応する最新のドライババージョンをインストールします。このオプションは、Container-Optimized OS を使用するノードでのみ使用できます。
  - disabled: ドライバの自動インストールをスキップします。ノードプールの作成後に、手動でドライバをインストールする必要があります。
- GKE ノードバージョンのデフォルトの GPU ドライババージョンと最新の GPU ドライババージョンの詳細については、NVIDIA GPU ドライバを手動でインストールするのセクションの表をご覧ください。
予約アフィニティを選択する:
- 予約の名前や予約内の特定のブロックの名前など、予約に関する情報を確認できます。これらの値を確認するには、将来の予約リクエストを表示するをご覧ください。
- --reservation-affinity フラグは、specific または any の値を取ることができます。ただし、高パフォーマンスの分散 AI ワークロードには、特定の予約を使用することをおすすめします。
- 共有予約などの特定の予約を使用する場合は、--reservation フラグの値を次の形式で指定します。
```
projects/PROJECT_ID/reservations/RESERVATION_NAME/reservationBlocks/BLOCK_NAME
```
  次の値を置き換えます。
  - PROJECT_ID: 実際の Google Cloud プロジェクト ID。
  - RESERVATION_NAME: 予約の名前。
  - BLOCK_NAME: 予約内の特定のブロックの名前。
  VM が BLOCK_NAME 内の単一のサブブロックに配置されるように、サブブロックをターゲットとする予約を使用するには、パスの末尾に次の内容を追加します。
```
/reservationSubBlocks/SUB_BLOCK_NAME
```
  SUB_BLOCK_NAME は、サブブロックの名前に置き換えます。
ヒント: 予約が現在のプロジェクトに存在する場合は、予約値の projects/PROJECT_ID/reservations/ を省略できます。

A4X と GPUDirect RDMA を使用する AI 最適化 GKE クラスタを作成する

分散 AI ワークロードの場合、複数の GPU ノードがリンクされて 1 台のコンピュータとして動作することがよくあります。A4X は、NVIDIA GB200 NVL72 ラックスケールアーキテクチャに基づくエクサスケールプラットフォームです。このマシンタイプは、AI ワークロードに高性能なクラウドエクスペリエンスを提供することで、複数の GPU 間でのスケーリングとコラボレーションを可能にします。ネットワーク帯域幅や NIC の配置など、A4X のネットワークアーキテクチャの詳細については、A4X マシンタイプをご覧ください。

A4X と GPUDirect RDMA を使用して GKE Standard クラスタを作成するには、次の手順を行います。これらの手順については、次のセクションで説明します。

VPC とサブネットを作成する
マルチネットワーキングを使用して GKE クラスタを作成する
GKE ネットワークオブジェクトを作成する
ワークロードポリシーを作成する
A4X を使用してノードプールを作成する
RDMA バイナリをインストールして NCCL を構成する
NVIDIA コンピューティングドメイン CRD と DRA ドライバをインストールする

VPC とサブネットを作成する

A4X VM の構成は次のとおりです。

NVLink で接続された仮想マシンあたり 4 個の NVIDIA B200 GPU
2 つの Arm ベースの NVIDIA Grace CPU
GPU 間ネットワーキング用の 4 つの 400 Gbps CX-7 ネットワークインターフェースカード（NIC）
外部サービス用の 2 つの 200 Gbps Google Titanium ネットワークインターフェースカード（NIC）

分散トレーニングなどの AI ワークロードと ML ワークロードでは、ジョブの完了時間を短縮してパフォーマンスを最適化するために、強力なアクセラレーションが必要となります。高性能、高スループット、低レイテンシを必要とするワークロードの場合、GPUDirect RDMA は、ペイロードを GPU との間で転送するために必要なネットワークホップを削減します。このアプローチでは、利用可能なネットワーク帯域幅をより効率的に使用します。

CPU に関連付けられている Google Titanium NIC の 1 つは GKE のデフォルトネットワークを使用するため、デフォルトネットワークに十分な IP アドレス範囲がある限り、この NIC 用に新しい VPC を作成する必要はありません。

次のコマンドを使用して、2 番目の CPU Titanium NIC（gVNIC）用に 1 つの VPC を作成し、4 つの CX-7 RDMA NIC 用に別の VPC を作成できます。

ネットワーク帯域幅を最大化するため、追加の GVNIC の VPC を作成するコマンドでは、最大伝送単位（MTU）が 8896 に設定されます。RDMA VPC のデフォルトは、推奨設定の 8896 です。詳細については、MTU 設定と GPU マシンタイプをご覧ください。

デプロイに合わせて環境変数を設定します。
```
export REGION="COMPUTE_REGION"
export ZONE="COMPUTE_ZONE"
export PROJECT="PROJECT_ID"
export GVNIC_NETWORK_PREFIX="GVNIC_NETWORK_PREFIX"
export RDMA_NETWORK_PREFIX="RDMA_NETWORK_PREFIX"
```
次の変数を置き換えます。
- COMPUTE_REGION: クラスタのリージョン。
- COMPUTE_ZONE: ノードプールのゾーン。
- PROJECT_ID: 実際の Google Cloud プロジェクト ID。
- GVNIC_NETWORK_PREFIX: GVNIC ネットワークの接頭辞（例: a4x-gvnic）。
- RDMA_NETWORK_PREFIX: RDMA ネットワークの接頭辞（例: a4x-rdma）。

2 つの VPC ネットワークを作成します。

# Create a VPC for the additional GVNIC
gcloud compute --project=${PROJECT} \
  networks create \
  GVNIC_NETWORK_PREFIX-net \
  --subnet-mode=custom \
  --mtu=8896

gcloud compute --project=${PROJECT} \
  networks subnets create \
  GVNIC_NETWORK_PREFIX-sub \
  --network=GVNIC_NETWORK_PREFIX-net \
  --region=${REGION} \
  --range=192.168.0.0/24

gcloud compute --project=${PROJECT} \
  firewall-rules create \
  GVNIC_NETWORK_PREFIX-internal \
  --network=GVNIC_NETWORK_PREFIX-net \
  --action=ALLOW \
  --rules=tcp:0-65535,udp:0-65535,icmp \
  --source-ranges=192.168.0.0/16

# Create HPC VPC for the RDMA NICs with 4 subnets.
gcloud compute --project=${PROJECT} \
  networks create RDMA_NETWORK_PREFIX-net \
  --network-profile=${ZONE}-vpc-roce \
  --subnet-mode=custom

# Create subnets for the HPC VPC.
for N in $(seq 0 3); do
  gcloud compute --project=${PROJECT} \
    networks subnets create \
    RDMA_NETWORK_PREFIX-sub-$N \
    --network=RDMA_NETWORK_PREFIX-net \
    --region=${REGION} \
    --range=192.168.$((N+1)).0/24 &  # offset to avoid overlap with gvnics
done

マルチネットワーキングを使用して GKE クラスタを作成する

マルチネットワーキングを使用して GKE Standard クラスタを作成します。
```
gcloud container clusters create CLUSTER_NAME \
    --enable-dataplane-v2 --enable-ip-alias --location=COMPUTE_REGION \
    --enable-multi-networking --cluster-version=CLUSTER_VERSION \
    --enable-kubernetes-unstable-apis=resource.k8s.io/v1beta1/deviceclasses,resource.k8s.io/v1beta1/resourceclaims,resource.k8s.io/v1beta1/resourceclaimtemplates,resource.k8s.io/v1beta1/resourceslices \
    [--services-ipv4-cidr=SERVICE_CIDR \
    --cluster-ipv4-cidr=POD_CIDR]
```
このコマンドを準備するときは、次の操作を行います。
- GKE バージョン 1.34 以降を実行するクラスタを作成する場合は、DRA の有効化に使用される --enable-kubernetes-unstable-apis フラグを削除します。このフラグは、バージョン 1.32 または 1.33 を実行するクラスタを作成する場合にのみ必要です。ベータ版 API を有効にした場合は、ベータ版 API が非推奨になり、以降の Kubernetes マイナーバージョンで削除されたときに、ベータ版 API から移行する必要があります。詳細については、ベータ版 API の非推奨をご覧ください。
- 次のように置き換えます。
  - CLUSTER_NAME: クラスタの名前。
  - CLUSTER_VERSION: 新しいクラスタのバージョン。構成をサポートする GKE のバージョンについては、このドキュメントの要件をご覧ください。
  - COMPUTE_REGION: コンピューティングリージョンの名前。
- 必要に応じて、サービスと Pod のセカンダリ CIDR 範囲を明示的に指定できます。これらのオプションフラグを使用する場合は、次の変数を置き換えます。
  - SERVICE_CIDR: Service のセカンダリ CIDR の範囲。
  - POD_CIDR: Pod のセカンダリ CIDR の範囲。
  これらのフラグを使用する場合は、CIDR の範囲が追加のノードネットワークのサブネット範囲と重複してないことを確認する必要があります。たとえば、SERVICE_CIDR=10.65.0.0/19 と POD_CIDR=10.64.0.0/19 を考えてみましょう。詳細については、Pod の IPv4 アドレス範囲を追加するをご覧ください。

GKE ネットワークオブジェクトを作成する

前のセクションで作成した VPC ネットワークは、GKE ネットワークパラメータセットを使用して構成する必要があります。具体的には、2 番目の CPU Titanium NIC（gVNIC）を NetDevice モードで構成し、4 つの CX-7 RDMA NIC をそれぞれ RDMA モードで構成する必要があります。

このコマンドでは、次の名前を使用します。

CPU Titanium NIC（gVNIC）VPC の名前は GVNIC_NETWORK_PREFIX-net で、サブネットの名前は GVNIC_NETWORK_PREFIX-sub です。
CX-7 RDMA NIC の VPC の名前は RDMA_NETWORK_PREFIX-net で、サブネットの名前は RDMA_NETWORK_PREFIX-sub-[0…3] です。

次のコマンドを実行して、GKE ネットワークオブジェクトを作成します。

kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: gvnic-1
spec:
  vpc: GVNIC_NETWORK_PREFIX-net
  vpcSubnet: GVNIC_NETWORK_PREFIX-sub
  deviceMode: NetDevice
---
apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: gvnic-1
spec:
  type: "Device"
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: gvnic-1
---
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: rdma-0
spec:
  vpc: RDMA_NETWORK_PREFIX-net
  vpcSubnet: RDMA_NETWORK_PREFIX-sub-0
  deviceMode: RDMA
---
apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: rdma-0
spec:
  type: "Device"
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: rdma-0
---
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: rdma-1
spec:
  vpc: RDMA_NETWORK_PREFIX-net
  vpcSubnet: RDMA_NETWORK_PREFIX-sub-1
  deviceMode: RDMA
---
apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: rdma-1
spec:
  type: "Device"
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: rdma-1
---
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: rdma-2
spec:
  vpc: RDMA_NETWORK_PREFIX-net
  vpcSubnet: RDMA_NETWORK_PREFIX-sub-2
  deviceMode: RDMA
---
apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: rdma-2
spec:
  type: "Device"
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: rdma-2
---
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: rdma-3
spec:
  vpc: RDMA_NETWORK_PREFIX-net
  vpcSubnet: RDMA_NETWORK_PREFIX-sub-3
  deviceMode: RDMA
---
apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: rdma-3
spec:
  type: "Device"
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: rdma-3
EOF

ワークロードポリシーの作成

パーティションを作成するには、ワークロードポリシーが必要です。詳細については、MIG のワークロードポリシーをご覧ください。

accelerator_topology フィールドが 1x72 に設定された HIGH_THROUGHPUT ワークロードポリシーを作成します。

gcloud beta compute resource-policies create workload-policy WORKLOAD_POLICY_NAME \
    --type HIGH_THROUGHPUT \
    --accelerator-topology 1x72 \
    --project PROJECT \
    --region COMPUTE_REGION

次のように置き換えます。

WORKLOAD_POLICY_NAME: ワークロードポリシーの名前。
PROJECT: プロジェクトの名前。
COMPUTE_REGION: コンピューティングリージョンの名前。

A4X を使用してノードプールを作成する

GKE GPU デバイスプラグインを使用するノードプールを作成することをおすすめします。このプラグインは、GKE 管理の GPU リソース管理を提供します。このアプローチには次のメリットがあります。

導入とアップグレードの容易さ
ドライバの自動インストール
GKE で管理される GPU 機能（指標やパーティショニングされた GPU など）
重要なセキュリティの脆弱性の修正

ユースケースで必要な場合は、NVIDIA GPU Operator を使用することもできます。詳細については、NVIDIA GPU Operator を使用する理由をご覧ください。

GKE GPU デバイスプラグインを使用して A4X ノードプールを作成する

GKE GPU デバイスプラグインを使用する A4X ノードプールを作成します。

gcloud container node-pools create NODE_POOL_NAME \
    --location COMPUTE_REGION \
    --node-locations COMPUTE_ZONE \
    --cluster CLUSTER_NAME \
    --num-nodes=NODE_COUNT \
    --machine-type MACHINE_TYPE \
    --accelerator type=nvidia-gb200,count=4,gpu-driver-version=DRIVER_VERSION \
    --additional-node-network network=GVNIC_NETWORK_PREFIX-net,subnetwork=GVNIC_NETWORK_PREFIX-sub \
    --additional-node-network network=RDMA_NETWORK_PREFIX-net,subnetwork=RDMA_NETWORK_PREFIX-sub-0 \
    --additional-node-network network=RDMA_NETWORK_PREFIX-net,subnetwork=RDMA_NETWORK_PREFIX-sub-1 \
    --additional-node-network network=RDMA_NETWORK_PREFIX-net,subnetwork=RDMA_NETWORK_PREFIX-sub-2 \
    --additional-node-network network=RDMA_NETWORK_PREFIX-net,subnetwork=RDMA_NETWORK_PREFIX-sub-3 \
    --scopes "https://www.googleapis.com/auth/cloud-platform" \
    --reservation-affinity=specific \
    --reservation=RESERVATION_NAME/reservationBlocks/BLOCK_NAME \
    --placement-policy=WORKLOAD_POLICY_NAME

次のように置き換えます。

NODE_POOL_NAME: ノードプールの名前。
COMPUTE_REGION: クラスタのリージョン。
COMPUTE_ZONE: ノードプールのゾーン。
CLUSTER_NAME: クラスタの名前。
NODE_COUNT: ノードプールのノード数。18 個以下のノードにする必要があります。NVLink ドメインを使用して 1 つのサブブロックで 1x72 の GPU トポロジを取得するには、18 個のノードを使用することをおすすめします。
MACHINE_TYPE: ローカル SSD が必要な場合は a4x-highgpu-4g、不要な場合は a4x-highgpu-4g-nolssd。
DRIVER_VERSION: インストールする NVIDIA ドライバのバージョン。default、latest、disabled のいずれかの値になります。
RESERVATION_NAME: 予約の名前。この値を確認するには、将来の予約リクエストを表示するをご覧ください。
BLOCK_NAME: 予約内の特定のブロックの名前。この値を確認するには、将来の予約リクエストを表示するをご覧ください。
WORKLOAD_POLICY_NAME: 以前に作成したワークロードポリシーの名前。

NVIDIA GPU Operator を使用して A4X ノードプールを作成する

または、NVIDIA GPU Operator を使用するには、次の操作を行います。

前のセクションの gcloud container node-pools create コマンドを次のように変更して実行します。
- gpu-driver-version=latest を gpu-driver-version=disabled に変更します。この変更により、NVIDIA GPU Operator を使用する場合はサポートされていないため、GPU ドライバの自動インストールがスキップされます。
- --node-labels="gke-no-default-nvidia-gpu-device-plugin=true" を設定して、GKE 管理の GPU デバイスプラグインの DaemonSet を無効にします。
GKE GPU ドライバインストーラ DaemonSet マニフェストを適用します。このマニフェストは、各 A4X ノードに GPU ドライバインストーラ Pod をデプロイします。
```
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/refs/heads/master/nvidia-driver-installer/cos/daemonset-preloaded.yaml
```

Google Kubernetes Engine（GKE）で NVIDIA GPU Operator を使用して GPU スタックを管理する:

GPU ノードプールを作成して設定するセクションで、認証情報を取得する手順から始まる手順に沿って操作します。

NVIDIA GPU Operator をインストールします。すべての手順を完了しますが、Helm を使用して NVIDIA GPU Operator をインストールする参照セクションのコマンドを置き換えます。代わりに、次のコマンドを使用します。

helm install --wait --generate-name \
  -n gpu-operator \
  nvidia/gpu-operator \
  --version="25.3.0" \
  -f <(cat <<EOF
hostPaths:
  driverInstallDir: /home/kubernetes/bin/nvidia
toolkit:
  installDir: /home/kubernetes/bin/nvidia
cdi:
  enabled: true
  default: true
driver:
  enabled: false

daemonsets:
  tolerations:
    - key: nvidia.com/gpu
      operator: Equal
      value: present
      effect: NoSchedule
    - key: kubernetes.io/arch
      operator: Equal
      value: arm64
      effect: NoSchedule

node-feature-discovery:
  worker:
    tolerations:
      - key: kubernetes.io/arch
        operator: Equal
        value: arm64
        effect: NoSchedule
      - key: "node-role.kubernetes.io/master"
        operator: "Equal"
        value: ""
        effect: "NoSchedule"
      - key: "node-role.kubernetes.io/control-plane"
        operator: "Equal"
        value: ""
        effect: "NoSchedule"
      - key: nvidia.com/gpu
        operator: Exists
        effect: NoSchedule
EOF
)

RDMA バイナリをインストールして NCCL を構成する

次の DaemonSet を適用して、各ノードに RDMA バイナリと NCCL ライブラリをインストールします。基盤となる各 VM に、RDMA バイナリは /home/kubernetes/bin/gib ディレクトリにインストールされ、NCCL ライブラリは /home/kubernetes/bin/nvidia/lib64 ディレクトリにインストールされます。

  kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/gpudirect-rdma/nccl-rdma-installer-a4x.yaml

NVIDIA コンピューティングドメイン CRD と DRA ドライバをインストールする

NVIDIA コンピューティングドメイン CRD と DRA ドライバをインストールします。詳細については、GPU 用の NVIDIA DRA ドライバをご覧ください。

開発環境に Helm がインストールされていることを確認します。Helm は Cloud Shell に事前にインストールされています。

特定の Helm バージョンの要件はありません。次のコマンドを使用すると、Helm がインストールされていることを確認できます。
```
helm version
```
出力が Command helm not found のようになる場合は、次のコマンドを実行して Helm CLI をインストールできます。
```
curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 \
  && chmod 700 get_helm.sh \
  && ./get_helm.sh
```

NVIDIA Helm リポジトリを追加します。

helm repo add nvidia https://helm.ngc.nvidia.com/nvidia \
  && helm repo update

DRA ドライバの ResourceQuota を作成します。

export POD_QUOTA=POD_QUOTA

kubectl create ns nvidia-dra-driver-gpu

kubectl apply -n nvidia-dra-driver-gpu -f - << EOF
apiVersion: v1
kind: ResourceQuota
metadata:
  name: nvidia-dra-driver-gpu-quota
spec:
  hard:
    pods: ${POD_QUOTA}
  scopeSelector:
    matchExpressions:
    - operator: In
      scopeName: PriorityClass
      values:
        - system-node-critical
        - system-cluster-critical
EOF

POD_QUOTA は、クラスタ内の A4X ノード数の 2 倍に 1 を加えた数以上に置き換えます。たとえば、クラスタに 18 個の A4X ノードがある場合は、変数を 37 以上に設定する必要があります。

DRA ドライバをインストールします。

helm install nvidia-dra-driver-gpu nvidia/nvidia-dra-driver-gpu \
    --version="DRIVER_VERSION" \
    --create-namespace \
    --namespace nvidia-dra-driver-gpu \
    -f <(cat <<EOF
nvidiaDriverRoot: /home/kubernetes/bin/nvidia
resources:
  gpus:
    enabled: false

controller:
  affinity:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: "nvidia.com/gpu"
              operator: "DoesNotExist"

kubeletPlugin:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: cloud.google.com/gke-accelerator
                operator: In
                values:
                  - nvidia-gb200
              - key: kubernetes.io/arch
                operator: In
                values:
                  - arm64

  tolerations:
    - key: nvidia.com/gpu
      operator: Equal
      value: present
      effect: NoSchedule
    - key: kubernetes.io/arch
      operator: Equal
      value: arm64
      effect: NoSchedule
EOF
)

DRIVER_VERSION は、バージョン 25.3.1 以降に置き換えます。

マルチネットワーキング、RDMA、IMEX ドメイン用にワークロードマニフェストを構成する

Pod メタデータに次のアノテーションを追加します。

metadata:
  annotations:
    networking.gke.io/default-interface: 'eth0'
    networking.gke.io/interfaces: |
      [
        {"interfaceName":"eth0","network":"default"},
        {"interfaceName":"eth2","network":"rdma-0"},
        {"interfaceName":"eth3","network":"rdma-1"},
        {"interfaceName":"eth4","network":"rdma-2"},
        {"interfaceName":"eth5","network":"rdma-3"}
      ]

Arm ノードでスケジュールするノードアフィニティルールを追加します。

spec:
affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/arch
          operator: In
          values:
          - arm64

詳細については、単一のアーキテクチャへのワークロードをスケジュールするをご覧ください。

次の Volume を Pod 仕様に追加します。

spec:
volumes:
  - name: library-dir-host
    hostPath:
      path: /home/kubernetes/bin/nvidia
  - name: gib
    hostPath:
      path: /home/kubernetes/bin/gib

GPU をリクエストするコンテナに、次のボリュームマウント、環境変数、リソースを追加します。ワークロードコンテナは、4 つの GPU すべてをリクエストする必要があります。

containers:
- name: my-container
  volumeMounts:
    - name: library-dir-host
      mountPath: /usr/local/nvidia
    - name: gib
   mountPath: /usr/local/gib
  env:
    - name: LD_LIBRARY_PATH
      value: /usr/local/nvidia/lib64
  resources:
    limits:
      nvidia.com/gpu: 4

ワークロードの ComputeDomain リソースを作成します。

apiVersion: resource.nvidia.com/v1beta1
kind: ComputeDomain
metadata:
  name: a4x-compute-domain
spec:
  numNodes: NUM_NODES
  channel:
    resourceClaimTemplate:
      name: a4x-compute-domain-channel

NUM_NODES は、ワークロードに必要なノード数に置き換えます。

Pod が使用する resourceClaimTemplate を指定します。

spec:
  ...
  volumes:
    ...
  containers:
    - name: my-container
      ...
      resources:
        limits:
          nvidia.com/gpu: 4
  claims:
          - name: compute-domain-channel
        ...
resourceClaims:
  - name: compute-domain-channel
    resourceClaimTemplateName: a4x-compute-domain-channel

NCCL を構成するために必要なすべての環境変数を設定します。ワークロードコンテナから次のシェルスクリプトを使用します。
```
source /usr/local/gib/scripts/set_nccl_env.sh
```

完成した Pod 仕様は次のようになります。

apiVersion: resource.nvidia.com/v1beta1
kind: ComputeDomain
metadata:
  name: a4x-compute-domain
spec:
  numNodes: NUM_NODES
  channel:
    resourceClaimTemplate:
      name: a4x-compute-domain-channel
---
apiVersion: apps/v1
kind: Pod
metadata:
  name: my-pod
  labels:
    k8s-app: my-pod
  annotations:
    networking.gke.io/default-interface: 'eth0'
    networking.gke.io/interfaces: |
      [
        {"interfaceName":"eth0","network":"default"},
        {"interfaceName":"eth2","network":"rdma-0"},
        {"interfaceName":"eth3","network":"rdma-1"},
        {"interfaceName":"eth4","network":"rdma-2"},
        {"interfaceName":"eth5","network":"rdma-3"},
      ]
spec:
  ...
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/arch
            operator: In
            values:
            - arm64
  volumes:
    - name: library-dir-host
      hostPath:
        path: /home/kubernetes/bin/nvidia
    - name: gib
      hostPath:
        path: /home/kubernetes/bin/gib
  containers:
    - name: my-container
      volumeMounts:
        - name: library-dir-host
          mountPath: /usr/local/nvidia
        - name: gib
       mountPath: /usr/local/gib
      env:
        - name: LD_LIBRARY_PATH
          value: /usr/local/nvidia/lib64
      resources:
        limits:
          nvidia.com/gpu: 4
        claims:
          - name: compute-domain-channel
        ...
resourceClaims:
  - name: compute-domain-channel
    resourceClaimTemplateName: a4x-compute-domain-channel

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

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

次のステップ

TAS と Kueue を使用して GKE クラスタでワークロードをスケジュールする方法については、トポロジ対応スケジューリングで GKE ワークロードをスケジュールするをご覧ください。
GKE クラスタと AI ワークロードに関連する一般的なイベントの管理については、AI 最適化 GKE クラスタを管理するをご覧ください。