1. Definire il riferimento e il risultato atteso
Inizia da ciò che vuoi ripetere: produrre le stesse categorie, ottenere valori simili o riprendere una traiettoria di addestramento. Mantieni un piccolo set di input che attraversa le fasi importanti e un esempio di output valido. Un'installazione che termina senza errori non risponde ancora a questa domanda.
Prendiamo un caso didattico: la tua applicazione produce embedding per un campione identificato. Sull'ambiente di riferimento devi rilevare la forma degli output, il loro tipo, l'assenza di valori non finiti e il criterio di business utile. Se confronti dei valori, scegli una tolleranza giustificata dal tuo uso. Qui non viene fornita alcuna soglia numerica universale.
Assegna una revisione al codice, ai dati e ai pesi. Un nome come «ultimo-modello» può cambiare senza che il programma lo mostri. Associa anche i parametri e il preprocessing al riferimento. Questo fascicolo permette di sapere se una differenza deriva dal software, dagli input o dalle condizioni di esecuzione.
Scorri la tabella per leggere tutte le colonne.| Elemento | Da conservare | Controllo dopo la ricostruzione |
|---|---|---|
| Codice e parametri | Revisione, eventuali modifiche, configurazione | Stesso punto di ingresso e stesse opzioni. |
| Dati e pesi | Versione o impronta, provenienza e diritti di accesso | Stesso campione e stesso contenuto atteso. |
| Python e pacchetti | Versioni, procedura e fonti di installazione | Interprete corretto e dipendenze coerenti. |
| Sistema e backend | OS, architettura, driver, CUDA o ROCm | Dispositivo visibile e calcolo minimo riuscito. |
| Risultato | Formato e criteri di accettazione | Struttura poi qualità o tolleranza prevista. |
2. Separare la catena di sistema dai pacchetti Python
Verifica insieme scheda, sistema, driver, Python e librerie. Un ambiente virtuale organizza i pacchetti Python; non sostituisce il driver di sistema. Allo stesso modo, il riferimento di un'immagine non basta a descrivere l'accesso reale alla GPU dal suo host. Per un'estensione compilata, annota gli strumenti e le librerie di compilazione necessari.
Scegli la distribuzione PyTorch in base alla piattaforma di calcolo del tuo progetto. Su ROCm, PyTorch riutilizza le chiamate torch.cuda e i dispositivi denominati cuda: il nome dell'interfaccia non permette di identificare NVIDIA. Rileva separatamente torch.version.cuda e torch.version.hip. Un'estensione scritta per una determinata catena merita un proprio controllo.
Conserva la procedura che ha effettivamente consentito l'installazione, con l'origine dei pacchetti. Evita di mescolare un comando recente trovato online con un vecchio file di dipendenze senza esaminarne la compatibilità. La documentazione consultata può cambiare; annota le versioni utilizzate nel tuo fascicolo.
3. Scrivere una ricostruzione invece di copiare la cartella installata
Crea un nuovo ambiente con il Python scelto. Poi usa esplicitamente il suo interprete per installare e avviare il progetto. Su Linux sarà ad esempio .venv-rebuild/bin/python; su Windows, .venv-rebuild\Scripts\python.exe. Non devi dipendere da un'attivazione precedente. La documentazione Python precisa che un ambiente virtuale va ricreato quando cambia posizione.
pip freeze fornisce un inventario dei pacchetti installati, non un file di lock calcolato. Conservalo come osservazione. Il file di ricostruzione deve anche esplicitare gli indici o i file necessari alla tua variante di PyTorch e le versioni compatibili. Rileggi i percorsi o gli URL che un inventario potrebbe contenere prima di condividerlo.
I comandi seguenti illustrano una ricostruzione Linux da adattare; non costituiscono una prova eseguita del tuo progetto. Il file requirements-rebuild.txt deve già descrivere il tuo ambiente, incluso il corretto scelta di PyTorch. Non sostituirlo con un elenco di versioni presunte universali.
python -m venv .venv-rebuild
.venv-rebuild/bin/python -m pip --version
.venv-rebuild/bin/python -m pip install -r requirements-rebuild.txt
.venv-rebuild/bin/python -m pip check
.venv-rebuild/bin/python -m pip freeze --all > installed-after.txt4. Verificare il contratto delle dipendenze prima del calcolo
python -m pip check, avviato con l'interprete corretto, cerca dipendenze installate mancanti o incompatibili in base ai loro metadati. Un risultato senza conflitti non è una validazione del driver, delle estensioni native o della qualità dell'applicazione. Mantieni quindi questa fase breve e prosegui verso un controllo di calcolo.
Per rendere la ricostruzione più rigorosa, puoi fissare le versioni e conservare le impronte delle distribuzioni consentite. Questa decisione richiede di mantenere l'elenco completo che corrisponde alla tua piattaforma. Un archivio di wheel compilate può dipendere dall'OS e dall'architettura; non è una garanzia di portabilità tra due macchine diverse.
Nel nostro esempio di embeddings, confronta l'inventario ricostruito con il riferimento prima di modificare il modello o i suoi parametri. Se una differenza è intenzionale, annotala e tratta la nuova esecuzione come una variante. Altrimenti, correggi la ricostruzione; cambiare più livelli contemporaneamente renderà la diagnosi meno precisa.
5. Passare dal controllo minimo all'applicazione
Nell'interprete del progetto, rileva Python, PyTorch e il backend, poi verifica il dispositivo e un piccolo calcolo. Ferma questa fase se la GPU prevista non è accessibile; un'esecuzione CPU di riserva confonderebbe il confronto. La diagnostica Kernodeck fornisce un report interpretabile e distingue le fasi realmente superate.
Una volta superato questo controllo, usa il tuo piccolo campione applicativo. Per gli embeddings, verifica il numero di output, le loro dimensioni, la loro corrispondenza con gli identificatori e il criterio scelto. Ricarica i file dalla cartella di output. Un calcolo matriciale riuscito non dimostra che il preprocessing o un'estensione del progetto funzioni.
Se il test si blocca durante la lettura dei dati, il trasferimento o un'operazione specifica, conserva la fase e il primo errore. La ricostruzione generale potrebbe essere corretta; il blocco può appartenere al data loader o a un operatore particolare. Orienta quindi la diagnosi verso quello strato.
6. Distinguere ricostruzione e identità numerica
Ritrovare le stesse dipendenze non garantisce risultati identici tra hardware, piattaforme o versioni di PyTorch. Fissare un seed non copre tutte le fonti di variazione. Documenta i generatori utilizzati, le trasformazioni dei dati e le impostazioni di precisione o determinismo pertinenti.
Definisci il criterio di confronto prima di guardare la differenza: struttura esatta, tolleranza numerica o stabilità di una metrica. Alcune impostazioni deterministiche possono rifiutare operazioni o modificare il costo di calcolo. Il risultato ricercato è una conclusione comprensibile nelle condizioni dichiarate, non una promessa di identità su qualsiasi macchina.
Per una ripresa dell'addestramento, le versioni non bastano: occorre anche ripristinare lo stato di calcolo e l'avanzamento. La cartella di ripresa verifica questa questione separatamente. Il suo esercizio CPU e la sua tolleranza non diventano automaticamente le condizioni del tuo modello.
7. Concludere con una cartella che un altro avvio può utilizzare
La cartella finale riunisce la procedura, l'inventario osservato, la configurazione, i riferimenti dei dati e i risultati del controllo. Aggiungi la sequenza esatta: ricostruire, diagnosticare, eseguire il campione, rileggere l'output. Conserva gli accessi a parte e specifica solo come fornirli.
Riprendi questa sequenza in una cartella pulita prima di considerare l'ambiente trasmissibile. Il controllo deve riuscire senza recuperare una variabile da un vecchio notebook né cercare un file dimenticato. Se un cambiamento è necessario, correggi la procedura e dai una nuova identità al riferimento. Ottieni una base utilizzabile per il tuo prossimo periodo di calcolo.