Pemecahan masalah penyebaran model jarak jauh

Pelajari cara memecahkan masalah dan menyelesaikan, atau mengatasi, kesalahan umum yang mungkin Anda alami saat menerapkan model ke Azure Container Instances (ACI) dan Azure Kubernetes Service (AKS) menggunakan Azure Machine Learning.

Catatan

Jika Anda menyebarkan model ke Azure Kubernetes Service (AKS), kami menyarankan untuk mengaktifkan Azure Monitor untuk kluster tersebut. Ini akan membantu Anda memahami keseluruhan kesehatan kluster dan penggunaan sumber daya. Anda mungkin juga menemukan kegunaan sumber daya berikut ini:

Jika Anda mencoba menyebarkan model ke kluster yang tidak sehat atau kelebihan beban, diperkirakan Anda akan mengalami masalah. Jika Anda memerlukan bantuan pemecahan masalah kluster AKS, silakan hubungi Dukungan AKS.

Prasyarat

Langkah-langkah untuk penerapan Docker model pembelajaran mesin

Saat Anda menyebarkan model ke komputasi non-lokal di Azure Machine Learning, hal-hal berikut ini akan terjadi:

  1. Dockerfile yang Anda tentukan di objek Lingkungan di InferenceConfig Anda dikirim ke cloud, bersama dengan konten direktori sumber Anda
  2. Jika gambar yang dibuat sebelumnya tidak tersedia di registri kontainer Anda, gambar Docker baru dibangun di cloud dan disimpan di registri kontainer default ruang kerja Anda.
  3. Gambar Docker dari registri kontainer Anda diunduh ke target komputasi Anda.
  4. Penyimpanan Blob default ruang kerja Anda dipasang ke target komputasi Anda, memberi Anda akses ke model terdaftar
  5. Server web Anda diinisialisasi dengan menjalankan fungsi init() skrip entri Anda
  6. Saat model yang Anda sebarkan menerima permintaan, run() fungsi Anda menangani permintaan tersebut

Perbedaan utama saat menggunakan penyebaran lokal adalah bahwa gambar kontainer dibangun di mesin lokal Anda, itulah sebabnya Anda perlu memasang Docker untuk penyebaran lokal.

Memahami langkah-langkah tingkat tinggi ini akan membantu Anda memahami tempat terjadinya kesalahan.

Mendapatkan log penyebaran

Langkah pertama dalam kesalahan debugging adalah mendapatkan log penyebaran Anda. Pertama, ikuti instruksi di sini untuk menyambungkan ke ruang kerja Anda.

Untuk mendapatkan log dari layanan web yang disebarkan, lakukan:

az ml service get-logs --verbose --workspace-name <my workspace name> --name <service name>

Mendebug secara lokal

Jika Anda mengalami masalah saat menyebarkan model ke ACI atau AKS, sebarkan model sebagai layanan web lokal. Menggunakan layanan web lokal memudahkan untuk memecahkan masalah. Untuk memecahkan masalah penyebaran secara lokal, lihat artikel pemecahan masalah lokal.

Server HTTP inferensi Azure Machine Learning

Server inferensi lokal memungkinkan Anda men-debug skrip entri (score.py) dengan cepat. Jika skrip skor yang mendasarinya memiliki bug, server akan gagal menginisialisasi atau melayani model. Sebaliknya, ini akan menghilangkan pengecualian & lokasi tempat masalah terjadi. Pelajari Server HTTP inferensi Azure Machine Learning lebih lanjut

  1. Pasang paket azureml-inference-server-http dari umpan pypi:

    python -m pip install azureml-inference-server-http
    
  2. Mulai server dan atur score.py sebagai skrip entri:

    azmlinfsrv --entry_script score.py
    
  3. Kirim permintaan penilaian ke server menggunakan curl:

    curl -p 127.0.0.1:5001/score
    

Kontainer tidak dapat dijadwalkan

Saat menyebarkan layanan ke target komputasi Azure Kubernetes Service, Azure Machine Learning akan mencoba menjadwalkan layanan dengan jumlah sumber daya yang diminta. Jika tidak ada simpul yang tersedia di kluster dengan jumlah sumber daya yang sesuai setelah 5 menit, penyebaran akan gagal. Pesan kegagalan adalah Couldn't Schedule because the kubernetes cluster didn't have available resources after trying for 00:05:00. Anda dapat mengatasi kesalahan ini dengan menambahkan lebih banyak simpul, mengubah SKU simpul Anda, atau mengubah persyaratan sumber daya layanan Anda.

Pesan kesalahan biasanya akan menunjukkan sumber daya mana yang lebih Anda butuhkan - misalnya, jika Anda melihat pesan kesalahan yang menunjukkan 0/3 nodes are available: 3 Insufficient nvidia.com/gpu bahwa layanan memerlukan GPU dan ada tiga simpul di kluster yang tidak memiliki GPU yang tersedia. Ini dapat diatasi dengan menambahkan lebih banyak simpul jika Anda menggunakan GPU SKU, beralih ke SKU yang diaktifkan GPU jika Anda tidak atau mengubah lingkungan Anda untuk tidak memerlukan GPU.

Peluncuran layanan gagal

Setelah gambar berhasil dibangun, sistem mencoba memulai kontainer menggunakan konfigurasi penyebaran Anda. Sebagai bagian dari proses start-up kontainer, fungsi init() dalam skrip penilaian Anda dipanggil oleh sistem. Jika ada pengecualian kesalahan yang tidak terdeteksi dalam fungsi init(), Anda mungkin melihat CrashLoopBackOff dalam pesan kesalahan.

Gunakan info di artikel Periksa log Docker.

Fungsi gagal: get_model_path()

Sering kali, dalam fungsi init()dalam fungsi skrip penilaian, fungsi Model.get_model_path() dipanggil untuk menemukan file model atau folder file model dalam kontainer. Jika file atau folder model tidak dapat ditemukan, fungsi akan gagal. Cara termudah untuk men-debug kesalahan ini adalah dengan menjalankan kode Python di shell Kontainer:

from azureml.core.model import Model
import logging
logging.basicConfig(level=logging.DEBUG)
print(Model.get_model_path(model_name='my-best-model'))

Contoh ini mencetak jalur lokal (relatif terhadap /var/azureml-app) dalam kontainer tempat skrip penilaian Anda diharapkan untuk menemukan file atau folder model. Kemudian Anda dapat memverifikasi apakah file atau folder memang berada di tempat yang diharapkan.

Menyetel tingkat pencatatan ke DEBUG dapat menyebabkan informasi tambahan dicatat, yang mungkin berguna dalam mengidentifikasi kegagalan.

Fungsi gagal: run(input_data)

Jika layanan berhasil disebarkan, tetapi mengalami crash saat Anda memposting data ke titik akhir penilaian, Anda dapat menambahkan pernyataan penangkapan kesalahan dalam run(input_data) fungsi Anda sehingga mengembalikan pesan kesalahan terperinci sebagai gantinya. Contohnya:

def run(input_data):
    try:
        data = json.loads(input_data)['data']
        data = np.array(data)
        result = model.predict(data)
        return json.dumps({"result": result.tolist()})
    except Exception as e:
        result = str(e)
        # return error message back to the client
        return json.dumps({"error": result})

Catatan: Mengembalikan pesan kesalahan dari panggilan run(input_data) harus dilakukan hanya untuk tujuan debugging. Untuk alasan keamanan, Anda tidak boleh mengembalikan pesan kesalahan dengan cara ini di lingkungan produksi.

Kode status HTTP 502

Kode status 502 menunjukkan bahwa layanan telah melemparkan pengecualian atau crash dalam metode run() file score.py. Gunakan informasi dalam artikel ini untuk men-debug file.

Kode status HTTP 503

Penyebaran Azure Kubernetes Service mendukung autoscaling, yang memungkinkan replika ditambahkan untuk mendukung beban tambahan. Autoscaler dirancang untuk menangani perubahan beban secara bertahap. Jika Anda menerima lonjakan besar dalam permintaan per detik, klien mungkin menerima kode status HTTP 503. Meskipun autoscaler bereaksi dengan cepat, AKS membutuhkan waktu yang signifikan untuk membuat kontainer tambahan.

Keputusan untuk meningkatkan/menurunkan skala didasarkan pada pemanfaatan replika kontainer saat ini. Jumlah replika yang sibuk (memproses permintaan) dibagi dengan jumlah total replika saat ini adalah pemanfaatan saat ini. Jika angka ini melebihi autoscale_target_utilization, maka lebih banyak replika akan dibuat. Jika lebih rendah, maka replika akan dikurangi. Keputusan untuk menambahkan replika sangat lekas dan cepat (sekitar 1 detik). Keputusan untuk menghapus replika bersifat konservatif (sekitar 1 menit). Secara default, pemanfaatan target autoscaling diatur ke 70% , yang berarti bahwa layanan dapat menangani lonjakan permintaan per detik (RPS) hingga 30% .

Ada dua hal yang dapat membantu mencegah 503 kode status:

Tip

Kedua pendekatan ini dapat digunakan secara individual atau dalam kombinasi.

  • Ubah tingkat pemanfaatan tempat autoscaling membuat replika baru. Anda dapat menyesuaikan target pemanfaatan dengan menetapkan autoscale_target_utilization ke nilai yang lebih rendah.

    Penting

    Perubahan ini tidak menyebabkan replika menjadi lebih cepat. Sebaliknya, mereka dibuat pada ambang pemanfaatan yang lebih rendah. Alih-alih menunggu sampai layanan ini digunakan 70%, mengubah nilai menjadi 30% menyebabkan replika dibuat ketika terjadi pemanfaatan sebanyak 30%.

    Jika layanan web sudah menggunakan replika maksimum saat ini dan Anda masih melihat kode status 503, tingkatkan nilai autoscale_max_replicas untuk meningkatkan jumlah maksimum replika.

  • Mengubah jumlah minimum replika. Meningkatkan replika minimum menyediakan kumpulan yang lebih besar untuk menangani lonjakan yang masuk.

    Untuk meningkatkan jumlah minimum replika, atur ke nilai autoscale_min_replicas yang lebih tinggi. Anda dapat menghitung replika yang diperlukan dengan menggunakan kode berikut, mengganti nilai dengan nilai khusus untuk proyek Anda:

    from math import ceil
    # target requests per second
    targetRps = 20
    # time to process the request (in seconds)
    reqTime = 10
    # Maximum requests per container
    maxReqPerContainer = 1
    # target_utilization. 70% in this example
    targetUtilization = .7
    
    concurrentRequests = targetRps * reqTime / targetUtilization
    
    # Number of container replicas
    replicas = ceil(concurrentRequests / maxReqPerContainer)
    

    Catatan

    Jika Anda menerima lonjakan permintaan yang lebih besar dari replika minimum baru yang dapat ditangani, Anda mungkin menerima kode 503 lagi. Misalnya, ketika lalu lintas ke layanan Anda meningkat, Anda mungkin perlu meningkatkan replika minimum.

Untuk informasi selengkapnya terkait pengaturan autoscale_target_utilization, autoscale_max_replicas, dan autoscale_min_replicas, lihat referensi modul AksWebservice.

Kode status HTTP 504

Kode status 504 menunjukkan bahwa permintaan telah kehabisan waktu. Batas waktu default adalah 1 menit.

Anda dapat menambahkan waktu tunggu atau mencoba mempercepat layanan dengan memodifikasi score.py untuk menghapus panggilan yang tidak perlu. Jika tindakan ini tidak memperbaiki masalah, gunakan informasi dalam artikel ini untuk men-debug score.py file. Kode tersebut mungkin berada dalam keadaan tidak responsif atau perulangan tidak terbatas.

Pesan kesalahan lainnya

Ambil tindakan ini untuk kesalahan berikut:

Kesalahan Resolusi
409 kesalahan konflik Saat operasi sedang berlangsung, setiap operasi baru pada layanan web yang sama akan merespons dengan 409 kesalahan konflik. Misalnya, jika membuat atau memperbarui operasi layanan web sedang berlangsung dan jika Anda memicu operasi Hapus baru, hal tersebut akan menimbulkan kesalahan.
Kegagalan pembangunan gambar saat menyebarkan layanan web Tambahkan "pynacl==1.2.1" sebagai dependensi pip ke file Conda untuk konfigurasi gambar
['DaskOnBatch:context_managers.DaskOnBatch', 'setup.py']' died with <Signals.SIGKILL: 9> Ubah SKU untuk VM yang digunakan dalam penyebaran Anda menjadi SKU yang memiliki lebih banyak memori.
Kegagalan FPGA Anda tidak akan dapat menggunakan model pada FPGA sampai Anda meminta dan disetujui untuk kuota FPGA. Untuk meminta akses, isi formulir permintaan kuota: https://aka.ms/aml-real-time-ai

Proses debug tingkat lanjut

Anda mungkin perlu secara interaktif men-debug kode Python yang terdapat dalam penyebaran model. Misalnya, jika skrip entri gagal dan alasannya tidak dapat ditentukan oleh pencatatan tambahan. Dengan menggunakan Visual Studio Code dan debugpy, Anda dapat melampirkan ke kode yang sedang berjalan di dalam kontainer Docker.

Untuk informasi lebih lanjut, kunjungi penelusuran kesalahan interaktif dalam panduan kode VS.

Forum pengguna penyebaran model

Langkah berikutnya

Pelajari selengkapnya tentang penyebaran: