Panduan praktik terbaik ini menunjukkan metrik yang tersedia dan cara memilih metrik yang sesuai untuk menyiapkan Horizontal Pod Autoscaler(HPA) untuk workload inferensi JetStream host tunggal dengan TPU di GKE. HPA adalah cara yang efisien untuk memastikan bahwa skala server model Anda sesuai dengan beban. Menyesuaikan setelan HPA adalah cara utama untuk menyelaraskan biaya hardware yang disediakan dengan permintaan traffic untuk mencapai sasaran performa server inferensi Anda.
Untuk contoh cara menerapkan praktik terbaik ini, lihat Mengonfigurasi penskalaan otomatis untuk workload LLM di TPU 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 workload JetStream host tunggal mereka menggunakan TPU dengan Kubernetes.
Setelah membaca panduan ini, Anda akan dapat:
- Memahami metrik penskalaan otomatis utama untuk inferensi JetStream satu host.
- Memahami konsekuensi tingkat tinggi saat mempertimbangkan metrik mana yang harus diskalakan secara 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 bagaimana pipeline permintaan JetStreams memengaruhi indikator performa utama. Semua permintaan masuk bergerak melalui antrean isi otomatis, antrean transfer, dan generate queue, lalu menjadi permintaan dekode. JetStream menerima permintaan dekode secara bertahap dan memprosesnya secara serentak menggunakan thread dekode dalam jumlah tetap. Persentase mesin dekode yang digunakan untuk menangani permintaan dekode 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 disimpan dalam antrean jika tingkat permintaan yang masuk kurang dari tingkat ketika slot dekode dapat memproses permintaan. Jika JetStream tidak memiliki backlog, throughput akan sebanding dengan tingkat permintaan masuk. Sebagian besar latensi akan tetap konstan, tetapi meningkat sedikit dan secara proporsional dengan jumlah permintaan dekode serentak karena permintaan dekode yang baru diterima akan mengganggu dekode.
- Permintaan akan disimpan dalam antrean setelah tingkat permintaan yang masuk melebihi tingkat di mana slot dekode dapat memproses permintaan. Jika JetStream memiliki backlog, latensi permintaan akan meningkat secara lebih signifikan dan proporsional dengan jumlah permintaan yang tertahan 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 diproses dalam antrean server ({i>backlog<i}). Metrik ini memiliki korelasi yang kuat dengan latensi. Untuk mempelajari lebih lanjut, lihat bagian praktik terbaik terkait.jetstream_slots_used_percentage: Jumlah permintaan yang 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 konfigurasi hardware TPU.
Metrik TPU
Mengingat inferensi LLM terhambat oleh memori dan bukan komputasi, kami merekomendasikan agar Anda menskalakan JetStream dengan penggunaan memori, bukan dengan metrik TPU lainnya karena 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 guna memilih metrik terbaik untuk penskalaan otomatis di GKE agar memenuhi sasaran performa workload inferensi Anda.
Praktik terbaik: Gunakan ukuran backlog (antrean) pengisian otomatis untuk memaksimalkan throughput dan meminimalkan biaya dalam batas latensi target tertentu
Sebaiknya isi otomatis penskalaan otomatis ukuran antrean saat mengoptimalkan throughput dan biaya, dan jika target latensi Anda dapat dicapai dengan throughput maksimum server model Anda per ukuran batch perangkat.
Ukuran antrean pengisian otomatis berkorelasi langsung dengan latensi permintaan. Permintaan yang masuk akan dimasukkan ke antrean pengisian otomatis server model sebelum diproses, dan waktu antrean ini akan menambah latensi keseluruhan. Ukuran antrean adalah indikator sensitif dari lonjakan beban, karena peningkatan beban mengisi antrean dengan cepat.
Penskalaan otomatis berdasarkan ukuran antrean pengisian otomatis meminimalkan waktu antrean dengan meningkatkan skala berdasarkan beban, dan memperkecil skala saat antrean kosong. Pendekatan ini relatif mudah untuk implementasikan karena ukuran antrean tidak bergantung pada ukuran permintaan, model, atau hardware.
Pertimbangkan untuk berfokus pada ukuran antrean pengisian otomatis jika Anda ingin memaksimalkan throughput setiap replika server model. Pengisian otomatis jalur ukuran antrean tertunda, tidak diproses, permintaan. JetStream menggunakan batching berkelanjutan, yang memaksimalkan permintaan serentak dan menjaga antrean tetap rendah saat ruang batch tersedia. Antrean akan terus bertambah jika ruang batch terbatas, jadi gunakan titik pertumbuhan sebagai sinyal untuk memulai peningkatan skala. Dengan menggabungkan penskalaan otomatis ukuran antrean dan throughput batch yang dioptimalkan, Anda dapat memaksimalkan throughput permintaan.
Menentukan nilai batas ukuran antrean yang optimal untuk HPA
Untuk memilih batas ukuran antrean yang benar, mulailah dengan nilai antara 3–5, lalu tingkatkan secara bertahap hingga permintaan mencapai latensi pilihan. Gunakan alat locust-load-inference untuk pengujian. Untuk nilai minimum di bawah 10, sesuaikan setelan peningkatan skala HPA guna menangani lonjakan traffic.
Anda juga dapat membuat dasbor kustom Cloud Monitoring untuk memvisualisasikan perilaku metrik.
Batasan
Perhatikan toleransi HPA, yang default-nya adalah rentang tanpa tindakan 0,1 di sekitar nilai target untuk meredam osilasi.
Ukuran antrean pengisian otomatis 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 tumpukan per perangkat atau penskalaan otomatis pada ukuran tumpukan secara manual.
Praktik terbaik: Gunakan persentase slot_used untuk mencapai batas latensi target yang lebih rendah dari ukuran antrean
Sebaiknya pilih penskalaan otomatis berbasis slot_used jika Anda memiliki beban kerja yang sensitif terhadap latensi yang penskalaan berbasis antrean tidak cukup cepat untuk memenuhi persyaratan Anda.
Penskalaan otomatis di slot_used memastikan bahwa throughput beban kerja Anda ditingkatkan untuk memaksimalkan jumlah permintaan yang diproses secara paralel sekaligus, dan menurunkan skala saat ada lebih sedikit permintaan yang diproses secara paralel. Hal ini memiliki dua implikasi untuk latensi. Pertama, karena penskalaan otomatis berbasis slot_used diskalakan untuk memastikan slot untuk setiap permintaan masuk, seberapa dekat ambang batas ditetapkan ke 1 akan sesuai dengan kemungkinan waktu yang dihabiskan permintaan dalam antrean, sehingga memiliki latensi yang lebih tinggi. Kedua, ukuran batch yang lebih besar meningkatkan throughput, tetapi juga meningkatkan latensi karena fase pengisian otomatis dari beberapa permintaan yang mengganggu fase dekode lainnya dalam 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 ukuran antrean untuk penskalaan otomatis. Hal ini memaksimalkan throughput dan efisiensi biaya. Namun, slot_used berguna untuk workload yang sensitif terhadap latensi.
Kami juga menyarankan untuk menyesuaikan ukuran batch per perangkat ke nilai yang sesuai sebelum mempelajari penskalaan otomatis berbasis slot_used. Jika ingin, Anda juga dapat memasangkannya dengan penskalaan otomatis berbasis antrean.
Menentukan nilai batas persentase slot_used yang optimal untuk HPA
Untuk memilih batas ukuran tumpukan yang tepat, secara eksperimental, tingkatkan beban di server Anda dan amati puncak ukuran tumpukan. Sebaiknya gunakan juga
Alat locust-load-inference untuk pengujian. Setelah mengidentifikasi ukuran batch per perangkat yang optimal untuk penggunaan memori dimaksimalkan, Anda dapat mengonfigurasi target persentase slot_used Anda. Setel nilai target awal sedikit di bawah 1 dan turunkan hingga latensi yang diinginkan tercapai.
Anda juga dapat membuat dasbor kustom Cloud Monitoring untuk memvisualisasikan perilaku metrik.
Batasan
Perhatikan toleransi HPA, yang merupakan rentang tanpa tindakan default 0,1 di sekitar nilai target untuk meredam osilasi.
Penskalaan otomatis pada persentase slot_used, sekaligus membantu untuk kontrol latensi, memiliki batasan. Memvariasikan ukuran permintaan dan batasan hardware membuat menemukan batas persentase slot_used yang tepat menjadi sulit. Memiliki aturan skala yang mencoba mempertahankan persentase slot_used rata-rata di bawah 100% berarti bahwa aturan skala mencoba mempertahankan angka bukan nol untuk slot yang tersedia. Slot yang tersedia ini berkaitan dengan throughput yang tidak digunakan. Hal ini tidak ideal jika Anda ingin mengoptimalkan TPU yang tersedia.
Praktik terbaik: Menggunakan penggunaan TPU high bandwidth memory (HBM) untuk memaksimalkan penggunaan hardware
Penggunaan TPU high bandwidth memory (HBM) memiliki korespondensi paling langsung dengan pemanfaatan hardware, bahkan jika dibandingkan dengan metrik sistem karena ukuran permintaan tidak memperhitungkan ukuran permintaan. Meskipun penskalaan dengan ukuran antrean memaksimalkan penggunaan hardware dengan lebih baik, hal itu akan melakukannya dengan mengorbankan latensi. Jika Anda lebih suka mengandalkan metrik sistem daripada metrik server, sebaiknya gunakan HBM sebagai alternatif terbaik untuk penskalaan otomatis dengan slot_used karena keduanya sesuai dengan throughput. Untuk mengetahui informasi selengkapnya tentang memori TPU, lihat Cara kerja TPU.
Meningkatkan ukuran tumpukan di luar titik optimal akan meningkatkan throughput, tetapi juga meningkatkan risiko error kehabisan memori (OOM). Kami sangat merekomendasikan penskalaan berdasarkan metrik HBM untuk menyeimbangkan throughput dan stabilitas. Sebaiknya jangan menskalakan dengan ukuran antrean pengisian otomatis dan penggunaan HBM secara bersamaan karena seiring meningkatnya beban, penggunaan HBM akan meningkat dan memicu penskalaan terlebih dahulu.
Menentukan nilai batas penggunaan TPU HBM yang optimal untuk HPA
Sebelum memilih batas penggunaan memori, sebaiknya setel 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 perintah dan panjang respons yang diharapkan. Sebaiknya gunakan alat locust-load-inference untuk eksperimen dan pengujian.
Serupa dengan ukuran batch per perangkat, tetapkan batas 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 hal yang perlu diwaspadai yang mengurangi kekuatan latensi dan throughput yang sesuai dengan penggunaan HBM, yaitu volatilitas penggunaan HBM dan frekuensi sampling yang lebih rendah dari metrik TPU secara umum. Selain itu, meskipun masih ada korespondensi antara penggunaan HBM dan latensi, peningkatan HBM menggunakan latensi dampak yang jauh lebih sedikit daripada peningkatan jumlah permintaan dalam antrean.
Praktik terbaik: Mengoptimalkan konfigurasi HPA
Sebaiknya tetapkan opsi konfigurasi HPA ini:
- Periode stabilisasi: Gunakan opsi konfigurasi HPA ini untuk mencegah perubahan jumlah replika yang cepat karena metrik yang berfluktuasi. Defaultnya adalah 5 menit untuk penurunan skala (menghindari penurunan skala dini) dan 0 untuk peningkatan skala (memastikan responsivitas). Sesuaikan nilai berdasarkan volatilitas workload dan responsivitas pilihan Anda.
- 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 diubah per unit waktu, dan "Persen" kebijakan yang ditentukan berdasarkan perubahan persentase.
Untuk mempelajari opsi ini lebih lanjut, baca Penskalaan Otomatis Pod Horizontal dalam dokumentasi Kubernetes open source.
Langkah selanjutnya
- Pelajari cara Mengonfigurasi penskalaan otomatis untuk workload LLM di TPU.