Qwen-Image-2.1-GGUF

云碩（xCloudinfo）自製的 Qwen-Image-2.1 GGUF 量化版本，底模 Qwen/Qwen-Image-2.1。

這個 repo 解決什麼問題

llama.cpp 生態（含 ComfyUI-GGUF）原本不支援量化 Qwen-Image-2.1——llama-quantize 遇到這個架構會直接報 unknown model architecture: 'qwen_image21'。我方在 leejet 的 ComfyUI-GGUF fork 補上了 qwen_image21 架構的量化支援（C++ 端五處：架構列舉、名稱對照表、tensor map、 metadata 略過規則、量化排除規則），重新編譯 llama-quantize 後產出完整六階量化。 ComfyUI 端的讀取支援 leejet fork 其實已經內建（qwen_image21 已列在其 loader.py 的 IMG_ARCH_LIST），本次補的是「產出」這一側的缺口。

內含檔案

• Qwen-Image-2.1-{Q8_0,Q6_K,Q5_K_M,Q4_K_M,Q3_K_M,Q2_K}.gguf —— DiT 主體，六個量化階
• text_encoders/qwen3vl_8b_bf16.safetensors —— Qwen3-VL-8B 文字編碼器，bf16，單一檔案。 權重與官方 text_encoder 的四個分片逐位元相同（750 個張量全部比對，無任何差異）。 差別只在封裝：合併成單檔，且語言模型張量的鍵名由官方的 model.language_model.layers.* 改為 model.layers.*。這不是 Qwen 官方發布的檔案形式，是為了單檔載入而重新封裝的版本。
• vae/qwen_image_2.1_vae.safetensors —— 官方 vae/diffusion_pytorch_model.safetensors，內容未修改， 上傳時僅更改檔名。

量化方法

邊界層（img_in. / txt_in. / time_text_embed. / modulation. / norm_out. / proj_out.weight） 維持 bf16 不量化，逐層注意力與 MLP 矩陣依量化階梯轉換，1D 正規化層（norm_q/norm_k）自動保留 f32 ——沿用 llama.cpp 對 FLUX、SD3 等既有 diffusion 架構的既定處理方式。

沒有 IQ4_XS / IQ2_M：llama.cpp（含此 fork）目前對所有 image-model 架構統一禁用 I-quant 系列 （Invalid quantization type for image model (Not supported)），FLUX/SD3 等既有架構一樣不能轉 I-quant。 這是上游程式碼現有的限制，不是這次轉檔特有的問題。最小的可用量化階是 Q2_K。

誠實揭露

• 已做結構驗證：297 個張量數量與命名對齊原始 f16、邊界層確認未被量化、輸出檔案能被 gguf reader 正常解析。
• 未做端到端生圖驗證：轉檔環境沒有安裝完整 ComfyUI，沒有實際跑一次生圖比對輸出品質。 建議初次使用先用較高量化階（Q8_0/Q6_K）跑一張對照圖確認品質，再視需求換更小的階。
• 使用需要支援 qwen_image21 架構的 ComfyUI-GGUF 節點；目前建議用 leejet 的 fork，vanilla city96 版尚未收錄此架構。

使用方式（ComfyUI）

1. 安裝 leejet/ComfyUI-GGUF 到 custom_nodes/。
2. DiT GGUF 放 models/diffusion_models/，用 UNET Loader (GGUF) 節點載入。
3. 文字編碼器放 models/text_encoders/，VAE 放 models/vae/，分別用對應的原生節點載入。

授權

繼承 Qwen-Image-2.1 原廠授權（Apache 2.0）。