Vertex AI predykcja online 429 RESOURCE_EXHAUSTED: limit, autoskalowanie i ponawianie

Ten runbook dotyczy throttlingu w czasie predykcji. Jeśli model w ogóle się nie wdrożył, zobacz runbook o wdrożeniu endpointu. O tym, jak moc predykcji przekłada się na koszt, piszemy w jak działa cennik Vertex AI. Po pomoc praktyczną umów konsultację.

Objawy

Wywołanie zwraca 429. Treść komunikatu wskazuje, którą przyczynę masz.

# Ogólne wyczerpanie zasobów (często przejściowe, współdzielona moc)
google.api_core.exceptions.ResourceExhausted: 429 Resource exhausted.
Please try again later.

# Sufit limitu replik / serwowania (strukturalny, nie przejściowy)
google.api_core.exceptions.ResourceExhausted: 429 The following
quotas are exceeded: CustomModelServing<ACCELERATOR>PerProjectPerRegion

Obserwowalny skutek:

• Część wywołań predykcji kończy się błędem pod obciążeniem, podczas gdy inne przechodzą
• Błędy skupiają się w szczytach ruchu i znikają, gdy ruch spada (przejściowe), albo utrzymują się niezależnie od pory (sufit limitu)
• Klienci asynchroniczni lub o wysokiej współbieżności widzą 429 znacznie częściej niż prosty klient sekwencyjny

Przyczyna

Dwa mechanizmy dają 429 w predykcji online, a rozwiązanie zależy od tego, na który trafiasz.

• Throttling współdzielonej mocy on-demand. Predykcja on-demand konkuruje o współdzieloną moc GPU/TPU w regionie. Gdy popyt w tym regionie rośnie skokowo, żądania on-demand są throttlowane jako pierwsze. Te błędy 429 są przejściowe i mają być ponawiane. Są częstsze przy klientach asynchronicznych, o wysokiej współbieżności, oraz przy dużych żądaniach multimodalnych.
• Sufit limitu replik autoskalowania. Limit dla custom model serving opiera się na mocy obliczeniowej, której w czasie rzeczywistym używają Twoje wdrożone modele. Jeśli suma maxReplicaCount we wszystkich wdrożeniach w projekcie przekracza limit projektu, wdrożenia nie mogą skalować się w górę pod obciążenie, więc żądania ponad bieżącą moc są odrzucane. To strukturalne, żadna liczba ponowień tego nie usunie, dopóki nie zmieni się limit albo sufit replik.

Rozwiązanie

Krok 1: Ustal, który 429 masz

Sprawdź, czy endpoint uderza w sufit replik, czy tylko jedzie na współdzielonej mocy.

# Ile replik wdrożony model może mieć i ile używa?
gcloud ai endpoints describe ENDPOINT_ID --region=us-central1 \
  --format="yaml(deployedModels[].dedicatedResources.minReplicaCount,
    deployedModels[].dedicatedResources.maxReplicaCount)"

# Zobacz liczbę replik i metryki odrzuceń w Cloud Monitoring
# (prediction/online/replica_count oraz liczniki błędów predykcji)
gcloud monitoring time-series list \
  --filter='metric.type="aiplatform.googleapis.com/prediction/online/replica_count"' \
  --interval-start-time="$(date -u -v-1H +%Y-%m-%dT%H:%M:%SZ 2>/dev/null || date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ)" 2>/dev/null

Jeśli liczba replik jest przyklejona do maxReplicaCount podczas błędów, masz sufit mocy/limitu (krok 2). Jeśli repliki są poniżej maksimum, a mimo to dostajesz 429, to throttling współdzielonej mocy (krok 3).

Krok 2: Podnieś sufit replik albo limit serwowania

Jeśli model jest przyklejony do maksimum replik, daj mu miejsce, ale tylko do limitu serwowania projektu. Jeśli to sam limit jest granicą, poproś o jego zwiększenie.

# Podnieś maksymalną liczbę replik wdrożonego modelu
gcloud ai endpoints deploy-model ENDPOINT_ID \
  --region=us-central1 \
  --model=MODEL_ID \
  --max-replica-count=10 \
  --traffic-split=0=100

# Sprawdź limit custom model serving, zanim podniesiesz repliki ponad niego
# Konsola: IAM & Admin > Quotas, filtr Service = "Vertex AI API",
# metryka CustomModelServing<ACCELERATOR>PerProjectPerRegion
gcloud alpha services quota list \
  --service=aiplatform.googleapis.com \
  --consumer=projects/YOUR_PROJECT 2>/dev/null | grep -i customModelServing

Podniesienie maxReplicaCount ponad limit serwowania nie pomaga, bo wdrożenie i tak nie przeskaluje się poza limit. Poproś o zwiększenie limitu na stronie Quotas, gdy to limit jest prawdziwą granicą.

Krok 3: Dodaj wykładniczy backoff dla przejściowych 429

Błędy 429 ze współdzielonej mocy są oczekiwane pod obciążeniem i należy je ponawiać z backoff, a nie pokazywać użytkownikom.

import time, random
from google.api_core.exceptions import ResourceExhausted

def predict_with_retry(client, endpoint, instances, max_retries=5):
    for attempt in range(max_retries):
        try:
            return client.predict(endpoint=endpoint, instances=instances)
        except ResourceExhausted:
            if attempt == max_retries - 1:
                raise
            # wykładniczy backoff z jitterem
            time.sleep(min(2 ** attempt, 30) + random.uniform(0, 1))

Trzymaj współbieżność w ryzach. Rozsiewające żądania klienty asynchroniczne wzmacniają 429, więc ogranicz liczbę żądań w locie i rozłóż obciążenie, zamiast wysyłać wszystko naraz.

Krok 4: Przy stałym, przewidywalnym obciążeniu zarezerwuj moc

Jeśli obciążenie jest ciągłe, a nie skokowe, zejdź z czystego on-demand, aby nie konkurować o współdzieloną moc.

• Użyj dedykowanego endpointu z wyższym minReplicaCount, aby zawsze trzymać ciepłą moc
• Dla modeli generatywnych rozważ Provisioned Throughput tam, gdzie jest dostępny, który rezerwuje moc zamiast ją współdzielić
• Trzymaj endpoint i wołające go usługi w tym samym regionie, aby uniknąć rywalizacji między regionami

Walidacja

Potwierdź, że odsetek 429 spada pod reprezentatywnym obciążeniem.

# Wygeneruj krótki, reprezentatywny skok i policz odpowiedzi inne niż 200
for i in $(seq 1 50); do
  gcloud ai endpoints predict ENDPOINT_ID --region=us-central1 \
    --json-request=request.json >/dev/null 2>err.txt || cat err.txt
done | grep -c "RESOURCE_EXHAUSTED"
# Oczekiwane: 0 (lub mała liczba w pełni pochłonięta przez ponawianie z backoff)

Następnie potwierdź, że repliki skalują się teraz pod obciążeniem, zamiast przyklejać się do starego sufitu:

gcloud ai endpoints describe ENDPOINT_ID --region=us-central1 \
  --format="value(deployedModels[].dedicatedResources.maxReplicaCount)"
# Oczekiwane: podniesiony sufit, z replikami skalującymi się poniżej niego

Każda replika trzymana ciepło, aby pokonać 429, też nalicza koszt godzinowo, niezależnie od tego, czy obsługuje ruch. Dobierz minReplicaCount do realnego obciążenia bazowego, nie do szczytu. Przewymiarowanie, aby uniknąć sporadycznego throttlingu, bywa droższe niż poprawny backoff.

Skalujesz ruch predykcji na Vertex AI?

Umów bezpłatną rozmowę na 30 minut. Pomagamy zespołom dobrać rozmiar endpointów Vertex AI pod realne obciążenie, stroić autoskalowanie i decydować, kiedy rezerwowana moc wygrywa z on-demand.

Umów rozmowę Wyślij wiadomość

Powiązane

• Vertex AI: wdrożenie endpointu zablokowane lub nieudane - gdy model w ogóle nie wstał
• Vertex AI przekroczony limit wdrożenia / brak GPU - wersja sufitu limitu w czasie wdrożenia
• Jak działa cennik Vertex AI - dlaczego ciepłe repliki kosztują nawet bezczynne
• Dokumentacja autoskalowania predykcji Vertex AI