Panduan praktik terbaik ini menunjukkan metrik yang tersedia dan cara memilih metrik yang sesuai untuk menyiapkan Penskala Otomatis Pod Horizontal (HPA) untuk workload inferensi Anda di GKE. HPA adalah cara yang efisien untuk memastikan bahwa server model Anda diskalakan dengan tepat dengan beban. Menyesuaikan setelan HPA adalah cara utama untuk menyelaraskan biaya perangkat keras yang disediakan dengan permintaan lalu lintas untuk mencapai tujuan inferensi sasaran performa server.
Untuk contoh cara menerapkan praktik terbaik ini, lihat Mengonfigurasi penskalaan otomatis untuk workload LLM pada GPU dengan GKE.
Tujuan
Panduan ini ditujukan untuk pelanggan AI generatif, baik pelanggan baru maupun lama Pengguna GKE, ML Engineer, 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.
- Memahami konsekuensi tingkat tinggi saat mempertimbangkan metrik mana yang harus diskalakan secara otomatis.
Ringkasan metrik penskalaan otomatis untuk inferensi LLM
Metrik berikut tersedia di GKE:
Metrik server
Server inferensi LLM yang populer seperti TGI, vLLM, dan NVIDIA Triton emit metrik performa spesifik per workload. GKE menyederhanakan scraping dan penskalaan otomatis beban kerja berdasarkan metrik tingkat server ini. Anda dapat menggunakan metrik ini untuk mendapatkan visibilitas tentang indikator kinerja seperti ukuran tumpukan, ukuran antrean, dan latensi dekode.
Berdasarkan metrik ini, Anda dapat mengarahkan penskalaan otomatis ke opsi yang paling relevan indikator performa. Metrik tingkat server utama untuk penskalaan otomatis mencakup:
- Ukuran Antrean: Jumlah permintaan yang menunggu diproses 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 tumpukan untuk mencapai batas latensi target yang lebih rendah dari ukuran antrean. Kepada Pelajari lebih lanjut, lihat bagian praktik terbaik terkait.
Metrik ini sering kali tahan terhadap performa dan fluktuasi traffic, menjadikannya titik awal yang andal untuk penskalaan otomatis di beragam GPU pengaturan perangkat keras.
Metrik GPU
GPU menampilkan berbagai metrik penggunaan dan performa, yang menawarkan agnostik workload penskalaan otomatis untuk tugas berbasis GPU, termasuk menginferensi workload yang tidak metrik kustom. Untuk mempelajari cara menyiapkan kumpulan DCGM, lihat Mengonfigurasi kumpulan DCGM.
Metrik GPU umum untuk GKE meliputi:
| Metrik GPU | Penggunaan | Batasan |
|---|---|---|
Pemanfaatan GPU (DCGM_FI_DEV_GPU_UTIL) |
Mengukur siklus tugas, yang merupakan jumlah waktu GPU aktif. | Tidak mengukur berapa banyak pekerjaan yang dilakukan saat GPU aktif. Hal ini mempersulit pemetaan metrik performa berbasis inferensi, seperti sebagai latensi dan throughput, ke batas Penggunaan GPU. |
Penggunaan Memori GPU (DCGM_FI_DEV_FB_USED) |
Mengukur berapa banyak memori GPU yang digunakan pada titik waktu tertentu. Hal ini berguna untuk workload yang mengimplementasikan alokasi dinamis memori GPU. | Untuk workload yang mengalokasikan memori GPU lebih awal atau tidak pernah membatalkan alokasi memori (seperti beban kerja yang berjalan pada TGI dan vLLM), metrik ini hanya berfungsi untuk meningkatkan skala, dan tidak akan mengurangi skala saat traffic menurun. |
Metrik CPU
Di GKE, HPA langsung berfungsi dengan CPU dan aplikasi berbasis memori penskalaan otomatis. Untuk workload yang berjalan pada CPU, metrik pemakaian CPU dan memori biasanya merupakan metrik penskalaan otomatis utama.
Untuk workload inferensi yang berjalan pada GPU, kami tidak merekomendasikan CPU dan memori pemanfaatan sebagai satu-satunya indikator jumlah sumber daya yang dikonsumsi oleh tugas karena inferensi 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 penskalaan otomatis di GKE untuk memenuhi workload inferensi Anda sasaran performa.
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.
Ukuran antrean secara langsung berkorelasi dengan latensi permintaan. Antrean permintaan masuk di server model sebelum diproses, dan langkah ini waktu antrean menambah latensi keseluruhan. Ukuran antrean adalah indikator sensitif dari lonjakan beban, karena peningkatan beban dengan cepat yang mengisi antrean.
Penskalaan otomatis berdasarkan ukuran antrean meminimalkan waktu antrean dengan meningkatkan skala berdasarkan beban, dan memperkecil skala saat antrean kosong. Pendekatan ini relatif mudah untuk 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 saat dengan tetap memperhatikan konfigurasi server model Anda. Trek ukuran antrean tertunda, tidak permintaan pemrosesan. vLLM dan TGI menggunakan batching berkelanjutan, yang memaksimalkan permintaan serentak dan menjaga antrean tetap rendah saat ruang batch tersedia. Antrean akan terlihat bertambah besar ketika ruang batch terbatas, jadi gunakan pertumbuhan sebagai sinyal untuk memulai peningkatan skala. Dengan menggabungkan penskalaan otomatis ukuran antrean dengan yang dioptimalkan, Anda dapat memaksimalkan throughput permintaan.
Menentukan nilai batas ukuran antrean yang optimal untuk HPA
Perhatikan Toleransi HPA, yang ditetapkan secara default ke rentang tanpa tindakan 0,1 di sekitar target untuk meredam osilasi.
Untuk memilih batas ukuran antrean yang benar, mulailah dengan nilai antara 3-5 dan
secara bertahap meningkatkannya hingga permintaan mencapai latensi pilihan. Gunakan
Alat locust-load-inference untuk pengujian. Untuk nilai minimum di bawah 10,
menyesuaikan 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 dari ukuran tumpukan maksimum yang diizinkan. Sebagai solusinya, Anda dapat mengurangi ukuran tumpukan maksimum secara manual atau penskalaan otomatis pada ukuran tumpukan.
Praktik terbaik: Menggunakan ukuran batch untuk mencapai nilai minimum latensi target yang lebih rendah dari ukuran antrean
Sebaiknya pilih penskalaan otomatis berbasis ukuran batch jika Anda memiliki latensi yang sensitif beban kerja yang penskalaan berbasis antreannya tidak cukup cepat untuk memenuhi persyaratan Anda.
Ukuran batch secara langsung berkorelasi dengan throughput dan latensi peristiwa permintaan. Ukuran tumpukan adalah indikator yang baik untuk lonjakan beban, sebagai peningkatan menyebabkan lebih banyak permintaan ditambahkan ke batch yang ada, sehingga ukuran tumpukan yang lebih besar. Secara umum, semakin besar ukuran tumpukan, semakin tinggi latensinya. Penskalaan otomatis pada ukuran tumpukan memastikan skala beban kerja Anda meningkat untuk memaksimalkan jumlah permintaan yang diproses secara paralel sekaligus, dan menurunkan skala saat ada lebih sedikit permintaan yang diproses secara paralel.
Jika ukuran antrean sudah memenuhi target latensi Anda, prioritaskan ukuran antrean untuk penskalaan otomatis. Hal ini memaksimalkan throughput dan efisiensi biaya. Namun, ukuran tumpukan untuk workload yang sensitif terhadap latensi. Peningkatan ukuran tumpukan yang lebih besar throughput transaksi yang tinggi, tetapi juga meningkatkan latensi karena fase pengisian otomatis dari beberapa permintaan mengganggu fase dekode orang lain dalam batching berkelanjutan server model. Anda dapat memantau pola ukuran tumpukan dan menggunakan penskalaan otomatis untuk meminimalkan permintaan serentak selama lonjakan beban.
Jika server model Anda memungkinkan, sebaiknya sesuaikan ukuran tumpukan maksimum sebagai mekanisme tuning tambahan. Anda juga dapat memasangkannya dengan penskalaan otomatis berbasis antrean.
Menentukan nilai minimum ukuran tumpukan yang optimal untuk HPA
Perhatikan toleransi HPC, yang merupakan rentang tanpa tindakan default 0,1 di sekitar target untuk meredam osilasi.
Untuk memilih batas ukuran tumpukan yang tepat, tingkatkan beban secara eksperimental pada
server Anda dan mengamati di
mana ukuran tumpukan memuncak. Sebaiknya gunakan juga
Alat locust-load-inference untuk pengujian. Setelah mengidentifikasi kelompok maksimum
tetapkan nilai target awal sedikit di bawah nilai maksimum ini dan turunkan nilai tersebut
hingga latensi pilihan tercapai.
Anda juga dapat membuat dasbor kustom Cloud Monitoring untuk memvisualisasikan perilaku metrik.
Batasan
Penskalaan otomatis pada ukuran tumpukan, sekaligus membantu untuk kontrol latensi, memiliki batasan. Memvariasikan ukuran permintaan dan batasan hardware membuat menemukan ukuran batch yang tepat ambang batas menantang.
Praktik terbaik: Mengoptimalkan konfigurasi HPA
Sebaiknya tetapkan opsi konfigurasi HPA ini:
- Periode stabilisasi: Gunakan opsi konfigurasi HPA ini untuk mencegah perubahan jumlah replika karena metrik yang berfluktuasi. Defaultnya adalah 5 menit untuk penurunan skala (menghindari penurunan skala dini) dan 0 untuk peningkatan skala (memastikan tingkat respons). Sesuaikan nilai berdasarkan ketidakstabilan beban kerja dan pilihan responsivitas.
- Kebijakan penskalaan: Gunakan opsi konfigurasi HPA ini untuk menyesuaikan perilaku peningkatan skala dan penurunan skala. Anda dapat menyetel "Pod" kebijakan untuk menentukan jumlah absolut replika yang berubah per unit waktu, dan "Persen" kebijakan untuk menentukan berdasarkan perubahan persentase.
Untuk mempelajari opsi ini lebih lanjut, lihat Penskalaan Otomatis Pod Horizontal di Kubernetes open source dokumentasi tambahan.
Langkah selanjutnya
- Pelajari cara Mengonfigurasi penskalaan otomatis untuk workload LLM di GPU.