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 server model Anda diskalakan dengan tepat sesuai beban. Penyesuaian 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 dari semua praktik terbaik GKE, lihat Praktik terbaik untuk 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:
- Pahami metrik penskalaan otomatis utama untuk inferensi JetStream host tunggal.
- Pahami konsekuensi tingkat tinggi saat mempertimbangkan metrik yang akan digunakan untuk penskalaan 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 masuk melewati antrean prefill, antrean transfer, dan antrean pembuatan, lalu menjadi permintaan dekode. JetStream menerima permintaan dekode secara berkelanjutan dan memprosesnya secara serentak menggunakan jumlah thread dekode yang 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, ada dua implikasi untuk latensi dan throughput:
- Permintaan tidak akan tertunda dalam antrean jika kecepatan permintaan yang masuk lebih rendah daripada kecepatan slot dekode dapat memproses permintaan. Jika JetStream tidak memiliki backlog, throughput akan sebanding dengan kecepatan permintaan yang masuk. Latensi akan tetap hampir konstan, tetapi meningkat sedikit dan proporsional dengan jumlah permintaan dekode serentak karena permintaan dekode yang baru diterima akan mengganggu dekode.
- Permintaan akan di-backlog dalam antrean setelah rasio permintaan yang masuk melebihi rasio slot dekode yang dapat memproses permintaan. Jika JetStream memiliki backlog, latensi permintaan akan meningkat lebih signifikan dan proporsional 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 di antrean server (tunggakan). 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 total jumlah 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 menjadi titik awal yang andal untuk penskalaan otomatis di berbagai penyiapan hardware TPU.
Metrik TPU
Mengingat penayangan LLM terhambat 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 gunakan penskalaan otomatis ukuran antrean pengisian otomatis saat mengoptimalkan throughput dan biaya, serta saat target latensi Anda dapat dicapai dengan throughput maksimum ukuran batch per perangkat server model Anda.
Ukuran antrean pengisian otomatis berkorelasi langsung dengan latensi permintaan. Permintaan masuk diantrekan di antrean pengisian awal 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 pra-pengisian meminimalkan waktu antrean dengan meningkatkan skala saat ada beban, dan memperkecil skala saat antrean kosong. Pendekatan ini relatif mudah diimplementasikan 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. Ukuran antrean pengisian awal melacak permintaan yang tertunda, bukan yang sedang diproses. JetStream menggunakan batch berkelanjutan, yang memaksimalkan permintaan serentak dan menjaga antrean tetap rendah saat ruang batch tersedia. Antrean akan bertambah besar 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 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 ditetapkan ke rentang tanpa tindakan 0,1 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 solusi, Anda dapat mengurangi ukuran batch per perangkat secara manual atau menskalakan otomatis pada ukuran batch.
Praktik terbaik: Gunakan persentase slots_used untuk mencapai nilai minimum target latensi 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 meningkat untuk memaksimalkan jumlah permintaan yang diproses secara paralel sekaligus, dan memperkecil skala saat ada lebih sedikit permintaan yang diproses secara paralel. Hal ini memiliki dua implikasi untuk latensi. Pertama, karena penskalaan otomatis berbasis slots_used menskalakan untuk memastikan adanya slot bagi 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 tumpukan yang lebih besar meningkatkan throughput, tetapi juga meningkatkan latensi karena fase pengisian awal beberapa permintaan mengganggu fase decoding 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 ukuran antrean sudah memenuhi target latensi Anda, prioritaskan untuk penskalaan otomatis. Hal ini memaksimalkan throughput dan efisiensi biaya. Namun, slots_used berguna untuk workload yang sensitif terhadap latensi.
Sebaiknya sesuaikan juga ukuran tumpukan per perangkat ke nilai yang sesuai sebelum mempelajari penskalaan otomatis berbasis slots_used. Secara opsional, Anda juga dapat memasangkannya 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 pada server Anda secara eksperimental dan amati di mana ukuran batch mencapai puncaknya. Sebaiknya gunakan alat
locust-load-inference untuk pengujian. Setelah mengidentifikasi ukuran tumpukan per perangkat yang optimal dengan penggunaan memori yang 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 merupakan rentang default 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 batas persentase slots_used yang tepat menjadi sulit. Memiliki aturan penskalaan yang mencoba mempertahankan persentase slots_used rata-rata di bawah 100% berarti aturan penskalaan 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: Menggunakan penggunaan memori bandwidth tinggi (HBM) TPU untuk memaksimalkan pemanfaatan hardware
Penggunaan memori bandwidth tinggi (HBM) TPU memiliki korelasi paling langsung dengan pemakaian hardware, bahkan jika dibandingkan dengan metrik sistem karena metrik tersebut tidak memperhitungkan ukuran permintaan. Meskipun penskalaan dengan ukuran antrean memaksimalkan penggunaan hardware dengan lebih baik, hal ini akan dilakukan dengan mengorbankan latensi. Jika Anda lebih memilih untuk 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 melakukan penskalaan dengan ukuran antrean pengisian otomatis 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 batas 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 perkiraan panjang perintah dan respons. Sebaiknya gunakan alat locust-load-inference untuk eksperimen dan pengujian Anda.
Mirip dengan ukuran batch per perangkat, tetapkan nilai minimum untuk memaksimalkan pemanfaatan 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 korelasi latensi dan throughput dengan penggunaan HBM, yaitu volatilitas penggunaan HBM dan frekuensi sampling metrik TPU yang lebih rendah secara umum. Selain itu, meskipun masih ada korespondensi antara penggunaan HBM dan latensi, peningkatan penggunaan HBM jauh lebih kecil dampaknya terhadap 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 yang terlalu 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 dan penurunan skala. Anda dapat menetapkan batas kebijakan "Pods" untuk menentukan jumlah absolut replika yang diubah per unit waktu, dan batas kebijakan "Percent" untuk menentukan persentase perubahan.
Untuk mempelajari opsi ini lebih lanjut, lihat Penskalaan Otomatis Pod Horizontal di dokumentasi Kubernetes open source.
Langkah berikutnya
- Pelajari cara Mengonfigurasi penskalaan otomatis untuk workload LLM di TPU.