翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# PCS でのマルチインスタンス GPU (MIG) AWS の設定
NVIDIA マルチインスタンス GPU (MIG) は、サポートされている GPU を分離された GPU インスタンスに分割し、それぞれに独自のメモリとコンピューティングリソースがあります。Slurm は、各 MIG プロファイルを独自の汎用リソース (GRES) タイプとしてスケジュールするため、複数のジョブで 1 つの物理 GPU をハードウェア分離と共有できます。
MIG デバイスを で静的に記述することはできません`gres.conf`。デバイスファイルと UUIDsは、起動されたノードで MIG インスタンスが作成された後にのみ存在するため、事前に設定する `File`または `Type`値はありません。 AWS PCS では、 のみを有効にする`gres.conf`レコードと`AutoDetect`、プロファイルを宣言する`Gres`設定を使用して MIG を設定します。 `slurmd` は、ノードの起動時に MIG デバイスを検出します。 AWS PCS は`AutoDetect`、Slurm バージョン 25.11 以降で 、つまり MIG をサポートします。
MIG を設定すると、各ノードの GPUs がパーティション分割され、結果のプロファイルがコンピューティングノードグループの Slurm に宣言されます。どちらも単独では機能しないため、両方を 1 回の変更で適用します。Slurm がノードのパーティションを知らない場合、ノードにはスケジューリング可能な GRES がありません。宣言されたプロファイルを作成するノードがない場合、ノードは登録時にドレインされます。推奨されるノードライフサイクルアクションでは、1 つのコンピューティングノードグループの更新でパーティショニングスクリプトと GRES 設定の両方が保持されます。
## 前提条件
+ MIG 対応インスタンスタイプを使用するコンピューティングノードグループ。
+ Slurm バージョン 25.11 以降。
+ 設定された CPU トポロジ。GPU 自動検出には、ノードのソケットレイアウトが必要です。Slurm 25.11 `Sockets`では、コンピューティングノードグループに を設定します。Slurm 26.05 以降では、 AWS PCS によって自動的に設定されます。詳細については、「[PCS AWS でのハードウェアトポロジの設定](hardware-topology.md)」を参照してください。
## 起動ごとに MIG ノードが持つ必要があるもの
MIG モードと MIG インスタンスはディスク上ではなく GPU 上に存在するため、カスタム AMI はそれらを伝送できず、インスタンスが停止、中断、または終了されるたびに失われます。起動するたびに、 `slurmd`を開始する前に、次のすべてが true である必要があります。
1. **MIG モードは、MIG インスタンスを処理するすべての GPU で有効**になります。 は `Current`と `Pending` モード`nvidia-smi -q`を報告し、 `Current`である必要があります`Enabled`。
1. **MIG インスタンスは、GPU インスタンスとコンピューティングインスタンスの両方が、コンピューティングノードグループの設定のすべてのプロファイルに存在します**。 `Gres`
1. **プロファイルとカウントは 設定と一致し**ます。 `Gres`
MIG モードが有効になっていても MIG インスタンスが存在しない場合、 は親 GPU `slurmd`を見つけますが、MIG デバイスを見つけません。 GPUs をログに記録し`MIG mode is enabled, but no MIG devices were found`、宣言されたプロファイル`Discarding the following config-only GPU due to lack of File specification`ごとに を記録します。ノードは が`Gres`宣言する数よりも少ない GPUs を報告するため、コントローラーは登録を拒否し、 という理由でノードをドレインします`gres/gpu count reported lower than configured`。ノードで GPU をリクエストするジョブは、 で失敗します`Required node not available`。その後に MIG インスタンスを作成しても、ノードのドレインは解除されません。再開または置き換える必要があります。「」で説明されているノードライフサイクルアクションは、登録前にノードが失敗することでこれ[ノードライフサイクルアクションを使用して設定を適用する](#mig-configuration-instances-nla)を回避します。
## インスタンスで MIG を設定する
インスタンスを設定すると、次の 2 つのオペレーションが実行されます。ノードライフサイクルアクションから実行します。これにより、再構築する必要がある AMI ではなく、コンピューティングノードグループにロジックが保持されます。「[ノードライフサイクルアクションを使用して設定を適用する](#mig-configuration-instances-nla)」を参照してください。その時点で別のプロセスがすでに GPUs を保持している場合は、`cloud-init`ブートフックまたはカスタム AMI の`systemd`ユニットからより前に実行します。「[MIG モードが保留中のままの場合](#mig-configuration-instances-pending)」を参照してください。コマンドの詳細については、[「NVIDIA マルチインスタンス GPU ユーザーガイド](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/)」を参照してください。
1. GPUs で MIG モードを有効にします。
```
nvidia-smi -mig 1
```
プロセスが GPUs を使用している間は、モードの変更を有効にすることはできません。`nodeBootstrapped` ステージ`slurmd`では開始されていないため、他の GPU サービスを実行しないノードでは、再起動なしで変更が有効になります。で、適用されたモードがすべての GPU `Enabled`にあることを確認します`nvidia-smi --query-gpu=mig.mode.current --format=csv`。
**重要**
MIG モードが のままの場合`Pending`、別のプロセスで GPUs。「[MIG モードが保留中のままの場合](#mig-configuration-instances-pending)」を参照してください。
1. 必要なプロファイルの GPU インスタンスとコンピューティングインスタンスを作成します。たとえば、8 つの GPUsに分割するには`2g.10gb`、次のようにします。 `3g.20gb` `1g.5gb`
```
for i in 0 1 2 3 4 5 6 7; do
nvidia-smi mig -i $i -cgi 3g.20gb,2g.10gb,1g.5gb,1g.5gb -C
done
```
`-cgi` は数値プロファイル IDs、同じ ID は別の GPU モデルで異なるプロファイルを意味します。 `9,14,19,19`は`p4d`インスタンスの 40 GB A100 で、 は 、`2g.20gb`、および `3g.40gb`2 は 80 GB パーツ`1g.10gb`です。プロファイル名を使用すると、`Gres`設定と一致し、そのようなプロファイルを持たない GPU で作成が失敗します。
この例のように、最初に最大のプロファイルを作成します。MIG 配置は固定されているため、小さなプロファイルが大きなプロファイルに必要なスライスを取ると、フィットするレイアウトは作成に失敗する可能性があります。
### ノードライフサイクルアクションを使用して設定を適用する
ノードライフサイクルアクションを次のように設定します。コンピューティングノードグループに 1 つを追加する方法については、「」を参照してください[PCS AWS でノードライフサイクルアクションを設定する](cng-node-lifecycle-actions-configure.md)。
| **フィールド** | **値** | **なぜ** |
| --- | --- | --- |
| ライフサイクルステージ | `nodeBootstrapped` | が GPUs `slurmd`を開き、ノードを登録する前に を実行します。 |
| `executionPolicy` | `EVERY_BOOT` | MIG 状態は、停止、停止、または終了後も存続しません。 |
| `arguments` | `["3g.20gb,2g.10gb,1g.5gb,1g.5gb"]` | 各 GPU で作成する MIG プロファイルの名前。次に、1 つのスクリプトが異なるレイアウトのコンピューティングノードグループを提供します。 |
| `onError` | `TERMINATE` | MIG デバイスなしで登録するのではなく、パーティション化できないノードを置き換えます。デバッグ中は、 `STOP_SEQUENCE` を使用してインスタンスを検査用に保持します。 |
起動ごとに実行されるスクリプトはべき等である必要があります。次の概要は、最初の引数として GPU ごとのレイアウトを取り、一度に 1 つの GPU を処理します。そのレイアウトが既にある GPU をスキップし、他のすべてのパーティションを再分割して、完了できない場合はゼロ以外を終了し、ノードが失敗します。ノードを再起動することはありません。引数がスクリプトに到達する方法については、「」を参照してください[スクリプトに引数を渡す](cng-node-lifecycle-actions-configure.md#cng-node-lifecycle-actions-configure-arguments)。
```
#!/usr/bin/env bash
# Partition every GPU as $1 specifies, then verify the result. Expected
# nvidia-smi failures are handled inline, so this doesn't use 'set -e'.
set -uo pipefail
# $1 - per-GPU MIG profile names, comma-separated, largest first, as in Gres.
PROFILES="${1:-}"
if ! echo "$PROFILES" | grep -Eq '^[0-9]+g\.[0-9]+gb(,[0-9]+g\.[0-9]+gb)*$'; then
echo "ERROR: pass the per-GPU MIG profiles as the first argument," >&2
echo " for example 3g.20gb,2g.10gb,1g.5gb,1g.5gb" >&2
exit 1
fi
EXPECTED=$(echo "$PROFILES" | tr ',' '\n' | sort)
# Fail, rather than exit 0, when there is no GPU to configure.
GPUS=$(nvidia-smi --query-gpu=index --format=csv,noheader) || {
echo "ERROR: nvidia-smi failed. This node has no usable NVIDIA driver." >&2
exit 1
}
if [ -z "$GPUS" ]; then
echo "ERROR: no NVIDIA GPUs detected." >&2
exit 1
fi
# The MIG profiles on GPU $1, in the same form as EXPECTED. nvidia-smi -L lists
# what NVML reports, which is what slurmd autodetects.
mig_devices() {
nvidia-smi -L | awk -v gpu="$1" '
/^GPU [0-9]+:/ { current = ($2 + 0); next }
$1 == "MIG" && current == gpu { print $2 }
' | sort
}
for i in $GPUS; do
# 1. Skip a GPU that already has the requested layout.
if [ "$(mig_devices "$i")" = "$EXPECTED" ]; then
echo "GPU $i: already configured as $PROFILES"
continue
fi
# 2. Enable MIG mode. Ignore the exit status; step 3 checks the result.
enable_output=$(nvidia-smi -i "$i" -mig 1 2>&1) || true
# 3. Fail if the mode isn't applied. Don't reboot: that would interrupt
# the AWS PCS bootstrap.
current=$(nvidia-smi -i "$i" --query-gpu=mig.mode.current --format=csv,noheader)
pending=$(nvidia-smi -i "$i" --query-gpu=mig.mode.pending --format=csv,noheader)
if [ "$current" != "Enabled" ]; then
echo "ERROR: GPU $i MIG mode is '$current', pending '$pending'." >&2
echo "$enable_output" >&2
if [ "$pending" = "Enabled" ]; then
echo "The enable is pending, so a process is holding the GPU. Stop it," >&2
echo "or configure MIG mode in a boothook instead." >&2
elif [ "$current" = "[N/A]" ] || [ "$current" = "N/A" ]; then
echo "This GPU does not support MIG." >&2
fi
exit 1
fi
# 4. Recreate the layout from scratch, because instances can't be added to
# a partial one. Nothing uses them yet, because slurmd hasn't started.
nvidia-smi mig -i "$i" -dci >/dev/null 2>&1 || true
nvidia-smi mig -i "$i" -dgi >/dev/null 2>&1 || true
if ! nvidia-smi mig -i "$i" -cgi "$PROFILES" -C; then
echo "ERROR: MIG instance creation failed on GPU $i" >&2
exit 1
fi
# 5. Check which profiles exist, not only how many, so a layout that
# doesn't match Gres fails here instead of at job time.
actual=$(mig_devices "$i")
if [ "$actual" != "$EXPECTED" ]; then
echo "ERROR: GPU $i has the wrong MIG layout." >&2
echo " expected: $(echo "$EXPECTED" | tr '\n' ' ')" >&2
echo " found: $(echo "$actual" | tr '\n' ' ')" >&2
exit 1
fi
echo "GPU $i: configured as $PROFILES"
done
```
スクリプトと GRES 設定を 1 回の呼び出しで設定するには、 の例を参照してください[MIG プロファイルを Slurm に宣言する](#mig-configuration-slurm)。
スクリプトを適応させる場合は、両方のチェックを保持します。モードチェックがないと、MIG モード`Enabled`が MIG デバイスなしで登録されることはなく、原因は`slurmd`ログにのみ表示されます。レイアウトチェックを行わないと、間違ったプロファイルを作成するノードは正常に登録され、宣言されたプロファイルをリクエストするジョブのみに失敗します。スクリプトの出力が書き込まれる場所については、「」を参照してください[ログ記録とデバッグ](cng-node-lifecycle-actions-configure.md#cng-node-lifecycle-actions-configure-logging)。
### MIG モードが保留中のままの場合
GPU が開いているプロセスがある間、MIG モードの有効化は失敗GPUs。 は、 などで有効化を保留中として`nvidia-smi`報告し`In use by another client`、それらのプロセスが終了するかノードが再起動された後にのみ有効になります。 AWS PCS コンピューティングノードでは、プロセスは通常、NVIDIA DCGM や AMI に付属するエージェントなどの GPU モニタリングエージェントです。起動後に MIG が設定されている場合はそれ`slurmd`自体`slurmd`です。ライフサイクルアクションから再起動できないため、次のいずれかの修正を使用します。
+ **GPUs を保持するプロセスを停止します。**カスタム AMI で、MIG 設定の実行前に GPUs を開くデーモンを無効化または削除します。また、MIG 自体を設定するデーモンも削除します。同じ GPUs をパーティション化する 2 つのコンポーネントは、 `Gres`設定と一致しないレイアウトを生成します。
+ **ブートフックで MIG を設定します。**プロセスを停止できない場合は、MIG モードの変更とプロファイルの作成を起動テンプレートのユーザーデータの`cloud-init`ブートフックに移動します。ブートフックは PCS AWS ブートストラップの前と AMI のサービスが開始される前に実行されるため、モードの変更は再起動なしで有効になります。書き込み方法については、「」を参照してください[例: cloud-init ブートフックを使用して早期起動オペレーションを実行する](working-with_ec2-user-data_early-boot.md)。ライフサイクルアクションをチェックとして保持します。起動するたびにレイアウトを確認し、ブートフックが適用しなかった場合はノードに失敗します。
## MIG プロファイルを Slurm に宣言する
コンピューティングノードグループで両方の GRES 設定を宣言します。
+ では`gresCustomSettings`、 のみを有効にする GPU レコード`AutoDetect`。`Name`、`Type`、または を設定しないでください`File`。MIG デバイスはノードで検出されます。
+ では`slurmCustomSettings`、MIG プロファイルを宣言し、ジョブがリクエストできる をカウントする`Gres`設定。プロファイル名とカウントは、ノードで作成された MIG インスタンスと一致する必要があります。
**Example – 両方のパートを 1 つの更新に適用する (8 GPUs、それぞれを 1 つの 、1 つの `3g.20gb`、`2g.10gb`2 つの に分割`1g.5gb`)**
```
aws pcs update-compute-node-group \
--cluster-identifier {{my-cluster}} \
--compute-node-group-identifier {{my-cng-1}} \
--slurm-configuration '{
"gresCustomSettings": [
{ "AutoDetect": "nvml" }
],
"slurmCustomSettings": [
{ "parameterName": "Gres", "parameterValue": "gpu:3g.20gb:8,gpu:2g.10gb:8,gpu:1g.5gb:16" }
]
}' \
--node-lifecycle-actions '{
"stages": {
"nodeBootstrapped": [
{
"name": "configure-mig",
"scriptSource": {
"scriptLocation": "s3://{{my-bucket}}/configure-mig.sh"
},
"arguments": ["3g.20gb,2g.10gb,1g.5gb,1g.5gb"],
"executionPolicy": "EVERY_BOOT",
"onError": "TERMINATE"
}
]
}
}'
```
この例では、`Gres`値にカンマが含まれているため、両方のパラメータを JSON として渡します。この CLI 短縮構文はエスケープする必要があります。
`arguments` `Gres` 一貫性を保つ: 8 つの GPUs `3g.20gb,2g.10gb,1g.5gb,1g.5gb`ごとに、 が`gpu:3g.20gb:8,gpu:2g.10gb:8,gpu:1g.5gb:16`宣言する 8、8、および 16 個のインスタンスが提供されます。
2 つの設定間の制約については、「」を参照してください[gres.conf と Gres 設定の間の制約](gres-custom-settings.md#gres-custom-settings-constraints)。PCS AWS は起動時に検出されたデバイスをカウントできないため、 のみを有効にするレコードの `Gres`設定でプロファイル名とカウントを受け入れます`AutoDetect`。実際の MIG インスタンスとの整合性は、ノードの登録時にのみ検証されます。
ノードが起動して登録されると、検出されたプロファイルをソケットアフィニティ、たとえば でアドバタイズします`Gres=gpu:3g.20gb:8(S:0),gpu:1g.5gb:28(S:1)`。などのプロファイルをリクエストするジョブは `--gres=gpu:3g.20gb:1`1 つの MIG インスタンスに配置され、 で UUID を取得するため `CUDA_VISIBLE_DEVICES` (例: `MIG-e7aa6185-06d5-53e9-a4d9-00f7670f741e`)、CUDA はジョブをその MIG インスタンスに制限します。
**注記**
コントローラーは、MIG レコード`Ignoring file-less GPU gpu:3g.20gb from final GRES list`の などの警告を記録します。これは想定されます。権威 GRES はノード登録から取得されます。
## 制限事項
MIG 設定ではデバイスの名前がないため、コントローラーはノードの起動と登録後にのみノードの実際の GRES を認識します。ノードが一度登録されるまで、コントローラーは `Gres`設定のプロファイル数のみを保持します。これにより、次の制限が発生します。これは、 のみを有効にする GPU レコード`AutoDetect`、つまりすべての MIG コンピューティングノードグループに適用されます。
**注記**
ベストプラクティスとして、MIG には静的コンピューティングノードグループを使用します。スケーリング設定`maxInstanceCount`では に`minInstanceCount`等しく設定されます。その後、ノードは起動時に、ジョブが割り当てられる前に登録されるため、制限を回避できます。
### ノードが最初に登録される前に割り当てられたジョブは GPU なしで開始できます
新しく作成されたコンピューティングノードグループの最初の起動時など、電源が切られて登録されていないノードに割り当てられたジョブには、プロファイルカウントが付与されますが、デバイスはまだわからないため、特定のデバイスはありません。ノードが起動してジョブが開始されると、ジョブには MIG デバイスが割り当てられません。 `CUDA_VISIBLE_DEVICES` は設定されず、PCS AWS は cgroup を介したデバイスアクセスを制限しないため、ジョブはノード上のすべての MIG デバイスを使用できます。Slurm はジョブを`RUNNING`そのように報告し、ジョブがカウントされた MIG インスタンスは、そのプロファイルをリクエストする次のジョブに割り当てられるため、両方のジョブが同じ MIG インスタンスで終了する可能性があります。1 回登録した後にノードに割り当てられたジョブは、後の電源オフサイクルと電源アップサイクルの後を含め、想定どおりにデバイスを取得します。
この条件を検出するには、設定`CUDA_VISIBLE_DEVICES`されているジョブの開始時に を確認し、設定されていない場合はジョブを終了または再キューに入れます。
```
if [ -z "${CUDA_VISIBLE_DEVICES-}" ]; then
scontrol requeue "$SLURM_JOB_ID"
exit 1
fi
```
再キューに入れられたジョブは、デフォルトで 5 秒のス`requeue_delay`ケジューラパラメータの後に再度実行できるようになります。その後、ノードは登録されているため、ジョブは次の起動時にデバイスを取得します。