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:

Ключевым архитектурным отличием 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;75;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-генерации при использовании подходящих моделей и энкодера, особенно после тонкой настройки параметров запуска.