写实人像这个方向，我踩过的坑基本集中在两件事上：一是脸不像人，二是等得太久。前者是模型与提示词的匹配问题，后者是采样链路的设计问题。Z-Image Turbo v7.0 配合 ComfyUI 这套组合，我用下来最直接的感受是，把“等”这个变量几乎从流程里删掉了——单张 1024 级别的写实人像，从点下队列到看到成图，常规配置下是秒级而不是分钟级。这意味着你可以把原来“想清楚再点一次”的习惯，改成“连出十张再挑一张”，工作方式的差别比参数本身的差别大得多。这篇内容面向的是已经会用基础文生图、但被出图速度和写实度同时卡住的人，也适合手里只有一张中端显卡、又不愿意把素材往外传的从业者。我会把节点链路、参数联动、显存分配、踩坑记录完整拆一遍，能直接抄的部分我会给到具体数值。

1. 先想清楚：本地跑写实人像值不值得折腾

1.1 本地出图与云端出图的真实差距在哪

很多人纠结本地还是云端，其实纠结错了维度。真正的差别不在画质，而在迭代节奏和素材归属。云端出图的隐性成本是每一次试错都要经过上传、排队、下载三个环节，单次可能只有十几秒，但你的注意力被打断了。写实人像恰恰是一个高度依赖连续试错的活——你调一版光影，看效果，再调一版肤质，这个过程里“等待”会严重削弱你的判断连贯性。本地跑起来之后，参数改完直接回车，两秒出图，你可以在一分钟内试完六种打光方案，这种密度是云端给不了的。

另一个维度是素材归属。写实人像经常涉及真人参考照、客户肖像、家庭合影这类不适合外传的素材，尤其是做商业委托的时候。本地部署的意义不是省钱，是把“这张图能不能传出去”这个问题从流程里彻底移除。我见过不少同行因为上传限制，把本来可以做得很细的活做得很粗，本质上是工具限制了工作方式。

当然本地也不是没代价。初次配置的时间成本、模型文件的管理成本、显存不够时的降级妥协，这些都是真实存在的。我的判断标准很简单：如果你一周出图量超过五十张，或者对素材外传有顾虑，本地值得投入一个下午配好；如果只是偶尔玩两张，云端更省心，不必硬上。这个判断比任何参数对比都实用。

1.2 Turbo 类加速模型到底省掉了什么

Turbo 这个词现在被用得很泛，容易让人误以为是“画质更好”。恰恰相反，这类模型的设计目标是用极少的采样步数逼近多步采样的结果，代价通常是一点点细节丰富度和构图多样性。它的技术路径大体是蒸馏：用一个跑满步数的教师模型生成采样轨迹，再让学生模型用 4 到 8 步去拟合这条轨迹。所以你会看到一个很典型的特征——步数给到 6 到 8 步之后，再加步数收益急剧下降，画面几乎不变，纯属浪费时间。

这带来两个连锁反应，必须一起理解。第一是CFG 的用法变了。传统模型靠 7 左右的 CFG 来强化提示词服从度，Turbo 类模型在训练时做了引导蒸馏，推理时 CFG 拉到 1.0 到 2.0 就够，硬拉到 7 反而会把画面烤焦，出现死白、硬边、色彩断层。第二是采样器的敏感度上升。步数少意味着每一步的噪声调度权重更大，采样器和调度器的组合选错，会在第 2 步就把画面结构定死，后面几步只能修细节，救不回来。

我一般会跟人说，用 Turbo 模型要换一套肌肉记忆：步数往下压、CFG 往下压、把精力从“调参”转移到“调提示词和后期控制”上。真要说它省了什么，省的不是画质，是采样时间，把原来三十步的耗时压到八步，同时把 CFG 的调参空间也压没了——这既是优点也是约束，你得接受它不太听话这个事实。

1.3 这套组合适合谁，不适合谁

说句实在话，这套东西不是万能钥匙。适合的人群画像比较清晰：做电商人像、社交头像、角色设定图、短剧分镜这类需要大批量、风格统一、快速迭代的场景；手里有 12GB 以上显存的显卡；愿意花时间理解节点连线而不是只想要一个“一键生成”按钮。

不太适合的场景我也说清楚。第一是需要极致细节的商业级输出，比如印刷级海报上的人脸，Turbo 类模型在睫毛、发丝、皮肤毛孔这些微观层次上还是弱于慢速大模型，通常得靠放大加局部重绘补。第二是需要高度精确的姿态控制，如果客户给了参考姿势要严格还原，你得额外上 ControlNet，工作流复杂度会翻倍，这时候 Turbo 的速度优势会被抵消一部分。第三是完全零基础的用户，ComfyUI 的节点思维对纯小白有门槛，虽然现在有一堆整合包，但出问题时的排查能力还是得靠理解链路。

认清边界比盲目上手重要。我见过有人拿这套跑四开海报的主视觉，放大三轮还是糊，最后换回慢速模型，白折腾两天。

2. 环境与依赖：一次装对，后面少折腾

2.1 显存档位决定你能直出多大的图

写实人像的分辨率不是随便填的，它跟显存是硬绑定关系。原因在于 Latent 张量的大小随分辨率平方增长，加上注意力层的中间激活值，显存占用会比你想象的高。我整理了一份实测档位表，数值是在关闭 xformers 替代方案、使用默认注意力实现下测的，你的环境可能有 ±15% 浮动，但量级不会差太远。

这张表的用法是把你的显存对到自己那一行，然后别越级。8GB 硬上 1024 直出，大概率在 KSampler 阶段就掉进显存不足的坑，就算勉强跑通，速度也会慢到失去意义——因为系统开始往内存里换页，那才是最慢的状态。宁可 512 起步做两段放大，也别死磕直出。

提示：显存不足时优先降低分辨率，其次降批次，最后才考虑换更省的注意力实现。顺序反了会浪费大量排查时间。

2.2 ComfyUI 目录结构与插件最小化原则

ComfyUI 的目录结构不复杂，但放错位置是最常见的低级错误。模型文件全部在models下面按类型分目录，加载器节点只会扫对应目录，放错目录不会报错，而是下拉框里压根看不到这个文件，新手经常在这一步卡半小时。

# 典型的目录归属，按这个放基本不会错 ComfyUI/models/checkpoints/ # 主模型 ComfyUI/models/vae/ # VAE（如果模型不自带） ComfyUI/models/loras/ # 风格或人物 LoRA ComfyUI/models/controlnet/ # 姿态、深度、边缘控制 ComfyUI/models/upscale_models/ # 放大模型 ComfyUI/models/clip_vision/ # 图像反推用

插件这块我的态度很明确：能少装就少装。理由不是洁癖，是排查成本。一个节点报错，如果装了二十个第三方包，你很难判断是哪个包改了依赖。我的最小集是四个：节点管理器（用来装别的）、面部细化相关的包、脚本增强包（保存工作流预览图很方便）、以及一个文本处理包（做提示词拼接）。其余的等到真正需要再加，别一上来装一堆“看起来很厉害”的包，最后互相冲突。

安装本身的流程不复杂，git clone拉下来，进目录pip install -r requirements.txt，然后启动主程序。真正容易出问题的是 Python 环境和显卡驱动的版本匹配，这部分在后面的排查章节细说。

2.3 模型文件命名与版本管理

这事听起来像强迫症，但真能省命。我的做法是文件名里带上“模型名 + 主版本 + 用途标签”，比如xxx_turbo_v7_portrait.safetensors。原因是这类加速模型更新频繁，v6 和 v7 的参数习惯可能完全不一样，混在一起你根本记不住哪张图是哪个版本跑的。我吃过这个亏，回头想复现一张图，发现模型已经覆盖了，白搭。

另外建议单独建一个notes文本，记录每次换模型时的关键参数，至少记三样：步数、CFG、采样器组合。这三样一变，出图风格就有明显漂移。别指望自己记得住，真的记不住。

3. 工作流拆解：从加载器到出图的每一环

3.1 核心节点链路与数据流向

基础链路其实就六个节点，理解顺序比记住名字重要。模型加载输出三个东西：模型本体、文本编码器、VAE。文本编码器接正向和负向两个提示词节点，各自吐出一组条件张量。空 Latent 节点负责定义画布尺寸和批次。采样器节点把这四路输入（模型、正向条件、负向条件、空 Latent）揉在一起跑去噪循环，最后交给 VAE 解码成像素图，再由保存节点落盘。

这条链路里最容易搞混的是“条件”这个概念。正向提示词不是直接画东西，它是引导去噪方向的一股力；负向提示词也不是“不要画什么”，而是把这股力往反方向推。理解了这一点，你就明白为什么负面词写太多反而会让画面变呆——反方向推得太猛，整体分布被压扁了。

注意：换模型后一定要检查加载器节点是否已经指向新文件。ComfyUI 会记住上次的选择，但如果你删了旧文件，它会静默回退到列表第一个，导致你以为在用 v7，其实跑的是别的。

3.2 采样器、步数与 CFG 的联动关系

这三个参数不能分开调，它们是一个三角关系。Turbo 类模型的常用组合我整理成了表，按用途分档，直接照抄能省不少试错。

为什么草稿用 4 步就够？因为你在草稿阶段只需要判断构图、姿态、大致光影，这些信息在 4 步时已经成型了，后面几步修的是皮肤纹理和发丝边缘。用 4 步跑一轮，挑出构图对的，再用同种子跑 8 步，这个习惯能把你一天的有效产出提高接近一倍。

CFG 超过 2.5 在 Turbo 模型上我基本不推荐，画面会出现明显的“过饱和 + 硬边”特征，尤其是皮肤高光区域，容易出现塑料感。如果你觉得提示词不听话，先别急着拉 CFG，回去改提示词的结构和顺序，收益大得多。

3.3 分辨率、Latent 与放大策略

写实人像的构图比例有讲究。竖构图 832×1216 或 768×1152 是最贴近人像习惯的，横构图 1216×832 适合半身带环境。为什么要用这些“非整数”比例？因为模型训练时用的就是这类尺寸，用 1000×1000 这种反而容易触发构图崩坏，出现双头、肢体粘连的概率明显上升。

放大策略上，我推荐两段式而不是一步到位。第一段用 0.5 到 0.6 的放大倍率配合 0.45 左右的降噪，让模型补充细节而不是重画；第二段再用 8 到 12 步、0.35 降噪修一遍。为什么不一次性放大两倍？因为单次放大倍率过高时，模型需要“无中生有”地编造大量细节，很容易在人脸区域编出五官错位。分两段走，每段的编造量可控，出错概率低很多。

还有个小技巧：放大前先把原图的脸部区域单独裁出来做一次细化，再贴回去放大，效果比整体放大的脸好很多。这个流程稍微绕一点，但商业出图时值得。

4. 写实人像的关键控制：脸、光、肤

4.1 提示词的分层写法

写实人像的提示词不要写成一大串形容词堆砌，那是新手最常见的失效原因。正确的做法是分层写，从抽象到具体，让模型按顺序解析。我固定用四层结构，效果比随意堆砌稳得多。

第一层是主体与姿态：谁、在做什么、什么景别。第二层是光影条件：光源方向、软硬程度、时间感。第三层是肤质与质感：这是写实度的核心，必须单独说。第四层是镜头语言：焦段、光圈、景深、胶片质感。四层写完，通常已经足够。

举个具体的例子，描述一个窗边人像：主体层写“年轻女性半身坐姿，面向画面左侧，视线离开镜头”；光影层写“午后侧逆光，柔光从左上打入，面部右半边落在柔和阴影里”；肤质层写“自然肤质，可见细微毛孔与绒毛，无过度磨皮”；镜头层写“85mm 定焦，f/2.0，浅景深，背景虚化”。这套写下来，比写十个“beautiful, masterpiece”有用得多。

为什么不建议堆一堆质量词？因为 Turbo 类模型对这类词的响应很弱，它们更多是在慢速大模型上被训练成“提权信号”，在少步蒸馏模型里反而会干扰构图收敛。

4.2 负面提示词的克制用法

负面提示词这块，我的核心观点是越短越好。很多人习惯抄一大串通用负面词，动辄几十个，结果画面变得呆板、构图保守、缺乏生气。原因前面提过，负向条件是把采样往反方向推，推太猛就把整个分布压扁了。

我常用的是六到八个，针对写实人像的高频瑕疵：模糊、低分辨率、多余手指、肢体畸形、皮肤塑料感、过曝高光、五官不对称。就这些，够用。真出现具体问题时再针对性加，比如出图总带奇怪的水印，就加一条；不要预防性地堆。

有个反直觉的经验：如果负面词里写了“过度磨皮”，有时候反而会让模型理解成“要磨皮”，因为它对否定词的解析并不严谨。这种情况改用正面描述更有效——直接在正向里写“可见皮肤纹理与毛孔”，比在负向里否定三次都管用。

4.3 面部细化该不该开，什么时候开

面部细化这个环节，本质是把脸的区域裁出来，用更高的有效分辨率重绘一遍再贴回。它的价值在于解决小脸问题：当你出的是半身或全身构图，脸在画面里只占很小一块像素，原分辨率下人脸必然是糊的，这时候不细化就废了。

但它也有代价。第一是耗时，一张图多两三秒；第二是风格漂移风险，细化模型和主模型不匹配时，脸会变得和身体不像同一个人；第三是有时候会把原本还行的手也一起改了。所以我的原则是：景别决定开不开。特写和大头照不开，半身照开，全身照必须开而且要把脸部裁切范围调大一点。

提示：面部细化的降噪强度不要超过 0.45，超过这个值基本等于重画一张脸，很容易和原图气质脱节。

5. 出图效率实战：把单张耗时压到最低

5.1 首次运行与预热的意义

第一次跑新模型的时候，速度会明显慢于后续，这不是错觉。系统需要把模型权重加载到显存，还要做一次算子编译和缓存预热。一张图可能要十几秒，第二张开始就回到正常速度。所以别拿第一张图的时间来判断配置够不够，容易误判。

我的习惯是每次换模型或换工作流后，先跑一张 4 步的废图做预热，把它当“点火”用。这个动作花不了两秒，但能避免你在正式出图时被突然的长耗时打断节奏。批量出图时这个差异更明显，预热过一次的队列，整体耗时能压掉一成左右。

5.2 批量出图与队列管理

ComfyUI 的队列机制是串行的，点一次排队就跑一次。想批量出图有两个办法：一是把 Latent 节点的批次调大，一次出多张；二是改种子后连续点队列。前者省显存管理开销但吃显存，后者显存友好但操作繁琐。

我的做法是混合用。显存够的时候批次设 2，同时手动排三到四个不同种子的任务，这样队列里有活干，我也能腾出手去看前一批的结果。如果显存紧张，就批次设 1，纯靠队列串行跑，这时候别去动浏览器标签，页面切到后台有时候会影响前端轮询，虽然不影响后端执行，但你看不到进度容易误以为卡死。

关于种子，建议固定一个初值然后递增扫描，而不是随机。随机种子的问题是无法复现，你今天调到一张特别好的图，明天想微调就找不回来了。递增扫描的话，至少你知道大概在哪个区间出的好图。

5.3 一份实测耗时记录

下面是某台 16GB 显存机器上的实测数据，分辨率 832×1216，批次 1，记录的是连续跑十张的平均值。不同驱动和系统会有差异，看量级就好。

这组数据最有价值的结论是：从 6 步提到 8 步，多花 0.6 秒换来的细节提升，肉眼几乎看不出来。所以日常我就跑 6 步，只有确定这一版要出成片时才上 8 步。这个取舍比抠参数本身更影响效率。

6. 常见问题与排查速查

6.1 显存与报错类问题

显存不足的报错信息通常比较直白，会明确告诉你在哪个节点分配失败。但有个坑是它会连着报好几次，让你误以为是多个问题，其实根源就一个。排查顺序固定为：降分辨率 → 降批次 → 关掉面部细化或放大 → 检查是否开了太多浏览器标签占用显存。

注意：不要迷信各种“显存优化”参数全开。有些优化是以牺牲速度为代价的，开了之后显存是够了，但单张耗时翻倍，反而得不偿失。按需开，别全开。

6.2 画面质量类问题

画质问题比报错难查，因为它不报错，只是结果不对。我把常见的几种整理成了对照表，按“症状 → 病因 → 药方”的思路排。

这里面最容易忽略的是“提示词内部矛盾”。比如你同时写了“柔和月光”和“强烈阳光”，模型会在两种光之间摇摆，结果就是一片说不清道不明的灰。写提示词时要自己读一遍，确认光线描述是自洽的，这个检查花不了十秒，能省掉大量无效出图。

6.3 工作流保存与复用

调好的工作流一定要存，而且建议存两份：一份是完整版，包含所有可选模块；一份是精简版，只留主链路。日常用精简版跑得快、出错少，遇到需要特殊控制的时候再切完整版。命名上带上日期和用途，比如“人像_竖构图_基础_0312”，别用“最终版”“最终版2”这种，过一周你根本分不清。

还有一个容易忽略的点：工作流里嵌的模型路径是相对路径，换了机器或者改了目录结构，打开时会提示找不到模型。这时候别慌，节点上会标红，点开重新选一次就行，连线不会断。养成把工作流和模型一起打包备份的习惯，回头复现比别人快得多。

我在实际操作中的体会是，这套流程真正的门槛不在技术，在克制。参数不要贪多，负面词不要贪全，插件不要贪新。我见过太多人把工作流堆成一张蜘蛛网，最后出问题时连自己都找不到是哪根线的问题。反而是最朴素的那条六节点链路，配上合适的提示词分层，能稳定产出九成以上的可用图。剩下那一成，靠的是放大和局部重绘慢慢磨，而不是靠把参数调到某个神秘组合。速度给你的最大红利，其实是允许你把省下来的时间花在挑图和改图上，而不是继续加节点。