NVIDIA montre comment TensorRT LLM VisualGen accélère FLUX 3 Image Klein sur Blackwell : jusqu'à 3,46 fois en texte vers image et 4,45 fois en image vers image pour Base en 2048×2048 sur un B200 face au BF16 non compilé, mais ces chiffres sont ceux de NVIDIA sur une branche de fonctionnalité et des réglages plus rapides modifient les images

Le 6 novembre 2026, NVIDIA a publié un tutoriel technique pour exécuter plus vite FLUX 3 Image Klein sur des GPU Blackwell avec TensorRT LLM VisualGen, un environnement d'exécution pour modèles de diffusion intégré à TensorRT LLM. FLUX 3 Image Klein est un modèle de génération et d'édition d'images de Black Forest Labs (BFL). Il existe en point de contrôle Base non distillé, qui utilise 50 étapes de débruitage et un coefficient de guidage de 3,5, et en point de contrôle distillé, qui utilise 16 étapes sans guidage. La fiche du modèle indique un transformeur d'image de 5,6 milliards de paramètres, avec Qwen3-VL-4B-Instruct comme encodeur de texte séparé, jusqu'à 10 images de référence, des variantes BF16, FP8 et NVFP4, et la FLUX Kommunity License, qui autorise l'usage non commercial et prévoit une exception pour les sorties commerciales des utilisateurs éligibles. L'article dit que BFL a entraîné le modèle sur des systèmes NVIDIA GB200 NVL72 et l'a optimisé pour les GPU NVIDIA : c'est donc un tutoriel de fournisseur pour son propre matériel. Toutes les durées ci-dessous sont celles de NVIDIA.

L'article décompose d'abord où passe le temps. À 2048 par 2048 pixels sur un GPU NVIDIA B200, avec des poids NVFP4, torch.compile et l'attention standard, le débruitage a pris 14,24 secondes sur 14,70 pour le Base en texte vers image, soit environ 96,8 %, et 39,40 secondes sur 40,29 pour le Base en image vers image, soit environ 97,8 %. Le modèle distillé a pris 2,71 secondes en texte vers image, dont 84,0 % de débruitage. Les poids NVFP4 seuls étaient jusqu'à 1,62 fois plus rapides en texte vers image et 1,58 fois en image vers image que le BF16.

Il teste ensuite plusieurs optimisations, chacune avec sa propre référence. Les noyaux de multiplication matricielle PrimsTS réglés étaient 1,02 à 1,10 fois plus rapides que la version NVFP4 de TensorRT LLM réglée automatiquement, en texte vers image. L'attention représentait environ 60 % du temps de noyau du transformeur, et les auteurs ont donc essayé des variantes quantifiées et creuses. Par rapport à l'attention BF16 standard, cuDNN FP8 a donné 1,08 fois pour le Base et 1,09 fois pour le distillé, et VC-Attention FP8 avec un budget de réparation de 0,005 a donné 1,18 et 1,16 fois. Sol-Attention avec son paramètre de parcimonie tau à 1,0 a donné un débruitage plus décodage 1,24 fois plus rapide pour le Base avec 16 étapes initiales denses, ou 1,30 fois avec 12. Cache-DiT, qui réutilise les sorties intermédiaires d'une étape à l'autre lorsqu'un seuil de différence résiduelle de 0,24 le permet, a donné 1,97 fois pour le Base et 1,26 fois pour le distillé en 1024 par 1024, et 1,94 et 1,20 fois en 2048 par 2048.

La qualité d'image est jugée avec LPIPS, une distance perceptuelle, calculée par rapport à la sortie non optimisée pour la même graine, une valeur plus basse signifiant plus proche. Les valeurs citées dans l'article comprennent 0,033 pour Cache-DiT sur le Base, 0,086 pour VC-Attention FP8 sur le Base et 0,151 à 0,161 pour certains réglages distillés ou à 12 étapes denses, et l'article dit qu'un tau plus élevé réduisait la qualité pour très peu de vitesse en plus. Les accélérations ne sont donc pas gratuites en pixels. Les auteurs suggèrent 16 étapes denses pour la fidélité ou 12 pour la vitesse, et montrent des exemples que les lecteurs doivent comparer eux-mêmes.

Les résultats phares combinent des étapes sur un seul B200 en 2048 par 2048, comparés au BF16 non compilé pour le Base : la compilation, NVFP4 avec les noyaux PrimsTS, Sol-Attention et Cache-DiT ont donné 3,46 fois en texte vers image, de 22,36 à 6,46 secondes, et 4,45 fois en image vers image, de 54,64 à 12,28 secondes. Le modèle distillé a atteint jusqu'à 2,34 fois. Sur un seul GPU RTX PRO 6000 Blackwell Server Edition, les gains étaient de 1,73 à 3,25 fois. Attention à la référence : ce sont des accélérations par rapport au BF16 non compilé, pas par rapport aux chiffres NVFP4 compilés plus haut, et les facteurs individuels ne se multiplient pas simplement.

Pour plusieurs GPU, VisualGen utilise le parallélisme du guidage sans classifieur et le parallélisme de séquence Ulysses. Sur un NVIDIA DGX B200 à huit GPU en 2048 par 2048, la latence médiane en texte vers image est passée de 14,90 à 3,00 secondes pour le Base et de 2,73 à 1,08 seconde pour le distillé. Le débruitage a été accéléré de 6,01 et 4,44 fois, mais environ la moitié du temps du distillé sur huit GPU se passe hors débruitage, ce qui limite le gain de bout en bout. En 1024 par 1024, CUDA Graphs a ramené la latence du Base de 1,823 à 0,809 seconde et celle du distillé de 0,791 à 0,366 seconde.

Pour le déploiement, l'article fournit une commande de conteneur, un script hors ligne et un point d'accès /v1/images/generations compatible OpenAI lancé avec trtllm-serve, ainsi qu'un fichier YAML par réglage. NVFP4 se choisit en réglant variant sur nvfp4. Sur huit GPU, le modèle Base utilise cfg_size à 2 et ulysses_size à 4, et le modèle distillé cfg_size à 1 et ulysses_size à 8. La configuration de référence charge aussi un classifieur de sécurité, et la fiche du modèle avertit que des prompts courts envoyés tels quels donnent des sorties génériques, d'où la demande d'exécuter l'extenseur.

Les limites comptent. Les résultats couvrent les GPU de centre de données NVIDIA Blackwell et le RTX PRO 6000 Blackwell Server Edition, pas d'autres matériels. Les moyennes viennent de 10 requêtes après deux échauffements avec la graine 0, et l'article ne donne aucune dispersion entre exécutions. Les latences rapportées excluent l'extenseur de prompt de BFL, que la fiche du modèle demande d'exécuter toujours et qui est un modèle de 18,8 Go dans la configuration de référence. L'étiquette du conteneur et les liens de code pointent vers une branche de fonctionnalité, feat/flux3-image-klein, et non vers une version stable. LPIPS est une mesure automatique, et les images d'exemple ne couvrent que quelques scènes, comme une scène de thé, un chat, une nature morte de cuisine et l'édition d'un canoë : elles ne montrent pas le comportement de chaque réglage sur tous les prompts. Nous n'avons reproduit aucun chiffre.

Notre lecture : c'est une recette pratique et détaillée, avec de vrais fichiers de configuration, qui montre où passe le temps. Ceux qui servent FLUX 3 Klein sur Blackwell peuvent essayer NVFP4, la compilation et les options d'attention, puis vérifier LPIPS et les images avec leur propre exigence de qualité. Ceux qui utilisent d'autres GPU ou une version stable devraient attendre. Il faut traiter les plus grands chiffres comme des meilleurs cas issus des tests d'un seul fournisseur, et lire chaque facteur par rapport à sa propre référence.