AMD erklärt Occupancy-Mathematik für MI355X: Hohe Auslastung ist keine Voraussetzung für Peak-Throughput

Das AMD-ROCm-Team hat einen umfangreichen technischen Leitfaden zur Berechnung der GPU-Occupancy für die CDNA4-Architektur, konkret für den MI355X-Beschleuniger, veröffentlicht. Der Text richtet sich an GPU-Kernel-Ingenieure, die benutzerdefinierte Kernel für Produktionsinferenz oder Training optimieren — und liefert einen Befund, der direkt kontraintuitiv für Entwickler aus dem NVIDIA-CUDA-Ökosystem ist.

Was ist Occupancy und warum wird sie manuell berechnet?

GPU-Occupancy misst den Anteil verfügbarer Ressourcen, die aktiv mit Wavefronts (CUDA-Terminologie: Warps) besetzt sind. Hohe Occupancy galt lange als Voraussetzung für hohen Throughput — mehr aktive Wavefronts bedeuten mehr Möglichkeiten, die Latenz von Speicherzugriffen zu verbergen.

Die Autoren des Leitfadens vertreten eine andere Position: Occupancy ist vollständig aus bekannten Hardware-Einschränkungen und den vom Kernel verbrauchten Ressourcen ableitbar und sollte aus ersten Prinzipien verstanden werden, nicht als undurchsichtige Metrik aus Profiling-Tools. Das Ziel ist, Ingenieure in die Lage zu versetzen, Occupancy vor dem Ausführen eines Kernels vorherzusagen.

Vier Limiter und die CDNA4-Architektur

Der MI355X ist um 256 Compute Units organisiert, verteilt auf 8 XCD-Chips, getaktet auf 2,4 GHz. Jede CU enthält 4 SIMD-Einheiten mit 64 Lanes, jede mit einer privaten Registerdatei.

Der Leitfaden identifiziert vier Ressourcen, die die Obergrenze der Occupancy bestimmen:

Vektor-Register (VGPR) — auf CDNA4 hat die Registerdatei 512 Einträge pro Lane, und die Register werden zwischen regulären und Akkumulator-Registern geteilt. Das ist ein wesentlicher Unterschied zu CDNA3, wo Akkumulator-Register (AccVGPR) ein separater Pool waren — AMD betont, dass Ingenieure, die Wissen von der vorherigen Generation übertragen, diese Annahme aktualisieren müssen.

Skalar-Register (SGPR) — rund 800 pro SIMD-Einheit, werden für wavefront-einheitliche Werte verwendet.

Lokaler geteilter Speicher (LDS) — von 64 KB auf CDNA3 auf 160 KB pro Compute Unit auf CDNA4 erhöht.

Workgroup-Slots — Hardware-Beschränkung der Anzahl gleichzeitig aktiver Workgroups pro CU.

Kontraintuitiver Befund: Niedrige Occupancy, Peak-Throughput

Der zentrale Befund des Leitfadens widerspricht direkt der Intuition aus CUDA-Optimierungserfahrung. AMDs Microbenchmark für MXFP8-Operationen — für die der MI355X rund 5 PFLOP/s erreicht — zeigt, dass Kernel mit hohem Instruction-Level-Parallelismus (ILP=8) 4,82 PFLOP/s bei nur 12 % Occupancy halten. Dieser Wert übertrifft alles, was ein ILP=2-Kernel auch bei 96 % Occupancy erreicht.

Der Grund: Die Matrix-Einheiten auf CDNA4 sind schnell genug, um die Pipeline mit einer kleinen Anzahl aktiver Wavefronts zu sättigen. Wenn ein Kernel Latenz erfolgreich durch ILP statt durch Wavefront-Parallelismus verbirgt, ist hohe Occupancy nicht nur unnötig — sie kann aufgrund von Register-Datei-Einschränkungen unmöglich sein, ohne irgendeinen Nutzen zu bringen.

MXFP8-GEMM-Beispiel: Derselbe Kernel, zwei Generationen

Der Leitfaden enthält ein konkretes Beispiel: Ein MXFP8-GEMM-Kernel mit einer Tile-Größe von 256 Threads, der 128 VGPRs und 32 KB LDS verbraucht.

Auf CDNA3 mit 64 KB LDS: Der Kernel ist LDS-limitiert und erreicht 25 % Occupancy — nur zwei solcher Kernel können gleichzeitig pro CU aktiv sein, da sie gemeinsam den LDS erschöpfen.

Auf CDNA4 mit 160 KB LDS: Derselbe Kernel ist nicht mehr LDS-limitiert. Nun begrenzen ihn die Register, und die Occupancy steigt auf 50 % — vier Instanzen pro CU. Derselbe Quellcode, unterschiedliche Limiter, doppelt so hohe Auslastung.

Kontext: AMD schließt die Dokumentationslücke zu CUDA

Der Leitfaden ist Teil von AMDs breiterem Bemühen, die ROCm-Softwaredokumentation zu verbessern und die Hürde für Ingenieure zu senken, die vom NVIDIA-Ökosystem wechseln. CUDA hatte jahrzehntelang einen Vorteil in der Tiefe der technischen Dokumentation — Details wie diese über Ressourcengrenzen und deren Auswirkung auf Occupancy waren für NVIDIA-Architekturen gut dokumentiert, während sie für AMD-GPUs experimentelle Untersuchung oder interne Code-Einblicke erforderten.

Solche Leitfäden aus ersten Prinzipien zielen genau auf diese Lücke: Ingenieure, die wissen, was sie suchen, können Occupancy nun analytisch ableiten, ohne Kernel auszuführen — was den iterativen Optimierungszyklus von Produktions-KI-Modellen auf AMD-Infrastruktur beschleunigt.