Quale GPU costa meno per lo stesso risultato ML?

Definire cosa conterà come risultato accettato

Scrivi la decisione prima delle prove: «Quale configurazione elabora tutti i miei documenti, rispetta la mia qualità minima e termina prima della mia scadenza, per il budget impegnato più basso?» Fissa lo scenario: qui, un corpus elaborato offline. Un'applicazione interattiva richiederebbe anche di definire l'arrivo delle richieste, la loro concorrenza e la latenza ammissibile; la sua classificazione non si deduce da questa sola prova.

Chiama corpus validato un insieme completo di output che supera tutti i tuoi controlli. Un file creato non è ancora un risultato accettato. Verifica gli identificatori, il formato, la copertura e una metrica legata al tuo utilizzo. Inscrivi la soglia e la tolleranza rispetto a un riferimento prima di guardare i tempi. Due configurazioni possono così essere equivalenti per la decisione senza produrre numeri identici bit per bit.

Questa separazione tra set di dati, obiettivo di qualità e scenario esiste anche nei principi di MLPerf Inference. Il protocollo qui sotto è il nostro metodo di lavoro da adattare al tuo progetto; non costituisce né un'esecuzione né una certificazione MLPerf.

Fonti tecniche: MLCommons — scenari, metriche e obiettivi di qualità

Preparare gli input, il riferimento e il manifesto

Ti serve un corpus che hai il diritto di usare, risposte di riferimento o una procedura di valutazione, il codice di inferenza e un ambiente in grado di eseguire il modello scelto. Separa i dati che servono a regolare la configurazione del corpus finale di confronto. Se regoli le soglie dopo aver visto quest'ultimo, prepara una nuova valutazione indipendente per sostenere la conclusione.

Assegna un identificatore stabile a ogni input. Conserva un'impronta del corpus, l'ordine di passaggio, la revisione del modello e del tokenizer, le versioni del codice e delle dipendenze. Il manifesto descrive anche GPU utilizzate, precisione, quantizzazione, compilazione, backend di attenzione, politica di padding e lunghezza massima. Una troncatura diversa cambierebbe il lavoro da confrontare.

Rileva il driver e il backend effettivamente presenti. Per una variante AMD, verifica la combinazione sistema, GPU, ROCm e framework nella matrice ufficiale. Una documentazione consultata o il nome di una scheda non provano che questo ambiente sia installato. Se gli stack software differiscono tra due prove, la conclusione riguarderà le configurazioni complete testate.

Fonti tecniche: AMD — matrice di compatibilità ROCm

Esempio: classificare gli stessi 1.000 testi

Ecco un esperimento da costruire con i tuoi dati, senza risultati di prestazioni presunti. Vuoi classificare 1.000 testi nelle categorie del tuo progetto. Riserva 600 voci brevi, 300 intermedie e 100 lunghe; definisci i limiti con il tokenizer scelto e mantieni una distribuzione rappresentativa delle classi. Questa suddivisione è un esempio di protocollo, non un corpus fornito né una raccomandazione universale di proporzioni.

Confronta batch di 1, 4 e 8 con lo stesso modello, la stessa precisione, lo stesso ordine e la stessa regola di padding. L'unica variabile di questa prima serie è il batch. Una seconda serie potrà cambiare la precisione o l'hardware, mantenendo esplicitamente fissate le altre scelte. Un raggruppamento per lunghezza è una nuova variante da dichiarare, perché modifica l'organizzazione del lavoro.

Per ogni esecuzione, esporta le 1.000 predizioni con i loro identificatori. Il controllo deve ritrovare esattamente gli identificatori attesi, senza duplicati né omissioni. Conserva le predizioni errate: servono al calcolo della qualità. Rimuovere gli esempi difficili migliorerebbe artificialmente il punteggio e ridurrebbe il corpus effettivamente elaborato.

Separare avvio, riscaldamento ed esecuzione misurata

Registra il download necessario, l'installazione, il caricamento e la compilazione separatamente dall'elaborazione stabilizzata. Possono essere esclusi dal cronometro di un'esecuzione pur occupando una parte del noleggio. Fissa una regola di riscaldamento identica per tutte le varianti: input coperti, numero di esecuzioni e gestione delle ricompilazioni. Non modificare questa regola dopo aver visto quale variante ne beneficia.

Definisci i limiti del tempo principale. Per questo esempio offline, misura la lettura del corpus, la tokenizzazione, i trasferimenti, l'inferenza e la materializzazione delle predizioni sull'host. Cronometra poi la valutazione e la scrittura dei deliverable separatamente per stabilire la campagna completa. Una durata limitata al calcolo GPU non è direttamente confrontabile con questo tempo di elaborazione.

Le operazioni CUDA sono asincrone: un cronometro host deve attendere la fine delle operazioni precedenti prima del suo avvio e quella del lavoro misurato prima del suo arresto. Gli eventi CUDA sono adatti a un perimetro GPU correttamente definito. Per un'operazione isolata, torch.utils.benchmark.Timer gestisce il riscaldamento e la sincronizzazione. Mantieni gli stessi confini di misurazione tra le varianti.

Fonti tecniche: PyTorch 2.14 — esecuzione CUDA asincrona · PyTorch — misurare con torch.utils.benchmark

Ripetere e conservare i fallimenti

Prevedi cinque esecuzioni complete per variante per questo primo confronto. Alterna il loro ordine, ad esempio 1–4–8 poi 4–8–1 poi 8–1–4, in modo che una sola variante non sia sempre la prima. Mantieni la politica di processi, cache e riscaldamento. Queste cinque esecuzioni descrivono la tua piccola serie; da sole non dimostrano la stabilità su un lungo periodo.

Una riga della tabella grezza rappresenta un passaggio tentato, incluso un arresto. Collega la variante e il corpus ai parametri, alla durata e al verdetto di qualità. I campi expected_ids e observed_ids registrano il numero di voci; ids_match conferma l'uguaglianza degli insiemi, verificata nei file di predizioni conservati separatamente. corpus_accepted contiene il verdetto del passaggio. Inserisci gli errori e il percorso degli output in notes. Se manca una misura, lascia la sua cella vuota e indica perché. L'assenza di una GPU non è una misura di zero secondi o di zero byte.

Se il batch 8 supera la memoria sulle voci lunghe, conserva la riga di fallimento e il numero di voci completate. Non sostituire silenziosamente questo passaggio con un batch più piccolo. La configurazione di ripresa diventa una variante distinta; il suo tempo e i suoi tentativi fanno parte del bilancio. Un'interruzione o un errore di formato non è mai un successo economico solo perché è stato rapido.

Leggere le durate senza sovrainterpretare cinque prove

Presenta le cinque durate grezze, la loro mediana, il minimo e il massimo, con il numero di successi e di fallimenti. La mediana descrive il centro di queste osservazioni; non elimina gli incidenti. Se un passaggio viene escluso per una causa esterna documentata, conservane traccia e applica la stessa regola di esclusione a tutte le varianti.

Non presentare un p95 calcolato su cinque passaggi come una stima robusta dei casi lenti. Per studiare la latenza delle richieste, raccogli un insieme adeguato di tempi individuali con lo scenario di arrivo e la concorrenza. Le cinque durate del corpus e le latenze di 1 000 richieste non sono la stessa popolazione.

Se la dispersione osservata è paragonabile allo scarto tra le mediane, la serie non distingue ancora le opzioni. Aggiungi ripetizioni in un protocollo comune oppure esamina una causa precisa: caricamento, forme di input, compilazione, attività concorrente. Evita di tenere solo il miglior passaggio di ogni scheda.

Verificare la qualità dopo un cambio di precisione

Per confrontare FP32, BF16 o una quantizzazione, riparti dagli stessi input e dallo stesso riferimento. Valuta il formato, la metrica principale e i sottogruppi previsti. Una variante che supera la tua tolleranza può essere interessante per un altro obiettivo; non entra nel confronto a qualità equivalente abbassando la soglia a posteriori.

Registra i seed e le opzioni deterministiche utilizzate. PyTorch non garantisce una riproducibilità completa tra versioni, piattaforme o esecuzioni CPU e GPU, anche con lo stesso seed. Specifica quindi cosa cerchi di riprodurre: output identici, scarto numerico limitato o qualità di business accettabile. Per un protocollo stocastico, prevedi più seed comuni e conserva i loro risultati separatamente.

Fonti tecniche: PyTorch 2.14 — portata e limiti della riproducibilità

Usare la memoria come criterio di fattibilità

Un'opzione deve completare il corpus con i suoi input lunghi prima che il suo costo venga confrontato. Rileva il picco di memoria per dispositivo e il perimetro del contatore. Con PyTorch, memory_allocated segue i tensori e memory_reserved la memoria gestita dall'allocatore: questi valori non si sommano. I picchi corrispondenti possono verificarsi in momenti diversi.

Il notebook della cartella memoria aiuta a distinguere stima e osservazione. Il suo esercizio non sostituisce la misura del tuo modello: carica il tuo ambiente, conserva i parametri e riesegui il tuo carico. Una capacità dichiarata per scheda e un prezzo a lotto non permettono di dedurre un throughput, un'interconnessione o una ripartizione automatica del modello su più GPU.

Fonti tecniche: PyTorch 2.14 — contatori e allocatore di memoria

Scegliere la durata con il calendario completo

La durata necessaria non è solo la somma dei kernel GPU. Costruisci una finestra di accesso che vada dalla preparazione sul noleggio al recupero dei deliverable: installazione, controlli, riscaldamento, confronti, riprese previste, valutazione ed export. Aggiungi i periodi di attesa durante i quali hai ancora bisogno di mantenere il noleggio. Quando le attività si sovrappongono, ragiona sul calendario reale invece di sommare due volte le loro durate.

Esempio di calendario, senza ipotesi di velocità: vuoi mantenere l'accesso dal lunedì alle 9:00 al venerdì alle 9:00, nello stesso fuso orario e fuori dal cambio dell'ora. Questa finestra copre 96 ore. Supera le 72 ore di un pacchetto da 3 giorni e rientra nelle 168 ore di un pacchetto da 7 giorni. Ciò non prova che le tue elaborazioni finiranno in tempo: le loro durate restano da misurare.

Il calcolatore permette di inserire la tua finestra totale e mostra i forfait da 3, 7 e 30 giorni. Un forfait che copre il calendario diventa un candidato. Se la campagna supera il periodo scelto, modifica il programma o quantifica esplicitamente i periodi aggiuntivi necessari; non dare per scontata una proroga automatica.

Calcolare il costo impegnato con i nostri forfait

Il budget di un noleggio è il prezzo del forfait per un lotto, moltiplicato per il numero di lotti. Il costo per corpus validato divide poi questo importo intero per i corpus utili effettivamente accettati nel perimetro annunciato. Se nessun corpus viene accettato, il rapporto è indefinito. La spesa impegnata, invece, resta nel bilancio.

I prezzi qui sotto provengono dal nostro catalogo, versione del 24 settembre 2026. Illustrano la regola di calcolo, senza stabilire quale GPU termina la tua elaborazione più velocemente. Un lotto B200 comprende già due schede: moltiplicare di nuovo il suo prezzo per due conterebbe queste schede due volte. Due lotti di RTX 4090 per 7 giorni costano così 220 USD; un lotto di due B200 per 7 giorni costa 2.071 USD.

Un'esecuzione breve non trasforma il forfait in una fattura a ore. Il calcolatore usa il totale del forfait, anche se una parte del periodo resta inutilizzata. Per un budget di progetto più ampio, registra separatamente le altre spese effettivamente applicabili e la loro giustificazione. Non mescolare costi misurati in una delle varianti con voci dimenticate nell'altra.

Fonti tecniche: IteraGPU — forfait del catalogo

Contare deliverable utili, non ripetizioni di misura

Le cinque ripetizioni di uno stesso benchmark servono a osservare la dispersione. Non diventano cinque corpus di produzione utili solo perché sono stati scritti cinque file. Definisci i deliverable attesi prima della campagna e conta ogni deliverable accettato una sola volta. Se il lavoro reale riguarda più corpus, ogni configurazione deve trattare gli stessi corpus e applicare la stessa regola di qualità.

Nel calcolatore, lascia vuoto il numero di corpus finché i deliverable utili non sono realmente terminati e validati. La casella di qualità conferma il tuo controllo; lo strumento non legge né le tue previsioni né le tue metriche. Indica solo la quantità riscontrata. La finestra di campagna può essere un'ipotesi di pianificazione, ma una previsione di capacità non sostituisce risultati accettati.

Il bilancio finale riunisce, per ogni configurazione ammissibile, i verdetti di qualità, le durate grezze, la finestra di campagna, il forfait impegnato e il numero di deliverable accettati. Un'opzione veloce può essere utile per una scadenza stretta senza essere la meno cara. Due opzioni che rientrano nello stesso calendario possono essere distinte dal loro costo impegnato, dai loro fallimenti o dall'incertezza che rimane.

Scaricare il protocollo e conservare una prova riutilizzabile

La cartella IteraGPU Lab v1 raccoglie i supporti di questo confronto e della misura della memoria. Inizia dal README e dal protocollo di qualità, poi completa la tabella grezza con le tue esecuzioni. Le celle di performance restano vuote prima di un'esecuzione; le tariffe sono dati di catalogo, separati dalle misure.

Per preventivare due lotti di RTX 4090 per 7 giorni, metti calcul_forfaits.py e tarifs-forfaits.csv nella stessa cartella, apri un terminale in quella cartella e lancia il comando seguente con Python 3.10 o versione successiva. Mostra un preventivo di 220,00 USD per due GPU. L'opzione facoltativa --accepted-results riceve il tuo numero intero di corpus utili distinti effettivamente completati e validati. Omettila finché questo dato non esiste: in tal caso lo script calcola solo il preventivo, senza inventare un costo per risultato.

Conserva insieme il manifest, le impronte degli input, le predizioni, i verdetti e la tabella dei tentativi. La nota di decisione indica la configurazione scelta, il carico coperto e la motivazione della scelta. Potrai confrontarla con il tuo noleggio nel registro IteraGPU e riproporre esattamente la stessa domanda sperimentale in caso di cambio di modello o di versione.

Questo protocollo offline non qualifica da solo un servizio interattivo, un addestramento fino a convergenza o un altro set di dati. Per questi usi, ridefinisci l'unità utile e i controlli prima di confrontare. I file forniti servono a preparare e documentare le tue prove; questa cartella non presenta alcun confronto misurato tra le configurazioni del catalogo né alcun risparmio osservato.

python calcul_forfaits.py --gpu rtx-4090 --days 7 --lots 2

• IteraGPU Lab v1 — cartella completa ↓

  Archivio degli script, del notebook, delle tabelle e delle istruzioni.

• Protocollo di qualità ↓

  Input, criteri di accettazione e regole di confronto da fissare prima delle prove.

• Tabella dei risultati grezzi ↓

  Foglio vuoto per conservare parametri, misure, verdetti e fallimenti.

• Calcolo dei preventivi ↓

  Calcolo del budget con prezzo per lotto, durate di 3, 7 e 30 giorni e corpus validati.

• Tariffe dei preventivi ↓

  Istantanea dei prezzi del nostro catalogo utilizzati dal calcolo fornito.

• Notebook di misura della memoria ↓

  Calcoli ed esercizio di misura da interpretare con la cartella sulla memoria.

• Script di misura della memoria ↓

  Versione Python dell'esercizio, con controllo dell'ambiente.

• Istruzioni e prerequisiti ↓

  Perimetro degli strumenti e procedura per eseguirli e conservare gli output.

• Licenza delle risorse ↓

  Condizioni di riutilizzo delle risorse originali della cartella.