Stable Diffusion 黑图 / 爆显存终极排障指南
从 WebUI 参数、VAE、xFormers 到 CUDA 环境，一次讲清楚最常见的黑图、NaN 与显存溢出问题。
| 文档定位 图文实战版｜适合 Stable Diffusion 新手与本地部署用户 | 适用范围 AUTOMATIC1111 / 常见整合包 / Windows 为主，亦可迁移到 Linux |
| 核心问题 黑图、绿图、灰图、VAE NaN、CUDA Out of Memory、xFormers 异常 | 阅读收益 先判断症状，再按优先级修复，减少反复重装和无效折腾 |
导读
Stable Diffusion 的“黑图”与“显存溢出”，看起来像两个问题，实则经常是同一条链路上的不同表现：模型、VAE、注意力后端、半精度、分辨率、扩展插件和 CUDA 环境一起叠加后，最终要么直接报错，要么勉强跑完却只输出一张黑图。
很多人一出问题就重装整套 WebUI，但真正高效的做法，是先把问题缩小成“最小可复现基线”：单模型、单 VAE、无 Hires.fix、无 ControlNet、Batch Size = 1。只要基线能跑，再逐个把功能加回去，故障点通常很快就会暴露。
| 这篇教程的核心结论 • 黑图优先排查半精度与 VAE：先试 –upcast-sampling，再试 –no-half-vae，最后才考虑 –no-half。 • 爆显存优先排查分辨率、Batch Size、Hires.fix 和附加模块；步骤数通常影响时间多于显存。 • 低显存卡先用 –xformers 或 –opt-sdp-no-mem-attention，再看是否需要 –medvram / –lowvram。 • PyTorch 的 empty_cache() 不是万能药；如果是碎片化或版本错配，真正有效的往往是重启进程、清理扩展或重建 venv。 |
图 1｜黑图 / 爆显存排障分流图
一、先判断：你遇到的到底是哪一类问题？
先别急着改一堆参数。下面这张表能帮你把故障快速归类。
| 症状 | 最可能原因 | 第一步动作 |
| 黑图 / 绿图 | 显卡对 fp16 不稳定，或 VAE 里出现 NaN | 先加 –upcast-sampling；再试 –no-half-vae |
| 立刻 OOM | 分辨率、Batch Size、Hires.fix 或扩展过重 | 宽高回到 512-768 档，Batch Size = 1 |
| 更新后出错 | xFormers / Torch / CUDA 版本错配 | 临时去掉 –xformers，必要时清 venv |
| 只在某模型下异常 | Checkpoint / VAE / LoRA 组合问题 | 换回已知正常模型做基线测试 |
| 连续跑久了才炸 | 缓存碎片、扩展泄漏、长期占用未释放 | 重启 WebUI，再考虑 allocator 调优 |
二、黑图的 4 个高频根因：为什么它能“生成完成”却什么都没有？
1）半精度不兼容：最常见，也最容易被误判成模型坏了
在部分显卡上，fp16 路线并不稳定，结果就是进度条跑完、显存也动了，但输出是一整张黑图、绿图或灰块。AUTOMATIC1111 的故障排查页直接给出的第一条方向，就是先尝试 –upcast-sampling；如果还不行，再提升到 –precision full –no-half，不过后者会明显增加显存占用。
经验上，更稳妥的顺序是：–upcast-sampling → –no-half-vae → –no-half。因为很多问题其实只发生在 VAE 阶段，直接把整个推理链路都切成全精度，代价往往太大。
2）VAE 出现 NaN：看起来像模型崩了，本质却常常是解码阶段翻车
当控制台出现“A tensor with all NaNs was produced in the VAE”一类提示时，说明模型前面可能还在正常推理，但在 VAE 解码时数值爆掉了。这类问题可能来自模型本身、模型合并、VAE 不匹配，或者显卡 / 算子对 fp16 支持不佳。
此时 –disable-nan-check 只能帮助你确认问题，不是修复手段。更实用的动作，是先换回已知正常的 checkpoint 与 VAE，再逐个撤掉 LoRA、ControlNet 和后处理模块。
3）注意力后端或 xFormers 版本错配：更新后突然坏，大多不是“玄学”
如果你之前一直正常，更新 WebUI、Torch、CUDA、显卡驱动或 xFormers 之后突然开始黑图、报 no kernel image 或随机异常，优先怀疑版本兼容性。
最简单的验证法不是继续叠参数，而是先去掉 –xformers，用默认路径跑一轮；如果恢复正常，再决定是重装 xFormers，还是改回 WebUI 提供的另一条注意力优化路线。
4）环境脏了：旧扩展、旧缓存、旧 venv 混到一起
长期使用整合包的人，最容易忽略的一件事是：同一个目录里可能已经积了多轮升级残留、旧扩展和不兼容依赖。控制台明明写着 CUDA OOM，真正的问题却可能是扩展重复吃显存，或者老版本 wheel 没被彻底替换。
当你无法确认到底是模型、参数还是环境时，最有价值的操作是做一次“干净启动”：临时禁用扩展、换回官方推荐参数、必要时删除 venv 重建。
| :: Windows 用户可先在 webui-user.bat 里尝试这一组保守参数 set COMMANDLINE_ARGS=–xformers –upcast-sampling –no-half-vae –medvram |
上面这组不是“最强性能配置”，但对于 6GB 及以下显存、或容易出黑图的老卡来说，通常是一个更稳的起点。
三、显存溢出的真正罪魁祸首：别把精力都浪费在“步骤数”上
很多新手看到 OOM，会先把采样步数从 30 改到 20。但对显存来说，更应该优先动的是下面这些项目。
| 项目 | 对显存影响 | 更实用的建议 |
| 分辨率 / 宽高 | 极高 | 先把长边控制在 512-768 档，确认稳定后再逐步加大 |
| Batch Size | 极高 | 优先设为 1；需要多图时尽量提高 Batch Count 而非 Batch Size |
| Hires.fix | 高 | 黑图 / OOM 时先关掉，先在基础尺寸上跑通 |
| ControlNet / ADetailer / 面修 | 高 | 逐个开启，别一上来全叠上 |
| 模型体量（如 SDXL） | 高 | 先用更轻的模型做基线，确认环境没问题 |
| xFormers / SDP 优化缺失 | 中高 | 补上 –xformers 或 –opt-sdp-no-mem-attention |
| Steps | 低 | 主要影响速度与收敛，不是最优先的显存开关 |
图 2｜显存优化优先级路径图
四、真正好用的“终极方案”：按这 5 步排，不走弯路
第 1 步：先做最小可复现基线
• 只保留一个已知正常的 checkpoint 与 VAE，关闭 Hires.fix、ControlNet、ADetailer、面部修复、脚本与多数扩展。
• 分辨率先放回 512×512、512×768 或 768×512；Batch Size = 1；Batch Count 可先设 1-4。
第 2 步：优先修黑图，不要一上来就 no-half
• 先加 –upcast-sampling。
• 如果控制台出现 VAE NaN，或旧卡依旧异常，再加 –no-half-vae。
• 只有前两步都失败，才上 –precision full –no-half；同时准备接受更高显存占用，并视情况搭配 –medvram。
第 3 步：优先修 OOM，先关最重的功能
• 先砍分辨率，再看 Batch Size，再关 Hires.fix 和附加模块。
• 如果显存本来就很紧，先试 –xformers 或 –opt-sdp-no-mem-attention；4GB 左右显存再考虑 –medvram / –lowvram。
第 4 步：怀疑环境时，先做“干净重启”，再做“干净重装”
• 退出 WebUI，清掉后台占显存的软件，重新启动一次。
• 问题仍在时，临时禁用扩展；再不行就删除 venv 让环境重建，而不是盲目覆盖安装。
第 5 步：最后再动 allocator 和高级变量
• 如果你已经确认不是模型、不是分辨率、不是扩展，而是长时间运行后才 OOM，可以把 PyTorch allocator 调优作为“最后一手”。
• 这类设置更像手术刀，不是万金油；有些机器会改善碎片化，有些机器只会变慢。
| 高级用户才建议尝试的 allocator 设置 • PyTorch 新文档中推荐使用 PYTORCH_ALLOC_CONF；PYTORCH_CUDA_ALLOC_CONF 只是兼容旧写法。 • max_split_size_mb 适合怀疑“内存碎片化”的场景，但官方明确把它描述为 last resort。 • 如果你只是单次高分辨率任务 OOM，先降分辨率、关扩展，通常比改 allocator 更直接。 | |
| :: 仅在确认存在碎片化、且反复长跑后才 OOM 时再尝试 set PYTORCH_CUDA_ALLOC_CONF=max_split_size_mb:128 :: 或者新写法 set PYTORCH_ALLOC_CONF=max_split_size_mb:128 | |
五、很多人容易踩的 6 个误区
误区 1｜一黑图就直接 no-half
no-half 常常能绕过问题，但它不是最低成本方案；不少情况只需要 no-half-vae。
误区 2｜OOM 先降 steps
步数影响更多是时间，而不是最优先的显存开销。
误区 3｜Batch Count 和 Batch Size 一样伤显存
真正更吃显存的是并行生成的 Batch Size。
误区 4｜empty_cache() 能把当前任务也救回来
PyTorch 文档明确指出，它释放的是未使用缓存，对已被张量占用的显存无能为力。
误区 5｜某个模型能跑，说明环境一定没问题
环境错配并不一定会让所有模型都报错；重模型、某些 VAE 或扩展路径更容易先暴露问题。
误区 6｜重装等于解决
如果不先做基线测试，你很可能只是把原来的问题打包迁移到新目录。
FAQ
Q1：GTX 10 系 / 16 系更容易黑图吗？
| 相对更容易踩到半精度相关问题。按 WebUI 故障页的建议，优先尝试 –upcast-sampling，并视情况补 –no-half-vae。 |
Q2：我只有 4GB 显存，还能继续玩吗？
| 可以，但要接受速度下降。优先使用 –xformers 或 –opt-sdp-no-mem-attention，再配合 –medvram；不行再尝试 –lowvram。 |
Q3：为什么我把 Batch Size 调成 1 还是会爆显存？
| 因为分辨率、Hires.fix、ControlNet、ADetailer、模型体量和 no-half 都会继续拉高显存需求。Batch Size 只是第一层开关。 |
Q4：黑图和 NaN 一定是显卡坏了吗？
| 不一定。模型 / VAE 不匹配、扩展冲突、xFormers 版本不兼容都可能造成相似现象。 |
Q5：清 venv 值得做吗？
| 如果问题出现在升级、换 Python/Torch/CUDA 之后，非常值得。它常常比‘覆盖安装’更干净。 |
相关阅读
• 《本地部署入门：手把手带你下载 Stable Diffusion WebUI 整合包》
• 《小白必看：如何在 Windows / Mac 上配置 Python 与 GPU 加速环境》
• 《从零开始：使用 Flux 1.0 生成超写实摄影大片的参数指南》
• 《Midjourney v7 新功能详解：局部重绘与风格迁移实战》
资料参考（官方 / 一手资料）
• AUTOMATIC1111 stable-diffusion-webui Wiki：Troubleshooting、Command Line Arguments and Settings
• PyTorch 官方文档：CUDA semantics / Memory management / CUDA Environment Variables
• Hugging Face Diffusers 官方文档：Reduce memory usage
• xFormers 官方文档：memory-efficient attention 说明
