Panduan praktik terbaik ini menunjukkan metrik yang tersedia dan cara memilih metrik yang sesuai untuk menyiapkan Horizontal Pod Autoscaler (HPA) untuk beban kerja inferensi di GKE. HPA adalah cara yang efisien untuk memastikan server model Anda diskalakan 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.
Untuk contoh cara menerapkan praktik terbaik ini, lihat Mengonfigurasi penskalaan otomatis untuk workload LLM di GPU dengan GKE.
Tujuan
Panduan ini ditujukan untuk pelanggan AI generatif, pengguna GKE baru atau lama, Engineer ML, dan engineer LLMOps (DevOps) yang tertarik untuk mengoptimalkan beban kerja LLM mereka menggunakan GPU dengan Kubernetes.
Setelah membaca panduan ini, Anda akan dapat:
- Memahami metrik penskalaan otomatis untuk inferensi LLM.
- Pahami konsekuensi tingkat tinggi saat mempertimbangkan metrik yang akan diskalakan secara 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 beban kerja. GKE menyederhanakan scraping dan penskalaan otomatis workload berdasarkan metrik tingkat server ini. Anda dapat menggunakan metrik ini untuk mendapatkan visibilitas tentang 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 utama tingkat server 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 latensi target tertentu. Untuk mempelajari lebih lanjut, lihat bagian praktik terbaik terkait.
- Ukuran Batch: Jumlah permintaan yang 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 menjadikannya titik awal yang andal untuk penskalaan otomatis di berbagai konfigurasi hardware GPU.
Metrik GPU
GPU memunculkan berbagai metrik penggunaan dan performa, yang menawarkan penskalaan otomatis agnostik beban kerja untuk tugas berbasis GPU apa pun, termasuk inferensi beban kerja 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 |
|---|---|---|
Pemakaian 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 metrik performa berbasis inferensi, seperti latensi dan throughput, ke nilai minimum 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 sebelumnya atau tidak pernah mengalokasikan ulang memori (seperti workload yang berjalan di TGI dan vLLM), metrik ini hanya berfungsi untuk penskalaan ke atas, dan tidak akan diskalakan ke bawah saat traffic menurun. |
Metrik CPU
Di GKE, HPA berfungsi secara otomatis dengan penskalaan otomatis berbasis CPU dan memori. Untuk beban kerja 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 mengandalkan 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, dan saat target latensi dapat dicapai dengan throughput maksimum ukuran batch maksimum server model Anda.
Ukuran antrean berkorelasi langsung dengan latensi permintaan. Permintaan masuk akan diantrekan di server model sebelum diproses, dan waktu antrean ini akan menambah latensi secara keseluruhan. Ukuran antrean adalah indikator sensitif lonjakan beban, karena peningkatan beban dengan cepat mengisi antrean.
Penskalaan otomatis berdasarkan ukuran antrean meminimalkan waktu antrean dengan menskalakan ke atas saat beban tinggi, dan menskalakan ke bawah saat antrean kosong. Pendekatan ini relatif mudah diterapkan dan sebagian besar tidak bergantung pada beban kerja, karena ukuran antrean tidak bergantung pada ukuran permintaan, model, atau hardware.
Pertimbangkan untuk berfokus pada ukuran antrean jika Anda ingin memaksimalkan throughput sekaligus mematuhi konfigurasi server model Anda. Ukuran antrean melacak permintaan yang tertunda, bukan yang sedang diproses. vLLM dan TGI menggunakan pengelompokan batch berkelanjutan, yang memaksimalkan permintaan serentak dan menjaga antrean tetap rendah saat ruang batch tersedia. Antrean akan bertambah secara signifikan jika 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 nilai minimum ukuran antrean yang optimal untuk HPA
Perhatikan toleransi HPA, yang secara default ditetapkan ke 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 penskalaan HPA untuk menangani lonjakan traffic.
Anda juga dapat membuat dasbor kustom Cloud Monitoring untuk memvisualisasikan perilaku metrik.
Batasan
Ukuran antrean tidak mengontrol permintaan serentak secara langsung, sehingga nilai minimumnya tidak dapat memastikan latensi yang lebih rendah daripada yang diizinkan ukuran batch maksimum. Sebagai solusi, Anda dapat mengurangi ukuran batch maksimum secara manual atau penskalaan otomatis pada ukuran batch.
Praktik terbaik: Gunakan ukuran batch untuk mencapai nilai minimum latensi target yang lebih rendah daripada ukuran antrean
Sebaiknya pilih penskalaan otomatis berbasis ukuran batch jika Anda memiliki workload sensitif latensi dengan penskalaan berbasis antrean yang 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, semakin besar ukuran batch, semakin tinggi latensinya. Penskalaan otomatis pada ukuran batch memastikan bahwa workload Anda diskalakan untuk memaksimalkan jumlah permintaan yang diproses secara paralel sekaligus, dan diskalakan ke bawah 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 beban kerja yang sensitif terhadap latensi. Ukuran batch yang lebih besar meningkatkan throughput, tetapi juga meningkatkan latensi karena fase pra-pengisian beberapa permintaan mengganggu fase dekode permintaan lainnya di server model pengelompokan 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 nilai minimum 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 batch yang tepat, tingkatkan beban secara eksperimental di
server Anda dan amati titik puncak ukuran batch. Sebaiknya gunakan juga 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 membantu untuk kontrol latensi, memiliki batasan. Ukuran permintaan dan batasan hardware yang bervariasi membuat menemukan 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 akibat metrik yang berfluktuasi. Defaultnya adalah 5 menit untuk penurunan skala (menghindari penurunan skala yang terlalu dini) dan 0 untuk peningkatan skala (memastikan responsivitas). Sesuaikan nilai berdasarkan volatilitas workload dan responsivitas yang Anda inginkan.
- Kebijakan penskalaan: Gunakan opsi konfigurasi HPA ini untuk menyesuaikan perilaku penskalaan ke atas dan penskalaan ke bawah. Anda dapat menetapkan batas kebijakan "Pod" untuk menentukan jumlah absolut replika 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 selanjutnya
- Pelajari cara Mengonfigurasi penskalaan otomatis untuk workload LLM di GPU.