ComfyUI 深度研究：一张计算图如何成为开放权重模型的事实运行时

00 / 摘要十条核心论断，一页读完

这十条论断均可证伪。报告后续每一章都是其中某条的展开，而不是资料的平行堆砌。每条后面附「反证据/边界」，避免只引一边。

146,557

GitHub stars

一手：GitHub API，2026-11-13 实测

17,466

forks

同上；open issues 5,526

$500M

Comfy Org 估值

2026-04-24，B 轮 $30M，累计 $47M

v0.45.0

一句话判断（这是观点，不是共识）

ComfyUI 最值得研究的不是「怎么画节点」，而是它把生成流程变成了一种可执行、可交换、可计价的中间表示。谁掌握了这层表示，谁就掌握了开放权重模型到实际产出之间的调度权。它的最大风险也来自同一处：当这层表示同时允许任意 Python 扩展、任意远程模型调用与任意自动生成的图时，信任边界必须由部署者自己重新画一遍。

阅读约定：凡标注「一手」的数据来自官方仓库、官方文档、官方公告、arXiv 论文、NVD/CVE 或安全研究报告原文；「二手」为中文/英文转述与媒体分析，仅用于线索发现与交叉印证；「自报」为厂商营销口径，不作为结论依据；「推测」会显式标注。数字打架时以时间戳最新的一手来源为准，并在第 07 章展示核对过程。

01 / 范式判定它到底是什么：不是 GUI，是一层运行时

把 ComfyUI 归类为「AI 绘画软件」是绝大多数误判的起点。它更接近一个带可视化编辑器的生成式模型运行时：前端只是它的一个客户端，节点图才是它的程序表示。理解这一点，后面所有的商业、安全与工程结论才立得住。

1.1 三条判别式

判断一个系统是否属于「ComfyUI 范式」，看三条充要特征，而不是看它有没有画布：

判别式	含义	为什么是分水岭
图即程序	执行单元是带类型端口的节点，连线定义数据流；工作流以结构化 JSON 保存。	工作流可以被 diff、被版本控制、被程序生成，也可以被当作数据集（ComfyGen 正是这么做）。表单式 UI 的状态无法这样复用。
图即请求体	导出的 `workflow_api.json` 可直接 POST 到 `/prompt`，无需 SDK。	编辑界面与生产接口共用同一份表示，消除了「UI 状态 → API 参数」的翻译层。来源：docs.comfy.org 自托管文档，一手
图即配方	完整工作流与 seed 写入产出 PNG / WebP / FLAC 元数据，拖回画布可复原。	可复现性内建于产物本身，而非依赖外部实验记录。来源：README「recover complete workflows and seeds from supported generated media」，一手

三条同时成立，才解释了一个反常识现象：一个「画画的工具」会被 VFX 工作室塞进渲染农场、被学术论文当作可优化搜索空间、被云厂商当作 API 商品。它们用的不是它的界面，是它的中间表示。

1.2 概念分野：四种东西别混为一谈

层	代表	职责	状态
模型权重	SDXL、FLUX、Wan、Qwen Image	提供生成能力，自带独立许可证	第三方，ComfyUI 不拥有
推理库	PyTorch、Diffusers、comfy-aimdo、comfy-kitchen	张量运算、注意力、低比特算子、权重流	可替换；Diffusers 是库，ComfyUI 是运行时
图运行时	ComfyUI Core（GPL-3.0）	校验、拓扑排序、缓存、显存预算、作业队列、WebSocket	本报告主体
产品层	Desktop、Cloud、API、Enterprise、Partner Nodes、Comfy Agent	分发、计费、托管、商业化	Comfy Org 经营，与开源核心目标函数不完全一致

关键区分：「ComfyUI」（GPL-3.0 开源核心）与「Comfy」（Comfy Org 的商业产品族）不是同一个东西。混合两者讨论，会既高估也低估它的开放性：核心确实永久开源且可完全离线，但产品层的账单、账号与闭源节点也确实进入了同一张图。

1.3 演化时间轴：从个人实验到基础设施

图 1　ComfyUI 关键节点时间轴。起点是 2023-01-16 首个 GitHub 版本（GitHub API 显示仓库创建于 2023-01-17）与 2023-06 因 SDXL 的 base+refiner 链式结构被 Stability AI 雇用；2024-06-18 创始人离职并组建 Comfy Org；2024-08 FLUX 发布当日支持、前端拆为独立 TypeScript/Vue 仓库；2024-10-21 宣布 V1 桌面版；2025-09-16 A 轮 $17M；2026-04-24 B 轮 $30M / 估值 $500M；2026-11-10 发布 v0.45.0。

来源：GitHub API（仓库创建时间、release 时间，一手）／README Release Process（一手）／Comfy Org 融资公告（一手）／Latent Space 创始人访谈 2025-01（转述一手访谈）／AI Wiki 版本史（二手，仅用于交叉核对日期）。

1.4 一个被反复误读的起点

创始人（GitHub 名 comfyanonymous，2026 融资公告中具名为 Yannik Marek）的自述动机不是「做一个更好用的绘画 UI」，而是想做链式扩散实验：低分辨率生成 → 放大 → 用另一个模型再跑一遍扩散，且第二遍想换采样器、换模型。在 A1111 里实现这个实验比自己重写一个界面更麻烦。其被反复引用的设计原话是「大家都想做易用的界面，我想做一个强大但不那么易用的界面」。

这解释了两个后来的结构性事实：第一，SDXL 的 base+refiner 双模型链式结构恰好是节点图天然能表达、表单 UI 需要专门适配的形状，成为 2023 年采纳率跃升的拐点；第二，「把内部机制全部暴露出来」从一开始就是设计目标，而不是后期为了可解释性补的装饰。2026 年 arXiv 上把 ComfyUI 节点图当作 XAI 界面做层级干预（model bending）的工作，其实是回到了这个原点。来源：Latent Space 访谈、arXiv:2607.22428，一手/二手交叉

范式判定的结论

ComfyUI 与 A1111 / Fooocus / Midjourney 不是同一赛道的竞品，而是不同抽象层：前者是可编程的运行时，后者是面向终端用户的产品。真正与它竞争的是「直接写 Diffusers 脚本」和「自己搭调度服务」这两个选项。第 04 章的选型矩阵按这个层次重排，而不是按 UI 好不好看排。

02 / 理论根基为什么必须是这个形状：五条能推出工程动作的理论

好的理论章节能推导出具体动作，而不只是打比方。下面每条理论都给出「若成立则应观察到什么」与「因此工程上该怎么做」，并标注它是否被源码或文献支持。

理论	核心陈述	可证伪的预测	推导出的工程动作
数据流 / 异构算子图	生成管线是有类型端口的 DAG：`MODEL`、`CLIP`、`CONDITIONING`、`LATENT`、`IMAGE` 沿边流动。	执行前必须能做静态类型与文件存在性校验；若不能，错误应集中出现在运行期而非提交期。	把 `validate_prompt` 放在队列之前；先拓扑排序生成 ExecutionList 再执行；新模型架构只加节点，不改执行器。源码：execution.py / comfy_execution，二手技术拆解 + 官方文档交叉
记忆化 / 增量计算	节点输出是 `f(节点类型, 输入值)`；输入不变则输出可复用，改一个节点只需重跑它与其下游。	修改末端提示词时，模型权重与上游编码不应被重算；关闭缓存后耗时显著上升。	以输入指纹为缓存键；提供 `--cache-none` 做干净重跑以排查缓存污染；禁止自定义节点持有隐藏状态，否则增量正确性失效。来源：docs.comfy.org 启动参数，一手
工作集 / 分页预算	显存不是「够/不够」的开关，而是可分页的工作集：模型权重可部分常驻，缺的部分在 forward 时按层搬入。	显存下降应导致耗时连续变慢而非突然 OOM；权重搬运与计算应能重叠。	VRAMState 分态 + `lowvram_model_memory` 预算计算 + 按剩余显存自动选 fp16/bf16/fp8 + 异步权重流与 pin 分级驱逐。来源：model_management.py 相关源码解读、comfy-aimdo，二手但可复核
程序即数据 / IR	当图被序列化为 JSON，它就同时是源码、请求体与产物元数据，可被程序生成、diff、评分与搜索。	应能观察到「以工作流为输入/输出的研究」出现，且能用 LLM 预测工作流以提升画质。	把 `workflow_api.json` 当作部署制品纳入 CI；把 workflow JSON 嵌进产出文件；对外只暴露 `/prompt` 与 WebSocket，不另造 SDK。实证：ComfyGen arXiv:2410.01731、ComfyGen-RL arXiv:2505.21478，一手
可检查性 / 认知卸载	把中间张量与每一步参数显式暴露，使创作者能定位「哪一层造成伪影」，把黑盒变成可干预的材料。	应能观察到针对特定层的干预产生成族的、可预期的视觉变化，而非随机噪声。	提供中间预览（TAESD 快速潜图解码）、节点级单步与层选择控件；把复杂图用 App Mode / Subgraph 折叠以降低认知负荷。来源：arXiv:2607.22428 在 SD1.5 上的定性与定量层干预实验，一手

2.1 从理论推出一个不显然的判断

把前两条叠起来可得：既然图是程序、且节点输出可被记忆化，那么「工作流」本身就是一种可优化的对象，而不只是人写给机器的指令。这不是比喻——NVIDIA Research 的 ComfyGen 把 33 个人类工作流增强为 310 个工作流，用 500 条提示词各生成图像，以 LAION Aesthetic / ImageReward / HPS v2.1 / PickScore 集成打分，得到 (prompt, workflow, score) 三元组，再训练 LLM 按提示词预测工作流；其微调版在 GenEval 上取得 0.61（最佳基线 0.59），对 SDXL 的 HPS v2.0 胜率 93%、用户研究胜率 72%，并在 500 条提示词上产生 79 种不同工作流（in-context 版仅 41 种）。

2025 年的后续工作（arXiv:2505.21478，Technion + NVIDIA Research）直接指出 ComfyGen 的局限：它本质上是在已有流程集合上做分类，不能生成新拓扑；于是改用代理奖励模型 + GRPO + 逐 token 奖励归因来搜索新图结构。学术上的这条自我修正，恰好印证了「图即程序」——一旦流程变成可序列化数据，流程设计就变成了一个可学习的搜索问题。

观点（非共识）：这条推理链也预示了 Comfy Agent 这类产品的必然性，以及它的主要风险。当图可由智能体自动生成，人类审查的对象从「一张自己连的图」变成「一段自己没读过的程序」；第 08 章的供应链问题因此会从「安装节点」扩展到「导入工作流与接受生成的图」。可审计性将取代易用性，成为下一阶段的核心指标。

反证与边界：ComfyGen 的实验全部基于 SDXL 级模型（论文明确标注 “no FLUX!”），且在空间定位类提示上表现偏弱；其结论不能直接外推到 2026 年的视频/多模态工作流。增量计算的正确性还依赖节点纯度假设，而 60,000 个社区节点里大量存在 git clone 装依赖、monkeypatch 核心、带全局状态的实现——理论与生态现实之间有明显裂缝。

03 / 主框架一次生成的完整链路：从画布到显存再到 WebSocket

ComfyUI 是前后端一体的 Python 单体服务：浏览器画布只负责编辑与序列化，全部推理发生在本地服务端。下面这条链路是理解后面所有章节（缓存、显存、API、安全）的共用骨架。

图 2　一次生成的七步链路。注意第 2 步与第 4 步的两个「结构红利」：请求体直接复用画布导出的 JSON；拓扑排序阶段即可依据输入指纹决定哪些节点根本不必执行。前者让它天然是 API，后者让它天然适合反复调参。

来源：docs.comfy.org 自托管与启动参数文档（一手）／README Features 段（一手）／execution.py、comfy_execution、model_patcher.py、model_management.py 的公开源码解读（二手技术拆解，可复核）／社区架构综述（二手，用于交叉印证）。

3.1 三仓库联动与发布节奏

README 的 Release Process 明确写了三个互锁仓库：Core（约每两周一个稳定版，每周一目标发一个周版）、Desktop（基于最新稳定核心构建）、Frontend（TypeScript/Vue，每两周以上合并进核心，以 comfyui-frontend-package 作为 PyPI 依赖）。补丁版本用于向当前稳定版回填修复，次版本用于 master 分支发布。

同一份 README 也自己承认了代价：「稳定 release 标签之外的提交可能非常不稳定并破坏许多自定义节点」。这不是外部批评，是官方写的。实测印证：GitHub Releases 一手数据显示近 24 天内有 5 个发布（v0.42.0 / v0.42.1 / v0.43.0 / v0.44.0 / v0.45.0，2026-10-18 至 2026-11-10）。

环节	实现位置	工程含义	证据强度
HTTP / WebSocket 服务	`server.py`（aiohttp）	REST 端点 `/prompt` `/history` `/view` `/object_info`；前端只是一个客户端	一手文档
模型路径注册	`folder_paths.py` + `extra_model_paths.yaml`	可挂载其他 UI 已下载的模型目录，避免数十 GB 重复权重	一手文档
执行与缓存	`execution.py` / `comfy_execution`	校验先行、可中断、作业状态可观测	源码解读
权重挂载	`comfy/model_patcher.py`	LoRA / hook 作为 copy-on-write patch，多工作流共享一份权重	源码解读
显存预算	`comfy/model_management.py`	六态 VRAMState、按需装载/驱逐、自动精度选择	源码解读
异步权重流	`comfy-aimdo`（独立 PyPI 包）	把权重搬运从同步阻塞改成流水线，官方称支持 4GB 显存场景	厂商自报

可直接复用的工程结论：因为「前端只是一个客户端」，任何能说 HTTP + WebSocket 的系统都能驱动 ComfyUI。这解释了 SwarmUI 直接用它做后端、Krita 插件接入、以及 Imaj Future Lab 把工作流提交进 CGRU/Afanasy 渲染农场——它们没有调用任何专有 SDK，只是把 workflow_api.json 当作作业描述丢给 /prompt。

04 / 生态位与选型决策树：什么时候不该用 ComfyUI

选型章最容易写成软文。这里先把反证据摆出来：多个第三方对比都指出，ComfyUI 的学习曲线最陡，且在「单张 SDXL 出图速度」和「极低显存稳定性」上并非第一。

必须先说的反证据：一份 2026 年的第三方对比在 RTX 3090 24GB、1024×1024 SDXL、30 步条件下测得 Forge 3.2s、ComfyUI 3.8s、SwarmUI 4.0s、InvokeAI 4.5s，并称 6GB 卡上只有 Forge 能在 1024×1024 不 OOM。证据强度：单一测评、未公开完整硬件/版本/采样器配置，属「单一案例」，不能上升为通用结论，但足以否定「ComfyUI 在所有维度最快」这一说法。README 的 “by far the most optimized inference engine in the world” 是厂商自述，未见公开对照实验支撑。

4.1 按抽象层重排的对比矩阵

方案	抽象层	最强项	主要代价	适合谁
ComfyUI	图运行时	模型覆盖最广、day-0 支持、复杂/视频管线、可 API 化与复现	学习曲线陡；周更易破坏自定义节点；默认无鉴权单租户	需要可复现、可部署、可扩展流程的技术美术与工程团队
Diffusers	Python 库	代码优先、类型与调试体验、Hugging Face 生态最深	无 UI、无队列、无显存调度，生产化要自建	写服务、做研究、需要精确控制的研究者与后端
Forge / A1111	表单式 WebUI	上手最快、教程与老插件最多、低显存优化激进	新模型跟进慢（Forge 主线 2025-07 后停更）；管线形状固定	只想快速出图、沿用 A1111 习惯的用户
SwarmUI	产品化前端	以 ComfyUI 为后端，表单易用 + 节点图底座两全；多用户/多 GPU 更友好	依赖 ComfyUI 主线；多一层抽象成本	小团队共享 GPU、希望降低培训成本
InvokeAI	画布式产品	资产管理、版本/检索/元数据、商用许可选项清晰	自定义节点生态与模型覆盖不及节点图路线	工作室/代理商做客户项目与资产治理
Midjourney / Runway 等	闭源托管产品	零运维、开箱即用、无需 GPU	不可控中间步骤、数据出本地、按量付费、模型锁定	对可控性与数据本地化无硬要求的个人创作者

来源：README 模型清单（一手）／local-llm.net 2026 对比测评（第三方单一案例）／SwarmUI 官方文档（说明以 ComfyUI 为后端，一手）／invokeai 与 Forge 仓库状态（二手交叉）／中文技术博客横向对比（二手，仅作线索）。星数口径见第 07 章。

4.2 选型决策树

图 3　按「流程是否需要被复用与部署」分叉的选型决策树。分叉点刻意不放在「会不会画节点」上——那是学习成本，不是架构判据。右侧两支并非互斥：把 ComfyUI 当作无头后端、由自己的服务提交工作流，正是第 03 章 Imaj Future Lab 渲染农场的做法。

来源：作者基于本文档第 01–03 章判别式与第 04 章对比矩阵的综合判断（属观点，非共识）；分支内的工具能力描述回溯各项目官方文档与第三方对比。

观点：最值得注意的不是「谁赢了」，而是 SwarmUI 直接把 ComfyUI 当后端。当竞争者选择复用你的执行引擎、只在上面做一层更友好的壳，这比任何星数都更能说明抽象层已经稳固。同理，国内 RunningHub、LiblibAI 等平台把「云端 ComfyUI 工作流」作为核心商品，本质也是在同一层运行时之上做分发与计费。

05 / 关键能力一模型覆盖与 day-0 机制：为什么模型实验室愿意适配它

一个运行时的护城河，取决于「新模型发布当天能不能跑」。ComfyUI 在这方面形成了正循环：模型实验室把它列入发布清单 → 用户不必等 → 更多用户留在这层运行时 → 实验室更有动力优先适配。

5.1 README 一手清单：从扩散 GUI 到全模态引擎

2026-11 版 README 的自述已不是「Stable Diffusion GUI」，而是 “the AI creation engine for visual professionals”，Features 段列出的原生支持跨越七类模态。这张清单本身就是论据——它说明节点图抽象没有被绑定在某一种模型架构上。

模态	README 列举的代表模型	结构性含义
图像生成	SD1.5 / SDXL / SD3.5 / Flux.1 / Flux.2 / Qwen Image / Z-Image / Hunyuan Image 2.1 / HiDream / Lumina 2.0 / Chroma / Kandinsky 5 / Ernie Image / Moss Image 等	单一种类即十余个架构，每种的 CLIP/VAE/采样配置都不同
图像编辑	Flux Kontext / Flux.2 Klein / Qwen Image Edit / HiDream E1.1、O1 / OmniGen2 / Fibo 2.0 等	引入参考图条件与多输入，管线形状与文生图不同
视频生成	Wan 2.1 / 2.2、LTX-Video 2 / 2.3、HunyuanVideo 1.5、Kandinsky 5 Video、CogVideoX、Cosmos Predict2、Mochi 等	时序潜变量与帧处理，是表单 UI 最难吸收的一类
音视频 / 音频	MiniMax H3、LTX-AV、ACE-Step 1.5、Stable Audio 3、MiniMax Music 3、Yue 2	已超出「视觉」，产出元数据也扩展到 FLAC
3D 与视觉	Hunyuan3D 2.1、TripoSplat、SeedVR2、SUPIR、Depth Anything 3、SAM 3 / 3.1、BiRefNet 等	条件/分割/超分作为一等节点参与构图
文本生成	Gemma 3 / 4、Qwen3 / Qwen3.5、Qwen3-VL（含多模态输入）	最关键的一行：节点图引擎同时装下 LLM 与扩散两条技术栈

来源：https://raw.githubusercontent.com/Comfy-Org/ComfyUI/master/README.md Features 段，2026-11-13 抓取，一手。README 自带限定：「This is a representative list」，即非穷举。

图 4　四层栈。GPL-3.0 只覆盖 Core 运行时；模型权重各带独立许可证；Partner Nodes 按 Comfy 积分计费且需登录、不能离线。把「开源核心」与「产品层」分开看，才能同时解释「永久开源」的承诺与社区对付费节点的抵触。

来源：README、docs.comfy.org 账户/自托管文档、Comfy Org 官网产品页（均一手）；comfy-aimdo / comfy-kitchen 的模块归属来自公开源码技术拆解（二手，可复核）。

5.2 day-0 为什么在技术上可行

「首发即支持」常被当作商务关系的结果，其实主要由三个工程机制支撑：其一，模型检测器按权重名前缀匹配已注册架构，新 checkpoint 格式能被同一套装载路径吸收；其二，新架构的差异被封装成新增节点与 comfy_extras 模块，不需要改动执行器、缓存或 UI 的表单布局；其三，核心、前端、桌面三仓库解耦，前端可独立发版。官方发布节奏（周版 + 双周稳定版）则是把这种技术可行性变成时间上的确定性。

可核验的时间点：FLUX 于 2024-08 发布当日获得支持；LTX-2.5 发布时即带 ComfyUI 模板；2026 年 Seedance 2.5、MiniMax H3、Wan Animate 2、Nano Banana 2.1 等在官网首页以「新模型发布」形式出现，且分别标注开放权重或 Partner Nodes。国内侧，RunningHub 在通义万相 Wan2.6 发布当日完成工作流环境集成，阿里云 2025-03 上线 Serverless ComfyUI 应用模板。

反证据要一起看：这种速度是以稳定性换来的。README 明确警告稳定标签外的提交「可能非常不稳定并破坏许多自定义节点」；第三方工程综述把「依赖冲突每周发生、节点 monkeypatch 核心导致下个版本就坏」列为其生产可用性的首要痛点。对模型覆盖的追逐与对生态可靠性的承诺，是同一笔预算的两个方向——Comfy Org 2026 年 B 轮公告把「生态系统可靠性」列为资金用途之一，正是对这一矛盾的承认。

5.3 中文生态：运行时之上的第二层商业

国内形成了一个值得单独观察的现象：ComfyUI 本身是开源核心，但围绕它长出了规模可观的托管工作流平台。RunningHub（海马云）以云端 ComfyUI 环境与工作流 API 为核心，公开资料称已积累 1.3 万+ 节点、10 万+ 模型、8 万+ 工作流、10 万+ AI 应用，并在 2026 WAIC 披露月服务用户 2600 万、API 月调用 30 亿次（厂商自报，未经独立审计）；LiblibAI 提供云端 ComfyUI 与中文模型社区；此外还有影视节黑客松用 ComfyUI + 本地工作站集群完成 72 小时创作、国产显卡以 ComfyUI 工作流做出图性能演示等。

观点：这印证了第 01 章的范式判定——当运行时足够稳固，竞争就上移到「谁把工作流变成可分发、可计费的商品」。同时也提示一个容易被忽略的风险：这些平台预装了大量第三方节点，等于把第 08 章要讨论的供应链信任问题整体接管了过去。选用托管平台时，「节点谁审核过」比「节点有多少」更重要。

06 / 关键能力二显存预算与增量执行：4GB 声明的机制解释与证据审查

「4GB 显存跑最大开源模型」是 ComfyUI 最广为流传也最需要审慎对待的声明。这一章先解释它在机制上怎么成立，再审查它的证据强度与反例。

6.1 VRAMState 六态：把 OOM 变成连续曲线

启动时探测设备显存并归入六态，状态决定后续所有装载策略的激进程度。一次执行前由 load_models_gpu 统一调度：去重本次所需模型 → 标记已驻留模型 → 计算「所需显存 × 系数 + 推理预留」→ free_memory 驱逐旧权重 → 逐模型算 lowvram_model_memory，放得下就全量进卡，放不下就部分常驻、forward 时按层搬入。v0.40 之后又加入 pin（钉住常用权重）与按优先级分级驱逐。

图 5　VRAMState 六态与对应策略。高度仅示意「可用资源与性能上限的相对关系」，不是实测量化刻度；右端的 SHARED 因此画成独立柱而非最高阶。这一区分很重要：把六种状态误读成一条线性刻度，会得出「统一内存比 24GB 独显更快」的错误推论。

来源：comfy/model_management.py 与 cli_args.py 的公开源码解读（DeepWiki，二手但可复核）／docs.comfy.org 启动参数文档（一手）／README 关于异步权重流的说明（一手，厂商自述）。

6.2 4GB 声明的证据审查

检查项	结果	判定
原文	“Can run even the biggest open source models on as low as 4GB vram + 8GB ram relatively quickly ... using our state of the art asynchronous weight streaming technology.”	厂商自报
机制是否可解释	是。部分常驻 + 按层搬入 + 异步流 + 自动降精度 + 低显存态，机制链完整且与源码结构一致	成立
有无独立复现基准	本轮检索未找到公开的第三方对照实验；「relatively quickly」无量化定义，未说明模型、分辨率、步数、耗时	缺失
数量级自洽性	5.6B 级模型 fp8 权重约 5–6GB，叠加文本编码器与激活，4GB 显存 + 8GB 内存需持续换入换出，属「可运行但极慢」区间；第三方配置矩阵把 4–6GB 标为 “Very slow”，与之一致	不矛盾
方向相反的证据	第三方单测称 6GB 卡上 Forge 是唯一能 1024×1024 SDXL 不 OOM 的方案；另一份来源称 ComfyUI 可在 1GB 显存运行（不同来源口径冲突，说明该数字高度依赖模型与量化）	存在反例

结论：机制可信，数字不可当采购依据

把 4GB 理解为「降级曲线的下端存在」是对的，理解为「4GB 卡能舒服地生产」是错的。正确的工程动作是：按目标模型与分辨率自己跑一遍基准，记录 --lowvram / --novram / fp8 / GGUF 各组合的实测耗时与 OOM 率，再决定硬件；不要引用 README 的营销句做容量规划。

6.3 增量执行：缓存是最被低估的能力

官方文档明确：「ComfyUI 会在同一会话中复用已缓存的节点结果，这正是重复运行更快的原因」，并提供 --cache-none 「每个节点都会重新执行，生成时间会更长」，专供调试或排除缓存复用。把它与第 02 章的记忆化理论对上，可得三条实践：

实践	理由
调参时只改末端节点	改提示词只重跑 CLIP 编码及其下游，模型权重与已缓存分支不重算；在 50 节点图上收益显著
结果异常先用 `--cache-none` 复跑	区分「工作流逻辑错误」与「缓存污染/节点隐藏状态」两类问题
自定义节点必须保持纯函数语义	读取全局状态、写随机文件、依赖时间戳的节点会破坏指纹缓存的正确性；这也是 60,000 节点生态里最常见的隐性缺陷

边界：缓存以输入指纹为键，不等于严格可复现。随机种子、第三方 API 节点、模型权重文件被原位替换、GPU 非确定性算子，都可能让「同输入不同输出」。生产系统若需要审计级复现，应额外固定：核心版本 tag、节点 commit、权重哈希、seed 与采样器参数，并把这些写进作业记录。

07 / 证据全景数字打架时怎么办：证据分级与数量级反推

这一章把本报告用到的证据摊开，包括互相矛盾的数字与方向相反的结论。研究类交付物的可信度不取决于引用了多少条，而取决于敢不敢把不利于自己论断的证据也列出来并说明如何处理。

7.1 证据分级光谱

原始技能分级（RCT > 受控实验 > 大样本观察 > 自报/调查 > 单一案例 > 建模）来自医学语境，直接套到软件工程研究会失真。本报告按「可复核性」映射为四级：

图 6　四级证据强度光谱。注意 A 级内部还有差别：GitHub API 的 stars 数是机器可复核的观测值，而官方融资公告里的「400 万用户」虽属一手，却是无审计的自报值——两者不能同等对待，故第 7.3 节单独做数字核对。

分级方法为本报告基于 deep-research-html-report 技能原始分级做的工程语境映射，属方法论观点（D 级）。

7.2 完整证据表（含反证据列）

结论 / 数据	来源与年份	强度	支持方向	反证据 / 边界
146,557 stars / 17,466 forks / 5,526 open issues / GPL-3.0 / 创建于 2023-01-17	GitHub REST API，2026-11-13 实测	A	生态规模与许可证事实	观测瞬时值；stars 不等于活跃用户
最新 v0.45.0（2026-11-10），24 天内 5 个 release	GitHub Releases API，2026-11-13	A	周更节奏的技术可行性	反面：官方自承稳定标签外提交可能破坏大量自定义节点
七类模态、数十个模型家族原生支持；可完全离线	README master，2026-11-13 抓取	A	C2 / C5 论断	清单自称 representative，非穷举；离线需 `--offline` 关闭可选 API 节点
默认绑定 127.0.0.1、无鉴权；`--listen` 暴露不算漏洞	SECURITY.md（v0.44.0 引入）+ 自托管文档，2026	A	C6 / C7 论断	反证据：官方给出反代鉴权方案；App Mode / Enterprise 在补多租户
CVE-2025-67303，CVSS 7.5，Manager <3.38 未鉴权 RCE；需 Core ≥v0.3.76	NVD 2026-01-05 / DailyCVE / CSA Labs 2026-04	A	C6 论断	补丁已发布；不能外推到当前版本
CVE-2024-21574，`/customnode/install` pip 字段未校验导致 RCE	NVD 2024-12-12 / SentinelOne 漏洞库	A	C6 论断	修复于 Manager V2.51.1；历史漏洞
千台级公开实例被植入挖矿僵尸网络（XMRig + lolMiner + Hysteria2）	CSA Labs 研究简报，2026-04-08	B	C6 / C7 论断	同类问题也见于 OpenWebUI 15,000+ / Ollama 175,000+ 暴露实例，非 ComfyUI 独有
官方 Registry 曾出现投递 Akira Stealer 的恶意包	CSA Labs 2026-04 引述 / 安全厂商博客	B	C6 论断	已下架并加审核标准；「下架后换名重现」的说法来自二手博客，未独立核实
B 轮 $30M、估值 $500M、累计 $47M，2026-04-24	Comfy Org 官方公告（中英双版）	A	C8 论断	媒体写「约 $48M / Series A $17–19M」，与官方 $47M 有 1M 口径差
400 万+ 用户、60,000+ 节点、15 万+ 日下载	同上官方公告 / comfy.org 首页	C	生态规模	无审计；「60,000 节点」与第三方「千余个扩展包」口径不同，疑为节点类数量而非包数
4GB VRAM + 8GB RAM 跑最大开源模型、世界最快推理引擎	README，2026	C	C4 论断（仅机制部分）	无独立基准；第三方单测 Forge 3.2s < ComfyUI 3.8s；6GB 卡反例
ComfyGen：310 工作流 / 500 提示词，GenEval 0.61 vs 0.59，HPS 胜率 93%、用户研究 72%	arXiv:2410.01731，NVIDIA Research + TAU，2024	A	C1 / C10 论断（图即程序）	仅 SDXL 级模型、无 FLUX；空间定位类提示偏弱；后续工作指其只是「在已有流程上分类」
ComfyGen-RL 用 GRPO + 代理奖励模型生成新拓扑	arXiv:2505.21478，Technion + NVIDIA，2025	A	C10 论断	预印本，标注 under review；未大规模落地验证
节点图作为 XAI 界面，层干预产生成族可预期视觉变化	arXiv:2607.22428，2026-07	A	第 02 章可检查性理论	SD1.5 上的定性与定量分析，未覆盖新架构
SVEDKA 超级碗广告：周期由约半年压到不足一个月	comfy.org 官方客户案例，2026-02-08	B	生产可用性	厂商精选案例，有幸存者偏差；中文转述的「效率提升 180 倍」等数字无出处，不采信
把 ComfyUI 工作流提交进 CGRU/Afanasy 渲染农场，数据不出内网	Imaj Future Lab 工程博客，2026	B	C7 / 图即请求体	单一团队实践；自建框架，非开箱能力
`--disable-api-nodes` 破坏 Manager，社区指「enshittification」，v0.39.0 拆分修复	GitHub issue #14887，2026-07 至 10	A	C8 论断	反证据：核心开发者亲自回应，且三个月内落地拆分 flag，说明反馈通道有效
节点/模型许可证地域与商用限制造成工作室合规困难	GitHub discussion #14346，2026-06	B	第 09 章治理风险	社区讨论中的法律理解非专业法律意见
「ARR 几乎为零 / pre-revenue」	中文商业分析站，2026	D	治理张力背景	无财务披露、无数据来源；仅作为待验证假设，不作结论
60,000 节点生态与 day-0 支持构成护城河	综合本报告第 05 章证据	D	C5 论断	「护城河」是判断不是观测；可被模型 API 化或浏览器原生推理绕过

7.3 数字打架：同一指标六个数字

研究中最常见的错误，是把不同时间点、不同口径的数字并列当作「矛盾」。以 GitHub stars 为例，本轮检索一共遇到六个值：

数值	采样时间	来源	处理
122k	2026-07	开源图片生成器对比站	二手快照，时间最早，不采信为当前值
129k	2026-08（文中语境）	英文技术分析	二手，与前后值单调一致，可作趋势点
132,542	2026-09-11	Repocloud 页面	同页正文又写「126,000+」，自相矛盾，降权
139,381	2026-10-20	中文技术拆解	二手但与一手序列吻合
142,520	2026-10-24	英文资料站	二手，附精确日期，可信度较高
146,557	2026-11-13	GitHub REST API 实测	一手、时间最新，作为报告基准值

数量级反推自洽性检查：从 2026-07 的 122k 到 2026-11-13 的 146,557，约 4.4 个月增长 24.5k，月均约 5.6k stars；从 10-24 的 142,520 到 11-13 的 146,557，20 天增长 4,037，日均约 202，折算月均约 6.1k——两条独立路径算出的量级一致，说明这六个数字主要是采样时间差，而非数据造假或口径冲突。同理可反推 forks（16,803 @10-24 → 17,466 @11-13，20 天 +663）也自洽。这一步是「中文二手转述只用于线索发现」原则的具体落地。

反而真正需要警惕的口径冲突：官方称「60,000+ 社区节点」，安全研究报告称「流通中的自定义节点扩展包远超一千个」。两者差约一个数量级，最合理的解释是前者数的是节点类（一个包注册多个节点），后者数的是包/仓库，但官方没有公开统计口径。因此本报告只把 60,000 当作「生态规模的量级指示」，绝不拿它做人均产出、漏洞率等任何除法运算。

7.4 方向相反的证据如何改变结论

如果只看支持证据会写成	反证据	修正后的表述
「ComfyUI 是最快的推理引擎」	第三方单测 Forge 3.2s < ComfyUI 3.8s；6GB 卡 Forge 更稳	优势在模型覆盖、day-0 与可组合性，不在单图绝对吞吐
「ComfyUI 赢了所有竞品」	SwarmUI 复用其后端；Diffusers 在代码优先场景更合适	它赢的是「运行时」这一层，产品层与库层各有胜者
「开放性让生态无限繁荣」	同一开放性导致 RCE、Registry 投毒、僵尸网络	护城河与攻击面同源，须由部署者补信任边界
「公司在把开源闭源化」	核心仍 GPL-3.0、README 承诺离线、v0.39.0 按社区反馈拆分 flag	治理张力真实但未越界；应持续观察而非下定性结论
「4GB 显存即可生产」	无独立基准，第三方矩阵标为 Very slow	降级曲线下端成立，不适合作为容量规划依据

08 / 安全与供应链当「节点」就是任意 Python，信任边界必须重画

这是整份报告里最需要工程动作的一章。核心判断不是「ComfyUI 有几个漏洞」，而是：它的扩展契约把「安装节点」等价于「安装任意软件」，而默认威胁模型又假设所有能访问服务的人都是可信的。两者叠加，一旦把服务暴露到公网，后果不是报错而是主机失陷。

8.1 官方威胁模型（一手，必须原样理解）

SECURITY.md 写得很直白：ComfyUI 被设计为本地运行，默认绑定 127.0.0.1；威胁模型假设用户从受支持渠道安装、没有安装不可信自定义节点、任何能访问 ComfyUI URL 的人都是可信的。更关键的是「不视为漏洞」清单第一条：需要 --listen 或非默认网络暴露的问题，「用户选择了暴露它并负责保护该部署……这些是 bug，不是漏洞」；依赖特定自定义节点的问题也明确排除，理由是「自定义节点是第三方代码」。

自托管文档给出对应的操作建议：「ComfyUI 服务器默认没有任何身份验证。请仅在可信网络中绑定非回环地址，或在其前端部署带身份验证的反向代理。」以及：社区 Docker 模板由社区维护、非官方发布，「在向模板中放入凭据或私有模型之前，请先了解该模板会安装哪些内容」。

这个威胁模型对本地单用户是合理的，对生产部署是不完整的

它没有错，但它把一整类风险显式移交给了部署者。因此任何「ComfyUI 上生产」的方案，安全边界都不能指望核心提供，必须由部署架构补齐。把本地工具的默认假设直接带进工作室或企业环境，是这类事故最常见的根因。

8.2 已公开的事件与漏洞

时间 / 编号	问题	影响与修复
2024-12-12 CVE-2024-21574	ComfyUI-Manager `/customnode/install` 的 pip 字段未做白名单校验（CWE-94 代码注入）	未认证远程代码执行，权限同服务进程；修复于 Manager V2.51.1，引入 `block` 安全级别与 `is_allowed_security_level` 校验
2025 年初供应链事件	`ultralytics` 库被投毒、ComfyUI_LLMVISION 节点发现漏洞	促使官方对自定义节点生态做一系列加固：限制 `eval`/`exec`、禁止 Registry 包运行时 pip 安装、Manager 增加远程禁用机制
2025 Registry 投毒	官方 Comfy Registry 中某发布者的包被识别为 Akira Stealer 投递载体；伪装成放大节点，图像原样通过、后台窃取浏览器凭据与钱包	包已下架；Registry 标准新增禁止代码混淆与运行时子进程安装。「换名重现」的说法来自二手安全博客，本报告未独立核实
2026-01-05 CVE-2025-67303	ComfyUI-Manager <3.38 的未保护备用通道（CWE-420），CVSS 3.1 = 7.5 HIGH；`user/default/` 经 `/userdata` 无鉴权可读写	可篡改配置/快照 → 重启后 clone 攻击者仓库并执行 `install.py` → RCE。修复：Manager 3.38+ 且 Core v0.3.76+（System User Protection API），配置迁至 `user/__manager/`，旧数据备份并提醒清理
2026-04-08 CSA Labs 简报	面向公网的 ComfyUI 挖矿僵尸网络：扫描暴露实例 → 探测可执行 shell/任意 Python 的社区节点，或直接利用 CVE-2025-67303 安装恶意节点	XMRig 挖 Monero（CPU）+ lolMiner 挖 Conflux（GPU）；Hysteria V2 把流量伪装成 bing.com TLS 并作代理节点；Flask C2 集中管理；`LD_PRELOAD` 与 `chattr +i` 持久化。研究者称超过一千台公开实例受影响

来源：NVD / DailyCVE / SentinelOne 漏洞库（一手漏洞记录）／CSA Labs《AI Inference Under Siege》研究简报 2026-04-08 及 PDF 原文（B 级独立研究）／ComfyUI-Manager 修复提交（一手）。CSA 简报同时给出横向对照：Cybernews 2026-01 发现 15,000+ 公开 OpenWebUI 实例、TechRadar 报道 175,000+ 暴露 Ollama 实例，说明这是 AI 推理服务器的共性暴露面。

8.3 攻击链与对应门禁

图 7　攻击链与逐环节门禁。第 2 步存在两条路径：已安装节点自带可执行端点则直接利用，否则通过 CVE-2025-67303 远程安装攻击者选定的恶意节点。这也是为什么「只打补丁」不足以覆盖全部暴露面——节点清单本身就是攻击面。

来源：CSA Labs 2026-04 研究简报（攻击链与载荷，一手研究）／DailyCVE 对 CVE-2025-67303 的复现步骤（一手）／官方 SECURITY.md 与自托管文档（一手）／门禁措施为综合两家安全机构建议后的整理（本报告观点）。

8.4 一个常被忽略的第三类入口：工作流文件

除节点包之外，JSON 工作流本身也是不可信输入。工作流可引用任意节点类型，导入后若本机装有存在漏洞的节点，即可能触发其危险路径；而社区习惯是「下载别人分享的工作流直接用」，几乎不做安全审查。对签有 NDA 的工作室，一台能接触未发布客户素材的工作站被植入凭据窃取器，后果是合同责任而非重装一下午。因此门禁清单应包含「工作流来源审查」与「离线实例处理敏感素材」两条。

观点：第 02 章末尾的判断在这里得到印证。随着 Comfy Agent 一类能力普及，工作流会越来越多地由智能体生成或修改，「导入的工作流是谁写的、改了什么」将变得难以回答。可审计性（diff、签名、最小权限执行）应当在设计阶段就进入架构，而不是等第一起事故后再补。

09 / 治理与商业化GPL、Partner Nodes 与「永久开源」承诺之间的张力

这一章不下道德判断，只做事实梳理：把公司做了什么、社区反对什么、官方怎么回应、核心的许可证保证了什么，按时间摆在一起。

9.1 公司与资本的时间线

时间	事件	对开源核心的影响
2023-01 / 06	个人项目开源；创始人因 SDXL 链式实验加入 Stability AI	核心由个人维护
2024-06-18	创始人宣布从 Stability AI 离职，Comfy Org 成立；创始团队含 ComfyUI-Manager、SwarmUI、Comfy Registry 等生态关键项目的作者	生态关键基础设施的维护者被纳入同一组织，治理集中度上升
2024-08	与 Invoke、Civitai 共同发起 Open Model Initiative 并加入 Linux Foundation；FLUX 首发日支持	「开放模型」成为公开立场
2025-09-16	A 轮 $17M（Pace Capital、Chemistry、Abstract、Essence VC 等）	资金用途含「稳定自定义节点生态」
2025-11 / 2026-03	Comfy Cloud 公测 / 正式版（Blackwell RTX PRO 6000，96GB VRAM）；2026-03-10 上线 App Mode、App Builder 与 URL 分享	开始出现需要账号的托管产品
2026-04-24	B 轮 $30M，估值 $500M，累计 $47M；宣称 400 万+ 用户、60,000+ 节点、15 万+ 日下载	公告明确承诺「ComfyUI 永久开放」「始终可自托管并完全掌控自己的创作」
2026-07 → 10	GitHub issue #14887：关闭 API 节点会连带破坏节点管理器，社区措辞激烈；核心开发者亲自回应；v0.39.0 拆分为 `--offline` 与 `--disable-partner-nodes`	反馈通道在约三个月内闭环，README 同步更新离线说明
2026-11-13	Core 仍为 GPL-3.0；v0.45.0；近 24 天 5 个 release 中多个条目为 Partner Nodes 新增	产品层迭代在发布日志中占比可观，与社区关注点形成对比

来源：GitHub API（许可证与 releases，一手）／Comfy Org 融资公告中英双版（一手）／GitHub issue #14887 全线程（一手）／README Release Process 与离线说明（一手）／AI Wiki 与 Latent Space 的版本史与访谈（二手交叉）。

9.2 争议的结构，而不是情绪

把 issue #14887 里最尖锐的几句翻译成结构问题，会得到三条清晰的产品缺陷，而不是「用户不喜欢广告」这么简单：

社区诉求	当时的实际情况	正确的产品解法（后来是否落地）
「离线」与「别在我自托管 UI 里显示付费内容」应是两个开关	`--disable-api-nodes` 语义是「核心与前端完全不与在线服务器通信」，因此连带禁用了依赖在线 Registry 的 ComfyUI-Manager	拆成 `--offline`（彻底断网）与 `--disable-partner-nodes`（仅隐藏付费节点）；v0.39.0 落地
flag 命名应能预测副作用	名字听起来只关 API 节点，用户花三小时排查 Manager 为何失效	README 现明确写出两个 flag 各自作用；旧 flag 弃用
PR 长期无人处理会削弱信任	有贡献者称半年前就提交过修复 PR 未获关注	无公开结论；属治理吞吐问题，仍应观察

为什么这条 issue 值得单独分析：它是少见的、可完整追溯的「社区质疑 → 核心开发者亲自解释 → 版本修复 → 文档同步」闭环。既证明商业化确实侵入了默认体验（不能替官方洗掉），也证明治理通道并未失灵（不能据此断言「正在闭源化」）。两种简化说法都与一手记录不符。

9.3 GPL-3.0 的真实边界

GitHub API 确认核心许可证为 GPL-3.0。这一选择有两面：一方面它保证了核心与其衍生分发必须保持开源，构成对「永久开放」承诺的法律支撑；另一方面，把修改后的核心分发进自有产品会触发同源开源义务，让不少企业内部工具的合规边界变模糊。社区讨论 #14346 提出了更细的问题：内置节点与模型可能带地域或商用限制（例如某厂商节点排除特定地区），工作室希望在节点里做许可证检查。

需要区分三类对象，社区讨论中的答复（非专业法律意见）与通行理解一致：

对象	适用许可	工程含义
本地代码 / custom_nodes	直接扩展或修改核心，通常视为衍生作品，受 GPL-3.0 约束	若要分发，需按 GPL 开源相应部分
远程 API 服务	独立进程通过 HTTP 调用，一般不受 GPL 传染	把 ComfyUI 当独立服务驱动是多数生产部署的选择，也是规避合规灰区的实用做法
模型权重 / LoRA / 产出	各自独立许可（如 FLUX 系 Kommunity License 对年收入超阈值组织要求商业授权）	「工具开源」不等于「模型可商用」；上线前须逐模型核对，且 Partner Nodes 走的是按量付费 API

不构成法律意见：以上是公开社区讨论与通行工程实践的整理，具体产品的合规判断应由法务按实际分发方式给出。可确定的是：GPL 保护的是核心代码的开放性，不解决模型权重、地域限制与商业授权的合规问题——把三者混为一谈是工作室最常见的合规误判。

9.4 商业模式：待验证的假设

官方产品矩阵已覆盖 Desktop（免费本地）、Cloud（订阅/按 GPU 时长）、Developer Platform / API（工作流部署为生产端点）、Enterprise（企业基础设施）、Partner Nodes（按积分调用闭源模型）与 MiniMax 商业许可转售。有中文分析称公司目前近乎 pre-revenue、ARR 可忽略，估值主要反映生态位而非收入——该说法无财务披露支撑，本报告标为 D 级推测，不作为结论。

观点：更值得关注的不是「它能不能赚到钱」，而是账单层与开源层的目标函数是否会持续分离。核心的价值来自「任意模型、任意节点、完全离线」，而产品层的价值来自「更省心、更多模型、按量付费」。这两者在多数时候互补，但在「默认体验里该出现什么」「新模型优先开放权重还是优先 Partner Nodes」「flag 的默认行为」这类细节上会持续产生摩擦。可观察的先行指标是发布日志中 Partner Nodes 条目的占比，以及离线 flag 是否始终可用。

10 / 度量体系三层指标与反 Goodhart 原则

如果用 stars 和「支持多少模型」来考核 ComfyUI 的采用效果，几乎必然做出错误决策。下面给出一套分层指标，并刻意包含「不该被优化」的指标。

层	指标	怎么测	常见失真
运行时健康	单工作流端到端耗时 / OOM 率	固定权重哈希、版本 tag、seed、分辨率、步数，跑 N 次取分布	缓存命中会让首次与后续差异巨大，须显式区分冷/热缓存
	缓存命中率与增量收益	对比 `--cache-none` 与默认配置的耗时比	只报「快了多少倍」而不报图规模与改动位置，无意义
	版本升级后的节点存活率	锁定的节点包清单，升级后逐一导入并跑冒烟工作流	只看「能否启动」会漏掉静默行为变化
生产可用性	作业成功率 / 排队时延 / GPU 利用率	从 jobs API 或自建队列采集，按 GPU 池分组	单租户单队列下，一个长视频作业会污染全部指标
	结果可复现率	固定全部输入与权重哈希后比对输出哈希或感知指标	把「同 seed 出同图」当复现，忽略 GPU 非确定性与远程节点
	安全门禁覆盖率	已审查节点包 / 已安装节点包；公网暴露实例数应为 0	只统计「有没有补丁」，不统计「有没有暴露」与「装了什么」
组织价值	工作流复用率	共享库中被实际调用的工作流数 / 总工作流数	囤积几百个 JSON 无人使用，看起来像资产其实是负债
组织价值	人工返工率 / 交付周期	每个项目记录从需求到过审的轮次与工时	用「生成张数」代替「过审张数」，等于奖励废片

10.1 三条反 Goodhart 原则

原则一

凡是被当 KPI 的计数，都会被灌水

「节点数」「工作流数」「模型数」都是可无限堆砌的存量指标。一旦用于考核，团队会批量导入低质量包，反而抬高供应链风险。用被调用率与过审率替代存量计数。

原则二

速度指标必须与质量成对出现

单图秒数可以被降步数、降分辨率、换快采样器轻易刷低。任何提速宣称都要同时报告质量指标与完整的模型/参数配置，否则不可比。

原则三

「零事故」要拆成暴露面与事件数

没有事故可能只是没暴露到公网、没人审计。把「公网暴露实例数 = 0」「未审查节点包数 = 0」这类前置可控量作为安全指标，比统计事故数更有预警价值。

本报告自身的度量诚实性：全文未使用「效率提升 180 倍」「成本下降 60%」这类在中文二手转述中流传但无出处、无法反推的数字；对官方自报的 400 万用户 / 60,000 节点，只作量级指示，不参与任何比率计算；对第三方单次性能测评，明确标为单一案例而非通用结论。

11 / 落地成熟度阶梯、90 天路线与检查清单

从「一台机器上画图」到「组织级生产能力」，缺的不是更多节点，而是版本固化、准入治理、调度与可复现这四件基础设施。下面给出可执行的阶梯与路线。

图 8　五级成熟度阶梯。每一级的「门槛」写的都是官方不提供、必须由部署者补的能力：L2 的复现记录、L3 的信任边界、L4 的队列与调度、L5 的组织流程。这也是「生产可用」与「生产级开箱即用」的区别。

来源：本报告综合第 06–10 章证据整理的落地框架（D 级观点）；L4 的具体做法参考 Imaj Future Lab 把工作流提交进 CGRU/Afanasy 渲染农场的公开工程实践（B 级）。

11.1 90 天路线

图 9　90 天路线。刻意把「安全边界」排在「无头 API」之前——一旦 /prompt 对外开放而鉴权与节点准入尚未就绪，就等于把第 08 章的攻击链主动接上。时间格为两周一段，非精确工期估算。

来源：本报告综合整理（D 级观点）；顺序约束的根据是官方 SECURITY.md 威胁模型、CSA Labs 攻击链与第 06 章显存证据审查。

11.2 上线前检查清单

安全（一票否决）

□ 公网暴露实例数是否为 0
□ 是否部署反向代理 + TLS + 鉴权
□ ComfyUI-Manager ≥ 3.38 且 Core ≥ v0.3.76
□ 已安装节点是否全部在准入白名单内
□ 是否移除可执行 shell / 任意 Python 的节点
□ 是否禁止运行时 pip 与 eval/exec
□ 敏感素材是否只在离线实例处理
□ 出站流量是否阻断矿池并告警

可复现与工程

□ 核心版本 tag、节点 commit、权重哈希是否固定
□ 工作流是否入 Git 并做 code review
□ 是否区分冷/热缓存记录基准耗时
□ 是否有升级前冒烟用例
□ 作业记录是否含 seed、采样器与参数
□ 是否按目标模型实测显存曲线（不引用 4GB 声明）
□ 第三方 API 节点是否有失败与计费兜底
□ 是否有回滚到上一稳定 tag 的镜像

11.3 反模式清单

层	反模式与症状	修正
战略	把「支持多少模型/节点」当北极星，持续导入新包；症状是环境越来越脆、每次升级都报红	以「被调用工作流数」与「过审率」为指标，节点包按季度复审并淘汰
战略	用 README 的「4GB / 世界最快」做硬件采购与 SLA 承诺；症状是上线后频繁 OOM 与超时	按真实模型、分辨率、并发跑实测基准，容量规划留余量
工程	跟踪 master 分支追新模型；症状是某个周一后大量自定义节点失效	锁定稳定 tag，新版本先在隔离实例跑冒烟再灰度
工程	把 ComfyUI 当多租户 SaaS 直接对外；症状是单队列互相阻塞、无认证、作业无法审计	每 GPU 一实例 + 自建队列/调度，或采用有隔离与配额的托管方案
工程	依赖「同 seed 出同图」当复现；症状是跨实例/跨版本结果对不上	固定权重哈希、节点 commit、参数与版本；对远程 API 节点单独记账
治理	认为「工具 GPL-3.0」等于「模型可商用」；症状是客户交付后被追责	建立模型许可证台账，逐个核对商用与地域限制，Partner Nodes 单独按 API 条款处理
治理	把社区工作流 JSON 当无害素材随意导入；症状是引用了本机存在漏洞的节点	工作流纳入与节点包同级的来源审查，敏感项目使用离线实例
治理	让智能体直接生成并执行工作流却不做 diff；症状是产出异常但无人能解释改了什么	生成结果先入评审与 diff，最小权限执行，保留完整作业记录

12 / 结论判断、失效条件与参考来源

12.1 明确标注：以下是观点，不是共识

三条判断

一、ComfyUI 的历史意义在于把生成流程变成了一种中间表示。「图即程序、图即请求体、图即配方」这三条性质，让它同时被创作者、研究者与工程系统采用。这不是 UI 偏好之争，而是抽象层之争；也解释了为什么模型实验室会把 day-0 支持写进发布清单。

二、它的最大风险与最大优势来自同一个设计决策。任意 Python 节点 + 开放注册表 + 默认信任内网，既造就 60,000 节点生态，也造就未授权 RCE 与供应链投毒。补丁能修具体 CVE，修不了这个信任模型；边界必须由部署者重画。

三、它现在最像的是「正在补齐语言特性的运行时」。Subgraph、V3 类型化 schema、jobs API、App Mode、Comfy Agent，分别对应函数、类型系统、可观测作业、用户界面与自动编程。这条路径若走通，ComfyUI 会从工具变成基础设施；若走偏，最可能的失败方式不是被竞品打败，而是生态复杂度与商业化摩擦共同抬高使用成本。

12.2 本报告的失效条件

若观察到	则哪条论断失效
主流模型发布不再优先提供 ComfyUI 工作流，或改用其他 IR 作为部署格式	C5（事实运行时）与 C1（图即请求体）失效，整个护城河论证需重写
核心引入默认多租户鉴权与沙箱化节点执行，且未牺牲模型覆盖速度	C6/C7 中「开放性 = 攻击面同源」的判断被削弱，第 08 章门禁建议需简化
出现设计良好的独立第三方对照基准，证明 4GB 声明在指定模型/分辨率下可稳定复现	第 06 章对 4GB 的降级处理应升级为 A/B 级事实
Partner Nodes 在发布日志占比持续过半，或离线 flag 被移除	C8 的「张力未越界」判断失效，第 09 章结论需转向
ComfyGen 类方法在视频/多模态工作流上被证伪（工作流结构对画质无显著影响）	C10 与第 02 章「工作流是可优化对象」的推理链需收回

12.3 参考来源（按证据类型分组）

A · 一手：官方仓库、文档与公告

Comfy-Org/ComfyUI GitHub REST API（仓库元数据：146,557 stars / 17,466 forks / 5,526 issues / GPL-3.0 / created 2023-01-17），2026-11-13 实测。
Comfy-Org/ComfyUI Releases API（v0.42.0 至 v0.45.0，2026-10-18 至 2026-11-10），2026-11-13 实测。
Comfy-Org/ComfyUI README.md @master：Features、Release Process、离线与启动说明、4GB 声明，2026-11-13 抓取。
Comfy-Org/ComfyUI SECURITY.md（v0.44.0 引入，commit ed78da0）：威胁模型与漏洞范围界定。
docs.comfy.org：自托管选项、启动参数（缓存与 VRAM 模式）、V3 Migration、开发者与 API 文档；docs.comfy.ac.cn 账户管理（中文镜像）。
Comfy Org 融资公告中英双版：《ComfyUI raises $30M to scale open-source AI for creative production》，2026-04-24；A 轮 $17M，2025-09-16。
comfy.org 官网与中文站：产品矩阵、Partner Nodes、模型发布页、客户案例《Shake Your Bots Off: how Svedka and Silverside AI made the first AI-generated Super Bowl ad with ComfyUI》，2026-02-08。
GitHub issue #14887（--disable-api-nodes 争议，2026-07-11 至 10-09）与 discussion #14346（节点/模型许可证合规，2026-06）。

A · 一手：学术论文与漏洞记录

Gal et al., ComfyGen: Prompt-Adaptive Workflows for Text-to-Image Generation, arXiv:2410.01731, 2024（NVIDIA Research / Tel Aviv University）；项目页 comfygen-paper.github.io。
Gadot et al., Policy Optimized Text-to-Image Pipeline Design（ComfyGen-RL / FlowRL）, arXiv:2505.21478, 2025（Technion / NVIDIA Research，预印本）。
Unboxing Diffusion Models for the Arts: Interactive Model Bending and Practice-Based Explainability, arXiv:2607.22428, 2026-07（cs.HC）。
NVD / DailyCVE / SentinelOne Vulnerability Database：CVE-2024-21574（2024-12-12）、CVE-2025-67303（2026-01-05，CVSS 7.5，CWE-420）。
Cloud Security Alliance Labs, AI Inference Under Siege: The ComfyUI Cryptomining Botnet, 研究简报及 PDF，2026-04-08。

B · 独立第三方研究与工程实践

DeepWiki：model_management.py 显存与性能配置矩阵、Low VRAM Strategies、Memory and Performance Issues（源码结构化解读，可复核）。
Imaj Future Lab, Our Local AI Cloud: How We Brought ComfyUI to the Render Farm（CGRU/Afanasy 集成），2026。
Latent Space，comfyanonymous 访谈与 ComfyUI 词条，2025-01-04（转述一手访谈，含起源与设计原话）。
AI Wiki：ComfyUI Architecture and Technical Design / Version History and Milestones / History and Origins（二手，用于交叉核对日期）。
local-llm.net《ComfyUI vs Forge vs SwarmUI vs InvokeAI in 2026》（第三方单次性能对比，证据强度：单一案例）。
RenderBob《The Malware Is Inside the Workflow: ComfyUI's Custom-Node Supply-Chain Problem》，2026（安全分析博客）。

C/D · 二手转述、厂商自报与分析推测（仅作线索）

中文技术拆解与 GitCode 博客：架构图、模块归属、竞品星数快照（2026-10-20）——用于线索发现与数字打架核对，未单独支撑结论。
RunningHub / LiblibAI 官网与百度百科 RunningHub 词条：国内云端 ComfyUI 平台规模数据（厂商自报，未经独立审计）。
AI 邮报《400 万用户、估值 5 亿、目前几乎零收入》及 getaibook 融资报道：商业模式与估值分析（含推测成分，标为 D 级）。
CSDN《ComfyUI 商用落地真实案例》等中文转述：其中「效率提升 180 倍」「成本下降 60%」等数字无出处，本报告明确不采信。

检索方法说明：本报告按「理论/学术、一手实证、行业现状 2026、落地实践」四象限做了 7 轮并行检索，并对关键数字回溯一手来源（GitHub API、README、SECURITY.md、Releases、arXiv、NVD）。所有引用数据标注来源与年份；中文二手转述仅用于线索发现，未经一手回溯者不作为结论依据；建模值与实测值在第 06 章显式区分。