Pemecahan Masalah - Amazon SageMaker AI

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 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 keSample count, Periode diatur ke1 minute, dan jumlah yang dihasilkan adalah 5.

CloudWatch konsol yang menampilkan grafik jumlah instance aktif untuk titik akhir.

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.2berarti 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. 0berarti 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, adalah1, 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 meningkatkanjob_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.

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. MaxConcurrentInvocationsPerInstanceadalah fitur titik akhir asinkron. Ini tidak tergantung pada implementasi wadah khusus. MaxConcurrentInvocationsPerInstancemengontrol 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 Periksa apakah instans yang diperlukan tersedia di wilayah Anda sebelum melanjutkan.