Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Komputasi dan Penskalaan Otomatis
**Tip**
[Jelajahi](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) praktik terbaik melalui lokakarya Amazon EKS.
## Optimalisasi Sumber Daya GPU dan Manajemen Biaya
### Jadwalkan beban kerja dengan persyaratan GPU menggunakan label Terkenal
[https://karpenter.sh/v1.0/concepts/scheduling/#labels](https://karpenter.sh/v1.0/concepts/scheduling/#labels) Gagal mendefinisikan ini dapat mengakibatkan pod dijadwalkan pada instance dengan sumber daya GPU yang tidak memadai, menyebabkan kegagalan atau penurunan kinerja. Kami merekomendasikan penggunaan [afinitas [nodeSelector](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) atau Node](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity) untuk menentukan node mana yang harus dijalankan pod dan menyetel [sumber daya](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/) komputasi (CPU, memori, GPUs dll) di bagian sumber daya pod.
**Contoh**
Misalnya, menggunakan pemilih node nama GPU saat menggunakan Karpenter:
```
apiVersion: v1
kind: Pod
metadata:
name: gpu-pod-example
spec:
containers:
- name: ml-workload
image:
resources:
limits:
nvidia.com/gpu: 1 # Request one NVIDIA GPU
nodeSelector:
karpenter.k8s.aws/instance-gpu-name: "l40s" # Run on nodes with NVIDIA L40S GPUs
```
### Gunakan Plugin Perangkat Kubernetes untuk mengekspos GPUs
Untuk mengekspos GPUs pada node, driver GPU NVIDIA harus diinstal pada sistem operasi node dan runtime kontainer yang dikonfigurasi untuk memungkinkan penjadwal Kubernetes menetapkan pod ke node yang tersedia. GPUs Proses penyiapan untuk Plugin Perangkat NVIDIA Kubernetes bergantung pada AMI Akselerasi EKS yang Anda gunakan:
+ **[Bottlerocket Accelerated AMI](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami-bottlerocket.html)**: AMI ini mencakup **driver** GPU NVIDIA dan Plugin [Perangkat NVIDIA Kubernetes](https://github.com/NVIDIA/k8s-device-plugin) sudah diinstal sebelumnya dan siap digunakan, memungkinkan dukungan GPU di luar kotak. Tidak diperlukan konfigurasi tambahan untuk mengekspos GPUs ke penjadwal Kubernetes.
+ **[AL2023 AMI yang Dipercepat](https://aws.amazon.com/blogs/containers/amazon-eks-optimized-amazon-linux-2023-accelerated-amis-now-available/)****: AMI ini menyertakan driver GPU NVIDIA tetapi [Plugin Perangkat NVIDIA Kubernetes belum diinstal sebelumnya](https://github.com/NVIDIA/k8s-device-plugin).** Anda harus menginstal dan mengkonfigurasi plugin perangkat secara terpisah, biasanya melalui file DaemonSet. Perhatikan bahwa jika Anda menggunakan eksctl untuk membuat cluster Anda dan menentukan jenis instans GPU (misalnya,`g5.xlarge`) di Anda ClusterConfig, secara otomatis `eksctl` akan memilih AMI yang sesuai dan menginstal Plugin Perangkat NVIDIA Kubernetes. Untuk mempelajari lebih lanjut, lihat [Dukungan GPU dalam dokumentasi](https://eksctl.io/usage/gpu-support/) eksctl.
Jika Anda memutuskan untuk menggunakan [operator EKS Accelerated AMIs dan NVIDIA GPU](https://github.com/NVIDIA/gpu-operator) untuk mengelola komponen seperti plugin perangkat NVIDIA Kubernetes sebagai gantinya, perhatikan untuk menonaktifkan manajemen driver GPU NVIDIA dan toolkit NVIDIA Container sesuai dengan Driver GPU NVIDIA [Pra-Instalasi dan dokumentasi NVIDIA Container Toolkit NVIDIA](https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/getting-started.html#pre-installed-nvidia-gpu-drivers-and-nvidia-container-toolkit).
Untuk memverifikasi bahwa Plugin Perangkat NVIDIA aktif dan GPUs terpapar dengan benar, jalankan:
```
kubectl describe node | grep nvidia.com/gpu
```
Perintah ini memeriksa apakah `nvidia.com/gpu` sumber daya berada dalam kapasitas node dan sumber daya yang dapat dialokasikan. Misalnya, node dengan satu GPU harus ditampilkan`nvidia.com/gpu: 1`. Lihat Panduan [Penjadwalan GPU Kubernetes](https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/) untuk informasi selengkapnya.
### Gunakan banyak jenis instans EC2 yang berbeda
Menggunakan sebanyak mungkin jenis instans EC2 yang berbeda adalah praktik terbaik yang penting untuk skalabilitas di Amazon EKS, seperti yang diuraikan di bagian ini. [Pesawat Data Kubernetes](scale-data-plane.md) Rekomendasi ini juga berlaku untuk instance dengan perangkat keras yang dipercepat (misalnya, GPUs). Jika Anda membuat klaster yang hanya menggunakan satu jenis instans dan mencoba menskalakan jumlah node di luar kapasitas wilayah, Anda mungkin menerima kesalahan kapasitas yang tidak mencukupi (ICE), yang menunjukkan bahwa tidak ada instance yang tersedia. Penting untuk memahami karakteristik unik dari AI/ML beban kerja Anda sebelum melakukan diversifikasi secara sewenang-wenang. Tinjau jenis instans yang tersedia menggunakan alat [EC2 Instance Type Explorer](https://aws.amazon.com/ec2/instance-explorer/) untuk membuat daftar jenis instans yang sesuai dengan persyaratan komputasi spesifik Anda, dan hindari membatasi secara sewenang-wenang jenis instance yang dapat digunakan di klaster Anda.
Instans komputasi yang dipercepat ditawarkan dalam model pembelian yang berbeda agar sesuai dengan beban kerja jangka pendek, jangka menengah, dan kondisi tunak. Untuk beban kerja jangka pendek, fleksibel, dan toleran kesalahan, di mana Anda ingin menghindari reservasi, lihat contoh Spot. Blok Kapasitas, Instans Sesuai Permintaan, dan Paket Penghematan memungkinkan Anda menyediakan instans komputasi yang dipercepat untuk durasi beban kerja jangka menengah dan panjang. Untuk meningkatkan peluang berhasil mengakses kapasitas yang diperlukan dalam opsi pembelian pilihan Anda, disarankan untuk menggunakan beragam daftar jenis instans dan zona ketersediaan. Atau, jika Anda menemukan ICEs model pembelian tertentu, coba lagi menggunakan model yang berbeda.
**Contoh Contoh** berikut menunjukkan cara mengaktifkan Karpenter NodePool untuk menyediakan instance G dan P yang lebih besar dari generasi 3 (misalnya, p3). Untuk mempelajari lebih lanjut, lihat [Praktik terbaik Skalabilitas EKS](scalability.md) bagian.
```
- key: karpenter.k8s.aws/instance-category
operator: In
values: ["g", "p"] # Diversifies across G-series and P-series
- key: karpenter.k8s.aws/instance-generation
operator: Gt
values: ["3"] # Selects instance generations greater than 3
```
Untuk detail tentang penggunaan instans Spot untuk GPU, lihat “Pertimbangkan untuk menggunakan Instans Spot Amazon EC2 GPUs untuk dengan Karpenter” di bawah ini.
### Pertimbangkan untuk menggunakan Instans Spot Amazon EC2 untuk Karpenter GPUs
Instans Spot Amazon EC2 memungkinkan Anda memanfaatkan kapasitas EC2 yang tidak terpakai di AWS cloud dan tersedia dengan diskon hingga 90% dibandingkan dengan harga Sesuai Permintaan. Instans Spot Amazon EC2 dapat terganggu dengan pemberitahuan dua menit saat EC2 membutuhkan kapasitas kembali. Untuk informasi selengkapnya, lihat [Instans Spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) di Panduan Pengguna Amazon EC2. Amazon EC2 Spot dapat menjadi pilihan tepat untuk beban kerja yang toleran terhadap kesalahan, tanpa kewarganegaraan, dan fleksibel (tipe waktu dan instans). Untuk mempelajari lebih lanjut tentang kapan menggunakan instans Spot, lihat Praktik Terbaik [Instans Spot EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html). Anda juga dapat menggunakan Instans Spot untuk AI/ML beban kerja jika mereka ramah tempat.
**Kasus penggunaan**
Beban kerja yang ramah tempat dapat berupa data besar, beban kerja kontainer, CI/CD, server web stateless, komputasi kinerja tinggi (HPC), dan beban kerja rendering. Instans Spot tidak cocok untuk beban kerja yang tidak fleksibel, stateful, tidak toleran kesalahan, atau digabungkan erat antara node instance (misalnya, beban kerja dengan proses paralel yang sangat bergantung satu sama lain untuk komputasi, membutuhkan komunikasi antar-simpul yang konstan, seperti aplikasi komputasi kinerja tinggi berbasis MPI seperti dinamika fluida komputasi atau database terdistribusi dengan saling ketergantungan yang kompleks). Berikut adalah kasus penggunaan khusus yang kami rekomendasikan (tanpa urutan tertentu):
+ **Inferensi online real-time**: Gunakan instans Spot untuk penskalaan yang dioptimalkan biaya untuk beban kerja inferensi waktu nyata Anda, selama beban kerja Anda ramah tempat. Dengan kata lain, waktu inferensi kurang dari dua menit, aplikasi toleran terhadap kesalahan terhadap interupsi, dan dapat berjalan pada jenis instance yang berbeda. Pastikan ketersediaan tinggi melalui keragaman instans (misalnya, di beberapa jenis instans dan Availability Zone) atau reservasi, sambil menerapkan toleransi kesalahan tingkat aplikasi untuk menangani potensi gangguan Spot.
+ **Penyetelan parameter hiper**: Gunakan instans Spot untuk menjalankan pekerjaan penyetelan eksplorasi secara oportunistik, karena interupsi dapat ditoleransi tanpa kerugian yang signifikan, terutama untuk eksperimen berdurasi pendek.
+ **Augmentasi data**: Gunakan instans Spot untuk melakukan prapemrosesan data dan tugas augmentasi yang dapat dimulai ulang dari pos pemeriksaan jika terputus, menjadikannya ideal untuk ketersediaan variabel Spot.
+ **Model fine-tuning**: Gunakan instans Spot untuk fine-tuning dengan mekanisme checkpointing yang kuat untuk melanjutkan dari status tersimpan terakhir, meminimalkan dampak interupsi instans.
+ **Inferensi Batch**: Gunakan instans Spot untuk memproses sejumlah besar permintaan inferensi offline non-real-time dengan cara tertentu, di mana pekerjaan dapat dijeda dan dilanjutkan, menawarkan penyelarasan terbaik dengan penghematan biaya Spot dan menangani potensi gangguan melalui percobaan ulang atau diversifikasi.
+ **Subset pelatihan oportunistik**: Gunakan instance Spot untuk beban kerja pelatihan marjinal atau eksperimental (misalnya, model yang lebih kecil di bawah 10 juta parameter), di mana interupsi dapat diterima dan pengoptimalan efisiensi seperti diversifikasi di seluruh jenis instans atau wilayah dapat diterapkan—meskipun tidak direkomendasikan untuk pelatihan skala produksi karena potensi gangguan.
**Pertimbangan-pertimbangan**
Untuk menggunakan Instans Spot untuk beban kerja yang dipercepat di Amazon EKS, ada sejumlah pertimbangan utama (tanpa urutan tertentu):
+ **Gunakan Karpenter untuk mengelola instans Spot dengan konsolidasi lanjutan diaktifkan**. Dengan menentukan karpenter.sh/capacity-type sebagai “spot” di Karpenter Anda, Karpenter NodePool akan menyediakan instance Spot secara default tanpa konfigurasi tambahan. Namun, untuk mengaktifkan Spot-to-Spot konsolidasi lanjutan, yang menggantikan node Spot yang kurang dimanfaatkan dengan alternatif Spot dengan harga lebih rendah, Anda perlu mengaktifkan [gerbang SpotToSpotConsolidation fitur](https://karpenter.sh/docs/reference/settings/) dengan menyetel --feature-gates SpotToSpotConsolidation =true dalam argumen pengontrol Karpenter atau melalui variabel lingkungan FEATURE\$1GATES. Karpenter menggunakan strategi [price-capacity-optimized](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-allocation-strategy.html)alokasi untuk menyediakan instans EC2. [Berdasarkan NodePool persyaratan dan batasan pod, Karpenter bin-pack pod yang tidak dapat dijadwalkan dan mengirimkan beragam jenis instance ke Amazon EC2 Fleet API.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-request-type.html) Anda dapat menggunakan alat [EC2 Instance Type Explorer](https://aws.amazon.com/ec2/instance-explorer/) untuk membuat daftar jenis instans yang sesuai dengan persyaratan komputasi spesifik Anda.
+ **Pastikan beban kerja tidak memiliki kewarganegaraan, toleransi kesalahan,** dan fleksibel. Beban kerja harus tanpa kewarganegaraan, toleran terhadap kesalahan, dan fleksibel dalam hal ukuran. instance/GPU Hal ini memungkinkan dimulainya kembali secara mulus setelah interupsi Spot, dan fleksibilitas instans memungkinkan Anda untuk tetap berada di Spot lebih lama. Aktifkan [penanganan interupsi Spot](https://karpenter.sh/docs/concepts/disruption/#interruption) di Karpenter dengan mengonfigurasi nilai Settings.InterruptionQueue Helm dengan nama antrian AWS SQS untuk menangkap peristiwa interupsi Spot. Misalnya, saat menginstal melalui Helm, gunakan --set “settings.interruptionQueue=\$1 \$1CLUSTER\$1NAME\$1”. Untuk melihat contoh, lihat panduan [Memulai dengan Karpenter](https://karpenter.sh/docs/getting-started/getting-started-with-karpenter/). Ketika Karpenter melihat peristiwa interupsi Spot, ia secara otomatis mengikat, menodai, menguras, dan mengakhiri node sebelum peristiwa interupsi untuk memaksimalkan masa tenggang terminasi pod. Pada saat yang sama, Karpenter akan segera memulai node baru sehingga dapat siap sesegera mungkin.
+ **Hindari terlalu membatasi pemilihan jenis instance**. Anda harus menghindari membatasi jenis instance sebanyak mungkin. Dengan tidak membatasi jenis instans, ada kemungkinan lebih tinggi untuk memperoleh kapasitas Spot pada skala besar dengan frekuensi interupsi Instans Spot yang lebih rendah dengan biaya lebih rendah. Misalnya, hindari membatasi tipe tertentu (misalnya, g5.xlarge). Pertimbangkan untuk menentukan serangkaian kategori dan generasi instance yang beragam menggunakan kunci seperti karpenter.k8s. aws/instance-category and karpenter.k8s.aws/instance-generation. Karpenter enables easier diversification of on-demand and Spot instance capacity across multiple instance types and Availability Zones (AZs). Moreover, if your AI/MLbeban kerja memerlukan jumlah akselerator tertentu atau terbatas tetapi fleksibel antar wilayah, Anda dapat menggunakan Skor Penempatan Spot untuk mengidentifikasi wilayah optimal secara dinamis untuk menerapkan beban kerja Anda sebelum diluncurkan.
+ **Perluas NodePool persyaratan untuk memasukkan sejumlah besar keluarga instans EC2 serupa**. Setiap kumpulan Instans Spot terdiri dari kapasitas instans EC2 yang tidak digunakan untuk jenis instans tertentu di Availability Zone (AZ) tertentu. Ketika Karpenter mencoba untuk menyediakan node baru, ia memilih jenis instance yang cocok dengan persyaratan. NodePool Jika tidak ada jenis instans yang kompatibel yang memiliki kapasitas Spot di AZ mana pun, maka penyediaan gagal. Untuk menghindari masalah ini, izinkan instance g-series yang lebih luas (generasi 4 atau lebih tinggi) dari NVIDIA di seluruh ukuran dan Availability Zones (AZs), sambil mempertimbangkan kebutuhan perangkat keras seperti memori GPU atau Ray Tracing. Karena instance dapat dari berbagai jenis, Anda perlu memastikan bahwa beban kerja Anda dapat berjalan pada setiap jenis, dan kinerja yang Anda dapatkan memenuhi kebutuhan Anda.
+ **Manfaatkan semua zona ketersediaan di suatu wilayah**. Kapasitas yang tersedia bervariasi menurut Availability Zone (AZ), jenis instans tertentu mungkin tidak tersedia di satu AZ tetapi berlimpah di AZ lainnya. Setiap kombinasi unik dari tipe instans dan Availability Zone merupakan kumpulan kapasitas Spot yang terpisah. Dengan meminta kapasitas di semua wilayah AZs dalam NodePool persyaratan Karpenter Anda, Anda secara efektif mencari lebih banyak kumpulan sekaligus. Ini memaksimalkan jumlah kumpulan kapasitas Spot dan oleh karena itu meningkatkan kemungkinan memperoleh kapasitas Spot. Untuk mencapai ini, dalam NodePool konfigurasi Anda, hilangkan kunci topology.kubernetes.io/zone sepenuhnya untuk memungkinkan Karpenter memilih dari semua yang tersedia AZs di wilayah, atau daftar AZs secara eksplisit menggunakan operator: In dan berikan nilainya (misalnya, us-west-2a).
+ **Pertimbangkan untuk menggunakan Spot Placement Score (SPS) untuk mendapatkan visibilitas ke kemungkinan berhasil mengakses kapasitas yang diperlukan menggunakan instans** Spot. [Spot Placement Score (SPS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/work-with-spot-placement-score.html) adalah alat yang memberikan skor untuk membantu Anda menilai seberapa besar kemungkinan permintaan Spot berhasil. Saat menggunakan SPS, pertama-tama Anda menentukan persyaratan komputasi untuk Instans Spot, lalu Amazon EC2 mengembalikan 10 Wilayah atau Availability Zone (AZs) teratas tempat permintaan Spot Anda kemungkinan berhasil. Wilayah dan Zona Ketersediaan diberi skor pada skala 1 hingga 10. Skor 10 menunjukkan bahwa permintaan Spot Anda sangat mungkin tetapi tidak dijamin berhasil. Skor 1 menunjukkan bahwa permintaan Spot Anda tidak mungkin berhasil. Skor yang sama mungkin ditampilkan untuk Wilayah atau Zona Ketersediaan yang berbeda. Untuk mempelajari selengkapnya, lihat [Panduan Membangun Dasbor Pelacak Skor Penempatan Spot di AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/work-with-spot-placement-score.html). Karena kapasitas Spot berfluktuasi sepanjang waktu, SPS akan membantu Anda mengidentifikasi kombinasi jenis instans AZs, dan wilayah mana yang paling sesuai untuk kendala beban kerja Anda (yaitu fleksibilitas, kinerja, ukuran, dll.). Jika AI/ML beban kerja Anda memerlukan akselerator tertentu atau jumlah terbatas tetapi fleksibel antar wilayah, Anda dapat menggunakan skor penempatan Spot untuk mengidentifikasi wilayah optimal secara dinamis untuk menerapkan beban kerja Anda sebelum diluncurkan. Untuk membantu Anda mengetahui secara otomatis kemungkinan memperoleh kapasitas Spot, kami memberikan panduan untuk membangun dasbor pelacak SPS. Solusi ini memantau skor SPS dari waktu ke waktu menggunakan konfigurasi YAMAL untuk penyiapan yang beragam (misalnya, persyaratan instans termasuk GPUs), menyimpan metrik CloudWatch, dan menyediakan dasbor untuk membandingkan konfigurasi. Tentukan dasbor per beban kerja untuk mengevaluasi kebutuhan vCPU, memori, dan GPU, memastikan pengaturan optimal untuk kluster EKS termasuk pertimbangan penggunaan Wilayah AWS lainnya. Untuk mempelajari lebih lanjut, lihat [Cara kerja skor penempatan Spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/how-sps-works.html).
+ **Dengan anggun menangani interupsi dan pengujian Spot**. Untuk pod dengan periode terminasi lebih dari dua menit, node lama akan terganggu sebelum pod tersebut dijadwalkan ulang, yang dapat memengaruhi ketersediaan beban kerja. Pertimbangkan pemberitahuan interupsi Spot dua menit saat merancang aplikasi Anda, terapkan checkpointing dalam aplikasi yang berjalan lama (misalnya, menyimpan kemajuan ke penyimpanan persisten seperti Amazon S3) untuk melanjutkan setelah interupsi, memperpanjang terminationGracePeriod Detik (default adalah 30 detik) dalam spesifikasi Pod untuk memungkinkan lebih banyak waktu untuk shutdown yang anggun, dan menangani interupsi menggunakan siklus hidup PreStop menghubungkan sinyal and/or SIGTERM dalam aplikasi Anda untuk aktivitas shutdown yang anggun seperti pembersihan, penghematan negara, dan penutupan koneksi. Untuk beban kerja real-time, di mana waktu penskalaan penting dan beban kerja membutuhkan waktu lebih dari dua menit agar aplikasi siap melayani lalu lintas, pertimbangkan untuk mengoptimalkan waktu start-up kontainer dan pemuatan model ML dengan meninjau dan praktik terbaik. [Penyimpanan](aiml-storage.md) [Penskalaan dan Kinerja Aplikasi](aiml-performance.md) Untuk menguji node pengganti, gunakan [AWS Fault Injection Service](https://aws.amazon.com/fis/) (FIS) untuk mensimulasikan interupsi Spot.
Selain praktik terbaik Spot inti ini, pertimbangkan faktor-faktor ini saat mengelola beban kerja GPU di Amazon EKS. Tidak seperti beban kerja berbasis CPU, beban kerja GPU sangat sensitif terhadap detail perangkat keras seperti kemampuan GPU dan memori GPU yang tersedia. Beban kerja GPU mungkin dibatasi oleh jenis instance yang dapat mereka gunakan, dengan lebih sedikit opsi yang tersedia dibandingkan dengan. CPUs Sebagai langkah pertama, menilai apakah beban kerja Anda fleksibel. Jika Anda tidak tahu berapa banyak jenis instans yang dapat digunakan oleh beban kerja Anda, ujilah satu per satu untuk memastikan kompatibilitas dan fungsionalitas. Identifikasi seberapa fleksibel Anda dapat melakukan diversifikasi sebanyak mungkin, sambil mengonfirmasi bahwa diversifikasi membuat beban kerja tetap bekerja dan memahami dampak kinerja apa pun (misalnya, pada throughput atau waktu penyelesaian). Sebagai bagian dari diversifikasi beban kerja Anda, pertimbangkan hal berikut:
+ **Tinjau CUDA dan kompatibilitas kerangka kerja**. Beban kerja GPU Anda mungkin dioptimalkan untuk perangkat keras tertentu, jenis GPU (misalnya, V100 di p3 vs. A100 di p4), atau ditulis untuk versi CUDA tertentu untuk pustaka seperti TensorFlow, jadi pastikan untuk meninjau kompatibilitas untuk beban kerja Anda. Kompatibilitas ini sangat penting untuk mencegah kesalahan runtime, crash, kegagalan dalam akselerasi GPU (misalnya, versi CUDA yang tidak cocok dengan kerangka kerja seperti PyTorch atau TensorFlow dapat mencegah eksekusi), atau kemampuan untuk memanfaatkan fitur perangkat keras seperti/presisi. FP16 INT8
+ **Memori GPU**. Pastikan untuk mengevaluasi persyaratan memori model Anda dan profil penggunaan memori model Anda selama runtime menggunakan alat seperti [DCGM Exporter](https://docs.nvidia.com/datacenter/dcgm/latest/gpu-telemetry/dcgm-exporter.html) dan atur memori GPU minimum yang diperlukan untuk jenis instans di label terkenal seperti karpenter.k8s.aws/. instance-gpu-memory GPU VRAM bervariasi antar jenis instans (misalnya, NVIDIA T4 memiliki 16GB, A10G memiliki 24GB, V100 memiliki 16-32GB), dan model ML (misalnya, model bahasa besar) dapat melebihi memori yang tersedia, menyebabkan (OOM) kesalahan atau crash. out-of-memory Untuk Instans Spot di EKS, ini dapat membatasi diversifikasi. Misalnya, Anda tidak dapat menyertakan tipe VRAM yang lebih rendah jika model Anda tidak cocok, yang dapat membatasi akses ke kumpulan kapasitas dan meningkatkan risiko gangguan. Perhatikan bahwa untuk GPU tunggal, inferensi simpul tunggal (misalnya, beberapa pod yang dijadwalkan pada node yang sama untuk memanfaatkan sumber daya GPU-nya), ini mungkin membatasi diversifikasi, karena Anda hanya dapat menyertakan tipe instance dengan VRAM yang cukup dalam konfigurasi Spot Anda.
+ **Presisi dan kinerja floating-point**. Tidak semua arsitektur GPU Nvidia memiliki presisi floating point yang sama (misalnya, FP16/INT8). Evaluasi kinerja tipe inti (CUDA/Tensor/RT) dan presisi floating point yang diperlukan untuk beban kerja Anda. Berjalan pada GPU dengan harga lebih rendah dan kurang berkinerja tidak berarti itu lebih baik, jadi pertimbangkan untuk mengevaluasi kinerja dalam hal pekerjaan yang diselesaikan dalam kerangka waktu tertentu untuk memahami dampak diversifikasi.
**Skenario: Diversifikasi untuk beban kerja inferensi waktu nyata**
Untuk beban kerja inferensi online real-time di Instans Spot, Anda dapat mengonfigurasi Karpenter NodePool untuk melakukan diversifikasi di seluruh keluarga dan generasi instans GPU yang kompatibel. Pendekatan ini memastikan ketersediaan tinggi dengan menggambar dari beberapa kumpulan Spot, sambil mempertahankan kinerja melalui kendala pada kemampuan GPU, memori, dan arsitektur. Ini mendukung penggunaan alternatif ketika kapasitas instance dibatasi, meminimalkan interupsi dan mengoptimalkan latensi inferensi. Contoh ini NodePool menyatakan, gunakan instance seri g dan p lebih besar dari 3, yang memiliki memori GPU lebih dari 20GB.
**Contoh**
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu-inference-spot
spec:
template:
metadata:
labels:
role: gpu-spot-worker
spec:
requirements:
- key: karpenter.sh/capacity-type
operator: In
values: ["spot"] # Use Spot Instances
- key: karpenter.k8s.aws/instance-category
operator: In
values: ["g", "p"] # Diversifies across G-series and P-series
- key: karpenter.k8s.aws/instance-generation
operator: Gt
values: ["3"] # Selects instance generations greater than 3
- key: kubernetes.io/arch
operator: In
values: ["amd64"] # Specifies AMD64 architecture, compatible with NVIDIA GPUs
- key: karpenter.k8s.aws/instance-gpu-memory
operator: Gt
values: ["20480"] # Ensures more than 20GB (20480 MiB) total GPU memory
taints:
- key: nvidia.com/gpu
effect: NoSchedule
nodeClassRef:
name: gpu-inference-ec2
group: karpenter.k8s.aws
kind: EC2NodeClass
expireAfter: 720h
limits:
cpu: 100
memory: 100Gi
disruption:
consolidationPolicy: WhenEmptyOrUnderutilized
consolidateAfter: 5m # Enables consolidation of underutilized nodes after 5 minutes
```
### Menerapkan Checkpointing untuk Pekerjaan Pelatihan Jangka Panjang
Checkpointing adalah teknik toleransi kesalahan yang melibatkan penyelamatan keadaan proses secara berkala, memungkinkannya untuk melanjutkan dari titik terakhir yang disimpan jika terjadi gangguan. Dalam pembelajaran mesin, ini umumnya dikaitkan dengan pelatihan, di mana pekerjaan yang berjalan lama dapat menghemat bobot model dan status pengoptimal untuk melanjutkan pelatihan setelah kegagalan, seperti masalah perangkat keras atau gangguan Instans Spot.
Anda menggunakan pos pemeriksaan untuk menyimpan status model pembelajaran mesin (ML) selama pelatihan. Checkpoint adalah snapshot dari model dan dapat dikonfigurasi oleh fungsi callback kerangka kerja HTML. Anda dapat menggunakan pos pemeriksaan yang disimpan untuk memulai kembali pekerjaan pelatihan dari pos pemeriksaan terakhir yang disimpan. Dengan menggunakan pos pemeriksaan, Anda menyimpan snapshot model Anda di bawah pelatihan karena gangguan yang tidak terduga pada pekerjaan atau instance pelatihan. Ini memungkinkan Anda untuk melanjutkan pelatihan model di masa depan dari pos pemeriksaan. Selain menerapkan sistem ketahanan node, sebaiknya implementasikan checkpointing untuk mengurangi dampak interupsi, termasuk yang disebabkan oleh kegagalan perangkat keras atau interupsi Instans Spot Amazon EC2.
Tanpa checkpointing, interupsi dapat mengakibatkan waktu komputasi yang terbuang dan kehilangan kemajuan, yang mahal untuk pekerjaan pelatihan yang berjalan lama. Checkpointing memungkinkan pekerjaan untuk menyimpan statusnya secara berkala (misalnya, bobot model dan status pengoptimal) dan melanjutkan dari pos pemeriksaan terakhir (batch yang diproses terakhir) setelah gangguan. Untuk menerapkan pos pemeriksaan, rancang aplikasi Anda untuk memproses data dalam batch besar dan menyimpan hasil perantara ke penyimpanan persisten, seperti bucket Amazon S3 melalui Mountpoint [for Amazon S3](https://docs.aws.amazon.com/eks/latest/userguide/s3-csi.html) CSI Driver saat tugas pelatihan berlangsung.
**Kasus penggunaan**
Checkpointing sangat bermanfaat dalam skenario tertentu untuk menyeimbangkan toleransi kesalahan dengan overhead kinerja. Pertimbangkan untuk menggunakan pos pemeriksaan dalam kasus berikut:
+ **Durasi pekerjaan melebihi beberapa jam**: Untuk pekerjaan pelatihan jangka panjang (mis., > 1-2 jam untuk model kecil, atau days/weeks untuk model pondasi besar dengan miliaran parameter), di mana kerugian kemajuan dari interupsi mahal. Pekerjaan yang lebih pendek mungkin tidak membenarkan I/O overhead.
+ **Untuk instans Spot atau kegagalan perangkat keras**: Di lingkungan yang rentan terhadap gangguan, seperti EC2 Spot (pemberitahuan 2 menit) atau kegagalan perangkat keras (misalnya, kesalahan memori GPU), pos pemeriksaan memungkinkan dimulainya kembali dengan cepat, membuat Spot layak untuk penghematan biaya dalam beban kerja yang toleran terhadap kesalahan.
+ **Pelatihan terdistribusi pada skala**: Untuk pengaturan dengan hundreds/thousands akselerator (misalnya, >100 GPUs), di mana waktu rata-rata antara kegagalan berkurang secara linier dengan skala. Gunakan untuk model/data paralelisme untuk menangani akses pos pemeriksaan bersamaan dan menghindari restart lengkap.
+ **Model skala besar dengan permintaan sumber daya yang tinggi**: Dalam pelatihan LLM skala petabyte, di mana kegagalan tidak dapat dihindari karena ukuran cluster; pendekatan berjenjang (lokal cepat setiap 5-30 menit untuk transien, tahan lama setiap jam untuk kegagalan besar) mengoptimalkan waktu pemulihan vs. efisiensi.
### Gunakan Blok Kapasitas ML untuk jaminan kapasitas instans P dan Trainium
[Blok Kapasitas untuk ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) memungkinkan Anda untuk memesan instans GPU yang sangat dicari, khususnya instans P (misalnya, p6-b200, p5, p5e, p5en, p4d, p4de) dan instans Trainium (misalnya, trn1, trn2), untuk memulai baik segera atau di masa mendatang untuk mendukung beban kerja machine learning (ML) durasi pendek Anda. Reservasi ini ideal untuk memastikan kapasitas untuk tugas-tugas komputasi intensif seperti pelatihan model dan fine-tuning. Harga Blok Kapasitas EC2 terdiri dari biaya reservasi dan biaya sistem operasi. Untuk mempelajari lebih lanjut tentang harga, lihat [Blok Kapasitas EC2 untuk harga ML](https://aws.amazon.com/ec2/capacityblocks/pricing/).
GPUs Untuk memesan AI/ML beban kerja di Amazon EKS untuk jaminan kapasitas yang dapat diprediksi, kami merekomendasikan untuk memanfaatkan Blok Kapasitas ML untuk [Reservasi Kapasitas jangka pendek atau Sesuai Permintaan () ODCRs untuk jaminan kapasitas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) tujuan umum.
+ ODCR memungkinkan Anda untuk memesan kapasitas instans EC2 (misalnya, instans GPU seperti g5 atau p5) di Availability Zone tertentu selama durasi tertentu, memastikan ketersediaan, bahkan selama permintaan tinggi. ODCRs tidak memiliki komitmen jangka panjang, tetapi Anda membayar tarif On-Demand untuk kapasitas cadangan, baik digunakan atau tidak digunakan. Di EKS, ODCRs didukung oleh tipe node seperti [Karpenter](https://karpenter.sh/) dan grup [node terkelola](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html). Untuk memprioritaskan ODCRs di Karpenter, konfigurasikan NodeClass untuk menggunakan bidang. `capacityReservationSelectorTerms` Lihat Dokumentasi [Karpenter NodePools ](https://karpenter.sh/docs/concepts/nodeclasses/#speccapacityreservationselectorterms).
+ Blok Kapasitas adalah mekanisme reservasi khusus untuk instans GPU (misalnya, p5, p4d) atau Trainium (trn1, trn2), yang dirancang untuk beban kerja MS jangka pendek seperti pelatihan model, fine-tuning, atau eksperimen. Anda memesan kapasitas untuk jangka waktu tertentu (biasanya 24 jam hingga 182 hari) dimulai pada tanggal future, hanya membayar untuk waktu yang dipesan. Mereka pra-bayar, memerlukan pra-perencanaan untuk kebutuhan kapasitas dan tidak mendukung penskalaan otomatis, tetapi mereka ditempatkan di EC2 untuk jaringan latensi rendah. UltraClusters Mereka hanya mengenakan biaya untuk periode yang dipesan. Untuk mempelajari selengkapnya, lihat [Temukan dan beli Blok Kapasitas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-purchase.html), atau mulai dengan menyiapkan grup node terkelola dengan Blok Kapasitas menggunakan petunjuk dalam [Membuat grup node terkelola dengan Blok Kapasitas untuk ML](https://docs.aws.amazon.com/eks/latest/userguide/capacity-blocks-mng.html).
Cadangan kapasitas melalui AWS Management Console dan konfigurasikan node Anda untuk menggunakan blok kapasitas ML. Rencanakan reservasi berdasarkan jadwal beban kerja dan uji dalam klaster pementasan. Lihat [Dokumentasi Blok Kapasitas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) untuk informasi lebih lanjut.
### Pertimbangkan Pemesanan Kapasitas Sesuai Permintaan, Amazon EC2 Spot, atau Sesuai Permintaan (ODCR) untuk instans G Amazon EC2
Untuk Instans G Amazon EC2, pertimbangkan opsi pembelian yang berbeda dari On-Demand, Instans Spot Amazon EC2, dan Reservasi Kapasitas Sesuai Permintaan. [ODCRs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html)memungkinkan Anda untuk memesan kapasitas instans EC2 di Availability Zone tertentu untuk durasi tertentu, memastikan ketersediaan bahkan selama permintaan tinggi. Tidak seperti Blok Kapasitas ML, yang hanya tersedia untuk instans P dan Trainium, ODCR dapat digunakan untuk berbagai jenis instans yang lebih luas, termasuk instans G, sehingga cocok untuk beban kerja yang memerlukan kemampuan GPU berbeda, seperti inferensi atau grafik. Saat menggunakan Instans Spot Amazon EC2, dapat beragam di berbagai jenis instans, ukuran, dan zona ketersediaan adalah kunci untuk dapat tetap berada di Spot lebih lama.
ODCRs tidak memiliki komitmen jangka panjang, tetapi Anda membayar tarif On-Demand untuk kapasitas cadangan, baik digunakan atau tidak digunakan. ODCRs dapat dibuat untuk segera digunakan atau dijadwalkan untuk masa depan, memberikan fleksibilitas dalam perencanaan kapasitas. Di Amazon EKS, ODCRs didukung oleh tipe node seperti [Karpenter](https://karpenter.sh/) dan grup [node terkelola](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html). Untuk memprioritaskan ODCRs di Karpenter, konfigurasikan NodeClass untuk menggunakan bidang. `capacityReservationSelectorTerms` Lihat Dokumentasi [Karpenter NodePools ](https://karpenter.sh/docs/concepts/nodepools/). Untuk informasi selengkapnya tentang pembuatan ODCRs, termasuk perintah CLI, lihat Memulai [Reservasi Kapasitas Sesuai Permintaan](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations-getting-started.html).
### Pertimbangkan jenis dan ukuran instans akselerasi lainnya
Memilih instans dan ukuran akselerasi yang sesuai sangat penting untuk mengoptimalkan kinerja dan biaya dalam beban kerja ML Anda di Amazon EKS. Misalnya, keluarga instans GPU yang berbeda memiliki kinerja dan kemampuan yang berbeda seperti memori GPU. **Untuk membantu Anda memilih opsi berkinerja harga paling tinggi, tinjau instans GPU yang tersedia di halaman Jenis Instans [EC2](https://aws.amazon.com/ec2/instance-types/) di bawah Komputasi Akselerasi.** Evaluasi beberapa jenis dan ukuran instans untuk menemukan yang paling sesuai dengan kebutuhan beban kerja spesifik Anda. Pertimbangkan faktor-faktor seperti jumlah GPUs, memori, dan kinerja jaringan. Dengan hati-hati memilih jenis dan ukuran instans GPU yang tepat, Anda dapat mencapai pemanfaatan sumber daya dan efisiensi biaya yang lebih baik di kluster EKS Anda.
Jika Anda menggunakan instance GPU di node EKS maka `nvidia-device-plugin-daemonset` pod akan ada di `kube-system` namespace secara default. Untuk mengetahui dengan cepat apakah Anda sepenuhnya menggunakan GPU dalam instance Anda, Anda dapat menggunakan [nvidia-smi](https://docs.nvidia.com/deploy/nvidia-smi/index.html) seperti yang ditunjukkan di sini:
```
kubectl exec nvidia-device-plugin-daemonset-xxxxx \
-n kube-system -- nvidia-smi \
--query-gpu=index,power.draw,power.limit,temperature.gpu,utilization.gpu,utilization.memory,memory.free,memory.used \
--format=csv -l 5
```
+ Jika `utilization.memory` mendekati 100%, maka kode Anda kemungkinan terikat memori. Ini berarti bahwa GPU (memori) sepenuhnya digunakan tetapi dapat menyarankan bahwa optimasi kinerja lebih lanjut harus diselidiki.
+ Jika mendekati 100%, ini tidak berarti GPU sepenuhnya digunakan. `utilization.gpu` Metrik yang lebih baik untuk dilihat adalah rasio `power.draw` to`power.limit`. Jika rasio ini 100% atau lebih, maka kode Anda sepenuhnya memanfaatkan kapasitas komputasi GPU.
+ `-l 5`Bendera mengatakan untuk menampilkan metrik setiap 5 detik. Dalam kasus jenis instans GPU tunggal, flag kueri indeks tidak diperlukan.
Untuk mempelajari selengkapnya, lihat [instans GPU dalam dokumentasi](https://docs.aws.amazon.com/dlami/latest/devguide/gpu.html) AWS.
### Optimalkan Alokasi Sumber Daya GPU dengan Time-Slicing, MIG, dan Alokasi GPU Fraksional
Batas sumber daya statis di Kubernetes (misalnya, CPU, memori, jumlah GPU) dapat menyebabkan penyediaan berlebih atau kurang dimanfaatkan, terutama untuk beban kerja dinamis seperti inferensi. AI/ML Memilih GPU yang tepat adalah penting. Untuk beban kerja bervolume rendah atau runcing, time-slicing memungkinkan beberapa beban kerja untuk berbagi satu GPU dengan berbagi sumber daya komputasi, berpotensi meningkatkan efisiensi dan mengurangi pemborosan. Berbagi GPU dapat dicapai melalui berbagai opsi:
+ **Memanfaatkan Node Selectors/Node affinity untuk mempengaruhi penjadwalan**: Pastikan node yang disediakan dan pod dijadwalkan sesuai GPUs untuk beban kerja (mis.,) `karpenter.k8s.aws/instance-gpu-name: "a100"`
+ **Time-Slicing**: Menjadwalkan beban kerja untuk berbagi sumber daya komputasi GPU dari waktu ke waktu, memungkinkan eksekusi bersamaan tanpa partisi fisik. Ini sangat ideal untuk beban kerja dengan tuntutan komputasi variabel, tetapi mungkin tidak memiliki isolasi memori.
+ **Multi-Instance GPU (MIG)**: MIG memungkinkan satu GPU NVIDIA untuk dipartisi menjadi beberapa instance yang terisolasi dan didukung dengan NVIDIA Ampere (misalnya, GPU A100), NVIDIA Hopper (misalnya, GPU H100), dan NVIDIA Blackwell (misalnya, Blackwell). GPUs GPUs Setiap instans MIG menerima sumber daya komputasi dan memori khusus, memungkinkan berbagi sumber daya di lingkungan multi-penyewa atau beban kerja yang memerlukan jaminan sumber daya, yang memungkinkan Anda mengoptimalkan pemanfaatan sumber daya GPU, termasuk skenario seperti menyajikan beberapa model dengan ukuran batch berbeda melalui pengiris waktu.
+ **Alokasi GPU pecahan**: Menggunakan penjadwalan berbasis perangkat lunak untuk mengalokasikan bagian dari komputasi atau memori GPU ke beban kerja, menawarkan fleksibilitas untuk beban kerja dinamis. [NVIDIA KAI Scheduler](https://github.com/NVIDIA/KAI-Scheduler), bagian dari platform Run:AI, memungkinkan pod untuk meminta sumber daya GPU fraksional.
Untuk mengaktifkan fitur-fitur ini di EKS, Anda dapat menerapkan Plugin Perangkat NVIDIA, yang mengekspos GPUs sebagai sumber daya yang dapat dijadwalkan dan mendukung pengiris waktu dan MIG. Untuk mempelajari lebih lanjut, lihat [Time-Slicing GPUs di Kubernetes dan [berbagi GPU di Amazon EKS dengan NVIDIA](https://aws.amazon.com/blogs/containers/gpu-sharing-on-amazon-eks-with-nvidia-time-slicing-and-accelerated-ec2-instances/) time-slicing](https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/gpu-sharing.html) dan instans EC2 yang dipercepat.
**Contoh**
Misalnya, untuk mengaktifkan pengiris waktu dengan Plugin Perangkat NVIDIA:
```
apiVersion: v1
kind: ConfigMap
metadata:
name: nvidia-device-plugin-config
namespace: kube-system
data:
config.yaml: |
version: v1
sharing:
timeSlicing:
resources:
- name: nvidia.com/gpu
replicas: 4 # Allow 4 pods to share each GPU
```
**Contoh**
Misalnya, untuk menggunakan KAI Scheduler untuk alokasi GPU fraksional, terapkan bersama Operator GPU NVIDIA dan tentukan sumber daya GPU fraksional dalam spesifikasi pod:
```
apiVersion: v1
kind: Pod
metadata:
name: fractional-gpu-pod-example
annotations:
gpu-fraction: "0.5" # Annotation for 50% GPU
labels:
runai/queue: "default" # Required queue assignment
spec:
containers:
- name: ml-workload
image: nvcr.io/nvidia/pytorch:25.04-py3
resources:
limits:
nvidia.com/gpu: 1
nodeSelector:
nvidia.com/gpu: "true"
schedulerName: kai-scheduler
```
## Ketahanan Node dan Manajemen Job Pelatihan
### Menerapkan Pemeriksaan Kesehatan Node dengan Pemulihan Otomatis
Untuk pekerjaan pelatihan terdistribusi di Amazon EKS yang memerlukan komunikasi antar simpul yang sering, seperti pelatihan model multi-GPU di beberapa node, masalah perangkat keras seperti kegagalan GPU atau EFA dapat menyebabkan gangguan pada pekerjaan pelatihan. Gangguan ini dapat menyebabkan hilangnya kemajuan pelatihan dan peningkatan biaya, terutama untuk AI/ML beban kerja jangka panjang yang bergantung pada perangkat keras yang stabil.
**Untuk membantu menambah ketahanan terhadap kegagalan perangkat keras, seperti kegagalan GPU di kluster EKS yang menjalankan beban kerja GPU, kami sarankan untuk memanfaatkan **Agen Pemantauan Node EKS dengan Perbaikan Otomatis** atau Amazon. SageMaker HyperPod** Sementara Agen Pemantauan Node EKS dengan Perbaikan Otomatis menyediakan fitur-fitur seperti pemantauan kesehatan node dan perbaikan otomatis menggunakan mekanisme Kubernetes standar, SageMaker HyperPod menawarkan ketahanan yang ditargetkan dan fitur tambahan yang dirancang khusus untuk pelatihan ML skala besar, seperti pemeriksaan kesehatan mendalam dan dimulainya kembali pekerjaan otomatis.
+ [Agen Pemantauan Node EKS](https://docs.aws.amazon.com/eks/latest/userguide/node-health.html) dengan Perbaikan Otomatis Node terus memantau kesehatan node dengan membaca log dan menerapkan NodeConditions, termasuk kondisi standar seperti `Ready` dan kondisi khusus untuk perangkat keras yang dipercepat untuk mengidentifikasi masalah seperti GPU atau kegagalan jaringan. Ketika sebuah node dianggap tidak sehat, Node Auto Repair mengikatnya dan menggantinya dengan node baru. Penjadwalan ulang pod dan restart pekerjaan bergantung pada mekanisme Kubernetes standar dan kebijakan restart pekerjaan.
+ Pemeriksaan kesehatan [SageMaker HyperPod](https://catalog.workshops.aws/sagemaker-hyperpod-eks/en-US)mendalam dan agen pemantauan kesehatan terus memantau status kesehatan GPU dan instance berbasis Trainium. Ini disesuaikan untuk AI/ML beban kerja, menggunakan label (misalnya, node-health-status) untuk mengelola kesehatan node. Ketika sebuah node dianggap tidak sehat, HyperPod memicu penggantian otomatis perangkat keras yang rusak, seperti. GPUs Ini mendeteksi kegagalan terkait jaringan untuk EFA melalui pemeriksaan kesehatan dasarnya secara default dan mendukung resume otomatis untuk pekerjaan pelatihan yang terputus, memungkinkan pekerjaan untuk melanjutkan dari pos pemeriksaan terakhir, meminimalkan gangguan untuk tugas-tugas ML skala besar.
[Untuk Agen Pemantau Node EKS dengan Perbaikan Otomatis dan SageMaker HyperPod cluster yang menggunakan EFA, untuk memantau metrik khusus EFA seperti kesalahan Remote Direct Memory Access (RDMA) dan penurunan paket, pastikan driver AWS EFA diinstal.](https://docs.aws.amazon.com/eks/latest/userguide/node-efa.html) Selain itu, kami merekomendasikan untuk menggunakan [Pengaya CloudWatch Observabilitas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-setup-EKS-addon.html) atau menggunakan alat seperti Eksportir DCGM dengan Prometheus dan Grafana untuk memantau EFA, GPU, dan, untuk, metrik spesifik yang terkait dengan fitur-fiturnya. SageMaker HyperPod
### Nonaktifkan Konsolidasi Karpenter untuk beban kerja sensitif interupsi
Untuk beban kerja yang sensitif terhadap gangguan, seperti pemrosesan, tugas AI/ML prediksi skala besar, atau pelatihan, kami merekomendasikan untuk menyetel kebijakan [konsolidasi Karpenter](https://karpenter.sh/v1.0/concepts/disruption/#consolidation) untuk mencegah gangguan selama pelaksanaan pekerjaan. Fitur konsolidasi Karpenter secara otomatis mengoptimalkan biaya cluster dengan menghentikan node yang kurang dimanfaatkan atau menggantinya dengan alternatif yang lebih murah. Namun, bahkan ketika beban kerja sepenuhnya menggunakan GPU, Karpenter dapat mengkonsolidasikan node jika mengidentifikasi jenis instance berukuran tepat dengan harga lebih rendah yang memenuhi persyaratan pod, yang mengarah ke gangguan pekerjaan.
Kebijakan `WhenEmptyOrUnderutilized` konsolidasi dapat menghentikan node sebelum waktunya, yang mengarah ke waktu eksekusi yang lebih lama. Misalnya, interupsi dapat menunda dimulainya kembali pekerjaan karena penjadwalan ulang pod, pemuatan ulang data, yang bisa mahal untuk pekerjaan inferensi batch yang berjalan lama. Untuk mengurangi ini, Anda dapat mengatur `consolidationPolicy` ke `WhenEmpty` dan mengonfigurasi `consolidateAfter` durasi, seperti 1 jam, untuk mempertahankan node selama lonjakan beban kerja. Contoh:
```
disruption:
consolidationPolicy: WhenEmpty
consolidateAfter: 60m
```
Pendekatan ini meningkatkan latensi startup pod untuk beban kerja inferensi batch runcing dan pekerjaan sensitif interupsi lainnya, seperti pemrosesan data inferensi online real-time atau pelatihan model, di mana biaya interupsi melebihi penghematan biaya komputasi. [Anggaran NodePool Gangguan](https://karpenter.sh/docs/concepts/disruption/#nodepool-disruption-budgets) Karpenter adalah fitur lain untuk mengelola gangguan Karpenter. Dengan anggaran, Anda dapat memastikan bahwa tidak lebih dari sejumlah node node akan terganggu pada yang dipilih NodePool pada suatu titik waktu. Anda juga dapat menggunakan anggaran gangguan untuk mencegah semua node terganggu pada waktu tertentu (misalnya jam sibuk). Untuk mempelajari lebih lanjut, lihat dokumentasi [Konsolidasi Karpenter](https://karpenter.sh/docs/concepts/disruption/#consolidation).
### Gunakan Pekerjaan ttlSecondsAfter Kubernetes Selesai untuk Membersihkan Otomatis
Kami merekomendasikan pengaturan `ttlSecondsAfterFinished` untuk pekerjaan Kubernetes di Amazon EKS untuk secara otomatis menghapus objek pekerjaan yang sudah selesai. Objek pekerjaan yang tersisa menggunakan sumber daya klaster, seperti memori server API, dan mempersulit pemantauan dengan mengacaukan dasbor (misalnya, Grafana, Amazon). CloudWatch Misalnya, menyetel TTL 1 jam memastikan pekerjaan dihapus segera setelah selesai, menjaga cluster Anda tetap rapi. Untuk detail selengkapnya, lihat [Pembersihan Otomatis untuk Pekerjaan Selesai](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/).
### Konfigurasikan Preemption Job Prioritas Rendah untuk Pekerjaan/Beban Kerja Prioritas Tinggi
Untuk beban AI/ML kerja prioritas campuran di Amazon EKS, Anda dapat mengonfigurasi preemption pekerjaan dengan prioritas rendah untuk memastikan tugas dengan prioritas lebih tinggi (misalnya, inferensi waktu nyata) menerima sumber daya dengan segera. Tanpa preemption, beban kerja dengan prioritas rendah seperti proses batch (misalnya, inferensi batch, pemrosesan data), layanan non-batch (misalnya, tugas latar belakang, pekerjaan cron), atau pekerjaan intensif CPU/memori (misalnya, layanan web) dapat menunda pod kritis dengan menempati node. Preemption memungkinkan Kubernetes untuk mengusir Pod dengan prioritas rendah ketika Pod dengan prioritas tinggi membutuhkan sumber daya, memastikan alokasi sumber daya yang efisien pada node dengan, atau memori. GPUs CPUs Sebaiknya gunakan Kubernetes `PriorityClass` untuk menetapkan prioritas dan `PodDisruptionBudget` mengendalikan perilaku penggusuran.
```
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
name: low-priority
value: 100
---
spec:
priorityClassName: low-priority
```
Lihat [Dokumentasi Prioritas dan Preemption Kubernetes](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/) untuk informasi selengkapnya.
## Penskalaan dan Kinerja Aplikasi
### Sesuaikan Kapasitas Komputasi untuk beban kerja ML dengan Karpenter atau Static Nodes
Untuk memastikan kapasitas komputasi yang hemat biaya dan responsif untuk alur kerja machine learning (ML) di Amazon EKS, sebaiknya sesuaikan strategi penyediaan node Anda dengan karakteristik beban kerja dan komitmen biaya Anda. Di bawah ini adalah dua pendekatan yang perlu dipertimbangkan: just-in-time penskalaan dengan [Karpenter](https://karpenter.sh/docs/) dan grup node statis untuk kapasitas cadangan.
+ **Just-in-time scaler bidang data seperti Karpenter**: Untuk alur kerja HTML dinamis dengan tuntutan komputasi variabel (misalnya, inferensi berbasis GPU diikuti oleh plotting berbasis CPU), kami merekomendasikan penggunaan scaler bidang data seperti Karpenter. just-in-time
+ **Gunakan grup simpul statis untuk beban kerja yang dapat** diprediksi: Untuk beban kerja HTML kondisi mapan yang dapat diprediksi atau saat menggunakan instans Cadangan, [grup node terkelola EKS](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html) dapat membantu memastikan kapasitas cadangan sepenuhnya disediakan dan digunakan, memaksimalkan penghematan. Pendekatan ini sangat ideal untuk jenis contoh tertentu yang dilakukan melalui RIs atau ODCRs.
**Contoh**
Ini adalah contoh dari Karpenter beragam [NodePool](https://karpenter.sh/docs/concepts/nodepools/)yang memungkinkan peluncuran instans Amazon `g` EC2 di mana pembuatan instans lebih dari tiga.
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu-inference
spec:
template:
spec:
nodeClassRef:
group: karpenter.k8s.aws
kind: EC2NodeClass
name: default
requirements:
- key: karpenter.sh/capacity-type
operator: In
values: ["on-demand"]
- key: karpenter.k8s.aws/instance-category
operator: In
values: ["g"]
- key: karpenter.k8s.aws/instance-generation
operator: Gt
values: ["3"]
- key: kubernetes.io/arch
operator: In
values: ["amd64"]
taints:
- key: nvidia.com/gpu
effect: NoSchedule
limits:
cpu: "1000"
memory: "4000Gi"
nvidia.com/gpu: "10" *# Limit the total number of GPUs to 10 for the NodePool*
disruption:
consolidationPolicy: WhenEmpty
consolidateAfter: 60m
expireAfter: 720h
```
**Contoh**
Contoh menggunakan grup node statis untuk beban kerja pelatihan:
```
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: ml-cluster
region: us-west-2
managedNodeGroups:
- name: gpu-node-group
instanceType: p4d.24xlarge
minSize: 2
maxSize: 2
desiredCapacity: 2
taints:
- key: nvidia.com/gpu
effect: NoSchedule
```
### Gunakan taint dan toleransi untuk mencegah beban kerja yang tidak dipercepat dijadwalkan pada instans yang dipercepat
Menjadwalkan beban kerja yang tidak dipercepat pada sumber daya GPU tidak efisien komputasi, kami merekomendasikan penggunaan taint dan toleransi untuk memastikan pod beban kerja yang tidak dipercepat tidak dijadwalkan pada node yang tidak sesuai. Lihat [dokumentasi Kubernetes](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) untuk informasi lebih lanjut.
### Skala Berdasarkan Kinerja Model
Untuk beban kerja inferensi, sebaiknya gunakan Kubernetes Event-Driven Autoscaling (KEDA) untuk menskalakan berdasarkan metrik kinerja model seperti permintaan inferensi atau throughput token, dengan periode cooldown yang sesuai. Kebijakan penskalaan statis dapat menyediakan sumber daya yang berlebihan atau kurang, berdampak pada biaya dan latensi. Pelajari lebih lanjut di [Dokumentasi KEDA](https://keda.sh/).
## Alokasi sumber daya dinamis untuk manajemen GPU tingkat lanjut
[Alokasi sumber daya dinamis (DRA)](https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/#enabling-dynamic-resource-allocation) merupakan kemajuan mendasar dalam manajemen sumber daya GPU Kubernetes. DRA bergerak melampaui batasan plugin perangkat tradisional untuk memungkinkan berbagi GPU yang canggih, kesadaran topologi, dan koordinasi sumber daya lintas simpul. Tersedia di Amazon EKS [versi 1.33](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions-standard.html#kubernetes-1-33), DRA mengatasi tantangan kritis dalam AI/ML beban kerja dengan menyediakan hal-hal berikut:
+ Alokasi GPU berbutir halus
+ Mekanisme berbagi tingkat lanjut, seperti Multi-Process service (MPS) dan Multi-Instance GPU (MIG)
+ Dukungan untuk arsitektur perangkat keras generasi berikutnya, termasuk NVIDIA GB200 UltraServers
Alokasi GPU tradisional diperlakukan GPUs sebagai sumber daya bilangan bulat buram, menciptakan pemanfaatan yang kurang signifikan (seringkali 30-40% dalam cluster produksi). Ini terjadi karena beban kerja menerima akses eksklusif ke seluruh GPUs bahkan ketika hanya membutuhkan sumber daya fraksional. DRA mengubah model ini dengan memperkenalkan alokasi deklaratif terstruktur yang menyediakan penjadwal Kubernetes dengan visibilitas lengkap ke dalam karakteristik perangkat keras dan persyaratan beban kerja. Hal ini memungkinkan keputusan penempatan cerdas dan berbagi sumber daya yang efisien.
### Keuntungan menggunakan DRA bukan plugin perangkat NVIDIA
Plugin perangkat NVIDIA (mulai dari versi`0.12.0`) mendukung mekanisme berbagi GPU termasuk time-slicing, MPS, dan MIG. Namun, ada batasan arsitektur yang ditangani DRA.
**Keterbatasan plugin perangkat NVIDIA**
+ **Konfigurasi statis: Konfigurasi** berbagi GPU (replika pengiris waktu dan pengaturan MPS) memerlukan pra-konfigurasi di seluruh klaster. `ConfigMaps` Ini membuat penyediaan strategi berbagi yang berbeda untuk beban kerja yang berbeda menjadi sulit.
+ **Pemilihan granular terbatas:** Meskipun plugin perangkat mengekspos karakteristik GPU melalui label node, beban kerja tidak dapat secara dinamis meminta konfigurasi GPU tertentu (ukuran memori dan kemampuan komputasi) sebagai bagian dari keputusan penjadwalan.
+ **Tidak ada koordinasi sumber daya lintas simpul:** Tidak dapat mengelola sumber daya GPU terdistribusi di beberapa node atau mengekspresikan persyaratan topologi kompleks seperti NVLink domain untuk sistem seperti NVIDIA. GB200
+ **Batasan penjadwal:** Penjadwal Kubernetes memperlakukan sumber daya GPU sebagai bilangan bulat buram, membatasi kemampuannya untuk membuat keputusan sadar topologi atau menangani dependensi sumber daya yang kompleks.
+ **Kompleksitas konfigurasi:** Menyiapkan strategi berbagi yang berbeda membutuhkan pelabelan node yang banyak `ConfigMaps` dan hati-hati, menciptakan kompleksitas operasional.
**Solusi dengan DRA**
+ **Pemilihan sumber daya dinamis:** DRA memungkinkan beban kerja untuk menentukan persyaratan terperinci (memori GPU, versi driver, dan atribut tertentu) pada saat permintaan selesai. `resourceclaims` Ini memungkinkan pencocokan sumber daya yang lebih fleksibel.
+ **Kesadaran topologi:** Melalui parameter terstruktur dan pemilih perangkat, DRA menangani persyaratan kompleks seperti komunikasi GPU lintas simpul dan interkoneksi yang koheren memori.
+ **Manajemen sumber daya lintas-node:** `computeDomains` memungkinkan koordinasi sumber daya GPU terdistribusi di beberapa node, penting untuk sistem seperti GB200 dengan saluran IMEX.
+ **Konfigurasi khusus beban kerja: Masing-masing `ResourceClaim` menentukan strategi dan konfigurasi** berbagi yang berbeda, memungkinkan kontrol berbutir halus per beban kerja daripada pengaturan di seluruh cluster.
+ **Integrasi penjadwal yang disempurnakan:** DRA menyediakan penjadwal dengan informasi perangkat terperinci dan memungkinkan keputusan penempatan yang lebih cerdas berdasarkan topologi perangkat keras dan karakteristik sumber daya.
Penting: DRA tidak menggantikan plugin perangkat NVIDIA sepenuhnya. Driver NVIDIA DRA bekerja bersama plugin perangkat untuk memberikan kemampuan yang ditingkatkan. Plugin perangkat terus menangani penemuan dan manajemen GPU dasar, sementara DRA menambahkan fitur alokasi dan penjadwalan lanjutan.
### Instans yang didukung oleh DRA dan fitur-fiturnya
Dukungan DRA bervariasi menurut keluarga instans Amazon EC2 dan arsitektur GPU, seperti yang ditunjukkan pada tabel berikut.
| Keluarga instans | Jenis GPU | Mengiris waktu | Dukungan MIG | Dukungan MPS | Dukungan IMEX | Kasus penggunaan |
| --- | --- | --- | --- | --- | --- | --- |
| G5 | NVIDIA A10G | Ya | Tidak | Ya | Tidak | Beban kerja inferensi dan grafis |
| G6 | NVIDIA L4 | Ya | Tidak | Ya | Tidak | Inferensi AI dan pemrosesan video |
| G6e | NVIDIA L40-AN | Ya | Tidak | Ya | Tidak | Pelatihan, inferensi, dan grafik |
| P4D/P4DE | NVIDIA A100 | Ya | Ya | Ya | Tidak | Pelatihan skala besar dan HPC |
| P5 | NVIDIA H100 | Ya | Ya | Ya | Tidak | Pelatihan model pondasi |
| P6 | NVIDIA B200 | Ya | Ya | Ya | Tidak | Model miliaran atau triliunan parameter, pelatihan terdistribusi, dan inferensi |
| P6e | NVIDIA GB200 | Ya | Ya | Ya | Ya | Model miliaran atau triliunan parameter, pelatihan terdistribusi, dan inferensi |
Berikut ini adalah deskripsi dari setiap fitur dalam tabel:
+ **Time-slicing**: Memungkinkan beberapa beban kerja untuk berbagi sumber daya komputasi GPU dari waktu ke waktu.
+ **Multi-Instance GPU (MIG)**: Partisi tingkat perangkat keras yang membuat instance GPU terisolasi.
+ **Multi-Process service (MPS)**: Memungkinkan eksekusi bersamaan dari beberapa proses CUDA pada satu GPU.
+ **Internode Memory Exchange (IMEX): Komunikasi** koheren memori lintas node untuk. GB200 UltraServers
### Sumber daya tambahan
Untuk informasi selengkapnya tentang driver Kubernetes DRA dan NVIDIA DRA, lihat sumber daya berikut di: GitHub
+ Kubernetes [dynamic-resource-allocation](https://github.com/kubernetes/dynamic-resource-allocation)
+ [Proposal peningkatan Kubernetes untuk DRA](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/3063-dynamic-resource-allocation)
+ [Driver NVIDIA DRA untuk GPUs](https://github.com/NVIDIA/k8s-dra-driver-gpu)
+ [Contoh NVIDIA DRA dan mulai cepat](https://github.com/NVIDIA/k8s-dra-driver-gpu/tree/main/demo/specs/quickstart)
### Siapkan alokasi sumber daya dinamis untuk manajemen GPU tingkat lanjut
Topik berikut menunjukkan cara mengatur alokasi sumber daya dinamis (DRA) untuk manajemen GPU tingkat lanjut.
#### Prasyarat
Sebelum menerapkan DRA di Amazon EKS, pastikan lingkungan Anda memenuhi persyaratan berikut.
##### Konfigurasi klaster
+ Amazon EKS cluster menjalankan versi `1.33` atau yang lebih baru
+ [Grup node terkelola Amazon EKS (DRA saat ini hanya didukung oleh grup node terkelola dengan AL2023 dan Bottlerocket NVIDIA dioptimalkan AMIs, bukan dengan Karpenter)](https://github.com/kubernetes-sigs/karpenter/issues/1231)
+ Node pekerja berkemampuan GPU NVIDIA dengan tipe instans yang sesuai
##### Komponen yang dibutuhkan
+ Versi plugin perangkat NVIDIA `0.17.1` atau yang lebih baru
+ Versi driver NVIDIA DRA `25.3.0` atau yang lebih baru
#### Langkah 1: Buat cluster dengan grup node yang mendukung DRA menggunakan eksctl
1. Buat file konfigurasi cluster bernama`dra-eks-cluster.yaml`:
```
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: dra-eks-cluster
region: us-west-2
version: '1.33'
managedNodeGroups:
- name: gpu-dra-nodes
amiFamily: AmazonLinux2023
instanceType: g6.12xlarge
desiredCapacity: 2
minSize: 1
maxSize: 3
labels:
node-type: "gpu-dra"
nvidia.com/gpu.present: "true"
taints:
- key: nvidia.com/gpu
value: "true"
effect: NoSchedule
```
1. Buat cluster:
```
eksctl create cluster -f dra-eks-cluster.yaml
```
#### Langkah 2: Menyebarkan plugin perangkat NVIDIA
Terapkan plugin perangkat NVIDIA untuk mengaktifkan penemuan GPU dasar:
1. Tambahkan repositori Helm plugin perangkat NVIDIA:
```
helm repo add nvidia https://nvidia.github.io/k8s-device-plugin
helm repo update
```
1. Buat nilai kustom untuk plugin perangkat:
```
cat < nvidia-device-plugin-values.yaml
gfd:
enabled: true
nfd:
enabled: true
tolerations:
- key: nvidia.com/gpu
operator: Exists
effect: NoSchedule
EOF
```
1. Instal plug-in perangkat NVIDIA:
```
helm install nvidia-device-plugin nvidia/nvidia-device-plugin \
--namespace nvidia-device-plugin \
--create-namespace \
--version v0.17.1 \
--values nvidia-device-plugin-values.yaml
```
#### Langkah 3: Menyebarkan bagan Helm driver NVIDIA DRA
1. Buat file `dra-driver-values.yaml` nilai untuk driver DRA:
```
---
nvidiaDriverRoot: /
gpuResourcesEnabledOverride: true
resources:
gpus:
enabled: true
computeDomains:
enabled: true # Enable for GB200 IMEX support
controller:
tolerations:
- key: nvidia.com/gpu
operator: Exists
effect: NoSchedule
kubeletPlugin:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: "nvidia.com/gpu.present"
operator: In
values: ["true"]
tolerations:
- key: nvidia.com/gpu
operator: Exists
effect: NoSchedule
```
1. Tambahkan repositori NVIDIA NGC Helm:
```
helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm repo update
```
1. Instal driver NVIDIA DRA:
```
helm install nvidia-dra-driver nvidia/nvidia-dra-driver-gpu \
--version="25.3.0-rc.2" \
--namespace nvidia-dra-driver \
--create-namespace \
--values dra-driver-values.yaml
```
#### Langkah 4: Verifikasi instalasi DRA
1. Verifikasi bahwa sumber daya DRA API tersedia:
```
kubectl api-resources | grep resource.k8s.io/v1beta1
```
Berikut ini adalah output yang diharapkan:
```
deviceclasses resource.k8s.io/v1beta1 false DeviceClass
resourceclaims resource.k8s.io/v1beta1 true ResourceClaim
resourceclaimtemplates resource.k8s.io/v1beta1 true ResourceClaimTemplate
resourceslices resource.k8s.io/v1beta1 false ResourceSlice
```
1. Periksa kelas perangkat yang tersedia:
```
kubectl get deviceclasses
```
Berikut ini adalah contoh output yang diharapkan:
```
NAME AGE
compute-domain-daemon.nvidia.com 4h39m
compute-domain-default-channel.nvidia.com 4h39m
gpu.nvidia.com 4h39m
mig.nvidia.com 4h39m
```
Saat instans GPU G6 yang baru dibuat bergabung dengan cluster Amazon EKS Anda dengan DRA diaktifkan, tindakan berikut akan terjadi:
+ Driver NVIDIA DRA secara otomatis menemukan GPU A10G dan membuat dua `resourceslices` pada node itu.
+ `gpu.nvidia.com`Slice mendaftarkan perangkat GPU A10G fisik dengan spesifikasinya (memori, kemampuan komputasi, dan banyak lagi).
+ Karena A10G tidak mendukung partisi MIG, `compute-domain.nvidia.com` irisan membuat domain komputasi tunggal yang mewakili seluruh konteks komputasi GPU.
+ Ini kemudian `resourceslices` dipublikasikan ke server API Kubernetes, membuat sumber daya GPU tersedia untuk penjadwalan. `resourceclaims`
Penjadwal DRA sekarang dapat dengan cerdas mengalokasikan GPU ini ke Pod yang meminta sumber daya GPU melalui`resourceclaimtemplates`, menyediakan manajemen sumber daya yang lebih fleksibel dibandingkan dengan pendekatan plugin perangkat tradisional. Ini terjadi secara otomatis tanpa intervensi manual. Node hanya tersedia untuk beban kerja GPU setelah driver DRA menyelesaikan penemuan sumber daya dan proses pendaftaran.
Ketika Anda menjalankan perintah berikut:
```
kubectl get resourceslices
```
Berikut ini adalah contoh output yang diharapkan:
```
NAME NODE DRIVER POOL AGE
ip-100-64-129-47.ec2.internal-compute-domain.nvidia.com-rwsts ip-100-64-129-47.ec2.internal compute-domain.nvidia.com ip-100-64-129-47.ec2.internal 35m
ip-100-64-129-47.ec2.internal-gpu.nvidia.com-6kndg ip-100-64-129-47.ec2.internal gpu.nvidia.com ip-100-64-129-47.ec2.internal 35m
```
Lanjutkan ke [Jadwalkan beban kerja GPU sederhana menggunakan alokasi sumber daya dinamis](#aiml-dra-workload).
### Jadwalkan beban kerja GPU sederhana menggunakan alokasi sumber daya dinamis
Untuk menjadwalkan beban kerja GPU sederhana menggunakan alokasi sumber daya dinamis (DRA), lakukan langkah-langkah berikut. Sebelum melanjutkan, pastikan Anda telah mengikuti[Siapkan alokasi sumber daya dinamis untuk manajemen GPU tingkat lanjut](#aiml-dra-setup).
1. Buat dasar `ResourceClaimTemplate` untuk alokasi GPU dengan file bernama: `basic-gpu-claim-template.yaml`
```
---
apiVersion: v1
kind: Namespace
metadata:
name: gpu-test1
---
apiVersion: resource.k8s.io/v1beta1
kind: ResourceClaimTemplate
metadata:
namespace: gpu-test1
name: single-gpu
spec:
spec:
devices:
requests:
- name: gpu
deviceClassName: gpu.nvidia.com
```
1. Terapkan template:
```
kubectl apply -f basic-gpu-claim-template.yaml
```
1. Verifikasi status:
```
kubectl get resourceclaimtemplates -n gpu-test1
```
Berikut ini adalah output contoh:
```
NAME AGE
single-gpu 9m16s
```
1. Buat Pod yang menggunakan file `ResourceClaimTemplate` dengan nama`basic-gpu-pod.yaml`:
```
---
apiVersion: v1
kind: Pod
metadata:
namespace: gpu-test1
name: gpu-pod
labels:
app: pod
spec:
containers:
- name: ctr0
image: ubuntu:22.04
command: ["bash", "-c"]
args: ["nvidia-smi -L; trap 'exit 0' TERM; sleep 9999 & wait"]
resources:
claims:
- name: gpu0
resourceClaims:
- name: gpu0
resourceClaimTemplateName: single-gpu
nodeSelector:
NodeGroupType: gpu-dra
nvidia.com/gpu.present: "true"
tolerations:
- key: "nvidia.com/gpu"
operator: "Exists"
effect: "NoSchedule"
```
1. Terapkan dan pantau Pod:
```
kubectl apply -f basic-gpu-pod.yaml
```
1. Periksa status Pod:
```
kubectl get pod -n gpu-test1
```
Berikut ini adalah contoh output yang diharapkan:
```
NAME READY STATUS RESTARTS AGE
gpu-pod 1/1 Running 0 13m
```
1. Periksa `ResourceClaim` statusnya:
```
kubectl get resourceclaims -n gpu-test1
```
Berikut ini adalah contoh output yang diharapkan:
```
NAME STATE AGE
gpu-pod-gpu0-l76cg allocated,reserved 9m6s
```
1. Lihat log Pod untuk melihat informasi GPU:
```
kubectl logs gpu-pod -n gpu-test1
```
Berikut ini adalah contoh output yang diharapkan:
```
GPU 0: NVIDIA L4 (UUID: GPU-da7c24d7-c7e3-ed3b-418c-bcecc32af7c5)
```
Lanjutkan ke [Teknik optimasi GPU dengan alokasi sumber daya dinamis](#aiml-dra-optimization) teknik optimasi GPU yang lebih canggih menggunakan DRA.
### Teknik optimasi GPU dengan alokasi sumber daya dinamis
Beban kerja GPU modern membutuhkan manajemen sumber daya yang canggih untuk mencapai pemanfaatan dan efisiensi biaya yang optimal. DRA memungkinkan beberapa teknik optimasi canggih yang menangani berbagai kasus penggunaan dan kemampuan perangkat keras:
+ **Time-slicing** memungkinkan beberapa beban kerja untuk berbagi sumber daya komputasi GPU dari waktu ke waktu, menjadikannya ideal untuk beban kerja inferensi dengan penggunaan GPU sporadis. Sebagai contoh, lihat [Optimalkan beban kerja GPU dengan pengiris waktu](#aiml-dra-timeslicing).
+ **Multi-Process service (MPS)** memungkinkan eksekusi bersamaan dari beberapa proses CUDA pada satu GPU dengan isolasi yang lebih baik daripada time-slicing. Sebagai contoh, lihat [Optimalkan beban kerja GPU dengan MPS](#aiml-dra-mps).
+ **Multi-Instance GPU (MIG)** menyediakan partisi tingkat perangkat keras, membuat instance GPU terisolasi dengan sumber daya komputasi dan memori khusus. Sebagai contoh, lihat [Optimalkan beban kerja GPU dengan GPU Multi-Instance](#aiml-dra-mig).
+ **Internode Memory Exchange (IMEX)** memungkinkan komunikasi yang koheren memori di seluruh node untuk pelatihan terdistribusi pada sistem NVIDIA. GB200 Sebagai contoh, lihat [Optimalkan beban kerja GPU dengan IMEX menggunakan instans P6e GB200](#aiml-dra-imex).
Teknik-teknik ini secara signifikan dapat meningkatkan pemanfaatan sumber daya. Organizations melaporkan pemanfaatan GPU meningkat dari 30-40% dengan alokasi tradisional menjadi 80-90% dengan strategi berbagi yang dioptimalkan. Pilihan teknik tergantung pada karakteristik beban kerja, persyaratan isolasi, dan kemampuan perangkat keras.
#### Optimalkan beban kerja GPU dengan pengiris waktu
Time-slicing memungkinkan beberapa beban kerja untuk berbagi sumber daya komputasi GPU dengan menjadwalkannya untuk berjalan secara berurutan pada GPU fisik yang sama. Ini sangat ideal untuk beban kerja inferensi dengan penggunaan GPU sporadis.
Lakukan langkah-langkah berikut.
1. Tentukan `ResourceClaimTemplate` for time-slicing dengan file bernama: `timeslicing-claim-template.yaml`
```
---
apiVersion: v1
kind: Namespace
metadata:
name: timeslicing-gpu
---
apiVersion: resource.k8s.io/v1beta1
kind: ResourceClaimTemplate
metadata:
name: timeslicing-gpu-template
namespace: timeslicing-gpu
spec:
spec:
devices:
requests:
- name: shared-gpu
deviceClassName: gpu.nvidia.com
config:
- requests: ["shared-gpu"]
opaque:
driver: gpu.nvidia.com
parameters:
apiVersion: resource.nvidia.com/v1beta1
kind: GpuConfig
sharing:
strategy: TimeSlicing
```
1. Tentukan Pod menggunakan time-slicing dengan file bernama: `timeslicing-pod.yaml`
```
---
# Pod 1 - Inference workload
apiVersion: v1
kind: Pod
metadata:
name: inference-pod-1
namespace: timeslicing-gpu
labels:
app: gpu-inference
spec:
restartPolicy: Never
containers:
- name: inference-container
image: nvcr.io/nvidia/pytorch:25.04-py3
command: ["python", "-c"]
args:
- |
import torch
import time
import os
print(f"=== POD 1 STARTING ===")
print(f"GPU available: {torch.cuda.is_available()}")
print(f"GPU count: {torch.cuda.device_count()}")
if torch.cuda.is_available():
device = torch.cuda.current_device()
print(f"Current GPU: {torch.cuda.get_device_name(device)}")
print(f"GPU Memory: {torch.cuda.get_device_properties(device).total_memory / 1024**3:.1f} GB")
# Simulate inference workload
for i in range(20):
x = torch.randn(1000, 1000).cuda()
y = torch.mm(x, x.t())
print(f"Pod 1 - Iteration {i+1} completed at {time.strftime('%H:%M:%S')}")
time.sleep(60)
else:
print("No GPU available!")
time.sleep(5)
resources:
claims:
- name: shared-gpu-claim
resourceClaims:
- name: shared-gpu-claim
resourceClaimTemplateName: timeslicing-gpu-template
nodeSelector:
NodeGroupType: "gpu-dra"
nvidia.com/gpu.present: "true"
tolerations:
- key: nvidia.com/gpu
operator: Exists
effect: NoSchedule
---
# Pod 2 - Training workload
apiVersion: v1
kind: Pod
metadata:
name: training-pod-2
namespace: timeslicing-gpu
labels:
app: gpu-training
spec:
restartPolicy: Never
containers:
- name: training-container
image: nvcr.io/nvidia/pytorch:25.04-py3
command: ["python", "-c"]
args:
- |
import torch
import time
import os
print(f"=== POD 2 STARTING ===")
print(f"GPU available: {torch.cuda.is_available()}")
print(f"GPU count: {torch.cuda.device_count()}")
if torch.cuda.is_available():
device = torch.cuda.current_device()
print(f"Current GPU: {torch.cuda.get_device_name(device)}")
print(f"GPU Memory: {torch.cuda.get_device_properties(device).total_memory / 1024**3:.1f} GB")
# Simulate training workload with heavier compute
for i in range(15):
x = torch.randn(2000, 2000).cuda()
y = torch.mm(x, x.t())
loss = torch.sum(y)
print(f"Pod 2 - Training step {i+1}, Loss: {loss.item():.2f} at {time.strftime('%H:%M:%S')}")
time.sleep(5)
else:
print("No GPU available!")
time.sleep(60)
resources:
claims:
- name: shared-gpu-claim-2
resourceClaims:
- name: shared-gpu-claim-2
resourceClaimTemplateName: timeslicing-gpu-template
nodeSelector:
NodeGroupType: "gpu-dra"
nvidia.com/gpu.present: "true"
tolerations:
- key: nvidia.com/gpu
operator: Exists
effect: NoSchedule
```
1. Terapkan template dan Pod:
```
kubectl apply -f timeslicing-claim-template.yaml
kubectl apply -f timeslicing-pod.yaml
```
1. Pantau klaim sumber daya:
```
kubectl get resourceclaims -n timeslicing-gpu -w
```
Berikut ini adalah output contoh:
```
NAME STATE AGE
inference-pod-1-shared-gpu-claim-9p97x allocated,reserved 21s
training-pod-2-shared-gpu-claim-2-qghnb pending 21s
inference-pod-1-shared-gpu-claim-9p97x pending 105s
training-pod-2-shared-gpu-claim-2-qghnb pending 105s
inference-pod-1-shared-gpu-claim-9p97x pending 105s
training-pod-2-shared-gpu-claim-2-qghnb allocated,reserved 105s
inference-pod-1-shared-gpu-claim-9p97x pending 105s
```
Pod Pertama (`inference-pod-1`)
+ **Negara**: `allocated,reserved`
+ **Artinya**: DRA menemukan GPU yang tersedia dan memesannya untuk Pod ini
+ **Status pod**: Mulai berjalan segera
Pod Kedua (`training-pod-2`)
+ **Negara**: `pending`
+ **Artinya**: Menunggu DRA mengonfigurasi pengiris waktu pada GPU yang sama
+ **Status pod**: Menunggu untuk dijadwalkan
+ Negara akan beralih dari `pending` `allocated,reserved` ke `running`
#### Optimalkan beban kerja GPU dengan MPS
Multi-Process Service (MPS) memungkinkan eksekusi bersamaan dari beberapa konteks CUDA pada satu GPU dengan isolasi yang lebih baik daripada time-slicing.
Lakukan langkah-langkah berikut.
1. Tentukan `ResourceClaimTemplate` untuk MPS dengan file bernama`mps-claim-template.yaml`:
```
---
apiVersion: v1
kind: Namespace
metadata:
name: mps-gpu
---
apiVersion: resource.k8s.io/v1beta1
kind: ResourceClaimTemplate
metadata:
name: mps-gpu-template
namespace: mps-gpu
spec:
spec:
devices:
requests:
- name: shared-gpu
deviceClassName: gpu.nvidia.com
config:
- requests: ["shared-gpu"]
opaque:
driver: gpu.nvidia.com
parameters:
apiVersion: resource.nvidia.com/v1beta1
kind: GpuConfig
sharing:
strategy: MPS
```
1. Mendefinisikan Pod menggunakan MPS dengan file bernama`mps-pod.yaml`:
```
---
# Single Pod with Multiple Containers sharing GPU via MPS
apiVersion: v1
kind: Pod
metadata:
name: mps-multi-container-pod
namespace: mps-gpu
labels:
app: mps-demo
spec:
restartPolicy: Never
containers:
# Container 1 - Inference workload
- name: inference-container
image: nvcr.io/nvidia/pytorch:25.04-py3
command: ["python", "-c"]
args:
- |
import torch
import torch.nn as nn
import time
import os
print(f"=== INFERENCE CONTAINER STARTING ===")
print(f"Process ID: {os.getpid()}")
print(f"GPU available: {torch.cuda.is_available()}")
print(f"GPU count: {torch.cuda.device_count()}")
if torch.cuda.is_available():
device = torch.cuda.current_device()
print(f"Current GPU: {torch.cuda.get_device_name(device)}")
print(f"GPU Memory: {torch.cuda.get_device_properties(device).total_memory / 1024**3:.1f} GB")
# Create inference model
model = nn.Sequential(
nn.Linear(1000, 500),
nn.ReLU(),
nn.Linear(500, 100)
).cuda()
# Run inference
for i in range(1, 999999):
with torch.no_grad():
x = torch.randn(128, 1000).cuda()
output = model(x)
result = torch.sum(output)
print(f"Inference Container PID {os.getpid()}: Batch {i}, Result: {result.item():.2f} at {time.strftime('%H:%M:%S')}")
time.sleep(2)
else:
print("No GPU available!")
time.sleep(60)
resources:
claims:
- name: shared-gpu-claim
request: shared-gpu
# Container 2 - Training workload
- name: training-container
image: nvcr.io/nvidia/pytorch:25.04-py3
command: ["python", "-c"]
args:
- |
import torch
import torch.nn as nn
import time
import os
print(f"=== TRAINING CONTAINER STARTING ===")
print(f"Process ID: {os.getpid()}")
print(f"GPU available: {torch.cuda.is_available()}")
print(f"GPU count: {torch.cuda.device_count()}")
if torch.cuda.is_available():
device = torch.cuda.current_device()
print(f"Current GPU: {torch.cuda.get_device_name(device)}")
print(f"GPU Memory: {torch.cuda.get_device_properties(device).total_memory / 1024**3:.1f} GB")
# Create training model
model = nn.Sequential(
nn.Linear(2000, 1000),
nn.ReLU(),
nn.Linear(1000, 500),
nn.ReLU(),
nn.Linear(500, 10)
).cuda()
criterion = nn.MSELoss()
optimizer = torch.optim.Adam(model.parameters(), lr=0.001)
# Run training
for epoch in range(1, 999999):
x = torch.randn(64, 2000).cuda()
target = torch.randn(64, 10).cuda()
optimizer.zero_grad()
output = model(x)
loss = criterion(output, target)
loss.backward()
optimizer.step()
print(f"Training Container PID {os.getpid()}: Epoch {epoch}, Loss: {loss.item():.4f} at {time.strftime('%H:%M:%S')}")
time.sleep(3)
else:
print("No GPU available!")
time.sleep(60)
resources:
claims:
- name: shared-gpu-claim
request: shared-gpu
resourceClaims:
- name: shared-gpu-claim
resourceClaimTemplateName: mps-gpu-template
nodeSelector:
NodeGroupType: "gpu-dra"
nvidia.com/gpu.present: "true"
tolerations:
- key: nvidia.com/gpu
operator: Exists
effect: NoSchedule
```
1. Terapkan template dan buat beberapa MPS Pod:
```
kubectl apply -f mps-claim-template.yaml
kubectl apply -f mps-pod.yaml
```
1. Pantau klaim sumber daya:
```
kubectl get resourceclaims -n mps-gpu -w
```
Berikut ini adalah output contoh:
```
NAME STATE AGE
mps-multi-container-pod-shared-gpu-claim-2p9kx allocated,reserved 86s
```
Konfigurasi ini menunjukkan berbagi GPU sejati menggunakan NVIDIA Multi-Process Service (MPS) melalui dynamic resource allocation (DRA). Tidak seperti time-slicing di mana beban kerja bergiliran menggunakan GPU secara berurutan, MPS memungkinkan kedua kontainer berjalan secara bersamaan pada GPU fisik yang sama. Insight kuncinya adalah bahwa berbagi MPS DRA membutuhkan beberapa kontainer dalam satu Pod, bukan beberapa Pod terpisah. Ketika di-deploy, driver DRA mengalokasikan satu `ResourceClaim` ke Pod dan secara otomatis mengkonfigurasi MPS untuk memungkinkan kedua kontainer inferensi dan pelatihan untuk mengeksekusi secara bersamaan.
Setiap kontainer mendapatkan ruang memori GPU yang terisolasi dan sumber daya komputasi, dengan daemon MPS mengoordinasikan akses ke perangkat keras yang mendasarinya. Anda dapat memverifikasi bahwa ini berfungsi dengan melakukan hal berikut:
+ Memeriksa`nvidia-smi`, yang akan menampilkan kedua kontainer sebagai proses M\$1C (`MPS + Compute`) berbagi perangkat GPU yang sama.
+ Memantau log dari kedua kontainer, yang akan menampilkan stempel waktu yang disisipkan yang membuktikan eksekusi simultan.
Pendekatan ini memaksimalkan pemanfaatan GPU dengan memungkinkan beban kerja pelengkap untuk berbagi perangkat keras GPU yang mahal secara efisien, daripada membiarkannya kurang dimanfaatkan oleh satu proses.
##### Kontainer1: `inference-container`
```
root@mps-multi-container-pod:/workspace# nvidia-smi
Wed Jul 16 21:09:30 2025
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 570.158.01 Driver Version: 570.158.01 CUDA Version: 12.9 |
|-----------------------------------------+------------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+========================+======================|
| 0 NVIDIA L4 On | 00000000:35:00.0 Off | 0 |
| N/A 48C P0 28W / 72W | 597MiB / 23034MiB | 0% E. Process |
| | | N/A |
+-----------------------------------------+------------------------+----------------------+
+-----------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=========================================================================================|
| 0 N/A N/A 1 M+C python 246MiB |
+-----------------------------------------------------------------------------------------+
```
##### Kontainer2: `training-container`
```
root@mps-multi-container-pod:/workspace# nvidia-smi
Wed Jul 16 21:16:00 2025
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 570.158.01 Driver Version: 570.158.01 CUDA Version: 12.9 |
|-----------------------------------------+------------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+========================+======================|
| 0 NVIDIA L4 On | 00000000:35:00.0 Off | 0 |
| N/A 51C P0 28W / 72W | 597MiB / 23034MiB | 0% E. Process |
| | | N/A |
+-----------------------------------------+------------------------+----------------------+
+-----------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=========================================================================================|
| 0 N/A N/A 1 M+C python 314MiB |
+-----------------------------------------------------------------------------------------+
```
#### Optimalkan beban kerja GPU dengan GPU Multi-Instance
Multi-instance GPU (MIG) menyediakan partisi tingkat perangkat keras, membuat instance GPU terisolasi dengan sumber daya komputasi dan memori khusus.
Menggunakan partisi MIG dinamis dengan berbagai profil memerlukan Operator GPU [NVIDIA](https://github.com/NVIDIA/gpu-operator). Operator GPU NVIDIA menggunakan [MIG Manager](https://github.com/NVIDIA/gpu-operator/blob/47fea81ac752a68745300b5ec77f3bd8ee69d059/deployments/gpu-operator/values.yaml#L374) untuk membuat profil MIG dan me-reboot instance GPU seperti P4D, P4De, P5, P6, dan lainnya untuk menerapkan perubahan konfigurasi. Operator GPU mencakup kemampuan manajemen MIG yang komprehensif melalui komponen MIG Manager, yang mengawasi perubahan label node dan secara otomatis menerapkan konfigurasi MIG yang sesuai. Ketika perubahan profil MIG diminta, operator dengan anggun mematikan semua klien GPU, menerapkan geometri partisi baru, dan memulai ulang layanan yang terpengaruh. Proses ini memerlukan reboot node untuk instance GPU untuk memastikan transisi status GPU yang bersih. Inilah sebabnya mengapa mengaktifkan `WITH0REBOOT=true` konfigurasi MIG Manager sangat penting untuk penerapan MIG yang sukses.
Anda memerlukan [Driver NVIDIA DRA](https://github.com/NVIDIA/k8s-dra-driver-gpu) dan Operator GPU NVIDIA untuk bekerja dengan MIG di Amazon EKS. Anda tidak memerlukan Plugin Perangkat NVIDIA dan Eksportir DCGM selain ini karena ini adalah bagian dari Operator GPU NVIDIA. Karena EKS NVIDIA AMIs datang dengan Driver NVIDIA yang sudah diinstal sebelumnya, kami menonaktifkan penyebaran driver oleh Operator GPU untuk menghindari konflik dan memanfaatkan driver yang dioptimalkan yang sudah ada pada instance. Driver NVIDIA DRA menangani alokasi sumber daya dinamis untuk instans MIG, sementara Operator GPU mengelola seluruh siklus hidup GPU. Ini termasuk konfigurasi MIG, fungsionalitas plugin perangkat, pemantauan melalui DCGM, dan penemuan fitur node. Pendekatan terintegrasi ini memberikan solusi lengkap untuk manajemen GPU perusahaan, dengan isolasi tingkat perangkat keras dan kemampuan alokasi sumber daya dinamis.
##### Langkah 1: Menyebarkan Operator GPU NVIDIA
1. Tambahkan repositori Operator GPU NVIDIA:
```
helm repo add nvidia https://nvidia.github.io/gpu-operator
helm repo update
```
1. Buat `gpu-operator-values.yaml` file:
```
driver:
enabled: false
mig:
strategy: mixed
migManager:
enabled: true
env:
- name: WITH_REBOOT
value: "true"
config:
create: true
name: custom-mig-parted-configs
default: "all-disabled"
data:
config.yaml: |-
version: v1
mig-configs:
all-disabled:
- devices: all
mig-enabled: false
# P4D profiles (A100 40GB)
p4d-half-balanced:
- devices: [0, 1, 2, 3]
mig-enabled: true
mig-devices:
"1g.5gb": 2
"2g.10gb": 1
"3g.20gb": 1
- devices: [4, 5, 6, 7]
mig-enabled: false
# P4DE profiles (A100 80GB)
p4de-half-balanced:
- devices: [0, 1, 2, 3]
mig-enabled: true
mig-devices:
"1g.10gb": 2
"2g.20gb": 1
"3g.40gb": 1
- devices: [4, 5, 6, 7]
mig-enabled: false
devicePlugin:
enabled: true
config:
name: ""
create: false
default: ""
toolkit:
enabled: true
nfd:
enabled: true
gfd:
enabled: true
dcgmExporter:
enabled: true
serviceMonitor:
enabled: true
interval: 15s
honorLabels: false
additionalLabels:
release: kube-prometheus-stack
nodeStatusExporter:
enabled: false
operator:
defaultRuntime: containerd
runtimeClass: nvidia
resources:
limits:
cpu: 500m
memory: 350Mi
requests:
cpu: 200m
memory: 100Mi
daemonsets:
tolerations:
- key: "nvidia.com/gpu"
operator: "Exists"
effect: "NoSchedule"
nodeSelector:
accelerator: nvidia
priorityClassName: system-node-critical
```
1. Instal GPU Operator menggunakan `gpu-operator-values.yaml` file:
```
helm install gpu-operator nvidia/gpu-operator \
--namespace gpu-operator \
--create-namespace \
--version v25.3.1 \
--values gpu-operator-values.yaml
```
Bagan Helm ini menyebarkan komponen berikut dan beberapa profil MIG:
+ Plugin Perangkat (penjadwalan sumber daya GPU)
+ Eksportir DCGM (metrik dan pemantauan GPU)
+ Penemuan Fitur Node (NFD - pelabelan perangkat keras)
+ Penemuan Fitur GPU (GFD - pelabelan khusus GPU)
+ Manajer MIG (Partisi GPU multi-instance)
+ Toolkit Kontainer (runtime kontainer GPU)
+ Operator Controller (manajemen siklus hidup)
1. Verifikasi Pod penerapan:
```
kubectl get pods -n gpu-operator
```
Berikut ini adalah output contoh:
```
NAME READY STATUS RESTARTS AGE
gpu-feature-discovery-27rdq 1/1 Running 0 3h31m
gpu-operator-555774698d-48brn 1/1 Running 0 4h8m
nvidia-container-toolkit-daemonset-sxmh9 1/1 Running 1 (3h32m ago) 4h1m
nvidia-cuda-validator-qb77g 0/1 Completed 0 3h31m
nvidia-dcgm-exporter-cvzd7 1/1 Running 0 3h31m
nvidia-device-plugin-daemonset-5ljm5 1/1 Running 0 3h31m
nvidia-gpu-operator-node-feature-discovery-gc-67f66fc557-q5wkt 1/1 Running 0 4h8m
nvidia-gpu-operator-node-feature-discovery-master-5d8ffddcsl6s6 1/1 Running 0 4h8m
nvidia-gpu-operator-node-feature-discovery-worker-6t4w7 1/1 Running 1 (3h32m ago) 4h1m
nvidia-gpu-operator-node-feature-discovery-worker-9w7g8 1/1 Running 0 4h8m
nvidia-gpu-operator-node-feature-discovery-worker-k5fgs 1/1 Running 0 4h8m
nvidia-mig-manager-zvf54 1/1 Running 1 (3h32m ago) 3h35m
```
1. Buat klaster Amazon EKS dengan grup node terkelola P4DE untuk menguji contoh MIG:
```
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: dra-eks-cluster
region: us-east-1
version: '1.33'
managedNodeGroups:
# P4DE MIG Node Group with Capacity Block Reservation
- name: p4de-mig-nodes
amiFamily: AmazonLinux2023
instanceType: p4de.24xlarge
# Capacity settings
desiredCapacity: 0
minSize: 0
maxSize: 1
# Use specific subnet in us-east-1b for capacity reservation
subnets:
- us-east-1b
# AL2023 NodeConfig for RAID0 local storage only
nodeadmConfig:
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
instance:
localStorage:
strategy: RAID0
# Node labels for MIG configuration
labels:
nvidia.com/gpu.present: "true"
nvidia.com/gpu.product: "A100-SXM4-80GB"
nvidia.com/mig.config: "p4de-half-balanced"
node-type: "p4de"
vpc.amazonaws.com/efa.present: "true"
accelerator: "nvidia"
# Node taints
taints:
- key: nvidia.com/gpu
value: "true"
effect: NoSchedule
# EFA support
efaEnabled: true
# Placement group for high-performance networking
placementGroup:
groupName: p4de-placement-group
strategy: cluster
# Capacity Block Reservation (CBR)
# Ensure CBR ID matches the subnet AZ with the Nodegroup subnet
spot: false
capacityReservation:
capacityReservationTarget:
capacityReservationId: "cr-abcdefghij" # Replace with your capacity reservation ID
```
NVIDIA GPU Operator menggunakan label ditambahkan ke node `nvidia.com/mig.config: "p4de-half-balanced"` dan partisi GPU dengan profil yang diberikan.
1. Login ke `p4de` instance.
1. Jalankan perintah berikut:
```
nvidia-smi -L
```
Anda akan melihat contoh output berikut:
```
[root@ip-100-64-173-145 bin]# nvidia-smi -L
GPU 0: NVIDIA A100-SXM4-80GB (UUID: GPU-ab52e33c-be48-38f2-119e-b62b9935925a)
MIG 3g.40gb Device 0: (UUID: MIG-da972af8-a20a-5f51-849f-bc0439f7970e)
MIG 2g.20gb Device 1: (UUID: MIG-7f9768b7-11a6-5de9-a8aa-e9c424400da4)
MIG 1g.10gb Device 2: (UUID: MIG-498adad6-6cf7-53af-9d1a-10cfd1fa53b2)
MIG 1g.10gb Device 3: (UUID: MIG-3f55ef65-1991-571a-ac50-0dbf50d80c5a)
GPU 1: NVIDIA A100-SXM4-80GB (UUID: GPU-0eabeccc-7498-c282-0ac7-d3c09f6af0c8)
MIG 3g.40gb Device 0: (UUID: MIG-80543849-ea3b-595b-b162-847568fe6e0e)
MIG 2g.20gb Device 1: (UUID: MIG-3af1958f-fac4-59f1-8477-9f8d08c55029)
MIG 1g.10gb Device 2: (UUID: MIG-401088d2-716f-527b-a970-b1fc7a4ac6b2)
MIG 1g.10gb Device 3: (UUID: MIG-8c56c75e-5141-501c-8f43-8cf22f422569)
GPU 2: NVIDIA A100-SXM4-80GB (UUID: GPU-1c7a1289-243f-7872-a35c-1d2d8af22dd0)
MIG 3g.40gb Device 0: (UUID: MIG-e9b44486-09fc-591a-b904-0d378caf2276)
MIG 2g.20gb Device 1: (UUID: MIG-ded93941-9f64-56a3-a9b1-a129c6edf6e4)
MIG 1g.10gb Device 2: (UUID: MIG-6c317d83-a078-5c25-9fa3-c8308b379aa1)
MIG 1g.10gb Device 3: (UUID: MIG-2b070d39-d4e9-5b11-bda6-e903372e3d08)
GPU 3: NVIDIA A100-SXM4-80GB (UUID: GPU-9a6250e2-5c59-10b7-2da8-b61d8a937233)
MIG 3g.40gb Device 0: (UUID: MIG-20e3cd87-7a57-5f1b-82e7-97b14ab1a5aa)
MIG 2g.20gb Device 1: (UUID: MIG-04430354-1575-5b42-95f4-bda6901f1ace)
MIG 1g.10gb Device 2: (UUID: MIG-d62ec8b6-e097-5e99-a60c-abf8eb906f91)
MIG 1g.10gb Device 3: (UUID: MIG-fce20069-2baa-5dd4-988a-cead08348ada)
GPU 4: NVIDIA A100-SXM4-80GB (UUID: GPU-5d09daf0-c2eb-75fd-3919-7ad8fafa5f86)
GPU 5: NVIDIA A100-SXM4-80GB (UUID: GPU-99194e04-ab2a-b519-4793-81cb2e8e9179)
GPU 6: NVIDIA A100-SXM4-80GB (UUID: GPU-c1a1910f-465a-e16f-5af1-c6aafe499cd6)
GPU 7: NVIDIA A100-SXM4-80GB (UUID: GPU-c2cfafbc-fd6e-2679-e955-2a9e09377f78)
```
Operator GPU NVIDIA telah berhasil menerapkan profil `p4de-half-balanced` MIG ke instance P4DE Anda, membuat partisi GPU tingkat perangkat keras seperti yang dikonfigurasi. Begini cara kerja partisi:
Operator GPU menerapkan konfigurasi ini dari profil MIG yang disematkan:
```
p4de-half-balanced:
- devices: [0, 1, 2, 3] # First 4 GPUs: MIG enabled
mig-enabled: true
mig-devices:
"1g.10gb": 2 # 2x small instances (10GB each)
"2g.20gb": 1 # 1x medium instance (20GB)
"3g.40gb": 1 # 1x large instance (40GB)
- devices: [4, 5, 6, 7] # Last 4 GPUs: Full GPUs
mig-enabled: false
```
Dari `nvidia-smi -L` output Anda, inilah yang dibuat oleh Operator GPU:
+ MiG-enabled GPUs (0-3): perangkat keras dipartisi
+ GPU 0: NVIDIA A100- -80GB SXM4
+ MIG 3g.40gb Perangkat 0 - Beban kerja besar (memori 40GB, 42) SMs
+ MIG 2g.20gb Perangkat 1 - Beban kerja sedang (memori 20GB, 28) SMs
+ MIG 1g.10gb Perangkat 2 - Beban kerja kecil (memori 10GB, 14) SMs
+ MIG 1g.10gb Perangkat 3 - Beban kerja kecil (memori 10GB, 14) SMs
+ GPU 1: NVIDIA A100- -80GB SXM4
+ MIG 3g.40gb Perangkat 0 - Tata letak partisi identik
+ Perangkat MIG 2g.20gb 1
+ Perangkat MIG 1g.10gb 2
+ Perangkat MIG 1g.10gb 3
+ GPU 2 dan GPU 3 — Pola yang sama dengan GPU 0 dan GPU 1
+ Penuh GPUs (4-7): Tidak ada partisi MIG
+ GPU 4: NVIDIA A100- SXM4 -80GB - GPU 80GB Penuh
+ GPU 5: NVIDIA A100- SXM4 -80GB - GPU 80GB Penuh
+ GPU 6: NVIDIA A100- SXM4 -80GB - GPU 80GB Penuh
+ GPU 7: NVIDIA A100- SXM4 -80GB - GPU 80GB Penuh
Setelah Operator GPU NVIDIA membuat partisi MIG, Driver NVIDIA DRA secara otomatis mendeteksi instans terisolasi perangkat keras ini dan membuatnya tersedia untuk alokasi sumber daya dinamis di Kubernetes. Driver DRA menemukan setiap instance MIG dengan profil spesifiknya (1g.10gb, 2g.20gb, 3g.40gb) dan mengeksposnya sebagai sumber daya yang dapat dijadwalkan melalui kelas perangkat. `mig.nvidia.com`
Driver DRA terus memantau topologi MIG dan memelihara inventaris instance yang tersedia di semua. GPUs Ketika Pod meminta profil MIG tertentu melalui a`ResourceClaimTemplate`, driver DRA secara cerdas memilih instance MIG yang sesuai dari GPU yang tersedia, memungkinkan multi-tenancy tingkat perangkat keras yang sebenarnya. Alokasi dinamis ini memungkinkan beberapa beban kerja yang terisolasi berjalan secara bersamaan pada GPU fisik yang sama sambil mempertahankan batasan sumber daya yang ketat dan jaminan kinerja.
##### Langkah 2: Uji alokasi sumber daya MIG
Sekarang mari kita jalankan beberapa contoh untuk menunjukkan bagaimana DRA secara dinamis mengalokasikan instance MIG ke beban kerja yang berbeda. Terapkan `resourceclaimtemplates` dan uji pod untuk melihat bagaimana driver DRA menempatkan beban kerja di seluruh partisi MIG yang tersedia, memungkinkan beberapa kontainer untuk berbagi sumber daya GPU dengan isolasi tingkat perangkat keras.
1. Buat `mig-claim-template.yaml` untuk memuat MIG`resourceclaimtemplates`:
```
apiVersion: v1
kind: Namespace
metadata:
name: mig-gpu
---
# Template for 3g.40gb MIG instance (Large training)
apiVersion: resource.k8s.io/v1beta1
kind: ResourceClaimTemplate
metadata:
name: mig-large-template
namespace: mig-gpu
spec:
spec:
devices:
requests:
- name: mig-large
deviceClassName: mig.nvidia.com
selectors:
- cel:
expression: |
device.attributes['gpu.nvidia.com'].profile == '3g.40gb'
---
# Template for 2g.20gb MIG instance (Medium training)
apiVersion: resource.k8s.io/v1beta1
kind: ResourceClaimTemplate
metadata:
name: mig-medium-template
namespace: mig-gpu
spec:
spec:
devices:
requests:
- name: mig-medium
deviceClassName: mig.nvidia.com
selectors:
- cel:
expression: |
device.attributes['gpu.nvidia.com'].profile == '2g.20gb'
---
# Template for 1g.10gb MIG instance (Small inference)
apiVersion: resource.k8s.io/v1beta1
kind: ResourceClaimTemplate
metadata:
name: mig-small-template
namespace: mig-gpu
spec:
spec:
devices:
requests:
- name: mig-small
deviceClassName: mig.nvidia.com
selectors:
- cel:
expression: |
device.attributes['gpu.nvidia.com'].profile == '1g.10gb'
```
1. Terapkan tiga templat:
```
kubectl apply -f mig-claim-template.yaml
```
1. Jalankan perintah berikut:
```
kubectl get resourceclaimtemplates -n mig-gpu
```
Berikut ini adalah output contoh:
```
NAME AGE
mig-large-template 71m
mig-medium-template 71m
mig-small-template 71m
```
1. Buat `mig-pod.yaml` untuk menjadwalkan beberapa pekerjaan untuk memanfaatkan ini`resourceclaimtemplates`:
```
---
# ConfigMap containing Python scripts for MIG pods
apiVersion: v1
kind: ConfigMap
metadata:
name: mig-scripts-configmap
namespace: mig-gpu
data:
large-training-script.py: |
import torch
import torch.nn as nn
import torch.optim as optim
import time
import os
print(f"=== LARGE TRAINING POD (3g.40gb) ===")
print(f"Process ID: {os.getpid()}")
print(f"GPU available: {torch.cuda.is_available()}")
print(f"GPU count: {torch.cuda.device_count()}")
if torch.cuda.is_available():
device = torch.cuda.current_device()
print(f"Using GPU: {torch.cuda.get_device_name(device)}")
print(f"GPU Memory: {torch.cuda.get_device_properties(device).total_memory / 1e9:.1f} GB")
# Large model for 3g.40gb instance
model = nn.Sequential(
nn.Linear(2048, 1024),
nn.ReLU(),
nn.Linear(1024, 512),
nn.ReLU(),
nn.Linear(512, 256),
nn.ReLU(),
nn.Linear(256, 10)
).cuda()
optimizer = optim.Adam(model.parameters())
criterion = nn.CrossEntropyLoss()
print(f"Model parameters: {sum(p.numel() for p in model.parameters())}")
# Training loop
for epoch in range(100):
# Large batch for 3g.40gb
x = torch.randn(256, 2048).cuda()
y = torch.randint(0, 10, (256,)).cuda()
optimizer.zero_grad()
output = model(x)
loss = criterion(output, y)
loss.backward()
optimizer.step()
if epoch % 10 == 0:
print(f"Large Training - Epoch {epoch}, Loss: {loss.item():.4f}, GPU Memory: {torch.cuda.memory_allocated()/1e9:.2f}GB")
time.sleep(3)
print("Large training completed on 3g.40gb MIG instance")
medium-training-script.py: |
import torch
import torch.nn as nn
import torch.optim as optim
import time
import os
print(f"=== MEDIUM TRAINING POD (2g.20gb) ===")
print(f"Process ID: {os.getpid()}")
print(f"GPU available: {torch.cuda.is_available()}")
print(f"GPU count: {torch.cuda.device_count()}")
if torch.cuda.is_available():
device = torch.cuda.current_device()
print(f"Using GPU: {torch.cuda.get_device_name(device)}")
print(f"GPU Memory: {torch.cuda.get_device_properties(device).total_memory / 1e9:.1f} GB")
# Medium model for 2g.20gb instance
model = nn.Sequential(
nn.Linear(1024, 512),
nn.ReLU(),
nn.Linear(512, 256),
nn.ReLU(),
nn.Linear(256, 10)
).cuda()
optimizer = optim.Adam(model.parameters())
criterion = nn.CrossEntropyLoss()
print(f"Model parameters: {sum(p.numel() for p in model.parameters())}")
# Training loop
for epoch in range(100):
# Medium batch for 2g.20gb
x = torch.randn(128, 1024).cuda()
y = torch.randint(0, 10, (128,)).cuda()
optimizer.zero_grad()
output = model(x)
loss = criterion(output, y)
loss.backward()
optimizer.step()
if epoch % 10 == 0:
print(f"Medium Training - Epoch {epoch}, Loss: {loss.item():.4f}, GPU Memory: {torch.cuda.memory_allocated()/1e9:.2f}GB")
time.sleep(4)
print("Medium training completed on 2g.20gb MIG instance")
small-inference-script.py: |
import torch
import torch.nn as nn
import time
import os
print(f"=== SMALL INFERENCE POD (1g.10gb) ===")
print(f"Process ID: {os.getpid()}")
print(f"GPU available: {torch.cuda.is_available()}")
print(f"GPU count: {torch.cuda.device_count()}")
if torch.cuda.is_available():
device = torch.cuda.current_device()
print(f"Using GPU: {torch.cuda.get_device_name(device)}")
print(f"GPU Memory: {torch.cuda.get_device_properties(device).total_memory / 1e9:.1f} GB")
# Small model for 1g.10gb instance
model = nn.Sequential(
nn.Linear(512, 256),
nn.ReLU(),
nn.Linear(256, 10)
).cuda()
print(f"Model parameters: {sum(p.numel() for p in model.parameters())}")
# Inference loop
for i in range(200):
with torch.no_grad():
# Small batch for 1g.10gb
x = torch.randn(32, 512).cuda()
output = model(x)
prediction = torch.argmax(output, dim=1)
if i % 20 == 0:
print(f"Small Inference - Batch {i}, Predictions: {prediction[:5].tolist()}, GPU Memory: {torch.cuda.memory_allocated()/1e9:.2f}GB")
time.sleep(2)
print("Small inference completed on 1g.10gb MIG instance")
---
# Pod 1: Large training workload (3g.40gb)
apiVersion: v1
kind: Pod
metadata:
name: mig-large-training-pod
namespace: mig-gpu
labels:
app: mig-large-training
workload-type: training
spec:
restartPolicy: Never
containers:
- name: large-training-container
image: nvcr.io/nvidia/pytorch:25.04-py3
command: ["python", "/scripts/large-training-script.py"]
volumeMounts:
- name: script-volume
mountPath: /scripts
readOnly: true
resources:
claims:
- name: mig-large-claim
resourceClaims:
- name: mig-large-claim
resourceClaimTemplateName: mig-large-template
nodeSelector:
node.kubernetes.io/instance-type: p4de.24xlarge
nvidia.com/gpu.present: "true"
tolerations:
- key: nvidia.com/gpu
operator: Exists
effect: NoSchedule
volumes:
- name: script-volume
configMap:
name: mig-scripts-configmap
defaultMode: 0755
---
# Pod 2: Medium training workload (2g.20gb) - can run on SAME GPU as Pod 1
apiVersion: v1
kind: Pod
metadata:
name: mig-medium-training-pod
namespace: mig-gpu
labels:
app: mig-medium-training
workload-type: training
spec:
restartPolicy: Never
containers:
- name: medium-training-container
image: nvcr.io/nvidia/pytorch:25.04-py3
command: ["python", "/scripts/medium-training-script.py"]
volumeMounts:
- name: script-volume
mountPath: /scripts
readOnly: true
resources:
claims:
- name: mig-medium-claim
resourceClaims:
- name: mig-medium-claim
resourceClaimTemplateName: mig-medium-template
nodeSelector:
node.kubernetes.io/instance-type: p4de.24xlarge
nvidia.com/gpu.present: "true"
tolerations:
- key: nvidia.com/gpu
operator: Exists
effect: NoSchedule
volumes:
- name: script-volume
configMap:
name: mig-scripts-configmap
defaultMode: 0755
---
# Pod 3: Small inference workload (1g.10gb) - can run on SAME GPU as Pod 1 & 2
apiVersion: v1
kind: Pod
metadata:
name: mig-small-inference-pod
namespace: mig-gpu
labels:
app: mig-small-inference
workload-type: inference
spec:
restartPolicy: Never
containers:
- name: small-inference-container
image: nvcr.io/nvidia/pytorch:25.04-py3
command: ["python", "/scripts/small-inference-script.py"]
volumeMounts:
- name: script-volume
mountPath: /scripts
readOnly: true
resources:
claims:
- name: mig-small-claim
resourceClaims:
- name: mig-small-claim
resourceClaimTemplateName: mig-small-template
nodeSelector:
node.kubernetes.io/instance-type: p4de.24xlarge
nvidia.com/gpu.present: "true"
tolerations:
- key: nvidia.com/gpu
operator: Exists
effect: NoSchedule
volumes:
- name: script-volume
configMap:
name: mig-scripts-configmap
defaultMode: 0755
```
1. Terapkan spesifikasi ini, yang seharusnya menyebarkan tiga Pod:
```
kubctl apply -f mig-pod.yaml
```
Pod ini harus dijadwalkan oleh driver DRA.
1. Periksa log DRA driver Pod dan Anda akan melihat output yang mirip dengan ini:
```
I0717 21:50:22.925811 1 driver.go:87] NodePrepareResource is called: number of claims: 1
I0717 21:50:22.932499 1 driver.go:129] Returning newly prepared devices for claim '933e9c72-6fd6-49c5-933c-a896407dc6d1': [&Device{RequestNames:[mig-large],PoolName:ip-100-64-173-145.ec2.internal,DeviceName:gpu-0-mig-9-4-4,CDIDeviceIDs:[k8s.gpu.nvidia.com/device=**gpu-0-mig-9-4-4**],}]
I0717 21:50:23.186472 1 driver.go:87] NodePrepareResource is called: number of claims: 1
I0717 21:50:23.191226 1 driver.go:129] Returning newly prepared devices for claim '61e5ddd2-8c2e-4c19-93ae-d317fecb44a4': [&Device{RequestNames:[mig-medium],PoolName:ip-100-64-173-145.ec2.internal,DeviceName:gpu-2-mig-14-0-2,CDIDeviceIDs:[k8s.gpu.nvidia.com/device=**gpu-2-mig-14-0-2**],}]
I0717 21:50:23.450024 1 driver.go:87] NodePrepareResource is called: number of claims: 1
I0717 21:50:23.455991 1 driver.go:129] Returning newly prepared devices for claim '1eda9b2c-2ea6-401e-96d0-90e9b3c111b5': [&Device{RequestNames:[mig-small],PoolName:ip-100-64-173-145.ec2.internal,DeviceName:gpu-1-mig-19-2-1,CDIDeviceIDs:[k8s.gpu.nvidia.com/device=**gpu-1-mig-19-2-1**],}]
```
1. Verifikasi `resourceclaims` untuk melihat status Pod:
```
kubectl get resourceclaims -n mig-gpu -w
```
Berikut ini adalah output contoh:
```
NAME STATE AGE
mig-large-training-pod-mig-large-claim-6dpn8 pending 0s
mig-large-training-pod-mig-large-claim-6dpn8 pending 0s
mig-large-training-pod-mig-large-claim-6dpn8 allocated,reserved 0s
mig-medium-training-pod-mig-medium-claim-bk596 pending 0s
mig-medium-training-pod-mig-medium-claim-bk596 pending 0s
mig-medium-training-pod-mig-medium-claim-bk596 allocated,reserved 0s
mig-small-inference-pod-mig-small-claim-d2t58 pending 0s
mig-small-inference-pod-mig-small-claim-d2t58 pending 0s
mig-small-inference-pod-mig-small-claim-d2t58 allocated,reserved 0s
```
Seperti yang Anda lihat, semua Pod dipindahkan dari pending ke `allocated,reserved` driver DRA.
1. Jalankan `nvidia-smi` dari node. Anda akan melihat tiga prosesor Python sedang berjalan:
```
root@ip-100-64-173-145 bin]# nvidia-smi
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 570.158.01 Driver Version: 570.158.01 CUDA Version: 12.8 |
|-----------------------------------------+------------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+========================+======================|
| 0 NVIDIA A100-SXM4-80GB On | 00000000:10:1C.0 Off | On |
| N/A 63C P0 127W / 400W | 569MiB / 81920MiB | N/A Default |
| | | Enabled |
+-----------------------------------------+------------------------+----------------------+
| 1 NVIDIA A100-SXM4-80GB On | 00000000:10:1D.0 Off | On |
| N/A 56C P0 121W / 400W | 374MiB / 81920MiB | N/A Default |
| | | Enabled |
+-----------------------------------------+------------------------+----------------------+
| 2 NVIDIA A100-SXM4-80GB On | 00000000:20:1C.0 Off | On |
| N/A 63C P0 128W / 400W | 467MiB / 81920MiB | N/A Default |
| | | Enabled |
+-----------------------------------------+------------------------+----------------------+
| 3 NVIDIA A100-SXM4-80GB On | 00000000:20:1D.0 Off | On |
| N/A 57C P0 118W / 400W | 249MiB / 81920MiB | N/A Default |
| | | Enabled |
+-----------------------------------------+------------------------+----------------------+
| 4 NVIDIA A100-SXM4-80GB On | 00000000:90:1C.0 Off | 0 |
| N/A 51C P0 77W / 400W | 0MiB / 81920MiB | 0% Default |
| | | Disabled |
+-----------------------------------------+------------------------+----------------------+
| 5 NVIDIA A100-SXM4-80GB On | 00000000:90:1D.0 Off | 0 |
| N/A 46C P0 69W / 400W | 0MiB / 81920MiB | 0% Default |
| | | Disabled |
+-----------------------------------------+------------------------+----------------------+
| 6 NVIDIA A100-SXM4-80GB On | 00000000:A0:1C.0 Off | 0 |
| N/A 52C P0 74W / 400W | 0MiB / 81920MiB | 0% Default |
| | | Disabled |
+-----------------------------------------+------------------------+----------------------+
| 7 NVIDIA A100-SXM4-80GB On | 00000000:A0:1D.0 Off | 0 |
| N/A 47C P0 72W / 400W | 0MiB / 81920MiB | 0% Default |
| | | Disabled |
+-----------------------------------------+------------------------+----------------------+
+-----------------------------------------------------------------------------------------+
| MIG devices: |
+------------------+----------------------------------+-----------+-----------------------+
| GPU GI CI MIG | Memory-Usage | Vol| Shared |
| ID ID Dev | BAR1-Usage | SM Unc| CE ENC DEC OFA JPG |
| | | ECC| |
|==================+==================================+===========+=======================|
| 0 2 0 0 | 428MiB / 40192MiB | 42 0 | 3 0 2 0 0 |
| | 2MiB / 32767MiB | | |
+------------------+----------------------------------+-----------+-----------------------+
| 0 3 0 1 | 71MiB / 19968MiB | 28 0 | 2 0 1 0 0 |
| | 0MiB / 16383MiB | | |
+------------------+----------------------------------+-----------+-----------------------+
| 0 9 0 2 | 36MiB / 9728MiB | 14 0 | 1 0 0 0 0 |
| | 0MiB / 8191MiB | | |
+------------------+----------------------------------+-----------+-----------------------+
| 0 10 0 3 | 36MiB / 9728MiB | 14 0 | 1 0 0 0 0 |
| | 0MiB / 8191MiB | | |
+------------------+----------------------------------+-----------+-----------------------+
| 1 1 0 0 | 107MiB / 40192MiB | 42 0 | 3 0 2 0 0 |
| | 0MiB / 32767MiB | | |
+------------------+----------------------------------+-----------+-----------------------+
| 1 5 0 1 | 71MiB / 19968MiB | 28 0 | 2 0 1 0 0 |
| | 0MiB / 16383MiB | | |
+------------------+----------------------------------+-----------+-----------------------+
| 1 13 0 2 | 161MiB / 9728MiB | 14 0 | 1 0 0 0 0 |
| | 2MiB / 8191MiB | | |
+------------------+----------------------------------+-----------+-----------------------+
| 1 14 0 3 | 36MiB / 9728MiB | 14 0 | 1 0 0 0 0 |
| | 0MiB / 8191MiB | | |
+------------------+----------------------------------+-----------+-----------------------+
| 2 1 0 0 | 107MiB / 40192MiB | 42 0 | 3 0 2 0 0 |
| | 0MiB / 32767MiB | | |
+------------------+----------------------------------+-----------+-----------------------+
| 2 5 0 1 | 289MiB / 19968MiB | 28 0 | 2 0 1 0 0 |
| | 2MiB / 16383MiB | | |
+------------------+----------------------------------+-----------+-----------------------+
| 2 13 0 2 | 36MiB / 9728MiB | 14 0 | 1 0 0 0 0 |
| | 0MiB / 8191MiB | | |
+------------------+----------------------------------+-----------+-----------------------+
| 2 14 0 3 | 36MiB / 9728MiB | 14 0 | 1 0 0 0 0 |
| | 0MiB / 8191MiB | | |
+------------------+----------------------------------+-----------+-----------------------+
| 3 1 0 0 | 107MiB / 40192MiB | 42 0 | 3 0 2 0 0 |
| | 0MiB / 32767MiB | | |
+------------------+----------------------------------+-----------+-----------------------+
| 3 5 0 1 | 71MiB / 19968MiB | 28 0 | 2 0 1 0 0 |
| | 0MiB / 16383MiB | | |
+------------------+----------------------------------+-----------+-----------------------+
| 3 13 0 2 | 36MiB / 9728MiB | 14 0 | 1 0 0 0 0 |
| | 0MiB / 8191MiB | | |
+------------------+----------------------------------+-----------+-----------------------+
| 3 14 0 3 | 36MiB / 9728MiB | 14 0 | 1 0 0 0 0 |
| | 0MiB / 8191MiB | | |
+------------------+----------------------------------+-----------+-----------------------+
+-----------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=========================================================================================|
**| 0 2 0 64080 C python 312MiB |
| 1 13 0 64085 C python 118MiB |
| 2 5 0 64073 C python 210MiB |**
+-----------------------------------------------------------------------------------------+
```
#### Optimalkan beban kerja GPU dengan IMEX menggunakan instans P6e GB200
IMEX (Internode Memory Exchange) memungkinkan komunikasi yang koheren memori di seluruh node untuk pelatihan terdistribusi di NVIDIA. GB200 UltraServers
Lakukan langkah-langkah berikut.
1. Tentukan pelatihan `ComputeDomain` untuk multi-node dengan file bernama`imex-compute-domain.yaml`:
```
apiVersion: resource.nvidia.com/v1beta1
kind: ComputeDomain
metadata:
name: distributed-training-domain
namespace: default
spec:
numNodes: 2
channel:
resourceClaimTemplate:
name: imex-channel-template
```
1. Mendefinisikan Pod menggunakan saluran IMEX dengan file bernama`imex-pod.yaml`:
```
apiVersion: v1
kind: Pod
metadata:
name: imex-distributed-training
namespace: default
labels:
app: imex-training
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: nvidia.com/gpu.clique
operator: Exists
containers:
- name: distributed-training
image: nvcr.io/nvidia/pytorch:25.04-py3
command: ["bash", "-c"]
args:
- |
echo "=== IMEX Channel Verification ==="
ls -la /dev/nvidia-caps-imex-channels/
echo ""
echo "=== GPU Information ==="
nvidia-smi
echo ""
echo "=== NCCL Test (if available) ==="
python -c "
import torch
import torch.distributed as dist
import os
print(f'CUDA available: {torch.cuda.is_available()}')
print(f'CUDA device count: {torch.cuda.device_count()}')
if torch.cuda.is_available():
for i in range(torch.cuda.device_count()):
print(f'GPU {i}: {torch.cuda.get_device_name(i)}')
# Check for IMEX environment variables
imex_vars = [k for k in os.environ.keys() if 'IMEX' in k or 'NVLINK' in k]
if imex_vars:
print('IMEX Environment Variables:')
for var in imex_vars:
print(f' {var}={os.environ[var]}')
print('IMEX channel verification completed')
"
# Keep container running for inspection
sleep 3600
resources:
claims:
- name: imex-channel-0
- name: imex-channel-1
resourceClaims:
- name: imex-channel-0
resourceClaimTemplateName: imex-channel-template
- name: imex-channel-1
resourceClaimTemplateName: imex-channel-template
tolerations:
- key: nvidia.com/gpu
operator: Exists
effect: NoSchedule
```
**catatan**
Ini membutuhkan instance P6e GB200 .
1. Menyebarkan IMEX dengan menerapkan `ComputeDomain` dan template:
```
kubectl apply -f imex-claim-template.yaml
kubectl apply -f imex-compute-domain.yaml
kubectl apply -f imex-pod.yaml
```
1. Periksa `ComputeDomain` statusnya.
```
kubectl get computedomain distributed-training-domain
```
1. Pantau penyebaran daemon IMEX.
```
kubectl get pods -n nvidia-dra-driver -l resource.nvidia.com/computeDomain
```
1. Periksa saluran IMEX di Pod:
```
kubectl exec imex-distributed-training -- ls -la /dev/nvidia-caps-imex-channels/
```
1. Lihat log Pod:
```
kubectl logs imex-distributed-training
```
Berikut ini adalah contoh output yang diharapkan:
```
=== IMEX Channel Verification ===
total 0
drwxr-xr-x. 2 root root 80 Jul 8 10:45 .
drwxr-xr-x. 6 root root 380 Jul 8 10:45 ..
crw-rw-rw-. 1 root root 241, 0 Jul 8 10:45 channel0
crw-rw-rw-. 1 root root 241, 1 Jul 8 10:45 channel1
```
Untuk informasi selengkapnya, lihat [contoh NVIDIA](https://github.com/NVIDIA/k8s-dra-driver-gpu/discussions/249) di GitHub.