CapordiaDelimitare ciò che migra e ciò che deve attendere
Questa guida si rivolge a chi coordina il calcolo, i dati e l'operatività. Qui un lotto indica un pacchetto di lavoro identificato, distinto da un lotto di schede GPU del catalogo. Il metodo è adatto innanzitutto alle uscite che possono essere controllate prima dell'accettazione. Per un servizio che riceve richieste senza sosta, prevedi dove attenderanno le nuove entrate, quanto tempo questa attesa è accettabile e come raggiungeranno la destinazione. Un dossier copiato non definisce da solo questa politica di ammissione.
L'esercizio proposto lavora su un insieme chiuso di otto lotti sintetici. Non invia alcuna richiesta di rete e non richiede né GPU né account Capordia. Insegna una logica di ripresa su un solo postazione e un solo processo di lavoro. Non convalida una coda distribuita, la continuità di un servizio esposto o lo spostamento a caldo di un calcolo. Prima di una migrazione reale, il tuo team deve qualificare questi elementi con l'applicazione e l'hardware scelti.
Costituire un inventario che permetta di ricostruire
Raccogli il codice e la sua versione, le dipendenze, i parametri, i modelli, gli input, le attività pianificate e le destinazioni di output. Per ciascuno, indica il proprietario, il metodo di ricostruzione e il controllo atteso sulla destinazione. Annota i nomi dei segreti e la loro modalità di fornitura, senza inserire il loro valore nel registro condiviso. Un'installazione manuale o un'attività attivata all'avvio può mancare in una semplice copia della directory del progetto.
Separa i file di input, i risultati accettati e lo stato necessario al riavvio. Per un addestramento, questo stato può superare i pesi del modello: il tutorial PyTorch sul salvataggio di un checkpoint generale comprende in particolare lo stato dell'ottimizzatore e l'avanzamento. Il contenuto richiesto dipende dal tuo codice. Ripristinalo in un processo nuovo, poi confronta le uscite secondo una tolleranza decisa prima della prova; non dedurre un'identità numerica universale da un solo riavvio riuscito.
Assegnare la decisione, il trasferimento e l'accettazione
Designa i ruoli prima di fissare la finestra. In una squadra piccola la stessa persona può ricoprirne diversi, ma le decisioni restano distinte. Il responsabile del passaggio conferma l'arresto del vecchio produttore e autorizza l'avvio della destinazione. Il responsabile dei dati controlla l'inventario, le impronte e gli output. Il proprietario dell'elaborazione valuta la qualità funzionale. L'esercizio conserva il registro delle modifiche e prepara la transizione.
La scheda di passaggio deve rispondere a quattro domande concrete: chi può fermare gli ingressi, chi constata che la vecchia elaborazione non pubblica più, chi accetta i primi risultati e chi decide il ritorno. Indica anche un'ora limite per la decisione e i mezzi per contattare queste persone. «Tornare se necessario» non basta quando la destinazione ha già prodotto risultati che il vecchio registro non conosce.
Tenere un registro che distingua iniziato e accettato
Assegna un identificatore stabile a ogni lotto e collegalo a una versione precisa dei dati. Conserva il suo stato, il numero di tentativi, la posizione del risultato e il controllo che ne autorizza l'accettazione. Un lotto in corso non è terminato solo perché esiste un file di output: quel file può essere parziale o provenire da un tentativo precedente. La procedura deve esplicitare ciò che sarà conservato, ciò che sarà ricalcolato e ciò che resterà in quarantena per esame.
Nell'esercizio, un registro SQLite locale tiene insieme lo stato e l'accettazione del risultato in una transazione. I suoi stati sono termine, en_cours e a_reprendre; quest'ultimo copre anche un lotto che non è ancora partito. La destinazione riprende i lotti non validati invece di rilanciare indistintamente gli otto ingressi. Le esportazioni JSON e CSV rendono leggibile il monitoraggio. Il CSV vuoto accompagna la tua preparazione e la tua revisione umana; non sostituisce il meccanismo di coordinamento di un'applicazione reale.
| Lotti | Stato al confine | Decisione prima della ripresa |
|---|---|---|
| LOT-001 a LOT-003 | termine | Conservare i risultati e verificarne l'integrità |
| LOT-004 | en_cours, risultato non accettato | Preparare esplicitamente un nuovo tentativo |
| LOT-005 a LOT-008 | a_reprendre, nessun tentativo | Avviare sulla destinazione dopo autorizzazione |
Scarica e avvia l'esercizio di interruzione e ripresa
Prevedi Python 3.10 o più recente con il modulo sqlite3, e una directory locale scrivibile. Scarica l'archivio completo ed estrailo mantenendo insieme lo script, la cartella dei dati e il manifest. Il file README dettaglia i comandi disponibili. Non occorre installare alcun driver, pacchetto di calcolo o modello. Leggi lo script prima di eseguirlo, poi usa una cartella di output nuova così che le prove di più tentativi non si mescolino.
Dalla directory che contiene exercice.py, il comando seguente produce un riferimento continuo, un'elaborazione interrotta, una copia di passaggio e una ripresa confrontata con il riferimento. Gli otto file CSV contengono 48 misurazioni dimensionali fittizie di provini, espresse in micrometri interi e create per questo dossier. Nessun controllo industriale reale è rappresentato. Il calcolo su CPU serve a esaminare la gestione dei lotti, non a stimare un throughput GPU o una durata di migrazione dei tuoi dati.
python exercice.py demonstration --dossier essai-capordiaLeggere le prove della ripresa, lotto per lotto
Esempio Capordia: una squadra prepara otto pacchetti di file da elaborare. Il riferimento li elabora senza interruzione. Sull'altro percorso, l'arresto lascia tre lotti terminati, LOT-004 in corso e quattro lotti da riprendere senza tentativo. Il responsabile del passaggio non chiede «riprendere a metà»: designa LOT-004. La preparazione della ripresa lo riporta allo stato a_reprendre: tre lotti sono allora terminati e cinque sono da eseguire. I lotti già accettati non devono essere ricalcolati.
Consulta etat.json per identificatori, stati e tentativi, registro-lotti.csv per la revisione, resultats.json per gli output, poi rapport-verification.json per i controlli. Durante l'esecuzione locale del 24 settembre 2026 su Windows AMD64, Python 3.14.6 e SQLite 3.50.4, i 16 controlli derivanti da 37 lanci dello script sono riusciti: gli otto risultati ripresi corrispondono al riferimento, i lotti completati non vengono ricalcolati e una nuova accettazione dello stesso lotto viene rifiutata. Vengono rilevati anche gli input alterati, gli identificatori duplicati e gli output corrotti.
Copiare uno stato coerente, poi controllarne l'integrità
In un passaggio reale, interrompi l'ammissione o metti i nuovi input in una coda esplicitamente prevista. Attendi la fine del lavoro in corso, oppure registra i lotti interrotti secondo la tua regola di ripresa. Conferma poi che la vecchia istanza non possa più pubblicare. Il sigillo della sorgente in questo esercizio impedisce allo script di riutilizzarla come produttore. Resta una protezione locale dello scenario, non un'esclusione reciproca tra più macchine che possiedano ciascuna una copia dello stato.
Per copiare un database SQLite utilizzato da un'applicazione, la sua documentazione propone un'API di backup che produce un'istantanea coerente. Una copia ordinaria di un file di database in fase di scrittura non è quindi una procedura da improvvisare. Verifica anche il manifesto dei file trasferiti. Gli hash SHA-256, disponibili in hashlib, aiutano qui a rilevare una differenza di contenuto; non dicono se il risultato è corretto per il tuo ambito, né se il manifesto di riferimento sia affidabile.
Decidere quando riprendere e quando tornare indietro
Autorizza la destinazione solo quando gli input, il registro e i risultati conservati concordano, il vecchio produttore è fermo e i prerequisiti software sono soddisfatti. Avvia prima un perimetro i cui output possano essere riletti. Il proprietario del trattamento accetta la qualità; il responsabile dei dati verifica gli identificatori, i mancanti e i duplicati. Un avvio senza errori non basta se il risultato utile è incompleto.
Se il difetto appare prima di qualsiasi nuova pubblicazione, mantieni la destinazione ferma e riparti dallo stato sorgente controllato secondo la procedura prevista. Dopo una pubblicazione, preserva prima i risultati e il registro della destinazione. Riavvicina i lotti che ha completato con quelli della sorgente, poi scegli un'unica ripresa autorizzata. Riattivare entrambi i lati per guadagnare tempo può creare proprio i duplicati che la migrazione doveva evitare.
| Osservazione | Decisione immediata | Condizione per proseguire |
|---|---|---|
| Input assente o hash diverso | Sospendere il trasferimento e isolare la copia | Recuperare un input conforme al manifesto di riferimento |
| Identificatore duplicato o output inatteso | Non pubblicare il lotto interessato | Comprendere il conflitto e trattenere una sola versione accettata |
| Stato di ripresa inutilizzabile | Arrestare la destinazione e conservare le prove | Ripristinare uno stato noto o applicare il ritorno preparato |
| Risultato fuori dal criterio di business | Arrestare l'ampliamento della ripresa | Correggere e poi rifare la validazione funzionale |
| Raggiunto l'orario limite di decisione | Attivare la decisione di ritorno o di rinvio | Accordo esplicito del responsabile e capacità di completare l'export |
Misurare l'intera finestra e preparare la consegna
Ripeti l'installazione, la copia, la verifica, la ripresa e l'export nel loro ordine reale. Annota il tempo di ogni fase e gli interventi umani, con un campione il cui trasferimento è autorizzato. Per stimare la tua finestra, tieni conto dei nuovi input che resteranno in attesa e della capacità di smaltire questo ritardo. Il miglior tempo osservato su una piccola cartella non è un impegno su un volume maggiore.
Il periodo scelto deve coprire preparazione, ripetizione, commutazione, osservazione e recupero dei risultati. I pacchetti Capordia da 3, 7 o 30 giorni restano periodi da organizzare; questa guida non ne deduce alcun tempo di calcolo. Prima della chiusura, una seconda persona deve ritrovare il registro, aprire gli output dalla loro destinazione e saper rilanciare l'elaborazione. Archivia la decisione di fine del ripristino, gli scostamenti accettati e le azioni rimanenti prima di rimuovere gli accessi diventati inutili.
Cosa verifica l'esercizio e cosa resta da qualificare
Il contributo di questo dossier è una procedura leggibile e un'esperienza riproducibile di ripresa su file sintetici. Lo stesso lotto deve essere identificabile prima dell'arresto, durante la commutazione e dopo la ripresa. Il registro, il confronto con un riferimento e i rifiuti provocati rendono osservabile questa regola. L'interruzione è attivata da un'eccezione controllata nello script: nessuna prova di guasto elettrico è stata eseguita. La documentazione tecnica citata spiega i meccanismi impiegati; non certifica il tuo futuro ambiente di produzione.
Nello scenario lavora un solo processo alla volta. Il sigillo locale non è un lock distribuito; un'impronta non è un test di qualità; un risultato CPU non è una qualificazione CUDA, ROCm o multi-GPU. Un'applicazione che scrive anche in un database esterno, in uno storage condiviso o in una coda richiede una regola coerente su tutte queste destinazioni. Fai validare questa regola e il tuo piano di ritorno prima di migrare l'elaborazione reale.
Per preparare il seguito
Un backup deve permettere di riprendere il lavoro.
Ripristinare in una destinazione isolata e verificare che la copia permetta davvero di riprendere.
Passare il testimone con uno stato, un'azione e un responsabile.
Trasmettere azioni, limiti e responsabilità a un'altra persona.