★ FEATURED ARTICLE 大模型绘画玩到第二年你会发现一个挺有意思的分水岭一部分人还在反复调整提示词试图靠咒语逼出想要的画面另一部分人已经把整条生成链路拆成了模块用节点图的方式拼装、复用、批量跑。前者是在赌运气后者是在做工程。ComfyUI 就是后一种思路的典型代表它把扩散模型的一次生成过程彻底摊开成一张有向图每个节点负责一件事连线决定数据怎么流。这篇接着上次的话题往下聊因为我这一年多把它从折腾着玩用到了每天要跑几千张图的程度踩的坑和攒的经验都不少索性一次性写透它适合谁、核心数据链路长什么样、显存怎么算、条件控制怎么叠、工作流怎么交付、以及那些看起来像 Bug 其实全是接线问题的故障。如果你手上有几张显卡、想把手上的出图流程做稳做可复现下面的内容应该能省你不少时间。1. 从填表单到拉线ComfyUI 到底改变了哪件事1.1 表单式界面藏起来的那部分逻辑大多数图形化绘画界面走的是表单路线一个大输入框写提示词几个滑块调步数和引导强度一个下拉框选采样器点生成。这套设计对新手极其友好但代价是它把中间过程封装成了一个黑盒。你知道结果好或不好却很难说清楚是哪一环导致的。比如同一段提示词出图偏灰、构图塌、细节糊这三个现象在表单界面里调整手段几乎只有改提示词和换模型两个按钮而真正的原因可能完全不在提示词上——可能是 VAE 解码精度掉了可能是条件控制的权重压过了主体描述也可能是潜空间分辨率不匹配导致的高频崩坏。节点式界面把这层封装撕开了。它把文本编码潜空间初始化采样解码保存这些步骤变成一个个可以单独观察和干预的节点你随时能在任意两个节点之间插一个中间节点去看张量长什么样。我最早意识到这个差别是在调一张产品图的时候表单界面里怎么改提示词都出不来干净的边缘换成节点图后我把解码前的潜空间接出来单独解码一眼就看出是采样步数给太少了高频信息根本没收敛。这种定位效率的差距是节点式工作流最实际的价值跟看起来专业没有半点关系。1.2 图结构带来的可复现性红利节点图的第二个价值是可复现。表单界面的参数散落在界面各处你把截图发给同事对方照着填也可能漏掉一两项而一张节点图保存下来就是一个完整的 JSON包含所有节点的类型、参数和连线关系发给谁都能一模一样地跑出同一张图前提是模型和随机种子一致。这件事在团队协作里价值巨大——我们做电商素材的时候一个基础模板定下来运营只需要改提示词和产品图其余几十个参数一个都不用碰出错率直接降到接近零。更实用的是分支复用。一张图里你可以让同一个潜空间同时走两条采样路径一条低步数快出草图一条高步数精修最后拼在一起对比也可以让同一个模型分别接不同的 LoRA 出多组结果。这种并行结构在表单界面里要靠反复手动操作才能模拟在图里就是多拉两根线的事而且一次运行全部出完。我现在的习惯是任何需要试三五个方案再选的场景都先在图里铺开分支一次跑完再挑比来回改参数省一半以上时间。1.3 谁适合上手谁上手会难受说句实话这个工具不是所有人的最优解。如果你只是偶尔出几张插画、对画面细节没有明确的控制诉求表单式界面完全够用学习节点图的投入产出比并不高。但如果你符合下面任意一条那值得花两三天认真啃需要严格控制构图、姿态、景深、光影方向而不是大致像需要批量生成几百上千张图并且要求参数完全一致需要把出图能力接进自己的脚本或服务里做自动化需要复现别人的效果或者让别人复现你的效果。反过来上手会难受的点也很明确一是节点一多画布会变成一团面条找一根线要花半分钟二是自定义节点生态很杂装错了、版本对不上就会满屏红框三是它对显存的管理策略比较激进第一次遇到模型被反复搬进搬出导致速度骤降的时候很容易怀疑人生。这些问题后面几节都会给具体解法先记住一点节点图乱不是工具的锅是没做分组和整理。2. 拆一张真实工作图数据从加载器走到解码器2.1 主干五件套与它们之间的张量契约把一张最小的可运行图拆开主干其实只有五个节点模型加载器、正向文本编码、负向文本编码、采样器、解码器再加一个潜空间初始化。它们之间的连线不是随便连的每一根线都对应明确的张量类型接错了界面上会直接拒绝连接——这其实是节点式设计最贴心的地方它在连线阶段就帮你挡掉了大量类型错误。具体的数据契约是这样的模型加载器输出三个东西分别是扩散模型主体、文本编码器、变分自编码器这三者要分别接到需要它们的地方。文本编码器吃进字符串吐出条件张量正向和负向各一份采样器同时需要扩散模型、正向条件、负向条件和一个初始潜空间吐出采样后的潜空间解码器把潜空间还原成像素图最后交给保存节点。这中间任何一环的参数变化都会影响最终结果但它们影响的维度不一样文本编码影响语义初始潜空间影响构图尺寸采样器影响收敛质量解码器影响色彩和细节锐度。我自己排图有个固定习惯从左到右依次是模型区、条件区、潜空间区、采样区、输出区用节点组框起来并标上颜色。这么排不是为了好看是因为排查问题的时候你能按区域逐个断开验证。比如出图色彩发灰先怀疑解码区构图不对先怀疑条件区整体糊先怀疑采样区。有了分区排查就从全图瞎猜变成定点检查。节点角色典型输入典型输出出问题时的表现模型加载器权重文件路径扩散模型、文本编码器、变分自编码器加载失败、节点爆红、显存溢出文本编码字符串、文本编码器条件张量语义不生效、提示词互相打架潜空间初始化宽、高、批量空潜空间尺寸报错、构图比例异常采样器模型、正负条件、潜空间、六个参数采样后潜空间画面糊、过饱和、结构崩坏解码器潜空间、变分自编码器像素图全黑、全灰、色彩偏移2.2 采样器的六个数seed、steps、cfg、sampler、scheduler、denoise采样器节点是整个图里参数最密集的地方也是最容易被当成玄学的地方。其实这六个数各自管的事很清楚搞明白分工就不会乱调。随机种子决定的是噪声起点同一个种子加同样的参数必然出同一张图这是复现的基础。步数决定去噪迭代多少次太少高频信息不收敛太多边际收益递减还浪费时间。引导强度控制的是条件张量对结果的拉扯力度数值越高越贴合提示词但过高会让画面过饱和、边缘发硬、结构僵硬数值过低则画面松散、语义漂移。采样算法决定每一步怎么走有的稳有的快有的爱出细节调度器决定噪声 schedule 的曲线形状和采样算法是搭配关系而不是独立参数。最后一个去噪强度在图生图场景里最关键它决定从原图保留多少信息——数值越接近 1 越接近纯文生图越接近 0 越像原图。一个常见误区是把步数和采样算法分开调。实际上它们强耦合二十来步配某种二阶算法加某种曲线调度可能比五十步配最朴素的算法效果更好速度还快一倍。我自己的经验区间是写实向的图用中等步数配收敛快的算法组合插画向可以适当降步数换取更多随机性。至于引导强度除非用了强条件控制一般不要往高位推一旦超过某个阈值画面就会开始出现那种塑料感——颜色艳得失真、暗部死黑、细节糊成一片。这个阈值跟模型训练时的配置强相关换模型必须重新摸一遍。还有一点很少有人提去噪强度小于 1 的时候实际执行的步数会被压缩。名义上设了四十步、去噪强度设成一半真正跑的迭代次数并不是四十。所以图生图重绘的时候如果想要精细控制要么把步数往上抬要么干脆别用去噪强度做粗调而是在提示词和条件控制上做文章。2.3 分辨率为什么必须凑 8 和 64 的倍数新手最先撞上的报错往往跟尺寸有关。原因是这样的像素图要先被编码进潜空间才能采样而编码器的下采样倍率是 8所以宽高必须是 8 的整数倍否则编码阶段就会因为除不尽而报错或者裁切。这还只是最低要求。实际使用中你会发现尺寸凑到 8 的倍数虽然能跑但某些模型在非 64 倍数下会出现明显的边缘重复纹理或者构图偏移尤其是注意力窗口按块切分的实现里块边界对不齐就会留下痕迹。所以稳妥做法是直接凑 64 的倍数。另一个坑是尺寸和模型训练分辨率不匹配。每个扩散模型都有它训练时的主要分辨率区间超出这个区间的尺寸会让模型进入分布外状态典型表现是人物出现两个头、肢体重复、或者画面整体被拉伸。想画大图正确做法不是直接把初始尺寸拉到很大而是先按训练分辨率出图再用放大节点做潜空间放大或者像素放大然后低去噪强度重采样一遍补细节。这个先出再放的两段式流程几乎是所有高质量大图的通用套路直接一步到位拉大尺寸只会得到一张构图崩坏的大图。还有个小细节潜空间放大节点放大的是潜空间而不是像素放大倍率通常取 1.5 左右比较稳放得太大细节会假。放大之后必须接一次低强度重采样否则放大带来的模糊不会被修复。3. 显存这本账什么时候该省什么时候省了反而更慢3.1 一次采样的显存都花在哪显存占用分两块静态的权重占用和动态的中间激活占用。静态部分好算模型权重的参数量乘以精度字节数就是下限。以常见的半精度为例中小模型的主体权重在一到两吉字节量级大一点模型的主体权重会到五吉字节上下再加上两个文本编码器和一个解码器整体常驻占用还要往上加。动态部分才是真正的变量采样过程中每一步都要保存注意力计算的中间结果这部分跟分辨率、批大小强相关而且不是线性增长——分辨翻倍中间的注意力矩阵规模是按平方级膨胀的。所以你会看到一个反直觉的现象换更大的模型显存可能只是紧了一点但把出图尺寸从五百多提到一千或者把批大小从一提到四显存会直接炸掉。原因就是动态激活增长太快。明白了这一点优化方向就很清楚了优先降批大小和分辨率其次才是换模型精度。优化手段省显存的量级对速度的影响对质量的影响建议使用场景降低批大小明显接近线性变慢单批吞吐下降无首选几乎无副作用降低分辨率后放大很明显先快后慢总体可控轻微大图必用权重降到八位浮点中等略快有可见损失显存吃紧时妥协解码分块明显仅解码阶段变慢极小出大图必开强制低显存模式明显明显变慢无显存实在不够时3.2 启动参数与精度开关的取舍启动参数是最容易被乱抄的一环。网上流传的很多参数组合是针对特定显卡和特定版本的照抄到自己机器上经常是能跑但很慢。核心逻辑其实很简单低显存模式的工作原理是把暂时用不到的模块挪到内存里用的时候再搬回来代价是频繁的跨设备传输。如果你的显存其实够用开了低显存模式反而会慢一大截因为它在做无谓的搬运。判断标准是看日志里有没有反复出现权重加载的记录——如果生成一张图的过程中权重被反复搬运说明这个模式开错了或者显存确实不够。精度开关也是同理。把权重降到八位浮点确实能省一截显存、略提速度但扩散模型对这种量化比较敏感暗部容易出现色带、细节容易糊。如果只是自己看草图无所谓但如果要交付成品图我不建议开。折中方案是只对文本编码器做低精度主体模型保持半精度因为文本编码器对量化更宽容而且它只在开头跑一次省下的显存是实打实的。3.3 分块解码与大图拼接解码阶段是显存占用的第二个高峰因为它要一次性把整个潜空间还原成像素图。出大图的时候采样阶段可能勉强能过解码阶段直接爆掉这时候就要用分块解码把潜空间切成若干块逐块解码再拼回去。切块大小可以在设置里调块越小显存越省但接缝风险越大。经验值是从中等块大小开始试如果接缝处出现明显的亮度或纹理跳变就调大块并增加重叠区域。分块解码有个副作用容易被忽略它会改变最终画面的细微纹理分布同一张图开与不开分块解码放大看细节会有差别。所以做对比测试的时候要么全程都开要么全程都不开不要一半一半否则你会误以为是别的参数在起作用。4. 条件控制叠加的顺序问题ControlNet、LoRA、参考图谁先谁后4.1 LoRA 挂在模型链上ControlNet 挂在条件链上这是最容易接错的地方。LoRA 的作用方式是修改模型权重所以它必须挂在模型加载器和采样器之间串联在模型这条线上而 ControlNet 的作用方式是修改条件张量所以它挂在文本编码器和采样器之间的条件线上。搞混了这两条链轻则效果不生效重则直接连线报错。正确的串联顺序是模型加载器输出模型接 LoRA 加载节点LoRA 输出修改后的模型再进采样器。多个 LoRA 就是串联多个节点每个节点有自己的权重参数。这里有个细节LoRA 节点同时也会透传文本编码器所以如果你在 LoRA 后面接文本编码用的是被 LoRA 影响过的编码器如果在前面接用的是原始编码器。这个差别在有些 LoRA 上影响很小但在训练时动过文本编码器的 LoRA 上差别会很明显。我的习惯是统一把文本编码放在 LoRA 之后保证编码器和模型处于同一个被修改过的状态一致性更好。ControlNet 这边节点需要四个输入控制图、控制网模型、正向条件、负向条件输出修改后的正向和负向条件再一起进采样器。所以它的位置一定在文本编码之后、采样器之前。如果同时用了多个 ControlNet就是多个节点串联前一个的输出接后一个的输入。4.2 多个 ControlNet 叠加时的权重分配叠加多个控制网是出精细构图的常用手段比如一张图同时约束姿态和深度。但叠加的时候权重分配很讲究总权重过高会让画面变成控制图的描边失去生成的自然感总权重过低则控制不住。我的经验是把总权重控制在中等偏下的水平然后在多个控制网之间分配主约束给高一点辅助约束给低一点。比如姿态是硬约束、深度是软约束那就姿态给高、深度给低。还有一个更隐蔽的坑多个控制网如果作用于同一段去噪过程它们的介入时机是一样的容易互相打架。更精细的做法是让不同的控制网在不同的去噪阶段介入——前段控制构图和大结构后段控制细节和纹理。这需要能分段控制介入区间的节点社区里有现成的实现。我试过在人物图上用这种方式前三分之一去噪用姿态约束定骨架后段切换到边缘约束修细节出来的效果比全程双开要自然得多代价是图变复杂、调试成本上升。4.3 参考图注入与提示词的关系参考图注入把一张图的视觉特征提取出来作为条件跟 ControlNet 是两回事前者管长什么样后者管在哪。这两者可以同时用但要注意它们和提示词的关系参考图注入的权重过高时会明显压制提示词的作用你写的描述会被参考图的风格覆盖掉。所以用参考图的时候提示词要写得更明确、更具体用文字去锚定参考图没覆盖到的部分。另一个实际问题是一致性。想让同一个角色在不同场景里保持长相一致单靠提示词几乎做不到靠单张参考图也只能做到七八分。稳妥方案是训练一个轻量的角色适配权重配合固定的种子和固定的基础模型再把服装、场景这些变量交给提示词控制。这套组合拳我用了大半年出图的一致性能稳定在可交付的水平比纯靠参考图省心太多。5. 把工作流变成能交付的资产导出、批处理与版本管理5.1 普通保存和 API 导出的区别界面上有两个保存入口很多人混着用结果接脚本的时候疯狂报错。普通保存出来的是带界面信息的完整工作流文件包含节点位置、颜色、分组这些用于再编辑的信息同时也包含节点的参数而 API 格式导出的是精简版只保留节点类型、输入参数和连线关系去掉了所有界面信息。前者给人看后者给程序看。差异带来的实际影响是API 格式里每个节点用一个字符串编号做键值是节点类型和输入字典输入里如果指向另一个节点的输出会写成来源节点编号 输出槽位序号的两元组。脚本调接口时提交的就是这个结构。如果你把普通保存的文件直接提交接口会返回参数校验错误因为它不认识那些界面字段。{ 3: { class_type: KSampler, inputs: { seed: 123456, steps: 28, cfg: 6.5, sampler_name: dpmpp_2m, scheduler: karras, denoise: 1.0, model: [4, 0], positive: [6, 0], negative: [7, 0], latent_image: [5, 0] } } }上面这段就是 API 格式里一个采样节点的样子注意model、positive、negative、latent_image四个字段的值都是节点编号 槽位的形式这就是数据流在 JSON 里的表达方式。5.2 用脚本批量跑图的最小闭环批量出图的最小闭环只有三步提交任务、轮询状态、取回文件。提交是往任务接口发一个包含完整图的 POST 请求请求体里带上图和客户端标识返回里会给出任务编号然后按任务编号轮询历史接口直到状态完成最后按返回的文件名去取图接口下载。import json, time, uuid, urllib.request BASE http://127.0.0.1:8188 CLIENT str(uuid.uuid4()) def submit(graph): payload json.dumps({prompt: graph, client_id: CLIENT}).encode() req urllib.request.Request( BASE /prompt, datapayload, headers{Content-Type: application/json}) with urllib.request.urlopen(req) as r: return json.loads(r.read())[prompt_id] def wait(pid, timeout300): t0 time.time() while time.time() - t0 timeout: with urllib.request.urlopen(f{BASE}/history/{pid}) as r: hist json.loads(r.read()) if pid in hist: return hist[pid] time.sleep(1.0) raise TimeoutError(pid) def fetch(info): files [] for node_out in info[outputs].values(): for img in node_out.get(images, []): q f?filename{img[filename]}subfolder{img[subfolder]}type{img[type]} with urllib.request.urlopen(BASE /view q) as r: files.append(r.read()) return files这段代码能跑但有几个实际使用中必须处理的问题。第一同一个任务编号不要重复提交接口不会帮你做幂等重复提交会重复排队。第二轮询间隔不要设得太短一秒一次已经足够太密只会白白消耗资源。第三批量跑的时候一定要在提交前把种子和图一起改好因为图是静态 JSON你不改它就一直是同一张。第四出错的时候返回里会带节点级别的错误信息这个信息非常有用它会告诉你具体是哪个节点编号的哪个输入不合法直接定位不用猜。5.3 工作流也需要版本管理和命名规范这一点是我踩过最贵的坑。早期我的工作流文件命名是最终版最终版2真的最终版两个月后完全不知道哪个对应哪套参数。后来改成规范命名用途加基础模型加版本号加日期比如产品图-大模型-零三-零九一二。同时在每个图的开头加一个备注节点写清楚这张图的适用场景、依赖哪些自定义节点、依赖哪些模型文件。更关键的是工作流和模型文件必须绑定版本。同一个图配不同版本的模型出来的结果可能完全不一样。所以我把工作流 JSON 和它依赖的模型文件名清单放在同一个目录模型文件本身按版本号归档绝不覆盖。这样半年后回来复现还是能一模一样地跑出来。这件事听起来像强迫症但当你要给客户交一批图、三个月后对方要求再补二十张风格一致的你会庆幸自己当初做了归档。6. 那些看着像 Bug 的接线问题6.1 节点爆红与依赖地狱打开别人的工作流满屏红框是最常见的场景。红框的意思是这个节点类型我没装。解决路径只有一条装对应的自定义节点包。问题在于很多工作流的红框不是缺一个包而是缺七八个而且这些包之间还有版本依赖关系。排查顺序我固定三步走。第一步看红框节点的类型名通常能直接对应到某个包名第二步优先用管理器安装它会自动处理依赖第三步如果管理器装完还是红的就去翻启动日志日志里会写清楚是哪个导入失败、缺哪个模块按报错装对应的库就行。这里有个高频陷阱某个包依赖特定版本的推理框架而你的环境里装的是另一个版本装上之后整个环境都起不来。所以装自定义节点之前务必先备份环境或者用独立环境隔离。还有一个隐性问题装完包重启后节点出现了但连线是断的。这通常是因为包的版本变了、节点输入输出定义改了老工作流里的连线对不上。这种只能手动重连没有别的办法。所以我建议任何要长期使用的工作流都把依赖包的版本号记在备注节点里别用最新版。6.2 出图全黑、全灰、模糊、重复的排查顺序这四类症状我全遇到过每一个的根因都不一样按固定顺序排查能省大量时间。全黑或全白先看解码器。最常见的原因是解码精度不匹配权重是半精度但解码器被强制成了单精度或者反过来导致数值溢出。其次是变分自编码器接错了——有些模型自带解码器有些需要外挂接错了就是一个纯色块。再其次是采样后的潜空间数值异常把解码前的潜空间单独接一个统计节点看一眼数值范围就能确认。整体发灰、对比度低先看引导强度是不是太低其次看是不是用了某种对暗部不友好的采样算法组合最后才怀疑提示词。我遇到过好几次是引导强度设得太保守画面永远差一口气调到合适区间立刻通透。细节糊、边缘软优先怀疑步数不足。但要注意步数够不够跟采样算法强相关同一个步数在快收敛的算法上够用在慢收敛的算法上就不够。另一个常见原因是低强度重采样放大的环节做得太糙放大倍率过大又没有补采样细节自然补不回来。画面重复、人体结构错乱基本可以锁定是分辨率超出模型训练区间或者批大小过大导致注意力窗口错位。先把尺寸降回训练分辨率验证如果正常了就改用先出图再放大的两段式流程。症状第一怀疑对象第二怀疑对象快速验证方法全黑全白解码精度不匹配变分自编码器接错单独解码潜空间看数值整体发灰引导强度过低采样算法组合不当逐步上调引导强度对比细节模糊步数不足放大环节未补采样步数翻倍看是否改善结构重复尺寸超出训练区间批大小过大降回训练分辨率重试6.3 缓存与改了参数没生效最后一个坑最折磨人你明明改了参数出图却一模一样。原因通常是执行缓存——这个工具为了避免重复计算会复用输入没变的节点的结果。如果你只改了某个下游节点的参数但它的上游输入没变那么上游确实不用重算这是正常的但如果你改的是上游参数却感觉没生效多半是因为你改的那个节点没有被标记为需要重算或者你改的是备注节点、空白节点的参数。解决办法很简单改动之后要么手动清空缓存再跑要么直接把种子换掉让整条链失效重算。我现在的习惯是任何一次改参数验证效果都顺手把种子加一这样能百分之百确认结果是新跑出来的。另外节点组复制之后参数是独立的但如果你复制的是共享输入的节点比如靠中转节点共享的模型加载器改其中一个可能会影响另一个这一点在排图的时候要做到心里有数。还有个小细节值得提批量跑图的时候如果图里带了随机种子节点而你通过接口提交图随机种子节点在接口模式下不会自动变化每次提交都是同一个值。想让每张图种子不同必须在脚本里改图再提交别指望它自己变。我个人在实际操作中最大的体会是这个工具真正难的不是学节点怎么连而是建立一套可排查的习惯给节点分组、给工作流命名、给依赖留记录、给出图留参数快照。工具本身的复杂度是有限的真正拖垮效率的永远是三个月后看不懂自己当初做了什么。所以哪怕你现在只是自己玩也建议从第一张图开始就按规范来这套习惯的复利会在半年后显现得特别明显。
阅读完成 · 觉得有帮助？
核心原理与主流框架实战指南)
