Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Pemecahan Masalah
Berikut ini FAQs dapat membantu Anda memecahkan masalah dengan titik akhir Inferensi SageMaker Asinkron Amazon Anda.
Anda dapat menggunakan metode berikut untuk menemukan jumlah instance di belakang titik akhir Anda:
Anda dapat menggunakan SageMaker AI DescribeEndpointAPI untuk menjelaskan jumlah instance di belakang titik akhir pada titik waktu tertentu.
Anda bisa mendapatkan jumlah instans dengan melihat CloudWatch metrik Amazon Anda. Lihat metrik untuk instans titik akhir Anda, seperti
CPUUtilization
atauMemoryUtilization
dan periksa statistik jumlah sampel untuk periode 1 menit. Hitungannya harus sama dengan jumlah instance aktif. Tangkapan layar berikut menunjukkan grafikCPUUtilization
metrik di CloudWatch konsol, di mana Statistik diatur keSample count
, Periode diatur ke1 minute
, dan jumlah yang dihasilkan adalah 5.

Tabel berikut menguraikan variabel lingkungan umum yang dapat disetel untuk wadah SageMaker AI menurut jenis kerangka kerja.
TensorFlow
Variabel lingkungan | Deskripsi |
---|---|
|
Untuk model TensorFlow berbasis, |
|
Parameter ini mengatur fraksi memori GPU yang tersedia untuk menginisialisasi CUDA/cuDNN dan pustaka GPU lainnya. |
|
Ini mengikat kembali ke |
|
Ini mengikat kembali ke |
|
Ini mengatur jumlah proses pekerja yang diminta Gunicorn untuk menelurkan untuk menangani permintaan. Nilai ini digunakan dalam kombinasi dengan parameter lain untuk mendapatkan satu set yang memaksimalkan throughput inferensi. Selain itu, |
|
Ini mengatur jumlah proses pekerja yang diminta Gunicorn untuk menelurkan untuk menangani permintaan. Nilai ini digunakan dalam kombinasi dengan parameter lain untuk mendapatkan satu set yang memaksimalkan throughput inferensi. Selain itu, |
|
Python secara internal menggunakan OpenMP untuk mengimplementasikan multithreading dalam proses. Biasanya, thread yang setara dengan jumlah core CPU muncul. Tetapi ketika diimplementasikan di atas Simultaneous Multi Threading (SMT), seperti Intel HypeThreading, proses tertentu mungkin kelebihan langganan inti tertentu dengan menelurkan utas dua kali lebih banyak daripada jumlah inti CPU yang sebenarnya. Dalam kasus tertentu, biner Python mungkin berakhir dengan pemijahan hingga empat kali lebih banyak utas daripada inti prosesor yang tersedia. Oleh karena itu, pengaturan ideal untuk parameter ini, jika Anda memiliki kelebihan langganan core yang tersedia menggunakan thread pekerja, adalah |
|
Dalam beberapa kasus, mematikan MKL dapat mempercepat inferensi jika |
PyTorch
Variabel lingkungan | Deskripsi |
---|---|
|
Ini adalah waktu tunda batch maksimum yang TorchServe menunggu untuk diterima. |
|
Jika TorchServe tidak menerima jumlah permintaan yang ditentukan |
|
Jumlah minimum pekerja yang TorchServe diizinkan untuk menurunkan skala. |
|
Jumlah maksimum pekerja yang TorchServe diizinkan untuk ditingkatkan. |
|
Waktu tunda, setelah itu waktu inferensi habis tanpa adanya respons. |
|
Ukuran muatan maksimum untuk TorchServe. |
|
Ukuran respons maksimum untuk TorchServe. |
Server Multi Model (MMS)
Variabel lingkungan | Deskripsi |
---|---|
|
Parameter ini berguna untuk disetel ketika Anda memiliki skenario di mana jenis payload permintaan inferensi besar, dan karena ukuran payload yang lebih besar, Anda mungkin memiliki konsumsi memori heap yang lebih tinggi dari JVM di mana antrian ini sedang dipertahankan. Idealnya Anda mungkin ingin menjaga persyaratan memori heap JVM lebih rendah dan memungkinkan pekerja Python membagikan lebih banyak memori untuk penyajian model yang sebenarnya. JVM hanya untuk menerima permintaan HTTP, mengantri, dan mengirimkannya ke pekerja berbasis Python untuk inferensi. Jika Anda meningkatkan |
|
Parameter ini untuk penyajian model backend dan mungkin berharga untuk disetel karena ini adalah komponen penting dari keseluruhan penyajian model, berdasarkan proses Python menelurkan utas untuk setiap Model. Jika komponen ini lebih lambat (atau tidak disetel dengan benar), penyetelan front-end mungkin tidak efektif. |
Anda dapat menggunakan wadah yang sama untuk Inferensi Asinkron yang Anda lakukan untuk Inferensi Waktu Nyata atau Transformasi Batch. Anda harus mengonfirmasi bahwa batas waktu tunggu dan ukuran muatan pada kontainer Anda diatur untuk menangani muatan yang lebih besar dan batas waktu yang lebih lama.
Lihat batas berikut untuk Inferensi Asinkron:
Batas ukuran muatan: 1 GB
Batas waktu tunggu: Permintaan dapat memakan waktu hingga 60 menit.
Pesan antrian TimeToLive (TTL): 6 jam
Jumlah pesan yang dapat dimasukkan ke dalam Amazon SQS: Tidak terbatas. Namun, ada kuota 120.000 untuk jumlah pesan dalam penerbangan untuk antrian standar, dan 20.000 untuk antrian FIFO.
Secara umum, dengan Asynchronous Inference, Anda dapat menskalakan berdasarkan pemanggilan atau instance. Untuk metrik pemanggilan, ada baiknya untuk melihat metrik AndaApproximateBacklogSize
, yang merupakan metrik yang menentukan jumlah item dalam antrian Anda yang belum diproses. Anda dapat menggunakan metrik ini atau InvocationsPerInstance
metrik Anda untuk memahami TPS apa yang mungkin membuat Anda terhambat. Pada tingkat instans, periksa jenis instans Anda dan pemanfaatan CPU/GPU-nya untuk menentukan kapan harus menskalakan. Jika instance tunggal di atas kapasitas 60-70%, ini sering merupakan pertanda baik bahwa Anda menjenuhkan perangkat keras Anda.
Kami tidak menyarankan memiliki beberapa kebijakan penskalaan, karena ini dapat bertentangan dan menyebabkan kebingungan di tingkat perangkat keras, menyebabkan penundaan saat penskalaan keluar.
Periksa apakah kontainer Anda dapat menangani permintaan ping dan memanggil secara bersamaan. SageMaker Permintaan pemanggilan AI memakan waktu sekitar 3 menit, dan dalam durasi ini, biasanya beberapa permintaan ping akhirnya gagal karena batas waktu yang menyebabkan SageMaker AI mendeteksi wadah Anda sebagai. Unhealthy
Ya. MaxConcurrentInvocationsPerInstance
adalah fitur titik akhir asinkron. Ini tidak tergantung pada implementasi wadah khusus. MaxConcurrentInvocationsPerInstance
mengontrol tingkat di mana permintaan pemanggilan dikirim ke wadah pelanggan. Jika nilai ini ditetapkan sebagai1
, maka hanya 1 permintaan yang dikirim ke wadah sekaligus, tidak peduli berapa banyak pekerja yang ada di wadah pelanggan.
Kesalahan berarti bahwa wadah pelanggan mengembalikan kesalahan. SageMaker AI tidak mengontrol perilaku kontainer pelanggan. SageMaker AI hanya mengembalikan respons dari ModelContainer
dan tidak mencoba lagi. Jika mau, Anda dapat mengonfigurasi pemanggilan untuk mencoba lagi pada kegagalan. Kami menyarankan Anda mengaktifkan pencatatan kontainer dan memeriksa log penampung Anda untuk menemukan akar penyebab kesalahan 500 dari model Anda. Periksa MemoryUtilization
metrik yang sesuai CPUUtilization
dan pada titik kegagalan juga. Anda juga dapat mengonfigurasi S3 FailurePath ke respons model di Amazon SNS sebagai bagian dari Pemberitahuan Kesalahan Async untuk menyelidiki kegagalan.
Anda dapat memeriksa metrikInvocationsProcesssed
, yang seharusnya sejajar dengan jumlah pemanggilan yang Anda harapkan akan diproses dalam satu menit berdasarkan konkurensi tunggal.
Praktik terbaik adalah mengaktifkan Amazon SNS, yang merupakan layanan notifikasi untuk aplikasi berorientasi pesan, dengan beberapa pelanggan yang meminta dan menerima pemberitahuan “push” pesan kritis waktu dari pilihan protokol transportasi, termasuk HTTP, Amazon SQS, dan email. Inferensi asinkron memposting pemberitahuan saat Anda membuat titik akhir dengan CreateEndpointConfig
dan menentukan topik Amazon SNS.
Untuk menggunakan Amazon SNS untuk memeriksa hasil prediksi dari titik akhir asinkron Anda, Anda harus terlebih dahulu membuat topik, berlangganan topik, mengonfirmasi langganan Anda ke topik, dan mencatat Nama Sumber Daya Amazon (ARN) dari topik tersebut. Untuk informasi terperinci tentang cara membuat, berlangganan, dan menemukan Amazon ARN dari topik Amazon SNS, lihat Mengonfigurasi Amazon SNS di Panduan Pengembang Amazon SNS. Untuk informasi selengkapnya tentang cara menggunakan Amazon SNS dengan Inferensi Asinkron, lihat Periksa hasil prediksi.
Ya. Inferensi Asinkron menyediakan mekanisme untuk menurunkan skala ke nol instance ketika tidak ada permintaan. Jika titik akhir Anda telah diperkecil menjadi nol instans selama periode ini, maka titik akhir Anda tidak akan ditingkatkan lagi hingga jumlah permintaan dalam antrian melebihi target yang ditentukan dalam kebijakan penskalaan Anda. Hal ini dapat mengakibatkan waktu tunggu yang lama untuk permintaan dalam antrian. Dalam kasus seperti itu, jika Anda ingin meningkatkan dari nol instance untuk permintaan baru yang kurang dari target antrian yang ditentukan, Anda dapat menggunakan kebijakan penskalaan tambahan yang disebut. HasBacklogWithoutCapacity
Untuk informasi selengkapnya tentang cara mendefinisikan kebijakan penskalaan ini, lihat Menskalakan otomatis titik akhir asinkron.
Untuk daftar lengkap instance yang didukung oleh Inferensi Asinkron per wilayah, lihat harga AI. SageMaker