显存不足与卡顿：OOM 的系统解法
生成到一半弹出 CUDA out of memory，或者进度条卡死、显存被吃满——这就是显存不足，也是 ComfyUI 里最常见的一类问题。先别急着换显卡：按下面顺序排查，大多数 OOM 都能在软件层面解决。第一次排错的话，建议先过一遍排错总览。
症状：先对号入座
CUDA out of memory / torch.OutOfMemoryError
先重启 ComfyUI 释放可能泄漏的显存，再用 --lowvram 启动，让文本编码器改在 CPU 上运行、降低显存占用。
进度条卡死、显存占满但迟迟不报错
先用 nvidia-smi 看清是谁在占显存，关掉浏览器、游戏和其他绘图程序，再试一次。
换了更大的模型后必崩
大模型权重直接超出了物理显存，调参数只能缓解，换量化版本或更小的 checkpoint 才是根治办法。
快速检查（60 秒）
- 用
nvidia-smi或任务管理器确认：没有浏览器、游戏、其他 AI 程序在抢显存。 - 重启 ComfyUI。异常中断后显存经常没被释放，重启是最快的“清零”手段。
- 把分辨率和批量（batch size）降到最低，先证明工作流本身能跑通。
- 数一数这次生成同时加载几个模型：checkpoint、ControlNet、放大模型、LoRA 都算。
做完还 OOM？进入正式排查。
排查步骤
第 1 步：降低单次生成的显存压力
OOM 多数是“一次要的东西太多”。先把分辨率降一档（如 512×768）、batch size 设为 1，跑通后再逐步加回去，找到你这台机器的临界点。再检查工作流里是否同时挂着多个大模型节点，用不到的先断开——每个驻留显存的模型都在抬高峰值。
第 2 步：用启动参数重新分配显存
ComfyUI 提供一组启动参数控制显存策略，按需组合：
--lowvram：低显存模式，让文本编码器改在 CPU 上运行，用速度换显存，最常用。--cpu：把计算放到内存和 CPU 上，极慢但几乎不会 OOM，适合应急验证工作流。--reserve-vram：预留一部分显存给系统或其他程序，避免显卡被榨干后整机卡死。--async-offload：生成过程中异步换入换出模型权重，进一步压低峰值占用（NVIDIA 显卡上默认已开启）。--cache-*系列：控制模型与节点结果的缓存回收策略，常用取值有--cache-none（少占内存/显存，但每个节点每次运行都重新执行）、--cache-lru 10（最多缓存 10 份节点结果）、--cache-classic（旧版激进缓存）。
Windows 便携包用户一般在启动脚本里追加这些参数：编辑便携包根目录的 run_nvidia_gpu.bat，在 .\python_embeded\python.exe -s ComfyUI\main.py --windows-standalone-build 这一行末尾追加即可。
第 3 步：换更小的模型或量化版本
参数调满还频繁 OOM，说明模型本体对你的显存就是太大。两条路：一是改用 GGUF 量化模型，低显存也能跑大模型，做法见GGUF 量化模型：低显存跑大模型；二是直接换更小的 checkpoint，先用小模型把流程跑顺。
注意区分：如果是模型一加载就报错（而不是生成中途 OOM），那多半不是显存问题，去看上一页模型加载失败。
升级条件：什么时候停止抠参数
满足任意一条，就别在软件层面继续耗了：
--lowvram+ 最低分辨率 + 量化模型仍然必现 OOM：显存物理上低于模型底线，考虑升级显卡，或接受--cpu慢速模式长期出图。- 显存没满却持续卡顿：问题可能不在显存，回到排错总览按日志定位。
- 报错不是 OOM，而是加载或架构类错误：转模型加载失败。
- 都对不上：带完整控制台日志去 ComfyUI 的 GitHub 仓库搜 "out of memory"，大概率有人踩过同一个坑。