Panduan praktik terbaik ini menunjukkan metrik yang tersedia dan cara memilih metrik yang sesuai untuk menyiapkan Horizontal Pod Autoscaler(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 dengan 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.
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 single-host 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 memahami terlebih dahulu pengaruh pipeline permintaan JetStream terhadap indikator performa utama. Semua permintaan masuk melewati antrean pengisian otomatis, antrean transfer, dan antrean pembuatan, lalu menjadi permintaan dekode. JetStream menerima permintaan dekode secara berkelanjutan dan memprosesnya secara serentak menggunakan sejumlah thread dekode 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 tidak ada backlog di JetStream, throughput akan sebanding dengan kecepatan permintaan 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 tertunda dalam antrean setelah rasio permintaan yang masuk melebihi rasio pemrosesan permintaan oleh slot dekode. Jika JetStream memiliki backlog, latensi permintaan akan meningkat secara 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 sedang 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 menjadikannya titik awal yang andal untuk penskalaan otomatis di berbagai konfigurasi 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 hal ini paling mencerminkan pemanfaatan 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) pengisian otomatis 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 dalam 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 pengisian awal meminimalkan waktu antrean dengan meningkatkan skala saat ada beban, dan menurunkan 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 otomatis 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 penskalaan. Dengan menggabungkan penskalaan otomatis ukuran antrean dengan throughput batch yang dioptimalkan, Anda dapat memaksimalkan throughput permintaan.
Menentukan nilai batas 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 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 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 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 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 di slots_used memastikan bahwa throughput workload Anda meningkat untuk memaksimalkan jumlah permintaan yang diproses secara paralel sekaligus, dan menurun 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 batch yang lebih besar meningkatkan throughput, tetapi juga meningkatkan latensi karena fase pengisian awal beberapa permintaan mengganggu fase decoding permintaan lainnya di server model 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 berguna untuk workload yang sensitif terhadap latensi.
Sebaiknya sesuaikan 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 batas persentase slots_used yang optimal untuk HPA
Untuk memilih batas 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 batch per perangkat yang optimal dengan penggunaan memori yang maksimal, Anda dapat mengonfigurasi target persentase slots_used. Tetapkan 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 berdasarkan persentase slots_used, meskipun berguna untuk kontrol latensi, memiliki batasan. Ukuran permintaan yang bervariasi dan batasan hardware membuat penentuan nilai persentase slots_used yang tepat menjadi sulit. Memiliki aturan penskalaan yang berupaya menjaga persentase slots_used rata-rata di bawah 100% berarti aturan penskalaan berupaya 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 penggunaan hardware
Penggunaan memori bandwidth tinggi (HBM) TPU memiliki korespondensi paling langsung dengan pemanfaatan hardware, bahkan jika dibandingkan dengan metrik sistem karena tidak memperhitungkan ukuran permintaan. Meskipun penskalaan dengan ukuran antrean memaksimalkan penggunaan hardware dengan lebih baik, hal ini akan mengorbankan latensi. Jika Anda lebih memilih 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 batas 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 korespondensi latensi dan throughput dengan penggunaan HBM, yaitu volatilitas penggunaan HBM dan laju pengambilan sampel 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 prematur) dan 0 untuk peningkatan skala (memastikan responsivitas). Sesuaikan nilai berdasarkan volatilitas beban kerja dan responsivitas yang Anda inginkan.
- Kebijakan penskalaan: Gunakan opsi konfigurasi HPA ini untuk menyempurnakan 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 perubahan persentase.
Untuk mempelajari lebih lanjut opsi ini, lihat Penskalaan Otomatis Pod Horizontal di dokumentasi Kubernetes open source.
Langkah berikutnya
- Pelajari cara Mengonfigurasi penskalaan otomatis untuk workload LLM di TPU.