Distribuire modelli di Machine Learning in ambienti di produzione

Articolo
06/24/2023

Questo articolo descrive le procedure consigliate per la distribuzione di modelli di Machine Learning negli ambienti di produzione usando Azure Machine Learning. La distribuzione di modelli di Machine Learning nell'ambiente di produzione è importante per le organizzazioni che usano l'intelligenza artificiale per migliorare le operazioni. Può trattarsi di un processo complesso, ma questo articolo consente di comprendere i passaggi.

Considerazioni sull'architettura

Scegliere il metodo di distribuzione corretto. Ogni metodo di distribuzione presenta vantaggi e svantaggi. È importante scegliere quello più adatto alle esigenze dell'organizzazione. Esistono due metodi di distribuzione principali:
- L'inferenza in tempo reale (online) elabora i dati di input ricevuti, spesso con un requisito di bassa latenza. La bassa latenza è importante per le applicazioni che richiedono risposte immediate, ad esempio il rilevamento delle frodi, il riconoscimento vocale o i sistemi di raccomandazione. L'inferenza in tempo reale è più complessa e costosa da implementare rispetto all'inferenza batch perché richiede un'infrastruttura più veloce e affidabile. Il calcolo sottostante per l'inferenza in tempo reale viene in genere eseguito in modo continuo alle richieste di servizio più velocemente.
- L'inferenza batch (offline) elabora un batch di dati di input di grandi dimensioni contemporaneamente anziché elaborare singolarmente ogni punto dati di input in tempo reale. L'inferenza batch è ideale per scenari di volumi di dati di grandi dimensioni che richiedono un'elaborazione efficiente, ma il tempo di risposta non è critico. Ad esempio, è possibile usare l'inferenza batch per elaborare un set di dati di grandi dimensioni di immagini e il modello di Machine Learning esegue stime su tutte le immagini contemporaneamente. L'inferenza batch è meno costosa e più efficiente dell'inferenza in tempo reale. Il calcolo sottostante per l'inferenza batch viene in genere eseguito solo durante il processo batch.
Machine Learning usa gli endpoint per distribuire modelli in scenari in tempo reale e batch. Gli endpoint forniscono un'interfaccia unificata per richiamare e gestire le distribuzioni di modelli tra i tipi di calcolo. Gli endpoint online gestiti servono, ridimensionano, proteggono e monitorano i modelli di Machine Learning per l'inferenza.

Per altre informazioni, vedere la sezione seguente in questo articolo Metodi di distribuzione.
Garantire la coerenza. È importante distribuire il modello in modo coerente tra ambienti, ad esempio sviluppo, gestione temporanea e produzione. Usare tecnologie di containerizzazione o virtualizzazione, ad esempio ambienti di Machine Learning, per garantire coerenza e incapsulare l'ambiente.
Monitorare le prestazioni. Dopo la distribuzione del modello nell'ambiente di produzione, è necessario tenere traccia delle metriche, ad esempio accuratezza, latenza e velocità effettiva e configurare avvisi per notificare quando le prestazioni sono inferiori ai livelli accettabili. Usare Application Insights e le funzionalità di monitoraggio predefinite degli endpoint gestiti per visualizzare le metriche e creare avvisi.
Implementare misure di sicurezza. Proteggere i dati e i sistemi. È possibile configurare controlli di autenticazione e accesso, crittografare i dati in transito e inattivi, usare la sicurezza di rete e monitorare l'attività sospetta.
Creare un piano per gli aggiornamenti. I modelli di Machine Learning necessitano di aggiornamenti man mano che diventano disponibili nuovi dati e nuovi algoritmi. È importante creare un processo per testare e convalidare il modello aggiornato prima di distribuirlo nell'ambiente di produzione. La distribuzione blu/verde è una strategia comune che aggiorna i modelli di Machine Learning nell'ambiente di produzione. Con la distribuzione blu/verde, è possibile aggiornare un modello a un nuovo ambiente, testarlo e quindi passare al nuovo modello dopo la convalida. La distribuzione blu/verde garantisce che i potenziali problemi con il modello aggiornato non influiscano sui clienti. Per altre informazioni, vedere Distribuzione nativa blu/verde.

Metodi di distribuzione

Considerare le domande seguenti per valutare il modello, confrontare i due metodi di distribuzione e selezionare il metodo più adatto al modello:

Con quale frequenza devono essere generate le previsioni?
Quanto tempo sono necessari i risultati?
Le stime vengono archiviate o usate immediatamente?
Le previsioni devono essere generate singolarmente, in batch di piccole dimensioni o in batch di grandi dimensioni?
La latenza è prevista dal modello?
Quanta potenza di calcolo deve essere eseguita dal modello?
Esistono implicazioni operative e in termini di costi per la gestione del modello?
Come viene attivata la stima? È basato su eventi o pianificato?

Vedere l'albero delle decisioni seguente per determinare il modello di distribuzione più adatto al caso d'uso:

Inferenza batch

L'inferenza batch è un processo semplice che consente l'esecuzione dei modelli in intervalli di tempo o in base ai trigger. Con l'inferenza batch, le applicazioni aziendali possono archiviare stime.

Considerare le procedure consigliate seguenti per l'inferenza batch:

Eseguire operazioni batch usando l'API. Usare gli endpoint batch per creare un endpoint HTTPS durevole che attiva un processo di assegnazione dei punteggi batch per le pipeline di dati pianificate o basate su eventi. L'API può essere integrata con qualsiasi piattaforma di orchestrazione dei dati che supporta la chiamata all'API REST. Per altre informazioni, vedere il punto elenco di integrazione batch in questa sezione e Distribuire i modelli per l'assegnazione dei punteggi negli endpoint batch.
Opzioni di calcolo. I processi di inferenza batch in genere non vengono eseguiti in modo continuo, quindi è utile avviare, arrestare e ridimensionare automaticamente i cluster riutilizzabili che possono gestire una gamma di carichi di lavoro. Modelli diversi richiedono spesso ambienti diversi. La soluzione deve distribuire un ambiente specifico e rimuoverlo al termine dell'inferenza. Automazione rende disponibile il calcolo per il modello successivo. Per ridurre i costi, usare macchine virtuali con priorità bassa per i nodi di calcolo.

Importante

Le dimensioni dei nodi di calcolo sono importanti. Se i nodi sono troppo piccoli, il processo di inferenza batch richiede più tempo. Se i nodi sono troppo grandi, il processo è più costoso. Testare e monitorare i nodi di calcolo per determinare le dimensioni corrette per il modello.
Prendere in considerazione le esigenze di scalabilità. Per migliorare le prestazioni, Machine Learning supporta funzionalità che consentono l'elaborazione scalabile. Il numero di nodi di calcolo e i parametri di concorrenza massimi vengono definiti durante la distribuzione dell'endpoint batch in Machine Learning. È possibile eseguire l'override dei parametri per ogni processo, che offre ai clienti flessibilità di runtime e parallelismo predefinito. Queste funzionalità funzionano con inferenza tabulare e basata su file.
Problemi di inferenza batch. L'inferenza batch è un modo più semplice per usare e distribuire il modello nell'ambiente di produzione, ma presenta un proprio set di sfide.
- A seconda della frequenza di esecuzione dell'inferenza, la stima generata potrebbe essere irrilevante dal momento in cui si accede.
- La distribuzione in molte aree e la progettazione della soluzione per la disponibilità elevata non sono problemi critici in uno scenario di inferenza batch perché il modello non viene distribuito a livello di area. L'archivio dati potrebbe tuttavia dover essere distribuito con una strategia di disponibilità elevata in molte posizioni. La distribuzione deve seguire la progettazione e la strategia a disponibilità elevata dell'applicazione.
- I dati generati durante un'inferenza batch potrebbero non riuscire parzialmente. Ad esempio, se una pipeline pianificata attiva un processo di inferenza batch e la pipeline ha esito negativo, i dati generati dal processo di inferenza batch potrebbero essere incompleti. I riavvii parziali sono un problema comune con l'inferenza batch. Una soluzione consiste nell'usare un'area di staging per i dati e spostare i dati solo nella destinazione finale dopo il completamento del processo di inferenza batch. Un'altra soluzione consiste nel mantenere un record, o transazione, di ogni file elaborato e confrontarlo con l'elenco di file di input per evitare la duplicazione. Questo metodo incorpora la logica nello script di assegnazione dei punteggi. Questa soluzione è più complessa, ma è possibile personalizzare la logica di errore se il processo di inferenza batch ha esito negativo.
Requisiti di sicurezza. Usare l'autenticazione e l'autorizzazione per controllare l'accesso all'endpoint batch per una maggiore sicurezza.
- Un endpoint batch con protezione in ingresso accetta solo le richieste di assegnazione dei punteggi dagli host all'interno di una rete virtuale. Non accetta richieste di assegnazione dei punteggi da Internet pubblico. Un endpoint batch creato in un'area di lavoro abilitata per il collegamento privato ha protezione in ingresso. Per altre informazioni, vedere Isolamento di rete negli endpoint batch.
- Usare i token Microsoft Entra per l'autenticazione.
- Usare la crittografia SSL nell'endpoint, che è abilitata per impostazione predefinita per la chiamata dell'endpoint di Machine Learning.
- Gli endpoint batch assicurano che solo gli utenti autorizzati possano richiamare distribuzioni batch, ma le singole persone possono usare altre credenziali per leggere i dati sottostanti. Per un riferimento agli archivi dati e alle credenziali per accedervi, vedere la tabella di accesso ai dati.
Integrazione batch. Gli endpoint batch di Machine Learning usano un'API aperta. L'inferenza batch può essere integrata con altri servizi di Azure, ad esempio Azure Data Factory, Azure Databricks e Azure Synapse Analytics per formare parte di una pipeline di dati più grande. Ad esempio, è possibile usare:
- Data Factory per orchestrare il processo di inferenza batch.
- Azure Databricks per preparare i dati per l'inferenza batch.
- Machine Learning per eseguire il processo di inferenza batch.
- Azure Synapse Analytics per archiviare le stime successive.
Gli endpoint batch supportano Microsoft Entra ID per l'autorizzazione. La richiesta all'API richiede l'autenticazione corretta. I servizi di Azure, ad esempio Data Factory, supportano l'uso di un'entità servizio o di un'identità gestita per l'autenticazione in endpoint batch. Per altre informazioni, vedere Eseguire endpoint batch da Data Factory.

Per scegliere il metodo migliore per l'elaborazione batch di input e output, è importante comprendere come i dati si spostano nelle fasi delle pipeline di dati. È possibile accedere ai servizi dati di Azure direttamente tramite lo script di assegnazione dei punteggi degli endpoint batch usando gli SDK, ma l'uso degli archivi dati registrati di Machine Learning è più semplice, sicuro e controllabile. Per le origini dati di terze parti, usare un motore di elaborazione dati, ad esempio Data Factory, Azure Databricks o Azure Synapse Analytics, per preparare i dati per l'inferenza batch e applicare l'elaborazione post-inferenza.
MLflow. Usare il framework open source MLflow durante lo sviluppo di modelli. Machine Learning supporta la distribuzione senza codice dei modelli creati e registrati con MLflow. Quando si distribuisce il modello MLflow in un endpoint batch, non è necessario indicare uno script di assegnazione dei punteggi o un ambiente.

Inferenza in tempo reale

L'inferenza in tempo reale è un metodo che consente di attivare l'inferenza del modello in qualsiasi momento e fornisce una risposta immediata. Usare questo metodo per analizzare i dati di streaming o i dati interattivi dell'applicazione.

Considerare le procedure consigliate seguenti per l'inferenza in tempo reale:

Opzioni di calcolo. Il modo migliore per implementare l'inferenza in tempo reale consiste nel distribuire il modello presente in un endpoint online gestito in un endpoint online gestito o in un endpoint online Kubernetes. Gli endpoint online gestiti distribuiscono immediatamente i modelli di Machine Learning usando computer CPU o GPU in Azure. Questo metodo è scalabile e completamente gestito. Gli endpoint online Kubernetes distribuiscono modelli e gestiscono endpoint online nel cluster Kubernetes completamente configurato e gestito. Per altre informazioni, vedere Endpoint online gestiti e endpoint online kubernetes.
Distribuzione multimultidimensionale e disponibilità elevata. La distribuzione a livello di area e le architetture a disponibilità elevata sono esempi di scenari di inferenza in tempo reale perché le prestazioni della latenza e del modello sono fondamentali. Per ridurre la latenza nelle distribuzioni multimultidimensionali, individuare il modello il più vicino possibile al punto di consumo. Per il modello e l'infrastruttura di supporto, seguire i principi e la strategia di disponibilità elevata e ripristino di emergenza aziendali.
Problemi di inferenza in tempo reale.
- L'inferenza in tempo reale è più complessa a causa di requisiti di latenza e prestazioni. Un semplice sistema in tempo reale riceve l'input tramite una richiesta HTTP e restituisce una stima. Un sistema complesso potrebbe tuttavia dover rispondere in 100 millisecondi o meno. Durante tale periodo, recupera i dati, esegue la progettazione delle funzionalità, esegue inferenza, convalida e archivia i risultati del modello, esegue la logica di business e restituisce i risultati al sistema o all'applicazione.
- Offload della progettazione delle funzionalità in un archivio dati a bassa latenza, nel servizio di memorizzazione nella cache o in un archivio funzionalità dedicato. Un archivio funzionalità è un repository centralizzato che consente ai data scientist di trovare e condividere funzionalità. Un archivio funzionalità garantisce che lo stesso codice usato per calcolare i valori delle funzionalità venga usato anche per il training e l'inferenza del modello.
Requisiti di sicurezza. Per una maggiore sicurezza, usare l'autenticazione e l'autorizzazione per controllare l'accesso all'endpoint online.
- Un endpoint online con protezione in ingresso accetta solo le richieste di assegnazione dei punteggi dagli host all'interno di una rete virtuale. Non accetta richieste di assegnazione dei punteggi da Internet pubblico. Un endpoint online creato in un'area di lavoro abilitata per il collegamento privato ha protezione in ingresso. Per altre informazioni, vedere Usare l'isolamento di rete con endpoint online gestiti.
- Usare i token Microsoft Entra per l'autenticazione del piano di controllo. Per le operazioni del piano dati, sono supportati approcci basati su chiave e basati su token. L'approccio basato su token è preferibile perché i token scadono. Usare i controlli degli accessi in base al ruolo di Azure per limitare l'accesso e recuperare la chiave o il token per un endpoint online.
- Usare la crittografia SSL nell'endpoint, che è abilitata per impostazione predefinita per la chiamata dell'endpoint di Machine Learning.
Integrazione in tempo reale. Integrare l'inferenza in tempo reale con altri servizi di Azure usando SDK per linguaggi diversi e richiamando l'endpoint usando un'API REST. È possibile richiamare l'endpoint online come parte del codice di un'applicazione.
MLflow. Usare il framework open source MLflow durante lo sviluppo di modelli. Machine Learning supporta la distribuzione senza codice dei modelli creati e registrati con MLflow. Quando si distribuisce il modello MLflow in un endpoint online, non è necessario indicare uno script di assegnazione dei punteggi o un ambiente.
Cassaforte'implementazione. Distribuire aggiornamenti in più fasi ai modelli di Machine Learning per garantire che il modello venga eseguito come previsto. Usare la strategia di implementazione sicura di Machine Learning per distribuire un modello in un endpoint, eseguire test sul modello e aumentare gradualmente il traffico verso il nuovo modello. Sfruttare il traffico con mirroring per eseguire il mirroring di una percentuale di traffico attivo verso il nuovo modello per una convalida aggiuntiva. Il mirroring del traffico, detto anche shadowing, non modifica i risultati restituiti ai client. Tutte le richieste passano comunque al modello originale. Per altre informazioni, vedere Cassaforte'implementazione per gli endpoint online.

Altre considerazioni

Tenere presenti queste considerazioni quando si distribuiscono modelli di Machine Learning in ambienti di produzione.

ONNX

Per ottimizzare l'inferenza dei modelli di Machine Learning, usare Open Neural Network Exchange (ONNX). Può essere una sfida usare completamente le funzionalità hardware quando si ottimizzano i modelli, in particolare quando si usano piattaforme diverse , ad esempio cloud/edge o CPU/GPU. È possibile eseguire il training di un nuovo modello o convertire un modello esistente da un altro formato a ONNX.

Scenario con molti modelli

Un modello singolare potrebbe non acquisire la natura complessa dei problemi reali. Ad esempio, i supermercati hanno dati demografici, marchi, SKU e altre funzionalità che variano tra le aree, il che rende difficile creare un singolo modello di stima delle vendite. Analogamente, le variazioni a livello di area possono rappresentare una sfida per un modello di manutenzione predittiva del contatore intelligente. Usare molti modelli per acquisire relazioni a livello di archivio o dati a livello di area per garantire una maggiore accuratezza rispetto a un singolo modello. L'approccio molti modelli presuppone che siano disponibili dati sufficienti per questo livello di granularità.

Uno scenario molti modelli prevede tre fasi: origine dati, data science e molti modelli.

Origine dati. Nella fase dell'origine dati è importante segmentare i dati in pochi elementi. Ad esempio, non considerare l'ID prodotto o il codice a barre nella partizione principale perché produce troppi segmenti e potrebbe inibire modelli significativi. Il marchio, lo SKU o la località sono elementi più adatti. È importante semplificare i dati rimuovendo anomalie che potrebbero inclinare la distribuzione dei dati.
Data science. Nella fase di data science diversi esperimenti vengono eseguiti in parallelo a ogni segmento di dati. La sperimentazione di molti modelli è un processo iterativo che valuta i modelli per determinare quello migliore.
Molti modelli. I modelli migliori per ogni segmento o categoria vengono registrati nel registro dei modelli. Assegnare nomi significativi ai modelli per renderli più individuabili per l'inferenza. Usare l'assegnazione di tag dove necessario per raggruppare il modello in categorie specifiche.

Inferenza batch per molti modelli

Per molti modelli, durante l'inferenza batch, le stime sono in base a una pianificazione ricorrente e possono gestire dati di grandi volumi eseguiti contemporaneamente. A differenza di uno scenario a modello singolo, l'inferenza di molti modelli si verifica contemporaneamente.

Molti modelli per l'inferenza batch usano più distribuzioni in un endpoint gestito singolo. L'inferenza batch per modelli specifici richiama il nome della distribuzione durante la chiamata REST o SDK. Per altre informazioni, vedere Distribuire più modelli in una distribuzione.

Inferenza in tempo reale per molti modelli

È possibile distribuire più modelli in un endpoint online gestito singolo, che è possibile richiamare tramite un'API REST o un SDK. Quando si creano le distribuzioni, registrare più modelli come un singolo "modello registrato" in Azure. Includere più modelli nella stessa directory e passare tale directory come percorso del singolo modello. I modelli vengono caricati in un dizionario con chiave sui nomi. Quando viene ricevuta una richiesta REST, il modello desiderato viene recuperato dal payload JSON e il modello pertinente assegna un punteggio al payload.

I modelli caricati in una distribuzione a più modelli usando questa tecnica devono condividere la stessa versione di Python e non avere dipendenze in conflitto. Le librerie devono essere importate contemporaneamente anche se non hanno rigorosamente le stesse dipendenze.

Per un esempio, vedere Creare una distribuzione multimodello usando un contenitore personalizzato.

Share via