日期：2026年 07月 04日
標籤： Linux Ubuntu Docker Docker-Compose Container Stable Diffusion ComfyUI WSL 2 Wan 2.1 GGUF
摘要：生成式AI
應用所需：1. 已安裝 Windows 的 Docker Desktop (Use WSL 2 instead of Hyper-V)
2. 已安裝 Hyper-V + ComfyUI(容器化)
3. 顯示卡使用 RTX 5070 以上 + 12G VRAM
4. Windows 10 以上作業系統
解決問題：1. 延續上一篇文章，並且當顯示卡低於 16 VRAM 的優化 Wan 2.1 生成影片的優化方案，如何用另一種 GGUF 導入的方式提升速度與品質
2. 說明與 LightX2V LoRA 模型的差異，講述 GGUF 原理、應用情境
相關參考：1. 0002. ComfyUI容器化執行 Wan 2.1(2.2) 生成影片(圖片生成影片) + 頻頻跳出 Killed 錯誤？ 說明隱藏在 Windowss 下 WSL2 記憶體限制裡的 OOM 隱形殺手
2. 0003. 動態與速度兼得：如何用 LightX2V Lora 替代傳統採樣算法，解放消費級顯卡的 Wan 2.1 影片生成潛力
基本介紹：本篇分為三大部分。
第一部分：問題描述
第二部分：優化工作流-導入 GGUF 量化模型
第三部分：驗證成果
第一部分：問題描述
Step 1：Wan 2.1(2.2) 執行效能慢補充
若受限於顯示卡 VRAM 不足於 16G 的情況下，用一般的方式執行 Wan 2.1(2.2) 圖片生成影片效能會很差，因為 VRAM 不足的情況下會導致
不斷把資料「往系統 RAM 甚至硬碟 Swap 搬運 (Offload)」
因此上一篇生成 5 秒的影片，25 分鐘有很多都是在執行釋放記憶體的工作
Step 2：本篇說明 - 對應規格
若硬體設備遠高於此，基本上 VRAM 不足的問題應不容易發生，可不用檢閱此篇內容
| 項目 | 規格 |
|---|---|
| GPU | 名稱 NVIDIA GeForce RTX 5070 (12G VRAM) |
| CPU | Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz，3192 Mhz，6 個核心，12 個邏輯處理器 |
| RAM | 48 GB |
| OS | Microsoft Windows 10 專業版 |
第二部分：優化工作流-導入 GGUF 量化模型
Step 1：GGUF 原理
GGUF（GPT-Generated Unified Format） 由著名的開源開發者 Georgi Gerganov（llama.cpp 的作者）。
所設計的一種二進位模型儲存格式。
| 特性 | 說明如何優化 |
|---|---|
| 1. 高階權重量化 | 原本官方的 safetensors 模型（例如 Wan 2.1/2.2 14B）內部的數十億個權重參數是用 FP16（16位元浮點數） |
| GGUF 採用量化技術（如 Q4_K_M），利用演算法把 16 位元的高精度數字，對應並壓縮成 4 位元（4-bit） | |
| 以圖片來舉例：原本 Wan 2.1 14B 等於 BMP 圖檔 ; GGUF 就變成了 JPG，品質空間優化壓縮，但是人類肉眼無法看出差異 | |
| 2. 單一檔案封裝 | 傳統的 AI 模型在載入時，常常需要同時讀取模型權重、詞表（Tokenizer）、硬體設定等多個分散的檔案。 |
| 而 GGUF GGUF 把所有的元數據（Metadata）、模型架構、權重數據全部打包在同一個 .gguf 檔案裡 | |
| 這也是為什麼 GGUF 模型的載入速度通常比 Safetensors 快非常多的原因。 | |
| 3. 解放 VRAM，消滅 Offload | 當 14B 模型透過 GGUF 壓縮到 9GB 後，它能整尊塞進 12GB 的顯存中 |
| 而不會發生硬碟 Swap 搬運 (Offload)造成執行釋放記憶體工作 |
Step 2：GGUF 與 LightX2V LoRA 的差異
這兩個技術常常被放在一起討論，因為它們都能「提速」，但兩者運行的原理完全不同：
| 特性 | GGUF 量化模型 | LightX2V (Low / High - Noise) |
|---|---|---|
| 1. 運作層面 | 電腦底層的數據封裝與壓縮 | 數學演算法上的 噪點 預測與限制 |
| 2. 原理 | 參數的位元精確度改變（FP16 -> 4 位元），壓縮變小 | 改變神經網路去噪時的時間步長(20->4)與噪點權重。 |
| 3. 核心目的 | 讓中低階顯卡放得下模型，免除顯存與系統 RAM 的交換地獄 | 提升畫面的穩定度（減少閃爍），並減少無效計算步數。 |
| 4. 硬體體積 | 檔案大小大幅縮小（30GB -> 9GB） | 檔案大小沒有變化 |
Step 3： GGUF 導入考量
通常 VRAM 不足的情況下， GGUF 是可選擇的解決方案之一，解決 SWAP Offload 耗時問題
情況 1：無條件選擇 GGUF
| 1. 硬體限制 | 顯卡 VRAM 在 8GB ~ 16GB 之間 |
| 2. 記憶體不足 | 跑原生模型時，docker stats 顯示記憶體衝破 90%，後台頻繁出現 Killed，或者一鏡 5 秒要跑 15~20 分鐘以上。 |
| 3. 理由 | 此時 GGUF 很合適，透過微小的「精確度損失（數學上的四捨五入）」，換取了數十倍的生成速度，對生產力是壓倒性的提升。 |
情況 2：維持原生的 Safetensors
| 1. 硬體限制 | 你擁有 24GB VRAM 的高階顯示卡 / 多張顯卡 |
| 2. 作畫需求 | 追求極致商業級細節（例如寫實風的皮膚毛孔、複雜的沙塵暴粒子特效），且完全不在意生成時間。 |
| 3. 理由 | 24GB 顯存可以完美生吞 14B 的完整 FP16 模型，就不需要承受 GGUF 量化帶來的微幅細節失真。 |
| 工作應用上有追求最高品質，也請勿使用 GGUF，避免壓縮導致細節破壞 |
Step 4：GGUF 缺點 & 優點補充
GGUF 的核心優點除了壓縮外，補充以下 4 項優點
| 1. 顯存與記憶體佔用 | 大模型能完完整整地塞進 12GB VRAM 中，彻底消滅了因顯存超支而引發的 CPU/RAM 慢速交換（Offload） |
| 2. 極致的加載與讀取速度 | 將權重與所有的元數據（Metadata，包含詞表、硬體配置等）打包在單一檔案內，加快運行速度 |
| 3. I/O 頻寬與硬碟空間雙重解放 | 檔案體積縮小了 60% ~ 70%。對於硬碟空間有限的個人創作者來說非常友善 |
| 4. CPU/GPU 混合硬體調配彈性 | 未來想挑戰更巨大的模型（例如 32B 規格），GGUF 允許精確指定「幾層由 GPU 計算，剩下的丟給 CPU/RAM 扛」 |
補充以下 3 項缺點
| 1. 數學精確度損失 | 雖然肉眼不可見，但 FP16（16位元浮點數）壓縮成 4-bit 整數，本質上就是一種「有損壓縮」(毛孔細節遺失)。 |
| 2. LoRA 等微調模型的相容性較繁瑣 | 因為主模型的權重結構已經被量化改變，在 ComfyUI 中，必須額外安裝 ComfyUI-GGUF 等專用插件節點， |
| 讓 AI 在執行時動態去把 LoRA 權重和 GGUF 進行數學對齊。 | |
| 3. 高度依賴開源社群的轉檔與更新 | 阿里官方（Wan-AI）釋出模型時，只會提供標準的 safetensors (FP16/BF16) 官方版 |
| ※當前是 Wan 2.2 未來 Wan 2.3 一出時，需要等待官方釋出 GGUF，否則就要依賴社群相關開發者提供 |
因此在 ComfyUI 中使用 GGUF 需要額外的安裝插件
Step 5：導入 GGUF - 下載頁面
進入下載模型Huggige Face 上的 Wan2.1 - GGUF
然後選擇 Files and versions
Step 6：導入 GGUF - Q4_K_M
Q4 體積約 8.5GB ~ 9GB，對 12G 的顯示卡是相當合適，兼具速度 + 品質
Step 7：補充 GGUF - 參數說明
在下載頁會出現很多 GGUF 的量化模型檔案下載，列表如下：
wan2.1-i2v-14b-480p-BF16.gguf
wan2.1-i2v-14b-480p-F16.gguf
wan2.1-i2v-14b-480p-Q3_K_M.gguf
wan2.1-i2v-14b-480p-Q3_K_S.gguf
wan2.1-i2v-14b-480p-Q4_0.gguf
wan2.1-i2v-14b-480p-Q4_1.gguf
wan2.1-i2v-14b-480p-Q4_K_M.gguf
wan2.1-i2v-14b-480p-Q4_K_S.gguf
wan2.1-i2v-14b-480p-Q5_0.gguf
wan2.1-i2v-14b-480p-Q5_1.gguf
wan2.1-i2v-14b-480p-Q5_K_M.gguf
wan2.1-i2v-14b-480p-Q5_K_S.gguf
wan2.1-i2v-14b-480p-Q6_K.gguf
wan2.1-i2v-14b-480p-Q8_0.gguf
檔案名稱是有意義的，參數對應說明如下：
※ 模型大小 = 精度 X 模型參數量
| 參數 | 說明 |
|---|---|
| i2v | Image to Video |
| 14b | 140億參數 |
| 480p | 影片解析度 |
| BF16 | 原生未壓縮，Bfloat16，大腦浮點數(brain floating point)。訓練常用格式，範圍 8 BITS，精度 7 BITS |
| F16 | 原生未壓縮，Float16，半精度浮點數。F16 相容性較廣，精度比 BF16 更高，範圍 5 BITS，精度 10 BITS |
| _0 | 對稱量化，舊式，相容性較佳，但品質略遜 |
| _1 | 非對稱量化，舊式，相容性較佳，但品質略遜 |
| _K | 新式，同位元數下品質更好，推薦優先選擇 |
| _S | 檔案較小，速度較快，品質略低 |
| _M | 稍大，品質明顯優於 S，通常選 M 更划算 |
Step 8：補充 GGUF - 如何選擇
BF16、F16 可以排除，因為基本屬於原生，對節省記憶體、效能沒有任何提升，可以使用原生的 Wan 2.1 模型
以下是顯卡記憶體與情境分類，實務訓練時可選擇合適自己的項目：
| 格式 | 每權重位元數 | VRAM 約略大小 | 品質 | 速度 | 適合情境 |
|---|---|---|---|---|---|
| Q3_K_S | ~3.0 bit | ~6.5 GB | ★★☆☆☆ | 最快 | VRAM 極度吃緊 |
| Q3_K_M | ~3.3 bit | ~7.1 GB | ★★★☆☆ | 很快 | 低 VRAM 可用 |
| Q4_0 | 4 bit | ~7.9 GB | ★★★☆☆ | 快 | 舊式，相容性佳 |
| Q4_1 | 4 bit | ~8.7 GB | ★★★☆☆ | 快 | 比 Q4_0 略精準 |
| Q4_K_S | ~4.0 bit | ~8.1 GB | ★★★☆☆ | 快 | 推薦入門選擇 |
| Q4_K_M | ~4.5 bit | ~8.6 GB | ★★★★☆ | 快 | 最常用，CP值最高 |
| Q5_0 | 5 bit | ~9.7 GB | ★★★★☆ | 中 | 舊式 5-bit |
| Q5_1 | 5 bit | ~10.6 GB | ★★★★☆ | 中 | 比 Q5_0 略精準 |
| Q5_K_S | ~5.0 bit | ~9.9 GB | ★★★★☆ | 中 | 5-bit 新式 |
| Q5_K_M | ~5.5 bit | ~10.4 GB | ★★★★☆ | 中 | 高品質推薦 |
| Q6_K | ~6.0 bit | ~12.1 GB | ★★★★★ | 較 | 慢接近原始精度 |
| Q8_0 | 8 bit | ~15.6 GB | ★★★★★ | 慢 | 幾乎無損，偏好精度 |
Step 9：導入 GGUF - 放到正確位置
下載完成後，放到對應目錄，可以參考圖示：
ComfyUI/
└── models/
└── diffusion_models/
├── wan2.1-i2v-14b-480p-Q4_K_M.gguf
Step 10：導入 GGUF - 增加 GGUF 加載器
上一篇文章的工作流步驟如下：
UNet加載器
└─ 模型 ──→ 模型 ──→ K采樣器
加載CLIP
└─ CLIP ──→ CLIP ──→ CLIP Text Encode
我們目標是添加 GGUF 模型，基本上是完全替換 Unet 加載器即可
UNET 加載器 (GGUF)
└─ 模型 ──→ 模型 ──→ K采樣器
加載CLIP
└─ CLIP ──→ CLIP ──→ CLIP Text Encode
因此先在 ComfyUI 空白處，添加 UNET 加載器 (GGUF)
這時有可能會出現沒有找到的狀況，這時就要對 ComfyUI 做外掛安裝 ComfyUI-GGUF
Step 11：ComfyUI - 管理擴展功能
開啟 ComfyUI 左側管理擴展功能
Step 12：ComfyUI - 安裝擴充
搜尋欄輸入 GGUF ，會出現 ComfyUI-GGUF 進行安裝
安裝完成後，重新啟動整個容器
Step 13：導入 GGUF - 出現 GGUF 加載器
重啟後，再次進行添加節點 -> 加載器 -> Unet Loader(GGUF)
Step 14：導入 GGUF - 替換模型
接著將 UNet 替換掉，並且將剛剛下載的模型 (wan2.1-i2v-14b-480p-Q4_K_M.gguf) 選取
第三部分：驗證成果
Step 1：開始執行 ITV - DEMO結果
最後嘗試執行，我們平均花費約 11~13 分鐘間完成生成 5 秒影片，影片在大多時間下仍能保持一定品質
生成結果 - Youtube 播放：
Step 2：穩定的執行速度
在 VRAM 的載入量都很穩定，無論首次或者後續載入，VRAM 尚有餘力
GGUF 帶來約 1.7x 加速 (原耗費時間為 25 分鐘，變為 12分鐘左右)
