ComfyUI 显存与速度调优：启动参数、精度选项、分块解码与测量方法

显存不够最常见的两种反应都不划算：一种是直接放弃，另一种是到处抄「神秘加速参数」。正确的顺序是三步：先测量，再改精度与参数，最后改出图策略（降分辨率、分块解码、两步放大）。这篇把每一步拆成可执行的命令和参数名；所有「可跑」判断都标了是经验起点，请用第一节的方法在你自己的机器上复核，我在这里不编造跑分数字。

一、先学会测量：三个数字决定一切

1.1 单次耗时（改动前后对比的基准）

跑完一次任务后，ComfyUI 控制台会打印一行形如：

Prompt executed in 12.34 seconds

注意两点：第一次运行包含模型加载，明显偏慢，要用同一工作流连跑两次、取第二次的数值；显存不足时程序会在显存与内存之间反复换页，这个数字会成倍上涨，所以耗时也是判断「有没有触发低显存路径」的间接指标。

1.2 显存峰值（判断会不会 OOM 的关键）

开一个命令行窗口，运行下面这条，让 memory.used 每秒刷新一次，再切回 ComfyUI 出图，盯着数值的最高点：

nvidia-smi --query-gpu=memory.used,memory.total,utilization.gpu --format=csv -l 1

按 Ctrl + C 停止刷新。也可以用 nvidia-smi dmon -s u -d 1，或者最简单的：任务管理器 → 性能 → GPU → 「专用 GPU 内存」曲线。判断标准：

• 峰值稳定在总显存 80% 以内：安全，可以尝试提分辨率或批量。
• 峰值贴着 95% 且耗时忽高忽低：随时会 OOM，先降一档再谈速度。
• 还不够直观就再看控制台：显存紧张时日志会打印模型的加载/卸载方式，出现「未能完整放入显存、部分在内存里运行」之类的提示，就说明已经到了需要调参的区间。

1.3 记录表：一次只改一个变量

固定模型、提示词、种子、步数，只改一个参数，每项跑 3 次取中位数，填进下面这张表。这是后面所有判断的依据：

二、启动参数：什么时候用哪一个

以下参数名与官方说明一致；官方明确写了一句关键前提：在启用动态显存管理的情况下，--lowvram 不产生效果，所以不要把它当万能开关，先测再加。

写参数的两种方式——便携版用记事本编辑启动脚本，源码安装直接跟在命令后面：

# 便携版：编辑 run_nvidia_gpu.bat，把参数加在最后
.\python_embeded\python.exe -s ComfyUI\main.py --windows-standalone-build --lowvram --reserve-vram 1

# 源码 + venv 安装
python main.py --lowvram --reserve-vram 1

三、精度选项：先默认，再 fp8，最后才动 VAE

决策顺序建议：默认 → 降分辨率或批量 → 换 bf16/fp16 → UNet 上 fp8 → 文本编码器上 fp8 → cpu-vae。VAE 相关参数放在最后，因为它们直接影响出图正确性（黑图、颜色偏移），排查成本最高。

四、注意力实现：SDP 是默认，xformers 已经不是必需品

• --use-pytorch-cross-attention：使用 PyTorch 2.0 的交叉注意力实现。新版 ComfyUI 的依赖清单里已经不含 xformers，默认走的就是 PyTorch 原生注意力，多数情况下你不需要装任何额外加速库。
• --disable-xformers：显式关闭 xformers。如果装过 xformers 又怀疑它导致报错或画质问题，用这个参数对照一次即可。
• --use-flash-attention / --use-sage-attention：需要另行安装对应库，且有显卡架构与版本要求；装上后是提速还是拖慢，取决于模型、分辨率与版本，必须实测。
• 「No module named xformers」这类报错基本来自老插件，不是 ComfyUI 核心；按报错速查表处理，不要为了一个插件把整个环境折腾坏。

五、分块解码（tiled VAE）与两步出图

显存主要爆在三个时刻：加载权重、采样时的注意力计算、VAE 解码。最后一个是高分辨率玩家最容易忽略的。对策有两种：

1. 用 VAE Decode (Tiled) 节点替换普通 VAE Decode。它是官方核心节点（显示名 VAE Decode (Tiled)），参数：tile_size 默认 512、overlap 默认 64，视频 VAE 另有 temporal_size/temporal_overlap。tile_size 越小越省显存但越慢，出现接缝时把 overlap 调大。补充一句：当普通 VAE Decode 因显存不足失败时，新版 ComfyUI 会自动改用分块实现重试——所以如果你在日志里看到自动重试，说明已经到了该换节点的边缘。
2. 改出图策略：低分辨率出图 + 放大。先用 512（SD1.5）或 1024（SDXL / Flux）把构图定下来，再用放大模型或二次采样放大。这条路线在 8G～12G 显卡上比重试一次性出大图的时间成本低得多。

六、按显存档位的经验起点表

先看这条声明：下表是「起点」而非保证值，用于帮你少试几次错。含义约定：可跑 = 该档基础分辨率、批量 1、常规 20～30 步，能稳定出图；需调参 = 加上表中列出的参数后可用；需分块 = 还要配合 tiled 解码或显著降分辨率。所有格子都请用第一节的测量表复核。

如果连基准组都跑不起来，检查顺序是：分辨率是否超出模型训练范围 → 是否叠了多个 LoRA / 插件节点 → 是否同时开了游戏或浏览器占用显存 → 再考虑降精度。排查细节见报错速查表的「CUDA out of memory」条目。

七、采样器与步数：用你自己的表说话

网上「某采样器快 30%」的说法几乎一定过期——采样器实现、调度器、显卡架构、步数都会改变结论。正确做法是固定其他变量，只换采样器与步数，把耗时填进表里：

几条可用于起步的经验区间（再次强调：经验值，不是跑分）：

• 步数：SD1.5 / SDXL 常规在 20～30 步，超过 40 步的收益通常很小，耗时却线性上涨。
• CFG：多数 SD 模型在 5～8 之间（7 是常见起点）；Flux 这类引导式模型走的是独立 guidance 参数，CFG 用 1。
• 采样器选择：想快用 euler 系；要细节用 dpmpp_2m + karras；具体差异在你自己的表里对比，别照抄榜单。
• 先固定 seed 再对比：不固定种子的「对比」没有意义。

八、显存不够时的处理顺序（速查）

1. 关掉浏览器多余标签、聊天软件、录屏软件，用 nvidia-smi 确认没有别的程序占着显存。
2. 降分辨率（面积减半，显存明显下降），或把 batch_size 降到 1。
3. 卸掉工作流里没用到的 LoRA、ControlNet、放大模型节点。
4. 加 --lowvram；仍不够再加 --novram。
5. UNet 换 fp8 存储；大模型再给文本编码器也换 fp8。
6. 出现随机性 OOM（同一工作流时好时坏）时加 --disable-smart-memory，并给系统留出 --reserve-vram 1 或 2。
7. 解码阶段爆显存：换 VAE Decode (Tiled)，或临时用 --cpu-vae。
8. 还是不行就改策略：低分辨率出图 + 放大模型/二次采样，把一次性大图的显存需求拆成两次。

九、不改精度也能省显存：工作流层面的五个做法

• 尺寸取 8 的倍数：宽高都用 8 的倍数（如 1024×1024、832×1216），既避免报错，也不会为不完整的潜空间块多付显存。
• 潜空间放大代替一次性大图：先出基础分辨率（SD1.5 用 512 档、SDXL / Flux 用 1024 档），再接潜空间放大或放大模型做二次采样。峰值显存按「小图 + 放大」结算，比重试大图低一档。
• 减少同时挂载的 ControlNet 数量：每个 ControlNet 都要额外加载一份模型与条件，叠两个以上显存占用明显上涨；能用合并版（Union）就别串多个。
• 批量优先用队列，而不是加大 batch_size：队列逐张执行，峰值显存与单张一致；batch_size 是线性叠加。无人值守跑图时队列更不容易中途 OOM。
• 关掉用不上的预览与多余节点：确认工作流里没有残留的高清预览节点，采样预览用 --preview-method none 关闭（默认即关闭）。

最后一条经验：如果每个方案都要靠降精度才能勉强跑起来，说明模型选得比显卡大一档。换成同架构的小体积权重（已发布的量化版本、更小的蒸馏/加速版本），画质与稳定性通常都好于把参数抠到极限。模型世代与替代思路见工作流与模型管理。

下一步：把测量表跑起来，再回到工作流与模型管理梳理节点与批量出图的写法；任何一步出现报错，去报错速查表；环境还没装，先读安装篇。所有数值请以你机器上的实测与官方最新文档为准。