AMD Quark bringt MXFP4-Quantisierung für FLUX.1-dev auf Instinct MI350 mit 1,92× Beschleunigung

AMD hat die Unterstützung für MXFP4-Quantisierung auf den Bereich der Bildgenerierung ausgeweitet. Das ermöglichende Werkzeug ist Quark, AMDs Quantisierungs-Framework, integriert mit dem xDiT-Framework für parallele Ausführung von Diffusionsmodellen. Messungen auf dem AMD-Instinct-MI350-GPU (Architektur gfx950) zeigen erhebliche Beschleunigungen ohne messbare Qualitätseinbußen bei generierten Bildern.

MXFP4-Quantisierung für Diffusionsmodelle auf AMD-Instinct-Plattform

Die Bildgenerierung mit Diffusionsmodellen gehört zu den speicherintensiven Workloads – eine große Anzahl von Parametern durchläuft aufeinanderfolgende Denoise-Schritte, und bei Echtzeit-Inferenz oder Batch-Verarbeitung beeinflusst jede Millisekunde Latenz direkt die Servicewirtschaftlichkeit. FP4-Quantisierung bietet eine dramatische Reduzierung des Speicher-Footprints, doch ohne strukturiertes Skalieren entsteht ein zu großer numerischer Präzisionsverlust, der als Artefakte in generierten Bildern sichtbar wird.

Quark Release 0.12 implementiert MXFP4 per-Layer mit nativen AITER-GEMM-Kerneln, die direkt im MXFP4-Format arbeiten. Es gibt keine Dequantisierungsphase zwischen Schichten – der Kernel empfängt MXFP4-Eingabe und produziert Ausgabe ohne Konvertierung zurück zu FP16 oder BF16, wodurch der Speicherbandbreiten-Overhead eliminiert wird, der andernfalls den Vorteil niedrigerer Präzision teilweise zunichtemachen würde.

Testumgebung: PyTorch 2.9.1 mit ROCm-Backend, AITER 0.1.10, Quark Release 0.12, Docker Image rocm/pytorch-xdit:v26.5.

Was ist MXFP4 und warum eliminiert es den Dequantisierungs-Overhead?

FP4-Repräsentation wird in 4 Bit pro Element gespeichert, was im Vergleich zu BF16 (16 Bit) einen 4× kleineren Modell-Speicher-Footprint ergibt. Das Problem von Standard-FP4 ist der enge dynamische Bereich: Ohne Information über die Datenmagnitude verschwinden kleine numerische Unterschiede zwischen Aktivierungen in der Rundung.

MXFP4 (Microscaling FP4) löst dies durch Block-Level-Skalierung: Jeder Block von 32 Elementen teilt einen gemeinsamen Skalierungsfaktor, der in höherer Präzision gespeichert ist. Dies ist ein standardisierter Ansatz, der innerhalb der umfassenderen Microscaling-Spezifikation (MX) definiert ist und FP4-Komprimierung mit einem dynamischen Bereich ermöglicht, der mit FP8-Formaten vergleichbar ist. AMDs AITER-GEMM-Kernel implementieren dieses Format nativ auf der MI350-Architektur, was bedeutet, dass die GPU direkt mit MXFP4-Tensoren arbeitet, ohne Software-Konversionen im Hot Path.

Gemessene Beschleunigung auf einem und zwei MI350-GPUs

Das Referenzmodell ist FLUX.1-dev (black-forest-labs), generiert bei einer Auflösung von 1024×768 Pixeln, 20 Inferenzschritten, Guidance Scale 3,5. Die Qualitätsvalidierung wurde an 100 Samples aus dem COCO-2017-Datensatz mit openai/clip-vit-base-patch16 durchgeführt.

Auf einem GPU mit torch.compile erzielt die MXFP4-ASM-Konfiguration eine 1,92×-Beschleunigung gegenüber dem BF16-Eager-Baseline – die Latenz sinkt von 2,054 s/Bild auf 1,069 s/Bild. Im Vergleich zur kompilierten BF16-Variante beträgt die Beschleunigung 1,41×. Im Eager-Modus ohne Kompilierung bringt MXFP4 eine 1,15×-schnellere Generierung (1,779 s/Bild gegenüber 2,054 s/Bild).

Bei einer Konfiguration mit 2 GPUs unter Verwendung von Ulysses-Parallelismus erreicht die MXFP4-kompilierte Variante optimale 0,855 s/Bild bei Batch-Größe 16, was einen 1,23× besseren Durchsatz gegenüber dem BF16-Äquivalent (1,052 s/Bild) darstellt. Bei Batch-Größe 1 ist die Beschleunigung etwas geringer, 1,21×, aufgrund geringerer paralleler Auslastung.

Qualität der generierten Bilder bleibt unverändert

Der BF16-Eager-Baseline erzielt einen CLIP-Score von 30,98. Die MXFP4-ASM-kompilierte Variante erzielt 31,84 – numerisch höher als der Baseline, innerhalb der statistischen Variabilität des Messverfahrens bei 100 Samples. Alle vier getesteten Konfigurationen (BF16 Eager, BF16 kompiliert, MXFP4 Eager, MXFP4 kompiliert) halten CLIP-Scores innerhalb eines Bereichs von ±0,5 Punkten.

Dies ist praktisch relevant: CLIP-Scores messen die semantische Übereinstimmung zwischen Bild und Beschreibung, was der Wahrnehmung des Benutzers näher ist als Metriken wie PSNR, die Pixelähnlichkeit messen. Die Bestätigung, dass MXFP4 den CLIP-Score nicht verschlechtert, bedeutet, dass die Quantisierung keine semantischen Artefakte einführt, die für den Endbenutzer sichtbar wären.

Die Integration mit dem xDiT-Framework lässt Raum für Erweiterung auf 4 oder 8 GPUs ohne Änderung der Quantisierungskonfiguration – AMD Quark 0.12 unterstützt FP8- und MXFP4-Formate auf derselben MI350-Infrastruktur. Für Betreiber von Bildgenerierungs-Services bedeutet die Beschleunigung von 1,92× direkt eine Verdoppelung der Kapazität pro GPU oder eine proportionale Reduzierung der Infrastrukturkosten bei gleicher Last. Die Zugänglichkeit des Ansatzes – Standard-Docker-Image, Diffusers-Integration, xDiT-Ulysses-Parallelismus ohne Modifikationen am Modell – macht die MXFP4-Quantisierung zu einer praktikablen Option für Produktions-Deployments ohne spezialisiertes Expertenwissen über AMD-Hardware.