AUTOMATIC1111을 Gradio Workflow로 재구축하기

gr.Workflow

graphs를 통해 AUTOMATIC1111의 stable-diffusion-webui처럼 복잡한 것을 구축하는 데 필요한 내용을 보여주었습니다. 본 게시물에서는 AUTOMATIC1111의 대부분 기능 세트를 단일 워크플로우 캔버스로 재구축한 Workflow1111을 안내합니다.

Workflow1111은 73개 노드를 사용하여 구축된 11개의 미디어 파이프라인 그래프입니다. 이 워크플로우는 text-to-image, hi-resolution fix, image-to-image, prompt-matrix grids, VLM interrogate, detection-to-inpaint masks, ControlNet-style annotators, 배경 제거(background removal), PNG Info 저장, 그리고 image-to-video에 대한 SOTA 모델들을 통합합니다.

Hugging Face 계정으로 로그인하거나 액세스 토큰을 제공하여 이 파이프라인들 중 어느 것이든 실행할 수 있습니다. 로그인하면 모델 호출은 사용자의 할당량(quota)을 사용합니다.

👉 Workflow1111을 사용해 보거나, Space를 복제하여 자신만의 사용 사례에 맞게 재배선해 보세요.

캔버스를 살펴보겠습니다.

모든 미디어 파이프라인은 지난 게시물과 공식 가이드에서 다룬 동일한 네 가지 연산자(operator) 종류로 구축되었습니다. 캔버스 위의 각 노드는 하나의 연산자를 감싸고 있으며, 이 연산자의 입력 및 출력은 연결할 포트가 됩니다. 네 가지 연산자 종류에 대한 빠른 참고 자료는 다음과 같습니다: fn

은 Python 함수이며, model은 InferenceClient를 통해 호출되는 모델이고, space는 또 다른 Gradio Space이며, dataset은 Hub 데이터셋의 한 행입니다.

파이프라인들을 하나씩 살펴보겠습니다.

이것이 핵심 파이프라인입니다. A1111의 txt2img 탭에서 기대할 수 있는 컨트롤들(negative prompt, steps, CFG, seed, width 및 height)과 체크포인트를 선택하는 model_id 필드를 가지고 있습니다. 프롬프트는 먼저 프롬프트 빌더 fn 노리를 거쳐 선택된 스타일 프리셋이 추가되고 텍스트가 정리된 후, Inference Providers를 통해 체크포인트를 호출하는 model 노리로 들어갑니다. 사후 처리(post-process) fn 노리는 생성 매개변수를 PNG의 메타데이터에 기록하여 출력하며, 이것이 나중에 PNG Info 파이프라인에서 다시 읽어오는 내용입니다.

Automatic1111에서는 hi-resolution fix가 먼저 txt2img 출력을 업스케일링한 다음 두 번째 디노이징 패스를 실행합니다. 여기서는 대신 두 개의 노드 경로를 거칩니다. 텍스트-이미지 결과는 refine 지침(

이는 AUTOMATIC1111의 프롬프트 매트릭스와 같습니다. 기본 프롬프트인 "외로운 참나무(a lone oak tree)"가 fn 노드를 통해 네 개의 접미사(일출 시, 폭풍우 속에서, 은하수 아래에서, 가을 안개 속에서)와 결합되고, 각 변형은 자체 텍스트-이미지 노드로 전송됩니다. 마지막 노드가 이 네 가지 결과를 하나의 컨택트 시트로 합칩니다.

gr.Workflow는 루프 연산자(loop operator)가 없기 때문에, 네 개의 텍스트-이미지 노드는 캔버스 위에 나란히 배치됩니다. 이들은 동일한 종속성 깊이에 있으므로 병렬로 실행되며, 네 이미지 모두 동시에 생성을 시작합니다.

이는 Automatic1111의 Extras 탭과 같습니다. 여기에는 두 개의 업스케일러 노드가 있으며, 각각 다른 경로를 거칩니다. 첫 번째는 fn 노드 내에서 로컬 Lanczos 리샘플링을 수행하며, 네트워크 호출이 필요 없고 Pillow가 크기를 조정하는 속도만큼 빠르게 완료됩니다. 두 번째는 AuraSR ×4이며, 캔버스 위의 첫 번째 space 노드입니다. 이 노드는 Hub의 Space를 호출하고 그 결과를 다른 어떤 노드의 출력처럼 취급합니다.

배경 제거(Background removal) 역시 같은 방식으로 작동합니다. BRIA RMBG-2.0은 또 다른 space 노드이므로, 전체 모델이 자체 Space에 존재하며 이 캔버스는 단지 이를 호출하는 역할을 합니다.

Canny, 라인 아트(line art), 스케치(sketch), luma-depth, 포스터라이즈(posterize)는 Automatic1111의 ControlNet 확장 기능에서 일반적으로 얻을 수 있는 전처리 필터입니다. 여기에서는 각각 모델 없이 순수 NumPy로 작성된 fn 노드입니다. 건물 파사드의 미리 로드된 예시 사진에 대해 각 주석 생성기는 CPU에서 약 반 초가 걸립니다.

이 앱에는 36개의 연산자(operator) 노드가 있으며, 그중 32개는 fn 노드이고, 이 중 22개는 네트워크 호출 없이 완전히 인-프로세스(in-process)로 실행됩니다. 연결이 끊겨도 캔버스의 약 3분의 2가 계속 작동합니다. 이것들이 일반 Python 함수이기 때문에, 캔버스나 서버, GPU와 아무 관계없이 직접 테스트할 수도 있습니다.

AUTOMATIC1111은 생성 세부 정보를 PNG의 parameters에 저장합니다.

텍스트 청크(text chunk)를 읽고 PNG Info 탭에서 이를 다시 불러옵니다. Workflow1111도 동일하게 작동합니다. 텍스트-이미지 파이프라인의 후처리 노드(post-process node)는 메타데이터를 작성하고, 이 파이프라인은 프롬프트(prompt), 네거티브 프롬프트(negative prompt), 스텝(steps), CFG, 시드(seed), 이미지 크기(image size), 모델을 포함하여 이를 다시 읽어옵니다.

PNG Info가 데이터를 읽는 이미지 노드는 또한 Wan 2.2 I2V A14B 노드로 연결되어 애니메이션을 생성합니다. 데모 예시에서는 잠자고 있는 여우가 깨어나 움직이기 시작합니다. 참조 노드(reference node) 하나가 필요한 만큼 많은 다운스트림 파이프라인에 데이터를 공급할 수 있기 때문에 두 번째 업로드 상자가 없습니다. 따라서 단일 업로드가 메타데이터를 읽고 동일한 캔버스에서 애니메이션화됩니다.

지금까지 모든 모델 호출은 Inference Providers나 Space를 통해 다른 사람의 하드웨어로 전송되었습니다. 이것이 바로 자체 GPU 없이도 Workflow1111과 같은 것을 구축하고 실행할 수 있는 이유입니다.

fn 노드는 단지 Python 코드일 뿐이지만, 따라서 로컬에서 모델을 불러와 자체 GPU에서 실행하는 것도 가능합니다. FastVideo/fastvideo-fasth3-preview는 정확히 그렇게 하는 gr.Workflow 앱입니다. 이는 MiniMax-H3의 4단계 증류본인 FastH3를 실행하고 ZeroGPU에서 사운드트랙이 있는 비디오를 생성합니다.

전체 앱은 하나의 바운드 함수(bound function)에 달려 있습니다:

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

ZeroGPU는 함수가 필요로 할 때 GPU를 제공하고, 호출이 완료되면 이를 해제합니다. gr.Workflow는 이러한 세부 사항을 알 필요가 없습니다. 단지 fn 노드를 호출할 뿐입니다.

이는 Spaces에만 국한된 이야기도 아닙니다. bind= 지점을 로컬 체크포인트(local checkpoint)를 불러오는 함수로 지정하고, 자체 머신에서 .launch()를 실행하면 Workflow1111 캔버스가 자체 GPU를 구동할 수 있습니다.

캔버스 위의 모든 출력 노드(output node)는 수작업으로 라우트를 작성하지 않아도 REST 엔드포인트가 됩니다. Workflow1111은 그중 아홉 개를 노출합니다: /image, /edited_image, /generated_prompt, /recovered_prompt, /detected_objects, /x_y_grid, /upscaled_local, /annotator_map, 그리고 /png_info.

동일한 엔드포인트들은 MCP 도구(tool)이기도 합니다. mcp_server=True로 실행하세요.

(가이드) 그리고 모든 출력 노드는 AI 어시스턴트가 호출할 수 있는 도구로 표시됩니다. Claude Code, Cursor 또는 모든 MCP 클라이언트를 서버 URL에 연결하세요:

{
"mcpServers": {
"workflow1111": {
...

이제 에이전트는 접착 코드(glue code) 없이도 이미지를 생성하거나, 프롬프트를 읽어내거나, 탐지(detection)를 실행하는 등 더 큰 작업의 단계로 실행할 수 있습니다. 각 호출자는 X-HF-Token 헤더에 자신의 토큰을 보내므로 Space는 자체적인 토큰을 보유하지 않습니다.

AUTOMATIC1111은 기능 목록을 제공했지만, 비교 대상이 되는 도구 Gradio Workflow는 노드 그래프(node graph)라는 점에서 ComfyUI와 정말 유사합니다. 사람들이 구축하고 배포하려는 많은 것들에 대해 gr.Workflow가 동일한 영역을 다룹니다.

노드는 자신이 소유하지 않은 하드웨어일 수 있습니다. 추론 제공업체(Inference Providers)를 통해 실행되거나, 허브의 모든 Space 또는 모든 API를 호출하거나, 데이터셋에서 가져올 수 있습니다. 이것이 Workflow1111이 자체 GPU 없이 실행되는 방식입니다.
모든 출력은 타입이 지정된 REST 엔드포인트가 됩니다. 이 엔드포인트들은 그래프로부터 생성됩니다.
방문자는 자신의 신원(identity)으로 워크플로우를 실행할 수 있습니다. OAuth를 켜고 공개 URL을 공유하면, 누구나 설치 없이 로그인하여 앱을 사용할 수 있습니다.
동일한 캔버스에서 모델과 양식(modality)을 혼합할 수 있습니다. 확산 모델(Diffusion models), LLM, VLM, 탐지기(detectors), 비디오 모델 모두 동일한 워크플로우의 일부가 될 수 있습니다.
맞춤 기능이 필요한가요? 함수를 작성하세요. 사용자 정의 노드는 Python 함수이므로, Python이 할 수 있는 모든 것을 수행할 수 있습니다.

그 결과는 사용자들이 브라우저에서 열고, 로그인하고, 즉시 사용하며, 코드로 호출할 수 있는 다중 모델 파이프라인입니다.

Workflow1111은 73개의 노드를 가지고 있지만, 처음에는 이것만으로 시작했습니다:

import gradio as gr
def your_function(text: str) -> str:
pass
...

bind=는 함수를 노드로 변환하고, edges=는 이들을 연결하며, .launch()는 캔버스를 브라우저에서 열어 계속 편집할 수 있게 합니다. 준비가 되면, gradio deploy

전체 것을 Space에 게시합니다. gr.Workflow 가이드에는 JSON 스키마와 모든 오퍼레이터 유형을 포함하여 전체 세부 정보가 있습니다.

만약 이미 작동하는 것부터 시작하고 싶다면, Workflow1111을 열고 Duplicate를 누른 다음 변경할 11개의 파이프라인 중 하나를 선택하세요: 노드를 삭제하거나, 모델을 교체하거나, 흐름을 재배선할 수 있습니다. 더 작게 시작하고 싶다면, 이전 게시물에 각각 약 1분 만에 실행할 수 있는 다섯 가지 워크플로우가 있습니다.

어떤 것을 만들든, X에 게시하고 @gradio를 태그하세요. 저희는 여러분의 워크플로우를 홍보해 드릴 준비가 되어 있습니다.