Qwen-Image-2.1 GGUF: Wat een gekwantiseerde build je werkelijk kost

Er is geen officiële GGUF van Qwen-Image-2.1. Elk .gguf bestand dat die naam draagt, is achteraf door iemand anders gemaakt, door de 7B-diffusietransformer van de leverancier te nemen en de gewichten ervan met lagere precisie opnieuw te coderen — GGUF is het gekwantiseerde checkpointformaat in één bestand dat de lokale inferentiestacks lezen. Die ene zin beantwoordt de eerste vraag die een lezer heeft en werpt de moeilijkere vragen op die deze pagina oplost: wat een kwantisatie van een beeldmodel eigenlijk comprimeert, wat het bestand standaard weglaat, wat de niveaus je in het beeld kosten in plaats van alleen in de tijd, en wat het herverdelen van een exemplaar vereist onder de licentie die bij de gewichten hoort.

Het model zelf is het feit dat deze pagina dateert, niet het nieuws dat erin wordt gerapporteerd. Qwen-Image-2.1 verscheen op 20 september 2026 op Hugging Face en ModelScope, en kwantisaties door de community ervan volgden dezelfde dag — de repositories van leejet, Abiray en RealRebelAI werden allemaal op 20 september aangemaakt en die van unsloth op 21 september, wat 23 dagen vóór het schrijven van deze pagina is. Niets aan die tijdlijn hoeft hier opnieuw te worden vermeld; wat een lezer die "qwen image 2.1 gguf" typt wil, is de handleiding, en dit is hem.

Wat een GGUF van dit model is, en wat het niet is

Het eerste dat je moet internaliseren, is dat het bestand een fragment is. Qwen-Image-2.1 is geen enkel netwerk; het is een diffusietransformer plus een visie-taal-tekstencoder plus een autoencoder. De kwantisaties die onder zijn naam circuleren, bevatten de eerste daarvan en niets anders, en de repositories zeggen dat zelf. De kaart van Unsloth voor zijn Qwen-Image-2.1 GGUF vat het in één regel samen: "Een GGUF is alleen de denoiser, dus het heeft de VAE en de Qwen3-VL-tekstencoder ernaast nodig."

Een GGUF-download is dus de transformer — 32 single-stream DiT-lagen, 7B parameters in de visuele generatiecomponent — herschreven met verminderde numerieke precisie. De tekstencoder en de VAE blijven in hun oorspronkelijke formaten of worden afzonderlijk gekwantiseerd, door verschillende mensen, in verschillende repositories. Dit is het structurele verschil met de tekstmodel-situatie die de meeste lezers in hun hoofd hebben: wanneer je een GGUF van een chatmodel downloadt, heb je het model gedownload. Hier heb je een derde van een pipeline gedownload.

Niets hiervan is de verpakking van de leverancier. De leveranciersrepository Qwen/Qwen-Image-2.1 is een release in Diffusers-indeling — model_index.json, transformer/, text_encoder/, vae/, scheduler/, processor/ — en de bestandslijst ervan, gelezen op 13 oktober 2026, bevat geen .gguf-bestand van welke aard dan ook. De quantisaties zijn community-artefacten, gepubliceerd onder de namen van hun auteurs, en ze erven de licentie van de leverancier in plaats van de goedkeuring van de leverancier.

Waarom de wijsheid over kwantisatie van tekstmodellen niet overdraagbaar is

De gangbare wijsheid over GGUF komt uit taalmodellen, waar die ongeveer luidt: Q8_0 is vrijwel verliesloos, Q4_K_M is het optimum, alles onder Q3 is een compromis, en kwaliteit wordt gemeten als perplexiteit of KL-divergentie ten opzichte van een referentie met volledige precisie. Bijna niets daarvan gaat op voor een beeldmodel, en het loont de moeite om precies te zijn over de redenen daarvoor.

Er bestaat geen perplexiteit voor een diffusion transformer. Het model produceert geen tokenverdeling die je kunt scoren; het produceert een latente die een VAE naar pixels decodeert. De metrieken die aan deze kant van het hek bestaan — LPIPS, SSIM tegen een referentierender — vereisen dezelfde seed, dezelfde prompt en dezelfde samplerinstellingen aan beide kanten van de vergelijking, en ze meten nog steeds perceptuele afstand in plaats van correctheid. Dus de vraag "hoeveel kost Q4_K_M mij?" heeft geen enkel gepubliceerd getal zoals bij een tekstmodel, en wie er een citeert, citeert één meting op één seed.

Ten tweede, en nog belangrijker: bij een beeldmodel is de gemiddelde bitbreedte minder belangrijk dan welke tensoren hun bits hebben verloren. De attention-projecties en de MLP-paden die beeldstructuur dragen, degraderen zichtbaar bij afronding, terwijl kleine normalisatie- en modulatietensoren bijna alles tolereren. Een conversie die voor elke tensor een uniform doel aanhoudt, kan er dus slechter uitzien dan een conversie met hetzelfde nominale label die de gevoelige lagen beschermt — wat precies is wat de mensen die dit werk doen hebben gevonden. RealRebelAI, dat de meest expliciete kwantisatienotities publiceert die we konden vinden, stelt dat "een standaard generieke Q4_K_M-conversie zichtbaar kwaliteitsverlies vertoonde in fijne structuur en anatomie vergeleken met het referentie-INT8-model", en dat zijn eigen builds attention Q/K/V/Out op Q8_0 houden binnen een Q4_K_M-bestand om dat te herstellen. Het label op de bestandsnaam is de basiskwantisatie, niet het beleid.

Ten derde: de faalmodus is van een andere aard. Tekstkwantisatie verslechtert vooral qua vloeiendheid, en dat gaat geleidelijk — een iets slechtere zin is nog steeds een zin. Beeldkwantisatie op de lage niveaus faalt op manieren die overduidelijk en soms onbruikbaar zijn: handen en anatomie, fijne textuur, kleine typografie, en — de faalwijze die gemakkelijk over het hoofd te zien is omdat het helemaal geen pixelartefact is — naleving van de prompt. Als een build de helft van een lange instructie niet meer opvolgt, is dat een kwantisatiekost, en dat zal niet opvallen in een zij-aan-zijvergelijking van twee goede renders.

De ladder, in bestanden in plaats van bijvoeglijke naamwoorden.

Bestandsgroottes zijn het enige deel hiervan dat harde feiten zijn in plaats van een beoordeling, omdat elke repository zijn eigen lijst publiceert. Gelezen op 13 oktober 2026: de twee meest gedownloade community-quantisaties wijken licht van elkaar af, wat op zichzelf informatief is.

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

• RealRebelAIpubliceert een gemengde-precisieladder met een -HQv3-achtervoegsel in plaats van gewone niveaus, en documenteert de precisie per module in een tabel; de basiskwantisaties lopen van Q2_K tot Q8_0.

De spreiding is reëel. Q8_0 beslaat 7,59 tot 7,69 GB bij drie uitgevers, en Q6_K beslaat 5,88 tot 6,27 GB — een gat van 0,4 GB voor hetzelfde nominale niveau, wat het gemengd-precisiebeleid is dat zich in bytes manifesteert. Wie twee builds alleen op bestandsnaam vergelijkt, vergelijkt labels, niet artefacten.

Voor de schaal aan de andere kant: de referentie-F16-transformer is 14,23 GB, en de eigen bfloat16-diffusiecomponent van de leverancier in de Comfy-Org-repack is 14,23 GB. Dus een GGUF van Q4-klasse is ongeveer een 3,4×-reductie op de transformer, en helemaal geen reductie op de tekstencoder, tenzij je die apart quantiseert.

Wat elke trede kost, waar een bron dat aangeeft

Bijna niemand publiceert voor dit model een gemeten kwaliteitskost per niveau, en het eerlijke om te doen is de drie soorten claims die in omloop zijn van elkaar te scheiden.

• Geheugenrichtlijn, door de community gerapporteerd. De repository van Abiray koppelt elk bestand aan een aanbevolen VRAM-profiel: Q8_0 7,59 GB bij "12 GB+ (bijna verliesvrije getrouwheid)", Q6_K 5,88 GB bij 10–12 GB, Q5_K_M 5,01 GB bij 8–10 GB, Q4_K_M 4,19 GB en Q4_K_S 4,06 GB bij 6–8 GB, en Q3_K_M 3,19 GB bij 4–6 GB voor "extreem budget / minimale VRAM". Dit zijn de eigen vuistregels van de uitgever, geen leveranciersspecificatie en geen benchmark die wij konden reproduceren; ze beschrijven ook alleen het transformerbestand, dus de extra ruimte die je nodig hebt voor de tekstencoder komt daar bovenop.

• Een gemeten vergelijking, gerapporteerd door de kwantisator en met één seed. Unsloth publiceert één getallenpaar voor de encoderzijde van de pipeline: zijn Dynamic 2.0 4-bit tekstencoder tegenover een uniforme Q4_K_M-encoder, beide bij een gedeelde seed waarbij de denoiser en VAE vastgehouden worden, bij LPIPS 0,029 en SSIM 0,959, in 5,15 GB versus 5,03 GB en 36,5 s versus 39,0 s. Het is één meting door de partij die het bestand verkoopt, op één seed, en het is de enige gepubliceerde kwantitatieve vergelijking van twee kwantisatiestrategieën voor dit model die wij konden vinden.

• Kwalitatieve lijsten van tekortkomingen, door de community gemeld. RealRebelAI benoemt wat kwantisatie met minder bits nog kan beïnvloeden — "fijne details, handen en anatomie, typografie, promptnaleving, bewerkingsgetrouwheid, textuurconsistentie" — en adviseert een trede hoger te gaan wanneer verslechtering zichtbaar is. Het stelt ronduit dat Q3_K_M en Q2_K bedoeld zijn voor systemen met beperkt geheugen en "nog steeds toenemend kwaliteitsverlies kunnen vertonen ondanks de beschermde hoge-precisielagen."

Wat niet gepubliceerd is, is even belangrijk als wat wel is. Er is helemaal geen leveranciersverklaring over kwantisatiekwaliteit voor Qwen-Image-2.1, geen enkele onafhankelijke benchmark van welke GGUF-build dan ook, en geen doorvoertabel voor genoemde consumentenhardware van wie dan ook die wij konden vinden. De richting van de geheugenafweging is zeker en de richting van de snelheidsafweging is in grote lijnen zeker; de omvang van het kwaliteitsverlies is niet publiekelijk vastgesteld, en deze pagina zal die niet voor u schatten.

Wat voert het eigenlijk uit?

Het runtimeverhaal is ongewoon uitgekristalliseerd voor een formaat dat zo recent is, wat een echt voordeel is ten opzichte van de gebruikelijke GGUF-situatie.

• stable-diffusion.cpp — de referentie-implementatie voor GGUF van beeldmodellen. De nieuwslijst van het project vermeldt Day-0-ondersteuning voor Qwen-Image-2.1 op 20 september 2026, en er wordt een speciale pagina aan het model gewijd. De opdrachtregel neemt het gekwantiseerde diffusiemodel rechtstreeks: --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, met --steps 20 --cfg-scale 6.0 --sampling-method euler in het voorbeeld van de uitgever zelf.

• ComfyUI, via een aangepaste node. Dit is de route die de meeste lezers zullen volgen, en er zit een addertje onder het gras dat het weten waard is voordat je iets installeert. De repository waarnaar de meeste quantiseerders verwijzen is city96/ComfyUI-GGUF; de auteur van stable-diffusion.cpp publiceert zijn eigen fork, leejet/ComfyUI-GGUF, en zijn README bevat de expliciete instructie om die te verkiezen, op grond van de bewering dat "de city96-repository niet langer actief onderhouden lijkt te worden." Dat is een bewering van de ene partij over de andere, en ze is gedateerd; de commitgeschiedenis van city96/ComfyUI-GGUF laat wel degelijk zien dat de meest recente activiteit in januari 2026 was. ComfyUI's eigen officiële documentatiepagina voor Qwen-Image-2.1 vermeldt alleen .safetensors-gewichten en noemt GGUF helemaal niet, dus de aangepaste node is niet optioneel en is niet door de leverancier gezegend. Beide loaders plaatsen het bestand in ComfyUI/models/diffusion_models/ en stellen het beschikbaar via een GGUF-diffusiemodelloader.

• llama.cpp / ggml — geen sampler voor dit model, maar de oorsprong van het formaat en de toolchain die deze bestanden produceert. Zowel de leejet- als de Abiray-repositories erkennen dit expliciet. Als je een niveau wilt dat niemand heeft gepubliceerd, is dit waarmee je converteert.

• Unsloth Desktop — door de unsloth-repository genoemd als een ondersteunde front-end naast stable-diffusion.cpp.

Eén runtime laadt het opvallend genoeg niet: Diffusers. De eigen snelstart van de leverancier is een QwenImage21Pipeline op de bfloat16-safetensors-repository, en er is geen GGUF-pad in die pipeline. Als je Diffusers wilt, ben je niet de doelgroep voor een gekwantiseerd bestand; als je een gekwantiseerd bestand wilt, kom je terecht bij stable-diffusion.cpp of een ComfyUI-graaf.

Het deel dat mensen echt tegenhoudt

Elk foutrapport rond dit formaat komt op hetzelfde neer: de GGUF is de transformer, dus de rest van de pipeline moet handmatig worden samengesteld, in de juiste formaten, uit de juiste repositories. Drie componenten vallen binnen scope en een van hen bevat een valkuil.

• De tekstencoder.Qwen-Image-2.1 conditioneert op Qwen3-VL 8B, en die encoder is groter dan de transformer bij volledige precisie — 17,53 GB in bfloat16 in de Comfy-Org-repack, tegenover 14,23 GB voor het diffusiemodel. Er bestaan gekwantiseerde alternatieven van 9,35 GB (int8) en 6,31 GB (w4a8) in dezelfde repack, en onafhankelijk daarvan als GGUF: de leverancier publiceert een eigen Qwen/Qwen3-VL-8B-Instruct-GGUF met F16 op 16,39 GB, Q8_0 op 8,71 GB en Q4_K_M op 5,03 GB. Merk op dat deze encoder-GGUF een artefact van de leverancier is, anders dan de transformer-GGUF waar hij naast staat — de twee helften van je pipeline komen van verschillende uitgevers met een verschillende herkomst.

• De VAE. Eén bestand, qwen_image_2.1_vae_bf16.safetensors, 0,68 GB in de Comfy-Org-repack. Het is klein en het is het onderdeel waarvan mensen het vaakst aannemen dat het uitwisselbaar is, en dat is het niet: in de documentatie van stable-diffusion.cpp staat dat de eerdere VAE-gewichten van Qwen Image en Wan 2.2 niet uitwisselbaar zijn met de VAE-gewichten van Qwen Image 2.1. Koppel je de verkeerde, dan laadt de grafiek en produceert het verkeerde beeld.

• De vision-projector, als je wilt bewerken. Tekst-naar-afbeelding is het makkelijke deel. Voor het bewerken van afbeeldingen heeft de encoder een aparte multimodale projector nodig: de documentatie van stable-diffusion.cpp instrueert lezers om ook mmproj-Qwen3VL-8B-Instruct-F16.gguf (1,16 GB) uit de encoder-repository te downloaden en deze door te geven met --llm_vision, en herhaal -r eenmaal per referentieafbeelding. Een GGUF met alleen een transformer plus een tekstencoder is een tekst-naar-afbeelding-pijplijn en niets meer.

Er zijn nog twee uploads die het weten waard zijn. De release bevat ook twee encoders die prompts herschrijven — Qwen-Image-2.1-PE-T2I en Qwen-Image-2.1-PE-I2I, beide fine-tuned 9B-modellen — die de leverancier aanraadt vóór het beeldmodel te draaien, en die worden ook gekwantiseerd: een GGUF-build van de T2I-herschrijver uit het LightX2V-project verscheen op 12 oktober 2026 op Hugging Face, naast diverse builds uit de community. En het alfakanaal, een van de kenmerkendere eigenschappen van dit model, overleeft kwantisatie, maar niet elke container: het diffusiemodel bepaalt transparantie aan de hand van de prompt en niet via een schakelaar, en de alfa wordt alleen behouden in .png en .webp-uitvoer.

Geheugenplanning rond de GGUF zelf is een plek waar de runtime-documentatie echt specifiek is, wat zeldzaam is. stable-diffusion.cpp hergebruikt de stap-onafhankelijke tekst- en referentieafbeeldingssleutels en -waarden als een prefixcache, en publiceert wat dat per conditie kost voor het 32-laags model bij een prefix van 4096 tokens: 4 GiB bij FP32, 2 GiB bij FP16, 1,0625 GiB bij q8_0, 0,5625 GiB bij q4_0. Het kwantiseren van de cache is een tweede, aparte afweging naast het kwantiseren van de gewichten, staat standaard uit, en gekwantiseerde cacheopslag introduceert extra afrondingsfout die de documentatie benoemt in plaats van verbergt.

De licentie die de kwantisatie erft

Dit is het gedeelte dat de meeste GGUF-pagina's overslaan, en voor dit model is het juist dit gedeelte dat verandert wat je kunt doen.

De basisgewichten worden niet onder een permissieve licentie gedistribueerd. De Qwen/Qwen-Image-2.1-repository bevat license: other met license_name: qwen-research, en het LICENSE-bestand is de Qwen Research License Agreement, met releasedatum 20 september 2026. Bij volledige lezing op 13 oktober 2026 blijkt de eigenlijke verlening een niet-exclusieve, wereldwijde, niet-overdraagbare, royaltyvrije licentie te zijn om “de Materialen te gebruiken, te reproduceren, te distribueren, te kopiëren, er afgeleide werken van te maken en er wijzigingen in aan te brengen, ENKEL VOOR NIET-COMMERCIËLE DOELEINDEN”, waarbij “Niet-Commercieel” in de overeenkomst wordt gedefinieerd als “enkel voor onderzoeks- of evaluatiedoeleinden” en commercieel gebruik wordt doorverwezen naar een afzonderlijke licentie die per e-mail kan worden aangevraagd op het adres dat de overeenkomst vermeldt.

Een gekwantiseerd checkpoint is een afgeleid werk van die Materialen, wat betekent dat herdistributie van een GGUF herdistributie is onder die overeenkomst en alle voorwaarden die eraan verbonden zijn overneemt. Drie ervan zijn concreet:

• Je moet de overeenkomst doorgeven.Sectie 3(a) vereist dat je aan iedereen die de materialen of een afgeleide ontvangt een kopie van de licentie geeft. Een GGUF-repository met een licentietag en zonder overeenkomsttekst voldoet niet, ongeacht het aantal downloads.

• U moet aangeven wat u hebt gewijzigd. Sectie 3(b) vereist dat gewijzigde bestanden opvallende kennisgevingen bevatten waarin staat dat ze zijn gewijzigd. Een opnieuw gecodeerd gewichtsbestand is een gewijzigd bestand.

• U moet de attributiekennisgeving woordelijk overnemen. Sectie 3(c) vereist dat de kennisgevingstekst — "Qwen is licensed under the Qwen RESEARCH LICENSE AGREEMENT, Copyright (c) 2026 Hangzhou Tongyi Laboratory Technology Co., Ltd. All Rights Reserved." — wordt behouden in een tekstbestand "Notice" dat met de kopieën wordt meegeleverd.

Twee aanvullende regels binden degene die de kwantisering uitvoert en iedereen die op het resultaat voortbouwt. Als je een AI-model traint, fine-tunet of verbetert met behulp van de materialen of hun outputs en het vervolgens distribueert, moet je prominent "Built with Qwen" of "Improved using Qwen" in de productdocumentatie weergeven. En je mag "Qwen" niet gebruiken als de primaire naam of identificatie van een afgeleid werk, hoewel beschrijvend gebruik zoals "fine-tuned from Qwen Image" is toegestaan. Het toepasselijke recht is het Chinese recht, met exclusieve rechtsmacht bij de Volksrechtbanken van Hangzhou.

De praktische slotsom is één regel, en het is de moeite waard die ronduit te zeggen, want het formaat verbergt haar: het kwantiseren van de gewichten verandert niets aan de licentie. Elke repository die voor deze pagina is onderzocht, bevat license_name: qwen-research en verwijst terug naar het LICENSE-bestand van de leverancier, en het aantal downloads van een GGUF-bestand is geen toekenning van commerciële rechten. Ter contrast: de eerdere Qwen-afbeeldingslijn was permissief — de modelkaarten voor Qwen-Image, Qwen-Image-Edit, Qwen-Image-Edit-2511 en Qwen-Image-2512 vermeldden allemaal apache-2.0 op 13 oktober 2026 — en Qwen-Image-2.1 is de breuk in dat patroon. Als een commerciële pijplijn het doel is, is de licentie het eerste dat je moet lezen en niet het laatste.

Wat dit voor jou betekent

Als een beslissing geformuleerd, niet als een samenvatting: als je kaart de transformer van 14,23 GB plus een encoder van 17,53 GB plus de VAE niet kan bevatten, is een GGUF-build de enige manier waarop je Qwen-Image-2.1 überhaupt kunt draaien, en de eerlijke verwachting is dat een middelzware kwantisatie je de run oplevert en je iets kost op het gebied van fijne details, handen, kleine tekst en instructieopvolging — zonder gepubliceerde meting die je vertelt hoeveel. Als je kaart het wel kan bevatten, is het safetensors-pad het pad dat de leverancier documenteert en het pad met een gedefinieerde referentie.

Twee lezers hebben elders op deze site elk één zin nodig. Als wat je eigenlijk wilt een community-build is waarin het veiligheidsfilter is verwijderd, in plaats van een discussie over het formaat, dan is dat een andere pagina en daar worden de ongecensureerde builds behandeld. En als je echte bestemming een werkende nodegraaf is in plaats van een bestand dat je handmatig moet samenstellen, dan doorloopt de ComfyUI-pagina de hele pipeline, loader voor loader.

Wat open blijft, is datgene wat het ecosysteem niet heeft gepubliceerd: een gecontroleerde vergelijking van deze niveaus op een vaste seed, met dezelfde prompt en dezelfde sampler, op hardware die iemand bij naam noemt. De opmerking van RealRebelAI dat een generieke Q4_K_M zichtbaar degradeerde ten opzichte van een INT8-referentie, terwijl een mixed-precision-build met hetzelfde label dat niet deed, komt in het openbaar het dichtst bij dat antwoord, en het is de eigen A/B-test van één uitgever. Totdat iemand de vergelijking publiceert, is het niveau dat je moet kiezen het hoogste dat je geheugen toelaat, en het label op de bestandsnaam is een zwakkere garantie dan het tensorbeleid erachter.