Genererat hero-kort med titeln ”Qwen-Image-2.1 GGUF”, med underrubriken ”denoisern, med lägre precision”, som listar Q8_0 vid 7,64 GB, Q4_K_M vid 4,20 GB och F16 vid 14,23 GB, med en sidfot som lyder ”storlekar avlästa från publicerade filförteckningar i repositoriet, 13 oktober 2026”.
Guides & Insights

Qwen-Image-2.1 GGUF: Vad ett kvantiserat bygge faktiskt kostar dig

Författare

Elias Hawthorne

Publiceringsdatum

Senaste modellerna · 20Visa alla modeller →
Benchmarks: Artificial Analysis · uppdateras dagligen
Tillbaka till alla inlägg

Det finns ingen officiell GGUF av Qwen-Image-2.1. Varje .gguf fil som bär det namnet producerades av någon annan, i efterhand, genom att ta leverantörens 7B-diffusionstransformator och koda om dess vikter med lägre precision — GGUF är det enfiliga kvantiserade checkpoint-formatet som de lokala inferensstackarna läser. Den där enda meningen besvarar den första frågan en läsare har och väcker de svårare som den här sidan reder ut: vad en kvantisering av en bildmodell egentligen komprimerar, vad filen utelämnar direkt ur lådan, vad nivåerna kostar dig i bilden snarare än bara i klockan, och vad en vidaredistribution av en sådan kräver enligt licensen som vikterna kom med.

Det som daterar den här sidan är själva modellen, inte nyheterna den rapporterar. Qwen-Image-2.1 lades upp på Hugging Face och ModelScope den 20 september 2026, och community-kvantiseringar av den följde samma dag – leejet-, Abiray- och RealRebelAI-repona skapades alla den 20 september och unsloths den 21 september, vilket är 23 dagar innan den här sidan skrevs. Inget i den tidslinjen behöver upprepas här; vad en läsare som skriver "qwen image 2.1 gguf" vill ha är bruksanvisningen, och det här är den.

Vad en GGUF av den här modellen är, och vad den inte är

Det första man måste internalisera är att filen är ett fragment. Qwen-Image-2.1 är inte ett enda nätverk; det är en diffusionstransformator plus en vision-språk-textkodare plus en autoencoder. Kvantiseringarna som cirkulerar under dess namn innehåller den första av dem och inget annat, och repona säger det själva. Unsloths modellkort för dess Qwen-Image-2.1 GGUF sammanfattar det i en rad: ”En GGUF är bara avbrusaren, så den behöver VAE:n och Qwen3-VL-textkodaren vid sin sida.”

Så en GGUF-nedladdning är transformatorn — 32 enkelströms-DiT-lager, 7B parametrar i den visuella genereringskomponenten — återgiven med reducerad numerisk precision. Textkodaren och VAE:n förblir i sina ursprungliga format eller kvantiseras separat, av olika personer, i olika repositorier. Detta är den strukturella skillnaden gentemot den textmodellssituation som de flesta läsare bär med sig i huvudet: när du laddar ner en GGUF för en chattmodell har du laddat ner modellen. Här har du laddat ner en tredjedel av en pipeline.

Inget av detta är leverantörens paketering. Leverantörens arkiv Qwen/Qwen-Image-2.1 är en utgåva med Diffusers-layout – model_index.json, transformer/, text_encoder/, vae/, scheduler/, processor/ – och dess fillista, läst den 13 oktober 2026, innehåller ingen .gguf-fil av något slag. Kvantiseringarna är gemenskapsartefakter, publicerade under sina författares namn, och de ärver leverantörens licens snarare än leverantörens godkännande.

Varför visdomen om kvantisering av textmodeller inte överförs

Den vedertagna uppfattningen om GGUF kommer från språkmodeller, där den ungefär är: Q8_0 är i praktiken förlustfritt, Q4_K_M är den optimala balansen, allt under Q3 är en kompromiss, och kvalitet mäts som perplexitet eller KL-divergens mot en fullprecisionsreferens. Nästan inget av det överförs till en bildmodell, och anledningarna är värda att redogöra för på ett precist sätt.

Det finns ingen perplexitet för en diffusionstransformer. Modellen avger ingen tokenfördelning som du kan poängsätta; den avger en latent representation som en VAE avkodar till pixlar. De mått som finns på den här sidan av staketet – LPIPS, SSIM mot en referensrendering – kräver samma slumpfrö, samma prompt och samma sampler-inställningar på båda sidor av jämförelsen, och de mäter fortfarande perceptuellt avstånd snarare än korrekthet. Så frågan "hur mycket kostar Q4_K_M mig?" har inget enskilt publicerat tal på samma sätt som för en textmodell, och den som citerar ett sådant tal citerar en enda mätning med ett enda slumpfrö.

För det andra, och med större konsekvenser: i en bildmodell spelar den genomsnittliga bitbredden mindre roll än vilka tensorer som förlorade sina bitar. Attention-projektionerna och MLP-vägarna som bär bildstrukturen försämras synligt när de avrundas, medan små normaliserings- och modulationstensorer tål nästan vad som helst. En konvertering som träffar ett enhetligt mål över alla tensorer kan därför se sämre ut än en konvertering med samma nominella etikett som skyddar de känsliga lagren – vilket är precis vad de som arbetar med detta upptäckte. RealRebelAI, som publicerar de mest explicita kvantiseringsanteckningar vi kunde hitta, anger att "en standardmässig generisk Q4_K_M-konvertering visade synlig kvalitetsförlust i finstruktur och anatomi jämfört med referensmodellen INT8", och att deras egna byggen behåller attention Q/K/V/Out i Q8_0 inuti en Q4_K_M-fil för att återställa detta. Etiketten i filnamnet är baskvantiseringen, inte policyn.

För det tredje är felmoden av en annan art. Textkvantisering försämras mest i form av flyt, och den försämras skonsamt – en något sämre mening är fortfarande en mening. Bildkvantisering på de låga nivåerna misslyckas på sätt som är uppenbara och ibland oanvändbara: händer och anatomi, fin textur, liten typografi, och – den som är lätt att missa eftersom den inte alls är en pixelartefakt – promptföljsamhet. Om en build slutar följa hälften av en lång instruktion är det en kvantiseringskostnad, och den kommer inte att synas i en sida-vid-sida-jämförelse av två bra renderingar.

Stegen, i filer snarare än adjektiv

Filestorlekar är den enda delen av det här som är hårda fakta snarare än en bedömning, eftersom varje repositorium publicerar sin egen lista. Läst den 13 oktober 2026 skiljer sig de två mest nedladdade community-kvantiseringarna något åt, vilket i sig är informativt.

• Unsloth Dynamic 2.0 (12 filer): 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 filer): 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 filer): 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.

• RealRebelAIpublicerar en stege för blandad precision med ett -HQv3-suffix i stället för vanliga nivåer och dokumenterar precision per modul i en tabell; baskvantiseringarna går från Q2_K till Q8_0.

Spridningen är verklig. Q8_0 sträcker sig från 7,59 till 7,69 GB över tre utgivare, och Q6_K sträcker sig från 5,88 till 6,27 GB – en lucka på 0,4 GB för samma nominella nivå, vilket är policyn för blandad precision som visar sig i byte. Den som jämför två byggen enbart utifrån filnamn jämför etiketter, inte artefakter.

För att sätta det i proportion på andra sidan: referens-F16-transformatorn är 14,23 GB, och leverantörens egen bfloat16-diffusionskomponent i Comfy-Org-repacken är 14,23 GB. Så en GGUF i Q4-klass är ungefär en 3,4× minskning för transformatorn, och ingen minskning alls för textkodaren om du inte kvantiserar den separat.

A reference card for Qwen-Image-2.1 GGUF listing the published size of each quantisation level from the unsloth Dynamic 2.0 repository: 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 and Q2_K 2.47 GB, with a footer reading 'sizes as published in the repository file listing, read 13 October 2026'

Vad varje steg kostar, där en källa säger det

Nästan ingen publicerar en uppmätt kvalitetskostnad per nivå för den här modellen, och det ärliga att göra är att skilja på de tre typerna av påståenden som cirkulerar.

• Minnesvägledning, community-rapporterad. Abirays arkiv parar ihop varje fil med en rekommenderad VRAM-profil: Q8_0 7,59 GB vid "12 GB+ (nära förlustfri återgivning)", Q6_K 5,88 GB vid 10–12 GB, Q5_K_M 5,01 GB vid 8–10 GB, Q4_K_M 4,19 GB och Q4_K_S 4,06 GB vid 6–6", och Q3_K_M 3,19 GB vid 4–6 GB för "extrem budget / minimal VRAM". Dessa är utgivarens egen tumregel, inte en leverantörsspecifikation och inte ett riktmärke som vi kunde reproducera; de beskriver textkodaren?

• En uppmätt jämförelse, rapporterad av kvantiseraren och med en enda seed.Unsloth publicerar ett talpar för encodersidan av pipelinen: dess Dynamic 2.0 4-bitars textencoder mot en enhetlig Q4_K_M-encoder, båda med en gemensam seed med denoisern och VAE oförändrade, vid LPIPS 0,029 och SSIM 0,959, i 5,15 GB mot 5,03 GB och 36,5 s mot 39,0 s. Det är en mätning av den part som säljer filen, på en seed, och det är den enda publicerade kvantitativa jämförelsen av två kvantiseringsprinciper för denna modell som vi kunde hitta.

• Kvalitativa fellistor, communityrapporterade. RealRebelAI namnger vad kvantisering med lägre bitantal fortfarande kan påverka – "fina detaljer, händer och anatomi, typografi, promptföljsamhet, redigeringsfidelitet, texturkonsistens" – och rekommenderar att gå upp ett steg när försämring syns. Det säger klart att Q3_K_M och Q2_K är för minnesbegränsade system och "kan fortfarande uppvisa ökande kvalitetsförlust trots de skyddade högprecisionslagren."

Vad som inte publiceras är lika viktigt som vad som publiceras. Det finns över huvud taget inget uttalande från tillverkaren om kvantiseringskvalitet för Qwen-Image-2.1, ingen oberoende benchmark av något GGUF-bygge och ingen genomströmningstabell för namngiven konsumenthårdvara från någon vi kunde hitta. Riktningen för minnesavvägningen är säker och riktningen för hastighetsavvägningen är i stort sett säker; storleken på kostnaden för återgivningstrohet är inte fastställd offentligt, och den här sidan kommer inte att uppskatta den åt dig.

Vad driver det egentligen?

Runtime-situationen är ovanligt stabil för ett format så här nytt, vilket är en verklig fördel jämfört med den vanliga GGUF-situationen.

• stable-diffusion.cpp — referensimplementationen för GGUF för bildmodeller. I dess projektnyheter listas Day-0-stöd för Qwen-Image-2.1 den 20 september 2026, och den dokumenterar en dedikerad sida för modellen. Kommandoraden tar den kvantiserade diffusionsmodellen direkt: --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, med --steps 20 --cfg-scale 6.0 --sampling-method euler i utgivarens eget exempel.

• ComfyUI, via en anpassad nod. Det här är vägen de flesta läsare kommer att ta, och den har en hake som är värd att känna till innan du installerar något. Repositoriet som de flesta kvantiserare pekar på är city96/ComfyUI-GGUF; författaren till stable-diffusion.cpp publicerar sin egen fork, leejet/ComfyUI-GGUF, och hans README innehåller en uttrycklig instruktion att föredra den, med den angivna motiveringen att "city96-repositoriet verkar inte längre underhållas aktivt." Det är ett påstående från en part om en annan och det är daterat; commit-historiken för city96/ComfyUI-GGUF visar faktiskt sin senaste aktivitet i januari 2026. ComfyUI:s egen officiella dokumentationssida för Qwen-Image-2.1 listar endast .safetensors-vikter och nämner inte GGUF alls, så den anpassade noden är inte valfri och är inte välsignad av leverantören. Båda laddarna placerar filen i ComfyUI/models/diffusion_models/ och exponerar den via en GGUF-laddare för diffusionsmodeller.

• llama.cpp / ggml — inte en sampler för denna modell, utan ursprunget till formatet och verktygskedjan som producerar dessa filer. Både leejet- och Abiray-repositorierna krediterar det uttryckligen. Om du vill ha en nivå som ingen har publicerat, är det här vad du konverterar med.

• Unsloth Desktop — som unsloth-repositoriet namnger som en frontend som stöds vid sidan av stable-diffusion.cpp.

En runtime inteladdar den uppenbarligen Diffusers. Leverantörens egen snabbstart är en QwenImage21Pipeline över bfloat16-safetensors-repositoriet, och det finns ingen GGUF-väg i den pipelinen. Om du vill använda Diffusers är du inte målgruppen för en kvantiserad fil; om du vill ha en kvantiserad fil är stable-diffusion.cpp eller en ComfyUI-graf där du hamnar.

Screenshot of the stable-diffusion.cpp documentation page for Qwen Image 2.1, captured 13 October 2026, showing the download list for the diffusion model, VAE and Qwen3-VL-8B text encoder in both safetensors and GGUF form, the sd-cli example command passing --diffusion-model, --vae and --llm, and the note that earlier Qwen Image and Wan 2.2 VAE weights are not interchangeable with the Qwen Image 2.1 VAE

Den del som faktiskt hindrar folk

Varje felrapport kring det här formatet kan spåras tillbaka till samma sak: GGUF är transformatorn, så resten av pipelinen måste sättas ihop manuellt, i rätt format, från rätt repositorier. Tre komponenter ingår i omfattningen och en av dem har en fälla i sig.

• Textkodaren. Qwen-Image-2.1 betingas på Qwen3-VL 8B, och den kodaren är större än transformatorn vid full precision – 17,53 GB i bfloat16 i Comfy-Org-omförpackningen, mot 14,23 GB för diffusionsmodellen. Det finns kvantiserade alternativ på 9,35 GB (int8) och 6,31 GB (w4a8) i samma omförpackning, och oberoende som GGUF: leverantören publicerar en förstapartsmodell, Qwen/Qwen3-VL-8B-Instruct-GGUF med F16 på 16,39 GB, Q8_0 på 8,71 GB och Q4_K_M på 5,03 GB. Observera att denna kodar-GGUF är en leverantörsartefakt, till skillnad från den transformator-GGUF som den ligger bredvid – de två halvorna av din pipeline kommer från olika utgivare med olika proveniens.

• VAE:n. En enstaka fil, qwen_image_2.1_vae_bf16.safetensors, 0,68 GB i Comfy-Org-ompackningen. Den är liten och den är den komponent som folk oftast antar är utbytbar, och det är den inte: dokumentationen för stable-diffusion.cpp anger att de tidigare VAE-vikterna för Qwen Image och Wan 2.2 inte är utbytbara mot VAE-vikterna för Qwen Image 2.1. Kombinerar du fel laddas grafen och producerar fel bild.

• Visionsprojektorn, om du vill redigera. Text-till-bild är den enkla hälften. För bildredigering behöver encodern en separat multimodal projektor: dokumentationen för stable-diffusion.cpp uppmanar läsarna att även ladda ner mmproj-Qwen3VL-8B-Instruct-F16.gguf (1,16 GB) från encoderns kodförråd och ange den med --llm_vision, samt upprepa -r en gång per referensbild. En GGUF med enbart en transformer plus en textencoder är en text-till-bild-pipeline och inget mer.

Ytterligare två uppladdningar är värda att känna till. Släppet innehåller även två promptomskrivande encoders – Qwen-Image-2.1-PE-T2I och Qwen-Image-2.1-PE-I2I, båda finjusterade 9B-modeller – som leverantören rekommenderar att köra framför bildmodellen, och även dessa kvantiseras: ett GGUF-bygge av T2I-omskrivaren från LightX2V-projektet dök upp på Hugging Face den 12 oktober 2026, tillsammans med flera community-byggen. Och alfakanalen, som är en av den här modellens mer utmärkande egenskaper, överlever kvantisering men inte alla containrar: diffusionsmodellen avgör transparens utifrån prompten snarare än via en brytare, och alfan bevaras endast i .png och .webp-utdata.

Minnesplanering kring själva GGUF är en punkt där runtime-dokumentationen är genuint specifik, vilket är sällsynt. stable-diffusion.cpp återanvänder de stegoberoende nycklarna och värdena för text och referensbilder som en prefixcache, och publicerar vad det kostar per betingelse för 32-lagersmodellen vid ett prefix på 4096 token: 4 GiB vid FP32, 2 GiB vid FP16, 1,0625 GiB vid q8_0, 0,5625 GiB vid q4_0. Att kvantisera cachen är en andra, separat avvägning från att kvantisera vikterna, den är avstängd som standard, och kvantiserad cachelagring medför ytterligare avrundningsfel som dokumentationen påpekar i stället för att dölja.

Screenshot of the RealRebelAI Qwen-Image-2.1 GGUF repository README on Hugging Face, captured 13 October 2026, showing the note that a standard generic Q4_K_M conversion showed visible quality loss in fine structure and anatomy against the reference INT8 model, a quant ladder table listing Q8_0-HQv3 through Q2_K-HQv3 with the precision kept for attention Q/K/V/Out and the img_mlp projections, and a list of what lower-bit quantisation can still affect including fine detail, hands and anatomy, typography and prompt adherence

Licensen som kvantiseringen ärver

Det här är avsnittet som de flesta GGUF-sidor hoppar över, och för den här modellen är det det som förändrar vad du kan göra.

Basvikterna distribueras inte under en tillåtande licens. Qwen/Qwen-Image-2.1-arkivet har licens: annan med licensnamn: qwen-research, och LICENSE-filen är Qwen Research License Agreement, utgivningsdatum 20 september 2026. Läst i sin helhet den 13 oktober 2026, dess faktiska beviljande är en icke-exklusiv, världsomspännande, icke-överlåtbar, royaltyfri licens att "använda, reproducera, distribuera, kopiera, skapa derivatverk av och göra ändringar i Materialet ENDAST FÖR ICKE-KOMMERSIELLA ÄNDAMÅL", där "Icke-kommersiell" definieras i avtalet som "endast för forsknings- eller utvärderingsändamål" och kommersiell användning hänvisas till en separat licens som begärs via e-post på den adress som avtalet anger.

En kvantiserad checkpoint är ett derivatverk av dessa Material, vilket innebär att vidaredistribution av en GGUF är vidaredistribution enligt det avtalet och omfattas av varje villkor som är knutet till det. Tre av dem är konkreta:

• Du måste föra avtalet vidare.Avsnitt 3(a) kräver att du ger alla som tar emot materialet eller ett derivat en kopia av licensen. Ett GGUF-repositorium med en licenstagg och ingen avtalstext uppfyller inte kraven, oavsett dess nedladdningsantal.

• Du måste markera vad du har ändrat. Avsnitt 3(b) kräver att ändrade filer har framträdande meddelanden som anger att de har ändrats. En omkodad viktfil är en ändrad fil.

• Du måste återge attributionsmeddelandet ordagrant. Avsnitt 3(c) kräver att meddelandetexten – "Qwen is licensed under the Qwen RESEARCH LICENSE AGREEMENT, Copyright (c) 2026 Hangzhou Tongyi Laboratory Technology Co., Ltd. All Rights Reserved." – bevaras i en "Notice"-textfil som distribueras tillsammans med kopiorna.

Ytterligare två regler är bindande för den som utför kvantiseringen och för alla som bygger vidare på resultatet. Om du tränar, finjusterar eller förbättrar en AI-modell med hjälp av materialen eller deras utdata och sedan distribuerar den, måste du på ett framträdande sätt visa "Built with Qwen" eller "Improved using Qwen" i produktdokumentationen. Och du får inte använda "Qwen" som primärt namn eller identifierare för ett derivatverk, även om beskrivande användning såsom "fine-tuned from Qwen Image" är tillåten. Tillämplig lag är kinesisk, med exklusiv jurisdiktion vid Folkdomstolarna i Hangzhou.

Den praktiska slutsatsen är en enda rad, och den är värd att säga rakt ut eftersom formatet döljer den: att kvantisera vikterna ändrar inte licensen. Varje arkiv som granskats för den här sidan har license_name: qwen-research och länkar tillbaka till leverantörens LICENSE-fil, och antalet nedladdningar av en GGUF-fil är inte ett beviljande av kommersiella rättigheter. Som kontrast var den tidigare Qwen-bildserien tillåtande — modellkorten för Qwen-Image, Qwen-Image-Edit, Qwen-Image-Edit-2511 och Qwen-Image-2512 angav alla apache-2.0 den 13 oktober 2026 — och Qwen-Image-2.1 är avbrottet i det mönstret. Om en kommersiell pipeline är målet är licensen det första man bör läsa, inte det sista.

Var detta lämnar dig

Uttalat som ett beslut snarare än en sammanfattning: om ditt kort inte kan rymma 14,23 GB-transformatorn plus en 17,53 GB-encoder plus VAE:n, är ett GGUF-bygge det enda sättet du överhuvudtaget kan köra Qwen-Image-2.1 på, och den ärliga förväntan är att en medelhög kvantisering ger dig körningen och kostar dig något när det gäller fina detaljer, händer, små textpartier och instruktionsefterlevnad — utan någon publicerad mätning som säger hur mycket. Om ditt kort kan rymma det är safetensors-vägen den som leverantören dokumenterar och den med en definierad referens.

Två läsare behöver var sin mening någon annanstans på den här webbplatsen. Om det du faktiskt vill ha är ett community-bygge med säkerhetsfiltreringen borttagen i stället för en diskussion om formatet, är det en annan sida, och de ocensurerade byggena behandlas där. Och om din egentliga destination är en fungerande nodgraf i stället för en fil som du måste sätta ihop för hand, går ComfyUI-sidan igenom hela pipelinen, loader för loader.

Det som fortfarande står öppet är det som ekosystemet inte har publicerat: en kontrollerad jämförelse av dessa nivåer på ett fast seed, med samma prompt och samma sampler, på hårdvara som någon namnger. RealRebelAI:s notering att en generisk Q4_K_M synbart försämrades mot en INT8-referens medan en build med blandad precision vid samma etikett inte gjorde det är det närmaste svaret som finns offentligt, och det är en utgivares eget A/B-test. Tills någon publicerar jämförelsen är nivån du bör välja den högsta som ditt minne tillåter, och etiketten på filnamnet är en svagare garanti än tensorpolicyn bakom den.