Debugging degli endpoint SageMaker con Docker

Debugging SageMaker endpoints with Docker.

Un’alternativa a SageMaker Local Mode

Immagine da Unsplash di Mohammad Rahmani

Un problema comune nello sviluppo di SageMaker Real-Time Inference è che a volte è difficile fare il debug. Quando si crea un endpoint, ci sono diversi elementi che devono essere configurati correttamente per un deployment di successo.

  • Una corretta strutturazione dei file dei modelli, a seconda del Model Server e del Container che si sta utilizzando. Essenzialmente, il model.tar.gz fornito deve essere in un formato compatibile con il Model Server.
  • Se si dispone di uno script di inferenza personalizzato che implementa la pre e la post-elaborazione per il modello, è necessario assicurarsi che gli handlers implementati siano compatibili con il model server e che non ci siano errori di scripting a livello di codice.

In precedenza abbiamo discusso di SageMaker Local Mode, ma al momento di questo articolo Local Mode non supporta tutte le opzioni di hosting e i model server disponibili per SageMaker Deployment.

Per superare questa limitazione, diamo un’occhiata all’utilizzo di Docker con un modello di esempio e vediamo come possiamo testare/fare il debug dei nostri artefatti di modello e script di inferenza prima del deployment di SageMaker. In questo esempio specifico utilizzeremo il modello BART che ho già coperto nel mio ultimo articolo e vedremo come possiamo ospitarlo con Docker.

NOTA: per coloro che sono nuovi ad AWS, assicurarsi di creare un account al seguente link se si vuole seguire l’esempio. L’articolo assume anche una comprensione intermedia di SageMaker Deployment, suggerisco quindi di seguire questo articolo per una comprensione più approfondita di Deployment/Inference. Una conoscenza di livello intermedio di Docker sarà anche utile per capire appieno questo esempio.

Come Funziona Il Hosting Di SageMaker?

Prima di passare alla parte del codice di questo articolo, diamo un’occhiata a come SageMaker serve effettivamente le richieste. Al suo nucleo, l’Inference di SageMaker ha due costrutti:

  • Container: Questo stabilisce l’ambiente di runtime per il modello, ed è integrato con il model server che si sta utilizzando. Si può utilizzare uno dei Container di Deep Learning esistenti (DLCs) o costruirne uno proprio.
  • Artifatti del Modello: Nella chiamata API CreateModel, specificano un URL S3 con i dati del modello presenti nel formato di un model.tar.gz (tarball). Questi dati del modello vengono caricati nella directory opt/ml/model del container, e questo include anche qualsiasi script di inferenza che si fornisce.

La chiave qui è che il container ha bisogno di un web server implementato che risponde alla porta 8080 sui percorsi /invocations e /ping. Un esempio di web server che abbiamo implementato con questi percorsi è Flask durante un esempio Bring Your Own Container.

Con Docker, ciò che faremo sarà esporre questa porta e puntare verso il nostro script locale e gli artefatti del modello, in modo da simulare il modo in cui ci si aspetta che un Endpoint di SageMaker si comporti.

Testing Con Docker

Per semplicità, utilizzeremo il mio esempio BART dal mio ultimo articolo, è possibile recuperare gli artefatti da questo repository. Qui si dovrebbero vedere i seguenti file:

  • model.py: Questo è lo script di inferenza con cui stiamo lavorando. In questo caso, stiamo utilizzando DJL Serving che si aspetta un model.py con una funzione di handler che implementa l’inferenza. Il tuo script di inferenza deve comunque essere compatibile con il formato che il model server si aspetta.
  • requirements.txt: Eventuali dipendenze aggiuntive che il tuo script model.py richiede. Per DJL Serving, PyTorch è già installato in precedenza, utilizziamo numpy per l’elaborazione dei dati.
  • serving.properties: Questo è anche un file specifico di DJL, qui è possibile definire qualsiasi configurazione a livello di modello (ad esempio: lavoratori per modello).

Ora abbiamo i nostri artefatti di modello, ora abbiamo bisogno del container che utilizzeremo. In questo caso, possiamo recuperare l’immagine DJL DeepSpeed esistente. Per una lista estesa delle immagini già fornite da AWS, si prega di fare riferimento a questa guida. È anche possibile costruire la propria immagine localmente e puntare su quella. In questo caso, operiamo in un ambiente SageMaker Classic Notebook Instance che ha pre-installato anche Docker.

Per lavorare con le immagini fornite da AWS, è necessario accedere al registro dei contenitori elastici di AWS (ECR) per recuperare l’immagine. Puoi farlo con il seguente comando shell.

$(aws ecr get-login --region us-east-1 --no-include-email --registry-ids 763104351884)

Dovresti vedere un messaggio di login riuscito simile al seguente.

Login Succeeded (Screenshot by Author)

Una volta effettuato l’accesso, possiamo accedere al percorso in cui sono archiviati i nostri artefatti del modello e eseguire il seguente comando che avvierà il server del modello. Se non hai ancora recuperato l’immagine, questa verrà anche recuperata da ECR.

docker run \-v /home/ec2-user/SageMaker:/opt/ml/model \--cpu-shares 512 \-p 8080:8080 \763104351884.dkr.ecr.us-east-1.amazonaws.com/djl-inference:0.21.0-deepspeed0.8.0-cu117 \serve

Alcuni punti chiave qui:

  • Stiamo esponendo la porta 8080 poiché SageMaker Inference lo richiede.
  • Indirizziamo anche l’immagine esistente. Questa stringa dipende dalla regione e dal modello in cui stai operando. Puoi anche utilizzare la chiamata API retrieve image_uri di SageMaker Python SDK per identificare l’immagine appropriata da recuperare qui.
Image being retrieved (Screenshot by Author)

Dopo aver recuperato l’immagine, vedrai che il server del modello è stato avviato.

DJL Server Started (Screenshot by Author)

Puoi anche verificare che questo contenitore sia in esecuzione utilizzando il seguente comando Docker.

docker container ls
Container Started (Screenshot by Author)

Vediamo che l’API è esposta tramite la porta 8080 a cui possiamo inviare richieste di esempio tramite curl. Nota che specificiamo il percorso /invocations che i contenitori SageMaker si aspettano.

curl -X POST http://localhost:8080/invocations -H "Content-type: text/plain" "This is a sample test string"

Vediamo quindi l’infersi restituito per la richiesta e anche il server del modello che tiene traccia della risposta ed emette le nostre dichiarazioni di registrazione dal nostro script di infersi.

Sample Request (Screenshot by Author)

Suddividiamo il nostro model.py e vediamo se possiamo rilevare l’errore inizialmente con Docker. Qui nella funzione di infersi aggiungo una dichiarazione di stampa sintatticamente scorretta e riavvio il mio server del modello per vedere se questo errore viene catturato.

def inference(self, inputs):        """        Custom service entry point function.        :param inputs: the Input object holds the text for the BART model to infer upon        :return: the Output object to be send back        """        #sample error        print("=)

Puoi quindi vedere che questo errore viene catturato dal server del modello quando eseguiamo il comando di esecuzione docker.

Error captured by Model Server (Screenshot by Author)

Nota che non sei limitato a utilizzare solo curl per testare il tuo container. Possiamo anche utilizzare qualcosa come la libreria Python requests per interfacciare e lavorare con il container. Una richiesta di esempio sarebbe la seguente:

import requestsheaders = {    'Content-type': 'text/plain',}response = requests.post('http://localhost:8080/invocations', headers=headers)

Utilizzando qualcosa come requests puoi eseguire test di carico su larga scala sul container. Nota che l’hardware su cui stai eseguendo il container è ciò che viene utilizzato (pensa a questo come il tuo equivalente all’istanza dietro un Endpoint SageMaker).

Risorse aggiuntive e conclusione

GitHub – RamVegiraju/SageMaker-Docker-Local: Come testare localmente SageMaker Inference con Docker

Come testare localmente SageMaker Inference con Docker – GitHub – RamVegiraju/SageMaker-Docker-Local: Come testare localmente…

github.com

Puoi trovare il codice per l’intero esempio al link sopra. Con SageMaker Inference vuoi evitare il dolore di attendere che l’endpoint venga creato per catturare eventuali errori. Utilizzando questo approccio puoi lavorare con qualsiasi container SageMaker per testare e debuggare i tuoi artefatti del modello e gli script di inferenza.

Come sempre, sentiti libero di lasciare qualsiasi feedback o domanda, grazie per la lettura!

Se ti è piaciuto questo articolo, sentiti libero di connetterti con me su LinkedIn e iscriviti alla mia newsletter Nisoo. Se sei nuovo su Nisoo, iscriviti usando il mio codice di riferimento per i membri.