Questa pagina spiega lo stato di un cluster di addestramento durante il ciclo di vita di un job di addestramento e come Agent Platform 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 come Agent Platform gestisce le VM worker durante il ciclo di vita di un job di addestramento.
Mettere in coda un nuovo job
Quando crei un CustomJob o un HyperparameterTuningJob, il job potrebbe rimanere
nello stato JOB_STATE_QUEUED per un po' di tempo prima
che Agent Platform lo esegua. Questo periodo è in genere breve, ma se il tuo
Google Cloud progetto non dispone di quote di addestramento personalizzato
rimanenti sufficienti per il job, Agent Platform
mantiene il job in coda finché non hai quote sufficienti.
Avviare i worker in parallelo
Quando viene avviato un job di addestramento, Agent Platform pianifica il maggior numero possibile di worker in un breve periodo di tempo. Di conseguenza, i worker potrebbero essere avviati in parallelo anziché in sequenza. Per ridurre la latenza di avvio, Agent Platform inizia a eseguire il codice su ogni worker non appena diventa disponibile. Quando tutti i worker sono disponibili, Agent Platform imposta lo stato del job su JOB_STATE_RUNNING.
Nella maggior parte dei casi, il framework di machine learning gestisce automaticamente l'avvio parallelo dei worker. Se utilizzi una strategia di distribuzione nel codice di addestramento, potrebbe essere necessario modificarla manualmente per gestire l'avvio parallelo dei worker. Scopri di più sulle strategie di distribuzione in TensorFlow e in PyTorch.
Riavviare i worker durante il job di addestramento
Durante un job di addestramento, Agent Platform può riavviare i worker da qualsiasi pool di worker con lo stesso nome host. Questo può verificarsi per i seguenti motivi:
- Manutenzione delle VM: quando la VM che esegue un worker è soggetta a manutenzione, Agent Platform 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, Agent Platform lo riavvia immediatamente nella stessa VM.
- Se un worker non riesce a causa di un errore comune, viene considerato come un errore permanente e Agent Platform arresta l'intero job. Se i container vengono riavviati prima che Agent Platform arresti l'intero job, questi container potrebbero generare log in Cloud Logging.
- Se un worker non riesce a causa di un errore non permanente (qualsiasi errore non elencato negli errori comuni), Agent Platform consente al worker riavviato di continuare l'esecuzione, con un massimo di cinque riavvii per worker. Dopo cinque riavvii, se un worker non riesce di nuovo, Agent Platform ritenta l'intero job fino a tre volte prima di non riuscire a completarlo.
Per gestire i riavvii dei worker nel codice di addestramento, salva regolarmente i checkpoint durante l'addestramento in modo da poterli ripristinare quando un worker viene riavviato. Se prevedi che l'addestramento duri 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
Un job di addestramento viene completato correttamente quando la replica primaria esce con il codice di uscita 0. A questo punto, Agent Platform arresta tutti gli altri worker in esecuzione.
Come Agent Platform gestisce gli errori dei job di addestramento
Questa sezione spiega come Agent Platform gestisce gli errori comuni dei job di addestramento e gli errori interni.
Circa un minuto dopo la fine di un job, Agent Platform imposta il codice di errore sull'oggetto del job di addestramento, in base al codice di uscita.
Gestire gli errori comuni
Agent Platform arresta tutti i worker se rileva uno dei seguenti problemi:
| Tipo di errore | Messaggio/log di errore | Nota |
| Eccezione del codice utente | La replica REPLICA_NAME è uscita con uno stato diverso da zero di EXIT_CODE. Motivo della terminazione: REASON. | Se il job ha rilevato codici di uscita che potrebbero essere temporanei,
Agent Platform tenta di riavviare il job fino a tre volte.
I codici di errore potenzialmente temporanei che richiedono ad Agent Platform di
riprovare a eseguire il job includono:
|
| Memoria insufficiente | La replica REPLICA_NAME ha esaurito la memoria ed è uscita con uno stato diverso da zero di EXIT_CODE. |
GKE riserva memoria sui nodi di Agent Platform. Sui
tipi di macchina più piccoli (ad esempio n1-standard-4),
gli agenti di sistema di Agent Platform possono occupare fino al 40% della memoria totale.
Per le VM più grandi, l'overhead è relativamente piccolo. Confronta
la memoria allocabile per i tipi di macchinan1-standard.
|
| Capacità insufficiente nella regione (esaurimento delle scorte di Compute Engine) | Le risorse sono insufficienti nella regione: REGION_NAME. Prova a utilizzare un'altra regione o un altro acceleratore. | Si verifica un
esaurimento delle scorte quando Compute Engine raggiunge la capacità massima per la
CPU o la GPU selezionata nella regione. Non è correlato alla quota del progetto.
In questo caso, Agent Platform tenta di riavviare il job fino a
tre volte.
Per i job in esecuzione su VM A2 e A3, Dynamic Workload Scheduler consente di pianificare i job da eseguire quando le risorse GPU richieste diventano disponibili, anziché non riuscire a causa di un errore di esaurimento delle scorte. Per ulteriori informazioni, consulta Pianificare i job di addestramento in base alla disponibilità delle risorse. |
Gestire gli errori interni
Se Agent Platform rileva un errore interno, tenta di riavviare un job due volte (tre tentativi in totale). Se anche i tentativi di riavvio non vanno a buon fine, Agent Platform restituisce un errore interno con il messaggio: Internal error occurred for the current attempt.