In un deployment in sequenza, un modello di cui è stato eseguito il deployment viene sostituito con una nuova versione dello stesso modello. Il nuovo modello riutilizza le risorse di computing del precedente.
Nella richiesta di implementazione graduale, la suddivisione del traffico e i valori di dedicatedResources
sono gli stessi dell'implementazione precedente. Al termine del deployment
in sequenza, la suddivisione del traffico viene aggiornata per mostrare che tutto il traffico del
DeployedModel
precedente è stato migrato al nuovo deployment.
Altri campi configurabili in DeployedModel
(ad esempio serviceAccount
,
disableContainerLogging
e enableAccessLogging
) sono impostati sugli stessi valori
di DeployedModel
precedente per impostazione predefinita. Tuttavia, puoi specificare
facoltativamente nuovi valori per questi campi.
Quando un modello viene sottoposto a deployment utilizzando un deployment in sequenza, viene creato un nuovo DeployedModel
. Il nuovo DeployedModel
riceve un nuovo ID diverso da quello
precedente. Riceve anche un nuovo valore revisionNumber
nel campo
rolloutOptions
.
Se sono presenti più implementazioni in sequenza che hanno come target le stesse risorse di backend,
DeployedModel
con il revisionNumber
più alto viene considerato lo
stato finale previsto.
Man mano che l'implementazione progressiva procede, tutte le repliche esistenti per la precedente
DeployedModel
vengono sostituite con repliche della nuova DeployedModel
. Ciò
avviene rapidamente e le repliche vengono aggiornate ogni volta che il deployment ha un numero sufficiente di repliche disponibili o una capacità di picco sufficiente per creare repliche aggiuntive.
Inoltre, man mano che il deployment progressivo procede, il traffico per il vecchio
DeployedModel
viene gradualmente migrato al nuovo DeployedModel
. Il traffico
viene bilanciato in proporzione al numero di repliche pronte per la pubblicazione di ciascun
DeployedModel
.
Se le nuove repliche del deployment in sequenza non diventano mai pronte perché il loro percorso di controllo dell'integrità restituisce costantemente un codice di risposta diverso da 200, il traffico non viene inviato a queste repliche non pronte. In questo caso, il deployment in sequenza alla fine
non riesce e le repliche vengono ripristinate al precedente DeployedModel
.
Avvia un deployment in sequenza
Per avviare un deployment progressivo, includi il campo rolloutOptions
nella richiesta di deployment del modello, come mostrato nell'esempio seguente.
REST
Prima di utilizzare i dati della richiesta, apporta le seguenti sostituzioni:
- LOCATION_ID: la regione in cui utilizzi Vertex AI.
- PROJECT_ID: il tuo ID progetto
- ENDPOINT_ID: l'ID dell'endpoint.
- MODEL_ID: l'ID del modello da implementare.
-
PREVIOUS_DEPLOYED_MODEL: L'ID
DeployedModel
di un modello sullo stesso endpoint. Specifica ilDeployedModel
le cui risorse di supporto devono essere riutilizzate. Puoi chiamareGetEndpoint
per ottenere un elenco dei modelli di cui è stato eseguito il deployment su un endpoint insieme ai relativi ID numerici. - MAX_UNAVAILABLE_REPLICAS: il numero di repliche del modello che possono essere ritirate durante il deployment in sequenza.
- MAX_SURGE_REPLICAS: il numero di repliche del modello aggiuntive che possono essere create durante il deployment in sequenza. Se questo valore è impostato su zero, viene utilizzata solo la capacità esistente.
Metodo HTTP e URL:
POST https://LOCATION_ID-aiplatform.googleapis.com/v1beta1/projects/PROJECT_ID/locations/LOCATION_ID/endpoints/ENDPOINT_ID:deployModel
Corpo JSON della richiesta:
{ "deployedModel": { "model": "projects/PROJECT_ID/locations/LOCATION_ID/models/MODEL_ID", "rolloutOptions": { "previousDeployedModel": "PREVIOUS_DEPLOYED_MODEL", "maxUnavailableReplicas": "MAX_UNAVAILABLE_REPLICAS", "maxSurgeReplicas": "MAX_SURGE_REPLICAS" } } }
Per inviare la richiesta, espandi una di queste opzioni:
Dovresti ricevere un codice di stato riuscito (2xx) e una risposta vuota.
Se vuoi, puoi sostituire maxSurgeReplicas
e maxUnavailableReplicas
,
o entrambi, con valori percentuali, come mostrato nell'esempio seguente.
REST
Prima di utilizzare i dati della richiesta, apporta le seguenti sostituzioni:
- MAX_UNAVAILABLE_PERCENTAGE: la percentuale di repliche del modello che possono essere ritirate durante il deployment in sequenza.
- MAX_SURGE_PERCENTAGE: la percentuale di repliche del modello aggiuntive che possono essere attivate durante il deployment in sequenza. Se questo valore è impostato su zero, viene utilizzata solo la capacità esistente.
Metodo HTTP e URL:
POST https://LOCATION_ID-aiplatform.googleapis.com/v1beta1/projects/PROJECT_ID/locations/LOCATION_ID/endpoints/ENDPOINT_ID:deployModel
Corpo JSON della richiesta:
{ "deployedModel": { "model": "projects/PROJECT/locations/LOCATION_ID/models/MODEL_ID", "rolloutOptions": { "previousDeployedModel": "PREVIOUS_DEPLOYED_MODEL", "maxUnavailablePercentage": "MAX_UNAVAILABLE_PERCENTAGE", "maxSurgePercentage": "MAX_SURGE_PERCENTAGE" } } }
Per inviare la richiesta, espandi una di queste opzioni:
Dovresti ricevere un codice di stato riuscito (2xx) e una risposta vuota.
Eseguire il rollback di un deployment in sequenza
Per eseguire il rollback di un deployment in sequenza, avvia un nuovo deployment in sequenza del modello precedente utilizzando l'ID DeployedModel
del deployment in sequenza in corso come previousDeployedModel
.
Per ottenere l'ID DeployedModel
per un deployment in corso, imposta il parametro
allDeploymentStates=true
nella chiamata a GetEndpoint
, come mostrato nell'esempio
seguente.
REST
Prima di utilizzare i dati della richiesta, apporta le seguenti sostituzioni:
- LOCATION_ID: la regione in cui utilizzi Vertex AI.
- PROJECT_ID: il tuo ID progetto
- ENDPOINT_ID: l'ID dell'endpoint.
Metodo HTTP e URL:
GET https://LOCATION_ID-aiplatform.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION_ID/endpoints/ENDPOINT_ID?allDeploymentStates=true
Per inviare la richiesta, espandi una di queste opzioni:
Dovresti ricevere una risposta JSON simile alla seguente:
{ "name": "projects/PROJECT_ID/locations/LOCATION_ID/endpoints/ENDPOINT_ID", "displayName": "rolling-deployments-endpoint", "deployedModels": [ { "id": "2718281828459045", "model": "projects/PROJECT_ID/locations/LOCATION_ID/models/MODEL_ID@1", "displayName": "rd-test-model", "createTime": "2024-09-11T21:37:48.522692Z", "dedicatedResources": { "machineSpec": { "machineType": "e2-standard-2" }, "minReplicaCount": 5, "maxReplicaCount": 5 }, "modelVersionId": "1", "state": "BEING_DEPLOYED" } ], "etag": "AMEw9yMs3TdZMn8CUg-3DY3wS74bkIaTDQhqJ7-Ld_Zp7wgT8gsEfJlrCOyg67lr9dwn", "createTime": "2024-09-11T21:22:36.588538Z", "updateTime": "2024-09-11T21:27:28.563579Z", "dedicatedEndpointEnabled": true, "dedicatedEndpointDns": "ENDPOINT_ID.LOCATION_ID-PROJECT_ID.prediction.vertexai.goog" }
Vincoli e limiti
- Il precedente
DeployedModel
deve trovarsi sullo stesso endpoint del nuovoDeployedModel
. - Non puoi creare più implementazioni in sequenza con lo stesso
previousDeployedModel
. - Non puoi creare implementazioni in sequenza sopra un
DeployedModel
che non è completamente implementato. Eccezione: sepreviousDeployedModel
è a sua volta un deployment rolling in corso, è possibile creare un nuovo deployment rolling sopra. Ciò consente di eseguire il rollback dei deployment che iniziano a non riuscire. - I modelli precedenti non vengono annullati automaticamente dopo il completamento corretto di un deployment progressivo. Puoi ritirare manualmente il modello.
- Per i deployment in sequenza sugli endpoint pubblici condivisi, i valori di
predictRoute
ehealthRoute
per il nuovo modello devono essere uguali a quelli del modello precedente. - I deployment graduali non sono compatibili con il co-hosting dei modelli.
- I deployment in sequenza non possono essere utilizzati per i modelli che richiedono spiegazioni online.