Spiegare le attese prima di cercare una GPU più potente.

Descrivere il problema con un risultato e una finestra

Sostituisci «la GPU non lavora» con un'osservazione verificabile: il primo risultato arriva tardi, le fasi presentano pause o il numero di output accettati diminuisce. Indica il set di input, la versione dell'applicazione, le impostazioni e il periodo osservato. Un primo avvio può includere fasi diverse da un'esecuzione già preparata; non mescolarle senza precisarlo.

Suddividi il percorso in apertura dei file, preparazione CPU, trasferimento, calcolo GPU, scrittura e poi validazione. Queste fasi possono sovrapporsi: lo schema costituisce un'ipotesi da confrontare con le tracce. Annota i limiti con lo stesso fuso orario e una precisione sufficiente. Un grafico hardware rilevato dopo la pausa non permette di spiegare la pausa, anche se il suo valore sembra insolito.

Leggere correttamente le percentuali e le memorie

In NVIDIA SMI, l'utilizzo GPU indica la parte dell'intervallo di campionamento durante la quale almeno un kernel era in esecuzione. Non è una valutazione delle prestazioni di tutti i componenti. L'utilizzo della memoria descrive la sua attività di lettura o scrittura; non va confuso con la quantità di memoria occupata. La documentazione precisa anche che alcuni campi possono essere indisponibili a seconda dell'ambiente.

Conserva quindi il nome esatto della metrica e la sua unità. Una quantità di memoria elevata può corrispondere a dati conservati in attesa; una bassa attività può comparire durante una normale fase di preparazione. Al contrario, un'attività elevata non stabilisce che il programma svolga un lavoro utile. Occorre guardare gli output e l'avanzamento applicativo insieme all'hardware.

Raccogliere un rilevamento correlato e sufficientemente breve

Scegli una sequenza rappresentativa e limita la raccolta a quella sequenza. Rileva gli orari, l'identificatore della GPU, l'attività, la memoria occupata e le fasi dell'applicazione. In parallelo, usa gli strumenti disponibili sul tuo sistema per osservare il processo CPU, le sue attese, le sue letture e scritture. Una media su tutti i core può mascherare un singolo thread saturo; guarda anche i processi coinvolti.

Il comando di lettura qui sotto è proposto per una destinazione NVIDIA autorizzata che dispone già di NVIDIA SMI. Non è stato eseguito per questa guida. Mantiene le unità nel CSV e mostra un'osservazione al secondo fino alla sua interruzione. Verifica i campi supportati dalla tua versione e interrompi la raccolta alla fine dello scenario. Un campo N/A resta sconosciuto: non trasformarlo in zero.

Il log minimo collega un identificatore di lavoro, un orario con fuso, la fase corrente, un input o un lotto identificabile, l'avanzamento e l'eventuale errore. Non deve contenere né segreti né contenuti di business inutili alla diagnosi. Se la telemetria manca, verifica prima il suo sistema di raccolta e l'avanzamento applicativo: una curva vuota non prova che un processo sia fermo. Contrassegna il periodo senza osservazione invece di ricostruirlo a memoria.

nvidia-smi --version
nvidia-smi --query-gpu=timestamp,uuid,utilization.gpu,memory.used,memory.total --format=csv --loop=1

Distinguere un'ipotesi da una conclusione

Se l'attività GPU cala mentre l'applicazione attende i suoi input, esamina il percorso dei file. Se cala durante una lunga preparazione CPU, esamina quella fase e il suo parallelismo reale. Se i dispositivi attendono gli altri partecipanti di un lavoro distribuito, verifica l'equilibrio dei carichi e le comunicazioni. Più sintomi possono verificarsi insieme; la loro correlazione non è ancora una prova di causalità.

Scrivi un'ipotesi breve e una modifica che permetta di discriminarla. Per esempio, confrontare gli stessi input già preparati con la loro preparazione abituale può isolare una fase, purché i risultati restino identici. Non cambiare contemporaneamente la dimensione del lotto, la precisione, il numero di processi e la localizzazione dei file: un miglioramento diventerebbe difficile da attribuire.

Esempio fittizio: analizzare un ciclo di cento secondi

Il team fittizio «Revue des maquettes» descrive un ciclo senza sovrapposizione: sessanta secondi di preparazione CPU, venti di calcolo GPU, poi venti di export. Il totale è 100 secondi e la frazione temporale attribuita al calcolo GPU vale 20/100, ossia il 20 %. Questo calcolo didattico non prevede la percentuale di uno strumento di campionamento e non corrisponde ad alcuna misura di una GPU del catalogo.

Supponiamo che la preparazione possa essere ridotta a trenta secondi, senza cambiare il calcolo né gli output. Il ciclo farebbe allora 30 + 20 + 20 = 70 secondi: trenta secondi in meno, con una frazione GPU di 20/70, ossia circa il 28,6 %. Al contrario, dividere ipoteticamente il solo calcolo GPU per due darebbe 60 + 10 + 20 = 90 secondi. Lo scenario spiega perché affrontare l'attesa più lunga può pesare di più che cambiare scheda.

Approfondire una fase con un profiler

Se l'osservazione generale individua una zona lenta senza spiegarla, usa il profiler adatto all'applicazione su una finestra breve. PyTorch Profiler può raccogliere eventi CPU e CUDA e organizzare finestre di raccolta. La documentazione segnala un sovraccarico quando la registrazione delle forme o degli stack è attiva. Una traccia dettagliata è quindi uno strumento di diagnostica; il suo tempo totale non deve essere presentato senza riserve come il tempo normale del programma.

Mantieni i nomi delle fasi abbastanza espliciti da collegare un'operazione tecnica al tuo lavoro: preparazione di un gruppo di file, trasferimento, fase applicativa o pubblicazione dell'output. Inizia con il livello di dettaglio necessario all'ipotesi. Dopo la modifica, ripeti un'osservazione comparabile e poi un'esecuzione senza strumentazione pesante. Questo secondo controllo permette di verificare che il beneficio esista anche nelle condizioni usuali.

Evitare correzioni che nascondono il problema

Aumentare la concorrenza può riempire la GPU sovraccaricando al contempo il disco, la memoria host o le uscite. Aumentare la dimensione dei batch può cambiare la latenza e la memoria necessaria. Ridurre la precisione può modificare il risultato. Queste decisioni non sono vietate, ma devono essere valutate sullo stesso obiettivo di business, con i loro effetti collaterali, invece di essere adottate perché la percentuale mostrata aumenta.

Non ripristinare un dispositivo né modificarne i parametri hardware per diagnosticare un semplice calo di attività. Inizia dalla lettura, poi fai esaminare gli errori espliciti dal responsabile autorizzato. Evita anche di pubblicare tracce grezze contenenti percorsi privati, parametri riservati o dati di input. Prepara un estratto utile alla diagnostica e conserva la prova completa nel perimetro autorizzato del team.

Chiudere la diagnostica con una prova utile alla decisione

Il dossier finale deve indicare il sintomo, l'ipotesi adottata, la modifica provata, le sue condizioni e il risultato osservato. Conserva almeno un confronto prima/dopo sullo stesso set di input, la stessa qualità e la stessa definizione di fine. Se il risultato non è conclusivo, scrivi cosa è stato escluso e la prossima osservazione necessaria. Una pista scartata e documentata evita che un'altra persona ricominci a caso.

Una bassa attività normale non richiede sempre una correzione. Se l'attività rispetta la sua scadenza, la sua qualità e il suo budget, ridurre una complessità può essere preferibile a un'ottimizzazione fragile. Se si considera una nuova configurazione, trasmetti i vincoli dimostrati al dossier di ricezione. Nessun rilevamento isolato classifica il catalogo e nessun valore di questo esempio costituisce una performance promessa.