Qwen-Image-2.1 GGUF : ce que vous coûte réellement une version quantifiée

Il n'existe aucun GGUF officiel de Qwen-Image-2.1. Chaque fichier .gguf portant ce nom a été produit par quelqu'un d'autre, a posteriori, en reprenant le transformer de diffusion 7B du fournisseur et en ré-encodant ses poids à une précision inférieure — le GGUF étant le format de checkpoint quantifié en fichier unique que lisent les piles d'inférence locales. Cette seule phrase répond à la première question que se pose un lecteur et soulève les plus ardues que cette page tranche : ce qu'une quantification d'un modèle d'image compresse réellement, ce que le fichier ne fournit pas d'emblée, ce que les niveaux vous coûtent en qualité d'image et pas seulement en temps de calcul, et ce que la redistribution de l'un d'eux exige au titre de la licence qui accompagnait les poids.

Le modèle lui-même est le fait qui date cette page, pas les actualités qu'il rapporte. Qwen-Image-2.1 a été mis en ligne sur Hugging Face et ModelScope le 20 septembre 2026, et les quantifications communautaires ont suivi le jour même — les dépôts de leejet, Abiray et RealRebelAI ont tous été créés le 20 septembre et celui d'unsloth le 21 septembre, soit 23 jours avant la rédaction de cette page. Rien dans cette chronologie n'a besoin d'être répété ici ; ce qu'un lecteur tapant « qwen image 2.1 gguf » veut, c'est le manuel d'utilisation, et c'est ce que voici.

Ce qu’est un GGUF de ce modèle, et ce qu’il n’est pas

La première chose à intégrer est que le fichier est un fragment. Qwen-Image-2.1 n'est pas un seul réseau ; c'est un transformateur de diffusion, plus un encodeur de texte vision-langage, plus un autoencodeur. Les quantifications qui circulent sous son nom contiennent la première de ces parties et rien d'autre, et les dépôts le disent eux-mêmes. La fiche d'Unsloth pour son GGUF Qwen-Image-2.1 le résume en une ligne : « Un GGUF n'est que le débruiteur, il lui faut donc le VAE et l'encodeur de texte Qwen3-VL en complément. »

Donc, un téléchargement GGUF est le transformer — 32 couches DiT à flux unique, 7 milliards de paramètres dans le composant de génération visuelle — réexprimé à une précision numérique réduite. L’encodeur de texte et le VAE restent dans leurs formats d’origine ou sont quantifiés séparément, par des personnes différentes, dans des dépôts différents. C’est la différence structurelle avec la situation des modèles textuels que la plupart des lecteurs ont en tête : lorsque vous téléchargez un GGUF d’un modèle de chat, vous avez téléchargé le modèle. Ici, vous n’avez téléchargé qu’un tiers d’un pipeline.

Rien de tout cela ne constitue l'empaquetage du fournisseur. Le dépôt du fournisseur Qwen/Qwen-Image-2.1 est une version au format Diffusers — model_index.json, transformer/, text_encoder/, vae/, scheduler/, processor/ — et sa liste de fichiers, consultée le 13 octobre 2026, ne contient aucun fichier de type .gguf, quel qu'il soit. Les quantifications sont des artefacts communautaires, publiés sous le nom de leurs auteurs, et elles héritent de la licence du fournisseur plutôt que de son approbation.

Pourquoi la sagesse en matière de quantification des modèles textuels ne se transpose pas

Les idées reçues sur GGUF proviennent des modèles de langue, où elles se résument en gros à ceci : Q8_0 est pratiquement sans perte, Q4_K_M est l’optimum, tout ce qui est en dessous de Q3 est un compromis, et la qualité se mesure en perplexité ou en divergence KL par rapport à une référence en pleine précision. Presque rien de tout cela ne se transpose à un modèle d’image, et il vaut la peine d’être précis quant aux raisons.

Il n'y a pas de perplexité pour un transformer de diffusion. Le modèle n'émet pas de distribution de tokens que l'on peut évaluer ; il émet un latent qu'un VAE décode en pixels. Les métriques qui existent de ce côté-ci de la barrière — LPIPS, SSIM par rapport à un rendu de référence — exigent la même graine, le même prompt et les mêmes paramètres de sampler des deux côtés de la comparaison, et elles mesurent toujours une distance perceptuelle plutôt qu'une exactitude. Ainsi, la question « combien Q4_K_M me coûte-t-il ? » n'a pas de chiffre publié unique comme c'est le cas pour un modèle de texte, et quiconque en cite un cite une mesure sur une seule graine.

Deuxièmement, et c'est plus déterminant encore : sur un modèle d'image, la largeur de bits moyenne compte moins que quels tenseurs ont perdu leurs bits. Les projections d'attention et les chemins MLP qui portent la structure de l'image se dégradent visiblement lorsqu'ils sont arrondis, tandis que les petits tenseurs de normalisation et de modulation tolèrent à peu près n'importe quoi. Une conversion qui vise une cible uniforme sur tous les tenseurs peut donc paraître pire qu'une conversion affichant le même label nominal mais protégeant les couches sensibles — ce qui est exactement ce qu'ont constaté les personnes qui font ce travail. RealRebelAI, qui publie les notes de quantification les plus explicites que nous ayons pu trouver, affirme qu'« une conversion Q4_K_M générique standard a montré une perte de qualité visible dans les structures fines et l'anatomie par rapport au modèle INT8 de référence », et que ses propres builds maintiennent l'attention Q/K/V/Out en Q8_0 à l'intérieur d'un fichier Q4_K_M pour la récupérer. Le label figurant sur le nom de fichier est la quantification de base, pas la politique.

Troisièmement, le mode de défaillance est différent par nature. La quantification du texte se dégrade principalement en fluidité, et elle se dégrade en douceur — une phrase légèrement moins bonne reste une phrase. La quantification d'image aux échelons les plus bas échoue de manières évidentes et parfois inutilisables : les mains et l'anatomie, la texture fine, la petite typographie, et — celui qu'il est facile de manquer parce que ce n'est pas du tout un artefact de pixel — le respect du prompt. Si une build cesse d'obéir à la moitié d'une longue instruction, c'est un coût de quantification, et cela n'apparaîtra pas dans une comparaison côte à côte de deux bons rendus.

L’échelle, en fichiers plutôt qu’en adjectifs

La taille des fichiers est le seul aspect de tout ceci qui relève d’un fait objectif plutôt que d’un jugement, car chaque dépôt publie sa propre liste. Consultation du 13 octobre 2026 : les deux quantisations communautaires les plus téléchargées ne concordent pas tout à fait entre elles, ce qui est en soi instructif.

• Unsloth Dynamic 2.0 (12 fichiers) : F16 14,23 GB, Q8_0 7,64 GB, Q6_K_XL 6,72 GB, Q6_K 6,27 GB, Q5_K_M 5,39 GB, Q5_K_S 4,50 GB, Q4_K_M 4,20 GB, Q4_K_S 3,91 GB, Q3_K_XL 3,61 GB, Q3_K_M 3,17 GB, Q3_K_S 2,72 GB, Q2_K 2,47 GB.

• leejet / stable-diffusion.cpp (7 fichiers) : Q8_0 7,69 Go, Q6_K 6,00 Go, Q5_0 5,07 Go, Q4_K 4,20 Go, Q4_0 4,20 Go, Q3_K 3,27 Go, Q2_K 2,56 Go.

• Abiray (6 fichiers) : Q8_0 7,59 Go, Q6_K 5,88 Go, Q5_K_M 5,01 Go, Q4_K_M 4,19 Go, Q4_K_S 4,06 Go, Q3_K_M 3,19 Go.

• RealRebelAI publie une échelle de précision mixte avec un -HQv3 suffixe plutôt que des niveaux simples, et documente la précision par module dans un tableau ; les quantifications de base vont de Q2_K à Q8_0.

L'écart est réel. Q8_0 s'étend de 7,59 à 7,69 Go chez trois éditeurs, et Q6_K s'étend de 5,88 à 6,27 Go — un écart de 0,4 Go pour un même niveau nominal, ce qui correspond à la politique de précision mixte qui se traduit en octets. Quiconque compare deux builds sur le seul nom de fichier compare des étiquettes, pas des artefacts.

Pour situer l’échelle de l’autre côté : le transformer F16 de référence fait 14,23 Go, et le composant de diffusion bfloat16 du fournisseur lui-même dans le repack Comfy-Org fait 14,23 Go. Ainsi, un GGUF de classe Q4 représente environ une réduction d’un facteur 3,4 sur le transformer, et aucune réduction sur l’encodeur de texte, sauf si vous quantifiez celui-ci séparément.

Combien coûte chaque échelon, là où une source le dit

Presque personne ne publie de coût qualité mesuré par niveau pour ce modèle, et la chose honnête à faire est de distinguer les trois types d’affirmations en circulation.

• Recommandations mémoire, signalées par la communauté. Le dépôt d’Abiray associe chaque fichier à un profil VRAM recommandé : Q8_0 7,59 Go à « 12 Go+ (fidélité quasi sans perte) », Q6_K 5,88 Go à 10–12 Go, Q5_K_M 5,01 Go à 8–10 Go, Q4_K_M 4,19 Go et Q4_K_S 4,06 Go à 6–8 Go, et Q3_K_M 3,19 Go à 4–6 Go pour « budget extrême / VRAM minimale ». Il s’agit de règles empiriques de l’éditeur lui-même, et non d’une spécification de fournisseur ni d’un benchmark que nous avons pu reproduire ; elles décrivent en outre uniquement le fichier transformer, donc la marge nécessaire pour l’encodeur de texte vient s’ajouter par-dessus.

• Une comparaison mesurée, rapportée par le quantificateur et à graine unique. Unsloth publie une paire de chiffres pour le côté encodeur du pipeline : son encodeur de texte 4 bits Dynamic 2.0 face à un encodeur Q4_K_M uniforme, tous deux à une graine partagée avec le débruiteur et le VAE maintenus fixes, à LPIPS 0,029 et SSIM 0,959, en 5,15 Go contre 5,03 Go et 36,5 s contre 39,0 s. Il s'agit d'une seule mesure réalisée par la partie qui vend le fichier, sur une seule graine, et c'est la seule comparaison quantitative publiée de deux politiques de quantification pour ce modèle que nous ayons pu trouver.

• Listes de défaillances qualitatives, rapportées par la communauté. RealRebelAI nomme ce que la quantification à bits réduits peut encore affecter — « détails fins, mains et anatomie, typographie, respect du prompt, fidélité des retouches, cohérence des textures » — et conseille de monter d'un cran lorsque la dégradation est visible. Il indique clairement que Q3_K_M et Q2_K sont destinés aux systèmes à mémoire limitée et « peuvent encore afficher une perte de qualité croissante malgré les couches de haute précision protégées ».

Ce qui n'est pas publié est aussi important que ce qui l'est. Il n'existe aucune déclaration du fournisseur sur la qualité de quantification pour Qwen-Image-2.1, aucun benchmark indépendant d'une build GGUF, et aucun tableau de débit sur du matériel grand public explicitement nommé, de la part de qui que ce soit que nous ayons pu trouver. Le sens du compromis sur la mémoire est certain et le sens du compromis sur la vitesse est globalement certain ; l'ampleur du coût en fidélité n'est pas établie publiquement, et cette page ne l'estimera pas à votre place.

Qu'est-ce qui le fait réellement tourner

La situation côté runtime est étonnamment bien établie pour un format aussi récent, ce qui représente un véritable avantage par rapport à la situation habituelle avec GGUF.

• stable-diffusion.cpp — l'implémentation de référence pour les GGUF de modèles d'image. La liste d'actualités du projet mentionne la prise en charge Day-0 de Qwen-Image-2.1 le 20 septembre 2026, et une page dédiée au modèle y est documentée. La ligne de commande prend directement le modèle de diffusion quantifié : --diffusion-model qwen-image-2.1-Q4_K_M.gguf --vae qwen_image_2.1_vae_bf16.safetensors --llm Qwen3-VL-8B-Instruct-UD-Q4_K_XL.gguf, avec --steps 20 --cfg-scale 6.0 --sampling-method euler dans l'exemple fourni par l'éditeur.

• ComfyUI, via un nœud personnalisé. C'est la voie que la plupart des lecteurs emprunteront, et elle comporte un détail qu'il vaut la peine de connaître avant d'installer quoi que ce soit. Le dépôt vers lequel la plupart des quantiseurs renvoient est city96/ComfyUI-GGUF ; l'auteur de stable-diffusion.cpp publie son propre fork, leejet/ComfyUI-GGUF, et son README contient une instruction explicite invitant à lui préférer celui-ci, pour le motif déclaré que « le dépôt city96 semble ne plus être activement maintenu ». Il s'agit là d'une affirmation d'une partie à propos d'une autre, et elle est datée ; l'historique des commits de city96/ComfyUI-GGUF montre bien que son activité la plus récente remonte à janvier 2026. La page de documentation officielle de ComfyUI consacrée à Qwen-Image-2.1 ne liste que des poids .safetensors et ne mentionne pas du tout GGUF, de sorte que le nœud personnalisé n'est ni facultatif ni approuvé par l'éditeur. Les deux chargeurs placent le fichier dans ComfyUI/models/diffusion_models/ et l'exposent via un chargeur de modèle de diffusion GGUF.

• llama.cpp / ggml — pas un échantillonneur pour ce modèle, mais l'origine du format et de la chaîne d'outils qui produit ces fichiers. Les dépôts leejet et Abiray le créditent explicitement. Si vous voulez un niveau que personne n'a publié, c'est avec ça que vous convertissez.

• Unsloth Desktop — nommé par le dépôt unsloth comme front-end pris en charge aux côtés de stable-diffusion.cpp.

Un runtime ne charge manifestement pas ce fichier : Diffusers. Le guide de démarrage rapide du fournisseur lui-même est un QwenImage21Pipeline sur le dépôt safetensors en bfloat16, et il n'existe aucun chemin GGUF dans ce pipeline. Si vous voulez Diffusers, vous n'êtes pas le public visé par un fichier quantifié ; si vous voulez un fichier quantifié, c'est vers stable-diffusion.cpp ou un graphe ComfyUI que vous vous tournerez.

La partie qui bloque vraiment les gens

Chaque rapport d'échec concernant ce format remonte à la même chose : le GGUF est le transformer, donc le reste du pipeline doit être assemblé à la main, dans les bons formats, à partir des bons dépôts. Trois composants sont concernés, et l'un d'eux comporte un piège.

• L'encodeur de texte. Qwen-Image-2.1 est conditionné sur Qwen3-VL 8B, et cet encodeur est plus gros que le transformer en pleine précision — 17,53 Go en bfloat16 dans le repack de Comfy-Org, contre 14,23 Go pour le modèle de diffusion. Il existe des alternatives quantifiées à 9,35 Go (int8) et 6,31 Go (w4a8) dans le même repack, ainsi qu'indépendamment au format GGUF : le fournisseur publie un GGUF officiel Qwen/Qwen3-VL-8B-Instruct-GGUF avec F16 à 16,39 Go, Q8_0 à 8,71 Go et Q4_K_M à 5,03 Go. Notez que ce GGUF d'encodeur est un artefact du fournisseur, contrairement au GGUF du transformer à côté duquel il se trouve — les deux moitiés de votre pipeline proviennent d'éditeurs différents, avec des provenances différentes.

• Le VAE. Un seul fichier, qwen_image_2.1_vae_bf16.safetensors, 0,68 Go dans le repack Comfy-Org. Il est petit, et c'est le composant que l'on suppose le plus souvent interchangeable, à tort : la documentation de stable-diffusion.cpp indique que les poids VAE des versions antérieures de Qwen Image et de Wan 2.2 ne sont pas interchangeables avec ceux du VAE Qwen Image 2.1. Associez le mauvais et le graphe se charge puis produit une image incorrecte.

• Le projecteur de vision, si vous souhaitez modifier. La génération d'images à partir de texte, c'est la partie facile. Pour l'édition d'images, l'encodeur a besoin d'un projecteur multimodal distinct : la documentation de stable-diffusion.cpp invite les lecteurs à télécharger également mmproj-Qwen3VL-8B-Instruct-F16.gguf (1,16 Go) depuis le dépôt de l'encodeur et à le passer avec --llm_vision, et à répéter -r une fois par image de référence. Un GGUF uniquement transformeur accompagné d'un encodeur de texte constitue un pipeline de génération d'images à partir de texte, et rien de plus.

Deux autres téléversements méritent d'être connus. La publication inclut également deux encodeurs de réécriture de prompt — Qwen-Image-2.1-PE-T2I et Qwen-Image-2.1-PE-I2I, tous deux des modèles 9B affinés — que le fournisseur recommande d'exécuter en amont du modèle d'image, et ceux-ci sont également en cours de quantification : une version GGUF du réécrivain T2I issue du projet LightX2V est apparue sur Hugging Face le 12 octobre 2026, aux côtés de plusieurs versions communautaires. Et le canal alpha, qui est l'une des caractéristiques les plus distinctives de ce modèle, survit à la quantification mais pas à tous les conteneurs : le modèle de diffusion détermine la transparence à partir du prompt plutôt qu'à partir d'un commutateur, et l'alpha n'est conservé que dans les sorties .png et .webp.

La planification de la mémoire autour du GGUF lui-même est un domaine où la documentation du runtime est réellement précise, ce qui est rare. stable-diffusion.cpp réutilise comme cache de préfixe les clés et valeurs, indépendantes de l’étape, du texte et de l’image de référence, et publie ce que cela coûte par condition pour le modèle à 32 couches avec un préfixe de 4096 jetons : 4 Gio en FP32, 2 Gio en FP16, 1,0625 Gio en q8_0, 0,5625 Gio en q4_0. La quantification du cache est un deuxième compromis, distinct de la quantification des poids ; elle est désactivée par défaut, et le stockage de cache quantifié introduit une erreur d’arrondi supplémentaire que la documentation signale plutôt que de la masquer.

La licence dont la quantification hérite

C'est la section que la plupart des pages GGUF passent sous silence, et pour ce modèle, c'est celle qui change ce que vous pouvez faire.

Les pondérations de base ne sont pas distribuées sous une licence permissive. Le dépôt Qwen/Qwen-Image-2.1 porte license: other avec license_name: qwen-research, et le fichier LICENSE est le Qwen Research License Agreement, date de publication : 20 septembre 2026. Lu dans son intégralité le 13 octobre 2026, son octroi effectif est une licence non exclusive, mondiale, non transférable et exempte de redevances permettant d'« utiliser, reproduire, distribuer, copier, créer des œuvres dérivées de, et apporter des modifications aux Matériels À DES FINS NON COMMERCIALES UNIQUEMENT », « Non-Commercial » étant défini dans l'accord comme « à des fins de recherche ou d'évaluation uniquement », et l'usage commercial renvoyant à une licence distincte à demander par courriel à l'adresse indiquée dans l'accord.

Un point de contrôle quantifié est une œuvre dérivée de ces Matériaux, ce qui signifie que la redistribution d’un GGUF relève de cet accord et entraîne toutes les conditions qui y sont attachées. Trois d’entre elles sont concrètes :

• Vous devez transmettre l’accord. L’article 3(a) exige que vous remettiez à quiconque reçoit les matériels ou un dérivé une copie de la licence. Un dépôt GGUF avec un tag de licence et sans texte d’accord n’est pas conforme, quel que soit son nombre de téléchargements.

• Vous devez indiquer ce que vous avez modifié. L'article 3(b) exige que les fichiers modifiés portent des mentions bien visibles indiquant qu'ils ont été modifiés. Un fichier de poids réencodé est un fichier modifié.

• Vous devez reproduire textuellement l'avis d'attribution. La section 3(c) exige que le texte de l'avis — « Qwen is licensed under the Qwen RESEARCH LICENSE AGREEMENT, Copyright (c) 2026 Hangzhou Tongyi Laboratory Technology Co., Ltd. All Rights Reserved. » — soit conservé dans un fichier texte « Notice » distribué avec les copies.

Deux règles supplémentaires s'imposent à la personne qui effectue la quantification et à quiconque s'appuie sur le résultat. Si vous entraînez, affinez ou améliorez un modèle d'IA à l'aide des matériaux ou de leurs sorties, puis le distribuez, vous devez afficher de manière bien visible « Construit avec Qwen » ou « Amélioré avec Qwen » dans la documentation du produit. Et vous ne pouvez pas utiliser « Qwen » comme nom principal ou identifiant d'une œuvre dérivée, bien qu'un usage descriptif tel que « affiné à partir de Qwen Image » soit autorisé. Le droit applicable est chinois, avec compétence exclusive attribuée aux tribunaux populaires de Hangzhou.

La conclusion pratique tient en une ligne, et il vaut la peine de l'énoncer clairement parce que le format la dissimule : la quantification des poids ne change pas la licence. Tous les dépôts inspectés pour cette page portent license_name: qwen-research et renvoient au fichier LICENSE du fournisseur, et le nombre de téléchargements d'un fichier GGUF ne constitue pas une concession de droits commerciaux. Par contraste, la précédente gamme d'images Qwen était permissive — les fiches de modèle de Qwen-Image, Qwen-Image-Edit, Qwen-Image-Edit-2511 et Qwen-Image-2512 affichaient toutes apache-2.0 le 13 octobre 2026 — et Qwen-Image-2.1 est la rupture dans ce schéma. Si l'objectif est un pipeline commercial, la licence est la première chose à lire, et non la dernière.

Où cela vous laisse

Énoncé comme une décision plutôt qu'un résumé : si votre carte ne peut pas contenir le transformer de 14,23 Go plus un encodeur de 17,53 Go plus le VAE, une version GGUF est le seul moyen d'exécuter Qwen-Image-2.1 tout court, et l'attente honnête est qu'une quantification de niveau intermédiaire vous achète l'exécution et vous coûte quelque chose en détails fins, en mains, en petits textes et en suivi d'instructions — sans aucune mesure publiée pour vous dire combien. Si votre carte peut le contenir, la voie safetensors est celle que le fournisseur documente et celle qui dispose d'une référence définie.

Deux lecteurs ont besoin d’une phrase chacun ailleurs sur cette propriété. Si ce que vous voulez réellement, c’est une version communautaire débarrassée du filtrage de sécurité plutôt qu’une discussion sur le format, il s’agit d’une autre page et les versions non censurées y sont traitées. Et si votre véritable destination est un graphe de nœuds fonctionnel plutôt qu’un fichier que vous devez assembler à la main, la page ComfyUI parcourt tout le pipeline, chargeur par chargeur.

Ce qui reste en suspens est ce que l’écosystème n’a pas publié : une comparaison contrôlée de ces niveaux sur une graine fixe, avec le même prompt et le même sampler, sur un matériel que quelqu’un nomme. La remarque de RealRebelAI selon laquelle un Q4_K_M générique se dégradait visiblement par rapport à une référence INT8, tandis qu’une build en précision mixte au même libellé ne le faisait pas, est ce qui ressemble le plus à cette réponse dans le domaine public, et il s’agit du test A/B d’un seul éditeur. Tant que personne ne publie la comparaison, le niveau que vous devriez choisir est le plus élevé que votre mémoire permette, et le libellé sur le nom de fichier est une garantie plus faible que la politique de tenseurs qui le sous-tend.