AI绘画本地部署：Stable Diffusion WebUI与ComfyUI实战指南

艺术家ZHO提出过一个很激进的判断：AI正在把人类从“创作者”这个身份里逐渐开除出去。过去我们觉得，绘画、摄影、设计这些能力天然属于人类，AI只是工具；但当模型能在几秒内生成一张完成度足够高的图像，创作者的核心价值就从“亲手画出来”变成了“想清楚要什么，并判断生成结果是否可用”。这个转变对内容生产、设计工作流、甚至所谓的“艺术天赋”都有直接影响。

这个话题没有必要停留在讨论层面。技术人员最直接的反应是：把模型下载到本地，亲手跑一遍，看看AI生成能力的边界到底在哪，再判断它对人类创作者到底意味着什么。这篇文章就围绕AI绘画本地部署展开，完整讲述从环境准备、模型加载、WebUI启动到功能测试、接口调用、批量任务和显存观察的整套流程。文章不会去夸大某个工具的效果，也不打算把问题推到“AI是否取代人类”这种大而空的层面——先能跑起来，再讨论它改变了什么。

文章以Stable Diffusion WebUI和ComfyUI这两类最常见的本地AI绘画工具链为例。它们是目前覆盖最多用户、社区最成熟的开源方案，可以完成文生图、图生图、局部重绘、ControlNet结构控制、LoRA风格定制等任务。读完这篇文章，你应该能独立完成一套本地AI绘画环境的搭建，并验证它能否真正放进你的实际工作流。

1. 核心能力速览

先给出一张能力速览表，让读者快速判断这套方案值不值得装。表格中的数据以常见本地部署流程为准，具体版本和显存占用需要结合你自己的机器实测。

这张表里最关键的两个信息是：第一，门槛不高，有一块NVIDIA显卡就能跑起来，显存不够可以做CPU推理，只是速度慢；第二，它不是只能点按钮的玩具，而是能通过API接到自己业务系统里的工具链。

2. 适用场景与使用边界

AI绘画本地部署适合谁？首先是经常需要批量出图的运营、设计和内容创作者。过去出一张参考图可能要打开PS找素材、调色、合成，现在可以先把提示词写好，用一个模型批量生成十几个候选方向，再人工筛选。其次是做AI应用开发的技术人员。本地部署意味着图片数据不出机器，可以放心处理内网素材，也能把生成接口封装给团队内部使用。最后是学习和实验用户。通过WebUI可以直接看到提示词、采样器、步数、分辨率对成图的影响，这是理解扩散模型最有用的路径。

不适合的场景也要说清楚。需要精确到毫米级的工业制图、工程图纸，AI绘画不能完全取代；需要100%还原某个特定产品外观的电商主图，生成结果不稳定，仍需专业人工修图；版权归属不明确的商业项目，要谨慎处理训练数据和生成素材来源。

这里必须强调合规边界。本地部署不等于可以无限制生成任何内容。涉及真人肖像、他人作品风格、品牌标识、受版权保护的素材时，必须先确认授权；用于公开发布或商用前，要做人工复核。生成内容的合规责任最终由使用者承担。另外，如果启动了API服务，不要直接暴露在公网，应该只监听本机或内网，并加访问控制，否则容易被外部调用消耗资源。

3. 环境准备与前置条件

搭建一套可用的AI绘画本地环境，需要同时满足软件、硬件、网络和磁盘几个条件。

硬件方面：NVIDIA显卡是首选，因为CUDA生态最成熟，绝大多数优化方案都优先支持。显存8G属于比较舒服的起步线，可以跑常见的1024x1024以下分辨率，配合xformers这类显存优化方案能获得不错体验。6G显存也能跑，但建议把分辨率控制在768以下，并使用fp16精度的模型文件。没有NVIDIA显卡的用户也不是完全不能跑，CPU推理可以完成，只是单张512x512图像可能需要几分钟，做批量任务会很煎熬。

软件方面：操作系统建议Windows 10/11或Ubuntu 20.04以上；Python推荐3.10或3.11版本，太高或太低都可能遇到依赖不兼容的问题；安装NVIDIA显卡驱动后，不需要单独装完整的CUDA Toolkit，因为PyTorch预编译包通常会自带CUDA运行库，但需要确保显卡驱动版本足够新。工作目录里建议预留至少20G磁盘空间，模型文件通常2G到7G不等，临时文件和输出图也会持续占用空间。

网络方面：下载模型文件依赖Hugging Face、GitHub等源站，速度不稳定时建议使用国内镜像源，或者在下载工具中配置代理。这里不给具体镜像地址，因为地址经常变化，以你实际能访问到的稳定源为准。

端口方面：Stable Diffusion WebUI默认端口是7860，ComfyUI默认端口是8188。如果端口被占用，可以用--port参数改掉。

准备工作的核心思路是：不要一上来就研究模型原理，先保证Python版本正确、显卡驱动可用、依赖能装进去、模型文件放对位置，这四个条件满足后，启动过程通常就顺了。

4. 安装部署与启动方式

本地AI绘画有两类主流入口。第一类是Stable Diffusion WebUI，适合刚入门、希望直接点界面的用户，功能完整，社区资料最多；第二类是ComfyUI，以节点工作流为核心，适合需要精细控制生成流程、做自动化管线和批量任务的用户。下面分别说明部署方式。

4.1 创建Python虚拟环境

不论使用哪个WebUI，都建议先创建虚拟环境，避免污染系统Python。以Windows PowerShell为例：

# 创建虚拟环境 python -m venv sd-env # 激活虚拟环境 .\sd-env\Scripts\Activate.ps1

Linux或macOS使用：

python3 -m venv sd-env source sd-env/bin/activate

激活后命令行前会出现(sd-env)前缀，后续安装依赖都在这套环境里执行。

4.2 安装Stable Diffusion WebUI

WebUI项目依赖很多，通过Git拉取代码后，直接用pip安装依赖。不同项目的依赖管理方式不同，可以使用项目自带的启动脚本自动安装依赖。

# 拉取项目代码 git clone https://github.com/AUTOMATIC1111/stable-diffusion-webui.git cd stable-diffusion-webui # 安装依赖，实际安装项以项目launch脚本为准 pip install -r requirements_versions.txt

如果网络访问GitHub不稳定，可以先把仓库打包下载后解压，再把大模型文件手动放入对应目录。依赖安装失败时，优先排查Python版本和pip源。

4.3 下载模型文件

模型文件是影响出图质量的核心。下载后放入models/Stable-diffusion目录，例如：

models/Stable-diffusion/majicmixRealistic_v7.safetensors models/Stable-diffinition/dreamshaper_8.safetensors

WebUI启动后会在模型下拉框里显示这些文件名。模型没有放对位置时，即使界面正常打开，也无法生成图像，这是最常见的坑。

4.4 启动WebUI

python launch.py --xformers --port 7860 --api

参数说明：

• --xformers：开启显存优化，NVIDIA显卡建议加上，6G显存用户尤其需要。
• --port 7860：指定端口，冲突时换用其他端口。
• --api：启动API服务，后面做接口调用时使用。
• --medvram或--lowvram：显存紧张时的降级参数，显存大于8G通常不需要。

启动成功会在命令行看到本地访问地址，浏览器打开http://127.0.0.1:7860，看到页面、并且模型下拉框能选出模型，就算部署成功。

4.5 ComfyUI启动方式

ComfyUI更轻量，安装思路类似。拉取代码、安装依赖后，运行：

python main.py

默认监听8188端口。ComfyUI以工作流文件为核心，可以在界面上拖拽节点，也可以导入别人分享的工作流JSON文件，自动化程度更高，适合后期做批量生成任务。

5. 功能测试与效果验证

环境跑通后，下面按功能维度做测试。每个测试都按照“测试目的、输入、操作、预期结果、判断标准、失败排查”来展开。

5.1 文生图基础测试

测试目的：确认模型能正常生成图像，并检查提示词、采样参数是否生效。

在WebUI的txt2img页面输入提示词，例如：

a mountain lake at sunset, highly detailed, digital art

负向提示词可以填：

blurry, low quality, bad anatomy

采样器选择Euler a，步数设置为20，分辨率根据显存设置为512x512或768x512，点击Generate。

预期结果：十几秒到几十秒内生成一张图片，图片下方显示生成参数。判断成功的标准是没有报错，画面内容与提示词方向基本一致，人脸和肢体没有明显畸变。

如果生成报错，优先检查模型文件是否加载，再观察命令行日志中的显存信息。图像质量差通常不是故障，而是提示词、采样器、步数搭配问题，可以换采样器或增加步数再试。

5.2 图生图测试

测试目的：验证输入图片能否在保持整体结构的前提下被改写成新风格。

在img2img页面上传一张测试图片，填写想要的风格提示词，将denoising strength设置为0.5左右。这个值越大，输出与输入图差异越大；值越小，越接近原图。

预期结果：生成图保留原图的构图和主体轮廓，同时呈现新的风格。判断成功标准是前后两张图在布局上明显关联，而不是完全重绘。

如果输出与输入完全无关，说明denoising strength过高；如果输出与输入几乎一样，说明数值过低。

5.3 局部重绘测试

测试目的：验证局部修改能力，也就是只重绘指定区域，不破坏画面其他部分。

在img2img页面上传图片，切换到Inpaint模式，用画笔工具蒙住要修改的区域，填写描述该区域的提示词。分辨率保持原图尺寸，denoising strength设置到0.7左右。

预期结果：蒙版区域被修改，非蒙版区域保持一致。判断成功标准是区域边界过渡自然，没有大面积颜色污染。

如果边界生硬，可以开启mask blur并提高数值；如果整个画面都变了，说明denoising strength偏高。

5.4 ControlNet结构控制测试

测试目的：验证通过姿态或边缘控制生成构图的能力，这是AI绘画进入可控生产流程的关键。

需要先下载ControlNet模型文件，放入models/ControlNet目录。在WebUI中启用ControlNet，上传一张有人物姿态的参考图，选择对应预处理器和模型，然后再输入提示词生成。

预期结果：生成的人物姿态与参考图基本一致，但服装、背景、画风可以自由变化。判断标准是骨架结构正确，构图受控。

ControlNet功能对显存占用更高，8G以下显存建议降低分辨率，或关闭多余预处理模块。

5.5 批量生成测试

测试目的：验证批量任务稳定性，观察连续生成是否会导致显存泄漏或崩溃。

在文生图页面设置Batch count为5，每批1张；或设置Batch size为2，一次生成两张。开始生成后观察命令行日志和显存占用。

预期结果：连续多张图都成功输出，显存占用稳定，不会随批次数无限增长。判断标准是最后一张图和第一张图拥有相同质量，且没有OOM报错。

如果批量生成中途卡死，先降低Batch size，再检查显存是否不足，最后查看日志是否有单个CUDA错误。

6. 接口 API 与批量任务

WebUI启动时加--api后，会提供完整的HTTP接口。常用接口是/sdapi/v1/txt2img，请求体为JSON，返回base64编码的图片数据。

下面给出curl调用示例：

curl -X POST http://127.0.0.1:7860/sdapi/v1/txt2img \ -H "Content-Type: application/json" \ -d '{ "prompt": "a cat sitting on a windowsill, cozy light, photograph", "negative_prompt": "blurry, low quality", "steps": 25, "width": 512, "height": 512, "batch_size": 1 }'

返回结果中data字段是一个字符串数组，每个元素是一张base64编码的PNG图片。用Python可以这样处理：

import requests import base64 from PIL import Image from io import BytesIO url = "http://127.0.0.1:7860/sdapi/v1/txt2img" payload = { "prompt": "a cat sitting on a windowsill, cozy light, photograph", "negative_prompt": "blurry, low quality", "steps": 25, "width": 512, "height": 512, "batch_size": 1, } response = requests.post(url, json=payload, timeout=300) result = response.json() img_data = base64.b64decode(result["data"][0]) image = Image.open(BytesIO(img_data)) image.save("output.png")

批量任务可以写成脚本，按目录读取提示词文件，循环调用接口，输出文件按序号或内容命名。建议在循环中加入异常捕获，防止单张失败导致整个任务中断：

import requests import base64 import time url = "http://127.0.0.1:7860/sdapi/v1/txt2img" prompts = [ "a futuristic city street at night, neon lights", "a cozy cabin in the snowy forest, morning light", "an underwater palace with coral and fish, dreamlike", ] for idx, prompt in enumerate(prompts): payload = { "prompt": prompt, "negative_prompt": "blurry, low quality", "steps": 20, "width": 512, "height": 512, "batch_size": 1, } try: resp = requests.post(url, json=payload, timeout=600) resp.raise_for_status() img_data = base64.b64decode(resp.json()["data"][0]) with open(f"output_{idx}.png", "wb") as f: f.write(img_data) print(f"task {idx} done") except Exception as e: print(f"task {idx} failed: {e}") time.sleep(2)

批量任务要注意三个问题。第一，接口调用压力集中在显卡时，并发数不要设太高，建议单卡同时只跑一个请求；第二，每次请求的显存占用在返回结果后不会立即完全释放，连续大批量任务建议每50到100张重启一次进程；第三，请求超时时间要设置得足够长，大分辨率生成可能超过几十秒，接口不是越快越好，而是稳。

7. 资源占用与性能观察

本地AI绘画最需要观察的资源是显存。WebUI界面右上角自带显存占用显示，命令行也会输出生成耗时。更准确的方式是用nvidia-smi实时观察：

nvidia-smi -l 2

这个命令每两秒刷新一次GPU利用率、显存使用和温度。

影响显存占用的因素主要有四个：分辨率、步数、批量数量、ControlNet是否启用。分辨率从512提升到1024，显存占用可能翻倍以上；批量数量从1提高到2，显存占用也接近线性增长；步数主要影响计算时长，对显存影响相对小。ControlNet会引入额外网络结构，显存占用明显上升。

如果你的显存只有6G，建议这样配置：分辨率控制在768以下，批量数量为1，开启--xformers，模型使用fp16或safetensors格式，避免加载多个ControlNet模型。如果仍显存不足，可以开启--medvram或--lowvram，代价是生成速度下降。

CPU推理不是不能跑，但速度差异非常明显。同一张512x512图像，GPU可能只需要几秒，CPU可能需要几分钟甚至更久。CPU推理适合验证功能或处理极少量图片，不适合批量生产。做一个判断：如果你的日常工作流里需要每天产出几十张图，CPU方案基本不现实，至少需要一块二手NVIDIA入门卡。

性能观察的另一个重点是温度。长时间连续生成时，GPU温度可能升高，导致降频，最终表现为生成速度越来越慢。连续跑大任务时，可以观察nvidia-smi里的温度值，超过85摄氏度就要让机器休息或改善散热，而不是盲目加任务。

8. 常见问题与排查方法

下面整理一份高频问题排查表，覆盖从安装到批量任务的主要故障点：

这些问题的共性规律是：本地AI绘画软件依赖项多，出问题先看命令行日志，再按“模型文件是否放对、显存是否够、参数是否合理”的顺序排查，基本能覆盖80%的故障。

9. 最佳实践与使用建议

从工程角度看，本地AI绘画部署要想稳定好用，需要建立一套基本的使用规范。

第一，第一次测试时使用小参数。512x512分辨率、20步、批量1，先把流程跑通，再用大分辨率和高步数验证效果。不要一上来就尝试8K出图，显存溢出后很难判断是配置问题还是模型问题。

第二，目录结构要清晰。建议采用以下目录划分：

models/ 存放模型文件，按类型分目录 outputs/ 保存生成结果，按日期分目录 prompts/ 保存提示词文本，便于复用 logs/ 记录批量任务的输出日志

模型文件、输入素材、输出结果一定要分开。模型文件动辄几个G，不适合频繁移动；输出结果按日期和任务命名，方便后续回看。

第三，API服务只能监听内网。启动时使用默认的127.0.0.1监听，不要用0.0.0.0暴露到公网。如果团队内部需要共享，也要放在内网环境，并加一层访问控制。本地API一旦暴露，外部请求会不断消耗你的显存，严重影响任务执行。

第四，批量任务必须加日志与失败重试。你的脚本要记录每次请求的提示词、参数、输出文件名和错误信息。失败的任务不要立刻覆盖输出文件，而是单独存到一个failed目录，方便二次处理。

第五，使用自己的素材时，要注意授权边界。本地生成一张图用于自测没问题，但如果你要生成真人肖像的拟真图，必须获得对方明确授权；如果要模仿某位现役画师的风格做商业项目，同样需要得到授权。AI绘画不改变版权规则，只改变了创作方式。

第六，记录每张图的生成配置。WebUI生成的图片会自动嵌入参数信息，ComfyUI则通过工作流文件保存配置。需要复现时可以直接读取这些信息，避免靠记忆找回参数。

第七，模型不是越多越好。社区模型非常多，但真正适合你业务的可能只有两三个。先把一两个模型的特性摸透，再根据出图风格决定是否更换，不要把所有模型都堆进目录，浪费磁盘空间也会增加管理负担。

第八，发布或商用前做人工复核。本地AI绘画产物中可能包含模糊的文字、畸变的手部、不合逻辑的细节，这些在批量任务里很容易被忽略。人工复核不是可选步骤，而是发布前的必做动作。

10. 总结与下一步

回到ZHO那个观点：AI不是要把人类从“人类”这个身份里开除，而是在把“绘画执行”这件事从人类身上剥离。对那些长期靠手工绘制和修图吃饭的人来说，这种变化确实有冲击力；但从工具使用者的角度看，AI绘画更像是一个“意图放大器”——你越清楚自己想要什么，越会写提示词，越懂得筛选和修正结果，你的产出效率就越高。创作者从“画手”变成“导演”，这正是很多人尚未适应的新分工。

这篇文章覆盖了本地AI绘画部署所需的核心环节：环境准备、安装启动、文生图与图生图测试、ControlNet控制、API调用、批量任务、显存观察和常见问题排查。如果你正准备上手，建议第一步先跑通文生图和小批量任务，确认显卡驱动、模型路径和API调用都能正常工作；最容易踩的坑集中在依赖安装、模型放置位置和端口冲突这三个地方，遇到问题先看日志，不要盲目重装。

下一步的方向很清晰：一是研究ComfyUI的节点工作流，把生成流程固定成可复用的工作流文件；二是尝试LoRA训练，用你自己的图片集微调模型风格；三是把API接到内部工具或自动化流水线里，让AI绘画真正成为日常生产的稳定组件。建议先收藏这篇文章，动手部署时再对照各章节逐步操作。