Konfiguration der Multi-Instance GPU (MIG) in AWS STCK

NVIDIA Multi-Instance GPU (MIG) partitioniert eine unterstützte GPU in isolierte GPU-Instanzen, von denen jede über ihren eigenen Speicher und ihre eigenen Rechenressourcen verfügt. Slurm plant jedes MIG-Profil als eigenen GRES-Typ (Generic Resource) ein, sodass sich mehrere Jobs eine physische GPU mit Hardware-Isolierung teilen können.

MIG-Geräte können nicht statisch beschrieben werden ingres.conf: Ihre Gerätedateien und UUIDs existieren erst, nachdem die MIG-Instanzen auf dem gestarteten Knoten erstellt wurden, sodass es keinen File Type Wert gibt, der im Voraus konfiguriert werden muss. Auf AWS PCS konfigurieren Sie MIG mit einem gres.conf Datensatz, der nur aktiviert wirdAutoDetect, zusammen mit einer Gres Einstellung, die die Profile deklariert. slurmderkennt dann die MIG-Geräte, wenn der Knoten gestartet wird. AWS PCS unterstützt AutoDetect und somit MIG auf Slurm-Version 25.11 und höher.

Die Konfiguration von MIG bedeutet, die GPUs auf jedem Knoten zu partitionieren und die resultierenden Profile Slurm in der Compute-Knotengruppe zu deklarieren. Beides funktioniert nicht alleine, also wenden Sie beide zusammen mit einer Änderung an. Wenn Slurm nichts über die Partitionen eines Knotens weiß, hat der Knoten kein planbares GRES. Wenn kein Knoten die deklarierten Profile erstellt, werden die Knoten bei der Registrierung geleert. Bei der empfohlenen Aktion für den Knotenlebenszyklus enthält ein Update der Compute-Knotengruppe sowohl das Partitionierungsskript als auch die GRES-Einstellungen.

Voraussetzungen

Was ein MIG-Knoten bei jedem Start haben muss

MIG-Modus und MIG-Instances befinden sich auf der GPU, nicht auf der Festplatte, sodass ein benutzerdefiniertes AMI sie nicht übertragen kann. Sie gehen verloren, wenn die Instance gestoppt, ausgesetzt oder beendet wird. Bei jedem Start müssen alle folgenden Bedingungen erfüllt sein, bevor slurmd gestartet wird:

Wenn der MIG-Modus aktiviert ist, aber keine MIG-Instanzen vorhanden sind, slurmd findet er die übergeordneten GPUs, aber kein MIG-Gerät. Es protokolliertMIG mode is enabled, but no MIG devices were found, dann Discarding the following config-only GPU due to lack of File specification für jedes deklarierte Profil. Da der Knoten weniger GPUs meldet als Gres deklariert, lehnt der Controller die Registrierung ab und leert den Knoten mit der Begründung. gres/gpu count reported lower than configured Jobs, die eine GPU auf dem Knoten anfordern, schlagen mit fehl. Required node not available Wenn Sie die MIG-Instanzen anschließend erstellen, wird der Knoten nicht entlastet. Sie müssen den Vorgang fortsetzen oder ersetzen. Die unter beschriebene Aktion im Lebenszyklus eines Knotens Wenden Sie die Konfiguration mit einer Node-Lifecycle-Aktion an vermeidet dies, indem der Knoten vor der Registrierung ausfällt.

Konfigurieren Sie MIG auf den Instanzen

Die Konfiguration der Instanzen erfordert die folgenden beiden Vorgänge. Führen Sie sie über eine Node-Lifecycle-Aktion aus, bei der die Logik in der Compute-Knotengruppe und nicht in einem AMI, das Sie neu erstellen müssen, beibehalten wird. Siehe Wenden Sie die Konfiguration mit einer Node-Lifecycle-Aktion an. Wenn die GPUs zu diesem Zeitpunkt bereits in einem anderen Prozess gespeichert sind, führen Sie sie früher von einem cloud-init Boothook oder einer systemd Einheit in einem benutzerdefinierten AMI aus. Siehe Wenn der MIG-Modus weiterhin aussteht. Weitere Informationen zu den Befehlen finden Sie im NVIDIA Multi-Instance GPU-Benutzerhandbuch.

Wenden Sie die Konfiguration mit einer Node-Lifecycle-Aktion an

Konfigurieren Sie die Aktion für den Knotenlebenszyklus wie folgt. Informationen zum Hinzufügen eines Knotens zu einer Compute-Knotengruppe finden Sie unterKonfigurieren Sie Node-Lifecycle-Aktionen in AWS STCK.

Ein Skript, das bei jedem Start ausgeführt wird, muss idempotent sein. Die folgende Gliederung verwendet das Layout pro GPU als erstes Argument und behandelt jeweils eine GPU. Es überspringt eine GPU, die bereits über dieses Layout verfügt, partitioniert jede andere neu und wird ungleich Null beendet, wenn sie nicht fertig werden kann, wodurch der Knoten fehlschlägt. Der Knoten wird nie neu gestartet. Informationen dazu, wie Argumente ein Skript erreichen, finden Sie unterÜbergabe von Argumenten an Skripts.

#!/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

Informationen zum Festlegen des Skripts und der GRES-Einstellungen in einem Aufruf finden Sie im Deklarieren Sie die MIG-Profile für Slurm Beispiel unter.

Wenn Sie das Skript anpassen, behalten Sie beide Häkchen bei. Ohne die Modusüberprüfung registriert sich ein Knoten, dessen MIG-Modus nie aktiviert wurdeEnabled, ohne seine MIG-Geräte, und die Ursache wird nur im slurmd Protokoll angezeigt. Ohne die Layoutüberprüfung registriert sich ein Knoten, der die falschen Profile erstellt, normal und schlägt nur bei den Jobs fehl, die die deklarierten Profile anfordern. Informationen darüber, wo die Ausgabe des Skripts geschrieben wird, finden Sie unterLoggen und Debuggen.

Wenn der MIG-Modus weiterhin aussteht

Die Aktivierung des MIG-Modus schlägt fehl, solange bei einem Prozess die GPUs geöffnet sind. nvidia-smimeldet die Aktivierung als ausstehend, z. B. mitIn use by another client, und sie wird erst wirksam, wenn diese Prozesse beendet werden oder der Knoten neu gestartet wird. Auf einem AWS PCS-Rechenknoten ist der Prozess normalerweise ein GPU-Monitoring-Agent, wie NVIDIA DCGM, oder ein Agent, der im AMI enthalten ist, oder er slurmd selbst, wenn MIG nach dem slurmd Start konfiguriert wird. Sie können den Computer nicht von der Lifecycle-Aktion aus neu starten. Verwenden Sie daher eine der folgenden Korrekturen:

Deklarieren Sie die MIG-Profile für Slurm

Deklarieren Sie beide GRES-Einstellungen für die Compute-Knotengruppe:

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"
          }
        ]
      }
    }'

Die Einschränkungen zwischen den beiden Einstellungen finden Sie unter. Einschränkungen zwischen gres.conf und der Gres-Einstellung Da AWS PCS Geräte, die beim Systemstart erkannt werden, nicht zählen kann, akzeptiert es alle Profilnamen und zählt in der Gres Einstellung für einen Datensatz, der nur aktiviert istAutoDetect. Die Konsistenz mit den tatsächlichen MIG-Instanzen wird erst überprüft, wenn sich der Knoten registriert.

Wenn ein Knoten bootet und sich registriert, kündigt er beispielsweise Gres=gpu:3g.20gb:8(S:0),gpu:1g.5gb:28(S:1) die erkannten Profile mit ihrer Socket-Affinität an. Ein Job, der ein Profil anfordert, wie z. B.--gres=gpu:3g.20gb:1, wird auf einer einzelnen MIG-Instance platziert und erhält seine UUID CUDA_VISIBLE_DEVICES (z. B.MIG-e7aa6185-06d5-53e9-a4d9-00f7670f741e), sodass CUDA den Job auf diese MIG-Instance beschränkt.

Einschränkungen

Da eine MIG-Konfiguration keine Geräte benennt, kennt der Controller das tatsächliche GRES eines Knotens erst, nachdem der Knoten gestartet und registriert wurde. Bis sich ein Knoten einmal registriert hat, speichert der Controller nur die Profilwerte aus der Gres Einstellung. Dies führt zu der folgenden Einschränkung. Sie gilt für jeden GPU-Datensatz, der nur aktiviert istAutoDetect, und somit für jede MIG-Rechenknotengruppe.

Jobs, die zugewiesen werden, bevor sich ein Knoten zum ersten Mal registriert, können ohne GPU gestartet werden

Einem Auftrag, der einem Knoten zugewiesen ist, der heruntergefahren ist und sich noch nie registriert hat, beispielsweise beim ersten Start einer neu erstellten Rechenknotengruppe, wird eine Profilanzahl zugewiesen, aber kein bestimmtes Gerät, da die Geräte noch nicht bekannt sind. Wenn der Knoten dann bootet und der Job gestartet wird, ist dem Job kein MIG-Gerät zugewiesen: CUDA_VISIBLE_DEVICES ist nicht gesetzt, und da AWS PCS den Gerätezugriff nicht über Cgroups einschränkt, kann der Job jedes MIG-Gerät auf dem Knoten verwenden. Slurm meldet den Job als RUNNING ob, und die MIG-Instanz, für die der Job gezählt wurde, wird dem nächsten Job zugewiesen, der dieses Profil anfordert, sodass beide Jobs auf derselben MIG-Instance landen können. Jobs, die dem Knoten zugewiesen werden, nachdem er sich einmal registriert hat, auch nach späteren Aus- und Einschaltzyklen, erhalten ihr Gerät wie erwartet.

Um diesen Zustand zu erkennen, stellen Sie zu Beginn des Jobs sicher, dass der Job eingerichtet CUDA_VISIBLE_DEVICES ist, und beenden Sie den Job oder stellen Sie ihn erneut in die Warteschlange, wenn nicht:

if [ -z "${CUDA_VISIBLE_DEVICES-}" ]; then
    scontrol requeue "$SLURM_JOB_ID"
    exit 1
fi

Ein Auftrag, der in die Warteschlange gestellt wurde, kann nach dem requeue_delay Scheduler-Parameter erneut ausgeführt werden, standardmäßig 5 Sekunden. Bis dahin hat sich der Knoten registriert, sodass der Job beim nächsten Start ein Gerät erhält.