显存优化不是万能药：4 步加速版在 8G 卡上翻车的那些瞬间

显存优化不是万能药：4 步加速版在 8G 卡上翻车的那些瞬间

"4 步出图""提速 8 到 10 倍""显存峰值降到 8GB，3090 就能跑"——过去几个月，围绕 Qwen-Image 加速版的社区文章几乎都用同一套话术：步数蒸馏 + LoRA + 量化，显存和速度一起解放。直到你真正把Qwen-Image-2.1-viggle-turbo拖进一台 8G 显存的消费卡，才会发现"能跑"和"跑得动"之间隔着一条比想象中宽得多的鸿沟。本文不写宣传稿，只做三件事：拆穿显存口径的数字游戏，划出 8G 卡上真实的性能分界线，再给一份基于仓库源码的自救手册。

显存峰值的口径差异：0.4GB 与 ≤10GB 到底在说什么

社区里流传最广的一组数据是"空闲 0.4GB / 生成峰值 ≤10GB"。这两个数字本身没错，但它们各自测量的对象完全不同，放在一起就会产生一种危险的错觉：仿佛 8G 卡随手就能跑。

先看"空闲 0.4GB"。这是 GPU 在没有任何生成任务时的显存占用量，通常来自 ComfyUI 前端、CUDA context 和刚加载的 VAE 等常驻对象。它既不包含 text encoder，也不包含 diffusion transformer，对"能不能跑"几乎没有任何参考价值——它只是告诉你"显卡还空着"。

再看"峰值 ≤10GB"。社区实测多基于RTX 3090（24GB），且往往只统计单步采样过程中transformer 的显存，或者说的是某一档量化后的权重文件体积。仓库 README 里的数据表就是最好的证据：单文件 transformer 里，int8_convrot 是 7.3GB，Q6_K 是 6.0GB，Q4_K_M 是 4.3GB——权重本身确实可以塞进 8G 卡。但"权重能放下"和"整条 pipeline 能跑"是两回事。

真实的全链路显存账本是这样的（文件大小均来自仓库）：

光是把这几样同时装进显存，就已经是 18GB 起步。这还没算采样过程中的激活值（activation）与 KV cache。仓库 README 写得非常诚实：官方 ComfyUI 工作流（int8 文件 + r128 LoRA + prompt enhancer）在 1248×832 分辨率下峰值约 26GB VRAM。26GB 是什么概念？比 3090 还高，直接奔着 4090 去。

所以"峰值 ≤10GB"的真实含义是：只算 diffusion model 单步峰值，且不算文本编码阶段。Qwen3-VL-8B 这个 8B 级 text encoder 本身就是一头吞显存的巨兽，它在生成前就要把提示词编码成序列，这一段的显存开销在 8G 卡上根本无法忽略。口径不统一，是所有"8G 卡也能跑"结论的第一个坑。

8G 卡实测：能跑与跑得动的分界线在哪

8G 卡上的真实处境，可以拆成三根链条逐段分析。

第一段：文本编码。Qwen3-VL-8B 的 int8 权重 9.4GB，单看这一项就已经超过 8G 显存。任何试图"整卡常驻"的方案在这里都会直接 OOM。社区文章里"序列化 CPU 卸载"被当成万能解药——它确实能解决 OOM，但代价是每轮生成要把 text encoder 权重从内存搬到显存再搬回去，显著拉长端到端时间。而仓库官方工作流还把 prompt enhancer（TextGenerate节点）默认打开，让 Qwen3-VL 再跑一遍 greedy decoding 重写提示词，这个阶段同样吃显存和时间。8G 卡上第一条自救规则就是：要么接受 CPU offload 的时延，要么关掉 enhancer。

第二段：扩散采样。这是步数蒸馏真正发力的地方。仓库的 viggle_turbo.py 给出了关键实现：CFG 被关掉了，BasicGuider+euler，每一步只有一次模型调用。6 步（v0.3）或 4 步（v0.1 的Qwen-Image-2.1-viggle-turbo-4step-lora-r64.safetensors）相比基座 40 步，减少的是步数和时间，而不是单步的激活值峰值。transformer 配置（transformer/config.json）显示这是一个 32 层、32 头、每头 128 维、上下文 4096 的 DiT 架构——在 1024×1024 输出下，latent 是 64×64 patch，token 数约 1 万级，激活值和 KV cache 会随分辨率二次方增长。这就是为什么 README 反复强调"1 MP 是甜点区，最高约 4 MP"。

第三段：LoRA 与量化档位的两难。8G 卡上你几乎必然要选单文件量化档。仓库给出了完整的 LPIPS 对比表（越低越接近原版）：

Q4_K_M 是唯一能"轻松"塞进 8G 卡的档位，但 README 的警告是Q4_K_M 漂移明显，96 个请求里有 23–29 个肉眼可辨，官方原话是"只有什么都放不下时才用它"。也就是说，在 8G 卡上你面临的不是"能不能跑"，而是"跑出来的是不是你要的图"——量化救显存，但画质的第一刀就砍在 8G 用户头上。

这还没完。仓库工作流默认走LoRA 未合并路径（ViggleTurboLora节点），源码注释说明得很清楚：把 LoRA 合并进 bf16 权重会丢掉约 30% 的更新量，合并进 int8 权重则会引入数倍于 LoRA 本身的量化噪声，所以官方选择在运行时做y = Wx + BAx的侧分支计算——代价是每步多花 10–25% 时间。步数省下来的时间，一部分又被"为了保住画质而不合并 LoRA"还了回去。这就是"显存优化不是万能药"的第二个注脚：优化往往不是免费的，而是把成本从显存转移到了时间或画质。

CPU 卸载、量化与批大小的自救手册

如果你坚持要在 8G 卡上跑这套加速版，以下操作按收益排序，每一条都有仓库源码或文档依据。

1. 文本编码器是第一个要处理的对象。int8 的 Qwen3-VL-8B 有 9.4GB，无论如何不能和扩散模型同驻。最稳妥的做法是接受官方架构的现实：文本编码阶段用 CPU offload（或换用更小的编码器），采样阶段再把扩散模型放回显存。同时把工作流里的 prompt enhancer 关掉——TextGenerate节点在 NVIDIA 驱动版本过旧时还会直接报 CUDA driver error（README.md 的 Troubleshooting 部分），在 8G 卡上它只会让本就不宽裕的显存雪上加霜。

2. 扩散模型档位按"能接受多大画质损失"而不是"能塞进多大显存"来选。从仓库的 LPIPS 表看，Q8_0 和 int8 之间差距很小（0.051 vs 0.057），但体积差了 0.4GB；从 Q6_K 往下开始，质量损失加速变陡，到 Q4_K_M 已经是"明显可辨"的级别。8G 卡如果一定要在 Q6_K（6.0GB）和 Q5_K_M（5.1GB）之间选，先想清楚你的激活值预算还剩多少——权重体积永远只是显存账单的一半。

3. 把分辨率焊死在 1 MP 附近。仓库 README 明说"1 MP 是甜点区，最高约 4 MP 可用"。对 8G 卡来说，4 MP 只是"不报错"的上限，激活值和 KV cache 翻倍增长会把采样峰值直接顶爆。工作流里EmptyLatentImage+ 分辨率选择器默认就是 1 MP、32 的倍数（Qwen-Image-2.1-viggle-turbo-t2i.json），这个默认值不是随便定的。

4. 批大小必须为 1。加速版蒸馏掉的是 CFG（一步只跑一次模型），如果为了吞吐把 batch 开大，激活值和 KV cache 会随 batch 线性放大，8G 卡的预算瞬间归零。批处理是服务器的事，不是 8G 卡的事。

5. 别在采样中途改 sigma 节点。仓库对规则写得很死：只能在高噪声端加减步数，必须保留0.875, 0.75, 0.5, 0.25四个低噪声节点；换 KSampler 默认调度器、加 CFG、写 negative prompt 都不会让 6 步模型变好，只会更慢或更糊。scheduler 配置（scheduler/scheduler_config.json）里shift_terminal被从基座的 0.02 改成null——这是蒸馏模型赖以成立的细节，改回 0.02 会直接毁掉最后一步。

最后：认清加速版的能力边界

显存优化救不了的东西，仓库 README 的 Known limitations 已经替你说完了：多参考图合成、换脸、强约束指令编辑仍会翻车（重影、身份漂移）；小字和长文字渲染比基座更容易糊，9 步模式能缓解但"不是总能";v0.3 的细纹理比 v0.2.1 更软。更重要的是，Viggle 自己说"6 步已接近这个 LoRA 的能力上限，再往下只能靠加步数换质量"——加速是有天花板的，显存优化只是把天花板从 24G 挪到 8G，并没有把它掀掉。

8G 卡用户真正该记住的结论只有一条：0.4GB 空闲是假象，26GB 峰值才是官方文档里的真实数字；加速版替你省下了 34 步的时间，却省不掉 text encoder 和激活值这两块显存大头。要在 8G 卡上"跑得动"，靠的不是某一招，而是"CPU 卸载文本编码 + Q6_K 级量化 + 1 MP 分辨率 + batch 1 + 关 enhancer"这一整套组合拳。任何只报峰值、不报口径的显存宣传，都值得你在动手部署前多问一句：它算 text encoder 了吗？算激活值了吗？算的是 1024 还是 2048？

参考图与工作流：仓库自带的编辑示例图 cat.webp 与 woman2.webp 放在comfyui/input/，连同 t2i / edit 两套工作流 JSON 一起，是 8G 卡上验证上述所有结论的最低成本起点。