8GB 显存也能玩：KV Cache 与 Block Cache 优化清单，低配党照抄

8GB 显存也能玩：KV Cache 与 Block Cache 优化清单，低配党照抄

【免费下载链接】Minimax-H3-ComfyUI项目地址: https://ai.gitcode.com/hf_mirrors/Alissonerdx/Minimax-H3-ComfyUI

MiniMax H3 开源后，社区里最热闹的话题不是它 33B 的全模态架构，而是"这张卡到底能不能跑"。目前流传的结论相当分裂：有人说 INT8 量化版 8GB 显存就能出片（实测 480P 视频 5–10 分钟），有人说单张 24G 是门槛，还有人在 12G 的 RTX 3060 上顺利跑通了文生视频。分歧的来源不是玄学，而是视频扩散模型的显存消耗结构——它的瓶颈几乎不在权重本身，而在 KV Cache 与注意力激活值上。这篇文章以 Minimax-H3-ComfyUI 仓库的实际工作流为底，把 KV Cache 的消耗逻辑、Block Cache 的降显存原理和一套可照抄的采样参数组合拆开讲清楚，低配党可以直接对照抄作业。

一、KV Cache 瓶颈定位：显存到底被谁吃掉了

先纠正一个直觉：文生图模型吃显存的重头是权重和 UNet/DiT 的中间激活，而 H3 这类视频模型完全不是这个量级。社区排障文章总结过它与文本/图像模型在"模型结构、显存需求、推理链路"三方面的本质差异——视频生成把时间维度折叠进了 latent 序列，序列长度直接决定注意力层的显存天花板。

看仓库工作流的模型补丁链就能明白设计者的算账方式。LMS 工作流 在模型链上依次挂了MiniMaxH3SigmaShift、MiniMaxLowVRAMAttention（head_chunks=4）、MiniMaxChunkFeedForward（4 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节点（kijai/ComfyUI-SolAttn_triton），它做的事情本质上是两件：稀疏注意力（按 tau 阈值剪掉冗余 token，min_tokens=4096兜底保证不过度裁剪）和KV 量化（int8_qk/int8_pv把 QK 与 PV 的缓存压到 8bit）。为什么要同时上这两板斧？因为视频生成的 KV Cache 是按"帧数 × 每帧 token 数"线性膨胀的。

仓库 README 里有一条被很多人忽略的硬约束：H3 只支持17n + 5的帧数（5、22、39、56、73、90、107、124……）。这看起来像某种训练格式对齐，本质上就是序列长度的档位表——每多 17 帧，attention 的序列就跳一个量级，KV Cache 随之线性上涨。8G 卡想稳住，先学会在这张表里挑小档位，而不是去猜分辨率。

所以"显存被谁吃掉了"的完整账单是四笔：权重（量化版差异巨大，见下文）、KV Cache（随帧数与分辨率涨）、注意力激活值（单次前向的中间张量，MiniMaxLowVRAMAttention的 head_chunks=4 就是把它切成 4 块分批算）、VAE 与音频分支。前两笔是 8G 卡的生死线，后两笔是 12G–16G 卡的优化空间。

二、Block Cache 降显存原理与开启姿势

如果说 KV Cache 是"省着用"，Block Cache 就是"少算点"。扩散模型在相邻去噪步之间，很多 Transformer block 的输出其实高度相似——第 3 步和第 4 步中间层算出来的特征，肉眼几乎无差别。Block Cache 的思路就是：把前几步算好的 block 输出缓存下来，后续步数直接复用，跳过整块计算。

社区实测报告里，Block Cache 在 H3 上带来的是"显存直降 10GB"量级的收益，并且能和 TeaCache 叠加。两者的差别在粒度：TeaCache 是 token 级缓存——只复用相似度高的那部分 token 的 block 输出，属于"部分跳过"；Block Cache 是整层整块缓存——命中区间内的层直接引用历史结果，属于"整体跳过"。前者省显存的同时省时间，后者主要换显存，两者叠加时显存曲线会更平缓。

开启姿势分两步。第一步是用 ComfyUI Manager 安装 TeaCache / Block Cache 相关节点；第二步是把它插进模型补丁链。仓库工作流已经给出了标准串法——从 LMS 工作流 可以看到补丁是按SigmaShift → 低显存注意力 → 分块前馈 → SolAttn的顺序串联的，这些低显存节点在设计上就是"可旁路启停"的开关：显存充裕时旁路掉、按原始图跑，显存吃紧时逐个开启。TeaCache / Block Cache 就加在这条链的末尾（模型已经过量化与稀疏化处理之后），把它当成一个额外的MODEL补丁节点接在采样器之前即可。

需要说明的是，Block Cache / TeaCache 属于社区插件生态，本仓库的工作流并未内置对应节点——仓库 README 明确这些权重与工作流面向ref2va基座，低显存补丁由社区节点提供。这恰恰是它适合低配党的原因：显存优化和效果增强（LoRA、潜空间放大）是两条正交的链，可以分别叠加，互不干扰。比如先在低显存模式出 480P 初稿，再用仓库里的 LMS 锐化 LoRA 做二遍清晰度增强（对比示例），把"跑得动"和"画质够"拆成两件事解决。

三、采样参数与 CPU Offload 组合拳：8G–16G 显存配置速查

仓库五份工作流是目前社区里少见的、真实跑通过的参数底稿，直接拿来当速查表：

这几组参数有明确的低显存意图，逐条拆开说：

• CFG = 1：H3 是蒸馏/无分类器引导训练，CFG=1 意味着采样时不需要额外跑一遍无条件分支——一次去噪只做一次前向，显存和时间双省。这是视频模型比文生图模型在低配机上更友好的关键原因之一。
• 6–8 步 + simple/sgm_uniform/beta：视频模型步数直接换算成 KV Cache 的"被访问次数"和总计算量，6 步和 8 步的显存峰值差不了太多，但时间差近三成。VFX Edit 用 6 步是因为编辑类任务低步数欠拟合风险低，从生成角度这是质量与资源的平衡点。
• SigmaShift (12, 3)：把噪声调度整体前移，让早期大噪声步承担更多去噪任务。它不直接省显存，但允许你在更少步数下保住画面结构，从而间接把 KV 访问压到最低。
• 帧数档位：严格按 17n+5 选帧。8G 卡先锁 22 帧（对应 480P 档），不要一上来就挑战 56 帧。

再看权重选择。社区整理的 H3 权重谱系里，BF16 全量约 66G，NVFP4 约 34G，INT8 压缩版可到 21G 量级——这三档直接决定了你的卡够不够放权重。实测反馈是：INT8 版在 8GB 显存设备可运行，480P 生成耗时 5–10 分钟；RTX 3060 12G可跑文生视频；RTX 5060 Ti 16G + 64G 内存被社区用来做完整部署实录。在 16G 卡上 NVFP4 被反复验证为"同画质更快"，是 50 系卡的默认选项。

最后是 CPU Offload 的正确用法。Offload 不是万能药，它的本质是把"显存不够"变成"内存来凑"，代价是 PCIe 传输延迟。低配党记住三条纪律：

1. 只 offload 不参与当前计算的权重，优先用 ComfyUI 的--lowvram/--cpu-vae这类启动级开关，而不是把模型链上的节点随意旁路；
2. 系统内存要给足——社区实录里 16G 显存配 64G 内存，Offload 才有缓冲余地，8G 卡建议至少 32G 内存；
3. Offload 与采样档位联动：Offload 开后把帧数再降一档（56→39），比硬扛高帧数然后 OOM 重跑快得多。OOM 的排查顺序也按这个优先级走：先降帧数档位 → 再降分辨率 → 再开 KV 量化与稀疏化 → 最后才动 Offload，避免一上来就牺牲采样质量。

最终一张 8G–16G 速查表收尾：

MiniMax H3 给低配党留下的空间比想象中大：KV 可以量化、可以稀疏、可以分块，block 输出可以缓存复用，采样步数可以压到 6 步，权重可以压到 21G 档——这些优化在 仓库工作流 里都能找到对应的开关和默认值。照抄这份清单，8G 卡出的第一段视频可能不算惊艳，但它至少证明：全模态视频生成，不再是 24G 显存玩家的特权。

【免费下载链接】Minimax-H3-ComfyUI项目地址: https://ai.gitcode.com/hf_mirrors/Alissonerdx/Minimax-H3-ComfyUI