Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # 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 di`gres.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. `slurmd`kemudian menemukan perangkat MIG saat node melakukan booting. AWS PCS mendukung`AutoDetect`, 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 + Grup simpul komputasi yang menggunakan tipe MIG-capable instance. + Slurm versi 25.11 atau yang lebih baru. + Topologi CPU yang dikonfigurasi. Deteksi otomatis GPU memerlukan tata letak soket node. Pada Slurm 25.11, atur `Sockets` untuk grup simpul komputasi; pada Slurm 26.05 dan yang lebih baru, PCS mengonfigurasinya secara otomatis. AWS Untuk informasi selengkapnya, lihat [Mengkonfigurasi topologi perangkat keras di AWS PCS](hardware-topology.md). ## 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: 1. **Mode MIG diaktifkan ** pada setiap GPU yang melayani instans MIG. `nvidia-smi -q`melaporkan a `Current` dan a `Pending` mode, dan `Current` harus demikian`Enabled`. 1. **Instans MIG ada**, baik instans GPU maupun instans komputasi, untuk setiap profil dalam pengaturan grup simpul komputasi. `Gres` 1. **Profil dan hitungan cocok ** dengan `Gres` pengaturan. Jika mode MIG diaktifkan tetapi tidak ada instans MIG, `slurmd` temukan GPU induk tetapi tidak ada perangkat MIG. Itu mencatat`MIG 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 gagal`Required 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](#mig-configuration-instances-nla) 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](#mig-configuration-instances-nla). 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](#mig-configuration-instances-pending). Untuk informasi selengkapnya tentang perintah, lihat Panduan Multi-Instance Pengguna GPU [ NVIDIA](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/). 1. Aktifkan mode MIG pada GPU: ``` nvidia-smi -mig 1 ``` Perubahan mode tidak dapat berlaku saat proses menggunakan GPU. Pada `nodeBootstrapped` tahap `slurmd` belum dimulai, jadi pada node yang tidak menjalankan layanan GPU lain, perubahan berlaku tanpa reboot. Periksa apakah mode yang diterapkan ada `Enabled` di setiap GPU dengan`nvidia-smi --query-gpu=mig.mode.current --format=csv`. **penting** Jika mode MIG tetap`Pending`, proses lain membuka GPU. Lihat [Jika mode MIG tetap tertunda](#mig-configuration-instances-pending). 1. Buat instance GPU dan instans komputasi untuk profil yang Anda inginkan. Misalnya, untuk mempartisi masing-masing 8 GPU menjadi satu`3g.20gb`, satu`2g.10gb`, dan dua `1g.5gb` contoh: ``` 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`juga menerima ID profil numerik, tetapi ID yang sama berarti profil yang berbeda pada model GPU yang berbeda: `9,14,19,19` apakah tata letak ini pada 40 GB A100 dalam sebuah `p4d` contoh, dan`3g.40gb`,`2g.20gb`, dan dua `1g.10gb` pada bagian 80 GB. Gunakan nama profil, sehingga cocok dengan `Gres` pengaturan dan pembuatan gagal pada GPU yang tidak memiliki profil seperti itu. Buat profil terbesar terlebih dahulu, seperti pada contoh. Penempatan MIG sudah diperbaiki, sehingga tata letak yang sesuai masih dapat gagal dibuat jika profil kecil mengambil irisan yang dibutuhkan yang besar. ### Menerapkan konfigurasi dengan tindakan siklus hidup simpul Konfigurasikan tindakan siklus hidup simpul sebagai berikut. Untuk cara menambahkan satu ke grup simpul komputasi, lihat[Konfigurasikan tindakan siklus hidup simpul di AWS PCS](cng-node-lifecycle-actions-configure.md). | **Bidang** | **Nilai** | **Mengapa ** | | --- | --- | --- | | Tahap siklus hidup | `nodeBootstrapped` | Berjalan sebelum `slurmd` membuka GPU dan mendaftarkan node. | | `executionPolicy` | `EVERY_BOOT` | Status MIG tidak selamat dari penghentian, penangguhan, atau penghentian. | | `arguments` | `["3g.20gb,2g.10gb,1g.5gb,1g.5gb"]` | Profil MIG yang akan dibuat pada setiap GPU, berdasarkan nama. Satu skrip kemudian melayani grup simpul komputasi dengan tata letak yang berbeda. | | `onError` | `TERMINATE` | Mengganti node yang tidak dapat dipartisi alih-alih membiarkannya mendaftar tanpa perangkat MIG-nya. Saat men-debug, gunakan `STOP_SEQUENCE` untuk menyimpan instance untuk diperiksa. | 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, lihat[Meneruskan argumen ke skrip](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 ``` Untuk mengatur skrip dan pengaturan GRES dalam satu panggilan, lihat contoh di[Deklarasikan profil MIG ke Slurm](#mig-configuration-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, lihat[Logging dan debugging](cng-node-lifecycle-actions-configure.md#cng-node-lifecycle-actions-configure-logging). ### Jika mode MIG tetap tertunda Mengaktifkan mode MIG gagal saat proses apa pun memiliki GPU terbuka. `nvidia-smi`melaporkan pengaktifan sebagai tertunda`In 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: + **Hentikan proses yang menahan GPU. ** Di AMI kustom, nonaktifkan atau hapus daemon apa pun yang membuka GPU sebelum konfigurasi MIG berjalan. Juga hapus daemon apa pun yang mengkonfigurasi MIG itu sendiri. Dua komponen yang mempartisi GPU yang sama menghasilkan tata letak yang tidak sesuai dengan pengaturan. `Gres` + **Konfigurasikan MIG di boothook. ** Jika Anda tidak dapat menghentikan proses, pindahkan perubahan mode MIG dan pembuatan profil ke `cloud-init` boothook di data pengguna template peluncuran. Boothook berjalan sebelum bootstrap AWS PCS dan sebelum layanan AMI dimulai, sehingga perubahan mode berlaku tanpa reboot. Untuk cara menulisnya, lihat[Contoh: Jalankan operasi boot awal dengan boothook cloud-init](working-with_ec2-user-data_early-boot.md). Simpan tindakan siklus hidup sebagai pemeriksaan: pada setiap boot itu mengonfirmasi tata letak dan gagal node jika boothook tidak menerapkannya. ## Deklarasikan profil MIG ke Slurm Deklarasikan kedua pengaturan GRES pada grup simpul komputasi: + Dalam`gresCustomSettings`, catatan GPU yang hanya mengaktifkan`AutoDetect`. Jangan mengatur`Name`,`Type`, atau`File`. Perangkat MIG ditemukan di node. + Dalam`slurmCustomSettings`, `Gres` pengaturan yang mendeklarasikan profil MIG dan penghitungan yang dapat diminta oleh pekerjaan. Nama profil dan jumlah harus sesuai dengan instans MIG yang dibuat pada node. **Example - Menerapkan kedua bagian dalam satu pembaruan (8 GPU, masing-masing dipartisi menjadi satu `3g.20gb, satu 2 g.10gb`, dan dua 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" } ] } }' ``` Contoh meneruskan kedua parameter sebagai JSON karena nil `Gres` ainya berisi koma, yang perlu dihindari oleh sintaks steno CLI. Tet `arguments` ap dan `Gres` konsisten: `3g.20gb,2g.10gb,1g.5gb,1g.5gb` pada masing-masing 8 GPU memberikan 8, 8, dan 16 instance yang `gpu:3g.20gb:8,gpu:2g.10gb:8,gpu:1g.5gb:16` menyatakan. Untuk batasan antara dua pengaturan, lihat[Kendala antara gres.conf dan pengaturan Gres](gres-custom-settings.md#gres-custom-settings-constraints). 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 mengaktifkan`AutoDetect`. 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, misalnya`Gres=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. **catatan** Pengontrol mencatat peringatan seperti `Ignoring file-less GPU gpu:3g.20gb from final GRES list` untuk catatan MIG. Ini diharapkan: GRES otoritatif berasal dari pendaftaran node. ## 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 memungkinkan`AutoDetect`, dan oleh karena itu untuk setiap grup simpul komputasi MIG. **catatan** Sebagai praktik terbaik, gunakan grup simpul komputasi statis untuk MIG: setel `minInstanceCount` sama dengan `maxInstanceCount` dalam konfigurasi penskalaan. Node kemudian mendaftar ketika diluncurkan, sebelum pekerjaan apa pun dialokasikan kepada mereka, yang menghindari batasan. ### 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.