Mengkonfigurasi Multi-Instance GPU (MIG) di AWS PCS

NVIDIA Multi-Instance GPU (MIG) mempartisi GPU yang didukung ke dalam instans GPU terisolasi, masing-masing dengan memori dan sumber daya komputasi sendiri. Slurm menjadwalkan setiap profil MIG sebagai tipe Generic Resource (GRES) sendiri, sehingga beberapa pekerjaan dapat berbagi satu GPU fisik dengan isolasi perangkat keras.

Perangkat MIG tidak dapat dijelaskan secara statis digres.conf: file perangkat dan UUID mereka hanya ada setelah instance MIG dibuat pada node yang di-boot, jadi tidak ada File atau Type nilai untuk dikonfigurasi sebelumnya. Pada AWS PCS Anda mengonfigurasi MIG dengan gres.conf catatan yang hanya AutoDetect mengaktifkan, bersama dengan Gres pengaturan yang mendeklarasikan profil. slurmdkemudian menemukan perangkat MIG saat node melakukan booting. AWS PCS mendukungAutoDetect, dan karena itu MIG, pada Slurm versi 25.11 dan yang lebih baru.

Mengkonfigurasi MIG berarti mempartisi GPU pada setiap node dan mendeklarasikan profil yang dihasilkan ke Slurm pada grup node komputasi. Tidak ada yang bekerja sendiri, jadi terapkan keduanya dalam satu perubahan. Jika Slurm tidak tahu tentang partisi node, node tidak memiliki GRES yang dapat dijadwalkan. Jika tidak ada node yang membuat profil yang dideklarasikan, node akan terkuras saat mendaftar. Dengan tindakan siklus hidup simpul yang direkomendasikan, satu pembaruan grup simpul komputasi membawa skrip partisi dan pengaturan GRES.

Prasyarat

Apa yang harus dimiliki node MIG pada setiap boot

Mode MIG dan instans MIG hidup di GPU, bukan pada disk, sehingga AMI khusus tidak dapat membawanya, dan mereka hilang setiap kali instance dihentikan, ditangguhkan, atau dihentikan. Pada setiap boot, semua hal berikut harus benar sebelum slurmd memulai:

Jika mode MIG diaktifkan tetapi tidak ada instans MIG, slurmd temukan GPU induk tetapi tidak ada perangkat MIG. Itu mencatatMIG mode is enabled, but no MIG devices were found, lalu Discarding the following config-only GPU due to lack of File specification untuk setiap profil yang dideklarasikan. Karena node melaporkan lebih sedikit GPU daripada yang din Gres yatakan, pengontrol menolak pendaftaran dan menguras node dengan alas gres/gpu count reported lower than configured annya. Pekerjaan yang meminta GPU pada node gagalRequired node not available. Membuat instance MIG sesudahnya tidak menguras simpul; Anda harus melanjutkan atau menggantinya. Tindakan siklus hidup simpul yang dijelaskan dalam Menerapkan konfigurasi dengan tindakan siklus hidup simpul menghindari hal ini dengan mengecewakan node sebelum mendaftar.

Konfigurasikan MIG pada instance

Mengkonfigurasi instance membutuhkan dua operasi berikut. Jalankan mereka dari tindakan siklus hidup node, yang menjaga logika pada grup simpul komputasi alih-alih di AMI yang harus Anda bangun kembali. Lihat Menerapkan konfigurasi dengan tindakan siklus hidup simpul. Jika proses lain sudah memegang GPU pada saat itu, jalankan sebelumnya dari cloud-init boothook atau systemd unit di AMI khusus. Lihat Jika mode MIG tetap tertunda. Untuk informasi selengkapnya tentang perintah, lihat Panduan Multi-Instance Pengguna GPU NVIDIA.

Menerapkan konfigurasi dengan tindakan siklus hidup simpul

Konfigurasikan tindakan siklus hidup simpul sebagai berikut. Untuk cara menambahkan satu ke grup simpul komputasi, lihatKonfigurasikan tindakan siklus hidup simpul di AWS PCS.

Skrip yang berjalan pada setiap boot harus idempotent. Garis besar berikut mengambil tata letak per-GPU sebagai argumen pertamanya dan menangani satu GPU pada satu waktu. Ini melewatkan GPU yang sudah memiliki tata letak itu, mempartisi ulang yang lain, dan keluar bukan nol jika tidak dapat selesai, yang mengecewakan node. Itu tidak pernah me-reboot node. Untuk bagaimana argumen mencapai skrip, lihatMeneruskan argumen ke skrip.

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

Untuk mengatur skrip dan pengaturan GRES dalam satu panggilan, lihat contoh diDeklarasikan profil MIG ke Slurm.

Jika Anda mengadaptasi skrip, simpan kedua cek. Tanpa pemeriksaan mode, node yang mode MIG-nya tidak pernah menjadi Enabled melanjutkan untuk mendaftar tanpa perangkat MIG-nya, dan penyebabnya hanya muncul di slurmd log. Tanpa pemeriksaan tata letak, node yang membuat profil yang salah mendaftar secara normal dan gagal hanya pekerjaan yang meminta profil yang dideklarasikan. Untuk di mana output skrip ditulis, lihatLogging dan debugging.

Jika mode MIG tetap tertunda

Mengaktifkan mode MIG gagal saat proses apa pun memiliki GPU terbuka. nvidia-smimelaporkan pengaktifan sebagai tertundaIn use by another client, misalnya dengan, dan itu berlaku hanya setelah proses tersebut keluar atau node reboot. Pada node komputasi AWS PCS prosesnya biasanya merupakan agen pemantauan GPU, seperti NVIDIA DCGM atau agen yang dikirimkan dalam AMI, atau slurmd itu sendiri jika MIG dikonfigurasi setelah slurmd dimulai. Anda tidak dapat melakukan reboot dari tindakan siklus hidup, jadi gunakan salah satu perbaikan berikut:

Deklarasikan profil MIG ke Slurm

Deklarasikan kedua pengaturan GRES pada grup simpul komputasi:

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

Untuk batasan antara dua pengaturan, lihatKendala antara gres.conf dan pengaturan Gres. Karena AWS PCS tidak dapat menghitung perangkat yang ditemukan saat boot, PCS menerima nama profil dan penghitungan apa pun dalam Gres pengaturan untuk catatan yang hanya mengaktifkanAutoDetect. Konsistensi dengan instans MIG aktual hanya diverifikasi ketika node mendaftar.

Ketika sebuah node melakukan boot dan mendaftar, ia mengiklankan profil yang ditemukan dengan afinitas soketnya, misalnyaGres=gpu:3g.20gb:8(S:0),gpu:1g.5gb:28(S:1). Pekerjaan yang meminta profil, seperti--gres=gpu:3g.20gb:1, ditempatkan pada satu instance MIG dan mendapatkan UUID-nya di CUDA_VISIBLE_DEVICES (misalnya,MIG-e7aa6185-06d5-53e9-a4d9-00f7670f741e), sehingga CUDA membatasi pekerjaan ke instance MIG tersebut.

Batasan

Karena konfigurasi MIG tidak menamai perangkat, pengontrol hanya mengetahui GRES asli node setelah node melakukan boot dan mendaftar. Sampai node terdaftar sekali, pengontrol hanya menyimpan jumlah profil dari Gres pengaturan. Hal ini menyebabkan keterbatasan berikut. Ini berlaku untuk catatan GPU apa pun yang hanya memungkinkanAutoDetect, dan oleh karena itu untuk setiap grup simpul komputasi MIG.

Pekerjaan yang dialokasikan sebelum node pertama mendaftar dapat dimulai tanpa GPU

Pekerjaan yang dialokasikan ke node yang dimatikan dan belum pernah terdaftar, misalnya pada boot pertama dari grup simpul komputasi yang baru dibuat, diberikan jumlah profil tetapi tidak ada perangkat tertentu, karena perangkat belum diketahui. Ketika node kemudian di-boot dan pekerjaan dimulai, pekerjaan tidak memiliki perangkat MIG yang ditetapkan: tidak CUDA_VISIBLE_DEVICES disetel, dan karena AWS PCS tidak membatasi akses perangkat melalui cgroups, pekerjaan dapat menggunakan setiap perangkat MIG di node. Slurm melaporkan pekerjaan RUNNING seolah-olah, dan instance MIG yang dihitung pekerjaan ditugaskan ke pekerjaan berikutnya yang meminta profil itu, sehingga kedua pekerjaan dapat berakhir pada instance MIG yang sama. Pekerjaan yang dialokasikan ke node setelah terdaftar sekali, termasuk setelah siklus power down dan power-up nanti, mendapatkan perangkat mereka seperti yang diharapkan.

Untuk mendeteksi kondisi ini, verifikasi di awal pekerjaan yang CUDA_VISIBLE_DEVICES disetel, dan keluar atau minta pekerjaan jika tidak:

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

Pekerjaan yang diminta menjadi memenuhi syarat untuk dijalankan lagi setelah parameter pen requeue_delay jadwal, 5 detik secara default. Pada saat itu node telah terdaftar, sehingga pekerjaan mendapatkan perangkat pada awal berikutnya.