Condividi tramite

Risoluzione dei problemi relativi alla distribuzione modello remoto

  • Articolo

Informazioni su come risolvere i problemi o trovare soluzioni alternative per gli errori comuni che possono verificarsi durante la distribuzione di un modello in Istanze di Azure Container (ACI) e al servizio Azure Kubernetes usando Azure Machine Learning.

Nota

Se si distribuisce un modello nel servizio Azure Kubernetes, è consigliabile abilitare Monitoraggio di Azure per il cluster. Ciò consente di comprendere l'integrità complessiva del cluster e l'utilizzo delle risorse. Potrebbero essere utili anche le risorse seguenti:

Se si sta tentando di distribuire un modello in un cluster non integro o sovraccarico, è prevedibile che si verifichino problemi. Per assistenza nella risoluzione dei problemi del cluster del servizio Azure Kubernetes, contattare il supporto del servizio Azure Kubernetes.

Prerequisiti

Passaggi per la distribuzione tramite Docker di modelli di Machine Learning

Quando si distribuisce un modello in un ambiente di calcolo non locale in Azure Machine Learning, vengono eseguite le operazioni seguenti:

  1. Il Dockerfile specificato nell'oggetto Environments in InferenceConfig viene inviato al cloud, insieme al contenuto della directory di origine
  2. Se non è disponibile un'immagine compilata in precedenza nel registro contenitori, una nuova immagine Docker viene compilata nel cloud e archiviata nel registro contenitori predefinito dell'area di lavoro.
  3. L'immagine Docker dal registro contenitori viene scaricata nella destinazione di calcolo.
  4. L'archivio BLOB predefinito dell'area di lavoro viene montato nella destinazione di calcolo, consentendo l'accesso ai modelli registrati
  5. Il server Web viene inizializzato eseguendo la funzione init() dello script di immissione
  6. Quando il modello distribuito riceve una richiesta, la funzione run() gestisce tale richiesta

La differenza principale quando si usa una distribuzione locale è che l'immagine del contenitore è basata sul computer locale, motivo per cui è necessario che Docker sia installato per una distribuzione locale.

Comprendere questi passaggi generali consente di capire dove si verificano gli errori.

Ottenere i log di distribuzione

Il primo passaggio del debug degli errori consiste nell'ottenere i log di distribuzione. Innanzitutto, seguire le istruzioni qui per connettersi all'area di lavoro.

SI APPLICA A:Estensione Machine Learning dell'interfaccia della riga di comando di Azure v1

Per ottenere i log da un servizio Web distribuito, eseguire le operazioni seguenti:

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

Eseguire il debug in locale

Se si verificano problemi durante la distribuzione di un modello in ACI o AKS, distribuirlo come servizio Web locale. L'utilizzo di un servizio Web locale rende più semplice la risoluzione dei problemi. Per risolvere i problemi relativi a una distribuzione in locale, vedere l'articolo sulla risoluzione dei problemi locali.

Server HTTP di inferenza di Azure Machine Learning

Il server di inferenza locale consente di eseguire rapidamente il debug dello script di immissione (score.py). Nel caso in cui lo script del punteggio sottostante abbia un bug, il server non riesce a inizializzare o gestire il modello. Genera invece un'eccezione e la posizione in cui si sono verificati i problemi. Altre informazioni sul server HTTP di inferenza di Azure Machine Learning

  1. Installare il pacchetto azureml-inference-server-http dal feed pypi:

    python -m pip install azureml-inference-server-http

  2. Avviare il server e impostare score.py come script di immissione:

    azmlinfsrv --entry_script score.py

  3. Inviare una richiesta di assegnazione di punteggio al server tramite curl:

    curl -p 127.0.0.1:5001/score

Nota

Domande frequenti sul server HTTP di inferenza di Azure Machine Learning.

Non è possibile pianificare il contenitore

Quando si distribuisce un servizio in una destinazione di calcolo del servizio Kubernetes di Azure, Azure Machine Learning tenta di pianificare il servizio con la quantità di risorse richiesta. Se, dopo 5 minuti, nel cluster non sono disponibili nodi con la quantità appropriata di risorse, la distribuzione avrà esito negativo. Il messaggio di errore è Couldn't Schedule because the kubernetes cluster didn't have available resources after trying for 00:05:00. Per risolvere questo errore, è possibile aggiungere più nodi, modificare lo SKU dei nodi o modificare i requisiti di risorse del servizio.

Il messaggio di errore indicherà in genere la risorsa non sufficiente. Ad esempio, se viene visualizzato un messaggio di errore che indica 0/3 nodes are available: 3 Insufficient nvidia.com/gpu, che significa che il servizio richiede GPU e che nel cluster sono presenti tre nodi che non hanno GPU disponibili. È possibile risolvere questo problema aggiungendo altri nodi se si usa uno SKU GPU, passando a uno SKU abilitato per GPU in caso contrario, o modificando l'ambiente in modo da non richiedere GPU.

Errore di avvio del servizio

Dopo aver creato correttamente l'immagine, il sistema tenta di avviare un contenitore usando la configurazione della distribuzione. Nell'ambito del processo di avvio del contenitore, il sistema richiama la funzione init() nello script di assegnazione dei punteggi. Se la funzione init() contiene eccezioni non rilevate, nel messaggio di errore potrebbe essere visualizzato l'errore CrashLoopBackOff.

Usare le informazioni presenti nell'articolo Esaminare il log di Docker.

Errore di avvio di azureml-fe-aci del contenitore

Quando si distribuisce un servizio in una destinazione di calcolo dell'istanza di contenitore di Azure, Azure Machine Learning tenta di creare un contenitore front-end con il nome azureml-fe-aci per la richiesta di inferenza. Se azureml-fe-aci si arresta in modo anomalo, è possibile visualizzare i log eseguendo az container logs --name MyContainerGroup --resource-group MyResourceGroup --subscription MySubscription --container-name azureml-fe-aci. È possibile seguire il messaggio di errore nei log per apportare la correzione.

L'errore più comune per azureml-fe-aci è che il certificato o la chiave SSL forniti non sono validi.

Errore della funzione: get_model_path()

Nella funzione init() dello script di assegnazione dei punteggi viene spesso chiamata la funzione Model.get_model_path() per individuare un file di modello o una cartella di file di modello nel contenitore. Se non è possibile trovare il file o la cartella del modello, la funzione ha esito negativo. Il modo più semplice per eseguire il debug di questo errore consiste nell'eseguire il codice Python seguente nella shell del contenitore:

SI APPLICA A:Python SDK azureml v1

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

Questo esempio consente di visualizzare il percorso locale (relativo a /var/azureml-app) nel contenitore in cui si prevede che lo script di assegnazione dei punteggi trovi il file o la cartella di modello. È quindi possibile verificare se il file o la cartella si trova effettivamente dove dovrebbe essere.

L'impostazione del livello di registrazione su DEBUG potrebbe causare la registrazione di informazioni aggiuntive che potrebbero essere utili per identificare l'errore.

Errore della funzione: run(input_data)

Se il servizio viene distribuito correttamente, ma si arresta in modo anomalo quando si pubblicano dati nell'endpoint di assegnazione dei punteggi, è possibile aggiungere un'istruzione di rilevamento degli errori nella funzione run(input_data) in modo che restituisca il messaggio di errore dettagliato. Ad esempio:

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})

Nota: la restituzione di messaggi di errore dalla chiamata a run(input_data) dovrebbe essere eseguita solo a scopo di debug. Per motivi di sicurezza, non si devono restituire i messaggi di errore in questo modo in un ambiente di produzione.

Codice di stato HTTP 502

Un codice di stato 502 indica che il servizio ha generato un'eccezione o si è arrestato in modo anomalo nel metodo run() del file score.py. Usare le informazioni presenti in questo articolo per eseguire il debug del file.

Codice di stato HTTP 503

Le distribuzioni del servizio Azure Kubernetes supportano il ridimensionamento automatico, che consente di aggiungere repliche per supportare un carico aggiuntivo. Il ridimensionamento automatico è progettato per gestire modifiche graduali nel carico. Se si ricevono picchi elevati di richieste al secondo, i client potrebbero ricevere un codice di stato HTTP 503. Anche se il ridimensionamento automatico reagisce rapidamente, il servizio Azure Kubernetes richiede molto tempo per creare più contenitori.

Le decisioni per aumentare o ridurre le prestazioni si basano sull'utilizzo delle repliche dei contenitori correnti. Il numero di repliche occupate (che hanno una richiesta di elaborazione in corso) diviso per il numero totale di repliche correnti è l'utilizzo corrente. Se questo numero supera autoscale_target_utilization, vengono create più repliche. Se è inferiore, le repliche vengono ridotte. Le decisioni per aggiungere repliche sono veloci e immediate (circa 1 secondo). Le decisioni per rimuovere le repliche sono conservative (circa 1 minuto). Per impostazione predefinita, l'uso della destinazione per il ridimensionamento automatico è impostato su 70%, che significa che il servizio è in grado di gestire picchi di richieste al secondo (RPS) fino al 30%.

Esistono due elementi che consentono di prevenire codici di stato 503:

Suggerimento

Questi due approcci possono essere usati singolarmente o combinati.

  • Modificare il livello di utilizzo a cui il ridimensionamento automatico crea nuove repliche. È possibile regolare la destinazione di utilizzo impostando autoscale_target_utilization su un valore inferiore.

    Importante

    Questa modifica non comporta la creazione di repliche più velocemente. Vengono invece create con una soglia di utilizzo inferiore. Anziché attendere fino al 70% di utilizzo del servizio, la modifica del valore su 30% comporta la creazione di repliche quando si verifica l'utilizzo al 30%.

    Se il servizio Web sta già usando le repliche massime correnti e vengono ancora visualizzati codici di stato 503, aumentare il valore di autoscale_max_replicas per aumentare il numero massimo di repliche.

  • Modificare il numero minimo di repliche. L'aumento delle repliche minime offre un pool più grande per gestire i picchi in ingresso.

    Per aumentare il numero minimo di repliche, impostare autoscale_min_replicas su un valore più elevato. È possibile calcolare le repliche richieste usando il codice seguente, sostituendo i valori con valori specifici del progetto:

    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)

    Nota

    Se si ricevono picchi di richiesta di dimensioni maggiori di quelle che possono essere gestite dalle nuove repliche minime, si potrebbero ricevere nuovamente codici di stato 503. Ad esempio, mano a mano che il traffico verso il servizio aumenta, potrebbe essere necessario aumentare le repliche minime.

Per altre informazioni sull'impostazione di autoscale_target_utilization, autoscale_max_replicas e autoscale_min_replicas, vedere il riferimento al modulo AksWebservice.

Codice di stato HTTP 504

Un codice di stato 504 indica che si è verificato il timeout della richiesta. Il timeout predefinito è 1 minuto.

È possibile aumentare il timeout o provare ad accelerare il servizio modificando il file score.py per rimuovere le chiamate non necessarie. Se queste azioni non consentono di risolvere il problema, usare le informazioni contenute in questo articolo per eseguire il debug del file score.py. Il codice potrebbe trovarsi in uno stato non reattivo o in un ciclo infinito.

Altri messaggi di errore

Eseguire queste azioni per gli errori seguenti:

Error Risoluzione
errore di conflitto 409 Quando un'operazione è già in corso, qualsiasi nuova operazione nello stesso servizio Web risponderà con un errore di conflitto 409. Ad esempio, se l'operazione di creazione o aggiornamento del servizio Web è in corso e, se si attiva una nuova operazione di eliminazione, viene generato un errore.
Errore di compilazione di immagini durante la distribuzione del servizio Web Aggiungere "pynacl==1.2.1" come dipendenza pip al file Conda per la configurazione dell'immagine
['DaskOnBatch:context_managers.DaskOnBatch', 'setup.py']' died with <Signals.SIGKILL: 9> Modificare lo SKU per le macchine virtuali usate nella distribuzione in un'istanza con più memoria.
Errore FPGA Non è possibile distribuire i modelli in FPGA fino a quando non viene richiesta e approvata la quota FPGA. Per richiedere l'accesso, compilare il modulo di richiesta della quota: https://forms.office.com/Pages/ResponsePage.aspx?id=v4j5cvGGr0GRqy180BHbR2nac9-PZhBDnNSV2ITz0LNUN0U5S0hXRkNITk85QURTWk9ZUUFUWkkyTC4u

Debug avanzato

Potrebbe essere necessario eseguire il debug interattivo del codice Python contenuto nella distribuzione modello. Ad esempio, se l'esecuzione dello script di immissione non viene completata e non è possibile determinare il motivo con una registrazione aggiuntiva. Usando Visual Studio Code e debugpy, è possibile connettersi al codice in esecuzione all'interno del contenitore Docker.

Per altre informazioni, vedere il debug interattivo nella guida di VS Code.

Forum utenti sulla distribuzione modello

Passaggi successivi

Altre informazioni sulla distribuzione: