Logo Zephyrnet

MLOp all'edge con Amazon SageMaker Edge Manager e AWS IoT Greengrass

Data:

Internet of Things (IoT) ha consentito ai clienti di diversi settori, come quello manifatturiero, automobilistico ed energetico, di monitorare e controllare gli ambienti del mondo reale. Implementando una varietà di dispositivi IoT perimetrali come telecamere, termostati e sensori, puoi raccogliere dati, inviarli al cloud e creare modelli di machine learning (ML) per prevedere anomalie, guasti e altro ancora. Tuttavia, se il caso d'uso richiede una previsione in tempo reale, è necessario arricchire la soluzione IoT con funzionalità ML at the edge (ML@Edge). ML @ Edge è un concetto che separa il ciclo di vita del modello ML dal ciclo di vita dell'app e consente di eseguire una pipeline ML end-to-end che include preparazione dei dati, creazione di modelli, compilazione e ottimizzazione del modello, distribuzione del modello (a un parco dispositivi perimetrali), esecuzione del modello e monitoraggio e governo del modello. Distribuisci l'app una volta ed esegui la pipeline ML tutte le volte che vuoi.

Come puoi immaginare, implementare tutti i passaggi proposti dal concept ML@Edge non è banale. Ci sono molte domande che gli sviluppatori devono affrontare per implementare una soluzione ML@Edge completa, ad esempio:

  • Come faccio a utilizzare i modelli ML su una flotta (centinaia, migliaia o milioni) di dispositivi perimetrali?
  • Come posso proteggere il mio modello mentre lo distribuisco e lo eseguo all'edge?
  • Come posso monitorare le prestazioni del mio modello e riqualificarlo, se necessario?

In questo post imparerai come rispondere a tutte queste domande e costruire una soluzione end-to-end per automatizzare la tua pipeline ML@Edge. Vedrai come usarlo Gestore perimetrale di Amazon SageMaker, Amazon Sage Maker Studioe AWS IoT Greengrass v2 per creare un ambiente MLOps (ML Operations) che automatizza il processo di creazione e distribuzione di modelli ML a grandi flotte di dispositivi perimetrali.

Nelle sezioni successive, presenteremo un'architettura di riferimento che descrive in dettaglio tutti i componenti e i flussi di lavoro necessari per creare una soluzione completa per MLOp incentrata sui carichi di lavoro edge. Quindi ci addentriamo nei passaggi che questa soluzione esegue automaticamente per costruire e preparare un nuovo modello. Ti mostriamo anche come preparare i dispositivi perimetrali per iniziare a distribuire, eseguire e monitorare i modelli ML e come monitorare e mantenere i modelli ML distribuiti nel tuo parco dispositivi.

Panoramica della soluzione

La produzione di solidi modelli ML richiede la collaborazione di più persone, come data scientist, ingegneri ML, ingegneri dei dati e stakeholder aziendali, in un'infrastruttura semi-automatizzata a seguito di operazioni specifiche (MLOps). Inoltre, la modularizzazione dell'ambiente è importante per dare a tutte queste diverse persone la flessibilità e l'agilità per sviluppare o migliorare (indipendentemente dal flusso di lavoro) la componente di cui sono responsabili. Un esempio di tale infrastruttura è costituito da più account AWS che consentono questa collaborazione e produzione dei modelli ML sia nel cloud che verso i dispositivi perimetrali. Nella seguente architettura di riferimento, mostriamo come abbiamo organizzato i molteplici account e servizi che compongono questa piattaforma MLOps end-to-end per creare modelli ML e distribuirli all'edge.

Questa soluzione è composta dai seguenti account:

  • Conto Data Lake – I tecnici dei dati acquisiscono, archiviano e preparano i dati da più origini dati, inclusi database locali e dispositivi IoT.
  • Conto utensili – Gli operatori IT gestiscono e controllano le pipeline CI/CD per la distribuzione continua automatizzata e l'implementazione di pacchetti di modelli ML negli account di pre-produzione e produzione per i dispositivi edge remoti. Le esecuzioni delle pipeline CI/CD sono automatizzate tramite l'utilizzo di Amazon EventBridge, che monitora gli eventi relativi allo stato di modifica dei modelli e delle destinazioni ML AWS Code Pipeline.
  • Conto di sperimentazione e sviluppo – I data scientist possono condurre ricerche e sperimentare molteplici tecniche di modellazione e algoritmi per risolvere problemi aziendali basati su ML, creando soluzioni proof of concept. Ingegneri e data scientist di ML collaborano per scalare un proof of concept, creando flussi di lavoro automatizzati utilizzando Pipeline di Amazon SageMaker per preparare i dati e creare, addestrare e creare pacchetti di modelli ML. L'implementazione delle pipeline è guidata tramite pipeline CI/CD, mentre il controllo della versione dei modelli viene ottenuto utilizzando il Registro dei modelli Amazon SageMaker. I data scientist valutano le metriche di più versioni del modello e richiedono la promozione del modello migliore in produzione attivando la pipeline CI/CD.
  • Conto di pre-produzione – Prima della promozione del modello nell'ambiente di produzione, il modello deve essere testato per garantirne la robustezza in un ambiente di simulazione. Pertanto, l'ambiente di pre-produzione è un simulatore dell'ambiente di produzione, in cui gli endpoint del modello SageMaker vengono distribuiti e testati automaticamente. I metodi di prova possono includere un test di integrazione, un test di stress o test specifici di ML sui risultati dell'inferenza. In questo caso, l'ambiente di produzione non è un endpoint del modello SageMaker ma un dispositivo perimetrale. Per simulare un dispositivo perimetrale in pre-produzione, sono possibili due approcci: utilizzare un Cloud di calcolo elastico di Amazon (Amazon EC2) con le stesse caratteristiche hardware oppure utilizza un banco di prova in laboratorio costituito dai dispositivi effettivi. Con questa infrastruttura, la pipeline CI/CD distribuisce il modello al simulatore corrispondente ed esegue automaticamente più test. Dopo che i test sono stati eseguiti con successo, la pipeline CI/CD richiede l'approvazione manuale (ad esempio, dallo stakeholder IoT per promuovere il modello alla produzione).
  • Conto di produzione – Nel caso di hosting del modello sul cloud AWS, la pipeline CI/CD distribuisce un endpoint del modello SageMaker sull'account di produzione. In questo caso, l'ambiente di produzione è costituito da più flotte di dispositivi periferici. Pertanto, la pipeline CI/CD utilizza Edge Manager per distribuire i modelli al parco di dispositivi corrispondente.
  • Dispositivi Edge – I dispositivi perimetrali remoti sono dispositivi hardware in grado di eseguire modelli ML utilizzando Edge Manager. Consente all'applicazione su tali dispositivi di gestire i modelli, eseguire l'inferenza sui modelli e acquisire i dati in modo sicuro Servizio di archiviazione semplice Amazon (Amazon S3).

Progetti SageMaker aiutarti ad automatizzare il processo di fornitura delle risorse all'interno di ciascuno di questi account. Non ci addentriamo in questa funzione, ma per saperne di più su come creare un modello di progetto SageMaker che distribuisca i modelli ML tra gli account, dai un'occhiata Distribuzione del modello multi-account con Amazon SageMaker Pipelines.

Account di pre-produzione: gemello digitale

Dopo il processo di formazione, il modello risultante deve essere valutato. Nell'account di pre-produzione, hai un dispositivo Edge simulato. Rappresenta il gemello digitale del dispositivo perimetrale su cui viene eseguito il modello ML in produzione. Questo ambiente ha il duplice scopo di eseguire i classici test (come unità, integrazione e fumo) e di essere un playground per il team di sviluppo. Questo dispositivo viene simulato utilizzando un'istanza EC2 in cui sono stati distribuiti tutti i componenti necessari per gestire il modello ML.

I servizi coinvolti sono i seguenti:

  • AWS IoT Core - Noi usiamo AWS IoT Core per creare oggetti oggetto AWS IoT, creare un parco dispositivi, registrare il parco dispositivi in ​​modo che possa interagire con il cloud, creare certificati X.509 per autenticare dispositivi edge su AWS IoT Core, associare l'alias ruolo con AWS IoT Core che è stato generato quando il parco istanze ha creato, ottieni un endpoint specifico dell'account AWS per il provider di credenziali, ottieni un file Amazon Root CA ufficiale e carica il file Amazon CA su Amazon S3.
  • Amazon Sagemaker Neo – Sagemaker Neo ottimizza automaticamente i modelli di apprendimento automatico per l'inferenza per un'esecuzione più veloce senza perdita di precisione. Supporta il modello di machine learning già creato con DarkNet, Keras, MXNet, PyTorch, TensorFlow, TensorFlow-Lite, ONNX o XGBoost e addestrato in Amazon SageMaker o altrove. Quindi scegli la piattaforma hardware di destinazione, che può essere un'istanza di hosting SageMaker o un dispositivo edge basato su processori di Ambarella, Apple, ARM, Intel, MediaTek, Nvidia, NXP, Qualcomm, RockChip, Texas Instruments o Xilinx.
  • Gestore perimetrale – Usiamo Edge Manager per registrare e gestire il dispositivo perimetrale all'interno delle flotte Sagemaker. Le flotte sono raccolte di dispositivi raggruppati logicamente che puoi utilizzare per raccogliere e analizzare i dati. Inoltre, Edge Manager packager, impacchetta il modello ottimizzato e crea un componente AWS IoT Greengrass V2 che può essere distribuito direttamente. Puoi utilizzare Edge Manager per utilizzare i modelli ML su una flotta di fotocamere intelligenti, altoparlanti intelligenti, robot e altre flotte di dispositivi SageMaker.
  • AWS IoT Greengrass V2 - AWS IoT Greengrass ti consente di distribuire componenti nei dispositivi simulati utilizzando un'istanza EC2. Utilizzando l'agente AWS IoT Greengrass V2 nelle istanze EC2, possiamo semplificare l'accesso, la gestione e la distribuzione dell'agente e del modello di Edge Manager sui dispositivi. Senza AWS IoT Greengrass V2, la configurazione di dispositivi e flotte per l'utilizzo di Edge Manager richiede la copia manuale dell'agente da un bucket di rilascio S3. Con l'integrazione di AWS IoT Greengrass V2 e Edge Manager, è possibile utilizzare i componenti di AWS IoT Greengrass V2. I componenti sono moduli software predefiniti che possono connettere dispositivi perimetrali a servizi AWS o servizi di terze parti tramite AWS IoT Greengrass.
  • Agente Edge Manager – L'agente Edge Manager viene distribuito tramite AWS IoT Greengrass V2 nell'istanza EC2. L'agente può caricare più modelli alla volta ed effettuare inferenze con modelli caricati sui dispositivi perimetrali. Il numero di modelli che l'agente può caricare è determinato dalla memoria disponibile sul dispositivo.
  • Amazon S3 – Usiamo un bucket S3 per archiviare i dati acquisiti dall'inferenza dall'agente Edge Manager.

Possiamo definire un account di pre-produzione come un gemello digitale per testare i modelli ML prima di spostarli in dispositivi edge reali. Ciò offre i seguenti vantaggi:

  • Agilità e flessibilità – I data scientist e gli ingegneri ML devono convalidare rapidamente se il modello ML e gli script associati (script di preelaborazione e di inferenza) funzioneranno sull'edge del dispositivo. Tuttavia, i dipartimenti di IoT e scienza dei dati nelle grandi imprese possono essere entità diverse. Replicando in modo identico lo stack tecnologico nel cloud, i data scientist e gli ingegneri ML possono iterare e consolidare gli artefatti prima dell'implementazione.
  • Valutazione del rischio e tempi di produzione accelerati – La distribuzione sul dispositivo perimetrale è la fase finale del processo. Dopo aver convalidato tutto in un ambiente isolato e autonomo, assicurati che sia conforme alle specifiche richieste dall'edge in termini di qualità, prestazioni e integrazione. Ciò consente di evitare un ulteriore coinvolgimento di altre persone nel reparto IoT per correggere e ripetere le versioni degli artefatti.
  • Collaborazione in team migliorata e qualità e prestazioni migliorate – Il team di sviluppo può valutare immediatamente l'impatto del modello ML analizzando le metriche dell'hardware edge e misurando il livello di interazione con strumenti di terze parti (es. I/O rate). Quindi, il team IoT è responsabile solo della distribuzione nell'ambiente di produzione e può essere certo che gli artefatti siano accurati per un ambiente di produzione.
  • Parco giochi integrato per i test – Dato l'obiettivo dei modelli ML, l'ambiente di pre-produzione in un flusso di lavoro tradizionale dovrebbe essere rappresentato da un dispositivo perimetrale esterno all'ambiente cloud. Questo introduce un altro livello di complessità. Sono necessarie integrazioni per raccogliere metriche e feedback. Invece, utilizzando l'ambiente simulato del gemello digitale, le interazioni sono ridotte e il time to market è ridotto.

Account di produzione e ambiente perimetrale

Dopo che i test sono stati completati e la stabilità dell'artefatto è stata raggiunta, è possibile procedere alla distribuzione della produzione attraverso le pipeline. La distribuzione dell'artefatto avviene a livello di codice dopo che un operatore ha approvato l'artefatto. Tuttavia, l'accesso al Console di gestione AWS viene concesso agli operatori in modalità di sola lettura per poter monitorare i metadati associati alle flotte e quindi avere informazioni dettagliate sulla versione del modello ML distribuito e su altre metriche associate al ciclo di vita.

I parchi dispositivi perimetrali appartengono all'account di produzione AWS. Questo account ha specifiche configurazioni di rete e sicurezza per consentire la comunicazione tra il cloud e i dispositivi perimetrali. I principali servizi AWS distribuiti nell'account di produzione sono Edge Manager, che è responsabile della gestione di tutte le flotte di dispositivi, della raccolta dei dati e del funzionamento dei modelli ML, e AWS IoT Core, che gestisce oggetti, certificati, alias di ruolo ed endpoint IoT.

Allo stesso tempo, dobbiamo configurare un dispositivo perimetrale con i servizi e i componenti per gestire i modelli ML. I componenti principali sono i seguenti:

  • AWS IoT Greengrass V2
  • Un agente Edge Manager
  • Certificati AWS IoT
  • Application.py, che è responsabile dell'orchestrazione del processo di inferenza (recupero delle informazioni dall'origine dati perimetrale ed esecuzione dell'inferenza utilizzando l'agente Edge Manager e il modello ML caricato)
  • Una connessione ad Amazon S3 o all'account data lake per archiviare i dati inferenziati

Pipeline di machine learning automatizzate

Ora che sai di più sull'organizzazione e sui componenti dell'architettura di riferimento, possiamo approfondire la pipeline ML che utilizziamo per creare, addestrare e valutare il modello ML all'interno dell'account di sviluppo.

Una pipeline (costruita utilizzando Condutture per la costruzione di modelli Amazon SageMaker) è una serie di passaggi interconnessi definiti da una definizione di pipeline JSON. Questa definizione di pipeline codifica una pipeline utilizzando un grafico aciclico diretto (DAG). Questo DAG fornisce informazioni sui requisiti e sulle relazioni tra ogni passaggio della pipeline. La struttura del DAG di una pipeline è determinata dalle dipendenze dei dati tra i passaggi. Queste dipendenze di dati vengono create quando le proprietà dell'output di un passaggio vengono passate come input a un altro passaggio.

Per consentire ai team di data science di automatizzare facilmente la creazione di nuove versioni dei modelli ML, è importante introdurre passaggi di convalida e dati automatizzati per l'alimentazione e il miglioramento continui dei modelli ML, nonché strategie di monitoraggio dei modelli per abilitare l'attivazione della pipeline. Il diagramma seguente mostra una pipeline di esempio.

Per abilitare le automazioni e le funzionalità MLOps, è importante creare componenti modulari per creare artefatti di codice riutilizzabili che possono essere condivisi in diversi passaggi e casi d'uso ML. Ciò consente di spostare rapidamente l'implementazione da una fase di sperimentazione a una fase di produzione automatizzando la transizione.

I passaggi per definire una pipeline ML per abilitare la formazione continua e il versioning dei modelli ML sono i seguenti:

  • Pre-elaborazione – Il processo di pulizia dei dati, ingegneria delle funzionalità e creazione di set di dati per l'addestramento dell'algoritmo ML
  • Allenamento – Il processo di addestramento dell'algoritmo ML sviluppato per la generazione di una nuova versione dell'artefatto del modello ML
  • Valutazione – Il processo di valutazione del modello ML generato, per l'estrazione di metriche chiave relative al comportamento del modello su nuovi dati non visti durante la fase di training
  • Iscrizione – Il processo di versionamento del nuovo artefatto del modello ML addestrato collegando le metriche estratte con l'artefatto generato

Puoi vedere maggiori dettagli su come creare una pipeline SageMaker di seguito taccuino.

Attiva pipeline CI/CD utilizzando EventBridge

Al termine della creazione del modello, è possibile avviare il processo di distribuzione. L'ultimo passaggio della pipeline SageMaker definito nella sezione precedente registra una nuova versione del modello nel gruppo di registro del modello SageMaker specifico. La distribuzione di una nuova versione del modello ML viene gestita utilizzando lo stato del registro del modello. Approvando o rifiutando manualmente una versione del modello ML, questo passaggio genera un evento acquisito da EventBridge. Questo evento può quindi avviare una nuova pipeline (questa volta CI/CD) per la creazione di una nuova versione del componente AWS IoT Greengrass che viene quindi distribuito negli account di pre-produzione e produzione. Lo screenshot seguente mostra la nostra regola EventBridge definita.

Questa regola monitora il gruppo di pacchetti di modelli SageMaker cercando gli aggiornamenti dei pacchetti di modelli nello stato Approved or Rejected.

La regola EventBridge viene quindi configurata per indirizzare CodePipeline, che avvia il flusso di lavoro di creazione di un nuovo componente AWS IoT Greengrass utilizzando Amazon Sage Maker Neo e Gestore perimetrale.

Ottimizza i modelli ML per l'architettura di destinazione

Neo ti consente di ottimizzare i modelli ML per eseguire l'inferenza su dispositivi edge (e nel cloud). Ottimizza automaticamente i modelli ML per prestazioni migliori in base all'architettura di destinazione e disaccoppia il modello dal framework originale, consentendoti di eseguirlo su un runtime leggero.

Fare riferimento a quanto segue taccuino per un esempio di come compilare un modello PyTorch Resnet18 usando Neo.

Crea il pacchetto di distribuzione includendo il componente AWS IoT Greengrass

Edge Manager consente di gestire, proteggere, distribuire e monitorare i modelli su un parco dispositivi perimetrali. Nel seguente taccuino, puoi vedere maggiori dettagli su come creare una flotta minimalista di dispositivi perimetrali ed eseguire alcuni esperimenti con questa funzione.

Dopo aver configurato il parco istanze e compilato il modello, è necessario eseguire un processo di confezionamento di Edge Manager, che prepara il modello da distribuire nel parco istanze. Puoi avviare un processo di confezionamento utilizzando Boto3 SDK. Per i nostri parametri, utilizziamo il modello ottimizzato e i metadati del modello. Aggiungendo i seguenti parametri a OutputConfig, il lavoro prepara anche un componente AWS IoT Greengrass V2 con il modello:

  • PresetDeploymentType
  • PresetDeploymentConfig

Vedi il seguente codice:

import boto3
import time

SageMaker_client = boto3.client('SageMaker')

SageMaker_client.create_edge_packaging_job(
    EdgePackagingJobName="mlops-edge-packaging-{}".format(int(time.time()*1000)),
    CompilationJobName=compilation_job_name,
    ModelName="PytorchMLOpsEdgeModel",
    ModelVersion="1.0.0",
    RoleArn=role,
    OutputConfig={
        'S3OutputLocation': 's3://{}/model/'.format(bucket_name),
        "PresetDeploymentType": "GreengrassV2Component",
        "PresetDeploymentConfig": json.dumps(
            {"ComponentName": component_name, "ComponentVersion": component_version}
        ),
    }
)

Distribuisci modelli ML ai margini su larga scala

Ora è il momento di distribuire il modello alla tua flotta di dispositivi perimetrali. In primo luogo, dobbiamo assicurarci di avere il necessario Gestione dell'identità e dell'accesso di AWS (SONO) permessi per eseguire il provisioning dei nostri dispositivi IoT e siamo in grado di distribuirvi componenti. Abbiamo bisogno di due elementi di base per iniziare l'onboarding dei dispositivi nella nostra piattaforma IoT:

  • politica IAM – Questa politica consente il provisioning automatico di tali dispositivi, collegati all'utente o al ruolo che esegue il provisioning. Dovrebbe disporre delle autorizzazioni di scrittura IoT per creare l'oggetto e il gruppo IoT, nonché per collegare i criteri necessari al dispositivo. Per ulteriori informazioni, fare riferimento a Criterio IAM minimo per il programma di installazione per il provisioning delle risorse.
  • Ruolo IAM – questo ruolo è legato alle cose e ai gruppi IoT che creiamo. Puoi creare questo ruolo al momento del provisioning con autorizzazioni di base, ma mancherà di funzionalità come l'accesso ad Amazon S3 o Servizio di gestione delle chiavi AWS (AWS KMS) che potrebbe essere necessario in seguito. Puoi creare questo ruolo in anticipo e riutilizzarlo quando eseguiamo il provisioning del dispositivo. Per ulteriori informazioni, fare riferimento a Autorizza i dispositivi core a interagire con AWS.

Installazione e provisioning di AWS IoT Greengrass

Dopo aver implementato la policy e il ruolo IAM, siamo pronti per farlo installa il software AWS IoT Greengrass Core con il provisioning automatico delle risorse. Sebbene sia possibile eseguire il provisioning delle risorse IoT seguendo i passaggi manuali, esiste la pratica procedura di provisioning automatico di queste risorse durante l'installazione del nucleo AWS IoT Greengrass v2. Questa è l'opzione preferita per eseguire rapidamente l'onboarding di nuovi dispositivi nella piattaforma. Oltretutto default-jdk, è necessario installare altri pacchetti, come curl, unzipe python3.

Quando eseguiamo il provisioning del nostro dispositivo, il nome dell'oggetto IoT deve essere esattamente lo stesso del dispositivo perimetrale definito in Edge Manager, altrimenti i dati non verranno acquisiti nel bucket S3 di destinazione.

Il programma di installazione può creare il ruolo e l'alias AWS IoT Greengrass durante l'installazione se non esistono. Tuttavia, verranno creati con autorizzazioni minime e richiederanno l'aggiunta manuale di più policy per interagire con altri servizi come Amazon S3. Ti consigliamo di creare in anticipo queste risorse IAM, come mostrato in precedenza, e di riutilizzarle durante l'onboarding di nuovi dispositivi nell'account.

Imballaggio del modello e dei componenti di inferenza

Dopo che il nostro codice è stato sviluppato, possiamo distribuire sia il codice (per l'inferenza) che i nostri modelli ML come componenti nei nostri dispositivi.

Dopo che il modello ML è stato addestrato in SageMaker, puoi ottimizzare il modello con Neo utilizzando un lavoro di compilazione Sagemaker. Gli artefatti del modello compilato risultanti possono quindi essere impacchettati in un componente GreenGrass V2 utilizzando il packager Edge Manager. Quindi, può essere registrato come componente personalizzato nel file I miei componenti sezione sulla console AWS IoT Greengrass. Questo componente contiene già i comandi del ciclo di vita necessari per scaricare e decomprimere l'artefatto del modello nel nostro dispositivo, in modo che il codice di inferenza possa caricarlo per inviare le immagini acquisite attraverso di esso.

Per quanto riguarda il codice di inferenza, dobbiamo creare un componente utilizzando la console o Interfaccia della riga di comando di AWS (AWS CLI). Innanzitutto, imballiamo il nostro codice di inferenza sorgente e le dipendenze necessarie su Amazon S3. Dopo aver caricato il codice, possiamo creare il nostro componente utilizzando una ricetta in .yaml o JSON come il seguente esempio:

---
RecipeFormatVersion: 2020-01-25
ComponentName: dummymodel.inference
ComponentVersion: 0.0.1
ComponentDescription: Deploys inference code to a client
ComponentPublisher: Amazon Web Services, Inc.
ComponentDependencies:
  aws.GreenGrass.TokenExchangeService:
    VersionRequirement: '>=0.0.0'
    DependencyType: HARD
  dummymodel:
    VersionRequirement: '>=0.0.0'
    DependencyType: HARD
Manifests:
  - Platform:
      os: linux
      architecture: "*"
    Lifecycle:
      install: |-
        apt-get install python3-pip
        pip3 install numpy
        pip3 install sysv_ipc
        pip3 install boto3
        pip3 install grpcio-tools
        pip3 install grpcio
        pip3 install protobuf
        pip3 install SageMaker
        tar xf {artifacts:path}/sourcedir.tar.gz
      run:
        script: |-
          sleep 5 && sudo python3 {work:path}/inference.py 
    Artifacts:
      - URI: s3://BUCKET-NAME/path/to/inference/sourcedir.tar.gz
        Permission:
          Execute: OWNER

Questa ricetta di esempio mostra il nome e la descrizione del nostro componente, nonché i prerequisiti necessari prima del nostro comando di esecuzione dello script. La ricetta decomprime l'artefatto in un ambiente di cartelle di lavoro nel dispositivo e utilizziamo quel percorso per eseguire il nostro codice di inferenza. Il comando AWS CLI per creare tale ricetta è:

aws greengrassv2 create-component-version --region $REGION 
                                          --inline-recipe fileb://path/to/recipe.yaml

Ora puoi vedere questo componente creato sulla console AWS IoT Greengrass.

Fai attenzione al fatto che la versione del componente è importante e deve essere specificata nel file della ricetta. La ripetizione dello stesso numero di versione restituirà un errore.

Dopo che il nostro modello e il codice di inferenza sono stati impostati come componenti, siamo pronti per distribuirli.

Distribuisci l'applicazione e il modello utilizzando AWS IoT Greengrass

Nelle sezioni precedenti, hai imparato come impacchettare il codice di inferenza e i modelli ML. Ora possiamo creare una distribuzione con più componenti che includono sia i componenti che le configurazioni necessarie affinché il nostro codice di inferenza interagisca con il modello nel dispositivo perimetrale.

L'agente Edge Manager è il componente che deve essere installato su ciascun dispositivo perimetrale per abilitare tutte le funzionalità di Edge Manager. Sulla console SageMaker abbiamo definito un parco dispositivi a cui è associato un bucket S3. Tutti i dispositivi perimetrali associati al parco istanze acquisiranno e segnaleranno i propri dati a questo percorso S3. L'agente può essere distribuito come componente in AWS IoT Greengrass v2, il che semplifica l'installazione e la configurazione rispetto a se l'agente fosse distribuito in modalità standalone. Quando si distribuisce l'agente come componente, è necessario specificarne i parametri di configurazione, ovvero il parco dispositivi e il percorso S3.

Creiamo una configurazione di distribuzione con i componenti personalizzati per il modello e il codice che abbiamo appena creato. Questa configurazione è definita in un file JSON che elenca il nome e la destinazione della distribuzione, nonché i componenti della distribuzione. Possiamo aggiungere e aggiornare i parametri di configurazione di ogni componente, come nell'agente Edge Manager, dove specifichiamo il nome della flotta e il bucket.

{
    "targetArn": "targetArn",
    "deploymentName": "dummy-deployment",
    "components": {
        "aws.GreenGrass.Nucleus": {
            "version": "2.5.3",
        },
        "aws.GreenGrass.Cli": {
            "version": "2.5.3"
        },
        "aws.GreenGrass.SageMakerEdgeManager": {
            "version": 1.1.0,
            "configurationUpdate": {
                "merge": {
                "DeviceFleetName": "FLEET-NAME",
                "BucketName": "BUCKET-NAME-URI"
                }
            }
        },
        "dummymodel.inference": {
            "version": "0.0.1"
        },
        "dummymodel": {
            "version": "0.0.1"
        }
    }
}

Vale la pena notare che abbiamo aggiunto non solo il modello, i componenti di inferenza e l'agente, ma anche l'interfaccia a riga di comando e il nucleo di AWS IoT Greengrass come componenti. Il primo può aiutare a eseguire il debug di determinate distribuzioni localmente sul dispositivo. Quest'ultimo viene aggiunto alla distribuzione per configurare l'accesso alla rete necessario dal dispositivo stesso, se necessario (ad esempio, impostazioni proxy), e anche nel caso in cui si desideri eseguire un aggiornamento OTA del nucleo AWS IoT Greengrass v2. Il nucleo non viene distribuito perché è installato nel dispositivo e verrà applicato solo l'aggiornamento della configurazione (a meno che non sia in atto un aggiornamento). Per eseguire la distribuzione, è sufficiente eseguire il comando seguente sulla configurazione precedente. Ricordarsi di impostare l'ARN di destinazione a cui verrà applicata la distribuzione (un oggetto IoT o un gruppo IoT). Possiamo anche distribuire questi componenti dalla console.

aws greengrassv2 create-deployment --region $REGION 
                                   --cli-input-json file://path/to/deployment.json

Monitora e gestisci i modelli ML distribuiti all'edge

Ora che la tua applicazione è in esecuzione sui dispositivi perimetrali, è tempo di capire come monitorare il parco istanze per migliorare governance, manutenzione e visibilità. Sulla console SageMaker, scegli Gestore perimetrale nel riquadro di navigazione, quindi scegli Flotte di dispositivi perimetrali. Da qui, scegli la tua flotta.

Nella pagina dei dettagli della flotta, puoi vedere alcuni metadati dei modelli in esecuzione su ciascun dispositivo della tua flotta. Il rapporto sulla flotta viene generato ogni 24 ore.

I dati acquisiti da ciascun dispositivo tramite l'Edge Agent vengono inviati a un bucket S3 in formato json lines (JSONL). Il processo di invio dei dati acquisiti è gestito dal punto di vista dell'applicazione. Sei quindi libero di decidere se inviare questi dati, come e con quale frequenza.

Puoi utilizzare questi dati per molte cose, come il monitoraggio della deriva dei dati e della qualità del modello, la creazione di un nuovo set di dati, l'arricchimento di un data lake e altro ancora. Un semplice esempio di come utilizzare questi dati è quando si identifica una deriva dei dati nel modo in cui gli utenti interagiscono con l'applicazione ed è necessario addestrare un nuovo modello. Quindi crei un nuovo set di dati con i dati acquisiti e lo copi di nuovo nell'account di sviluppo. Ciò può avviare automaticamente una nuova esecuzione dell'ambiente che crea un nuovo modello e lo ridistribuisce all'intero parco istanze per mantenere le prestazioni della soluzione distribuita.

Conclusione

In questo post, hai imparato come creare una soluzione completa che combini MLOps e ML@Edge utilizzando i servizi AWS. Costruire una soluzione del genere non è banale, ma speriamo che l'architettura di riferimento presentata in questo post possa ispirarti e aiutarti a costruire un'architettura solida per le tue sfide aziendali. Puoi anche utilizzare solo le parti oi moduli di questa architettura che si integrano con il tuo ambiente MLOps esistente. Prototipando un singolo modulo alla volta e utilizzando i servizi AWS appropriati per affrontare ogni parte di questa sfida, puoi imparare come creare un solido ambiente MLOps e anche semplificare ulteriormente l'architettura finale.

Come passaggio successivo, ti invitiamo a provare Sagemaker Edge Manager per gestire il tuo ML al ciclo di vita edge. Per ulteriori informazioni sul funzionamento di Edge Manager, vedere Distribuisci modelli all'edge con SageMaker Edge Manager .


Circa gli autori

Bruno Pistone è un AI/ML Specialist Solutions Architect per AWS con sede a Milano. Lavora con clienti di qualsiasi dimensione per aiutarli a comprendere a fondo le loro esigenze tecniche e progettare soluzioni di intelligenza artificiale e machine learning che sfruttino al meglio il cloud AWS e lo stack Amazon Machine Learning. I suoi campi di competenza sono Machine Learning end to end, Machine Learning Industrialization e MLOps. Gli piace passare il tempo con i suoi amici ed esplorare nuovi posti, oltre a viaggiare verso nuove destinazioni.

Matteo Calabrese è un architetto per la consegna dei clienti AI/ML nel team dei servizi professionali AWS. Lavora con grandi imprese EMEA su progetti AI/ML, aiutandole a proporre, progettare, fornire, scalare e ottimizzare i carichi di lavoro di produzione ML. Le sue principali competenze sono ML Operation (MLOps) e Machine Learning in Edge. Il suo obiettivo è abbreviare il loro tempo per valutare e accelerare i risultati aziendali fornendo le migliori pratiche AWS. Nel tempo libero ama fare escursioni e viaggiare.

Raúl Diaz Garcia è un Data Scientist senior nel team dei servizi professionali di AWS. Lavora con grandi clienti aziendali nell'area EMEA, dove li aiuta a abilitare soluzioni relative alla visione artificiale e all'apprendimento automatico nello spazio IoT.

Sokratis Kartakis è un Senior Machine Learning Specialist Solutions Architect per Amazon Web Services. Sokratis si concentra sul consentire ai clienti aziendali di industrializzare le loro soluzioni di Machine Learning (ML) sfruttando i servizi AWS e modellando il loro modello operativo, ovvero la base MLOps e la roadmap di trasformazione, sfruttando le migliori pratiche di sviluppo. Ha trascorso oltre 15 anni inventando, progettando, guidando e implementando soluzioni innovative di ML e Internet of Things (IoT) end-to-end a livello di produzione nei domini dell'energia, vendita al dettaglio, salute, finanza/bancario, sport motoristici ecc. A Sokratis piace passare il tempo libero con la famiglia e gli amici o andare in moto.

Samir Araújo è un AI / ML Solutions Architect presso AWS. Aiuta i clienti a creare soluzioni AI / ML che risolvono le loro sfide aziendali utilizzando AWS. Ha lavorato a diversi progetti AI / ML relativi a visione artificiale, elaborazione del linguaggio naturale, previsioni, ML at the edge e altro ancora. Gli piace giocare con i progetti hardware e di automazione nel tempo libero e ha un interesse particolare per la robotica.

spot_img

L'ultima intelligenza

spot_img