Informazioni sul servizio di addestramento personalizzato

Questa pagina illustra lo stato di un cluster di addestramento attraverso il ciclo di vita di un job di addestramento e come Vertex AI gestisce gli errori di addestramento. Puoi utilizzare queste informazioni per adattare di conseguenza il tuo codice di addestramento.

Ciclo di vita di un job di addestramento

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

Mettere in coda un nuovo job

Quando crei un elemento CustomJob o HyperparameterTuningJob, il job potrebbe rimanere in stato JOB_STATE_QUEUED per un po' di tempo prima di eseguirlo da Vertex AI. In genere questo periodo è breve, ma se il tuo progetto Google Cloud non dispone di quote di addestramento personalizzato rimanenti sufficienti per il tuo job, Vertex AI mantiene il job in coda fino a quando non avrai quote sufficienti.

Avvia worker in parallelo

Quando inizia un job di addestramento, Vertex AI pianifica il maggior numero possibile di worker in un breve periodo di tempo. Di conseguenza, i worker potrebbero avviarsi in parallelo anziché in sequenza. Per ridurre la latenza di avvio, Vertex AI inizia a eseguire il codice su ogni worker non appena diventa disponibile. 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 i worker. Se utilizzi una strategia di distribuzione nel codice di addestramento, potresti doverla regolare manualmente per gestire i worker che iniziano in parallelo. Scopri di più sulle strategie di distribuzione in TensorFlow e PyTorch.

Riavvia i worker durante il job di addestramento

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

  • Manutenzione della VM: quando la VM che esegue un worker è soggetta alla manutenzione della VM, 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 il worker immediatamente nella stessa VM.

    • Se un worker non funziona a causa di un errore comune, viene considerato come un errore permanente e Vertex AI arresta l'intero job. Se un container si riavvia prima che Vertex AI arresti l'intero job, questi potrebbero produrre log in Cloud Logging.
    • Se un worker non funziona a causa di un errore non permanente (qualsiasi errore non elencato tra gli errori comuni), Vertex AI consente al worker riavviato di continuare a lavorare, con un massimo di cinque riavvii per worker. Dopo cinque riavvii, se un worker continua a non riuscire, Vertex AI riprova l'intero job fino a tre volte prima di non completare l'intero job.

Per gestire i riavvii dei worker nel codice di addestramento, salva regolarmente i checkpoint durante l'addestramento, in modo da poterli ripristinare dai checkpoint al riavvio di un worker. 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 di addestramento in TensorFlow e in PyTorch.

Completamento di un job riuscito

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 tutti gli altri worker in esecuzione.

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

Questa sezione spiega in che modo Vertex AI gestisce gli errori comuni dei job di addestramento e quelli interni.

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

Gestire gli errori comuni

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

Tipo di errore Messaggio di errore/Log Nota
Eccezione codice utente La replica REPLICA_NAME è stata chiusa con uno stato diverso da zero di EXIT_CODE. Motivo della chiusura: REASON. Se il job ha rilevato codici di uscita che potrebbero essere temporanei, Vertex AI tenta di riavviare il job fino a tre volte. I codici di errore potenzialmente temporanei che richiedono a Vertex AI di riprovare a eseguire il job includono:
  • SIGABRT
    • ExitCode 6
    • ExitCode 134 (container personalizzati)
  • SIGSEGV
    • ExitCode 11
    • ExitCode 139 (container personalizzati)
Memoria esaurita La replica REPLICA_NAME ha esaurito la memoria ed è stata chiusa con uno stato diverso da zero di EXIT_CODE. GKE prenota memoria sui nodi Vertex AI. Sui tipi di macchine più piccole (come n1-standard-4), gli agenti di sistema Vertex AI possono utilizzare fino al 40% della memoria totale. Per le VM più grandi, l'overhead è relativamente ridotto. Confronta la memoria allocabile per i tipi di macchina n1-standard.
Capacità insufficiente nella tua regione (disponibilità di Compute Engine) Risorse insufficienti nella regione: REGION_NAME. Prova con un'altra regione o utilizza un altro acceleratore. Si verifica un esaurimento scorte quando Compute Engine ha raggiunto la capacità della CPU o della GPU selezionata nella tua regione. Non è correlato alla tua quota di progetto. In questo caso, Vertex AI tenta di riavviare il job fino a tre volte.

Gestire gli errori interni

Se Vertex AI presenta un errore interno, prova a 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.