View a markdown version of this page

Menggunakan penjadwalan sadar topologi di Amazon SageMaker HyperPod - Amazon SageMaker AI
UltraServer arsitekturLabel topologiPlugin topologi slurmPraktik terbaikBatasan

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

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- AWS Region 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 yang dihasilkan secara dinamis. topology.conf 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.

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. Node topology.conf peta yang dihasilkan menjadi hierarki sakelar yang mencerminkan tingkatan komunikasi perangkat keras Anda.

Pastikan Anda slurm.conf termasuk:

TopologyPlugin=topology/tree

Konfigurasi

SageMaker HyperPod secara otomatis mengkonfigurasi topology/tree plugin berdasarkan informasi yang diberikan oleh Amazon EC2. Untuk detail selengkapnya tentang topologi Amazon EC2, lihat topologi instans Amazon EC2.

Ketika topology/tree plugin digunakan, Slurm topology.conf terlihat seperti 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 contoh seperti ml.p6e-gb200.NVL72 dan. ml.p6e-gb300.NVL72

Konfigurasi

SageMaker HyperPod secara otomatis mengkonfigurasi topology/block plugin. Jika Anda ingin mengkonfigurasi plugin secara manual, tentukan yang berikut ini dalam topology.conf file di direktori konfigurasi Slurm Anda:

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

Pastikan Anda slurm.conf termasuk:

TopologyPlugin=topology/block

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

Pemilihan topologi untuk cluster dengan tipe instance campuran

HyperPod saat ini menggunakan Slurm 24.11, yang hanya mendukung konfigurasi topologi tunggal per cluster. Ini berarti bahwa pemilihan topologi per partisi tidak didukung, beberapa model topologi tidak dapat hidup berdampingan dalam satu cluster, dan semua node harus sesuai dengan definisi topologi tunggal.

Saat klaster Anda berisi beberapa jenis instance, HyperPod pilih topologi yang kompatibel di semuanya. Tabel berikut menunjukkan contoh bagaimana HyperPod menyelesaikan topologi untuk cluster dengan tipe instance campuran.

Grup instans Tipe instans Topologi pilihan

IG-1

ml.p5.48xbesar

Pohon

IG-2

ml.p6e-GB300.nvl72

Blokir

Dalam contoh ini, topologi blok optimal untuk ml.P6E-GB300.NVL72, tetapi topologi pohon kompatibel dengan ml.p5.48xlarge dan ml.P6E-GB300.NVL72. HyperPod memilih topologi pohon sebagai topologi cluster-wide untuk memastikan bahwa semua node dapat berpartisipasi dalam penjadwalan dengan benar dan tidak ada jenis instance yang dikecualikan atau disalahartikan.

penting

Untuk beban kerja di mana penjadwalan sadar topologi sangat penting untuk kinerja, sebaiknya buat cluster terpisah untuk setiap jenis instance daripada menggabungkan tipe instance yang berbeda dalam satu cluster. Ini memastikan bahwa setiap cluster menggunakan topologi optimal untuk perangkat kerasnya, memberikan kinerja beban kerja sebaik mungkin. Misalnya, alih-alih menggabungkan instance ml.p5.48xlarge dan ml.p6e-GB300.NVL72 dalam satu cluster di mana topologi pohon dipilih sebagai kompromi yang kompatibel, buat cluster khusus untuk setiap jenis instance sehingga masing-masing menggunakan model topologi idealnya.

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.

Contoh:

# Set this value to disable topology plugin
TopologyPlugin=topology/flat

Pembaruan topologi dinamis

Topology-aware penjadwalan terus mempertahankan kebenaran topologi saat klaster Anda berubah. Topologi secara otomatis dihitung ulang dan topology.conf file 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 dan memodifikasi secara manual. slurm.conf 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

Ketika 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

topology/blockPlugin ini memiliki keterbatasan dengan cluster heterogen (cluster dengan tipe instance yang berbeda):

  • Hanya node yang terdaftar dalam blok yang dapat dijadwalkan oleh Slurm

  • Setiap blok harus memiliki setidaknya BlockSizes[0] node

Untuk cluster heterogen, 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.