Qwen-Image-2.1 GGUF: O que uma build quantizada realmente custa a você

Não existe um GGUF oficial de Qwen-Image-2.1. Todo arquivo .gguf com esse nome foi produzido por outra pessoa, a posteriori, pegando o transformer de difusão de 7B do fornecedor e recodificando seus pesos em precisão menor — sendo o GGUF o formato de checkpoint quantizado em arquivo único que as pilhas de inferência local leem. Essa única frase responde à primeira pergunta que um leitor tem e levanta as mais difíceis que esta página resolve: o que uma quantização de um modelo de imagem realmente comprime, o que o arquivo deixa de fora por padrão, quanto os níveis custam a você na imagem em vez de apenas no relógio, e o que a redistribuição de um exige sob a licença com que os pesos vieram.

O próprio modelo é o fato que data esta página, e não a notícia que ela veicula. O Qwen-Image-2.1 foi publicado no Hugging Face e no ModelScope em 20 de setembro de 2026, e as quantizações comunitárias dele surgiram no mesmo dia — os repositórios leejet, Abiray e RealRebelAI foram todos criados em 20 de setembro, e o da unsloth em 21 de setembro, 23 dias antes de esta página ser escrita. Nada sobre essa cronologia precisa ser repetido aqui; o que um leitor que digita "qwen image 2.1 gguf" quer é o manual de operação, e é isso que ele encontra aqui.

O que é um GGUF deste modelo, e o que ele não é

A primeira coisa a internalizar é que o arquivo é um fragmento. O Qwen-Image-2.1 não é uma única rede; é um transformador de difusão, mais um codificador de texto de visão e linguagem e um autoencoder. As quantizações que circulam sob seu nome contêm o primeiro deles e nada mais, e os próprios repositórios dizem isso. O cartão do Unsloth para seu Qwen-Image-2.1 GGUF resume tudo em uma linha: "Um GGUF é apenas o denoiser, então precisa do VAE e do codificador de texto Qwen3-VL junto a ele."

Então, um download GGUF é o transformer — 32 camadas DiT de fluxo único, 7 bilhões de parâmetros no componente de geração visual — reexpresso em precisão numérica reduzida. O codificador de texto e o VAE permanecem em seus formatos originais ou são quantizados separadamente, por pessoas diferentes, em repositórios diferentes. Essa é a diferença estrutural em relação à situação dos modelos de texto que a maioria dos leitores tem em mente: quando você baixa um GGUF de um modelo de chat, você baixou o modelo. Aqui, você baixou um terço de um pipeline.

Nada disto é o empacotamento do fornecedor. O repositório do fornecedor Qwen/Qwen-Image-2.1 é uma versão com o formato do Diffusers — model_index.json, transformer/, text_encoder/, vae/, scheduler/, processor/ — e a sua listagem de ficheiros, consultada a 13 de outubro de 2026, não contém nenhum ficheiro .gguf de qualquer tipo. As quantizações são artefactos da comunidade, publicados sob os nomes dos seus autores, e herdam a licença do fornecedor, não o seu endosso.

Por que a sabedoria da quantização de modelos de texto não se transfere

A sabedoria convencional sobre GGUF vem dos modelos de linguagem, onde é mais ou menos assim: Q8_0 é efetivamente sem perdas, Q4_K_M é o ponto ideal, qualquer coisa abaixo de Q3 é um compromisso, e a qualidade é medida como perplexidade ou divergência KL em relação a uma referência de precisão total. Quase nada disso se aplica a um modelo de imagem, e as razões merecem precisão.

Não há perplexidade para um transformer de difusão. O modelo não emite uma distribuição de tokens que você possa pontuar; ele emite um latente que um VAE decodifica em pixels. As métricas que existem deste lado da cerca — LPIPS, SSIM em relação a uma renderização de referência — exigem a mesma seed, o mesmo prompt e as mesmas configurações de amostrador em ambos os lados da comparação, e ainda medem distância perceptual em vez de correção. Então a pergunta "quanto me custa o Q4_K_M?" não tem um único número publicado como acontece com um modelo de texto, e qualquer pessoa que cite um está citando uma medição em uma seed.

Em segundo lugar, e de forma mais consequente: num modelo de imagem, a média de largura de bits importa menos do que quais tensores perderam seus bits. As projeções de atenção e os caminhos MLP que carregam a estrutura da imagem se degradam visivelmente quando arredondados, enquanto pequenos tensores de normalização e modulação toleram quase tudo. Uma conversão que atinge um alvo uniforme em todos os tensores pode, portanto, parecer pior do que uma conversão com o mesmo rótulo nominal que protege as camadas sensíveis — que é exatamente o que as pessoas que fazem esse trabalho descobriram. A RealRebelAI, publicando as notas de quantização mais explícitas que conseguimos encontrar, afirma que "uma conversão genérica padrão Q4_K_M apresentou perda visível de qualidade em estrutura fina e anatomia em comparação com o modelo INT8 de referência", e que suas próprias builds mantêm a atenção Q/K/V/Out em Q8_0 dentro de um arquivo Q4_K_M para recuperá-la. O rótulo no nome do arquivo é a quantização base, não a política.

Terceiro, o modo de falha é de natureza diferente. A quantização de texto degrada-se sobretudo na fluência e degrada-se graciosamente — uma frase ligeiramente pior ainda é uma frase. A quantização de imagens nos patamares mais baixos falha de maneiras óbvias e, por vezes, inutilizáveis: mãos e anatomia, textura fina, tipografia pequena e — a que é fácil de passar despercebida porque não é de todo um artefato de pixel — a aderência ao prompt. Se uma build deixa de obedecer a metade de uma instrução longa, isso é um custo de quantização, e não aparecerá numa comparação lado a lado de duas boas renderizações.

A escada, em ficheiros em vez de adjetivos

Tamanhos de arquivo são a única parte disto que é fato concreto, e não julgamento, porque cada repositório publica sua própria listagem. Consultados em 13 de outubro de 2026, os dois quantizações da comunidade mais baixadas divergem ligeiramente entre si, o que é, por si só, informativo.

• Unsloth Dynamic 2.0 (12 arquivos): 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 arquivos): 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 arquivos): 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 publica uma escada de precisão mista com um sufixo -HQv3 em vez de níveis simples, e documenta a precisão por módulo numa tabela; as quantizações base vão de Q2_K a Q8_0.

A variação é real. Q8_0 varia de 7,59 a 7,69 GB entre três publicadores, e Q6_K varia de 5,88 a 6,27 GB — uma diferença de 0,4 GB para o mesmo nível nominal, o que é a política de precisão mista se manifestando em bytes. Quem compara duas builds apenas pelo nome do arquivo está comparando rótulos, não artefatos.

Para dar uma noção de escala do outro lado: o transformer F16 de referência tem 14,23 GB, e o próprio componente de difusão bfloat16 do fornecedor no repack da Comfy-Org tem 14,23 GB. Portanto, um GGUF da classe Q4 representa uma redução de cerca de 3,4× no transformer, e nenhuma redução no codificador de texto, a menos que você o quantize separadamente.

Quanto custa cada degrau, onde uma fonte o afirma

Quase ninguém publica um custo de qualidade mensurado por nível para este modelo, e o mais honesto a fazer é separar os três tipos de afirmação em circulação.

• Orientação sobre memória, relatada pela comunidade. O repositório do Abiray associa cada arquivo a um perfil de VRAM recomendado: Q8_0 7,59 GB em "12 GB+ (fidelidade quase sem perdas)", Q6_K 5,88 GB em 10–12 GB, Q5_K_M 5,01 GB em 8–10 GB, Q4_K_M 4,19 GB e Q4_K_S 4,06 GB em 6–8 GB, e Q3_K_M 3,19 GB em 4–6 GB para "orçamento extremo / VRAM mínima". Estas são a regra geral do próprio publicador, não uma especificação de fornecedor nem um benchmark que pudéssemos reproduzir; elas também descrevem apenas o arquivo do transformer, então a folga necessária para o codificador de texto fica por cima.

• Uma comparação medida, relatada pelo quantizador e com uma única seed. A Unsloth publica um par de números para o lado do codificador do pipeline: o seu codificador de texto Dynamic 2.0 de 4 bits contra um codificador uniforme Q4_K_M, ambos numa seed partilhada com o denoiser e o VAE mantidos fixos, com LPIPS 0,029 e SSIM 0,959, em 5,15 GB versus 5,03 GB e 36,5 s versus 39,0 s. É uma única medição feita pela parte que vende o ficheiro, numa única seed, e é a única comparação quantitativa publicada de duas políticas de quantização para este modelo que conseguimos localizar.

• Listas de falhas qualitativas, relatadas pela comunidade. O RealRebelAI nomeia o que a quantização de bits mais baixos ainda pode afetar — "detalhes finos, mãos e anatomia, tipografia, adesão ao prompt, fidelidade de edição, consistência de textura" — e aconselha subir um degrau quando a degradação é visível. Afirma claramente que Q3_K_M e Q2_K são para sistemas com memória limitada e "ainda podem apresentar perda de qualidade crescente, apesar das camadas de alta precisão protegidas".

O que não é publicado é tão importante quanto o que é. Não há absolutamente nenhuma declaração do fornecedor sobre a qualidade de quantização para o Qwen-Image-2.1, nenhum benchmark independente de qualquer build GGUF, e nenhuma tabela de throughput em hardware de consumo nomeado de ninguém que conseguíssemos encontrar. A direção do trade-off de memória é certa e a direção do trade-off de velocidade é amplamente certa; o tamanho do custo de fidelidade não está estabelecido publicamente, e esta página não o estimará para você.

O que na verdade o executa

O cenário de runtime é incomumente estável para um formato tão recente, o que representa uma vantagem real em relação à situação habitual do GGUF.

• stable-diffusion.cpp — a implementação de referência para GGUF de modelos de imagem. A lista de notícias do projeto registra suporte Day-0 para Qwen-Image-2.1 em 20 de setembro de 2026, e documenta uma página dedicada ao modelo. A linha de comando recebe diretamente o modelo de difusão quantizado: --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, com --steps 20 --cfg-scale 6.0 --sampling-method euler no próprio exemplo do publicador.

• ComfyUI, através de um nó personalizado. Esta é a via que a maioria dos leitores seguirá, e tem uma particularidade que vale a pena conhecer antes de instalar seja o que for. O repositório que a maioria dos quantizadores indica é city96/ComfyUI-GGUF; o autor do stable-diffusion.cpp publica o seu próprio fork, leejet/ComfyUI-GGUF, e o seu README contém uma instrução explícita para o preferir, com o fundamento declarado de que "o repositório city96 parece já não ser mantido ativamente". Trata-se de uma afirmação de uma parte sobre outra e está datada; o histórico de commits em city96/ComfyUI-GGUF mostra, de facto, a sua atividade mais recente em janeiro de 2026. A página de documentação oficial do próprio ComfyUI para o Qwen-Image-2.1 lista apenas pesos .safetensors e não menciona GGUF de todo, pelo que o nó personalizado não é opcional e não tem o aval do fornecedor. Ambos os loaders colocam o ficheiro em ComfyUI/models/diffusion_models/ e expõem-no através de um loader de modelos de difusão GGUF.

• llama.cpp / ggml — não é um amostrador para este modelo, mas sim a origem do formato e da cadeia de ferramentas que produz esses arquivos. Tanto os repositórios do leejet quanto o do Abiray o creditam explicitamente. Se você quer um nível que ninguém publicou, é com isso que você converte.

• Unsloth Desktop — nomeado pelo repositório unsloth como um front-end suportado ao lado de stable-diffusion.cpp.

Um runtime conspicuosamente não o carrega: Diffusers. O início rápido do próprio fornecedor é um QwenImage21Pipeline sobre o repositório de safetensors em bfloat16, e não há caminho GGUF nesse pipeline. Se você quer Diffusers, você não é o público para um arquivo quantizado; se você quer um arquivo quantizado, stable-diffusion.cpp ou um grafo do ComfyUI é onde você vai parar.

A parte que realmente bloqueia as pessoas

Todo relatório de falha em torno deste formato remonta à mesma coisa: o GGUF é o transformer, então o restante do pipeline precisa ser montado manualmente, nos formatos corretos, a partir dos repositórios corretos. Três componentes estão no escopo e um deles tem uma armadilha.

• O codificador de texto. O Qwen-Image-2.1 é condicionado pelo Qwen3-VL 8B, e esse codificador é maior que o transformer em precisão total — 17,53 GB em bfloat16 no repack da Comfy-Org, contra 14,23 GB do modelo de difusão. Existem alternativas quantizadas em 9,35 GB (int8) e 6,31 GB (w4a8) no mesmo repack e, de forma independente, como GGUF: o fornecedor publica um artefato próprio Qwen/Qwen3-VL-8B-Instruct-GGUF com F16 em 16,39 GB, Q8_0 em 8,71 GB e Q4_K_M em 5,03 GB. Observe que esse GGUF do codificador é um artefato do fornecedor, ao contrário do GGUF do transformer ao lado dele — as duas metades do seu pipeline vêm de publicadores diferentes, com proveniência diferente.

• O VAE. Um único arquivo, qwen_image_2.1_vae_bf16.safetensors, 0,68 GB no repack da Comfy-Org. Ele é pequeno e é o componente que as pessoas mais frequentemente presumem ser intercambiável, e não é: a documentação do stable-diffusion.cpp afirma que os pesos anteriores do VAE do Qwen Image e do Wan 2.2 não são intercambiáveis com os pesos do VAE do Qwen Image 2.1. Pareie com o errado e o grafo carrega e produz a imagem errada.

• O projetor de visão, se você quiser editar. Texto para imagem é a metade fácil. Para edição de imagem, o codificador precisa de um projetor multimodal separado: a documentação do stable-diffusion.cpp orienta os leitores a também baixar mmproj-Qwen3VL-8B-Instruct-F16.gguf (1,16 GB) do repositório do codificador e passá-lo com --llm_vision, e repetir -r uma vez por imagem de referência. Um GGUF apenas de transformer mais um codificador de texto é um pipeline de texto para imagem e nada mais.

Vale a pena conhecer mais dois uploads. O lançamento também traz dois codificadores de reescrita de prompt — Qwen-Image-2.1-PE-T2I e Qwen-Image-2.1-PE-I2I, ambos modelos 9B afinados — que o fornecedor recomenda executar antes do modelo de imagem, e esses também estão sendo quantizados: uma build GGUF do reescritor T2I do projeto LightX2V apareceu no Hugging Face em 12 de outubro de 2026, juntamente com várias builds da comunidade. E o canal alfa, que é uma das características mais distintivas deste modelo, sobrevive à quantização, mas não a todos os contêineres: o modelo de difusão decide a transparência a partir do prompt, e não de um interruptor, e o alfa é mantido apenas em .png e .webp de saída.

O planejamento de memória em torno do próprio GGUF é um ponto em que a documentação do runtime é genuinamente específica, o que é raro. O stable-diffusion.cpp reutiliza as chaves e os valores de texto e de imagem de referência, independentes do passo, como cache de prefixo, e publica quanto isso custa por condição para o modelo de 32 camadas com um prefixo de 4096 tokens: 4 GiB em FP32, 2 GiB em FP16, 1,0625 GiB em q8_0, 0,5625 GiB em q4_0. A quantização do cache é um segundo trade-off, separado da quantização dos pesos, vem desativada por padrão, e o armazenamento de cache quantizado introduz erro de arredondamento adicional que a documentação sinaliza em vez de ocultar.

A licença que a quantização herda

Esta é a secção que a maioria das páginas GGUF ignora e, para este modelo, é aquela que muda o que pode fazer.

Os pesos base não são distribuídos sob uma licença permissiva. Qwen/Qwen-Image-2.1O repositório traz license: other com license_name: qwen-research, e o arquivo LICENSE é o Qwen Research License Agreement, com data de lançamento em 20 de setembro de 2026. Lido na íntegra em 13 de outubro de 2026, sua concessão operativa é uma licença não exclusiva, mundial, não transferível e livre de royalties para "usar, reproduzir, distribuir, copiar, criar obras derivadas e fazer modificações dos Materiais SOMENTE PARA FINS NÃO COMERCIAIS", com "Não Comercial" definido dentro do acordo como "apenas para fins de pesquisa ou avaliação", e o uso comercial encaminhado para uma licença separada, solicitada por e-mail no endereço indicado no acordo.

Um checkpoint quantizado é uma obra derivada daqueles Materiais, o que significa que a redistribuição de um GGUF é uma redistribuição sob esse acordo e assume todas as condições a ele vinculadas. Três delas são concretas:

• Você deve repassar o acordo. A Seção 3(a) exige que você forneça uma cópia da licença a qualquer pessoa que receba os materiais ou uma obra derivada. Um repositório GGUF com uma etiqueta de licença e nenhum texto de acordo não está em conformidade, independentemente do seu número de downloads.

• Você deve marcar o que alterou. A Seção 3(b) exige que arquivos modificados contenham avisos em destaque declarando que foram alterados. Um arquivo de pesos recodificado é um arquivo modificado.

• É necessário incluir o aviso de atribuição exatamente como está. A Seção 3(c) exige que o texto do aviso — "Qwen is licensed under the Qwen RESEARCH LICENSE AGREEMENT, Copyright (c) 2026 Hangzhou Tongyi Laboratory Technology Co., Ltd. All Rights Reserved." — seja mantido em um arquivo de texto "Notice" distribuído junto com as cópias.

Duas regras adicionais vinculam a pessoa que realiza a quantização e qualquer pessoa que construa sobre o resultado. Se você treinar, fizer ajuste fino ou melhorar um modelo de IA usando os materiais ou seus resultados e depois distribuí-lo, deverá exibir com destaque "Built with Qwen" ou "Improved using Qwen" na documentação do produto. E você não pode usar "Qwen" como o nome principal ou identificador de uma obra derivada, embora o uso descritivo, como "fine-tuned from Qwen Image", seja permitido. A lei aplicável é a chinesa, com jurisdição exclusiva nos Tribunais Populares de Hangzhou.

O resultado prático é uma frase, e vale a pena declará-la claramente, porque o formato a esconde: quantizar os pesos não altera a licença. Todos os repositórios inspecionados para esta página contêm license_name: qwen-research e remetem para o ficheiro LICENSE do fornecedor, e a contagem de downloads de um ficheiro GGUF não constitui uma concessão de direitos comerciais. Em contrapartida, a linha anterior de imagens Qwen era permissiva — os cartões de modelo de Qwen-Image, Qwen-Image-Edit, Qwen-Image-Edit-2511 e Qwen-Image-2512 todos indicavam apache-2.0 em 13 de outubro de 2026 — e o Qwen-Image-2.1 é a quebra nesse padrão. Se o objetivo é um pipeline comercial, a licença é a primeira coisa a ler e não a última.

Onde isso te deixa

Afirmado como uma decisão e não como um resumo: se a sua placa gráfica não conseguir comportar o transformer de 14,23 GB mais o encoder de 17,53 GB mais o VAE, uma build GGUF é a única forma de sequer conseguir executar o Qwen-Image-2.1, e a expectativa honesta é que uma quantização de nível intermédio lhe garanta a execução e lhe custe algo em detalhe fino, mãos, texto pequeno e capacidade de seguir instruções — sem qualquer medição publicada que lhe diga quanto. Se a sua placa gráfica conseguir comportá-lo, o caminho dos safetensors é o que o fornecedor documenta e aquele que tem uma referência definida.

Dois leitores precisam de uma frase cada em outro lugar neste site. Se o que você realmente quer é uma build da comunidade com a filtragem de segurança removida, em vez de uma discussão sobre o formato, essa é outra página, e as builds sem censura são abordadas lá. E se o seu destino real é um grafo de nós funcional, em vez de um arquivo que você tem de montar à mão, a página do ComfyUI percorre todo o pipeline, carregador por carregador.

O que fica em aberto é aquilo que o ecossistema não publicou: uma comparação controlada desses níveis com uma seed fixa, com o mesmo prompt e o mesmo sampler, em hardware que alguém nomeie. A observação da RealRebelAI de que um Q4_K_M genérico se degradou visivelmente em relação a uma referência INT8, enquanto uma build de precisão mista com o mesmo rótulo não o fez, é o que mais se aproxima dessa resposta em domínio público, e trata-se do próprio teste A/B de um único publicador. Até que alguém publique a comparação, o nível que você deve escolher é o mais alto que sua memória permitir, e o rótulo no nome do arquivo é uma garantia mais fraca do que a política de tensores por trás dele.