Qwen-Image-2.1-Turbo vs Qwen-Image-2.1 : ce qui a réellement changé entre le checkpoint de base et la version accélérée

Même composant de génération visuelle 7B. Mêmes 32 couches DiT à flux unique. Mêmes sept préréglages de résolution, même interface unifiée de génération et d'édition, même licence non commerciale, même classe de pipeline pour le charger. Qwen-Image-2.1-Turbo et Qwen-Image-2.1 ne sont pas deux modèles entre lesquels choisir selon les capacités — le checkpoint Turbo est un fine-tune du modèle de base, et le dépôt le dit dans ses propres métadonnées. Ce qui les sépare, c'est une seule trajectoire d'échantillonnage, et la manière dont cette trajectoire est stockée. L'un exécute quarante étapes. L'autre en exécute huit, et refuse qu'on lui dise le contraire au moment de l'appel. Tout ce qu'il y a d'intéressant dans ce duo tient dans cette deuxième phrase.

Commencez par les parties qui sont identiques

Avant les différences, la similitude mérite d’être cartographiée, car elle est plus étendue que ne le suggère l’étiquette « Turbo », et c’est ce qui rend l’échange attrayant.

• L’architecture. La fiche Turbo indique qu’il « utilise la même architecture de génération visuelle 7B » que Qwen-Image-2.1. Le projet décrit ce composant comme 7B de paramètres répartis sur 32 couches DiT Single-Stream. Rien dans le dépôt Turbo n’annonce un backbone plus petit, élagué ou réarchitecturé.

• Les capacités.Les deux checkpoints sont décrits comme effectuant la génération d'images à partir de texte et l'édition d'images. Turbo hérite de la surface du modèle de base plutôt que de la reformuler : la fiche du modèle de base documente la transparence RGBA native, jusqu'à 10 images de référence, et des modifications locales spécifiées par des cercles, des annotations peintes ou des masques distincts, avec préservation de l'identité pour les personnes et les produits.

• Les résolutions.La fiche de Turbo indique d’« utiliser les mêmes préréglages de résolution que Qwen-Image-2.1 », puis les énumère : 1:1 en 2048 × 2048, 4:3 en 2400 × 1792, 3:4 en 1792 × 2400, 3:2 en 2528 × 1696, 2:3 en 1696 × 2528, 16:9 en 2752 × 1536 et 9:16 en 1536 × 2752. La fiche du modèle de base liste le tableau identique. Les deux fiches utilisent le niveau de résolution 2048 pour leurs exemples.

• Le chemin de chargement. Les deux se chargent via QwenImage21Pipeline dans Diffusers. Le démarrage rapide de la fiche Turbo correspond à celui de la fiche de base, avec le nom du checkpoint modifié et bfloat16 écrit dtype au lieu de torch_dtype.

• Les documents administratifs.Les deux sont sous licence selon l'accord de licence de recherche Qwen-Image-2.1, les deux portent license: other avec license_name: qwen-research, et les deux ont un fichier LICENSE dans le dépôt, à côté des poids.

Si vous avez déjà Qwen-Image-2.1 en place, alors la surface de migration est vraiment réduite. C’est précisément pourquoi il vaut la peine de s’attarder sur le seul argument qui ne se comporte pas comme vous l’attendez.

Le planning a quitté votre code pour rejoindre le point de contrôle.

Sur le modèle de base, c'est vous qui définissez le nombre d'étapes. L'exemple texte-vers-image de la carte Qwen-Image-2.1, son exemple d'édition et son exemple de transparence RGBA passent tous num_inference_steps=40, et ce nombre est un argument fourni au moment de l'appel, comme le veut l'usage habituel de Diffusers. Rien sur cette carte ne vous dit que le checkpoint a des opinions sur le programme d'inférence.

Sur Turbo, le planning fait partie des métadonnées du checkpoint. La fiche indique que le checkpoint « inclut son planning d’échantillonnage recommandé, de sorte qu’il est prêt à l’emploi sans avoir à configurer manuellement le planificateur », puis, dans la section sur l’échantillonnage, précise ce que cela signifie en pratique : « Le planning d’échantillonnage recommandé en 8 étapes est enregistré avec le checkpoint et chargé automatiquement. Définir num_inference_steps à lui seul ne le remplace pas. »

Deux choses s'ensuivent, et il est facile de se tromper sur l'une comme sur l'autre, mais dans des directions opposées.

Le premier point, c’est que huit n’est pas une valeur par défaut que l’on peut ajuster à la hausse. Si vous voulez savoir à quoi ressemble Turbo à douze étapes ou à vingt, la fiche vous indique que la seule voie possible est un argument sigmas explicite au moment de l’appel — puis elle ferme la porte à l’expérimentation en précisant que d’autres planifications « n’ont pas été évaluées pour ce checkpoint ». C’est un fournisseur qui vous dit que la configuration en huit étapes est celle qu’il cautionne, et que tout le reste est un territoire inexploré dans lequel vous vous aventurez seul. C’est une phrase d’une honnêteté inhabituelle, et elle doit être lue comme une limite plutôt que comme une invitation.

Le deuxième est un piège de reproduction sans aucun message d’erreur associé. Prenez l’exemple du modèle de base, remplacez la chaîne du dépôt par celle du checkpoint Turbo, laissez num_inference_steps=40 en place, et le code s’exécutera. Il ne vous avertira pas. Il produira une image à l’aide du programme de huit étapes enregistré, et ce ne sera pas la sortie qu’affiche la vitrine Turbo, car quarante n’a jamais été lu. C’est le mode de défaillance où rien ne semble cassé — le rendu se termine, l’image est plausible, et la seule façon de le découvrir est d’aller chercher une différence. Une deuxième dépendance est enfouie à côté : le checkpoint a besoin d’une version de Diffusers qui comprend les sigmas d’échantillonnage configurés au niveau du pipeline, ajoutés dans la PR #14950, qui, au moment de la rédaction, se trouve dans l’arborescence source de Diffusers plutôt que dans une version étiquetée. L’installation indiquée est une version de PyTorch compatible CUDA ainsi que la source de Diffusers, transformers>=5.17.0, accelerate et pillow.

Qu'est-ce qui paie pour les 32 pas que tu n'as pas faits

La carte nomme deux mécanismes, et il vaut la peine de connaître les deux, car ils expliquent ce que le Turbo checkpoint suppose sur la manière dont vous l'appellerez.

• CFG 1 par défaut.« La génération utilise CFG=1 par défaut. » À une échelle de guidage sans classifieur égale à un, le modèle n'effectue pas la seconde passe inconditionnelle que le CFG requiert normalement — ce qui explique en grande partie comment une trajectoire est raccourcie sans être simplement tronquée. Cela signifie aussi que l'habitude du modèle de base de régler une échelle de guidage ne se transpose pas ; il n'y a rien à régler ici, et la fiche ne propose aucune recommandation de guidage à laquelle se régler.

• Mise en cache KV de préfixe. La fiche de Turbo indique que « la mise en cache KV de préfixe réutilise le contexte du texte et de l'image de référence d'une étape de débruitage à l'autre ». Il s'agit d'un mécanisme hérité, et non d'un élément nouveau propre au checkpoint accéléré : l'annonce de Qwen-Image-2.1 classe la réutilisation du cache KV de préfixe parmi les quatre améliorations phares du modèle de base, aux côtés de l'attention à granularité mixte, et les intégrations de serving dès le jour zéro pour le modèle de base — les entrées vLLM-Omni et SGLang dans la liste d'actualités du projet — mentionnent explicitement la mise en cache KV de préfixe parmi les fonctionnalités qu'elles prennent en charge. Dans une boucle de quarante étapes, cette réutilisation est une optimisation. Dans une boucle de huit étapes, elle compte proportionnellement davantage, car chaque étape mise en cache représente une part plus importante du travail total.

Ce que la fiche ne nomme pas, c’est une quelconque technique de distillation. La fiche Qwen-Image-2.1 du modèle de base et le README du projet décrivent l’architecture et les capacités ; la fiche Turbo décrit les mécanismes. Si vous cherchez à raisonner sur ce que huit étapes coûtent en termes de qualité, le dépôt ne vous donne aucune méthode à partir de laquelle raisonner — seulement un planning et un ensemble d’images de démonstration.

Le nombre de pas n'est pas une référence.

C'est la partie de la comparaison où la réponse honnête est qu'il n'y a pas de comparaison, et il vaut la peine d'être direct sur le pourquoi.

• Le checkpoint Turbo n'a aucun score publié. Sa fiche ne comporte aucun chiffre d'évaluation, quel qu'il soit. Il n'existe aucun résultat Qwen-Image-Bench pour Turbo, aucune comparaison côte à côte avec le checkpoint de base, aucune ablation sur le nombre d'étapes, et aucun tableau montrant à quel niveau la qualité plafonne.

• Le score du checkpoint de base est déclaré par le fournisseur. Le seul chiffre phare de la gamme Qwen-Image-2.1 est le résultat Qwen-Image-Bench du modèle de base lui-même, rapporté par le fournisseur pour le checkpoint de base. Il ne s'agit pas d'une mesure du checkpoint Turbo et il ne doit pas lui être transféré — l'accélération est exactement ce qui serait susceptible de faire bouger un tel chiffre, et le fournisseur n'a pas indiqué dans quelle mesure.

• Aucune des deux fiches ne rapporte de temps ni de mémoire. Il n’y a aucune valeur de latence, aucune valeur de débit et aucune empreinte mémoire pour aucun des deux checkpoints, et aucune des deux fiches n’indique le matériel sur lequel ses exemples ont été exécutés. La fiche du modèle de base documente au moins une section d’optimisation de la mémoire ; la fiche Turbo documente l’installation, la génération, l’édition, l’échantillonnage et les ratios d’aspect, puis s’arrête là.

Ainsi, l’argument en faveur de Turbo plutôt que du checkpoint de base porte actuellement sur l’intention de conception, pas sur des résultats mesurés. Huit étapes avec la même architecture et le même niveau de résolution 2048 devraient coûter sensiblement moins par image. Le mot « sensiblement » joue un rôle déterminant dans cette phrase, et la seule façon de le remplacer par un chiffre est d’exécuter les deux checkpoints sur votre propre charge de travail, ce qui est aussi la seule façon de découvrir ce que la trajectoire raccourcie fait aux images particulières qui vous importent.

Rien d'autre n'a été déplacé, y compris la licence.

Deux choses qu'un lecteur pourrait raisonnablement s'attendre à voir changées, et qui ne l'ont pas été.

Le premier est l’écosystème. Lorsque Qwen-Image-2.1 est sorti le 20 septembre 2026, la liste d’actualités du projet a recensé, le jour même, cinq intégrations distinctes dès le premier jour : la prise en charge de Diffusers via la PR #14804, la prise en charge native de ComfyUI avec des modèles de workflow publiés pour la génération d’images à partir de texte et l’édition, la prise en charge de vLLM-Omni avec exécution pas à pas, décodage CUDA Graph, quantification FP8 et parallélisme tensoriel, la prise en charge de SGLang avec Cache-DiT et déchargement de composants, et l’accélération apportée par le projet LightX2V. L’entrée datée du 9 octobre 2026 qui couvre Qwen-Image-2.1-Turbo consigne le checkpoint lui-même et une note indiquant que les API Pro et Turbo sont disponibles sur Alibaba Cloud Model Studio. Il n’existe pas de liste de frameworks dès le premier jour pour Turbo, et chaque entrée de framework dans la liste d’actualités renvoie encore au modèle de base. Le checkpoint Turbo se charge via une classe de pipeline qui existait déjà ; la prise en charge de sa planification enregistrée est le seul élément nouveau, et elle arrive via le code source de Diffusers plutôt que par une version étiquetée.

La deuxième est la licence. Turbo porte l'accord de licence de recherche Qwen, exactement comme le modèle de base. L'accélération ne s'est pas accompagnée d'une dérogation commerciale, d'un palier séparé ou d'un assouplissement des conditions — la restriction non commerciale s'applique au modèle affiné autant qu'au modèle de base. Les métadonnées du dépôt lui-même et le fichier de licence à côté des poids sont la preuve ; la section licence de la carte est une phrase qui renvoie au même accord. Si la raison pour laquelle huit étapes vous importent est qu'elles rendent le modèle suffisamment bon marché pour être intégré à un produit, la licence est clairement un obstacle, et c'est le fournisseur — et non ce dépôt — qui doit en répondre.

Points de terminaison hébergés, et où OrcaRouter s'intègre

OrcaRouter ne route ni Qwen-Image-2.1-Turbo ni Qwen-Image-2.1. Tous deux sont absents de notre catalogue, et rien ici ne constitue une offre de servir l’un ou l’autre. Si vous les voulez, vos voies sont les API hébergées du fournisseur lui-même, plusieurs plateformes tierces, ou les poids avec une version de Diffusers assez récente pour gérer le programme d’échantillonnage enregistré du checkpoint Turbo.

Là où OrcaRouter entre en jeu dans cette comparaison particulière, c'est le basculement que vous opérez lorsque l'auto-hébergement d'un checkpoint cesse d'être la bonne réponse. Passer d'un modèle à poids ouverts que vous exécutez vous-même à un point de terminaison d'image hébergé n'est pas simplement un changement de modèle — c'est un changement de modes de défaillance. Un processus local échoue de manières que vous pouvez voir ; un point de terminaison hébergé échoue de manières qui dépendent du fournisseur qui a répondu, et de ce qui se passe lorsque l'un d'eux se dégrade en cours de requête. OrcaRouter place plus de 200 modèles derrière un point de terminaison unique compatible OpenAI et répercute le prix catalogue du fournisseur sans marge, de sorte qu'une baisse de prix d'un fournisseur se répercute de notre côté le jour même, plutôt que d'attendre une passe de re-tarification. En plus de cela, il ajoute un basculement automatique entre fournisseurs, un DSL de routage permettant de spécifier quels modèles et fournisseurs une requête peut utiliser, et une fusion de modèles pour combiner plusieurs modèles en un seul appel. Les modèles d'image que nous prenons en charge sont la famille OpenAI GPT-Image, les niveaux d'Imagen 4 de Google, y compris les variantes fast et ultra, les points de terminaison de prévisualisation d'image Gemini de Google, et le point de terminaison d'image xAI Grok Imagine.

Concrètement : si vous hésitez entre les deux checkpoints Qwen, il s’agit d’une décision d’auto-hébergement, et les raisons de préférer l’un à l’autre sont le comportement de l’ordonnancement et le nombre d’étapes. Si ce dont vous avez réellement besoin, c’est d’une image en production sans posséder les GPU, c’est la décision pour laquelle nous sommes en mesure de vous aider, et c’est une décision différente.

La version courte

• Choisissez Qwen-Image-2.1 si vous voulez le checkpoint dont le comportement d'échantillonnage correspond à sa documentation, si vous devez faire varier le nombre d'étapes ou explorer les planifications, ou si vous voulez la version arrivée avec une prise en charge dès le jour zéro dans Diffusers, ComfyUI, vLLM-Omni, SGLang et LightX2V.

• Choisissez Qwen-Image-2.1-Turbo si vous voulez la même architecture et les mêmes capacités avec une trajectoire nettement plus courte et êtes prêt à considérer huit étapes comme fixes, et à installer Diffusers depuis les sources pour le charger.

• Attendez-vous à la même licence dans un cas comme dans l'autre, et ne vous attendez à aucun chiffre de qualité publié pour le checkpoint accéléré qui permette de le comparer à la version de base. La réduction du nombre d'étapes est réelle et documentée. Le coût en qualité d'image n'est documenté nulle part, et aucune lecture des deux fiches, aussi attentive soit-elle, ne vous le dira — cette réponse n'existe que sur votre propre matériel, face à vos propres prompts.