Как установить ComfyUI на сервер и собрать первый workflow

ComfyUI решает задачу, с которой обычные веб-интерфейсы не справляются. Нужный кадр зависит от сида, LoRA и маски, а собрать ту же цепочку заново в форме с полями удаётся не всегда: каждый запуск получается немного другим. В ComfyUI эта цепочка лежит в JSON, её можно сохранить, отдать коллеге и отправить в API. Ниже установка на Linux-сервер, первый workflow и граница, за которой сервер уже не нужен.

Что такое ComfyUI и чем он отличается от обычных веб-интерфейсов

ComfyUI это нодовый интерфейс для диффузионных моделей. Каждая нода делает одну операцию. Одна грузит чекпойнт, другая кодирует промпт, третья считает латент, четвёртая декодирует результат. Связи между нодами передают тензоры, а весь граф целиком это и есть workflow.

От обычного веб-интерфейса он отличается тем, что не предлагает готовую форму с полями. Форму вы собираете сами, и она остаётся в виде JSON. Один и тот же граф запускается из браузера и из скрипта. Граф можно версионировать в git и сравнивать диффом. ComfyUI пересчитывает только изменившуюся часть графа, поэтому правка последней ноды не тянет за собой весь пайплайн.

Разобраться с нуля мешает пустое поле вместо формы. Человек, привыкший к полям «промпт», «шаги», «сид», первые полчаса смотрит на него. Выручает браузер шаблонов, о нём ниже.

Проект под GPL-3.0, последний релиз на 20 октября 2026 это 0.42.1, у репозитория около 140 тысяч звёзд. Лицензию надо учитывать при встраивании движка в закрытый продукт.

Что нужно по железу и почему видеопамять важнее процессора

ComfyUI работает на NVIDIA, AMD, Intel, Apple Silicon и на чистом CPU, и это одна из причин, почему его берут вместо привязанных к одной платформе альтернатив.

VRAM это видеопамять видеокарты, отдельная память, куда загружаются веса модели и промежуточные тензоры.

Видеопамять важнее процессора, потому что сэмплирование это матричные операции на видеокарте. Процессор в этот момент почти не участвует, он кормит карту данными и обслуживает очередь. Слабая карта с большим объёмом памяти кадр посчитает, мощная карта с малым объёмом упрётся в нехватку места.

Разработчики заявляют, что движок запускает самые большие открытые модели на 4 ГБ VRAM и 8 ГБ оперативной памяти за счёт асинхронной подгрузки весов. Если файл модели больше видеопамяти, часть весов живёт в RAM и подгружается по ходу шага. Про удобство эта цифра не говорит ничего.

Размеры файлов такие. v1-5-pruned-emaonly.safetensors весит 4,27 ГБ, его fp16-вариант 2,13 ГБ. sd_xl_base_1.0.safetensors весит 6,94 ГБ. flux1-dev.safetensors весит 23,8 ГБ, а fp8-чекпойнт 17,25 ГБ. Если файл не влезает в VRAM целиком, часть весов ходит через RAM, а падение скорости зависит от графа и оборудования и может быть кратным.

Для FLUX документация прямо оговаривает, что t5xxl_fp16 рекомендуется при VRAM больше 32 ГБ, иначе берут fp8-вариант.

К весам добавляются латенты, декодирование и буферы, поэтому памяти нужно больше, чем весит файл. Для SDXL на практике берут карту от 8 ГБ, для квантованного FLUX от 12 ГБ, для FLUX в bf16 от 24 ГБ, уже с офлоадом текстового энкодера. Пик зависит от разрешения и размера батча, а для видео запас нужен больше.

RAM подбирают под модель и офлоад. Минимум равен VRAM, при активном офлоаде нужен запас сверху. Если своей карты нет, варианты аренды разобраны в статье про нейросети и аренду GPU.

Установка ComfyUI на Linux-сервер

Ставится он в отдельное окружение, потому что зависимости конфликтуют с системным Python. Документация предлагает conda, но venv даёт тот же результат и не тянет второй менеджер пакетов.

Python 3.13 поддерживается хорошо и рекомендуется. 3.12 годится как запасной вариант, если ноды капризничают. 3.14 работает, но часть кастомных нод может сломаться.

Последовательность команд для NVIDIA:

sudo useradd -r -s /usr/sbin/nologin comfy
sudo git clone https://github.com/Comfy-Org/ComfyUI.git /opt/ComfyUI
cd /opt/ComfyUI
sudo git checkout v0.42.1
sudo chown -R comfy:comfy /opt/ComfyUI
sudo -u comfy python3.13 -m venv venv
sudo -u comfy /opt/ComfyUI/venv/bin/pip install torch torchvision torchaudio --extra-index-url https://download.pytorch.org/whl/cu130
sudo -u comfy /opt/ComfyUI/venv/bin/pip install -r requirements.txt
sudo -u comfy /opt/ComfyUI/venv/bin/python main.py --listen 127.0.0.1 --port 8188

На картах 20-й серии и новее README требует PyTorch с CUDA 13.0 и выше, поэтому ставится сборка cu130. Если после установки появляется ошибка Torch not compiled with CUDA enabled, значит подтянулась CPU-версия: удалите пакеты командой sudo -u comfy /opt/ComfyUI/venv/bin/pip uninstall -y torch torchvision torchaudio, поставьте сборку с нужного индекса и проверьте python -c "import torch; print(torch.cuda.is_available())".

Для AMD на Linux команда другая, с индексом rocm7.2. Для Intel команда установки своя, она разобрана в README. Смешивать их в одном окружении не надо.

Сервис лучше завести в systemd, иначе после перезагрузки он не поднимется. Юнит кладётся в /etc/systemd/system/comfyui.service, после чего выполняются sudo systemctl daemon-reload, sudo systemctl enable --now comfyui и проверка sudo systemctl status comfyui.

[Unit]
Description=ComfyUI
After=network-online.target

[Service]
Type=simple
User=comfy
WorkingDirectory=/opt/ComfyUI
ExecStart=/opt/ComfyUI/venv/bin/python main.py --listen 127.0.0.1 --port 8188
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Флаг --listen 127.0.0.1 в юните оставлен намеренно. Пока внешний доступ не нужен, сервис не должен торчать в сеть.

Установка на Windows портативной сборкой

Портативная сборка это архив с встроенным Python, распаковал и запустил. Качать нужно вариант под свою карту. Сборка nvidia поддерживает 20-ю серию и новее, для 10-й серии и старше есть архив с cu126. Внутри уже лежат Python 3.13 и PyTorch с CUDA 13.0, поэтому первым делом обновите драйвер NVIDIA, иначе запуск упрётся в несовместимость.

Запускается это батником run_nvidia_gpu.bat, флаги при необходимости добавляются прямо в него. Модели кладутся в ComfyUI\models\checkpoints.

Для обычного пользователя разработчики советуют десктопное приложение. Оно ставится на Windows, macOS и Linux и обновляется само, а портативная сборка нужна для последних коммитов и жизни в одной папке.

Куда класть модели и как устроены каталоги

Каталог models разбит по типам, потому что ноды ищут файлы именно по этим папкам. checkpoints для однофайловых чекпойнтов, diffusion_models для отдельных UNet и DiT, text_encoders для CLIP и T5, vae для VAE, loras для LoRA, controlnet для ControlNet, vae_approx для TAESD, upscale_models для апскейлеров, embeddings для textual inversion.

Исторические имена работают как алиасы. unet указывает на diffusion_models, clip на text_encoders, поэтому старые инструкции не ломаются. Полный список отдаёт сам сервер по GET /models, и это удобнее, чем сверяться с документацией.

Однофайловая модель это не универсальный случай. У FLUX отдельно лежат трансформер, текстовый энкодер и VAE, и грузятся они тремя разными нодами. Если положить всё в checkpoints, часть нод файл просто не увидит.

Когда моделей много и они нужны нескольким инстансам, помогает extra_model_paths.yaml. Файл кладётся в корень ComfyUI, в нём описываются базовый путь и подкаталоги по типам, после перезапуска сервер видит их наравне со своими.

Первый workflow по шагам

На сервере без графики интерфейс открывают через SSH-туннель: ssh -L 8188:127.0.0.1:8188 user@server. Пока соединение активно, http://127.0.0.1:8188 открывается в браузере на рабочей машине.

После запуска интерфейс открывается на http://127.0.0.1:8188. В свежей сборке по умолчанию подставляется граф на Z-Image Turbo, и он показывает общую схему. Модель грузится тремя нодами UNETLoader, CLIPLoader, VAELoader. Два CLIPTextEncode дают положительный и отрицательный промпт, EmptySD3LatentImage задаёт размер, KSampler считает, VAEDecode переводит латент в картинку, SaveImage пишет файл.

С нуля такой граф собирать не нужно. В интерфейсе есть браузер шаблонов, пакет comfyui-workflow-templates ставится вместе с зависимостями, и оттуда берётся готовый workflow под нужную модель.

Открываете шаблон, смотрите, какие файлы он просит, кладёте их в соответствующие папки, обновляете страницу и выбираете модель в выпадающем списке лоадера. Дальше правите промпт в верхней ноде CLIPTextEncode, выставляете размер и жмёте Ctrl+Enter.

Прогресс виден на ноде KSampler, готовый файл появляется в output. Если в списке моделей пусто, дело почти всегда в папке или в том, что страницу не обновили после копирования файла.

Доступ снаружи через порт и Nginx Proxy Manager

Сервер слушает 127.0.0.1:8188, то есть с другой машины его не видно. Это разумный режим, и его лучше сохранить, пока доступ не нужен.

Для доступа по сети есть флаг --listen. Без аргумента он раскрывает сервис на 0.0.0.0 и ::, с аргументом слушает конкретный адрес. Порт меняется флагом --port.

Снаружи обычно ставят Nginx Proxy Manager. Он принимает запрос на 443, держит сертификат Let’s Encrypt и передаёт трафик на 127.0.0.1:8188. Если NPM работает в bridge-сети Docker, 127.0.0.1 внутри контейнера указывает на сам контейнер: тогда в upstream нужен адрес хоста, а ComfyUI должен слушать доступный интерфейс. В настройках хоста нужно включить Websockets Support, иначе интерфейс отвалится при первом же обновлении прогресса, потому что живой статус идёт через /ws. Устройство Nginx Proxy Manager разобрано в отдельном гайде.

Своей авторизации для доступа у ComfyUI нет. Её добавляет Access List в Nginx Proxy Manager, это обычная HTTP Basic-аутентификация с логином и паролем. Для личного доступа этого достаточно, но порт 8188 должен быть закрыт снаружи; для общего сервиса нужны отдельные учётные записи и ограничения нагрузки.

Риск здесь конкретный. Если выставить --listen 0.0.0.0 на машину с публичным адресом без фронта и пароля, через порт можно будет и посмотреть ваши модели, и запустить генерацию, и прочитать историю. Флаг --enable-cors-header без значения разрешает запросы с любого origin, и на открытом порту это тоже лишний риск.

Свой TLS у сервера есть, флаги --tls-keyfile и --tls-certfile включают HTTPS с указанными ключом и сертификатом; для самоподписанного нужно настроить доверие на клиентах. Для публичного домена он не годится, но внутри сети закрывает трафик.

API и автоматизация

Встроенный API это тот же сервер, который обслуживает интерфейс. Отдельно включать ничего не нужно, эндпоинты живут на том же порту.

Формат запроса важнее самих эндпоинтов. POST /prompt принимает JSON вида {"prompt": {...}, "client_id": "..."}, где prompt это словарь, ключ это id ноды, а значение содержит class_type и inputs. Связь между нодами записывается парой [id_ноды, номер_выхода].

Такой JSON не совпадает с тем, что сохраняет кнопка Save. Сохранённый workflow это граф с массивами nodes и links, он нужен интерфейсу, и сервер его не примет. Для API в меню нужен пункт экспорта: по умолчанию он скрыт, поэтому сначала включите Enable Dev mode Options в настройках. После этого меню даст граф в структуре API.

Цикл короткий. POST /prompt возвращает prompt_id, number и node_errors. По GET /history/{prompt_id} забирается результат, в outputs лежит список файлов с полями filename, subfolder, type. Сам файл отдаётся по GET /view с этими тремя параметрами.

Проверка на локальной CPU-сборке, без видеокарты, выглядит так. Граф из двух нод EmptyImage и SaveImage ушёл на /prompt и вернул prompt_id, через секунду в истории появился статус success, а PNG скачался по /view. Ответ 200, файл 64 на 64 пикселя, 376 байт. Для проверки обвязки этого достаточно, модель такому тесту не нужна.

Статус очереди отдаёт GET /queue, текущую задачу прерывает POST /interrupt, список нод с их входами лежит в GET /object_info, а сведения о железе и версии в GET /system_stats. Прогресс удобнее слушать через WebSocket /ws, сообщения приходят типами executing и progress. В истории результаты сгруппированы по ID выходных нод: у SaveImage файлы лежат в outputs[node_id].images.

Ограничение тут архитектурное. В стандартной конфигурации один процесс последовательно выполняет задания очереди на выбранном устройстве, и если два скрипта одновременно закинут тяжёлые графы, они встанут друг за другом. Для потока задач нужен свой диспетчер с таймаутами и повторными попытками.

Менеджер нод и обновление

Кастомные ноды ставятся в custom_nodes, но вручную их ставить и обновлять быстро надоедает. ComfyUI-Manager это расширение, которое ставит, удаляет, отключает и включает ноды из интерфейса.

В текущей схеме установка выглядит так. pip install -r manager_requirements.txt, затем запуск с флагом --enable-manager. Флаг --disable-manager-ui оставляет фоновые задачи и убирает интерфейс; границей безопасности он не является.

Кастомная нода это Python-код, который выполняется с правами процесса ComfyUI, и песочницы там нет. Ставить что попало из случайного репозитория на сервер с доступом в интернет рискованно.

Обновление самого ComfyUI это git pull и повторный pip install -r requirements.txt. Релизы выходят тегами почти каждую неделю, а коммиты вне тегов могут быть нестабильными и ломать кастомные ноды. Для рабочего сервера обновление по тегу спокойнее, чем по master.

PyTorch тоже лучше держать свежим. README прямо говорит, что сборка старше полугода это повод обновиться, иначе часть оптимизаций просто не включится.

Бэкап и перенос

Переносить нужно не всё. Код и виртуальное окружение восстанавливаются из репозитория и requirements.txt, а вот модели, кастомные ноды и настройки придётся сохранить.

Переносить нужно каталог models целиком или список файлов с версиями, custom_nodes без виртуальных окружений внутри, каталог user с настройками и историей, extra_model_paths.yaml если он есть, и output если результаты нужны. Версию ComfyUI стоит зафиксировать тегом, иначе после восстановления получится другая сборка.

Модели занимают много места. Один FLUX это 23,8 ГБ, а набор из пяти моделей легко переваливает за 100 ГБ. Гонять такое в обычный бэкап дорого, поэтому практичнее хранить список имён и скрипт, который их скачивает, а сами веса считать восстановимыми.

Ставите ту же версию, копируете models и custom_nodes, возвращаете user и файл путей, запускаете и проверяете, что шаблон из первого раза открывается без красных нод.

Когда сервер не нужен

Сервер не нужен, если генерация идёт с одной машины, вы работаете за ней же и никакой другой сервис не просит картинки по API. В этом случае десктопное приложение или портативная сборка закрывают задачу полностью, а выделенная машина добавляет только обслуживание.

Сервер начинает быть полезным, когда появляется очередь. Например, ночью считается пачка кадров, днём к той же карте обращается скрипт, а вечером вы сами садитесь за интерфейс. Другой сценарий это доступ из сети, когда карта одна, а рабочие места разные.

Ещё один повод это слабый ноутбук. Если локальная машина не тянет модель, дешевле один раз собрать сервер с нормальной картой, чем каждый раз ждать.

Если вы делаете 10 картинок в день и вам хватает домашней карты, сервер не даст ничего, кроме ещё одного набора обновлений, который надо ставить. Разница начнётся на объёме. На первой же генерации её не будет. Похожая логика у текстовых моделей, она разобрана в статье про Ollama.

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

Нужна ли видеокарта NVIDIA

Нет. Поддерживаются AMD через ROCm, Intel через XPU, Apple Silicon через MPS и обычный CPU. Практическая разница в скорости и в том, что под NVIDIA инструкций и готовых сборок больше.

Сколько VRAM нужно минимум

По README запуск возможен на 4 ГБ VRAM и 8 ГБ RAM; речь о минимальном запуске, а не о комфортной работе. Для SDXL нужно от 8 ГБ, для FLUX от 12 ГБ с квантованием.

Есть ли официальный Docker-образ

Нет. Документация прямо говорит, что команда ComfyUI официальный образ не выпускает, а образы на Docker Hub поддерживают сообщества и не сопровождают. Если контейнер нужен, берите образ с активными коммитами и сами проверяйте, что внутри.

Почему появляется ошибка Torch not compiled with CUDA enabled

Потому что в окружение встала CPU-сборка PyTorch. Лечится переустановкой torch командой с --extra-index-url https://download.pytorch.org/whl/cu130.

Можно ли работать без интернета

Да. Флаг --offline запрещает фронтенду ходить в сеть и отключает платные партнёрские ноды. Кастомные ноды и менеджер могут обращаться к сети независимо от режима фронтенда, поэтому для полной изоляции ограничивают исходящий трафик средствами ОС или контейнера.

Где смотреть, какие ноды доступны

GET /object_info отдаёт все типы нод с их входами и выходами. По одной ноде работает GET /object_info/{node_class}.