Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # 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 in`gres.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 wird`AutoDetect`, zusammen mit einer `Gres` Einstellung, die die Profile deklariert. `slurmd`erkennt 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 + Eine Compute-Knotengruppe, die einen MIG-capable Instanztyp verwendet. + Slurm-Version 25.11 oder höher. + Konfigurierte CPU-Topologie. Für die automatische GPU-Erkennung ist das Socket-Layout des Knotens erforderlich. Auf Slurm 25.11 auf die Compute-Knotengruppe eingestellt`Sockets`; auf Slurm 26.05 und höher konfiguriert PCS sie automatisch. AWS Weitere Informationen finden Sie unter [Konfiguration der Hardwaretopologie in AWS STCK](hardware-topology.md). ## 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: 1. **Der MIG-Modus ist ** auf jeder GPU aktiviert, die MIG-Instanzen bedient. `nvidia-smi -q`meldet einen `Current` und einen `Pending` Modus und `Current` muss es sein`Enabled`. 1. **Die MIG-Instanzen**, sowohl GPU-Instanzen als auch Compute-Instances, sind für jedes Profil in der `Gres` Einstellung der Compute-Knotengruppe vorhanden. 1. **Die Profile und die Anzahl entsprechen ** der `Gres` Einstellung. Wenn der MIG-Modus aktiviert ist, aber keine MIG-Instanzen vorhanden sind, `slurmd` findet er die übergeordneten GPUs, aber kein MIG-Gerät. Es protokolliert`MIG 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](#mig-configuration-instances-nla) 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](#mig-configuration-instances-nla). 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](#mig-configuration-instances-pending). Weitere Informationen zu den Befehlen finden Sie im [ NVIDIA Multi-Instance GPU-Benutzerhandbuch. ](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/) 1. Aktivieren Sie den MIG-Modus auf den GPUs: ``` nvidia-smi -mig 1 ``` Die Modusänderung kann nicht wirksam werden, solange ein Prozess die GPUs verwendet. Da die `nodeBootstrapped` Phase `slurmd` noch nicht gestartet wurde, wird die Änderung auf einem Knoten, auf dem kein anderer GPU-Dienst ausgeführt wird, ohne dass ein Neustart erforderlich ist, wirksam. Vergewissern Sie sich, dass der angewendete Modus `Enabled` auf jeder GPU mit aktiviert ist`nvidia-smi --query-gpu=mig.mode.current --format=csv`. **Wichtig** Bleibt der MIG-Modus bestehen`Pending`, sind die GPUs bei einem anderen Prozess geöffnet. Siehe [Wenn der MIG-Modus weiterhin aussteht](#mig-configuration-instances-pending). 1. Erstellen Sie die GPU-Instanzen und berechnen Sie Instanzen für die gewünschten Profile. Um beispielsweise jede der 8 GPUs in eine `3g.20gb``2g.10gb`, eine und zwei `1g.5gb` Instanzen zu partitionieren: ``` 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`akzeptiert auch numerische Profil-IDs, aber dieselbe ID bedeutet ein anderes Profil auf einem anderen GPU-Modell: `9,14,19,19` ist dieses Layout auf dem 40-GB-A100 in einer `p4d` Instanz und `3g.40gb``2g.20gb`, und zwei `1g.10gb` auf einem 80-GB-Teil. Verwenden Sie die Profilnamen so, dass sie der `Gres` Einstellung entsprechen und die Erstellung auf einer GPU, die kein solches Profil hat, fehlschlägt. Erstellen Sie zuerst die größten Profile, wie im Beispiel. MIG-Platzierungen sind festgelegt, sodass ein passendes Layout immer noch nicht erstellt werden kann, wenn die kleinen Profile die Abschnitte einnehmen, die die großen Profile benötigen. ### 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 unter[Konfigurieren Sie Node-Lifecycle-Aktionen in AWS STCK](cng-node-lifecycle-actions-configure.md). | **Feld** | **Wert** | **Warum ** | | --- | --- | --- | | Phase des Lebenszyklus | `nodeBootstrapped` | Wird ausgeführt, bevor die GPUs `slurmd` geöffnet und der Knoten registriert wird. | | `executionPolicy` | `EVERY_BOOT` | Der MIG-Status übersteht einen Stopp, eine Aussetzung oder eine Kündigung nicht. | | `arguments` | `["3g.20gb,2g.10gb,1g.5gb,1g.5gb"]` | Die MIG-Profile, die auf jeder GPU erstellt werden sollen, namentlich. Ein Skript dient dann zur Berechnung von Knotengruppen mit unterschiedlichen Layouts. | | `onError` | `TERMINATE` | Ersetzt einen Knoten, der nicht partitioniert werden kann, anstatt ihn ohne seine MIG-Geräte registrieren zu lassen. Verwenden Sie diese Option beim Debuggen, `STOP_SEQUENCE` um die Instanz zur Überprüfung aufzubewahren. | 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](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 ``` Informationen zum Festlegen des Skripts und der GRES-Einstellungen in einem Aufruf finden Sie im [Deklarieren Sie die MIG-Profile für Slurm](#mig-configuration-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 wurde`Enabled`, 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 unter[Loggen und Debuggen](cng-node-lifecycle-actions-configure.md#cng-node-lifecycle-actions-configure-logging). ### Wenn der MIG-Modus weiterhin aussteht Die Aktivierung des MIG-Modus schlägt fehl, solange bei einem Prozess die GPUs geöffnet sind. `nvidia-smi`meldet die Aktivierung als ausstehend, z. B. mit`In 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: + **Stoppen Sie den Prozess, der die GPUs enthält. ** Deaktivieren oder entfernen Sie im benutzerdefinierten AMI alle Daemons, die die GPUs öffnen, bevor die MIG-Konfiguration ausgeführt wird. Entfernen Sie auch alle Daemons, die MIG selbst konfiguriert. Zwei Komponenten, die dieselben GPUs partitionieren, erzeugen ein Layout, das nicht der Einstellung entspricht. `Gres` + **Konfigurieren Sie MIG in einem Boothook. ** Wenn Sie den Vorgang nicht stoppen können, verschieben Sie den MIG-Moduswechsel und die Profilerstellung in einen `cloud-init` Boothook in den Benutzerdaten der Startvorlage. Ein Boothook wird vor dem AWS PCS-Bootstrap und vor dem Start der AMI-Dienste ausgeführt, sodass die Modusänderung ohne Neustart wirksam wird. Wie man einen schreibt, finden Sie unter. [Beispiel: Führen Sie frühe Startvorgänge mit einem Cloud-Init-Boothook aus](working-with_ec2-user-data_early-boot.md) Behalten Sie die Lifecycle-Aktion im Auge: Bei jedem Systemstart wird das Layout bestätigt und der Node schlägt fehl, wenn der Boothook es nicht angewendet hat. ## Deklarieren Sie die MIG-Profile für Slurm Deklarieren Sie beide GRES-Einstellungen für die Compute-Knotengruppe: + In`gresCustomSettings`, ein GPU-Datensatz, der nur aktiviert`AutoDetect`. Stellen Sie nicht `Name` ein`Type`, oder`File`. Die MIG-Geräte werden auf dem Knoten erkannt. + In`slurmCustomSettings`, eine `Gres` Einstellung, die die MIG-Profile und die Anzahl der MIG-Profile deklariert, die Jobs anfordern können. Die Profilnamen und die Anzahl müssen mit den auf dem Knoten erstellten MIG-Instanzen übereinstimmen. **Example — Anwenden beider Teile in einem Update (8 GPUs, jede partitioniert in eine `3G.20gb`, eine `` 2G.10gb und zwei 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" } ] } }' ``` Im Beispiel werden beide Parameter als JSON übergeben, da der `Gres` Wert Kommas enthält. Diese CLI-Kurzsyntax müsste maskiert werden. Behalten `arguments` und `Gres` konsistent: `3g.20gb,2g.10gb,1g.5gb,1g.5gb` Auf jeder der 8 GPUs werden die 8, 8 und 16 Instanzen angezeigt, die deklariert werden. `gpu:3g.20gb:8,gpu:2g.10gb:8,gpu:1g.5gb:16` Die Einschränkungen zwischen den beiden Einstellungen finden Sie unter. [Einschränkungen zwischen gres.conf und der Gres-Einstellung](gres-custom-settings.md#gres-custom-settings-constraints) 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 ist`AutoDetect`. 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. **Anmerkung** Der Controller protokolliert Warnungen, z. B. `Ignoring file-less GPU gpu:3g.20gb from final GRES list` für MIG-Datensätze. Dies wird erwartet: Das autoritative GRES stammt aus der Knotenregistrierung. ## 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 ist`AutoDetect`, und somit für jede MIG-Rechenknotengruppe. **Anmerkung** Verwenden Sie als bewährte Methode eine statische Rechenknotengruppe für MIG: `maxInstanceCount` in der Skalierungskonfiguration auf `minInstanceCount` gleich gesetzt. Die Knoten registrieren sich dann, wenn sie gestartet werden, bevor ihnen ein Job zugewiesen wird, wodurch die Beschränkung umgangen wird. ### 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.