本地部署ComfyUI+LoRA，构建角色一致性批量图像生成工作流

“全世界都想亲吻迪克格雷森”——这句话你多半在某个同人圈、超英讨论组或者角色人气汇总帖里见过。放在技术语境里看，它真正想表达的是：一个高人气角色，在全网有大量同人图像、壁纸、排版素材、风格化头像需求。手动一张张找图、修图、统一画风，效率太低。所以这次我们解决的问题很直接：如何用本地部署的 ComfyUI 工作流，配合角色一致性模型和 LoRA，把“生成一张迪克格雷森风格图”变成可批量、可复现、可接到 API 里的生产流程。

这个方案不是只能套在迪克格雷森身上。角色可以是原创 IP，也可以是自有版权素材中的固定角色。整条链路包括本地模型部署、提示词控制、参考图引导、批量生成、接口调用和显存观察。下面会把环境准备、启动方式、功能测试、批量任务、API 调用和排错清单全部过一遍，读完你就能在自己的机器上搭出一套角色图像生成工作台。

1. 核心能力速览

上面这张表是整个方案的骨架。接下来要说明的是：这样一个工作流到底适合谁，哪些场景能直接受益，又有哪些边界必须提前划清楚。

2. 适用场景与使用边界

这个方案最适合三类人。第一类是内容创作者，需要为一个固定角色持续产出多张风格相近的图像素材；第二类是技术集成者，想在自己开发的工具、网站或小程序里接一个“角色图像生成”接口；第三类是本地部署爱好者，希望在不上传隐私素材的前提下，用本地模型完成图像生成和批量处理。

先说能解决的典型问题。比如你想做一组“迪克格雷森从罗宾到夜翼再到蝙蝠侠时期”的角色成长图集，需要保证每一张图里人物形象一致。手动生图时，每张图都可能脸型漂移、服装细节对不上，而通过参考图约束和角色关键词模板，可以把一致性拉高。另一个典型问题是批量修图：已经有几十张角色原图，需要统一改成横版海报比例、统一补全背景，这一类任务用局部重绘和低步数批量生成就能很快跑完。

不适合的场景也要讲清楚。第一，不适合直接商用未授权 IP 角色。迪克格雷森是 DC 旗下角色，粉丝创作以个人学习、同人交流为限，一旦用于商品销售、品牌联名或付费服务，必须获得版权方授权。第二，不适合用来生成真人演员的换脸图，尤其不能在没有肖像授权的情况下处理真实人物。第三，如果你的素材本身包含敏感服饰、暴力元素或不适合公开传播的内容，本地生成可以，但不要发布和传播。

合规边界这里再强调一次：涉及角色版权、真人肖像、音乐音色、隐私数据时，先确认授权范围，再决定是否使用这套工作流。技术本身是中立的，但使用场景必须自己把关。

3. 本地部署环境准备

在动手之前，先按下面的检查清单过一遍环境。ComfyUI 本身对系统限制不多，真正决定能不能跑的是显卡驱动、显存大小、Python 版本和磁盘空间。

操作系统方面，Windows 10/11、Ubuntu 20.04 及以上、macOS 都能运行。Windows 用户注意，ComfyUI 的启动脚本对中文路径支持一般，项目目录最好放在纯英文路径下，比如D:\ComfyUI，避免因为路径里带中文导致模型加载失败。

显卡是关键硬件。NVIDIA 显卡优先，因为 CUDA 生态最完整。显存 8G 以上的显卡跑主流 SD 系列模型比较舒服，可以开到 512 或 768 分辨率；6G 显存建议用 SD 1.5 版本的小模型，并把分辨率控制在 512 附近；12G 以上可以尝试更高分辨率或更大的模型。没有 NVIDIA 显卡的机器，可以走 CPU 推理，速度会慢很多，但对“能不能跑通”没有决定性影响。

语言环境方面，Windows 上建议先装好 Git 和 Python。Python 版本用 3.10 或 3.11 都比较常见，ComfyUI 官方依赖兼容性较好。如果你不想手动管理 Python 环境，直接用 ComfyUI 内置的python_embeded目录运行也行，这是整合包最常见的启动方式。

磁盘空间按模型数量估算。一个小型 SD 1.5 模型文件大约 2GB 到 4GB，一个大模型 7GB 到 15GB，再加几个 LoRA 和 VAE 文件，建议预留 30GB 以上空间。如果你还要存放批量生成的输入输出素材，空间需求会更高。

端口占用也提前确认一下。ComfyUI 默认端口是 8188。启动前可以执行端口占用检查：

# Windows 检查 8188 端口是否被占用 netstat -ano | findstr 8188 # Linux / macOS 检查 8188 端口 lsof -i:8188

如果端口被占用，可以换一个端口启动，后面会讲具体方法。

4. 安装部署与启动方式

ComfyUI 的部署方式比较灵活，最常见的两种是 Git 拉取源码和直接下载整合包。这里给出一套通用流程，你需要根据自己下载的项目目录调整路径。

方式一：Git 方式安装。这种方式适合喜欢保持最新版本的开发者。

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

依赖安装完成后，把模型文件放到指定目录。不同模型类型对应不同目录。

主模型文件一般是.safetensors格式，从 Hugging Face 或模型发布页下载后，直接放进models/checkpoints目录即可。LoRA 文件放在models/loras。

方式二：整合包方式。整合包的好处是已经内置了 Python 运行环境，不需要自己装依赖。解压之后直接运行启动脚本：

# Windows 整合包启动示例 run_nvidia_gpu.bat

# Linux / macOS 整合包启动示例 ./run.sh

启动成功的标志是控制台出现类似下面的日志：

Starting server To see the GUI go to: http://127.0.0.1:8188

浏览器访问http://127.0.0.1:8188，看到 ComfyUI 的节点编辑界面就说明服务已经起来了。如果你的显卡不是 NVIDIA，或者驱动版本较低，启动可能需要换用run_cpu.bat等脚本。

如果端口被占用，可以在启动命令里手动指定端口：

python main.py --port 8189

5. 功能测试与效果验证

服务启动后，不要急着批量跑图，先按下面的顺序做四轮基础测试。每一步都确认成功，再进入批量阶段，这样排错成本最低。

5.1 文生图测试

测试目的：确认主模型加载正常、采样器工作正常、出图流程完整。

操作步骤：

1. 在浏览器打开的 ComfyUI 工作区里加载默认工作流。
2. 选择一个主模型，例如放在models/checkpoints下的 SD 系列模型。
3. 输入正向提示词和反向提示词。
4. 分辨率先设 512x512。
5. 采样步数设 20。
6. 点击“运行”按钮。

输入示例：

正向提示词：nightwing, dc comics, blue costume, masked hero, dynamic pose, city rooftop at night, detailed face, high quality 反向提示词：lowres, bad anatomy, bad hands, blurry, extra fingers, watermark, text

预期结果：页面右下角出现一张与提示词匹配的角色图像。判断标准是画面没有明显崩坏，角色身体结构正常，色彩风格符合预期。

常见失败原因：模型文件没放到正确目录，控制台会有Checkpoint file not found类似报错；反向提示词没生效说明节点连线错误；步数太高导致生成时间过长，可以先降到 20 步验证流程。

注意：这里用“dc comics”作为风格提示词只是演示，实际商用需要遵循版权规则。

5.2 图生图测试

测试目的：验证角色一致性，即“给定一张参考角色图，生成保持同一角色的新动作或新场景”。

操作步骤：

1. 在 ComfyUI 中加载“图生图”节点。
2. 上传一张角色参考图作为输入。
3. 设置去噪强度 denoise，建议从 0.4 开始。
4. 修改正向提示词中的动作和背景描述。
5. 运行工作流。

去噪强度是图生图里最关键的参数。数值越低，输出越接近原图；数值越高，模型改动越大。0.3 到 0.5 适合保持构图和角色特征，0.6 到 0.8 适合大幅改变场景。第一次测试建议先用 0.5，观察角色脸部是否保持稳定。

判断成功标准：生成结果中角色身份可辨认，服装风格一致，背景和动作按提示词发生了合理变化。如果脸部彻底变化，说明去噪强度太高或参考图约束不够。

5.3 局部重绘测试

测试目的：验证局部修改能力，比如只替换服装配色、只修改背景、只改变角色眼神方向。

操作步骤：

1. 加载局部重绘节点。
2. 上传一张已生成的角色图。
3. 用遮罩标记需要修改的区域。
4. 修改局部提示词，例如把服装颜色从蓝色改成黑色。
5. 运行并观察变化区域是否只限定在遮罩范围内。

局部重绘适合做服饰二创、场景替换、小道具增减这类精细操作。测试时要重点关注遮罩边缘是否生硬，如果边缘过度不自然，可以加大重绘区域的羽化值，或者降低去噪强度到 0.3 左右。

5.4 批量生成测试

测试目的：验证多条提示词能否连续出图，为后续批量任务做准备。

操作步骤：

1. 准备一个包含多条提示词的文本文件，每行一个提示词。
2. 在 ComfyUI 中加载“批量提示词”工作流节点。
3. 设置批量大小或循环次数。
4. 运行并观察是否按顺序生成多张图。

文本文件示例：

nightwing, blue suit, standing on gotham rooftop, rain, cinematic lighting nightwing, black suit, fighting in alley, motion blur, dramatic shadows nightwing, civilian outfit, bruce wayne's mansion, morning light, casual pose nightwing, training with batman, batcave, blue tone, action scene

批量测试的关键是稳定性。如果第 3 张突然崩坏，常见原因是提示词里引入了模型不熟悉的元素，或者角色描述词不一致。批量生成时最好把“角色名 + 核心外观关键词”固定为公共前缀，只替换动作、场景和氛围描述，这样一致性会高很多。

6. 接口 API 与批量任务

ComfyUI 的核心价值不只是可视化操作，它自带 HTTP API，可以把生图能力接到自己的工具或脚本里。

6.1 查询系统配置

启动服务后，先访问http://127.0.0.1:8188/system_stats，确认 API 可用并查看当前设备信息。

curl http://127.0.0.1:8188/system_stats

返回内容包括设备类型、显存大小、内存占用等。这一步能快速确认服务启动是否正常。

6.2 提交生成任务

提交任务的基本流程是：先把工作流转换为 API 格式的 JSON，然后通过 POST 请求提交到/prompt接口。

import json import urllib.request def queue_prompt(prompt_workflow): data = json.dumps({"prompt": prompt_workflow}).encode("utf-8") req = urllib.request.Request( "http://127.0.0.1:8188/prompt", data=data, headers={"Content-Type": "application/json"} ) with urllib.request.urlopen(req) as response: return json.loads(response.read()) # 这里的 workflow_json 需要在 ComfyUI 中把工作流导出为 API 格式 # workflow_json = {...} # result = queue_prompt(workflow_json) # print(result)

注意，这里的workflow_json不是 ComfyUI 界面里直接保存的 UI 工作流，而是通过“菜单 - 导出（API 格式）”得到的 JSON 结构。如果你直接复制界面工作流，接口可能返回参数缺失错误。

6.3 查询任务结果

提交任务后，服务端会返回一个prompt_id。用这个 ID 查询执行状态：

curl http://127.0.0.1:8188/history/{prompt_id}

返回内容包含生成图片的文件名。图片文件默认保存在output目录，可以通过/view接口访问：

curl http://127.0.0.1:8188/view?filename=xxx.png --output result.png

6.4 批量任务目录设计

如果你有大量素材要处理，建议在项目里搭建统一目录结构：

comfy-batch/ ├── inputs/ │ ├── prompt_list.txt │ └── reference/ ├── outputs/ │ ├── 20250101/ │ └── archive/ ├── scripts/ │ └── batch_gen.py └── workflows/ └── character_workflow_api.json

批量脚本的核心逻辑是四个步骤：

1. 读取提示词列表。
2. 把提示词逐条填充到工作流 JSON 中。
3. 通过 API 提交任务。
4. 轮询任务状态，输出结果并记录日志。

这里特别建议加失败重试。网络抖动、显存占用、单次生成异常都可能导致任务失败，重试逻辑可以简单做成“失败后等待 10 秒再提交一次”，最多重试 3 次。批量任务跑完后，检查生成图片数量和提示词数量是否一致，这是最简单的完整性校验。

7. 资源占用与性能观察

本地跑图像生成，显存和内存是关键瓶颈。虽然这里不会给出一台固定机器上的具体数字，但你可以用下面的方法自己观察。

启动 ComfyUI 后，打开 Windows 任务管理器或 NVIDIA 的nvidia-smi，可以看到 GPU 利用率和显存占用。生成过程中，显存会在模型加载时快速上升；生成结束后，显存回落但不会完全释放，这是正常现象。

# Linux 下实时观察 GPU 状态 watch -n 1 nvidia-smi

影响显存占用最明显的三个因素是模型尺寸、分辨率和批量大小。模型越大显存占用越高；分辨率从 512 提到 768，显存占用会明显上涨；批量数从 1 提到 2，显存也会接近翻倍。如果你的显存有限，优先降低分辨率，而不是降低模型质量。

CPU 推理和 GPU 推理的差异主要体现在时间上。同一张图，GPU 可能十几秒出图，CPU 可能要几分钟。CPU 跑通流程没问题，但不建议做批量生产。显存不足时，可以考虑启用低显存模式或减少批次数，具体参数名称以你安装的 ComfyUI 版本为准。

长时间批量跑任务时，进程残留也是需要关注的。如果脚本异常退出，ComfyUI 主进程可能还在后台占用显存和端口。排查方法先看进程列表，再决定是否强制结束。

# Windows 查看残留 Python 进程 tasklist | findstr python # Linux / macOS 查看残留进程 ps aux | grep python

8. 常见问题与排查方法

本地部署最常见的坑集中在依赖、模型、显卡和端口四个方面。下面的排查表可以直接对照使用。

批量任务里最隐蔽的一个坑是“单张显存溢出导致整批中断”。在脚本里对每张图都做独立 try-except，失败后把提示词写入 error 日志，而不是直接终止整个任务。

9. 最佳实践与使用建议

把整套流程跑通之后，下面几个工程化建议能帮你减少后面折腾的麻烦。

第一，第一次跑任务时用小参数验证。分辨率 512、步数 20、批量数 1，先确认整条链路能产出结果，再逐步调大参数。盲目一上来就开 1024 分辨率加批量 4，容易在显存、速度和出图质量三个维度同时踩坑。

第二，保留一套最小可运行配置。把验证通过的模型目录、工作流文件、提示词模板放在独立目录里，用 Git 或其他方式做好版本管理。这样即使某次更新 ComfyUI 后出问题，也能快速回退。

第三，模型文件、输入素材、输出结果分目录管理。模型文件按checkpoints、loras、vae分类；输入素材按日期或角色分类；输出结果按批次命名。批量任务跑完后，建议按批次归档，而不是让所有图片堆在同一个目录里。

第四，批量任务必须有日志和失败重试。日志至少包含提示词、任务 ID、开始时间、结束时间、结果状态。失败重试间隔建议短一些，避免在批量高峰期反复请求。

第五，接口服务要限制访问范围。ComfyUI 默认监听 127.0.0.1，只在本地访问。如果你确实要对外开放 API，建议加一层访问控制或反代认证，不要直接暴露到公网。

第六，涉及人脸、声音、版权素材时必须确认授权。这里再强调一次：迪克格雷森是一个版权角色，粉丝同人创作以学习交流为边界，商业使用必须获得授权。真人肖像的生成和传播更要谨慎，避免侵犯肖像权。

第七，发布或商用前要做效果复核。批量生成的图不要直接上线，人工检查角色特征、文字水印、构图问题。模型有可能生成版权方标志、文字符号或敏感元素，复核环节不能省。

10. 总结与下一步

这套方案最值得尝试的点，不是“生出一张好看的图”，而是把角色图像生成从单次实验变成了可批量、可接接口、可复现的本地工作流。先用文生图验证模型和采样器，再用图生图和局部重绘收紧角色一致性，最后用批量提示词和 API 脚本放大产能。

你可以先在自己的机器上完成第 5 节的前三轮测试，确认模型和角色一致性达标，然后再考虑接入 API 和批量任务。最容易踩的坑是模型文件放错目录、API 格式用了 UI 工作流、批量任务没有加失败重试。这三个坑提前避开，整个流程会顺畅很多。

后续值得扩展的方向包括：训练专属角色 LoRA，实现对特定角色风格的更强控制；接入 ControlNet 精修人物姿势；把批量结果接入内容审核流程；或者在更多下游工具里通过 API 调用这套生图能力。角色图像的批量生产只是第一步，真正稳定好用，还得靠工作流模板、目录规范和质量检查这套工程习惯。