Panduan praktik terbaik ini menunjukkan metrik yang tersedia dan cara memilih metrik yang sesuai untuk menyiapkan Horizontal Pod Autoscaler(HPA) bagi workload inferensi JetStream host tunggal Anda dengan TPU 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 Anda.
Untuk contoh cara menerapkan praktik terbaik ini, lihat Mengonfigurasi penskalaan otomatis untuk workload LLM di TPU 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 JetStream host tunggal mereka menggunakan TPU dengan Kubernetes.
Setelah membaca panduan ini, Anda akan dapat:
- Memahami metrik penskalaan otomatis utama untuk inferensi JetStream host tunggal.
- Memahami pertimbangan tingkat tinggi saat mempertimbangkan metrik mana yang akan diskalakan otomatis.
Ringkasan metrik penskalaan otomatis untuk inferensi JetStream
Sebaiknya gunakan metrik berikut:
Metrik server
JetStream, seperti banyak server inferensi LLM lainnya, menyediakan metrik performa. GKE menyederhanakan pemantauan dan penskalaan otomatis JetStream berdasarkan metrik tingkat server ini. Untuk mengonfigurasi penskalaan otomatis, Anda harus terlebih dahulu memahami pengaruh pipeline permintaan JetStream terhadap indikator performa utama. Semua permintaan yang masuk akan dipindahkan melalui antrean pra-pengisian, antrean transfer, dan antrean pembuatan, lalu menjadi permintaan decoding. JetStream menerima permintaan decoding secara bergilir dan memprosesnya secara serentak menggunakan jumlah thread decoding yang tetap. Persentase mesin decoding yang digunakan untuk menangani permintaan decoding pada titik tertentu diukur sebagai metrik jetstream_slots_used_percentage.
Untuk menskalakan JetStream host tunggal, hal ini memiliki dua implikasi untuk latensi dan throughput:
- Permintaan tidak akan tertunda di antrean jika rasio permintaan yang masuk lebih rendah daripada rasio slot decoding yang dapat memproses permintaan. Jika JetStream tidak memiliki backlog, throughput akan sebanding dengan rasio permintaan yang masuk. Latensi akan tetap sebagian besar konstan, tetapi meningkat sedikit dan sebanding dengan jumlah permintaan decoding serentak karena permintaan decoding yang baru diterima akan mengganggu decoding.
- Permintaan akan tertunda di antrean setelah rasio permintaan yang masuk melebihi rasio slot decoding yang dapat memproses permintaan. Jika JetStream memiliki backlog, latensi permintaan akan meningkat lebih signifikan dan sebanding dengan jumlah permintaan yang tertunda, sementara throughput akan tetap konstan.
Metrik server berikut akan memiliki korelasi terkuat dengan indikator performa yang relevan ini. Sebaiknya gunakan metrik ini untuk penskalaan otomatis:
jetstream_prefill_backlog_size: Jumlah permintaan yang menunggu pemrosesan dalam antrean server (backlog). Metrik ini memiliki korelasi yang kuat dengan latensi. Untuk mempelajari lebih lanjut, lihat bagian praktik terbaik terkait.jetstream_slots_used_percentage: Jumlah permintaan yang sedang menjalani inferensi sebagai persentase dari jumlah total permintaan yang dapat ditangani JetStream. Metrik ini memiliki korelasi yang kuat dengan throughput. 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 TPU.
Metrik TPU
Karena penayangan LLM dibatasi oleh memori, bukan komputasi, sebaiknya Anda menskalakan JetStream dengan penggunaan memori, bukan dengan metrik TPU lainnya karena metrik ini paling mencerminkan penggunaan resource hardware. Untuk mempelajari lebih lanjut, lihat bagian praktik terbaik terkait.
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 backlog (antrean) pra-pengisian untuk memaksimalkan throughput dan meminimalkan biaya dalam batas latensi target tertentu
Sebaiknya lakukan penskalaan otomatis ukuran antrean pra-pengisian saat mengoptimalkan throughput dan biaya, serta saat target latensi Anda dapat dicapai dengan throughput maksimum ukuran batch per perangkat server model Anda.
Ukuran antrean pra-pengisian berkorelasi langsung dengan latensi permintaan. Permintaan yang masuk akan mengantre di antrean pra-pengisian server model sebelum diproses, dan waktu antrean ini akan menambah latensi keseluruhan. Ukuran antrean adalah indikator lonjakan beban yang sensitif, karena peningkatan beban akan dengan cepat mengisi antrean.
Penskalaan otomatis berdasarkan ukuran antrean pra-pengisian akan meminimalkan waktu antrean dengan meningkatkan skala saat beban tinggi, dan menurunkan skala saat antrean kosong. Pendekatan ini relatif mudah diterapkan karena ukuran antrean tidak bergantung pada ukuran permintaan, model, atau hardware.
Pertimbangkan untuk berfokus pada ukuran antrean pra-pengisian jika Anda ingin memaksimalkan throughput setiap replika server model. Ukuran antrean pra-pengisian melacak permintaan yang tertunda, bukan yang sedang diproses. JetStream 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 peningkatan skala. Dengan menggabungkan penskalaan otomatis ukuran antrean dengan throughput batch yang dioptimalkan, Anda dapat memaksimalkan throughput permintaan.
Menentukan nilai minimum ukuran antrean yang optimal untuk HPA
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
Perhatikan toleransi HPA, yang secara default adalah rentang 0,1 tanpa tindakan di sekitar nilai target untuk meredam osilasi.
Ukuran antrean pra-pengisian tidak secara langsung mengontrol permintaan serentak, sehingga nilai minimumnya tidak dapat menjamin latensi yang lebih rendah daripada yang diizinkan oleh ukuran batch per perangkat. Sebagai solusinya, Anda dapat mengurangi ukuran batch per perangkat secara manual atau melakukan penskalaan otomatis pada ukuran batch.
Praktik terbaik: Gunakan persentase slots_used untuk mencapai nilai minimum latensi target yang lebih rendah daripada ukuran antrean
Sebaiknya pilih penskalaan otomatis berbasis slots_used jika Anda memiliki workload yang sensitif terhadap latensi dan penskalaan berbasis antrean tidak cukup cepat untuk memenuhi persyaratan Anda.
Penskalaan otomatis pada slots_used memastikan throughput workload Anda ditingkatkan untuk memaksimalkan jumlah permintaan yang diproses secara paralel sekaligus, dan diturunkan saat ada lebih sedikit permintaan yang diproses secara paralel. Hal ini memiliki dua implikasi untuk latensi. Pertama, karena penskalaan otomatis berbasis slots_used ditingkatkan untuk memastikan slot untuk setiap permintaan yang masuk, seberapa dekat nilai minimum ditetapkan ke 1 akan sesuai dengan kemungkinan permintaan menghabiskan waktu dalam antrean dan akibatnya memiliki latensi yang lebih tinggi. Kedua, ukuran batch yang lebih besar akan meningkatkan throughput, tetapi juga meningkatkan latensi karena fase pra-pengisian beberapa permintaan mengganggu fase decoding 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 ukuran antrean sudah memenuhi target latensi Anda, prioritaskan untuk penskalaan otomatis. Hal ini akan memaksimalkan throughput dan efisiensi biaya. Namun, slots_used sangat berharga untuk workload yang sensitif terhadap latensi.
Sebaiknya sesuaikan ukuran batch per perangkat ke nilai yang sesuai sebelum mempelajari penskalaan otomatis berbasis slots_used. Secara opsional, Anda juga dapat menggabungkannya dengan penskalaan otomatis berbasis antrean.
Menentukan nilai minimum persentase slots_used yang optimal untuk HPA
Untuk memilih nilai minimum ukuran batch yang tepat, tingkatkan beban di server Anda secara eksperimental dan amati tempat ukuran batch mencapai puncaknya. Sebaiknya gunakan alat
locust-load-inference untuk pengujian. Setelah mengidentifikasi ukuran batch per perangkat yang optimal dan penggunaan memori dimaksimalkan, Anda dapat mengonfigurasi target persentase slots_used. Tetapkan nilai target awal sedikit di bawah 1 dan kurangi hingga latensi yang diinginkan tercapai.
Anda juga dapat membuat dasbor kustom Cloud Monitoring untuk memvisualisasikan perilaku metrik.
Batasan
Perhatikan toleransi HPA, yang secara default adalah rentang 0,1 tanpa tindakan di sekitar nilai target untuk meredam osilasi.
Penskalaan otomatis pada persentase slots_used, meskipun berguna untuk kontrol latensi, memiliki batasan. Ukuran permintaan yang bervariasi dan batasan hardware membuat penentuan nilai minimum persentase slots_used yang tepat menjadi sulit. Memiliki aturan skala yang mencoba mempertahankan persentase slots_used rata-rata di bawah 100% berarti aturan skala mencoba mempertahankan jumlah slot yang tersedia bukan nol. Slot yang tersedia ini sesuai dengan throughput yang tersedia yang tidak digunakan, yang tidak ideal jika Anda ingin memanfaatkan TPU yang tersedia secara maksimal.
Praktik terbaik: Gunakan penggunaan memori bandwidth tinggi (HBM) TPU untuk memaksimalkan penggunaan hardware
Penggunaan memori bandwidth tinggi (HBM) TPU memiliki korespondensi paling langsung dengan penggunaan hardware, bahkan jika dibandingkan dengan metrik sistem karena metrik ini tidak memperhitungkan ukuran permintaan. Meskipun penskalaan dengan ukuran antrean memaksimalkan penggunaan hardware dengan lebih baik, hal ini akan mengorbankan latensi. Jika Anda lebih suka mengandalkan metrik sistem daripada metrik server, sebaiknya gunakan penggunaan HBM sebagai alternatif terbaik untuk penskalaan otomatis dengan slots_used karena keduanya sesuai dengan throughput. Untuk mengetahui informasi selengkapnya tentang memori TPU, lihat Cara kerja TPU.
Meningkatkan ukuran batch di luar titik optimal akan meningkatkan throughput, tetapi juga meningkatkan risiko error kehabisan memori (OOM). Sebaiknya lakukan penskalaan berdasarkan metrik HBM untuk menyeimbangkan throughput dan stabilitas. Sebaiknya jangan lakukan penskalaan dengan ukuran antrean pra-pengisian dan penggunaan HBM secara bersamaan karena saat beban meningkat, penggunaan HBM akan meningkat dan memicu penskalaan terlebih dahulu.
Menentukan nilai minimum penggunaan HBM TPU yang optimal untuk HPA
Sebelum memilih nilai minimum penggunaan memori, sebaiknya tetapkan ukuran batch per perangkat ke nilai yang memaksimalkan memori yang digunakan saat beroperasi di bawah beban maksimum yang diharapkan. Perhatikan bahwa nilai ini harus ditentukan secara eksperimental dan akan sangat bergantung pada total HBM serta panjang perintah dan respons yang diharapkan. Sebaiknya gunakan alat locust-load-inference untuk eksperimen dan pengujian Anda.
Mirip dengan ukuran batch per perangkat, tetapkan nilai minimum untuk memaksimalkan penggunaan memori TPU sekaligus meminimalkan risiko perilaku OOM.
Anda juga dapat membuat dasbor kustom Cloud Monitoring untuk memvisualisasikan perilaku metrik.
Batasan
Ada dua peringatan yang mengurangi kekuatan korespondensi latensi dan throughput dengan penggunaan HBM, yaitu volatilitas penggunaan HBM dan rasio sampling metrik TPU yang lebih rendah secara umum. Selain itu, meskipun masih ada korespondensi antara penggunaan HBM dan latensi, peningkatan penggunaan HBM jauh lebih sedikit memengaruhi latensi dibandingkan peningkatan jumlah permintaan dalam antrean.
Praktik terbaik: Mengoptimalkan konfigurasi HPA
Sebaiknya tetapkan opsi konfigurasi HPA berikut:
- Periode 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 peningkatan skala (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 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 berikutnya
- Pelajari cara Mengonfigurasi penskalaan otomatis untuk workload LLM di TPU.