Bantu meningkatkan 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 GitHub tautan Edit halaman ini di 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, GPU NVIDIA) untuk pelatihan AI dan beban kerja inferensi menggunakan Mode Otomatis Amazon EKS atau Karpenter yang dikelola sendiri.
EKS Auto Mode dan Karpenter mendukung dua mode penyediaan: penyediaan dinamis dan penyediaan statis. Dengan penyediaan dinamis, Mode Otomatis EKS dan Karpenter menyediakan dan menskalakan instans komputasi yang dipercepat saat beban kerja dijadwalkan di cluster. Dengan penyediaan statis, Mode Otomatis EKS dan Karpenter menyediakan dan mempertahankan jumlah node tetap. Penyediaan dinamis dan statis dapat digunakan dalam cluster yang sama untuk mempertahankan kumpulan kapasitas dasar yang konstan sambil melakukan penskalaan 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 berbeda dalam kepemilikan operasional, API sumber daya, dukungan sistem operasi, penanganan gangguan Spot, dan fleksibilitas konfigurasi.
| Fitur | Mode Otomatis EKS | Self-managed Karpenter |
|---|---|---|
|
Terbaik untuk |
Tim yang lebih memilih infrastruktur terkelola dengan biaya operasional minimal |
Tim yang lebih memilih kontrol penuh atas siklus hidup node, AMI, penyetelan OS, dan tambalan. |
|
Model operasional |
AWS menyediakan dan mengelola pengontrol Karpenter, GPU/Trainium driver, plugin perangkat, tambalan OS, dan penanganan gangguan Spot. |
Anda menginstal dan mengoperasikan pengontrol Karpenter di cluster Anda dan memiliki GPU/Trainium driver, plugin perangkat, siklus hidup AMI, tambalan, dan penanganan gangguan 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 |
Bottlerocket saja. NVIDIA GPU, AWS Trainium, dan dependensi EFA disertakan. |
AL2023, Bottlerocket, Windows, atau AMI Anda sendiri. |
|
Seumur hidup simpul |
Masa pakai node maksimum 21 hari untuk tambalan keamanan. Beban kerja harus mentolerir rotasi node. |
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 wadah cepat |
Tarik paralel SOCI termasuk 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 |
Konfigurasi per antarmuka untuk jenis |
Konfigurasi per 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 |
Sumber terbuka. Anda membayar instans EC2 yang mendasarinya. |
L AI/ML abel terkenal umum
Mode Otomatis EKS dan Karpenter mengekspos label instans 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 menggunakan Karpenter yang dikelola sendiri. karpenter.k8s.aws/
Tabel di bawah ini menunjukkan label yang relevan yang dapat digunakan di NodePools. EKS Auto Mode dan Karpenter juga menerapkan label yang tercantum dalam dokumentasi Karpenter
Label penjadwalan untuk kapasitas yang dicadangkan
Ketika EKS Auto Mode atau Karpenter meluncurkan node ke reservasi, ia menambahkan label berikut. Gunakan mereka dinodeSelector, afinitas simpul, atau NodePool persyaratan untuk merutekan beban kerja.
-
karpenter.sh/capacity-type:reserved,on-demand, atauspot. Menunjukkan kapasitas yang 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"
Hanya node ODCR target (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 checkpointing Anda sesuai dengan jenis reservasi yang mendukung beban kerja Anda.
ODCR
Instance yang diluncurkan ke ODCR tidak ada di 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 karpenter.sh/capacity-type label node dari ke. reserved on-demand Instans tetap berjalan sebagai On-Demand kapasitas standar, dan Pod yang ada terus berjalan tanpa gangguan.
catatan
Pod apa pun yang dijadwalkan dengan ketat tidak nodeSelector: karpenter.sh/capacity-type: reserved akan menjadwalkan ke node jika telah diberi label ulang. Agar beban kerja bertahan dari kedaluwarsa atau pembatalan ODCR, gunakan preferredDuringSchedulingIgnoredDuringExecution pola yang ditunjukkan di atas alih-alih a. nodeSelector
Blok Kapasitas
Tidak seperti ODCR, Blok Kapasitas selalu memiliki waktu akhir, dan EC2 mengakhiri instans Blok Kapasitas 30 menit lebih awal dari waktu akhir (60 menit untuk UltraServer jenis instans). Rencanakan pekerjaan pelatihan dan inferensi untuk menyelesaikan atau menyimpan status sebelum jendela reservasi ditutup. Pod yang menggunakan strict nodeSelector untuk langkah tertentu setelah blok berakhir dan tidak akan capacity-reservation-id men Pending jadwal ulang di tempat lain. Gabungkan checkpointing dengan pola afinitas fleksibel di atas jika Anda memerlukan beban kerja untuk pindah ke kapasitas lain selama masa berakhirnya 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 di Blok Kapasitas 10 menit sebelum EC2 memulai penghentian, sehingga beban kerja memiliki waktu untuk memeriksa dan mematikan dengan lancar.
Kapasitas statis NodePools
EKS Auto Mode dan Karpenter mendukung kapasitas statis NodePools, yang mempertahankan jumlah node tetap terlepas dari permintaan beban kerja. Kumpulan statis menghilangkan penundaan start dingin untuk inferensi sensitif latensi, dan memungkinkan Anda memesan jejak infrastruktur minimum untuk cluster Anda.
Kapasitas statis dikonfigurasi dengan mengatur replicas bidang pada NodePool.
Pertimbangan-pertimbangan
-
Setelah
replicasdiatur pada a NodePool, Anda tidak dapat menghapusnya. Satu NodePool tidak dapat beralih antara penyediaan kapasitas statis dan dinamis. -
Kapasitas statis NodePools tidak dipertimbangkan untuk konsolidasi. Setel
limits.nodesdi atasreplicasuntuk memungkinkan penskalaan sementara selama penyimpangan 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 untuk memesan P-family dan instance Trainium untuk jendela masa depan yang ditentukan. Mereka dibayar di muka, jadi EKS Auto Mode dan Karpenter memodelkannya sebagai gratis dan memprioritaskannya di atas On-Demand dan Spot. 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. Istilah dapat menentukan ID, satu set tag, atau kriteria kecocokan 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 selengkapnya, lihat dokumentasi Karpenter.
On-Demand Reservasi Kapasitas (ODCR)
ODCR menjamin kapasitas dalam 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 instans yang tidak didukung oleh Blok Kapasitas untuk ML. ODCR dibayar di muka, 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, instans tetap berjalan sebagai standar On-Demand. Lihat Perilaku kedaluwarsa reservasi untuk detail.
Untuk menggunakan ODCR dengan Mode Otomatis EKS atau Karpenter, konfigurasikan capacityReservationSelectorTerms dengan ketentuan reservasi kapasitas Anda di. NodeClass Istilah dapat menentukan ID, satu set tag, atau kriteria kecocokan instance untuk dipilih. Saat menentukan tag, itu akan memilih semua reservasi kapasitas yang dapat diakses dari akun dengan tag yang cocok. Saat menentukan kriteria kecocokan instans, ia memilih reservasi berdasarkan perilaku pencocokannya: terbuka (cocok dengan semua instans yang kompatibel) atau ditargetkan (hanya cocok dengan instance yang ditargetkan secara eksplisit). Ini dapat dibatasi lebih lanjut dengan menentukan ID akun pemilik.
Untuk contoh selengkapnya, lihat dokumentasi Karpenter.
On-Demand
On-Demand adalah tipe kapasitas default dan dapat digunakan dengan penyediaan statis atau dinamis di EKS Auto Mode dan Karpenter. Anda dapat secara eksplisit meminta On-Demand instans dengan meny karpenter.sh/capacity-type: on-demand etel di NodePool. Mode Otomatis EKS 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 tahan lama (Amazon S3 atau Amazon EFS) secara berkala sehingga Pod dapat menyimpan status selama jendela pembuangan.
Spot sangat 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 terganggu.
-
Pelatihan terdistribusi dengan checkpoin ting: pekerjaan yang berjalan lama 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.
-
Prapemrosesan data dan saluran rekayasa fitur: transformasi paralel pada kumpulan data besar.
-
Evaluasi model dan pembandingan: pekerjaan berulang yang menghasilkan hasil yang berpotensi.
-
Pengembangan, pembuatan prototipe, dan buku catatan: 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 melakukan checkpoint atau tidak dapat mentolerir restart.
Anda dapat secara eksplisit meminta instans Spot dengan menyet karpenter.sh/capacity-type: spot el instans Anda NodePool.