Воссоздание AUTOMATIC1111 с рабочим процессом Gradio
gr.Workflow и рассказали, что потребуется для создания чего-то настолько сложного, как stable-diffusion-webui от AUTOMATIC1111. В этой статье мы расскажем о Workflow1111 — проекте, в котором большая часть функций AUTOMATIC1111 воссоздана на едином рабочем поле workflow.
Workflow1111 — это граф из одиннадцати медиапайплайнов, созданный с помощью семидесяти трёх узлов. Он объединяет передовые модели для преобразования текста в изображение, исправления изображений в высоком разрешении, преобразования изображения в изображение, матриц промптов, анализа изображений с помощью VLM, создания масок для инпейнтинга на основе детекции, аннотаторов в стиле ControlNet, удаления фона, сохранения информации PNG и преобразования изображения в видео.
Вы можете запустить любой из этих пайплайнов, войдя в аккаунт Hugging Face или указав токен доступа. После входа вызовы моделей используют вашу собственную квоту.
👉 Попробуйте Workflow1111 или создайте копию Space и начните перенастраивать его под свой сценарий использования.
Давайте разберём рабочее поле.
Что находится на рабочем поле
Все медиапайплайны построены из тех же четырёх типов операторов, которые мы рассмотрели в предыдущей статье и в официальном руководстве. Каждый узел на рабочем поле оборачивает один оператор, а входы и выходы оператора становятся портами, к которым подключаются рёбра. Кратко напомним о четырёх типах операторов: fn — это функция Python, model — модель, вызываемая через InferenceClient, space — другой Gradio Space, а dataset — строка из датасета Hub.
Давайте разберём пайплайны по очереди.
Преобразование текста в изображение
Это основной пайплайн. В нём есть ожидаемые элементы управления из вкладки txt2img A1111: негативный промпт, количество шагов, CFG, seed, ширина и высота, а также поле model_id для выбора чекпойнта. Сначала промпт проходит через узел fn построения промпта, который добавляет выбранный пресет стиля и очищает текст, а затем поступает в узел model, вызывающий чекпойнт через провайдеров инференса. Узел fn постобработки по пути выхода записывает параметры генерации в метаданные PNG — именно их позднее считывает пайплайн PNG Info.
Исправление в высоком разрешении
В Automatic1111 исправление в высоком разрешении сначала увеличивает изображение, полученное через txt2img, а затем выполняет второй проход шумоподавления. Здесь вместо этого используется обход из двух узлов. Результат преобразования текста в изображение поступает в узел model FLUX.1-Kontext с инструкцией уточнения («улучшить мелкие детали и микротекстуру, сохранить композицию неизменной»), после чего возвращается более резким и крупным.
Преобразование изображения в изображение
Тот же узел Kontext также используется для вкладки image-to-image. Загрузите изображение, опишите желаемое изменение — и получите отредактированное изображение.
Пусть LLM напишет промпт
Пусть LLM напишет промпт
Начните с приблизительного промпта, например «Маяк во время шторма». Этот пайплайн отправляет его в узел model Qwen3-4B, а небольшой узел fn превращает ответ в чистый список тегов длиной не более сорока: «бурное море, мокрые скалы, драматичная композиция, съёмка с нижнего ракурса, объёмное освещение, зловещая атмосфера». К этому выходу можно подключить любой узел диффузионной модели для создания изображения.
В отличие от ComfyUI здесь нет пользовательского узла. В workflow Gradio и LLM, и диффузионная модель являются обычными операторами model на одном рабочем поле.
Считать изображение обратно в промпт
Это аналог кнопки Interrogate в AUTOMATIC1111, только анализ выполняет VLM, а не CLIP. Qwen2.5-VL анализирует фотографию ночного рынка и пишет промпт, который мог бы её создать. Узел классификатора ViT считывает то же изображение и возвращает метки: ресторан — 51,9%, табачный магазин — 15,6%, магазин игрушек — 9,1%.
Оба узла используют один и тот же вход изображения, поэтому gr.Workflow запускает их параллельно, и вы получаете оба ответа примерно за время, необходимое для одного запуска.
От детекции к маске для инпейнтинга
AUTOMATIC1111 заставляет вручную рисовать маску для инпейнтинга. Этот пайплайн вместо этого создаёт её с помощью детектора. DETR находит на фотографии улицы шесть объектов (трёх людей, собаку, велосипед и автомобиль), после чего workflow разделяется на две ветви: одна рисует обнаруженные рамки на исходном изображении, а другая превращает их в маску, которую можно передать в последующий пайплайн инпейнтинга.
И рисование, и создание маски выполняются локально с помощью 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
До сих пор каждый вызов модели отправлялся на чужое оборудование — через провайдеров инференса или 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 предлагает те же возможности.
- Узел может работать на оборудовании, которым вы не владеете. Он может выполняться через провайдеров инференса, вызывать любой Space на Hub или любой API либо получать данные из датасета. Именно поэтому Workflow1111 работает без собственного GPU.
- Каждый выход становится типизированным REST-эндпойнтом. Эндпойнты создаются на основе графа.
- Посетители могут запускать workflow от своего имени. Включите OAuth, поделитесь публичным URL, и любой пользователь сможет войти и использовать приложение без установки чего-либо.
- Смешивайте модели и модальности на одном рабочем поле. Диффузионные модели, LLM, VLM, детекторы и видеомодели могут быть частью одного workflow.
- Нужно что-то особенное? Напишите функцию. Пользовательский узел — это функция 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, нажмите Duplicate и выберите один из одиннадцати пайплайнов для изменения: удаляйте узлы, заменяйте модели, перенастраивайте поток. Если вы хотите начать с чего-то меньшего, в предыдущей статье есть пять workflow, каждый из которых можно запустить примерно за минуту.
Что бы вы ни создали, опубликуйте это в X и отметьте @gradio. Мы с радостью расскажем о ваших workflow.
Модели, упомянутые в этой статье 8
Spaces, упомянутые в этой статье 4
Сообщество
Действительно впечатляющий разбор. Больше всего выделяется то, что структура графа обеспечивает параллельное выполнение «из коробки» (как в примерах с матрицей промптов и анализом изображений) без дополнительного кода оркестрации. Сочетание типов узлов fn, model и space на одном рабочем поле также хорошо подчёркивает сравнение с ComfyUI: вы получаете гибкость пользовательских узлов благодаря обычному Python, но при этом автоматически получаете REST/MCP-эндпойнты без написания кода. Интересно, насколько сложным может стать рабочее поле, прежде чем производительность или сопровождаемость начнут вызывать проблемы. Кто-нибудь переходил за предел 73 узлов?
· Зарегистрируйтесь или войдите, чтобы оставить комментарий
Модели, упомянутые в этой статье 8
Spaces, упомянутые в этой статье 4
Переведено автоматически с английского. Оригинал статьи — по ссылке ниже.
