AI绘画角色一致性新方案：ComfyUI本地部署“New Face”工作流-平芜编程栈

这次我们来看一个社区创作者项目，标题是 “New face new unc // og idea”，作者标记为 jyns_hotspot。项目名里最有信息量的就是 “New face”，翻译成技术目标就是：在 AI 绘画里生成一张全新的、可复用的角色面孔，并在不同姿势、表情、场景下尽量保持这张脸的身份一致性。它不是一个常见的重量级开源框架，更像一个“原创想法 + 模型 / 工作流”的组合。实际使用时要放进本地 ComfyUI 或 Stable Diffusion WebUI 生态里，把它当成人物一致性创作方案来跑。

在一个 AI 绘画模型多到记不过来的阶段，这种项目真正值得关注的不是“能画得多好看”，而是能不能稳定出来一张可复用的新面孔，以及能不能批量生成一批设定图、表情图、动态姿势预览。我写这篇文章不打算去猜作者每个缩写的具体含义，而是直接给一套可落地的本地部署流程：环境准备、下载放置模型、ComfyUI 启动、单图测试、批量生成、API 接入、资源占用观察、常见问题排查。这样无论你拿到的是 LoRA 还是工作流 JSON，都能照着推一遍。

先说结论：如果你有 NVIDIA 显卡，愿意折腾 ComfyUI，并且手上有人脸素材的使用授权，这类项目很快就能成为角色设定的效率工具。如果只是想看一张图就判断好不好用，建议直接看后面的“核心能力速览”和“功能测试”两节，再决定要不要花时间部署。

1. 核心能力速览

能力项	说明
项目类型	AI 绘画角色一致性创作项目（社区原创想法）
提供方	jyns_hotspot
核心功能	“新面孔”角色生成、人脸一致性保持、风格化形象创作
推荐运行方式	ComfyUI / Stable Diffusion WebUI 本地部署
启动方式	命令行启动后通过浏览器访问 Web UI
是否支持 CPU	可以运行，但速度较慢，推荐 NVIDIA GPU
显存需求	以实际模型版本为准，建议 8G 起步
是否支持 API	项目本身不直接提供 API，可通过 ComfyUI API 暴露服务
是否支持批量任务	可配合脚本或队列批量生成
适合场景	原创角色设定、插画前期探索、游戏概念设计、短视频素材预演

这类项目的核心链路通常是：参考人脸图片 → 提取人脸特征 → 结合提示词生成新姿势 / 新表情 / 新场景 → 输出一批保持身份一致性的图片。标题里的 “new face” 对应整个人脸生成入口，而 “unc” 这类后缀在不同社区平台含义并不统一，技术使用上不必过度纠结，以作者发布的模型卡说明为准。

1.1 项目定位判断

“New face new unc // og idea by: jyns_hotspot”不是开箱即用的独立 App，它最可能的形态是：原创角色概念图、配套 LoRA 模型、ComfyUI 工作流文件，或者是几者组合。拿到这样的项目后，需要先做一个基本判断：作者是否提供了可下载的模型文件；工作流是否存在外部依赖节点；参考图素材是否允许二次使用。这些信息一般在发布页的说明栏里，部署前先把这些确认清楚，省得下载半天发现模型文件和说明对不上。

2. 适用场景与使用边界

2.1 这个项目适合谁

正在设计原创角色，需要快速出多角度设定图的画师或设计师。
做 AI 视频，需要同一张脸出现在多个分镜脚本里的短视频创作者。
运行 ComfyUI 比较熟练，习惯把社区模型接入到自己工作流里的玩家。
需要批量生成角色表情包、动作参考、服装方案的内容团队。

2.2 能解决什么问题

它解决的是 AI 绘画里比较头疼的“人物保持问题”。普通文生图出图，每次都是新脸，角色前后不连贯。而这类人脸一致性项目，会把参考人脸的特征固定下来。你先生成一张新面孔，或者直接用授权过的参考人脸，再到后续不同场景中复用这张脸。这对角色设定图的效率提升非常明显。

2.3 不适合什么场景

完全没有本地部署经验、不愿意用命令行和环境配置的纯新手。
没有独立显卡，只能用 CPU 跑图且对生成速度要求高。
需要把生成结果直接商用，但无法确认人脸素材、模型权重和参考图授权来源。

2.4 版权、隐私与安全边界

这里必须重点提醒：凡是涉及人脸生成、人脸替换、形象复用的项目，都要先确认素材来源。公开人物的脸、私人照片、未经授权的模特图，都不能随意拿来做生成素材。本地生成只能用于个人研究和技术验证。如果要把生成结果发布、商用或用于公开传播，必须确保以下三点都有据可查：原始图片的肖像授权、模型权重的使用许可、生成内容的合规边界。对创作者提供的参考图和工作流同样要保持警惕，不要在没有授权的情况下复制他人风格或角色。

3. 环境准备与前置条件

3.1 硬件与操作系统

部署 ComfyUI 或 Stable Diffusion WebUI 这类本地绘画环境，最常见的是 Windows 10 / Windows 11 和 Linux 环境。硬件方面，NVIDIA 显卡体验最好，建议显卡驱动更新到较新版本，并安装匹配的 CUDA 版本。显存方面，从经验来看，8G 是一个相对从容的起步线，可以跑大多数常见的 checkpoint 和人脸类模型；6G 显存也能运行，但需要开启低显存模式，分辨率不能开太高。纯 CPU 推理理论上能跑，但生成一张图可能要等很久，只建议做流程验证。

3.2 软件与依赖

需要提前准备：

Python 3.10 或 3.11，避免版本过新导致部分依赖编译失败。
Git，用于拉取 ComfyUI 和相关自定义节点。
NVIDIA 显卡驱动，尽量选择 Game Ready 或 Studio 驱动。
PyTorch 环境，安装时根据显卡选择对应 CUDA 版本。
浏览器，推荐 Edge 或 Chrome，用于访问 ComfyUI 界面。

3.3 磁盘空间

ComfyUI 主体很小，但模型文件不小。一个基础 checkpoint 通常是 2G 到 7G，一个 LoRA 文件从几十 MB 到几百 MB 不等。如果还要安装人脸识别、换脸、IPAdapter 之类的自定义节点，依赖模型会额外占用几 GB。建议预留至少 30G 空间，并保持 C 盘之外有独立工作目录，避免系统盘写满。

3.4 网络与下载

模型下载源主要有 Hugging Face、Civitai、GitHub，以及部分国内镜像站。下载时注意校验文件大小和哈希值，确认文件完整性。如果下载慢或经常中断，可以检查网络连接、使用代理下载工具，或者选择下载速度更稳定的平台，这部分不展开。

4. 安装部署与启动方式

下面以 ComfyUI 为运行环境，给出一套通用部署流程。这个流程对大多数社区模型项目都适用。如果你拿到的是项目作者已经打包好的一键包，则可以跳过前几小节，直接看启动命令。

4.1 拉取 ComfyUI

打开终端，进入你想要放项目的目录，执行：

git clone https://github.com/comfyanonymous/ComfyUI.git cd ComfyUI

如果网络环境不稳定，拉取失败时可以多试几次，或者使用镜像仓库。这里用的是 ComfyUI 官方仓库路径，具体版本以官方页面说明为准。

4.2 创建虚拟环境

Windows 下使用 venv 创建隔离环境，避免依赖冲突：

python -m venv venv venv\Scripts\activate

Linux / macOS 下执行：

python -m venv venv source venv/bin/activate

看到终端提示符前出现(venv)就说明虚拟环境已激活。后面安装的依赖都会装在这个环境里，不会污染系统全局 Python。

4.3 安装依赖

pip install -r requirements.txt

如果你的显卡是 NVIDIA 且需要 CUDA 加速，还需要确认 PyTorch 是否装到了对应 CUDA 版本。如果默认安装的 PyTorch 是 CPU 版，需要到 PyTorch 官网选择对应的安装命令重新安装。

安装完成后，可以先用默认模型启动一次 ComfyUI，确认基础环境没问题，再放入项目模型。

4.4 放置模型文件

进入 ComfyUI 目录后，模型文件要按类型放到对应子目录：

大模型 checkpoint 放入models/checkpoints
LoRA 模型放入models/loras
VAE 文件放入models/vae
人脸识别 / 换脸类模型放入models/reactor或models/insightface，具体看自定义节点要求
ControlNet 模型放入models/controlnet

不要把所有模型都堆在 checkpoints 目录里。目录整理清楚，工作流在加载节点时才能快速找到对应文件，排查问题也会方便很多。

4.5 启动 ComfyUI

python main.py --lowvram --port 8188

这是一个通用启动示例。--lowvram适合显存不够宽裕的情况，如果显存充足，可以不使用这个参数；--port 8188指定端口，避免和其他本地服务冲突。启动成功后，终端会显示访问地址，默认是：

http://127.0.0.1:8188

用浏览器打开这个地址，就能看到 ComfyUI 的节点编辑界面。

4.6 导入项目工作流

如果 jyns_hotspot 发布的内容里包含工作流文件，常见导入方式有两种：

直接把工作流 JSON 文件拖进 ComfyUI 界面。
如果发布的是带工作流信息的 PNG 图片，把图片拖进界面即可自动加载对应节点。

加载后先检查节点是否完整。如果发现某些节点显示为紫色或提示缺失，说明缺少对应的自定义节点，需要到ComfyUI-Manager里搜索并安装。

5. 功能测试与效果验证

部署完成后，不要直接上复杂参数。先做一轮从简单到复杂的验证，确认每个功能点都能跑通。以下测试流程以人脸一致性生成项目为例。

5.1 基础文生图测试

测试目的：确认 ComfyUI 基础出图链路正常，模型、VAE、采样器都工作。

在正面提示词区域填写角色描述，例如：

new face, beautiful detailed eyes, soft lighting, portrait, upper body, small smile

负面提示词填写：

bad anatomy, bad hands, extra fingers, deformed face, blurred, watermark

采样参数使用通用默认值：采样步数 20 到 30，CFG 3.5 到 7，分辨率从 512x768 开始。点击生成后，开始观察：

图片是否正常生成。
有没有报错。
显存是否有明显波动。
角色脸部是否清晰。

判断成功标准：图片不出现大面积黑图、灰图、崩脸，脸部结构和手部结构可接受。如果生成失败，优先看终端日志，定位是模型加载失败、显存溢出还是提示词解析错误。

5.2 新面孔生成与一致性测试

这是项目核心测试。如果项目包含人脸参考图流程，需要先把参考图上传到 ComfyUI 的加载图片节点，然后接人脸特征提取节点，再传入生成链路。

测试步骤：

准备一张干净、正面、光线均匀的参考人脸图。
在加载图片节点中选中该图。
设置人脸特征提取的放大倍率、检测阈值等参数。
输入一组不同的姿态和场景提示词。
固定同一个随机种子，连续生成 4 到 6 张图。

预期结果：所有输出图都是同一个人物，只是表情、角度或背景发生变化。如果出现每张图长相不一致，说明人脸特征权重过低，或者参考图本身不够清晰，需要调整权重参数。

判断成功标准：多张图之间的人物五官轮廓、脸型、瞳色等核心特征保持一致。最容易失败的场景是侧脸、俯拍角度和低光照，这三类情况需要单独调参。

5.3 图生图与局部重绘测试

很多人脸项目在生成设定图时还会用到图生图或局部重绘。比如只改服装、只改发型、不改脸。在 ComfyUI 里可以通过遮罩节点实现局部重绘。

测试目的是确认人物角色的可编辑性。操作时把一张已生成的正面图拖进图生图节点，加入局部遮罩，只覆盖服装区域，然后填写新的服装描述。生成后观察脸部是否保持原样，服装是否按提示词变化。如果脸部也发生变化，说明遮罩范围没有限制住，或者重绘幅度过大。此时把去噪强度从 0.5 调节到 0.35 左右再审一遍。

5.4 批量生成验证

批量任务不是把所有图片一次塞进 GPU 并行处理，而是把多个任务放进队列顺序执行。在 ComfyUI 界面里，可以反复点击“提交”按钮，把多组提示词加入队列。更高效的做法是使用 API 脚本循环提交，这个在下一节单独讲。

批量验证时建议先用 5 张图测试队列稳定性，确认每张图都正常输出后，再扩大到 50 张甚至更多。如果队列中间卡住，重点检查模型是否加载失败、提示词里是否有非法字符、输出格式是否与保存节点不匹配。

6. 接口 API 与批量任务

ComfyUI 自带 HTTP API，可以把项目生成能力暴露成可访问的接口服务。这样就不用每次手动在网页上点生成，可以接到自己的工具链里，批量处理一批提示词、一批参考图或者一批参数组合。

6.1 开启远程访问

默认启动时 API 只监听本地。如果需要局域网内其他设备访问，启动命令加--listen：

python main.py --listen 0.0.0.0 --port 8188

这样同一局域网内的机器可以通过http://本机IP:8188访问。但注意，接口服务不要直接暴露到公网，模型生成接口很容易被滥用，建议只在可信内网使用。

6.2 提交生成任务

ComfyUI 的 API 核心接口是POST /prompt，请求体里包含工作流的 JSON 数据。工作流 JSON 可以通过界面右上角按钮导出，也可以在浏览器里用开发模式获取 API 格式 JSON。

下面是一个通用 Python 示例，思路是先读取工作流 JSON，再替换提示词，然后提交：

import requests import json server = "http://127.0.0.1:8188" # 读取 ComfyUI 导出的 API 格式工作流 with open("workflow_api.json", "r", encoding="utf-8") as f: workflow = json.load(f) # 找到提示词节点并替换，节点 id 需要根据实际工作流确认 for node_id, node in workflow.items(): if node.get("class_type") == "CLIPTextEncode": if "正面提示词" in node["inputs"].get("text", ""): node["inputs"]["text"] = "new face, portrait, golden hour, soft light" payload = { "prompt": workflow } resp = requests.post(f"{server}/prompt", json=payload, timeout=30) print(resp.json())

如果返回结果里有prompt_id，说明任务已进入队列。之后通过/history/{prompt_id}查询任务状态和输出图片。

6.3 获取生成结果

import requests server = "http://127.0.0.1:8188" prompt_id = "这里填返回的 prompt_id" resp = requests.get(f"{server}/history/{prompt_id}", timeout=15) data = resp.json() if prompt_id in data: outputs = data[prompt_id]["outputs"] for node_id, output in outputs.items(): if "images" in output: for img in output["images"]: print(f"生成图片：{img['filename']}")

注意这段代码只是示例，具体字段结构以实际运行时的接口返回为准。

6.4 批量任务设计

批量任务的核心不是一次性提交几百个请求，而是控制提交节奏、保存任务状态、处理失败重试。一个比较稳妥的脚本流程是：

读取输入文件，比如一个提示词列表或参考图目录。
对每条记录生成工作流 JSON。
提交到/prompt接口，记录prompt_id。
定时查询任务状态。
任务完成后下载输出图片，并按原文件名保存。
如果查询超时或任务失败，记录日志后重试 2 到 3 次。

伪代码示例：

import time import requests import json server = "http://127.0.0.1:8188" task_queue = [ {"id": "01", "prompt": "portrait, new face, red dress"}, {"id": "02", "prompt": "portrait, new face, black suit"}, ] for task in task_queue: workflow = load_workflow_template() set_prompt(workflow, task["prompt"]) resp = requests.post(f"{server}/prompt", json={"prompt": workflow}).json() prompt_id = resp.get("prompt_id") for _ in range(60): time.sleep(2) status = requests.get(f"{server}/history/{prompt_id}").json() if prompt_id in status: save_output(status[prompt_id], task["id"]) break else: log(f"task {task['id']} timeout")

同一个模型连续跑几十张图，最容易出现的问题是显存积累和临时文件堆积。因此批量任务最好加上队列间隔，比如每张图生成完成后等 1 到 2 秒再提交下一个任务，给显存和内存释放留时间。

7. 资源占用与性能观察

这类本地绘画项目，真正要盯的性能指标就是显存占用和单张生成时间。不要只看最终图片质量，还要看整个任务执行过程是否稳定。

7.1 如何观察显存占用

在另一个终端窗口运行：

nvidia-smi -l 1

这个命令每 1 秒刷新一次显存和 GPU 利用率。生成图片时，会看到显存占用瞬间拉高，生成结束后回落到基础占用。如果某些节点在单进程内反复加载模型，显存可能始终处于高位，这不是错误，但批量任务时要关注是否出现缓慢增长，最终导致 OOM。

7.2 CPU 推理和 GPU 推理差异

GPU 推理生成一张图通常只要几秒到几十秒，CPU 推理则可能延长到几分钟甚至更久。如果机器只有 CPU，可以先低分辨率、低步数验证工作流逻辑，不要直接上高分辨率批量任务。从实际体验看，人脸一致性工作流往往包含多个模型，CPU 模式下单个节点推理耗时成倍增长，整体排队时间非常可观。

7.3 影响性能的关键参数

分辨率：从 512 提升到 1024，计算量明显增加；再做 2 倍放大，又会在后处理阶段占用额外显存。
采样步数：步数越高，生成时间越长，但超过一定步数后画质提升不明显。
批量大小：一次生成多张图会成倍增加显存压力，通常建议批量大小从 1 开始。
人脸检测模型：人脸识别节点在每张图上都会运行，参考图中人脸数量和检测阈值会影响耗时。
文本长度：超长提示词对显存影响不大，但对 CLIP 编码器的推理时间有一定影响。

7.4 降低显存占用的方法

显存不足时，优先尝试这几个方向：

启动时加--lowvram，把模型分块加载。
使用 fp16 或 bf16 精度。
降低批量大小为 1。
关闭其他占用显存的程序，比如浏览器硬件加速。
去掉不必要的放大节点，先生成小图，再单独跑放大。

7.5 端口冲突和进程残留

启动时如果提示端口被占用，可以换一个端口：

python main.py --port 8189

如果已经启动过多个服务，终端关掉后发现端口仍被占用，可以在 Windows 下使用netstat -ano | findstr 8188查看进程 PID，再在任务管理器结束对应进程。Linux 下使用lsof -i:8188查看占用进程。

8. 常见问题与排查方法

问题现象	可能原因	排查方式	解决方案
启动后页面打不开	端口被占用或服务未启动	看终端日志，检查端口监听	更换端口或重启服务
CUDA 不可用 / 找不到显卡	显卡驱动太旧或 PyTorch 版本与 CUDA 不匹配	`nvidia-smi`检查驱动，Python 里检查 torch.cuda	更新驱动，安装对应 CUDA 版本的 PyTorch
显存不足 OOM	分辨率过高、批量数过大、模型过大	查看错误日志和 nvidia-smi	降低分辨率，批量数设 1，开启 --lowvram
模型文件加载失败	文件放在错误目录或文件不完整	检查模型放置路径和文件大小	移动到正确 models 目录，重新下载
自定义节点显示缺失	缺少对应 ComfyUI 插件	打开 ComfyUI-Manager 查看缺失列表	安装对应自定义节点后重启
生成图片人脸不一致	人脸特征权重过低或参考图模糊	观察不同输出的脸部变化	提高人脸特征权重，换一张更清晰的参考图
批量任务卡住	任务队列堆积，节点报错未捕获	查看终端日志和任务状态	增加任务间延时，脚本中加入超时和重试
输出图片风格不稳定	随机种子变化，提示词不够稳	固定 seed，检查工作流中是否有随机节点	使用固定 seed，统一提示词模板
参考图片不生效	节点连接错误或检测模型未加载	检查人脸检测节点是否有输出	重新连接节点路径，安装对应检测模型
生成图片有违规内容	提示词或素材使用了不当描述	检查提示词和输入素材	移除违规描述，严格使用合规素材

排查问题时，最优先看终端日志，而不是只看界面报错。ComfyUI 的大部分错误信息会直接打印在终端，包括缺少文件、节点执行失败、显存分配失败等。把日志复制出来搜索关键字，通常比反复重新生成更有效。

9. 最佳实践与使用建议

9.1 第一次先小参数测试

不要一上来就生成 1024x1024、80 步、批量生成几十张图。第一次运行，用最低分辨率、最低步数，只验证工作流能跑通。确认整条链路没有问题后，再逐步提高参数。这样可以省下大量排查时间。

9.2 保留一套最小可运行配置

当你调通一个组合，马上把工作流 JSON 导出来保存，同时在旁边写一个简单的说明，记录模型版本、关键参数、正负提示词。这个最小配置以后可以作为所有新测试的基础模板。

9.3 目录管理要规范

建议整个项目目录按下面的方式组织：

project_root/ ├── models/ # 模型文件 ├── workflows/ # 工作流 JSON ├── inputs/ # 参考图、输入素材 ├── outputs/ # 生成结果 └── logs/ # 批量任务日志

模型文件、输入素材、输出结果分目录管理，不只是为了整洁。批量任务脚本和日志记录都需要依赖明确路径，目录混乱最容易导致脚本意外覆盖文件或读取错误。

9.4 批量任务要加日志和失败重试

批量生成不是提交完就结束。建议执行前记录任务总数、每个任务的参数、开始时间；执行中记录每个任务的 prompt_id 和状态；执行后记录输出文件路径。脚本捕获到异常时，先记录日志，再按规则重试。如果连续失败超过 3 次，停止批量任务，人工检查。

9.5 接口服务要限制访问范围

使用 API 时，不要把--listen 0.0.0.0的服务直接暴露到公网。如果确实需要远程调用，建议放在内网或通过防火墙限制来源 IP，并在生成服务前面加一层自己的鉴权逻辑，防止接口被滥用。

9.6 涉及人脸、声音、版权素材时必须确认授权

再强调一次：所有涉及真人脸部的生成，都必须在授权范围内使用。发布任何包含由 AI 生成人脸的作品时，需要仔细确认肖像权、版权和使用许可。技术本身没有倾向，但如果使用不当，会带来法律风险。不要为了省事跳过这一条。

9.7 发布或商用前要做效果复核

AI 生成的人脸有时在极端角度下会有细微畸形，批量生成后一定要人工抽查。尤其是准备对外发布的素材，逐张检查脸型、手指、五官结构、文字和 logo 区域，避免低级错误影响最终交付。

10. 总结与下一步

这个项目最值得尝试的点，是“围绕一张新面孔做二次创作”的工作流思路。不管最后你使用的模型是不是 jyns_hotspot 发布的原始版本，只要把角色一致性生成链路跑通，就能把这套方法复用到自己的角色设定、插画草稿和视频脚本预演里。

建议拿到项目后，先验证三件事：

基础文生图链路是否正常，模型能不能加载。
人脸参考图节点是否真的影响生成结果，换两张不同的参考图看输出差异。
工作流能不能通过 API 批量提交，脚本跑一次 10 张图的队列是否稳定。

最容易踩的坑，其实不在生成环节，而在环境准备阶段：模型放错目录、PyTorch 版本和 CUDA 不匹配、自定义节点没装全。这三个问题占了新手部署失败的大多数。先把 ComfyUI 官方示例工作流跑通，再套入项目模型，会顺畅很多。

后续可以继续扩展的方向很多：把这个工作流接到自己的批量图片脚本里，做成一个简单的角色设定生成工具；或是在工作流中追加 LoRA 训练，让新面孔变成可复用的独立角色模型；再或者配合视频生成模型，把多张保持一致性的角色图作为分镜素材使用。只要把基础链路的部署、测试和排错流程掌握清楚，这个项目就能从“看看效果”变成真正能稳定产出内容的工具。

对已经接触过本地部署的读者来说，最快验证方式就是照着上面的流程，从基础文生图开始逐步替换成项目自带的工作流，第一张图出来后再决定要不要继续投入时间。建议收藏备用，后面实际部署时可以少走弯路。