US$ 1,85 e 832 steps perdidos num pod eviction
Um fine-tuning numa A100 alugada morreu no step 832 por um pod eviction. /workspace é efêmero, nohup não sobrevive à queda do SSH e pkill -9 python derruba mais do que o seu treino.
O treino estava no step 832 de 1500. O checkpoint do step 500 estava em
/workspace/output. O host tomou o pod de volta. Tudo naquela máquina sumiu: o
checkpoint, o treino parcial, US$ 1,85. Refiz do zero.
Três suposições erradas.
/workspace não é storage
Num pool de GPU SECURE, /workspace é efêmero. Nem declarar volume_in_gb na
spec do pod te protege. O host pode tomar o nó de volta e levar o volume junto.
O checkpoint do step 500 não era backup. Era um arquivo no disco de outra
pessoa.
A correção: um loop de scp local rodando em paralelo com o treino. A cada 60
segundos ele consulta o diretório de saída remoto e copia qualquer
.safetensors novo que ainda não viu. Use --save_every_n_steps 250 em vez do
padrão 500. No pior caso, um eviction custa uma janela de checkpoint. A conexão
do scp precisa de -o ConnectTimeout=30 -o ServerAliveInterval=15, senão cai
em silêncio quando o remoto fica ocioso.
nohup não sobrevive ao shell
nohup ... &; disown não mantém o processo vivo quando a sessão SSH fecha na
imagem ComfyUI da RunPod. O processo morre junto com o shell.
setsid cria uma sessão nova, totalmente desacoplada do terminal:
setsid bash -c "sleep 6000 && pkill -9 -f flux_train_network" \
< /dev/null > /dev/null 2>&1 &O treino sobrevive à morte do shell. O timer do watchdog dispara no horário, com a conexão aberta ou não.
pkill -9 python mata mais do que o seu treino
Nessa imagem, o sshd é um wrapper em Python. pkill -9 python derruba ele
junto, globalmente, e a conexão cai no meio do treino. Mate scripts pelo nome
específico com pkill -f <script_name>, nunca pelo runtime.
Lição
Infraestrutura alugada é efêmera por padrão. Faça o treino sobreviver à máquina sumindo, em vez de assumir que ela continua de pé.