ComfyUI Low VRAM Optimization：低显存性能优化总入口
ComfyUI low VRAM optimization 低显存总入口，串联 8GB VRAM settings、CUDA out of memory、SDXL 8GB VRAM、ControlNet low VRAM，按分辨率、batch、模型家族、ControlNet、upscale 和启动模式逐层降载。
一句话结论
低显存优化不是一个单独参数，而是一套性能专题链路：先选 4GB/6GB/8GB 的安全基线，再按 8GB VRAM settings、CUDA out of memory、SDXL 8GB VRAM、ControlNet low VRAM、upscale 和 low VRAM mode 分支处理。
这篇解决什么问题
低显存机器也能跑 ComfyUI，但要接受边界：降低尺寸、减少并行、少用重插件，优先跑通再提画质。
如果你搜索的是 ComfyUI low VRAM optimization、ComfyUI low VRAM mode、ComfyUI 8GB VRAM settings、ComfyUI CUDA out of memory、ComfyUI SDXL 8GB VRAM 或 ControlNet low VRAM，本页是总入口。它不是只给一个“降低分辨率”的答案，而是把低显存问题拆成可执行路径；如果你还没确定基础模型，可以先从 完整模型选择指南 开始。
如果你是第一次接触 ComfyUI，建议不要跳步。先把最小流程跑通，再安装插件、导入复杂工作流或追求高分辨率。ComfyUI 的大多数问题都可以通过“看控制台日志、确认目录、确认版本、降低参数”这四件事定位。
适合谁
- 刚开始使用 ComfyUI，需要一篇可以照着做的教程。
- 已经遇到相关报错，但不知道该先检查哪一步。
- 想把安装、模型、插件、工作流整理成可复查流程的用户。
准备条件
- 知道显存容量。
- 能修改工作流尺寸和 batch。
低显存专题导航
| 你现在的问题 | 先看哪一页 | 本页给你的判断 |
|---|---|---|
| 我是 8GB 显卡，想要一套稳定起步参数 | 8GB 显存设置 | 先定 batch、resolution、SD1.5/SDXL 边界，再谈画质 |
已经报 CUDA out of memory | CUDA out of memory 排查 | OOM 是运行阶段显存峰值问题，按错误处理，不要先重装 |
| 想知道 SDXL 在 8GB 上能不能跑 | 8GB 显存设置 和 SD1.5 和 SDXL 对比 | SDXL 可以试，但要小图、batch 1、少分支 |
| ControlNet / IPAdapter 一开就爆显存 | 本页的 ControlNet low VRAM 清单 | 先只开一个控制分支，确认成功再逐个增加 |
| 文生图能跑，放大就失败 | 本页的 staged upscale 清单 | 把生成和放大拆成两个工作流 |
不知道要不要开 --lowvram | 本页的 low VRAM mode 顺序 | 先降工作流，再改启动模式 |
这张参数卡是低显存排查的起点，不保证所有工作流都能运行；如果仍然 OOM，继续降低分辨率或换 SD1.5。
低显存机器最重要的是先跑通：batch 1、小尺寸、少插件。上图读取的是本机 ComfyUI 的显存信息，并把新手最该先改的参数放在右侧。确认能生成后，再逐步提高分辨率或加 ControlNet。
不要一次同时改模型、尺寸、采样步数、ControlNet 和放大器。低显存排错要“一次只改一个参数”：先把尺寸降下来，再关掉额外插件，最后才考虑换模型。
操作步骤
- 4GB：优先 SD1.5、512×512、batch 1，少用 ControlNet。
- 6GB：SD1.5 比较舒服，可尝试 512×768 或小幅高清修复。
- 8GB：可入门 SDXL，但复杂工作流需要降尺寸或关插件。
- 关闭其他 GPU 程序，尤其浏览器视频、游戏、其他 AI 服务。
- 使用 —lowvram 或 —normalvram 测试稳定性。
- 放大单独做，避免文生图和高倍放大同一阶段爆显存。
低显存分流决策树
- 先看显存容量：4GB/6GB 从 SD1.5 小图起步；8GB 用户先打开 8GB 显存设置 对齐参数。
- 再看失败阶段：加载模型就失败，优先检查模型家族；点击 Queue 后失败，优先按 CUDA out of memory 排查峰值。
- 再看模型家族：SD1.5 成功但 SDXL 失败时，切到 SD1.5 和 SDXL 对比 判断是否该降回 SD1.5。
- 再看控制分支：一开 ControlNet、IPAdapter 或 Reference 就失败时，切到 ControlNet 低显存指南 拆控制模型。
- 最后看放大和后处理：文生图能跑、upscale 失败时，把放大拆成第二个工作流，不要继续加启动参数。
按场景选择下一步
| 场景 | 最稳下一步 | 不要先做什么 |
|---|---|---|
| 还没开始，只知道自己是 8GB 显卡 | 先用 8GB 显存设置 建立预运行参数 | 不要直接导入 SDXL + 多 ControlNet + upscale 工作流 |
| SD1.5 能跑，SDXL 一跑就 OOM | 回到 SD1.5 和 SDXL 对比 判断模型家族边界 | 不要用重装 ComfyUI 代替降载 |
Queue 后终端报 CUDA out of memory | 打开 CUDA OOM 中枢 按报错节点处理 | 不要随机改 CUDA、驱动或 Python 版本 |
| 一开 ControlNet/IPAdapter 就失败 | 打开 ControlNet 低显存指南 只保留一个控制分支 | 不要同时测试多个控制模型 |
| 文生图成功，放大阶段失败 | 把 upscale 拆到第二个工作流 | 不要在主生成链路里叠 2x/4x 放大 |
| Flux 工作流跑不动 | 先回到 Flux / SDXL / SD1.5 选择表 | 不要把 Flux 当成 SDXL 的简单替代 |
这个表是本站显存集群的入口地图。你不需要每次从头排查，只要先判断“还没开始、已经 OOM、模型太重、控制分支太多、还是放大阶段失败”，就能进入对应页面。
4GB / 6GB / 8GB 安全基线
| 显存 | 推荐起点 | 模型路线 | 不要先做什么 |
|---|---|---|---|
| 4GB | SD1.5、512x512、batch 1 | 小模型、少 LoRA、无放大 | 不要直接跑 SDXL、Flux、视频、多个 ControlNet |
| 6GB | SD1.5、512x768 或 768x512、batch 1 | 可以小幅尝试高清修复 | 不要把 upscale 和文生图塞进同一阶段 |
| 8GB | SD1.5 稳定；SDXL 从 768x768 起步 | 参考 8GB 显存设置 | 不要同时开 SDXL、多 ControlNet、IPAdapter、upscale |
| 12GB+ | SDXL 更舒服，但仍要控制分支 | 可以逐步加放大和控制节点 | 不要误以为显存大就不用看终端报错 |
低显存优化的顺序固定：先 batch 1，再降 resolution，再关 upscale，再关 ControlNet/IPAdapter，再换模型家族，最后才考虑启动参数。8GB 显卡可以直接参考 这套 ComfyUI 参数；如果已经出现 CUDA out of memory，建议先按 排查清单 定位原因。这样做可以避免把“模型太大”“图太大”“控制分支太多”“显存碎片”混成一个问题。
ControlNet low VRAM 清单
ControlNet、IPAdapter、Reference、Depth、OpenPose 这类节点很容易让低显存工作流从“能跑”变成“Queue 后 OOM”。使用 ControlNet 时，还需要单独考虑 控制模型带来的显存开销。处理顺序如下：
- 先关闭所有 ControlNet / IPAdapter，只保留 checkpoint、prompt、KSampler、VAE Decode。
- 确认基础文生图能连续成功 3 次。
- 只打开 1 个 ControlNet，保持 batch 1 和低分辨率。
- 如果成功，再增加第二个控制分支；如果失败，先不要换 CUDA，先降低输入图尺寸或 control strength。
- SDXL + 多 ControlNet + upscale 对 8GB 显卡通常过重，优先拆阶段。
- 如果终端出现
CUDA out of memory，切到 CUDA out of memory 排查 按 OOM 错误处理。
SDXL 8GB 与模型家族选择
SDXL 在 8GB 上不是完全不能用，但它不是最稳的新手起点。低显存用户更适合先用 SD1.5 建立“安装健康、模型可加载、工作流能跑通”的基线，然后再试 SDXL。
- 如果 SD1.5 小图也 OOM，优先排查显存占用、启动方式和后台程序。
- 如果 SD1.5 正常、SDXL OOM，说明问题大概率是工作流重量，不是 ComfyUI 损坏。
- 如果 SDXL + LoRA 报
shape mismatch，那是模型家族兼容问题，不是低显存问题。 - 如果 SDXL 只能在重启后跑一次，说明边界太紧，需要进一步降 resolution 或拆 upscale。
如果优化后仍然吃力，可能需要重新比较 SD1.5 和 SDXL 的显存需求，不要只靠启动参数硬撑。
Staged upscale：把放大拆出去
低显存机器最常见的错误，是在一个图里同时完成生成、高清修复、2x/4x 放大、脸部修复和保存多张图。更稳的做法是：
- 第一阶段只生成基础图，尺寸保守，batch 1。
- 保存成功结果。
- 第二阶段重新加载图片，只做 upscale 或局部修复。
- 第三阶段再做脸部修复、细节修复或格式输出。
这种分阶段方法会慢一点，但更容易定位问题。文生图能跑、放大失败时，不要重装模型；先把 upscale 从主工作流里拆出来。
low VRAM mode 使用顺序
--lowvram 和 --normalvram 是辅助工具，不是替代合理工作流的万能开关。推荐顺序：
- 默认启动方式 + batch 1 + 低分辨率。
- 仍失败时，关闭 upscale、ControlNet、IPAdapter、视频节点。
- 仍失败时，尝试
--normalvram。 - 显存非常紧时，再尝试
--lowvram。 - 每次只改一个启动参数，重启 ComfyUI 后用同一个小工作流复测。
如果开了 low VRAM mode 以后速度变慢，这是正常的；它的目标是让工作流更可能跑完，不是让生成更快。
判断问题属于哪一类
- 如果页面打不开，先看启动窗口是否还在运行，以及端口是否正确。
- 如果节点是红色，优先处理缺失自定义节点或插件加载失败。
- 如果模型下拉框为空，优先检查模型类型和放置目录。
- 如果开始生成后失败，优先看显存、模型版本和具体报错节点。
- 如果更新后才坏，优先考虑插件版本不兼容，必要时回退或临时移除插件。
常见错误
- 低显存还使用多个 ControlNet + IPAdapter + SDXL。
- batch_size 大于 1。
- 误以为虚拟内存能替代显存。
验证是否成功
- 连续生成 3 张不 OOM。
nvidia-smi峰值稳定在显存上限以内。- 能说清楚当前问题属于 8GB 预运行设置、CUDA OOM、模型家族、ControlNet 分支还是 upscale 阶段。
- 每次只加回一个重模块：先提高 resolution，再加 LoRA，再加 ControlNet，最后才做 upscale。
- 如果换到 SDXL 或 Flux，会重新检查显存基线，而不是沿用 SD1.5 的复杂工作流。
如果仍然失败
请把控制台里从 Traceback 开始到最后一行的完整报错保存下来，同时记录：ComfyUI 版本、启动方式、显卡型号、显存容量、使用的模型文件名、刚安装过哪些插件。不要只截网页上的红色提示，因为真正有用的信息通常在启动窗口里。
如果你在本站提交反馈，登录状态下会自动附带 user_id，方便后续追踪同一个用户遇到的连续问题；未登录也可以匿名提交。
下一步推荐
- 8GB 参数基线：ComfyUI 8GB 显存设置
- 已经 OOM：CUDA out of memory 排查
- 模型取舍：SD1.5 和 SDXL 对比
- ControlNet 分支：ControlNet 低显存指南
- 新手路线：/topics/comfyui-beginner/
- 报错排查：/topics/comfyui-errors/
- 模型基础：/topics/model-basics/
- 插件安装：/topics/must-have-plugins/
更新记录
- 2026-05-12：扩写为正式教程，补充操作步骤、常见错误和验证清单。