Bantu tingkatkan halaman ini
Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Untuk berkontribusi pada panduan pengguna ini, pilih Edit halaman ini pada GitHub tautan yang terletak di panel kanan setiap halaman.
Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Kelola komputasi untuk AI/ML beban kerja dengan EKS Auto Mode dan Karpenter
Tip
Daftar
Bagian ini mencakup cara mengelola komputasi yang dipercepat (AWS Trainium, NVIDIA GPU) untuk pelatihan AI dan beban kerja inferensi menggunakan Amazon EKS Auto Mode atau Karpenter yang dikelola sendiri.
EKS Auto Mode dan Karpenter mendukung dua mode penyediaan: penyediaan dinamis dan penyediaan statis. Dengan penyediaan dinamis, EKS Auto Mode dan Karpenter menyediakan dan menskalakan instans komputasi yang dipercepat saat beban kerja dijadwalkan di cluster. Dengan penyediaan statis, EKS Auto Mode dan Karpenter menyediakan dan mempertahankan jumlah node tetap. Penyediaan dinamis dan statis dapat digunakan dalam klaster yang sama untuk mempertahankan kumpulan kapasitas dasar yang konstan sambil menskalakan dengan tuntutan beban kerja.
EKS Auto Mode dan Karpenter mendukung keempat opsi pembelian kapasitas (On-Demand, Spot, Blok Kapasitas, dan ODCR) dan selalu menyediakan kapasitas cadangan terlebih dahulu, diikuti oleh Spot atau. On-Demand
Mode Otomatis EKS vs Karpenter
Kedua pendekatan berbagi NodePool API, tetapi keduanya berbeda dalam kepemilikan operasional, API sumber daya, dukungan sistem operasi, penanganan interupsi Spot, dan fleksibilitas konfigurasi.
| Fitur | Mode Otomatis EKS | Self-managed Karpenter |
|---|---|---|
|
Terbaik untuk |
Tim yang lebih memilih infrastruktur terkelola dengan overhead operasional minimal |
Tim yang lebih memilih kontrol penuh atas siklus hidup node, AMI, penyetelan OS, dan patching. |
|
Model operasional |
AWS menyediakan dan mengelola pengontrol Karpenter, GPU/Trainium driver, plugin perangkat, penambalan OS, dan penanganan interupsi Spot. |
Anda menginstal dan mengoperasikan pengontrol Karpenter di cluster dan GPU/Trainium driver Anda sendiri, plugin perangkat, siklus hidup AMI, penambalan, dan penanganan interupsi Spot. |
|
Opsi Komputasi |
On-Demand, Spot, ODCR, Blok Kapasitas untuk ML |
On-Demand, Spot, ODCR, Blok Kapasitas untuk ML |
|
API Sumber Daya |
|
|
|
Sistem operasi node |
Hanya Bottlerocket. Termasuk dependensi NVIDIA GPU, AWS Trainium, dan EFA. |
AL2023, Bottlerocket, Windows, atau AMI Anda sendiri. |
|
Node seumur hidup |
Masa pakai node maksimum 21 hari untuk patch keamanan. Beban kerja harus mentolerir rotasi simpul. |
Anda menentukan siklus hidup node melalui NodePool |
|
Penanganan gangguan spot |
Asli. Tidak diperlukan antrian SQS atau Node Termination Handler. |
Tanggung jawab Anda untuk mengkonfigurasi dan mengaktifkan. |
|
Penarikan kontainer cepat |
SOCI parallel pull disertakan dalam semua instance keluarga G, P, dan Trn |
Tanggung jawab Anda untuk mengkonfigurasi dan mengaktifkan. |
|
Grup penempatan EC2 |
Cluster, partisi, penyebaran |
Cluster, partisi, penyebaran |
|
Konfigurasi antarmuka jaringan |
Tidak didukung |
Per konfigurasi antarmuka untuk jenis |
|
Perbaikan simpul |
Diaktifkan secara default, agen pemantauan simpul EKS disertakan |
Diaktifkan secara opsional, agen pemantauan simpul EKS dikelola sendiri |
|
Harga |
Biaya manajemen Mode Otomatis EKS selain biaya |
Sumber terbuka. Anda membayar instans EC2 yang mendasarinya. |
Label umum AI/ML yang terkenal
EKS Auto Mode dan Karpenter mengekspos label instance yang dapat Anda gunakan di NodePool requirements dan Pod nodeSelector atau nodeAffinity untuk menargetkan beban kerja tanpa jenis instance hardcoding. Awalan label berbeda di antara keduanya: Mode Otomatis EKS digunakan eks.amazonaws.com/ saat Karpenter yang dikelola sendiri menggunakan. karpenter.k8s.aws/
Tabel di bawah ini menunjukkan label yang relevan yang dapat digunakan NodePools. EKS Auto Mode dan Karpenter juga menerapkan label yang tercantum dalam dokumentasi Karpenter
Menjadwalkan label untuk kapasitas cadangan
Ketika EKS Auto Mode atau Karpenter meluncurkan node ke reservasi, ia menambahkan label berikut. Gunakan mereka dalamnodeSelector, afinitas simpul, atau NodePool persyaratan untuk merutekan beban kerja.
-
karpenter.sh/capacity-type:reserved,on-demand, atauspot. Menunjukkan kapasitas mendukung node. -
karpenter.k8s.aws/capacity-reservation-id: ID reservasi spesifik tempat node diluncurkan. -
karpenter.k8s.aws/capacity-reservation-type:defaultuntuk ODCR,capacity-blockuntuk Blok Kapasitas.
Contoh berikut menunjukkan pola penjadwalan umum:
Sematkan Pod ke satu reservasi tertentu (tanpa fallback):
spec: nodeSelector: karpenter.sh/capacity-type: reserved karpenter.k8s.aws/capacity-reservation-id: "cr-0123456789abcdef0"
Targetkan node ODCR saja (ODCR apa pun, bukan Blok Kapasitas):
spec: nodeSelector: karpenter.sh/capacity-type: reserved karpenter.k8s.aws/capacity-reservation-type: default
Targetkan kapasitas cadangan apa pun (ODCR atau Blok Kapasitas):
spec: nodeSelector: karpenter.sh/capacity-type: reserved
Lebih suka dipesan tetapi kembali ke Spot atau On-Demand jika tidak tersedia:
spec: affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 preference: matchExpressions: - key: karpenter.sh/capacity-type operator: In values: ["reserved"]
Perilaku kedaluwarsa reservasi
ODCR dan Blok Kapasitas berperilaku berbeda saat reservasi berakhir. Pastikan strategi penjadwalan dan pos pemeriksaan Anda sesuai dengan jenis reservasi yang mendukung beban kerja Anda.
ODCR
Sebuah instance yang diluncurkan ke ODCR tidak ada dalam ODCR itu tanpa batas waktu. ODCR dapat kedaluwarsa, dibatalkan, atau instance dapat dihapus secara manual dari ODCR. Jika salah satu dari ini terjadi dan EKS Auto Mode/Karpenter mendeteksi bahwa instance tidak lagi milik ODCR, itu memperbarui label node dari to. karpenter.sh/capacity-type reserved on-demand Instance terus berjalan sebagai On-Demand kapasitas standar, dan Pod yang ada terus berjalan tanpa gangguan.
catatan
Setiap Pod yang dijadwalkan dengan ketat tidak nodeSelector: karpenter.sh/capacity-type: reserved akan menjadwalkan ke node jika telah diberi label ulang. Agar beban kerja dapat bertahan dari kedaluwarsa atau pembatalan ODCR, gunakan preferredDuringSchedulingIgnoredDuringExecution pola yang ditunjukkan di atas, bukan a. nodeSelector
Blok Kapasitas
Tidak seperti ODCR, Blok Kapasitas selalu memiliki waktu akhir, dan EC2 mengakhiri instance Blok Kapasitas 30 menit sebelum waktu akhir (60 menit untuk tipe instance). UltraServer Rencanakan pekerjaan pelatihan dan inferensi untuk menyelesaikan atau menyimpan status sebelum jendela reservasi ditutup. Pod yang menggunakan strict nodeSelector for a specific capacity-reservation-id go Pending setelah pemblokiran berakhir dan tidak akan menjadwal ulang di tempat lain. Gabungkan checkpointing dengan pola afinitas fleksibel di atas jika Anda membutuhkan beban kerja untuk pindah ke kapasitas lain selama kadaluwarsa Blok Kapasitas.
-
Anda dapat menggunakan instans cadangan hingga 30 menit sebelum waktu akhir Blok Kapasitas untuk sebagian besar jenis instans, atau 60 menit sebelum waktu akhir untuk jenis UltraServer instans.
-
Mode Otomatis EKS dan Karpenter terlebih dahulu mulai menguras node dalam Blok Kapasitas 10 menit sebelum EC2 memulai penghentian, sehingga beban kerja punya waktu untuk memeriksa dan mematikan dengan anggun.
Kapasitas statis NodePools
EKS Auto Mode dan Karpenter mendukung kapasitas statis NodePools, yang mempertahankan jumlah node tetap terlepas dari permintaan beban kerja. Pool statis menghilangkan penundaan start dingin untuk inferensi sensitif latensi, dan memungkinkan Anda memesan jejak infrastruktur minimum untuk klaster Anda.
Kapasitas statis dikonfigurasi dengan mengatur replicas bidang pada NodePool.
Pertimbangan-pertimbangan
-
Setelah
replicasdiatur pada a NodePool, Anda tidak dapat menghapusnya. Seseorang tidak NodePool dapat beralih antara penyediaan kapasitas statis dan dinamis. -
Kapasitas NodePools statis tidak dipertimbangkan untuk konsolidasi. Setel
limits.nodesdi atasreplicasuntuk memungkinkan penskalaan sementara selama drift atau kedaluwarsa AMI. -
Untuk distribusi Availability Zone (AZ) yang dapat diprediksi, buat satu kapasitas statis NodePool per AZ daripada mencakup beberapa zona dalam satu kumpulan.
Blok Kapasitas untuk ML
Blok Kapasitas untuk ML memungkinkan Anda melakukan reservasi P-family dan instans Trainium untuk jendela masa depan yang ditentukan. Mereka pra-bayar, jadi EKS Auto Mode dan Karpenter memodelkannya sebagai gratis dan memprioritaskannya di atas dan Spot. On-Demand Blok Kapasitas untuk ML dapat memiliki durasi reservasi 1-14 hari atau kelipatan 7 hari, hingga 182 hari (6 bulan).
Untuk menggunakan Blok Kapasitas untuk ML dengan Mode Otomatis EKS atau Karpenter, konfigurasikan capacityReservationSelectorTerms dengan ID reservasi kapasitas Anda di. NodeClass Anda tidak dapat menggunakan pencocokan reservasi terbuka dengan Blok Kapasitas untuk ML. Sebuah istilah dapat menentukan ID, satu set tag, atau kriteria pencocokan instance untuk dipilih. Saat menentukan tag, itu akan memilih semua reservasi kapasitas yang dapat diakses dari akun dengan tag yang cocok. Ini dapat dibatasi lebih lanjut dengan menentukan ID akun pemilik.
Untuk contoh lainnya, lihat dokumentasi Karpenter
On-Demand Reservasi Kapasitas (ODCR)
ODCR menjamin kapasitas di Availability Zone (AZ) tertentu tanpa komitmen jangka panjang. Anda ditagih dengan On-Demand tarif standar apakah kapasitas digunakan atau tidak. ODCR mendukung semua keluarga GPU NVIDIA, termasuk G-family instance yang tidak didukung oleh Blok Kapasitas untuk ML. ODCR adalah pra-bayar, jadi EKS Auto Mode dan Karpenter memodelkannya sebagai gratis dan memprioritaskannya di atas dan Spot. On-Demand
ODCR berperilaku berbeda dari Blok Kapasitas untuk ML di akhir reservasi. Ketika ODCR kedaluwarsa atau dibatalkan, instance tetap berjalan sebagai standar. On-Demand Lihat Perilaku kedaluwarsa reservasi untuk detail.
Untuk menggunakan ODCR dengan EKS Auto Mode atau Karpenter, konfigurasikan capacityReservationSelectorTerms dengan syarat reservasi kapasitas Anda di. NodeClass Sebuah istilah dapat menentukan ID, satu set tag, atau kriteria pencocokan instance untuk dipilih. Saat menentukan tag, itu akan memilih semua reservasi kapasitas yang dapat diakses dari akun dengan tag yang cocok. Saat menentukan kriteria pencocokan instance, ia memilih reservasi berdasarkan perilaku pencocokannya: open (cocok dengan semua instance yang kompatibel) atau ditargetkan (hanya cocok dengan instance yang ditargetkan secara eksplisit). Ini dapat dibatasi lebih lanjut dengan menentukan ID akun pemilik.
Untuk contoh lainnya, lihat dokumentasi Karpenter
On-Demand
On-Demand adalah tipe kapasitas default dan dapat digunakan dengan penyediaan statis atau dinamis dalam Mode Otomatis EKS dan Karpenter. Anda dapat secara eksplisit meminta On-Demand instance dengan menyetel karpenter.sh/capacity-type: on-demand di. NodePool EKS Auto Mode dan Karpenter memilih instance dengan harga terendah yang memenuhi permintaan sumber daya Pod. Gunakan On-Demand untuk pengembangan, pembuatan prototipe, penskalaan inferensi yang tidak dapat diprediksi, dan beban kerja apa pun yang membutuhkan ketersediaan segera tanpa risiko gangguan.
Spot
Spot menawarkan penghematan hingga 90% dibandingkan On-Demand dengan menggunakan kapasitas EC2 cadangan. AWS dapat merebut kembali instans Spot dengan pemberitahuan interupsi 2 menit. Maksimalkan ketersediaan dengan mencantumkan beberapa keluarga instans di NodePool. Pasangkan beban kerja Spot dengan pos pemeriksaan PodDisruptionBudget dan ke penyimpanan yang tahan lama (Amazon S3 atau Amazon EFS) secara berkala sehingga Pod dapat menyimpan status selama jendela drain.
Spot cocok untuk beban kerja pelatihan yang toleran terhadap kesalahan, dapat dilanjutkan, dan inferensi di mana gangguan sesekali dapat diterima dengan imbalan penghematan biaya yang signifikan.
Kandidat umum meliputi:
-
Penyetelan dan sapuan hiperparameter: banyak uji coba paralel pendek yang dapat dicoba lagi jika terputus.
-
Pelatihan terdistribusi dengan checkpointing: pekerjaan jangka panjang yang secara berkala menyimpan status ke S3 atau FSx dan dapat dilanjutkan dari pos pemeriksaan terakhir setelah kehilangan node.
-
Inferensi batch dan offline: pekerjaan penilaian skala besar terhadap kumpulan data di mana latensi ujung ke ujung diukur dalam jam, bukan detik.
-
Pemrosesan awal data dan jaringan pipa rekayasa fitur: transformasi paralel pada kumpulan data besar.
-
Evaluasi model dan benchmarking: pekerjaan berulang yang menghasilkan hasil idempoten.
-
Pengembangan, pembuatan prototipe, dan notebook: eksperimen interaktif di mana pengguna dapat mentolerir restart sesekali.
Hindari Spot untuk inferensi real-time yang sensitif terhadap latensi, titik akhir SLA-bound produksi, dan beban kerja yang tidak dapat ditoleransi oleh pos pemeriksaan atau tidak dapat mentolerir restart.
Anda dapat secara eksplisit meminta instans Spot dengan karpenter.sh/capacity-type: spot menyetelnya. NodePool