開源 AI 圖像生成的領導工具 ComfyUI 於本週正式釋出 v0.12.0 版本更新。本次更新在底層效能與生成式 AI 的跨領域整合繼續深化。對於長期關注本地端 AI 部署的開發者與創作者而言，這次更新最引人注目的莫過於對大型語言模型（LLM）推論速度的最佳化，以及針對 Windows 使用者長期詬病的記憶體溢出問題修復。
以下是 CyberQ 實測與彙整的 v0.12.0 版本更新重點分析：
導入 KV Cache 大幅提升 LLM 文字生成效率
在 v0.12.0 中，ComfyUI 開發團隊為 Llama 系列模型導入了 KV Cache（Key-Value Cache） 機制，是加速 LLM 推論的重要技術之一。
在過去的純文字生成節點中，模型在生成每一個新 Token 時，往往需要重新計算先前所有 Token 的注意力權重，這導致生成長文本時速度會呈指數級下降。KV Cache 的加入，讓系統能夠暫存先前計算過的 Key 與 Value 矩陣，這意味著在生成下一個字時，只需計算最新的部分即可。
當我們在 ComfyUI 工作流中整合了本地 LLM（例如用於擴寫 Prompt 或生成影片故事腳本），v0.12.0 的文字生成速度將會有顯著的提升，且我們實測它中，隨著生成文字長度的增加，效能差異會更明顯。
記憶體管理與 VRAM 最佳化
本次更新也針對硬體資源管理進行了多項底層修復，特別是解決了困擾許多 Windows 用戶的「共享記憶體溢出（Shared Memory Spilling）」問題。
過去在 VRAM 吃緊時，系統嘗試調用 Windows 共享記憶體可能導致效能驟降或崩潰，新版本有重新再最佳化這個機制，減少效能降低和崩潰的機率。
另外這次改版也降低了 RAM 佔用，同樣也修復了視訊記憶體 VRAM OOM 的問題，開發者 @rattus128 提交的修復大幅減少了模型加載時的 RAM 需求，並解決了特定情況下的 VRAM 記憶體不足（OOM）錯誤，這對於使用 8GB 或 12GB 顯示卡的用戶來說是一大福音。
新增節點與模型支援
除了底層最佳化，功能層面也有不少新增強化：
這次更新也導入了一些新的 AI 音樂生成模型的範本，很值得去嘗試看看。
新的 Qwen-Image 2512 Turbo 出圖速度極快，也是從 0.11.1 到 0.12.0 後的新增重點範本。
包括 Vidu 影片生成模型更新，新增對 Vidu Q3 模型的支援，並導入了 Extend（延伸）與 MultiFrame 多幀節點，提升了影片生成的連貫性與控制力。
Recraft 風格節點，新增 RecraftCreateStyleNode，這是更便捷的風格遷移和風格鎖定功能，對於追求風格一致性的創作者相當實用。
這次也整合了 HitPaw API 節點，官方持續注重與擴展第三方 API 生態，繼續提供更多樣化的圖像處理服務。
告別 OOM 的秘密武器是動態模型載入 (Adaptive Model Loading)
根據開發者 rattus128 在 PR #11845 的技術說明，v0.12.0 的記憶體最佳化並非僅是參數調整，而是引入了一套全新的 ModelPatcher 實作，其核心基於 comfy-aimdo 函式庫。這項更新帶來了兩個革命性的改變：
首先是智慧型 VRAM 談判機制 (Lazy Loading & Dynamic Negotiation) 的導入，新系統不再像過去那樣「預先估算」VRAM 用量，而是改採「延遲載入（Lazy Load）」策略。只有在模型真正開始推論（例如 KSampler 的第一步）時，系統才會根據當前顯卡狀態，動態決定要載入多少權重。最關鍵的是，如果推論過程中 VRAM 不足，新機制會趕在 OOM記憶體溢位崩潰發生前，自動將部分權重卸載（Offload）到系統記憶體，這讓許多原本會讓 VRAM 爆掉的大模型現在都能順利執行。
其次是 mmap 與 Commit Charge 的最佳化，針對 Windows 系統，開發者特別解決了 Commit Charge 耗盡的問題。在舊版中，模型權重會被完整載入到 RAM 中，這會擠壓作業系統的磁碟快取（Disk Cache）。 新版本利用 PyTorch 的 mmap（記憶體映射）特性，讓模型權重直接停留在磁碟映射區，不佔用實際的程式 RAM。這不僅大幅降低了 Windows 的記憶體壓力，更因為保留了磁碟快取，使得模型的「第二次讀取」速度幾乎是瞬間完成，解決了 Windows 共享記憶體洩漏導致的效能低落問題。
迭代更新快速有好有壞
ComfyUI 的更新頻率極高（距離 v0.11.1 僅數天），這雖然展現了開源社群的強大活力，但也伴隨著部分用戶的更新焦慮。社群中已有部分用戶反映，v0.12.0 的底層改動導致部分舊版自定義節點（Custom Nodes）失效。
CyberQ 建議，若是已經在進行穩定的生產專案，這部分可先建議暫緩更新，使用另一個獨立的環境進行測試後，確定你的工作流和自訂義節點沒問題後，正式生產環境就可以更新導入了。對於熱衷嘗試新技術的玩家來說，這次針對 LLM 與 VRAM 的最佳化絕對值得一試，我們實測了產圖和產影片的記憶體耗用程度比之前少了 5% 到 15% 左右。
