💻 computer science

High-Performance FP16 General Matrix Multiplication on NVIDIA Ada Lovelace via CUTLASS and WMMA: A Benchmark and Pipeline-Depth Analysis

Questo articolo esamina le prestazioni delle operazioni GEMM in FP16 sulla GPU NVIDIA Ada Lovelace RTX 4060 attraverso cuBLAS, CUTLASS e implementazioni WMMA personalizzate, rivelando che una profondità di pipeline di tre con una specifica geometria dei tile raggiunge il 52,7% del throughput di picco, dimostrando al contempo che la pressione sulla memoria condivisa, piuttosto che la profondità della pipeline, è il collo di bottiglia principale che limita un'ulteriore ottimizzazione.

Autori originali: Lucas Lima Freitag

Pubblicato 2026-07-15

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Lucas Lima Freitag

Articolo originale sotto licenza CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di avere una cucina superveloce (una GPU) con un team di chef specializzati chiamati Tensor Core. Questi chef sono incredibilmente veloci a tritare e mescolare gli ingredienti (moltiplicazione di matrici) per un banchetto gigante (deep learning). La cucina sulla nuova fornella "Ada Lovelace" (una scheda grafica RTX 4060) è teoricamente capace di servire 60,55 TFLOPS (ovvero 60,55 trilioni di operazioni matematiche al secondo).

Ma ecco il problema: solo perché gli chef possono tritare così velocemente, non significa che lo stiano facendo davvero a quella velocità. Spesso devono aspettare che gli ingredienti vengano consegnati dalla dispensa.

Il Grande Esperimento: Come Tenere Occupati gli Chef

I ricercatori volevano capire il modo migliore per organizzare la cucina in modo che gli chef non smettano mai di tritare. Hanno testato tre modi diversi per gestire la cucina:

La Scatola Nera (cuBLAS): Una ricetta pre-confezionata e a codice chiuso di NVIDIA che di solito funziona molto bene, ma che non permette di modificarne i dettagli.
Il Progetto Aperto (CUTLASS): Un toolkit flessibile e open-source che ti permette di costruire la tua configurazione di cucina da zero.
L'Approccio Fai-da-Te (WMMA): Una cucina costruita su misura dove controlli ogni singolo movimento degli chef, ma è molto più difficile da costruire.

Hanno allestito una massiccia sfida culinaria con ingredienti di dimensioni 8192 × 8192 e hanno provato diversi "profondità di pipeline". Pensa alla profondità di pipeline come al numero di vassoi di ingredienti che la cucina tiene pronti.

Profondità di Pipeline 2: Solo 2 vassoi pronti.
Profondità di Pipeline 3: 3 vassoi pronti.
Profondità di Pipeline 4: 4 vassoi pronti.
La saggezza comune (e un semplice modello matematico) suggeriva che più vassoi = più velocità. La logica era: "Se abbiamo più vassoi, gli chef non rimarranno mai senza ingredienti, quindi lavoreranno più velocemente".

La Sorpresa: Più Non è Sempre Meglio

I ricercatori hanno misurato la velocità e hanno scoperto quanto segue:

Profondità 2: La cucina girava a 25,6 TFLOPS. Gli chef stavano aspettando troppo tempo.
Profondità 3: La cucina è accelerata a 31,9 TFLOPS (che è il 52,7% del massimo teorico). Questo era il punto di equilibrio perfetto!
Profondità 4: La cucina è in realtà rallentata a 31,1 TFLOPS.

Questa è la scoperta principale: Aggiungere un quarto vassoio non ha aiutato; ha peggiorato le cose. Il semplice modello matematico prevedeva che la velocità sarebbe salita a 35,4 TFLOPS, ma non è successo. Il modello era sbagliato del 13,8%.

Perché Aggiungere un Vassoio è Tornato Controproducente?

Il documento spiega che la cucina ha uno spazio limitato. Quando hanno aggiunto il 4° vassoio (aumentando l'uso della "Shared Memory" a 96 KB), ciò ha costretto la cucina a ridurre il numero di squadre di cucina (threadblock) che potevano lavorare contemporaneamente.

Con 3 vassoi, la cucina poteva ospitare 2 squadre di chef su ogni fornello.
Con 4 vassoi, la cucina poteva ospitare solo 1 squadra.

Anche se la singola squadra aveva più ingredienti, doveva aspettare più a lungo perché c'erano meno squadre pronte a subentrare quando una si bloccava. La cucina è diventata "affollata" di ingredienti ma "vuota" di lavoratori. I ricercatori hanno misurato che l'occupancy (quante squadre sono al lavoro) è scesa, e gli chef hanno dovuto usare più "register" (i loro taccuini personali), il che ha rallentato ulteriormente il processo.

Vincitori e Perdenti

Il Vincitore: Il toolkit CUTLASS con 3 vassoi e una dimensione specifica di tile di 256 × 128. Ha raggiunto i 31,9 TFLOPS. È stato così buono da battere il "Black Box" standard (cuBLAS) di una piccola quantità, quasi impercettibile, dell'1,3% (che gli autori dicono essere probabilmente solo rumore, ma dimostra che il progetto aperto può eguagliare quello chiuso).
Il Secondo Classificato Fai-da-Te: Il kernel WMMA personalizzato (la cucina completamente fai-da-te) ha gestito 25,1 TFLOPS su un test leggermente più piccolo. Era più lento perché non utilizzava i trucchi del "double buffering" per sovrapporre la consegna degli ingredienti con la cottura.
Il Perdente: L'idea che "una maggiore profondità di pipeline sia sempre meglio". Il documento esclude esplicitamente questa ipotesi per questo specifico hardware.

Quanto Sono Sicuri?

Gli autori sono molto sicuri di questi numeri perché li hanno misurati direttamente sull'hardware, eseguendo il test 10 volte e facendone la media. Hanno anche controllato i loro calcoli rispetto a uno strumento integrato di NVIDIA (il profiler) e hanno scoperto che il loro codice personalizzato corrispondeva perfettamente.

Tuttavia, ammettono alcune cose che non hanno dimostrato:

Hanno testato solo una specifica dimensione del problema (8192). Non sanno se la regola "3 vassoi è il meglio" valga per problemi più piccoli o con forme insolite.
Non hanno potuto testare profondità di pipeline superiori a 4 perché la cucina semplicemente è finita con lo spazio (memoria).
Hanno dovuto eseguire i loro test su Windows, dove un glitch del driver ha impedito loro di confrontare il proprio codice personalizzato e il codice standard nello stesso identico run (sebbene l'abbiano fatto in run separati).

Il Punto Chiave

Se stai cercando di ottenere il massimo da una scheda grafica consumer come la RTX 4060 per compiti pesanti dal punto di vista matematico, non aggiungere semplicemente più buffer. Esiste una zona "Goldilocks" (né troppo calda, né troppo fredda). In questo caso, 3 stadi di preparazione erano perfetti. Passare a 4 stadi ha reso la cucina troppo affollata, rallentando tutti.

I ricercatori hanno rilasciato tutto il loro codice come open-source, quindi chiunque può provare a costruire la propria cucina e vedere se può battere il record dei 31,9 TFLOPS. Suggeriscono che il lavoro futuro dovrebbe guardare a diverse dimensioni dei problemi e utilizzare Linux per ottenere dati ancora più puliti, ma per ora, hanno dimostrato che 31,9 TFLOPS è il picco attuale per questa configurazione e che 31,1 TFLOPS è ciò che accade quando si cerca di essere troppo avidi con la memoria.

Riepilogo Tecnico: GEMM FP16 ad Alte Prestazioni su NVIDIA Ada Lovelace tramite CUTLASS e WMMA

Problematica
La Moltiplicazione di Matrici Generica (GEMM) è la base computazionale del deep learning e del calcolo scientifico. Sebbene l'architettura NVIDIA Ada Lovelace (specificamente la RTX 4060 di classe consumer con chip AD107) offra un throughput teorico di picco per Tensor Core FP16 di 60,55 TFLOPS, raggiungere prestazioni vicine al picco richiede un'orchestrazione intricata della gerarchia di memoria della GPU. La sfida consiste nel bilanciare le strategie di tiling, la profondità del pipelining software e l'occupancy dei threadblock per saturare i Tensor Core senza essere limitati dalla pressione della memoria condivisa o dai vincoli dei registri. La letteratura precedente ha ampiamente caratterizzato la GEMM a livello di library-profiler, ma esiste una lacuna nella valutazione sistematica dell'impatto di profondità di pipeline arbitrarie e geometrie di tile utilizzando l'API a livello di device di CUTLASS su hardware consumer.

Metodologia
Gli autori hanno condotto un benchmark sistematico di operazioni GEMM FP16→FP32 su una NVIDIA RTX 4060 (Ada Lovelace) eseguita su Windows 11 con CUDA 13.1. Lo studio ha confrontato tre livelli di implementazione:

cuBLAS: La libreria proprietaria ottimizzata dal vendor, utilizzata come riferimento.
CUTLASS Device-Level API: Una libreria C++ template open-source che consente la personalizzazione a tempo di compilazione delle dimensioni dei tile, della profondità di pipeline ( $S$ ) e della vettorizzazione dell'epilogo.
Kernel WMMA Custom: Un kernel ottimato manualmente utilizzando l'API CUDA Warp Matrix Multiply Accumulate (WMMA) per la validazione pedagogica.

Gli esperimenti si sono concentrati su una dimensione del problema fissa di $N = 8192$ ( $M=N=K=8192$ ). La metodologia ha previsto:

Variazione della Profondità di Pipeline: Test delle configurazioni CUTLASS con profondità di pipeline $S=3$ e $S=4$ utilizzando tile di threadblock $256 \times 128$ e $128 \times 128$ .
Modellazione Analitica: Sviluppo di un modello di performance basato sull'efficienza della pipeline ( $S/(S+\kappa)$ ) ed estensione dello stesso per includere i vincoli di occupancy ( $\gamma(S)$ ) per prevedere il throughput.
Validazione: Assicurazione della correttezza numerica del kernel WMMA custom rispetto a cuBLAS con una soglia di errore relativo di $10^{-2}$ .
Protocollo di Misurazione: Utilizzo di temporizzazione lato host con fasi di warmup per mitigare lo scaling della frequenza di clock e l'overhead di inizializzazione, segnalando al contempo specifici problemi di stabilità del driver Windows (TDR) che hanno reso necessario separare gli stream di esecuzione di cuBLAS e CUTLASS.

Risultati Chiave

Configurazione Ottimale: La configurazione CUTLASS con una profondità di pipeline $S=3$ , un tile di threadblock $256 \times 128$ e vettorizzazione dell'epilogo di 4 ha raggiunto 31,9 TFLOPS (52,7% del picco teorico). Ciò ha eguagliato le prestazioni del kernel s16816gemm_f16 integrato nel profiler di CUTLASS e ha superato leggermente il riferimento cuBLAS (31,5 TFLOPS) dell'1,3%, una differenza attribuita all'overhead del benchmark piuttosto che a una superiorità algoritmica.
Anomalia della Profondità di Pipeline: Controintuitivamente, aumentare la profondità della pipeline a $S=4$ ha causato una regressione delle prestazioni a 31,1 TFLOPS (una diminuzione del 2,5%).
Analisi dei Colli di Bottiglia: La degradazione a $S=4$ è stata attribuita al collasso dell'occupancy. Mentre $S=3$ (che richiede 72 KB di memoria condivisa) permetteva 2 threadblock per Streaming Multiprocessor (SM), $S=4$ (che richiede 96 KB) ha forzato l'occupancy a scendere a 1 block per SM. Ciò ha dimezzato il numero di warp concorrenti, riducendo la capacità dello scheduler di nascondere la latenza di memoria. Inoltre, la pressione sui registri è aumentata da circa 64 a circa 72 registri per thread.
Accuratezza del Modello: Un semplice modello analitico ha previsto accuratamente le prestazioni per $S=2$ e $S=3$ , ma ha sovrastimato $S=4$ del 13,8%. Un modello esteso che incorpora i soffitti di occupancy ha corretto la previsione di $S=4$ entro l'1% del valore misurato.
Performance del Kernel Custom: Il kernel WMMA custom ha raggiunto 25,1 TFLOPS (41,5% del picco) a $N=4096$ . Le sue prestazioni inferiori sono state attribuite alla mancanza di pipelining software (single buffering) e a un maggiore overhead di sincronizzazione rispetto ai template ottimizzati di CUTLASS.

Contributi Chiave

Framework di Benchmarking Riproducibile: Un framework open-source che utilizza l'API a livello di device di CUTLASS per istanziare kernel GEMM con parametri arbitrari a tempo di compilazione su GPU Ada Lovelace.
Empirismo sulla Profondità di Pipeline: Evidenza sperimentale che dimostra come pipeline più profonde ( $S=4$ ) non producano sempre un throughput maggiore sulle GPU consumer a causa dei vincoli di memoria condivisa e di occupancy, contraddicendo i semplici modelli di throughput.
Modello Analitico Calibrato: Un modello di performance che prevede con successo il throughput per $S=2$ e $S=3$ , ma che richiede un'estensione limitata dall'occupancy per modellare accuratamente il regime $S=4$ .
Riferimento Pedagogico: Un kernel WMMA custom completamente validato che funge da riferimento per la programmazione a basso livello dei Tensor Core.
Osservazione del Comportamento dei Driver: Documentazione di una specifica instabilità del driver Windows (relativa al TDR) durante l'intercalazione di kernel CUTLASS e cuBLAS, evidenziando i vincoli pratici del benchmarking cross-library su Windows.

Significato e Rivendicazioni
Il documento sostiene che il raggiungimento di un'alta performance GEMM sulle moderne GPU consumer è un problema multi-collo di bottiglia in cui la profondità della pipeline non è l'unico determinante del throughput. Lo studio evidenzia come la pressione della memoria condivisa e i vincoli di occupancy possano invertire i benefici attesi di pipeline software più profonde. Dimostrando che una GPU consumer come la RTX 4060 può raggiungere circa il 53% del picco teorico dei Tensor Core (31,9 TFLOPS), il lavoro suggerisce che livelli di performance vicini a quelli dei datacenter sono accessibili su hardware economico. Gli autori pongono i loro strumenti e le loro scoperte open-source come risorsa per educatori e ricercatori per studiare le tecniche di ottimizzazione delle GPU, contribuendo agli obiettivi più ampi di calcolo ad alte prestazioni accessibile e inferenza di machine learning a efficienza energetica. Il lavoro non pretende di risolvere tutte le sfide di ottimizzazione GEMM, ma fornisce un'analisi specifica e riproducibile dei compromessi tra profondità di pipeline e occupancy sull'architettura Ada Lovelace.