本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 在中配置 Multi-Instance GPU (MIG) AWS 个
NVIDIA Multi-Instance GPU (MIG) 将支持的 GPU 划分为独立的 GPU 实例，每个实例都有自己的内存和计算资源。Slurm 将每个 MIG 配置文件安排为自己的通用资源 (GRES) 类型，因此多个任务可以在硬件隔离的情况下共享一个物理 GPU。
无法在中静态描述 MIG 设备`gres.conf`：它们的设备文件和 UUID 仅在启动的节点上创建 MIG 实例后才存在，因此无需提前配置`File`或`Type`值。在 AWS PCS 上，您可以使用仅启`gres.conf`用的记录`AutoDetect`以及声明配置文件的`Gres`设置来配置 MIG。`slurmd`然后在节点启动时发现 MIG 设备。 AWS PCS 支持 `AutoDetect` Slurm 版本 25.11 及更高版本，因此也支持 MIG。
配置 MIG 意味着对每个节点上的 GPU 进行分区，并将生成的配置文件声明给计算节点组上的 Slurm。两者都不能单独使用，因此一次更改即可同时应用两者。如果 Slurm 不知道某个节点的分区，则该节点没有可调度的 GRES。如果没有节点创建声明的配置文件，则这些节点在注册时会被排空。使用推荐的节点生命周期操作，一次计算节点组更新将同时包含分区脚本和 GRES 设置。
## 先决条件
+ 使用 MIG-capable 实例类型的计算节点组。
+ Slurm 版本 25.11 或更高版本。
+ 已配置的 CPU 拓扑。GPU 自动检测需要节点的套接字布局。在 Slurm 25.11 上，`Sockets`为计算节点组进行设置；在 Slurm 26.05 及更高版本中，PCS 会自动对其进行配置。 AWS 有关更多信息，请参阅 [在中配置硬件拓扑 AWS 个](hardware-topology.md)。
## MIG 节点在每次启动时必须具备的功能
MIG 模式和 MIG 实例在 GPU 上运行，而不是在磁盘上，因此自定义 AMI 无法携带它们，并且只要实例停止、暂停或终止，它们就会丢失。每次启动时，`slurmd`启动前必须满足以下所有条件：
1. **在为 MIG 实例提供服务的每个 GPU ** 上都启用了 MIG 模式。`nvidia-smi -q`报告 a `Current` 和 a `Pending` 模式，并且`Current`必须是`Enabled`。
1. **计算节点组`Gres`设置中的每个配置文件都存在 ** MIG 实例，包括 GPU 实例和计算实例。
1. **配置文件和计数与`Gres`设置**相符。
如果启用了 MIG 模式但不存在 MIG 实例，则会`slurmd`找到父 GPU，但找不到 MIG 设备。然后它会记录`MIG mode is enabled, but no MIG devices were found`每个已声明`Discarding the following config-only GPU due to lack of File specification`的配置文件。由于该节点报告的 GPU 少于`Gres`声明的数量，因此控制器拒绝注册并按原因耗尽该节点。`gres/gpu count reported lower than configured`在节点上请求 GPU 的任务会失败`Required node not available`。之后创建 MIG 实例不会耗尽节点；你必须恢复或替换它。中描述的节点生命周期操作通过在节点注册之前使其失效来[使用节点生命周期操作应用配置](#mig-configuration-instances-nla)避免这种情况。
## 在实例上配置 MIG
配置实例需要执行以下两项操作。通过节点生命周期操作运行它们，这会将逻辑保留在计算节点组上，而不是在你必须重建的 AMI 中。请参阅[使用节点生命周期操作应用配置](#mig-configuration-instances-nla)。如果此时已有其他进程存放 GPU，请先从自定义 AMI 的`cloud-init`展位或`systemd`单元中运行它们。请参阅[如果 MIG 模式仍处于待处理状态](#mig-configuration-instances-pending)。有关这些命令的更多信息，请参阅 [ NVIDIA Multi-Instance GPU 用户指南](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/)。
1. 在 GPU 上启用 MIG 模式：
```
nvidia-smi -mig 1
```
当进程使用 GPU 时，模式更改无法生效。该`nodeBootstrapped`阶段`slurmd`尚未启动，因此在不运行其他 GPU 服务的节点上，更改将在不重启的情况下生效。使用检查每个 GPU `Enabled` 上是否都处于应用模式`nvidia-smi --query-gpu=mig.mode.current --format=csv`。
**重要**
如果 MIG 模式保持不变`Pending`，则另一个进程会打开 GPU。请参阅[如果 MIG 模式仍处于待处理状态](#mig-configuration-instances-pending)。
1. 为所需的配置文件创建 GPU 实例和计算实例。例如，要将 8 个 GPU 中的每一个 GPU 分成一个`3g.20gb``2g.10gb`、一个和两个`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`也接受数字配置文件 ID，但相同的 ID 表示不同 GPU 型号上的配置文件不同：这种布局`9,14,19,19`是在 40 GB A100 的`p4d`实例上，还有，和 `3g.40gb``2g.20gb`，两个`1g.10gb`在 80 GB 的部分上。使用配置文件名称，使它们与`Gres`设置相匹配，并且在没有此类配置文件的 GPU 上创建失败。
如示例所示，首先创建最大的配置文件。MIG 的放置位置是固定的，因此，如果小配置文件占据大配置文件所需的切片，则仍然无法创建适合的布局。
### 使用节点生命周期操作应用配置
按如下方式配置节点生命周期操作。有关如何向计算节点组添加一个，请参阅[在中配置节点生命周期操作 AWS 个](cng-node-lifecycle-actions-configure.md)。
| **Field** | **Value** | **为什么 ** |
| --- | --- | --- |
| 生命周期阶段 | `nodeBootstrapped` | 在`slurmd`打开 GPU 和注册节点之前运行。 |
| `executionPolicy` | `EVERY_BOOT` | MIG 状态无法在停止、暂停或终止后幸存下来。 |
| `arguments` | `["3g.20gb,2g.10gb,1g.5gb,1g.5gb"]` | 按名称在每个 GPU 上创建的 MIG 配置文件。然后，一个脚本为具有不同布局的计算节点组提供服务。 |
| `onError` | `TERMINATE` | 替换无法分区的节点，而不是让它在没有 MIG 设备的情况下注册。调试时，用于保留实例`STOP_SEQUENCE`以供检查。 |
每次启动时运行的脚本必须是等效的。以下概述将每个 GPU 的布局作为其第一个参数，一次处理一个 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 设置，请参阅中的[向 Slurm 申报 MIG 配置文件](#mig-configuration-slurm)示例。
如果您调整脚本，请保留这两张支票。如果不进行模式检查，MIG 模式从未变为 `Enabled` MIG 模式的节点将在没有 MIG 设备的情况下继续注册，原因仅显示在日志中`slurmd`。如果不进行布局检查，创建错误配置文件的节点将正常注册，并且只会使请求声明配置文件的作业失败。有关脚本输出的写入位置，请参见[记录和调试](cng-node-lifecycle-actions-configure.md#cng-node-lifecycle-actions-configure-logging)。
### 如果 MIG 模式仍处于待处理状态
当任何进程都打开 GPU 时，启用 MIG 模式将失败。`nvidia-smi`将启用报告为待启用，例如使用`In use by another client`，并且仅在这些进程退出或节点重新启动后才生效。在 AWS PCS 计算节点上，该进程通常是 GPU 监控代理，例如 NVIDIA DCGM 或 AMI 中附带的代理，或者如果在启动后`slurmd`配置 MIG，则该进程`slurmd`本身。您无法从生命周期操作中重新启动，因此请使用以下修复程序之一：
+ **停止保存 GPU 的进程。**在自定义 AMI 中，禁用或移除在 MIG 配置运行之前打开 GPU 的任何守护程序。还要移除任何自行配置 MIG 的守护程序。将同一 GPU 分区的两个组件生成的布局与设置不匹配。`Gres`
+ **在电子书中配置 MIG。**如果您无法停止该进程，请将 MIG 模式更改和配置文件创建移至启动模板`cloud-init`用户数据中的书签中。boothook 在 AWS PCS 引导之前和 AMI 服务启动之前运行，因此模式更改无需重启即可生效。要了解如何编写，请参阅[示例：使用 cloud-init boothook 运行早期启动操作](working-with_ec2-user-data_early-boot.md)。将生命周期操作作为检查对象：每次启动时，它都会确认布局，如果启动簿未应用则会使节点失败。
## 向 Slurm 申报 MIG 配置文件
在计算节点组上声明两个 GRES 设置：
+ 在中`gresCustomSettings`，仅启用的 GPU 记录`AutoDetect`。不要设置`Name``Type`、或`File`。在节点上发现 MIG 设备。
+ 在中`slurmCustomSettings`，声明任务可以请求的 MIG 配置文件和计数的`Gres`设置。配置文件名称和数量必须与在节点上创建的 MIG 实例相匹配。
**Example — 在一次更新中应用这两个部分（8 个 GPU，每个分区为一个 `3g.20GB、一个 2 g.10GB` 和两个 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"
}
]
}
}'
```
该示例将两个参数作为 JSON 传递，因为该`Gres`值包含逗号，CLI 速记语法需要对其进行转义。
保持`arguments``Gres`一致：`3g.20gb,2g.10gb,1g.5gb,1g.5gb`在 8 个 GPU 上分别给出`gpu:3g.20gb:8,gpu:2g.10gb:8,gpu:1g.5gb:16`声明的 8、8 和 16 个实例。
有关这两种设置之间的限制，请参见[gres.conf 和 Gres 设置之间的限制](gres-custom-settings.md#gres-custom-settings-constraints)。由于 AWS PCS 无法计算启动时发现的设备，因此它接受任何配置文件名称和`Gres`设置中的计数，以记录仅启用`AutoDetect`。只有在节点注册时才能验证与实际 MIG 实例的一致性。
例如，当节点启动和注册时，它会以其套接字关联性公布发现的配置文件。`Gres=gpu:3g.20gb:8(S:0),gpu:1g.5gb:28(S:1)`请求配置文件（例如）的任务放置在单个 MIG 实例上并获取其 UUID`CUDA_VISIBLE_DEVICES`（例如`MIG-e7aa6185-06d5-53e9-a4d9-00f7670f741e`），因此 CUDA 将任务限制为该 MIG 实例。`--gres=gpu:3g.20gb:1`
**注意**
控制器会记录诸如 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`由于 AWS PCS 不限制通过 cgroup 访问设备，因此该任务可以使用该节点上的所有 MIG 设备。Slurm `RUNNING` 像报告任务一样，计算任务所依据的 MIG 实例将分配给下一个请求该配置文件的任务，因此这两个任务最终可以在同一 MIG 实例上运行。在节点注册一次之后（包括稍后的关机和开机周期之后）分配给该节点的任务将按预期获得其设备。
要检测这种情况，请在设置的任务开始时进行验证，如果未设置`CUDA_VISIBLE_DEVICES`则退出或重新启动任务：
```
if [ -z "${CUDA_VISIBLE_DEVICES-}" ]; then
scontrol requeue "$SLURM_JOB_ID"
exit 1
fi
```
重新排队的作业有资格在`requeue_delay`调度器参数之后再次运行，默认为 5 秒。到那时，该节点已经注册，因此任务将在下次启动时获得一台设备。