Разработчик Deen-Media открыл публичный доступ к DGX Monarch: репозиторий подключает кластер из двух NVIDIA DGX Spark к ComfyUI и распределяет между устройствами генерацию изображений и видео. Заявленный эффект - почти двукратный рост скорости рендеринга, в формулировке автора "nearly 2x render speeds". Тут же идёт оговорка: результаты зависят от модели и настроек (анонс DGX Monarch).
Короткий ответ для тех, кто решает, читать ли дальше: инструмент рассчитан на владельцев пары DGX Spark, которые уже рендерят в ComfyUI. Поддержаны BF16, FP8, NVFP4, INT8 и другие форматы, причём список зависит от конкретной модели. GGUF не поддерживается вообще. Одна Spark, станция на RTX, Mac или арендованный облачный GPU - не тот случай.
Дальше разберём, откуда берётся заявленное ускорение, как замерить его на своём стенде без самообмана, какие форматы совместимы, как выглядит порядок запуска и где у проекта слабые места.
Что такое DGX Monarch и кому он нужен
DGX Monarch - открытый проект под генерацию в ComfyUI на кластере из двух NVIDIA DGX Spark. Автор описывает момент релиза прямо: если вы хотели задействовать свою пару Spark для генерации изображений и видео в ComfyUI, это ваш день. Путь до публикации занял месяцы: проект начался в апреле 2026 года как личный эксперимент и дорос до релиза, когда автор счёл результат достаточно стабильным.
Ключевая идея: два Spark вместо одного
Схема такая: одна DGX Spark обслуживает рендеринг сама, а DGX Monarch разводит ту же работу по двум узлам кластера. Вместо одного устройства в очереди на сэмплинг участвуют два, и суммарное время генерации падает почти вдвое по оценке автора.
Деталей реализации в анонсе нет: не раскрыто, какие именно этапы пайплайна делятся между узлами и как устроен обмен данными. Поэтому ожидания стоит привязывать к заявленной цифре "почти 2×", а не к гипотетическому идеальному удвоению.
Кластер из двух машин не превращается в одну удвоенную карту автоматически. Часть времени уходит на синхронизацию и пересылку данных между устройствами, и чем выше эта доля в конкретном воркфлоу, тем скромнее итоговый выигрыш. DGX Monarch решает задачу для конкретной конфигурации и не заменяет универсальный ускоритель для любого железа.
Кому проект не подойдёт
Отсечь себя можно по трём признакам:
- У вас одна DGX Spark или другое железо. Проект построен вокруг пары Spark, на одиночном устройстве заявленного эффекта не будет.
- Ваш пайплайн завязан на GGUF. Этот формат не поддерживается.
- Нужна сборка с поддержкой вендора и гарантиями. DGX Monarch - личный проект одного разработчика, а не корпоративный продукт.
Насколько реально ускорение: что стоит за «почти 2×»
Цифра "почти 2×" принадлежит автору и не подтверждена независимыми замерами. В том же анонсе он пишет, что результаты зависят от модели и настроек. Формулировка честная: двукратный прирост - верхняя планка для удачной комбинации, а не гарантия для любого воркфлоу.
От чего зависит прирост скорости
Факторы, которые стоит проверить на своём сценарии:
- Модель и её формат. Тяжёлые модели в BF16 и лёгкие квантованные варианты по-разному ложатся на два узла. Если модель почти не нагружает одну Spark, делить между машинами особо нечего.
- Настройки ComfyUI. Разрешение, число шагов, sampler, размер батча. Чем длиннее сэмплинг, тем выше доля времени, которую реально распараллелить.
- Тип задачи. Изображение - один проход по сравнительно короткой последовательности. Видео - длинная цепочка кадров, где накладные расходы между узлами накапливаются иначе. Выигрыш для видео и для картинок может отличаться заметно.
- Структура воркфлоу. Постобработка, апскейл, загрузка моделей и прочие шаги вне сэмплинга ускоряются от второго узла слабо.
- Связь между Spark. Пропускная способность и задержки обмена между устройствами определяют, сколько от заявленного ускорения вы получите на практике.
Разумная позиция такая: 2× - ориентир автора, ваша цифра будет своей. Проверить это можно за один вечер.
Как корректно измерить ускорение у себя
Методика ниже - рекомендация, а не результат наших тестов. Замеры вы делаете сами.
- Зафиксируйте параметры: модель, формат, seed, разрешение, число шагов, sampler и весь граф воркфлоу.
- Прогоните воркфлоу на одной Spark и замерьте полное время от запуска до готового файла, не только сэмплинг.
- Повторите тот же воркфлоу на двух Spark с теми же настройками.
- Сделайте минимум три прогона в каждом режиме и берите медиану. Первый прогон обычно включает прогрев и выбивается из ряда.
- Во время замеров не грузите кластер ничем другим.
- Отдельно запишите потребление памяти и время загрузки модели: на unified memory эти метрики часто важнее пиковой скорости.
Логика сравнения конфигураций на DGX Spark подробно разобрана в отдельном материале: чек-лист метрик и условий запуска для DeepSeek V4 Flash, Qwen3.8 Flash Next, Qwen3.8-27B и Qwen3.6-35B-A3B. Без фиксации контекста и параметров любые цифры сравнивать бессмысленно, и пиковые значения без условий запуска ничего не значат.
Поддерживаемые форматы и главное ограничение: нет GGUF
Список форматов: BF16, FP8, NVFP4, INT8 и другие, в зависимости от модели. Отдельно и жёстко оговорено, что GGUF не поддерживается (анонс проекта). Это ограничение определяет, подходит ли инструмент под вашу библиотеку моделей.
BF16, FP8, NVFP4, INT8: что выбрать
Все четыре формата - разные способы хранить веса, и выбор между ними определяется не вкусом, а тем, в каких вариантах существует нужная модель.
- BF16 - 16-битная плавающая точка. Максимальная точность из перечисленных, самый большой расход памяти.
- FP8 - 8-битная плавающая точка. Меньше памяти, чем BF16, при обычно умеренной потере качества.
- INT8 - 8-битные целые. Ещё один способ ужать модель примерно вдвое относительно 16 бит.
- NVFP4 - 4-битный формат NVIDIA. Самый экономный по памяти вариант из списка и самый чувствительный к тому, как модель подготовлена.
Универсальной рекомендации нет: совместимость привязана к конкретной модели, и точный перечень стоит смотреть в README и FAQ репозитория до того, как качать десятки гигабайт. Практическое правило простое: сначала посмотрите, в каких форматах опубликована ваша модель, затем берите самый лёгкий из поддерживаемых, если памяти впритык.
Насколько агрессивная квантизация бьёт по качеству, разбиралось на примере 2.45-битного GGUF против нативного FP8/FP4: сравнение на 2× DGX Spark и MacBook M5 Max. Вывод оттуда: на агентных задачах агрессивная квантизация оказалась ближе к нативному чекпоинту, чем принято думать, но это не отменяет проверки на вашей задаче.
Почему GGUF не поддерживается и что это значит на практике
GGUF - формат из мира llama.cpp. Его отсутствие в списке поддержки означает: популярные GGUF-сборки в DGX Monarch не загрузятся. Если ваша библиотека моделей собрана в GGUF, проект в текущем виде задачу не решит.
Вариантов два: взять модели в поддерживаемых форматах либо заняться конвертацией. Второй путь не гарантирован: перенос между форматами не всегда тривиален и не всегда даёт работоспособный результат, а поддержку GGUF автор не обещает. Планировать переход стоит только после чтения FAQ.
Как установить и запустить DGX Monarch
Автор задаёт порядок изучения документации явно: сначала README, следом FAQ, причём FAQ он рекомендует читать обязательно. Это не формальность: проект вырос из личного эксперимента, и часть ограничений описана именно там.
Конкретных команд установки в этой статье нет и быть не может: они меняются вместе с репозиторием. Общий алгоритм выглядит так.
- Прочитать README целиком.
- Прочитать FAQ. Без него легко наступить на известную проблему и потерять вечер.
- Проверить связность двух Spark между собой до запуска генерации, чтобы отделить проблемы сети от проблем модели.
- Взять пример воркфлоу из репозитория и прогнать лёгкий тестовый рендер.
- Переносить свои воркфлоу только после того, как пример работает стабильно.
README и FAQ: что читать в первую очередь
README даёт общую картину: что поддерживается, как устроен запуск, какие форматы ожидаются. FAQ закрывает типовые вопросы и ограничения. Обратный порядок обычно заканчивается тем, что человек собирает стенд и упирается в ограничение, о котором в FAQ написано прямым текстом.
Примеры ComfyUI-воркфлоу в репозитории
В репозиторий включены примеры воркфлоу для ComfyUI. Это ровно то, с чего стоит начинать: готовый маршрут для проверки, что кластер работает и модели загружаются. Личными AI-агентными рабочими процессами разработки автор не делится, но примеры воркфлоу для пользователей выложены.
Если вы ещё выбираете среду для генерации, полезно сравнить подходы заранее: разбор Gradio Workflow против ComfyUI и AUTOMATIC1111. DGX Monarch привязан именно к ComfyUI, так что переход на другую среду автоматически закрывает для вас этот инструмент.
Происхождение проекта: личный эксперимент и AI-агенты
DGX Monarch начался в апреле 2026 года как личный эксперимент и только сейчас дошёл до публичного релиза. Автор не скрывает, как он делался: AI-агенты использовались активно, а собственное время ушло на проверку результатов и производительности и на реальное использование проекта. Фактически человек взял на себя роль валидатора, а не автора каждой строки (анонс DGX Monarch).
Что это значит для пользователя
Два следствия. Первое: проект молодой и растёт быстро, поэтому в документации и на краевых сценариях возможны шероховатости, которые автор просто не встречал. Второе: заявленные цифры прошли проверку на стенде автора, но не на вашем железе и не на ваших моделях.
Отсюда практический вывод: сравнивать DGX Monarch с корпоративным продуктом с SLA некорректно, а для локальных экспериментов и личного рендеринга это рабочий вариант. Для критичных задач стоит заранее решить, что вы делаете, если обновление репозитория сломает пайплайн: стабильной ветки с гарантиями у такого проекта обычно нет.
Как внести вклад и не потратить время зря
Автор заранее говорит, что ждёт AI-сгенерированные пул-реквесты, и формулирует единственное требование: изменения нужно валидировать, отрендерить и протестировать, приложив результаты. Пул-реквест без подтверждения работоспособности рискует остаться без рассмотрения, а сроки рассмотрения автор не обещает.
Свои личные AI-агентные рабочие процессы разработки он не публикует, и просить их смысла нет. Примеры ComfyUI-воркфлоу в репозитории - другое дело, они предназначены пользователям.
Стоит ли использовать DGX Monarch: практический вывод
Кому подходит
- У вас есть кластер из двух NVIDIA DGX Spark.
- Вы рендерите в ComfyUI и хотите сократить время генерации.
- Ваши модели доступны в BF16, FP8, NVFP4 или INT8.
- Вы готовы читать README и FAQ и проверять заявленное ускорение на своих задачах.
Кому не подходит
- Нет двух DGX Spark: на одной машине или другом железе заявленный эффект не воспроизводится.
- Рабочий процесс держится на GGUF-моделях.
- Нужна поддержка вендора и предсказуемость уровня корпоративного продукта.
- Нет желания разбираться с документацией и валидировать результаты.
DGX Monarch - открытый проект Deen-Media, который подключает два NVIDIA DGX Spark к ComfyUI. Автор заявляет почти двукратный прирост скорости рендеринга и сразу оговаривает, что результат зависит от модели и настроек. Работают BF16, FP8, NVFP4, INT8 и другие форматы по модели, GGUF не работает. Проект вырос из личного эксперимента, начатого в апреле 2026 года, в разработке активно участвовали AI-агенты, а проверка результатов осталась за автором.
Что сделать прямо сейчас, если вы в целевой аудитории: откройте репозиторий, прочитайте README, затем FAQ, прогоните пример ComfyUI-воркфлоу и замерьте свой основной сценарий по методике выше. Если цифра ускорения устраивает, инструмент ваш. Если нет, вы узнаете это за один вечер, а не после недели настройки.