Workflow1111 собрал возможности AUTOMATIC1111 на холсте Gradio

Один холст вместо набора вкладок

10 сентября команда Gradio представила Workflow1111 — реконструкцию большей части возможностей stable-diffusion-webui от AUTOMATIC1111 в виде единого визуального графа. Демонстрация включает 73 узла и 11 медиаконвейеров: text-to-image, hi-resolution fix, image-to-image, составление prompt matrix, описание изображения с помощью VLM, построение маски по найденным объектам, annotators в стиле ControlNet, удаление фона, чтение PNG Info и image-to-video. Это не новая модель генерации, а пример того, как разнородные модели и функции можно соединить в Gradio Workflow.

У каждого узла есть входные и выходные порты, а связи задают порядок передачи данных. В публикации перечислены четыре типа операторов: fn вызывает Python-функцию, model обращается к модели через InferenceClient, space использует другой Gradio Space, а dataset получает строку из набора данных на Hub. Благодаря этому локальная обработка, удалённый inference и готовые сервисы выглядят на одном холсте одинаковыми строительными блоками.

Авторы не утверждают, что воспроизвели AUTOMATIC1111 буквально. Они говорят о большей части набора функций и показывают альтернативную организацию тех же классов задач. Поэтому Workflow1111 разумнее оценивать как демонстрационный reference workflow и отправную точку для собственных графов, а не как совместимую замену всех расширений, настроек и привычных сценариев stable-diffusion-webui.

Как устроена генерация и редактирование

Основной text-to-image-конвейер принимает negative prompt, число шагов, CFG, seed, ширину, высоту и model_id. Сначала fn-узел очищает запрос и добавляет выбранный стилевой preset, затем model-узел вызывает checkpoint через Inference Providers. После генерации ещё одна функция записывает параметры в metadata PNG, чтобы отдельный конвейер PNG Info мог восстановить prompt, negative prompt, steps, CFG, seed, размер изображения и выбранную модель.

Hi-resolution fix здесь реализован не так, как в AUTOMATIC1111. Вместо увеличения изображения с последующим вторым проходом denoising результат передаётся в FLUX.1-Kontext с инструкцией сохранить композицию и усилить детали. Тот же model-узел используется для image-to-image: пользователь загружает изображение и описывает требуемое изменение. Это функциональное приближение к знакомым операциям, но не заявление об идентичности алгоритмов и результатов.

Ещё один конвейер превращает короткую идею в prompt: Qwen3-4B расширяет фразу, а Python-функция формирует список не более чем из 40 тегов. Обратную задачу выполняет Qwen2.5-VL, который описывает загруженную фотографию, пока ViT-классификатор параллельно определяет категории изображения. Параллельность возникает из структуры графа: независимые узлы одного уровня зависимостей запускаются одновременно, а не ждут друг друга.

Локальные функции соседствуют с удалёнными моделями

В примере с маской DETR находит объекты на фотографии, после чего граф разделяется на две ветви: одна рисует bounding boxes, другая превращает области объектов в маску для последующего inpainting. Рисование и подготовка маски выполняются локально с Pillow и NumPy; наружу уходит только запрос к detector. Аналогично Canny, line art, sketch, luma-depth и posterize реализованы обычными функциями NumPy без отдельной модели.

По подсчёту авторов, в приложении 36 операторных узлов, из которых 32 относятся к fn, а 22 работают полностью внутри процесса без сетевого запроса. Это не означает, что весь Workflow1111 автономен без интернета: генеративные model- и space-узлы по умолчанию обращаются к внешнему inference. Но значительную часть преобразований можно тестировать как обычные Python-функции без холста, сервера или GPU.

Для upscale показаны два подхода. Первый — локальный Lanczos resize в fn-узле, второй — четырёхкратное увеличение через AuraSR, запущенную в отдельном Space. Background removal таким же образом делегируется BRIA RMBG-2.0. В prompt matrix четыре варианта запроса направляются в четыре параллельных text-to-image-узла, поскольку специального loop-оператора в gr.Workflow нет.

Собственный GPU необязателен, но возможен

Публичная демонстрация может вызывать модели через Inference Providers и Spaces, поэтому для запуска графа пользователю не обязательно иметь локальный GPU. Для модельных вызовов нужно войти в Hugging Face или предоставить access token; расходуется квота самого пользователя. Такой режим упрощает первый запуск, но переносит доступность, лимиты и часть задержки на используемые внешние сервисы.

При этом fn-узел может загрузить checkpoint локально и использовать собственный GPU. В статье приведён FastVideo/fastvideo-fasth3-preview: функция, обёрнутая декоратором Spaces GPU, получает ускоритель в ZeroGPU на время вызова и освобождает его после завершения. Авторы также поясняют, что bind можно направить на функцию с локальной моделью и запустить Workflow на собственной машине. Сам граф не обязан знать, где именно исполняется функция.

Эта абстракция удобна для прототипирования, но не отменяет инженерных различий между режимами. Удалённый provider, чужой Space, ZeroGPU и собственный сервер имеют разные лимиты, стоимость, приватность данных и требования к эксплуатации. Workflow1111 показывает единый способ соединения узлов; опубликованный материал не содержит сравнительного benchmark задержки или стоимости всех вариантов размещения.

Граф сразу становится API и MCP-сервером

Каждый выходной узел Workflow1111 автоматически превращается в REST endpoint. В демонстрации их девять: /image, /edited_image, /generated_prompt, /recovered_prompt, /detected_objects, /x_y_grid, /upscaled_local, /annotator_map и /png_info. Клиент может вызвать их через gradio_client, не создавая маршруты вручную. Это позволяет использовать один и тот же граф как браузерный интерфейс и как программный backend.

Те же выходы можно предоставить в качестве MCP tools, если запустить приложение с mcp_server=True. В примере MCP-клиент подключается к URL сервера и передаёт пользовательский токен в заголовке X-HF-Token; сам Space не хранит общий token для посетителей. Таким способом AI-агент может включить генерацию изображения, detection или чтение metadata в более крупную последовательность действий.

Именно здесь проходит наиболее содержательная граница с привычным локальным UI. Авторы сравнивают Workflow с ComfyUI и подчёркивают возможность смешивать LLM, VLM, diffusion, detector, video, функции, datasets и удалённые Spaces на одном холсте. Однако статья не доказывает полного покрытия экосистемы custom nodes ComfyUI. Практический выбор будет зависеть от того, важнее ли готовая публикация через браузер и API или существующая совместимость с конкретными локальными workflow и расширениями.

Что проверить перед использованием

Для собственного прототипа логично начать не с копирования всех 73 узлов, а с одного проверяемого конвейера. Нужно определить, какие операции могут оставаться локальными, какие требуют model или space, какой credential используется каждым внешним вызовом и какие данные покидают машину. После этого полезно отдельно измерить время, расход квоты и поведение при недоступности сети. Эти проверки не являются обещанными функциями продукта, а следуют из смешанной локально-удалённой архитектуры демонстрации.

Workflow1111 уже показывает полезный принцип: визуальный граф не обязан заканчиваться изображением на экране. Его результаты могут быть typed REST endpoints и MCP tools, а одна reference node может одновременно питать несколько downstream-процессов. За счёт этого холст превращается из редактора картинок в способ описать исполняемый мультимодальный сервис.

Пока вывод ограничен демонстрацией Hugging Face. Подтверждены структура из 11 конвейеров, состав основных узлов, варианты удалённого и локального исполнения и автоматическая публикация выходов как API. Реальные надёжность, стоимость и удобство сопровождения нужно измерять на своём графе. Именно такая проверка покажет, остаётся ли Workflow1111 эффектным примером или становится практичной основой для конкретного приложения.