CUDA out of memory 解决：ComfyUI 显存不足处理清单
ComfyUI CUDA out of memory 英文搜索入口和显存不足修复清单，覆盖 8GB VRAM ComfyUI settings、low VRAM mode、降低 resolution、batch size、upscale、ControlNet 和模型体积。
一句话结论
CUDA out of memory 是显存错误诊断中枢，不是单一参数问题。先把工作流降到能跑：batch 1、降低 resolution、关闭 upscale、只留一个 ControlNet/IPAdapter、必要时从 SDXL/Flux 回退到 SD1.5；跑通后再按顺序加回质量和控制模块。
这篇解决什么问题
CUDA out of memory 表示显存不够，不是内存条不够。解决思路是减少显存占用：尺寸、batch、模型、插件、后台进程。
如果你搜索的是 ComfyUI CUDA out of memory、8GB VRAM ComfyUI settings、ComfyUI low VRAM mode、reduce resolution batch size upscale ControlNet，本页就是显存排查入口。它不把 OOM 当成一个模糊报错，而是按“基础参数 → 模型家族 → 附加节点 → 放大阶段 → 启动模式 → 后台占用”逐层降载。
如果你还没有遇到明确的 OOM 报错，只是在为 8GB 显卡找一套稳定起步参数，先看独立参数页：8GB 显存 ComfyUI 设置。如果你想系统降低显存占用，可以回到 低显存优化总览 建立长期基线。
这页同时承接三个相关入口：8GB 参数页负责“跑之前怎么设”，SD1.5 和 SDXL 对比 负责“模型家族是不是太重”，ControlNet 模型选择 负责“ControlNet 分支是不是叠太多”。只要最后报错是 CUDA out of memory，都回到本页按同一套顺序降载。
如果你是第一次接触 ComfyUI，建议不要跳步。先把最小流程跑通，再安装插件、导入复杂工作流或追求高分辨率。ComfyUI 的大多数问题都可以通过“看控制台日志、确认目录、确认版本、降低参数”这四件事定位。
30 秒显存止血清单
| 优先级 | 立刻改什么 | 推荐值 | 为什么有效 |
|---|---|---|---|
| 1 | batch_size | 1 | batch 是最容易被忽略的显存倍增器，先归零风险最低 |
| 2 | 分辨率 | SD1.5 先用 512x512 或 512x768；SDXL 先用 768x768 | latent 尺寸越大，采样阶段显存增长越明显 |
| 3 | 模型家族 | 8GB 显存优先 SD1.5，谨慎 SDXL，暂缓 Flux/视频工作流 | 大模型和复杂 loader 会更早打满显存 |
| 4 | ControlNet / IPAdapter | 先全部关闭，只保留主 checkpoint | 多个条件分支会叠加显存和中间张量 |
| 5 | Upscale | 先关闭或拆到第二个工作流 | 放大阶段经常在基础图已经生成后才 OOM |
| 6 | 启动模式 | 先默认；仍失败再试 --lowvram 或 --normalvram | 启动参数是辅助，不应替代降分辨率和降 batch |
| 7 | 后台进程 | 关闭游戏、视频剪辑、其他 AI 程序和多余 ComfyUI 实例 | 释放被其他进程占用的 VRAM |
这张表的目的不是让画质永久降低，而是先把工作流降到“能跑完”。能跑完后再一次只加回一个因素：先提高尺寸，再加 ControlNet，再加 upscale。
显存错误诊断中枢
| 你现在的情况 | 先看哪页 | 回到本页处理什么 |
|---|---|---|
| 还没报错，只想给 8GB 显卡找安全参数 | 8GB 显存设置 | 如果 Queue 后仍 OOM，用本页定位 batch、尺寸、upscale 或后台占用 |
| 不确定该用 SD1.5、SDXL 还是 Flux | SD1.5 和 SDXL 对比 和 完整模型选择指南 | 如果 SDXL/Flux 工作流 OOM，用本页判断是否应回退模型家族 |
| OOM 出现在 ControlNet、IPAdapter 或多条件分支 | ControlNet 模型选择 | 用本页决定先关几个分支、保留哪一个测试 |
| OOM 出现在模型加载或 Queue 开始时 | 模型加载失败排查 | 区分模型损坏、shape mismatch 和真正显存不足 |
| 只在高清修复或放大阶段 OOM | 本页先处理 | 把 upscale 拆到第二个工作流，降低倍率或改用分块放大 |
本页应该作为显存相关报错的最终落点：其他页面帮你决定“为什么会重”，这里帮你按顺序把它降下来。不要在每个页面都随机改参数，否则你会失去对比基线。
适合谁
- 刚开始使用 ComfyUI，需要一篇可以照着做的教程。
- 已经遇到相关报错，但不知道该先检查哪一步。
- 想把安装、模型、插件、工作流整理成可复查流程的用户。
准备条件
- 知道显卡显存容量。
- 能看到报错发生在哪个节点。
这张图把本机 ComfyUI /system_stats、nvidia-smi 和降参顺序放在一起。OOM 不要先重装 ComfyUI，先确认可用显存，再把 batch、尺寸、模型和附加模块降下来。
这张图补充说明稳定的降参顺序。能跑通后再一点点加回去；每次只改一个参数，才知道是哪一步把显存打满。
能跑通后再一点点加回去；每次只改一个参数，才知道是哪一步把显存打满。
先判断 OOM 发生在哪一步
- 一点 Queue 就报错：通常是尺寸、batch 或模型本身太吃显存。
- 跑到一半才报错：通常是采样步数、ControlNet、LoRA、IPAdapter 一起叠满了。
- 只在放大阶段报错：通常是 upscale 倍率太高或者分块太大。
- 更新插件后才报错：优先怀疑插件版本和依赖变化，不要先怪显卡坏了。
你如果只看到网页上的红字，不够。最重要的是黑色控制台最后一段日志，因为那里会写出是哪个节点把显存打满。
按报错位置选择处理分支
| 报错位置 | 先做什么 | 不要先做什么 |
|---|---|---|
| Checkpoint / UNet / CLIP 加载时 | 换更轻模型、确认 fp16/低显存模型、关闭其他占显存程序 | 不要先改提示词 |
| KSampler 开始或中途 | 降 resolution、batch 1、减少步数和附加条件分支 | 不要直接重装 CUDA |
| ControlNet / IPAdapter 节点 | 只保留 1 个分支，降低输入图尺寸，确认模型家族匹配 | 不要同时开 Canny、Depth、OpenPose、IPAdapter 测试 |
| VAE Decode / Save Image 前后 | 降输出尺寸，确认没有隐藏的高清修复或二次采样 | 不要把它误判为模型文件损坏 |
| Upscale / tiled upscale | 降倍率、减小 tile、拆到第二个工作流 | 不要在主生成链路里叠 2x/4x 放大 |
| 第二次、第三次运行才 OOM | 重启 ComfyUI，关闭多余进程，检查是否有旧任务占显存 | 不要只因为重启后好了就认为问题彻底解决 |
如果你能说清楚 OOM 发生在哪个节点，修复就会快很多。定位不到节点时，先复制控制台最后 20 行，再回到 30 秒止血清单，把所有重模块关掉，确认最小链路能跑。
操作步骤
- 先把 batch_size 改成 1。
- 把尺寸降到 512×512 或 512×768，SDXL 可先降到 768×768 测试。
- 关闭浏览器里其他占 GPU 的应用和游戏。
- 使用 SD1.5 替代 SDXL，或选择 fp16/低显存友好模型。
- 减少 ControlNet、IPAdapter、放大等附加模块。
- 启动参数尝试 —lowvram 或 —normalvram，按显存情况选择。
- 如果是放大阶段 OOM，降低 upscale 倍率或分块放大。
新手最稳的降参顺序
- 先把 batch_size 改成 1。
- 再把分辨率降到 512×512 或 512×768。
- 再把模型从 SDXL 换成 SD1.5。
- 再删掉不必要的 ControlNet、IPAdapter、放大节点。
- 最后才考虑 lowvram、normalvram 和更复杂的启动参数。
这个顺序不要乱。很多人一上来就改启动参数，结果根本不知道是哪个节点太吃显存。
判断问题属于哪一类
- 如果页面打不开，先看启动窗口是否还在运行，以及端口是否正确。
- 如果节点是红色，优先处理缺失自定义节点或插件加载失败。
- 如果模型下拉框为空，优先检查模型类型和放置目录。
- 如果开始生成后失败，优先看显存、模型版本和具体报错节点。
- 如果更新后才坏，优先考虑插件版本不兼容，必要时回退或临时移除插件。
常见错误
- 只重启 ComfyUI，不降低任何参数。
- 把系统内存当显存扩容。
- 同时开多个 ComfyUI 或其他 AI 程序。
8GB VRAM ComfyUI settings
8GB 显存不是不能用 ComfyUI，但不要用“高分辨率 SDXL + 多 ControlNet + 放大 + 视频节点”作为起点。更稳的 8GB 基线如下：
| 场景 | 建议设置 |
|---|---|
| SD1.5 文生图 | 512x512、512x768、batch 1、先不放大 |
| SDXL 文生图 | 768x768 起步，batch 1，关闭多余 LoRA 和 ControlNet |
| ControlNet | 先只开 1 个 ControlNet，确认成功后再加第二个 |
| Upscale | 先生成基础图，再用单独放大工作流处理 |
| LoRA | 一次只测试 1 个 LoRA，避免多个 adapter 同时吃显存和引入兼容问题 |
| Flux / 视频 | 8GB 上先不要作为默认学习入口，除非使用专门的轻量流程 |
8GB 用户最常见的错误，是把“能打开工作流”误以为“显存足够跑完整工作流”。导入复杂工作流后，先把放大、视频、多个 ControlNet、多个 IPAdapter 全部关掉，只保留主链路测试。
low VRAM mode 怎么选
--lowvram、--normalvram 这类启动参数可以帮助 ComfyUI 调整模型和显存调度，但它们不是万能修复。推荐顺序是：
- 先用默认启动方式，把 batch、分辨率、upscale、ControlNet 降下来。
- 如果默认方式仍然 OOM，再尝试
--normalvram。 - 如果显存非常紧张，再尝试
--lowvram。 - 每次只改一个启动参数，改完重启 ComfyUI 并用同一个小工作流测试。
- 不要同时堆很多未知参数，否则无法判断到底是哪一个参数改善或破坏了运行。
低显存模式可能降低速度或改变模型调度方式。它适合“勉强跑通”，不是替代合理分辨率和合理工作流结构的捷径。
reduce resolution / batch size / upscale / ControlNet 的顺序
英文搜索里经常把 reduce resolution batch size upscale ControlNet 放在一起，但实际处理要有顺序：
- 先降
batch_size，因为它通常不影响单张图构图，只影响一次生成几张。 - 再降 resolution，因为 latent 尺寸直接影响采样显存峰值。
- 再关 upscale，因为放大阶段经常在主图完成后才 OOM。
- 再关 ControlNet / IPAdapter，因为它们会把条件分支和中间特征叠加到主流程上。
- 最后才换模型家族或启动参数，因为这一步会影响画质、速度和工作流兼容性。
如果只在放大阶段 OOM，说明基础生成链路可能是健康的，不必重装 ComfyUI。把放大倍率降到 1.5x 或 2x，或者改成 tile/分块放大，通常比盲目换 checkpoint 更有效。
如果经常复发
如果当前模型始终跑不稳，建议重新选择更适合你显存的 基础模型家族；如果问题主要出现在 SDXL 上，可以重新比较 SD1.5 和 SDXL 的显存压力。如果 OOM 出现在 ControlNet 工作流中，也需要检查 控制模型和预处理器组合。
不同显存的现实预期
- 4GB 左右：优先 SD1.5，小图，少插件。
- 6GB 左右：SD1.5 也要保守，SDXL 很容易紧张。
- 8GB 左右：能跑不少基础工作流，但复杂节点还是要控制尺寸。
- 12GB 以上：空间更大，但也不是可以无限开插件和高分辨率。
验证是否成功
- 同一工作流降低参数后能跑完。
nvidia-smi显示显存峰值低于总显存。- 能说清楚 OOM 是发生在加载、采样、ControlNet、VAE decode 还是 upscale。
- 能从 8GB 参数页、SD1.5/SDXL 选择页、ControlNet 页回到本页继续降载。
- 加回画质设置时一次只改一个因素，而不是同时提高尺寸、LoRA、ControlNet 和 upscale。
如果仍然失败
请把控制台里从 Traceback 开始到最后一行的完整报错保存下来，同时记录：ComfyUI 版本、启动方式、显卡型号、显存容量、使用的模型文件名、刚安装过哪些插件。不要只截网页上的红色提示，因为真正有用的信息通常在启动窗口里。
如果你在本站提交反馈，登录状态下会自动附带 user_id，方便后续追踪同一个用户遇到的连续问题；未登录也可以匿名提交。
下一步推荐
- 8GB 参数基线：8GB 显存设置
- SD1.5 / SDXL 模型选择：SD1.5 和 SDXL 对比
- ControlNet 低显存用法：ControlNet 模型选择
- 全局低显存优化顺序：低显存优化总览
- 报错排查总入口：/topics/comfyui-errors/
更新记录
- 2026-05-12：扩写为正式教程，补充操作步骤、常见错误和验证清单。