8GB VRAM 跑得動 12B 模型？本地 AI 圖片生成的模型選擇思路

最近在建一條本地 AI 影片生成流水線，需要挑一個 T2I 模型做 keyframe 的上游。硬體限制是 RTX 3070 Laptop，8GB VRAM，不能加卡。

挑模型的過程裡，順帶整理了一些平時容易混淆的概念，以及讓系統跑穩的幾個關鍵設定。

Fine-tune、LoRA、Distill 是三件不同的事

這三個詞在中文圈常常被混在一起講，但它們根本不是同一個維度：

這三件事可以疊在同一個工作流裡。juggernautXL_v9-lightning.safetensors 這個常見的模型，本質就是寫實 fine-tune + Lightning distill 的組合；用它的時候還可以再加角色 LoRA + 風格 LoRA。

弄清楚這個，選模型的時候就不會被名字搞混。

把常見的選項排一遍：

模型	VRAM	1024² 出圖時間	品質	8GB 可行？
SDXL Lightning（4–8 步）	~7 GB	4–6 s	★★★★☆	✓
SDXL base + fine-tune（30 步）	~7 GB	15–22 s	★★★★☆	✓
Flux Schnell GGUF Q4_K_M	~7 GB + offload	15–20 s	★★★★★	✓
Flux Dev GGUF Q4_K_M	~7 GB + offload	60–90 s	★★★★★	✓ 但慢
Flux fp16	12 GB+	—	★★★★★	✗

12B 的 Flux 為什麼能塞進 8GB？靠 GGUF Q4_K_M 量化——精度損失大約 5–10%，但 Flux 的 prompt 理解能力幾乎全保留。Q4_K_M 是 4-bit 量化裡品質與速度的甜蜜點， Q4 還是 Flux 級的，不是閹割版。

搭配 ComfyUI 的 --cache-none 啟動參數以及系統自動 offload，8GB 跑圖片其實非常夠用，可以達到相當穩定的效果。

測試幾輪下來，有一個結果出乎意料：

寫實 SDXL fine-tune 在單張人像特寫場景，有時候贏 Flux。

Flux 的「AI 感」比想像中明顯——塑膠皮膚、過度平滑的質感，在人像特寫裡特別容易被注意到。寫實 SDXL（Juggernaut、RealVisXL 這類）因為是在大量攝影照片上 fine-tune 的，皮膚紋理相對自然。

但這個優勢邊界其實是流動的，還在測試中。偶爾 SDXL 贏，偶爾 Flux 贏，取決於場景、構圖、光線方向這些細節。

最後發現，模型之間的邊界不是最重要的事。真正決定產出品質的，是你對提示詞的熟練度，以及你對這個模型的反應熟不熟。 同樣一行 prompt，對 SDXL 有效的寫法拿去餵 Flux 未必成立。換模型，等於重新建立一套使用直覺。

這個問題卡了我一段時間，值得單獨說。

在 Windows 上跑 AI 圖片生成，當 VRAM + RAM 都吃滿，系統會把溢出的資料 offload 到 pagefile。 Pagefile 在 SSD 上，速度比 RAM 慢 10–50 倍。一旦生成流進入 pagefile 處理，出圖時間會異常拉長。

問題在於，Windows 預設的 pagefile 是自動增長模式，理論上系統會按需擴大。實際上，當模型 offload 量大的時候，我曾經看到 pagefile 自動增長到 6X GB—— 這個大小讓 swap 有機會觸發磁碟 I/O，反而造成不穩定。

解法：把 pagefile 設成固定大小。

計算方式：系統 RAM（32 GB）+ 估計需要的 model swap space，取一個保守的固定值（例如 24 GB）。設定固定大小後，系統不會再無限增長，pagefile 用量變得可預測，出圖速度也恢復穩定。

設定路徑：進階系統設定 → 效能選項 → 虛擬記憶體 → 取消自動管理 → 手動指定固定大小。

「8GB VRAM 跑不動現代模型」這個說法在 2024 年前大概是對的。 2025 年後，GGUF Q4_K_M 量化 + distill + 智能 offload，加上 --cache-none 這類記憶體管理參數，讓這個上限被推高了不少。

8GB 跑 Flux 12B、跑 SDXL，在設定對了的前提下，現在都是可行的。要付出的代價是速度，以及對工作流更細緻的理解——哪個步驟在哪一層記憶體裡、會不會打架。

最終哪個模型更好，測試還在進行。但這些設定讓我可以在穩定的環境下繼續測下去，這才是前提。