Comfy API上线：工作流一键部署为生产级API

ComfyUI 正式推出 Comfy API，把原本只能在本地或自建 GPU 环境里跑的工作流，直接变成一个可自动扩缩容的生产级 API 端点——这意味着 ComfyUI 从"创作者的本地工具"正式跨入"工程团队的生产基础设施"。

这次发布到底解决了什么问题

在 Comfy API 出现之前，把一个 ComfyUI 工作流搬进生产环境是一段极其痛苦的旅程。团队需要租 GPU、重新安装每一个自定义节点、重新下载每一个模型、重新梳理 Python 依赖，还得自己写一套扩缩容逻辑。这个过程的核心痛点不是"难"，而是"重复"——你在本地已经调通的东西，到了生产环境要再走一遍，而且不保证结果一致。

Until now, putting a ComfyUI workflow into production meant rebuilding its environment somewhere else.

Comfy API 的做法是：把你已经调好的工作流连同它的自定义节点、LoRA、模型和 Python 依赖一起打包，部署成一个带独立 URL 的托管端点。工作流本身不变，引擎保持开源，构建产物（Build）可以移植到你自己的硬件上。

Build 和 Release 的分离是整套设计的核心

Comfy API 引入了一个关键的工程概念：Build 和 Release 的分离。

Build 捕获的是你的工作流所依赖的完整环境——ComfyUI 版本、自定义节点、模型、Python 依赖。Builder 会读取工作流 JSON（或从 Comfy Desktop 导出的快照），自动识别需要的模型和节点，并帮助解决冲突的 Python 依赖。你可以覆盖它选的任何版本。

从 Build 切出一个不可变的 Release，然后把这个 Release 部署为托管端点。因为 Release 是不可变的，你测试的环境就是你部署的环境。需要改动时，更新 Build、切一个新 Release，线上那个不受影响。

这个设计直接回应了 AI 工作流部署中最常见的翻车场景：本地跑得好好的，部署上去因为某个自定义节点版本不一样、某个模型文件被替换了、某个 Python 包升级了，结果输出完全不对。不可变 Release 从机制上消除了这类"环境漂移"问题。

终端和 Agent 两条路都能走

Comfy API 不只是给点击式操作准备的。通过 comfy-cli 和 Comfy Skills，你或者你的编码 Agent 可以直接从终端打包和部署本地 ComfyUI 安装：

``` $ comfy build init ✓ Scanned this ComfyUI install - custom nodes, models, pinned deps $ comfy build push --release ```

也可以跳过这些设置，直接复制 Comfy API 页面上的 Agent prompt，粘贴到编码 Agent 里，让它完成打包和部署。Comfy SDK 目前支持在 Comfy API 和 Comfy Cloud API 上运行工作流；如果要用同一个 SDK 对接自托管的 ComfyUI 部署，只需运行代理服务并设置一个环境变量。

这意味着 ComfyUI 正在把自己嵌入到现代开发者的工作流里——不是让你打开一个 GUI 画节点，而是让你的 CI/CD、你的编码 Agent、你的终端命令直接操作工作流的构建和部署。

谁应该用，谁不需要

Comfy 在公告里很坦诚地划了边界：如果你已经在 RunPod 或 Modal 上跑 ComfyUI 而且跑得通，继续用。如果你需要 GPU 做的事情不止 ComfyUI，通用平台可能更合适。

Comfy API earns its place when ComfyUI is the part you keep managing.

RunPod 和 Modal 解决的是"不用管基础设施"的问题。Comfy API 额外解决的是"不用管 ComfyUI 环境"的问题——自定义节点、模型、Python 依赖、版本漂移，这些全部由 Build 机制接管。它是 ComfyUI 背后的团队做的，所以从本地工作流到部署端点的路径是产品的一部分，而不是你需要自己维护的集成。

团队协作和治理是这次发布的隐藏重点

公告里有一句话点出了真实场景：构建工作流的人，往往不是唯一需要运行它的人。

Comfy API 就是为这个交接设计的。在 Team 和 Enterprise 计划上，队友可以从同一个 Build 工作，ComfyUI 版本、模型、自定义节点和 Python 依赖全部锁定在一起。你可以把最小实例数设为 0，没有请求时不消耗 GPU 时间；也可以在请求不能等冷启动时保持 worker 热运行。使用量、GPU 时间和成本都在 Developer Platform 控制台里追踪。

Enterprise 客户还可以用 Managed Builds 和治理控制来标准化整个团队批准的 ComfyUI 版本、模型、自定义节点和依赖。这对有合规要求或多人协作的企业来说，是把 ComfyUI 从"某个人电脑上的魔法"变成"团队可审计的基础设施"的关键一步。

定价和可用性

Comfy API 在付费 Comfy 计划上可用，从 Standard 计划起步。使用量单独计费：GPU 时间按秒计费，存储按小时比例计费。

这对行业意味着什么

ComfyUI 一直以来的核心价值是控制力——每个节点可见，每个参数可调。但这种控制力长期被锁在"本地"这个边界里。你可以在 ComfyUI 里做出极其精细的图像和视频生成管线，但要让团队用、让产品调、让客户跑，就得在另一个地方重建一遍，而且不保证行为一致。

Comfy API 关闭的就是这个缺口。你在 ComfyUI 里构建工作流，Comfy API 打包环境并在端点后面运行它，你的团队或产品调用它但不需要看到图。

Comfy is building an open standard for visual AI. For that standard to hold up in production, the workflow can't lose its custom nodes, models, or dependencies on the way there.

这句话是整篇公告里最重要的战略表态。ComfyUI 不只想做一个好用的节点编辑器，它想成为视觉 AI 的开放标准。而一个标准要在生产环境里站得住，工作流在从本地到云端的过程中就不能丢失它的自定义节点、模型或依赖。Build 的版本化、引擎的开源、工作的可移植性，都是为这个目标服务的。

对从业者来说，这意味着几件事：独立创作者和小团队可以用极低的运维成本把自己的工作流变成产品功能；企业团队终于有了一个可治理、可审计、可标准化的 ComfyUI 生产路径；而那些已经在自建 ComfyUI 基础设施的团队，现在有了一个"官方出品"的替代方案来决定是否迁移。ComfyUI 正在从工具变成平台，而这次 API 发布是它迈过那条线的一步。