1. Scegliere il punto di partenza che corrisponde al progetto
Una base Ubuntu è adatta quando sai organizzare il tuo stack software e descrivere le sue dipendenze di sistema. Una preparazione PyTorch permette di segnalare il framework centrale del progetto. Blender indica un'esigenza di creazione o rendering. La preparazione personalizzata serve quando la tua applicazione ha già condizioni specifiche che queste etichette riassumono male.
Queste scelte non includono automaticamente il tuo codice, i tuoi pesi, i tuoi dati né le tue licenze. Scrivi ciò che deve essere disponibile, ciò che apporti tu e ciò che verificherai all'avvio. Il nome di una preparazione non deve esimerti dal controllare la versione effettivamente eseguita.
Una buona richiesta non consiste nell'elencare tutti gli strumenti conosciuti. Descrivi il percorso utile: leggere un input, caricare una risorsa, calcolare e poi scrivere un risultato. Questo aiuta a distinguere una dipendenza obbligatoria da uno strumento di comodo e a diagnosticare la fase mancante.
Scorri la tabella per leggere tutte le colonne.| Preparazione | Esigenza da descrivere | Controllo specifico del progetto |
|---|---|---|
| Ubuntu | Versione attesa e dipendenze di sistema indispensabili | Il tuo programma si avvia con le librerie necessarie. |
| PyTorch | Python, variante del framework ed estensioni | Import, calcolo sul backend e poi attività rappresentativa. |
| Blender | Versione, estensioni, risorse collegate e formato di esportazione | Progetto aperto e fase di elaborazione verificata. |
| Personalizzata | Procedura, versioni e file di riferimento | Ogni criterio del capitolato di preparazione è controllato. |
2. Scrivere un cahier di preparazione compatto
Per un progetto Python, distingui il sistema, l'interprete, i pacchetti e le risorse dell'applicazione. Mantieni le versioni esatte quando una dipendenza le richiede. Quando accetti un intervallo, spiega il controllo che permetterà di validarlo. «Installare le ultime versioni» è difficile da ricondurre a un ambiente di riferimento.
Esempio didattico: il tuo progetto classifica immagini con un'estensione nativa. La tua richiesta indica la versione di Python, la variante di PyTorch scelta, la revisione del progetto e i prerequisiti dell'estensione. Fornisce tre immagini di controllo autorizzate e descrive la forma di output attesa. Non dichiara throughput né memoria sufficiente senza una prova.
Il dossier di preparazione può restare breve: un README, un file delle dipendenze e una revisione del codice bastano se i passaggi e gli accessi sono chiari. Conserva i parametri modificabili in un file separato, così che una nuova dimensione del batch non trasformi la richiesta in un'altra installazione.
Obiettivo: classificare un piccolo campione di immagini
Codice: repository e revisione del progetto
Python: versione richiesta dall'applicazione
PyTorch: versione e variante CUDA o ROCm scelte
Estensioni: versioni, provenienza e prerequisiti di compilazione
Input: campione autorizzato e identificatori attesi
Controllo: output per identificatore, formato valido, risultato rileggibile
Fornitura degli accessi: procedura separata, senza segreti in questa scheda3. Esaminare le dipendenze specifiche di PyTorch
Verifica la catena di calcolo prima di moltiplicare i pacchetti. Il selettore ufficiale PyTorch permette di scegliere un'installazione in base alla piattaforma. CUDA e ROCm non sono due nomi intercambiabili dello stesso binario. Il framework principale può funzionare mentre un operatore specializzato o un'estensione del progetto resta incompatibile.
Se un'estensione deve essere compilata, la sua build può richiedere strumenti e librerie aggiuntive. La documentazione PyTorch precisa che l'installazione del pacchetto torch non fornisce automaticamente le toolchain necessarie a tutte le estensioni. Indica questi prerequisiti nella procedura; un comando di installazione che tenta di compilare non è un'anomalia da nascondere.
Pianifica tre controlli separati: import del framework, piccolo calcolo sul dispositivo e operazione che utilizza l'estensione. Se i primi due passano e il terzo fallisce, disponi di una diagnosi più precisa di un semplice «PyTorch non funziona». Annota il primo errore completo e le versioni coinvolte.
4. Scegliere come descrivere l'ambiente
Per i pacchetti Python, una procedura di ricostruzione con un ambiente virtuale è spesso una base semplice. Individua un interprete e separa le dipendenze del progetto. Non descrive l'intera macchina: mantieni i requisiti di sistema nel README e non presentare la copia di una directory installata come una procedura portabile.
Se il tuo progetto utilizza già un container, fornisci la sua ricetta, il suo riferimento e i parametri indispensabili all'avvio. Un tag può evolvere; un riferimento tramite digest identifica più precisamente una determinata immagine. Occorre comunque organizzare gli aggiornamenti e rivalidare il progetto. Il container non prova, da solo, l'accesso alla GPU o la presenza dei tuoi dati.
Scegli il meccanismo che sai mantenere. Un'immagine molto completa può nascondere dipendenze inutili; una ricetta troppo minimale può lasciare installazioni manuali fuori dal dossier. In entrambi i casi, il controllo applicativo resta il punto di confronto. Queste indicazioni descrivono la tua preparazione, senza presumere le modalità di fornitura di un'immagine da parte del servizio.
5. Preparare i notebook e i progetti grafici
Un notebook aiuta a esplorare i dati e a visualizzare un output. Il suo file e il processo che esegue le sue celle sono tuttavia distinti: le variabili di una vecchia sessione non costituiscono una dipendenza documentata. Prima del trasferimento, riavvia il kernel ed esegui le celle in ordine; annota la versione di Python utilizzata.
Quando la prova diventa un'elaborazione regolare, prepara un punto di ingresso che non richieda di manipolare le celle una per una. La guida dedicata al passaggio dal notebook allo script descrive questa trasformazione. La tua richiesta di preparazione deve identificare la necessità del notebook, senza confondere l'interfaccia di lavoro con un controllo riuscito del programma.
Per Blender o un altro software grafico, aggiungi le risorse correlate, le estensioni e la procedura di esportazione. Un progetto che si apre sul tuo computer può dipendere da file collocati altrove. Chiediti come un'altra macchina ritroverà ciascuno di essi e quale piccolo risultato permetterà di verificare la catena prima del lavoro completo.
6. Ricevere con criteri e un risultato riesaminato
Al momento della messa a disposizione, confronta le versioni osservate con la tua scheda. Avvia la diagnostica, poi il caso applicativo previsto. Per le tre immagini dell'esempio, controlla che ogni identificatore abbia un output, che le categorie siano valide e che i file prodotti possano essere riletti. Uno schermo senza errori non sostituisce questo bilancio.
Conserva gli scostamenti utili: versione diversa, estensione assente, input inaccessibile, output scritto altrove. Distingui ciò che impedisce di iniziare da ciò che richiede semplicemente un aggiornamento della documentazione. Per chiedere aiuto, allega il riferimento dell'ordine e un estratto minimo; non è necessario trasmettere tutto il tuo corpus.
Una preparazione validata per il campione non garantisce né la capacità di memoria né il comportamento di tutti i carichi futuri. Aumenta poi il volume con un obiettivo definito ed esamina il primo limite incontrato. Infine conserva la procedura corretta: diventa il tuo riferimento per il prossimo noleggio.