View a markdown version of this page

Tata kelola tugas untuk penerapan model HyperPod - Amazon SageMaker AI

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Tata kelola tugas untuk penerapan model HyperPod

Bagian ini mencakup cara mengoptimalkan kluster Amazon SageMaker HyperPod EKS bersama Anda untuk beban kerja inferensi waktu nyata. Anda akan belajar mengonfigurasi fitur tata kelola tugas Kueue — termasuk manajemen kuota, penjadwalan prioritas, dan kebijakan berbagi sumber daya — untuk memastikan beban kerja inferensi Anda mendapatkan sumber daya GPU yang mereka butuhkan selama lonjakan lalu lintas sambil mempertahankan alokasi yang adil di seluruh aktivitas pelatihan, evaluasi, dan pengujian tim Anda. Untuk informasi lebih umum tentang tata kelola tugas, lihatSageMaker HyperPod tata kelola tugas.

Bagaimana manajemen beban kerja inferensi bekerja

Untuk secara efektif mengelola lonjakan lalu lintas inferensi real-time di kluster HyperPod EKS bersama, terapkan strategi tata kelola tugas berikut menggunakan kemampuan Kueue yang ada.

Konfigurasi kelas prioritas

Tentukan kelas prioritas khusus untuk beban kerja inferensi dengan bobot tinggi (seperti 100) untuk memastikan pod inferensi diterima dan dijadwalkan sebelum jenis tugas lainnya. Konfigurasi ini memungkinkan beban kerja inferensi untuk mendahului pekerjaan dengan prioritas lebih rendah selama beban klaster, yang sangat penting untuk mempertahankan persyaratan latensi rendah selama lonjakan lalu lintas.

Ukuran dan alokasi kuota

Cadangan sumber daya GPU yang cukup di tim Anda ClusterQueue untuk menangani lonjakan inferensi yang diharapkan. Selama periode lalu lintas inferensi rendah, sumber daya kuota yang tidak digunakan dapat dialokasikan sementara untuk tugas tim lain. Ketika permintaan inferensi meningkat, sumber daya yang dipinjam ini dapat direklamasi untuk memprioritaskan pod inferensi yang tertunda. Untuk informasi selengkapnya, lihat Antrian Kluster.

Strategi Berbagi Sumber Daya

Pilih di antara dua pendekatan pembagian kuota berdasarkan kebutuhan Anda:

  1. Kontrol Sumber Daya yang Ketat: Nonaktifkan peminjaman kuota dan pinjaman untuk menjamin kapasitas GPU cadangan selalu tersedia untuk beban kerja Anda. Pendekatan ini membutuhkan kuota ukuran yang cukup besar untuk menangani permintaan puncak secara independen dan dapat mengakibatkan node menganggur selama periode lalu lintas rendah.

  2. Berbagi Sumber Daya Fleksibel: Aktifkan peminjaman kuota untuk menggunakan sumber daya idle dari tim lain bila diperlukan. Pod yang dipinjam ditandai sebagai preemptible dan dapat diusir jika tim pemberi pinjaman merebut kembali kapasitas.

Intra-Team Preemption

Aktifkan preemption intra-tim saat menjalankan beban kerja campuran (evaluasi, pelatihan, dan inferensi) di bawah kuota yang sama. Hal ini memungkinkan Kueue untuk mendahului pekerjaan dengan prioritas lebih rendah dalam tim Anda untuk mengakomodasi pod inferensi prioritas tinggi, memastikan inferensi real-time dapat berjalan tanpa bergantung pada pinjaman kuota eksternal. Untuk informasi lebih lanjut, lihat Preemption.

Pengaturan beban kerja inferensi sampel

Contoh berikut menunjukkan bagaimana Kueue mengelola resource GPU di cluster Amazon bersama. SageMaker HyperPod

Konfigurasi klaster dan pengaturan kebijakan

Cluster Anda memiliki konfigurasi berikut:

  • Tim A: Kuota GPU 10 P4

  • Tim B: 20 kuota GPU P4

  • Penyediaan statis: Tidak ada penskalaan otomatis

  • Total kapasitas: 30 GPU P4

Kumpulan GPU bersama menggunakan kebijakan prioritas ini:

  1. Real-time inferensi: Prioritas 100

  2. Pelatihan: Prioritas 75

  3. Evaluasi: Prioritas 50

Kueue memberlakukan kuota tim dan kelas prioritas, dengan preemption dan peminjaman kuota diaktifkan.

Keadaan awal: Pemanfaatan cluster normal

Dalam operasi normal:

  • Tim A menjalankan pekerjaan pelatihan dan evaluasi pada semua 10 GPU P4

  • Tim B menjalankan inferensi real-time (10 P4) dan evaluasi (10 P4) dalam kuota 20 GPU-nya

  • Cluster ini sepenuhnya digunakan dengan semua pekerjaan yang diterima dan berjalan

Lonjakan inferensi: Tim B membutuhkan GPU tambahan

Saat Tim B mengalami lonjakan lalu lintas, pod inferensi tambahan membutuhkan 5 GPU P4 lagi. Kueue mendeteksi bahwa pod baru adalah:

  • Dalam namespace Tim B

  • Prioritas 100 (inferensi waktu nyata)

  • Penerimaan tertunda karena kendala kuota

Proses respons Kueue memilih di antara dua opsi:

Opsi 1: Peminjaman kuota - Jika Tim A hanya menggunakan 6 dari 10 P4, Kueue dapat menerima pod Tim B menggunakan 4 P4 idle. Namun, sumber daya yang dipinjam ini dapat didahulukan—jika Tim A mengirimkan pekerjaan untuk mencapai kuota penuhnya, Kueue akan mengusir pod inferensi pinjaman Tim B.

Opsi 2: Self-preemption (Disarankan) - Tim B menjalankan pekerjaan evaluasi prioritas rendah (prioritas 50). Saat pod inferensi prioritas tinggi menunggu, Kueue mendahului pekerjaan evaluasi dalam kuota Tim B dan menerima pod inferensi. Pendekatan ini menyediakan alokasi sumber daya yang aman tanpa risiko penggusuran eksternal.

Kueue mengikuti proses tiga langkah untuk mengalokasikan sumber daya:

  1. Cek kuota

    Pertanyaan: Apakah Tim B memiliki kuota yang tidak terpakai?

    • Ya → Akui pod

    • Tidak → Lanjutkan ke Langkah 2

  2. Self-preemption dalam Tim B

    Pertanyaan: Bisakah pekerjaan Tim B dengan prioritas lebih rendah didahului?

    • Ya → Pekerjaan evaluasi pendahuluan (prioritas 50), gratis 5 P4, dan akui pod inferensi

    • Tidak → Lanjutkan ke Langkah 3

    Pendekatan ini menjaga beban kerja dalam kuota terjamin Tim B, menghindari risiko penggusuran eksternal.

  3. Meminjam dari tim lain

    Pertanyaan: Apakah ada kuota idle dan dapat dipinjam dari tim lain?

    • Ya → Akui menggunakan kuota pinjaman (ditandai sebagai preemptible)

    • Tidak → Pod tetap dalam NotAdmitted status

Mengkonfigurasi tata kelola tugas untuk beban kerja inferensi

Untuk mengintegrasikan beban kerja inferensi Anda dengan Kueue, tambahkan label tata kelola tugas ke CRD Anda. InferenceEndpointConfig JumpStartModel Label ini menentukan mana yang LocalQueue menerima beban kerja untuk manajemen kuota dan menentukan prioritas penjadwalan yang digunakan dalam keputusan preemption. Bagian berikut mencakup prasyarat, pelingkupan sumber daya, konfigurasi label, dan langkah-langkah verifikasi.

Prasyarat

Sebelum mengonfigurasi tata kelola tugas untuk beban kerja inferensi, pastikan sumber daya berikut ada di klaster Anda: HyperPod

  • Kueue diinstal dan berjalan di cluster Anda

  • A ClusterQueueada dengan kuota GPU yang dialokasikan untuk tim Anda

  • A LocalQueueada di namespace tempat Anda berencana untuk menerapkan titik akhir inferensi Anda

  • Satu atau lebih PriorityClasssumber daya didefinisikan untuk jenis beban kerja (seperti inferensi, pelatihan, evaluasi)

Untuk memverifikasi sumber daya ini tersedia, jalankan perintah berikut:

# Verify Kueue is installed kubectl get crd | grep kueue # List available PriorityClasses kubectl get priorityclass # List ClusterQueues kubectl get clusterqueue # List LocalQueues in your namespace kubectl get localqueue -n <your-namespace>

Memahami pelingkupan sumber daya

Sumber daya tata kelola tugas memiliki cakupan berbeda yang memengaruhi cara Anda mengonfigurasi label penerapan inferensi.

kueue.x-k8s.io/queue-nameLabel harus mereferensikan a LocalQueue yang ada di namespace yang sama dengan nama Anda InferenceEndpointConfig atau. JumpStartModel Jika tidak LocalQueue ada kecocokan yang ditemukan di namespace itu, beban kerja tidak akan diterima oleh Kueue.

ClusterQueue, ResourceFlavor, dan PriorityClass memiliki cakupan cluster dan dapat diakses dari namespace apa pun.

Untuk memverifikasi pelingkupan sumber daya di klaster Anda:

kubectl api-resources | grep kueue

Menambahkan label tata kelola tugas

Untuk mengaktifkan tata kelola tugas untuk penerapan inferensi Anda, tambahkan label berikut ke metadata bagian CRD atau AndaInferenceEndpointConfig: JumpStartModel

metadata: name: <your-deployment-name> namespace: <your-namespace> labels: kueue.x-k8s.io/queue-name: <your-localqueue-name> kueue.x-k8s.io/priority-class: <your-priority-class>

Deskripsi label:

  • kueue.x-k8s.io/queue-name— Rutekan beban kerja ke tim Anda untuk LocalQueue pelacakan kuota. Harus cocok dengan LocalQueue nama di namespace yang sama dengan beban kerja.

  • kueue.x-k8s.io/priority-class— Menetapkan prioritas penjadwalan untuk keputusan preemption. Referensi cluster yang dicakup oleh nama PriorityClass .

Memverifikasi konfigurasi tata kelola tugas

Setelah menerapkan label tata kelola tugas Anda InferenceEndpointConfig atau JumpStartModel dengan, verifikasi bahwa Kueue mengakui beban kerja dan pod dijadwalkan dengan benar.

Untuk memverifikasi tata kelola tugas berfungsi
  1. Periksa status penerimaan beban kerja:

    kubectl get workloads -n <namespace>

    Beban kerja yang berhasil diterima ditampilkan True di kolom DITERIMA dan mencantumkan sumber daya ClusterQueue yang dicadangkan di kolom RESERVED IN.

  2. Periksa status pod:

    kubectl get pods -n <namespace>

    Setelah masuk, pod secara bertahap bertransisi melalui tahap inisialisasi hingga mencapai Running status.

  3. Periksa konsumsi kuota:

    kubectl get clusterqueue <clusterqueue-name> -o yaml

    Tinjau status bagian untuk mengonfirmasi konsumsi sumber daya sedang dilacak.

  4. Periksa beban kerja LocalQueue yang tertunda:

    kubectl get localqueue -n <namespace>

    Kolom BEBAN KERJA PENDING menunjukkan berapa banyak beban kerja yang menunggu untuk masuk.

  5. Lihat acara penerimaan Kueue:

    kubectl describe workload <workload-name> -n <namespace>

    Tinjau bagian Acara untuk keputusan penerimaan dan kesalahan apa pun.

Jika pod tetap dalam Pending status, tentukan apakah masalahnya ada pada tingkat penerimaan Kueue (beban kerja ditampilkanAdmitted: False) atau tingkat penjadwal Kubernetes (beban kerja diterima tetapi pod tidak dapat dijadwalkan).