Eseguire il deployment di un modello in un endpoint

Prima di poter ottenere previsioni online da un modello addestrato, devi eseguire il deployment del modello in un endpoint. Puoi farlo utilizzando la console Google Cloud, Google Cloud CLI o l'API Vertex AI.

Questo documento descrive la procedura per il deployment dei modelli negli endpoint.

Cosa succede quando esegui il deployment di un modello

Il deployment di un modello associa risorse fisiche al modello in modo che possa fornire previsioni online con bassa latenza.

Puoi eseguire il deployment di più modelli in un endpoint oppure dello stesso modello in più endpoint. Per ulteriori informazioni, consulta Motivi per eseguire il deployment di più modelli nello stesso endpoint.

Prepararsi a eseguire il deployment di un modello in un endpoint

Durante il deployment del modello, devi prendere le seguenti decisioni importanti su come eseguire la previsione online:

Risorsa creata Impostazione specificata al momento della creazione della risorsa
Endpoint Località in cui eseguire le previsioni
Modello Contenitore da utilizzare (ModelContainerSpec)
DeployedModel Risorse di calcolo da utilizzare per la previsione online

Una volta eseguito il deployment del modello nell'endpoint, queste impostazioni di deployment non possono essere modificate. Per modificarli, devi eseguire nuovamente il deployment del modello.

Il primo passaggio della procedura di deployment consiste nel decidere quale tipo di endpoint utilizzare. Per ulteriori informazioni, consulta Scegliere un tipo di endpoint.

Dopodiché, assicurati che il modello sia visibile nel registro dei modelli di Vertex AI. Questo è necessario per poter eseguire il deployment del modello. Per informazioni su Model Registry, inclusa la procedura per importare gli elementi del modello o crearli direttamente in Model Registry, consulta Introduzione a Vertex AI Model Registry.

La decisione successiva da prendere riguarda le risorse di calcolo da utilizzare per la pubblicazione del modello. Il tipo di addestramento (AutoML o personalizzato) e il tipo di dati (AutoML) del modello determinano i tipi di risorse fisiche a disposizione del modello. Dopo il deployment del modello, puoi mutate alcune di queste risorse senza creare un nuovo deployment.

La risorsa endpoint fornisce l'endpoint (URL) del servizio che utilizzi per richiedere la previsione. Ad esempio:

   https://us-central1-aiplatform.googleapis.com/v1/projects/{project}/locations/{location}/endpoints/{endpoint}:predict

Eseguire il deployment di un modello in un endpoint

Puoi eseguire il deployment di un modello in un endpoint utilizzando la console Google Cloud o utilizzando gcloud CLI o l'API Vertex AI.

Eseguire il deployment di un modello in un endpoint pubblico utilizzando la console Google Cloud

Nella console Google Cloud, puoi eseguire il deployment di un modello in un endpoint pubblico dedicato o condiviso esistente oppure puoi creare un nuovo endpoint durante la procedura di deployment. Per informazioni dettagliate, consulta Eseguire il deployment di un modello utilizzando la console Google Cloud.

Esegui il deployment di un modello in un endpoint pubblico utilizzando l'interfaccia a riga di comando gcloud o l'API Vertex AI

Quando esegui il deployment di un modello utilizzando l'interfaccia a riga di comando gcloud o l'API Vertex AI, devi prima creare un endpoint dedicato o condiviso e poi eseguire il deployment del modello al suo interno. Per maggiori dettagli, vedi:

  1. Creare un endpoint pubblico dedicato o condiviso
  2. Esegui il deployment di un modello utilizzando l'interfaccia a riga di comando gcloud o l'API Vertex AI

Eseguire il deployment di un modello in un endpoint Private Service Connect

Per maggiori dettagli, consulta Utilizzare gli endpoint di Private Service Connect per la previsione online.

Utilizzare un deployment incrementale per aggiornare un modello di cui è stato eseguito il deployment

Puoi utilizzare un deployment incrementale per sostituire un modello di cui è stato eseguito il deployment con una nuova versione dello stesso modello. Il nuovo modello riutilizza le risorse di calcolo del precedente. Per maggiori dettagli, consulta Utilizzare un deployment incrementale per sostituire un modello di cui è stato eseguito il deployment.

Annullare il deployment di un modello ed eliminare l'endpoint

Puoi annullare il deployment di un modello ed eliminare l'endpoint. Per maggiori dettagli, consulta Annullare il deployment di un modello ed eliminare l'endpoint.

Motivi per eseguire il deployment di più modelli nello stesso endpoint

Il deployment di due modelli nello stesso endpoint ti consente di sostituire gradualmente un modello con l'altro. Ad esempio, supponiamo che tu stia utilizzando un modello e trovi un modo per aumentarne l'accuratezza con nuovi dati di addestramento. Tuttavia, non vuoi aggiornare l'applicazione in modo che rimandi a un nuovo URL endpoint e non vuoi creare modifiche improvvise nell'applicazione. Puoi aggiungere il nuovo modello allo stesso endpoint, pubblicando una piccola percentuale di traffico, e aumentare gradualmente la suddivisione del traffico per il nuovo modello fino a quando non gestisce il 100% del traffico.

Poiché le risorse sono associate al modello anziché all'endpoint, puoi eseguire il deployment di modelli di tipi diversi nello stesso endpoint. Tuttavia, la migliore prassi è eseguire il deployment di modelli di un tipo specifico (ad esempio tabulari AutoML o con addestramento personalizzato) in un endpoint. Questa configurazione è più facile da gestire.

Motivi per eseguire il deployment di un modello in più di un endpoint

Potresti voler eseguire il deployment dei modelli con risorse diverse per ambienti di applicazione diversi, ad esempio di test e di produzione. Potresti anche supportare SLO diversi per le richieste di previsione. È possibile che una delle tue applicazioni abbia esigenze di prestazioni molto più elevate rispetto alle altre. In questo caso, puoi eseguire il deployment del modello in un endpoint con prestazioni superiori e con più risorse di calcolo. Per ottimizzare i costi, puoi anche eseguire il deployment del modello in un endpoint con prestazioni inferiori e con meno risorse di sistema.

Comportamento di scalabilità

Quando esegui il deployment di un modello per la previsione online come DeployedModel, puoi configurare i nodi di previsione in modo che si scalino automaticamente. Per farlo, imposta dedicatedResources.maxReplicaCount su un valore maggiore di dedicatedResources.minReplicaCount.

Quando configuri un DeployedModel, devi impostare dedicatedResources.minReplicaCount su almeno 1. In altre parole, non puoi configurare DeployedModel per scalare fino a 0 nodi di previsione quando non è utilizzato.

Per impostazione predefinita, l'operazione di deployment viene considerata riuscita solo se il numero di nodi di previsione raggiunge dedicatedResources.minReplicaCount prima del valore del timeout della richiesta di deployment. In caso contrario, il deployment viene contrassegnato come non riuscito e le risorse sottostanti vengono rilasciate.

Deployment e mutazione parzialmente riusciti

Puoi modificare il comportamento di implementazione predefinito impostando dedicatedResources.requiredReplicaCount su un valore inferiore a dedicatedResources.minReplicaCount. In questo caso, quando il numero di nodi di previsione raggiunge dedicatedResources.requiredReplicaCount, l'operazione di dispiegamento viene contrassegnata come riuscita, anche se non è ancora completata. Il deployment continua fino al raggiungimento di dedicatedResources.minReplicaCount. Se dedicatedResources.minReplicaCount non viene raggiunto prima dell'ora della richiesta di deployment, l'operazione è comunque riuscita, ma viene restituito un messaggio di errore per le repliche non riuscite in DeployedModel.status.message.

La quota per la pubblicazione di modelli personalizzati viene calcolata in base all'utilizzo in tempo reale delle risorse di calcolo da parte del modello di cui è stato eseguito il deployment. Se la somma di maxReplicaCount per tutti i deployment nel tuo progetto supera la quota del progetto, la scalabilità automatica di alcuni deployment potrebbe non riuscire a causa dell'esaurimento della quota.

Gli endpoint vengono scalati verso l'alto e verso il basso in base alla macchina, ma la quota viene calcolata per CPU o GPU. Ad esempio, se il modello viene disegnato per il tipo di macchina a2-highgpu-2g, ogni replica attiva viene conteggiata come 24 CPU e 2 GPU rispetto alla quota del progetto. Per ulteriori informazioni, consulta Quote e limiti.

I nodi di previsione per le previsioni in batch non vengono scalati automaticamente. Vertex AI utilizza BatchDedicatedResources.startingReplicaCount e ignora BatchDedicatedResources.maxReplicaCount.

Utilizzo e configurazione del target

Per impostazione predefinita, se esegui il deployment di un modello senza risorse GPU dedicate, Vertex AI aumenta o riduce automaticamente il numero di repliche in modo che l'utilizzo della CPU corrisponda al valore target predefinito del 60%.

Per impostazione predefinita, se esegui il deployment di un modello con risorse GPU dedicate (se machineSpec.accelerator_count è maggiore di 0), Vertex AI aumenterà o diminuirà automaticamente il numero di repliche in modo che l'utilizzo della CPU o della GPU, a seconda del valore più elevato, corrisponda al valore predefinito del 60%. Pertanto, se il throughput di previsione causa un utilizzo elevato della GPU, ma non della CPU, Vertex AI eseguirà il ridimensionamento e l'utilizzo della CPU sarà molto basso, il che sarà visibile nel monitoraggio. Al contrario, se il contenitore personalizzato sottoutilizza la GPU, ma ha un processo non correlato che aumenta l'utilizzo della CPU oltre il 60%, Vertex AI eseguirà l'upgrade, anche se potrebbe non essere stato necessario per raggiungere i target di QPS e latenza.

Puoi ignorare la metrica e il target della soglia predefiniti specificando autoscalingMetricSpecs. Tieni presente che se il deployment è configurato per il ridimensionamento in base solo all'utilizzo della CPU, non verrà eseguito lo scale up anche se l'utilizzo della GPU è elevato.

Gestire l'utilizzo delle risorse

Puoi monitorare il tuo endpoint per tenere traccia di metriche come l'utilizzo della CPU e dell'acceleratore, il numero di richieste, la latenza e il numero di repliche correnti e target. Queste informazioni possono aiutarti a comprendere il comportamento di scalabilità e l'utilizzo delle risorse del tuo endpoint.

Tieni presente che ogni replica esegue un solo contenitore. Ciò significa che se un contenitore di previsione non può utilizzare completamente la risorsa di calcolo selezionata, ad esempio codice a thread singolo per una macchina multi-core o un modello personalizzato che chiama un altro servizio durante la generazione della previsione, i nodi potrebbero non essere scalabili.

Ad esempio, se utilizzi FastAPI o qualsiasi server di modelli con un numero configurabile di worker o thread, in molti casi avere più di un worker può aumentare l'utilizzo delle risorse, migliorando la capacità del servizio di scalare automaticamente il numero di repliche.

In genere, consigliamo di iniziare con un worker o un thread per core. Se noti che l'utilizzo della CPU è basso, in particolare sotto carico elevato, o se il tuo modello non viene eseguito in modalità di scalabilità perché l'utilizzo della CPU è basso, aumenta il numero di worker. Se invece noti che l'utilizzo è troppo elevato e le latenze aumentano più del previsto sotto carico, prova a utilizzare meno worker. Se utilizzi già un solo worker, prova a utilizzare un tipo di macchina più piccolo.

Comportamento di scalabilità e tempo di latenza

Vertex AI regola il numero di repliche ogni 15 secondi utilizzando i dati della finestra dei 5 minuti precedenti. Per ogni ciclo di 15 secondi, il sistema misura l'utilizzo del server e genera un numero target di repliche in base alla seguente formula:

target # of replicas = Ceil(current # of replicas * (current utilization / target utilization))

Ad esempio, se hai due repliche utilizzate al 100%, il target è 4:

4 = Ceil(3.33) = Ceil(2 * (100% / 60%))

Un altro esempio: se hai 10 repliche e l'utilizzo scende all'1%, il target è 1:

1 = Ceil(.167) = Ceil(10 * (1% / 60%))

Al termine di ogni ciclo di 15 secondi, il sistema regola il numero di repliche in modo che corrisponda al valore target più alto della finestra dei 5 minuti precedenti. Tieni presente che, poiché viene scelto il valore target più alto, l'endpoint non verrà ridotto se si verifica un picco di utilizzo durante la finestra di 5 minuti, anche se l'utilizzo complessivo è molto basso. D'altra parte, se il sistema deve essere scalato, lo farà entro 15 secondi poiché viene scelto il valore target più alto anziché la media.

Tieni presente che anche dopo che Vertex AI ha modificato il numero di repliche, è necessario del tempo per avviarle o ridurle. Di conseguenza, si verifica un ritardo aggiuntivo prima che l'endpoint possa adeguarsi al traffico. I fattori principali che contribuiscono a questo tempo includono:

  • Il tempo necessario per il provisioning e l'avvio delle VM Compute Engine
  • Il tempo necessario per scaricare il contenitore dal registry
  • Il tempo necessario per caricare il modello dallo spazio di archiviazione

Il modo migliore per comprendere il comportamento di scalabilità del modello nel mondo reale è eseguire un test di carico e ottimizzare le caratteristiche importanti per il modello e il caso d'uso. Se lo strumento di scalabilità automatica non esegue lo scale up abbastanza rapidamente per la tua applicazione, esegui il provisioning di min_replicas sufficienti per gestire il traffico di riferimento previsto.

Aggiorna la configurazione della scalabilità

Se hai specificato DedicatedResources o AutomaticResources durante il deployment del modello, puoi aggiornare la configurazione di scalabilità senza eseguire nuovamente il deployment del modello chiamando mutateDeployedModel.

Ad esempio, la seguente richiesta aggiorna max_replica, autoscaling_metric_specs e disattiva il logging del contenitore.

{
  "deployedModel": {
    "id": "2464520679043629056",
    "dedicatedResources": {
      "maxReplicaCount": 9,
      "autoscalingMetricSpecs": [
        {
          "metricName": "aiplatform.googleapis.com/prediction/online/cpu/utilization",
          "target": 50
        }
      ]
    },
    "disableContainerLogging": true
  },
  "update_mask": {
    "paths": [
      "dedicated_resources.max_replica_count",
      "dedicated_resources.autoscaling_metric_specs",
      "disable_container_logging"
    ]
  }
}

Note sull'utilizzo:

  • Non puoi modificare il tipo di macchina o passare da DedicatedResources a AutomaticResources o viceversa. Gli unici campi di configurazione della scalabilità che puoi modificare sono: min_replica, max_replica, required_replica e AutoscalingMetricSpec (solo DedicatedResources).
  • Devi elencare tutti i campi da aggiornare in updateMask. I campi non elencati vengono ignorati.
  • DeployedModel deve essere in uno stato DEPLOYED. Può essere attiva al massimo un'operazione di mutazione per modello di cui è stato eseguito il deployment.
  • mutateDeployedModel ti consente inoltre di attivare o disattivare il logging del contenitore. Per ulteriori informazioni, consulta la sezione Log di previsione online.

Passaggi successivi