Bereitgestelltes Modell durch Rolling Deployment ersetzen

Bei einer Rolling Deployment wird ein bereitgestelltes Modell durch eine neue Version desselben Modells ersetzt. Das neue Modell verwendet die Rechenressourcen des vorherigen Modells wieder.

In der Anfrage für das stufenweise Deployment sind die Werte für die Aufteilung der Zugriffe und dedicatedResources dieselben wie beim vorherigen Deployment. Nach Abschluss der fortlaufenden Bereitstellung wird die Trafficaufteilung aktualisiert. Sie zeigt dann, dass der gesamte Traffic aus dem vorherigen DeployedModel zur neuen Bereitstellung migriert wurde.

Andere konfigurierbare Felder in DeployedModel (z. B. serviceAccount, disableContainerLogging und enableAccessLogging) werden standardmäßig auf dieselben Werte wie für die vorherige DeployedModel festgelegt. Sie können jedoch optional neue Werte für diese Felder angeben.

Wenn ein Modell mit einer fortlaufenden Bereitstellung bereitgestellt wird, wird eine neue DeployedModel erstellt. Das neue DeployedModel erhält eine neue ID, die sich von der des vorherigen unterscheidet. Außerdem wird im Feld rolloutOptions ein neuer revisionNumber-Wert empfangen.

Wenn es mehrere fortlaufende Bereitstellungen gibt, die auf dieselben zugrunde liegenden Ressourcen ausgerichtet sind, wird die DeployedModel mit dem höchsten revisionNumber als beabsichtigter Endzustand behandelt.

Im Laufe der fortlaufenden Bereitstellung werden alle vorhandenen Replikate für die vorherige DeployedModel durch Replikate der neuen DeployedModel ersetzt. Das geht schnell und Replikate werden aktualisiert, sobald für die Bereitstellung genügend verfügbare Replikate oder genügend Pufferkapazität zum Hochfahren zusätzlicher Replikate vorhanden sind.

Außerdem wird der Traffic für die alte DeployedModel im Laufe der fortlaufenden Bereitstellung nach und nach zur neuen DeployedModel migriert. Der Traffic wird proportional zur Anzahl der bereitgestellten Replikate der einzelnen DeployedModel per Load-Balancing verteilt.

Wenn die neuen Replikate des Rolling Deployments nie bereit sind, weil ihr Health-Route immer einen Antwortcode zurückgibt, der nicht 200 ist, wird kein Traffic an diese nicht bereiten Replikate gesendet. In diesem Fall schlägt das Rolling Deployment schließlich fehl und die Replikate werden auf die vorherige DeployedModel zurückgesetzt.

Rolling Deployment starten

Um ein Rolling Deployment zu starten, fügen Sie das Feld rolloutOptions in die Anfrage für das Modelldepoyment ein, wie im folgenden Beispiel gezeigt.

REST

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • LOCATION_ID: Die Region, in der Sie die Agent Platform verwenden.
  • PROJECT_ID: Ihre Projekt-ID. .
  • ENDPOINT_ID: Die ID des Endpunkts.
  • MODEL_ID: Die ID des bereitzustellenden Modells.
  • PREVIOUS_DEPLOYED_MODEL: Die DeployedModel-ID eines Modells am selben Endpunkt. Damit wird die DeployedModel angegeben, deren unterstützende Ressourcen wiederverwendet werden sollen. Sie können GetEndpoint aufrufen, um eine Liste der bereitgestellten Modelle an einem Endpunkt zusammen mit ihren numerischen IDs zu erhalten.
  • MAX_UNAVAILABLE_REPLICAS: Die Anzahl der Modellreplikate, die während der fortlaufenden Bereitstellung heruntergefahren werden können.
  • MAX_SURGE_REPLICAS: Die Anzahl der zusätzlichen Modellreplikate, die während des rollierenden Deployments hochgefahren werden können. Wenn dieser Wert auf null gesetzt ist, wird nur die vorhandene Kapazität verwendet.

HTTP-Methode und URL: 

POST https://LOCATION_ID-aiplatform.googleapis.com/v1beta1/projects/PROJECT_ID/locations/LOCATION_ID/endpoints/ENDPOINT_ID:deployModel

JSON-Text anfordern:

{
  "deployedModel": {
    "model": "projects/PROJECT_ID/locations/LOCATION_ID/models/MODEL_ID",
    "rolloutOptions": {
      "previousDeployedModel": "PREVIOUS_DEPLOYED_MODEL",
      "maxUnavailableReplicas": "MAX_UNAVAILABLE_REPLICAS",
      "maxSurgeReplicas": "MAX_SURGE_REPLICAS"
    }
  }
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten einen erfolgreichen Statuscode (2xx) und eine leere Antwort als Ausgabe erhalten.

Bei Bedarf können Sie maxSurgeReplicas und/oder maxUnavailableReplicas durch Prozentwerte ersetzen, wie im folgenden Beispiel gezeigt.

REST

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • MAX_UNAVAILABLE_PERCENTAGE: Der Prozentsatz der Modellreplikate, die während der fortlaufenden Bereitstellung heruntergefahren werden können.
  • MAX_SURGE_PERCENTAGE: Der Prozentsatz der zusätzlichen Modellreplikate, die während der fortlaufenden Bereitstellung hochgefahren werden können. Wenn dieser Wert auf null gesetzt ist, wird nur die vorhandene Kapazität verwendet.

HTTP-Methode und URL: 

POST https://LOCATION_ID-aiplatform.googleapis.com/v1beta1/projects/PROJECT_ID/locations/LOCATION_ID/endpoints/ENDPOINT_ID:deployModel

JSON-Text anfordern:

{
  "deployedModel": {
    "model": "projects/PROJECT/locations/LOCATION_ID/models/MODEL_ID",
    "rolloutOptions": {
      "previousDeployedModel": "PREVIOUS_DEPLOYED_MODEL",
      "maxUnavailablePercentage": "MAX_UNAVAILABLE_PERCENTAGE",
      "maxSurgePercentage": "MAX_SURGE_PERCENTAGE"
    }
  }
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten einen erfolgreichen Statuscode (2xx) und eine leere Antwort als Ausgabe erhalten.

Rollback eines fortlaufenden Deployments durchführen

Wenn Sie ein Rolling Deployment zurücksetzen möchten, starten Sie ein neues Rolling Deployment des vorherigen Modells und verwenden Sie die DeployedModel-ID des laufenden Rolling Deployments als previousDeployedModel.

Um die DeployedModel-ID für eine laufende Bereitstellung abzurufen, legen Sie den Parameter allDeploymentStates=true im Aufruf von GetEndpoint fest, wie im folgenden Beispiel gezeigt.

REST

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • LOCATION_ID: Die Region, in der Sie die Agent Platform verwenden.
  • PROJECT_ID: Ihre Projekt-ID. .
  • ENDPOINT_ID: Die ID des Endpunkts.

HTTP-Methode und URL: 

GET https://LOCATION_ID-aiplatform.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION_ID/endpoints/ENDPOINT_ID?allDeploymentStates=true

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten eine JSON-Antwort ähnlich wie diese erhalten:

{
  "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"
}

Einschränkungen und Grenzwerte

  • Die vorherige DeployedModel muss sich am selben Endpunkt wie die neue DeployedModel befinden.
  • Sie können nicht mehrere fortlaufende Bereitstellungen mit demselben previousDeployedModel erstellen.
  • Sie können keine fortlaufenden Bereitstellungen für eine DeployedModel erstellen, die nicht vollständig bereitgestellt ist. Ausnahme: Wenn previousDeployedModel selbst eine laufende Rolling-Bereitstellung ist, kann eine neue Rolling-Bereitstellung darauf aufbauend erstellt werden. So können Bereitstellungen, bei denen Fehler auftreten, zurückgesetzt werden.
  • Vorherige Modelle werden nach Abschluss einer stufenweisen Bereitstellung nicht automatisch zurückgezogen. Sie können das Modell manuell entfernen. Wenn Sie das vorherige Modell bereitstellen, warten Sie nach Abschluss der Traffic-Migration mindestens 10 bis 15 Minuten, bevor Sie die Bereitstellungsanfrage initiieren. So können In-Flight-Verbindungen beendet und Routing-Updates vollständig synchronisiert werden.
  • Bei der schrittweisen Bereitstellung auf gemeinsam genutzten öffentlichen Endpunkten müssen predictRoute und healthRoute für das neue Modell mit denen des vorherigen Modells übereinstimmen.
  • Rolling Deployments sind nicht mit Model-Cohosting kompatibel.
  • Rolling Deployments können nicht für Modelle verwendet werden, für die Online-Erläuterungen erforderlich sind.