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 yang dipercepat untuk AI/ML beban kerja di Amazon EKS
Tip
Daftar
Bagian ini membahas cara membeli dan menyediakan instans komputasi yang dipercepat EC2 untuk beban kerja AI/ML pelatihan dan inferensi dengan Amazon EKS. Baik Anda melatih model skala besar, menjalankan inferensi waktu nyata, atau menerapkan aplikasi AI generatif, menggunakan GPU NVIDIA atau kapasitas AWS Trainium yang tepat adalah dasar untuk kinerja beban kerja Anda.
Pilih dari jenis instans EC2
Lihat Spesifikasi instans komputasi akselerasi Amazon EC2 untuk detail tentang instans komputasi akselerasi Amazon EC2 yang tersedia. Ini termasuk instans GPU NVIDIA dari P-family dan G-family, serta akselerator yang AWS dirancang Trainium dan Inferentia.
Memahami opsi pembelian EC2
Setelah mengetahui instans yang dipercepat yang Anda butuhkan untuk beban kerja Anda, langkah selanjutnya adalah memahami opsi pembelian yang tersedia untuk memperoleh jenis instans yang dipercepat ini. AWS menawarkan empat opsi pembelian kapasitas komputasi: On-Demand Instans, Instans Spot, Blok Kapasitas untuk ML, dan Pemesanan On-Demand Kapasitas (ODCR). Setiap opsi melayani pola beban kerja yang berbeda, profil biaya, dan persyaratan ketersediaan. Dokumentasi Opsi Pembelian Instans Amazon EC2 menjelaskan cara kerja setiap opsi, model harga, dan kapan menggunakannya.
-
On-Demand Contoh: Bayar per detik tanpa komitmen dan ketersediaan segera ketika kapasitas ada. Terbaik untuk pengembangan, pembuatan prototipe, penskalaan inferensi yang tidak dapat diprediksi, dan beban kerja apa pun yang membutuhkan komputasi segera tanpa risiko gangguan.
-
Instans Spot: Penghematan hingga 90% dibandingkan On-Demand dengan menggunakan kapasitas EC2 cadangan, dengan pemberitahuan interupsi 2 menit. Terbaik untuk beban kerja toleran kesalahan yang memeriksa penyimpanan yang tahan lama: penyetelan hiperparameter, pelatihan terdistribusi dengan pos pemeriksaan berkala, inferensi batch dan offline, dan jalur pipa pra-pemrosesan data.
-
Blok Kapasitas untuk ML: Instans cadangan P-family dan Trainium untuk jendela tetap (24 jam, hingga 6 bulan), dipesan hingga 8 minggu sebelumnya dengan ketersediaan terjamin. Terbaik untuk menjalankan pelatihan skala besar yang direncanakan, eksperimen fine-tuning terikat waktu, dan proyek penelitian dengan jadwal yang diketahui yang memerlukan akses tanpa gangguan ke cluster GPU.
-
On-Demand Reservasi Kapasitas (ODCR): Cadangan kapasitas yang dipercepat di Zona Ketersediaan tertentu tanpa komitmen jangka panjang, ditagih dengan On-Demand tarif standar apakah kapasitas digunakan atau tidak. Terbaik untuk inferensi produksi, SLA-bound layanan, dan aplikasi penting bisnis di mana penundaan penjadwalan atau ketidaktersediaan kapasitas tidak dapat diterima. Tidak seperti Blok Kapasitas, ODCR mendukung keduanya P-family dan G-family instance.
Cocokkan opsi pembelian dengan persyaratan beban kerja
Sekarang setelah Anda memahami jenis instans yang dipercepat dan opsi pembelian, langkah selanjutnya adalah mencocokkan opsi pembelian yang tepat dengan persyaratan khusus beban kerja Anda. Beban kerja dengan fleksibilitas yang lebih besar di seluruh jenis instans, wilayah, dan waktu memenuhi syarat untuk opsi pembelian lebih banyak dan harga yang lebih rendah.
Dasarkan keputusan Anda pada faktor-faktor seperti:
-
Kepentingan strategis dan komitmen SLA
-
Permintaan prediktabilitas dan fleksibilitas penjadwalan
-
Kesediaan untuk berkomitmen pada kapasitas cadangan terlebih dahulu
-
Fleksibilitas di seluruh jenis instans, wilayah, dan waktu
-
Toleransi untuk interupsi versus penghematan biaya
Dalam praktiknya, tim mengadopsi pendekatan hibrida yang menggabungkan beberapa opsi pembelian untuk menyeimbangkan biaya, ketersediaan, dan keandalan di seluruh portofolio beban kerja mereka. Artikel Cara Mendapatkan Kapasitas GPU AWS
Verifikasi kuota layanan EC2 Anda
Sebelum menerapkan opsi pembelian kapasitas apa pun di kluster EKS Anda, verifikasi bahwa AWS akun Anda memiliki kuota vCPU yang cukup untuk keluarga instans GPU yang akan Anda gunakan. Tanpa kuota yang memadai, Karpenter NodePools, penyediaan Mode Otomatis EKS, dan grup node EKS akan gagal meluncurkan node komputasi yang dipercepat terlepas dari opsi pembelian mana yang Anda pilih.
AWS memberlakukan kuota vCPU terpisah per keluarga instance dan model pembelian. Tinjau kuota jenis instans Amazon EC2 untuk memahami kuota default untuk instans komputasi yang dipercepat.
Kuota ini didasarkan pada jumlah vCPU, bukan hitungan instance. Misalnya, meluncurkan 10 instance p6-b300.48xlarge membutuhkan 1.920 vCPU (10 × 192). Kuota GPU default sering disetel ke 0 untuk akun baru, jadi permintaan meningkat sebelum mencoba menerapkan instance.
Jika Anda mengalami batasan kuota saat membuat reservasi Blok Kapasitas, meluncurkan On-Demand instans, atau mengirimkan permintaan Spot, hubungi AWS Support atau tim AWS akun Anda untuk mendiskusikan persyaratan Anda dan jelajahi opsi untuk mengamankan kapasitas komputasi yang dipercepat yang paling sesuai dengan kebutuhan Anda.
Gunakan opsi pembelian EC2 dengan Amazon EKS
Setelah memilih opsi pembelian komputasi dipercepat EC2, konfigurasikan cluster Amazon EKS Anda untuk menggunakan kapasitas. Amazon EKS menyediakan tiga metode penyediaan, masing-masing dengan keseimbangan kontrol dan otomatisasi yang berbeda:
-
Mode Otomatis Amazon EKS: komputasi AWS terkelola yang secara otomatis menyediakan, menskalakan, dan menambal node. Menggunakan Karpenter bawaan untuk penyediaan dan sistem operasi Bottlerocket dengan driver NVIDIA dan plugin perangkat disertakan. Terbaik bila Anda menginginkan infrastruktur terkelola dengan overhead operasional minimal. Mendukung penyediaan kapasitas statis dan dinamis.
-
Karpenter (dikelola sendiri): Proyek upstream open source yang Anda instal dan operasikan di cluster Amazon EKS Anda. Menyediakan model penyediaan yang sama dengan Mode Otomatis EKS dan Anda memiliki kontrol penuh atas sistem operasi, AMI, penyetelan kernel, dan siklus hidup node. Terbaik untuk tim platform dengan persyaratan yang tidak disediakan oleh Mode Otomatis EKS di luar kotak.
-
Grup node (dikelola dan dikelola sendiri): Didukung oleh EC2 Auto Scaling Groups (ASG), kapasitas ditentukan di muka melalui template peluncuran EC2. Terbaik untuk tim platform dengan grup simpul yang dikelola atau dikelola sendiri EKS yang ada, dan beban kerja pelatihan dengan ukuran yang dapat diprediksi dengan jejak komputasi dipercepat statis yang diketahui.
Halaman di bawah ini mencakup setiap opsi penyediaan secara rinci.
Strategi campuran: menggabungkan opsi pembelian
Adalah umum untuk menggabungkan beberapa opsi pembelian kapasitas dalam satu cluster Amazon EKS. Pendekatan ini mengoptimalkan biaya, ketersediaan, dan keandalan secara bersamaan dengan merutekan beban kerja yang berbeda ke sumber kapasitas yang paling tepat. Pelanggan menerapkan strategi hybrid ini menggunakan salah satu dari tiga pendekatan manajemen komputasi EKS (EKS Auto Mode, Karpenter, atau Node Groups) atau menggabungkannya dalam cluster yang sama.
EKS Auto Mode dan Karpenter selalu menyediakan kapasitas cadangan (ODCR dan Blok Kapasitas) terlebih dahulu, diikuti oleh Spot atau. On-Demand Anda dapat menggabungkan prioritas penyediaan instance ini dengan menjadwalkan beban kerja penting Anda pada kapasitas terjamin, sambil menjadwalkan beban kerja fleksibel di Spot atau instans. On-Demand Anda mengontrol perutean beban kerja melalui Kubernetes-native penjadwalan primitif: nodeSelector menargetkan jenis kapasitas tertentu, taint dan toleransi mengisolasi node NVIDIA GPU atau AWS Trainium, dan mendistribusikan beban kerja di seluruh Availability Zone untuk ketersediaan tinggi. topologySpreadConstraints
Cluster Amazon EKS yang dirancang dengan baik mengatur komputasi NodePools atau grup node yang dipercepat ke dalam dua kategori, Reserved dan Burst, masing-masing selaras dengan pola beban kerja yang paling sesuai untuk strategi kapasitas. Contohnya dijelaskan di bawah ini.
Cadangan (Kapasitas Terjamin)
Grup A gpu-reserved NodePool atau node menjalankan inferensi produksi dan pelatihan skala besar terjadwal tentang kapasitas cadangan (ODCR dan Blok Kapasitas), memastikan ketersediaan yang terjamin untuk SLA-bound layanan dan pekerjaan komputasi intensif yang direncanakan. Grup ini NodePool atau node melayani titik akhir inferensi waktu nyata, penyajian model produksi, aplikasi penting bisnis yang membutuhkan ketersediaan GPU selalu aktif dengan kinerja yang dapat diprediksi, pelatihan terdistribusi yang direncanakan, eksperimen fine-tuning skala besar, proyek penelitian terikat waktu, dan beban kerja apa pun di mana Anda mengetahui waktu mulai dan durasi sebelumnya.
Burst (Kapasitas Elastis)
Grup A gpu-burst NodePool atau node menjalankan eksperimen, beban kerja ad hoc, dan pemrosesan batch menggunakan instans Spot sebagai tipe kapasitas utama dengan On-Demand fallback, memaksimalkan penghematan biaya untuk beban kerja yang toleran terhadap kesalahan sekaligus memastikan kapasitas saat Spot tidak tersedia. Grup ini NodePool atau node melayani inferensi offline batch, pipeline pra-pemrosesan data, pekerjaan evaluasi model, pengembangan dan pembuatan prototipe, penskalaan inferensi yang tidak dapat diprediksi, sesi debugging berumur pendek, dan beban kerja apa pun yang mengimplementasikan checkpointing dan dapat menangani gangguan Spot atau yang tidak membenarkan reservasi tetapi tidak dapat menunggu jendela yang dipesan. Beban kerja pada grup ini NodePool atau node menerapkan checkpointing dan shutdown yang anggun untuk menangani kehilangan node dalam jendela interupsi Spot 2 menit.
Jenis kapasitas yang diinginkan untuk beban kerja ditentukan menggunakan NodeSelector: karpenter.sh/capacity-type: spot (atau sesuai permintaan, dicadangkan), dan penyediaan berbasis bobot memastikan skala klaster secara efisien di semua kumpulan kapasitas. Arsitektur ini memberi tim fleksibilitas untuk menjalankan beragam AI/ML beban kerja, mulai dari notebook eksperimental hingga inferensi produksi, dalam satu cluster EKS sambil mengoptimalkan biaya.
