AI Platform Prediction: concetti di container personalizzati

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

In questo documento viene illustrato come pubblicare modelli di machine learning (ML) su Google Cloud utilizzando container personalizzati in AI Platform Prediction.

AI Platform Prediction è una piattaforma di gestione di modelli ML gestita di Google Cloud. Come servizio gestito, la piattaforma gestisce la configurazione, la manutenzione e la gestione dell'infrastruttura. AI Platform Prediction supporta l'inferenza CPU e GPU e offre una selezione di forme di nodi n1-standard in Compute Engine, consentendoti di personalizzare l'unità di scalabilità in base alle tue esigenze.

Il servizio AI Platform Prediction semplifica il servizio modello chiedendoti di specificare solo dove archivierai gli artefatti del modello. Tuttavia, con questa semplicità si ha una flessibilità ridotta, ad esempio puoi pubblicare solo framework integrati nel servizio. Con i container personalizzati, AI Platform Prediction riduce il livello di astrazione per consentirti di scegliere il framework, il server del modello, le operazioni di pre-elaborazione e post-elaborazione necessarie.

Questo documento fa parte di una serie per ingegneri e architetti del machine learning che progettano, creano e gestiscono una piattaforma di pubblicazione di modelli ad alte prestazioni su Google Cloud:

In questo documento vengono illustrate le scelte relative alla pubblicazione dei modelli con particolare attenzione ai container personalizzati in AI Platform Prediction. Il documento associato si concentra sull'integrazione di Triton Inference Server con container personalizzati in AI Platform Prediction.

Quando utilizzare container personalizzati con AI Platform Prediction

Google Cloud offre diverse opzioni per la distribuzione di modelli ML. La tabella seguente fornisce le opzioni più comuni in base ai vari requisiti, per aiutarti a scegliere la piattaforma più adatta alle tue esigenze di previsione.

Esigenze di previsione AI Platform Prediction di base Container personalizzati AI Platform Prediction Google Kubernetes Engine (GKE) Dataflow (utilizzato come pipeline di previsione)
Un servizio di previsione del modello gestito No
Previsione sincrona a bassa latenza No
Analisi dei flussi di dati asincrona No No No
Previsione batch A seconda del server del modello
Supporto integrato per i framework TensorFlow, scikit-learn, XGBoost Nessuno, containerizzato dall'utente Nessuno, containerizzato dall'utente Utente caricato
Supporto per i server di modelli di terze parti No Utente containerizzato Utente containerizzato Non applicabile
La scelta del tipo di macchina dei nodi mls1 e n1-standard n1-standard Qualsiasi supporto di GKE Qualsiasi supporto di Dataflow
Supporto GPU
Elaborazione personalizzata esterna al server del modello Routine di previsione personalizzate Non applicabile

Le seguenti sezioni forniscono ulteriori dettagli per aiutarti a valutare le opzioni.

Attivazione

È importante considerare le modalità di consumo di un modello dopo la sua pubblicazione. Applicazioni quali il rischio delle transazioni e la pubblicazione di annunci in genere richiedono una previsione online sincrona e sono sensibili alla latenza. Le previsioni del lifetime value cliente (CLV) e i consigli vengono generalmente elaborati in modo più efficace in batch periodici di grandi dimensioni. I casi d'uso di manutenzione predittiva generalmente trasmettono in modalità asincrona i dati di telemetria. In questi casi, utilizzi un modello per identificare le condizioni di errore e il consumatore delle previsioni può essere un'applicazione di aggregazione che non è il mittente della telemetria. La scelta di una piattaforma di pubblicazione dipende da come viene consumato il modello.

Supporto di Compute

AI Platform Prediction di base supporta i tipi di macchine mls1 e n1-standard, mentre i container personalizzati in AI Platform Prediction supportano i tipi di macchine n1-standard. Per prestazioni ottimali, dovresti prendere in considerazione solo i tipi di macchine n1-standard.

Se hai dimestichezza con la gestione di una piattaforma di previsione a livello di infrastruttura e le tue applicazioni sono stateless e progettate per i nuovi tentativi in caso di richieste perse, puoi utilizzare GKE con nodi prerilasciabili. I nodi prerilasciabili possono aiutarti a ridurre i costi di calcolo. Tuttavia, devi sapere che i nodi prerilasciabili durano solo fino a 24 ore. Se prevedi di utilizzare nodi prerilasciabili in produzione, devi eseguire il deployment solo di carichi di lavoro che sono tolleranti la scomparsa dei nodi. I job offline e riavviabili con checkpoint sono la soluzione ideale per i nodi prerilasciabili.

Server di modelli di terze parti

Se ti serve un server di modelli personalizzato come Triton Inference Server o Facebook TorchServe, devi scegliere una piattaforma di previsione che può essere pubblicata direttamente da un container o caricare server di modelli personalizzati.

Supporto integrato per i framework

AI Platform Prediction Basic è un servizio di previsione gestito che supporta direttamente TensorFlow, XGBoost e scikit-learn. Ti consigliamo AI Platform Prediction di base se i modelli supportati e le versioni del framework possono pubblicare direttamente il tuo modello.

Pre-elaborazione e post-elaborazione dei dati

Quando esegui il deployment di un modello per la previsione, la forma dei dati è raramente la stessa della forma dei dati utilizzati per addestrare il modello. Questa dinamica, nota come disallineamento addestramento/produzione, richiede il pre-elaborazione dei dati prima che il modello possa elaborare le richieste di previsione. Generalmente anche i risultati previsti vengono usati con una sorta di post-elaborazione. Se possibile, ti consigliamo di aggiungere le operazioni di elaborazione al modello. Framework, come TensorFlow, ti consentono di aggiungere operazioni al grafico di pubblicazione, che non solo semplifica l'ambiente ma ne aumenta le prestazioni perché stai riducendo gli hop.

A volte potresti non essere in grado di incorporare l'elaborazione nel grafico del modello. Ad esempio, potresti utilizzare la pre-elaborazione con XGBoost o la tua pre-elaborazione è un modello addestrato con PyTorch, ma la categoria di classificazione è un modello addestrato in TensorFlow. Anche se le routine di previsione personalizzate in AI Platform Prediction ti consentono di inserire questo tipo di codice di pre-elaborazione, ti consigliamo di utilizzare i container personalizzati per motivi legati alle prestazioni. Le routine di previsione personalizzate non solo aggiungono un hop extra, ma il nodo extra è il tipo mls1 con prestazioni meno elevate.

Architettura per i container personalizzati in AI Platform Prediction

Il seguente diagramma illustra i componenti principali dei container personalizzati in AI Platform Prediction:

I componenti principali includono l'immagine container, il codice post-elaborazione o di pre-elaborazione, il modello e l'archivio modelli.

Le sezioni seguenti spiegano i concetti importanti del diagramma precedente.

Immagine di base

Fornisci un'immagine container personalizzata (A) che è l'immagine di base di un server modello o un'immagine derivata dall'immagine di base di un server modello. Nell'esempio fornito in AI Platform Prediction: configurazione diretta del server modello per NVIDIA Triton Inference Server, il server modello è Triton Inference Server.

Pre-elaborazione e post-elaborazione del codice

Se è richiesto un codice speciale (B), ad esempio routing o elaborazione personalizzati, dovrai utilizzare un nuovo Dockerfile per incorporare gli artefatti nel container. Il codice di pre-elaborazione ascolta le richieste in entrata, applica la pre-elaborazione e poi passa la richiesta pre-elaborata al server del modello. Qualsiasi codice post-elaborazione deve eseguire e restituire risultati al client.

Negozio di modelli

Per scegliere la località in cui il modello viene mantenuto, hai due opzioni:

  • Specifica il percorso per creare gli artefatti del modello in Cloud Storage. Se il server del modello è in grado di leggere direttamente da Cloud Storage, è preferibile utilizzare questa opzione(C). Ti consente di eseguire il deployment di una nuova versione del modello senza dover creare un nuovo container.
  • Copia gli artefatti del modello direttamente nel container. Questa opzione (D) riguarda i server modello che non possono leggere direttamente da Cloud Storage. Questa opzione richiede un nuovo container ogni volta che esegui il deployment di una nuova versione del modello.

Modello

AI Platform Prediction utilizza un paradigma architetturale basato su modelli e versioni, in cui il modello è un raggruppamento logico di versioni dei modelli. Un impiego tipico di questo paradigma è l'addestramento continuo. In questo caso, le applicazioni progettate per un modello specifico utilizzano tale modello, ma adottano versioni più recenti quando il modello viene addestrato nuovamente nel tempo.

Versione modello

Una versione del modello in AI Platform Prediction è un'istanza di un modello addestrato con set di dati, configurazione e iperparametri specifici. In AI Platform Prediction, le versioni del modello vengono considerate immutabili. Se devi aggiornare un modello (ad esempio hai riaddestrato il modello con un nuovo set di dati), devi crearne una nuova versione e poi implementarla. Le versioni dei modelli aiutano a semplificare le implementazioni canary. Poiché all'interno di un modello sono presenti versioni, devi crearlo prima di creare la versione.

Contenitore personalizzato

Un contenitore personalizzato (E) è un'istanza della versione del modello. Puoi creare il container personalizzato dall'immagine container personalizzata.

Client di inferenza

Dopo aver configurato il server del modello, il client di inferenza (F) comunica con AI Platform Prediction.

Pattern container personalizzati

Per questa serie, facciamo riferimento a due modelli architettonici generali per i container personalizzati: il pattern server diretto e il server modello con pattern listener. Il pattern listener può includere pre-elaborazione e post-elaborazione personalizzate. Per aiutarti a scegliere il modello di pubblicazione più adatto alle tue esigenze, la seguente tabella descrive alcuni casi d'uso supportati da ogni modello:

Esigenze di previsione Server modello diretto Server del modello con listener
Deployment semplificato No
Latenza più bassa possibile Dipende dall'elaborazione
Supporto di modelli singoli
Sovrapposizione di più modelli No
Pre-elaborazione e post-elaborazione complesse esterne al modello di server No
Opzioni di personalizzazione o più opzioni di routing No

Le seguenti sezioni descrivono i due pattern dei container.

Server modello diretto

Il pattern del server di modello diretto offre l'accesso diretto da AI Platform al server di modello senza alcuna connessione intermedia, come mostra il seguente diagramma:

Il server del modello viene memorizzato in un container personalizzato ed è accessibile direttamente.

Questo pattern è utile quando hai bisogno di quanto segue:

  • Un percorso di previsione. Il supporto di più modelli potrebbe richiedere più route a seconda del server. Se pubblichi un solo modello o se puoi gestire il server di modelli utilizzando un solo percorso di previsione, il modello di server di modello diretto è la scelta migliore. In genere, questo pattern è il più facile da configurare.
  • Bassa latenza. La comunicazione diretta tra AI Platform e il server del modello elimina tutti i potenziali ritardi causati da un intermediario.
  • La capacità di incapsulare e post-elaborazione nel modello. Framework come TensorFlow consentono di aggiungere operazioni di pre-elaborazione e post-elaborazione al grafico di computing. In generale, questo approccio è il modo più efficace per gestire le operazioni di pre-elaborazione e post-elaborazione, in quanto riduce al minimo il marmorizzazione della memoria in tutti i processi. Alcuni server di modello, come Triton Inference Server, offrono modelli di insieme in cui l'output di un modello può essere l'input per un altro modello. Questa funzionalità consente la pre-elaborazione e la post-elaborazione downstream all'interno del server del modello.

Server del modello con listener

In questo pattern puoi impostare un listener tra AI Platform e il server di modello, come mostra il seguente diagramma:

Un container personalizzato memorizza il server del modello e un listener contenente qualsiasi codice di pre-elaborazione o post-elaborazione.

Questo pattern è utile quando devi gestire i seguenti aspetti:

  • Routing complesso o sovrapposizione di più modelli. Alcuni server di modello supportano più modelli nella stessa istanza e richiedono route separate per accedere ai modelli. Per il multiplex attraverso il percorso di previsione, di solito è necessario un listener, con informazioni sul percorso di destinazione incorporate altrove (come l'intestazione).
  • Pre-elaborazione e post-elaborazione complessi. Alcuni framework che non consentono di incorporare la logica di pre-elaborazione e post-elaborazione richiedono un'elaborazione al di fuori del processo di inferenza. Inoltre, potrebbero verificarsi casi in cui un passaggio di pre-elaborazione richiede una chiamata esterna a un altro servizio. Questi pattern diventano difficili o impossibili da includere in un grafico.
  • Conversione del formato di inferenza. Per supportare i vari formati su più server dei modelli, puoi utilizzare un listener per eseguire la conversione del formato.

È importante capire che il listener è l'intermediario tra il server modello e AI Platform, aggiungendo così la latenza al processo. L'impatto di questa latenza è maggiore su un modello leggero che su un modello pesante. Ad esempio, se il tempo di inferenza per un modello di deep learning pesante è di 50 millisecondi (ms) e aggiungi 20 ms di pre-elaborazione, 20 ms è un aumento del 40%. Se aggiungi gli stessi 20 ms a un tempo di inferenza di 10 ms per un modello XGBoost leggero, 20 ms è un aumento del 200%.

Pianificare un modello e una versione

AI Platform Prediction organizza gli artefatti del modello in una gerarchia di progetto-modello-versione. Ad esempio, una società può avere più progetti Google Cloud. Ogni progetto può avere più modelli. Ogni modello può avere una o più versioni. Questa struttura ha il seguente aspetto:

  • Organizzazione di esempio
    • Progetto SalesOps
      • Modello CustomerPropensity
        • v20201131 versione del modello
        • v20201107 versione del modello
        • v20201009 versione del modello

Per ulteriori informazioni sui modelli e sulle relative versioni, consulta la panoramica delle previsioni.

Prima di creare una versione modello, devi creare un modello. Di seguito è riportato il formato per la richiesta REST per la creazione di un modello:

POST -d "{'name': 'MODEL_NAME'}" \
    ENDPOINT/projects/PROJECT_ID/models/

Questa richiesta contiene i seguenti valori:

  • MODEL_NAME: il nome del modello che stai creando, ad esempio buyer_recommendation
  • ENDPOINT: il servizio AI Platform all'indirizzo https://ml.googleapis.com/v1
  • PROJECT_ID: il progetto Google Cloud in cui vuoi creare questo modello

Puoi creare versioni successive del modello in questo modello con la seguente richiesta POST:

POST -d @version_spec.json \
    ENDPOINT/projects/PROJECT_ID/models/MODEL_NAME/versions

Per ulteriori informazioni, consulta i comandi REST nel riferimento AI Platform Prediction.

Di seguito è riportato un file version_spec.json di esempio per Triton Inference Server:

{
  "name": "v3",
  "deployment_uri": "gs://model-artifacts-source-location",
  "container": {
    "image": "gcr.io/my_project/triton:20.06",
    "args": ["tritonserver",
             "--model-repository=$AIP_STORAGE_URI"
    ],
    "env": [
    ],
    "ports": [
      { "containerPort": 8000 }
    ]
  },
  "routes": {
    "predict": "/v2/models/$AIP_MODEL_NAME/infer",
    "health": "/v2/models/$AIP_MODEL_NAME"
  },
  "machine_type": "n1-standard4",
  "acceleratorConfig": {
    "count":1,
    "type":"nvidia-tesla-t4"
  },
  "autoScale": {
    "minNodes":1
  }
}

La tabella seguente descrive gli elementi della specifica JSON precedente:

Elemento (* = obbligatorio) Descrizione
name* Il nome della versione del modello.
deployment_uri La località dei modelli in Cloud Storage. Quando viene creata una versione del modello, AI Platform copia gli artefatti da questa posizione e li rende disponibili attraverso la variabile di ambiente AIP_STORAGE_URI.
container:image* Percorso dell'immagine container.
container:args Il comando e gli argomenti utilizzati all'avvio del container.
container:env Le variabili di ambiente. Queste variabili di ambiente fornite dagli utenti sono rese disponibili per il container in fase di runtime.
container:ports* La porta di rete che AI Platform utilizza per comunicare con i container. Se una porta non è specificata, la porta predefinita è 8080.
routes:predict

L'endpoint del container che AI Platform utilizza per inoltrare le richieste di previsione al container. Se questo elemento è assente, l'endpoint instrada i valori predefiniti:

/v1/models/$AIP_MODEL_NAME/version/$AIP_VERSION_NAME:predict

routes:health

La route dell'endpoint del container che AI Platform utilizza per verificare l'integrità del container della versione del modello. Solo dopo una risposta riuscita, ovvero un codice di stato HTTP 200 del container con HTTP GET, viene indirizzato a questa istanza della versione del modello. Se questo elemento non è specificato, per impostazione predefinita il percorso dell'endpoint è il seguente:

/v1/models/$AIP_MODEL_NAME/version/$AIP_VERSION_NAME

machine_type* Il tipo di macchina virtuale per il nodo di inferenza.
acceleratorConfig:Count Se è richiesta una GPU, il numero di GPU per ciascun nodo.
acceleratorConfig:Type Se è necessaria una GPU, il tipo di GPU.
autoScale:minNodes Il numero minimo di nodi in modalità di scalabilità automatica. Questo elemento non può essere utilizzato con l'elemento manualScale.
manualScale:nodes Conteggio dei nodi in modalità di scalabilità manuale. Questo elemento non può essere utilizzato con l'elemento autoScale.

Le variabili di ambiente con il prefisso AIP_ in spec.json esistono solo dopo aver creato il contenitore della versione del modello. Dal file di esempio precedente version_spec.json, considera quanto segue:

  • $AIP_STORAGE_URI. Quando crei una versione del modello, AI Platform copia gli artefatti del modello da deployment_uri. Quando il container è online, cerca gli asset del modello su $AIP_STORAGE_URI. Nell'esempio, definiamo il flag per il repository del modello Triton Inference Server come --model-repository=$AIP_STORAGE_URI.
  • $AIP_MODEL_NAME: server modello come Triton Inference Server e TorchServe supportano più modelli contemporaneamente e prevedono il percorso dell'endpoint di richiesta per specificare il modello da eseguire per l'inferenza per la richiesta. Il valore di questo ambiente viene derivato da ${MODEL_NAME} quando viene creata la versione del modello.

La tabella seguente descrive alcune variabili di ambiente AIP_ comuni disponibili per il container:

Variabile di ambiente Descrizione
AIP_PROJECT_NUMBER Il numero del progetto in cui viene creato un modello.
AIP_MODEL_NAME Il nome del modello in cui vengono create le versioni. Il nome è ricavato dal valore ${MODEL_NAME} nel comando POST che utilizzi per creare il modello.
AIP_VERSION_NAME Il nome di una versione del modello. Il nome della versione del modello è ricavato dal valore name nella specifica JSON precedente che utilizzi per creare il modello.
AIP_HTTP_PORT La porta di destinazione del listener nel container personalizzato con cui AI Platform comunica. Il listener potrebbe essere il server del modello stesso o un intermediario, ad esempio il pre-elaborazione dei dati a monte del server del modello. Questa porta è tratta da container:ports nella specifica JSON precedente.
AIP_PREDICT_ROUTE La route a cui AI Platform inoltra le richieste di previsione quando comunica con il container personalizzato. Questa route viene recuperata da routes:predict nella specifica JSON precedente.
AIP_HEALTH_ROUTE La route che AI Platform utilizza per controllare l'integrità del container personalizzato. Questa route è recuperata da routes:health nella specifica JSON precedente.
AIP_STORAGE_URI La posizione in cui vengono copiati gli asset del modello da deployment_uri nella specifica JSON precedente. Questa variabile di ambiente definisce dove il server del modello cerca gli artefatti del modello.

Passaggi successivi