“问什么问再问停雾”这句话你大概率在AI绘画交流群里见过。群友反复截一张灰蒙蒙的图问“为什么我生成的人像像隔了一层雾”问得多了老哥直接甩一句“再问我就把采样停了”。这算不上某个开源项目的正式名字更像本地生图圈里的一个黑色幽默。这篇博客就借这个梗把本地AI绘画部署里“出图发雾、清晰度差、生成中断、显存爆掉、接口不会调”这一整串问题完整过一遍排查路径。本文以 ComfyUI 作为主线来写SD WebUI 的排查思路也基本一致。你会看到发雾问题到底出在提示词、CFG、VAE、采样器还是模型选择本地环境应该怎么准备怎么启动服务并验证生成效果怎么用接口 API 提交任务怎么跑批量任务以及显存不够的时候有哪些降载手段。如果你最近正好被“雾蒙蒙的图”折磨过这篇文章可以直接收藏备用。1. 核心能力速览先给一张速查表把本文能解决的内容列清楚。排查主题说明出图发雾 / 朦胧感涉及负面提示词、CFG、VAE、采样器、模型选择生成中断 / 显存不足涉及分辨率、批量大小、模型精度、缓存清理图片模糊 / 细节丢失涉及采样步数、高清修复、放大算法ControlNet 不生效涉及模型放置、预处理器、控制权重、显存API 调用以 ComfyUI 的/prompt接口为例提供 curl 和 Python 示例批量任务目录队列、日志、失败重试、输出目录管理服务启动问题端口占用、依赖缺失、模型路径错误、驱动不匹配这里不写死任何显存数字因为实际占用取决于模型版本、分辨率、步数、ControlNet 数量和显卡驱动。更稳妥的做法是先按下面章节搭一套最小可运行环境再用自己的卡实测一轮。2. 适用场景与使用边界这套排查流程适合以下人群本地部署了 ComfyUI 或 SD WebUI但出图质量不稳定的人。想把手动生图改成脚本批量处理的人。想通过 API 把生图能力接到自己工具里的开发者。显卡显存不大想尽量压低资源占用的人。它不适合什么场景如果你只是偶尔用在线绘图工具不接触模型文件和本地环境就没必要照着本文折腾。如果你连 Python 虚拟环境都不熟悉建议先对着官方文档把基础概念补上否则排错时容易把“环境问题”和“参数问题”混在一起。使用边界必须说清楚。本地部署只解决技术问题不解决授权问题。任何涉及人脸、声音、版权素材的生成和处理都要确认你拥有合法授权。尤其是角色一致性、风格模仿、照片修复这类场景未经许可使用他人肖像或作品很容易踩到法律风险。生成测试请使用自己拍摄或获得授权的素材商用前务必做效果复核。3. 环境准备与前置条件本地 AI 绘画部署常见配置是这样的操作系统Windows 10/11、Ubuntu 20.04/22.04、Debian 系都可以。显卡NVIDIA 显卡优先驱动要支持 CUDA。A 卡或核显不是不能用但很多功能分支和加速方案不适用更建议先按 CPU 模式验证流程。显存建议 8G 起步跑 SD1.5 小模型比较舒服。4G 或 6G 也能跑但需要控制分辨率、批次和模型精度。内存16G 起步任务复杂时 32G 更稳。磁盘模型文件动辄几个 GSDXL 系列更大建议预留 50G 以上剩余空间。Python3.10 或 3.11 都常见具体看项目版本要求。端口ComfyUI 默认监听 8188SD WebUI 常用 7860。启动前先确认端口没被占用。依赖安装失败是最常见的入门坑。尽量不要直接用系统 Python 裸装先建一个虚拟环境避免污染系统环境。4. 安装部署与启动方式下面以 ComfyUI 为例给出一套通用流程。不同版本启动命令可能略有差异实际操作时以你 clone 下来的仓库 README 为准。git clone https://github.com/comfyanonymous/ComfyUI.git cd ComfyUI python -m venv venv # Windows venv\Scripts\activate # Linux / macOS source venv/bin/activate pip install -r requirements.txt依赖装好之后需要把模型放到对应目录。ComfyUI 默认的模型目录是models/checkpoints/、models/vae/、models/controlnet/、models/loras/。你从网上下载的 SD1.5、SDXL 或 Flux 模型文件按类型放进这些目录启动后才能在工作流里直接选择。启动命令# 默认 GPU 模式 python main.py # 显存较小可以尝试让程序自动降低显存占用 python main.py --lowvram # CPU 模式适合没有可用 N 卡时验证流程 python main.py --cpu启动成功后浏览器访问http://127.0.0.1:8188。如果页面打不开先看后台日志和端口占用情况再用下面的命令检查端口。# Windows netstat -ano | findstr 8188 # Linux / macOS lsof -i :8188如果你用的是别人做的整合包通常会提供一个双击启动的脚本。入口不一样但启动后的 Web 地址基本还是上面那个。需要留意的是整合包可能内置了特定版本的 Python 和 PyTorch升级时要谨慎避免依赖库不兼容。5. 功能测试与效果验证5.1 最小生成测试先跑一张最简单图用来确认环境没大问题。输入提示词可以这样写positive prompt: a portrait of a young woman, detailed face, clear skin, sharp focus, natural light negative prompt: fog, haze, blurry, low quality, watermark, oversmoothed参数建议分辨率 512x768步数 20 到 30CFG 设为 5 到 8采样器先用 Euler a 或 DPM 2M Karras批量大小 1。预期结果五官轮廓清晰皮肤有合理纹理背景没有大面积灰色雾感。如果画面依然发雾按下一节顺序排查。5.2 出图发雾排查路径“停雾”不是某一个参数的问题而是多个因素叠加的结果。建议按照下面顺序排查先检查 VAE 有没有加载。SD1.5 很多模型需要单独加载 VAE 文件不加载时图像会明显发灰、发白、像蒙了一层雾。SDXL 多数模型已经内置 VAE但部分修复版模型仍可能需要手动指定。在 ComfyUI 工作流里VAE Loader 节点要明确连接到 VAE Decode。如果你刚切了一个新 checkpoint最好重新确认工作流里的 VAE 节点不要依赖记忆。再检查 CFG 是否过低。CFG 太低模型对提示词的跟随变弱画面容易发虚、发雾。CFG 太高虽然边缘更硬但颜色可能过饱和甚至产生烧焦感。比较稳妥的测试范围是 5 到 8。你可以在同一 prompt 下跑 CFG 5、6、7、8 四张图对比选择最清晰且色彩正常的值。然后检查采样器和步数。Euler a、DPM 2M Karras、DDIM 这些采样器在相同步数下锐度不同。默认 20 到 30 步通常够用步数过低会出现细节不完整、整体模糊。不要盲目加到 60 步以上那不会带来线性提升还会明显增加耗时和显存占用。接着看负面提示词。把fog, haze, mist, grey, washed out, low contrast这类词加进 negative prompt对部分模型有直接改善。但负面提示词也不是越多越好写太多容易引入怪异瑕疵。再看模型本身。写实风格出图发糊先想一想是不是用错了模型。二次元模型和写实模型的训练数据差异巨大同一个 prompt 在两类模型上结果会完全不同。如果模型是从网上下载的转换版本也可能有精度损失。最后看放大流程。小分辨率直接放大往往会让原生细节丢失。建议先输出低分辨率图再接高清修复或放大模型比如 4x-UltraSharp 这类通用放大算法。放大倍数控制在 2 倍以内兼顾显存和效果。5.3 图生图测试图生图是验证参数是否合理的重要方式。上传一张已经确认清晰的图片设置 denoising strength 在 0.3 到 0.6 之间。测试时可以先固定 prompt只调整 denoising 强度。0.3 左右保留原图构图只做轻量细节修复。0.5 左右保留大致结构但整体风格会被 prompt 明显影响。0.7 以上原图痕迹变少接近重绘。判断成功标准是在保留有效结构的同时画面质感和风格符合预期。如果图生图结果像原图染了层滤镜说明 denoising 不够或 prompt 权重不足如果结果完全脱离原图说明 denoising 过强。5.4 ControlNet 效果验证ControlNet 常见用途是控制姿势、线稿、深度和边缘。测试时先确认ControlNet 模型文件放到了models/controlnet/。工作流里选择正确的预处理器。控制权重从 0.6 开始再逐步调整。输入参考图分辨率不要过大建议先压缩到 1024 以内。如果控制完全没生效优先检查模型路径和预处理器如果控制生效但结构扭曲通常是因为权重过高或输入图边缘信息过杂。手绘线稿和真实照片应该选择不同类型的 ControlNet 模型混用是无效的。5.5 显存不足与中断测试显存不足时典型现象是生成一段后直接报错后台日志出现 CUDA out of memory。常见诱因有分辨率过高、批量数大于 1、同时加载了多个模型、ControlNet 节点数量过多。验证方法很简单把分辨率降为 512x512批量数改为 1关掉不必要的预览和未使用的模型节点再生成一次。如果问题消失说明是资源超限而不是代码或模型损坏。6. 接口 API 与批量任务ComfyUI 启动后默认会开启后端 API。常用接口包括POST /prompt提交工作流任务。GET /history/{prompt_id}查询任务结果。GET /system_stats查看内存、显存等系统状态。GET /view查看输出图片。提交任务最简单的方式就是先在 UI 里搭好工作流导出为 API 格式 JSON再用脚本提交。这个 JSON 结构比较嵌套不建议手写完整结构。curl -X POST http://127.0.0.1:8188/prompt \ -H Content-Type: application/json \ -d workflow.json也可以用 Python 脚本提交。下面是一个示意代码实际字段需要根据你导出的工作流结构调整import requests import json import uuid server http://127.0.0.1:8188 client_id str(uuid.uuid4()) with open(workflow.json, r, encodingutf-8) as f: workflow json.load(f) payload { prompt: workflow, client_id: client_id } response requests.post(f{server}/prompt, jsonpayload, timeout30) print(response.json()[prompt_id])批量任务的思路就是准备一个工作流模板写脚本遍历输入目录替换工作流中的 prompt、图片路径和输出文件名然后逐条提交到队列。import os import json import requests import uuid import glob server http://127.0.0.1:8188 def submit_workflow(template_path, payload_map): with open(template_path, r, encodingutf-8) as f: workflow json.load(f) # 这里根据业务逻辑替换 workflow 中的字段 # 例如 workflow[6][inputs][text] payload_map[prompt] resp requests.post(f{server}/prompt, json{ prompt: workflow, client_id: str(uuid.uuid4()) }, timeout30) resp.raise_for_status() return resp.json()[prompt_id] for image_path in glob.glob(./inputs/*.png): prompt_id submit_workflow(batch_workflow.json, { prompt: a product photo, clean background, image: os.path.abspath(image_path) }) print(image_path, prompt_id)批量任务建议控制并发数量。不是提交越多越快同一时间多个高分辨率任务会抢显存反而导致任务排队和 OOM 中断。更稳的做法是一次只提交 1 到 2 个任务通过GET /history/{prompt_id}轮询完成状态失败后记录日志并重试。如果要做成服务建议把监听地址限制在本机python main.py --listen 127.0.0.1 --port 8188不要随意把服务暴露到公网。没有鉴权的本地 API 一旦开放到局域网或公网任何人都能调用你的显卡资源安全隐患很大。7. 资源占用与性能观察AI 绘画的显存占用和性能表现需要以本机实测为准。拿别人报的数字当结论没有意义因为显卡型号、驱动版本、模型量化方式都会影响结果。下面给出通用的观察方法。查看显存占用# Windows / Linux 均可实时刷新 nvidia-smi如果想持续观察可以写成循环watch -n 1 nvidia-smi影响性能和显存的因素主要有这几个分辨率。图像面积从 512x512 提到 1024x1024计算量接近四倍显存占用同步上升。步数。步数增加耗时增加但显存占用不一定线性上升。批量大小。批量数大于 1 时显存占用明显上升速度不一定成比例提升。ControlNet 预处理器。部分预处理器在前处理阶段就会消耗大量内存尤其是深度图、法线图这类任务。多模型同时加载。工作流里塞了多个 checkpoint 会导致显存被多个模型同时占用。降低显存占用的常见手段按优先级排列把批量数降为 1。把分辨率降到目标输出对应的低分辨率再走放大流程。使用 fp16 或量化模型。启动参数加--lowvram或--medvram。清理不再使用的模型节点。关掉实时预览和额外的高分辨率预览组件。CPU 模式可以跑但速度会慢很多。如果你没有可用 N 卡先用--cpu验证流程真正批量生成时再换到有 N 卡的机器上。4G 以下显存也不是完全不能跑但建议固定用 SD1.5 此类小模型并全程控制分辨率。进程残留是另一个容易忽视的点。生成任务中断后后端进程可能还没释放显存。如果再启动一个新实例会出现端口冲突或显存占用异常。遇到这种情况先结束旧进程再启动。# Windows按端口找 PID netstat -ano | findstr 8188 taskkill /PID pid /F # Linux / macOS lsof -i :8188 kill -9 pid8. 常见问题与排查方法问题现象可能原因排查方式解决方案启动后页面打不开端口被占用或服务未启动成功看终端日志检查端口更换端口或重启服务模型加载失败模型文件路径错误、文件名不匹配检查models目录看日志把模型放到正确目录重启出图全是黑色VAE 缺失或模型输出异常检查 VAE 节点换单个模型测试加载正确 VAE或重新下载模型出图发雾、发灰VAE 未加载、CFG 过低、采样器不适配按第 5.2 节顺序排查加载 VAE调整 CFG 和采样器CUDA out of memory显存不足看 nvidia-smi降参数重试降低分辨率、批量数使用低显存模式ControlNet 不生效路径放错、预处理器错误、权重过低检查节点配置和模型路径重新放置模型提高权重API 提交 404接口路径不对或服务未启动检查地址和日志访问/system_stats确认服务端口换正确路径批量任务卡住任务队列堆积、某个任务 OOM看日志轮询/history减少并发数加超时和重试依赖安装失败Python 版本不匹配、包冲突查看 pip 报错重建虚拟环境换 Python 版本依赖安装失败时优先看 pip 报错的具体包名。很多情况是 PyTorch 版本和显卡驱动 CUDA 版本不匹配。建议严格按项目 README 指定版本安装不要自己随手升级所有库。9. 最佳实践与使用建议本地 AI 绘画稳定运行靠的是一套工程化习惯而不是某次跑通就完事。第一次调试先小参数测试。分辨率 512步数 20批量数 1跑通后再逐步增加复杂度。这样能把“环境问题”和“参数问题”分开。很多人一上来就开 1024 加 ControlNet出问题后根本分不清是模型坏了还是显存爆了。保留一套最小可运行配置。记录一份你验证过可用的工作流 JSON 和 prompt 组合当作回归测试用例。以后换了模型、升级了依赖先用这套配置跑一遍确认环境没被改坏。文件和素材按目录管理。建议目录结构类似models/ checkpoints/ vae/ controlnet/ loras/ inputs/ outputs/ logs/ workflows/ templates/输入素材、输出结果、工作流模板分开放批量任务里按日期生成输出子目录避免所有图片堆在一个文件夹里。批量任务一定要加日志和失败重试。脚本里记录每条任务的 prompt_id、状态、耗时、返回信息。失败任务先重试一次如果仍然失败就写入 error 列表不要直接影响下一个任务。这个习惯在跑几百张图时尤其重要。接口服务要限制访问范围。开发测试时监听127.0.0.1就够了。如果需要局域网访问先确认网络环境安全再考虑防火墙和访问控制。涉及人脸、声音、版权素材时必须确认授权。无论是修图、换脸还是风格化处理都要先想清楚素材来源是否合法。商用前做效果复核把风险前置处理比事后补救容易得多。10. 总结与下一步“停雾”不是某个具体开关而是一类生成质量问题的总称。它可能来自 VAE 缺失、CFG 设置不合理、采样器选择错误、模型不匹配、放大流程粗糙甚至显存不足导致生成中断后输出残缺图。把这几个因素按顺序排查基本上能解决 80% 的“雾蒙蒙”问题。最值得先验证的不是复杂工作流而是最小生成测试。先跑通一张清晰图再逐步加功能。最容易踩的坑是环境没确认稳定就堆参数结果问题全混在一起排查起来非常痛苦。下一步可以继续扩展的方向很多把你验证过的参数沉淀成自己的预设模板把单张生成改成自动化批量处理用 API 把 ComfyUI 接入自己的工具链或者针对特定模型跑一组参数对比实验。本文这整套方法本身就适合作为你本地 AI 绘画工作流的基础框架。建议收藏备用以后遇到“雾气”问题直接按表排查。