Preparare la decisione prima della messa a disposizione
Parti da un'unità di lavoro conclusa: un dossier arricchito ed esportato, un lotto di rendering aperto dal suo destinatario o una valutazione accompagnata dai suoi output. Scrivi il criterio di business accanto al criterio tecnico. Un programma può terminare senza errori e produrre risultati inutilizzabili. Al contrario, un risultato corretto ottenuto una sola volta non dimostra ancora che la squadra sappia riavviare il lavoro e recuperare i propri file.
Conserva i parametri che influenzano il carico: volume degli input, precisione, dimensione dei batch, concorrenza e dipendenze. Distingui una coda di lavori indipendenti, un'attività che distribuisce il calcolo su più schede e un servizio che riceve richieste in modo continuo. Queste tre organizzazioni non hanno gli stessi criteri di accettazione. Una voce "GPU potente" non offre a nessuno un modo per decidere.
Il responsabile del progetto fissa i criteri prima delle prove. L'operatore prepara gli accessi, il responsabile applicativo fornisce il comando di avvio noto e il destinatario convalida gli output. Una stessa persona può ricoprire più ruoli; ogni ruolo deve comunque avere un titolare e un sostituto. Riserva nel periodo scelto l'installazione, le prove, una possibile correzione e l'esportazione finale, oltre al calcolo utile.
Separare produttore, allocazione e attività reale
La scheda di una GPU descrive un hardware di riferimento. La macchina allocata apporta altre proprietà: numero di periferiche visibili, accessi concessi, versioni software, volumi e percorsi utilizzabili. L'attività di riferimento apporta un terzo livello: il risultato ottenuto con i tuoi dati e le tue impostazioni. Nella griglia, assegna ogni riga a un solo livello per evitare che una caratteristica del produttore venga trattata come una misura del tuo servizio.
Non dedurre né NVLink, né una topologia particolare, né un throughput del disco dal solo modello di scheda. Se la tua applicazione dipende da queste proprietà, trasformale in requisiti espliciti, fai precisare il perimetro e poi controllalo sulla destinazione. Se non sono necessarie al tuo carico, non aggiungerle come condizioni di accettazione artificiose.
La memoria per GPU e il numero di schede restano due colonne diverse. Un lotto B200 presso Capordia comprende due GPU; questo non basta ad attribuire una memoria unica a un programma previsto per una sola scheda. Documenta il meccanismo di ripartizione del software prima di aspettarti un beneficio.
| Livello | Domanda affrontata | Prova da conservare | Cosa questo non dimostra |
|---|---|---|---|
| Riferimento del produttore | Il modello appartiene alla famiglia prevista? | Pagina ufficiale, variante e data di consultazione | La topologia e le risorse della macchina allocata |
| Ambiente allocato | Cosa può effettivamente utilizzare la mia applicazione? | Inventario datato, versioni, diritti e volumi controllati | La qualità o i tempi della mia attività |
| Attività rappresentativa | Il lavoro previsto è accettabile qui? | Input identificati, comando, output e convalida di business | Il comportamento di tutti i carichi futuri |
Stabilire l'inventario senza modificare le impostazioni
Su NVIDIA, i comandi seguenti rilevano la versione dello strumento, l'elenco delle GPU e alcuni attributi in formato CSV. Consulta prima la guida installata: i campi e le funzioni disponibili dipendono dalla versione. La documentazione NVIDIA consiglia identificatori come l'UUID per tracciare una periferica, poiché l'ordine degli indici può cambiare. Conserva le unità scritte dallo strumento. Questi rilevamenti non avviano un'attività GPU e non ne qualificano le prestazioni.
Per AMD, rileva la versione con "amd-smi version", poi l'inventario e le proprietà statiche con "amd-smi list --json" e "amd-smi static --json". Verifica le opzioni tramite la guida della tua installazione. AMD SMI presuppone una GPU AMD e il suo driver; la documentazione consultata è quella di AMD SMI 27.0.0. Un campo non disponibile deve restare "non stabilito", con la sua motivazione, piuttosto che ricevere un valore ipotizzato.
Archivia poi le versioni dell'applicazione e delle sue librerie. Il banner CUDA di NVIDIA SMI non prova da solo la versione del toolkit installato. Per ROCm, confronta la combinazione GPU, sistema e versione con la matrice corrispondente. In entrambi i casi, il test decisivo resta l'avvio della tua applicazione nell'ambiente effettivamente previsto.
Il file fornisce i comandi NVIDIA e AMD da eseguire sulla tua macchina, e poi da allegare al verbale. Si basano sulle documentazioni ufficiali; nessun risultato CUDA o ROCm è stato misurato in questo esempio. Il file di comandi scaricabile riprende entrambi i rami e i campi da allegare al verbale.
nvidia-smi --version
nvidia-smi --help-query-gpu
nvidia-smi -L
nvidia-smi --query-gpu=index,name,uuid,memory.total --format=csvTrasformare ogni requisito in un controllo osservabile
Una buona riga di accettazione collega un criterio, un metodo e un documento giustificativo. "Spazio di archiviazione sufficiente" diventa ad esempio: posizione di lavoro identificata, spazio disponibile rilevato prima dell'avvio ed export aperto dalla sua destinazione. La quantità necessaria è quella del tuo lavoro, compresi i file intermedi; questa guida non presume una capacità di disco associata a ciascuna GPU.
Fissa le unità prima di confrontare due rilevazioni. Un GB decimale vale un miliardo di byte; un GiB vale 2 alla 30 byte. Gli strumenti possono mostrare le notazioni inglesi GB e GiB, o MiB per un'unità più piccola. Conserva il valore grezzo e la sua unità, poi indica l'eventuale conversione. Non scartare una configurazione per la sola differenza di notazione tra una scheda e una rilevazione.
Per la rete, testa il flusso del progetto: stessa destinazione, stessi permessi e tipo di file rappresentativo. Un singolo download non qualifica l'export di migliaia di piccoli risultati. Misura e documenta il trasferimento in entrambe le direzioni se il progetto lo utilizza, poi annota la soglia che il tuo calendario richiede. Senza una soglia decisa prima della prova, una durata osservata resta un'osservazione.
Lo stato "non eseguito" vale più di un successo senza prova. La griglia CSV lascia vuote le colonne di osservazione, data e prova. Puoi eliminare un controllo fuori ambito solo spiegando perché e conservando l'accordo del decisore.
| Controllo | Criterio da scrivere | Prova attesa |
|---|---|---|
| Hardware accessibile | Modello e numero di dispositivi concordati | Inventario dall'ambiente dell'applicazione |
| Compatibilità | Applicazione e dipendenze identificate | Versioni e avvio completo |
| Memoria GPU | Carico e concorrenza definiti, senza errori di memoria | Rilevazione con unità, metodo e ambito di misura |
| Archiviazione | Input, intermedi ed export coperti | Spazio rilevato e file riletto a destinazione |
| Flusso di rete | Destinazioni e tempo massimo del progetto | Metodo di trasferimento, volume, durata e controllo di integrità |
| Risultato di business | Output e tolleranze fissati prima del test | Resoconto del responsabile dei risultati |
Rendere il task di riferimento un passaggio di consegne
Scegli un campione autorizzato che faccia emergere i vincoli del lavoro reale. Una dimostrazione minuscola è utile per verificare l'avvio; non sostituisce un caso che riveli il picco di memoria, i file intermedi o l'export finale. Annota l'identificativo del set di prova, le versioni e la configurazione. La cartella condivisa fa riferimento al metodo di fornitura dei segreti senza registrarne il valore.
Il responsabile applicativo esegue un ciclo completo da un avvio noto fino all'apertura degli output. L'operatore rifà poi il percorso a partire dalla procedura, senza dipendere da uno stato nascosto nel terminale del primo operatore. L'obiettivo è verificare un passaggio di consegne utilizzabile: percorsi, permessi, avvio, posizione dei log e recupero.
Definisci anche cosa succede dopo un errore controllato. Un output temporaneo deve poter essere distinto da un risultato accettato. Il dossier di accettazione non deve inventare un meccanismo di ripresa che l'applicazione non possiede: constata quello che esiste e rinvia alla procedura di migrazione per organizzare i lotti interrotti. Se il calcolo è numerico, la tolleranza appartiene al protocollo di business; l'identità bit a bit non è un requisito universale.
Quando confronti più configurazioni, mantieni questo protocollo costante. Annota anche gli errori e le prove da rifare. La decisione finale può preferire un'opzione perché semplifica la coda di lavoro, l'accettazione o il calendario; non ha bisogno di trasformare una singola rilevazione in una classifica generale delle GPU.
Leggere un esempio compilato senza scambiarlo per una misura
L'esempio scaricabile «Officina dei piani» è interamente fittizio. Un team vuole elaborare un corpus di prova di dodici documenti tecnici e poi recuperare un indice consultabile dai revisori. I dodici documenti sono un'ipotesi organizzativa; non vengono fornite velocità, consumo di memoria o misurazioni GPU. La target H100 è una candidata di inquadramento, da confermare dopo l'esame del software e del carico.
Il responsabile applicativo prepara il lancio e le credenziali previste. L'esercizio controlla gli accessi e il ritorno dei file. La persona incaricata dei risultati deve confermare che ogni documento abbia un output leggibile e un riferimento nell'indice. In questo scenario, non ha ancora potuto aprire l'export dalla propria destinazione. Le righe hardware e applicative restano non eseguite; la decisione fittizia è quindi «messa in servizio bloccata».
Questo esempio mostra come assegnare le responsabilità e prendere una decisione spiegabile senza fabbricare un successo. L'assenza di una prova di export non è una semplice nota a margine: blocca precisamente l'uso che richiede risultati recuperabili. Il nuovo tentativo dovrà riprendere questo controllo, allegare il relativo documento e far datare la decisione. Non basta cancellare il commento nella griglia.
| Punto | Stato dello scenario | Decisione |
|---|---|---|
| Input | Dodici identificatori previsti definiti, per ipotesi | Preparare il manifesto prima della prova |
| Hardware e software | Prove non eseguite | Nessuna conformità affermata |
| Export finale | Destinazione prevista, revisione non effettuata | Bloccare la messa in servizio |
| Decisore | Responsabile di progetto designato per ruolo | Rivedere i documenti prima di firmare |
Rifiutare, accettare con riserva o rinviare la decisione
Un criterio bloccante non soddisfatto interrompe il collaudo del perimetro interessato. Un controllo impossibile non diventa superato per impostazione predefinita: produce uno stato «bloccato» o «non eseguito», un'azione e un responsabile. Evita di usare «riserva» per mascherare un prerequisito del lavoro. Se un output non può essere recuperato, accettare il solo calcolo non autorizza l'intera catena.
Una riserva può essere adeguata per un punto secondario se l'uso autorizzato è chiaramente limitato, se una soluzione temporanea è verificata e se qualcuno accetta questo perimetro. Indica una scadenza di ricontrollo e cosa accadrà se non verrà rispettata. Un collaudo limitato a una prova non equivale al collaudo della produzione.
Il verbale conserva la decisione, i controlli che la giustificano e quelli che restano aperti. L'accettazione tecnica non conferma né un pagamento né una data contrattuale: tali monitoraggi mantengono i propri riferimenti. Una volta raggiunti i criteri, il team consegna all'esercizio il lancio, le versioni, le ubicazioni dei dati e la procedura di uscita.
| Riscontro | Stato consigliato | Seguito e responsabile |
|---|---|---|
| Modello o quantità non conformi al perimetro concordato | Rifiuto del perimetro | Far chiarire l'allocazione dal responsabile del progetto |
| Applicazione indispensabile non eseguibile | Bloccato | Responsabile applicativo: diagnosticare e poi ripetere il ciclo |
| Output assenti, illeggibili o fuori tolleranza | Rifiuto dell'attività | Responsabile dei risultati: isolare gli output e qualificare lo scostamento |
| Export o ripresa non verificati pur essendo richiesti | Bloccato | Esercizio: eseguire la procedura e allegare la prova |
| Punto secondario rinviato, uso limitato accettato | Riserva documentata | Decisore: limitare l'uso, fissare il ricontrollo e il suo titolare |
Scaricare e utilizzare il dossier di collaudo versione 1
Il modello Markdown funge da pagina di copertina e da verbale. La griglia CSV fornisce i controlli da personalizzare, con colonne per il livello di prova, il responsabile, il criterio deciso prima del test, il metodo, l'osservazione, il documento e lo stato. Apri il CSV in UTF-8 con la virgola come separatore; i campi di risultato sono volutamente vuoti. Conserva una copia vuota prima di lavorare.
Apri il modello con un editor di testo e la griglia con un foglio di calcolo. Adatta l'esempio fittizio ai tuoi requisiti, poi rileva le osservazioni sulla tua macchina. La licenza fornita autorizza l'uso e l'adattamento conservando l'avviso; i nomi di prodotti e documentazioni esterne mantengono i rispettivi diritti.
Usa questa ricezione per autorizzare un perimetro preciso, poi completala in occasione di un cambio di versioni, dati o modalità operativa. Non costituisce né un benchmark universale né una garanzia di assenza di interruzioni. La guida alla migrazione subentra quando occorre spostare uno stato di lavoro e spiegare il destino di ogni lotto.
Per preparare il seguito
Dare a ciascuno l'accesso necessario, con una fine prevista.
Assegnare gli accessi tecnici, verificare le identità e organizzarne la revoca.
Qualificare l'ambiente, poi ogni modifica.
Passare dalla cartella preparata a una decisione esplicita di messa in servizio.