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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-topology.html).
Topology-aware penjadwalan berfungsi dengan kedua cluster di Slurm dan Amazon EKS. Untuk informasi umum tentang cara kerja topologi dengan Slurm, lihat panduan [Topologi](https://slurm.schedmd.com/topology.html) 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 adalah`topology.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, lihat[Menggunakan UltraServers di Amazon SageMaker HyperPod](sagemaker-hyperpod-ultraserver.md).
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](sagemaker-hyperpod-eks-operate-console-ui-governance-tasks-scheduling.md).
## 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](#sagemaker-hyperpod-topology-dynamic-updates).
### 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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-topology-prerequisites.html#inst-net-topology-prereqs-instance-types) 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/tree`Plugin 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 seperti`ml.p5.48xlarge`,`ml.p5e.48xlarge`, dan`ml.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.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-topology.html)
Pada Slurm 25.11 dan yang lebih baru, HyperPod mendefinisikan topologi di`topology.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 dalam`topology.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 [BatchReplaceClusterNodes](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_BatchReplaceClusterNodes.html)API.
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.yaml`pada 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**:
+ Jika`BlockSizes=18`, pekerjaan dengan hingga 18 instans akan selalu berjalan dalam satu UltraServer.
+ Jika`BlockSizes=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](#sagemaker-hyperpod-topology-partition-level).
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.