Stable Diffusion в n8n: генерация изображений через API

Полный гайд по интеграции Stable Diffusion (SDXL, Flux) с n8n: HTTP-нода для генерации, prompt-шаблоны через Set node, batch-обработка строк из таблицы, сохранение в S3/Telegram.

Обновлено: 2026-05-19

TL;DR

n8n умеет HTTP, очереди и интеграции. Stable Diffusion (SDXL, Flux) умеет рисовать, но требует GPU. Сшить их через HTTP Request — задача на полдня; ключевые вопросы — где брать GPU, как параметризовать промпт, как переживать ошибки и пиковые нагрузки. В этом гайде — рабочая конфигурация: одиночная генерация, batch-обработка строк из таблицы, выбор между SDXL/Flux и оценка стоимости.

Что считать «Stable Diffusion в n8n»

Под этим термином в 2026 году обычно подразумевают одну из четырёх конфигураций:

Чистый Stable Diffusion API через A1111/Forge WebUI. Старый рабочий вариант, но WebUI плохо масштабируется и не умеет в multi-GPU из коробки.
ComfyUI как backend (см. отдельный гайд по n8n + ComfyUI). Самый гибкий вариант, но требует знания нод и экспорта workflow JSON.
Managed Stable Diffusion API — gpupool, ComfyICU, Replicate, fal.ai, BFL (Black Forest Labs). Простой HTTP, без своего GPU.
Self-hosted сервер инференса — vLLM/Diffusers под капотом, свой FastAPI-эндпоинт.

Для n8n-сценария (один промпт → одна или N картинок) удобнее всего варианты 2 и 3. Этот гайд оптимизирован для managed-API, но шаги дублируются и для self-hosted ComfyUI/WebUI.

Выбор модели: SDXL или Flux

Признак	SDXL 1.0 + LoRA	Flux dev	Flux schnell
Качество композиции	Хорошее	Очень хорошее	Хорошее
Понимание длинных промптов	Среднее	Высокое	Высокое
Поддержка LoRA	Огромная экосистема	Растущая (LoRA для Flux уже есть)	Ограниченная
Скорость на A100 80GB	~1.8s на 1024×1024 (30 steps)	~5-8s на 1024×1024 (28 steps)	~1.2s на 1024×1024 (4 steps)
Минимум VRAM (fp16)	8 GB	24 GB	24 GB
Лицензия	OpenRAIL	Non-commercial (dev)	Apache 2.0
Когда выбирать	Маркетплейс-фото, стилизованный контент	Рекламная графика, точное следование тексту	Быстрые превью, A/B-тесты

Краткий ориентир: SDXL — для production-рутины (1000+ картинок/день, цена решает), Flux dev — для маркетинга и редкой высококачественной генерации, Flux schnell — для near-real-time UI и интерактивных превью.

Базовый сценарий: один промпт → одна картинка

n8n workflow:

[Webhook Trigger]
   ↓
[Set: prompt, negative, model, seed]
   ↓
[HTTP Request: POST /v1/images/generate]   ← Bearer auth, JSON body
   ↓
[If: managed-API вернул URL сразу?]
   ├─ Yes  → [HTTP Request: GET URL] → [S3 Upload] → [Respond webhook]
   └─ No   → [Wait + poll /v1/tasks/{id}] → … → [GET URL] → [S3 Upload] → [Respond webhook]

HTTP Request body для SDXL (managed-API в духе gpupool/Replicate):

{
  "model": "sdxl-base-1.0",
  "prompt": "{{ $node['Set'].json.prompt }}",
  "negative_prompt": "blurry, low quality, watermark, text",
  "width": 1024,
  "height": 1024,
  "steps": 30,
  "cfg": 7.5,
  "sampler": "dpmpp_2m",
  "scheduler": "karras",
  "seed": {{ $node['Set'].json.seed }},
  "lora": [{"name": "product-photo-style", "weight": 0.7}],
  "client_id": "n8n-{{ $workflow.id }}-{{ $execution.id }}"
}

client_id нужен для идемпотентности и трейсинга в логах. Без него повторная отправка той же задачи (например, retry) создаст вторую задачу и удвоит счёт.

Параметризация промпта в n8n

В реальных проектах prompt — это не строка, а шаблон с подстановкой. Идиоматично:

Set node фиксирует базовые переменные (product_name, style, mood).
Function node собирает финальный промпт.

// Function node: build_prompt.js
const { product_name, style, mood } = $node['Set'].json;
const stylePresets = {
  'studio_white':   'professional product photography on white background, soft studio light, sharp focus',
  'lifestyle':      'lifestyle photo, natural daylight, shallow depth of field, instagram aesthetic',
  'flat_lay':       'flat lay photography from above, neutral grey background, geometric composition',
};
const prompt = `${product_name}, ${stylePresets[style] || stylePresets.studio_white}, ${mood} mood, hyperdetailed, 8k`;
return [{ json: { prompt } }];

Это удобнее, чем хардкодить промпты в нодах — стили версионируются, шаблоны можно A/B-тестировать.

Batch-генерация из таблицы

Самый частый продакшен-сценарий: «есть Google Sheet / Postgres с 500 товарами, нужно сгенерировать карточку на каждый».

[Schedule Trigger]
   ↓
[Google Sheets: getRows]    ← или [Postgres: SELECT * FROM products WHERE image IS NULL LIMIT 500]
   ↓
[SplitInBatches: size=3]    ← concurrency limiter (не больше 3 параллельных задач)
   ↓
[Function: build_prompt]
   ↓
[HTTP Request: POST /v1/images/generate]
   ↓
[Wait + polling]
   ↓
[HTTP Request: GET result URL]
   ↓
[AWS S3: Upload Object]
   ↓
[Google Sheets / Postgres: update row.image_url]
   ↓
[Loop back to SplitInBatches]

Важные детали:

batchSize в SplitInBatches = ваш предел concurrency. Managed-API обычно ставит limit (например, 5 параллельных задач на ключ). Ставьте n8n batchSize ≤ этому лимиту, иначе словите 429.
Wait перед polling — экспоненциальный (5s → 10s → 20s, capped). На SDXL первый ответ обычно за 2-4s, на Flux dev — 5-10s.
Idempotency: client_id = ${row.id} (id строки). Если worker n8n перезапустится посреди батча, не сгенерим дубль.

Сохранение результата

Самые частые синки:

Хранилище	Когда выбирать	Нода в n8n
AWS S3 / Yandex Object Storage	Прод, нужен CDN-URL, GDPR/152-ФЗ requirements	S3 (Upload Object)
Telegram-канал	Превью для команды, ручная модерация	Telegram (sendPhoto)
Google Drive	Чистовые ассеты для маркетинга, шеринг с не-инженерами	Google Drive
Локальный диск n8n	Только dev, не для prod (контейнер n8n не персистентен по умолчанию)	Move Binary Data
Postgres (bytea / pointer на S3)	Прод-БД, нужны транзакционные гарантии «row + image»	Postgres (Insert/Update)

Лучший паттерн в проде: S3 + Postgres-указатель. n8n загружает PNG в S3, получает URL, кладёт URL в БД одной транзакцией. Если что-то сломалось посреди — retry безопасен (S3 PUT идемпотентен по ключу).

Обработка ошибок

Конкретные ситуации, которые встречаются почти всегда:

HTTP 429 (rate limit) — managed-API ограничил concurrency. Решение: ставите Retry On Fail (3 попытки, backoff 5s/15s/45s) + уменьшаете batchSize в SplitInBatches.
HTTP 400 «model not found» — указали flux-pro на тарифе, где он недоступен. Решение: проверьте список моделей через /v1/models и сделайте маппинг.
Status=failed, error=cuda_oom — особенно на Flux при 1280×1280. Решение: понизить разрешение до 1024×1024 или сменить тариф GPU.
Status=failed, error=safety_filter — managed-API срезал генерацию по фильтру. Решение: переписать prompt; иногда помогает добавить «safe-for-work, no people».
Timeout — генерация шла >60 секунд, n8n уронил HTTP Request. Решение: polling через Wait вместо синхронного запроса; для async-API это и так норма.
Картинка некачественная (артефакты, кривые руки) — это не ошибка, это качество модели/промпта. Решение: добавить LoRA, заменить sampler (DPM++ 2M Karras почти всегда лучше Euler), поднять steps.

Все ошибки роутятся через Error Workflow (Settings → Workflow → Error workflow). Туда летят все unhandled exceptions с full context — связывайте с Telegram-каналом «#alerts-images».

Оценка стоимости

Очень грубая оценка (порядок величин для RU-managed API в 2026):

Сценарий	Расход
SDXL 1024×1024 30 steps	~₽1–2 за картинку (managed pay-per-task)
Flux dev 1024×1024 28 steps	~₽4–8 за картинку
Flux schnell 1024×1024 4 steps	~₽0.6–1.2 за картинку
Self-hosted RTX 4090 (24 GB) почасовая аренда	~₽120–180/час (≈ ₽0.05–0.08 за SDXL картинку при 1.8s)

Self-hosted дешевле только при стабильной утилизации >40%. На рваной нагрузке (типичный e-commerce — пики при загрузке каталога, пустота днём) pay-per-task почти всегда выходит дешевле, чем держать GPU включённым.

Чек-лист перед прод-релизом

API-ключ в Credentials, не в JSON ноды.
У всех HTTP Request включён Retry On Fail (минимум 3 попытки).
SplitInBatches с batchSize ≤ лимиту concurrency managed-API.
Idempotency по client_id = бизнес-идентификатор строки.
Error Workflow подключён, алерт в Telegram.
Изображения сохраняются в S3 + URL в БД (не локально в n8n).
Стоимость одного прогона измерена и положена в дашборд (можно через Yandex.Metrika events или отдельную таблицу в БД).

Частые вопросы

Какая модель Stable Diffusion подходит для n8n-сценариев?

SDXL — универсальный baseline (быстро, хорошее качество, много LoRA). Flux dev — лучше следует промпту, но требует больше VRAM и медленнее. Для маркетплейс-фото обычно хватает SDXL + LoRA-стиля; для рекламной графики и сложных композиций — Flux.

Можно ли запускать Stable Diffusion из n8n без своего GPU?

Да, через managed-API. n8n отправляет POST с prompt/seed/cfg в HTTP-ноде, получает URL результата. Своего GPU и CUDA не нужно.

Как организовать batch-генерацию изображений в n8n?

Источник данных (Sheets/Postgres/CSV) → SplitInBatches → HTTP Request на генерацию → Wait+polling → сохранение. Контролируйте concurrency через batchSize SplitInBatches, чтобы не упереться в rate limit API.

Как сохранять сгенерированные изображения из n8n?

Самые частые синки: AWS S3 / Yandex Object Storage (через S3-ноду), Telegram-канал (sendPhoto), Google Drive, локальный диск через Move Binary Data. Лучше всего — S3 + публичный CDN-URL, дальше отдельная нода кладёт URL в БД.