化清單，低配黨照抄)
8GB 顯存也能玩KV Cache 與 Block Cache 優(yōu)化清單低配黨照抄【免費下載鏈接】Minimax-H3-ComfyUI項目地址: https://ai.gitcode.com/hf_mirrors/Alissonerdx/Minimax-H3-ComfyUIMiniMax H3 開源后社區(qū)里最熱鬧的話題不是它 33B 的全模態(tài)架構而是這張卡到底能不能跑。目前流傳的結論相當分裂有人說 INT8 量化版 8GB 顯存就能出片實測 480P 視頻 5–10 分鐘有人說單張 24G 是門檻還有人在 12G 的 RTX 3060 上順利跑通了文生視頻。分歧的來源不是玄學而是視頻擴散模型的顯存消耗結構——它的瓶頸幾乎不在權重本身而在 KV Cache 與注意力激活值上。這篇文章以 Minimax-H3-ComfyUI 倉庫的實際工作流為底把 KV Cache 的消耗邏輯、Block Cache 的降顯存原理和一套可照抄的采樣參數(shù)組合拆開講清楚低配黨可以直接對照抄作業(yè)。一、KV Cache 瓶頸定位顯存到底被誰吃掉了先糾正一個直覺文生圖模型吃顯存的重頭是權重和 UNet/DiT 的中間激活而 H3 這類視頻模型完全不是這個量級。社區(qū)排障文章總結過它與文本/圖像模型在模型結構、顯存需求、推理鏈路三方面的本質差異——視頻生成把時間維度折疊進了 latent 序列序列長度直接決定注意力層的顯存天花板?？磦}庫工作流的模型補丁鏈就能明白設計者的算賬方式。LMS 工作流 在模型鏈上依次掛了MiniMaxH3SigmaShift、MiniMaxLowVRAMAttentionhead_chunks4、MiniMaxChunkFeedForward4 chunks、4352和SolAttnPatch其中 SolAttnPatch 的配置最能說明 KV Cache 的構成tau: 1.3, start_percent: 0.2, end_percent: 0.9, min_tokens: 4096, int8_qk: true, sink_conditioning: exact_kv_and_rows, int8_pv: true這套配置來自SolAttnPatch節(jié)點kijai/ComfyUI-SolAttn_triton它做的事情本質上是兩件稀疏注意力按 tau 閾值剪掉冗余 tokenmin_tokens4096兜底保證不過度裁剪和KV 量化int8_qk/int8_pv把 QK 與 PV 的緩存壓到 8bit。為什么要同時上這兩板斧因為視頻生成的 KV Cache 是按幀數(shù) × 每幀 token 數(shù)線性膨脹的。倉庫 README 里有一條被很多人忽略的硬約束H3 只支持17n 5的幀數(shù)5、22、39、56、73、90、107、124……。這看起來像某種訓練格式對齊本質上就是序列長度的檔位表——每多 17 幀attention 的序列就跳一個量級KV Cache 隨之線性上漲。8G 卡想穩(wěn)住先學會在這張表里挑小檔位而不是去猜分辨率。所以顯存被誰吃掉了的完整賬單是四筆權重量化版差異巨大見下文、KV Cache隨幀數(shù)與分辨率漲、注意力激活值單次前向的中間張量MiniMaxLowVRAMAttention的 head_chunks4 就是把它切成 4 塊分批算、VAE 與音頻分支。前兩筆是 8G 卡的生死線后兩筆是 12G–16G 卡的優(yōu)化空間。二、Block Cache 降顯存原理與開啟姿勢如果說 KV Cache 是省著用Block Cache 就是少算點。擴散模型在相鄰去噪步之間很多 Transformer block 的輸出其實高度相似——第 3 步和第 4 步中間層算出來的特征肉眼幾乎無差別。Block Cache 的思路就是把前幾步算好的 block 輸出緩存下來后續(xù)步數(shù)直接復用跳過整塊計算。社區(qū)實測報告里Block Cache 在 H3 上帶來的是顯存直降 10GB量級的收益并且能和 TeaCache 疊加。兩者的差別在粒度TeaCache 是 token 級緩存——只復用相似度高的那部分 token 的 block 輸出屬于部分跳過Block Cache 是整層整塊緩存——命中區(qū)間內的層直接引用歷史結果屬于整體跳過。前者省顯存的同時省時間后者主要換顯存兩者疊加時顯存曲線會更平緩。開啟姿勢分兩步。第一步是用 ComfyUI Manager 安裝 TeaCache / Block Cache 相關節(jié)點第二步是把它插進模型補丁鏈。倉庫工作流已經給出了標準串法——從 LMS 工作流 可以看到補丁是按SigmaShift → 低顯存注意力 → 分塊前饋 → SolAttn的順序串聯(lián)的這些低顯存節(jié)點在設計上就是可旁路啟停的開關顯存充裕時旁路掉、按原始圖跑顯存吃緊時逐個開啟。TeaCache / Block Cache 就加在這條鏈的末尾模型已經過量化與稀疏化處理之后把它當成一個額外的MODEL補丁節(jié)點接在采樣器之前即可。需要說明的是Block Cache / TeaCache 屬于社區(qū)插件生態(tài)本倉庫的工作流并未內置對應節(jié)點——倉庫 README 明確這些權重與工作流面向ref2va基座低顯存補丁由社區(qū)節(jié)點提供。這恰恰是它適合低配黨的原因顯存優(yōu)化和效果增強LoRA、潛空間放大是兩條正交的鏈可以分別疊加互不干擾。比如先在低顯存模式出 480P 初稿再用倉庫里的 LMS 銳化 LoRA 做二遍清晰度增強對比示例把跑得動和畫質夠拆成兩件事解決。三、采樣參數(shù)與 CPU Offload 組合拳8G–16G 顯存配置速查倉庫五份工作流是目前社區(qū)里少見的、真實跑通過的參數(shù)底稿直接拿來當速查表工作流SchedulerStepsDenoiseCFGSigmaShiftLMSsimple81112 / 3Style Transfersimple811–Head Swapbeta811–VFX Editsgm_uniform611–這幾組參數(shù)有明確的低顯存意圖逐條拆開說CFG 1H3 是蒸餾/無分類器引導訓練CFG1 意味著采樣時不需要額外跑一遍無條件分支——一次去噪只做一次前向顯存和時間雙省。這是視頻模型比文生圖模型在低配機上更友好的關鍵原因之一。6–8 步 simple/sgm_uniform/beta視頻模型步數(shù)直接換算成 KV Cache 的被訪問次數(shù)和總計算量6 步和 8 步的顯存峰值差不了太多但時間差近三成。VFX Edit 用 6 步是因為編輯類任務低步數(shù)欠擬合風險低從生成角度這是質量與資源的平衡點。SigmaShift (12, 3)把噪聲調度整體前移讓早期大噪聲步承擔更多去噪任務。它不直接省顯存但允許你在更少步數(shù)下保住畫面結構從而間接把 KV 訪問壓到最低。幀數(shù)檔位嚴格按 17n5 選幀。8G 卡先鎖 22 幀對應 480P 檔不要一上來就挑戰(zhàn) 56 幀。再看權重選擇。社區(qū)整理的 H3 權重譜系里BF16 全量約 66GNVFP4 約 34GINT8 壓縮版可到 21G 量級——這三檔直接決定了你的卡夠不夠放權重。實測反饋是INT8 版在 8GB 顯存設備可運行480P 生成耗時 5–10 分鐘RTX 3060 12G可跑文生視頻RTX 5060 Ti 16G 64G 內存被社區(qū)用來做完整部署實錄。在 16G 卡上 NVFP4 被反復驗證為同畫質更快是 50 系卡的默認選項。最后是 CPU Offload 的正確用法。Offload 不是萬能藥它的本質是把顯存不夠變成內存來湊代價是 PCIe 傳輸延遲。低配黨記住三條紀律只 offload 不參與當前計算的權重優(yōu)先用 ComfyUI 的--lowvram/--cpu-vae這類啟動級開關而不是把模型鏈上的節(jié)點隨意旁路系統(tǒng)內存要給足——社區(qū)實錄里 16G 顯存配 64G 內存Offload 才有緩沖余地8G 卡建議至少 32G 內存Offload 與采樣檔位聯(lián)動Offload 開后把幀數(shù)再降一檔56→39比硬扛高幀數(shù)然后 OOM 重跑快得多。OOM 的排查順序也按這個優(yōu)先級走先降幀數(shù)檔位 → 再降分辨率 → 再開 KV 量化與稀疏化 → 最后才動 Offload避免一上來就犧牲采樣質量。最終一張 8G–16G 速查表收尾顯存權重檔幀數(shù)分辨率采樣必開項8GBINT822480P8 步 / simpleLowVRAM 分塊、SolAttn 稀疏量化、TeaCache/Block Cache12GBINT8 / NVFP439480P–540P8 步SolAttn、Block Cache 可選16GBNVFP439–56540P–720P6–8 步SolAttn 低優(yōu)先級 OffloadMiniMax H3 給低配黨留下的空間比想象中大KV 可以量化、可以稀疏、可以分塊block 輸出可以緩存復用采樣步數(shù)可以壓到 6 步權重可以壓到 21G 檔——這些優(yōu)化在 倉庫工作流 里都能找到對應的開關和默認值。照抄這份清單8G 卡出的第一段視頻可能不算驚艷但它至少證明全模態(tài)視頻生成不再是 24G 顯存玩家的特權?！久赓M下載鏈接】Minimax-H3-ComfyUI項目地址: https://ai.gitcode.com/hf_mirrors/Alissonerdx/Minimax-H3-ComfyUI創(chuàng)作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考 8GB 顯存也能玩：KV Cache 與 Block Cache 優(yōu)化清單，低配黨照抄
8GB 顯存也能玩KV Cache 與 Block Cache 優(yōu)化清單低配黨照抄【免費下載鏈接】Minimax-H3-ComfyUI項目地址: https://ai.gitcode.com/hf_mirrors/Alissonerdx/Minimax-H3-ComfyUIMiniMax H3 開源后社區(qū)里最熱鬧的話題不是它 33B 的全模態(tài)架構而是這張卡到底能不能跑。目前流傳的結論相當分裂有人說 INT8 量化版 8GB 顯存就能出片實測 480P 視頻 5–10 分鐘有人說單張 24G 是門檻還有人在 12G 的 RTX 3060 上順利跑通了文生視頻。分歧的來源不是玄學而是視頻擴散模型的顯存消耗結構——它的瓶頸幾乎不在權重本身而在 KV Cache 與注意力激活值上。這篇文章以 Minimax-H3-ComfyUI 倉庫的實際工作流為底把 KV Cache 的消耗邏輯、Block Cache 的降顯存原理和一套可照抄的采樣參數(shù)組合拆開講清楚低配黨可以直接對照抄作業(yè)。一、KV Cache 瓶頸定位顯存到底被誰吃掉了先糾正一個直覺文生圖模型吃顯存的重頭是權重和 UNet/DiT 的中間激活而 H3 這類視頻模型完全不是這個量級。社區(qū)排障文章總結過它與文本/圖像模型在模型結構、顯存需求、推理鏈路三方面的本質差異——視頻生成把時間維度折疊進了 latent 序列序列長度直接決定注意力層的顯存天花板?？磦}庫工作流的模型補丁鏈就能明白設計者的算賬方式。LMS 工作流 在模型鏈上依次掛了MiniMaxH3SigmaShift、MiniMaxLowVRAMAttentionhead_chunks4、MiniMaxChunkFeedForward4 chunks、4352和SolAttnPatch其中 SolAttnPatch 的配置最能說明 KV Cache 的構成tau: 1.3, start_percent: 0.2, end_percent: 0.9, min_tokens: 4096, int8_qk: true, sink_conditioning: exact_kv_and_rows, int8_pv: true這套配置來自SolAttnPatch節(jié)點kijai/ComfyUI-SolAttn_triton它做的事情本質上是兩件稀疏注意力按 tau 閾值剪掉冗余 tokenmin_tokens4096兜底保證不過度裁剪和KV 量化int8_qk/int8_pv把 QK 與 PV 的緩存壓到 8bit。為什么要同時上這兩板斧因為視頻生成的 KV Cache 是按幀數(shù) × 每幀 token 數(shù)線性膨脹的。倉庫 README 里有一條被很多人忽略的硬約束H3 只支持17n 5的幀數(shù)5、22、39、56、73、90、107、124……。這看起來像某種訓練格式對齊本質上就是序列長度的檔位表——每多 17 幀attention 的序列就跳一個量級KV Cache 隨之線性上漲。8G 卡想穩(wěn)住先學會在這張表里挑小檔位而不是去猜分辨率。所以顯存被誰吃掉了的完整賬單是四筆權重量化版差異巨大見下文、KV Cache隨幀數(shù)與分辨率漲、注意力激活值單次前向的中間張量MiniMaxLowVRAMAttention的 head_chunks4 就是把它切成 4 塊分批算、VAE 與音頻分支。前兩筆是 8G 卡的生死線后兩筆是 12G–16G 卡的優(yōu)化空間。二、Block Cache 降顯存原理與開啟姿勢如果說 KV Cache 是省著用Block Cache 就是少算點。擴散模型在相鄰去噪步之間很多 Transformer block 的輸出其實高度相似——第 3 步和第 4 步中間層算出來的特征肉眼幾乎無差別。Block Cache 的思路就是把前幾步算好的 block 輸出緩存下來后續(xù)步數(shù)直接復用跳過整塊計算。社區(qū)實測報告里Block Cache 在 H3 上帶來的是顯存直降 10GB量級的收益并且能和 TeaCache 疊加。兩者的差別在粒度TeaCache 是 token 級緩存——只復用相似度高的那部分 token 的 block 輸出屬于部分跳過Block Cache 是整層整塊緩存——命中區(qū)間內的層直接引用歷史結果屬于整體跳過。前者省顯存的同時省時間后者主要換顯存兩者疊加時顯存曲線會更平緩。開啟姿勢分兩步。第一步是用 ComfyUI Manager 安裝 TeaCache / Block Cache 相關節(jié)點第二步是把它插進模型補丁鏈。倉庫工作流已經給出了標準串法——從 LMS 工作流 可以看到補丁是按SigmaShift → 低顯存注意力 → 分塊前饋 → SolAttn的順序串聯(lián)的這些低顯存節(jié)點在設計上就是可旁路啟停的開關顯存充裕時旁路掉、按原始圖跑顯存吃緊時逐個開啟。TeaCache / Block Cache 就加在這條鏈的末尾模型已經過量化與稀疏化處理之后把它當成一個額外的MODEL補丁節(jié)點接在采樣器之前即可。需要說明的是Block Cache / TeaCache 屬于社區(qū)插件生態(tài)本倉庫的工作流并未內置對應節(jié)點——倉庫 README 明確這些權重與工作流面向ref2va基座低顯存補丁由社區(qū)節(jié)點提供。這恰恰是它適合低配黨的原因顯存優(yōu)化和效果增強LoRA、潛空間放大是兩條正交的鏈可以分別疊加互不干擾。比如先在低顯存模式出 480P 初稿再用倉庫里的 LMS 銳化 LoRA 做二遍清晰度增強對比示例把跑得動和畫質夠拆成兩件事解決。三、采樣參數(shù)與 CPU Offload 組合拳8G–16G 顯存配置速查倉庫五份工作流是目前社區(qū)里少見的、真實跑通過的參數(shù)底稿直接拿來當速查表工作流SchedulerStepsDenoiseCFGSigmaShiftLMSsimple81112 / 3Style Transfersimple811–Head Swapbeta811–VFX Editsgm_uniform611–這幾組參數(shù)有明確的低顯存意圖逐條拆開說CFG 1H3 是蒸餾/無分類器引導訓練CFG1 意味著采樣時不需要額外跑一遍無條件分支——一次去噪只做一次前向顯存和時間雙省。這是視頻模型比文生圖模型在低配機上更友好的關鍵原因之一。6–8 步 simple/sgm_uniform/beta視頻模型步數(shù)直接換算成 KV Cache 的被訪問次數(shù)和總計算量6 步和 8 步的顯存峰值差不了太多但時間差近三成。VFX Edit 用 6 步是因為編輯類任務低步數(shù)欠擬合風險低從生成角度這是質量與資源的平衡點。SigmaShift (12, 3)把噪聲調度整體前移讓早期大噪聲步承擔更多去噪任務。它不直接省顯存但允許你在更少步數(shù)下保住畫面結構從而間接把 KV 訪問壓到最低。幀數(shù)檔位嚴格按 17n5 選幀。8G 卡先鎖 22 幀對應 480P 檔不要一上來就挑戰(zhàn) 56 幀。再看權重選擇。社區(qū)整理的 H3 權重譜系里BF16 全量約 66GNVFP4 約 34GINT8 壓縮版可到 21G 量級——這三檔直接決定了你的卡夠不夠放權重。實測反饋是INT8 版在 8GB 顯存設備可運行480P 生成耗時 5–10 分鐘RTX 3060 12G可跑文生視頻RTX 5060 Ti 16G 64G 內存被社區(qū)用來做完整部署實錄。在 16G 卡上 NVFP4 被反復驗證為同畫質更快是 50 系卡的默認選項。最后是 CPU Offload 的正確用法。Offload 不是萬能藥它的本質是把顯存不夠變成內存來湊代價是 PCIe 傳輸延遲。低配黨記住三條紀律只 offload 不參與當前計算的權重優(yōu)先用 ComfyUI 的--lowvram/--cpu-vae這類啟動級開關而不是把模型鏈上的節(jié)點隨意旁路系統(tǒng)內存要給足——社區(qū)實錄里 16G 顯存配 64G 內存Offload 才有緩沖余地8G 卡建議至少 32G 內存Offload 與采樣檔位聯(lián)動Offload 開后把幀數(shù)再降一檔56→39比硬扛高幀數(shù)然后 OOM 重跑快得多。OOM 的排查順序也按這個優(yōu)先級走先降幀數(shù)檔位 → 再降分辨率 → 再開 KV 量化與稀疏化 → 最后才動 Offload避免一上來就犧牲采樣質量。最終一張 8G–16G 速查表收尾顯存權重檔幀數(shù)分辨率采樣必開項8GBINT822480P8 步 / simpleLowVRAM 分塊、SolAttn 稀疏量化、TeaCache/Block Cache12GBINT8 / NVFP439480P–540P8 步SolAttn、Block Cache 可選16GBNVFP439–56540P–720P6–8 步SolAttn 低優(yōu)先級 OffloadMiniMax H3 給低配黨留下的空間比想象中大KV 可以量化、可以稀疏、可以分塊block 輸出可以緩存復用采樣步數(shù)可以壓到 6 步權重可以壓到 21G 檔——這些優(yōu)化在 倉庫工作流 里都能找到對應的開關和默認值。照抄這份清單8G 卡出的第一段視頻可能不算驚艷但它至少證明全模態(tài)視頻生成不再是 24G 顯存玩家的特權?！久赓M下載鏈接】Minimax-H3-ComfyUI項目地址: https://ai.gitcode.com/hf_mirrors/Alissonerdx/Minimax-H3-ComfyUI創(chuàng)作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考