ComfyUI 的界面第一眼看上去更像一张电路图，每个方框代表一个处理步骤，连线则决定数据如何在步骤之间流动。这和传统 Stable Diffusion WebUI 的表单式交互差别很大：WebUI 帮你隐藏了模型加载、提示词编码、采样、解码这些环节，而 ComfyUI 把它们全部拆开。拆开的好处是工作流可以复用、中间结果能够单独调试，更重要的是你能清楚地看到哪些模型常驻显存、哪些张量在某个节点之后就可以释放。理解节点连接逻辑和显存优化原理，是用好 ComfyUI 的关键，也能解释为什么同样的任务在不同启动参数下显存占用差异巨大。
节点连接本质：有向无环图与数据槽
ComfyUI 中的每个节点都可以看作一个有输入槽和输出槽的函数。输入槽接收特定类型的数据，比如 MODEL、CLIP、CONDITIONING、LATENT 或 IMAGE，输出槽产出一个或多个结果。连线只能发生在类型兼容的槽之间，UI 会为不同类型使用不同颜色，但颜色只是一种提示，真正决定能否连接的是内部类型定义。把 MODEL 直接连到 LATENT 输入会被拒绝，因为模型权重张量和潜在空间张量无法直接参与后续计算，必须经过 KSampler 或 VAEDecode 这样的节点转换。
执行顺序不由节点在画布上的摆放位置决定，而是由依赖关系推导。ComfyUI 会把所有连线解析成一张有向无环图，只有所有上游节点都执行完毕后，下游节点才会开始。画布上看起来靠上的节点不一定先运行，看起来靠右的节点也不一定后运行。你只要记住：数据从加载节点流向采样节点，再流向解码节点，最后到保存图像。触发一次队列后，系统会从输出端反查所有需要计算的节点，未连接到结束节点的旁支不会被执行。这也是有些节点放在那里却不运行的原因。
在底层，节点之间的连接用数组 [节点ID, 输出槽索引] 表示。下面是一个简化的工作流 JSON 片段，展示 KSampler 如何引用其他节点的输出：
{
"3": {
"class_type": "KSampler",
"inputs": {
"model": ["4", 0],
"positive": ["6", 0],
"negative": ["7", 0],
"latent_image": ["5", 0]
}
}
}
这里 model 来自节点 4 的第 0 个输出槽，其他输入同理。节点 4 通常是 CheckpointLoaderSimple，节点 5 通常是 EmptyLatentImage。理解这种数组引用方式，有助于你阅读导出的工作流文件，也能在脚本里动态修改连接关系。
连接逻辑中容易踩的坑
第一个常见问题是类型混淆。初学者往往把 MODEL 当成可以直接用于解码的潜在空间变量，或者把 CLIP 输出直接接到 KSampler 的 positive 输入。实际上 CLIP 节点本身不产生条件张量，必须经过 CLIPTextEncode 把文本转换成 CONDITIONING，才能被采样器消费。类似地，VAE 不是图像，LATENT 也不是像素，解码必须经过 VAEDecode。
第二个坑是扇出和扇入。同一个模型输出可以连接到多个采样节点，这没问题，但每一条分支都会增加显存压力，因为后续节点可能同时需要读取同一份模型权重，系统必须为不同分支保留中间激活。反过来，多个节点的输出同时接入一个节点的多个输入槽时，要确认每个槽的类型一致，例如 LoadImage 生成的 IMAGE 与 VAEDecode 生成的 IMAGE 类型相同，但如果混入 LATENT 就会失败。循环连线会被直接禁止，因为 ComfyUI 要求工作流是无环图，闭环会让执行计划无法确定终点。
第三个坑是节点执行状态。节点在队列运行时会有边框高亮或进度提示，没有被任何最终输出节点依赖的节点不会执行。如果你发现某个 PreviewImage 没有更新，先检查它是否连接到了主流程，或者它本身是否就是终点。有人会在画布上放多个 SaveImage，只有其中一个有效，其他不产生输出，这时要留意所需的分支是否真正连接到了有效输出。
显存优化原理：缓存策略与模型卸载
ComfyUI 之所以常被认为比传统 WebUI 更省显存，根源在于它采用了更细致的计算图缓存和模型生命周期管理。WebUI 运行时，模型、VAE、CLIP 以及一些中间状态往往一起常驻显存，而 ComfyUI 会分析节点依赖，只保留尚未被后续节点消费的张量。一个节点输出如果已经被所有下游节点读取完毕，对应的中间结果就可以被标记为可回收。这意味着在生成一张图的过程中，显存占用不是一条直线，而是随着节点执行不断上升又下降。
模型加载环节的拆分尤其重要。一个标准 Checkpoint 文件同时包含 UNet、CLIP 和 VAE 三部分。ComfyUI 的 CheckpointLoaderSimple 会一次性读取这些权重，但后续节点并不是同时都需要它们。文本编码阶段只用到 CLIP，采样阶段只用到 UNet，解码阶段才需要 VAE。通过节点拆分，ComfyUI 在不需要某部分权重时可以让它留在 CPU 内存或磁盘缓存中，直到对应节点执行前再加载到 GPU。这样即使显存很小的显卡，也可能通过不断换入换出跑完整个流程，代价是速度下降。
显存优化的另一个核心是 lowvram 模式。启动时加入 --lowvram，ComfyUI 会尽量减少常驻在 GPU 上的模型层数，每次计算时只把需要的层搬到显存，计算完成后释放。更极端的 --novram 会尽量不保留任何模型权重在显存中，只保留当前激活张量，所以速度最慢。相反，--highvram 会尽可能把模型常驻显存，换取最快速度。下面是一个低显存启动命令示例：
python main.py --lowvram --cpu-vae --reserve-vram 1.0
--cpu-vae 会把 VAE 强制放在 CPU 上运行，进一步降低解码阶段的显存峰值；--reserve-vram 则预留一部分显存给系统和驱动，防止 OOM。实际使用时，可以根据任务类型调整：只跑文生图且显存紧张时用 lowvram；需要高吞吐量且显存充裕时用 highvram。
分辨率、批次大小与显存的关系也直接受连接逻辑影响。潜在空间图像尺寸增大会让 UNet 的中间激活张量成倍增加，这时即使模型权重已经优化得很好，激活占用的显存也会迅速膨胀。批次大小从 1 增加到 2，UNet 中每一层的激活都会翻倍。节点连接如果包含多个分支，比如同时做放大和对比度调整，每条分支都可能保留自己的中间结果，增加显存峰值。因此优化工作流结构、减少不必要的分支，比单纯加启动参数更有效。
工作流层面的显存优化实践
除了启动参数，节点连接方式对显存影响同样很大。一个常见做法是合并重复的模型加载节点。如果你的工作流里有两个 CheckpointLoaderSimple 分别加载同一个模型，ComfyUI 可能把它们视为两个独立实例，各自占用一份显存。即使底层有缓存机制，也不应该依赖它去消除重复，最好让所有采样节点共享同一个加载节点的输出。这不仅节省显存，也避免加载两次模型浪费时间。
其次是按需拆分 VAE 和 CLIP。很多工作流在开始阶段就用 CheckpointLoaderSimple 直接输出三样东西，然后一路传到底。更省显存的方式是使用 Load Checkpoint 节点后，只在文本编码前保留 CLIP，采样结束后再加载 VAE 进行解码。ComfyUI 有专门的 VAELoader 节点，可以从指定路径单独加载 VAE，这样在采样阶段完全不需要 VAE 占用显存。对 ControlNet、LoRA 等附加模块也是同样的思路：用到了再加载，用完就断掉连接，让系统有机会释放。
预览节点和保存节点也可能成为隐形的显存消耗点。每一个 PreviewImage 都会把潜在空间解码成图像并保存一份像素数据，如果同时连接多个预览节点，显存中就会存在多份解码后的图像张量。建议只保留最终结果预览，中间调试用 SaveImage 临时输出，调试完成后删除或断连。对于最终输出，优先使用 VAEDecode 后再接 SaveImage，避免在多次解码过程中反复占用 VAE。
总的来看，ComfyUI 的节点连接逻辑和显存优化是同一件事的两面：连线定义了数据依赖，也定义了模型和张量的生命周期。理解类型系统能帮你避免连接错误，理解缓存释放规则能帮你规划更省显存的工作流结构。入门阶段不必一次性掌握所有节点，但抓住模型加载、文本编码、采样、解码这四条主线，再配合 --lowvram、--cpu-vae 等参数，就能在有限硬件上稳定地跑通大部分任务。之后随着工作流变复杂，再逐步调整节点分支、合并重复加载、拆分 VAE 与 CLIP，显存问题往往能在不更换显卡的情况下得到明显改善。