O que você vai executar
O mini-projeto Kernodeck contém um pequeno conjunto de dados sintéticos, uma rede com dropout, um loop de treinamento e um verificador. O protocolo força a CPU para isolar a lógica de sauvegarde e retomada. Ele não constitui uma qualificação CUDA, ROCm, multicartão ou uma medição de desempenho de uma GPU alugada.
O verificador abre processos novos para o percurso contínuo, a interrupção, a retomada completa e um caso negativo que não restaura os geradores aleatórios. O interesse deste último é verificar que o controle sabe detectar uma retomada incompleta, mesmo que os pesos e o número da etapa pareçam corretos.
Role a tabela para ler todas as colunas.| Percurso | Execução | Pergunta verificada |
|---|---|---|
| Contínuo | 10 atualizações desde o estado inicial. | Qual estado se alcança sem interrupção? |
| Interrupção | 5 atualizações, depois sauvegarde e parada. | O ponto intermediário contém os estados esperados? |
| Retomada completa | Novo processo, carregamento do ponto 5 e depois 5 atualizações. | Obtém-se a mesma sequência de entradas, de taxas e de parâmetros dentro da tolerância escolhida? |
| Retomada sem RNG | Novo processo, mesmo ponto de retomada, mas restauração da aleatoriedade omitida. | O teste detecta um desvio que um simples carregamento dos pesos deixaria passar? |
Pré-requisitos e início do protocolo
Baixe o arquivo, extraia-o em uma pasta de trabalho e depois entre na pasta que contém train.py e verify_resume.py. Use um ambiente Python com PyTorch e NumPy. O arquivo contém o código e os dados sintéticos; ele não baixa nenhum modelo e não exige uma conta Kernodeck para executar o exercício.
A prova fornecida foi executada com Python 3.14.6, PyTorch 2.11.0+cu128 e NumPy 2.4.4. O programa força a CPU, a precisão float64 e uma thread PyTorch. O sufixo do pacote, portanto, não significa que a retomada usou CUDA. Em outro ambiente, execute sua própria verificação.
Escolha um diretório de saída que ainda não exista. Cada percurso produz checkpoint.pt, sua impressão digital checkpoint.pt.sha256 e summary.json. O verificador reúne a comparação em verification.json. A opção --steps conta etapas adicionais: após a interrupção em 5, o comando de retomada executa 5 para chegar a 10. A opção Python -B evita os caches de bytecode na pasta do exercício.
python -B verify_resume.py --output runs/preuve-cpupython -B train.py --steps 10 --output runs/continu
python -B train.py --steps 5 --output runs/coupure
python -B train.py --steps 5 --resume runs/coupure/checkpoint.pt --output runs/repriseExportação de pesos e checkpoint de retomada não têm o mesmo papel
Comece escolhendo o que você quer recuperar. Uma exportação para inferência serve para produzir previsões com um modelo treinado. Uma retomada de treinamento também deve recuperar o estado que determina as próximas atualizações. Um processamento de inferência por arquivos exige, por sua vez, uma lista confiável dos elementos já concluídos. Essas três necessidades produzem sauvegardes diferentes.
Não confunda essa sauvegarde persistente com o activation checkpointing. Essa técnica reduz certas ativações mantidas na memória recalculando-as durante a retropropagação; ela não cria, por si só, um arquivo que permite retomar após uma parada. Portanto, especifique no seu projeto se a palavra checkpoint designa uma otimização de memória ou um ponto de retomada.
Os estados que devem ficar juntos
O state_dict do modelo contém os parâmetros e os buffers registrados; o otimizador tem seu próprio estado. Aqui, Adam, o StepLR, o dropout e três geradores aleatórios influenciam as próximas atualizações. O checkpoint deve representar o mesmo instante para todos esses elementos.
Documente também a versão do código, os parâmetros do experimento e a identidade dos dados. No meio de uma época, conhecer apenas o número dela não basta: é preciso conseguir recuperar a ordem dos exemplos e o próximo lote a consumir. Um erro nesse ponto pode pular entradas ou processá-las duas vezes.
O conjunto de 24 linhas descreve uma relação sintética entre duas variáveis e um alvo. A rede tem 33 parâmetros, com uma camada de oito neurônios e um dropout de 0,25. O batch contém quatro linhas. Após cinco atualizações, o cursor vale 20 de 24: a interrupção ocorre no meio de uma época. As dez atualizações consomem 40 observações, o que obriga a verificação a atravessar uma nova permutação dos dados.
Role a tabela para ler todas as colunas.| Estado | Função | Verificação a realizar |
|---|---|---|
| Modelo | Manter pesos e buffers. | Comparar os parâmetros finais e uma saída de avaliação. |
| Otimizador | Manter os estados usados pela próxima atualização. | Verificar seu recarregamento, não apenas seus hiperparâmetros. |
| Scheduler | Continuar a sequência das taxas de aprendizado. | Comparar a próxima taxa aplicada e depois as taxas seguintes. |
| RNG Python, NumPy e PyTorch | Continuar os sorteios efetivamente usados. | Verificar que o exercício negativo sem restauração diverge. |
| Dados | Retomar a permutação e o cursor. | Comparar os identificadores de entradas após a interrupção. |
| Progresso | Interpretar as etapas e as épocas. | Chegar a 10 atualizações no total, sem refazer nenhuma nem omitir. |
| Configuração | Reconstruir o mesmo experimento. | Manter dimensões, precisão, configurações e versões. |
Restaurar na ordem correta
Reconstrua o modelo, o otimizador e o scheduler antes de carregar seus estados. O scheduler deve ser criado antes de optimizer.load_state_dict(): sua construção pode, caso contrário, sobrescrever as taxas de aprendizado restauradas. Recarregue também seu próprio estado e depois verifique a taxa realmente usada na etapa seguinte.
Restaure os geradores aleatórios após a construção dos objetos que consomem sorteios, logo antes de continuar o trabalho. Apenas recolocar a semente inicial faria a sequência recomeçar do início; isso não é recuperar o estado alcançado após a quinta atualização. No seu projeto, localize todos os geradores usados, incluindo os das transformações e do carregamento dos dados.
Neste exercício, o Python ajusta um leve ganho sobre as entradas, um gerador NumPy PCG64 produz ruído e as permutações, e o PyTorch produz o dropout. O checkpoint mantém seus estados alcançados na interrupção. O verificador também observa seus próximos sorteios, restaurando imediatamente o estado para não perturbar a sequência do cálculo.
optimizer = torch.optim.Adam(model.parameters(), lr=0.03)
scheduler = torch.optim.lr_scheduler.StepLR(optimizer, step_size=3, gamma=0.5)
# No percurso de retomada, após a construção dos objetos:
state = load_checkpoint(resume)
model.load_state_dict(state["model"])
scheduler.load_state_dict(state["scheduler"])
optimizer.load_state_dict(state["optimizer"])
progress = state["progress"]
history = state["history"]
restore_rng(state["rng"], generator)
model.train()Escolher uma fronteira de salvamento coerente
Estabeleça uma fronteira explícita, por exemplo após uma atualização completa do otimizador. Se você acumular vários microbatches antes dessa atualização, salvar no meio exige gerenciar também o estado intermediário. Uma primeira implementação é mais fácil de verificar quando salva em uma fronteira onde os gradientes acumulados já foram consumidos.
Mantenha várias gerações de backup. Grave o novo arquivo com um nome distinto, aguarde o término da gravação, verifique se ele é legível e só então marque-o como utilizável. Não substitua seu único checkpoint válido antes dessa conferência. A frequência depende do trabalho que você aceita refazer e do tempo de gravação observado; ela não se deduz apenas da duração da locação.
O mini-projeto salva após uma iteração concluída, depois exporta o arquivo e sua impressão digital. Ele usa uma nova pasta para cada execução e não substitui uma prova anterior. Se o seu treinamento usa precisão mista com um GradScaler, o estado dele também faz parte da retomada. Essa variante não é coberta pelo exercício de CPU.
Ler a comparação e sua tolerância
O protocolo compara a continuação após o ponto 5: dados consumidos, taxa de aprendizado, perdas e parâmetros alcançados. Uma concordância apenas do número da etapa não basta. Um otimizador reinicializado pode continuar o loop produzindo atualizações diferentes.
A tolerância escolhida para este exercício é absoluta: 1e-12, com tolerância relativa de 0. Esse limiar faz parte do protocolo de CPU fornecido; ele não constitui uma regra universal para os seus modelos. A comparação deve sinalizar valores não finitos e diferenças de estrutura, em vez de aceitar silenciosamente uma saída inutilizável.
O PyTorch não garante identidade de resultados entre versões, plataformas, CPU e GPU. Se você portar o exercício, refaça a prova no destino e explique a tolerância adotada. Não amplie o limiar apenas para fazer desaparecer uma falha cuja origem você não entendeu.
Na prova fornecida, todos os desvios da execução completa valem zero: parâmetros, estado do otimizador, perdas, taxas e MSE. A ordem das linhas, a progressão, o estado do scheduler e os próximos sorteios também coincidem. A próxima taxa de aprendizado após a etapa 10 vale 0,00375 nas duas execuções. O resultado, portanto, não depende apenas de uma métrica final que poderia mascarar diferenças intermediárias.
Role a tabela para ler todas as colunas.| Comparação | Retomada completa | Retomada sem restauração de RNG |
|---|---|---|
| Desvio máximo dos pesos | 0 | 0,011669328447718508 |
| MSE final | 0,09538858591775097 | 0,0936034144665111 |
| Desvio de MSE em relação à execução contínua | 0 | 0,001785171451239867 |
| Veredito do subteste de concordância | Concordante dentro da tolerância de 1e-12 | Divergência detectada |
Por que manter o caso negativo sem aleatoriedade restaurada
Um controle é mais útil quando você sabe qual erro ele detecta. A variante negativa recarrega os mesmos pesos, estados de otimizador, scheduler e progressão, mas omite propositalmente a restauração de RNG. O processo pode terminar sem exceção Python enquanto segue outra trajetória.
Na prova fornecida, essa omissão produz um desvio máximo dos pesos superior a 0,011 e uma diferença de MSE superior a 0,0017. A MSE negativa aqui é mais baixa que a da execução contínua: isso não torna a retomada correta. O objetivo é recuperar a mesma experiência, não classificar dois modelos pelo erro final.
O verificador só passa quando a execução completa concorda e o caso negativo diverge. Ele então exibe all_checks_passed: true, positive: true e negative_divergence_detected: true. Seu código de saída vale 0 em caso de sucesso do protocolo, 1 se a comparação falhar e 2 se a verificação não puder ser concluída.
python -B train.py --steps 5 --resume runs/coupure/checkpoint.pt --omit-rng-restore --output runs/reprise-incompleteCarregar o arquivo do exercício sem afrouxar as proteções
O projeto carrega apenas o checkpoint que você criou com este exercício e manteve sob seu controle. Ele usa explicitamente torch.load(..., map_location="cpu", weights_only=True). O estado Python contém primitivas, o do gerador NumPy PCG64 contém inteiros e strings, e o do PyTorch CPU contém um tensor de bytes. Nenhum array NumPy arbitrário é colocado no estado de RNG salvo.
O carregador verifica a impressão digital associada, o tamanho, o esquema, o progresso, as versões, bem como a identidade do código e dos dados. Ele recusa um estado incoerente em vez de redefinir silenciosamente um elemento ausente. A impressão digital detecta uma modificação; ela não autentica o remetente de um arquivo.
Não adicione weights_only=False simplesmente para silenciar um erro de carregamento. O formato salvo e sua reconstrução devem ser coerentes. O carregamento restrito reduz as possibilidades de desserialização, mas não torna um arquivo desconhecido digno de confiança.
O que muda para um treinamento distribuído
Com vários processos ou estados distribuídos entre GPUs, verifique quem escreve o quê. Um arquivo produzido por um único processo não é necessariamente um backup completo do trabalho distribuído. Use o procedimento de backup previsto pela sua estratégia e aguarde sua conclusão nos participantes envolvidos. Identifique claramente os fragmentos que pertencem ao mesmo ponto de retomada.
Uma mudança no número de GPUs pode exigir uma redistribuição dos estados e modificar a distribuição dos dados. Os mecanismos de checkpoint distribuído podem lidar com algumas mudanças, mas essa possibilidade deve ser verificada para o seu formato e a sua configuração. Faça um teste de carregamento no destino previsto. Adicionar lotes ao pedido não converte automaticamente um backup de uma única placa em programa distribuído.
Terminar com uma exportação realmente recuperável
Antes do prazo, exporte os checkpoints úteis com sua configuração, as métricas, as instruções de carregamento e os identificadores dos dados. Verifique o tamanho e uma impressão digital dos arquivos copiados e, em seguida, carregue pelo menos um backup a partir do seu destino. Uma impressão digital idêntica controla a cópia; o recarregamento verifica se o conteúdo realmente basta para reconstruir o trabalho.
Carregue apenas arquivos cuja procedência você conhece e escolha um formato, bem como opções de desserialização, adequados. Mantenha o último ponto de retomada validado enquanto o novo não tiver passado pelos seus controles. A saída esperada é uma pasta recuperável e uma breve prova de retomada: comando executado, etapa recuperada, controle bem-sucedido e resultado exportado. Reserve esse tempo nos seus 3, 7 ou 30 dias.
Escopo da prova e escolha da locação
A prova de 24 de setembro de 2026 compara quatro processos novos em CPU, com uma tolerância absoluta de 1e-12 e nenhuma tolerância relativa. Ela não cobre CUDA, ROCm, AMP, treinamento distribuído nem workers de carregamento de dados. Ela valida a lógica de retomada da versão fornecida, no ambiente descrito, e não mede as capacidades de uma GPU alugada.
Após este pequeno exercício, transponha o mesmo protocolo para o seu modelo, seus dados e seu backend. Uma placa de 80 GB ou uma placa de 192 GB não corrige um checkpoint incompleto: escolha primeiro a cadeia compatível e depois dimensione a memória de uma etapa real. As ofertas vinculadas abaixo não são apresentadas como hardware testado para esta prova.
Reserve no seu período de 3, 7 ou 30 dias um primeiro ciclo de backup–parada–retomada e o tempo da exportação final. A saída útil é uma pasta cujas versões, ponto de retomada, controle comparativo e limites você consegue explicar; a mera existência de um arquivo .pt não oferece essa garantia.