Forschungsbericht · überarbeitet am 09. November 2026
Eine reale Projektion als feste Vergleichsaufgabe
Untersucht wird die Gate-Projektion der ersten MLP-Schicht des archivierten Qwen-Checkpoints. Ihre Matrix besitzt 17.408 Ausgabezeilen und 5.120 Eingabespalten. Die 89.128.960 BF16-Werte belegen unkomprimiert 178.257.920 Byte. Tensorherkunft und Inhalt sind über eine festgelegte Checkpointrevision und eine SHA256-Prüfsumme identifiziert. Damit vergleichen die Implementierungen dieselben Modellgewichte und nicht unterschiedlich günstige Zufallsmatrizen.
Die Aufgabe lautet Y = X · Wᵀ für Batchgrößen 1 und 8. Vergleichsgröße ist jeweils eine vollständige Batchprojektion. Acht Eingabevektoren sind deshalb nicht mit der Laufzeit eines einzelnen Vektors zu verwechseln. Der Versuch erzeugt keine Sprachmodellantworten. Er isoliert einen häufigen linearen Baustein, dessen Optimierung sich anschließend als stärkere Softwarebasis verwenden lässt.
cuBLAS und eigener Triton-Kern unter gleichen Bedingungen
Die Ausführung verwendet eine NVIDIA RTX PRO 6000 Blackwell Server Edition mit PyTorch 2.8.0, CUDA 12.8 und Triton 3.4. Der eigene unkomprimierte Triton-Kern wird mit der in diesem Versuch verwendeten cuBLAS-Ausführung verglichen. Die Kernelkonfigurationen wurden zunächst auf getrennten synthetischen Gewichten eingestellt und danach für den echten Tensor festgehalten. Dadurch wird nicht nachträglich die günstigste Konfiguration für jede Messrunde ausgewählt.
Alle Methoden verwenden CUDA-Graph-Blöcke und dieselbe BF16-Darstellung. TF32 und reduzierte BF16-Reduktionspräzision sind in der archivierten Umgebung deaktiviert. Die Ausgaben werden mit einer FP32-Referenz aus unveränderten BF16-Eingaben abgeglichen. Unterschiedliche Summationsreihenfolgen sind innerhalb der vorher festgelegten Genauigkeitsgrenzen zulässig. Es handelt sich daher nicht um den streng bitidentischen FMA-Vertrag der späteren RTL-Versuche.
Cachezustand und Wiederholungen getrennt betrachten
Jede Variante läuft sowohl mit wiederverwendeter Matrix als auch mit fünf rotierenden physischen Matrixkopien. Im Rotationsfall überschreitet der Arbeitsbestand bei beiden untersuchten Darstellungen das Vierfache des gemeldeten 128-MiB-L2-Caches. Das reduziert die Abhängigkeit von einer einzigen dauerhaft warmen Matrix. Tatsächliche Cache-Misses wurden jedoch nicht mit Hardwarezählern profiliert, weshalb die Rotation nicht als garantierter cachefreier Betrieb bezeichnet wird.
Drei getrennte Eingabeseeds liefern drei Messrunden je Bedingung. Berichtet wird der Median dieser Runden. Die gespeicherten p05/p95-Bereiche beschreiben die zeitlichen Blockstichproben innerhalb der Ausführung. Sie sind keine Konfidenzintervalle für alle Geräte, Systemzustände oder Anwendungslasten. Eine weitere erfolgreiche Cloud-Ausführung prüft die Wiederholbarkeit des zentralen Befunds.
Gemessene Operatorzeiten und Energie
| Erste Ausführung | cuBLAS | Triton |
|---|---|---|
| Batch 1, Rotation | 121,16 µs | 117,61 µs |
| Batch 8, Wiederverwendung | 133,15 µs | 119,86 µs |
| Batch 8, Rotation | 134,10 µs | 120,07 µs |
| GPU-Boardenergie, Batch 8, Rotation | 47,24 mJ | 41,40 mJ |
Im Batch-8-Rotationsfall entsprechen die ungerundeten Werte 10,47 % kürzerer Operatorzeit und 12,36 % weniger GPU-Boardenergie. Die Zeitbereiche der drei Runden bleiben getrennt, der Gewinn überschreitet jeweils die festgelegte 5-%-Schwelle. Bei Batch 1 ist der Zeitgewinn kleiner und erreicht diese Schwelle nicht.
Die zweite erfolgreiche Ausführung liefert für denselben Batch-8-Fall 134,05 gegenüber 120,08 µs sowie 47,61 gegenüber 39,89 mJ. Der Zeitbefund wiederholt sich mit 10,42 %. Die unterschiedliche Energieersparnis von 16,20 % zeigt zugleich, weshalb einzelne Energiefenster nicht als unveränderliche Eigenschaft eines Kernels behandelt werden dürfen.
Was der Energiezähler tatsächlich umfasst
Die Energie stammt aus mindestens zwei Sekunden langen NVML-Zählerfenstern. Wiederholte Projektionen werden gemeinsam gemessen und auf die ausgeführte Arbeit bezogen. Enthalten ist die GPU-Boardaufnahme einschließlich der im Fenster anfallenden Grundaufnahme. Die Werte sind keine reine Energie der Multiplikationen und keine Messung des gesamten Servers.
CPU, Hauptspeicher, Spannungsversorgung außerhalb des Boards und Kühlung sind nicht Teil dieser Grenze. Die Energie eines simulierten Kachelblocks kann daher nicht unmittelbar neben diese Millijoulewerte gestellt und als Effizienzvergleich gelesen werden. Für einen solchen Vergleich wären vollständige Arbeitsumfänge und übereinstimmende Energiegrenzen nötig.
Welche Referenz der Befund verbessert
Der unkomprimierte Kern ist für diese Projektion die stärkere der getesteten Implementierungen und wird als weitere Operatorreferenz gesichert. Das ist ein konkret gemessener Softwaregewinn auf vorhandener Hardware. cuBLAS bezeichnet eine Bibliothek für lineare Algebra und keine universelle Obergrenze aller GPU-Implementierungen.
Eine vollständige Modellreferenz müsste zusätzlich Fusionen, Laufzeitsoftware, Aufmerksamkeit, Speicherverwaltung und Ausgabeprozess einbeziehen. Auch weitere Geräte und optimierte Modellserver fehlen in diesem Versuch. Der wissenschaftliche Nutzen liegt deshalb in einer klar abgegrenzten positiven Kontrolle: Ein Kandidat, der diese bereits schnellere Implementierung nicht erreicht, kann nicht allein durch einen Vergleich mit der langsameren Bibliothekskonfiguration überzeugen.
Konsequenz für den nächsten Entwurf
Den schnelleren Triton-Kern als GPU-Operatorreferenz und Ausgangspunkt weiterer Softwareoptimierung sichern.