💻 computer science

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

Diese Arbeit benchmarkt die FP16-GEMM-Leistung auf der NVIDIA Ada Lovelace RTX 4060 über cuBLAS, CUTLASS und benutzerdefinierte WMMA-Implementierungen hinweg und zeigt auf, dass eine Pipeline-Tiefe von drei mit spezifischer Tile-Geometrie 52,7 % des Spitzen-Durchsatzes erreicht, während sie gleichzeitig demonstriert, dass der Shared-Memory-Druck und nicht die Pipeline-Tiefe der primäre Engpass ist, der eine weitere Optimierung begrenzt.

Ursprüngliche Autoren: Lucas Lima Freitag

Veröffentlicht 2026-07-15

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Lucas Lima Freitag

Originalarbeit lizenziert unter CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie haben eine superschnelle Küche (eine GPU) mit einem Team von spezialisierten Köchen namens Tensor Cores. Diese Köche sind unglaublich schnell im Hacken und Mischen von Zutaten (Matrixmultiplikation) für ein riesiges Festmahl (Deep Learning). Die Küche auf dem neuen „Ada Lovelace“-Herd (einer RTX 4060 Grafikkarte) ist theoretisch in der Lage, 60,55 TFLOPS (das sind 60,55 Billionen Rechenoperationen pro Sekunde) zu servieren.

Aber hier ist der Haken: Nur weil die Köche so schnell hacken können, heißt das nicht, dass sie es auch tun. Oft müssen sie warten, bis die Zutaten aus dem Vorratsschrank geliefert werden.

Das große Experiment: Wie man die Köfe beschäftigt hält

Die Forscher wollten herausfinden, wie man die Küche am besten organisiert, damit die Köche niemals aufhören zu hacken. Sie testeten drei verschiedene Arten, die Küche zu betreiben:

Die Black Box (cuBLAS): Ein vorgefertigtes, quelloffenes Rezept von NVIDIA, das normalerweise großartig funktioniert, aber keine Details zur Anpassung zulässt.
Der offene Bauplan (CUTLASS): Ein flexibles, Open-Source-Toolkit, mit dem Sie Ihr eigenes Küchenlayout von Grund auf neu erstellen können.
Der DIY-Ansatz (WMMA): Eine maßgeschneiderte Küche, in der Sie jede einzelne Bewegung der Köfe kontrollieren, was aber viel schwieriger zu bauen ist.

Sie richteten eine massive Koch-Herausforderung mit Zutaten der Größe 8192 × 8192 ein und testeten verschiedene „Pipeline-Tiefen“. Denken Sie bei der Pipeline-Tiefe an die Anzahl der bereitstehenden Zutatentabletts, die die Küche bereithält.

Pipeline-Tiefe 2: Nur 2 Tabletts bereit.
Pipeline-Tiefe 3: 3 Tabletts bereit.
Pipeline-Tiefe 4: 4 Tabletts bereit.

Die gängige Weisheit (und ein einfaches mathematisches Modell) besagte, dass mehr Tabletts = mehr Geschwindigkeit bedeuten. Die Logik war: „Wenn wir mehr Tabletts haben, werden die Köfe niemals ohne Zutaten dastehen, also arbeiten sie schneller.“

Die Überraschung: Mehr ist nicht immer besser

Die Forscher maßen die Geschwindigkeit, und dies ist, was sie herausfanden:

Tiefe 2: Die Küche lief mit 25,6 TFLOPS. Die Köfe warteten zu viel herum.
Tiefe 3: Die Küche beschleunigte auf 31,9 TFLOPS (was 52,7 % des theoretischen Maximums entspricht). Dies war der „Sweet Spot“!
Tiefe 4: Die Geschwindigkeit sank tatsächlich auf 31,1 TFLOPS.

Dies ist das Hauptergebnis: Das Hinzufügen eines vierten Tabletts half nicht; es machte die Sache schlechter. Das einfache mathematische Modell sagte voraus, dass die Geschwindigkeit auf 35,4 TFLOPS springen würde. Das passierte jedoch nicht. Das Modell lag um 13,8 % daneben.

Warum hat das Hinzufügen eines Tabletts nach hinten losgegangen?

Das Paper erklärt, dass die Küche begrenzten Platz hat. Als sie das 4. Tablett hinzufügten (wodurch der Verbrauch des „Shared Memory“ auf 96 KB stieg), zwang dies die Küche dazu, die Anzahl der Kochteams (Threadblocks) zu reduzieren, die gleichzeitig arbeiten konnten.

Mit 3 Tabletts konnte die Küche 2 Teams von Köfen auf jedem Herd unterbringen.
Mit 4 Tabletts konnte die Küche nur noch 1 Team unterbringen.

Obwohl das einzelne Team über mehr Zutaten verfügte, mussten sie länger warten, weil es weniger Teams gab, die man einschieben konnte, wenn eines feststeckte. Die Küche wurde „überfüllt“ mit Zutaten, aber „leer“ an Arbeitern. Die Forscher stellten fest, dass die „Occupancy“ (wie viele Teams arbeiten) sank und die Köfe mehr „Register“ (ihre persönlichen Notizblöcke) verwenden mussten, was sie ebenfalls verlangsamte.

Die Gewinner und Verlierer

Der Gewinner: Das CUTLASS-Toolkit mit 3 Tabletts und einer spezifischen Tile-Größe von 256 × 128. Es erreichte 31,9 TFLOPS. Dies war so gut, dass es das Standard-„Black Box“-Modell (cuBLAS) um ein winziges, fast unmessbares 1,3 % schlug (die Autoren sagen, dies sei wahrscheinlich nur Rauschen, aber es beweist, dass der offene Bauplan mit dem geschlossenen mithalten kann).
Der DIY-Runner-up: Der maßgeschneiderte WMMA-Kernel (die voll-DIY-Küche) schaffte 25,1 TFLOPS bei einem etwas kleineren Test. Er war langsamer, weil er nicht die ausgeklügelten „Double-Buffering“-Tricks verwendete, um die Lieferung der Zutaten mit dem Kochen zu überlappen.
Der Verlierer: Die Idee, dass „mehr Pipeline-Tiefe immer besser ist“. Das Paper schließt dies für diese spezifische Hardware explizit aus.

Wie sicher sind sie sich?

Die Autoren sind sehr zuversichtlich bei diesen Zahlen, da sie diese direkt auf der Hardware gemessen haben, indem sie den Test 10 Mal durchführten und die Ergebnisse im Durchschnitt bildeten. Sie haben ihre Berechnungen sogar mit einem eingebauten NVIDIA-Tool (dem Profiler) abgeglichen und festgestellt, dass ihr benutzerdefinierter Code perfekt mit diesem übereinstimmte.

Sie geben jedoch auch zu, dass sie einige Dinge nicht bewiesen haben:

Sie haben nur eine spezifische Problemgröße (8192) getestet. Sie wissen nicht, ob die Regel „3 Tabletts sind am besten“ auch für kleinere oder seltsam geformte Probleme gilt.
Sie konnten keine Pipeline-Tiefen höher als 4 testen, weil der Küche schlicht der Platz (Speicher) ausging.
Sie mussten ihre Tests unter Windows durchführen, wo ein Treiberfehler verhinderte, dass sie ihren benutzerdefinierten Code und den Standardcode im exakt gleichen Durchlauf vergleichen konnten (obwohl sie dies in separaten Durchläufen taten).

Das Fazript

Wenn Sie versuchen, das Beste aus einer grafikorientierten Karte wie der RTX 4060 für mathematisch intensive Aufgaben herauszuholen, fügen Sie nicht einfach immer mehr Puffer hinzu. Es gibt eine „Goldlöckchen-Zone“. In diesem Fall war die Vorbereitung mit 3 Stufen perfekt. Der Wechsel zu 4 Stufen machte die Küche zu eng und bremste alle aus.

Die Forscher haben ihren gesamten Code als Open Source veröffentlicht, sodass jeder versuchen kann, seine eigene Küche zu bauen und zu sehen, ob er den 31,9 TFLOPS-Rekord brechen kann. Sie schlagen vor, dass zukünftige Arbeiten sich auf andere Problemgrößen konzentrieren und Linux verwenden sollten, um noch sauberere Daten zu erhalten, aber für den Moment haben sie gezeigt, dass 31,9 TFLOPS der aktuelle Gipfel für dieses Setup ist und 31,1 TFLOPS das ist, was passiert, wenn man zu gierig mit dem Speicher umgeht.

Technisches Resümee: Hochleistungs-FP16-GEMM auf NVIDIA Ada Lovelace via CUTLASS und WMMA

Problemstellung
Die allgemeine Matrixmultiplikation (General Matrix Multiplication, GEMM) ist die rechnerische Grundlage des Deep Learning und des wissenschaftlichen Rechnens. Während die NVIDIA Ada Lovelace-Architektur (speziell der Consumer-Grafikprozessor RTX 4060 mit dem AD107-Chip) einen theoretischen FP16-Tensor-Core-Peak-Durchsatz von 60,55 TFLOPS bietet, erfordert das Erreichen einer Leistung nahe am Peak eine komplexe Orchestrierung der GPU-Speicherhierarchie. Die Herausforderung besteht darin, Tiling-Strategien, Software-Pipelining-Tiefe und Threadblock-Occupancy auszubalancieren, um Tensor Cores zu sättigen, ohne durch Shared-Memory-Druck oder Register-Beschränkungen ausgebremst zu werden. In der bisherigen Literatur wurde GEMM umfassend auf Ebene der Library-Profiler charakterisiert, jedoch gibt es eine Lücke in der systematischen Evaluierung der Auswirkungen beliebiger Pipeline-Tiefen und Tile-Geometrien unter Verwendung der CUTLASS Device-Level-API auf Consumer-Hardware.

Methodik
Die Autoren führten ein systematisches Benchmarking von FP16→FP32 GEMM-Operationen auf einer NVIDIA RTX 4060 (Ada Lovelace) unter Windows 11 mit CUDA 13.1 durch. Die Studie verglich drei Implementierungsstufen:

cuBLAS: Die proprietäre, herstelleroptimierte Bibliothek, die als Referenz dient.
CUTLASS Device-Level API: Eine Open-Source-C++-Template-Bibliothek, die eine Kompilierzeit-Anpassung von Tile-Dimensionen, Pipeline-Tiefe ( $S$ ) und Epilog-Vektorisierung ermöglicht.
Custom WMMA Kernel: Ein handoptimierter Kernel unter Verwendung der CUDA Warp Matrix Multiply Accumulate (WMMA) API zur pädagogischen Validierung.

Die Experimente konzentrierten sich auf eine feste Problemgröße von $N = 8192$ ( $M=N=K=8192$ ). Die Methodik umfasste:

Variation der Pipeline-Tiefe: Testen von CUTLASS-Konfigurationen mit Pipeline-Tiefen $S=3$ und $S=4$ unter Verwendung von Threadblock-Tiles von $256 \times 128$ und $128 \times 128$ .
Analytische Modellierung: Entwicklung eines Leistungsmodells basierend auf der Pipeline-Effizienz ( $S/(S+\kappa)$ ) und Erweiterung dieses Modells zur Berücksichtigung von Occupancy-Beschränkungen ( $\gamma(S)$ ), um den Durchsatz vorherzusagen.
Validierung: Sicherstellung der numerischen Korrektheit des benutzerdefinierten WMMA-Kernels gegenüber cuBLAS mit einem relativen Fehlerschwellenwert von $10^{-2}$ .
Messprotokoll: Verwendung von Host-seitigem Timing mit Warmup-Phasen, um Clock-Scaling und Initialisierungs-Overhead zu minimieren, wobei spezifische Probleme der Windows-Treiberstabilität (TDR) festgestellt wurden, die eine Trennung der cuBLAS- und CUTLASS-Ausführungs-Streams erforderlich machten.

Wesentliche Ergebnisse

Optimale Konfiguration: Die CUTLASS-Konfiguration mit einer Pipeline-Tiefe von $S=3$ , einem $256 \times 128$ Threadblock-Tile und einer Epilog-Vektorisierung von 4 erreichte 31,9 TFLOPS (52,7 % des theoretischen Peaks). Dies entsprach der Performance des im CUTLASS-Profiler integrierten s16816gemm_f16-Kernels und übertraf die cuBLAS-Referenz (31,5 TFLOPS) leicht um 1,3 %, wobei dieser Unterschied auf den Benchmark-Overhead und nicht auf eine algorithmische Überlegenheit zurückgeführt wurde.
Pipeline-Tiefe-Anomalie: Kontraintuitiv führte eine Erhöhung der Pipeline-Tiefe auf $S=4$ zu einer Leistungsregression auf 31,1 TFLOPS (eine Abnahme um 2,5 %).
Engpass-Analyse: Die Verschlechterung bei $S=4$ wurde auf einen Occupancy-Kollaps zurückgeführt. Während $S=3$ (das 72 KB Shared Memory erforderte) 2 Threadblocks pro Streaming Multiprocessor (SM) zuließ, zwang $S=4$ (das 96 KB erforderte) die Occupancy auf 1 Block pro SM herunter. Dies halbierte die Anzahl der gleichzeitigen Warps, was die Fähigkeit des Schedulers einschränkte, Speicherlatenz zu verbergen. Zusätzlich stieg der Registerdruck von etwa 64 auf etwa 72 Register pro Thread.
Modellgenauigkeit: Ein einfaches analytisches Modell sagte die Performance für $S=2$ und $S=3$ korrekt voraus, überschätzte jedoch $S=4$ um 13,8 %. Ein erweitertes Modell, das Occupancy-Deckel (Ceilings) einbezieht, korrigierte die Vorhersage für $S=4$ auf innerhalb von 1 % des gemessenen Wertes.
Custom Kernel Performance: Der benutzerdefinierte WMMA-Kernel erreichte 25,1 TFLOPS (41,5 % des Peaks) bei $N=4096$ . Seine geringere Leistung wurde auf das Fehlen von Software-Pipelining (Single Buffering) und höheren Synchronisations-Overhead im Vergleich zu den optimierten CUTLASS-Templates zurückgeführt.

Wesentliche Beiträge

Reproduzierbares Benchmarking-Framework: Ein Open-Source-Framework, das die CUTLASS Device-Level-API nutzt, um GEMM-Kernel mit beliebigen Kompilierzeit-Parametern auf Ada Lovelace-GPUs zu instanziieren.
Empirische Erkenntnisse zur Pipeline-Tiefe: Experimentelle Belege dafür, dass tiefere Pipelines ( $S=4$ ) auf Consumer-GPUs nicht zwangsläufig einen höheren Durchsatz liefern, da Shared-Memory- und Occupancy-Beschränkungen entgegen der einfachen Durchsatzmodelle wirken.
Kalibriertes analytisches Modell: Ein Leistungsmodell, das den Durchsatz für $S=2$ und $S=3$ erfolgreich vorhersagt, aber eine durch Occupancy begrenzte Erweiterung erfordert, um das $S=4$ -Regime genau zu modellieren.
Pädagogische Referenz: Ein vollständig validierter benutzerdefinierter WMMA-Kernel, der als Referenz für die Low-Level-Tensor-Core-Programmierung dient.
Beobachtung des Treiberverhaltens: Dokumentation einer spezifischen Windows-Treiberinstabilität (TDR-bezogen) beim Interleaving von CUTLASS- und cuBLAS-Kerneln, was die praktischen Einschränkungen beim Cross-Library-Benchmarking unter Windows hervorhebt.

Bedeutung und Ansprüche
Das Paper behauptet, dass das Erreichen eines Hochleistungs-GEMM auf modernen Consumer-GPUs ein Multi-Bottleneck-Problem ist, bei dem die Pipeline-Tiefe nicht der alleinige Bestimmungsfaktor für den Durchsatz ist. Die Studie zeigt auf, dass Shared-Memory-Druck und Occupancy-Beschränkungen die erwarteten Vorteile tieferer Software-Pipelines umkehren können. Durch den Nachweis, dass eine Consumer-Grade RTX 4060 etwa 53 % des theoretischen Tensor-Core-Peaks (31,9 TFLOPS) erreichen kann, legt die Arbeit nahe, dass Near-Datacenter-Leistungsniveaus für spezifische Workloads auch auf erschwinglicher Hardware zugänglich sind. Die Autoren positionieren ihre Open-Source-Tools und Erkenntnisse als Ressource für Lehrende und Forscher zur Untersuchung von GPU-Optimierungstechniken und tragen damit zu den breiteren Zielen des zugänglichen Hochleistungsrechnens und der energieeffizienten Machine-Learning-Inferenz bei. Die Arbeit beansprucht nicht, alle GEMM-Optimierungsherausforderungen zu lösen, bietet jedoch eine spezifische, reproduzierbare Analyse der Trade-offs zwischen Pipeline-Tiefe und Occupancy auf der Ada Lovelace-Architektur.