ComfyUI（Comfy-Org/ComfyUI）：把扩散模型推理拆成节点图的开源引擎，FLUX 3 Klein 首发即支持，8GB 显存跑 5.6B 模型

一、导读

2026 年 10 月 19 日，ComfyUI 在 GitHub 日涨星榜上拿下 1011 颗星，总星数达到 139381（截至 2026-10-20）。这家 2023 年初诞生的「Stable Diffusion 图形界面」，如今已经长成覆盖图像、视频、3D、音频、文本的全模态扩散模型引擎，并且仍然是几乎所有开源图像模型发布时的「Day-0 支持」首选阵地——三天前 Black Forest Labs 开放 FLUX 3 Image Klein（5.6B）权重，ComfyUI 当天跟进支持，随后连发 v0.41.0、v0.42.0、v0.42.1 三个版本。本文基于仓库源码、Release Notes 与官方博客的一手资料，拆解它的执行引擎与显存管理架构，并给出四个可落地的应用场景。

二、项目速览

项目	内容
仓库	Comfy-Org/ComfyUI（主开发线 comfyanonymous/ComfyUI 重定向至此）
当日涨星	+1011（2026-10-19，日榜大模型相关项目第一）
总星数 / Fork	139381 ★ / 16551 fork（截至 2026-10-20）
语言 / License	Python（PyTorch）/ GPL-3.0
创建时间	2023-01-17
定位	节点图驱动的扩散模型推理引擎与工作流编排器（图像/视频/3D/音频/文本）
发布节奏	每周一个版本（v0.42.1 发布于 2026-10-19），Core / Desktop / Frontend 三仓库联动
核心依赖	torch、comfy-aimdo（权重动态卸载）、comfy-kitchen（快速算子库）、SQLAlchemy + alembic（本地元数据库）
商业化	Comfy Desktop（免费桌面版）、Comfy Cloud（付费云）、Comfy API（工作流部署为生产 API）、Comfy Router（多模型统一 API）、Partner Nodes（闭源模型接入）

三、为什么是它：一次教科书级的「模型首发红利」

ComfyUI 的这波涨星，直接动因是三个新模型在同两周内的密集落地：

第一，FLUX 3 Image Klein 开放权重。Black Forest Labs 于 2026-10-15 发布 Klein 版本：5.6B 参数，比上一代 FLUX.2 [klein] 的 9B 少 38%，支持文生图、图像编辑与最多 10 张参考图的多参考生成，原生 4K 输出，提供 base 与步数蒸馏两个权重版本（来源：bfl.ai 博客，2026-10-20 获取）。HN 上相关帖子拿到 213 分（2026-10-16）。ComfyUI 在 v0.41.0（2026-10-15）当天加入 Flux3-image 模型支持（PR #17064），并在 v0.42.0 把节点标签更新为「FLUX 3 Image」。

第二，同期还有多路模型并进：v0.42.0 加入 MOSS-image 支持（PR #17095，含 fused situ 加速）与 Krea 3 Image 的 Partner 节点；v0.41.0 加入 MiniMax-H3 LightVAE 支持；此前 8 月的 MiniMax H3「Day-0 支持」曾让 ComfyUI 登上 HN 热榜（334 分，2026-08-03）。开源图像模型每发一枪，ComfyUI 的星星就涨一波，这个模式在过去一年反复验证。

第三，版本节奏本身也在制造事件感。ComfyUI 从 2026 年中起改为每周发布：v0.40.0（10-13）、v0.41.0（10-15）、v0.42.0（10-18）、v0.42.1（10-19），近 7 天合入 47 个 commit。对用户而言，这意味着「新模型发布 → 等一个 ComfyUI 版本 → 拉官方模板工作流」的路径稳定在几天之内，社区自然把它当作开源扩散模型的「事实发行渠道」。

值得注意的是，ComfyUI 的定位已经从「diffusion GUI」悄悄升级为「AI content creation engine」：README 明确列出文本生成（Gemma 3/4、Qwen3、Qwen3-VL）也已原生支持，一个节点图引擎同时装下了扩散模型与语言模型两条技术栈——这也是它能在「大模型应用」语境下持续占据涨星榜的结构性原因。

四、架构原理

4.1 整体架构：一张图看懂数据流

ComfyUI 是一个前后端一体的 Python 单体服务：浏览器里的节点画布只负责编辑与序列化，所有推理都发生在本地服务端。一次生成的完整数据流如下图：

flowchart TB
    subgraph FE["浏览器前端（ComfyUI_frontend 仓库，独立发包）"]
        C["节点画布<br/>Litegraph 编辑器"] --> S["序列化为 prompt JSON<br/>节点 id → class_type + inputs"]
    end
    S -->|"POST /prompt"| API["server.py<br/>aiohttp HTTP + WebSocket"]
    API --> V["validate_prompt 校验<br/>object_info 节点 schema"]
    V --> G["comfy_execution<br/>DynamicPrompt → TopologicalSort<br/>→ ExecutionList 增量执行"]
    G -->|"缓存命中跳过"| X["nodes.py / comfy_extras<br/>约 600+ 节点实现"]
    X --> P["comfy/model_patcher.py<br/>LoRA / ControlNet 权重挂载"]
    P --> MM["comfy/model_management.py<br/>VRAMState 六态 + 预算式调度"]
    MM --> AIM["comfy-aimdo<br/>host_buffer / vram_buffer<br/>多 CUDA stream 异步权重流"]
    AIM --> K["comfy-kitchen 快速算子<br/>fp8 / nvfp4 / mxfp8 / int8"]
    K --> MD["comfy/ldm 模型实现库<br/>189 个文件，覆盖 40+ 模型家族"]
    MD --> W["WebSocket 推送进度与预览图"]
    W --> FE2["前端画布实时预览"]
    X --> O["输出落盘 /view 取图<br/>工作流元数据写入 PNG"]

支撑这张图的是四个各司其职的仓库与一组核心模块：Core 仓库（每两周一个稳定版、每周一个 master 版）承载全部推理逻辑；Frontend 仓库独立开发、以 comfyui-frontend-package 依赖打包进 Core；Desktop 仓库用 Electron 壳封装出免配置的桌面版；工作流模板则以 comfyui-workflow-templates 数据包每周随版本更新。

4.2 执行引擎：节点图如何变成一次推理

ComfyUI 的执行层在 comfy_execution/ 中实现，核心是一条三段式流水线。前端把画布序列化成 prompt JSON 后 POST 到 /prompt，服务端先做 validate_prompt 校验（节点存在性、输入类型匹配），再把 JSON 包装成 DynamicPrompt——这个类支持子图嵌套与动态 prompt 扩展，节点可以在运行时产出新的节点图（subgraph 节点与 ephemeral 节点都由它承载）。

接下来是 TopologicalSort。它不是一次算出全图拓扑序，而是迭代式的：get_ready_nodes 只返回当前输入就绪的节点，执行器边跑边问，天然支持 lazy evaluation——某些节点声明了 lazy 输入后，只有真正需要其输出时才会执行。这套机制让「预览图出来就停」这类交互成为可能。

ExecutionList 继承自 TopologicalSort，执行时逐节点查询 is_cached：每个节点的输入签名做哈希（仓库引入了 blake3 做哈希），签名没变的节点直接复用上次输出。这就是 ComfyUI 最被低估的体验优势——改一个提示词重跑，前面的加载模型、编码潜图全部跳过，只有变化的子图重新执行。部分图重执行（partial graph re-execution）配合异步队列，让画布像一个增量求值的响应式系统，而不是「每次点按钮从头算」的批处理脚本。

执行结果通过 WebSocket 实时推回：进度条、预览图（可用 TAESD 快速潜图解码）、输出文件路径。v0.40.0 起 prompt 的 WebSocket 消息还支持附带业务元数据，方便上层系统关联自己的任务 ID。

4.3 显存管理：VRAMState 六态与预算式调度

ComfyUI 能在 4GB 显存消费级显卡上跑大模型，靠的是 comfy/model_management.py（74KB 的单文件）里一套朴素但精准的资源状态机。启动时探测显存，把设备归入六种 VRAMState：DISABLED（纯 CPU）、NO_VRAM、LOW_VRAM、NORMAL_VRAM、HIGH_VRAM、SHARED（无独显显存、CPU/GPU 共享内存的统一内存架构，Apple Silicon 走 MPS 即归入此类）。状态决定了后续所有策略的激进程度。

一次执行前的模型装载由 load_models_gpu 统一调度，逻辑值得细读：先把本次需要的模型（含 LoRA 等 model patches）按序去重；已驻留的标记为继续使用，被克隆替代的旧模型卸载；然后对每个 GPU 设备计算「所需显存 × 1.1 + 推理预留」，调用 free_memory 驱逐已有模型腾出空间；最后逐模型决定装载量——关键一行是 lowvram_model_memory 的计算：显存放得下就全量进卡，放不下则按 min(空闲显存 × 比例, 空闲显存 − 推理预留) 算出能塞多少权重，其余留在系统内存里。模型权重因此是「部分常驻显存」的，forward 时再把缺的部分按层搬入。这套预算式调度让「多大卡跑多大模型」变成连续可调，而不是「跑不动就 OOM」的二值事件。

v0.40 之后的版本又加了一层「pin（钉住）与分级驱逐」：常用模型的权重可以 pin 在显存或锁页内存中避免反复搬运，内存吃紧时按 pin_eviction_tiers 的优先级逐级释放（先驱逐非当前 prompt 使用的 pin）。这对「连续生成几百张图」的挂机场景收益明显。

4.4 comfy-aimdo：异步权重流式卸载

2026 年 ComfyUI 做的一次最重要的架构手术，是把权重搬运从「同步阻塞」改成「异步流水线」，并抽成了独立 PyPI 包 comfy-aimdo（AI Model Dynamic Offloader，当前版本 0.5.6）。它提供 host_buffer 与 vram_buffer 两个缓冲池，配合多 CUDA stream 工作：源码中 NUM_STREAMS 控制流数量，一条流上的 kernel 在消费第 N 层权重时，另一条流已经在把第 N+1 层从主机内存搬入显存、并把冷权重搬回，计算与传输重叠后小显存卡也能「流式」跑完一个大模型，README 的说法是 4GB VRAM + 8GB RAM 即可相对快速地跑最大的开源模型且打满 GPU 算力。日志里对应的提示是 Using async weight offloading with N streams。

这也解释了 v0.42.0 里 CPU device doesn't support fp8, nvfp4, mxfp8 or int8 这类提交：量化权重的格式支持与搬运路径深度耦合，CPU 回退路径必须显式排除不支持的格式。

4.5 算子与量化：comfy-kitchen 与注意力统一层

推理性能的另一条腿是算子。comfy-kitchen（0.2.39）是官方的快速算子库，支持多计算后端，把线性层的 prologue/epilogue 融合、注意力 kernel 选择（v0.40.0 起所有模型统一接入 comfy_attention 配置，可选 kitchen sol attention 等实现）收拢到一处。量化方面，ComfyUI 原生理解 fp8、int8、mxfp8、nvfp4（与 NVIDIA 合作引入的 4-bit 浮点格式）权重的加载与计算，v0.42.0 还补了「comfy 量化格式」的官方文档。落地效果可以直接看第三方数字：FLUX 3 Klein 官方模型卡给出的路径是 BF16 需 11.2GB 显存、FP8 需 5.6GB、INT8 可在 8GB 显存的 RTX 卡运行；蒸馏版 + INT8 在 RTX 5090 上约 4 秒生成 1MP 图、RTX 4070 上 9 秒内（来源：bfl.ai，2026-10-20 获取）。ComfyUI 的模型描述层会把模型声明成「分量的集合」——diffusion 模型、VAE、text encoder、LoRA 各自独立加载、各自量化，这正是「量化全家桶」能跨 40 多个模型家族复用的原因。

4.6 与同类架构路线的差异

同样做「扩散模型服务」，四条技术路线的取舍差异很大。ComfyUI 选择自研全栈：自己的执行引擎、自己的显存管理、自己的算子库，模型支持靠在 comfy/ldm（189 个文件）里逐家实现；Diffusers 走「代码即接口」路线，把模型做成 Python 类库让开发者写代码调用，不解决 UI 与调度；InvokeAI 是产品化路线，固定画布 + 队列的面板式体验，换来的易用性以灵活性为代价；WebUI Forge 系则在 gradio 表单范式上做性能修补，2025 年 7 月后已停止更新。SwarmUI 则干脆把 ComfyUI 当后端引擎，只做前端壳——生态已经用脚投票：节点图引擎成为共享底座。

五、应用场景

场景一：8GB 显存消费级显卡上的本地文生图与图像编辑

痛点：商业 API 按张计费且数据出域，而 5.6B 级别的新模型对显存要求看起来高不可攀——BF16 权重就要 11.2GB。

解决路径：ComfyUI 的量化加载 + 部分驻留让 Klein 在 8GB 卡上可用。官方模板工作流把「加载 FP8 权重 → 双编码器 → 蒸馏采样 4~8 步 → VAE 解码」封装成一键模板，FP8 权重需求 5.6GB、INT8 需求 8GB；RTX 5090 上蒸馏版 + INT8 约 4 秒一张 1MP 图（数字来源：bfl.ai 模型卡，截至 2026-10-20）。

最小示例：

pip install comfy-cli
comfy install
comfy launch
# 浏览器打开 http://127.0.0.1:8188
# 菜单 → Workflows → 搜索 "Flux 3 Klein"，加载官方模板后放入模型路径即可出图

收益与指标：零 API 成本、数据不出本机；配合 PNG 元数据回读，生成的每一张图都内嵌完整工作流与随机种子，改参数重跑可精确复现。

适用边界：FLUX Kommunity License 规定个人与年收入低于 500 万美元的公司可免费商用，更大规模需商业授权；再往上的 4K 原生输出、复杂编辑链路对显存的要求会重新抬升，4GB 级老卡建议改用更小的模型家族。

场景二：视频与音频生成的本地管线

痛点：开源视频模型（Wan 2.2、HunyuanVideo 1.5、LTX-Video 2.3、CogVideoX）各家权重结构、VAE、文本编码器差异极大，逐家写推理代码成本高。

解决路径：ComfyUI 已把这些模型家族全部实现在 comfy/ldm 中，模板库里按「video-generation」标签提供现成工作流；视频 VAE 这类热点组件官方直接做优化，如 MiniMax H3 视频 VAE 提速 2 倍（官方博客）。2026 年 8 月 MiniMax H3 发布时，官方演示了单张 GPU 上生成带原生音频的 2K 直播视频（HN 334 分，2026-08-03）。

最小示例（命令行提交工作流，不打开浏览器）：

# 模板工作流保存为 workflow.json 后，用脚本直接投递
python script_examples/basic_api_example.py
# 或经 HTTP：POST http://127.0.0.1:8188/prompt  body={"prompt": <workflow JSON>}

收益与指标：一套 UI 覆盖文生视频、图生视频、插帧、上采样全链路；异步队列 + 增量重执行让「改最后一帧提示词重跑」不必重算整条链。

适用边界：视频生成的显存峰值远高于图像，12GB 以下显存建议从 LTX-Video 等轻量家族起步；长视频仍需分段生成再拼接。

场景三：把工作流变成生产 API

痛点：算法团队在画布上调好的生成管线，工程团队往往要用自研代码重写一遍才能上线，两套实现长期漂移。

解决路径：ComfyUI 的工作流本身就是一份 JSON，/prompt 接口就是生产入口，/api/jobs 提供作业查询与取消，WebSocket 推送进度与预览。官方 2026 年还上线了两层托管方案：Comfy API 把工作流直接部署为生产 API；Comfy Router（2026-09 发布）则提供一个统一 API 调用多家前沿媒体模型。不想上云也可用 Partner Nodes 在本地画布内调用 Nano Banana 2.1、Krea 3 等闭源模型，--offline 参数可让整个核心保持完全离线。

最小示例（Python 提交并取图）：

import json, urllib.request

workflow = json.load(open("workflow.json"))["output"]
body = json.dumps({"prompt": workflow}).encode()
r = json.load(urllib.request.urlopen(
    urllib.request.Request("http://127.0.0.1:8188/prompt", data=body,
                           headers={"Content-Type": "application/json"})))
print(r["prompt_id"])  # 轮询 /history/{prompt_id} 后经 /view 取图

收益与指标：画布调参 → 线上服务零转译，工作流 JSON 可进 Git 做版本管理；/object_info 输出全部节点的输入 schema，可直接生成表单或给 LLM 做工具调用。

适用边界：开源版服务是单进程队列模型，高并发要自己在前面做排队与横向扩容，或改用官方云版；这是「单机推理引擎」而不是开箱即用的多租户平台。

场景四：新模型的 Day-0 复现与算法实验

痛点：新模型论文发布当天，研究者要的是「跑通、对比、改结构」，而不是读一周代码。

解决路径：ComfyUI 已是开源媒体模型的事实发行渠道——FLUX 3 Image Klein（10-15）、MOSS-image、Qwen-Image-2.1（支持透明通道）都在发布当日或次日进入主线，并附带官方模板工作流。实验时用「部分图重执行」改一个采样器或换一个 LoRA 只重算差异子图；节点输出即缓存，网格对比实验的成本接近线性。

最小示例：加载模板 → 右键节点选 bypass（旁路等效于从图中摘除并直连）做消融实验 → Ctrl+M 静音对比分支 → 导出工作流 JSON 归档。

收益与指标：模型加载、文本编码等公共前缀全部命中缓存，消融实验的迭代粒度从「分钟级整链重跑」降到「秒级局部重算」；工作流 JSON + PNG 元数据让实验天然可复现。

适用边界：主线每周更新，自定义节点可能因 API 变动暂时失效（官方已从 v0.40.0 起加入 custom node 治理机制缓解）；追求严格可复现的论文实验建议锁定版本号。

六、快速上手

最省事的路径是桌面版（Windows/macOS）：从 comfy.org/download 下载 Comfy Desktop，安装器内置 Python 环境与 PyTorch。命令行用户走 comfy-cli：

pip install comfy-cli
comfy install          # 安装 ComfyUI 与依赖
comfy launch -- --cpu  # 无独显时加 --cpu

手动安装（Linux/服务器）建议 Python 3.13 + 最新版 PyTorch（NVIDIA 20 系以上需 cu130 及以上）；Windows 便携包解压即用，自带 Python 3.13 与 CUDA 13.0。模型放到 models/ 对应子目录（checkpoints、diffusion_models、vae、text_encoders、loras），也可用 extra_model_paths.yaml 把 WebUI 等其他工具已下载的模型目录直接挂进来，避免重复下载数十 GB 权重。开箱后按 Ctrl+D 载入默认工作流，Ctrl+Enter 出第一张图。

七、横向对比

方案	星数（截至 2026-10-20）	形态	核心优势	主要短板
ComfyUI	139381	节点图引擎 + 桌面/云/API	自研执行与显存管理，Day-0 模型支持最快，增量重执行，全模态覆盖	节点图学习曲线陡；周更节奏对 custom node 有兼容压力
Diffusers	34759	Python 模型库（Apache-2.0）	代码优先，HF 生态集成最深，pip 即用	无 UI 与调度，生产化需自建
InvokeAI	28761	面板式创作产品	画布/队列体验对画师友好，上手快	灵活性与模型覆盖不及节点图路线
WebUI Forge	13072	gradio 表单式 WebUI	A1111 习惯延续，低显存优化好	2025-07 后停止更新，新模型跟进停滞
SwarmUI	4683	ComfyUI 之上的简化前端	把 ComfyUI 当后端，表单易用性 + 节点图底座两全	依赖 ComfyUI 主线，抽象层本身也有一层学习成本

一张表看懂路线分歧：Diffusers 服务开发者，InvokeAI 服务画师，Forge 系已成历史，而 ComfyUI 用「节点图 = 可序列化、可缓存、可 API 化的工作流」这一个抽象，同时吃下了创作者、研究者与工程化三个群体——SwarmUI 直接复用其引擎是最直接的认可。

八、局限与风险

第一，许可证不是完全开源意义上的自由。ComfyUI 核心是 GPL-3.0，而 FLUX 系权重走 Kommunity License（年收入超 500 万美元的组织需商业授权），把两者组合进商业产品前要分别核对授权边界；闭源模型经 Partner Nodes 调用则是按量付费的 API，--offline 才能保证完全离线。

第二，版本节奏是双刃剑。每周发布 + 约两周一个稳定版意味着新模型接入极快，但 master 分支的提交「可能非常不稳定并破坏许多 custom node」（README 原话）；生产环境应只跟稳定 tag，并锁定版本。

第三，复杂度并没有消失，只是被节点图封装了。理解采样器、VAE、文本编码器、量化格式依然是出好图的前提；节点图对「线性流程」的表达反而比代码啰嗦，纯批处理任务用 Diffusers 写脚本可能更直接。

第四，单写者架构的扩展天花板。核心服务是单进程队列，多用户高并发需要外层自建排队与扩缩容，或迁移到官方云；视频等长任务的资源隔离也要自己负责。

第五，生态质量参差。第三方 custom node 数以千计，供应链与维护状况不一——官方 v0.40.0 起引入治理机制（governance enforcement）是改善的开始，但引入前仍应自行审查来源与更新时间。

九、小结与行动建议

ComfyUI 的价值早已超出「一个 Stable Diffusion 界面」：它把扩散模型推理拆成了可序列化、可增量重算、可 API 化的节点图，并在显存管理（VRAMState 预算调度 + comfy-aimdo 异步权重流式）与算子量化（fp8/nvfp4/int8、comfy-kitchen）上把消费级显卡的极限一推再推。涨星榜的反馈说明，在开源媒体模型爆发的周期里，「最快跑上新模型」本身就是最强的增长引擎。给不同读者的行动建议：

1. 个人创作者：直接装 Comfy Desktop，从官方模板库的 FLUX 3 Klein 模板起步，8GB 显存即可进入 4 秒级出图循环。
2. 算法研究者：把工作流 JSON 纳入实验管理，用 bypass 与缓存机制做低成本消融；新模型论文日当天先查 ComfyUI 是否已有模板。
3. 工程团队：用 /prompt + /api/jobs 把画布管线原样搬上服务端，高并发场景评估 Comfy API 云版或自建排队层；生产环境锁定稳定版 tag。
4. 商业项目：上线前完成双许可证审查（GPL-3.0 核心 + 模型权重授权），年收入超 500 万美元的组织需为 FLUX 系权重取得商业授权。
5. 关注两个信号：文本生成（Qwen3、Gemma）进入节点图引擎，以及 Comfy Agent、Comfy Router 的推进——如果节点图引擎成为「多模态智能体」的执行底座，它的故事就不只是画图工具了。

参考资料

1. ComfyUI README（master 分支，raw.githubusercontent.com），获取日期 2026-10-20：https://github.com/Comfy-Org/ComfyUI
2. ComfyUI Releases v0.40.0 / v0.41.0 / v0.42.0（2026-10-13/15/18），获取日期 2026-10-20：https://github.com/comfyanonymous/ComfyUI/releases
3. Black Forest Labs 博客《FLUX 3 Image Klein》（2026-10-15），获取日期 2026-10-20：https://bfl.ai/blog/flux-3-image-klein
4. HN 讨论《FLUX 3 Image Klein》（2026-10-16，213 分）：https://news.ycombinator.com/item?id=50123580 （hn.algolia.com 检索）
5. comfy-aimdo 0.5.6（PyPI 官方包，AI Model Dynamic Offloader），获取日期 2026-10-20：https://pypi.org/project/comfy-aimdo/
6. ComfyUI 官方博客近期文章（FLUX 3 Klein / Comfy Router / MiniMax H3 等），获取日期 2026-10-20：https://blog.comfy.org/
7. HN 讨论《MiniMax H3 Day-0 Support in ComfyUI》（2026-08-03，334 分）：https://news.ycombinator.com （hn.algolia.com 检索）
8. GitHub API 仓库元数据与文件树（star/fork/license/commit），获取日期 2026-10-20：https://api.github.com/repos/comfyanonymous/ComfyUI