Qwen-Image-2.1 GGUF：量化构建究竟让你付出什么代价

不存在官方的 GGUF Qwen-Image-2.1。每一个.gguf带有这个名称的文件，都是别人事后制作的：他们拿来厂商的 7B 扩散 Transformer，把其权重重新编码为更低精度——GGUF 正是本地推理栈读取的单文件量化检查点格式。这一句话回答了读者最先想到的问题，也引出了本页要解决的更难的问题：图像模型的量化究竟压缩了什么、文件开箱即用时遗漏了什么、这些级别让你在画面上而不只是在耗时上付出什么代价，以及重新分发其中一个文件在权重所附带的许可证下需要满足什么要求。

给这个页面标注日期的其实是模型本身，而不是它所报道的新闻。Qwen-Image-2.1 于 2026 年 9 月 20 日上线 Hugging Face 和 ModelScope，社区对它的量化版本也在同一天跟进——leejet、Abiray 和 RealRebelAI 的仓库均创建于 9 月 20 日，unsloth 的则在 9 月 21 日，也就是本页面撰写之前的 23 天。这条时间线无需在此赘述；输入 "qwen image 2.1 gguf" 的读者想要的是操作手册，而这就是。

这个模型的 GGUF 是什么，以及它不是什么

首先要明白的是，这个文件只是一个片段。Qwen-Image-2.1 并不是一个单一网络；它由一个扩散 Transformer、一个视觉-语言文本编码器和一个自编码器组成。以它的名义流传的量化版本只包含其中第一个，别的什么都没有，而且相关仓库自己也这么说。Unsloth 关于其 Qwen-Image-2.1 GGUF 的模型卡用一句话点明：“GGUF 只是去噪器，因此还需要搭配 VAE 和 Qwen3-VL 文本编码器。”

所以，一份 GGUF 下载就是那个 transformer——视觉生成组件中 32 个单流 DiT 层、70 亿参数——以降低的数值精度重新表述后的版本。文本编码器和 VAE 则保持其原始格式，或者由不同的人、在不同的代码仓库中另行量化。这就是它与大多数读者脑海中关于文本模型的情形之间的结构性差异：当你下载一个聊天模型的 GGUF 时，你就是下载了整个模型。而在这里，你只下载了一条流水线的三分之一。

这些都不是厂商的打包内容。厂商仓库 Qwen/Qwen-Image-2.1是一个 Diffusers 布局的发布版本 —— model_index.json、transformer/、text_encoder/、vae/、scheduler/、processor/—— 其文件列表于 2026 年 10 月 13 日读取时，不包含任何类型的 .gguf文件。这些量化版本是社区产物，以其作者的名义发布，它们继承的是厂商的许可证，而非厂商的认可。

为什么文本模型的量化经验无法迁移

关于 GGUF 的普遍认知源自语言模型，在那里大致是：Q8_0 实际上无损，Q4_K_M 是最佳平衡点，低于 Q3 的任何方案都是妥协，而质量则通过相对于全精度参考的困惑度或 KL 散度来衡量。这些几乎完全不适用于图像模型，而其中的原因值得仔细说清。

扩散 Transformer 没有困惑度这种指标。模型不会输出一个你可以打分的 token 分布；它输出的是一个潜变量，再由 VAE 解码成像素。在这一侧存在的指标——LPIPS、与参考渲染图对比的 SSIM——要求比较双方使用相同的种子、相同的提示词和相同的采样器设置，而且它们衡量的仍然是感知距离，而非正确性。所以，“Q4_K_M 让我付出多少代价？”这个问题并不像文本模型那样有一个现成的公开数字，任何引用某个数字的人，引用的都只是在某一个种子上的某一次测量。

其次，而且影响更大的是：在图像模型上，平均位宽的重要性不如哪些张量丢失了它们的比特位。注意力投影以及承载图像结构的 MLP 路径在被舍入时会明显劣化，而小的归一化和调制张量几乎能容忍任何处理。因此，对所有张量都采用统一目标的转换，看起来可能比标称标签相同但保护敏感层的转换更差——这正是从事这项工作的人所发现的。RealRebelAI 发布了我们能找到的最明确的量化说明，其中指出：“与参考 INT8 模型相比，标准的通用 Q4_K_M 转换在精细结构和解剖结构上表现出可见的质量损失”，并且其自己的构建在 Q4_K_M 文件中将注意力 Q/K/V/Out 保持为 Q8_0 以恢复质量。文件名上的标签是基础量化，而不是策略。

第三，这种失效模式在性质上有所不同。文本量化主要表现为流畅度下降，而且退化得很平缓——一个稍差的句子仍然是一个句子。图像量化在低档位下的失效方式则显而易见，有时甚至无法使用：手部和人体结构、精细纹理、小字号排版，以及——这一点很容易被忽略，因为它根本不是像素层面的伪影——提示词遵循度。如果某个构建版本不再遵循一长段指令的一半，那就是一种量化代价，而它不会在两张优秀渲染图的并排对比中显现出来。

这架阶梯，用文件而非形容词

文件大小是这件事中属于硬事实而非判断的那一部分，因为每个仓库都会发布自己的清单。于 2026 年 10 月 13 日读取时，下载量最高的两个社区量化版本彼此略有出入，这本身就很有信息量。

• Unsloth Dynamic 2.0（12 个文件）：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 个文件）：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 个文件）：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发布了一套带-HQv3后缀的混合精度阶梯，而非单纯的级别，并以表格形式记录了各模块的精度；基础量化覆盖 Q2_K 到 Q8_0。

这个差异是真实存在的。Q8_0 在三个发布者之间跨度为 7.59 至 7.69 GB，而 Q6_K 跨度为 5.88 至 6.27 GB——同一标称级别竟有 0.4 GB 的差距，这正是混合精度策略以字节形式显现出来的结果。仅凭文件名比较两个构建版本的人，比较的是标签，而不是产物。

作为另一边的规模参照：参考 F16 transformer 为 14.23 GB，而厂商自家的 bfloat16 扩散组件在 Comfy-Org 重新打包版中也是 14.23 GB。所以，Q4 级别的 GGUF 在 transformer 上大约缩减 3.4 倍，而在文本编码器上完全没有缩减，除非你单独对它进行量化。

每一级的成本是多少，在有来源说明的情况下

几乎没有人会公布这个模型经过测量的每级质量成本，而诚实的做法是区分当前流传的三种主张。

• 显存指南，来自社区报告。Abiray 的仓库为每个文件搭配了一个推荐的显存配置方案：Q8_0 7.59 GB 对应“12 GB+（近乎无损保真度）”，Q6_K 5.88 GB 对应 10–12 GB，Q5_K_M 5.01 GB 对应 8–10 GB，Q4_K_M 4.19 GB 和 Q4_K_S 4.06 GB 对应 6–8 GB，Q3_K_M 3.19 GB 对应 4–6 GB，适用于“极限预算／最低显存”。这些只是发布者自己的经验法则，既不是厂商规格，也不是我们能够复现的基准测试；而且它们描述的仅是 transformer 文件本身，因此你为文本编码器所需的额外余量还要在此之上另算。

• 一次审慎的对比，由量化方自行报告，且仅基于单一随机种子。Unsloth 为流水线的编码器一侧公布了一组数字对比：其 Dynamic 2.0 4 位文本编码器对比统一的 Q4_K_M 编码器，两者采用相同的随机种子，去噪器与 VAE 均保持不变，LPIPS 为 0.029、SSIM 为 0.959，占用 5.15 GB 对 5.03 GB，耗时 36.5 秒对 39.0 秒。这是由出售该文件的一方所做的一次测量，仅基于一个随机种子，而且它是我们所能找到的、针对该模型两种量化策略的唯一已公布的定量比较。

• 定性失败清单，来自社区反馈。RealRebelAI 指出了低位量化仍可能影响哪些方面——“细节、手部与解剖结构、排版、提示词遵循度、编辑保真度、纹理一致性”——并建议在劣化肉眼可见时向上提升一档。它明确表示，Q3_K_M 和 Q2_K 面向内存受限的系统，“尽管有受保护的高精度层，仍可能表现出日益严重的质量损失”。

哪些内容未被公布，与已公布的内容同等重要。关于 Qwen-Image-2.1 的量化质量，完全没有厂商的说明；没有任何针对任一 GGUF 构建的独立基准测试；也没有任何我们找得到的、在具名消费级硬件上的吞吐量表格。内存权衡的方向是确定的，速度权衡的方向也大体确定；保真度代价的规模在公开信息中尚无定论，本页不会替你作出估计。

到底是什么在运行它

对如此新的格式来说，其运行时情况异常稳定，相比通常的 GGUF 局面，这是一个真正的优势。

• stable-diffusion.cpp —— 图像模型 GGUF 的参考实现。其项目新闻列表记录了 2026 年 9 月 20 日对 Qwen-Image-2.1 的 Day-0 支持，并为该模型提供了专门的文档页面。命令行可直接接收量化后的扩散模型：--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，并配合 --steps 20 --cfg-scale 6.0 --sampling-method euler，如发布方自己的示例所示。

• ComfyUI，通过自定义节点。这是大多数读者会走的路线，而在安装任何东西之前，有一个值得了解的波折。大多数量化者指向的仓库是city96/ComfyUI-GGUF；stable-diffusion.cpp 的作者发布了他自己的分支，leejet/ComfyUI-GGUF，而他的 README 中明确指示应优先使用它，理由是"city96 仓库似乎已不再积极维护"。这是一方对另一方提出的说法，而且已经过时了；city96/ComfyUI-GGUF 的提交历史确实显示其最近的活跃是在 2026 年 1 月。ComfyUI 官方关于 Qwen-Image-2.1 的文档页面只列出了.safetensors权重，完全没有提到 GGUF，因此这个自定义节点并非可有可无，也未获官方认可。两种加载器都会把文件放入ComfyUI/models/diffusion_models/，并通过 GGUF 扩散模型加载器来加载它。

• llama.cpp / ggml——它不是这个模型的采样器，而是该格式的源头，以及生成这些文件的工具链。leejet 和 Abiray 两个仓库都明确提到了它。如果你想要一个没人发布过的 level，这就是你用来转换的工具。

• Unsloth Desktop——被 unsloth 仓库列为与 stable-diffusion.cpp 并列受支持的前端。

有一个运行时明显不加载它：Diffusers。厂商自己的快速入门是 QwenImage21Pipeline，基于 bfloat16 safetensors 仓库，而且该 pipeline 中没有 GGUF 路径。如果你想要 Diffusers，你就不是量化文件的目标受众；如果你想要量化文件，stable-diffusion.cpp 或 ComfyUI 图才是你的归宿。

真正阻碍人们的部分

围绕这种格式的每一份失败报告，最终都追溯到同一件事：GGUF 就是 Transformer，因此流水线的其余部分必须手工组装，采用正确的格式，并从正确的仓库获取。有三个组件在范围内，而其中一个里面有个陷阱。

• 文本编码器。 Qwen-Image-2.1 以 Qwen3-VL 8B 作为条件输入，而在全精度下，该编码器比 transformer 还要大——在 Comfy-Org 重新打包版中，bfloat16 下为 17.53 GB，而扩散模型为 14.23 GB。同一重新打包版中还提供了量化替代方案：9.35 GB（int8）和 6.31 GB（w4a8），并且还以 GGUF 形式独立提供：厂商发布了一个第一方的 Qwen/Qwen3-VL-8B-Instruct-GGUF，其中 F16 为 16.39 GB，Q8_0 为 8.71 GB，Q4_K_M 为 5.03 GB。请注意，这个编码器 GGUF 是厂商制品，与它旁边的 transformer GGUF 不同——你流水线的这两部分来自不同的发布者，具有不同的出处。

• VAE。单个文件，qwen_image_2.1_vae_bf16.safetensors，在 Comfy-Org 重新打包版中为 0.68 GB。它很小，而且它是人们最常以为可以互换的组件，但事实并非如此：stable-diffusion.cpp 的文档指出，早期的 Qwen Image 和 Wan 2.2 VAE 权重与 Qwen Image 2.1 VAE 权重不可互换。配错了，计算图会加载并生成错误的图片。

• 视觉投影器，如果你想进行编辑的话。 文生图只是简单的那一半。若要编辑图像，编码器还需要一个单独的多模态投影器：stable-diffusion.cpp 的文档指示读者还要从编码器仓库下载 mmproj-Qwen3VL-8B-Instruct-F16.gguf（1.16 GB），并通过 --llm_vision 传入，而且每张参考图像都要重复一次 -r。仅含 transformer 的 GGUF 加上一个文本编码器，就只是一个文生图流水线，仅此而已。

还有两个上传值得了解。该版本还附带了两个提示重写编码器——Qwen-Image-2.1-PE-T2I和Qwen-Image-2.1-PE-I2I，两者都是经过微调的 9B 模型——供应商建议将它们放在图像模型之前运行，而这些也正在被量化：来自 LightX2V 项目的 T2I 重写器的 GGUF 构建于 2026 年 10 月 12 日出现在 Hugging Face 上，同时还有几个社区构建。而 alpha 通道——这是该模型较为独特的特性之一——在量化后依然保留，但并非每种容器都能保留：扩散模型根据提示词而不是某个开关来决定透明度，并且 alpha 只保留在 .png和 .webp 输出中。

围绕 GGUF 本身的内存规划，正是运行时文档真正给出具体细节的地方，这很少见。stable-diffusion.cpp 将与步数无关的文本和参考图像键值复用为前缀缓存，并公布了在 4096 token 前缀下、32 层模型按条件计算的开销：FP32 为 4 GiB，FP16 为 2 GiB，q8_0 为 1.0625 GiB，q4_0 为 0.5625 GiB。对缓存进行量化是与量化权重不同的第二项独立权衡，它默认关闭，而量化缓存存储会引入额外的舍入误差，文档对此明确指出而非隐藏。

量化所继承的许可证

这是大多数GGUF页面都会跳过的部分，而对于此模型而言，它却是能够改变你所能实现功能的关键章节。

基础权重并非以宽松许可证分发。Qwen/Qwen-Image-2.1 仓库带有 license: other，并附有 license_name: qwen-research，而 LICENSE 文件是 Qwen 研究许可协议，发布日期为 2026 年 9 月 20 日。于 2026 年 10 月 13 日完整阅读后，其实际授予的许可是非独占、全球范围、不可转让、免版税的许可，仅限“为非商业目的使用、复制、分发、拷贝、创建衍生作品以及对材料进行修改”，其中“非商业”在协议内定义为“仅用于研究或评估目的”，商业使用则需通过协议指定的电子邮件地址请求单独许可。

量化检查点是那些材料的衍生作品，这意味着再分发 GGUF 即构成该协议下的再分发，并受其附带的所有条件约束。其中三项是具体的：

• 你必须将协议一并传递下去。第 3(a) 条要求你向任何收到这些材料或衍生作品的人提供一份许可证副本。一个只带许可证标签却没有协议文本的 GGUF 仓库是不合规的，无论其下载量有多大。

• 你必须标明你所修改的内容。第3(b)条要求修改过的文件带有醒目声明，说明其已被修改。重新编码的权重文件属于修改过的文件。

• 您必须原样保留署名声明。第 3(c) 条要求，该声明文本——"Qwen is licensed under the Qwen RESEARCH LICENSE AGREEMENT, Copyright (c) 2026 Hangzhou Tongyi Laboratory Technology Co., Ltd. All Rights Reserved."——须保留在随副本一同分发的 "Notice" 文本文件中。

还有两条规则约束进行量化的人以及任何基于该成果继续开发的人。如果你使用这些材料或其输出训练、微调或改进 AI 模型，然后将其分发，你必须在产品文档中显著展示“Built with Qwen”或“Improved using Qwen”。并且，你不得将“Qwen”用作衍生作品的主要名称或标识，但允许进行描述性使用，例如“fine-tuned from Qwen Image”。管辖法律为中国法律，专属管辖法院为杭州市人民法院。

其实际结论只有一句话，而且值得直说，因为这种格式把它掩盖了：对权重做量化并不会改变许可证。为撰写本页而查验的每一个仓库都带有 license_name: qwen-research，并链接回厂商的 LICENSE 文件，而某个 GGUF 文件的下载量并不构成商业权利的授予。作为对比，早先的 Qwen 图像系列则是宽松许可——Qwen-Image、Qwen-Image-Edit、Qwen-Image-Edit-2511和Qwen-Image-2512的模型卡在 2026 年 10 月 13 日均标注为 apache-2.0——而 Qwen-Image-2.1 正是这一模式中的例外。如果目标是商业流水线，那么许可证是首先要读的东西，而不是最后才看的。

这让你处于什么境地

以下表述是一个判断，而非总结：如果你的显卡既装不下 14.23 GB 的 transformer，又装不下 17.53 GB 的 encoder，还要再加上 VAE，那么 GGUF 版本就是你能运行 Qwen-Image-2.1 的唯一途径；而且说实话，中等程度的量化只能让你跑起来，代价则是在精细细节、手部、小字和指令遵循上有所损失——目前没有任何公开的测量数据能告诉你损失有多大。如果你的显卡装得下，那么 safetensors 路线才是厂商文档所记载的路径，也是拥有明确参照基准的那条路。

有两位读者需要在本站其他地方各读到一句话。如果你真正想要的是去掉了安全过滤的社区构建版，而不是对格式的讨论，那是另一个页面，无审查构建版在那里有介绍。而如果你真正的目的地是一个可运行的节点图，而不是一个必须手动拼装的文件，那么 ComfyUI 页面会逐个加载器地走完整条流水线。

仍然悬而未决的，是整个生态系统尚未发布的东西：在固定种子、相同提示词和相同采样器，以及在有人明确指出的硬件上，对这些级别进行受控对比。RealRebelAI 指出，通用的 Q4_K_M 相比 INT8 参考版本出现了肉眼可见的劣化，而同一标签下的混合精度构建却没有，这是公开信息中最接近该答案的内容，而且它只是一家发布方自己的 A/B 测试。在有人发布这项对比之前，你应该选择的级别是你的内存所能允许的最高级别，而文件名上的标签，其保证力度弱于其背后的张量策略。