SGLang-Diffusion sert Qwen-Image-2.1 dès le jour zéro : générations en 2,75 s sur un seul B200

Qwen-Image-2.1 a été rendu public le 20 septembre 2026, et l'équipe SGLang-Diffusion disposait déjà d'une voie de service qui l'attendait. La prise en charge dès le premier jour couvre les trois tâches que le modèle effectue — génération texte-image, édition multi-images et sortie RGBA transparente — et elle s'accompagne de quelque chose de plus rare qu'une pull request fusionnée : une latence mesurée sur du matériel nommé, publiée avec la configuration qui l'a produite. Sur un seul NVIDIA B200, en 1024×1024 à 40 étapes, les chiffres de SGLang s'établissent à 2,748 secondes pour une génération et 3,358 secondes pour une édition. La pull request associée, sgl-project/sglang#39983, a été ouverte le 17 septembre — trois jours avant que les poids ne soient téléchargeables —, ce qui explique pourquoi ces chiffres existent bel et bien, plutôt que d'être promis pour plus tard.

Ce que signifie « jour zéro » ici, et pourquoi le timing est la partie intéressante.

La prise en charge des frameworks est généralement annoncée en même temps qu’une sortie de modèle, puis livrée quelques semaines plus tard. Le cas de SGLang est inverse. L’implémentation a été écrite contre un checkpoint qui n’était pas encore public, ce qui force les auteurs à traiter l’architecture réelle plutôt qu’une fiche de spécifications : le transformer de diffusion, le VAE RGBA à 64 canaux, le conditionnement Qwen3-VL, l’entrée multi-images de référence, et le RGBA en entrée comme en sortie.

C’est la raison pour laquelle il faut faire davantage confiance à un tableau de latence qu’à une liste de capacités. Un modèle qui n’a jamais été servi n’a aucun chiffre mesuré, et un chiffre accompagné de son matériel, de sa résolution, de son nombre d’étapes et de sa précision peut être vérifié par quiconque possède la même carte. Les chiffres de SGLang sont présentés comme une configuration spécifique, et non comme une affirmation générale sur le modèle.

Le reste de l'outillage est arrivé dans la même fenêtre. ComfyUI a publié une prise en charge native, Diffusers a fusionné QwenImage21Pipeline, vLLM-Omni a ajouté l'exécution pas à pas et la quantification FP8, et LightX2V a ajouté l'accélération avec la prise en charge d'AMD Radeon via ROCm. Les frameworks sont la partie d'une version qui détermine si quelqu'un en dehors d'un laboratoire peut l'utiliser.

Les chiffres, et ce qu’ils ne disent pas

Le travail sur SGLang publie la latence par requête, pas le débit. Cette distinction compte si vous dimensionnez un service plutôt que si vous lancez une démo : une génération unique de 2,7 seconde vous indique le temps aller-retour, pas combien d'utilisateurs simultanés une carte peut absorber. Les configurations publiées, toutes en 1024×1024 et 40 étapes :

• B200, poids résidents, FlashAttention — 2,748 s de génération, 3,358 s d'édition, après une correction de la norme Q/K et une modification de LayerNorm qui ont chacune gagné quelques pourcents.
• RTX PRO 6000 Blackwell, 96 Go, résident — 8,23 s de génération, 9,85 s d'édition avec un pic d'empreinte de 40,1 GiB ; 10,28 s et 10,66 s avec le transformer de diffusion déchargé, ce qui fait chuter le pic à 26,1 GiB.
• DGX Spark, 1× GB10, eager, décodage VAE complet — 35,36 s de génération, 42,23 s d'édition, 35,49 s et 42,21 s pour les variantes transparentes. Celles-ci incluent la sérialisation PNG. Les graphes CUDA découpables ont produit des pixels identiques sans gain de vitesse mesurable (35,96 s contre 35,64 s), et le traitement par lots ainsi que les configurations multi-Spark n'ont pas du tout été évalués.
• RTX 4090, 24 Go, déchargement couche par couche, débruitage uniquement — 26,69 s en BF16 de base avec SDPA, 10,31 s avec Cache-DiT (2,59×), 5,59 s avec Cache-DiT plus le jeu de noyaux INT8 (4,77×), 4,74 s en ajoutant l'attention Sage (5,63×).

Deux réserves honnêtes accompagnent ces lignes. Premièrement, ce sont des latences de requête unique, et la ligne 4090 ne mesure que le débruitage — l'encodeur de texte et le VAE sont en dehors du chronomètre. Deuxièmement, les auteurs de SGLang présentent la vérification plus large comme fonctionnelle, et non évaluative : la sortie BF16 n'est pas bit-exacte selon les différents placements, et la quantification ou le parallélisme tensoriel modifie les chiffres. Plus rapide et différent n'est pas synonyme de plus rapide et meilleur.

Pourquoi le chemin de sortie transparent est celui à surveiller

RGBA est ce qui distingue ce modèle des points de terminaison d’images que la plupart des équipes appellent déjà, et c’est aussi là que le serving devient délicat. Qwen-Image-2.1 débruite dans un espace latent qui comporte un canal alpha comme composant à part entière, via un VAE RGBA à 64 canaux avec une compression spatiale de 16×. La transparence n’est pas un post-traitement que l’on greffe avec un modèle de segmentation ; c’est ce que l’échantillonneur émet.

Servir cela correctement est plus difficile que de servir du RGB. La sortie est plus volumineuse, le VAE a davantage de canaux à décoder, et la requête transporte un bit de mode supplémentaire que le planificateur doit acheminer. La vérification de SGLang couvre exactement cette surface — sortie PNG transparente, canal alpha conservé sur toute la plage 0–255, et un PSNR RGBA de 60,69 dB sur un seul échantillon, les configurations FP8 réussissant également la génération transparente. Il s'agit d'un contrôle de correction plutôt que d'un benchmark de qualité, et les auteurs le disent. Cela établit que le canal alpha est réel et survit à la quantification ; cela ne dit rien sur la propreté des bords sur les cheveux, la fourrure ou le verre.

La valeur pratique d'une pile de service dotée d'un chemin de transparence éprouvé réside dans le fait qu'elle transforme un pipeline à trois outils en un seul appel. La génération avec alpha, l'édition à l'intérieur d'une image qui possède déjà un canal alpha et l'extraction d'un sujet d'une photographie RVB ordinaire vers une couche transparente passent toutes par le même point de terminaison.

Où cela s'inscrit si vous ne faites pas tourner le GPU vous-même

Le côté délicat de la sortie de Qwen-Image-2.1, c'est qu'il n'existe aucun point de terminaison hébergé à appeler. Les poids représentent un téléchargement d'environ 33 GB, le composant de génération est un transformer de diffusion 7B associé à un encodeur de texte Qwen3-VL 8B, et l'ensemble est distribué sous la Qwen Research License Agreement datée du 20 septembre 2026 — usage non commercial uniquement, tout déploiement commercial nécessitant une licence distincte auprès du fournisseur. La recette SGLang n'est donc pas une alternative à une API. C'est l'API, et c'est vous l'opérateur.

Cela change la raison d'être d'une couche de routage. OrcaRouter place plus de 200 modèles derrière un unique point de terminaison compatible OpenAI, au prix catalogue du fournisseur et sans marge, avec basculement automatique entre fournisseurs, un DSL de routage pour composer des solutions de repli, et une fusion de modèles pour les appels de type panel — mais il ne route aucun modèle Qwen-Image, quelle qu'en soit la version, et Qwen-Image-2.1 ne sera jamais une route que vous pourrez y appeler. L'architecture réaliste est scindée : exécutez Qwen-Image-2.1 sur votre propre matériel via SGLang pour le travail transparent et multi-références, et envoyez tout le reste vers des modèles d'images hébergés avec une seule clé. Notre catalogue comprend la gamme OpenAI GPT-Image, les paliers d'Imagen 4 de Google et les aperçus d'images Gemini, ainsi que le point de terminaison d'images Grok Imagine de xAI, tous au prix catalogue répercuté tel quel, si bien qu'un changement de prix d'un fournisseur sur l'un d'eux est effectif chez nous le jour même.

À quoi ressemble réellement un déploiement

La documentation SGLang fournit un guide pratique pour ce modèle, avec des commandes par GPU, et l'invocation serveur recommandée tient en une seule ligne — sglang serve --model-path Qwen/Qwen-Image-2.1 --performance-mode speed. Les requêtes text-to-image prennent en charge la mise en lots dynamique à activation explicite ; les requêtes d'édition d'image sont traitées par un chemin distinct, et une seule requête peut renvoyer plusieurs résultats.

Les configurations réellement vérifiées sont plus étroites que ne le laisse entendre la matrice de compatibilité. H200, B200, RTX PRO 6000 96 GB, RTX 5090 et RTX 4090 sont prises en charge pour la génération et l’édition en 1024×1024 à 40 étapes, y compris leurs variantes transparentes, ainsi que pour le parallélisme tensoriel multi-GPU, l’attention Ulysses et Ring, l’offload couche par couche, le décodage VAE tuilé parallèle, Cache-DiT, les graphes CUDA et la quantification FP8 en ligne et sérialisée. Les recettes multi-GPU et NVFP4 sur RTX PRO 6000 restent non vérifiées, et le RDMA multi-hôtes ainsi que les rôles désagrégés multi-rangs ne sont pas couverts. Si votre plan implique quatre cartes et un fabric, vous êtes en avance sur les preuves publiées.

Deux choses à surveiller ensuite. La première est de savoir si quelqu’un publie le débit plutôt que la latence — les chiffres de concurrence sont ce qui transforme un résultat de 2,7 secondes en un plan de capacité. La seconde est la licence : il n’existe ni prix publié ni feuille de conditions pour l’utilisation commerciale de Qwen-Image-2.1, et tant qu’il n’y en aura pas, la restriction non commerciale est tout ce qu’il y a à savoir pour tout ce qui est livré à un client.