Qwen-Image-2.1 GGUF: Cosa ti costa davvero una build quantizzata

Non esiste un GGUF ufficiale di Qwen-Image-2.1. Ogni .gguf file che porta quel nome è stato prodotto da qualcun altro, a posteriori, prendendo il diffusion transformer 7B del fornitore e ricodificando i suoi pesi a precisione inferiore — GGUF è il formato di checkpoint quantizzato in singolo file che gli stack di inferenza locale leggono. Quella singola frase risponde alla prima domanda che un lettore ha e solleva quelle più difficili che questa pagina risolve: che cosa comprime realmente una quantizzazione di un modello di immagini, che cosa il file omette di default, quanto ti costano i livelli nell'immagine e non solo nel tempo di calcolo, e che cosa richiede ridistribuirne uno in base alla licenza con cui sono arrivati i pesi.

Il modello stesso è il fatto che data questa pagina, non la notizia che riporta. Qwen-Image-2.1 è stato pubblicato su Hugging Face e ModelScope il 20 settembre 2026, e le quantizzazioni della community sono arrivate lo stesso giorno — i repository leejet, Abiray e RealRebelAI sono stati tutti creati il 20 settembre e quello di unsloth il 21 settembre, cioè 23 giorni prima che questa pagina fosse scritta. Nulla di quella cronologia va ripetuto qui; ciò che un lettore che digita "qwen image 2.1 gguf" vuole è il manuale operativo, e questo è quanto.

Che cos'è un GGUF di questo modello e cosa non è

La prima cosa da interiorizzare è che il file è un frammento. Qwen-Image-2.1 non è un'unica rete; è un transformer di diffusione più un text encoder vision-language più un autoencoder. Le quantizzazioni che circolano sotto il suo nome contengono il primo di essi e nient'altro, e i repository lo dicono essi stessi. La scheda di Unsloth per il suo Qwen-Image-2.1 GGUF lo riassume in una riga: "Un GGUF è solo il denoiser, quindi ha bisogno del VAE e del text encoder Qwen3-VL accanto."

Quindi un download GGUF è il transformer — 32 layer DiT single-stream, 7 miliardi di parametri nel componente di generazione visiva — riespresso a precisione numerica ridotta. L'encoder di testo e il VAE restano nei loro formati originali oppure vengono quantizzati separatamente, da persone diverse, in repository diversi. Questa è la differenza strutturale rispetto alla situazione dei modelli di testo che molti lettori hanno in mente: quando scarichi un GGUF di un modello di chat, hai scaricato il modello. Qui hai scaricato un terzo di una pipeline.

Niente di tutto questo è il packaging del fornitore. Il repository del fornitore Qwen/Qwen-Image-2.1 è una release con layout Diffusers — model_index.json, transformer/, text_encoder/, vae/, scheduler/, processor/ — e il suo elenco dei file, consultato il 13 ottobre 2026, non contiene alcun file .gguf di alcun tipo. Le quantizzazioni sono artefatti della comunità, pubblicati sotto il nome dei rispettivi autori, ed ereditano la licenza del fornitore anziché l'avallo del fornitore.

Perché la saggezza sulla quantizzazione dei modelli testuali non si trasferisce

Le convinzioni diffuse su GGUF provengono dai modelli linguistici, dove più o meno sono queste: Q8_0 è di fatto senza perdite, Q4_K_M è il punto di equilibrio ideale, qualunque cosa sotto Q3 è un compromesso, e la qualità si misura come perplessità o divergenza KL rispetto a un riferimento a piena precisione. Quasi nulla di tutto ciò si applica a un modello per immagini, e le ragioni meritano di essere precisate.

Non esiste una perplessità per un transformer di diffusione. Il modello non emette una distribuzione di token che puoi valutare; emette un latente che un VAE decodifica in pixel. Le metriche che esistono da questo lato della barricata — LPIPS, SSIM rispetto a un rendering di riferimento — richiedono lo stesso seed, lo stesso prompt e le stesse impostazioni del sampler su entrambi i lati del confronto, e misurano comunque la distanza percettiva piuttosto che la correttezza. Quindi la domanda "quanto mi costa Q4_K_M?" non ha un singolo numero pubblicato come ce l'ha per un modello di testo, e chiunque ne citi uno sta citando una singola misurazione su un singolo seed.

Secondo, e cosa più rilevante: su un modello di immagini, la media ampiezza in bit conta meno di quali tensori hanno perso i loro bit. Le proiezioni di attenzione e i percorsi MLP che trasportano la struttura dell'immagine si degradano in modo visibile quando vengono arrotondati, mentre i piccoli tensori di normalizzazione e modulazione tollerano quasi qualsiasi cosa. Una conversione che raggiunge un target uniforme su ogni tensore può quindi apparire peggiore di una conversione con la stessa etichetta nominale che protegge gli strati sensibili — che è esattamente ciò che hanno riscontrato le persone che svolgono questo lavoro. RealRebelAI, pubblicando le note di quantizzazione più esplicite che siamo riusciti a trovare, afferma che "una conversione Q4_K_M generica standard ha mostrato una perdita di qualità visibile nella struttura fine e nell'anatomia rispetto al modello INT8 di riferimento", e che le sue stesse build mantengono Q/K/V/Out dell'attenzione a Q8_0 all'interno di un file Q4_K_M per recuperarla. L'etichetta sul nome del file è la quantizzazione di base, non la policy.

Terzo, la modalità di guasto è di natura diversa. La quantizzazione del testo peggiora soprattutto in termini di scorrevolezza, e degrada in modo morbido: una frase leggermente peggiore è pur sempre una frase. La quantizzazione delle immagini ai livelli più bassi fallisce in modi evidenti e talvolta inutilizzabili: mani e anatomia, texture fini, tipografia di piccole dimensioni e — quello che è facile lasciarsi sfuggire perché non è affatto un artefatto di pixel — l'aderenza al prompt. Se una build smette di obbedire a metà di una lunga istruzione, quello è un costo di quantizzazione, e non emergerà in un confronto affiancato tra due buoni render.

La scala, in file anziché in aggettivi

Le dimensioni dei file sono l'unica parte di questo che è un dato di fatto concreto anziché un giudizio, perché ogni repository pubblica il proprio elenco. Consultate il 13 ottobre 2026, le due quantizzazioni della community più scaricate divergono leggermente l'una dall'altra, il che è di per sé informativo.

• Unsloth Dynamic 2.0 (12 file): 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 file): Q8_0 7,69 GB, Q6_K 6,00 GB, Q5_0 5,07 GB, Q4_K 4,20 GB, Q4_0 4,20 GB, Q3_K 3,27 GB, Q2_K 2,56 GB.

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

• RealRebelAI pubblica una scala a precisione mista con -HQv3 come suffisso anziché livelli semplici, e documenta la precisione per modulo in una tabella; le quantizzazioni di base vanno da Q2_K a Q8_0.

La dispersione è reale. Q8_0 va da 7,59 a 7,69 GB su tre publisher, e Q6_K va da 5,88 a 6,27 GB — un divario di 0,4 GB per lo stesso livello nominale, ovvero la politica di precisione mista che si manifesta nei byte. Chiunque confronti due build basandosi solo sul nome del file sta confrontando etichette, non artefatti.

Per dare un'idea della scala dall'altro lato: il transformer F16 di riferimento è di 14,23 GB, e il componente di diffusione bfloat16 dello stesso fornitore nel repack di Comfy-Org è di 14,23 GB. Quindi un GGUF di classe Q4 è all'incirca una riduzione di 3,4× sul transformer, e nessuna riduzione di sorta sul text encoder, a meno che non lo si quantizzi separatamente.

Quanto costa ogni gradino, dove una fonte lo afferma

Quasi nessuno pubblica un costo di qualità misurato per livello per questo modello, e la cosa onesta da fare è distinguere i tre tipi di affermazione in circolazione.

• Indicazioni sulla memoria, segnalate dalla community. Il repository di Abiray associa a ciascun file un profilo VRAM consigliato: Q8_0 7,59 GB con "12 GB+ (fedeltà quasi senza perdite)", Q6_K 5,88 GB con 10–12 GB, Q5_K_M 5,01 GB con 8–10 GB, Q4_K_M 4,19 GB e Q4_K_S 4,06 GB con 6–8 GB, e Q3_K_M 3,19 GB con 4–6 GB per "budget estremo / VRAM minima". Queste sono le regole pratiche dell'autore stesso, non una specifica del fornitore né un benchmark che abbiamo potuto riprodurre; inoltre descrivono solo il file del transformer, quindi il margine necessario per il text encoder va considerato in aggiunta.

• Un confronto misurato, riportato dal quantizzatore e basato su un singolo seed. Unsloth pubblica una coppia di numeri per il lato encoder della pipeline: il suo text encoder Dynamic 2.0 a 4 bit contro un encoder uniforme Q4_K_M, entrambi su un seed condiviso con il denoiser e il VAE tenuti fissi, a LPIPS 0,029 e SSIM 0,959, in 5,15 GB contro 5,03 GB e 36,5 s contro 39,0 s. Si tratta di una singola misurazione effettuata da chi vende il file, su un solo seed, ed è l'unico confronto quantitativo pubblicato tra due politiche di quantizzazione per questo modello che siamo riusciti a individuare.

• Elenchi qualitativi di fallimenti, segnalati dalla community. RealRebelAI indica ciò che la quantizzazione a bit inferiori può ancora influenzare — "dettagli fini, mani e anatomia, tipografia, aderenza al prompt, fedeltà delle modifiche, coerenza delle texture" — e consiglia di salire di un gradino quando la degradazione è visibile. Afferma chiaramente che Q3_K_M e Q2_K sono per sistemi con memoria limitata e "potrebbero comunque mostrare una crescente perdita di qualità nonostante gli strati ad alta precisione protetti".

Ciò che non è pubblicato è importante quanto ciò che lo è. Non c'è assolutamente alcuna dichiarazione del fornitore sulla qualità di quantizzazione per Qwen-Image-2.1, nessun benchmark indipendente di qualsiasi build GGUF, e nessuna tabella di throughput su hardware di consumo specificamente indicato da nessuno di quelli che siamo riusciti a trovare. La direzione del compromesso sulla memoria è certa e la direzione del compromesso sulla velocità è ampiamente certa; l'entità del costo in termini di fedeltà non è stabilita pubblicamente, e questa pagina non lo stimerà per voi.

Che cosa lo esegue effettivamente

La situazione del runtime è insolitamente consolidata per un formato così recente, il che rappresenta un vero vantaggio rispetto alla solita situazione di GGUF.

• stable-diffusion.cpp — l'implementazione di riferimento per i modelli immagine in formato GGUF. Il suo elenco di notizie del progetto registra il supporto Day-0 per Qwen-Image-2.1 il 20 settembre 2026 e documenta una pagina dedicata al modello. La riga di comando accetta direttamente il modello di diffusione quantizzato: --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, con --steps 20 --cfg-scale 6.0 --sampling-method euler nell'esempio fornito dall'editore stesso.

• ComfyUI, tramite un nodo personalizzato. Questa è la strada che seguiranno la maggior parte dei lettori, e ha una complicazione che vale la pena conoscere prima di installare qualsiasi cosa. Il repository che la maggior parte dei quantizzatori indica è city96/ComfyUI-GGUF; l'autore di stable-diffusion.cpp pubblica il proprio fork, leejet/ComfyUI-GGUF, e il suo README contiene un'istruzione esplicita a preferirlo, con la motivazione dichiarata che "il repository city96 sembra non essere più mantenuto attivamente". Si tratta di un'affermazione di una parte su un'altra ed è datata; la cronologia dei commit su city96/ComfyUI-GGUF mostra effettivamente la sua attività più recente a gennaio 2026. La pagina di documentazione ufficiale di ComfyUI per Qwen-Image-2.1 elenca solo .safetensors pesi e non menziona affatto GGUF, quindi il nodo personalizzato non è opzionale e non è approvato dal fornitore. Entrambi i loader collocano il file in ComfyUI/models/diffusion_models/ e lo espongono tramite un loader GGUF per modelli di diffusione.

• llama.cpp / ggml — non un sampler per questo modello, ma l'origine del formato e la toolchain che produce questi file. Entrambi i repository leejet e Abiray lo citano esplicitamente. Se vuoi un livello che nessuno ha pubblicato, questo è ciò con cui converti.

• Unsloth Desktop — citato dal repository unsloth come front-end supportato insieme a stable-diffusion.cpp.

Un runtime, in modo evidente, non lo carica: Diffusers. Il quick-start dello stesso fornitore è una QwenImage21Pipeline sul repository safetensors in bfloat16, e in quella pipeline non esiste alcun percorso GGUF. Se vuoi Diffusers, non sei il pubblico giusto per un file quantizzato; se vuoi un file quantizzato, la tua destinazione è stable-diffusion.cpp o un grafo ComfyUI.

La parte che blocca davvero le persone

Ogni segnalazione di errore relativa a questo formato risale sempre alla stessa cosa: il GGUF è il transformer, quindi il resto della pipeline deve essere assemblato a mano, nei formati giusti, dai repository giusti. Tre componenti sono in ambito e uno di essi contiene una trappola.

• Il codificatore di testo. Qwen-Image-2.1 si basa su Qwen3-VL 8B, e quel codificatore è più grande del transformer a piena precisione — 17,53 GB in bfloat16 nel repack di Comfy-Org, contro 14,23 GB per il modello di diffusione. Esistono alternative quantizzate a 9,35 GB (int8) e 6,31 GB (w4a8) nello stesso repack, e indipendentemente come GGUF: il fornitore pubblica un Qwen/Qwen3-VL-8B-Instruct-GGUF first-party con F16 a 16,39 GB, Q8_0 a 8,71 GB e Q4_K_M a 5,03 GB. Nota che questo GGUF del codificatore è un artefatto del fornitore, a differenza del GGUF del transformer che gli sta accanto — le due metà della tua pipeline provengono da editori diversi con provenienze diverse.

• Il VAE. Un singolo file, qwen_image_2.1_vae_bf16.safetensors, 0,68 GB nel repack Comfy-Org. È piccolo ed è il componente che più spesso si presume sia intercambiabile, e non lo è: la documentazione di stable-diffusion.cpp afferma che i pesi VAE precedenti di Qwen Image e Wan 2.2 non sono intercambiabili con i pesi VAE di Qwen Image 2.1. Abbina quello sbagliato e il grafo si carica e produce l'immagine sbagliata.

• Il proiettore di visione, se vuoi modificarlo. Il text-to-image è la metà facile. Per la modifica delle immagini l'encoder necessita di un proiettore multimodale separato: la documentazione di stable-diffusion.cpp indica ai lettori di scaricare anche mmproj-Qwen3VL-8B-Instruct-F16.gguf (1,16 GB) dal repository dell'encoder e di passarlo con --llm_vision, e di ripetere -r una volta per ogni immagine di riferimento. Un GGUF solo transformer più un text encoder è una pipeline text-to-image e nulla di più.

Vale la pena conoscere altri due upload. La release include anche due encoder di riscrittura dei prompt — Qwen-Image-2.1-PE-T2I e Qwen-Image-2.1-PE-I2I, entrambi modelli da 9B fine-tuned — che il fornitore consiglia di eseguire davanti al modello di immagini, e anche questi vengono quantizzati: una build GGUF del rewriter T2I del progetto LightX2V è apparsa su Hugging Face il 12 ottobre 2026, insieme a diverse build della community. E il canale alpha, che è una delle caratteristiche più distintive di questo modello, sopravvive alla quantizzazione ma non a tutti i container: il modello di diffusione decide la trasparenza dal prompt anziché da un interruttore, e l'alpha viene mantenuto solamente nei file .png e .webp di output.

La pianificazione della memoria attorno al GGUF stesso è un ambito in cui la documentazione del runtime è davvero specifica, cosa rara. stable-diffusion.cpp riutilizza le chiavi e i valori del testo e delle immagini di riferimento indipendenti dallo step come cache di prefisso, e pubblica quanto questo costa per condizione per il modello a 32 strati con un prefisso di 4096 token: 4 GiB a FP32, 2 GiB a FP16, 1,0625 GiB a q8_0, 0,5625 GiB a q4_0. Quantizzare la cache è un secondo compromesso, separato dalla quantizzazione dei pesi, è disattivato per impostazione predefinita, e l'archiviazione della cache quantizzata introduce un errore di arrotondamento aggiuntivo che la documentazione segnala anziché nascondere.

La licenza che la quantizzazione eredita

Questa è la sezione che la maggior parte delle pagine GGUF salta, e per questo modello è quella che cambia ciò che puoi fare.

I pesi di base non sono distribuiti con una licenza permissiva. Il Qwen/Qwen-Image-2.1 repository presenta license: other con license_name: qwen-research, e il file LICENSE è il Qwen Research License Agreement, data di rilascio 20 settembre 2026. Letto integralmente il 13 ottobre 2026, la sua concessione operativa è una licenza non esclusiva, mondiale, non trasferibile, esente da royalty per "usare, riprodurre, distribuire, copiare, creare opere derivate e apportare modifiche ai Materiali SOLO PER SCOPI NON COMMERCIALI", con "Non commerciale" definito all'interno dell'accordo come "solo per scopi di ricerca o valutazione" e l'uso commerciale indirizzato a una licenza separata richiesta via email all'indirizzo indicato nell'accordo.

Un checkpoint quantizzato è un'opera derivata di quei Materiali, il che significa che la ridistribuzione di un GGUF è una ridistribuzione ai sensi di tale accordo e assorbe ogni condizione a esso collegata. Tre di esse sono concrete:

• Devi trasmettere l'accordo. La sezione 3(a) richiede che tu dia a chiunque riceva i materiali o un'opera derivata una copia della licenza. Un repository GGUF con un tag di licenza e senza il testo dell'accordo non è conforme, qualunque sia il suo numero di download.

• Devi contrassegnare ciò che hai modificato.La sezione 3(b) richiede che i file modificati rechino avvisi ben visibili che dichiarino che sono stati modificati. Un file di pesi ricodificato è un file modificato.

• Devi riportare l'avviso di attribuzione testualmente. La sezione 3(c) richiede che il testo dell'avviso — "Qwen is licensed under the Qwen RESEARCH LICENSE AGREEMENT, Copyright (c) 2026 Hangzhou Tongyi Laboratory Technology Co., Ltd. All Rights Reserved." — sia conservato in un file di testo "Notice" distribuito con le copie.

Due ulteriori regole vincolano la persona che esegue la quantizzazione e chiunque costruisca sul risultato. Se addestri, metti a punto o migliori un modello di IA utilizzando i materiali o i loro output e poi lo distribuisci, devi visualizzare in modo prominente "Built with Qwen" o "Improved using Qwen" nella documentazione del prodotto. E non puoi usare "Qwen" come nome primario o identificatore di un'opera derivata, sebbene sia consentito l'uso descrittivo come "fine-tuned from Qwen Image". La legge applicabile è quella cinese, con giurisdizione esclusiva nei Tribunali del Popolo di Hangzhou.

Il risultato pratico sta in una riga, e vale la pena affermarlo chiaramente perché il formato lo nasconde: quantizzare i pesi non cambia la licenza. Ogni repository esaminato per questa pagina riporta license_name: qwen-research e rimanda al file LICENSE del fornitore, e il numero di download di un file GGUF non costituisce una concessione di diritti commerciali. Per contro, la precedente linea di immagini Qwen era permissiva — le model card di Qwen-Image, Qwen-Image-Edit, Qwen-Image-Edit-2511 e Qwen-Image-2512 riportavano tutte apache-2.0 il 13 ottobre 2026 — e Qwen-Image-2.1 è la rottura di questo schema. Se l'obiettivo è una pipeline commerciale, la licenza è la prima cosa da leggere, non l'ultima.

Dove questo ti lascia

Detto come decisione anziché come riassunto: se la tua scheda non può contenere il transformer da 14,23 GB più un encoder da 17,53 GB più il VAE, una build GGUF è l'unico modo in cui puoi eseguire Qwen-Image-2.1, e l'aspettativa onesta è che una quantizzazione di livello intermedio ti permetta di eseguirlo ma ti costi qualcosa in dettagli fini, mani, testi piccoli e rispetto delle istruzioni — senza alcuna misurazione pubblicata che ti dica quanto. Se la tua scheda può contenerlo, il percorso safetensors è quello documentato dal produttore e quello con un riferimento definito.

Due lettori hanno bisogno ciascuno di una frase in un'altra sezione di questa proprietà. Se quello che vuoi effettivamente è una build della community con il filtraggio di sicurezza rimosso anziché una discussione del formato, quella è una pagina diversa e le build non censurate sono trattate lì. E se la tua vera meta è un grafo di nodi funzionante anziché un file che devi assemblare a mano, la pagina di ComfyUI percorre l'intera pipeline, loader per loader.

Ciò che rimane aperto è la cosa che l'ecosistema non ha pubblicato: un confronto controllato di questi livelli su un seed fisso, con lo stesso prompt e lo stesso sampler, su hardware che qualcuno nomina. L'osservazione di RealRebelAI che un Q4_K_M generico si degradava visibilmente rispetto a un riferimento INT8 mentre una build a precisione mista con la stessa etichetta no, è la cosa più vicina a quella risposta in pubblico, ed è il test A/B di un singolo editore. Finché qualcuno non pubblica il confronto, il livello che dovresti scegliere è il più alto che la tua memoria consente, e l'etichetta sul nome del file è una garanzia più debole della politica dei tensori che vi sta dietro.