Endpoint e distribuzioni online per l'inferenza in tempo reale

  • Articolo

SI APPLICA A:estensione ml dell'interfaccia della riga di comando di Azure v2 (corrente)Python SDK azure-ai-ml v2 (corrente)

Azure Machine Learning consente di eseguire l'inferenza in tempo reale sui dati usando modelli distribuiti negli endpoint online. L'inferenza è il processo di applicazione di nuovi dati di input a un modello di apprendimento automatico per generare output. Anche se questi output vengono in genere definiti "stime", l'inferenza può essere usata per generare output per altre attività di apprendimento automatico, come la classificazione e il clustering.

Endpoint online

Gli endpoint online distribuiscono i modelli a un server Web in grado di restituire stime con il protocollo HTTP. Usare gli endpoint online per rendere operativi i modelli per l'inferenza in tempo reale nelle richieste sincrone a bassa latenza. È consigliabile usarli quando:

  • Si dispone di requisiti di bassa latenza
  • Il modello può rispondere alla richiesta in un periodo di tempo relativamente breve
  • Gli input del modello si adattano al payload HTTP della richiesta
  • È necessario aumentare le prestazioni in termini di numero di richieste

Per definire un endpoint, è necessario specificare:

  • Nome dell'endpoint: questo nome deve essere univoco nell'area di Azure. Per altre informazioni sulle regole di denominazione, vedere i limiti degli endpoint.
  • Modalità di autenticazione: è possibile scegliere tra la modalità di autenticazione basata su chiave, la modalità di autenticazione basata su token di Azure Machine Learning o l'autenticazione basata su token di Microsoft Entra (anteprima) per l'endpoint. Per altre informazioni sull'autenticazione, vedere Eseguire l'autenticazione a un endpoint online.

Azure Machine Learning offre la comodità di usare endpoint online gestiti per distribuire i modelli di Machine Learning in modo chiavi in mano. Questo è il modo consigliato per usare gli endpoint online in Azure Machine Learning. Funzionano con computer CPU e GPU potenti in Azure in modo scalabile e completamente gestito. Questi endpoint si occupano anche di gestire, dimensionare, proteggere e monitorare i modelli, liberando l'utente dalle attività di configurazione e gestione dell'infrastruttura sottostante. Per informazioni su come definire un endpoint online gestito, vedere Definire l'endpoint.

Perché scegliere gli endpoint online gestiti rispetto a Istanze di Azure Container o al servizio Azure Kubernetes (v1)?

L'uso di endpoint online gestiti è il modo consigliato per usare gli endpoint online in Azure Machine Learning. La tabella seguente evidenzia gli attributi chiave degli endpoint online gestiti rispetto alle soluzioni SDK/interfaccia della riga di comando di Azure Machine Learning v1 (Istanze di Azure Container o servizio Azure Kubernetes (v1)).

Attributi Endpoint online gestiti (v2) Istanze di Azure Container o servizio Azure Kubernetes (v1)
Sicurezza/Isolamento rete Facile controllo in ingresso/in uscita con attivazione/disattivazione rapida La rete virtuale non è supportata o richiede una configurazione manuale complessa
Servizio gestito - Provisioning/ridimensionamento dell'ambiente di calcolo completamente gestito
- Configurazione di rete per la prevenzione dell'esfiltrazione di dati
- Aggiornamento del sistema operativo host, implementazione controllata degli aggiornamenti sul posto		 - Il ridimensionamento è limitato nella versione 1
- La configurazione o l'aggiornamento della rete devono essere gestiti dall'utente
Concetto di endpoint/distribuzione La distinzione tra endpoint e distribuzione consente scenari complessi, come l'implementazione sicura dei modelli Nessun concetto di endpoint
Diagnostica e monitoraggio - Debug dell'endpoint locale possibile con Docker e Visual Studio Code
​ - Analisi avanzata delle metriche e dei log con grafico/query da confrontare tra le distribuzioni
- Suddivisione dei costi fino al livello di distribuzione		 Nessun debug locale semplice
Scalabilità Ridimensionamento illimitato, elastico e automatico - Istanze di Azure Container non è scalabile
- Il servizio Azure Kubernetes (v1) supporta solo la scalabilità all'interno del cluster e richiede la configurazione della scalabilità
Soluzione pronta per l'azienda Collegamento privato, chiavi gestite dal cliente, Microsoft Entra ID, gestione delle quote, integrazione della fatturazione, contratto di servizio Non supportato
Funzionalità avanzate di Machine Learning - Raccolta dati del modello
- Monitoraggio del modello
- Modello champion-challenger, implementazione sicura, mirroring del traffico
- Estendibilità dell'intelligenza artificiale responsabile		 Non supportato

In alternativa, se si preferisce usare Kubernetes per distribuire i modelli e gestire gli endpoint e si ha familiarità con la gestione dei requisiti dell'infrastruttura, è possibile usare gli endpoint online Kubernetes. Questi endpoint consentono di distribuire modelli e gestire endpoint online nel cluster Kubernetes completamente configurato e gestito ovunque, con CPU o GPU.

Perché scegliere gli endpoint online gestiti rispetto al servizio Azure Kubernetes (v2)?

Gli endpoint online gestiti possono semplificare il processo di distribuzione e offrire i vantaggi seguenti rispetto agli endpoint online Kubernetes:

  • Infrastruttura gestita

    • Effettua automaticamente il provisioning dell'ambiente di calcolo e ospita il modello (è sufficiente specificare il tipo di macchina virtuale e le impostazioni di scalabilità)
    • Aggiorna e applica automaticamente le patch all'immagine del sistema operativo host sottostante
    • Esegue automaticamente il ripristino dei nodi in caso di errore del sistema

  • Monitoraggio e log

    Screenshot che mostra il grafico di Monitoraggio di Azure della latenza dell'endpoint.

  • Visualizzare i costi

    Screenshot del grafico dei costi di un endpoint e di una distribuzione.

    Nota

    Gli endpoint online gestiti sono basati sull'ambiente di calcolo di Azure Machine Learning. Quando si usa un endpoint online gestito, si pagano i costi di calcolo e di rete. Non è previsto alcun supplemento. Per altre informazioni sui prezzi, vedere Calcolatore prezzi di Azure.

    Se si usa una rete virtuale di Azure Machine Learning per proteggere il traffico in uscita dall'endpoint online gestito, vengono addebitati i costi per il collegamento privato di Azure e le regole FQDN in uscita usate dalla rete virtuale gestita. Per altre informazioni, vedere Prezzi per la rete virtuale gestita.

Endpoint online gestiti ed endpoint online Kubernetes

La tabella seguente evidenzia le differenze principali tra gli endpoint online gestiti e gli endpoint online Kubernetes.

Endpoint online gestiti Endpoint online Kubernetes (servizio Azure Kubernetes (v2))
Utenti consigliati Utenti che vogliono una distribuzione di modelli gestita e un'esperienza MLOps migliorata Utenti che preferiscono Kubernetes e possono gestire autonomamente i requisiti dell'infrastruttura
Provisioning dei nodi Provisioning, aggiornamento e rimozione dell'ambiente di calcolo gestito Responsabilità dell'utente
Manutenzione dei nodi Aggiornamenti delle immagini del sistema operativo host gestito e protezione avanzata Responsabilità dell'utente
Dimensionamento (ridimensionamento) del cluster Scalabilità automatica e manuale gestita, con supporto del provisioning di nodi aggiuntivi Scalabilità automatica e manuale, con supporto del ridimensionamento del numero di repliche entro i limiti fissi del cluster
Tipo di ambiente di calcolo Gestito dal servizio Cluster Kubernetes gestito dal cliente (Kubernetes)
Identità gestita Supportata Supportata
Rete virtuale Supportata tramite l'isolamento network gestito Responsabilità dell'utente
Monitoraggio e registrazione predefiniti Basati su Monitoraggio di Azure e Log Analytics (include metriche chiave e tabelle di log per endpoint e distribuzioni) Responsabilità dell'utente
Registrazione con Application Insights (legacy) Supportata Supportata
Visualizzare i costi Dettagliati al livello di endpoint/distribuzione Livello cluster
Costo applicato a Macchine virtuali assegnate alle distribuzioni Macchine virtuali assegnate al cluster
Traffico con mirroring Supportata Non supportato
Distribuzione senza codice Supportata (modelli MLflow e Triton) Supportata (modelli MLflow e Triton)

Distribuzioni online

Una distribuzione è un set di risorse e ambienti di calcolo necessari per ospitare il modello che esegue l'inferenza effettiva. Un singolo endpoint può contenere più distribuzioni con configurazioni diverse. Questa configurazione consente di separare l'interfaccia presentata dall'endpoint dai dettagli di implementazione presenti nella distribuzione. Un endpoint online ha un meccanismo di routing che può indirizzare le richieste a distribuzioni specifiche nell'endpoint.

Il diagramma seguente mostra un endpoint online con due distribuzioni, blu e verde. La distribuzione blu usa macchine virtuali con uno SKU CPU ed esegue la versione 1 di un modello. La distribuzione verde usa macchine virtuali con uno SKU GPU ed esegue la versione 2 del modello. L'endpoint è configurato per instradare il 90% del traffico in ingresso alla distribuzione blu, mentre la distribuzione verde riceve il rimanente 10%.

Diagramma che mostra una suddivisione del traffico da un endpoint a due distribuzioni.

Per distribuire un modello, è necessario disporre di:

  • File di modello (o il nome e la versione di un modello già registrato nell'area di lavoro).
  • Uno script di assegnazione dei punteggi, ovvero il codice che esegue il modello in una determinata richiesta di input. Lo script di assegnazione dei punteggi riceve i dati inviati a un servizio Web distribuito e li passa al modello. Quindi, lo script esegue il modello e restituisce la risposta al client. Lo script di assegnazione dei punteggi è specifico del modello e deve comprendere i dati che il modello prevede come input e restituisce come output.
  • Ambiente in cui viene eseguito il modello. L'ambiente può essere un'immagine Docker con dipendenze Conda o un Dockerfile.
  • Impostazioni specificare il tipo di istanza e la capacità di ridimensionamento.

Attributi chiave di una distribuzione

La tabella seguente descrive gli attributi chiave di una distribuzione:

Attributo Descrizione
Name Nome della distribuzione.
Nome endpoint Nome dell'endpoint in cui creare la distribuzione.
Modello1 Modello da usare per la distribuzione. Questo valore può essere un riferimento a un modello con controllo delle versioni esistente nell'area di lavoro o a una specifica del modello inline. Per altre informazioni su come tenere traccia e specificare il percorso del modello, vedere Identificare il percorso del modello rispetto a AZUREML_MODEL_DIR.
Percorso del codice Percorso della directory nell'ambiente di sviluppo locale che contiene tutto il codice sorgente Python per l'assegnazione del punteggio al modello. È possibile usare directory e pacchetti annidati.
Scoring script (Script di assegnazione punteggi) Percorso relativo del file di punteggio nella directory del codice sorgente. Questo codice Python deve avere una funzione init() e una funzione run(). La funzione init() verrà chiamata dopo la creazione o l'aggiornamento del modello (ad esempio, è possibile usarla per memorizzare nella cache il modello in memoria). La funzione run() viene chiamata a ogni chiamata dell'endpoint per eseguire l'assegnazione del punteggio e la stima effettive.
Ambiente1 Ambiente in cui ospitare il modello e il codice. Questo valore può essere un riferimento a un ambiente con controllo delle versioni esistente nell'area di lavoro o a una specifica dell'ambiente inline. Nota: Microsoft applica regolarmente patch alle immagini di base per le vulnerabilità di sicurezza note. È necessario ridistribuire l'endpoint per usare l'immagine con le patch. Se si usa la propria immagine, si è responsabili dell'aggiornamento. Per altre informazioni, vedere Applicazione delle patch all'immagine.
Tipo di istanza Dimensioni della macchina virtuale da usare per la distribuzione. Per l'elenco delle dimensioni supportate, vedere Elenco di SKU degli endpoint online gestiti.
Numero di istanze Numero di istanze da usare per la distribuzione. Basare il valore sul carico di lavoro previsto. Per la disponibilità elevata, è consigliabile impostare il valore almeno su 3. Si riserva un ulteriore 20% per l'esecuzione degli aggiornamenti. Per altre informazioni, vedere Allocazione della quota di macchine virtuali per le distribuzioni.

1 Alcuni aspetti da notare sul modello e sull'ambiente:

  • Il modello e l'immagine del contenitore (come definito in Ambiente) possono essere nuovamente referenziati in qualsiasi momento dalla distribuzione quando le istanze dietro la distribuzione passano attraverso patch di sicurezza e/o altre operazioni di ripristino. Se si usa un modello registrato o un'immagine del contenitore in Registro Azure Container per la distribuzione e si rimuove il modello o l'immagine del contenitore, le distribuzioni basate su questi asset possono non riuscire quando si verifica la ricreazione dell'immagine. Se si rimuove il modello o l'immagine del contenitore, assicurarsi che le distribuzioni dipendenti vengano ricreate o aggiornate con un modello o un'immagine del contenitore alternativa.
  • Il registro contenitori a cui fa riferimento l'ambiente può essere privato solo se l'identità dell'endpoint ha l'autorizzazione per accedervi tramite l'autenticazione di Microsoft Entra e il controllo degli accessi in base al ruolo di Azure. Per lo stesso motivo, i registri Docker privati diversi da Registro Azure Container non sono supportati.

Per informazioni su come distribuire gli endpoint online con interfaccia della riga di comando, SDK, studio e modello di ARM, vedere Distribuire un modello di Machine Learning con un endpoint online.

Identificare il percorso del modello in relazione a AZUREML_MODEL_DIR

Quando si distribuisce il modello in Azure Machine Learning, è necessario specificare il percorso del modello da distribuire come parte della configurazione della distribuzione. In Azure Machine Learning il percorso del modello viene monitorato con la AZUREML_MODEL_DIR variabile di ambiente. Identificando il percorso del modello rispetto a AZUREML_MODEL_DIR, è possibile distribuire uno o più modelli archiviati in locale nel computer, oppure distribuire un modello registrato nell'area di lavoro di Azure Machine Learning.

Ad esempio, si fa riferimento alla struttura di cartelle locale seguente per i primi due casi in cui si distribuisce uno o più modelli archiviati in locale:

Screenshot che mostra una struttura di cartelle contenente più modelli.

Usare un singolo modello locale in una distribuzione

Per usare un singolo modello presente nel computer locale in una distribuzione, specificare path per model nello YAML di distribuzione. Ecco un esempio dello YAML di distribuzione con il percorso /Downloads/multi-models-sample/models/model_1/v1/sample_m1.pkl:

$schema: https://azuremlschemas.azureedge.net/latest/managedOnlineDeployment.schema.json 
name: blue 
endpoint_name: my-endpoint 
model: 
  path: /Downloads/multi-models-sample/models/model_1/v1/sample_m1.pkl 
code_configuration: 
  code: ../../model-1/onlinescoring/ 
  scoring_script: score.py 
environment:  
  conda_file: ../../model-1/environment/conda.yml 
  image: mcr.microsoft.com/azureml/openmpi4.1.0-ubuntu20.04:latest 
instance_type: Standard_DS3_v2 
instance_count: 1

Dopo aver creato la distribuzione, la variabile di ambiente AZUREML_MODEL_DIR punterà alla posizione di archiviazione in Azure in cui è archiviato il modello. Ad esempio, /var/azureml-app/azureml-models/81b3c48bbf62360c7edbbe9b280b9025/1 conterrà il modello sample_m1.pkl.

All'interno dello script di assegnazione dei punteggi (score.py), è possibile caricare il modello (in questo esempio sample_m1.pkl) nella funzione init():

def init(): 
    model_path = os.path.join(str(os.getenv("AZUREML_MODEL_DIR")), "sample_m1.pkl") 
    model = joblib.load(model_path)

Usare diversi modelli locali in una distribuzione

Anche se l'interfaccia della riga di comando di Azure, Python SDK, e altri strumenti client consentono di specificare un solo modello per distribuzione nella definizione di distribuzione, è comunque possibile usare diversi modelli in una distribuzione registrando una cartella contenente tutti i modelli come file o sottodirectory.

Nella struttura di cartelle di esempio precedente si noterà che nella cartella sono presenti diversi modelli nella cartella models. Nello YAML di distribuzione è possibile specificare il percorso della cartella models come indicato di seguito:

$schema: https://azuremlschemas.azureedge.net/latest/managedOnlineDeployment.schema.json 
name: blue 
endpoint_name: my-endpoint 
model: 
  path: /Downloads/multi-models-sample/models/ 
code_configuration: 
  code: ../../model-1/onlinescoring/ 
  scoring_script: score.py 
environment:  
  conda_file: ../../model-1/environment/conda.yml 
  image: mcr.microsoft.com/azureml/openmpi4.1.0-ubuntu20.04:latest 
instance_type: Standard_DS3_v2 
instance_count: 1

Dopo aver creato la distribuzione, la variabile di ambiente AZUREML_MODEL_DIR punterà alla posizione di archiviazione in Azure in cui sono archiviati i modelli. Ad esempio, /var/azureml-app/azureml-models/81b3c48bbf62360c7edbbe9b280b9025/1 conterrà i modelli e la struttura di file.

In questo esempio, il contenuto della cartella AZUREML_MODEL_DIR sarà simile al seguente:

Screenshot della struttura di cartelle del percorso di archiviazione per più modelli.

All'interno dello script di assegnazione dei punteggi (score.py) è possibile caricare i modelli nella funzione init(). Il codice seguente carica il modello sample_m1.pkl:

def init(): 
    model_path = os.path.join(str(os.getenv("AZUREML_MODEL_DIR")), "models","model_1","v1", "sample_m1.pkl ") 
    model = joblib.load(model_path)

Per un esempio di come distribuire diversi modelli in un'unica distribuzione, vedere Distribuire diversi modelli in un'unica distribuzione (esempio dell'interfaccia della riga di comando) e Distribuire diversi modelli in un'unica distribuzione (esempio dell'SDK).

Suggerimento

Se sono presenti più di 1500 file da registrare, è consigliabile comprimere i file o le sottodirectory con il formato .tar.gz durante la registrazione dei modelli. Per utilizzare i modelli, è possibile decomprimere i file o le sottodirectory nella funzione init() dallo script di assegnazione dei punteggi. In alternativa, quando si registrano i modelli, impostare la proprietà azureml.unpack su True, per decomprimere automaticamente i file o le sottodirectory. In entrambi i casi, la decompressione avviene quando si è nella fase di inizializzazione.

Usare i modelli registrati nell'area di lavoro di Azure Machine Learning in una distribuzione

Per usare nella distribuzione uno o più modelli registrati nell'area di lavoro di Azure Machine Learning, specificare il nome dei modelli registrati nel file YAML di distribuzione. Ad esempio, la configurazione YAML di distribuzione seguente specifica il nome registrato model come azureml:local-multimodel:3:

$schema: https://azuremlschemas.azureedge.net/latest/managedOnlineDeployment.schema.json 
name: blue 
endpoint_name: my-endpoint 
model: azureml:local-multimodel:3 
code_configuration: 
  code: ../../model-1/onlinescoring/ 
  scoring_script: score.py 
environment:  
  conda_file: ../../model-1/environment/conda.yml 
  image: mcr.microsoft.com/azureml/openmpi4.1.0-ubuntu20.04:latest 
instance_type: Standard_DS3_v2 
instance_count: 1

Per questo esempio, si consideri che local-multimodel:3 contiene i seguenti artefatti del modello, che è possibile visualizzare dalla scheda Modelli in Studio di Azure Machine Learning:

Screenshot della struttura di cartelle che mostra gli artefatti del modello registrato.

Dopo aver creato la distribuzione, la variabile di ambiente AZUREML_MODEL_DIR punterà alla posizione di archiviazione in Azure in cui sono archiviati i modelli. Ad esempio, /var/azureml-app/azureml-models/local-multimodel/3 conterrà i modelli e la struttura di file. AZUREML_MODEL_DIR punterà alla cartella contenente la radice degli artefatti del modello. In base a questo esempio, il contenuto della cartella AZUREML_MODEL_DIR sarà simile al seguente:

Screenshot della struttura di cartelle che mostra più modelli.

All'interno dello script di assegnazione dei punteggi (score.py) è possibile caricare i modelli nella funzione init(). Ad esempio, caricare il modello diabetes.sav:

def init(): 
    model_path = os.path.join(str(os.getenv("AZUREML_MODEL_DIR"), "models", "diabetes", "1", "diabetes.sav") 
    model = joblib.load(model_path)

Allocazione della quota di macchine virtuali per la distribuzione

Per gli endpoint online gestiti, Azure Machine Learning riserva il 20% delle risorse di calcolo per l'esecuzione degli aggiornamenti in alcune SKU di VM. Se si richiede un determinato numero di istanze per gli SKU di macchine virtuali in una distribuzione, è necessario disporre di una quota per ceil(1.2 * number of instances requested for deployment) * number of cores for the VM SKU evitare di ricevere un errore. Ad esempio, se si richiedono 10 istanze di una macchina virtuale Standard_DS3_v2 (fornita con quattro core) in una distribuzione, è necessario avere una quota per 48 core (12 instances * 4 cores) disponibile. Questa quota aggiuntiva è riservata alle operazioni avviate dal sistema, ad esempio gli aggiornamenti del sistema operativo e il ripristino della macchina virtuale, e non comporta costi a meno che tali operazioni non vengano eseguite.

Esistono determinati SKU di VM esentati dalla prenotazione di quote aggiuntive. Per visualizzare l'elenco completo, vedere l'elenco degli SKU degli endpoint online gestiti.

Per visualizzare gli incrementi relativi all'utilizzo e alla quota di richieste, vedere Visualizzare l'utilizzo e le quote nel portale di Azure. Per visualizzare i costi di esecuzione di un endpoint online gestito, vedere Visualizzare i costi per un endpoint online gestito.

Azure Machine Learning offre un pool di quote condivise da cui tutti gli utenti possono accedere alla quota per eseguire test per un periodo di tempo limitato. Quando si usa lo studio per distribuire modelli Llama (dal catalogo di modelli) a un endpoint online gestito, Azure Machine Learning consente di accedere a questa quota condivisa per un breve periodo di tempo.

Per distribuire un modello Llama-2-70b o Llama-2-70b-chat, tuttavia, è necessario disporre di una sottoscrizione Contratto Enterprise prima di poter eseguire la distribuzione usando la quota condivisa. Per altre informazioni su come usare la quota condivisa per la distribuzione di endpoint online, vedere Come distribuire i modelli di base usando Studio.

Per altre informazioni sulle quote e sui limiti per le risorse in Azure Machine Learning, vedere Gestire e aumentare quote e limiti per le risorse con Azure Machine Learning.

Distribuzione per utenti che scrivono codice e quelli che non scrivono codice

Azure Machine Learning supporta la distribuzione di modelli in endpoint online sia per utenti che scrivono codice sia per quelli che non scrivono codice, fornendo opzioni per la distribuzione senza codice, la distribuzione con poco codice e la distribuzione BYOC (Bring Your Own Container).

  • La distribuzione senza codice fornisce l'inferenza predefinita per i framework comuni (ad esempio, scikit-learn, TensorFlow, PyTorch e ONNX) tramite MLflow e Triton.
  • La distribuzione con poco codice consente di fornire codice minimo insieme al modello di Machine Learning per la distribuzione.
  • La distribuzione BYOC consente di portare virtualmente qualsiasi contenitore per eseguire l'endpoint online. È possibile usare tutte le funzionalità della piattaforma Azure Machine Learning, come scalabilità automatica, GitOps, debug e implementazione sicura per gestire le pipeline MLOps.

La tabella seguente illustra gli aspetti principali relativi alle opzioni di distribuzione online:

Senza codice Basso codice BYOC
Riepilogo Usa l'inferenza predefinita per i framework più comuni come scikit-learn, TensorFlow, PyTorch e ONNX tramite MLflow e Triton. Per altre informazioni, vedere Distribuire modelli MLflow in endpoint online. Usa immagini curate sicure pubblicate pubblicamente per i framework più comuni, con aggiornamenti ogni due settimane per risolvere le vulnerabilità. È possibile fornire script di assegnazione dei punteggi e/o dipendenze Python. Per altre informazioni, vedere Ambienti curati di Azure Machine Learning. È possibile fornire lo stack completo tramite il supporto di Azure Machine Learning per le immagini personalizzate. Per altre informazioni, vedere Usare un contenitore personalizzato per distribuire un modello in un endpoint online.
Immagine di base personalizzata No, l'ambiente curato fornirà questa funzionalità per semplificare la distribuzione. Sì e No, è possibile usare un'immagine curata o l'immagine personalizzata. Sì, fornire un percorso dell'immagine del contenitore accessibile (ad esempio, docker.io, Registro Azure Container o Registro Container Microsoft) o un Dockerfile che è possibile compilare/eseguirne il push con Registro Azure Container per il contenitore.
Dipendenze personalizzate No, l'ambiente curato fornirà questa funzionalità per semplificare la distribuzione. Sì, fornire l'ambiente di Azure Machine Learning in cui viene eseguito il modello; un'immagine Docker con dipendenze Conda o un dockerfile. Sì, questa funzionalità verrà inclusa nell'immagine del contenitore.
Codice personalizzato No, lo script di assegnazione dei punteggi verrà generato automaticamente per semplificare la distribuzione. Sì, fornire lo script di assegnazione dei punteggi. Sì, questa funzionalità verrà inclusa nell'immagine del contenitore.

Nota

Le esecuzioni di AutoML creano automaticamente uno script di assegnazione dei punteggi e le dipendenze per gli utenti, in modo da poter distribuire qualsiasi modello AutoML senza creare codice aggiuntivo (per la distribuzione senza codice) o modificare gli script generati automaticamente in base alle esigenze aziendali (per la distribuzione con poco codice). Per informazioni su come eseguire la distribuzione con i modelli AutoML, vedere Distribuire un modello AutoML con un endpoint online.

Debug degli endpoint online

È consigliabile eseguire il test dell'endpoint in locale per convalidare ed eseguire il debug del codice e della configurazione prima di eseguire la distribuzione in Azure. L'interfaccia della riga di comando di Azure e Python SDK supportano endpoint e distribuzioni locali, mentre Studio di Azure Machine Learning e il modello ARM no.

Azure Machine Learning offre diversi modi per eseguire il debug degli endpoint online in locale e usando i log dei contenitori.

Debug locale con il server HTTP di inferenza di Azure Machine Learning

È possibile eseguire il debug dello script di assegnazione dei punteggi in locale usando il server HTTP di inferenza di Azure Machine Learning. Il server HTTP è un pacchetto Python che espone la funzione di assegnazione del punteggio come endpoint HTTP ed esegue il wrapping del codice e delle dipendenze del server Flask in un unico pacchetto. È incluso nelle immagini Docker predefinite per l'inferenza usate durante la distribuzione di un modello con Azure Machine Learning. Usando il pacchetto da solo, è possibile distribuire il modello in locale per la produzione ed è anche possibile convalidare facilmente lo script di assegnazione dei punteggi (voce) in un ambiente di sviluppo locale. Se si verifica un problema con lo script di assegnazione dei punteggi, il server restituirà un errore e la posizione in cui si è verificato l'errore. È anche possibile usare Visual Studio Code per eseguire il debug con il server HTTP di inferenza di Azure Machine Learning.

Suggerimento

È possibile usare il pacchetto Python del server HTTP di inferenza di Azure Machine Learning per eseguire il debug dello script di assegnazione dei punteggi in locale senza il motore Docker. Il debug con il server di inferenza consente di eseguire il debug dello script di assegnazione dei punteggi prima della distribuzione negli endpoint locali in modo che sia possibile eseguire il debug senza alcun impatto sulle configurazioni del contenitore di distribuzione.

Per altre informazioni sul debug con il server HTTP, vedere Debug dello script di assegnazione dei punteggi con il server HTTP di inferenza di Azure Machine Learning.

Debug locale con endpoint locale

Per il debug locale, è necessaria una distribuzione locale; ovvero un modello distribuito in un ambiente Docker locale. È possibile usare questa distribuzione locale per il test e il debug prima della distribuzione nel cloud. Per eseguire la distribuzione in locale, è necessario che il motore Docker sia installato e in esecuzione. Azure Machine Learning crea quindi un'immagine Docker locale che simula l'immagine di Azure Machine Learning. Azure Machine Learning creerà ed eseguirà le distribuzioni per l'utente in locale e memorizzerà nella cache l'immagine per iterazioni rapide.

Suggerimento

Docker Engine viene in genere avviato all'avvio del computer. In caso contrario, è possibile eseguire la risoluzione dei problemi relativi a Docker Engine. È possibile usare strumenti sul lato client, ad esempio Docker Desktop , per eseguire il debug di ciò che accade nel contenitore.

I passaggi per il debug locale in genere includono:

  • Verifica dell'esito positivo della distribuzione locale
  • Richiamo dell'endpoint locale per l'inferenza
  • Revisione dei log per l'output dell'operazione di richiamo

Nota

Gli endpoint locali presentano le limitazioni seguenti:

  • Non supportano regole di traffico, autenticazione o impostazioni probe.
  • Supportano una sola distribuzione per endpoint.
  • Supportano solo file di modello e ambiente locali con file conda locali. Se si desidera testare i modelli registrati, prima di tutto scaricarli usando l'interfaccia della riga di comando o l'SDK, quindi usare path nella definizione di distribuzione per fare riferimento alla cartella padre. Per testare gli ambienti registrati, controllare il contesto dell'ambiente in studio di Azure Machine Learning e preparare un file conda locale da usare.

Per altre informazioni sul debug locale, vedere Distribuire ed eseguire il debug in locale usando un endpoint locale.

Debug locale con endpoint locale e Visual Studio Code (anteprima)

Importante

Questa funzionalità è attualmente in anteprima pubblica. Questa versione di anteprima viene fornita senza contratto di servizio, pertanto se ne sconsiglia l’uso per i carichi di lavoro in ambienti di produzione. Alcune funzionalità potrebbero non essere supportate o potrebbero presentare funzionalità limitate.

Per altre informazioni, vedere le Condizioni supplementari per l'uso delle anteprime di Microsoft Azure.

Come per il debug locale, è necessario prima che il motore Docker sia installato e in esecuzione e quindi distribuire un modello nell'ambiente Docker locale. Dopo aver creato una distribuzione locale, gli endpoint locali di Azure Machine Learning usano i contenitori di sviluppo Docker e Visual Studio Code (contenitori di sviluppo) per creare e configurare un ambiente di debug locale. Con i contenitori di sviluppo è possibile sfruttare le funzionalità di Visual Studio Code, come il debug interattivo, dall'interno di un contenitore Docker.

Per altre informazioni sul debug interattivo degli endpoint online in VS Code, vedere Eseguire il debug degli endpoint online in locale in Visual Studio Code.

Debug con i log dei contenitori

Per una distribuzione, non è possibile ottenere l'accesso diretto alla macchina virtuale in cui viene distribuito il modello. Tuttavia, è possibile ottenere i log da alcuni dei contenitori in esecuzione nella macchina virtuale. Esistono due tipi di contenitori da cui è possibile ottenere i log:

  • Server di inferenza: i log includono il log della console (dal server di inferenza) che contiene l'output delle funzioni di stampa/registrazione dallo script di assegnazione dei punteggi (codice score.py).
  • Inizializzatore di archiviazione: i log contengono informazioni che specificano se il codice e i dati del modello sono stati scaricati correttamente nel contenitore. Il contenitore viene eseguito prima dell'avvio dell'esecuzione del contenitore del server di inferenza.

Per altre informazioni sul debug con i log dei contenitori, vedere Ottenere i log dei contenitori.

Routing e mirroring del traffico verso distribuzioni online

Tenere presente che un singolo endpoint online può avere più distribuzioni. Quando l'endpoint riceve il traffico (o le richieste) in ingresso, può instradare le percentuali di traffico a ogni distribuzione, come usato nella strategia nativa di distribuzione blu/verde. Può anche eseguire il mirroring (o la copia) del traffico da una distribuzione a un'altra, operazione denominata anche mirroring o shadowing del traffico.

Routing del traffico per la distribuzione blu/verde

La distribuzione blu/verde è una strategia di distribuzione che consente di implementare una nuova distribuzione (la distribuzione verde) in un piccolo subset di utenti o richieste prima di implementarla completamente. L'endpoint può implementare il bilanciamento del carico per allocare determinate percentuali del traffico a ogni distribuzione, con l'allocazione totale in tutte le distribuzioni che raggiunge il 100%.

Suggerimento

Una richiesta può ignorare il bilanciamento del carico del traffico configurato includendo un'intestazione HTTP di azureml-model-deployment. Impostare il valore dell'intestazione sul nome della distribuzione a cui si vuole indirizzare la richiesta.

L'immagine seguente mostra le impostazioni nello studio di Azure Machine Learning per allocare il traffico tra una distribuzione blu e una verde.

Screenshot che mostra l'interfaccia del dispositivo di scorrimento per impostare l'allocazione del traffico tra le distribuzioni.

Questa allocazione del traffico instrada il traffico come illustrato nell'immagine seguente, con il 10% del traffico destinato alla distribuzione verde e il 90% del traffico destinato alla distribuzione blu.

Diagramma che mostra una suddivisione del traffico da un endpoint a due distribuzioni.

Mirroring del traffico verso distribuzioni online

L'endpoint può anche eseguire il mirroring (o la copia) del traffico da una distribuzione a un'altra distribuzione. Il mirroring del traffico (detto anche shadow testing) è utile quando si vuole testare una nuova distribuzione con traffico di produzione senza influire sui risultati che i clienti ricevono dalle distribuzioni esistenti. Ad esempio, quando si implementa una distribuzione blu/verde in cui il 100% del traffico viene instradato alla distribuzione blu e il 10% viene sottoposto a mirroring nella distribuzione verde, i risultati del traffico con mirroring verso la distribuzione verde non vengono restituiti ai client, ma vengono registrati i log e le metriche.

Diagramma che mostra un traffico di mirroring dell'endpoint verso una distribuzione.

Per informazioni su come usare il mirroring del traffico, vedere Implementazione sicura per gli endpoint online.

Altre funzionalità degli endpoint online in Azure Machine Learning

Autenticazione e crittografia

  • Autenticazione: chiave e token di Azure Machine Learning
  • Identità gestita: assegnata dall'utente e assegnata dal sistema
  • SSL per impostazione predefinita per la chiamata all'endpoint

Scalabilità automatica

La scalabilità automatica usa automaticamente la quantità corretta di risorse per gestire il carico dell'applicazione. Gli endpoint gestiti supportano la scalabilità automatica tramite l'integrazione con la funzionalità di scalabilità automatica di Monitoraggio di Azure. È possibile configurare il ridimensionamento basato sulle metriche (ad esempio, l'utilizzo della CPU >70%), il ridimensionamento basato su pianificazione (ad esempio, le regole di ridimensionamento per le ore lavorative di punta) o una combinazione.

Screenshot che mostra che la scalabilità automatica fornisce in modo flessibile tra le istanze min e max, a seconda delle regole.

Per informazioni su come configurare il ridimensionamento automatico, vedere Come ridimensionare automaticamente gli endpoint online.

Isolamento network gestito

Quando si distribuisce un modello di Machine Learning in un endpoint online gestito, è possibile proteggere la comunicazione con l'endpoint online utilizzando endpoint privati.

È possibile configurare la sicurezza per le richieste di assegnazione dei punteggi in ingresso e le comunicazioni in uscita con l'area di lavoro e altri servizi separatamente. Le comunicazioni in ingresso usano l'endpoint privato dell'area di lavoro di Azure Machine Learning. Le comunicazioni in uscita usano endpoint privati creati per la rete virtuale gestita dell'area di lavoro.

Per altre informazioni, vedere Isolamento di rete con gli endpoint online gestiti.

Monitoraggio di endpoint e distribuzioni online

Il monitoraggio degli endpoint di Azure Machine Learning è possibile tramite l'integrazione con Monitoraggio di Azure. Questa integrazione consente di visualizzare le metriche nei grafici, configurare avvisi, eseguire query da tabelle di log, usare Application Insights per analizzare gli eventi dai contenitori utente e così via.

  • Metriche: usare Monitoraggio di Azure per tenere traccia di varie metriche degli endpoint, come la latenza delle richieste, e per eseguire il drill-down a livello di distribuzione o stato. È anche possibile tenere traccia delle metriche a livello di distribuzione, come l'utilizzo di CPU/GPU, ed eseguire il drill-down a livello di istanza. Monitoraggio di Azure consente di tenere traccia di queste metriche nei grafici e di configurare dashboard e avvisi per un'ulteriore analisi.

  • Log: inviare le metriche all'area di lavoro Log Analytics in cui è possibile eseguire query sui log usando la sintassi di query Kusto. È anche possibile inviare metriche all'account di archiviazione e/o a Hub eventi per un'ulteriore elaborazione. Inoltre, è possibile usare tabelle di log dedicate per gli eventi correlati agli endpoint online, il traffico e i log dei contenitori. La query Kusto consente l'analisi complessa che unisce più tabelle.

  • Application Insights: gli ambienti curati includono l'integrazione con Application Insights ed è possibile abilitarla/disabilitarla quando si crea una distribuzione online. Le metriche e i log predefiniti vengono inviati ad Application Insights ed è possibile usare le funzionalità predefinite, come le metriche attive, la ricerca di transazioni, gli errori e le prestazioni per ulteriori analisi.

Per altre informazioni sul monitoraggio, vedere Monitorare gli endpoint online.

Inserimento di segreti nelle distribuzioni online (anteprima)

L'inserimento di segreti nel contesto di una distribuzione online è un processo di recupero di segreti (come le chiavi API) da archivi segreti e di inserimento nel contenitore utente eseguito all'interno di una distribuzione online. I segreti saranno infine accessibili tramite variabili di ambiente, fornendo così un modo sicuro per essere usati dal server di inferenza che esegue lo script di assegnazione dei punteggi o dallo stack di inferenza fornito con un approccio di distribuzione BYOC (Bring Your Own Container).

Esistono due modi per inserire i segreti. È possibile inserire i segreti manualmente, usando le identità gestite oppure è possibile usare la funzionalità di inserimento dei segreti. Per altre informazioni sulle modalità di inserimento dei segreti, vedere Inserimento di segreti negli endpoint online (anteprima).

Passaggi successivi