Panduan praktik terbaik ini menunjukkan metrik yang tersedia dan cara memilih metrik yang sesuai untuk menyiapkan Autoscaler Pod Horizontal(HPA) untuk beban kerja inferensi JetStream satu host 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 untuk mencapai sasaran performa server inferensi.
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 beban kerja JetStream satu host menggunakan TPU dengan Kubernetes.
Setelah membaca panduan ini, Anda akan dapat:
- Memahami metrik penskalaan otomatis utama untuk inferensi JetStream satu host.
- Pahami konsekuensi tingkat tinggi saat mempertimbangkan metrik yang akan 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 memahami terlebih dahulu bagaimana pipeline permintaan JetStreams memengaruhi indikator performa utama. Semua permintaan masuk akan dipindahkan melalui antrean pra-pengisian, antrean transfer, dan antrean pembuatan, lalu menjadi permintaan dekode. JetStream menerima permintaan dekode secara bergantian dan memprosesnya secara serentak menggunakan jumlah thread dekode yang tetap. Persentase mesin dekode yang 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 tertunda dalam antrean jika kecepatan permintaan yang masuk kurang dari kecepatan slot dekode yang dapat memproses permintaan. Jika JetStream tidak memiliki backlog, throughput akan sebanding dengan kecepatan permintaan yang masuk. Latensi sebagian besar 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 tertunda dalam antrean setelah kecepatan permintaan yang masuk melebihi kecepatan slot dekode dalam memproses permintaan. Jika JetStream memiliki backlog, latensi permintaan akan meningkat secara 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 (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 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
Mengingat penayangan LLM terkendala 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 beban kerja inferensi Anda.
Praktik terbaik: Gunakan ukuran antrean (antrean) pra-pengisian untuk memaksimalkan throughput dan meminimalkan biaya dalam batas latensi target tertentu
Sebaiknya gunakan penskalaan otomatis ukuran antrean pra-isi saat mengoptimalkan throughput dan biaya, serta saat target latensi dapat dicapai dengan throughput maksimum ukuran batch per perangkat server model Anda.
Ukuran antrean pra-isi berkorelasi langsung dengan latensi permintaan. Permintaan masuk akan diantrekan dalam antrean pengisian ulang server model sebelum diproses, dan waktu antrean ini akan menambah latensi secara keseluruhan. Ukuran antrean adalah indikator sensitif dari lonjakan beban, karena peningkatan beban dengan cepat mengisi antrean.
Penskalaan otomatis berdasarkan ukuran antrean pra-isi meminimalkan waktu antrean dengan menskalakan ke atas saat ada beban, dan menskalakan ke bawah 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 pra-pengisian jika Anda ingin memaksimalkan throughput setiap replika server model. Ukuran antrean pra-isi melacak permintaan yang tertunda, bukan yang sedang diproses. JetStream menggunakan pengelompokan 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
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
Perhatikan toleransi HPA, yang secara default ditetapkan ke rentang tanpa tindakan 0,1 di sekitar nilai target untuk meredam osilasi.
Ukuran antrean pra-isi tidak mengontrol permintaan serentak secara langsung, 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 berdasarkan 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 bahwa throughput workload Anda diskalakan untuk memaksimalkan jumlah permintaan yang diproses secara paralel sekaligus, dan diskalakan ke bawah jika ada lebih sedikit permintaan yang diproses secara paralel. Hal ini memiliki dua implikasi untuk latensi. Pertama, karena penskalaan otomatis berbasis slots_used diskalakan untuk memastikan slot bagi setiap permintaan yang masuk, seberapa dekat nilai minimum yang 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 meningkatkan throughput, tetapi juga meningkatkan latensi karena fase pra-pengisian beberapa permintaan mengganggu fase dekode permintaan lainnya di server model pengelompokan batch 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 sangat berharga untuk workload yang sensitif terhadap latensi.
Sebaiknya sesuaikan juga ukuran batch per perangkat ke nilai yang sesuai sebelum menjelajahi penskalaan otomatis berbasis slots_used. Secara opsional, Anda juga dapat memasangkannya dengan penskalaan otomatis berbasis antrean.
Menentukan nilai 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 titik puncak ukuran batch. Sebaiknya gunakan juga alat
locust-load-inference untuk pengujian. Setelah mengidentifikasi ukuran batch 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 tanpa tindakan default 0,1 di sekitar nilai target untuk meredam osilasi.
Penskalaan otomatis pada persentase slots_used, meskipun membantu untuk kontrol latensi, memiliki batasan. Ukuran permintaan dan batasan hardware yang bervariasi 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 bahwa aturan skala mencoba mempertahankan jumlah slot yang tersedia yang bukan nol. Slot yang tersedia ini sesuai dengan throughput yang tersedia yang tidak digunakan, yang tidak ideal jika Anda ingin memaksimalkan TPU yang tersedia.
Praktik terbaik: Menggunakan memori bandwidth tinggi (HBM) TPU untuk memaksimalkan penggunaan hardware
Penggunaan memori bandwidth tinggi (HBM) TPU memiliki korelasi paling langsung dengan penggunaan hardware, bahkan dibandingkan dengan metrik sistem karena tidak memperhitungkan ukuran permintaan. Meskipun penskalaan dengan ukuran antrean lebih memaksimalkan penggunaan hardware, hal ini akan mengorbankan latensi. Jika Anda lebih suka mengandalkan metrik sistem, bukan metrik server, sebaiknya gunakan 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 pra-pengisian dan penggunaan HBM secara bersamaan karena seiring meningkatnya beban, penggunaan HBM akan meningkat dan memicu penskalaan terlebih dahulu.
Menentukan nilai 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 perkiraan panjang perintah dan respons. Sebaiknya gunakan alat locust-load-inference untuk eksperimen dan pengujian Anda.
Serupa 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 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 korelasi antara penggunaan HBM dan latensi, peningkatan penggunaan HBM berdampak jauh lebih kecil pada latensi daripada peningkatan jumlah permintaan yang diantrekan.
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 karena metrik yang berfluktuasi. Nilai defaultnya adalah 5 menit untuk penskalaan ke bawah (menghindari penskalaan ke bawah yang terlalu cepat) dan 0 untuk penskalaan ke atas (memastikan responsivitas). Sesuaikan nilai berdasarkan volatilitas workload dan responsivitas yang Anda inginkan.
- Kebijakan penskalaan: Gunakan opsi konfigurasi HPA ini untuk menyesuaikan perilaku peningkatan skala 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 di dokumentasi Kubernetes open source.
Langkah selanjutnya
- Pelajari cara Mengonfigurasi penskalaan otomatis untuk workload LLM di TPU.