Відтворення AUTOMATIC1111 за допомогою робочого процесу Gradio

Оновити на GitHub

У нашій попередній публікації ми створили п’ять невеликих графів gr.Workflow і натякнули, що знадобилося б для побудови чогось настільки складного, як stable-diffusion-webui від AUTOMATIC1111. У цій публікації ми розповімо про Workflow1111, де відтворили більшість функцій AUTOMATIC1111 на одному полотні робочого процесу.

Workflow1111 — це граф із одинадцяти медіапайплайнів, створений за допомогою сімдесяти трьох вузлів. Він об’єднує найсучасніші моделі для перетворення тексту на зображення, виправлення зображень у високій роздільності, перетворення зображення на зображення, матриць промптів, інтерпретації VLM, створення масок для inpaint на основі детекції, анотаторів у стилі ControlNet, видалення тла, збереження PNG Info та перетворення зображення на відео.

Ви можете запускати будь-який із цих пайплайнів, увійшовши за допомогою облікового запису Hugging Face або надавши токен доступу. Після входу виклики моделей використовують вашу власну квоту.

👉 Спробуйте Workflow1111 або створіть дублікат Space і почніть переналаштовувати його під власний сценарій використання.

Розгляньмо полотно.

Що є на полотні

Усі медіапайплайни побудовані з тих самих чотирьох типів операторів, розглянутих у нашій попередній публікації та в офіційному посібнику. Кожен вузол на полотні обгортає один оператор, а входи й виходи оператора стають портами, до яких ви під’єднуєте ребра. Коротко про чотири типи операторів: fn — це функція Python, model — модель, що викликається через InferenceClient, space — інший Gradio Space, а dataset — рядок із набору даних Hub.

Розгляньмо пайплайни по черзі.

Перетворення тексту на зображення

Це основний пайплайн. Він має елементи керування, які ви очікуєте побачити на вкладці txt2img в A1111: негативний промпт, кількість кроків, CFG, seed, ширину та висоту, а також поле model_id для вибору чекпойнта. Спочатку промпт проходить через вузол fn для побудови промпту, який додає вибраний стиль і очищує текст, а потім надходить до вузла model, що викликає чекпойнт через Inference Providers. Вузол fn постобробки записує параметри генерації в метадані PNG на виході — саме їх згодом зчитує пайплайн PNG Info.

Виправлення у високій роздільності

В Automatic1111 виправлення у високій роздільності спочатку збільшує результат txt2img, а потім запускає другий прохід денойзингу. Тут замість цього використовується обхід із двох вузлів. Результат перетворення тексту на зображення надходить до вузла model FLUX.1-Kontext з інструкцією для покращення («покращити дрібні деталі та мікротекстуру, зберегти композицію без змін») і повертається чіткішим та більшим.

Перетворення зображення на зображення

Цей самий вузол Kontext також виконує роль вкладки image-to-image. Завантажте зображення, опишіть бажану зміну — і він поверне відредаговане зображення.

Дозвольте LLM написати промпт

Дозвольте LLM написати промпт

Почніть із приблизного промпту на кшталт «Маяк під час шторму». Цей пайплайн надсилає його до вузла model Qwen3-4B, а невеликий вузол fn перетворює відповідь на чистий список тегів, обмежений сорока: «бурхливе море, мокре каміння, драматична композиція, ракурс знизу, об’ємне освітлення, похмурий тон». До цього виходу можна під’єднати будь-який вузол дифузійної моделі, щоб згенерувати зображення.

На відміну від ComfyUI, тут немає спеціального вузла. У робочому процесі Gradio LLM і дифузійна модель є звичайними операторами model на одному полотні.

Зчитування зображення назад у промпт

Це аналог кнопки Interrogate в AUTOMATIC1111, але інтерпретацію виконує VLM, а не CLIP. Qwen2.5-VL аналізує фотографію нічного ринку й пише промпт, за яким її можна було б створити. Вузол класифікатора ViT читає те саме зображення та повертає мітки: ресторан — 51,9%, тютюнова крамниця — 15,6%, магазин іграшок — 9,1%.

Обидва вузли використовують один і той самий вхід зображення, тому gr.Workflow запускає їх паралельно, і ви отримуєте обидві відповіді приблизно за час, потрібний для одного запуску.

Від детекції до маски inpaint

AUTOMATIC1111 змушує вас вручну малювати маску inpaint. Цей пайплайн натомість генерує її за допомогою детектора. DETR знаходить шість об’єктів на вуличній фотографії (трьох людей, собаку, велосипед і автомобіль), після чого робочий процес розгалужується: один напрямок малює виявлені рамки на оригінальному зображенні, інший перетворює їх на маску, яку можна передати в наступний пайплайн inpaint.

І малювання, і створення маски виконуються локально за допомогою Pillow та NumPy. Лише виклик детекції залишає комп’ютер.

Матриця промптів

Це аналог матриці промптів AUTOMATIC1111. Базовий промпт «самотній дуб» вузол fn поєднує з чотирма суфіксами (на світанку, під час грози, під Чумацьким Шляхом, в осінньому тумані), а кожен варіант надходить до власного вузла перетворення тексту на зображення. Фінальний вузол об’єднує чотири результати в один аркуш ескізів.

У gr.Workflow немає оператора циклу, тому чотири вузли перетворення тексту на зображення розташовані поруч на полотні. Оскільки вони мають однакову глибину залежностей, то запускаються паралельно, і всі чотири зображення починають генеруватися одночасно.

Збільшення та видалення тла

Це аналог вкладки Extras в Automatic1111. Тут є два вузли збільшення, які працюють по-різному. Перший — локальне ресемплювання Lanczos у вузлі fn, якому не потрібен мережевий виклик і який завершується так швидко, як Pillow може змінити розмір. Другий — AuraSR ×4, і це перший вузол space на полотні: він викликає Space на Hub і обробляє результат як вихід будь-якого іншого вузла.

Видалення тла працює так само. BRIA RMBG-2.0 — це ще один вузол space, тому вся модель живе у власному Space, а це полотно лише викликає його.

Анотатори

Canny, line art, sketch, luma-depth і posterize — це препроцесори, які зазвичай надає розширення ControlNet в Automatic1111. Тут кожен із них є вузлом fn, написаним на звичайному NumPy, без моделі за ним. На попередньо завантаженому прикладі фотографії фасаду будівлі кожен анотатор працює на CPU близько пів секунди.

У застосунку 36 операторних вузлів, 32 з них — вузли fn, а 22 із цих вузлів працюють повністю в процесі без мережевого виклику. Приблизно дві третини полотна продовжують працювати, навіть якщо ви втратите з’єднання. Оскільки це звичайні функції Python, їх також можна тестувати безпосередньо — без полотна, сервера чи GPU.

PNG Info

AUTOMATIC1111 зберігає деталі генерації в текстовому фрагменті parameters файлу PNG, а вкладка PNG Info зчитує їх назад. Workflow1111 робить те саме. Вузол постобробки в пайплайні перетворення тексту на зображення записує метадані, а цей пайплайн зчитує їх, зокрема промпт, негативний промпт, кількість кроків, CFG, seed, розмір зображення та модель.

Перетворення зображення на відео

Вузол зображення, з якого PNG Info зчитує дані, також передає зображення до вузла Wan 2.2 I2V A14B, який його анімує; у демонстраційному прикладі спляча лисиця прокидається й починає рухатися. Друге поле завантаження не потрібне, оскільки один еталонний вузол може живити будь-яку кількість наступних пайплайнів: одне завантажене зображення одночасно аналізується на метадані та анімується на тому самому полотні.

Запуск моделей на власному GPU

Досі кожен виклик моделі надходив на чиєсь чуже обладнання через Inference Providers або Space. Саме тому ви можете створювати й запускати щось на кшталт Workflow1111 без власного GPU.

Однак вузол fn — це просто Python, тож він також може завантажити модель локально й запустити її на вашому GPU. FastVideo/fastvideo-fasth3-preview — це застосунок gr.Workflow, який робить саме це. Він запускає FastH3, чотирикрокову дистиляцію MiniMax-H3, і генерує відео із саундтреком на 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= функцію, яка завантажує локальний чекпойнт, запустіть .launch() на власному комп’ютері — і полотно Workflow1111 зможе керувати вашим GPU.

Кожен вихід — це API

Кожен вихідний вузол на полотні стає REST-ендпойнтом без ручного написання маршрутів. 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",
)

Ці самі ендпойнти також є інструментами MCP. Запустіть із параметром mcp_server=True (посібник), і кожен вихідний вузол з’явиться як інструмент, який може викликати AI-асистент. Підключіть Claude Code, Cursor або будь-який MCP-клієнт до URL-адреси сервера:

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

Тепер агент може генерувати зображення, зчитувати промпт або виконувати детекцію як кроки складнішого завдання без додаткового коду зв’язування. Кожен викликач надсилає власний токен у заголовку X-HF-Token, тому Space не зберігає жодного токена.

Місце цього рішення поруч із ComfyUI

AUTOMATIC1111 надав нам список функцій, але інструмент, із яким насправді порівнюють Gradio Workflow, — це ComfyUI, оскільки обидва є графами вузлів. Для багатьох речей, які люди хочуть створювати й запускати, gr.Workflow охоплює ту саму функціональність.

• Вузол може працювати на обладнанні, яким ви не володієте. Він може працювати через Inference Providers, викликати будь-який Space на Hub або будь-який API чи отримувати дані з набору даних. Саме так Workflow1111 працює без власного GPU.
• Кожен вихід стає типізованим REST-ендпойнтом. Ендпойнти генеруються з графа.
• Відвідувачі можуть запускати робочі процеси від власного імені. Увімкніть OAuth, поділіться публічною URL-адресою — і будь-хто зможе увійти та користуватися застосунком без встановлення будь-чого.
• Змішуйте моделі й модальності на одному полотні. Дифузійні моделі, 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-схему та всі типи операторів.

Якщо ви волієте почати з того, що вже працює, відкрийте Workflow1111, натисніть Дублювати й виберіть один з одинадцяти пайплайнів для змін: видаляйте вузли, замінюйте моделі, переналаштовуйте потік. Якщо хочете почати з чогось меншого, у попередній публікації є п’ять робочих процесів, кожен із яких можна запустити приблизно за хвилину.

Що б ви не створили, опублікуйте це в X і позначте @gradio. Ми залюбки поширимо інформацію про ваші робочі процеси.

Моделі, згадані в цій статті 8

Spaces, згадані в цій статті 4

Більше статей із нашого блогу