Qwen-Image-2.1 GGUF：量化版本實際上讓你付出什麼代價

官方並沒有 Qwen-Image-2.1 的 GGUF。每一份.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 沒有困惑度這種東西。模型不會輸出可供評分的詞元分佈；它輸出的是潛在表示，再由 VAE 解碼成像素。在這道分界線的這一側，現有的指標——LPIPS、相對於參考渲染的 SSIM——要求比較雙方使用相同的種子、相同的提示詞與相同的取樣器設定，而且它們衡量的仍然是感知距離，而不是正確性。所以「Q4_K_M 讓我付出多少代價？」這個問題，並不像文字模型那樣有一個單一已公佈的數字；任何引用某個數字的人，引用的都只是在某一個種子上的某一次測量。

其次，而且影響更大的是：在圖像模型上，平均位元寬度的重要性不如哪些張量失去了位元。乘載圖像結構的注意力投影與 MLP 路徑在被捨入時會明顯劣化，而小型正規化與調變張量幾乎能容忍任何情況。因此，對每個張量都套用一致目標的轉換，可能比同樣名義標籤、但會保護敏感層的轉換看起來更差——而這正是從事這項工作的人所發現的。RealRebelAI 發布了我們能找到最明確的量化說明，並表示「標準的通用 Q4_K_M 轉換，相較於參考 INT8 模型，在精細結構與解剖構造上出現明顯的品質損失」，且其自家建置版本會在 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，而廠商自家在 Comfy-Org 重新打包版本中的 bfloat16 擴散元件也是 14.23 GB。所以 Q4 等級的 GGUF 對 Transformer 大約有 3.4× 的縮減，而對文字編碼器則完全沒有縮減，除非你另外對它進行量化。

每一級的成本是多少，只要有來源這麼記載

幾乎沒有人會為這個模型公佈各等級經實測的品質成本，而誠實的做法，就是把目前流傳的三類說法區分開來。

• 記憶體指引，社群回報。 Abiray 的儲存庫會為每個檔案搭配建議的 VRAM 設定檔：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，用於「極致預算／最低 VRAM」。這些是發佈者自己的經驗法則，不是廠商規格，也不是我們能重現的基準測試；它們也只描述 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 這兩個儲存庫都明確致謝它。如果你想要一個沒人發布過的等級，這就是你用來轉換的工具。

• Unsloth Desktop — 由 unsloth 儲存庫列為與 stable-diffusion.cpp 並列的受支援前端。

有一個執行環境明顯不載入它：Diffusers。該廠商自家的快速入門是QwenImage21Pipeline，搭配 bfloat16 safetensors 儲存庫，而該管線中沒有 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。將快取量化，與將權重量化是另一項獨立的取捨，它預設為關閉，而量化後的快取儲存會引入額外的捨入誤差，文件對此加以標示而非隱藏。

量化所繼承的授權

這就是{{1}}那個{{/1}}{{2}}會{{/2}}改變{{3}}你能做什麼{{/3}}的那一個。

基礎權重並非依寬鬆授權條款散布。Qwen/Qwen-Image-2.1 儲存庫帶有 license: other，並有 license_name: qwen-research，而 LICENSE 檔案為 Qwen Research License Agreement，發布日期為 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 測試。在有人發表這項比較之前，你應該選擇的層級是你的記憶體所能容許的最高層級，而檔名上的標籤，比起其背後的張量策略，是更薄弱的保證。