
stable-diffusion.cpp — отличная альтернатива ComfyUI
При использовании нейросетей для работы с картинками, видео и музыкой часто используется окружение ComfyUI. Это заслуживающий доверия инструмент, позволяющий работать со сложными многоузловыми пайплайнами, ControlNet-цепочками, используя кастомные ноды сообщества и визуальный дебаг. Благодаря этому ComfyUI фактически не имеет сравнимой по функционалу альтернативы.
Если пользователю не нужен столь богатый набор опций, доступный в ComfyUI, но нужно по максимуму «выжать соки» из своего оборудования, можно задействовать программу stable-diffusion.cpp от разработчика, известного на github под ником leejet:

stable-diffusion.cpp — это движок инференса без визуального конструктора пайплайнов, схожий с llama.cpp, прекрасно подходящий для локальной AI-генерации и обработки изображений/видео и подобных задач, но менее требовательный к VRAM и подходящий для серверного inference.

Основные отличия stable-diffusion.cpp от ComfyUI:
| Параметр | ComfyUI | stable-diffusion.cpp |
|---|---|---|
Язык реализации | Python, PyTorch | Чистый C/C++, движок ggml (как у llama.cpp) |
Модель выполнения | Граф нод (node graph), визуальный редактор пайплайнов | CLI (sd-cli) + HTTP-сервер (sd-server) с базовым встроенным Web UI |
Зависимости | Python-окружение, PyTorch, CUDA-toolkit с python-биндингами, десятки pip-пакетов | Никаких — движок самодостаточен, собирается в один бинарник |
Формат весов | safetensors/ckpt/diffusers, часто fp16/bf16 | safetensors/ckpt нативно + собственная GGUF-квантизация (Q8_0, Q5_K, Q4_K и т.д.) |
Поддерживаемые архитектуры | Очень широкий охват через community-ноды | SD1.x/2.x/SDXL, SD3/3.5, Flux/Flux.2, Wan2.1/2.2 (видео), Qwen-Image(-Edit), Z-Image, Krea2, Ideogram4, LTX-2.3 и другие |
Расширяемость | Огромная экосистема кастомных нод (ControlNet-цепочки, IPAdapter, ADetailer и т.д.) | Ограниченный набор встроенных фич (LoRA, PhotoMaker, upscale, кэширование денойзинга типа TaylorSeer/EasyCache), расширение — через C API, а не через ноды |
GPU-модель распределения нагрузки | Через кастомные ноды/оффлоад-логику ComfyUI, довольно гибкая | Через флаги —backend/—max-vram, размещение отдельных компонентов пайплайна (диффузионная модель, VAE, текстовый энкодер) на разных устройствах |
Потребление ресурсов на старте | Тяжёлое: интерпретатор Python, загрузка torch/cuDNN, JIT-компиляция части операторов | Лёгкое: запуск бинарника, инициализация ggml-контекста — секунды, не минуты |
Ключевым архитектурным отличием stable-diffusion.cpp от ComfyUI является оболочка (среда композиции пайплайнов), предназначенная для исполнения одного инференс-запроса. Поэтому stable-diffusion.cpp не подходит тем, кому нужен сложный многошаговый workflow с масками, множественными ControlNet и постобработкой десятками нод. В то же время, stable-diffusion.cpp хорошо подходит для быстрой и экономной по памяти генерации изображений по фиксированному пайплайну.

Вам шашечки или ехать?
Народная мудрость…
Почему стоит обратить внимание на stable-diffusion.cpp?
Основным преимуществом stable-diffusion.cpp в сравнении с ComfyUI является возможность запуска современных AI-моделей даже на слабом железе. За счёт нативной GGUF-квантизации, надежно работающего даже на таких картах, как Nvidia Tesla V100, механизма Flash Attention (опция diffusion-fa) и оффлоада весов в RAM (опция offload-to-cpu), квантованные diffusion-модели (типа Z-Image) запускаются даже на GPU с 4 ГБ VRAM!

Другим немаловажным преимуществом stable-diffusion.cpp является отсутствие Python/PyTorch зависимостей. Благодаря этому не нужно использовать никаких виртуальных окружений (venv), следить за совместимостью версий torch/xformers/triton/cuDNN после обновлений. Благодаря использованию статически слинкованного для нативной машины бинарника достигается значительно более высокое быстродействие и полная совместимость со своим железом. Кроме того, исполняемые файлы stable-diffusion.cpp в разы быстрее инициализируются в сравнении с Python-стеком с загрузкой CUDA-контекста и JIT. Старт программы с нуля происходит буквально за секунды даже на относительно старом железе.
Движок sd.cpp работает на CPU, а также с любыми GPU, включая CUDA, Vulkan, Metal, ROCm/HIP, SYCL, OpenCL, Moore Threads MUSA и даже Adreno GPU через Android NDK.
На момент написания статьи stable-diffusion.cpp полностью поддерживает работу с safetensors, GGUF-квантованными диффузионными моделями, VAE и текстовыми энкодерами (включая LLM-энкодеры Qwen3) и «из коробки» даёт возможность работать в распределенном кластере, расширяя доступный объем памяти и архитектурные возможности. Благодаря rpc-серверу можно вынести обработку VAE/Text_Encoder-запросов на вторую машину с видеокартой любой архитектуры, что довольно сложно сделать в comfyui. Например, можно запустить AI-генерацию одновременно на Nvidia и AMD, причем даже на старых GPU, не поддерживаемых в последних версиях pytorch и rocm.
В распределенном AI-кластере, созданном на основе ggml-сервера stable-diffusion.cpp можно одновременно задействовать видеокарту Nvidia CUDA (старой или новой архитектуры), плюс новый AMD Radeon с rocm, либо старый AMD (либо Nvidia или Intel) с Vulkan.
Перечень возможностей программы постоянно расширяется, позволяя практически любому пользователю найти подходящий функционал.

К сожалению, в stable-diffusion.cpp пока нет визуальной композиции пайплайнов, экосистемы кастомных нод, подобных IPAdapter, ADetailer, множественных ControlNet, AnimateDiff и ряда других опций, доступных в comfyui. В будущем ситуация может измениться, так как stable-diffusion.cpp активно развивается усилиями сообщества.
Версии sd-server, выпущенные начиная с апреля 2026 года, позволяют работать с программой не только через консоль, но и в формате txt2img/img2img через веб-интерфейс (доступен в браузере по адресу http://127.0.0.1:1234).

Лучше всего запускать stable-diffusion.cpp, собрав исполняемые файлы из исходников, например, в Gentoo linux в связке с OpenRC + XFCE + LightDM.
Сборка stable-diffusion.cpp из исходного кода в linux gentoo
Устанавливаем зависимости:
sudo emerge --sync
sudo emerge -av dev-vcs/git dev-build/cmake sys-devel/gcc media-libs/libwebp media-libs/libpng media-libs/libjpeg-turbo
Для GPU-ускорения видеокарт NVIDIA CUDA:
sudo emerge -av x11-drivers/nvidia-drivers dev-util/nvidia-cuda-toolkit
Для multi-GPU систем Nvidia инсталлируем NCCL (см. статью«Никелирование» llama.cpp на компьютере с несколькими GPU Nvidia).
Для сборки stable-diffusion.cpp с поддержкой работы через браузер, устанавливаем в ситеме инструменты веб-разработки Node.js и pnpm:
sudo emerge --ask net-libs/nodejs && sudo npm install -g pnpm
В логах сборки теперь появится сообщение HAVE_INDEX_HTML enabled (веб-панель успешно вкомпилирована в бинарник sd.cpp).
Для видеокарт AMD, Intel и старых Nvidia ставим поддержку Vulkan:
sudo emerge -av media-libs/vulkan-loader dev-util/vulkan-headers dev-util/glslang
Скачиваем исходники stable-diffusion.cpp с github:
git clone --recursive https://github.com/leejet/stable-diffusion.cpp && cd stable-diffusion.cpp
Флаг —recursive обязателен, так как движок ggml и веб-интерфейс sdcpp-webui подключены как git submodules.
Собираем исполняемые файлы из исходного кода:
CPU-only:
mkdir build && cd build
для Nvidia (желательно от 4 ГБ VRAM):
cmake .. -DCMAKE_BUILD_TYPE=Release
cmake --build . --config Release -j$(nproc)
mkdir build-cuda && cd build-cuda
cmake .. -DCMAKE_BUILD_TYPE=Release -DSD_CUDA=ON
cmake --build . --config Release -j$(nproc)
Сборка для видеокарт с Vulkan (портируемый вариант, может использоваться на связке разных GPU в одной системе), простейший синтаксис:
mkdir build-vulkan && cd build-vulkan
cmake .. -DCMAKE_BUILD_TYPE=Release -DSD_VULKAN=ON
cmake --build . --config Release -j$(nproc)
Бинарники после сборки stable-diffusion.cpp находятся по пути build*/bin/sd-cli и build*/bin/sd-server.
Проверка версии sd-cli:
./sd-cli --version
stable-diffusion.cpp version master-765-bb84971, commit bb84971

Пример команд для сборки stable-diffusion.cpp на компьютере с Nvidia Tesla V100 16GB + Nvidia GeForce GTX 1660 Ti (gentoo linux):
git clone --recursive https://github.com/leejet/stable-diffusion.cpp
cd stable-diffusion.cpp
cmake -B build \
-DCMAKE_BUILD_TYPE=Release \
-DSD_CUDA=ON \
-DGGML_CUDA_F16=ON \
-DGGML_RPC=ON \
-DGGML_NCCL=ON \
-DGGML_CUDA_FORCE_MMQ=ON \
-DGGML_CCACHE=OFF \
-DCMAKE_CUDA_ARCHITECTURES="70;61-virtual;80-virtual" \
-DCMAKE_C_COMPILER=gcc-14 \
-DCMAKE_CXX_COMPILER=g++-14 \
-DCMAKE_C_FLAGS="-O3 -march=native -pipe -flto" \
-DCMAKE_CXX_FLAGS="-O3 -march=native -pipe -flto" \
-DCMAKE_CUDA_FLAGS="-O3" \
&& cmake --build build -j$(nproc)
В этой команде:
DGGML_CUDA_FORCE_MMQ вместе с DCMAKE_CUDA_ARCHITECTURES=80-virtual добавляет поддержку инструкций dp4a для ядер MMQ (Matrix Multiplication Quantized) для GTX 1660Ti. Они работают напрямую с квантованными весами (например, Q4_K, Q8_0) без предварительной распаковки матриц в формат FP16, что предотвращает утечки памяти и снижает общее потребление VRAM при старте модели. На старых видеокартах (без тензорных ядер int8, включая Pascal/GTX 10xx Turing/GTX 16xx, Tesla V100 или AMD RDNA3) этот режим может ощутимо поднять скорость генерации одиночного токена. В то же время, в сравнении со стандартной библиотекой cuBLAS, значительно падает скорость при больших Batch Size (при обработке длинных промптов).
DGGML_NCCL=ON — активирует технологию Nvidia Collective Communication Library, улучшающую коммуникацию между видеокартами Nvidia как на одном компьютере, так и по сети. Реальная архитектура 75 отключена для исключения ошибки при попытке включить несуществующие тензоры на GTX 1660Ti.
В команде сборки специально активированы виртуальные SM 6.1 и 8.0, чтобы видеокарта Nvidia GeForce GTX 1660 Ti , несмотря на gpu-чип Turing, не имеющий тензорных ядер, могла эффективно производить вычисления. Если запустить программу, собранную без добавления поддержки SM6.1 и 8.0, stable-diffusion.cpp выдает предупреждение:
The following devices will have suboptimal performance due to a lack of tensor cores:
Device 1: NVIDIA GeForce GTX 1660 Ti
Consider compiling with CMAKE_CUDA_ARCHITECTURES=61-virtual;80-virtual and DGGML_CUDA_FORCE_MMQ to force the use of the Pascal code for Turing.

Как запустить генерацию изображений в stable-diffusion.cpp?
Запуск stable-diffusion.cpp можно осуществлять также, как и llama.cpp.
Предварительно нужно узнать нумерацию устройств в системе командой:
./sd-cli --list-devices
ggml_cuda_init: found 2 CUDA devices (Total VRAM: 21891 MiB):
Device 0: Tesla V100-SXM2-16GB, compute capability 7.0, VMM: yes, VRAM: 16144 MiB
Device 1: NVIDIA GeForce GTX 1660 Ti, compute capability 7.5, VMM: yes, VRAM: 5747 MiB
CUDA0 Tesla V100-SXM2-16GB
CUDA1 NVIDIA GeForce GTX 1660 Ti
CPU Genuine Intel(R) CPU 0000 @ 2.80GHz
Эти данные нужно добавить в скрипт запуска, например:
#!/bin/bash
export CUDA_MODULE_LOADING=LAZY
# 1. ВКЛЮЧАЕМ РЕЖИМ ПОСТОЯНСТВА ДРАЙВЕРА
sudo nvidia-smi -pm 1
# 2. НАСТРОЙКА TESLA V100
sudo nvidia-smi -i 1 -pl 220
sudo nvidia-smi -i 1 -ac 877,1530
# 3. НАСТРОЙКА GTX 1660 Ti
sudo nvidia-smi -i 0 -pl 120
sudo nvidia-settings -a '[gpu:0]/GPUFanControlState=1'
sudo nvidia-settings -a '[fan:0]/GPUTargetFanSpeed=55'
sudo nvidia-settings -a '[gpu:0]/GPUMemoryTransferRateOffset[4]=800'
sudo nvidia-settings -a '[gpu:0]/GPUGraphicsClockOffset[4]=110'
sudo nvidia-settings -a '[gpu:0]/GPUPowerMizerMode=1'
# 4. ЗАПУСК ВЕБ-СЕРВЕРА НА ПОРТУ 1234 (для работы через интернет-браузер)
./sd-server \
--listen-ip 127.0.0.1 \
--listen-port 1234 \
--diffusion-model /path_to/diffusion_models/gguf/z-image-turbo-F16.gguf \
--vae /path_to/vae/zImage_vae.safetensors \
--llm /path_to/text_encoders/qwen3-4b-instruct-q8_0.gguf \
--fa \
--threads 8 \
--eager-load \
--mmap \
--vae-tiling \
--vae-relative-tile-size 0.25 \
--backend diffusion=CUDA0,vae=CUDA1,te=CUDA1 \
--diffusion-conv-direct \
--vae-conv-direct
В этом скрипте:
--backend diffusion=CUDA0,vae=CUDA1,te=CUDA1 — это распределение блокиов AI-генерации в памяти разных устройств компьютера (аргументы=CUDA0,vae=CUDA1,te=CPU или te=CUDA1). В данном случае диффузионная модель загружается на первую, самую мощную видеокарту Tesla V100 (CUDA0), а VAE и текстовый энкодер— на вторую (GTX 1660Ti);
./sd-server — запуск исполняемого файла веб-сервера для работы локального хостинга и графического интерфейса в браузере;
--listen-ip 127.0.0.1 — IP-адрес, на котором сервер слушает входящие запросы сетевого веб-интерфейса;
--listen-port 1234 — порт сетевого веб-интерфейса;
--diffusion-model ~/.../z-image-turbo-F16.gguf — путь к основной модели нейросети (блок диффузии UNET/DiT). Из этого файла считывается геометрия шума и базовый алгоритм генерации;
--vae ~/.../zImage_vae.safetensors — путь к модели VAE (Autoencoder). Этот блок переводит готовую латентную (математическую) матрицу пикселей в финальную понятную человеку картинку;
--llm ~/.../qwen3-vl-4b-instruct-heretic-q8_0.gguf — путь к большому языковому текстовому энкодеру (в данном случае на базе Qwen3). Он отвечает за то, чтобы нейросеть точно понимала смысл и детали текстового промпта;
--fa — активация алгоритма Flash Attention для математической оптимизации DiT-моделей (Z-Image, Flux и т.д.). Оптимизирует чтение матриц внимания в кэш-памяти GPU, за счет чего ускоряется генерация (в среднем на 20–30%), а потребление VRAM падает;
--threads 8 — Количество процессорных потоков, выделяемых программе на этапе сборки вычислительного графа (по числу физических ядер);
--eager-load — режим «жадной» загрузки. Заставляет сервер принудительно прочитать абсолютно все веса моделей с диска один раз при старте и зафиксировать их в видеопамяти (VRAM). Это полностью исключает медленную подгрузку файлов с диска во время генерации, убирая микрофризы и задержки;
--mmap — активация механизма Memory Mapping (проецирование файлов в оперативную память). Позволяет Linux-ядру использовать свободную RAM как буфер быстрого доступа к файлам моделей, что ускоряет первичный запуск сервера до секунд;
--vae-tiling — включение плиточной (кусочной) обработки изображений на этапе VAE-декодирования. Программа перестает пытаться обработать большой кадр одним монолитным куском. Иногда нужно отключать при генерации артефактов (подробнее в статье «ComfyUI генерирует чёрный квадрат/артефакты вместо изображения. Что делать?»);
--vae-relative-tile-size 0.25 — задает относительный коэффициент размера одного кусочка (тайла). Значение 0.25 математически делит латентную матрицу на 4 части. Вместо гигантского единого буфера в размером порядка 10ГБ, последовательно обрабатываются блоки размером около ~2.6 ГБ каждый, что идеально укладывается в физическую память второй видеокарты. Иногда этот параметр может привести к генерации артефактов.
Для открытия доступа к sd-server с других компьютеров в локальной сети вместо адреса 127.0.0.1 нужно использовать 0.0.0.0 (как у llama.cpp).
По умолчанию, после запуска сервера, интерфейс stable-diffusion.cpp открывается в браузере по адресу http://127.0.0.1:1234/. В нем, среди прочего, можно задать позитивный и негативный промт для генерации, основные параметры работы нейросети. Для создания картинки нажимаем кнопку Generate Image в окне OUTPUT:

При необходимости, можно генерировать картинки из консоли, задавая промт при запуске, например, используя следующий скрипт:
./sd-cli \
--diffusion-model /путь/z-image-turbo-F16.gguf \
--vae /путь/zImage_vae.safetensors \
--llm /путь/qwen3-4b-q8_0.gguf \
-p "$USER_PROMPT" \
--backend diffusion=CUDA0,vae=CUDA1,te=CUDA1 \
--fa \
--threads 8 \
--steps 8 \
--cfg-scale 1.0 \
--sampling-method euler \
--scheduler sgm_uniform \
-W 1280 \
-H 1280 \
--seed -1 \
--eager-load \
--mmap \
--vae-tiling \
--vae-relative-tile-size 0.25

Оптимизация текстового энкодера (LLM) на вспомогательной видеокарте
Интересный сценарий возникает в multi-GPU системах, когда основная мощная карта (например, Tesla V100) загружена диффузионной моделью (Z-Image-Turbo), а вторую карту (GTX 1660 Ti 6 ГБ) хочется использовать только под текстовый энкодер. В этом случае GGUF-версия энкодера часто работает заметно медленнее (до ~3 сек на итерацию). При этом генерация одной картинки размером 1024×1024 занимает почти три минуты:

Основная причина — реализация MMQ на архитектуре Turing, которая не имеет полноценных tensor cores. Теоретически, возможное решение проблемы — использование safetensors-версий диффузионной модели и LLM.

Лучшие safetensors-файлы: qwen_3_4b.safetensors или Qwen3-4B-Instruct-2507.safetensors из репозитория Comfy-Org/z_image_turbo. Если safetensors-энкодер выдаёт ошибку вида
Conditioner model tensor … has wrong shape in model metadata,
можно попробовать скачать более «чистую» версию из репозитория Comfy-Org или конвертировать официальную модель через инструменты stable-diffusion.cpp.
При использовании и safetensors и gguf-моделей с gguf-энкодером на Nvidia GeForce GTX 1660Ti скорость обработки текстового запроса очень медленная:
[INFO ] stable-diffusion.cpp:1468 - total params memory size = 15979.45MB (VRAM 15979.45MB, RAM 0.00MB): text_encoders 4076.43MB(VRAM), diffusion_model 11743.02MB(VRAM), vae 160.00MB(VRAM), controlnet 0.00MB(N/A), extensions 0.00MB(N/A)
[INFO ] stable-diffusion.cpp:1577 - running in FLOW mode
[INFO ] main.cpp:148 - listening on: http://127.0.0.1:1234
[INFO ] stable-diffusion.cpp:4966 - generate_image 1024x1024
[INFO ] denoiser.hpp:1050 - get_sigmas with SGM Uniform scheduler
[INFO ] stable-diffusion.cpp:3844 - sampling using Euler method
[INFO ] stable-diffusion.cpp:4664 - get_learned_condition completed, taking 0.86s
[INFO ] stable-diffusion.cpp:5013 - generating image: 1/1 - seed 42
|==================================================| 8/8 - 1.20s/it
[INFO ] stable-diffusion.cpp:5045 - sampling completed, taking 10.02s
[INFO ] stable-diffusion.cpp:5057 - generating 1 latent images completed, taking 10.02s
[INFO ] stable-diffusion.cpp:4689 - decoding 1 latents
|==================================================| 49/49 - 3.02s/it
[INFO ] stable-diffusion.cpp:4737 - latent 1 decoded, taking 146.16s
[INFO ] stable-diffusion.cpp:4741 - decode_first_stage completed, taking 146.16s
[INFO ] stable-diffusion.cpp:5195 - generate_image completed in 157.05s

После включения декодера TAESD (taef1_decoder.safetensors):
./sd-server \
--listen-ip 127.0.0.1 \
--listen-port 1234 \
--diffusion-model /~/z_image_turbo_fp16.safetensors \
--taesd /~/taef1_decoder.safetensors \
--llm /~/Qwen3-4b-Uncensored-Z-Image-Engineer-V4-Q8_0.gguf \
--fa \
--threads 8 \
--eager-load \
--mmap \
--backend diffusion=CUDA0,te=CUDA1,vae=CUDA0 \
--diffusion-conv-direct
Скорость VAE decode на той же видеокарте упала со 146 секунд до 0.95 секунды (в 150 раз быстрее!!!), общее время генерации 12.26с вместо 157с. Качество картинки осталось прмиерно тем же:

Для дальнейшей оптимизации можно еще больше ускорить Text encoder, используя более агрессивную квантизацию (Q4_K_M/IQ4_XS вместо Q8_0), а также более точно сбалансировать распредление нагрузки/памяти между Tesla V100 и 1660Ti, например, явно закрепить TAESD также на 1660Ti, чтобы максимально разгрузить V100 под диффузию:
Вместо полновесной fp16-модели z_image_turbo_fp16.safetensors (11.7GB VRAM) можно использовать GGUF-кванты, например, leejet/Z-Image-Turbo-GGUF:
- Q8_0 — 6.58 GB (почти без потерь качества)
- Q6_K — 5.26 GB
- Q5_0 — 4.54 GB
- Q4_0 — 3.68 GB
- Q2_K — 2.59 GB (заметные артефакты)
Переход на Q8_0 с fp16 освободил ~5.5GB VRAM на V100 почти без потери качества. После перехода на z_image_turbo-Q8_0.gguf:
./sd-server \
--listen-ip 127.0.0.1 \
--listen-port 1234 \
--diffusion-model ~/-/z_image_turbo-Q8_0.gguf \
--taesd ~/-/taef1_decoder.safetensors \
--llm ~/-/Qwen3-4b-Uncensored-Z-Image-Engineer-V4-Q8_0.gguf \
--fa \
--threads 8 \
--eager-load \
--mmap \
--backend diffusion=CUDA0,te=CUDA1,vae=CUDA0 \
--diffusion-conv-direct
На gguf-модели плюс taesd генерация картинки размером 1024 на 1024 пикселя занимает 11 секунд:

Сравнение AI-быстродействия до тюнинга и после:

Освобождённую память (~5.5GB) на V100 можно использовать для увеличения batch size, более высокого разрешения, или других задач (например, запуск одновременно с ComfyUI).

Заключение
Исходя из небольшого опыта использования stable-diffusion.cpp можно сделать вывод ,что эта программа хотя и не является полноценной заменой ComfyUI, очень хорошо подходит для продакшн/batch-генерации при использовании подходящих моделей и энкодера, особенно после тонкой настройки параметров запуска.
# sd-server — справка по опциям (перевод на русский с пояснениями)
**stable-diffusion.cpp**, версия `master-778-c00a9e9-1-ga8a91b2`, коммит `a8a91b2`
Это справка встроенного HTTP-сервера для генерации изображений/видео на базе C++-порта Stable Diffusion (проект поддерживает SD 1.x/2.x/XL/3.x, Flux, Flux Kontext, Qwen-Image, Wan 2.x, LTX-Video и др.).
```
Usage: ./sd-server [options]
```
> Название `sd-server` запускается с параметрами из командной строки.
---
## 1. Опции сервера (Server Options)
Отвечают за сам HTTP-сервер, а не за генерацию.
| Флаг | Перевод / назначение |
|---|---|
| `-l, --listen-ip <string>` | IP-адрес, на котором слушает сервер (по умолчанию `127.0.0.1`, т.е. только локальный доступ). Чтобы разрешить доступ из сети, укажите `0.0.0.0`. |
| `--serve-html-path <string>` | Путь к HTML-файлу, который будет отдаваться при обращении к корню сервера (`/`) — например, простой веб-интерфейс. Необязательный параметр. |
| `--listen-port <int>` | Порт сервера (по умолчанию `1234`). |
| `-v, --verbose` | Подробный вывод логов (больше диагностической информации). |
| `--color` | Раскрашивать теги логов в зависимости от уровня важности (info/warn/error и т.д.). |
| `-h, --help` | Показать это сообщение и выйти. |
---
## 2. Опции контекста (Context Options)
Задают, какие модели загружать и как распределять их между устройствами (CPU/GPU).
### Пути к моделям
| Флаг | Пояснение |
|---|---|
| `-m, --model <string>` | Путь к полной модели (единый файл со всеми компонентами — UNet/DiT + VAE + текстовый энкодер). |
| `--clip_l <string>` | Путь к текстовому энкодеру CLIP-L (используется в SD1.5/SDXL/SD3/Flux). |
| `--clip_g <string>` | Путь к текстовому энкодеру CLIP-G (используется в SDXL/SD3). |
| `--clip_vision <string>` | Путь к визуальному энкодеру CLIP (для задач, где модель «видит» референсное изображение). |
| `--t5xxl <string>` | Путь к текстовому энкодеру T5-XXL (используется в SD3, Flux — даёт лучшее понимание длинных промптов). |
| `--llm <string>` | Путь к LLM, используемому как текстовый энкодер (например, Qwen2.5-VL для Qwen-Image, Mistral-Small 3.2 для Flux2). |
| `--llm_vision <string>` | Путь к визуальной части (ViT) этой LLM. |
| `--qwen2vl <string>` | Устаревший алиас для `--llm`. |
| `--qwen2vl_vision <string>` | Устаревший алиас для `--llm_vision`. |
| `--diffusion-model <string>` | Путь к отдельной (standalone) диффузионной модели, если она не включена в единый файл `-m`. |
| `--high-noise-diffusion-model <string>` | Отдельная модель для «высокого уровня шума» — используется в MoE-архитектурах вроде Wan2.2, где одна модель работает на ранних (шумных) шагах, другая — на поздних. |
| `--uncond-diffusion-model <string>` | Модель для безусловной (unconditional) генерации; используется, например, в Ideogram4 при классическом CFG. |
| `--embeddings-connectors <string>` | Путь к «коннекторам эмбеддингов» для LTXAV. |
| `--vae <string>` | Путь к отдельной модели VAE (декодер/энкодер, переводящий между «латентным» пространством и пикселями). |
| `--vae-format <string>` | Принудительный формат латентного пространства VAE: `auto`, `flux`, `sd3` или `flux2`. |
| `--audio-vae <string>` | Путь к отдельной VAE-модели для аудио (LTX). |
| `--taesd <string>` | Путь к TAESD (Tiny AutoEncoder) — быстрый, но менее качественный декодер вместо полноценного VAE. |
| `--tae <string>` | Алиас для `--taesd`. |
| `--control-net <string>` | Путь к модели ControlNet (управление композицией по позе, глубине, краям и т.п.). |
| `--motion-module <string>` | Модуль AnimateDiff (для SD 1.5) — включает генерацию видео при `--video-frames > 1`. |
| `--embd-dir <string>` | Директория с текстовыми эмбеддингами (textual inversion). |
| `--lora-model-dir <string>` | Директория с LoRA-моделями. |
| `--hires-upscalers-dir <string>` | Директория с моделями-апскейлерами для highres fix (повышения разрешения). |
| `--tensor-type-rules <string>` | Задаёт тип весов (квантование) для тензоров по шаблону имени, например: `"^vae\.=f16,model\.=q8_0"` — VAE в f16, остальное в q8_0. |
| `--model-args <string>` | Дополнительные аргументы модели в формате `ключ=значение`: `chroma_use_dit_mask`, `chroma_use_t5_mask`, `chroma_t5_mask_pad`, `qwen_image_zero_cond_t`. |
| `--photo-maker <string>` | Путь к модели PhotoMaker (перенос личности человека по фото в генерацию). |
| `--pulid-weights <string>` | Путь к весам PuLID Flux (ещё один метод сохранения идентичности лица). |
| `--upscale-model <string>` | Путь к модели ESRGAN для увеличения разрешения. |
### Распределение по устройствам и производительность
| Флаг | Пояснение |
|---|---|
| `--backend <string>` | Назначение вычислительного backend'а: например `cpu` целиком, либо по модулям `clip=cpu,vae=cuda0,diffusion=vulkan0`. |
| `--params-backend <string>` | Где хранить параметры (веса): `disk`, `cpu` или по модулям, например `diffusion=disk,clip=cpu`. |
| `--split-mode <string>` | Как делить веса модуля между несколькими устройствами (когда `--backend "diffusion=cuda0&cuda1"`): <br>• `layer` — целые блоки трансформера на разные устройства (по умолчанию); <br>• `row` — строки матриц умножения делятся между устройствами (только CUDA). <br>Можно задать один режим на всё или по модулям: `row` или `diffusion=row,te=layer`. |
| `--rpc-servers <string>` | Список RPC-серверов через запятую для выгрузки вычислений на другие машины, формат `host:port`, например `localhost:50052,192.168.1.3:50052`. |
| `--max-vram <string>` | Лимит видеопамяти (в ГиБ) для «нарезки» графа вычислений по сегментам. Можно указать одно значение или по устройствам: `6` или `cuda0=6,vulkan0=4`. `0` — отключить нарезку; отрицательное значение — автоопределение свободной памяти с указанным запасом. |
| `-t, --threads <int>` | Число потоков CPU (по умолчанию `-1` — автоматически равно числу физических ядер). |
| `--stream-layers` | Включает потоковую подгрузку слоёв (residency+prefetch) поверх `--max-vram`. Без `--max-vram` не действует (по умолчанию выключено). |
| `--eager-load` | Загружать все параметры в память backend'а сразу при загрузке модели, а не лениво при первом использовании (по умолчанию выключено). |
| `--auto-fit` | Автоматически подобрать распределение diffusion/te/vae по устройствам исходя из размера модели и памяти (`--max-vram`). Переопределяет `--backend` и `--params-backend`; может «размазать» модули между несколькими GPU (`--split-mode` по-прежнему выбирает способ — layer или row). |
| `--force-sdxl-vae-conv-scale` | Принудительно использовать conv scale для VAE в SDXL. |
| `--offload-to-cpu` | Держать веса в оперативной памяти (не в VRAM) и подгружать их в видеопамять по мере необходимости — экономия VRAM ценой скорости. |
| `--mmap` | Использовать memory-map (mmap) для загрузки модели вместо полного чтения в память. |
| `--control-net-cpu` | **Устарело** — используйте `--backend controlnet=cpu`. |
| `--clip-on-cpu` | **Устарело** — используйте `--backend te=cpu` (текстовый энкодер на CPU). |
| `--vae-on-cpu` | **Устарело** — используйте `--backend vae=cpu`. |
| `--fa` | Использовать Flash Attention (ускоренная реализация механизма внимания, экономит память и время). |
| `--diffusion-fa` | Flash Attention только в диффузионной модели. |
| `--diffusion-conv-direct` | Использовать `ggml_conv2d_direct` (прямую свёртку) в диффузионной модели. |
| `--vae-conv-direct` | То же самое, но для VAE. |
| `--type` | Тип весов (квантование): `f32`, `f16`, `q4_0`, `q4_1`, `q5_0`, `q5_1`, `q8_0`, `q2_K`, `q3_K`, `q4_K` и т.д. Если не указано — берётся тип из файла весов. |
| `--rng` | Генератор случайных чисел: `std_default`, `cuda` или `cpu`. По умолчанию `cuda` (как в sd-webui) или `cpu` (как в ComfyUI). Влияет на воспроизводимость результатов между разными UI. |
| `--sampler-rng` | Отдельный RNG для семплера. Если не указан — берётся из `--rng`. |
| `--prediction` | Переопределение типа предсказания модели: `eps`, `v`, `edm_v`, `sd3_flow`, `flux_flow`, `sefi_flow`. |
| `--lora-apply-mode` | Способ применения LoRA: `auto` (по умолчанию), `immediately`, `at_runtime`. <br>• В `auto` для квантованных моделей используется `at_runtime`, иначе `immediately`. <br>• `immediately` быстрее и экономнее по памяти, но может терять точность на квантованных весах. <br>• `at_runtime` — наоборот, точнее, но медленнее/затратнее. |
| `--list-devices` | Вывести список доступных backend-устройств ggml (по одному `имя<TAB>описание` на строку) и выйти. Эти имена используются в `--backend` и `--params-backend`. |
---
## 3. Опции генерации по умолчанию (Default Generation Options)
Параметры самого процесса генерации изображения/видео (аналог настроек в sd-webui/ComfyUI).
### Промпт и входные файлы
| Флаг | Пояснение |
|---|---|
| `-p, --prompt <string>` | Текст запроса (промпт) для генерации. |
| `-n, --negative-prompt <string>` | Негативный промпт — что модель должна избегать (по умолчанию пусто). |
| `--ad-model <string>` | Путь к модели детекции YOLOv8 для ADetailer (автоматическое обнаружение и доработка лиц/деталей). |
| `--ad-prompt <string>` | Промпт для ADetailer; если пусто — используется основной промпт. Поддерживает плейсхолдеры `[PROMPT]`, `[SEP]`, `[SKIP]`. |
| `--ad-negative-prompt <string>` | Негативный промпт для ADetailer. |
| `--extra-ad-args <string>` | Доп. параметры ADetailer в формате `ключ=значение`: размер входа, порог уверенности, NMS, макс. число детекций, параметры маски (отступы, режим, размытие), сила денойзинга, шаги, cfg_scale, метод семплинга, планировщик, сортировка. |
| `-i, --init-img <string>` | Путь к исходному изображению (для img2img). |
| `--end-img <string>` | Путь к конечному изображению — нужен для режима flf2v (first-last-frame-to-video: генерация видео между двумя кадрами). |
| `--mask <string>` | Путь к изображению-маске (для inpainting — «дорисовки» части изображения). |
| `--control-image <string>` | Управляющее изображение для ControlNet. |
| `--control-video <string>` | Путь к директории с кадрами управляющего видео для ControlNet. Кадры должны идти в алфавитном порядке (00.png, 01.png…). |
| `--pm-id-images-dir <string>` | Директория с фото-референсами личности для PhotoMaker. |
| `--pm-id-embed-path <string>` | Путь к эмбеддингу личности PhotoMaker v2. |
| `--pulid-id-embedding <string>` | Путь к эмбеддингу личности PuLID. |
| `--prompt-file <string>` | Путь к файлу, содержащему промпт (вместо `-p`). |
| `--negative-prompt-file <string>` | Путь к файлу с негативным промптом. |
### Разрешение, шаги, размер батча
| Флаг | Пояснение |
|---|---|
| `-H, --height <int>` | Высота изображения в пикселях (по умолчанию `512`). |
| `-W, --width <int>` | Ширина изображения (по умолчанию `512`). |
| `--steps <int>` | Число шагов сэмплирования (по умолчанию `20`). |
| `--high-noise-steps <int>` | Число шагов на «фазе высокого шума» (по умолчанию `-1` — авто). |
| `--clip-skip <int>` | Сколько последних слоёв CLIP игнорировать. `1` — не пропускать ничего, `2` — пропустить один слой. По умолчанию `-1` (не задано; автоматически `1` для SD1.x, `2` для SD2.x). |
| `-b, --batch-count <int>` | Количество изображений в батче за один запуск. |
| `--qwen-image-layers <int>` | Число «слоёв» для Qwen Image Layered; итоговое число латентов/выходов = слои + 1. |
| `--video-frames <int>` | Число кадров видео (по умолчанию `1`, т.е. обычное изображение). |
| `--fps <int>` | Частота кадров видео (по умолчанию `24`). |
| `--timestep-shift <int>` | Сдвиг временного шага для моделей NitroFusion (по умолчанию `0`). Рекомендуется ~250 для NitroSD-Realism и ~500 для NitroSD-Vibrant. |
### Upscale и Highres fix (повышение разрешения)
| Флаг | Пояснение |
|---|---|
| `--upscale-repeats <int>` | Сколько раз повторно прогонять ESRGAN-апскейлер (по умолчанию `1`). |
| `--upscale-tile-size <int>` | Размер тайла для апскейлинга ESRGAN (по умолчанию `128`). |
| `--hires-width <int>` | Целевая ширина при highres fix; `0` — использовать `--hires-scale`. |
| `--hires-height <int>` | Целевая высота при highres fix; `0` — использовать `--hires-scale`. |
| `--hires-steps <int>` | Число шагов второго прохода highres fix; `0` — использовать `--steps`. |
| `--hires-upscale-tile-size <int>` | Размер тайла апскейлера в highres fix (для апскейлеров на основе моделей). |
| `--hires-upscaler <string>` | Алгоритм апскейлинга для highres fix: `Lanczos`, `Nearest`, `Latent` и варианты (`Latent (nearest)`, `Latent (bicubic)` и т.д.), либо имя модели из `--hires-upscalers-dir`. |
| `--hires-scale <float>` | Коэффициент увеличения для highres fix, если целевой размер не задан (по умолчанию `2.0`). |
| `--hires-denoising-strength <float>` | Сила денойзинга на втором проходе highres fix (по умолчанию `0.7`). |
| `--hires-sigmas <string>` | Пользовательские значения sigma для второго прохода highres fix, через запятую. |
| `--hires` | Включить highres fix (сначала генерация в низком разрешении, затем апскейл и доработка деталей). |
> **Highres fix** — техника «сначала сгенерировать в маленьком разрешении, потом увеличить и доработать», которая часто даёт лучше результат, чем сразу генерировать в высоком разрешении.
### CFG, guidance и родственные параметры
| Флаг | Пояснение |
|---|---|
| `--cfg-scale <float>` | Масштаб classifier-free guidance — насколько строго следовать промпту (по умолчанию `7.0`). |
| `--img-cfg-scale <float>` | Отдельный guidance-масштаб для изображений в моделях inpaint/edit (по умолчанию = `--cfg-scale`). |
| `--guidance <float>` | Дистиллированный guidance-масштаб для моделей со встроенным guidance-входом, например Flux (по умолчанию `3.5`). |
| `--slg-scale <float>` | Масштаб Skip Layer Guidance (SLG) — техника для DiT-моделей (по умолчанию `0`, выключено; `2.5` хорошо подходит для SD3.5 medium). |
| `--skip-layer-start <float>` | Точка (доля прогресса) включения SLG (по умолчанию `0.01`). |
| `--skip-layer-end <float>` | Точка отключения SLG (по умолчанию `0.2`). |
| `--skip-layers <string>` | Номера слоёв, пропускаемых на шагах SLG (по умолчанию `[7,8,9]`). |
| `--eta <float>` | Множитель шума в семплере (по умолчанию зависит от метода: `0` для ddim_trailing/tcd/res_multistep/res_2s, `1` для euler_a/er_sde/dpm++2s_a и др.). |
| `--flow-shift <float>` | Сдвиг для flow-моделей (SD3.x, WAN) — по умолчанию подбирается автоматически. |
| «high-noise»-версии | Все параметры выше (`cfg-scale`, `img-cfg-scale`, `guidance`, `slg-scale`, `skip-layer-start/end`, `skip-layers`, `eta`) продублированы с префиксом `--high-noise-*` — это те же настройки, но для «фазы высокого шума» в MoE-моделях типа Wan2.2. |
| `--moe-boundary <float>` | Граница временного шага, разделяющая фазы для Wan2.2 MoE (по умолчанию `0.875`). Работает, только если `--high-noise-steps` установлен в `-1` (авто). |
### Сила воздействия (strength) и специфичные модели
| Флаг | Пояснение |
|---|---|
| `--strength <float>` | Сила «зашумления/расшумления» — насколько сильно изменять исходное изображение в img2img (по умолчанию `0.75`). |
| `--pm-style-strength <float>` | Сила стиля для PhotoMaker. |
| `--pulid-id-weight <float>` | Вес (сила) применения идентичности PuLID. |
| `--control-strength <float>` | Сила применения ControlNet (по умолчанию `0.9`). `1.0` — полное «уничтожение» информации исходного изображения в пользу управляющего сигнала. |
| `--vace-strength <float>` | Сила VACE (Wan) — модуля управления видео. |
| `-r, --ref-image <string>` | Референсное изображение для моделей типа Flux Kontext (можно указывать несколько раз). |
| `--increase-ref-index` | Автоматически увеличивать индексы референсных изображений в порядке их перечисления (начиная с 1). |
| `--disable-auto-resize-ref-image` | Отключить автоматическое изменение размера референсных изображений. |
| `--ref-image-args <string>` | Ключ-значение параметры обработки референсных изображений (по умолчанию — автоопределение по весам модели). |
### VAE и тайлинг (обработка по частям)
| Флаг | Пояснение |
|---|---|
| `--vae-tiling` | Обрабатывать VAE по тайлам (частям изображения) — снижает потребление памяти на больших разрешениях. |
| `--vae-tile-size <string>` | Размер тайла для VAE, формат `[X]x[Y]` (по умолчанию `32x32`). |
| `--vae-relative-tile-size <string>` | Относительный размер тайла VAE (доля от размера изображения, если < 1, либо число тайлов на измерение, если ≥ 1). Переопределяет `--vae-tile-size`. |
| `--vae-tile-overlap <float>` | Перекрытие тайлов при VAE-тайлинге, доля от размера тайла (по умолчанию `0.5`). |
| `--temporal-tiling` | Включить временной тайлинг при декодировании видео-VAE LTX (по кадрам, а не только по пространству). |
| `--extra-tiling-args <string>` | Доп. параметры тайлинга VAE. Для LTX video VAE: `temporal_tile_frames` (по умолчанию `4`), `temporal_tile_overlap` (по умолчанию `1`). |
### Семплер, планировщик, кэширование
| Флаг | Пояснение |
|---|---|
| `--sampling-method <string>` | Метод сэмплирования: `euler`, `euler_a`, `heun`, `dpm2`, `dpm++2s_a`, `dpm++2m`, `dpm++2mv2`, `dpm++2m_sde`, `dpm++2m_sde_bt`, `ipndm`, `ipndm_v`, `lcm`, `ddim_trailing`, `tcd`, `res_multistep`, `res_2s`, `er_sde`, `euler_cfg_pp`, `euler_a_cfg_pp`. По умолчанию `euler` для Flux/SD3/Wan, иначе `euler_a`. |
| `--high-noise-sampling-method <string>` | Тот же выбор метода, но для фазы высокого шума. |
| `--scheduler <string>` | Планировщик сигм шума (denoiser sigma scheduler): `discrete`, `karras`, `exponential`, `ays`, `gits`, `smoothstep`, `sgm_uniform`, `simple`, `kl_optimal`, `lcm`, `bong_tangent`, `ltx2`, `logit_normal`, `flux2`, `flux`, `beta` (алиас: `normal` = `discrete`). По умолчанию зависит от модели. |
| `--sigmas <string>` | Пользовательские значения sigma для семплера через запятую, например: `"14.61,7.8,3.5,0.0"`. |
| `--extra-sample-args <string>` | Доп. параметры семплера/планировщика/guidance в формате `ключ=значение`: <br>• CFG: `guidance_schedule`; <br>• APG: `apg_eta`, `apg_momentum`, `apg_norm_threshold`, `apg_norm_threshold_smoothing`; <br>• SLG: `slg_uncond`; <br>• lcm: `noise_clip_std`, `noise_scale_start`, `noise_scale_end`; <br>• flux: `base_shift`, `max_shift`; <br>• ltx2: `max_shift`, `base_shift`, `stretch`, `terminal`; <br>• euler_ge: `gamma`; <br>• logit_normal: `mu`, `std`, `logsnr_min`, `logsnr_max`, `resolution_aware`. |
| `--cache-mode <string>` | Метод кэширования вычислений (ускоряет генерацию за счёт переиспользования промежуточных результатов): `easycache` (DiT), `ucache` (UNET), `dbcache`/`taylorseer`/`cache-dit` (кэш на уровне блоков DiT), `spectrum` (прогнозирование Чебышева+Тейлора для UNET/DiT). |
| `--cache-option <string>` | Именованные параметры кэша, формат `ключ=значение` через запятую. Для easycache/ucache: `threshold=`, `start=`, `end=`, `decay=`, `relative=`, `reset=`. Для dbcache/taylorseer/cache-dit: `Fn=`, `Bn=`, `threshold=`, `warmup=`. Для spectrum: `w=`, `m=`, `lam=`, `window=`, `flex=`, `warmup=`, `stop=`. Пример: `"threshold=0.25"`. |
| `--scm-mask <string>` | Маска шагов SCM для cache-dit: последовательность 0/1 через запятую (например `"1,1,1,0,0,1,0,0,1,0"`) — `1` означает «вычислить заново», `0` — «можно взять из кэша». |
| `--scm-policy <string>` | Политика SCM: `dynamic` (по умолчанию) или `static`. |
### Прочие визуальные эффекты и вывод
| Флаг | Пояснение |
|---|---|
| `--circular` | Включить круговой (тайловый) паддинг по обеим осям — для получения бесшовно повторяющихся текстур. |
| `--circularx` | Круговой паддинг только по оси X (ширина). |
| `--circulary` | Круговой паддинг только по оси Y (высота). |
| `--disable-image-metadata` | Не встраивать метаданные генерации (промпт, параметры) в файл изображения. |
| `-s, --seed <int>` | Зерно генератора случайных чисел (по умолчанию `42`; отрицательное значение — случайный seed). |
---
## Пояснения к некоторым понятиям (для контекста)
- **VAE (Variational AutoEncoder)** — модель, переводящая изображение между «пиксельным» и «латентным» (сжатым) представлением, в котором и работает диффузия.
- **ControlNet** — дополнительная сеть, позволяющая управлять композицией по позе, глубине, контурам и т.п. с помощью управляющего изображения.
- **LoRA (Low-Rank Adaptation)** — компактный способ дообучения модели под конкретный стиль/персонажа без изменения всех весов.
- **CFG (Classifier-Free Guidance)** — механизм, усиливающий влияние текстового промпта на результат.
- **SLG (Skip Layer Guidance)** — техника для DiT-архитектур, улучшающая качество за счёт временного «отключения» части слоёв.
- **Highres fix** — генерация сначала в низком разрешении с последующим апскейлом и доработкой деталей.
- **ADetailer** — автоматическое обнаружение (например, лиц) и их последующая доработка отдельным проходом генерации.
- **PhotoMaker / PuLID** — методы переноса личности человека (по фотографиям) в генерируемое изображение.
- **Flash Attention** — оптимизированная реализация механизма внимания, ускоряющая работу и снижающая расход памяти.
- **Квантование весов** (`q4_0`, `q8_0` и т.д.) — сжатие весов модели для экономии памяти ценой небольшой потери точности.
- **MoE (Mixture of Experts) / high-noise фаза** — в некоторых моделях (например, Wan2.2) для разных этапов шумоподавления используются разные «эксперты»-подмодели.


