Panduan praktik terbaik ini menunjukkan metrik yang tersedia dan cara memilih metrik yang sesuai untuk menyiapkan Horizontal Pod Autoscaler (HPA) untuk workload inferensi Anda di GKE. HPA adalah cara yang efisien untuk memastikan server model Anda diskalakan dengan tepat sesuai dengan beban. Penyesuaian setelan HPA adalah cara utama untuk menyelaraskan biaya hardware yang disediakan dengan permintaan traffic guna mencapai sasaran performa server inferensi Anda.
Untuk contoh cara menerapkan praktik terbaik ini, lihat Mengonfigurasi penskalaan otomatis untuk workload LLM pada GPU dengan GKE.
Untuk ringkasan gabungan semua praktik terbaik GKE, lihat Praktik terbaik untuk GKE.Tujuan
Panduan ini ditujukan untuk pelanggan AI generatif, pengguna GKE baru atau lama, Engineer ML, dan engineer LLMOps (DevOps) yang tertarik untuk mengoptimalkan workload LLM mereka menggunakan GPU dengan Kubernetes.
Setelah membaca panduan ini, Anda akan dapat:
- Pahami metrik penskalaan otomatis untuk inferensi LLM.
- Memahami konsekuensi tingkat tinggi saat mempertimbangkan metrik yang akan digunakan untuk penskalaan otomatis.
Ringkasan metrik penskalaan otomatis untuk inferensi LLM
Metrik berikut tersedia di GKE:
Metrik server
Server inferensi LLM populer seperti TGI, vLLM, dan NVIDIA Triton memunculkan metrik performa khusus workload. GKE menyederhanakan scraping dan penskalaan otomatis workload berdasarkan metrik tingkat server ini. Anda dapat menggunakan metrik ini untuk mendapatkan visibilitas ke dalam indikator performa seperti ukuran batch, ukuran antrean, dan latensi dekode.
Berdasarkan metrik ini, Anda dapat mengarahkan penskalaan otomatis pada indikator performa yang paling relevan. Metrik tingkat server utama untuk penskalaan otomatis meliputi:
- Ukuran Antrean: Jumlah permintaan yang menunggu pemrosesan di antrean server. Gunakan ukuran antrean untuk memaksimalkan throughput dan meminimalkan biaya dalam batas target latensi tertentu. Untuk mempelajari lebih lanjut, lihat bagian praktik terbaik terkait.
- Ukuran Batch: Jumlah permintaan yang sedang menjalani inferensi. Gunakan ukuran batch untuk mencapai nilai minimum latensi target yang lebih rendah daripada ukuran antrean. Untuk mempelajari lebih lanjut, lihat bagian praktik terbaik terkait.
Metrik ini sering kali tahan terhadap fluktuasi performa dan traffic, sehingga menjadi titik awal yang andal untuk penskalaan otomatis di berbagai penyiapan hardware GPU.
Metrik GPU
GPU memancarkan berbagai metrik penggunaan dan performa, yang menawarkan penskalaan otomatis yang tidak bergantung pada workload untuk tugas berbasis GPU apa pun, termasuk workload inferensi yang tidak memiliki metrik kustom. Untuk mempelajari cara menyiapkan pengumpulan DCGM, lihat Mengonfigurasi pengumpulan DCGM.
Metrik GPU umum untuk GKE meliputi:
| Metrik GPU | Penggunaan | Batasan |
|---|---|---|
Penggunaan GPU (DCGM_FI_DEV_GPU_UTIL) |
Mengukur siklus tugas, yaitu jumlah waktu GPU aktif. | Tidak mengukur seberapa banyak pekerjaan yang dilakukan saat GPU aktif. Hal ini menyulitkan pemetaan metrik performa berbasis inferensi, seperti latensi dan throughput, ke nilai minimum GPU Utilization. |
Penggunaan Memori GPU (DCGM_FI_DEV_FB_USED) |
Mengukur jumlah memori GPU yang digunakan pada waktu tertentu. Hal ini berguna untuk workload yang menerapkan alokasi memori GPU dinamis. | Untuk workload yang melakukan pra-alokasi memori GPU atau tidak pernah membatalkan alokasi memori (seperti workload yang berjalan di TGI dan vLLM), metrik ini hanya berfungsi untuk peningkatan skala, dan tidak akan memperkecil skala saat traffic menurun. |
Metrik CPU
Di GKE, HPA berfungsi langsung dengan penskalaan otomatis berbasis CPU dan memori. Untuk workload yang berjalan di CPU, metrik pemakaian CPU dan memori biasanya merupakan metrik penskalaan otomatis utama.
Untuk workload inferensi yang berjalan di GPU, kami tidak merekomendasikan pemanfaatan CPU dan memori sebagai satu-satunya indikator jumlah resource yang digunakan oleh tugas karena workload inferensi terutama mengandalkan resource GPU. Oleh karena itu, hanya menggunakan metrik CPU untuk penskalaan otomatis dapat menyebabkan performa dan biaya yang kurang optimal.
Pertimbangan untuk memilih metrik penskalaan otomatis
Gunakan pertimbangan dan praktik terbaik berikut untuk memilih metrik terbaik untuk penskalaan otomatis di GKE guna memenuhi sasaran performa workload inferensi Anda.
Praktik terbaik: Gunakan ukuran antrean untuk memaksimalkan throughput dan meminimalkan biaya dalam batas latensi target tertentu
Sebaiknya gunakan penskalaan otomatis ukuran antrean saat mengoptimalkan throughput dan biaya, serta saat target latensi Anda dapat dicapai dengan throughput maksimum ukuran batch maks server model Anda.
Ukuran antrean berkorelasi langsung dengan latensi permintaan. Permintaan yang masuk akan mengantre di server model sebelum diproses, dan waktu antrean ini akan menambah latensi keseluruhan. Ukuran antrean adalah indikator sensitif lonjakan beban, karena peningkatan beban akan dengan cepat mengisi antrean.
Penskalaan otomatis berdasarkan ukuran antrean meminimalkan waktu antrean dengan melakukan penskalaan saat ada beban, dan memperkecil skala saat antrean kosong. Pendekatan ini relatif mudah diterapkan dan sebagian besar tidak bergantung pada workload, karena ukuran antrean tidak bergantung pada ukuran permintaan, model, atau hardware.
Pertimbangkan untuk berfokus pada ukuran antrean jika Anda ingin memaksimalkan throughput sambil memperhatikan konfigurasi server model Anda. Ukuran antrean melacak permintaan yang tertunda, bukan permintaan yang sedang diproses. vLLM dan TGI menggunakan batch berkelanjutan, yang memaksimalkan permintaan serentak dan menjaga antrean tetap rendah saat ruang batch tersedia. Antrean akan bertambah besar saat ruang batch terbatas, jadi gunakan titik pertumbuhan sebagai sinyal untuk memulai penskalaan. Dengan menggabungkan penskalaan otomatis ukuran antrean dengan throughput batch yang dioptimalkan, Anda dapat memaksimalkan throughput permintaan.
Menentukan nilai batas ukuran antrean yang optimal untuk HPA
Perhatikan toleransi HPA, yang secara default adalah rentang tanpa tindakan 0,1 di sekitar nilai target untuk meredam osilasi.
Untuk memilih nilai minimum ukuran antrean yang benar, mulailah dengan nilai antara 3-5 dan
tingkatkan secara bertahap hingga permintaan mencapai latensi yang diinginkan. Gunakan alat
locust-load-inference untuk pengujian. Untuk nilai minimum di bawah 10,
sesuaikan setelan peningkatan skala HPA untuk menangani lonjakan traffic.
Anda juga dapat membuat dasbor kustom Cloud Monitoring untuk memvisualisasikan perilaku metrik.
Batasan
Ukuran antrean tidak secara langsung mengontrol permintaan serentak, sehingga nilai minimumnya tidak dapat menjamin latensi yang lebih rendah daripada yang diizinkan oleh ukuran batch maksimum. Sebagai solusi, Anda dapat mengurangi ukuran batch maksimum secara manual atau melakukan penskalaan otomatis pada ukuran batch.
Praktik terbaik: Gunakan ukuran tumpukan untuk mencapai nilai minimum latensi target yang lebih rendah daripada ukuran antrean
Sebaiknya pilih penskalaan otomatis berbasis ukuran tumpukan jika Anda memiliki workload yang sensitif terhadap latensi, dan penskalaan berbasis antrean tidak cukup cepat untuk memenuhi persyaratan Anda.
Ukuran batch berkorelasi langsung dengan throughput dan latensi permintaan yang masuk. Ukuran batch adalah indikator yang baik untuk lonjakan beban, karena peningkatan beban menyebabkan lebih banyak permintaan ditambahkan ke batch yang ada, sehingga menyebabkan ukuran batch yang lebih besar. Secara umum, makin besar ukuran tumpukan, makin tinggi latensinya. Penskalaan otomatis pada ukuran batch memastikan workload Anda melakukan penskalaan untuk memaksimalkan jumlah permintaan yang diproses secara paralel sekaligus, dan memperkecil skala saat jumlah permintaan yang diproses secara paralel lebih sedikit.
Jika ukuran antrean sudah memenuhi target latensi Anda, prioritaskan untuk penskalaan otomatis. Hal ini memaksimalkan throughput dan efisiensi biaya. Namun, ukuran batch sangat berguna untuk beban kerja yang sensitif terhadap latensi. Ukuran tumpukan yang lebih besar meningkatkan throughput, tetapi juga meningkatkan latensi karena fase pra-pengisian beberapa permintaan mengganggu fase dekode permintaan lainnya di server model batching berkelanjutan. Anda dapat memantau pola ukuran batch dan menggunakan penskalaan otomatis untuk meminimalkan permintaan serentak selama lonjakan beban.
Jika server model Anda mengizinkan, sebaiknya sesuaikan ukuran batch maksimum sebagai mekanisme penyesuaian tambahan. Anda juga dapat memasangkannya dengan penskalaan otomatis berbasis antrean.
Menentukan nilai batas ukuran batch yang optimal untuk HPA
Perhatikan toleransi HPA, yang merupakan rentang tanpa tindakan default 0,1 di sekitar nilai target untuk meredam osilasi.
Untuk memilih nilai minimum ukuran tumpukan yang tepat, tingkatkan beban di server Anda secara eksperimental dan amati di mana ukuran tumpukan mencapai puncaknya. Sebaiknya gunakan alat
locust-load-inference untuk pengujian. Setelah Anda mengidentifikasi ukuran batch maksimum, tetapkan nilai target awal sedikit di bawah maksimum ini dan kurangi hingga latensi yang diinginkan tercapai.
Anda juga dapat membuat dasbor kustom Cloud Monitoring untuk memvisualisasikan perilaku metrik.
Batasan
Penskalaan otomatis pada ukuran batch, meskipun berguna untuk kontrol latensi, memiliki batasan. Ukuran permintaan yang bervariasi dan batasan hardware membuat penentuan nilai minimum ukuran batch yang tepat menjadi sulit.
Praktik terbaik: Mengoptimalkan konfigurasi HPA
Sebaiknya tetapkan opsi konfigurasi HPA berikut:
- Jendela stabilisasi: Gunakan opsi konfigurasi HPA ini untuk mencegah perubahan jumlah replika yang cepat karena metrik yang berfluktuasi. Nilai defaultnya adalah 5 menit untuk perkecil skala (untuk menghindari penyusutan prematur) dan 0 untuk penskalaan (untuk memastikan responsivitas). Sesuaikan nilai berdasarkan volatilitas workload dan responsivitas yang Anda inginkan.
- Kebijakan penskalaan: Gunakan opsi konfigurasi HPA ini untuk menyesuaikan perilaku penskalaan dan pengecilan. Anda dapat menetapkan batas kebijakan "Pods" untuk menentukan jumlah absolut replika yang diubah per unit waktu, dan batas kebijakan "Percent" untuk menentukan persentase perubahan.
Untuk mempelajari opsi ini lebih lanjut, lihat Penskalaan Otomatis Pod Horizontal dalam dokumentasi Kubernetes open source.
Langkah berikutnya
- Pelajari cara Mengonfigurasi penskalaan otomatis untuk workload LLM di GPU.