Informazioni sul servizio di addestramento personalizzato

Questa pagina spiega lo stato di un cluster di addestramento attraverso il ciclo di vita di un e il modo in cui Vertex AI gestisce gli errori di addestramento. Puoi utilizzare queste informazioni per adattare il codice di addestramento di conseguenza.

Ciclo di vita di un job di addestramento

Questa sezione spiega in che modo Vertex AI gestisce le VM worker tramite ciclo di vita di un job di addestramento.

Mettere in coda un nuovo job

Quando crei un CustomJob o HyperparameterTuningJob, il job potrebbe rimanere nello stato JOB_STATE_QUEUED da un po' di tempo prima Vertex AI la esegue. Di solito questo periodo è breve, ma se Il progetto Google Cloud non dispone di sufficiente addestramento personalizzato rimanente quote per il tuo job, quindi Vertex AI e mantiene il job in coda finché non si dispone di quote sufficienti.

Avvia worker in parallelo

All'avvio di un job di addestramento, Vertex AI pianifica il maggior numero di worker possibile in breve tempo. Di conseguenza, i lavoratori potrebbero iniziare in parallelo anziché in sequenza. Per ridurre la latenza di avvio, Vertex AI inizia a eseguire il codice su ogni worker non appena viene la disponibilità del servizio. Quando tutti i worker sono disponibili, Vertex AI imposta lo stato del job su JOB_STATE_RUNNING.

Nella maggior parte dei casi, il framework di machine learning gestisce automaticamente worker che si avviano in parallelo. Se utilizzi una strategia di distribuzione nel tuo codice di addestramento, potresti doverlo modificare manualmente per gestire i worker parallelo. Scopri di più sulle strategie di distribuzione in TensorFlow e in PyTorch.

Riavvia i worker durante il job di addestramento

Durante un job di addestramento, Vertex AI può riavviare worker di qualsiasi pool di worker con lo stesso nome host. Ciò può verificarsi per: motivi:

  • Manutenzione della VM: quando la VM che esegue un worker è soggetta a una VM di manutenzione, Vertex AI riavvia il worker su un'altra VM. Scopri di più sulla migrazione live per la manutenzione delle VM.
  • Uscite diverse da zero: se un worker esce con un codice di uscita diverso da zero, Vertex AI riavvia immediatamente quel worker nella stessa VM.

    • Se un worker non riesce a causa di un errore comune, viene trattato come errore permanente e Vertex AI arresta l'intero un lavoro. Se un container si riavvia prima dell'arresto di Vertex AI l'intero job, questi container possono produrre log in Cloud Logging.
    • Se un worker non riesce a causa di un errore non permanente (qualsiasi errore non elencato in gli errori comuni), Vertex AI consente worker riavviato per continuare a eseguire, con un massimo di cinque riavvii per worker. Dopo cinque riavvii, se un worker continua a funzionare, Vertex AI riprova a eseguire l'intero job fino a tre volte prima di non riuscire a completare l'intero job.

Per gestire i riavvii dei worker nel codice di addestramento, salva regolarmente i checkpoint durante l'addestramento, in modo da poter eseguire il ripristino dai checkpoint quando si riavvia. Se prevedi che l'addestramento richieda più di quattro ore, ti consigliamo di salvare un checkpoint almeno una volta ogni quattro ore. Scopri come utilizzare i checkpoint dell'addestramento TensorFlow e in PyTorch.

Completare un lavoro correttamente

Un job di addestramento viene completato correttamente quando la replica principale viene chiusa con il codice di uscita 0. A quel punto, Vertex AI arresta tutte le altre worker in esecuzione.

In che modo Vertex AI gestisce gli errori del job di addestramento

Questa sezione spiega in che modo Vertex AI gestisce il job di addestramento comune e gli errori interni.

Circa un minuto dopo il termine di un job, Vertex AI imposta il codice di errore su dell'oggetto job di addestramento, in base al codice di uscita.

Gestire gli errori comuni

Vertex AI arresta tutti i worker se rileva uno dei seguenti problemi:

Tipo di errore Messaggio/log di errore Nota
Eccezione codice utente La replica REPLICA_NAME è stata chiusa con uno stato diverso da zero EXIT_CODE. Motivo della risoluzione: REASON. Se il job ha rilevato codici di uscita che potrebbero essere temporanei, Vertex AI prova a riavviare il job fino a tre volte. I codici di errore potenzialmente temporanei che richiedono a Vertex AI di riprova a eseguire il job e includi quanto segue:
  • SIGABRT
    • ExitCode 6
    • ExitCode 134 (container personalizzati)
  • SIGSEGV
    • ExitCode 11
    • ExitCode 139 (container personalizzati)
Memoria insufficiente La replica REPLICA_NAME ha esaurito la memoria ed è stata chiusa con un diverso da zero di EXIT_CODE. GKE prenota memoria sui nodi Vertex AI. Attivato i tipi di macchina più piccoli (ad esempio n1-standard-4), Gli agenti di sistema Vertex AI possono occupare fino al 40% della memoria totale. Per le VM più grandi, l'overhead è relativamente ridotto. Confronta memoria allocabile per n1-standard tipi di macchine.
Capacità insufficiente nella tua regione (disponibilità di Compute Engine) Le risorse non sono sufficienti nella regione REGION_NAME. Prova un'altra regione o utilizzare un acceleratore diverso. R stockout si verifica quando Compute Engine ha raggiunto la capacità massima per il tuo con la CPU o la GPU selezionata nella tua regione. Non è correlato alla quota del tuo progetto. In questo caso, Vertex AI tenta di riavviare il job fino al tre volte.

Gestire gli errori interni

Se si verifica un errore interno, Vertex AI tenta di riavviare un job due volte (tre tentativi in totale). Se anche i tentativi di riavvio non vanno a buon fine, Vertex AI restituisce un errore interno con il messaggio: Internal error occurred for the current attempt.