很多朋友想出一张配图、封面或概念草图但一打开绘图软件就发现完全不知道从哪下笔。这篇文章不劝你去补美术基础而是把“出图”这件事拆成工具问题文字描述进电脑图片在本地生成。这样你就不会因为画不好而卡在第一张图上真正需要花时间的只是提示词和参数调试。如果你连本地部署都还没跑过看这一篇就够了。这次我们来看一套通用的本地文生图项目部署思路。它解决的正是“不会画画但需要出图”这个最直接的问题没有手绘能力不依赖在线服务只要电脑硬件能支撑你写一段描述模型就返回一张图片。本文会先给你一张核心能力速览再按“环境准备、启动部署、功能测试、接口调用、性能观察、问题排查”的顺序走一遍。不会写死版本号是因为这类项目更新太快同一个思路在不同版本上参数名和显存占用都会变按实际项目文档来最稳妥。如果按常见本地文生图工具的工作流跑通你得到的核心能力是文生图、图生图、负面提示词控制、固定随机种子复现、批量出图、HTTP 接口调用。这些能力足够覆盖个人博客配图、产品原型占位图、PPT 素材、课程封面这类日常需求。下面进入正题。1. 核心能力速览先把最关键的信息列出来。因为本文不绑定某一个固定仓库表格里凡是取决于具体版本的内容都会标注“以实际项目文档为准”。能力项说明主要用途用文本描述生成图片辅助零基础用户完成配图、草图、概念图核心功能文生图、图生图、局部重绘、负面提示词、固定随机种子、批量任务接口能力多数本地服务会提供 HTTP API具体路径和入参以项目文档为准启动方式命令行启动 WebUI、一键启动脚本、Docker 容器三者选一推荐硬件优先 NVIDIA 显卡没有 GPU 时 CPU 也能推理但出图速度会明显变慢显存占用不固定由模型版本、输出分辨率、采样步数共同决定需要本机实测支持平台Windows / Linux 最常见macOS 看具体项目是否适配上手难度不需要绘画基础但需要理解提示词、采样步数、分辨率、种子这几个概念适用场景自媒体配图、PPT 素材、产品原型图、教学设计配图、概念验证建议你保存这张表第一次跑任何本地文生图项目时先对着表格确认这台机器显卡什么型号显存多少系统是 Windows 还是 Linux能不能联网下载模型权重。把这几项确认完再动手后面会少踩很多坑。2. 适用场景与使用边界先说适合谁。如果你完全没有绘画基础但需要高频产出图片素材这类项目就很合适。尤其适合个人博主做文章封面和章节配图。产品经理画功能原型占位图。老师或运营人员做课件素材。开发者做工具 App 的图标草稿或空状态插画。独立游戏开发者快速验证美术方向。它能解决的问题是“从 0 到 1”快速产出可用的视觉方案。你不需要会构图不需要会调色只要能在提示词里把主体、环境、光线、风格描述清楚模型就能返回初稿。接着你再通过图生图、局部重绘把初稿往目标方向调整。它不适合什么场景也需要说清楚。如果你是要做精细的商业海报、品牌级视觉设计、讲究字体排版和图层结构的物料文生图工具只能给方向不能直接替代专业设计软件。另外以下情况必须严格注意涉及真实人物肖像时要确认已取得授权。使用他人画作、摄影作品、品牌素材做参考或训练要有授权或版权依据。不得用生成图片冒充他人身份不得规避平台安全机制。商用前要做效果复核原创性、可版权性、平台规则都要确认。技术工具本身是中性的但生成内容的使用边界由使用者负责。这篇文章后续所有测试都建议只生成普通静物、风景、日常物品这类安全素材。3. 环境准备与前置条件本地文生图项目对环境的依赖比较集中主要检查这五类。3.1 操作系统Windows 10 或 Windows 11 最常见很多一键包默认支持 Windows。Linux 服务器也可以跑而且更适合后期做 API 服务和批量任务。macOS 要看具体项目是否提供安装脚本不建议新手一上来就在 Mac 上折腾 CUDA 类项目。3.2 显卡与驱动NVIDIA 显卡是首选因为多数文生图推理框架对 CUDA 的优化最完整。安装前先查看驱动版本计算机管理里能看到显卡型号命令行的查看方式是nvidia-smi如果提示命令不存在说明驱动工具没有配置到环境变量可以到 NVIDIA 官网更新驱动后重试。检查显卡后要记录显存大小。显存大小直接影响你能跑多大分辨率、多复杂的模型但具体数字要结合模型版本实测不能只凭显卡型号判断。3.3 Python 和依赖管理很多源码项目要求 Python 3.10 或更高版本但不同项目对版本的要求不一样。建议先装 Anaconda 或 Miniconda方便创建独立环境。不建议直接往系统 Python 里装依赖因为本地文生图项目依赖很多装在系统环境里容易和日常开发工具冲突。3.4 磁盘空间模型权重文件通常很大从 2GB 到十几 GB 都很常见。部署前至少准备 20GB 空闲磁盘最好是 SSD。下载模型时要注意网络环境大文件下载中断后要能断点续传很多下载工具支持这个功能。3.5 路径和端口两个最常见的启动失败原因一是项目目录路径里有中文或空格导致模型加载失败二是 7860 端口被其他程序占用。建议项目目录用纯英文比如D:\ai-drawing。启动前可以用命令看端口占用netstat -ano | findstr 7860如果输出为空说明端口没有被占用。如果看到端口被占用就换一个大于 10000 的端口启动。4. 安装部署与启动方式部署方式一般有三种源码安装、一键启动包、Docker 容器。这里给出一套通用流程具体命令中的路径、Python 版本、端口都要按你实际拿到的项目文档调整。4.1 源码方式启动源码方式步骤多但可控性最好便于排查问题。# 进入项目根目录请替换成你的实际项目目录 cd ai-drawing # 创建虚拟环境Linux/macOS 命令示例 python3 -m venv venv source venv/bin/activate # Windows 下激活虚拟环境 # venv\Scripts\activate # 安装依赖requirements.txt 是常见命名按实际项目文档来 pip install -r requirements.txt # 下载模型权重放到模型目录目录名以文档为准 # 例如 checkpoints/ 或 models/Stable-diffusion/ # 启动本地 WebUI主机和端口以文档为准 python launch.py --host 127.0.0.1 --port 7860第一次启动时间会比较长因为要加载模型权重到内存或显存。启动完成后浏览器打开http://127.0.0.1:7860应该能看到一个 Web 界面。如果页面打不开先看终端里的日志90% 的问题会在日志里直接体现。4.2 一键启动包方式如果你用的是社区制作的一键整合包操作更简单解压到纯英文目录双击启动脚本即可。整合包通常已经内置 Python 环境和模型文件适合第一次体验。使用一键包时要留意两点一是启动脚本会临时占用终端别在启动过程中关闭窗口二是模型文件不要擅自移动位置整合包内部路径是固定的。4.3 Docker 方式如果你想做成服务Docker 方式更干净适合部署到 Linux 服务器。但这需要显卡直通支持。# docker run 模板镜像名和参数以项目文档为准 docker run --gpus all -p 7860:7860 \ -v /your/models:/app/models \ -v /your/outputs:/app/outputs \ your-docker-image:latest参数解释--gpus all让容器可以使用宿主机显卡-p映射端口-v把模型目录和输出目录挂载出来。启动后同样访问http://127.0.0.1:7860。4.4 访问与停止访问地址建议直接用127.0.0.1不要用localhost。有些项目对这两个域名的处理不一致。停止服务时在启动服务的终端里按Ctrl C即可。遇到页面突然无响应再检查是不是前端口被占。5. 功能测试与效果验证部署完成只是第一步关键要验证功能是否正常。每个功能测试都按“输入什么、操作什么、预期什么、失败查什么”这四步来走。5.1 文生图基础测试测试目的确认模型能根据文本输出图片。操作步骤在提示词输入框写一个简单的英文或中文描述点击生成。示例提示词a small wooden table beside a window, soft daylight预期结果界面返回一张 512x512 或默认分辨率的图片图片主体和提示词相关。输出目录中出现新文件。判断成功的标准有三个有图片返回、图片没有全黑或全灰、提示词主要元素在图片里能辨认出来。如果失败优先查看终端日志。常见原因包括模型权重没有加载成功、显存不足、采样器参数不合法。5.2 负面提示词测试测试目的验证负面提示词是否真的起作用。操作步骤在负面提示词栏输入blurry, low quality, watermark, extra fingers同时把提示词改成人物描述例如a young man walking in the rain, street lamp, night scene预期结果生成结果中明显减少模糊、水印、手指畸形等问题。有些模型训练强度不同负面提示词效果也会有差异。如果几个负面词并没有减少对应问题说明你选的模型对这部分强调度不够可以后续用更高权重或更换模型。5.3 固定随机种子复现测试目的验证同一种子能否复现相似构图。操作步骤生成第一张图后把这条生成记录的随机种子记录到“种子”输入框其他参数保持相同再次生成。预期结果第二次生成的图片和第一次非常接近。如果项目支持全部参数复现图片应该几乎一致。这个功能对批量素材生成很重要你可以先锁定构图再通过局部重绘做微调。5.4 图生图测试测试目的验证基于已有图片再生成的能力。操作步骤上传一张本地普通照片或生成图设定一个重绘幅度参数输入新的描述词。示例提示词turn this table into a white marble table预期结果输出图片在保留原图基础结构的前提下体现新描述。调整重绘幅度数值越高改动越大。如果输出图片和原图差别很小可以适当调高重绘幅度。5.5 局部重绘测试测试目的验证只修改图片局部区域的能力。操作步骤在图生图功能里上传图片用蒙版工具涂抹需要修改的区域比如桌子上的水杯然后输入replace the cup with a laptop预期结果只有涂抹区域被改变未涂抹区域保持基本不变。这个功能很实用尤其适合先定构图再换局部元素。如果整张图都变化说明蒙版区域设置过大或者项目使用的模型对重绘区域不敏感。5.6 分辨率测试测试目的找到你的显卡能稳定运行的分辨率区间。操作步骤分别用 512x512、768x768、1024x1024 三个分辨率生成同一提示词。预期结果分辨率越大生成耗时越长显存占用越高。如果某个分辨率直接报“CUDA out of memory”或生成失败说明当前模型加当前分辨率已经超过你的显存上限要缩小分辨率或降低批次数量。6. 接口 API 与批量任务文生图项目如果只能网页点按钮很难接入真实工作流。很多本地文生图服务会提供 HTTP 接口把图片生成变成一个个可编程的请求这样就能做批量配图和自动化任务。6.1 先确认接口路径不同项目的接口路径差异很大常见的有/api/generate、/generate、/sdapi/v1/txt2img等。文章里的请求示例不能直接当结论用你必须先看实际项目文档或直接打开http://127.0.0.1:7860/docs看接口列表。6.2 单个请求测试假设服务地址是http://127.0.0.1:7860接口路径以实际文档为准先启动服务再写一个最小请求脚本import requests API_URL http://127.0.0.1:7860/api/generate # 按实际文档替换 payload { prompt: a small wooden table beside a window, soft daylight, negative_prompt: blurry, low quality, watermark, steps: 20, width: 512, height: 512, seed: -1 } response requests.post(API_URL, jsonpayload, timeout300) print(response.status_code) if response.ok: data response.json() print(data.keys()) # 图片可能在 data[images] 或 data[output]以文档为准 else: print(response.text)代码里面的timeout300很重要。生成图片不是秒级返回复杂任务可能要几十秒甚至几分钟请求超时时间要放宽。6.3 保存图片接口返回的图片可能是 base64 字符串也可能是磁盘文件路径。假设返回体中有images字段且第一项是 base64 编码那么保存方式如下from pathlib import Path import base64 # 以 response 返回的实际数据为准 images data.get(images) if images: img_str images[0] # 去掉 data:image/png;base64, 前缀如果存在 if , in img_str: img_str img_str.split(,, 1)[1] output_path Path(outputs/sample.png) output_path.parent.mkdir(parentsTrue, exist_okTrue) output_path.write_bytes(base64.b64decode(img_str)) print(fsaved to {output_path})如果项目返回的是文件路径那就直接读取该路径下的文件不需要 base64 解压。6.4 批量任务设计批量任务的关键不是把循环写出来而是把任务分成能重试的小单位。一个通用批量流程是读提示词列表逐个请求每个请求单独保存结果失败时记录到日志不中断整个队列。import time import requests API_URL http://127.0.0.1:7860/api/generate # 按实际文档替换 prompts [ a red mug on a desk, daylight, a green cactus in a white pot, studio light, a stack of notebooks on a wooden shelf, ] payload { negative_prompt: blurry, low quality, steps: 20, width: 512, height: 512, } for idx, prompt in enumerate(prompts, 1): payload[prompt] prompt try: resp requests.post(API_URL, jsonpayload, timeout300) resp.raise_for_status() data resp.json() images data.get(images) if images: out_file foutputs/image_{idx:03d}.png # 按 6.3 节的保存方式写文件 print(f{idx}: ok - {out_file}) else: print(f{idx}: no image in response) except Exception as exc: print(f{idx}: failed - {exc}) time.sleep(1)实际生产环境的批量任务会比这个复杂。建议加上每个任务写独立日志。请求失败后重试 2 到 3 次重试之间加延时。输出文件名要包含提示词序号和种子信息。批量规模大时控制并发数避免显存瞬间打满。如果项目有任务队列接口优先用队列而不是多线程并发。文生图的瓶颈通常在显存并发过高不仅不会加速反而会频繁触发 OOM。7. 资源占用与性能观察本地文生图项目值不值得长期跑关键看资源占用。这里给出一套观察方法不写死具体显存数字因为同一个模型在不同分辨率和采样步数下的差异非常明显。显存观察直接使用系统监控命令# Windows 和 Linux 通用实时刷新显存情况 nvidia-smi启动服务前记录一次空闲显存。生成第一张图时观察显存数值变化。生成结束后再观察显存是否回落。很多框架为了减少重复加载模型会常驻显存这是正常的。显存占用不降不等于程序出了问题。分辨率对性能的影响最直接。从 512x512 提高到 1024x1024计算量不是简单翻倍而是明显上升。采样步数同理步数越多生成时间越长但图像质量不一定是线性提升。通常是先固定一个步数区间做测试而不是一上来就用最高步数。CPU 推理和 GPU 推理的差异需要单独说。CPU 可以跑但速度通常会慢很多甚至慢一个数量级。如果你的电脑是核显或无独立显卡第一张图生成要耐心等待先不要判断项目卡死。降低资源占用的通用手段主要有降低输出分辨率。缩小批量数量批量先填 1。降低采样步数比如先用 20 步测试。使用量化版模型或小尺寸模型。关闭其他占显存的软件。部分框架支持显存自动释放可以看文档开启。判断性能是否够用只有一条标准生成一张可用图片的耗时和显存占用你是否能接受。如果临时出图慢一点也能等到如果每天要生成几十张那就必须优化参数或考虑更高配置的机器。8. 常见问题与排查方法第一次跑本地文生图项目遇到的问题基本都是环境问题。下面这张表覆盖最常见的现象和排查路径。问题现象可能原因排查方式解决方案启动后页面打不开端口被占用或服务未启动查看终端日志、检查端口占用更换端口或重启服务依赖安装失败Python 版本不匹配、依赖冲突查看 pip 错误信息新建虚拟环境按文档指定版本安装模型文件缺失权重没下载或放错目录检查模型目录对比文档要求重新下载权重放到正确目录CUDA 报错显卡驱动或 CUDA 版本不匹配用nvidia-smi查看驱动更新驱动或安装 CPU 版推理依赖显存不足分辨率过高、模型过大、批量数过大日志中出现 out of memory降低分辨率、降低步数、批量改为 1生成全黑图模型加载异常或输出通道错误查看控制台日志验证模型文件是否完整换一个权重测试接口调用 404接口路径不对查看接口文档或 /docs 页面替换为正确路径批量任务卡住单张图片生成时间过长或显存不足查看进程日志缩小任务规模逐条重试输出质量不稳定提示词太简短、步数太低、模型不适合题材对比同种子不同参数增加提示词细节调高采样步数换模型测试第二次启动比第一次慢模型文件反复校验或磁盘缓存异常查看启动日志清理缓存目录确认模型是否重新加载排查的基本原则是先看日志再改参数。不要凭感觉乱改配置。日志里通常包含“模型加载失败”“端口占用”“路径不存在”“CUDA 内存不足”这类明确线索。如果启动日志里出现大量红色错误也不要直接放弃。很多项目在启动时会扫描多个组件部分警告不影响主功能。判断标准很简单网页能否正常打开图片能否正常生成。只要这两个能跑通警告可以先忽略。9. 最佳实践与使用建议本地文生图项目上手不难但要用得稳建议从一开始就建立一套工作习惯。第一次体验先用最小参数。分辨率 512x512采样步数用 20批量调成 1提示词只写一个主体加一个环境。这样能把“管道是否畅通”和“效果是否满意”两个问题分开验证。不要一上来就挑战 1024 分辨率加复杂提示词否则出了问题很难定位是硬件、模型还是提示词的问题。项目文件建议按这个结构管理ai-drawing/ checkpoints/ models/ inputs/ outputs/ logs/checkpoints主模型文件。models外挂模型或辅助模型。inputs图生图、局部重绘的输入图片。outputs生成结果并按日期或任务名分目录。logs启动日志、批量任务日志、错误记录。输出目录分开的好处是批量生成几百张图后你能按任务定位图片。建议每个批次的输出文件名带上任务编号和种子例如task01_seed100023.png方便复现。接口服务要注意访问范围。如果只是本机使用启动时监听地址写127.0.0.1不要把端口直接暴露到公网。如果需要局域网调用也要加访问限制。生成服务的原始接口不面向公网设计暴露出去容易被人大量调用挤占显卡资源。遇到效果不理想时不要立刻怀疑模型坏了。先固定一个种子然后分别调整提示词和采样步数做简单的对照测试。每一次改动只改一个变量这是排查生成质量问题的最有效方法。合规方面任何涉及真人面部、他人创作风格、品牌标志、受版权保护角色的素材都必须先确认授权。尤其不能拿他人肖像做未授权的生成也不要把生成图伪装成真人照片。商用前要重新审视提示词中使用的艺术风格是否涉及侵权风险。10. 总结与下一步如果你想试第一个动作不是急着下载大模型而是先跑通一个最小测试写一段描述生成一张 512x512 的普通物品图。这能最快验证你的机器能不能跑项目环境有没有装对。最容易踩的坑有三个模型文件放错目录、路径里有中文、批量数一开始就调太高。前两个会导致启动失败或页面无响应第三个会导致显存直接溢出。记住这三条你第一次部署的成功率会明显提升。接下来可以逐步扩展先做图生图再试局部重绘然后尝试固定种子生成系列配图。等你熟悉了这些基本操作就可以转向 API 调用和批量任务把这套能力接进自己的内容生产流程。如果你对自动跑图有兴趣先从批量提示词列表开始批量任务最好是“每张图单独请求、单独保存、失败重试”的模型而不是一次性并发打满显存。这套方法不依赖某个特定仓库只要你以后看到任何本地文生图项目都能用它快速评估、安装、测试和排错。希望能帮你从“不会画画已急哭”的状态顺利过渡到“写提示词就能出图”的状态。 
长河君 · 2026/10/15 21:41:36 · 阅读 1.2k 本地文生图项目部署指南：零基础用提示词生成配图
很多朋友想出一张配图、封面或概念草图但一打开绘图软件就发现完全不知道从哪下笔。这篇文章不劝你去补美术基础而是把“出图”这件事拆成工具问题文字描述进电脑图片在本地生成。这样你就不会因为画不好而卡在第一张图上真正需要花时间的只是提示词和参数调试。如果你连本地部署都还没跑过看这一篇就够了。这次我们来看一套通用的本地文生图项目部署思路。它解决的正是“不会画画但需要出图”这个最直接的问题没有手绘能力不依赖在线服务只要电脑硬件能支撑你写一段描述模型就返回一张图片。本文会先给你一张核心能力速览再按“环境准备、启动部署、功能测试、接口调用、性能观察、问题排查”的顺序走一遍。不会写死版本号是因为这类项目更新太快同一个思路在不同版本上参数名和显存占用都会变按实际项目文档来最稳妥。如果按常见本地文生图工具的工作流跑通你得到的核心能力是文生图、图生图、负面提示词控制、固定随机种子复现、批量出图、HTTP 接口调用。这些能力足够覆盖个人博客配图、产品原型占位图、PPT 素材、课程封面这类日常需求。下面进入正题。1. 核心能力速览先把最关键的信息列出来。因为本文不绑定某一个固定仓库表格里凡是取决于具体版本的内容都会标注“以实际项目文档为准”。能力项说明主要用途用文本描述生成图片辅助零基础用户完成配图、草图、概念图核心功能文生图、图生图、局部重绘、负面提示词、固定随机种子、批量任务接口能力多数本地服务会提供 HTTP API具体路径和入参以项目文档为准启动方式命令行启动 WebUI、一键启动脚本、Docker 容器三者选一推荐硬件优先 NVIDIA 显卡没有 GPU 时 CPU 也能推理但出图速度会明显变慢显存占用不固定由模型版本、输出分辨率、采样步数共同决定需要本机实测支持平台Windows / Linux 最常见macOS 看具体项目是否适配上手难度不需要绘画基础但需要理解提示词、采样步数、分辨率、种子这几个概念适用场景自媒体配图、PPT 素材、产品原型图、教学设计配图、概念验证建议你保存这张表第一次跑任何本地文生图项目时先对着表格确认这台机器显卡什么型号显存多少系统是 Windows 还是 Linux能不能联网下载模型权重。把这几项确认完再动手后面会少踩很多坑。2. 适用场景与使用边界先说适合谁。如果你完全没有绘画基础但需要高频产出图片素材这类项目就很合适。尤其适合个人博主做文章封面和章节配图。产品经理画功能原型占位图。老师或运营人员做课件素材。开发者做工具 App 的图标草稿或空状态插画。独立游戏开发者快速验证美术方向。它能解决的问题是“从 0 到 1”快速产出可用的视觉方案。你不需要会构图不需要会调色只要能在提示词里把主体、环境、光线、风格描述清楚模型就能返回初稿。接着你再通过图生图、局部重绘把初稿往目标方向调整。它不适合什么场景也需要说清楚。如果你是要做精细的商业海报、品牌级视觉设计、讲究字体排版和图层结构的物料文生图工具只能给方向不能直接替代专业设计软件。另外以下情况必须严格注意涉及真实人物肖像时要确认已取得授权。使用他人画作、摄影作品、品牌素材做参考或训练要有授权或版权依据。不得用生成图片冒充他人身份不得规避平台安全机制。商用前要做效果复核原创性、可版权性、平台规则都要确认。技术工具本身是中性的但生成内容的使用边界由使用者负责。这篇文章后续所有测试都建议只生成普通静物、风景、日常物品这类安全素材。3. 环境准备与前置条件本地文生图项目对环境的依赖比较集中主要检查这五类。3.1 操作系统Windows 10 或 Windows 11 最常见很多一键包默认支持 Windows。Linux 服务器也可以跑而且更适合后期做 API 服务和批量任务。macOS 要看具体项目是否提供安装脚本不建议新手一上来就在 Mac 上折腾 CUDA 类项目。3.2 显卡与驱动NVIDIA 显卡是首选因为多数文生图推理框架对 CUDA 的优化最完整。安装前先查看驱动版本计算机管理里能看到显卡型号命令行的查看方式是nvidia-smi如果提示命令不存在说明驱动工具没有配置到环境变量可以到 NVIDIA 官网更新驱动后重试。检查显卡后要记录显存大小。显存大小直接影响你能跑多大分辨率、多复杂的模型但具体数字要结合模型版本实测不能只凭显卡型号判断。3.3 Python 和依赖管理很多源码项目要求 Python 3.10 或更高版本但不同项目对版本的要求不一样。建议先装 Anaconda 或 Miniconda方便创建独立环境。不建议直接往系统 Python 里装依赖因为本地文生图项目依赖很多装在系统环境里容易和日常开发工具冲突。3.4 磁盘空间模型权重文件通常很大从 2GB 到十几 GB 都很常见。部署前至少准备 20GB 空闲磁盘最好是 SSD。下载模型时要注意网络环境大文件下载中断后要能断点续传很多下载工具支持这个功能。3.5 路径和端口两个最常见的启动失败原因一是项目目录路径里有中文或空格导致模型加载失败二是 7860 端口被其他程序占用。建议项目目录用纯英文比如D:\ai-drawing。启动前可以用命令看端口占用netstat -ano | findstr 7860如果输出为空说明端口没有被占用。如果看到端口被占用就换一个大于 10000 的端口启动。4. 安装部署与启动方式部署方式一般有三种源码安装、一键启动包、Docker 容器。这里给出一套通用流程具体命令中的路径、Python 版本、端口都要按你实际拿到的项目文档调整。4.1 源码方式启动源码方式步骤多但可控性最好便于排查问题。# 进入项目根目录请替换成你的实际项目目录 cd ai-drawing # 创建虚拟环境Linux/macOS 命令示例 python3 -m venv venv source venv/bin/activate # Windows 下激活虚拟环境 # venv\Scripts\activate # 安装依赖requirements.txt 是常见命名按实际项目文档来 pip install -r requirements.txt # 下载模型权重放到模型目录目录名以文档为准 # 例如 checkpoints/ 或 models/Stable-diffusion/ # 启动本地 WebUI主机和端口以文档为准 python launch.py --host 127.0.0.1 --port 7860第一次启动时间会比较长因为要加载模型权重到内存或显存。启动完成后浏览器打开http://127.0.0.1:7860应该能看到一个 Web 界面。如果页面打不开先看终端里的日志90% 的问题会在日志里直接体现。4.2 一键启动包方式如果你用的是社区制作的一键整合包操作更简单解压到纯英文目录双击启动脚本即可。整合包通常已经内置 Python 环境和模型文件适合第一次体验。使用一键包时要留意两点一是启动脚本会临时占用终端别在启动过程中关闭窗口二是模型文件不要擅自移动位置整合包内部路径是固定的。4.3 Docker 方式如果你想做成服务Docker 方式更干净适合部署到 Linux 服务器。但这需要显卡直通支持。# docker run 模板镜像名和参数以项目文档为准 docker run --gpus all -p 7860:7860 \ -v /your/models:/app/models \ -v /your/outputs:/app/outputs \ your-docker-image:latest参数解释--gpus all让容器可以使用宿主机显卡-p映射端口-v把模型目录和输出目录挂载出来。启动后同样访问http://127.0.0.1:7860。4.4 访问与停止访问地址建议直接用127.0.0.1不要用localhost。有些项目对这两个域名的处理不一致。停止服务时在启动服务的终端里按Ctrl C即可。遇到页面突然无响应再检查是不是前端口被占。5. 功能测试与效果验证部署完成只是第一步关键要验证功能是否正常。每个功能测试都按“输入什么、操作什么、预期什么、失败查什么”这四步来走。5.1 文生图基础测试测试目的确认模型能根据文本输出图片。操作步骤在提示词输入框写一个简单的英文或中文描述点击生成。示例提示词a small wooden table beside a window, soft daylight预期结果界面返回一张 512x512 或默认分辨率的图片图片主体和提示词相关。输出目录中出现新文件。判断成功的标准有三个有图片返回、图片没有全黑或全灰、提示词主要元素在图片里能辨认出来。如果失败优先查看终端日志。常见原因包括模型权重没有加载成功、显存不足、采样器参数不合法。5.2 负面提示词测试测试目的验证负面提示词是否真的起作用。操作步骤在负面提示词栏输入blurry, low quality, watermark, extra fingers同时把提示词改成人物描述例如a young man walking in the rain, street lamp, night scene预期结果生成结果中明显减少模糊、水印、手指畸形等问题。有些模型训练强度不同负面提示词效果也会有差异。如果几个负面词并没有减少对应问题说明你选的模型对这部分强调度不够可以后续用更高权重或更换模型。5.3 固定随机种子复现测试目的验证同一种子能否复现相似构图。操作步骤生成第一张图后把这条生成记录的随机种子记录到“种子”输入框其他参数保持相同再次生成。预期结果第二次生成的图片和第一次非常接近。如果项目支持全部参数复现图片应该几乎一致。这个功能对批量素材生成很重要你可以先锁定构图再通过局部重绘做微调。5.4 图生图测试测试目的验证基于已有图片再生成的能力。操作步骤上传一张本地普通照片或生成图设定一个重绘幅度参数输入新的描述词。示例提示词turn this table into a white marble table预期结果输出图片在保留原图基础结构的前提下体现新描述。调整重绘幅度数值越高改动越大。如果输出图片和原图差别很小可以适当调高重绘幅度。5.5 局部重绘测试测试目的验证只修改图片局部区域的能力。操作步骤在图生图功能里上传图片用蒙版工具涂抹需要修改的区域比如桌子上的水杯然后输入replace the cup with a laptop预期结果只有涂抹区域被改变未涂抹区域保持基本不变。这个功能很实用尤其适合先定构图再换局部元素。如果整张图都变化说明蒙版区域设置过大或者项目使用的模型对重绘区域不敏感。5.6 分辨率测试测试目的找到你的显卡能稳定运行的分辨率区间。操作步骤分别用 512x512、768x768、1024x1024 三个分辨率生成同一提示词。预期结果分辨率越大生成耗时越长显存占用越高。如果某个分辨率直接报“CUDA out of memory”或生成失败说明当前模型加当前分辨率已经超过你的显存上限要缩小分辨率或降低批次数量。6. 接口 API 与批量任务文生图项目如果只能网页点按钮很难接入真实工作流。很多本地文生图服务会提供 HTTP 接口把图片生成变成一个个可编程的请求这样就能做批量配图和自动化任务。6.1 先确认接口路径不同项目的接口路径差异很大常见的有/api/generate、/generate、/sdapi/v1/txt2img等。文章里的请求示例不能直接当结论用你必须先看实际项目文档或直接打开http://127.0.0.1:7860/docs看接口列表。6.2 单个请求测试假设服务地址是http://127.0.0.1:7860接口路径以实际文档为准先启动服务再写一个最小请求脚本import requests API_URL http://127.0.0.1:7860/api/generate # 按实际文档替换 payload { prompt: a small wooden table beside a window, soft daylight, negative_prompt: blurry, low quality, watermark, steps: 20, width: 512, height: 512, seed: -1 } response requests.post(API_URL, jsonpayload, timeout300) print(response.status_code) if response.ok: data response.json() print(data.keys()) # 图片可能在 data[images] 或 data[output]以文档为准 else: print(response.text)代码里面的timeout300很重要。生成图片不是秒级返回复杂任务可能要几十秒甚至几分钟请求超时时间要放宽。6.3 保存图片接口返回的图片可能是 base64 字符串也可能是磁盘文件路径。假设返回体中有images字段且第一项是 base64 编码那么保存方式如下from pathlib import Path import base64 # 以 response 返回的实际数据为准 images data.get(images) if images: img_str images[0] # 去掉 data:image/png;base64, 前缀如果存在 if , in img_str: img_str img_str.split(,, 1)[1] output_path Path(outputs/sample.png) output_path.parent.mkdir(parentsTrue, exist_okTrue) output_path.write_bytes(base64.b64decode(img_str)) print(fsaved to {output_path})如果项目返回的是文件路径那就直接读取该路径下的文件不需要 base64 解压。6.4 批量任务设计批量任务的关键不是把循环写出来而是把任务分成能重试的小单位。一个通用批量流程是读提示词列表逐个请求每个请求单独保存结果失败时记录到日志不中断整个队列。import time import requests API_URL http://127.0.0.1:7860/api/generate # 按实际文档替换 prompts [ a red mug on a desk, daylight, a green cactus in a white pot, studio light, a stack of notebooks on a wooden shelf, ] payload { negative_prompt: blurry, low quality, steps: 20, width: 512, height: 512, } for idx, prompt in enumerate(prompts, 1): payload[prompt] prompt try: resp requests.post(API_URL, jsonpayload, timeout300) resp.raise_for_status() data resp.json() images data.get(images) if images: out_file foutputs/image_{idx:03d}.png # 按 6.3 节的保存方式写文件 print(f{idx}: ok - {out_file}) else: print(f{idx}: no image in response) except Exception as exc: print(f{idx}: failed - {exc}) time.sleep(1)实际生产环境的批量任务会比这个复杂。建议加上每个任务写独立日志。请求失败后重试 2 到 3 次重试之间加延时。输出文件名要包含提示词序号和种子信息。批量规模大时控制并发数避免显存瞬间打满。如果项目有任务队列接口优先用队列而不是多线程并发。文生图的瓶颈通常在显存并发过高不仅不会加速反而会频繁触发 OOM。7. 资源占用与性能观察本地文生图项目值不值得长期跑关键看资源占用。这里给出一套观察方法不写死具体显存数字因为同一个模型在不同分辨率和采样步数下的差异非常明显。显存观察直接使用系统监控命令# Windows 和 Linux 通用实时刷新显存情况 nvidia-smi启动服务前记录一次空闲显存。生成第一张图时观察显存数值变化。生成结束后再观察显存是否回落。很多框架为了减少重复加载模型会常驻显存这是正常的。显存占用不降不等于程序出了问题。分辨率对性能的影响最直接。从 512x512 提高到 1024x1024计算量不是简单翻倍而是明显上升。采样步数同理步数越多生成时间越长但图像质量不一定是线性提升。通常是先固定一个步数区间做测试而不是一上来就用最高步数。CPU 推理和 GPU 推理的差异需要单独说。CPU 可以跑但速度通常会慢很多甚至慢一个数量级。如果你的电脑是核显或无独立显卡第一张图生成要耐心等待先不要判断项目卡死。降低资源占用的通用手段主要有降低输出分辨率。缩小批量数量批量先填 1。降低采样步数比如先用 20 步测试。使用量化版模型或小尺寸模型。关闭其他占显存的软件。部分框架支持显存自动释放可以看文档开启。判断性能是否够用只有一条标准生成一张可用图片的耗时和显存占用你是否能接受。如果临时出图慢一点也能等到如果每天要生成几十张那就必须优化参数或考虑更高配置的机器。8. 常见问题与排查方法第一次跑本地文生图项目遇到的问题基本都是环境问题。下面这张表覆盖最常见的现象和排查路径。问题现象可能原因排查方式解决方案启动后页面打不开端口被占用或服务未启动查看终端日志、检查端口占用更换端口或重启服务依赖安装失败Python 版本不匹配、依赖冲突查看 pip 错误信息新建虚拟环境按文档指定版本安装模型文件缺失权重没下载或放错目录检查模型目录对比文档要求重新下载权重放到正确目录CUDA 报错显卡驱动或 CUDA 版本不匹配用nvidia-smi查看驱动更新驱动或安装 CPU 版推理依赖显存不足分辨率过高、模型过大、批量数过大日志中出现 out of memory降低分辨率、降低步数、批量改为 1生成全黑图模型加载异常或输出通道错误查看控制台日志验证模型文件是否完整换一个权重测试接口调用 404接口路径不对查看接口文档或 /docs 页面替换为正确路径批量任务卡住单张图片生成时间过长或显存不足查看进程日志缩小任务规模逐条重试输出质量不稳定提示词太简短、步数太低、模型不适合题材对比同种子不同参数增加提示词细节调高采样步数换模型测试第二次启动比第一次慢模型文件反复校验或磁盘缓存异常查看启动日志清理缓存目录确认模型是否重新加载排查的基本原则是先看日志再改参数。不要凭感觉乱改配置。日志里通常包含“模型加载失败”“端口占用”“路径不存在”“CUDA 内存不足”这类明确线索。如果启动日志里出现大量红色错误也不要直接放弃。很多项目在启动时会扫描多个组件部分警告不影响主功能。判断标准很简单网页能否正常打开图片能否正常生成。只要这两个能跑通警告可以先忽略。9. 最佳实践与使用建议本地文生图项目上手不难但要用得稳建议从一开始就建立一套工作习惯。第一次体验先用最小参数。分辨率 512x512采样步数用 20批量调成 1提示词只写一个主体加一个环境。这样能把“管道是否畅通”和“效果是否满意”两个问题分开验证。不要一上来就挑战 1024 分辨率加复杂提示词否则出了问题很难定位是硬件、模型还是提示词的问题。项目文件建议按这个结构管理ai-drawing/ checkpoints/ models/ inputs/ outputs/ logs/checkpoints主模型文件。models外挂模型或辅助模型。inputs图生图、局部重绘的输入图片。outputs生成结果并按日期或任务名分目录。logs启动日志、批量任务日志、错误记录。输出目录分开的好处是批量生成几百张图后你能按任务定位图片。建议每个批次的输出文件名带上任务编号和种子例如task01_seed100023.png方便复现。接口服务要注意访问范围。如果只是本机使用启动时监听地址写127.0.0.1不要把端口直接暴露到公网。如果需要局域网调用也要加访问限制。生成服务的原始接口不面向公网设计暴露出去容易被人大量调用挤占显卡资源。遇到效果不理想时不要立刻怀疑模型坏了。先固定一个种子然后分别调整提示词和采样步数做简单的对照测试。每一次改动只改一个变量这是排查生成质量问题的最有效方法。合规方面任何涉及真人面部、他人创作风格、品牌标志、受版权保护角色的素材都必须先确认授权。尤其不能拿他人肖像做未授权的生成也不要把生成图伪装成真人照片。商用前要重新审视提示词中使用的艺术风格是否涉及侵权风险。10. 总结与下一步如果你想试第一个动作不是急着下载大模型而是先跑通一个最小测试写一段描述生成一张 512x512 的普通物品图。这能最快验证你的机器能不能跑项目环境有没有装对。最容易踩的坑有三个模型文件放错目录、路径里有中文、批量数一开始就调太高。前两个会导致启动失败或页面无响应第三个会导致显存直接溢出。记住这三条你第一次部署的成功率会明显提升。接下来可以逐步扩展先做图生图再试局部重绘然后尝试固定种子生成系列配图。等你熟悉了这些基本操作就可以转向 API 调用和批量任务把这套能力接进自己的内容生产流程。如果你对自动跑图有兴趣先从批量提示词列表开始批量任务最好是“每张图单独请求、单独保存、失败重试”的模型而不是一次性并发打满显存。这套方法不依赖某个特定仓库只要你以后看到任何本地文生图项目都能用它快速评估、安装、测试和排错。希望能帮你从“不会画画已急哭”的状态顺利过渡到“写提示词就能出图”的状态。