先给结论：显存优化有四条互不相同的路 —— 降精度（fp8）、换权重格式与低比特量化（GGUF）、减少采样步数（蒸馏）、卸载与分块（动态显存 / Tiled VAE）。它们省的不是同一份资源，可以叠加，代价也完全不同；把它们统称为「量化」是排查 OOM 时最容易走偏的地方。
这篇文章按「省什么、代价是什么、什么顺序试」来组织，不列一刀切的显卡推荐表，因为同一个模型在不同实现下的占用差异很大。
事实口径：本文核对时间为 2026 年 11 月 10 日。精度与字节数换算、dtype 选择逻辑依据公开的 ComfyUI 实现与文档；FP8/NVFP4 提速与省显存数字来自 BFL 官方博客，并注明是 RTX 5080/5090、1024×1024 文生图的厂商自测条件。第三方节点的行为随版本变化，请以你所用版本的官方节点说明为准。
先把显存花在哪儿拆开
一次出图的峰值显存不是一个数，而是几块叠加：去噪网络权重、文本编码器、VAE 编解码、以及随分辨率平方增长的中间张量。只盯着「模型文件多大」会漏掉后三项，这也是为什么有人把模型压到 6 GB 后依然 OOM。
| 组成部分 | 随什么增长 | 常见优化 |
|---|---|---|
| 去噪网络权重 | 参数量 × 每参数字节数 | fp8 / GGUF 低比特 |
| 文本编码器 | 编码器数量与精度 | 移除 T5、用 fp8 版编码器 |
| VAE 编解码 | 像素面积 | Tiled VAE 分块 |
| 中间张量 | 面积、batch size、注意力实现 | 降分辨率、batch size 设 1 |
这也解释了为什么降分辨率通常是第一招：面积是平方关系，砍一半边长能省下远不止一半的中间张量。这条在故障排查的 OOM 顺序里也排第一。
降精度：fp16 / bf16 → fp8
按最朴素的换算，fp16/bf16 每个参数占 2 字节，fp8 占 1 字节，一个 2B 模型的权重从约 4 GB 降到约 2 GB；公开的 ComfyUI 实现里还列了 Q8_0 约 8 bit、Q5_0 约 5 bit、Q4_0 约 4 bit 的 GGUF 档位，逐级再降。
但 fp8 计算需要硬件支持：较新的 NVIDIA（Ampere 及以上）与 AMD RDNA3+ 有原生 fp8 路径，其他平台可能走软件模拟，速度收益会打折甚至变慢。ComfyUI 在加载时会依据权重类型、可用显存、平台能力与命令行参数自动选择计算 dtype，所以「我放了 fp8 文件」和「实际按 fp8 算」并不总是一回事。
BFL 官方给过一个带条件的数据：在 RTX 5080/5090、1024×1024 文生图的自测里，FP8 版本最多快 1.6 倍、少用 40% 显存，NVFP4 最多快 2.7 倍、少用 55%。厂商同时明确「Same licenses apply」—— 量化改变体积，不改变授权，这一点在许可证那篇里单独讲过。
GGUF：保持量化权重，按需解压
GGUF 是存放已量化权重的格式，设计重点之一是便于从 CPU 内存侧推理；权重在使用时才按需还原，配合低显存时的权重补丁机制，可以避免把整个模型一次性铺进显存。代价是权重重建本身有开销，低比特档位（Q4 一类）在颜色、细密纹理和文字上更容易出现可见退化。
要注意工具链差异：不同 ComfyUI 版本对 GGUF 的内置支持程度不同，很多教程仍要求安装 city96/ComfyUI-GGUF 这类自定义节点，并把加载节点换成对应的 Unet Loader。第三方节点更新频繁、LoRA 支持程度不一，照抄半年前的教程容易对不上。核对时以你当前版本的官方节点说明为准，而不是以博客发布日期为准。
蒸馏减少的是步数，不是权重体积
三个可核对的例子：Z-Image-Turbo 官方写 8 NFEs 且 guidance 设为 0；FLUX.1 [schnell] 是少步数的蒸馏型号；BFL 官方说明 [klein] 9B 被 step-distilled 到 4 步。它们的共同点是把「每张图跑几次前向」压下来，每一步的计算量和权重占用并没有变小。
而且关闭 CFG 会再省一次前向：常规 CFG 大于 1 时每步要做条件与无条件两次预测，Turbo 类模型把 guidance 设成 0 后每步只算一次。所以评估速度时，要把「步数 × 每步前向次数 × 每步成本」一起算，只比步数会得出错误结论。CFG 本身的机制写在负面提示词与 CFG里。
卸载与分块：不降质量，但会变慢
动态显存管理会在显存不足时把部分权重卸载到内存，并按需要搬回；Tiled VAE 则把高分辨率图切成带重叠的区块分别解码，避开 VAE 阶段的峰值。两者都不改变权重精度，代价是速度。
这里有个版本坑：较新的 ComfyUI 版本默认启用了动态显存策略，旧教程里的 --lowvram 参数在这种模式下未必按你以为的方式生效。遇到「加了参数却没变化」，先查当前版本文档，别急着叠加更多启动参数。
推荐的排查顺序
- 把 batch size 降到 1、砍分辨率（收益最大，代价可控）。
- 关掉暂时用不到的 ControlNet / 额外 LoRA，确认没有旧进程占着显存。
- 换 fp8 权重或让加载器按 fp8 计算；核对日志里实际生效的 dtype。
- 显存仍不够，再评估移除 T5 类文本编码器（会削弱长提示词与文字渲染）。
- 最后才考虑 GGUF 低比特、蒸馏小模型或 Tiled VAE，并接受相应画质/速度代价。
顺序的意义在于：越靠前的动作越可逆、越不容易伤画质。一上来就换 Q4 量化，往往既丢了细节又没解决真正的瓶颈（比如 2048×2048 的 VAE 峰值）。
小结
把四条路分开记：降精度省每参数字节、低比特格式省权重占用并允许卸载、蒸馏省步数、分块省峰值张量。任何一句「换量化就好了」都应该先问一句：这次 OOM 到底发生在哪一步。架构层面的差别可以接着看DiT 与 U-Net。
评论 0