Pengujian beban untuk melayani titik akhir

Artikel ini memandu Anda melalui proses penting pengujian beban titik akhir Mosaic AI Model Serving Anda untuk memastikan mereka dapat menangani beban kerja produksi secara efektif. Ini juga memberikan contoh praktis, analogi dunia nyata, dan instruksi langkah demi langkah menggunakan Locust load testing framework, untuk menunjukkan cara mengukur metrik performa utama seperti permintaan per detik dan batas konkurensi, sehingga Anda dapat menilai endpoint Anda dengan tepat dan dengan percaya diri menerapkan model untuk kebutuhan bisnis Anda.

Petunjuk / Saran

Pengujian beban adalah komponen penting dari pengoptimalan produksi. Untuk panduan komprehensif untuk strategi pengoptimalan termasuk infrastruktur, model, dan pengoptimalan sisi klien, lihat Mengoptimalkan titik akhir Model Melayani untuk produksi.

Apa itu uji beban?

Uji beban adalah pengujian yang mensimulasikan penggunaan model Mosaic AI dalam kondisi dunia nyata untuk melayani endpoint, memastikan bahwa model tersebut memenuhi persyaratan produksi Anda, seperti latensi atau permintaan per detik. Pengujian beban mengukur performa titik akhir Anda di bawah tingkat lalu lintas yang berbeda, membantu Anda mengukur titik akhir dengan benar sehingga tidak menyebabkan penundaan.

Gambar ini: Ini pukul 08.00 pada hari kerja, dan kafe populer di jantung kota baru saja dibuka. Aroma kopi segar memenuhi udara. Barista disiapkan, mesin dihangatkan, dan baris pelanggan yang kekurangan kafein sudah terbentuk.

Pada awalnya, semuanya berjalan lancar. Beberapa pelanggan melangkah, melakukan pemesanan, dan barista mulai menyiapkan minuman mereka. Beberapa minuman membutuhkan waktu 30 detik, yang lain membutuhkan waktu satu menit - tergantung pada kompleksitasnya. Barista menangani beberapa pesanan dengan efisiensi yang terlatih.

Tapi segera, lebih banyak orang tiba. Lima pelanggan berubah menjadi sepuluh, lalu dua puluh. Masing-masing menempatkan pesanan, menunggu minuman mereka, dan mungkin mengobrol sedikit di konter. Barista sekarang berada di bawah tekanan. Bahkan dengan barista kedua ikut membantu, sistem mulai terbebani — antrian bertambah, pesanan menumpuk, dan pelanggan mulai menunggu lebih lama.

Sekarang bayangkan Anda mencoba mengukur berapa banyak minuman yang dapat disajikan kafe per menit sebelum pelanggan mulai merasa frustrasi. Itu pengujian beban.

Dalam analogi ini:

• Setiap pelanggan adalah klien yang mengirim permintaan.
• Barista-barista tersebut mewakili server Anda yang memproses inferensi model satu per satu atau secara paralel.
• Waktu untuk mengambil pesanan dan kemudian menyajikan minuman adalah waktu implementasi model.
• Keterlambatan dalam komunikasi, pembayaran, atau menemukan pesanan merupakan beban jaringan Anda.
• Lebih banyak pelanggan yang tiba sekaligus adalah konkurensi klien.
• Menambahkan lebih banyak barista atau lebih banyak komputer seperti meningkatkan konkurensi server Anda.

Seperti di kafe yang bagus, ada batasan berapa banyak yang dapat ditangani staf sekaligus. Jika Anda tidak merencanakan ke depan — misalnya, dengan cara membawa lebih banyak barista selama jam sibuk — orang-orang pergi dengan perasaan tidak bahagia. Hal yang sama berlaku untuk sistem Anda di bawah beban. Pengujian beban membantu Anda mengidentifikasi di mana hambatan berada, berapa banyak lalu lintas yang dapat ditangani sistem Anda, dan perubahan apa yang perlu Anda lakukan untuk layanan yang lebih lancar.

Sebelum menjalankan uji beban pada titik akhir, Anda perlu:

• Pahami komponen dan konsep yang terkait dengan pengujian beban.
• Putuskan dan definisikan persyaratan produksi Anda.
• Temukan payload yang representatif untuk kerangka uji beban yang akan digunakan saat melakukan pengukuran kinerja endpoint Anda.

Memuat konsep dan definisi pengujian

Tabel berikut mendefinisikan konsep terkait pengujian beban:

Konsep	Deskripsi
Konkurensi klien (jumlah klien)	Jumlah total klien yang secara bersamaan mengirim permintaan secara paralel ke titik akhir. Ini adalah pelanggan Anda ke kafe dalam contoh di atas. Produksi: Total instans klien yang mengirim lalu lintas ke model yang melayani titik akhir. Uji beban: Dalam Locust, ini adalah jumlah pengguna yang dibuat untuk mengirim lalu lintas ke titik akhir model yang sedang diuji bebannya.
Konkurensi titik akhir	Jumlah proses inferensi atau instans model yang dapat menangani permintaan masuk. Juga dapat diekspresikan sebagai jumlah permintaan yang dapat ditangani secara bersamaan oleh endpoint Anda. Ini adalah jumlah barista dalam contoh di atas. Penyajian Model AI Mosaic: Titik akhir penyajian model dapat dikonfigurasi untuk ukuran ekspansi komputasi. Misalnya, menggunakan Small ukuran titik akhir CPU membuat empat instans model Anda di titik akhir.
Latensi	Waktu (dalam milidetik) untuk menyelesaikan permintaan pulang pergi penuh. Ukuran total waktu setelah klien mengirim permintaan hingga respons diterima, termasuk waktu proses titik akhir dan latensi jaringan.
Latensi PXX (P50,P90,P99)	Latensi (dalam milidetik) di mana persentil permintaan XX telah selesai lebih cepat daripada. Misalnya, P90 30ms berarti bahwa 90% dari semua permintaan telah selesai dalam 30ms atau kurang.
Permintaan per detik (RPS)	Jumlah permintaan yang diselesaikan per detik. Selesai berarti respons dikembalikan dari titik akhir ke klien.

Persyaratan latensi

Berdasarkan kebutuhan bisnis dan pelanggan Anda, tentukan performa ideal sistem Anda. Pada model yang melayani titik akhir, latensi mencakup waktu pulang pergi yang dialami klien saat mengirim data untuk inferensi. Ini termasuk latensi jaringan serta waktu inferensi. Penting untuk memastikan bahwa kebutuhan Anda realistis. Misalnya, jika model Anda membutuhkan waktu 15ms untuk melakukan inferensi saat dimuat ke dalam memori, Anda perlu mengizinkan waktu tambahan untuk latensi jaringan saat disajikan pada model yang melayani titik akhir.

Bagaimana hubungan RPS, latensi, dan keserentakan?

Bisnis memiliki beberapa kriteria yang ditentukan untuk keberhasilan sistem mereka. Untuk sistem ML, kriteria bisnis umumnya adalah hasil berkualitas tinggi, latensi rendah, dan throughput tinggi. Kualitas hasil secara khusus terkait dengan model itu sendiri, sementara latensi dan throughput end-to-end adalah sifat dari sistem penyajian data. Latensi end-to-end terdiri dari waktu eksekusi model dan overhead jaringan. Throughput (atau permintaan atau kueri per detik) secara terbalik terkait dengan latensi dan terkait langsung dengan konkurensi.

• Semakin banyak konkurensi, semakin tinggi throughput.
• Semakin tinggi latensi, semakin rendah kemampuan pemrosesan data.

Umumnya, ada rasio optimal konkurensi sisi klien terhadap konkurensi sisi server untuk aplikasi tertentu. Sebagai contoh, "berapa banyak burger yang bisa dikerjakan koki bagian secara bersamaan". Karena mungkin ada banyak langkah bersama dalam proses memasak, koki baris mungkin dapat mengoptimalkan memasak empat hamburger pada waktu yang sama daripada memasak hanya satu per satunya. Ada batasan untuk paralelisasi ini, pada titik tertentu tindakan melakukan banyak tindakan paralel menambahkan terlalu banyak latensi, seperti jika koki perlu menambahkan keju ke 1000 burger.

Salah satu tujuan utama dari uji beban adalah untuk menentukan rasio optimal untuk aplikasi Anda. Rasio optimal memaksimalkan RPS, memenuhi persyaratan latensi Anda, dan menghindari antrean. Rasio ini dapat digunakan untuk mengukur titik akhir Anda secara akurat untuk memenuhi beban Anda yang paling menuntut.

Jika titik akhir tidak dapat memproses permintaan dengan cukup cepat, garis mulai terbentuk. Ini disebut antrean. Pembentukan antrean biasanya berakibat pada latensi end-to-end yang lebih lama karena menambah waktu tunggu setiap permintaan sebelum diproses. Jika permintaan terus tiba lebih cepat daripada permintaan dapat diproses, antrean akan tumbuh, yang semakin meningkatkan latensi. Untuk alasan ini, penting untuk memahami permintaan puncak seperti apa yang mungkin dialami titik akhir Anda dan memastikannya berukuran benar dengan uji beban.

Memuat contoh skenario pengujian

Dalam pengujian beban, serta sistem dunia nyata, hubungan antara konkurensi klien, konkurensi server, dan latensi bersifat dinamis dan saling bergantung. Mari kita lihat hubungan ini dengan contoh sederhana:

Skenario 1: Penyiapan sederhana

Dalam penyiapan ini, satu klien mengirim permintaan secara berurutan - klien menunggu respons sebelum mengeluarkan permintaan berikutnya. Karena total waktu per permintaan adalah jumlah eksekusi model dan latensi overhead (40 ms + 10 ms), latensi total yang diukur adalah 50 ms.

• Jumlah klien: 1
• Konkurensi yang disediakan: 1
• Latensi overhead: 10 ms
• Waktu eksekusi model 40 ms

Akibatnya, klien menyelesaikan satu permintaan setiap 50 mdtk, yang setara dengan 20 permintaan per detik atau kueri per detik.

Skenario 2: Meningkatkan konkurensi yang disediakan

Dalam hal ini, Anda memiliki dua kali lipat konkurensi yang disediakan dan satu klien membuat permintaan secara berurutan. Ini berarti bahwa total latensi masih 50 ms (40ms + 10ms), dan sistem hanya melihat 20 permintaan per detik (QPS).

• Jumlah klien: 1
• Konkurensi yang disediakan: 1 -> 2
• Latensi overhead: 10 ms
• Waktu eksekusi model 40 ms

Skenario 3: Tambahkan klien lain ke sistem.

Sekarang Anda memiliki dua klien yang membuat permintaan ke titik akhir dengan dua konkurensi yang telah disediakan. Dalam hal ini, setiap permintaan klien dapat diproses secara independen oleh titik akhir secara bersamaan (dengan asumsi penyeimbangan beban yang sempurna). Jadi sementara total latensi masih 50 ms (40ms + 10ms), sistem mengamati 40 permintaan per detik, karena setiap klien mengirim 20 qps.

• Jumlah klien: 1 -> 2
• Konkurensi yang disediakan: 2
• Latensi overhead: 10 ms
• Waktu eksekusi model 40 ms

** Meningkatkan konkurensi yang telah ditetapkan dan jumlah klien yang membuat permintaan meningkatkan total QPS yang diamati dalam sistem Anda, tanpa mengorbankan latensi.

Skenario 4: Mari kurangi konkurensi yang disediakan

Dalam skenario terakhir ini, jumlah klien lebih besar dari konkurensi yang disediakan. Pengaturan ini memperkenalkan variabel lain, antrean, dalam sistem dan efeknya pada QPS dan latensi.

• Jumlah klien: 2
• Konkurensi yang disediakan: 2 -> 1
• Latensi overhead: 10 ms
• Waktu eksekusi model: 40 ms

Di sini, Anda memiliki dua klien yang membuat permintaan secara bersamaan. Namun, titik akhir hanya dapat memproses satu permintaan pada satu waktu. Ini memaksa permintaan kedua untuk menunggu sebelum permintaan pertama diproses. Menunggu, atau lebih tepat, pengantrean permintaan kedua dapat berdampak buruk pada latensi sistem. Dengan asumsi bahwa server memungkinkan antrean (diaktifkan secara default dalam Databricks Model Serving), klien kedua melihat latensi 90 ms: 10 ms (overhead jaringan) + 40 ms (waktu tunggu antrean) + 40 ms (waktu eksekusi model). Ini secara signifikan lebih buruk dari 50 ms yang terlihat sebelumnya.