Modelli di progettazione per l'inferenza seriale su Amazon SageMaker

Man mano che il machine learning (ML) diventa mainstream e ottiene un’adozione più ampia, le applicazioni basate sul ML stanno diventando sempre più comuni per risolvere una serie di problemi aziendali complessi. La soluzione a questi complessi problemi aziendali spesso richiede l’utilizzo di più modelli ML. Questi modelli possono essere combinati in sequenza per eseguire varie attività, come la preelaborazione, la trasformazione dei dati, la selezione del modello, la generazione di inferenze, il consolidamento delle inferenze e la postelaborazione. Le organizzazioni necessitano di opzioni flessibili per orchestrare questi complessi flussi di lavoro ML. Le pipeline di inferenza seriale sono uno di questi modelli di progettazione per organizzare questi flussi di lavoro in una serie di passaggi, in cui ogni passaggio arricchisce o elabora ulteriormente l'output generato dai passaggi precedenti e passa l'output al passaggio successivo nella pipeline.

Inoltre, queste pipeline di inferenza seriale dovrebbero fornire quanto segue:

• Implementazione flessibile e personalizzata (dipendenze, algoritmi, logica di business e così via)
• Ripetibile e coerente per l'implementazione della produzione
• Sollevamento pesante indifferenziato riducendo al minimo la gestione dell'infrastruttura

In questo post, esaminiamo alcuni casi d'uso comuni per le pipeline di inferenza seriale e analizziamo alcune opzioni di implementazione per ciascuno di questi casi d'uso utilizzando Amazon Sage Maker. Discuteremo anche considerazioni per ciascuna di queste opzioni di implementazione.

La tabella seguente riepiloga i diversi casi d'uso per l'inferenza seriale, considerazioni sull'implementazione e opzioni. Questi sono discussi in questo post.

Nelle sezioni seguenti, discutiamo ogni caso d'uso in modo più dettagliato.

Pipeline di inferenza seriale che utilizza contenitori di inferenza

I casi d'uso della pipeline di inferenza seriale hanno requisiti per preelaborare i dati in ingresso prima di richiamare un modello ML preaddestrato per generare inferenze. Inoltre, in alcuni casi, potrebbe essere necessario elaborare ulteriormente le inferenze generate, in modo che possano essere facilmente utilizzate dalle applicazioni a valle. Questo è uno scenario comune per i casi d'uso in cui un'origine dati in streaming deve essere elaborata in tempo reale prima che un modello possa essere adattato su di essa. Tuttavia, questo caso d'uso può manifestarsi anche per l'inferenza batch.

SageMaker offre un'opzione per personalizzare i contenitori di inferenza e utilizzarli per creare una pipeline di inferenza seriale. I contenitori di inferenza utilizzano il file SageMaker Toolkit di inferenza e sono costruiti su Server multimodello SageMaker (MMS), che fornisce un meccanismo flessibile per servire i modelli ML. Il diagramma seguente illustra un modello di riferimento su come implementare una pipeline di inferenza seriale utilizzando contenitori di inferenza.

SageMaker MMS prevede uno script Python che implementi le seguenti funzioni per caricare il modello, preelaborare i dati di input, ottenere previsioni dal modello e postelaborare i dati di output:

• input_fn () – Responsabile della deserializzazione e della preelaborazione dei dati di input
• modello_fn() – Responsabile del caricamento del modello addestrato dagli artefatti in Servizio di archiviazione semplice Amazon (Amazon S3)
• predict_fn () – Responsabile della generazione di inferenze dal modello
• output_fn () – Responsabile della serializzazione e della postelaborazione dei dati di output (inferenze)

Per i passaggi dettagliati per personalizzare un contenitore di inferenza, fare riferimento a Adattare il proprio contenitore di inferenza.

I contenitori di inferenza rappresentano un modello di progettazione ideale per i casi d'uso di pipeline di inferenza seriale con le seguenti considerazioni principali:

• Alta coesione – La logica di elaborazione e il modello corrispondente guidano le singole funzionalità aziendali e devono essere collocati nella stessa sede
• Latenza complessiva bassa – Il tempo trascorso tra il momento in cui viene effettuata una richiesta di inferenza e la ricezione della risposta

In una pipeline di inferenza seriale, la logica di elaborazione e il modello sono incapsulati nello stesso singolo contenitore, pertanto la maggior parte delle chiamate di invocazione rimangono all'interno del contenitore. Ciò aiuta a ridurre il numero complessivo di hop, con conseguente migliore latenza complessiva e reattività della pipeline.

Inoltre, per i casi d'uso in cui la facilità di implementazione è un criterio importante, i contenitori di inferenza possono essere d'aiuto, con la co-localizzazione di varie fasi di elaborazione della pipeline all'interno dello stesso contenitore.

Pipeline di inferenza seriale che utilizza una pipeline di inferenza SageMaker

Un'altra variazione del caso d'uso della pipeline di inferenza seriale richiede un disaccoppiamento più chiaro tra le varie fasi della pipeline (come la preelaborazione dei dati, la generazione dell'inferenza, la postelaborazione dei dati, la formattazione e la serializzazione). Ciò potrebbe essere dovuto a una serie di motivi:

• Il disaccoppiamento – Vari passaggi della pipeline hanno uno scopo chiaramente definito e devono essere eseguiti su contenitori separati a causa delle dipendenze sottostanti coinvolte. Questo aiuta anche a mantenere la pipeline ben strutturata.
• quadri – Vari passaggi della pipeline utilizzano framework specifici adatti allo scopo (come scikit o Spark ML) e pertanto devono essere eseguiti su contenitori separati.
• Isolamento delle risorse – Vari passaggi della pipeline hanno requisiti di consumo delle risorse variabili e pertanto devono essere eseguiti su contenitori separati per maggiore flessibilità e controllo.

Inoltre, per pipeline di inferenza seriale leggermente più complesse, potrebbero essere necessari più passaggi per elaborare una richiesta e generare un'inferenza. Pertanto, da un punto di vista operativo, potrebbe essere utile ospitare questi passaggi su contenitori separati per un migliore isolamento funzionale e facilitare aggiornamenti e miglioramenti più semplici (modificare un passaggio senza influire su altri modelli o passaggi di elaborazione).

Se il tuo caso d'uso è in linea con alcune di queste considerazioni, a Pipeline di inferenza SageMaker fornisce un'opzione semplice e flessibile per creare una pipeline di inferenza seriale. Il diagramma seguente illustra un modello di riferimento su come implementare una pipeline di inferenza seriale utilizzando più passaggi ospitati su contenitori dedicati utilizzando una pipeline di inferenza SageMaker.

Una pipeline di inferenza SageMaker è costituita da una sequenza lineare di 2-15 contenitori che elaborano le richieste di inferenze sui dati. La pipeline di inferenza offre la possibilità di utilizzare algoritmi integrati SageMaker preaddestrati o algoritmi personalizzati confezionati in contenitori Docker. I contenitori sono ospitati sulla stessa istanza sottostante, il che aiuta a ridurre la latenza complessiva e a minimizzare i costi.

Il seguente frammento di codice mostra come è possibile combinare più fasi di elaborazione e modelli per creare una pipeline di inferenza seriale.

Iniziamo costruendo e specificando modelli basati su Spark ML e XGBoost che intendiamo utilizzare come parte della pipeline:

from sagemaker.model import Model
from sagemaker.pipeline_model import PipelineModel
from sagemaker.sparkml.model import SparkMLModel
sparkml_data = 's3://{}/{}/{}'.format(s3_model_bucket, s3_model_key_prefix, 'model.tar.gz')
sparkml_model = SparkMLModel(model_data=sparkml_data)
xgb_model = Model(model_data=xgb_model.model_data, image=training_image)

I modelli vengono quindi disposti in sequenza all'interno della definizione del modello di pipeline:

model_name = 'serial-inference-' + timestamp_prefix
endpoint_name = 'serial-inference-ep-' + timestamp_prefix
sm_model = PipelineModel(name=model_name, role=role, models=[sparkml_model, xgb_model])

La pipeline di inferenza viene quindi distribuita dietro un endpoint per l'inferenza in tempo reale specificando il tipo e il numero di istanze ML host:

sm_model.deploy(initial_instance_count=1, instance_type='ml.c4.xlarge', endpoint_name=endpoint_name)

L'intera pipeline di inferenza assemblata può essere considerata un modello SageMaker che è possibile utilizzare per effettuare previsioni in tempo reale o elaborare direttamente trasformazioni batch, senza alcuna preelaborazione esterna. All'interno di un modello di pipeline di inferenza, SageMaker gestisce le invocazioni come una sequenza di richieste HTTP originate da un'applicazione esterna. Il primo contenitore nella pipeline gestisce la richiesta iniziale, esegue alcune elaborazioni e quindi invia la risposta intermedia come richiesta al secondo contenitore nella pipeline. Ciò avviene per ogni contenitore nella pipeline e infine restituisce la risposta finale all'applicazione client chiamante.

Le pipeline di inferenza SageMaker sono completamente gestite. Quando la pipeline viene distribuita, SageMaker installa ed esegue tutti i contenitori definiti su ciascuno dei Cloud di calcolo elastico di Amazon (Amazon EC2) istanze fornite come parte dell'endpoint o del processo di trasformazione batch. Inoltre, poiché i container sono posizionati nella stessa posizione e ospitati sulla stessa istanza EC2, la latenza complessiva della pipeline è ridotta.

Insieme di modelli seriali che utilizzano una pipeline di inferenza SageMaker

Un modello ensemble è un approccio in ML in cui più modelli ML vengono combinati e utilizzati come parte del processo di inferenza per generare inferenze finali. Le motivazioni per i modelli di insieme potrebbero includere, tra le altre cose, il miglioramento della precisione, la riduzione della sensibilità del modello a specifiche caratteristiche di input e la riduzione della distorsione del singolo modello. In questo post, ci concentriamo sui casi d'uso relativi a un insieme di modelli seriali, in cui più modelli ML vengono combinati sequenzialmente come parte di una pipeline di inferenza seriale.

Consideriamo un esempio specifico relativo a un insieme di modelli seriali in cui dobbiamo raggruppare le immagini caricate da un utente in base a determinati temi o argomenti. Questa pipeline potrebbe essere costituita da tre modelli ML:

• Modello 1 – Accetta un'immagine come input e valuta la qualità dell'immagine in base alla risoluzione dell'immagine, all'orientamento e altro. Questo modello tenta quindi di migliorare la qualità dell'immagine e invia le immagini elaborate che soddisfano una determinata soglia di qualità al modello successivo (modello 2).
• Modello 2 – Accetta le immagini convalidate tramite il Modello 1 ed esegue riconoscimento dell'immagine per identificare oggetti, luoghi, persone, testo e altre azioni e concetti personalizzati nelle immagini. L'output del Modello 2 che contiene gli oggetti identificati viene inviato al Modello 3.
• Modello 3 – Accetta l'output del Modello 2 ed esegue attività di elaborazione del linguaggio naturale (NLP) come la modellazione degli argomenti per raggruppare insieme le immagini in base ai temi. Ad esempio, le immagini potrebbero essere raggruppate in base alla posizione o alle persone identificate. L'output (raggruppamenti) viene inviato all'applicazione client.

Il diagramma seguente illustra un modello di riferimento su come implementare più modelli ML ospitati su un insieme di modelli seriali utilizzando una pipeline di inferenza SageMaker.

Come discusso in precedenza, la pipeline di inferenza di SageMaker viene gestita, il che consente di concentrarsi sulla selezione e sullo sviluppo del modello ML, riducendo al contempo il lavoro pesante indifferenziato associato alla creazione della pipeline dell'insieme seriale.

Inoltre, alcune delle considerazioni discusse in precedenza sul disaccoppiamento, sulla scelta dell’algoritmo e del framework per lo sviluppo e la distribuzione del modello sono rilevanti anche in questo caso. Ad esempio, poiché ogni modello è ospitato su un contenitore separato, hai flessibilità nella selezione del framework ML che meglio si adatta a ciascun modello e al tuo caso d'uso complessivo. Inoltre, dal punto di vista del disaccoppiamento e del funzionamento, è possibile continuare ad aggiornare o modificare i singoli passaggi molto più facilmente, senza incidere sugli altri modelli.

Anche la pipeline di inferenza SageMaker è integrata con Registro dei modelli SageMaker per la catalogazione dei modelli, il controllo delle versioni, la gestione dei metadati e la distribuzione regolamentata negli ambienti di produzione per supportare best practice operative coerenti. È integrata anche la pipeline di inferenza SageMaker Amazon Cloud Watch per consentire il monitoraggio dei modelli multi-contenitore nelle pipeline di inferenza. Puoi anche ottenere visibilità in metriche in tempo reale per comprendere meglio le invocazioni e la latenza per ciascun contenitore nella pipeline, il che aiuta nella risoluzione dei problemi e nell'ottimizzazione delle risorse.

Pipeline di inferenza seriale (con chiamata di modello mirata da un gruppo) utilizzando una pipeline di inferenza SageMaker

Endpoint multimodello SageMaker (MME) forniscono una soluzione conveniente per distribuire un gran numero di modelli ML dietro un singolo endpoint. Le motivazioni per l'utilizzo di endpoint multimodello potrebbero includere l'invocazione di un modello personalizzato specifico in base alle caratteristiche della richiesta (come origine, posizione geografica, personalizzazione dell'utente e così via) o semplicemente l'hosting di più modelli dietro lo stesso endpoint per ottenere l'ottimizzazione dei costi.

Quando distribuisci più modelli su un singolo endpoint abilitato per più modelli, tutti i modelli condividono le risorse di calcolo e il contenitore di servizio del modello. La pipeline di inferenza SageMaker può essere distribuita su un MME, dove uno dei contenitori nella pipeline può servire dinamicamente le richieste in base al modello specifico richiamato. Dal punto di vista della pipeline, i modelli hanno requisiti di preelaborazione identici e si aspettano lo stesso set di funzionalità, ma sono addestrati per allinearsi a un comportamento specifico. Il diagramma seguente illustra un modello di riferimento del funzionamento di questa pipeline integrata.

Con gli MME, la richiesta di inferenza che ha origine dall'applicazione client dovrebbe specificare il modello di destinazione che deve essere richiamato. Il primo contenitore nella pipeline gestisce la richiesta iniziale, esegue alcune elaborazioni e quindi invia la risposta intermedia come richiesta al secondo contenitore nella pipeline, che ospita più modelli. In base al modello di destinazione specificato nella richiesta di inferenza, il modello viene richiamato per generare un'inferenza. L'inferenza generata viene inviata al contenitore successivo nella pipeline per un'ulteriore elaborazione. Ciò accade per ogni contenitore successivo nella pipeline e infine SageMaker restituisce la risposta finale all'applicazione client chiamante.

Più artefatti del modello vengono mantenuti in un bucket S3. Quando viene richiamato un modello specifico, SageMaker lo carica dinamicamente sul contenitore che ospita l'endpoint. Se il modello è già caricato nella memoria del container, la chiamata è più veloce perché SageMaker non ha bisogno di scaricare il modello da Amazon S3. Se l'utilizzo della memoria dell'istanza è elevato e viene richiamato un nuovo modello che pertanto deve essere caricato, i modelli non utilizzati vengono scaricati dalla memoria. I modelli scaricati rimangono tuttavia nel volume di storage dell'istanza e possono essere caricati nuovamente nella memoria del container in un secondo momento, senza essere scaricati nuovamente dal bucket S3.

Una delle considerazioni chiave durante l'utilizzo degli MME è comprendere il comportamento della latenza di invocazione del modello. Come discusso in precedenza, i modelli vengono caricati dinamicamente nella memoria del contenitore dell'istanza che ospita l'endpoint quando richiamati. Pertanto, la chiamata del modello potrebbe richiedere più tempo quando viene richiamata per la prima volta. Quando il modello è già nella memoria del contenitore dell'istanza, le invocazioni successive sono più veloci. Se l'utilizzo della memoria di un'istanza è elevato ed è necessario caricare un nuovo modello, i modelli non utilizzati vengono scaricati. Se il volume di storage dell'istanza è pieno, i modelli non utilizzati vengono eliminati dal volume di storage. SageMaker gestisce completamente il carico e lo scarico dei modelli, senza che tu debba intraprendere alcuna azione specifica. Tuttavia, è importante comprendere questo comportamento perché ha implicazioni sulla latenza di chiamata del modello e quindi sulla latenza end-to-end complessiva.

Opzioni di hosting della pipeline

SageMaker ne fornisce molteplici tipo di istanza opzioni tra cui scegliere per la distribuzione di modelli ML e la creazione di pipeline di inferenza, in base al caso d'uso, alla velocità effettiva e ai requisiti di costo. Ad esempio, puoi scegliere istanze ottimizzate per CPU o GPU per creare pipeline di inferenza seriale, su un singolo contenitore o su più contenitori. Tuttavia, a volte vi sono requisiti in cui è necessario avere flessibilità e supporto per eseguire modelli su istanze basate su CPU o GPU all'interno della stessa pipeline per una maggiore flessibilità.

Ora puoi utilizzare NVIDIA Triton Inference Server per servire modelli per l'inferenza su SageMaker per requisiti di elaborazione eterogenei. Guardare Distribuisci intelligenza artificiale veloce e scalabile con NVIDIA Triton Inference Server in Amazon SageMaker per ulteriori dettagli.

Conclusione

Man mano che le organizzazioni scoprono e creano nuove soluzioni basate sul machine learning, gli strumenti necessari per orchestrare queste pipeline dovrebbero essere sufficientemente flessibili da supportare in base a un determinato caso d'uso, semplificando e riducendo al tempo stesso le spese generali operative in corso. SageMaker offre molteplici opzioni per progettare e costruire questi flussi di lavoro di inferenza seriale, in base alle tue esigenze.

Non vediamo l'ora di sentire la tua opinione sui casi d'uso che stai creando utilizzando le pipeline di inferenza seriale. Se hai domande o feedback, condividili nei commenti.

Circa gli autori

Rahul Sharma è Senior Solutions Architect presso AWS Data Lab e aiuta i clienti AWS a progettare e realizzare soluzioni AI/ML. Prima di entrare in AWS, Rahul ha trascorso diversi anni nel settore finanziario e assicurativo, aiutando i clienti a creare piattaforme dati e analitiche.

Anand Prakash è Senior Solutions Architect presso AWS Data Lab. Anand si concentra sull'aiutare i clienti a progettare e creare soluzioni di IA/ML, analisi dei dati e database per accelerare il loro percorso verso la produzione.

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 l'inferenza del modello ad alte prestazioni su SageMaker.

Saurabh Trikande è un Senior Product Manager per Amazon SageMaker Inference. È appassionato di lavorare con i clienti e rendere più accessibile l'apprendimento automatico. Nel tempo libero, Saurabh ama fare escursioni, conoscere tecnologie innovative, seguire TechCrunch e trascorrere del tempo con la sua famiglia.