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.
## T: Saya mengaktifkan penskalaan otomatis. Bagaimana saya bisa menemukan jumlah instance di belakang titik akhir pada titik tertentu?
Anda dapat menggunakan metode berikut untuk menemukan jumlah instance di belakang titik akhir Anda:
+ Anda dapat menggunakan SageMaker AI [DescribeEndpoint](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeEndpoint.html)API 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](https://docs.aws.amazon.com/sagemaker/latest/dg/monitoring-cloudwatch.html#cloudwatch-metrics-jobs), seperti `CPUUtilization` atau `MemoryUtilization` dan periksa statistik jumlah sampel untuk periode 1 menit. Hitungannya harus sama dengan jumlah instance aktif. Tangkapan layar berikut menunjukkan grafik `CPUUtilization` metrik di CloudWatch konsol, di mana **Statistik** diatur ke`Sample count`, **Periode** diatur ke`1 minute`, dan jumlah yang dihasilkan adalah 5.
## T: Apa variabel lingkungan umum yang dapat disetel untuk wadah SageMaker AI?
Tabel berikut menguraikan variabel lingkungan umum yang dapat disetel untuk wadah SageMaker AI menurut jenis kerangka kerja.
**TensorFlow**
| Variabel lingkungan | Deskripsi |
| --- | --- |
| `SAGEMAKER_TFS_INSTANCE_COUNT` | Untuk model TensorFlow berbasis, `tensorflow_model_server` biner adalah bagian operasional yang bertanggung jawab untuk memuat model dalam memori, menjalankan input terhadap grafik model, dan menurunkan output. Biasanya, satu contoh biner ini diluncurkan untuk melayani model di titik akhir. Biner ini secara internal multi-threaded dan memunculkan beberapa utas untuk menanggapi permintaan inferensi. Dalam kasus tertentu, jika Anda mengamati bahwa CPU digunakan dengan baik (lebih dari 30% digunakan) tetapi memori kurang dimanfaatkan (kurang dari 10% penggunaan), meningkatkan parameter ini dapat membantu. Meningkatkan jumlah yang `tensorflow_model_servers` tersedia untuk melayani biasanya meningkatkan throughput dari titik akhir. |
| `SAGEMAKER_TFS_FRACTIONAL_GPU_MEM_MARGIN` | Parameter ini mengatur fraksi memori GPU yang tersedia untuk menginisialisasi CUDA/cuDNN dan pustaka GPU lainnya. `0.2`berarti 20% dari memori GPU yang tersedia dicadangkan untuk menginisialisasi CUDA/cuDNN dan pustaka GPU lainnya, dan 80% dari memori GPU yang tersedia dialokasikan secara merata di seluruh proses TF. Memori GPU sudah dialokasikan sebelumnya kecuali `allow_growth` opsi diaktifkan. |
| `SAGEMAKER_TFS_INTER_OP_PARALLELISM` | Ini mengikat kembali ke `inter_op_parallelism_threads` variabel. Variabel ini menentukan jumlah utas yang digunakan oleh operasi non-pemblokiran independen. `0`berarti bahwa sistem memilih nomor yang sesuai. |
| `SAGEMAKER_TFS_INTRA_OP_PARALLELISM` | Ini mengikat kembali ke `intra_op_parallelism_threads` variabel. Ini menentukan jumlah utas yang dapat digunakan untuk operasi tertentu seperti perkalian matriks dan pengurangan untuk percepatan. Nilai `0` berarti bahwa sistem memilih nomor yang sesuai. |
| `SAGEMAKER_GUNICORN_WORKERS` | 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, `SAGEMAKER_GUNICORN_WORKER_CLASS` mengatur jenis pekerja yang melahirkan, biasanya atau. `async` `gevent` |
| `SAGEMAKER_GUNICORN_WORKER_CLASS` | 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, `SAGEMAKER_GUNICORN_WORKER_CLASS` mengatur jenis pekerja yang melahirkan, biasanya atau. `async` `gevent` |
| `OMP_NUM_THREADS` | 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`1`, atau setengah jumlah core CPU pada CPU dengan SMT dihidupkan. |
| `TF_DISABLE_MKL`
`TF_DISABLE_POOL_ALLOCATOR` | Dalam beberapa kasus, mematikan MKL dapat mempercepat inferensi jika `TF_DISABLE_MKL` dan `TF_DISABLE_POOL_ALLOCATOR` disetel ke. `1` |
**PyTorch**
| Variabel lingkungan | Deskripsi |
| --- | --- |
| `SAGEMAKER_TS_MAX_BATCH_DELAY` | Ini adalah waktu tunda batch maksimum yang TorchServe menunggu untuk diterima. |
| `SAGEMAKER_TS_BATCH_SIZE` | Jika TorchServe tidak menerima jumlah permintaan yang ditentukan `batch_size` sebelum timer habis, itu akan mengirimkan permintaan yang diterima ke handler model. |
| `SAGEMAKER_TS_MIN_WORKERS` | Jumlah minimum pekerja yang TorchServe diizinkan untuk menurunkan skala. |
| `SAGEMAKER_TS_MAX_WORKERS` | Jumlah maksimum pekerja yang TorchServe diizinkan untuk ditingkatkan. |
| `SAGEMAKER_TS_RESPONSE_TIMEOUT` | Waktu tunda, setelah itu waktu inferensi habis tanpa adanya respons. |
| `SAGEMAKER_TS_MAX_REQUEST_SIZE` | Ukuran muatan maksimum untuk TorchServe. |
| `SAGEMAKER_TS_MAX_RESPONSE_SIZE` | Ukuran respons maksimum untuk TorchServe. |
**Server Multi Model (MMS)**
| Variabel lingkungan | Deskripsi |
| --- | --- |
| `job_queue_size` | 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`job_queue_size`, Anda mungkin akhirnya meningkatkan konsumsi memori heap JVM dan akhirnya mengambil memori dari host yang bisa digunakan oleh pekerja Python. Karena itu, berhati-hatilah saat menyetel parameter ini juga. |
| `default_workers_per_model` | 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. |
## T: Bagaimana cara memastikan wadah saya mendukung Inferensi Asinkron?
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.
## T: Apa batas khusus untuk Inferensi Asinkron, dan dapatkah mereka disesuaikan?
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.
## T: Metrik apa yang terbaik untuk didefinisikan untuk penskalaan otomatis pada Inferensi Asinkron? Bisakah saya memiliki beberapa kebijakan penskalaan?
Secara umum, dengan Asynchronous Inference, Anda dapat menskalakan berdasarkan pemanggilan atau instance. Untuk metrik pemanggilan, ada baiknya untuk melihat metrik Anda`ApproximateBacklogSize`, 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.
## T: Mengapa titik akhir asinkron saya mengakhiri instance sebagai `Unhealthy` dan permintaan pembaruan dari penskalaan otomatis gagal?
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`
## T: Dapatkah `MaxConcurrentInvocationsPerInstance` bekerja untuk wadah model BYOC saya dengan pengaturan? ningx/gunicorn/flask
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 sebagai`1`, maka hanya 1 permintaan yang dikirim ke wadah sekaligus, tidak peduli berapa banyak pekerja yang ada di wadah pelanggan.
## T: Bagaimana cara men-debug kesalahan server model (500) pada titik akhir asinkron saya?
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](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_AsyncInferenceOutputConfig.html#sagemaker-Type-AsyncInferenceOutputConfig-S3FailurePath) ke respons model di Amazon SNS sebagai bagian dari Pemberitahuan Kesalahan Async untuk menyelidiki kegagalan.
## T: Bagaimana saya bisa tahu jika `MaxConcurrentInvocationsPerInstance=1` berlaku? Apakah ada metrik yang bisa saya periksa?
Anda dapat memeriksa metrik`InvocationsProcesssed`, yang seharusnya sejajar dengan jumlah pemanggilan yang Anda harapkan akan diproses dalam satu menit berdasarkan konkurensi tunggal.
## T: Bagaimana saya bisa melacak keberhasilan dan kegagalan permintaan doa saya? Apa praktik terbaik?
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](https://docs.aws.amazon.com/sns/latest/dg/sns-configuring.html). [Untuk informasi selengkapnya tentang cara menggunakan Amazon SNS dengan Inferensi Asinkron, lihat Periksa hasil prediksi.](https://docs.aws.amazon.com/sagemaker/latest/dg/async-inference-check-predictions.html)
## T: Dapatkah saya menentukan kebijakan penskalaan yang meningkatkan skala dari nol instans setelah menerima permintaan baru?
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](https://docs.aws.amazon.com/sagemaker/latest/dg/async-inference-autoscale.html#async-inference-autoscale-scale-up) asinkron.
## T: Saya mendapatkan kesalahan bahwa jenis instance tidak didukung untuk Inferensi Asinkron. Apa saja tipe instance yang didukung Asynchronous Inference?
[Untuk daftar lengkap instance yang didukung oleh Inferensi Asinkron per wilayah, lihat harga. SageMaker ](https://aws.amazon.com/sagemaker/pricing/) Periksa apakah instans yang diperlukan tersedia di wilayah Anda sebelum melanjutkan.