Nesta página, explicamos o estado de um cluster de treinamento durante o ciclo de vida de um job de treinamento e como o Agent Platform lida com erros de treinamento. Use essas informações para adaptar o código de treinamento de acordo.
Ciclo de vida de um job de treinamento
Nesta seção, explicamos como o Agent Platform lida com VMs de worker por meio do ciclo de vida de um job de treinamento.
Enfileirar um novo job
Quando você cria um CustomJob ou HyperparameterTuningJob, o job pode permanecer
no estado JOB_STATE_QUEUED por algum tempo antes
de ser executado pelo Agent Platform. Esse período costuma ser breve. No entanto, se o
Google Cloud projeto não tiver cotas de treinamento personalizado
suficientes, o Agent Platform
manterá o job na fila até que você tenha cotas suficientes.
Iniciar workers em paralelo
Quando um job de treinamento é iniciado, o Agent Platform agenda o máximo de workers possível em um curto período. Como resultado, os workers podem ser iniciados em paralelo em vez de em sequência. Para reduzir a latência de inicialização, o Agent Platform começa a executar o código em cada worker assim que ele fica disponível. Quando todos os workers estiverem disponíveis, o Agent Platform definirá o estado do job como JOB_STATE_RUNNING.
Na maioria dos casos, seu framework de machine learning gerencia automaticamente os workers começando em paralelo. Se você estiver usando uma estratégia de distribuição no código de treinamento, talvez seja necessário ajustá-la manualmente para processar os workers em paralelo. Saiba mais sobre estratégias de distribuição no TensorFlow e no PyTorch (links em inglês).
Reiniciar workers durante o job de treinamento
Durante um job de treinamento, o Agent Platform pode reiniciar os workers de qualquer pool de workers com o mesmo nome de host. Este problema pode ocorrer pelos seguintes motivos:
- Manutenção de VM: quando a VM que executa um worker está sujeita a manutenção de VM, o Agent Platform reinicia o worker em outra VM. Saiba mais sobre migração em tempo real para manutenção de VM.
Saídas diferentes de zero: se qualquer worker sair com um código de saída diferente de zero, o Agent Platform reiniciará esse worker imediatamente na mesma VM.
- Se um worker falhar devido a um erro comum, ele será tratado como um erro permanente, e o Agent Platform encerrará o job inteiro. Se qualquer contêiner for reiniciado antes que o Agent Platform encerre o job inteiro, eles podem gerar registros no Cloud Logging.
- Se um worker falhar devido a um erro não permanente (qualquer erro não listado em os erros comuns), o Agent Platform permitirá que o worker recriado seja em execução, com até cinco reinicializações por worker. Após cinco reinicializações, se um worker falhar novamente, o Agent Platform repetirá o job todo até três vezes antes da falha.
Para gerenciar reinicializações do worker no código de treinamento, salve os checkpoints regularmente durante o treinamento para que você possa restaurá-los quando um worker for reiniciado. Se você espera que o treinamento leve mais de quatro horas, recomendamos salvar um checkpoint pelo menos uma vez a cada quatro horas. Saiba como usar checkpoints de treinamento no TensorFlow e no PyTorch (links em inglês).
Concluir um job com sucesso
Um job de treinamento é concluído com sucesso quando a réplica principal sai com o código de saída 0. Nesse ponto, o Agent Platform encerra todos os outros workers em execução.
Como o Agent Platform lida com erros do job de treinamento
Nesta seção, explicamos como o Agent Platform processa erros comuns de job de treinamento e erros internos.
Cerca de um minuto após o término de um job, o Agent Platform define o código de erro no objeto de job de treinamento, com base no código de saída.
Lidar com erros comuns
O Agent Platform encerra todos os workers caso encontre algum dos seguintes problemas:
| Tipo de erro | Mensagem/registro de erro | Observação |
| Exceção de código do usuário | A réplica REPLICA_NAME saiu com status diferente de zero de EXIT_CODE. Motivo da rescisão: REASON. | Se o job encontrou códigos de saída que podem ser temporários,
o Agent Platform tentará reiniciar o job até três vezes.
Os códigos de erro possivelmente temporários que solicitam o Agent Platform para
tentar novamente o job incluem o seguinte:
|
| Memória insuficiente | A réplica REPLICA_NAME ficou sem memória e saiu com um status diferente de zero de EXIT_CODE. |
O GKE reserva a memória nos nós do Agent Platform. Nos
menores tipos de máquina (como n1-standard-4),
os agentes do sistema do Agent Platform podem ocupar até 40% da memória total.
Para VMs maiores, a sobrecarga é relativamente pequena. Comparar
a memória alocável para os tipos de máquina n1-standard.
|
| Capacidade insuficiente na sua região (esgotado do Compute Engine) | Há recursos insuficientes na região: REGION_NAME. Tente uma região diferente ou use outro acelerador. | Uma
retirada ocorre quando o Compute Engine atinge a capacidade da
CPU ou GPU selecionada na região. Não tem relação com sua cota de projeto.
Quando isso acontece, o Agent Platform tenta reiniciar o job até
três vezes.
Para jobs executados em VMs A2 e A3, o Dynamic Workload Scheduler permite programar jobs que são executados quando os recursos de GPU solicitados ficam disponíveis, em vez de falhar com um erro de retirada. Para mais informações, consulte Programar jobs de treinamento com base na disponibilidade de recursos. |
Lidar com erros internos
Se o Agent Platform tiver um erro interno, ele tentará reiniciar um job duas vezes (três tentativas no total). Se as tentativas de reinicialização também falharem, o Agent Platform retornará um erro interno com a mensagem: Internal error occurred for the current attempt.