企业官网建设流程全解析

“问什么问，再问停雾！”这句话你大概率在AI绘画交流群里见过。群友反复截一张灰蒙蒙的图问“为什么我生成的人像像隔了一层雾”，问得多了，老哥直接甩一句“再问我就把采样停了”。这算不上某个开源项目的正式名字，更像本地生图圈里的一个黑色幽默。这篇博客就借这个梗，把本地AI绘画部署里“出图发雾、清晰度差、生成中断、显存爆掉、接口不会调”这一整串问题，完整过一遍排查路径。

本文以 ComfyUI 作为主线来写，SD WebUI 的排查思路也基本一致。你会看到：发雾问题到底出在提示词、CFG、VAE、采样器还是模型选择；本地环境应该怎么准备；怎么启动服务并验证生成效果；怎么用接口 API 提交任务；怎么跑批量任务；以及显存不够的时候有哪些降载手段。如果你最近正好被“雾蒙蒙的图”折磨过，这篇文章可以直接收藏备用。

1. 核心能力速览

先给一张速查表，把本文能解决的内容列清楚。

这里不写死任何显存数字，因为实际占用取决于模型版本、分辨率、步数、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 更稳。
• 磁盘：模型文件动辄几个 G，SDXL 系列更大，建议预留 50G 以上剩余空间。
• Python：3.10 或 3.11 都常见，具体看项目版本要求。
• 端口：ComfyUI 默认监听 8188，SD 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 到 30，CFG 设为 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", encoding="utf-8") as f: workflow = json.load(f) payload = { "prompt": workflow, "client_id": client_id } response = requests.post(f"{server}/prompt", json=payload, timeout=30) 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", encoding="utf-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()) }, timeout=30) 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. 把批量数降为 1。
2. 把分辨率降到目标输出对应的低分辨率，再走放大流程。
3. 使用 fp16 或量化模型。
4. 启动参数加--lowvram或--medvram。
5. 清理不再使用的模型节点。
6. 关掉实时预览和额外的高分辨率预览组件。

CPU 模式可以跑，但速度会慢很多。如果你没有可用 N 卡，先用--cpu验证流程，真正批量生成时再换到有 N 卡的机器上。4G 以下显存也不是完全不能跑，但建议固定用 SD1.5 此类小模型，并全程控制分辨率。

进程残留是另一个容易忽视的点。生成任务中断后，后端进程可能还没释放显存。如果再启动一个新实例，会出现端口冲突或显存占用异常。遇到这种情况，先结束旧进程再启动。

# Windows，按端口找 PID netstat -ano | findstr 8188 taskkill /PID <pid> /F # Linux / macOS lsof -i :8188 kill -9 <pid>

8. 常见问题与排查方法

依赖安装失败时，优先看 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 绘画工作流的基础框架。建议收藏备用，以后遇到“雾气”问题直接按表排查。