Logo
GCP Vertex AI machine learning MLOps

Vertex AI: wdrożenie endpointu zablokowane lub nieudane - kontener, gotowość i limit

Rozwiązanie operacji DeployModel w Vertex AI, która utknęła lub kończy się błędem: diagnoza kontraktu kontenera modelu, gotowości tras health i predict, ścieżek artefaktu modelu oraz limitu custom model serving, który po cichu blokuje wdrożenie.

Jerzy Kopaczewski ·
Twoja operacja DeployModel na endpoincie Vertex AI działa długo i kończy się błędem, albo nigdy nie wchodzi w stan serwowania. Model wgrywa się poprawnie, ale nie wstaje za endpointem. Przyczyna to niemal zawsze jedno z tych trzech: kontener serwujący nie spełnia kontraktu Vertex AI, artefakt modelu lub health check jest błędny, albo wdrożenie blokuje limit custom model serving. Ten runbook rozdziela te trzy przypadki i naprawia każdy z nich.

Ten runbook dotyczy nieudanych wdrożeń własnych modeli. O tym, jak endpointy Vertex AI są rozliczane, gdy są wdrożone (dlatego zablokowane albo zapomniane wdrożenie kosztuje), piszemy w jak działa cennik Vertex AI oraz w przeglądzie platformy czym jest Vertex AI. Po pomoc praktyczną umów konsultację.

Objawy

Wdrożenie albo wisi, albo zwraca długo działającą nieudaną operację. Najpierw rozpoznaj swój przypadek.

# 1. Operacja DeployModel kończy się błędem po długim oczekiwaniu
google.api_core.exceptions.FailedPrecondition: 400 Model server
never became ready. Please validate that your model file or
container configuration are valid.

# 2. Operacja zablokowana przez limit (zobacz osobny runbook o limitach)
google.api_core.exceptions.ResourceExhausted: 429 The following
quotas are exceeded: CustomModelServingT4GPUsPerProjectPerRegion

# 3. Operacja po prostu wisi w toku
# gcloud ai operations describe pokazuje done: false przez 20-30+ minut
# bez błędu, aż w końcu przekracza limit czasu.

Obserwowalny skutek:

  • Model wgrywa się do Model Registry, ale nigdy nie obsługuje ruchu
  • gcloud ai endpoints describe pokazuje endpoint bez wdrożonego modelu lub wdrożony model, który uruchammia się ale bez zdrowych replik
  • Operacja DeployModel długo działa a w końcu kończy się błędem lub przekracza limit czasu

Przyczyna

Własny model Vertex AI musi przejść kontrakt kontenera i sprawdzenie gotowości, zanim endpoint zacznie do niego kierować ruch, a cała operacja musi zmimeścić się w limicie czasu.

  • Kontrakt kontenera niespełniony. Własny kontener serwujący musi nasłuchiwać na porcie, którego oczekuje Vertex AI, odpowiadać na skonfigurowaną trasę health i na trasę predict. Jeśli którakolwiek zakończy się błędem, serwer modelu „nigdy nie staje się gotowy” i wdrożenie kończy się błędem po upływie limitu czasu.
  • Niezgodność artefaktu lub trasy. Dla gotowych kontenerów artefakt pod artifactUri musi pasować do układu oczekiwanego przez framework (na przykład model.joblib, saved_model.pb lub pliki, których oczekuje kontener). Zła ścieżka lub format oznacza, że serwer startuje, ale nie potrafi wczytać modelu.
  • Limit blokuje wdrożenie. Custom model serving zużywa limit na region i na akcelerator. Jeśli wdrożenie potrzebuje GPU, na które projekt nie ma limitu, albo suma replik we wszystkich wdrożeniach przekracza limit, DeployModel kończy się błędem ResourceExhausted. Ten konkretny przypadek ma własny runbook (link poniżej).

Rozwiązanie

Krok 1: Odczytaj operację i logi serwera modelu

Operacja długo działająca niesie powód błędu, a Cloud Logging ma własne wyjście kontenera.

# Lista ostatnich operacji endpointu i ich stan
gcloud ai operations list --region=us-central1 \
  --filter="done=false" 2>/dev/null

# Opis konkretnej operacji DeployModel (id z wywołania deploy)
gcloud ai operations describe OPERATION_ID --region=us-central1

# Odczyt logów kontenera serwera modelu w Cloud Logging
gcloud logging read \
  'resource.type="aiplatform.googleapis.com/Endpoint" severity>=WARNING' \
  --limit=50 --freshness=1h --format="value(textPayload)"

Jeśli logi mówią, że serwer modelu nigdy nie stał się gotowy, przejdź do kroku 2. Jeśli widzisz ResourceExhausted lub limit CustomModelServing..., przejdź do runbooka o limitach. Jeśli kontener loguje błąd wczytywania, przejdź do kroku 3.

Krok 2: Zweryfikuj kontrakt kontenera serwującego lokalnie

Nie debuguj kontraktu przez ponowne wdrożenia, to wolne i zżera limit. Najpierw uruchom kontener lokalnie i sprawdź trasy health oraz predict.

# Uruchom kontener serwujący lokalnie, mapując port, który sprawdzi Vertex AI
docker run --rm -p 8080:8080 \
  -e AIP_HTTP_PORT=8080 \
  -e AIP_HEALTH_ROUTE=/health \
  -e AIP_PREDICT_ROUTE=/predict \
  YOUR_SERVING_IMAGE:TAG

# W drugiej powłoce: trasa health musi zwrócić 200
curl -i http://localhost:8080/health
# Oczekiwane: HTTP/1.1 200

# Trasa predict musi przyjąć kopertę żądania Vertex AI
curl -s -X POST http://localhost:8080/predict \
  -H "Content-Type: application/json" \
  -d '{"instances":[{"x":1}]}'
# Oczekiwane: {"predictions":[...]}

Vertex AI wstrzykuje do kontenera AIP_HTTP_PORT, AIP_HEALTH_ROUTE i AIP_PREDICT_ROUTE, więc Twój serwer musi czytać te zmienne środowiskowe, zamiast zapisywać port czy ścieżkę na sztywno. Kontener, który przechodzi te trzy sprawdzenia lokalnie, niemal zawsze wdroży się poprawnie.

Krok 3: Potwierdź, że artefakt modelu pasuje do kontenera

Dla gotowego kontenera układ artefaktu jest ustalony. Potwierdź, że plik oczekiwany przez kontener faktycznie zajduje się pod adresem z artifactUri.

# Sprawdź, co wgrałeś
gcloud ai models describe MODEL_ID --region=us-central1 \
  --format="value(containerSpec.imageUri, artifactUri)"

# Wylistuj katalog artefaktu w GCS
gcloud storage ls -r gs://your-bucket/your-model-dir/
# Gotowy sklearn oczekuje: model.joblib lub model.pkl
# Gotowy TensorFlow oczekuje: SavedModel (saved_model.pb + variables/)
# Gotowy XGBoost oczekuje: model.bst / model.joblib / model.pkl

Jeśli układ jest zły, wgraj artefakt ponownie w oczekiwanym formacie i ponów wdrożenie.

Krok 4: Wdróż ponownie z małą, jawną konfiguracją

Gdy kontener przechodzi lokalnie, a artefakt jest poprawny, wdróż ponownie z jedną małą repliką, aby błąd ujawnił się szybko i tanio.

gcloud ai endpoints deploy-model ENDPOINT_ID \
  --region=us-central1 \
  --model=MODEL_ID \
  --display-name=my-model-v1 \
  --machine-type=n1-standard-2 \
  --min-replica-count=1 \
  --max-replica-count=1 \
  --traffic-split=0=100

Wdróż najpierw na jedną replikę, potwierdź, że serwuje, a dopiero potem podnieś --max-replica-count. Podnoszenie liczby replik, zanim model w ogóle zaczął serwować, tylko mnoży koszt zepsutego wdrożenia.

Walidacja

Potwierdź, że model jest wdrożony i serwuje.

# 1. Endpoint pokazuje teraz wdrożony model ze zdrowymi replikami
gcloud ai endpoints describe ENDPOINT_ID --region=us-central1 \
  --format="value(deployedModels[].id, deployedModels[].displayName)"
# Oczekiwane: id i nazwa wyświetlana Twojego modelu

# 2. Prawdziwa predykcja zwraca wynik
gcloud ai endpoints predict ENDPOINT_ID --region=us-central1 \
  --json-request=request.json
# Oczekiwane: ładunek predictions, bez błędu

Endpoint Vertex AI nalicza koszt za każdą godzinę, w której model pozostaje wdrożony, nawet przy zerowym ruchu. Wdrożenie, które „utknęło”, to często model, który nie wstał, ale wciąż zarezerwował moc, więc napraw je albo wycofaj szybko, zamiast zostawiać je, by naliczało koszt.

 

Jerzy Kopaczewski

Uruchamiasz modele na Vertex AI?

Umów bezpłatną rozmowę na 30 minut. Pomagamy zespołom uruchomić własne modele na Vertex AI, przejść kontrakt kontenera za pierwszym razem i trzymać koszt endpointów pod kontrolą.

Umów rozmowę

Powiązane