Memperkenalkan Toolkit Pembandingan Inferensi Tanpa Server Amazon SageMaker

Inferensi Tanpa Server Amazon SageMaker adalah opsi inferensi yang dibuat khusus yang memudahkan Anda untuk menerapkan dan menskalakan model machine learning (ML). Ini menyediakan model bayar per penggunaan, yang ideal untuk layanan di mana pemanggilan titik akhir jarang terjadi dan tidak dapat diprediksi. Tidak seperti titik akhir hosting waktu nyata, yang didukung oleh instans yang berjalan lama, sumber daya komputasi untuk titik akhir tanpa server disediakan sesuai permintaan, sehingga menghilangkan kebutuhan untuk memilih jenis instans atau mengelola kebijakan penskalaan.

Arsitektur tingkat tinggi berikut mengilustrasikan cara kerja titik akhir tanpa server. Klien memanggil titik akhir, yang didukung oleh infrastruktur terkelola AWS.

Namun, endpoint tanpa server rentan terhadap cold start dalam urutan detik, dan oleh karena itu lebih cocok untuk beban kerja yang terputus-putus atau tidak dapat diprediksi.

Untuk membantu menentukan apakah titik akhir tanpa server adalah opsi penerapan yang tepat dari perspektif biaya dan kinerja, kami telah mengembangkan Perangkat Pembandingan Inferensi Tanpa Server SageMaker, yang menguji konfigurasi titik akhir yang berbeda dan membandingkan yang paling optimal dengan instans hosting waktu nyata yang sebanding.

Dalam posting ini, kami memperkenalkan toolkit dan memberikan gambaran umum tentang konfigurasi dan outputnya.

Ikhtisar solusi

Anda dapat mengunduh toolkit dan menginstalnya dari GitHub repo. Memulainya mudah: cukup instal perpustakaan, buat Model SageMaker, dan berikan nama model Anda bersama dengan file berformat baris JSON yang berisi kumpulan sampel parameter pemanggilan, termasuk badan muatan dan jenis konten. Fungsi kenyamanan disediakan untuk mengonversi daftar argumen permintaan sampel ke file baris JSON atau file acar untuk muatan biner seperti gambar, video, atau audio.

Instal toolkitnya

Pertama-tama instal pustaka pembandingan ke lingkungan Python Anda menggunakan pip:

pip install sm-serverless-benchmarking

Anda dapat menjalankan kode berikut dari Studio Amazon SageMaker contoh, Instance notebook SageMaker, atau contoh apa pun dengan akses terprogram ke AWS dan yang sesuai Identitas AWS dan Manajemen Akses (IAM). Izin IAM yang diperlukan didokumentasikan dalam GitHub repo. Untuk panduan tambahan dan contoh kebijakan untuk IAM, lihat Cara Kerja Amazon SageMaker dengan IAM. Kode ini menjalankan benchmark dengan set parameter default pada model yang mengharapkan input CSV dengan dua contoh record. Ini adalah praktik yang baik untuk memberikan serangkaian contoh yang representatif untuk menganalisis bagaimana kinerja titik akhir dengan muatan input yang berbeda.

from sm_serverless_benchmarking import benchmark
from sm_serverless_benchmarking.utils import convert_invoke_args_to_jsonl
model_name = ""
example_invoke_args = [
        {'Body': '1,2,3,4,5', "ContentType": "text/csv"},
        {'Body': '6,7,8,9,10', "ContentType": "text/csv"}
        ]
example_args_file = convert_invoke_args_to_jsonl(example_invoke_args,
output_path=".")
r = benchmark.run_serverless_benchmarks(model_name, example_args_file)

Selain itu, Anda dapat menjalankan tolok ukur sebagai pekerjaan Pemrosesan SageMaker, yang mungkin merupakan opsi yang lebih andal untuk tolok ukur yang berjalan lebih lama dengan sejumlah besar pemanggilan. Lihat kode berikut:

from sm_serverless_benchmarking.sagemaker_runner import run_as_sagemaker_job
run_as_sagemaker_job(
                    role="",
                    model_name="",
                    invoke_args_examples_file="",
                    )

Perhatikan bahwa ini akan dikenakan biaya tambahan untuk menjalankan instans Pemrosesan SageMaker ml.m5.large selama durasi benchmark.

Kedua metode menerima sejumlah parameter untuk dikonfigurasi, seperti daftar konfigurasi memori untuk dijadikan patokan dan berapa kali setiap konfigurasi akan dipanggil. Dalam kebanyakan kasus, opsi default sudah cukup sebagai titik awal, tetapi lihat: GitHub repo untuk daftar lengkap dan deskripsi setiap parameter.

Konfigurasi pembandingan

Sebelum mempelajari apa yang dilakukan benchmark dan output apa yang dihasilkannya, penting untuk memahami beberapa konsep utama dalam hal mengonfigurasi endpoint tanpa server.

Ada dua opsi konfigurasi utama: MemorySizeInMB dan MaxConcurrency. MemorySizeInMB mengonfigurasi jumlah memori yang dialokasikan ke instans, dan dapat berupa 1024 MB, 2048 MB, 3072 MB, 4096 MB, 5120 MB, atau 6144 MB. Jumlah vCPU juga diskalakan secara proporsional dengan jumlah memori yang dialokasikan. Itu MaxConcurrency parameter menyesuaikan berapa banyak permintaan bersamaan yang dapat dilayani oleh titik akhir. Dengan MaxConcurrency dari 1, titik akhir tanpa server hanya dapat memproses satu permintaan dalam satu waktu.

Untuk meringkas, MemorySizeInMB parameter menyediakan mekanisme untuk skalabilitas vertikal, memungkinkan Anda untuk menyesuaikan memori dan sumber daya komputasi untuk melayani model yang lebih besar, sedangkan MaxConcurrency menyediakan mekanisme untuk skalabilitas horizontal, memungkinkan titik akhir Anda memproses lebih banyak permintaan bersamaan.

Biaya pengoperasian titik akhir sebagian besar ditentukan oleh ukuran memori, dan tidak ada biaya yang terkait dengan peningkatan konkurensi maks. Namun, ada batas akun per Wilayah untuk konkurensi maksimum di semua titik akhir. Mengacu pada Titik akhir dan kuota SageMaker untuk batasan terbaru.

Output pembandingan

Mengingat hal ini, tujuan pembandingan titik akhir tanpa server adalah untuk menentukan setelan ukuran memori yang paling hemat biaya dan andal, serta konkurensi maksimum minimum yang dapat menangani pola lalu lintas yang Anda harapkan.

Secara default, alat ini menjalankan dua tolok ukur. Yang pertama adalah tolok ukur stabilitas, yang menyebarkan titik akhir untuk setiap konfigurasi memori yang ditentukan dan memanggil setiap titik akhir dengan muatan sampel yang disediakan. Tujuan dari benchmark ini adalah untuk menentukan pengaturan MemorySizeInMB yang paling efektif dan stabil. Tolok ukur menangkap latensi pemanggilan dan menghitung biaya per pemanggilan yang diharapkan untuk setiap titik akhir. Kemudian membandingkan biaya dengan contoh hosting real-time yang serupa.

Ketika benchmarking selesai, alat ini menghasilkan beberapa output dalam spesifikasi yang ditentukan result_save_path direktori dengan struktur direktori berikut:

├── benchmarking_report
├── concurrency_benchmark_raw_results
├── concurrency_benchmark_summary_results
├── cost_analysis_summary_results
├── stability_benchmark_raw_results
├── stability_benchmark_summary_results

Grafik benchmarking_report direktori berisi laporan konsolidasi dengan semua output ringkasan yang kami uraikan dalam posting ini. Direktori tambahan berisi output mentah dan menengah yang dapat Anda gunakan untuk analisis tambahan. Mengacu kepada GitHub repo untuk penjelasan lebih rinci tentang setiap artefak keluaran.

Mari kita periksa beberapa keluaran pembandingan aktual untuk titik akhir yang melayani model MobileNetV2 TensorFlow visi komputer. Jika Anda ingin mereproduksi contoh ini, lihat contoh buku catatan direktori di repo GitHub.

Keluaran pertama dalam laporan gabungan adalah tabel ringkasan yang menyediakan metrik latensi minimum, rata-rata, sedang, dan maksimum untuk setiap MemorySizeInMB konfigurasi ukuran memori yang berhasil. Seperti yang ditunjukkan pada tabel berikut, rata-rata latensi pemanggilan (invocation_latency_mean) terus meningkat karena konfigurasi memori ditingkatkan menjadi 3072 MB, tetapi berhenti meningkat setelahnya.

Selain statistik deskriptif tingkat tinggi, disediakan bagan yang menunjukkan distribusi latensi seperti yang diamati dari klien untuk setiap konfigurasi memori. Sekali lagi, kita dapat mengamati bahwa konfigurasi 1024 MB tidak seperforma opsi lain, tetapi tidak ada perbedaan substansial dalam kinerja dalam konfigurasi 2048 dan di atasnya.

amazoncloudwatch metrik yang terkait dengan setiap konfigurasi titik akhir juga disediakan. Salah satu metrik kunci di sini adalah ModelSetupTime, yang mengukur berapa lama waktu yang dibutuhkan untuk memuat model saat titik akhir dipanggil dalam keadaan dingin. Metrik mungkin tidak selalu muncul dalam laporan karena titik akhir diluncurkan dalam keadaan hangat. SEBUAH cold_start_delay tersedia untuk menentukan jumlah detik untuk tidur sebelum memulai benchmark pada endpoint yang diterapkan. Menyetel parameter ini ke angka yang lebih tinggi seperti 600 detik akan meningkatkan kemungkinan pemanggilan status dingin dan meningkatkan peluang menangkap metrik ini. Selain itu, metrik ini jauh lebih mungkin ditangkap dengan tolok ukur pemanggilan serentak, yang akan kita bahas nanti di bagian ini.

Tabel berikut menunjukkan metrik yang ditangkap oleh CloudWatch untuk setiap konfigurasi memori.

Bagan berikutnya menunjukkan kinerja dan pertukaran biaya dari konfigurasi memori yang berbeda. Satu baris menunjukkan perkiraan biaya penerapan titik akhir 1 juta kali, dan baris lainnya menunjukkan latensi respons rata-rata. Metrik ini dapat menginformasikan keputusan Anda tentang konfigurasi titik akhir mana yang paling hemat biaya. Dalam contoh ini, kita melihat bahwa latensi rata-rata mendatar setelah 2048 MB, sedangkan biaya terus meningkat, yang menunjukkan bahwa untuk model ini, konfigurasi ukuran memori 2048 akan menjadi yang paling optimal.

Hasil akhir dari tolok ukur biaya dan stabilitas adalah konfigurasi memori yang disarankan, bersama dengan tabel yang membandingkan biaya pengoperasian titik akhir tanpa server dengan instans hosting SageMaker yang sebanding. Berdasarkan data yang dikumpulkan, alat menentukan bahwa konfigurasi 2048 MB adalah yang paling optimal untuk model ini. Meskipun konfigurasi 3072 memberikan latensi yang kira-kira 10 milidetik lebih baik, itu disertai dengan peningkatan biaya 30%, dari $4.55 menjadi $5.95 per 1 juta permintaan. Selain itu, output menunjukkan bahwa titik akhir tanpa server akan memberikan penghematan hingga 88.72% terhadap instans hosting waktu nyata yang sebanding ketika ada kurang dari 1 juta permintaan permintaan bulanan, dan titik impas dengan titik akhir waktu nyata setelah 8.5 juta permintaan.

Jenis benchmark kedua adalah opsional dan menguji berbagai MaxConcurency pengaturan di bawah pola lalu lintas yang berbeda. Benchmark ini biasanya dijalankan menggunakan optimal MemorySizeInMB konfigurasi dari benchmark stabilitas. Dua parameter utama untuk tolok ukur ini adalah daftar: MaxConcurency pengaturan untuk diuji bersama dengan daftar pengganda klien, yang menentukan jumlah klien serentak yang disimulasikan dengan titik akhir yang diuji.

Misalnya dengan mengatur concurrency_benchmark_max_conc parameter ke [4, 8] dan concurrency_num_clients_multiplier ke [1, 1.5, 2], dua titik akhir diluncurkan: satu dengan MaxConcurency dari 4 dan 8. Setiap titik akhir kemudian di-benchmark dengan (MaxConcurency x multiplier) jumlah klien bersamaan yang disimulasikan, yang untuk titik akhir dengan konkurensi 4 berarti memuat tolok ukur uji dengan 4, 6, dan 8 klien bersamaan.

Keluaran pertama dari tolok ukur ini adalah tabel yang menunjukkan metrik latensi, pengecualian pembatasan, dan metrik transaksi per detik (TPS) yang terkait dengan masing-masing MaxConcurrency konfigurasi dengan jumlah klien bersamaan yang berbeda. Metrik ini membantu menentukan yang sesuai MaxConcurrency pengaturan untuk menangani beban lalu lintas yang diharapkan. Pada tabel berikut, kita dapat melihat bahwa titik akhir yang dikonfigurasi dengan konkurensi maksimal 8 mampu menangani hingga 16 klien bersamaan dengan hanya dua pengecualian pelambatan dari 2,500 pemanggilan yang dilakukan pada rata-rata 24 transaksi per detik.

Set output berikutnya menyediakan bagan untuk masing-masing MaxConcurrency pengaturan yang menunjukkan distribusi latensi di bawah beban yang berbeda. Dalam contoh ini, kita dapat melihat bahwa titik akhir dengan MaxConcurrency pengaturan 4 berhasil memproses semua permintaan dengan hingga 8 klien bersamaan dengan peningkatan minimal dalam latensi pemanggilan.

Hasil akhir menyediakan tabel dengan metrik CloudWatch untuk masing-masing MaxConcurrency konfigurasi. Tidak seperti tabel sebelumnya yang menunjukkan distribusi latensi untuk setiap konfigurasi memori, yang mungkin tidak selalu menampilkan cold start ModelSetupTime metrik, metrik ini jauh lebih mungkin muncul di tabel ini karena jumlah permintaan pemanggilan yang lebih besar dan MaxConcurrency.

Kesimpulan

Dalam posting ini, kami memperkenalkan SageMaker Serverless Inference Benchmarking Toolkit dan memberikan gambaran umum tentang konfigurasi dan outputnya. Alat ini dapat membantu Anda membuat keputusan yang lebih tepat sehubungan dengan inferensi tanpa server dengan memuat pengujian konfigurasi yang berbeda dengan pola lalu lintas yang realistis. Coba toolkit benchmark dengan model Anda sendiri untuk melihat sendiri kinerja dan penghematan biaya yang dapat Anda harapkan dengan menerapkan endpoint tanpa server. Silakan merujuk ke GitHub repo untuk dokumentasi tambahan dan contoh buku catatan.

Sumber daya tambahan

Tentang penulis

Simon Zamarin adalah Arsitek Solusi AI / ML yang fokus utamanya membantu pelanggan mengekstrak nilai dari aset data mereka. Di waktu luangnya, Simon menikmati menghabiskan waktu bersama keluarga, membaca fiksi ilmiah, dan mengerjakan berbagai proyek rumah DIY.

Dhawal Patel adalah Arsitek Pembelajaran Mesin Utama di AWS. Dia telah bekerja dengan organisasi mulai dari perusahaan besar hingga perusahaan rintisan menengah pada masalah yang terkait dengan komputasi terdistribusi dan kecerdasan buatan. Dia berfokus pada pembelajaran mendalam, termasuk NLP dan domain visi komputer. Dia membantu pelanggan mencapai inferensi model performa tinggi di SageMaker.

Rishabh Ray Chaudhury adalah Manajer Produk Senior dengan Amazon SageMaker, yang berfokus pada inferensi pembelajaran mesin. Dia bersemangat dalam berinovasi dan membangun pengalaman baru bagi pelanggan machine learning di AWS untuk membantu menskalakan beban kerja mereka. Di waktu luangnya, dia suka bepergian dan memasak. Anda dapat menemukannya di LinkedIn.