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, lihat[SageMaker HyperPod tata kelola tugas](sagemaker-hyperpod-eks-operate-console-ui-governance.md).
## 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](https://kueue.sigs.k8s.io/docs/concepts/cluster_queue/).
**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.
1. **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](https://kueue.sigs.k8s.io/docs/concepts/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
1. **Pelatihan**: Prioritas 75
1. **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
1. **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.
1. **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 **ClusterQueue**ada dengan kuota GPU yang dialokasikan untuk tim Anda
+ A **LocalQueue**ada di namespace tempat Anda berencana untuk menerapkan titik akhir inferensi Anda
+ Satu atau lebih **PriorityClass**sumber 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
```
### 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-name`Label 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 Anda`InferenceEndpointConfig`: `JumpStartModel`
```
metadata:
name:
namespace:
labels:
kueue.x-k8s.io/queue-name:
kueue.x-k8s.io/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
```
Beban kerja yang berhasil diterima ditampilkan `True` di kolom DITERIMA dan mencantumkan sumber daya ClusterQueue yang dicadangkan di kolom RESERVED IN.
1. Periksa status pod:
```
kubectl get pods -n
```
Setelah masuk, pod secara bertahap bertransisi melalui tahap inisialisasi hingga mencapai `Running` status.
1. Periksa konsumsi kuota:
```
kubectl get clusterqueue -o yaml
```
Tinjau `status` bagian untuk mengonfirmasi konsumsi sumber daya sedang dilacak.
1. Periksa beban kerja LocalQueue yang tertunda:
```
kubectl get localqueue -n
```
Kolom BEBAN KERJA PENDING menunjukkan berapa banyak beban kerja yang menunggu untuk masuk.
1. Lihat acara penerimaan Kueue:
```
kubectl describe workload -n
```
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 ditampilkan`Admitted: False`) atau tingkat penjadwal Kubernetes (beban kerja diterima tetapi pod tidak dapat dijadwalkan).