Iniziare con la distribuzione di modelli in tempo reale su Amazon SageMaker

Amazon Sage Maker è un servizio completamente gestito che offre a ogni sviluppatore e data scientist la possibilità di creare, addestrare e distribuire rapidamente modelli di machine learning (ML) su larga scala. Il ML si realizza nell'inferenza. SageMaker offre quattro opzioni di inferenza:

1. Inferenza in tempo reale
2. Inferenza senza server
3. Inferenza asincrona
4. Trasformazione batch

Queste quattro opzioni possono essere classificate a grandi linee in opzioni di inferenza online e batch. In Online Inference, è previsto che le richieste vengano elaborate non appena arrivano e l'applicazione che le utilizza si aspetta una risposta dopo l'elaborazione di ciascuna richiesta. Ciò può avvenire in modo sincrono (inferenza in tempo reale, serverless) o in modo asincrono (inferenza asincrona). In uno schema sincrono, l'applicazione che la utilizza viene bloccata e non può procedere finché non riceve una risposta. Questi carichi di lavoro tendono ad essere applicazioni in tempo reale, come il rilevamento di frodi con carte di credito online, in cui sono previste risposte nell'ordine di millisecondi o secondi e i carichi utili delle richieste sono piccoli (pochi MB). Nel modello asincrono, l'esperienza dell'applicazione non è bloccata (ad esempio, l'invio di una richiesta di risarcimento assicurativo tramite un'app mobile) e in genere richiede dimensioni di payload maggiori e/o tempi di elaborazione più lunghi. Nell'inferenza offline, un'aggregazione (batch) di richieste di inferenza viene elaborata insieme e le risposte vengono fornite solo dopo che l'intero batch è stato elaborato. Di solito, questi carichi di lavoro non sono sensibili alla latenza, coinvolgono grandi volumi (più GB) di dati e sono pianificati con cadenza regolare (ad esempio, eseguono il rilevamento di oggetti sui filmati delle telecamere di sicurezza alla fine della giornata o elaborano i dati delle buste paga al fine del mese).

Alle ossa nude, Inferenza in tempo reale di SageMaker è costituito da uno o più modelli, dal framework/contenitore con cui lavori e dall'infrastruttura/istanze che supportano il tuo endpoint distribuito. In questo post esploreremo come creare e richiamare un endpoint a modello singolo.

Scelta dell'opzione di distribuzione del modello

Scegliere il giusto tipo di inferenza può essere difficile e la seguente semplice guida può aiutarti. Non è un diagramma di flusso rigoroso, quindi se ritieni che un'altra opzione funzioni meglio per te, sentiti libero di utilizzarle. In particolare, Real-Time Inference è un'ottima opzione per ospitare i tuoi modelli quando hai una latenza bassa e coerente (nell'ordine di millisecondi o secondi) e carichi di lavoro sensibili al throughput. Puoi controllare il tipo di istanza e il conteggio dietro il tuo endpoint durante la configurazione Scalabilità automatica politica per gestire il traffico. Esistono altre due opzioni di inferenza di SageMaker che puoi utilizzare anche per creare un endpoint. L'inferenza asincrona si verifica quando si hanno dimensioni di payload di grandi dimensioni e larghezza di banda di latenza quasi in tempo reale. Questa è una buona opzione, soprattutto per i modelli PNL e Visione artificiale che hanno tempi di preelaborazione più lunghi. L'inferenza serverless è un'ottima opzione quando si dispone di traffico intermittente e non si desidera gestire la scalabilità dell'infrastruttura. La ricetta per la creazione di un endpoint rimane la stessa indipendentemente dal tipo di inferenza scelto. In questo post ci concentreremo sulla creazione di un endpoint basato su istanze in tempo reale, ma puoi facilmente adattarlo a una delle altre opzioni di inferenza in base al tuo caso d'uso. Infine, l'inferenza batch avviene offline, quindi puoi fornire un set di dati da cui desideri ottenere l'inferenza e noi la eseguiremo. Anche questo è basato sull'istanza, quindi puoi selezionare l'istanza ottimale per il tuo carico di lavoro. Poiché non esiste alcun endpoint attivo e funzionante, paghi solo per la durata del lavoro. È utile per elaborare gigabyte di dati e la durata del lavoro può essere di giorni. Sono disponibili funzionalità integrate per semplificare il lavoro con i dati strutturati e ottimizzazioni per distribuire automaticamente i dati strutturati. Alcuni esempi di casi d'uso sono la modellazione della propensione, la manutenzione predittiva e la previsione dell'abbandono. Tutto ciò può avvenire offline in blocco perché non è necessario reagire a un evento specifico.

Ospitare un modello su SageMaker Endpoints

Fondamentalmente, SageMaker Real-Time Endpoints è costituito da un modello e dall'infrastruttura con cui si sceglie di supportare l'endpoint. SageMaker utilizza i contenitori per ospitare i modelli, il che significa che è necessario un contenitore che configuri correttamente l'ambiente per il framework che utilizzi per ciascun modello fornito. Ad esempio, se stai lavorando con un modello Sklearn, devi passare gli script/dati del modello all'interno di un contenitore che imposta correttamente Sklearn. Fortunatamente, SageMaker fornisce immagini gestite per framework popolari, come TensorFlow, PyTorch, Sklearn e HuggingFace. È possibile recuperare e utilizzare queste immagini utilizzando il livello alto SDK Python di SageMaker e inserisci gli script e i dati del tuo modello in questi contenitori. Nel caso in cui SageMaker non disponga di un contenitore supportato, puoi farlo anche tu Costruisci il tuo contenitore e invia la tua immagine personalizzata, installando le dipendenze necessarie per il tuo modello.

SageMaker supporta sia modelli addestrati che preaddestrati. Nel paragrafo precedente, quando parliamo di script/dati del modello, facciamo riferimento a questo argomento. Puoi montare uno script sul contenitore oppure, se disponi di un artefatto del modello pre-addestrato (ad esempio, `modello.joblib` per SKLearn), puoi fornirlo insieme alla tua immagine a SageMaker. Per comprendere SageMaker Inference, ci sono tre entità principali che creerai nel processo di creazione dell'endpoint:

1. Entità del modello SageMaker: qui puoi trasmettere i dati del modello addestrato/lo script del modello e l'immagine con cui stai lavorando, sia che sia di proprietà di AWS o creata da te.
2. Creazione della configurazione dell'endpoint: qui definisci la tua infrastruttura, ovvero seleziona il tipo di istanza, il conteggio, ecc.
3. Creazione dell'endpoint: questo è l'endpoint REST che ospita il modello che stai invocando per ottenere una risposta. Diamo un'occhiata a come utilizzare un'immagine SageMaker gestita e la tua immagine personalizzata per distribuire un endpoint.

Requisiti dell'endpoint in tempo reale

1. Prima di creare un Endpoint, devi capire quale tipo di Modello vuoi ospitare. Se si tratta di un modello Framework, come TensorFlow, PyTorch o MXNet, puoi utilizzare uno dei immagini Framework predefinite.
   Se si tratta di un modello personalizzato o desideri la massima flessibilità nella creazione del contenitore che SageMaker eseguirà per l'inferenza, puoi creare il tuo contenitore.

Endpoint SageMaker sono costituiti da a Modello SageMaker ed Configurazione dell'endpoint.
Se utilizzi Boto3, creerai entrambi gli oggetti. Altrimenti, se utilizzi SageMaker Python SDK, la configurazione dell'endpoint verrà creata per tuo conto quando utilizzi il .deploy(..) funzione.

Entità SageMaker:

• Modello SageMaker:
  • Contiene i dettagli dell'immagine di inferenza e la posizione degli artefatti del modello Servizio di archiviazione semplice Amazon (Amazon S3), configurazione di rete e AWS Identity and Access Management (IAM) ruolo che deve essere utilizzato dall'endpoint.
    • SageMaker richiede che gli artefatti del tuo modello siano compressi in un file .tar.gz file. SageMaker lo estrae automaticamente .tar.gz file nel /opt/ml/model/ directory nel tuo contenitore. Se stai utilizzando uno dei contenitori del framework, come TensorFlow, PyTorch o MXNet, il contenitore prevede che la struttura TAR sia la seguente:
      • TensorFlow
        

        model.tar.gz/
        |--[model_version_number]/
        |--variables
        |--saved_model.pb
        code/
        |--inference.py
        |--requirements.txt

      • PyTorch
        

        model.tar.gz/
        |- model.pth
        |- code/
        |- inference.py
        |- requirements.txt # only for versions 1.3.1 and higher

      • MXNet
        

        model.tar.gz/
        |- model-symbol.json
        |- model-shapes.json
        |- model-0000.params
        |- code/
            |- inference.py
            |- requirements.txt # only for versions 1.6.0 and higher

      • Impara
        

        model.tar.gz/
        |- model.joblib
        | code/ 
        |- inference.py

    • Quando utilizziamo un'immagine Framework, possiamo fornire uno script del punto di ingresso personalizzato, in cui possiamo implementare la nostra pre e post elaborazione. Nel nostro caso, lo script di inferenza è impacchettato nel model.tar.gz nella directory /code.

• • Configurazione dell'endpoint
    • Contiene le informazioni sull'infrastruttura necessarie per distribuire il modello SageMaker sull'endpoint.
    • Ad esempio, qui viene specificato il modello SageMaker che abbiamo creato, nonché il tipo di istanza e il conteggio delle istanze iniziali.

Framework e BYOC

• • Recupero delle immagini SageMaker
    • Questa parte non è sempre necessaria e viene estratta dall'SDK Python di SageMaker tramite gli stimatori. Tuttavia, se desideri poter recuperare un'immagine gestita da SageMaker per estenderla su di essa, puoi ottenere le immagini disponibili tramite l'SDK. Di seguito è riportato un esempio di recupero di un'immagine TF 2.2 per l'inferenza.

      import sagemaker
      tf_image = sagemaker.image_uris.retreive(framework="tensorflow", region="us-east-1",
      image_scope = "inference", version = "2.2", instance_type = "ml.c5.xlarge)
      print(tf_image)

  • quadri
    • Nel caso in cui desideri distribuire un modello framework, come TensorFlow, PyTorch o MXNet, tutto ciò di cui hai bisogno sono gli artefatti del modello.
    • Consulta la documentazione per la distribuzione di modelli direttamente dagli artefatti del modello per TensorFlow, PyTorch, o MXNet.

• • Scelta tra 1P e BYOC
    • L'SDK SageMaker astrae anche la gestione dell'immagine, come hai visto nella precedente sezione Framework. Dispone di stimatori già pronti per Sklearn, TensorFlow e PyTorch che selezionano automaticamente l'immagine per te in base alla versione che hai selezionato. Quindi puoi passare uno script di addestramento/inferenza Modalità copione in questi stimatori.

      from sagemaker.pytorch import PyTorch #PyTorch Estimator within SageMaker SDK
      estimator_parameters = {"entry_point": "train_deploy_pytorch_without_dependencies.py",
      "source_dir": "pytorch_script","instance_type": train_instance_type,
      "instance_count": 1,"hyperparameters": hyperparameters,
      "role": role,"base_job_name": "pytorch-model","framework_version": "1.5",
      "py_version": "py3",}
      
      ## Model Training
      estimator = PyTorch(**estimator_parameters)estimator.fit(inputs)
      
      ## Deploy Trained model
      pytorch_predictor = estimator.deploy(initial_instance_count=1, instance_type="ml.m5.xlarge", endpoint_name=pytorch_endpoint_name)

    • Non tutti i pacchetti e le immagini sono supportati da SageMaker e in questo caso è necessario porta il tuo contenitore (BYOC). Ciò significa creare un Dockerfile che configurerà l'ambiente appropriato per il servizio del tuo modello. Un esempio di ciò è il modulo Spacy NLP e non esistono contenitori SageMaker gestiti per questo framework. Pertanto, è necessario fornire un Dockerfile che installi Spacy. All'interno del contenitore monti anche gli script di inferenza del modello. Parliamo rapidamente dei componenti forniti nel formato Bring Your Own Container, poiché rimangono coerenti per la maggior parte degli esempi.
      • "nginx.conf" è il file di configurazione per il front-end nginx. Non dovrai modificare questo file, a meno che tu non voglia ottimizzare queste parti.
      • "predictor.py" è il programma che implementa effettivamente il server web Flask e il codice modello per la tua applicazione. Puoi avere ulteriori file o funzioni Python nel tuo contenitore che puoi chiamare in questo file.
      • "servire" è il programma avviato quando viene avviato il contenitore per l'hosting. Avvia semplicemente il server gunicorn, che esegue più istanze dell'app Flask definita in predittor.py. Come nginx.conf, non è necessario modificare questo file a meno che non ci siano ulteriori ottimizzazioni che desideri eseguire.
      • "treno" è il programma che viene richiamato quando il contenitore viene eseguito per l'addestramento. Modificherai questo programma per implementare il tuo algoritmo di allenamento. Se stai portando un modello o un framework pre-addestrato come Spacy, non hai bisogno di questo file.
      • "wsgi.py" è un piccolo wrapper utilizzato per richiamare l'app Flask. Dovresti essere in grado di prendere questo file così com'è, a meno che tu non abbia cambiato il nome del tuo file predittore.py. In tal caso, assicurati che la mappatura sia corretta qui.

• • Script di inferenza personalizzato
    • I contenitori SageMaker Framework ti offrono la flessibilità di gestire la pre/post elaborazione della richiesta e il caricamento del modello utilizzando uno script/inference.py del punto di ingresso personalizzato.
    • Consulta la documentazione per la creazione di uno script inference.py personalizzato per TensorFlow, PyTorch ed MXNet.
  • Contenitore personalizzato

Diversi modi in cui puoi interagire con SageMaker Endpoints

Sono disponibili molte opzioni per l'utilizzo di SageMaker a livello di codice in modo da poter chiamare i modelli distribuiti per ottenere l'inferenza. IL Interfaccia a riga di comando di AWS (AWS CLI), API REST, AWS CloudFormazione, Kit di sviluppo cloud AWS (AWS CDK) e gli SDK AWS sono strumenti comuni offerti da AWS e ampiamente supportati da altri servizi AWS. Per SageMaker, abbiamo anche un SDK SageMaker Python. Ora confrontiamo le diverse opzioni per creare, richiamare e gestire gli endpoint SageMaker.

Oltre CLI di SageMaker, esistono due modi a livello di programmazione per interagire con gli endpoint in SageMaker tramite gli SDK. Diamo un'occhiata ad alcune differenze tra SDK Python di SageMaker ed SDK Boto3 Python:

1. SDK "Python" di SageMaker di alto livello: questo SDK è una libreria open source che fornisce un livello di astrazione di livello superiore pensato specificamente per chiamare le API SageMaker a livello di codice utilizzando Python. L'aspetto positivo di questo SDK è che è molto semplice chiamare le API sagemaker, vengono già eseguiti molti lavori pesanti, come chiamare le API in modalità sincrona/asincrona (aiuta a evitare il polling), schema di richiesta/risposta più semplice, molto meno codice e molto codice più semplice. SageMaker Python SDK fornisce diverse astrazioni di alto livello per lavorare con SageMaker. Il pacchetto ha lo scopo di semplificare diversi processi ML su SageMaker.
2. SDK AWS di basso livello (SDK Boto3): questo SDK funziona al livello inferiore consentendo all'utente di scegliere tra i linguaggi di programmazione supportati e chiamare qualsiasi servizio AWS in modo programmatico. Questo non è solo specifico di SageMaker ma può essere utilizzato in generale per tutti i servizi AWS. Gli SDK AWS di basso livello sono disponibili in vari linguaggi di programmazione, come .NET, Python, Java, Node.js, ecc. Uno degli SDK più utilizzati è boto3 python SDK, popolare nella comunità dei data scientist per il ML. L'aspetto positivo di questo SDK è che è molto leggero e disponibile per impostazione predefinita installato su AWS Lambda Durata. Inoltre, puoi utilizzare questo SDK per interagire con qualsiasi servizio AWS al di fuori di SageMaker.

Entrambi questi SDK possono essere utilizzati per le stesse attività, ma in alcuni casi è più intuitivo utilizzarne uno più dell'altro. L'SDK Python SageMaker è consigliato per eseguire test semplici, mentre l'SDK AWS/Boto3 è consigliato per i casi d'uso in produzione per un migliore controllo sulle prestazioni. Ad esempio, SageMaker come servizio fornisce immagini predefinite e mantenute per framework popolari, come Sklearn, PyTorch e TensorFlow. Può essere particolarmente utile utilizzare SageMaker SDK per recuperare immagini di deep learning e addestrare modelli utilizzando stimatorie distribuire facilmente il modello utilizzando una semplice chiamata API. È possibile trovare un esempio per mostrarlo in azione qui.

D'altra parte, a volte potresti utilizzare modelli preaddestrati o framework diversi. Ciò richiede una maggiore personalizzazione e l'SDK SageMaker non sempre lo offre. Abbiamo tre passaggi importanti e le corrispondenti chiamate API boto3 che dobbiamo eseguire per distribuire un endpoint: Creazione del modello, Creazione della configurazione dell'endpointe Creazione dell'endpoint. Le prime due entità sono state estratte con l'SDK SageMaker con i nostri framework supportati, ma vediamo questi dettagli con l'SDK Boto3. È possibile trovare un esempio dettagliato per mostrare i passaggi necessari per utilizzare un SDK Boto3 per creare e gestire un endpoint qui.

Considerazioni sull'hosting SageMaker

SageMaker Real-Time Inference prevede due ottimizzazioni principali che puoi considerare: 1/ Ottimizzazione delle prestazioni e 2/ Ottimizzazione dei costi. Diamo prima un'occhiata ottimizzazione delle prestazioni, come quando abbiamo a che fare con carichi di lavoro sensibili alla latenza, ogni millisecondo è cruciale. Esistono diverse manopole che puoi regolare per ottimizzare la latenza e il throughput. A livello di istanza, puoi utilizzare Consigliere di inferenza, il nostro strumento di test del carico integrato, per aiutarti a selezionare il tipo di istanza e il conteggio corretti per il tuo carico di lavoro. L'utilizzo della corretta combinazione di elaborazione ti aiuterà sia in termini di prestazioni che di costi. Puoi anche ottimizzare a livello di contenitore e framework.
Le domande da porsi includono:

1. Che quadro stai utilizzando?
2. Esistono variabili di ambiente che puoi ottimizzare all'interno del tuo contenitore?

Un esempio di ciò è la massimizzazione Prestazioni TensorFlow con i contenitori SageMaker. Un altro esempio di ottimizzazioni a livello di contenitore è utilizzando gRPC anziché REST dietro il tuo endpoint. Infine, puoi anche ottimizzare a livello di script. Il tuo codice di inferenza impiega più tempo in determinati blocchi? La tempistica di ogni singola riga del tuo script ti aiuterà a catturare eventuali colli di bottiglia nel tuo codice.

Ci sono tre modi per guardare migliorandone l'utilizzo del tuo endpoint in tempo reale:

1. Endpoint multimodello (MME)
   • Puoi ospitare migliaia di modelli dietro un singolo endpoint. Questo è perfetto per i casi d'uso in cui non è necessario un endpoint dedicato per ciascuno dei tuoi modelli. MME funziona meglio quando i modelli hanno dimensioni e latenza simili e appartengono allo stesso framework ML. Questi possono essere generalmente utilizzati quando non è necessario chiamare sempre lo stesso modello. Puoi caricare dinamicamente il rispettivo modello sull'endpoint SageMaker per soddisfare la tua richiesta. È possibile trovare un esempio che mostra MME in azione qui. Se desideri saperne di più sui diversi avvertimenti e sulle migliori pratiche per l'hosting di modelli su MME, fai riferimento al post qui.
2. Endpoint multi-contenitore (MCE)
   • Invece di utilizzare più endpoint per ospitare più contenitori, puoi ospitare fino a 15 contenitori su un singolo endpoint. Ciascuno di questi contenitori può essere richiamato direttamente. Pertanto, puoi considerare l'hosting di modelli disparati di framework diversi su un unico endpoint. Questa opzione è la migliore quando i contenitori presentano caratteristiche di utilizzo e prestazioni simili. È possibile trovare un esempio che mostra MCE qui. Se desideri saperne di più sui diversi avvertimenti e sulle migliori pratiche per l'hosting dei modelli su MCE, fai riferimento al post qui.
3. Pipeline di inferenza seriale (SIP)
   • Se disponi di una pipeline di passaggi nella logica di inferenza, potresti utilizzare Serial Inference Pipeline (SIP). SIP ti consente di concatenare da 2 a 15 contenitori dietro un singolo endpoint. SIP funziona bene quando sono presenti fasi di pre-elaborazione e post-elaborazione. Se desideri saperne di più sui modelli di progettazione per le pipeline di inferenza seriale, fai riferimento al post qui.

La seconda ottimizzazione principale da tenere a mente è costo. L'inferenza in tempo reale è una delle tre opzioni all'interno della creazione di endpoint SageMaker. Gli endpoint SageMaker sono sempre in esecuzione, a meno che non vengano eliminati. Pertanto, è necessario cercare di migliorare l'utilizzo dell'endpoint che a sua volta offre un vantaggio in termini di costi.

SageMaker offre anche Piani di risparmio. I Saving Plans possono ridurre i costi fino al 64%. Si tratta di un impegno a termine di 1 o 3 anni per una quantità costante di utilizzo ($/ora). Guarda questo link per maggiori informazioni. E guarda questo link per ottimizzare al meglio i costi per Inference su Amazon SageMaker.

Conclusione

In questo post, ti abbiamo mostrato alcune delle migliori pratiche per scegliere tra diverse opzioni di hosting di modelli su SageMaker. Abbiamo discusso i requisiti dell'endpoint SageMaker e anche messo a confronto i requisiti e le funzionalità del Framework e del BYOC. Inoltre, abbiamo parlato dei diversi modi in cui puoi sfruttare gli endpoint in tempo reale per ospitare i tuoi modelli ML in produzione. in modo economicamente vantaggioso e con prestazioni elevate.

Vedi il corrispondente Repository GitHub e prova gli esempi.

---

Circa gli autori

Raghu Ramesha è un ML Solutions Architect con il team di Amazon SageMaker Service. Si concentra sull'aiutare i clienti a creare, distribuire e migrare i carichi di lavoro di produzione ML su SageMaker su larga scala. È specializzato in domini di apprendimento automatico, intelligenza artificiale e visione artificiale e ha conseguito un master in informatica presso UT Dallas. Nel tempo libero ama viaggiare e la fotografia.

Ram Vegiraju è un ML Architect con il team SageMaker Service. Si concentra sull'aiutare i clienti a creare e ottimizzare le loro soluzioni AI/ML su Amazon SageMaker. Nel tempo libero ama viaggiare e scrivere.

Marc Karp è un ML Architect del team SageMaker Service. Si concentra sull'aiutare i clienti a progettare, distribuire e gestire i carichi di lavoro ML su larga scala. Nel tempo libero ama viaggiare ed esplorare posti nuovi.

Dhawal Patel è un Principal Machine Learning Architect presso AWS. Ha lavorato con organizzazioni che vanno dalle grandi imprese alle startup di medie dimensioni su problemi legati all'informatica distribuita e all'intelligenza artificiale. Si concentra sull'apprendimento profondo, inclusi i domini della PNL e della visione artificiale. Aiuta i clienti a ottenere un'inferenza del modello ad alte prestazioni su Amazon SageMaker.

Saurabh Trikande è un Senior Product Manager per Amazon SageMaker Inference. È appassionato di lavorare con i clienti ed è motivato dall'obiettivo di democratizzare l'apprendimento automatico. Si concentra sulle sfide principali relative all'implementazione di applicazioni ML complesse, modelli ML multi-tenant, ottimizzazioni dei costi e rendere più accessibile l'implementazione di modelli di deep learning. Nel tempo libero, Saurabh ama fare escursioni, conoscere tecnologie innovative, seguire TechCrunch e trascorrere del tempo con la sua famiglia.