Nesta página, explicamos o estado de um cluster de treinamento durante o ciclo de vida de um job de treinamento e como a 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 a Agent Platform lida com VMs de worker durante o 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 pela plataforma de agentes. Esse período costuma ser breve. No entanto, se o projetoGoogle Cloud não tiver cotas de treinamento personalizadas suficientes, a plataforma de agentes manterá o job na fila até que você tenha cotas suficientes.
Iniciar workers em paralelo
Quando um job de treinamento é iniciado, a plataforma de agentes 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,
a plataforma de agentes começa a executar o código em cada worker assim que ele
fica disponível. Quando todos os workers estiverem disponíveis, a plataforma do agente
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, a plataforma de agentes 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 da VM, a plataforma de agente 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, a plataforma de agentes reiniciará esse worker imediatamente na mesma VM.
- Se um worker falhar devido a um erro comum, ele será tratado como um erro permanente, e a plataforma de agentes encerrará o job inteiro. Se qualquer contêiner for reiniciado antes que a plataforma de agentes encerre o job inteiro, eles poderão gerar registros no Cloud Logging.
- Se um worker falhar devido a um erro não permanente (qualquer erro não listado nos erros comuns), a plataforma de agentes 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, a plataforma de agentes vai repetir o job inteiro até três vezes antes de falhar.
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, a plataforma de agentes encerra todos os outros workers em execução.
Como a plataforma de agentes lida com erros de job de treinamento
Nesta seção, explicamos como a Agent Platform processa erros comuns de job de treinamento e erros internos.
Cerca de um minuto após o término de um job, a plataforma de agentes define o código de erro no objeto de job de treinamento, com base no código de saída.
Lidar com erros comuns
A plataforma de agente 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,
a Agent Platform tentará reiniciar o job até três vezes.
Os códigos de erro possivelmente temporários que solicitam a 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 da plataforma de agentes. Nos
menores tipos de máquina (como n1-standard-4),
os agentes do sistema da plataforma de agentes 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, a plataforma de agentes 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 falta de estoque. Para mais informações, consulte Programar jobs de treinamento com base na disponibilidade de recursos. |
Lidar com erros internos
Se a plataforma de agente tiver um erro interno, ela tentará reiniciar um job
duas vezes (três tentativas no total). Se as tentativas de reinicialização também falharem,
a plataforma de agentes vai retornar um erro interno com a mensagem:
Internal error occurred for the current attempt.