BASE CONFIG — центральная панель управления профессиональным графом
Большой ComfyUI workflow становится управляемым только тогда, когда крупные processing-системы можно включать, отключать и тестировать из одного места. BASE CONFIG — это control plane графа: он определяет, какие модули участвуют в текущем runtime profile.
BASE CONFIG отвечает на вопрос «что вообще запускается?»
В большом production graph недостаточно уметь менять CFG, denoise или steps. Сначала нужно решить, какие крупные системы вообще участвуют в текущем прогоне: loaders, inputs, preprocessors, masks, PEOPLE, SDXL, FLUX, upscale и output.
BASE CONFIG централизует это решение. Он не заменяет параметры отдельных нод: он находится уровнем выше и управляет архитектурным состоянием workflow.
Какие processing-группы Hansen управляет централизованно
| Group toggle | Назначение |
|---|---|
| MODEL LOADERS | Загрузка checkpoints, UNet, CLIP, VAE и других моделей |
| INPUTS | Base image, references, maps и другие входные данные |
| CONTROL | Shared controls / selectors / общие параметры |
| SAMPLER CONFIGURATION | Seed, steps, sampler, scheduler и связанные настройки |
| ControlNet Preprocessors + Extras | Depth, edge и вспомогательная предобработка |
| MASKS | Архитектурные и локальные маски |
| PPL FLUX Generate | Отдельная генерация людей |
| PPL SEGMENTATION | Detection / segmentation людей |
| PPL FLUX Composite | Подготовка и compositing людей |
| PPL 3D INPAINT Detail | Альтернативная ветка работы с уже размещёнными людьми |
| Process SEGMENTATION | Общая segmentation processing |
| Process SDXL | Основной SDXL stage |
| Process FLUX | Основной FLUX refinement |
| Process UPSCALE | Upscale / HQ processing |
| Process ADD LOGO | Overlay / logo post-process |
| OUTPUT | Preview / save / delivery stage |
Bypass, selected-away и disabled — не одно и то же
В большом графе важно различать физическое наличие ветки, выбор её результата и само выполнение processing. Иначе пользователь видит подключённую ветку и ошибочно считает, что она участвует в текущем output.
| Состояние | Что происходит | Как читать |
|---|---|---|
| ACTIVE | Группа выполняется и её output нужен downstream | Участвует в runtime |
| BYPASSED | Processing сохранён в графе, но пропускается | Архитектура есть, вычисление выключено |
| SELECTED AWAY | Ветка может быть активна, но selector выбирает другой source | Не влияет на текущий result |
| DIAGNOSTIC ONLY | Результат идёт в preview/comparer, а не в production output | Нужен для наблюдения |
Централизованный bypass превращает группы в управляемые модули
Идея Fast Groups Bypasser в том, что пользователь не бегает по canvas и не выключает десятки нод вручную. Он управляет именованными группами из одной панели, а group names становятся частью архитектурного API workflow.
Отсюда следует важное правило: названия групп должны быть стабильными и однозначными. Если control plane обращается к группам по имени, переименование без системы ломает читаемость и может нарушить управление.
Hansen pattern
BASE CONFIG на видео используется как единая панель enable/bypass для крупных групп workflow.
Engineering rule
Group name следует считать частью интерфейса модуля: коротким, стабильным и отражающим функцию, а не историю редактирования.
Имена групп должны объяснять ответственность, а не автора или версию
| Плохо | Лучше |
|---|---|
| group 1 | INPUTS |
| test2 | CONTROLNET · DEPTH |
| new final | PROCESS · FLUX |
| people stuff | PPL · SEGMENTATION |
| final final | OUTPUT |
Группы нужно включать не случайно, а по dependency chain
У модулей есть зависимости. PROCESS FLUX бессмысленно тестировать, если его input не сформирован предыдущей стадией. PPL Composite не работает без подготовленного человека и placement data. Поэтому BASE CONFIG должен читаться как карта зависимостей, а не как список независимых переключателей.
Профессиональный BASE CONFIG должен поддерживать минимальные тестовые профили
При диагностике не нужно запускать весь Master Workflow. Чем меньше активных систем, тем проще понять источник ошибки и тем меньше расход VRAM / времени.
Debug principle
Активировать минимальный маршрут, который способен воспроизвести проблему; только после исправления возвращать downstream-модули.
| Preset | Что оставляем активным | Зачем |
|---|---|---|
| TEST INPUT ONLY | Loaders + Inputs + Preview | Проверить файлы, размеры и canvas |
| TEST PREPROCESS | Inputs + нужный preprocessor + Preview | Проверить depth / edge / map до генерации |
| TEST MASKS ONLY | Inputs + segmentation/masks + Preview | Проверить polarity, bounds и coordinate space |
| TEST PPL ONLY | PPL Generate + Segment + Composite + local previews | Изолировать PEOPLE module |
| TEST SDXL ONLY | Loaders + Inputs + SDXL + checkpoint preview | Проверить base generation |
| TEST FLUX ONLY | Готовый input + FLUX + preview | Проверить финальный refinement |
| FINAL FULL RUN | Все утверждённые production modules | Финальный интеграционный прогон |
BASE CONFIG также управляет стоимостью запуска
Отключение тяжёлой ветки — это не только визуальная чистота. Это способ не загружать лишние модели, не держать ненужные preprocessors в памяти и не выполнять downstream, который сейчас не тестируется.
Особенно это важно на GPU с ограниченной VRAM: архитектурное управление графом становится частью performance engineering.
Практика: спроектировать BASE CONFIG до добавления генеративных нод
Создай пустой учебный canvas и сначала нарисуй только группы: MODEL LOADERS, INPUTS, CONTROL, PREPROCESS, MASKS, PROCESS A, PROCESS B, OUTPUT. Затем запиши, какие группы должны быть активны для трёх режимов: Input Test, Module Test и Full Run.
На этом упражнении не требуется ни одна AI-модель. Цель — научиться проектировать control plane до того, как граф станет большим.