用 AI 生图的人大多接触过 ComfyUI：一堆节点连线，拖动参数，点运行出图。相比一句话提示词的黑盒，它能精细控制每一步。
这篇拆一下这套节点工作流的技术原理，以及为什么它成了生图的标准工具。
一、节点即计算单元
ComfyUI 的核心模型是有向无环图（DAG）：每个节点是一步计算，节点之间的连线表示数据流。
一个典型文生图工作流：
[加载模型 Checkpoint]
↓
[文本编码 CLIP] ← [正向提示词]
↓
[文本编码 CLIP] ← [负向提示词]
↓
[采样器 KSampler] ← [随机种子][步数][CFG]
↓
[解码 VAE]
↓
[保存图片]
每个节点有输入端口和输出端口，连线的方向决定执行顺序。这和传统图像处理软件的"图层"模型完全不同——图层是叠加结果，节点是传递中间张量。
二、执行引擎怎么调度
节点图不是简单按顺序执行的，引擎要做几件事：
1. 拓扑排序。 先算出哪些节点没有依赖，从这些开始执行，再逐步推进到叶子节点。
2. 结果缓存。 这是关键优化。如果某个节点的输入和参数都没变，引擎会直接复用上次的输出，不重新计算。所以改了提示词只重跑下游节点，改采样步数只重跑采样之后的部分。
3. 显存管理。 生图模型很大，中间张量（latent、attention 中间结果）占显存。引擎要在合适的时机把不再需要的张量释放，腾出空间给后续节点。显存不足时通常会分段执行或降精度。
4. 增量执行。 改了某个参数，只重算受影响的部分。这让"调参—预览"的迭代很快。
三、Lora 是怎么加载进去的
Lora 是常见的风格微调手段，技术上是低秩适配矩阵——不改动原模型权重，额外挂一小份参数，推理时叠加。
在 ComfyUI 里，加载 Lora 是一个独立节点：
[Checkpoint 模型] → [Lora Loader（选Lora文件，设权重）] → [采样器]
技术上要注意三点：
- Lora 要匹配基础模型架构，不匹配会加载失败或效果异常
- 权重系数可调（0.5–1.0 常见），系数过高会出现过度风格化
- 多个 Lora 可叠加，但顺序和权重组合会影响结果，需要实验
四、工作流文件本质是 JSON
导出的工作流是一个 JSON 文件，描述每个节点的类型、参数、连接关系。这带来几个工程好处：
可版本管理。 工作流进 git，和代码一样有变更历史。
可参数化。 把提示词、种子、步数抽成变量，一份工作流跑不同配置。
可批量执行。 用脚本调 API 提交工作流 JSON，带不同的输入参数，批量出图。
可复现。 同样的工作流 + 同样的种子 + 同样的模型，结果一致。
这也是为什么 ComfyUI 能被做成"预置工作流"服务——平台提供一份调好的工作流文件，用户只改几个参数就能用。
五、参数对结果的影响
几个关键参数的技术含义：
| 参数 | 作用 | 实践建议 |
|---|---|---|
| 采样步数 Steps | 去噪迭代次数 | 20–30 通常够，过高边际收益低 |
| CFG Scale | 提示词约束强度 | 7–9 常见，过高会出现色彩溢出 |
| 采样器类型 | 去噪算法 | 不同采样器风格差异明显，需实验 |
| 分辨率 | 输出尺寸 | 超出模型训练分辨率易出现结构崩坏 |
| 种子 Seed | 随机初值 | 固定种子可复现，用于调其他参数 |
新手常犯的错误是把步数拉得很高以为效果更好，实际上超过一定步数收益很小，只是耗时增加。真正的效果提升来自提示词质量和采样器选择。
六、部署这套工作流的技术要求
跑 ComfyUI 需要一定资源：
- 显存：生图模型 8GB 显存起步，大分辨率或复杂工作流需要更多
- 内存：加载模型和处理中间数据，16GB 起
- 存储：模型文件动辄几 GB，多个 Checkpoint + Lora 会占几十 GB
- CPU：主要用于预处理和后处理，不是瓶颈
如果本地跑不动，部署到云上是常见方案：买一台带 GPU 的实例，装好环境，起服务，通过浏览器访问；或者用 Serverless GPU 方案按需拉起实例。
Serverless 方案的代价是冷启动——模型要重新加载。但对批量任务来说影响可接受，一次提交一批图，冷启动成本被摊薄。
七、写在最后
ComfyUI 的价值不在于"能生图"，而在于把生图流程变成了可视化、可复用、可参数化的图结构。理解节点引擎的执行逻辑，你就能判断哪些改动是廉价的（只重跑下游），哪些是昂贵的（换基础模型），从而高效地调试工作流。
相关的函数计算 AI 应用部署方案可以看官方页面——查看函数计算部署 ComfyUI 与 AIGC 应用的技术方案。具体资源配置与计费以页面实际展示为准。
你们用 ComfyUI 是自己搭的还是用现成的工作流？调参踩过哪些坑？评论区聊聊。
