Panduan praktik terbaik ini menunjukkan metrik yang tersedia dan cara memilih metrik yang sesuai untuk menyiapkan Horizontal Pod Autoscaler (HPA) bagi workload inferensi Anda di GKE. HPA adalah cara yang efisien untuk memastikan server model Anda menskalakan dengan tepat sesuai beban. Menyesuaikan 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 di 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 yang sudah ada, Engineer ML, dan engineer LLMOps (DevOps) yang tertarik untuk mengoptimalkan workload LLM mereka menggunakan GPU dengan Kubernetes.
Setelah membaca panduan ini, Anda akan dapat:
- Memahami metrik penskalaan otomatis untuk inferensi LLM.
- Memahami kompromi tingkat tinggi saat mempertimbangkan metrik yang akan di-autoscaled.
Ringkasan metrik penskalaan otomatis untuk inferensi LLM
Metrik berikut tersedia di GKE:
Metrik server
Server inferensi LLM populer seperti TGI, vLLM, dan NVIDIA Triton memancarkan 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 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 mencakup:
- Ukuran Antrean: Jumlah permintaan yang menunggu pemrosesan dalam antrean server. Gunakan ukuran antrean untuk memaksimalkan throughput dan meminimalkan biaya dalam batas latensi target tertentu. Untuk mempelajari lebih lanjut, lihat bagian praktik terbaik terkait.
- Ukuran Batch: Jumlah permintaan yang menjalani inferensi. Gunakan ukuran batch untuk mencapai batas 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 menjadikannya 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 mencakup:
| Metrik GPU | Penggunaan | Batasan |
|---|---|---|
Penggunaan GPU (DCGM_FI_DEV_GPU_UTIL) |
Mengukur siklus tugas, yaitu jumlah waktu GPU aktif. | Tidak mengukur jumlah pekerjaan yang dilakukan saat GPU aktif. Hal ini menyulitkan pemetaan inferensi berdasarkan metrik performa, seperti latensi dan throughput, ke batas Penggunaan GPU. |
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 mengalokasikan memori GPU terlebih dahulu atau tidak pernah mendealokasikan memori (seperti workload yang berjalan di TGI dan vLLM), metrik ini hanya berfungsi untuk penskalaan, dan tidak akan melakukan penskalaan saat traffic menurun. |
Metrik CPU
Di GKE, HPA berfungsi langsung dengan penskalaan otomatis berbasis CPU dan memori. Untuk workload yang berjalan di CPU, metrik penggunaan CPU dan memori biasanya merupakan metrik penskalaan otomatis utama.
Untuk workload inferensi yang berjalan di GPU, sebaiknya jangan gunakan penggunaan CPU dan memori sebagai satu-satunya indikator jumlah resource yang digunakan tugas karena workload inferensi terutama bergantung pada resource GPU. Oleh karena itu, menggunakan metrik CPU saja 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 maksimum server model Anda.
Ukuran antrean berkorelasi langsung dengan latensi permintaan. Permintaan masuk mengantre di server model sebelum diproses, dan waktu antrean ini 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 beban meningkat, dan melakukan penskalaan 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 tetap memperhatikan konfigurasi server model Anda. Ukuran antrean melacak permintaan yang tertunda, bukan yang sedang diproses. vLLM dan TGI menggunakan batching berkelanjutan, yang memaksimalkan permintaan serentak dan menjaga antrean tetap rendah saat ruang batch tersedia. Antrean akan bertambah secara signifikan 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 batas 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 batas di bawah 10, sesuaikan setelan penskalaan 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 batasnya tidak dapat menjamin latensi yang lebih rendah daripada yang diizinkan oleh ukuran batch maksimum. Sebagai solusinya, Anda dapat mengurangi ukuran batch maksimum secara manual atau melakukan penskalaan otomatis pada ukuran batch.
Praktik terbaik: Gunakan ukuran batch untuk mencapai batas latensi target yang lebih rendah daripada ukuran antrean
Sebaiknya pilih penskalaan otomatis berbasis ukuran batch 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 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, semakin besar ukuran batch, semakin tinggi latensinya. Penskalaan otomatis pada ukuran batch memastikan workload Anda melakukan penskalaan untuk memaksimalkan jumlah permintaan yang diproses secara paralel sekaligus, dan melakukan penskalaan saat ada lebih sedikit permintaan yang diproses secara paralel.
Jika ukuran antrean sudah memenuhi target latensi Anda, prioritaskan untuk penskalaan otomatis. Hal ini memaksimalkan throughput dan efisiensi biaya. Namun, ukuran batch sangat berharga untuk workload yang sensitif terhadap latensi. Ukuran batch yang lebih besar meningkatkan throughput, tetapi juga meningkatkan latensi karena fase pengisian awal 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 menggabungkannya dengan penskalaan otomatis berbasis antrean.
Menentukan nilai batas ukuran batch yang optimal untuk HPA
Perhatikan toleransi HPA, yang merupakan rentang tanpa tindakan 0,1 default di sekitar nilai target untuk meredam osilasi.
Untuk memilih batas ukuran batch yang tepat, tingkatkan beban di server Anda secara eksperimental dan amati di mana ukuran batch mencapai puncaknya. Sebaiknya gunakan alat
locust-load-inference untuk pengujian. Setelah 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 dan batasan hardware yang bervariasi membuat penentuan batas 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 penurunan skala (menghindari penurunan skala prematur) dan 0 untuk penskalaan (memastikan responsivitas). Sesuaikan nilai berdasarkan volatilitas workload dan responsivitas yang Anda inginkan.
- Kebijakan penskalaan: Gunakan opsi konfigurasi HPA ini untuk menyesuaikan perilaku peningkatan dan penurunan skala. Anda dapat menetapkan batas kebijakan "Pod" untuk menentukan jumlah replika absolut yang diubah per unit waktu, dan batas kebijakan "Persen" untuk menentukan berdasarkan perubahan persentase.
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.