Qwen-Image 2.1 Turbo : 30 images en 135 secondes sur une RTX 5090

Après Z-Image Turbo puis Qwen-Image-2512, je continue mon tour des modèles open source de génération d'images avec la nouvelle version de la famille Qwen d'Alibaba : Qwen-Image 2.1, dans sa déclinaison Turbo.

Le principe ne change pas : les 30 mêmes prompts que lors des tests précédents, sur la même machine, pour pouvoir comparer les résultats image par image. Et cette fois, la surprise vient surtout de la vitesse : là où Qwen-Image-2512 demandait une minute par image, la version 2.1 Turbo en produit une toutes les 4,3 secondes, en pleine précision.

Mais faire tourner ce modèle sur une carte de 32 Go n'a pas été aussi simple que prévu. Ce test a surtout été l'occasion de comprendre où passe vraiment la mémoire d'un pipeline de génération d'images moderne.

Même environnement que pour les tests précédents : une RTX 5090 (32 Go de VRAM) sous Windows, avec 32 Go de RAM et un CPU 7800X3D. Sur le papier, un modèle de 7 milliards de paramètres doit tenir sans difficulté. En pratique, le chiffre « 7B » ne décrit que le transformer. Le pipeline complet est une chaîne de trois modèles :

L'encodeur de texte pèse plus lourd que le modèle « principal ». Avec 1,6 Go de marge, il ne reste plus de place pour les activations, c'est-à-dire les tenseurs intermédiaires du calcul.

Le piège Windows : pas d'erreur, juste un PC qui rame

Sous Linux, dépasser la VRAM provoque immédiatement une erreur CUDA out of memory. Sous Windows, les pilotes NVIDIA récents ont une « Sysmem Fallback Policy » activée par défaut : quand la VRAM est pleine, le pilote déborde en silence dans la RAM système, via le bus PCIe.

Résultat du premier essai (pipe.to("cuda")) : aucune erreur, mais une génération bloquée à l'étape 0/8 pendant plus de 7 minutes. Le PCIe 5.0 x16 plafonne à ~64 Go/s, contre ~1,8 To/s pour la GDDR7 de la 5090 : chaque accès devient environ 30 fois plus lent, et tout le PC rame puisque la carte gère aussi l'affichage.

Le mode enable_model_cpu_offload() de diffusers fonctionne, lui, mais il immobilise ~30 Go de RAM et fait transiter des dizaines de Go par le PCIe à chaque image. Le PC devenait inutilisable et j'ai interrompu le test.

La solution : générer en deux phases

Plutôt que de tout charger en même temps, le script sépare le travail en deux phases, chacune 100 % sur le GPU :

Chaque modèle n'est chargé qu'une seule fois par lot, quel que soit le nombre de prompts, et on n'utilise jamais plus de la moitié de la carte à la fois. Bonus : si tous les prompts sont déjà en cache, l'encodeur n'est même pas chargé, ce qui fait gagner une vingtaine de secondes quand on relance avec d'autres graines.

Pourquoi le 2048×2048 coûte bien plus que 4 fois le 1024×1024

Le modèle vise nativement des formats d'environ 2K (2048×2048, 2752×1536…). Le VAE compresse l'image d'un facteur 16 dans chaque dimension, et le transformer traite chaque case de 16×16 pixels comme un token : 4 096 tokens en 1024×1024, 16 384 en 2048×2048. Or l'attention compare chaque token à tous les autres, son coût croît avec le carré du nombre de tokens. Mesuré sur la 5090 : 4 fois plus de pixels donnent 5,6 fois plus de temps (~25 s par image au lieu de 4,3 s).

Côté mémoire, le transformer s'en sort grâce à l'attention optimisée de PyTorch (SDPA). C'est le décodage VAE qui a planté en 2048×2048 : ses dernières couches travaillent à pleine résolution avec plus d'une centaine de canaux, en partie en float32. Un seul tenseur intermédiaire pèse déjà ~2,4 Go, et plusieurs coexistent. La correction tient en une ligne : pipe.vae.enable_tiling(), qui décode l'image par tuiles qui se recouvrent puis les assemble. La mémoire devient bornée par la taille d'une tuile, sans jointure visible.

Pour ce test, j'ai gardé le 1024×1024 par défaut, pour comparer avec les articles précédents.

Lot de 30 prompts longs (jusqu'à ~950 caractères), 1024×1024, graine 42. Chaque durée est enregistrée image par image dans un fichier CSV.

Le temps de génération ne dépend pas de la longueur du prompt : une fois les embeddings calculés, le transformer travaille toujours sur la même quantité de tokens image. La première image est un peu plus lente (préchauffage du GPU), les 29 suivantes tombent toutes entre 4,28 et 4,45 secondes.

Comparatif avec les modèles déjà testés

Toutes les mesures ont été faites sur la même RTX 5090 en 1024×1024. Qwen-Image 2.1 Turbo est environ 14 fois plus rapide que Qwen-Image-2512, tout en tournant en pleine précision là où la 2512 devait être quantifiée en 4-bit pour tenir sur la carte.

Prérequis

1. Installer PyTorch avec CUDA 12.8

Indispensable pour une RTX 50xx (Blackwell, sm_120) : les versions standard de PyTorch sur PyPI ne la prennent pas en charge.

pip install torch torchvision --index-url https://download.pytorch.org/whl/cu128

2. Installer diffusers depuis GitHub

La classe QwenImage21Pipeline et le planning de 8 étapes du checkpoint ne sont disponibles que dans la version source.

pip install git+https://github.com/huggingface/diffusers.git
pip install "transformers>=5.17.0" accelerate pillow

Versions validées : torch 2.11.0+cu128, diffusers 0.41.0.dev0, transformers 5.19.0, accelerate 1.15.0. Prévoir ~60 Go de disque : le modèle seul pèse ~30 Go dans le cache Hugging Face.

Script de génération en deux phases

Version simplifiée du script utilisé pour ce test (sans le cache disque, l'aperçu en direct ni le CSV des durées) :

import gc
import os
os.environ.setdefault("PYTORCH_CUDA_ALLOC_CONF", "expandable_segments:True")

import torch
from diffusers import QwenImage21Pipeline

MODEL_ID = "Qwen/Qwen-Image-2.1-Turbo"
prompts = [
    "A weathered lighthouse keeper in his 70s standing at the top of a spiral staircase...",
    "An abandoned Art Deco theater overgrown with bioluminescent mushrooms...",
]

# Phase 1 : encodeur de texte seul (~16 Go), puis libéré
pipe = QwenImage21Pipeline.from_pretrained(
    MODEL_ID, transformer=None, vae=None, dtype=torch.bfloat16
).to("cuda")
with torch.inference_mode():
    embeds = [pipe.encode_prompt(prompt=p, device="cuda")[:2] for p in prompts]
del pipe
gc.collect()
torch.cuda.empty_cache()

# Phase 2 : transformer + VAE (~14 Go), sans l'encodeur
pipe = QwenImage21Pipeline.from_pretrained(
    MODEL_ID, text_encoder=None, dtype=torch.bfloat16
).to("cuda")
pipe.vae.enable_tiling()  # indispensable au-delà de 1024×1024

for i, (pe, mask) in enumerate(embeds):
    image = pipe(
        prompt_embeds=pe,
        prompt_embeds_mask=mask,
        width=1024,
        height=1024,
        use_kv_cache=True,
        generator=torch.Generator("cpu").manual_seed(42),
    ).images[0]
    image.save(f"image_{i + 1:02d}.png")

Conseil pour Windows

Si la génération reste figée à 0/8 et que le PC rame, c'est presque toujours un débordement silencieux de la VRAM vers la RAM. Fermez les applications qui utilisent le GPU (jeux, Blender, navigateur avec accélération matérielle). Dans le Panneau de configuration NVIDIA, le réglage CUDA – Sysmem Fallback Policy sur Prefer No Sysmem Fallback permet d'obtenir une vraie erreur au lieu d'un ralentissement.

Ce qui m'a convaincu

• Un rendu plus photographique : lumières plus naturelles, couleurs moins saturées, ambiances plus sombres et cinématographiques. Le marché aux épices (image 6), le vendeur de pad thaï (image 11) ou l'imprimeur japonais (image 16) ressemblent à de vraies photos, avec beaucoup moins cet « aspect IA » trop lisse et trop coloré.
• La compréhension des quantités : les douze morceaux de verre de la scène de crime (image 19) sont disposés de façon cohérente, et la station arctique (image 25) aligne une grille de fenêtres éclairées, chacune avec son reflet d'aurore.
• Les styles artistiques : la peinture à l'encre chinoise qui prend vie (image 27) et la chambre d'enfant façon gouache (image 13) sont parmi les plus réussies des trois modèles.

Ce qui pèche encore

• Des éléments du prompt oubliés : la sirène de la cathédrale sous-marine (image 12) devient une statue lointaine, et la bibliothèque impossible (image 30) perd son bibliothécaire à huit bras.
• Les scènes surréalistes : la cathédrale façon Escher (image 17) reste une cathédrale « normale », alors que Qwen-Image-2512 avait réellement joué avec les directions de gravité.
• Quelques contresens : le cosmonaute russe (image 14) porte une combinaison NASA avec un drapeau américain, et la baleine mécanique (image 4) a très peu de rouages visibles.

En résumé : sur les prompts « réalistes », Qwen-Image 2.1 Turbo est à mon sens le plus convaincant des trois. Sur les prompts très chargés ou volontairement absurdes, Qwen-Image-2512 reste plus fidèle, mais au prix d'une génération 14 fois plus lente.

Résumé des limitations

• Un pipeline plus gros qu'annoncé : 30 Go de poids en BF16 malgré le « 7B ». Sur une carte de 32 Go, il faut séparer encodeur et générateur.
• Diffusers en version de développement : la pipeline n'est pas encore dans la version publiée sur PyPI.
• Le 2K natif reste coûteux : ~25 s par image en 2048×2048, avec le décodage VAE par tuiles obligatoire.
• Pas de quantification adaptée à la Turbo : les versions communautaires existantes (FP8, NVFP4, GGUF) visent la version de base ou ComfyUI, pas la Turbo dans diffusers.

Prochaines étapes

• Un service d'encodage distant : faire tourner l'encodeur Qwen3-VL sur un autre serveur GPU, pour ne garder que le transformer et le VAE (~14 Go) chargés en permanence sur la 5090. Attention, un endpoint /v1/embeddings standard (OpenAI, vLLM, TEI) ne convient pas : le pipeline attend la séquence complète des embeddings par token, avec son gabarit de prompt exact.
• Un mode serveur : garder le modèle chargé et exposer une API HTTP locale.
• L'édition d'image : le même pipeline accepte une image de référence, que l'encodeur vision-langage sait lire.