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
Daftar
Optimalisasi Sumber Daya GPU dan Manajemen Biaya
Jadwalkan beban kerja dengan persyaratan GPU menggunakan label Well-Known
Untuk AI/ML beban kerja yang sensitif terhadap karakteristik GPU yang berbeda (misalnya GPU, memori GPU), sebaiknya tentukan persyaratan GPU menggunakan label penjadwalan yang diketahui
Contoh
Misalnya, menggunakan pemilih simpul nama GPU saat menggunakan Karpenter:
apiVersion: v1 kind: Pod metadata: name: gpu-pod-example spec: containers: - name: ml-workload image: <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 GPU
Untuk mengekspos GPU pada node, driver GPU NVIDIA harus diinstal pada sistem operasi node dan runtime container dikonfigurasi untuk memungkinkan penjadwal Kubernetes menetapkan pod ke node dengan GPU yang tersedia. Proses penyiapan untuk Plugin Perangkat NVIDIA Kubernetes bergantung pada EKS Accelerated AMI yang Anda gunakan:
-
Bottlerocket Acceler ated AMI: AMI ini mencakup driver GPU NVIDIA dan Plugin Perangkat
NVIDIA Kubernetes sudah diinstal sebelumnya dan siap digunakan, memungkinkan dukungan GPU di luar kotak. Tidak diperlukan konfigurasi tambahan untuk mengekspos GPU ke penjadwal Kubernetes. -
AMI yang Dipercepat AL2023
: AMI ini menyertakan driver GPU NVIDIA tetapi Plugin Perangkat NVIDIA Kubernetes tidak diinstal sebelumnya. Anda harus menginstal dan mengkonfigurasi plugin perangkat secara terpisah, biasanya melalui a DaemonSet. Perhatikan bahwa jika Anda menggunakan eksctl untuk membuat cluster Anda dan menentukan jenis instance GPU (misalnya, g5.xlarge) di Anda ClusterConfig,eksctlakan secara otomatis memilih AMI yang sesuai dan menginstal Plugin Perangkat NVIDIA Kubernetes. Untuk mempelajari selengkapnya, lihat dukungan GPUdi dokumentasi eksctl.
Jika Anda memutuskan untuk menggunakan EKS Accelerated AMI dan operator GPU NVIDIA
Untuk memverifikasi bahwa Plugin Perangkat NVIDIA aktif dan GPU terekspos 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 ditampilkannvidia.com/gpu: 1. Lihat Panduan Penjadwalan GPU Kubernetes
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 Pesawat Data Kubernetes ini. Rekomendasi ini juga berlaku untuk instance dengan perangkat keras yang dipercepat (misalnya, GPU). Jika Anda membuat cluster yang hanya menggunakan satu jenis instans dan mencoba menskalakan jumlah node di luar kapasitas wilayah, Anda mungkin menerima kesalahan kapasitas tidak memadai (ICE), yang menunjukkan bahwa tidak ada instans 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
Instans komputasi yang dipercepat ditawarkan dalam model pembelian yang berbeda agar sesuai dengan beban kerja jangka pendek, jangka menengah, dan kondisi mapan. Untuk beban kerja jangka pendek, fleksibel, dan toleran kesalahan, di mana Anda ingin menghindari membuat reservasi, lihat instans Spot. Blok Kapasitas, On-Demand instans, dan Paket Penyimpanan 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 ICE untuk 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 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 untuk GPU dengan Karpenter” di bawah ini.
Pertimbangkan untuk menggunakan Instans Spot Amazon EC2 untuk GPU dengan Karpenter
Instans Spot Amazon EC2 memungkinkan Anda memanfaatkan kapasitas EC2 yang tidak terpakai di cloud AWS dan tersedia dengan diskon hingga 90% dibandingkan dengan harga. On-Demand Instans Spot Amazon EC2 dapat terganggu dengan pemberitahuan dua menit ketika EC2 membutuhkan kapasitas kembali. Untuk informasi selengkapnya, lihat Instans Spot di Panduan Pengguna Amazon EC2. Amazon EC2 Spot dapat menjadi pilihan tepat untuk beban kerja yang toleran terhadap kesalahan, tanpa status, dan fleksibel (tipe waktu dan instans). Untuk mempelajari lebih lanjut tentang kapan menggunakan instans Spot, lihat Praktik Terbaik Instans Spot EC2. Anda juga dapat menggunakan Instans Spot untuk AI/ML beban kerja jika ada. Spot-friendly
Kasus penggunaan
Spot-friendly beban kerja dapat berupa data besar, beban kerja kontainer, server web tanpa status CI/CD, komputasi kinerja tinggi (HPC), dan beban kerja rendering. Instans Spot tidak cocok untuk beban kerja yang tidak fleksibel, stateful, tidak toleran terhadap kesalahan, atau digabungkan erat antar node instans (misalnya, beban kerja dengan proses paralel yang sangat bergantung satu sama lain untuk komputasi, membutuhkan komunikasi antar-node yang konstan, seperti aplikasi komputasi MPI-based kinerja tinggi seperti dinamika fluida komputasi atau database terdistribusi dengan saling ketergantungan yang kompleks). Berikut adalah kasus penggunaan khusus yang kami rekomendasikan (tanpa urutan tertentu):
-
Real-time inferensi online: Gunakan instans Spot untuk penskalaan yang dioptimalkan biaya untuk beban kerja inferensi real-time Anda, asalkan beban kerja Anda ramah lokasi. Dengan kata lain, waktu inferensi kurang dari dua menit, aplikasi ini toleran terhadap kesalahan terhadap gangguan, dan dapat berjalan pada jenis instance yang berbeda. Pastikan ketersediaan tinggi melalui keragaman instans (misalnya, di beberapa jenis instans dan Zona Ketersediaan) atau reservasi, sambil menerapkan toleransi kesalahan tingkat aplikasi untuk menangani potensi gangguan Spot.
-
Hyper-parameter penyetelan: Gunakan instance Spot untuk menjalankan pekerjaan penyetelan eksplorasi secara oportunistik, karena interupsi dapat ditoleransi tanpa kerugian yang signifikan, terutama untuk eksperimen durasi pendek.
-
Augmentasi data: Gunakan instance Spot untuk melakukan tugas prapemrosesan dan augmentasi data yang dapat memulai ulang dari pos pemeriksaan jika terganggu, menjadikannya ideal untuk ketersediaan variabel Spot.
-
Fine-tuning model: Gunakan instance Spot untuk menyempurnakan dengan mekanisme checkpointing yang kuat untuk melanjutkan dari status tersimpan terakhir, meminimalkan dampak interupsi instance.
-
Inferensi batch: Gunakan instans Spot untuk memproses sejumlah besar permintaan inferensi offline dengan cara non-real-time, di mana pekerjaan dapat dijeda dan dilanjutkan, menawarkan keselarasan 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 lintas 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-ketik sebagai “spot” di Karpenter Anda NodePool, Karpenter 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
dengan menyetel --feature-gates SpotToSpotConsolidation =true dalam argumen pengontrol Karpenter atau melalui variabel lingkungan FEATURE_GATES. Karpenter menggunakan strategi alokasi kapasitas harga yang dioptimalkan untuk menyediakan instans EC2. Berdasarkan NodePool persyaratan dan batasan pod, Karpenter mengemas pod yang tidak dapat dijadwalkan dan mengirimkan beragam jenis instans 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 untuk menghasilkan daftar jenis instans yang sesuai dengan persyaratan komputasi spesifik Anda. -
Pastikan beban kerja bersifat stateless, toleransi kesalahan, dan fleksibel. Beban kerja harus stateless, toleran terhadap kesalahan, dan fleksibel dalam hal ukuran. instance/GPU Hal ini memungkinkan dimulainya kembali dengan mulus setelah interupsi Spot, dan fleksibilitas instans memungkinkan Anda untuk berpotensi tetap berada di Spot lebih lama. Aktif kan penanganan gangguan Spot
di Karpenter dengan mengonfigurasi nilai Settings.InterruptionQueue Helm dengan nama antrian AWS SQS untuk menangkap peristiwa gangguan Spot. Misalnya, saat menginstal melalui Helm, gunakan --set “settings.interruptionQueue=$ {CLUSTER_NAME}”. Untuk melihat contoh, lihat panduan Mem ulai dengan Karpenter . Ketika Karpenter melihat peristiwa interupsi Spot, Karpenter secara otomatis menutup, menodai, menguras, dan mengakhiri node sebelum peristiwa interupsi untuk memaksimalkan masa tenggang penghentian 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 peluang lebih tinggi untuk memperoleh kapasitas Spot pada skala besar dengan frekuensi interupsi Instans Spot yang lebih rendah dengan biaya lebih rendah. Misalnya, hindari membatasi pada tipe tertentu (misalnya, g5.xlarge). Pertimbangkan untuk menentukan beragam kategori dan generasi instance menggunakan kunci seperti karpenter.k8s. aws/instance-kategori dan karpenter.k8s. aws/instance-generasi. Karpenter memungkinkan diversifikasi kapasitas instance on-demand dan Spot yang lebih mudah di beberapa jenis instans dan Availability Zone (AZ). Selain itu, jika AI/ML beban kerja Anda memerlukan akselerator dalam jumlah 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 peluncuran.
-
Perluas NodePool persyaratan untuk menyertakan lebih banyak 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 menyediakan node baru, ia memilih jenis instance yang sesuai 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 instans seri g yang lebih luas (generasi 4 atau lebih tinggi) dari NVIDIA di seluruh ukuran dan Zona Ketersediaan (AZ), sambil mempertimbangkan kebutuhan perangkat keras seperti memori GPU atau Ray Tracing. Karena instance dapat terdiri dari jenis yang berbeda, 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 lain. Setiap kombinasi unik dari jenis instans dan Availability Zone merupakan kumpulan kapasitas Spot yang terpisah. Dengan meminta kapasitas di semua AZ di wilayah 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 topology.kubernetes. io/zone kunci sepenuhnya untuk memungkinkan Karpenter memilih dari semua AZ yang tersedia di wilayah tersebut, atau secara eksplisit mencantumkan AZ menggunakan operator: Masuk dan memberikan nilainya (misalnya, us-west-2a).
-
Pertimbangkan untuk menggunakan Spot Placement Score (SPS) untuk mendapatkan visibilitas tentang kemungkinan berhasil mengakses kapasitas yang diperlukan menggunakan inst ans Spot. Spot Placement Score (SPS) 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, dan kemudian Amazon EC2 mengembalikan 10 Wilayah atau Zona Ketersediaan (AZ) teratas di mana permintaan Spot Anda kemungkinan akan 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. Karena kapasitas Spot berfluktuasi sepanjang waktu, SPS akan membantu Anda mengidentifikasi kombinasi jenis instans, AZ, dan wilayah mana yang paling sesuai dengan batasan beban kerja Anda (yaitu fleksibilitas, kinerja, ukuran, dll.). Jika AI/ML beban kerja Anda memerlukan 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 peluncuran. 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 YAML untuk pengaturan yang beragam (misalnya, persyaratan instans termasuk GPU), menyimpan metrik di CloudWatch, dan menyediakan dasbor untuk membandingkan konfigurasi. Tentukan dasbor per beban kerja untuk mengevaluasi kebutuhan vCPU, memori, dan GPU, memastikan pengaturan optimal untuk cluster EKS termasuk pertimbangan menggunakan Wilayah AWS lainnya. Untuk mempelajari selengkapnya, lihat Cara kerja skor penempatan Spot.
-
Tangani interupsi dan tes Spot dengan anggun. Untuk pod dengan periode penghentian lebih dari dua menit, node lama akan terganggu sebelum pod tersebut dijadwalkan ulang, yang dapat memengaruhi ketersediaan beban kerja. Pertimbangkan pemberitahuan interupsi Spot selama dua menit saat merancang aplikasi Anda, terapkan checkpoint dalam aplikasi yang berjalan lama (misalnya, menyimpan kemajuan ke penyimpanan persisten seperti Amazon S3) untuk melanjutkan setelah interupsi, perpanjang penghentian GracePeriodSeconds (default adalah 30 detik) dalam spesifikasi Pod untuk memberikan lebih banyak waktu untuk shutdown yang anggun, dan tangani interupsi menggunakan pengait siklus hidup PreStop sinyal and/or SIGTERM dalam aplikasi Anda untuk aktivitas shutdown yang anggun seperti pembersihan, penghematan status, 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 Penyimpanan dan Penskalaan dan Kinerja Aplikasi praktik terbaik. Untuk menguji node pengganti, gunakan AWS Fault Injection Service
(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 CPU-based beban kerja, 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 CPU. Sebagai langkah pertama, menilai apakah beban kerja Anda fleksibel instans. Jika Anda tidak tahu berapa banyak jenis instans yang dapat digunakan beban kerja Anda, uji secara individual untuk memastikan kompatibilitas dan fungsionalitas. Identifikasi seberapa fleksibel Anda untuk melakukan diversifikasi sebanyak mungkin, sambil mengonfirmasi bahwa diversifikasi membuat beban kerja tetap berfungsi dan memahami dampak kinerja apa pun (misalnya, pada throughput atau waktu penyelesaian). Sebagai bagian dari diversifikasi beban kerja Anda, pertimbangkan hal berikut:
-
Tinjau kompatibilitas CUDA dan 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 FP16/INT8 presisi.
-
Memori GPU. Pastikan untuk mengevaluasi persyaratan memori model Anda dan membuat profil penggunaan memori model Anda selama runtime menggunakan alat seperti Eksportir DCGM
dan mengatur memori GPU minimum yang diperlukan untuk jenis instance di label terkenal seperti karpenter.k8s. aws/instance-memori gpu. 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 kesalahan atau crash memori habis (OOM). Untuk Instans Spot di EKS, ini dapat membatasi diversifikasi. Misalnya, Anda tidak dapat menyertakan jenis VRAM yang lebih rendah jika model Anda tidak sesuai, 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 jenis instance dengan VRAM yang cukup dalam konfigurasi Spot Anda. -
Floating-point presisi dan kinerja. Tidak semua arsitektur GPU Nvidia memiliki presisi float point yang sama (mis., FP16/INT8). Evaluasi kinerja tipe inti (CUDA/Tensor/RT) dan presisi float point yang diperlukan untuk beban kerja Anda. Menjalankan pada GPU dengan harga lebih rendah dan berkinerja lebih rendah tidak berarti 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 pada 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 batasan 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 Checkpoint untuk Pekerjaan Pelatihan Lari Jangka Panjang
Checkpointing adalah teknik toleransi kesalahan yang melibatkan penyimpanan keadaan proses secara berkala, memungkinkannya untuk melanjutkan dari titik terakhir yang disimpan jika terjadi interupsi. Dalam pembelajaran mesin, ini biasanya 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 Instance 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 ML. 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 dalam pelatihan karena gangguan tak terduga pada pekerjaan atau instance pelatihan. Ini memungkinkan Anda untuk melanjutkan pelatihan model di masa depan dari pos pemeriksaan. Selain menerapkan sistem ketahanan node, kami sarankan menerapkan checkpointing untuk mengurangi dampak gangguan, termasuk yang disebabkan oleh kegagalan perangkat keras atau gangguan Instans Spot Amazon EC2.
Tanpa checkpoint, interupsi dapat mengakibatkan waktu komputasi terbuang dan hilangnya kemajuan, yang mahal untuk pekerjaan pelatihan yang berjalan lama. Checkpointing memungkinkan pekerjaan menyimpan statusnya secara berkala (misalnya, bobot model dan status pengoptimal) dan melanjutkan dari pos pemeriksaan terakhir (batch terakhir diproses) setelah interupsi. Untuk menerapkan checkpointing, rancang aplikasi Anda untuk memproses data dalam batch besar dan simpan hasil perantara ke penyimpanan persisten, seperti bucket Amazon S3 melalui Mountpoint for Amazon S3 CSI Driver saat pekerjaan pelatihan berlangsung.
Kasus penggunaan
Checkpoint sangat bermanfaat dalam skenario tertentu untuk menyeimbangkan toleransi kesalahan dengan overhead kinerja. Pertimbangkan untuk menggunakan checkpointing dalam kasus berikut:
-
Durasi pekerjaan melebihi beberapa jam: Untuk pekerjaan pelatihan yang berjalan lama (misalnya, >1-2 jam untuk model kecil, atau days/weeks untuk model pondasi besar dengan miliaran parameter), di mana kehilangan kemajuan akibat 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), checkpointing memungkinkan dimulainya kembali dengan cepat, membuat Spot layak untuk penghematan biaya dalam beban kerja yang toleran terhadap kesalahan.
-
Pelatihan terdistribusi dalam skala besar: Untuk pengaturan dengan hundreds/thousands akselerator (misalnya, >100 GPU), 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.
-
Large-scale model dengan tuntutan sumber daya 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 per jam untuk kegagalan besar) mengoptimalkan waktu pemulihan vs. efisiensi.
Gunakan Blok Kapasitas ML untuk jaminan kapasitas instans P dan Trainium
Blok Kapasitas untuk ML 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 segera atau pada tanggal mendatang untuk mendukung beban kerja pembelajaran mesin (ML) durasi pendek Anda. Reservasi ini ideal untuk memastikan kapasitas untuk tugas-tugas intensif komputasi seperti pelatihan model dan penyempurnaan. Harga Blok Kapasitas EC2 terdiri dari biaya reservasi dan biaya sistem operasi. Untuk mempelajari lebih lanjut tentang penetapan harga, lihat Blok Kapasitas EC2 untuk harga
Untuk memesan GPU untuk AI/ML beban kerja di Amazon EKS untuk jaminan kapasitas yang dapat diprediksi, kami sarankan memanfaatkan Blok Kapasitas ML untuk jangka pendek atau Reservasi Kapasitas (ODCR) untuk jaminan On-Demand kapasitas tujuan umum.
-
ODCR memungkinkan Anda untuk memesan kapasitas instans EC2 (misalnya, instans GPU seperti g5 atau p5) di Zona Ketersediaan tertentu untuk durasi tertentu, memastikan ketersediaan, bahkan selama permintaan tinggi. ODCR tidak memiliki komitmen jangka panjang, tetapi Anda membayar On-Demand tarif untuk kapasitas yang dicadangkan, baik bekas atau idle. Di EKS, ODCR didukung oleh tipe node seperti Karpenter
dan grup node terkelola. Untuk memprioritaskan ODCR di Karpenter, konfigurasikan NodeClass untuk menggunakan bidang tersebut. capacityReservationSelectorTermsLihat Dokumentasi Karpenter NodePools . -
Blok Kapasitas adalah mekanisme reservasi khusus untuk instans GPU (misalnya, p5, p4d) atau Trainium (trn1, trn2), yang dirancang untuk beban kerja ML jangka pendek seperti pelatihan model, penyempurnaan, atau eksperimen. Anda memesan kapasitas untuk periode yang ditentukan (biasanya 24 jam hingga 182 hari) mulai pada tanggal mendatang, hanya membayar untuk waktu yang dipesan. Mereka dibayar sebelumnya, 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, atau mulai dengan menyiapkan grup node terkelola dengan Blok Kapasitas menggunakan petunjuk di Membuat grup node terkelola dengan Blok Kapasitas untuk ML.
Cadangkan 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 Blo k Kapasitas untuk informasi selengkapnya.
Pertimbangkan On-Demand, Amazon EC2 Spot atau Reservasi On-Demand Kapasitas (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 On-Demand Kapasitas. ODCR memungkinkan Anda untuk memesan kapasitas instans EC2 di Zona Ketersediaan 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 yang berbeda, seperti inferensi atau grafik. Saat menggunakan Instans Spot Amazon EC2, kemampuan melakukan beragam jenis instans, ukuran, dan zona ketersediaan yang berbeda adalah kunci untuk dapat tetap berada di Spot lebih lama.
ODCR tidak memiliki komitmen jangka panjang, tetapi Anda membayar On-Demand tarif untuk kapasitas yang dicadangkan, baik bekas atau idle. ODCR dapat dibuat untuk penggunaan segera atau dijadwalkan untuk tanggal mendatang, memberikan fleksibilitas dalam perencanaan kapasitas. Di Amazon EKS, ODCR didukung oleh tipe node seperti Karpenter capacityReservationSelectorTerms Lihat Dokumentasi Karpenter NodePools .
Pertimbangkan jenis dan ukuran instance yang dipercepat lainnya
Memilih instance 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 paling tinggi, tinjau instans GPU yang tersedia di halaman Tipe Instans
Jika Anda menggunakan instance GPU di node EKS maka akan memiliki nvidia-device-plugin-daemonset pod di kube-system namespace secara default. Untuk mengetahui apakah Anda sepenuhnya menggunakan GPU dalam contoh Anda, Anda dapat menggunakan nvidia-sm
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.memorymendekati 100%, maka kode Anda kemungkinan terikat memori. Ini berarti bahwa GPU (memori) sepenuhnya dimanfaatkan tetapi dapat menyarankan bahwa pengoptimalan kinerja lebih lanjut harus diselidiki. -
Jika
utilization.gpumendekati 100%, ini tidak berarti GPU sepenuhnya dimanfaatkan. Metrik yang lebih baik untuk dilihat adalah rasiopower.drawterhadappower.limit. Jika rasio ini 100% atau lebih, maka kode Anda sepenuhnya memanfaatkan kapasitas komputasi GPU. -
-l 5Bendera mengatakan untuk menampilkan metrik setiap 5 detik. Dalam kasus jenis instance GPU tunggal, tanda kueri indeks tidak diperlukan.
Untuk mempelajari selengkapnya, lihat Instans GPU di dokumentasi 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 berlebihan atau kurang pemanfaatan, terutama untuk beban kerja dinamis seperti inferensi. AI/ML Memilih GPU yang tepat adalah penting. Untuk beban kerja bervolume rendah atau runcing, pemotongan waktu memungkinkan beberapa beban kerja untuk berbagi satu GPU dengan berbagi sumber daya komputasinya, berpotensi meningkatkan efisiensi dan mengurangi pemborosan. Berbagi GPU dapat dicapai melalui berbagai opsi:
-
Memanfaatkan Pemilih Node/Afinitas Node untuk mempengaruhi penjadwalan: Pastikan node yang disediakan dan pod dijadwalkan pada GPU yang sesuai 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 permintaan komputasi variabel, tetapi mungkin tidak memiliki isolasi memori.
-
Multi-Instance GPU (MIG): MIG memungkinkan satu GPU NVIDIA untuk dipartisi menjadi beberapa instans terisolasi dan didukung dengan GPU NVIDIA Ampere (misalnya, GPU A100), NVIDIA Hopper (misalnya, GPU H100), dan NVIDIA Blackwell (misalnya, GPU Blackwell). Setiap instans MIG menerima sumber daya komputasi dan memori khusus, memungkinkan berbagi sumber daya di lingkungan multi-tenant atau beban kerja yang memerlukan jaminan sumber daya, yang memungkinkan Anda mengoptimalkan pemanfaatan sumber daya GPU, termasuk skenario seperti melayani beberapa model dengan ukuran batch berbeda melalui pemotongan waktu.
-
Alokasi GPU Fraksional: 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
, bagian dari Run:ai platform, memungkinkan ini dengan mengizinkan pod untuk meminta sumber daya GPU fraksional.
Untuk mengaktifkan fitur-fitur ini di EKS, Anda dapat menerapkan Plugin Perangkat NVIDIA, yang mengekspos GPU sebagai sumber daya yang dapat dijadwalkan dan mendukung pemotongan waktu dan MIG. Untuk mempelajari selengkapnya, lihat Time-Slicing GPU di Kubernetes
Contoh
Misalnya, untuk mengaktifkan pemotongan 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 Pekerjaan Pelatihan
Menerapkan Pemeriksaan Kesehatan Node dengan Pemulihan Otomatis
Untuk pekerjaan pelatihan terdistribusi di Amazon EKS yang memerlukan komunikasi antar node 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 yang berjalan lama yang bergantung pada perangkat keras yang stabil.
Untuk membantu menambah ketahanan terhadap kegagalan perangkat keras, seperti kegagalan GPU di cluster EKS yang menjalankan beban kerja GPU, kami sarankan memanfaatkan Agen Pemantauan Node EKS dengan Perbaikan Otomatis atau Amazon. SageMaker HyperPod Sementara Agen Pemantauan Node EKS dengan Perbaikan Otomatis menyediakan 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 secara otomatis.
-
Agen Pemantauan Node EKS dengan Perbaikan Otomatis Node terus memantau kesehatan node dengan membaca log dan menerapkan NodeConditions, termasuk kondisi standar seperti
Readydan kondisi khusus untuk perangkat keras yang dipercepat untuk mengidentifikasi masalah seperti GPU atau kegagalan jaringan. Ketika sebuah node dianggap tidak sehat, Node Auto Repair membungkusnya dan menggantinya dengan node baru. Penjadwalan ulang pod dan memulai ulang pekerjaan bergantung pada mekanisme Kubernetes standar dan kebijakan restart pekerjaan. -
Pemer SageMaker HyperPod
iksaan kesehatan mendalam dan agen pemantauan kesehatan terus memantau status kesehatan GPU dan Trainium-based instans. Ini disesuaikan untuk AI/ML beban kerja, menggunakan label (misalnya, status kesehatan simpul) untuk mengelola kesehatan node. Ketika sebuah node dianggap tidak sehat, HyperPod memicu penggantian otomatis perangkat keras yang rusak, seperti GPU. Ini mendeteksi kegagalan terkait jaringan untuk EFA melalui pemeriksaan kesehatan dasarnya secara default dan mendukung resume otomatis untuk pekerjaan pelatihan yang terputus, memungkinkan pekerjaan dilanjutkan dari pos pemeriksaan terakhir, meminimalkan gangguan untuk tugas ML skala besar.
Untuk Agen Pemantauan Node EKS dengan Perbaikan Otomatis dan SageMaker HyperPod cluster yang menggunakan EFA, untuk memantau EFA-specific metrik seperti kesalahan Remote Direct Memory Access (RDMA) dan drop paket, pastikan driver AWS EFA diinstal. Selain itu, kami merekomendasikan untuk menerapkan CloudWatch Observabilitas Add-on 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 yang sensitif terhadap gangguan
Untuk beban kerja yang sensitif terhadap gangguan, seperti pemrosesan, tugas AI/ML prediksi skala besar, atau pelatihan, sebaiknya sesuaikan kebijakan konsolidasi Karpenter
Kebijakan WhenEmptyOrUnderutilized konsolidasi dapat mengakhiri node sebelum waktunya, yang menyebabkan 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 yang tajam dan pekerjaan sensitif interupsi lainnya, seperti pemrosesan data inferensi online real-time atau pelatihan model, di mana biaya interupsi lebih besar daripada penghematan biaya komputasi. Anggaran Gangguan Karpenter adalah fitur lain untuk mengelola
Gunakan ttl SecondsAfterFinished untuk Pekerjaan Clean-Up Kubernetes Otomatis
Sebaiknya setel ttlSecondsAfterFinished untuk pekerjaan Kubernetes di Amazon EKS agar secara otomatis menghapus objek pekerjaan yang telah selesai. Objek pekerjaan yang tersisa menghabiskan sumber daya cluster, seperti memori server API, dan mempersulit pemantauan dengan dasbor yang berantakan (misalnya, Grafana, Amazon). CloudWatch Misalnya, menetapkan TTL 1 jam memastikan pekerjaan dihapus segera setelah selesai, menjaga cluster Anda tetap rapi. Untuk detail selengkapnya, lihat Pem bersihan Otomatis untuk Pekerjaan Selesai.
Konfigurasikan Preemption Low-Priority Pekerjaan untuk Higher-Priority Jobs/workloads
Untuk AI/ML beban kerja prioritas campuran di Amazon EKS, Anda dapat mengonfigurasi preemption pekerjaan prioritas rendah untuk memastikan tugas dengan prioritas lebih tinggi (misalnya, inferensi real-time) menerima sumber daya dengan segera. Tanpa preemption, beban kerja prioritas rendah seperti proses batch (misalnya, inferensi batch, pemrosesan data), layanan non-batch (misalnya, tugas latar belakang, pekerjaan cron), atau CPU/memory-intensive pekerjaan (misalnya, layanan web) dapat menunda pod kritis dengan menempati node. Preemption memungkinkan Kubernetes untuk mengusir pod prioritas rendah ketika pod prioritas tinggi membutuhkan sumber daya, memastikan alokasi sumber daya yang efisien pada node dengan GPU, CPU, atau memori. Sebaiknya gunakan Kubernetes PriorityClass untuk menetapkan prioritas dan mengontrol perilaku penggus PodDisruptionBudget uran.
apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: low-priority value: 100 --- spec: priorityClassName: low-priority
Lihat Dokumentasi Prioritas dan Preemption Kubernetes untuk informasi selengkapnya.
Penskalaan dan Kinerja Aplikasi
Sesuaikan Kapasitas Komputasi untuk beban kerja ML dengan Karpenter atau Node Statis
Untuk memastikan kapasitas komputasi yang hemat biaya dan responsif untuk alur kerja pembelajaran mesin (ML) di Amazon EKS, sebaiknya sesuaikan strategi penyediaan node dengan karakteristik beban kerja dan komitmen biaya. Di bawah ini adalah dua pendekatan yang perlu dipertimbangkan: penskalaan just-in-time dengan Karpenter
-
Just-in-time penskalaan bidang data seperti Karpenter: Untuk alur kerja ML dinamis dengan tuntutan komputasi variabel (misalnya, GPU-based inferensi diikuti dengan plot), kami sarankan menggunakan skala bidang CPU-based data just-in-time seperti Karpenter.
-
Gunakan grup simpul statis untuk beban kerja yang dapat diprediksi: Untuk beban kerja ML kondisi mapan yang dapat diprediksi atau saat menggunakan instans Cadangan, grup node yang dikelola EKS dapat membantu memastikan kapasitas cadangan disediakan dan dimanfaatkan sepenuhnya, memaksimalkan penghematan. Pendekatan ini sangat ideal untuk jenis instans tertentu yang dilakukan melalui RI atau ODCR.
Contoh
Ini adalah contoh beragam Karpenter NodePool g Amazon EC2 di mana generasi 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 simpul 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 noda 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, sebaiknya gunakan noda dan toleransi untuk memastikan pod beban kerja yang tidak dipercepat tidak dijadwalkan pada node yang tidak sesuai. Lihat dokumentasi Kubernetes
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 https://keda.sh/
Alokasi sumber daya dinamis untuk manajemen GPU tingkat lanjut
Alokasi sumber daya dinamis (DRA)
-
Fine-grained Alokasi GPU
-
Mekanisme berbagi lanjutan, seperti Multi-Process layanan (MPS) dan Multi-Instance GPU (MIG)
-
Dukungan untuk arsitektur perangkat keras generasi berikutnya, termasuk NVIDIA GB200 UltraServers
Alokasi GPU tradisional memperlakukan GPU sebagai sumber daya integer buram, menciptakan kurangnya pemanfaatan yang signifikan (seringkali 30-40% dalam cluster produksi). Hal ini terjadi karena beban kerja menerima akses eksklusif ke seluruh GPU 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 yang cerdas dan berbagi sumber daya yang efisien.
Keuntungan menggunakan DRA alih-alih plugin perangkat NVIDIA
Plugin perangkat NVIDIA (mulai dari versi0.12.0) mendukung mekanisme berbagi GPU termasuk time-slicing, MPS, dan MIG. Namun, ada batasan arsitektur yang ditangani DRA.
Batasan plugin perangkat NVIDIA
-
Konfigurasi statis: Konfigurasi berbagi GPU (replika pemotongan waktu dan pengaturan MPS) memerlukan pra-konfigurasi di seluruh cluster.
ConfigMapsHal ini membuat penyediaan strategi berbagi yang berbeda untuk beban kerja yang berbeda menjadi sulit. -
Pilihan granular terbatas: Sementara 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 domain NVLink untuk sistem seperti NVIDIA GB200.
-
Kendala penjadwal: Pen jadwal 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 memerlukan pelabelan simpul ganda
ConfigMapsdan 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 waktu permintaan.
resourceclaimsIni 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 memori yang koheren.
-
Cross-node manajemen sumber daya:
computeDomainsmemungkinkan koordinasi sumber daya GPU terdistribusi di beberapa node, penting untuk sistem seperti GB200 dengan saluran IMEX. -
Workload-specific konfigurasi: Mas ing-masing
ResourceClaimmenentukan strategi dan konfigurasi berbagi yang berbeda, memungkinkan kontrol berbutir halus per beban kerja daripada pengaturan seluruh cluster. -
Integrasi penjadwal yang ditingkatkan: 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 | Time-slicing | 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 L40S |
Ya |
Tidak |
Ya |
Tidak |
Pelatihan, inferensi, dan grafik |
|
P4d/P4de |
NVIDIA A100 |
Ya |
Ya |
Ya |
Tidak |
Large-scale Pelatihan 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): Hardware-level partisi yang membuat instance GPU terisolasi.
-
Multi-Process layanan (MPS): Memungkinkan eksekusi bersamaan dari beberapa proses CUDA pada satu GPU.
-
Internode Memory Exchange (IMEX): Memory-coherent komunikasi 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 alokasi sumber daya dinamis https://github.com/kubernetes/dynamic-resource-allocation
Menyiapkan 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.33atau yang lebih baru -
Grup node terkelola Amazon EKS (DRA saat ini hanya didukung oleh grup node terkelola dengan AMI yang dioptimalkan AL2023 dan Bottlerocket NVIDIA, tidak dengan Karpenter)
-
N GPU-enabled ode pekerja NVIDIA dengan tipe instance yang sesuai
Komponen yang dibutuhkan
-
Versi plugin perangkat NVIDIA
0.17.1atau yang lebih baru -
Versi driver NVIDIA DRA
25.3.0atau yang lebih baru
Langkah 1: Buat cluster dengan grup DRA-enabled node menggunakan eksctl
-
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 -
Buat cluster:
eksctl create cluster -f dra-eks-cluster.yaml
Langkah 2: Terapkan plugin perangkat NVIDIA
Terapkan plugin perangkat NVIDIA untuk mengaktifkan penemuan GPU dasar:
-
Tambahkan plugin perangkat NVIDIA Helm repositori:
helm repo add nvidia https://nvidia.github.io/k8s-device-plugin helm repo update -
Buat nilai kustom untuk plugin perangkat:
cat <<EOF > nvidia-device-plugin-values.yaml gfd: enabled: true nfd: enabled: true tolerations: - key: nvidia.com/gpu operator: Exists effect: NoSchedule EOF -
Instal plug-in perangkat NVIDIA:
helm install nvidia-device-plugin nvidia/nvidia-device-plugin \ --namespace nvidia-device-plugin \ --create-namespace \ --version 0.17.1 \ --values nvidia-device-plugin-values.yaml
Langkah 3: Terapkan grafik Helm driver NVIDIA DRA
-
Buat file
dra-driver-values.yamlnilai 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 -
Tambahkan repositori NVIDIA NGC Helm:
helm repo add nvidia https://helm.ngc.nvidia.com/nvidia helm repo update -
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
-
Verifikasi bahwa sumber daya DRA API tersedia:
kubectl api-resources | grep resource.k8s.io/v1beta1Berikut 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 -
Periksa kelas perangkat yang tersedia:
kubectl get deviceclassesBerikut 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 4h39mSaat instance GPU G6 yang baru dibuat bergabung dengan cluster Amazon EKS Anda dengan DRA diaktifkan, tindakan berikut terjadi:
-
Driver NVIDIA DRA secara otomatis menemukan GPU A10G dan membuat dua
resourceslicespada node itu. -
Iris
gpu.nvidia.coman mendaftarkan perangkat GPU A10G fisik dengan spesifikasinya (memori, kemampuan komputasi, dan banyak lagi). -
Karena A10G tidak mendukung partisi MIG, ir
compute-domain.nvidia.comisan membuat domain komputasi tunggal yang mewakili seluruh konteks komputasi GPU. -
Ini kemudian
resourceslicesdipublikasikan ke server API Kubernetes, membuat sumber daya GPU tersedia untuk penjadwalan.resourceclaimsPenjadwal DRA sekarang dapat secara 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 resourceslicesBerikut 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.
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 mengikutiMenyiapkan alokasi sumber daya dinamis untuk manajemen GPU tingkat lanjut.
-
Buat dasar
ResourceClaimTemplateuntuk alokasi GPU dengan file bernamabasic-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 -
Terapkan template:
kubectl apply -f basic-gpu-claim-template.yaml -
Verifikasi statusnya:
kubectl get resourceclaimtemplates -n gpu-test1Berikut ini adalah output contoh:
NAME AGE single-gpu 9m16s -
Buat Pod yang menggunakan
ResourceClaimTemplatedengan file bernamabasic-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" -
Terapkan dan pantau Pod:
kubectl apply -f basic-gpu-pod.yaml -
Periksa status Pod:
kubectl get pod -n gpu-test1Berikut ini adalah contoh output yang diharapkan:
NAME READY STATUS RESTARTS AGE gpu-pod 1/1 Running 0 13m -
Periksa
ResourceClaimstatusnya:kubectl get resourceclaims -n gpu-test1Berikut ini adalah contoh output yang diharapkan:
NAME STATE AGE gpu-pod-gpu0-l76cg allocated,reserved 9m6s -
Lihat log Pod untuk melihat informasi GPU:
kubectl logs gpu-pod -n gpu-test1Berikut 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 untuk teknik pengoptimalan 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 optimal dan efisiensi biaya. DRA memungkinkan beberapa teknik pengoptimalan lanjutan yang menangani kasus penggunaan dan kemampuan perangkat keras yang berbeda:
-
Time-slicingmemungkinkan 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 pemotongan waktu.
-
Multi-Process layanan (MPS) memungkinkan eksekusi bersamaan dari beberapa proses CUDA pada satu GPU dengan isolasi yang lebih baik daripada pemotongan waktu. Sebagai contoh, lihat Optimalkan beban kerja GPU dengan MPS.
-
Multi-Instance GPU (MIG) menyediakan partisi tingkat perangkat keras, membuat instans GPU terisolasi dengan sumber daya komputasi dan memori khusus. Sebagai contoh, lihat Optimalkan beban kerja GPU dengan Multi-Instance GPU.
-
Internode Memory Exchange (IMEX) memungkinkan komunikasi memori yang koheren di seluruh node untuk pelatihan terdistribusi pada sistem NVIDIA GB200. Sebagai contoh, lihat Optimalkan beban kerja GPU dengan IMEX menggunakan instans GB200 P6e.
Teknik-teknik ini dapat secara signifikan meningkatkan pemanfaatan sumber daya. Organisasi melaporkan peningkatan pemanfaatan GPU 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 pemotongan 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.
-
Tentukan a
ResourceClaimTemplateuntuk mengiris waktu 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 -
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 -
Terapkan template dan Pod:
kubectl apply -f timeslicing-claim-template.yaml kubectl apply -f timeslicing-pod.yaml -
Pantau klaim sumber daya:
kubectl get resourceclaims -n timeslicing-gpu -wBerikut 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 mengkonfigurasi pemotongan waktu pada GPU yang sama
-
Status Pod: Menunggu untuk dijadwalkan
-
Negara akan beralih dari
pendingallocated,reservedkerunning
Optimalkan beban kerja GPU dengan MPS
Multi-Process Layanan (MPS) memungkinkan eksekusi bersamaan dari beberapa konteks CUDA pada satu GPU dengan isolasi yang lebih baik daripada pemotongan waktu.
Lakukan langkah-langkah berikut.
-
Tentukan a
ResourceClaimTemplateuntuk MPS dengan file bernamamps-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 -
Tentukan 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 -
Terapkan template dan buat beberapa Pod MPS:
kubectl apply -f mps-claim-template.yaml kubectl apply -f mps-pod.yaml -
Pantau klaim sumber daya:
kubectl get resourceclaims -n mps-gpu -wBerikut 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 Multi-Process Layanan NVIDIA (MPS) melalui alokasi sumber daya dinamis (DRA). Tidak seperti pemotongan waktu di mana beban kerja bergiliran menggunakan GPU secara berurutan, MPS memungkinkan kedua wadah berjalan secara bersamaan pada GPU fisik yang sama. Wawasan utamanya adalah bahwa berbagi DRA MPS memerlukan beberapa wadah dalam satu Pod, bukan beberapa Pod terpisah. Saat digunakan, driver DRA mengalokasikan satu ResourceClaim ke Pod dan secara otomatis mengonfigurasi MPS untuk memungkinkan wadah inferensi dan pelatihan dieksekusi secara bersamaan.
Setiap wadah mendapatkan ruang memori GPU terisolasi dan sumber daya komputasi sendiri, dengan daemon MPS mengoordinasikan akses ke perangkat keras yang mendasarinya. Anda dapat memverifikasi ini berfungsi dengan melakukan hal berikut:
-
Memer
nvidia-smiiksa, yang akan menampilkan kedua wadah sebagai proses M+C (MPS + Compute) berbagi perangkat GPU yang sama. -
Memantau log dari kedua wadah, 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: wadah kesimpulan
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 |
+-----------------------------------------------------------------------------------------+
Container2: wadah pelatihan
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 Multi-Instance GPU
Multi-instance GPU (MIG) menyediakan partisi tingkat perangkat keras, membuat instans GPU terisolasi dengan sumber daya komputasi dan memori khusus.
Menggunakan partisi MIG dinamis dengan berbagai profil memerlukan Operator GPU WITH0—REBOOT=true konfigurasi MIG Manager sangat penting untuk penerapan MIG yang sukses.
Anda memerlukan NVIDIA DRA Driver
Langkah 1: Terapkan Operator GPU NVIDIA
-
Tambahkan repositori Operator GPU NVIDIA:
helm repo add nvidia https://nvidia.github.io/gpu-operator helm repo update -
Buat
gpu-operator-values.yamlfile: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 -
Instal Operator GPU menggunakan
gpu-operator-values.yamlfile:helm install gpu-operator nvidia/gpu-operator \ --namespace gpu-operator \ --create-namespace \ --version v25.3.1 \ --values gpu-operator-values.yamlBagan Helm ini menerapkan 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 - GPU-specific pelabelan)
-
Manajer MIG (partisi Multi-instance GPU)
-
Toolkit Kontainer (runtime kontainer GPU)
-
Pengontrol Operator (manajemen siklus hidup)
-
-
Verifikasi Pod penerapan:
kubectl get pods -n gpu-operatorBerikut 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 -
Buat cluster 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 IDOperator GPU NVIDIA menggunakan label yang ditambahkan ke node
nvidia.com/mig.config: "p4de-half-balanced"dan mempartisi GPU dengan profil yang diberikan. -
Masuk ke
p4deinstance. -
Jalankan perintah berikut:
nvidia-smi -LAnda 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 instans P4DE Anda, membuat partisi GPU tingkat perangkat keras seperti yang dikonfigurasi. Berikut cara kerja partisi:
Operator GPU menerapkan konfigurasi ini dari profil MIG tertanam Anda:
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 GPU (0-3): perangkat keras dipartisi
-
GPU 0: NVIDIA A100-SXM4-80GB
-
MIG 3g.40gb Perangkat 0 - Beban kerja besar (memori 40GB, 42 SM)
-
MIG 2g.20gb Perangkat 1 - Beban kerja sedang (memori 20GB, 28 SM)
-
MIG 1g.10gb Perangkat 2 - Beban kerja kecil (memori 10GB, 14 SM)
-
MIG 1g.10gb Perangkat 3 - Beban kerja kecil (memori 10GB, 14 SM)
-
-
GPU 1: NVIDIA A100-SXM4-80GB
-
MIG 3g.40gb Perangkat 0 - Tata letak partisi yang 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
-
-
GPU Penuh (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 DRA NVIDIA 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 instans yang tersedia di semua GPU. Ketika Pod meminta profil MIG tertentu melalui aResourceClaimTemplate, driver DRA secara cerdas memilih instans MIG yang sesuai dari GPU apa pun yang tersedia, memungkinkan penyewaan multi-level perangkat keras yang sebenarnya. Alokasi dinamis ini memungkinkan beberapa beban kerja terisolasi berjalan secara bersamaan pada GPU fisik yang sama sambil mempertahankan batas sumber daya yang ketat dan jaminan kinerja.
Langkah 2: Uji alokasi sumber daya MIG
Sekarang mari kita jalankan beberapa contoh untuk menunjukkan bagaimana DRA mengalokasikan instans MIG secara dinamis 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 wadah untuk berbagi sumber daya GPU dengan isolasi tingkat perangkat keras.
-
Buat
mig-claim-template.yamluntuk berisi MIGresourceclaimtemplates: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' -
Terapkan tiga template:
kubectl apply -f mig-claim-template.yaml -
Jalankan perintah berikut:
kubectl get resourceclaimtemplates -n mig-gpuBerikut ini adalah output contoh:
NAME AGE mig-large-template 71m mig-medium-template 71m mig-small-template 71m -
Buat
mig-pod.yamluntuk menjadwalkan beberapa pekerjaan untuk memanfaatkan iniresourceclaimtemplates:--- # 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 -
Terapkan spesifikasi ini, yang seharusnya menerapkan tiga Pod:
kubctl apply -f mig-pod.yamlPod ini harus dijadwalkan oleh driver DRA.
-
Periksa log Pod driver DRA 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**],}] -
Verifikasi
resourceclaimsuntuk melihat status Pod:kubectl get resourceclaims -n mig-gpu -wBerikut 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 0sSeperti yang Anda lihat, semua Pod dipindahkan dari penundaan ke
allocated,reservedoleh driver DRA. -
Jalan
nvidia-smikan dari simpul. 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 GB200 P6e
IMEX (Internode Memory Exchange) memungkinkan komunikasi memori yang koheren di seluruh node untuk pelatihan terdistribusi pada NVIDIA GB200. UltraServers
Lakukan langkah-langkah berikut.
-
Tentukan
ComputeDomainuntuk pelatihan multi-node dengan file bernama:imex-compute-domain.yamlapiVersion: resource.nvidia.com/v1beta1 kind: ComputeDomain metadata: name: distributed-training-domain namespace: default spec: numNodes: 2 channel: resourceClaimTemplate: name: imex-channel-template -
Tentukan Pod menggunakan saluran IMEX dengan file bernama:
imex-pod.yamlapiVersion: 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: NoSchedulecatatan
Ini membutuhkan instans P6e GB200.
-
Terapkan IMEX dengan menerapkan template
ComputeDomaindan:kubectl apply -f imex-claim-template.yaml kubectl apply -f imex-compute-domain.yaml kubectl apply -f imex-pod.yaml -
Periksa
ComputeDomainstatusnya.kubectl get computedomain distributed-training-domain -
Pantau penyebaran daemon IMEX.
kubectl get pods -n nvidia-dra-driver -l resource.nvidia.com/computeDomain -
Periksa saluran IMEX di Pod:
kubectl exec imex-distributed-training -- ls -la /dev/nvidia-caps-imex-channels/ -
Lihat log Pod:
kubectl logs imex-distributed-trainingBerikut 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