UltraServer arsitektur Plugin topologi slurm Praktik terbaik Batasan

Menggunakan penjadwalan sadar topologi di Amazon SageMaker HyperPod

Efisiensi transfer data merupakan faktor penting dalam komputasi kinerja tinggi (HPC) dan beban kerja pembelajaran mesin. Saat menggunakan UltraServers dengan Amazon SageMaker HyperPod, SageMaker HyperPod secara otomatis menerapkan label topologi ke sumber daya Anda. Topology-aware penjadwalan membantu mengalokasikan sumber daya untuk meminimalkan overhead transfer data dengan mempertimbangkan topologi instance (bagaimana sumber daya terhubung dalam sebuah instance) dan topologi jaringan (bagaimana instance terhubung satu sama lain). Untuk informasi selengkapnya tentang topologi instans, lihat topologi instans Amazon EC2.

Topology-aware penjadwalan berfungsi dengan kedua cluster di Slurm dan Amazon EKS. Untuk informasi umum tentang cara kerja topologi dengan Slurm, lihat panduan Topologi dalam dokumentasi Slurm.

Di Amazon SageMaker HyperPod, overhead transfer data biasanya berasal dari tiga sumber utama:

GPU-to-GPU transfer data: Teknologi modern seperti sakelar NVLink dan NVLink memungkinkan transfer data throughput tinggi antar GPU tanpa melibatkan sumber daya komputasi lainnya. Ini sangat efisien tetapi biasanya terbatas pada satu contoh.
GPU-to-CPU transfer data: sistem akses Non-uniform memori (NUMA) memiliki beberapa bus sistem pada satu motherboard. Dalam arsitektur instans EC2 yang khas seperti p5.48xlarge, ada dua bus sistem yang berbeda, masing-masing dengan CPU dan 4 GPU. Untuk kinerja optimal, proses yang memuat atau membaca to/from GPU data harus dijalankan pada CPU yang terhubung ke bus sistem yang sama dengan GPU.
Komunikasi jaringan antar instance: Instans mentransfer data melalui rantai sakelar jaringan. Jalur terpendek biasanya sesuai dengan latensi terendah.

UltraServer arsitektur

SageMaker HyperPod mendukung UltraServer arsitektur dengan instance p6e-gb200.36xlarge. Sebuah UltraServer berisi hingga 18 instans p6e-gb200.36xlarge, dengan 4 GPU pada setiap instance. Semua GPU di semua node saling berhubungan melalui switch NVLink, memungkinkan transfer data antara dua GPU tanpa menggunakan antarmuka jaringan.

Arsitektur ini memberikan peningkatan kinerja yang signifikan dibandingkan dengan instance individual. Untuk memanfaatkan arsitektur ini secara efektif, pekerjaan harus diserahkan ke node komputasi dari satu UltraServer.

Label topologi EKS

Sesuai dengan topologi instans EC2, HyperPod secara otomatis memberi label pada node Anda dengan label berikut:

topology.kubernetes. io/region- Wilayah AWS yang node berada di.
topology.kubernetes. io/zone- Availability Zone tempat node berada.
topology.k8s. aws/network-node-layer - NetworkNodes menjelaskan kumpulan node jaringan dari sebuah instance. Dalam setiap set node jaringan, node jaringan terdaftar dalam urutan hierarkis dari atas ke bawah. Node jaringan yang terhubung ke instance adalah node jaringan terakhir dalam daftar. Ada hingga empat lapisan node jaringan, dan setiap node ditandai dengan label. Lapisan yang tersedia adalahtopology.k8s.aws/network-node-layer-1,topology.k8s.aws/network-node-layer-2,topology.k8s.aws/network-node-layer-3.
topology.k8s. aws/ultraserver-id - Pengidentifikasi yang digunakan untuk memberi label pada setiap instance milik domain NVLink yang sama di Ultraserver. Untuk mempelajari lebih lanjut tentang menggunakan UltraServers dengan SageMaker HyperPod, lihatMenggunakan UltraServers di Amazon SageMaker HyperPod.

Dengan menggunakan label ini, Anda dapat menggunakan penjadwalan sadar topologi dalam tata kelola HyperPod tugas untuk menerapkan label topologi dan anotasi guna mengoptimalkan efisiensi pelatihan beban kerja Anda. Untuk informasi selengkapnya, lihat Menggunakan penjadwalan sadar topologi di tata kelola tugas Amazon SageMaker HyperPod.

Plugin topologi jaringan slurm

Slurm menyediakan plugin bawaan untuk kesadaran topologi jaringan. SageMaker HyperPod secara otomatis memilih dan mengonfigurasi plugin topologi yang sesuai berdasarkan jenis instance di cluster Anda.

Pemilihan topologi otomatis

Saat Anda membuat klaster HyperPod Slurm, sistem akan memeriksa semua grup instans dan jenis instans terkait, mengidentifikasi karakteristik komunikasi GPU dari setiap jenis instance, dan mengonfigurasi Slurm dengan plugin topologi yang sesuai. Proses ini berjalan secara otomatis dan tidak memerlukan konfigurasi apa pun.

HyperPod mengelola topologi melalui file konfigurasi yang dihasilkan secara dinamis. Pada Slurm 25.11 dan yang lebih baru, topologi didefinisikan dalam sebuah topology.yaml file, yang merupakan sumber kebenaran dan mendukung beberapa definisi topologi dan penugasan per partisi. Pada Slurm 24.x, topologi didefinisikan dalam topology.conf file dengan topologi luster-lebar tunggal. Saat cluster berkembang melalui operasi penskalaan atau penggantian node, HyperPod terus merekonsiliasi konfigurasi topologi untuk mencerminkan status cluster saat ini. Untuk informasi selengkapnya, lihat Pembaruan topologi dinamis.

Jenis instans yang mendukung topologi jaringan

HyperPod mengonfigurasi topologi pohon atau blok untuk jenis instans yang mendukung topologi instans Amazon EC2. Untuk daftar jenis instans yang didukung yang otoritatif dan terkini, lihat Prasyarat untuk topologi Amazon EC2 di Panduan Pengguna Amazon EC2.

Jenis instans yang didukung termasuk keluarga komputasi yang dipercepat seperti G6e, G7e, P4d, P4de, P5, P5e, P5en, dan, serta keluarga AWS Trainium seperti Trn1, Trn1n P6e-GB200, dan Trn2. UltraServertipe instance (misalnya,ml.p6e-gb200.36xlarge) menggunakan topologi blok, dan tipe instance berkemampuan topologi lainnya menggunakan topologi pohon.

Menggunakan topology/tree plugin

topology/treePlugin memodelkan struktur komunikasi hierarkis dengan beberapa tingkatan bandwidth. Topologi pohon memungkinkan Slurm untuk menempatkan pekerjaan dengan cara yang meminimalkan komunikasi lintas tingkat dan memaksimalkan lokalitas.

Topologi pohon digunakan untuk tipe contoh dengan interkoneksi hierarkis, di mana beban kerja pelatihan terdistribusi mendapat manfaat dari penempatan sadar lokal. Ini termasuk jenis instance sepertiml.p5.48xlarge,ml.p5e.48xlarge, danml.p5en.48xlarge.

SageMaker HyperPod secara otomatis mengonfigurasi topology/tree plugin saat klaster Anda menggunakan jenis instance ini. Konfigurasi topologi yang dihasilkan memetakan node ke dalam hierarki sakelar yang mencerminkan tingkatan komunikasi perangkat keras Anda.

Pastikan Anda slurm.conf termasuk:


TopologyPlugin=topology/tree

Konfigurasi

SageMaker HyperPod secara otomatis mengonfigurasi topologi pohon berdasarkan informasi yang diberikan oleh Amazon EC2. Untuk detail selengkapnya tentang topologi Amazon EC2, lihat topologi instans Amazon EC2.

Pada Slurm 25.11 dan yang lebih baru, HyperPod mendefinisikan topologi ditopology.yaml, yang merupakan sumber kebenaran. Entri topologi pohon memetakan node ke dalam hierarki sakelar yang mencerminkan tingkatan komunikasi perangkat keras Anda:


- topology: tree
  cluster_default: true
  tree:
    switches:
      - switch: root
        children: leaf-0,leaf-1
      - switch: leaf-0
        nodes: compute-1,compute-2
      - switch: leaf-1
        nodes: compute-3,compute-4

Pada Slurm 24.x, topologi pohon didefinisikan topology.conf sebagai gantinya, yang menggunakan format berikut:


SwitchName=nn-6fe9d8a965d34d181 Switches=nn-0b53107754517bf0e

SwitchName=nn-0b53107754517bf0e Switches=nn-424c855d4ad825aa4,nn-95acd7c656329fc30

SwitchName=nn-424c855d4ad825aa4 Nodes=ip-10-1-111-198
SwitchName=nn-95acd7c656329fc30 Nodes=ip-10-1-53-231

Penggunaan

Ketika topology/tree plugin dikonfigurasi, Slurm mencoba mengalokasikan mesin yang dekat satu sama lain. Anda dapat memaksa Slurm untuk mengalokasikan mesin pada satu sakelar dengan meneruskan parameter baris --switch perintah ke atau: sbatch srun


sbatch --switch=1 ....

Menggunakan topology/block plugin

NVIDIA mengembangkan topology/block plugin yang menyediakan penjadwalan hierarkis di seluruh blok node dengan karakteristik sebagai berikut:

Blok adalah rentang node yang berurutan
Blok tidak dapat tumpang tindih satu sama lain
Semua node dalam blok dialokasikan ke pekerjaan sebelum blok berikutnya digunakan
Ukuran blok perencanaan adalah ukuran blok terkecil yang dikonfigurasi
Setiap ukuran level blok yang lebih tinggi adalah kekuatan dua dari yang sebelumnya

Plugin ini mengalokasikan node berdasarkan topologi jaringan yang ditentukan.

Model topologi blok seragam, domain komunikasi bandwidth tinggi di mana semua GPU berpartisipasi dalam satu domain berkecepatan tinggi dengan latensi hampir seragam. Topologi blok memperlakukan semua node sebagai bagian dari satu unit komunikasi kohesif. UltraServer arsitektur dalam SageMaker HyperPod mendukung plugin blok.

Topologi blok digunakan untuk jenis UltraServer contoh seperti. ml.p6e-gb200.36xlarge

Pastikan Anda slurm.conf termasuk:


TopologyPlugin=topology/block

Konfigurasi

SageMaker HyperPod secara otomatis mengkonfigurasi topologi blok. Pada Slurm 25.11 dan yang lebih baru, topologi blok didefinisikan dalamtopology.yaml, yang merupakan sumber kebenaran. Topologi blok dan pohon untuk cluster didefinisikan bersama dalam file yang sama. Contoh berikut menunjukkan cluster dengan partisi P5 (pohon) dan UltraServer partisi (blok):


- topology: tree
  cluster_default: true
  tree:
    switches:
      - switch: root
        children: leaf-0,leaf-1
      - switch: leaf-0
        nodes: compute-p5-1,compute-p5-2
      - switch: leaf-1
        nodes: compute-p5-3,compute-p5-4
- topology: block
  cluster_default: false
  block:
    block_sizes:
      - 18
    blocks:
      - block: cb-001
        nodes: ultraserver-1-[1-18]

Pada Slurm 24.x, topologi blok didefinisikan topology.conf sebagai gantinya, yang menggunakan format berikut:


BlockName=us1 Nodes=ultraserver1-[0-17]
BlockName=us2 Nodes=ultraserver2-[0-17]
BlockSizes=18

Penggunaan

Saat mengirimkan pekerjaan, Anda dapat menggunakan argumen tambahan berikut dengan sbatch dan srun perintah:

--segment=N: Tentukan jumlah node untuk dikelompokkan bersama. Ukuran segmen harus kurang dari atau sama dengan ukuran blok perencanaan.
--exclusive=topo: Meminta agar tidak ada pekerjaan lain yang ditempatkan di blok yang sama. Ini berguna untuk benchmarking dan aplikasi yang peka terhadap kinerja.

Berikut ini adalah contoh skenario yang mungkin Anda pertimbangkan ketika berpikir tentang mengalokasikan blok.

Alokasikan seluruh blok node pada sistem kosong


sbatch -N18

Alokasikan dua blok node pada sistem kosong


sbatch -N36

Alokasikan 18 node pada satu blok+6 node di blok lain


sbatch -N24

Alokasikan 12 node pada satu blok dan 12 node di blok lain


sbatch -N24 --segment=12

Dengan --exclusive=topo, pekerjaan harus ditempatkan di blok tanpa pekerjaan lain


sbatch -N12 --exclusive=topo

Partition-level pemilihan topologi

Dimulai dengan Slurm 25.11, HyperPod mendukung konfigurasi topologi pada tingkat partisi. Setiap partisi diberi topologi berdasarkan jenis instance dari grup instance komputasi, sehingga satu cluster dapat menjalankan topologi pohon di satu partisi dan memblokir topologi di partisi lain. Partisi yang berisi tipe instance tanpa dukungan topologi jaringan mewarisi flat default seluruh cluster, yang membuat node mereka dapat dijadwalkan.

HyperPod menyelesaikan topologi untuk setiap partisi sebagai berikut:

Jika setiap grup instance komputasi di partisi adalah tipe UltraServer instance, partisi menggunakan block topologi.
Jika setiap grup instance komputasi di partisi mendukung topologi jaringan (dan partisi tidak semuanya UltraServer), partisi menggunakan topologi. tree
Jika partisi berisi keduanya UltraServer dan jenis instance berkemampuan topologi lainnya, partisi menggunakan topologi. tree
Jika ada grup instans komputasi di partisi menggunakan tipe instance yang tidak mendukung topologi jaringan, partisi tidak memiliki penetapan topologi dan mewarisi default seluruh cluster. flat

Topologi default seluruh cluster dipilih berdasarkan topologi yang ada di seluruh cluster: jika hanya ada satu tipe topologi, tipe itu adalah default; jika blok dan pohon hadir tanpa grup non-topologi, pohon adalah default; dan jika ada grup komputasi non-topologi, adalah default sehingga node tersebut tetap dapat dijadwalkan. flat

Tabel berikut menunjukkan contoh bagaimana HyperPod menyelesaikan topologi untuk cluster dengan tipe instance campuran.

Grup instans	Tipe instans	Topologi terapan
IG-1	ml.p5.48xbesar	Pohon
IG-2	ml.p6e-gb200.36xlarge	Blokir

Dalam contoh ini, partisi P5 menggunakan topologi pohon dan UltraServer partisi menggunakan topologi blok. Dengan topologi tingkat partisi, setiap partisi menggunakan topologi optimalnya dalam cluster yang sama, sehingga Anda tidak perlu lagi membuat cluster terpisah untuk memberikan setiap jenis instance model topologi yang ideal.

catatan

Pada cluster yang menjalankan Slurm 24.x, hanya satu konfigurasi topologi seluruh cluster yang didukung. Per-partition topologi membutuhkan Slurm 25.11 atau yang lebih baru.

Topologi datar default

Ketika sebuah cluster berisi campuran tipe instance berkemampuan topologi dan non-topologi, berlaku sebagai default cluster. HyperPod topology/flat Topology-aware partisi diarahkan ke topologi pohon atau blok mereka melalui Topology= arahan per partisi di slurm.conf (Slurm 25.11 dan yang lebih baru), sedangkan partisi dengan node non-topologi tidak memiliki arahan dan mewarisi default datar. Topology= Ini memastikan setiap node tetap dapat dijadwalkan.

Nonaktifkan atau ubah plugin topologi

Ketika cluster Slurm dibuat, HyperPod secara otomatis memilih plugin topologi optimal. Untuk mengubah plugin topologi secara manual, perbarui TopologyPlugin nilai slurm.conf pada node pengontrol.

Untuk menonaktifkan penempatan sadar topologi, setel plugin ke topology/flat (atau): topology/default


# Set this value to disable topology-aware placement
TopologyPlugin=topology/flat

Pembaruan topologi dinamis

Topology-aware penjadwalan terus mempertahankan kebenaran topologi saat klaster Anda berubah. Topologi secara otomatis dihitung ulang dan file konfigurasi topologi dibuat ulang ketika salah satu peristiwa berikut terjadi:

Scale-up: Node baru ditambahkan ke cluster.
Scale-down: Node dihapus dari cluster.
Penggantian node: Node yang gagal atau tidak sehat diganti, atau node diganti secara manual menggunakan BatchReplaceClusterNodesAPI.

Ketika topologi diperbarui, node baru dimasukkan ke dalam struktur topologi yang benar, node yang dihapus dipangkas, dan konfigurasi Slurm diperbarui tanpa memerlukan intervensi manual. Ini memastikan bahwa topologi selalu mencerminkan keadaan cluster yang sebenarnya.

catatan

Pengguna tingkat lanjut dapat mengganti perilaku topologi dengan masuk ke node pengontrol Slurm dan memodifikasi secara manual dan file topologi yang berlaku (topology.yamlpada Slurm 25.11 slurm.conf dan yang lebih baru, atau di Slurm 24.x). topology.conf Namun, perubahan manual dapat ditimpa HyperPod selama pembaruan klaster berikutnya, termasuk operasi penskalaan, penggantian node, dan peristiwa siklus hidup klaster lainnya. Jika Anda memodifikasi file-file ini secara manual, verifikasi perubahan Anda setelah pembaruan klaster apa pun.

Praktik terbaik untuk UltraServer topologi

Untuk kinerja optimal dengan UltraServer arsitektur di SageMaker HyperPod:

Tetapkan ukuran blok yang sesuai: Konfigurasikan BlockSizes=18 (atau 17 jika satu node cadangan) agar sesuai dengan UltraServer arsitektur.
Gunakan segmen untuk ketersediaan yang lebih baik: Gunakan--segment=16,--segment=8, atau --segment=9 dengan srun dan sbatch perintah untuk meningkatkan fleksibilitas penjadwalan pekerjaan.
Pertimbangkan ukuran pekerjaan dan ukuran segmen:
- JikaBlockSizes=18, pekerjaan dengan hingga 18 instans akan selalu berjalan dalam satu UltraServer.
- JikaBlockSizes=16, pekerjaan dengan kurang dari 16 instans akan selalu berjalan pada satu UltraServer, sementara pekerjaan dengan 18 instance dapat berjalan pada satu atau dua. UltraServers

Saat berpikir tentang segmentasi, pertimbangkan hal berikut:

Dengan--segment=1, setiap instance dapat berjalan secara terpisah UltraServer.
Dengan-N 18 --segment 9, 9 node akan ditempatkan pada satu UltraServer, dan 9 node lainnya dapat ditempatkan pada yang sama atau yang lain UltraServer.
Dengan-N 24 --segment 8, pekerjaan dapat berjalan pada 2 atau 3 UltraServers, dengan setiap 8 node ditempatkan bersama di server yang sama.

Keterbatasan dalam SageMaker HyperPod penjadwalan sadar topologi

Dengan Slurm 25.11 dan yang lebih baru, cluster heterogen (cluster dengan tipe instance berbeda) didukung melalui topologi tingkat partisi dan default cluster. flat Setiap partisi menerima topologi yang paling sesuai dengan jenis instance-nya, dan non-topologi dan UltraServer node tetap dapat dijadwalkan dalam cluster yang sama. Untuk informasi selengkapnya, lihat Partition-level pemilihan topologi.

Pada cluster yang menjalankan Slurm 24.x, topologi seluruh cluster tunggal berlaku, dan plugin memiliki batasan berikut dengan cluster heterogen: topology/block

Hanya node yang terdaftar dalam blok yang dapat dijadwalkan oleh Slurm.
Setiap blok harus memiliki setidaknya BlockSizes[0] node.

Untuk cluster heterogen pada Slurm 24.x, pertimbangkan alternatif ini:

Jangan gunakan plugin blok dengan cluster heterogen. Sebaliknya, isolasi UltraServer node di partisi yang berbeda.
Buat cluster terpisah dengan UltraServers hanya di VPC yang sama dan gunakan pengaturan multicluster Slurm.

Awas Javascript dinonaktifkan atau tidak tersedia di browser Anda.

Untuk menggunakan Dokumentasi AWS, Javascript harus diaktifkan. Lihat halaman Bantuan browser Anda untuk petunjuk.

Konvensi Dokumen

Menerapkan beban kerja

Menyebarkan model pada HyperPod