1. Definire un risultato prima di scegliere la scheda
Scegli un campione che attraversa tutta la tua applicazione. Per l'inferenza, parti da alcuni input rappresentativi e da un formato di output atteso. Per l'adattamento di un modello, prevedi un'esecuzione breve che legge i dati, effettua un aggiornamento e scrive un checkpoint. L'obiettivo è verificare il percorso completo prima di affidargli il volume finale.
Facciamo un esempio didattico: vuoi classificare dei documenti. Prepara dodici documenti identificati, con lunghezze diverse e un caso che il programma deve rifiutare correttamente. Fissa le categorie ammesse e la destinazione dei risultati. I dodici identificatori dovranno comparire esattamente una volta nel riepilogo, con un risultato accettato o un errore esplicito. Questo scenario va adattato alla tua applicazione; non presuppone alcun modello o throughput particolare.
Scorri la tabella per leggere tutte le colonne.| Punto da verificare | Criterio preparato prima del lancio |
|---|---|
| Input | 12 identificatori univoci; file leggibili; un caso invalido previsto. |
| Risultati | Una categoria ammessa per documento accettato; nessun identificatore inventato. |
| Errori | Un motivo associato a ogni documento rifiutato; nessuna sparizione silenziosa. |
| Fine della prova | Accettati + rifiutati = 12; report e risultati riletti da una copia. |
2. Scegliere il backend, la memoria e il piano
Parti dalle librerie del progetto. Una dipendenza CUDA ti orienta verso una catena NVIDIA; un'offerta MI300X richiede di esaminare il supporto ROCm, in particolare quello delle estensioni. Il selettore ufficiale PyTorch distingue sistema e piattaforma di calcolo: copiare un comando da un'altra macchina non costituisce una verifica di compatibilità.
Poi confronta la memoria necessaria per un compito rappresentativo: pesi, input, calcoli intermedi e stati propri del tuo metodo. La dimensione del file del modello non basta. Se non conosci ancora il picco, mantieni questo punto come obiettivo del pilota, senza annunciare che un modello reggerà basandoti solo sul suo numero di parametri.
Scegli 3, 7 o 30 giorni e da 1 a 10 lotti. Un lotto contiene una scheda, tranne B200 che ne contiene due. Più schede non distribuiscono automaticamente il programma e non unificano la loro memoria. Prevedi nella durata l'installazione, i controlli, il calcolo e l'export; i dodici documenti del pilota servono a verificare la procedura, non a prevedere meccanicamente la durata dell'intera campagna.
3. Preparare una cartella che sopravvive al cambio di macchina
Raccogli la revisione del codice, le dipendenze, il riferimento dei dati e del modello, i parametri e il comando di avvio. Indica come fornire separatamente gli accessi necessari. Un percorso verso la tua directory personale non è una procedura di trasferimento: sostituisci le supposizioni implicite con dei parametri e verifica i percorsi dalla cartella del progetto.
La preparazione Ubuntu, PyTorch, Blender o personalizzata scelta nella configurazione esprime la tua esigenza. Non prova che il tuo progetto, le sue estensioni o le sue licenze siano già installati. Descrivi ciò che deve essere presente e poi controlla l'ambiente effettivamente ricevuto prima di iniziare l'elaborazione.
Per il nostro lotto di documenti, mantieni un input pilota immutabile, un file di parametri e una directory di risultati distinta per ogni prova. Scrivi anche come rileggere il riepilogo. Questa cartella non deve essere voluminosa; deve evitare che la riuscita dipenda da una cella dimenticata, da un terminale vecchio o da un file non copiato.
progetto/
README.md # installazione, avvio, controllo
requirements-rebuild.txt # dipendenze e provenienza documentate
config/pilote.json # parametri senza segreti
data/pilote/ # i 12 input ammessi
src/ # la tua applicazione
runs/ # una sottocartella per ogni prova4. Rileggere il comando e seguire i passaggi del servizio
Il riepilogo deve corrispondere alla tua scelta: modello, durata, lotti, numero totale di schede, preparazione e importo in USD. Il totale è il prezzo del lotto per la durata, moltiplicato per il numero di lotti. Il prezzo del lotto B200 include già le sue due schede: non moltiplicare una seconda volta per il numero di GPU.
Per un primo ordine, crea il tuo account con nome, cognome, email e password. Se hai già un account, accedi; se sei già connesso, i dati sono precompilati. L'account consente di ritrovare gli ordini e il saldo da un altro browser. Il percorso non richiede né procedura KYC né documento d'identità.
Per pagare in crypto, usa l'asset, la rete, l'indirizzo, l'importo e la scadenza mostrati per il pagamento in questione. Dopo il trasferimento, «Ho pagato» registra la tua segnalazione. Non conferma né la ricezione dei fondi né la messa a disposizione. Un saldo USD sufficiente può anche saldare integralmente la locazione. Segui poi le informazioni di preparazione e gli accessi effettivamente comunicati.
5. Controllare il lancio prima del volume finale
Quando la risorsa è messa a disposizione, identifica l'interprete realmente utilizzato e l'ambiente caricato. Avvia la diagnostica minima prima della tua applicazione. Un import PyTorch riuscito non dimostra un calcolo GPU; un calcolo semplice riuscito non convalida tutte le estensioni del modello. La cartella di diagnostica descrive questa progressione e fornisce una risorsa scaricabile.
Esegui poi il tuo pilota in una directory di output nuova. Per i documenti, verifica gli identificatori, le categorie, il numero di successi e i rifiuti attesi. Esamina diversi risultati con i loro input: un output sintatticamente valido può restare errato per l'uso. Passa al corpus completo solo dopo aver scritto ciò che è stato accettato e ciò che resta da correggere.
Se il lancio fallisce, annota il primo errore e il passaggio raggiunto. Verifica l'interprete prima di reinstallare; i percorsi prima di ricopiare; la dimensione degli input prima di aumentare il batch. Cambia un fattore alla volta. Se il processo dura a lungo, organizza il suo monitoraggio separatamente dalla connessione interattiva usata per avviarlo.
6. Recuperare una prova utilizzabile e decidere il seguito
Copia i risultati e il loro bilancio in una posizione che controlli, poi rileggi questa copia. Verifica che contenga i parametri e i riferimenti necessari per comprendere il risultato. Non considerare un file presente nell'ambiente di calcolo come il tuo unico backup. Fai questo controllo durante il pilota, senza aspettare la scadenza della locazione.
Per un addestramento, aggiungi un test di ripresa in un nuovo processo. Il mini-progetto Kernodeck dimostra un metodo su CPU; la tua applicazione deve ancora qualificare i propri stati, la precisione e i dati. Per i documenti indipendenti, la ripresa consiste piuttosto nell'identificare gli elementi completati e quelli da rielaborare.
La tua decisione finale può essere di avviare il volume previsto, di correggere l'ambiente o di rivedere la configurazione. Conserva questa decisione con la sua motivazione. Un pilota che rivela un'incompatibilità è utile: trasforma un problema vago in una condizione precisa da risolvere prima di impegnare ulteriore calcolo.