← 文章 / AI图像生成
HuggingFace博客 4小时前 · 2026-09-11 01:16:43 · 1 阅读

用 Gradio Workflow 重建 AUTOMATIC1111

在上一篇博文中,我们用 gr.Workflow 搭建了五张小图,并预告了构建像 AUTOMATIC1111 的 stable-diffusion-webui 这样复杂的项目需要什么。这一篇带你认识 Workflow1111——我们把 AUTOMATIC1111 的大部分功能重新实现为一张工作流画布。

Workflow1111 由 73 个节点组成,包含 11 条媒体处理管线,集成了文本生成图像、高分辨率修复、图生图、提示词矩阵网格、VLM 审问、检测转修复遮罩、ControlNet 风格标注器、背景移除、PNG 信息存储以及图转视频等 SOTA 模型。

登录 Hugging Face 账号或提供 access token 即可运行其中任意管线。登录后,模型调用会消耗你自己的配额。

👉 试试 Workflow1111,或者复制这个 Space,按自己的需求重新编排。

下面带你看一遍画布。

画布上有什么

所有管线都由上一篇博文和官方指南中介绍的四种算子类型搭建而成。画布上每个节点封装一个算子,算子的输入输出就是连接边的端口。四种算子类型速查:fn 是 Python 函数,model 是通过 InferenceClient 调用的模型,space 是另一个 Gradio Space,dataset 是 Hub 数据集的一行数据。

下面逐一走过各条管线。

文本生成图像

这是核心管线,拥有 A1111 txt2img 页面该有的所有控制项:负面提示词、步数、CFG、种子、宽高,以及用于选择 checkpoint 的 model_id 字段。提示词先经过一个 prompt-builder fn 节点,该节点会拼上所选的风格预设并清理文本,然后进入 model 节点,通过 Inference Providers 调用 checkpoint。出口处还有一个后处理 fn 节点,负责把生成参数写入 PNG 的元数据——这正是 PNG Info 管线后续读取的内容。

Hi-resolution fix

在 Automatic1111 中,Hi-resolution fix 会先把 txt2img 的输出放大,再跑一轮去噪。这里则改用一个两节点的"绕路"方案:文生图结果送入 FLUX.1-Kontextmodel 节点,附带一条精修指令("增强精细细节和微观纹理,保持构图不变"),出来的画面更清晰、尺寸更大。

Image-to-image

同一个 Kontext 节点兼作图生图功能。上传一张图,描述你想做的修改,就能拿到编辑后的结果。

让 LLM 来写提示词

从一个粗略的提示词开始,比如"A lighthouse in a storm"。这条流水线把它发给 Qwen3-4Bmodel 节点,再经一个小型 fn 节点将回复整理成不超过四十个标签的清单:"stormy sea, wet rocks, dramatic composition, low angle shot, volumetric lighting, ominous tone"。任意 diffusion model 节点都能接上这个输出来渲染图像。

与 ComfyUI 不同,这里没有用到任何自定义节点。在 Gradio workflow 中,LLM 和 diffusion model 都是同一画布上的普通 model 算子。

从图片反推提示词

这相当于 AUTOMATIC1111 的 Interrogate 按钮,只不过用 VLM 替代了 CLIP 来做识别。Qwen2.5-VL 看一张夜市照片,写出可能生成它的提示词。一个 ViT 分类节点读取同一张图,返回标签:restaurant 51.9%、tobacco shop 15.6%、toyshop 9.1%。

两个节点共用同一张图作为输入,gr.Workflow 会将它们并行执行,总耗时大约只等于跑一个节点。

检测生成修复掩码

AUTOMATIC1111 需要你手动画 inpaint mask。这条流水线改为让检测器自动生成。DETR 在一张街景照片中定位到六个目标(三个人、一只狗、一辆自行车和一辆汽车),之后流程分两条支路:一条把检测框画在原图上,另一条把它们转成掩码,供下游的 inpaint 流水线使用。

绘图和遮罩生成都用 Pillow 和 NumPy 在本地完成,只有检测调用会离开本机。

Prompt matrix

这类似于 AUTOMATIC1111 的 prompt matrix。一个基础提示词 "a lone oak tree" 通过 fn 节点与四个后缀(at sunrise、in a thunderstorm、under the Milky Way、in autumn fog)组合,每个变体分别送入各自的 text-to-image 节点。最后一个节点把四张结果拼成一张联络表。

gr.Workflow 没有循环操作符,所以四个 text-to-image 节点并排放在画布上。由于依赖深度相同,它们会并行运行,四张图同时开始生成。

Upscale and background removal

这类似于 Automatic1111 的 Extras 标签页。这里有两个 upscaler 节点,走不同的路线。第一个是 fn 节点里的本地 Lanczos 重采样,不需要网络调用,速度就是 Pillow 缩放的速度。第二个是 AuraSR ×4,也是画布上第一个 space 节点:它调用 Hub 上的一个 Space,并把结果当作普通节点输出使用。

背景移除也是同样的做法。BRIA RMBG-2.0 是另一个 space 节点,整个模型跑在它自己的 Space 里,这个画布只是调用它而已。

Annotators

Canny、line art、sketch、luma-depth 和 posterize 这些预处理器,在 Automatic1111 里通常来自 ControlNet 扩展。而在这里,每一个都是一个用纯 NumPy 写成的 fn 节点,背后没有任何模型。在一张预加载的建筑立面示例照片上,每个 annotator 在 CPU 上大约耗时半秒。

这个应用共有 36 个操作符节点,其中 32 个是 fn 节点,而这 32 个里又有 22 个完全在进程内运行、不需要网络调用。也就是说,就算断网,画布上大约三分之二的功能仍然可用。由于这些都是普通的 Python 函数,你还可以直接测试它们,完全不需要画布、服务器或 GPU。

PNG Info

AUTOMATIC1111 将生成参数写入 PNG 文件的 parameters 文本块,PNG Info 标签页负责读回。Workflow1111 机制相同:文生图管线末尾的后处理节点写入元数据,当前管线将其读回,内容涵盖提示词、负向提示词、步数、CFG、seed、图像尺寸和模型信息。

图生视频

PNG Info 读取图片的同一个节点,还接入 Wan 2.2 I2V A14B 节点做动画生成——演示中一只熟睡的狐狸醒来并开始活动。这里不需要第二个上传框:一个引用节点可以扇出到任意多下游管线,单次上传就能在同一画布上完成元数据读取和动画生成。

在本地 GPU 上运行模型

到目前为止,所有模型调用都发往别人的硬件,经由 Inference Providers 或 Space 完成。正因如此,你无需自备 GPU 就能搭建并运行 Workflow1111。

不过 fn 节点本质就是 Python,同样可以加载本地模型、跑在你自己的 GPU 上。FastVideo/fastvideo-fasth3-preview 就是一个 gr.Workflow 应用,做的正是这件事。它运行 FastH3——MiniMax-H3 的 4 步蒸馏版本——并在 ZeroGPU 上生成带音效的视频。

整个应用的核心就一个绑定函数:

@spaces.GPU(duration=get_duration, size=GPU_SIZE)
def _generate(prompt_embeds, text_token_tags, height, width, num_frames, seed):
    ...

gr.Workflow(bind={"generate": generate, "status": status}).launch()

ZeroGPU 在函数需要时分配 GPU,调用结束后释放。gr.Workflow 不需要感知这些细节,它只是调用 fn 节点。

这也不仅限于 Spaces。把 bind= 指向一个加载本地 checkpoint 的函数,在自己机器上运行 .launch(),Workflow1111 的画布就能驱动你自己的 GPU。

每个输出都是 API

画布上的每个输出节点都会自动成为一个 REST endpoint,无需手写任何路由。Workflow1111 共暴露了九个:/image/edited_image/generated_prompt/recovered_prompt/detected_objects/x_y_grid/upscaled_local/annotator_map/png_info

from gradio_client import Client

client = Client("ysharma/Workflow1111", oauth_token="hf_...")

image, params, hires = client.predict(
    "a red fox in a snowy pine forest",  # 提示词
    "",                                  # 负面提示词
    "Cinematic",                         # 风格预设
    "enhance fine detail",               # 高清细化指令
    api_name="/image",
)

这些 endpoint 同时也是 MCP 工具。启动时加上 mcp_server=True教程),每个输出节点都会变成 AI 助手可以直接调用的工具。只需把 Claude Code、Cursor 或任何 MCP 客户端指向服务器地址:

{
  "mcpServers": {
    "workflow1111": {
      "url": "https://ysharma-workflow1111.hf.space/gradio_api/mcp/",
      "headers": { "X-HF-Token": "hf_..." }
    }
  }
}

这样,agent 就能在更大的任务流程中执行生图、回读 prompt、运行检测等步骤,完全不需要胶水代码。每个调用方通过 X-HF-Token 请求头传入自己的 token,Space 本身不持有任何凭证。

与 ComfyUI 的关系

AUTOMATIC1111 给了我们功能清单,但 Gradio Workflow 真正要对标的其实是 ComfyUI,因为两者都是节点图。对于大多数搭建和发布场景,gr.Workflow 已经足够覆盖。

  • 节点可以是你自己没有的硬件。它可以通过 Inference Providers 运行,调用 Hub 上任意 Space 或任意 API,也可以从数据集拉取数据。Workflow1111 就是这样在没有自有 GPU 的情况下跑起来的。
  • 每个输出都会生成一个带类型的 REST endpoint。路由由图自动派生。
  • 访客可以用自己的身份运行工作流。开启 OAuth,分享公开链接,任何人无需安装任何东西就能登录使用你的应用。
  • 在同一画布上混搭模型和模态。扩散模型、LLM、VLM、检测器和视频模型都可以放进同一个工作流。
  • 需要自定义功能?写个函数就行。自定义节点就是一个 Python 函数,所以 Python 能做的事它都能做。

最终得到的是一个多模型流水线:别人可以在浏览器里打开、登录、立即使用,也能通过代码调用。

动手构建你自己的

Workflow1111 有 73 个节点,但它最初只是这样一段代码:

import gradio as gr

def your_function(text: str) -> str:
    pass

gr.Workflow(bind=[your_function]).launch()

bind= 把你的函数变成节点,edges= 负责连线,.launch() 会在浏览器里打开画布,方便你继续编辑。完成后运行 gradio deploy,整个应用就能部署到 Space 上。gr.Workflow 指南包含全部细节,包括 JSON schema 和所有算子类型。

如果你想从一个能跑起来的项目入手,可以打开 Workflow1111,点击 Duplicate,然后挑一条流水线来改造:删节点、换模型、重新连线都行。如果想从更小的示例开始,上一篇文章里有五个工作流,每个大约一分钟就能跑起来。

不管你构建了什么,欢迎发到 X 并 @gradio 我们,我们很乐意帮你推广你的工作流。

原始来源: HuggingFace博客

评论 (0)