Cosa eseguirai
Il mini-progetto Kernodeck contiene un piccolo dataset sintetico, una rete con dropout, un ciclo di addestramento e un verificatore. Il protocollo forza la CPU per isolare la logica di salvataggio e ripresa. Non costituisce una qualificazione CUDA, ROCm, multi-GPU né una misura di prestazioni di una GPU a noleggio.
Il verificatore apre processi nuovi per il percorso continuo, l'interruzione, la ripresa completa e un caso negativo che non ripristina i generatori casuali. L'interesse di quest'ultimo è verificare che il controllo sappia rilevare una ripresa incompleta, anche se i pesi e il numero di passo sembrano corretti.
Scorri la tabella per leggere tutte le colonne.| Percorso | Esecuzione | Domanda verificata |
|---|---|---|
| Continuo | 10 aggiornamenti dallo stato iniziale. | Quale stato si raggiunge senza interruzione? |
| Interruzione | 5 aggiornamenti, poi salvataggio e arresto. | Il punto intermedio contiene gli stati attesi? |
| Ripresa completa | Nuovo processo, caricamento del punto 5, poi 5 aggiornamenti. | Si ottiene la stessa sequenza di input, tassi e parametri entro la tolleranza scelta? |
| Ripresa senza RNG | Nuovo processo, stesso punto di ripresa ma ripristino della casualità omesso. | Il test rileva una deriva che un semplice caricamento dei pesi lascerebbe passare? |
Prerequisiti e avvio del protocollo
Scarica l'archivio, estrailo in una cartella di lavoro, poi posizionati nella cartella contenente train.py e verify_resume.py. Usa un ambiente Python con PyTorch e NumPy. L'archivio contiene il codice e i dati sintetici; non scarica alcun modello e non richiede un account Kernodeck per eseguire l'esercizio.
La prova fornita è stata eseguita con Python 3.14.6, PyTorch 2.11.0+cu128 e NumPy 2.4.4. Il programma forza la CPU, la precisione float64 e un thread PyTorch. Il suffisso del pacchetto non significa quindi che la ripresa abbia usato CUDA. Su un altro ambiente, esegui la tua verifica.
Scegli una directory di output che non esiste ancora. Ogni percorso produce checkpoint.pt, la sua impronta checkpoint.pt.sha256 e summary.json. Il verificatore raccoglie il confronto in verification.json. L'opzione --steps conta passi aggiuntivi: dopo l'interruzione a 5, il comando di ripresa ne esegue 5 per arrivare a 10. L'opzione Python -B evita le cache di bytecode nella cartella dell'esercizio.
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/repriseExport dei pesi e checkpoint di ripresa non hanno lo stesso ruolo
Inizia scegliendo cosa vuoi ritrovare. Un export per l'inferenza serve a produrre previsioni con un modello addestrato. Una ripresa di addestramento deve ritrovare anche lo stato che determina gli aggiornamenti successivi. Un'elaborazione di inferenza su file richiede invece un elenco affidabile degli elementi già completati. Queste tre esigenze producono salvataggi diversi.
Non confondere questo salvataggio persistente con l'activation checkpointing. Questa tecnica riduce alcune attivazioni mantenute in memoria ricalcolandole durante la retropropagazione; da sola non crea un file che permetta di riprendere dopo un arresto. Specifica quindi nel tuo progetto se la parola checkpoint indica un'ottimizzazione di memoria o un punto di ripresa.
Gli stati da tenere insieme
Il state_dict del modello contiene i parametri e i buffer registrati; l'ottimizzatore ha un proprio stato. Qui Adam, StepLR, il dropout e tre generatori casuali influenzano i prossimi aggiornamenti. Il checkpoint deve rappresentare lo stesso istante per tutti questi elementi.
Documenta anche la versione del codice, i parametri dell'esperimento e l'identità dei dati. A metà di un'epoca, conoscere solo il suo numero non basta: bisogna poter ritrovare l'ordine degli esempi e il prossimo gruppo da consumare. Un errore in questo punto può saltare delle voci o trattarle due volte.
Il set di 24 righe descrive una relazione sintetica tra due variabili e una variabile target. La rete conta 33 parametri, con uno strato di otto neuroni e un dropout di 0,25. Il batch contiene quattro righe. Dopo cinque aggiornamenti, il cursore vale 20 su 24: la cesura cade a metà di un'epoca. I dieci aggiornamenti consumano 40 osservazioni, il che obbliga il controllo ad attraversare una nuova permutazione dei dati.
Scorri la tabella per leggere tutte le colonne.| Stato | Ruolo | Controllo da eseguire |
|---|---|---|
| Modello | Conservare pesi e buffer. | Confrontare i parametri finali e un output di valutazione. |
| Ottimizzatore | Conservare gli stati usati dal prossimo aggiornamento. | Verificare il suo ricaricamento, non solo i suoi iperparametri. |
| Scheduler | Continuare la sequenza dei tassi di apprendimento. | Confrontare il prossimo tasso applicato e poi quelli successivi. |
| RNG Python, NumPy e PyTorch | Continuare le estrazioni effettivamente utilizzate. | Verificare che l'esercizio negativo senza ripristino diverga. |
| Dati | Riprendere la permutazione e il cursore. | Confrontare gli identificatori delle voci dopo la cesura. |
| Avanzamento | Interpretare le step e le epoche. | Arrivare a 10 aggiornamenti in totale, senza rifarne o ometterne. |
| Configurazione | Ricostruire lo stesso esperimento. | Conservare dimensioni, precisione, impostazioni e versioni. |
Ripristinare nell'ordine giusto
Ricostruisci il modello, l'ottimizzatore e lo scheduler prima di caricare i loro stati. Lo scheduler deve essere creato prima di optimizer.load_state_dict(): la sua costruzione può altrimenti sovrascrivere i tassi di apprendimento ripristinati. Ricarica anche il suo stato, poi verifica il tasso effettivamente utilizzato allo step successivo.
Ripristina i generatori casuali dopo la costruzione degli oggetti che consumano estrazioni, subito prima di continuare il lavoro. Rimettere semplicemente il seed iniziale farebbe ripartire la sequenza dall'inizio; non è ritrovare lo stato raggiunto dopo il quinto aggiornamento. Nel tuo progetto, individua tutti i generatori utilizzati, compresi quelli delle trasformazioni e del caricamento dei dati.
In questo esercizio, Python regola un leggero guadagno sugli input, un generatore NumPy PCG64 produce rumore e le permutazioni, e PyTorch produce il dropout. Il checkpoint conserva i loro stati raggiunti alla cesura. Il verificatore osserva anche le loro prossime estrazioni, ripristinando immediatamente lo stato per non disturbare il seguito del calcolo.
optimizer = torch.optim.Adam(model.parameters(), lr=0.03)
scheduler = torch.optim.lr_scheduler.StepLR(optimizer, step_size=3, gamma=0.5)
# Nel percorso di ripresa, dopo la costruzione degli oggetti:
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()Scegliere una frontiera di salvataggio coerente
Fissa una frontiera esplicita, per esempio dopo un aggiornamento completo dell'ottimizzatore. Se accumuli più microbatch prima di questo aggiornamento, salvare a metà impone di gestire anche lo stato intermedio. Una prima implementazione è più facile da verificare quando salva a una frontiera in cui i gradienti accumulati sono già stati consumati.
Conserva più generazioni di backup. Scrivi il nuovo file con un nome distinto, attendi la fine della scrittura, verifica che sia leggibile, poi contrassegnalo come utilizzabile. Non sostituire il tuo unico checkpoint valido prima di questo controllo. La frequenza dipende dal lavoro che accetti di rifare e dal tempo di scrittura osservato; non si deduce soltanto dalla durata del noleggio.
Il mini-progetto salva dopo un'iterazione completata, poi esporta il file e la sua impronta. Usa una nuova cartella per ogni percorso e non sostituisce una prova precedente. Se il tuo addestramento impiega la precisione mista con un GradScaler, anche il suo stato fa parte della ripresa. Questa variante non è coperta dall'esercizio CPU.
Leggere il confronto e la sua tolleranza
Il protocollo confronta la continuazione dopo il punto 5: dati consumati, tasso di apprendimento, perdite e parametri raggiunti. Una concordanza del solo numero di step non basta. Un ottimizzatore reimpostato può proseguire il ciclo producendo aggiornamenti diversi.
La tolleranza scelta per questo esercizio è assoluta: 1e-12, con una tolleranza relativa di 0. Questa soglia fa parte del protocollo CPU fornito; non costituisce una regola universale per i tuoi modelli. Il confronto deve segnalare valori non finiti e differenze di struttura, invece di accettare silenziosamente un output inutilizzabile.
PyTorch non garantisce l'identità dei risultati tra versioni, piattaforme, CPU e GPU. Se porti l'esercizio, rifai la prova sulla destinazione e spiega la tolleranza adottata. Non ampliare la soglia semplicemente per far sparire un fallimento di cui non hai capito l'origine.
Nella prova fornita, tutti gli scarti del percorso completo valgono zero: parametri, stato dell'ottimizzatore, perdite, tassi e MSE. Anche l'ordine delle righe, la progressione, lo stato dello scheduler e i successivi sorteggi coincidono. Il prossimo tasso di apprendimento dopo lo step 10 vale 0,00375 in entrambi i percorsi. Il risultato non dipende quindi soltanto da una metrica finale che potrebbe mascherare differenze intermedie.
Scorri la tabella per leggere tutte le colonne.| Confronto | Ripresa completa | Ripresa senza ripristino RNG |
|---|---|---|
| Scarto massimo dei pesi | 0 | 0,011669328447718508 |
| MSE finale | 0,09538858591775097 | 0,0936034144665111 |
| Scarto di MSE rispetto al percorso continuo | 0 | 0,001785171451239867 |
| Verdetto del sotto-test di concordanza | Concordante nella tolleranza di 1e-12 | Divergenza rilevata |
Perché conservare il caso negativo senza casualità ripristinata
Un controllo è più utile quando sai quale errore rileva. La variante negativa ricarica gli stessi pesi, stati dell'ottimizzatore, scheduler e progressione, ma omette volontariamente il ripristino RNG. Il processo può terminare senza eccezioni Python pur proseguendo su un'altra traiettoria.
Nella prova fornita, questa omissione produce uno scarto massimo dei pesi superiore a 0,011 e una differenza di MSE superiore a 0,0017. La MSE negativa qui è più bassa di quella del percorso continuo: ciò non rende corretta la ripresa. Lo scopo è ritrovare la stessa esperienza, non classificare due modelli in base al loro errore finale.
Il verificatore riesce solo quando il percorso completo concorda e il caso negativo diverge. Mostra allora all_checks_passed: true, positive: true e negative_divergence_detected: true. Il suo codice di uscita vale 0 se il protocollo riesce, 1 se il confronto fallisce e 2 se la verifica non ha potuto essere completata.
python -B train.py --steps 5 --resume runs/coupure/checkpoint.pt --omit-rng-restore --output runs/reprise-incompleteCaricare il file dell'esercizio senza allentare le protezioni
Il progetto carica unicamente il checkpoint che hai creato con questo esercizio e conservato sotto il tuo controllo. Usa esplicitamente torch.load(..., map_location="cpu", weights_only=True). Lo stato Python contiene primitive, quello del generatore NumPy PCG64 contiene interi e stringhe, e quello di PyTorch CPU contiene un tensore di byte. Nessun array NumPy arbitrario è inserito nello stato RNG salvato.
Il loader verifica l'impronta associata, la dimensione, lo schema, la progressione, le versioni nonché l'identità del codice e dei dati. Rifiuta uno stato incoerente invece di reimpostare silenziosamente un elemento mancante. L'impronta rileva una modifica; non autentica il mittente di un file.
Non aggiungere weights_only=False semplicemente per far tacere un errore di caricamento. Il formato salvato e la sua ricostruzione devono essere coerenti. Il caricamento limitato riduce le possibilità di deserializzazione, ma non rende affidabile un file sconosciuto.
Cosa cambia per un addestramento distribuito
Con più processi o stati distribuiti tra GPU, verifica chi scrive cosa. Un file prodotto da un solo processo non è necessariamente un backup completo del lavoro distribuito. Usa la procedura di backup prevista dalla tua strategia e attendine il completamento sui partecipanti interessati. Identifica chiaramente i frammenti che appartengono allo stesso punto di ripresa.
Un cambiamento del numero di GPU può richiedere una ridistribuzione degli stati e modificare la ripartizione dei dati. I meccanismi di checkpoint distribuito possono gestire alcune modifiche, ma questa possibilità va verificata per il tuo formato e la tua configurazione. Fai una prova di caricamento sulla destinazione prevista. Aggiungere batch all'ordine non converte automaticamente un backup single-GPU in un programma distribuito.
Concludere con un export realmente recuperabile
Prima della scadenza, esporta i checkpoint utili con la loro configurazione, le metriche, le istruzioni di caricamento e gli identificatori dei dati. Verifica la dimensione e un'impronta dei file copiati, poi carica almeno un backup dalla sua destinazione. Un'impronta identica controlla la copia; il ricaricamento verifica che il contenuto basti davvero a ricostruire il lavoro.
Carica solo file di cui conosci la provenienza e scegli un formato e opzioni di deserializzazione adeguati. Mantieni l'ultimo punto di ripresa convalidato finché il nuovo non ha superato i tuoi controlli. L'output atteso è una cartella recuperabile e una breve prova di ripresa: comando eseguito, step ritrovato, controllo superato e risultato esportato. Prevedi questo tempo nei tuoi 3, 7 o 30 giorni.
Perimetro della prova e scelta del noleggio
La prova del 24 settembre 2026 confronta quattro processi nuovi su CPU, con una tolleranza assoluta di 1e-12 e nessuna tolleranza relativa. Non copre né CUDA, né ROCm, né AMP, né l'addestramento distribuito, né i worker di caricamento dei dati. Convalida la logica di ripresa della versione fornita, nell'ambiente descritto, e non misura le capacità di una GPU noleggiata.
Dopo questo piccolo esercizio, trasponi lo stesso protocollo al tuo modello, ai tuoi dati e al tuo backend. Una scheda da 80 GB o una scheda da 192 GB non corregge un checkpoint incompleto: scegli prima la catena compatibile, poi dimensiona la memoria di uno step reale. Le offerte linkate di seguito non sono presentate come hardware testato per questa prova.
Prevedi nel tuo periodo di 3, 7 o 30 giorni un primo ciclo backup–arresto–ripresa e il tempo dell'export finale. L'output utile è una cartella di cui puoi spiegare le versioni, il punto di ripresa, il controllo comparativo e i limiti; la sola esistenza di un file .pt non dà questa garanzia.