Qwen-Image-2.1 LoRA : quels adaptateurs existent, ce qu’implique l’entraînement d’un tel modèle, et ce que dit réellement la licence

Il existe un véritable écosystème d'adaptateurs d'adaptation de rang faible (LoRA) pour Qwen-Image-2.1, le modèle d'image unifié de génération et d'édition du fournisseur, et il n'existe presque aucune documentation à ce sujet du côté du fournisseur. Cette page constitue la réponse permanente à quatre questions qu'un lecteur formule d'un seul tenant : quelqu'un fabrique-t-il réellement des adaptateurs pour ce modèle, où sont-ils hébergés, que faut-il pour en entraîner un, et que permet la licence de faire avec le résultat. Ce n'est pas un article de lancement. Qwen-Image-2.1 a été publié en open source le 20 septembre 2026 et son homologue accéléré Qwen-Image-2.1-Turbo a suivi le 9 octobre 2026 ; ces deux dates ne figurent ici que pour identifier les checkpoints dont traite cette page, et non pour annoncer quoi que ce soit.

En bref : les adaptateurs se comptent en quelques centaines, ils sont pour la plupart des travaux sur les personnages et les styles publiés par des praticiens individuels, l'entraînement de l'un d'entre eux est documenté de bout en bout par au moins trois chaînes d'outils tierces avec des mesures de mémoire publiées, et la licence — qui n'est pas Apache pour cette génération de modèles d'image — réaffirme une restriction non commerciale sur le dérivé que beaucoup des adaptateurs eux-mêmes ne parviennent pas à reporter.

Deux phrases sur ce qu’est un LoRA, puis le modèle

LoRA est un petit ensemble de deltas de poids de faible rang qui est ajouté à un checkpoint de base gelé au moment du chargement, adressé à des modules spécifiques par leur nom ; ce n'est pas un modèle, c'est un patch qui modifie le comportement d'un modèle existant. Comme les deltas sont entraînés par rapport à des poids particuliers, un adaptateur est lié au checkpoint sur lequel il a été entraîné d'une manière qu'un flag de configuration ne peut pas corriger.

Ce lien est la raison même pour laquelle cette page porte spécifiquement sur Qwen-2.1 plutôt que sur les LoRAs. Le checkpoint est un transformer de diffusion à flux unique de 32 couches, avec 7 milliards de paramètres pour sa génération visuelle, un encodeur de texte Qwen3-VL 8B et un VAE RGBA à 64 canaux fonctionnant à une compression spatiale de 16× — tous ces chiffres proviennent de la fiche modèle et du dépôt du fournisseur lui-même, consultés le 13 octobre 2026. Il définit son calendrier d'échantillonnage au moment de l'appel, avec 40 étapes d'inférence dans les exemples de la fiche elle-même. Aucun de ces détails n'est anodin pour les adaptateurs : l'architecture détermine ce qu'un fichier peut cibler, et le calendrier détermine ce qu'on demande de faire à un adaptateur entraîné avec une paramétrisation différente.

Qu'existe-t-il pour ce modèle, et comment le compter honnêtement ?

Les chiffres ci-dessous proviennent de l’API Hugging Face et de l’API Civitai, toutes deux consultées le 13 octobre 2026, et il vaut la peine de préciser la requête, car la même question donne des réponses radicalement différentes selon la façon dont on la pose.

• Dépôts sur Hugging Face qui déclarent Qwen-Image-2.1 comme leur modèle de base : 323.

• Parmi ceux-ci, les dépôts qui portent également le tag lora : 115.

• Adaptateurs sur Civitai correspondant à un filtre de modèle de base « Qwen 2.1 » avec le type défini sur LoRA : 106. Un passage antérieur le même jour en comptait 105 ; le filtre est dynamique et le nombre évolue, donc considérez-le comme une lecture plutôt qu'un total.

Les deux chiffres sont des planchers, pas des recensements. Le tag Hugging Face est appliqué par la personne qui met en ligne, donc un adaptateur dont l'auteur ne l'a pas taggé est invisible pour cette requête ; le décompte des modèles de base est plus élevé que celui des LoRA précisément parce qu'il capte aussi les quantisations, les fusions et les repacks. Sur Civitai, l'écart entre les méthodes est flagrant : une simple recherche textuelle pour « qwen image 2.1 » renvoie 994 modèles uniques, et la plupart d'entre eux ne sont pas du tout des adaptateurs de ce checkpoint — le même ensemble de résultats est dominé par des publications de workflows et par des fichiers dont le modèle de base déclaré relève d'une génération d'images entièrement différente. Filtrez sur le modèle de base, pas sur la barre de recherche.

Les deux sites sont là où vit cet écosystème, et c’est la seule affirmation faite à propos de l’un comme de l’autre : Hugging Face est l’endroit où les enregistrements d’entraînement et les jeux de données sont publiés, Civitai est l’endroit où se rassemblent les adaptateurs destinés au grand public et les workflows ComfyUI qui les entourent, et aucun des deux n’est un signal de qualité. Un fichier sur l’un ou l’autre peut être une œuvre originale issue d’un entraînement ou une copie de celle de quelqu’un d’autre.

Comment distinguer un adaptateur d'origine d'un adaptateur réemballé

C'est vérifiable, et la vérification prend environ une minute. Prenez deux dépôts qui ressemblent au même adaptateur.

akhaliq/Qwen-Image-2.1-Next-Scene-LoRA a été créé le 7 octobre 2026. TechnoBaptist/Qwen-Image-2.1-Next-Scene-LoRA a été créé le 9 octobre 2026. Leurs fichiers README sont identiques octet pour octet — même longueur, même MD5 — et les listes de fichiers des deux dépôts correspondent sur les 111 entrées. Le plus récent est une copie du plus ancien, description incluse.

Le cas le moins évident est la copie partielle. developerjeremylive/Qwen-Image-2.1-Multiple-Angles-LoRA-etheroicontient 163 fichiers. Chacun des 160 qui existent aussi dans akhaliq/Qwen-Image-2.1-Multiple-Angles-LoRAest identique en taille, et le dépôt est un sous-ensemble strict des 344 fichiers de celui-ci. Ce qui a été laissé de côté, c'est l'intégralité du répertoire benchmarks/, les grilles d'échantillons par point de contrôle sous samples/, et plusieurs variantes de point de contrôle. Les poids de l'adaptateur sont présents. Les preuves que l'adaptateur fait ce qu'il prétend ne le sont pas.

Donc le test pratique n’est pas « a-t-elle une jolie carte ? ». Il consiste à savoir si la carte porte les choses qui ne peuvent venir que du fait d’avoir fait la course :

• D'où proviennent les données d'entraînement, avec un lien — l'adaptateur d'angle indique sa source Objaverse et sa licence, et publie séparément les jeux de données de paires dérivés.

• L'entraîneur et les hyperparamètres, au niveau du rang, de l'alpha, du taux d'apprentissage, du nombre d'étapes et de la précision de base — assez pour que quelqu'un d'autre puisse tenter une reproduction.

• Des points de contrôle intermédiaires plutôt qu’un simple fichier final, afin que la courbe d’entraînement soit inspectable plutôt que simplement affirmée.

• Une évaluation qui n’est pas une vitrine pour l’auteur, et une section « Portée et limites » qui indique ce que l’adaptateur fait mal.

Une carte avec un mot déclencheur, une plage de force et une série de jolis échantillons, et rien d'autre, ne prouve rien. Ce n'est pas non plus la preuve d'un repack — de nombreux adaptateurs ponctuels honnêtes sont documentés aussi sommairement. Cela signifie simplement que vous n'avez rien sur quoi vous appuyer, ce qui, pour un fichier que vous êtes sur le point de mettre dans un pipeline de production, est la conclusion utile.

Quelle formation suit-on réellement ?

Le cadrage honnête d’abord, car l’écart ici est béant : publier un adaptateur est monnaie courante, mais en entraîner un relève d’un tout autre ordre d’entreprise. Il y a trois coûts, et ils sont tous bien réels.

Le checkpoint de base. Les trois composants de Qwen-Image-2.1 totalisent environ 33 GB entre le transformer, l’encodeur de texte et le VAE — c’est la somme des tailles de fichiers publiées par le dépôt lui-même, relevées le 13 octobre 2026. C’est ce qui est adapté, et cela ne rétrécit pas parce que vous n’entraînez qu’un petit patch par-dessus.

Les données. Un LoRA n'apprend pas un concept à partir d'une poignée d'images comme le fait un prompt. Les deux adaptateurs les mieux documentés de cet écosystème ont publié leurs jeux de données comme des artefacts à part entière : l'adaptateur de contrôle de caméra a été entraîné sur 5 028 paires étiquetées par angle dans sa première version et 13 328 dans la seconde ; l'adaptateur de continuation de scène a été entraîné sur 1 144 paires de progression image par image, avec des légendes rédigées par un modèle de vision pour chaque paire. Ces deux ensembles sont des jeux de données assemblés, et non des collections de photographies — les paires ont dû être générées, étiquetées et licenciées avant le début de l'entraînement, et dans un cas, les images sources ont dû être filtrées pour ne conserver que des objets sous licence permissive avant de pouvoir être utilisées.

Le calcul. C'est la partie avec des mesures publiées plutôt que du ressenti. Le guide de démarrage rapide de SimpleTuner pour le modèle donne des préréglages de VRAM et, séparément, les tests de mémoire qui les sous-tendent : une recette 512px avec gradient checkpointing à chaque étape a passé une limite d'allocation de 24 GiB tout en atteignant un pic de 20,06 GiB alloués et 21,10 GiB réservés par PyTorch. Une recette multi-résolution à 32,49 / 41,21 GiB a réussi sur une L40S mais a épuisé la mémoire sous un plafond de 32 GiB. Les auteurs précisent explicitement qu'il s'agit de contrôles de mémoire sur un sous-ensemble borné, et non de mesures de débit ou de convergence, et que les budgets inférieurs ont été simulés sur une L40S plutôt qu'exécutés sur leurs cartes nominales. Lues telles que publiées, elles disent une chose simple : le plancher pour ce modèle est une carte de 24 Go fonctionnant uniquement en 512px, et c'est à partir de 48 Go ou plus que deviennent disponibles les recettes multi-résolution que le framework recommande réellement.

Le temps est le coût le plus discret, et presque personne ne le publie. Ce qui est public, ce sont les nombres d’étapes — 2 000 mises à jour dans le préréglage 24 Go, 4 000 dans les plus grands, avec validation et création d’un point de contrôle tous les 250 — et des nombres de points de contrôle de l’ordre de quelques milliers d’après les propres relevés d’entraînement des adaptateurs. Le tableau des préréglages de SimpleTuner donne des budgets de mises à jour pour chaque palier de VRAM et indique clairement qu’il s’agit de points de départ à étendre uniquement après avoir inspecté les images des points de contrôle. Personne n’a publié d’heures de temps d’horloge pour une exécution reproductible, donc tout chiffre que vous voyez cité sur le temps que cela prend correspond à la carte graphique de quelqu’un et au jeu de données de quelqu’un, et non à une spécification.

En revanche, l'outillage est vraiment de qualité, et c'est la partie qui a changé assez récemment pour qu'il vaille la peine d'en dater les évolutions. L'éditeur renvoie à DiffSynth-Studio de ModelScope, dont le dépôt fournit un script d'entraînement LoRA fonctionnel pour ce checkpoint et, séparément, pour la variante Turbo — un seul accelerate launch avec un rang de 32, AdamW à 1e-4, cinq époques, un budget maximal de 1 048 576 pixels et le gradient checkpointing. Le quickstart de SimpleTuner est la recette publique la plus détaillée, et il fait preuve d'une honnêteté inhabituelle quant à ses propres limites. ai-toolkit liste à la fois Qwen-Image-2.1 et Qwen-Image-2.1-Turbo parmi ses architectures prises en charge, et deux des adaptateurs décrits plus haut indiquent avoir été entraînés avec lui. Et le 12 octobre 2026, musubi-tuner a fusionné une pull request ajoutant la prise en charge de Qwen-Image 2.1, couvrant l'entraînement LoRA, le fine-tuning complet, les aperçus d'entraînement et la conversion entre Diffusers et son propre format LoRA ; la demande de fonctionnalité correspondante, ouverte le 24 septembre, est toujours ouverte. Cette fusion a trois jours d'avance sur la date de cette page et il s'agit d'un changement d'outillage plutôt que d'une sortie de modèle — cela signifie qu'un quatrième outil d'entraînement est devenu disponible, et non que quoi que ce soit a changé dans le modèle.

Il existe une contrainte supplémentaire qui piège les personnes ayant entraîné des LoRAs pour d'autres architectures. La sortie de ce modèle n'a pas d'interrupteur alpha. Le VAE fonctionne dans un espace de pixels RGBA à quatre canaux, et le quatrième canal est décodé comme l'alpha, de sorte que la transparence est produite par le prompt et rien d'autre — la documentation du fournisseur elle-même indique qu'il n'existe aucun contrôle lié à l'alpha nulle part dans le pipeline. Un adaptateur entraîné sur des images opaques modifie la distribution que le prompt pilote ; il n'a pas de réglage de transparence distinct sur lequel se rabattre. Si votre pipeline dépend de détourages, c'est une propriété du modèle de base que vous empruntez, et il vaut la peine de la tester avant d'y consacrer une exécution d'entraînement.

Ce que la licence dit à propos de l’adaptateur que vous fabriquez

Lisez le fichier, car la réponse n'est pas ce que laisserait supposer une publication au nom permissif. Qwen-Image-2.1 est distribué sous l'accord de licence Qwen Research daté du 20 septembre 2026 — un document de 7 831 octets repris sans modification dans le dépôt Turbo, dont la copie est identique octet pour octet. Ce n'est pas Apache 2.0, alors que la précédente gamme Qwen-Image l'était.

La clause qui tranche l’essentiel de cette question est la concession. La section 2(a) vous autorise, à l’égard des matériels, à « utiliser, reproduire, distribuer, copier, créer des œuvres dérivées de ceux-ci et y apporter des modifications », puis plafonne l’ensemble : « À DES FINS NON COMMERCIALES UNIQUEMENT ». La section 1(i) définit l’usage non commercial comme « à des fins de recherche ou d’évaluation uniquement », ce qui est plus restrictif que « à but non lucratif » — cela ne prévoit pas d’exception pour l’usage interne en entreprise. La section 2(b) précise que l’usage commercial nécessite une licence distincte, à demander à l’adresse indiquée dans l’accord. Un adaptateur entraîné sur ce checkpoint est une œuvre dérivée de celui-ci, de sorte que la restriction suit l’adaptateur ; il ne devient pas utilisable à des fins commerciales du simple fait que vous l’avez entraîné vous-même.

Deux choses méritent d’être signalées, car toutes deux vont à l’encontre des idées reçues.

Premièrement, la licence n'est pas muette sur l'entraînement — elle l'envisage directement. La section 4(b) indique que si vous utilisez les éléments ou leurs résultats pour « créer, entraîner, fine-tuner ou améliorer un modèle d'IA qui est distribué ou mis à disposition », vous devez afficher bien en évidence « Built with Qwen » ou « Improved using Qwen » dans la documentation produit associée. Ainsi, le fine-tuning est traité nommément, et il s'accompagne d'une obligation d'étiquetage plutôt que d'une question d'autorisation.

Deuxièmement, la redistribution est expressément autorisée, sous conditions. La section 3 vous permet de distribuer des œuvres dérivées, sous forme de source ou d'objet, à condition de fournir aux destinataires une copie de l'accord, de marquer les fichiers modifiés et de conserver un fichier de mention indiquant « Qwen is licensed under the Qwen RESEARCH LICENSE AGREEMENT, Copyright (c) 2026 Hangzhou Tongyi Laboratory Technology Co., Ltd. All Rights Reserved. ». La section 4(c) interdit d'utiliser « Qwen » comme nom principal ou identifiant de votre œuvre dérivée — un usage descriptif est expressément autorisé. La section 5(a) confirme que vous êtes propriétaire de vos modifications, sous réserve de conformité. Les litiges sont régis par le droit chinois, devant les tribunaux de Hangzhou.

Ce sont des obligations cohérentes et lisibles. Le constat dérangeant, c'est la fréquence à laquelle l'écosystème ne les respecte pas. Parmi les adaptateurs échantillonnés lors des recherches pour cette page, l'un — un adaptateur de distillation par étapes pour le point de contrôle de base — livre le texte de la licence et un fichier de mention portant verbatim la chaîne d'attribution requise, ainsi qu'une section de licence dans sa fiche réaffirmant la limite non commerciale et le contact commercial. Plusieurs autres, dont deux des adaptateurs de contrôle de caméra et de continuité de scène les plus téléchargés, déclarent apache-2.0 dans leurs métadonnées, ne livrent aucun fichier de licence et ne contiennent aucune mention d'attribution. Leurs fiches ne revendiquent pas de droits Apache sur les poids de base ; le champ de métadonnées est simplement erroné, et c'est le champ qu'un outil en aval lira. Si c'est vous qui construisez sur un adaptateur, lisez vous-même la licence du modèle de base plutôt que de vous fier à l'étiquette figurant sur la fiche de l'adaptateur — et si c'est vous qui publiez, le conditionnement correct n'est pas compliqué, il suffit simplement de le faire exprès.

Compatibilité, et la seule chose à savoir sur « turbo »

Un adaptateur s'exécute sur le checkpoint que nomme son enregistrement d'entraînement. Pour la plupart des adaptateurs ici, il s'agit de Qwen-Image-2.1 lui-même, et c'est là qu'ils doivent être chargés. Le checkpoint Turbo est un fine-tune de la même architecture plutôt qu'un modèle différent — les deux partagent leur arbre de modules, ce qui explique pourquoi un adaptateur entraîné sur la base se chargera très probablement sur Turbo — mais il stocke son propre programme d'échantillonnage en huit étapes à l'intérieur du checkpoint et suit une trajectoire de débruitage dans laquelle l'adaptateur n'a pas été entraîné. Personne ne documente si cette combinaison se comporte correctement, pas même le fournisseur.

Il existe également un piège de dénomination : l'expression « turbo LoRA » recouvre deux artefacts opposés, un adaptateur entraîné sur le checkpoint Turbo et un adaptateur de distillation qui transforme le checkpoint standard en un modèle à quelques étapes. Ce sont des fichiers différents qui remplissent des fonctions différentes. La question du checkpoint de base par rapport au Turbo, et les deux significations de l'adaptateur turbo, ont leur propre page sur ce stem — Qwen-Image-2.1-Turbo LoRA — et cette page ne va pas devenir une seconde copie de celle-ci. Si vous disposez de Turbo et d'un adaptateur qui nomme le checkpoint standard, lisez cette page avant de charger quoi que ce soit.

Deux questions connexes ont elles aussi leur place ailleurs. Les checkpoints quantifiés — GGUF, FP8, INT4 et le reste — sont un autre sujet, avec une autre page ; un LoRA utilisé dans un pipeline quantifié est une note de compatibilité sur cette page-là, pas une section sur celle-ci. Et le modèle exécuté dans un outil spécifique est encore une autre question, avec ses propres listes de fichiers et ses propres modes de défaillance.

Ce qui casse, et ce qui n’est pas réglé

Les rapports de défaillance se répartissent en trois causes, et chacune d’elles a été documentée par quelqu’un qui a fait le travail, plutôt que simplement inférée.

Un adaptateur qui se charge et ne fait rien. Le cas le plus concret est une incompatibilité de nommage des clés : la fiche d'un adaptateur indique que ses fichiers bruts au format de l'entraîneur utilisent le nommage des clés MLP fusionnées de cet entraîneur, que Diffusers « ignore silencieusement » — le chargement réussit, aucune erreur n'est levée, et l'adaptateur n'a aucun effet. Le fichier fonctionne avec son propre chargeur et pas avec celui de la solution dominante. Il s'agit d'une différence de disposition des fichiers, et non de point de contrôle de base, et cela vaut la peine de l'écarter avant d'accuser autre chose.

Un adaptateur qui détruit des prompts sans rapport. C'est un problème de taux d'apprentissage et de durée, et il existe une mesure : dans une ablation publiée, une exécution à 3e-4 « a gravement dégradé les quatre prompts de validation dès l'update 500 », avec des sujets sans rapport — un renard, un portrait — qui se transformaient en le concept entraîné. L'étude du même auteur sur l'entraînement prolongé rapporte le piège inverse : dans une exécution, un prompt s'est amélioré jusqu'à l'update 3 500, a régressé à 4 000, puis s'est rétabli jusqu'à 10 000 ; un checkpoint intermédiaire médiocre n'est donc pas la preuve que l'exécution a échoué. Cette seconde observation est explicitement qualifiée de progression qualitative issue d'une seule exécution et d'une seule graine de validation, sans courbe d'erreur de test mesurée, et le rétablissement est décrit comme dépendant du prompt. Considérez-la comme une raison de conserver chaque checkpoint tous les 250 pas, et non comme une recette.

Un adaptateur qui se comporte bien, puis qui s'accumule. L'adaptateur de continuation de scène documente une dégradation mesurée en usage chaîné : le chaînage naïf à une intensité de 0,9 accumule le grain de film en bruit de couleur visible dès le troisième ou quatrième passage, et la solution de contournement vérifiée de l'auteur consiste en une intensité inférieure ou égale à 0,7, plus un flou gaussien d'un demi-pixel sur chaque entrée chaînée. La même fiche est honnête quant au fait que les transformations en fin de chaîne restent conservatrices, et désigne cela comme une limitation des données d'entraînement plutôt qu'un problème de réglages.

Sous tout cela se trouve un ensemble de choses qui ne sont véritablement pas établies, et il vaut la peine de les énoncer plutôt que de les combler. Personne n'a publié de comparaison de qualité entre Qwen-Image-2.1 et Qwen-Image-2.1-Turbo, il n'existe donc aucune référence permettant de juger de l'effet d'un adaptateur quelconque sur l'un ou l'autre. Personne n'a publié d'information indiquant si un adaptateur de point de contrôle standard se comporte correctement sur Turbo. Le fournisseur ne documente l'entraînement LoRA qu'une seule fois, dans la section ModelScope du dépôt du projet, en renvoyant à un framework tiers ; la fiche du modèle elle-même ne contient aucune indication sur les adaptateurs, et l'encodeur de texte du point de contrôle est un composant que la communauté a déjà commencé à republier séparément, ce qui pose sa propre question de compatibilité. Et chaque décompte sur cette page est un instantané d'un écosystème vieux de deux à trois semaines, lu un seul jour — le filtre Civitai et la requête sur le modèle de base de Hugging Face seront tous deux erronés le mois prochain, et ce dans le sens d'une augmentation.

Si vous décidez quoi faire aujourd’hui, la séquence qui survit à toutes ces lacunes est courte. Commencez par lire le registre d’entraînement de l’adaptateur, et non ses échantillons — s’il n’y a pas de registre, considérez le fichier comme non attribué et testez-le sur votre propre prompt avant de vous appuyer dessus. Faites correspondre l’adaptateur au checkpoint que nomme son registre, et si vous êtes sur Turbo, lisez d’abord la page Turbo. Vérifiez dans quel format de chargeur se trouve le fichier avant de conclure qu’il est cassé. Et lisez une fois la licence de base, car elle régit l’adaptateur, quelles que soient les prétentions de la fiche de l’adaptateur à son propre sujet. Ensuite, choisissez votre outil d’entraînement, partez du préréglage VRAM le plus petit que votre carte prend en charge, et jugez la grille de checkpoints plutôt que le fichier final.