NVIDIA zeigt, wie TensorRT LLM VisualGen FLUX 3 Image Klein auf Blackwell beschleunigt: bis zum 3,46-Fachen bei Text-zu-Bild und 4,45-Fachen bei Bild-zu-Bild für Base bei 2048×2048 auf einer B200 gegenüber nicht kompiliertem BF16, doch die Zahlen stammen von NVIDIA auf einem Feature-Branch und schnellere Einstellungen verändern die Bilder
Am 6. November 2026 veröffentlichte NVIDIA ein Tutorial zur Beschleunigung von FLUX 3 Image Klein von Black Forest Labs mit TensorRT LLM VisualGen. Auf einer B200 bei 2048 mal 2048 ergab die Kombination aus Kompilierung, NVFP4, Sol-Attention und Cache-DiT gegenüber nicht kompiliertem BF16 für Base das 3,46-Fache bei Text-zu-Bild (22,36 s auf 6,46 s) und das 4,45-Fache bei Bild-zu-Bild; auf einem DGX mit acht B200 sank die mediane Base-Text-zu-Bild-Latenz von 14,90 s auf 3,00 s. Jede Beschleunigung hat ihre eigene Vergleichsbasis, und schnellere Attention- und Cache-Einstellungen erhöhen LPIPS und verändern die Bilder. Die Zahlen stammen von NVIDIA selbst, von einem Feature-Branch, ohne Prompt-Erweiterung und ohne Angaben zur Streuung zwischen Läufen.
Am 6. November 2026 veröffentlichte NVIDIA ein technisches Tutorial dazu, FLUX 3 Image Klein auf Blackwell-GPUs mit TensorRT LLM VisualGen schneller auszuführen, einer Laufzeitumgebung für Diffusionsmodelle innerhalb von TensorRT LLM. FLUX 3 Image Klein ist ein Modell von Black Forest Labs (BFL) zur Bildgenerierung und -bearbeitung. Es gibt einen undestillierten Base-Checkpoint mit 50 Entrauschungsschritten und Guidance-Skala 3,5 sowie einen destillierten Checkpoint mit 16 Schritten ohne Guidance. Die Modellkarte nennt einen Bildtransformer mit 5,6 Milliarden Parametern, Qwen3-VL-4B-Instruct als separaten Textencoder, bis zu 10 Referenzbilder, BF16-, FP8- und NVFP4-Varianten und die FLUX Kommunity License, die nichtkommerzielle Nutzung erlaubt und für berechtigte Nutzer eine Ausnahme für kommerzielle Ausgaben vorsieht. Der Beitrag sagt, BFL habe das Modell auf NVIDIA-GB200-NVL72-Systemen trainiert und für NVIDIA-GPUs optimiert, es ist also ein Anbieter-Tutorial für die eigene Hardware. Alle Zeiten unten stammen von NVIDIA selbst.
Der Beitrag schlüsselt zuerst auf, wohin die Zeit geht. Bei 2048 mal 2048 Pixeln auf einer NVIDIA-B200-GPU mit NVFP4-Gewichten, torch.compile und Standardattention entfielen beim Base-Text-zu-Bild 14,24 von 14,70 Sekunden auf das Entrauschen, etwa 96,8 %, und beim Base-Bild-zu-Bild 39,40 von 40,29 Sekunden, etwa 97,8 %. Das destillierte Modell brauchte für Text-zu-Bild 2,71 Sekunden, davon 84,0 % Entrauschen. Allein die NVFP4-Gewichte waren bei Text-zu-Bild bis zu 1,62-mal und bei Bild-zu-Bild 1,58-mal schneller als BF16.
Dann testet er mehrere Optimierungen, jede mit eigener Vergleichsbasis. Abgestimmte PrimsTS-Matrixmultiplikationskerne waren bei Text-zu-Bild 1,02- bis 1,10-mal schneller als die automatisch abgestimmte NVFP4-Version von TensorRT LLM. Attention machte etwa 60 % der Kernelzeit des Transformers aus, daher probierten die Autoren quantisierte und dünn besetzte Varianten. Im Vergleich zur Standard-BF16-Attention brachte cuDNN FP8 das 1,08-Fache für Base und das 1,09-Fache für das destillierte Modell, und VC-Attention FP8 mit einem Reparaturbudget von 0,005 das 1,18- und 1,16-Fache. Sol-Attention mit dem Sparsity-Parameter tau von 1,0 machte Entrauschen plus Dekodieren für Base mit 16 anfänglich dichten Schritten 1,24-mal und mit 12 1,30-mal schneller. Cache-DiT, das Zwischenausgaben über Schritte hinweg wiederverwendet, wenn ein Schwellenwert für die Residuumsdifferenz von 0,24 es erlaubt, brachte bei 1024 mal 1024 das 1,97-Fache für Base und das 1,26-Fache für das destillierte Modell, bei 2048 mal 2048 das 1,94- und 1,20-Fache.
Die Bildqualität wird mit LPIPS beurteilt, einem Wahrnehmungsabstand, berechnet gegen die nicht optimierte Ausgabe mit demselben Seed, wobei ein niedrigerer Wert näher bedeutet. Zu den im Beitrag genannten Werten gehören 0,033 für Cache-DiT bei Base, 0,086 für VC-Attention FP8 bei Base und 0,151 bis 0,161 für einige destillierte oder 12-Dichte-Schritte-Einstellungen, und der Beitrag sagt, ein höheres tau senke die Qualität bei kaum mehr Tempo. Die Beschleunigungen sind in Pixeln also nicht umsonst. Die Autoren schlagen 16 dichte Schritte für Treue oder 12 für Tempo vor und zeigen Beispielbilder, die Leser selbst vergleichen sollten.
Die Spitzenwerte kombinieren Schritte auf einer einzelnen B200 bei 2048 mal 2048, verglichen mit nicht kompiliertem BF16 für Base: Kompilierung, NVFP4 mit PrimsTS-Kernen, Sol-Attention und Cache-DiT ergaben das 3,46-Fache bei Text-zu-Bild, von 22,36 auf 6,46 Sekunden, und das 4,45-Fache bei Bild-zu-Bild, von 54,64 auf 12,28 Sekunden. Das destillierte Modell erreichte bis zum 2,34-Fachen. Auf einer einzelnen RTX PRO 6000 Blackwell Server Edition betrugen die Gewinne das 1,73- bis 3,25-Fache. Man beachte die Vergleichsbasis: Das sind Beschleunigungen gegenüber nicht kompiliertem BF16, nicht gegenüber den oben genannten kompilierten NVFP4-Werten, und die einzelnen Faktoren multiplizieren sich nicht einfach.
Bei mehreren GPUs nutzt VisualGen Classifier-free-Guidance-Parallelität und Ulysses-Sequenzparallelität. Auf einem NVIDIA DGX B200 mit acht GPUs sank bei 2048 mal 2048 die mediane Text-zu-Bild-Latenz bei Base von 14,90 auf 3,00 Sekunden und beim destillierten Modell von 2,73 auf 1,08 Sekunden. Das Entrauschen wurde 6,01- und 4,44-mal schneller, doch etwa die Hälfte der Acht-GPU-Zeit des destillierten Modells liegt außerhalb des Entrauschens und begrenzt den Gesamtgewinn. Bei 1024 mal 1024 senkten CUDA Graphs die Base-Latenz von 1,823 auf 0,809 Sekunden und die des destillierten Modells von 0,791 auf 0,366 Sekunden.
Für den Einsatz liefert der Beitrag einen Container-Befehl, ein Offline-Skript und einen OpenAI-kompatiblen Endpunkt /v1/images/generations, der mit trtllm-serve gestartet wird, sowie eine YAML-Datei je Einstellung. NVFP4 wählt man, indem man variant auf nvfp4 setzt. Auf acht GPUs nutzt das Base-Modell cfg_size 2 und ulysses_size 4, das destillierte Modell cfg_size 1 und ulysses_size 8. Das Referenz-Setup lädt außerdem einen Sicherheitsklassifikator, und die Modellkarte warnt, dass kurze, unverändert gesendete Prompts generische Ausgaben liefern, weshalb sie den Prompt-Erweiterer verlangt.
Die Grenzen sind wichtig. Die Ergebnisse betreffen NVIDIA-Blackwell-Rechenzentrums-GPUs und die RTX PRO 6000 Blackwell Server Edition, keine andere Hardware. Die Mittelwerte stammen aus 10 Anfragen nach zwei Aufwärmanfragen mit Seed 0, und der Beitrag nennt keine Streuung zwischen Läufen. Die berichteten Latenzen schließen BFLs Prompt-Erweiterer aus, den die Modellkarte immer auszuführen empfiehlt und der in der Referenzkonfiguration ein Modell mit 18,8 GB ist. Container-Tag und Code-Links zeigen auf einen Feature-Branch, feat/flux3-image-klein, nicht auf eine stabile Version. LPIPS ist ein automatisches Maß, und die Beispielbilder decken nur wenige Szenen ab, etwa eine Teeszene, eine Katze, ein Küchenstillleben und eine Kanu-Bearbeitung, sie zeigen also nicht, wie sich jede Einstellung bei jedem Prompt verhält. Wir haben keine Zahl nachgebildet.
Unsere Einordnung: Das ist ein praktisches, detailliertes Rezept mit echten Konfigurationsdateien, und es zeigt, wohin die Zeit geht. Wer FLUX 3 Klein auf Blackwell betreibt, kann NVFP4, Kompilierung und die Attention-Optionen ausprobieren und LPIPS sowie Bilder an der eigenen Qualitätsmarke prüfen. Wer andere GPUs oder eine stabile Version nutzt, sollte warten. Die größten Zahlen sind als Bestfälle aus den Tests eines einzelnen Anbieters zu lesen, und jeder Faktor gehört zu seiner eigenen Vergleichsbasis.
Sources
FAQ
Gegen welche Vergleichsbasis sind die Beschleunigungen von 3,46 und 4,45 gemessen?
Gegen die nicht kompilierte BF16-Inferenz des Base-Modells auf einer B200 bei 2048 mal 2048. Die Werte stapeln Kompilierung, NVFP4 mit PrimsTS-Kernen, Sol-Attention und Cache-DiT. Sie sind nicht gegen kompiliertes NVFP4 gemessen, und die einzelnen Faktoren multiplizieren sich nicht einfach. Das destillierte Modell erreichte bis zum 2,34-Fachen; alle Zahlen stammen von NVIDIA.
Verändern die schnelleren Einstellungen die erzeugten Bilder?
Ja. Der Beitrag misst LPIPS, den Abstand zur nicht optimierten Ausgabe mit demselben Seed: 0,033 für Cache-DiT bei Base und 0,151 bis 0,161 für einige Einstellungen. Er sagt auch, ein höheres tau senke die Qualität bei kaum mehr Tempo. Die Autoren schlagen 16 dichte Schritte für Treue oder 12 für Tempo vor und zeigen Beispielbilder zum Vergleich.
Gelten die Ergebnisse für alle GPUs und für veröffentlichte Software?
Nein. Sie betreffen NVIDIA-Blackwell-Rechenzentrums-GPUs und die RTX PRO 6000 Blackwell Server Edition. Container-Tag und Code-Links zeigen auf einen Feature-Branch, feat/flux3-image-klein, nicht auf eine stabile Version. Die Latenzen schließen BFLs Prompt-Erweiterer aus, und der Beitrag nennt keine Streuung zwischen Läufen.