在 AWS PCS 中設定多執行個體 GPU (MIG)

NVIDIA 多執行個體 GPU (MIG) 會將支援的 GPU 分割為隔離的 GPU 執行個體，每個執行個體都有自己的記憶體和運算資源。Slurm 會將每個 MIG 設定檔排程為自己的一般資源 (GRES) 類型，因此多個任務可以與硬體隔離共用一個實體 GPU。

無法在 中靜態描述 MIG 裝置gres.conf：其裝置檔案和 UUIDs 只有在開機節點上建立 MIG 執行個體之後才會存在，因此沒有 File或 Type值可事先設定。在 AWS PCS 上，您使用只啟用 gres.conf的記錄來設定 MIGAutoDetect，以及宣告設定檔Gres的設定。 slurmd然後在節點開機時探索 MIG 裝置。 AWS PCS 在 Slurm 25.11 版和更新版本上支援 AutoDetect，因此支援 MIG。

設定 MIG 表示分割每個節點上的 GPUs，並將產生的設定檔宣告為運算節點群組上的 Slurm。這兩種方法都無法單獨運作，因此在一次變更中同時套用兩者。如果 Slurm 不知道節點的分割區，則節點沒有可排程的 GRES。如果沒有節點建立宣告的設定檔，節點會在註冊時耗盡。使用建議的節點生命週期動作，一個運算節點群組更新同時具有分割指令碼和 GRES 設定。

先決條件

每次開機時，MIG 節點必須具備什麼

MIG 模式和 MIG 執行個體位於 GPU 上，而非磁碟上，因此自訂 AMI 無法承載它們，而且每當執行個體停止、暫停或終止時，它們都會遺失。每次開機時，在slurmd啟動之前，下列所有項目都必須為 true：

如果已啟用 MIG 模式，但不存在 MIG 執行個體， 會slurmd尋找父 GPUs，但沒有 MIG 裝置。它會記錄 MIG mode is enabled, but no MIG devices were found，然後Discarding the following config-only GPU due to lack of File specification記錄每個宣告設定檔的 。由於節點回報的 GPUs 少於Gres宣告，控制器會拒絕註冊，並以 為由耗盡節點gres/gpu count reported lower than configured。在節點上請求 GPU 的任務失敗，並顯示 Required node not available。之後建立 MIG 執行個體並不會消除節點；您必須繼續或取代節點。中所述的節點生命週期動作可藉由在註冊之前使節點失敗來使用節點生命週期動作套用組態避免這種情況。

在執行個體上設定 MIG

設定執行個體需要下列兩個操作。從節點生命週期動作執行它們，這會將邏輯保留在運算節點群組上，而不是在您必須重建的 AMI 中。請參閱 使用節點生命週期動作套用組態。如果另一個程序在那時已保留 GPUs，請提早從 cloud-init boothook 或自訂 AMI 中的systemd單位執行 GPU。請參閱 如果 MIG 模式保持待定。如需 命令的詳細資訊，請參閱 NVIDIA Multi-Instance GPU 使用者指南。

使用節點生命週期動作套用組態

設定節點生命週期動作，如下所示。如需如何將節點新增至運算節點群組，請參閱 在 AWS PCS 中設定節點生命週期動作。

每次開機時執行的指令碼必須是等冪的。以下大綱採用每個 GPU 配置做為其第一個引數，並一次處理一個 GPU。它會略過已具有該配置的 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 設定，請參閱 中的範例將 MIG 設定檔宣告為 Slurm。

如果您調整指令碼，請保留兩個檢查。如果沒有模式檢查，則 MIG 模式永遠不會變成在沒有 MIG 裝置的情況下Enabled進行註冊的節點，原因只會顯示在slurmd日誌中。如果沒有配置檢查，建立錯誤設定檔的節點會正常註冊，而且只會失敗請求宣告設定檔的任務。如需指令碼輸出的寫入位置，請參閱 記錄和偵錯。

如果 MIG 模式保持待定

啟用 MIG 模式會在任何程序開啟 GPUs 時失敗。 會將啟用nvidia-smi報告為待定，例如使用 In use by another client，而且只有在這些程序結束或節點重新啟動後才會生效。在 AWS PCS 運算節點上，程序通常是 GPU 監控代理程式，例如 NVIDIA DCGM 或 AMI 中隨附的代理程式，如果 MIG 是在 slurmd 啟動後設定，則為slurmd本身。您無法從生命週期動作重新啟動，因此請使用下列其中一個修正：

將 MIG 設定檔宣告為 Slurm

宣告運算節點群組上的兩個 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)。請求設定檔的任務，例如 --gres=gpu:3g.20gb:1，會放置在單一 MIG 執行個體上，並在 中取得其 UUID CUDA_VISIBLE_DEVICES（例如 MIG-e7aa6185-06d5-53e9-a4d9-00f7670f741e)，因此 CUDA 會將任務限制在該 MIG 執行個體。

限制

由於 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 秒。然後節點已註冊，因此任務會在下次啟動時取得裝置。