在中配置 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 节点在每次启动时必须具备的功能

MIG 模式和 MIG 实例在 GPU 上运行，而不是在磁盘上，因此自定义 AMI 无法携带它们，并且只要实例停止、暂停或终止，它们就会丢失。每次启动时，slurmd启动前必须满足以下所有条件：

如果启用了 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

配置实例需要执行以下两项操作。通过节点生命周期操作运行它们，这会将逻辑保留在计算节点组上，而不是在你必须重建的 AMI 中。请参阅使用节点生命周期操作应用配置。如果此时已有其他进程存放 GPU，请先从自定义 AMI 的cloud-init展位或systemd单元中运行它们。请参阅如果 MIG 模式仍处于待处理状态。有关这些命令的更多信息，请参阅 NVIDIA Multi-Instance GPU 用户指南。

使用节点生命周期操作应用配置

按如下方式配置节点生命周期操作。有关如何向计算节点组添加一个，请参阅在中配置节点生命周期操作 AWS 个。

每次启动时运行的脚本必须是等效的。以下概述将每个 GPU 的布局作为其第一个参数，一次处理一个 GPU。它会跳过已经有这种布局的 GPU，对任何其他布局进行重新分区，如果无法完成则以非零值退出，这会导致节点出现故障。它永远不会重新启动节点。有关参数如何到达脚本的信息，请参阅将参数传递给脚本。

#!/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 模式从未变为 Enabled MIG 模式的节点将在没有 MIG 设备的情况下继续注册，原因仅显示在日志中slurmd。如果不进行布局检查，创建错误配置文件的节点将正常注册，并且只会使请求声明配置文件的作业失败。有关脚本输出的写入位置，请参见记录和调试。

如果 MIG 模式仍处于待处理状态

当任何进程都打开 GPU 时，启用 MIG 模式将失败。nvidia-smi将启用报告为待启用，例如使用In use by another client，并且仅在这些进程退出或节点重新启动后才生效。在 AWS PCS 计算节点上，该进程通常是 GPU 监控代理，例如 NVIDIA DCGM 或 AMI 中附带的代理，或者如果在启动后slurmd配置 MIG，则该进程slurmd本身。您无法从生命周期操作中重新启动，因此请使用以下修复程序之一：

向 Slurm 申报 MIG 配置文件

在计算节点组上声明两个 GRES 设置：

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.conf 和 Gres 设置之间的限制。由于 AWS PCS 无法计算启动时发现的设备，因此它接受任何配置文件名称和Gres设置中的计数，以记录仅启用AutoDetect。只有在节点注册时才能验证与实际 MIG 实例的一致性。

例如，当节点启动和注册时，它会以其套接字关联性公布发现的配置文件。Gres=gpu:3g.20gb:8(S:0),gpu:1g.5gb:28(S:1)请求配置文件（例如）的任务放置在单个 MIG 实例上并获取其 UUIDCUDA_VISIBLE_DEVICES（例如MIG-e7aa6185-06d5-53e9-a4d9-00f7670f741e），因此 CUDA 将任务限制为该 MIG 实例。--gres=gpu:3g.20gb:1

限制

由于 MIG 配置不命名设备，因此控制器仅在节点启动和注册后才知道该节点的真实 GRES。在节点注册一次之前，控制器仅保存Gres设置中的配置文件数。这会导致以下限制。它适用于任何仅启用的 GPU 记录AutoDetect，因此适用于每个 MIG 计算节点组。

在节点首次注册之前分配的任务可以在没有 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 秒。到那时，该节点已经注册，因此任务将在下次启动时获得一台设备。