«Работает — не трогай» — известная всем первая заповедь программиста, сисадмина, да и любого айтишника в самом широком смысле слова. Для оператора ИИ-модели, создающей изображения по текстовым подсказкам, она в общем случае тоже справедлива. Речь здесь идёт не о неуклонном совершенствовании самих этих подсказок, конечно же, а о попытках улучшить работу интерпретирующей их рабочей среды. Тем более что, если применяемое ПО чем-то пользователя не устраивает, для исправления ситуации — даже когда это софт с открытым кодом, такой как рассматривавшийся нами на протяжении уже трёх «Мастерских» AUTOMATIC1111 (раз, два, три), — требуется квалификация посущественнее собственно пользовательской.
Источник: ИИ-генерация на основе модели SDXL 1.0
Но вот какая незадача: некий софт — в данном случае рабочая среда для управления генеративной моделью, претворяющей текст в картинки, — может не то чтобы не работать совсем, а, скорее, ощутимо ограничивать (вследствие имманентно присущих ей особенностей) функциональные возможности этой самой модели. Взять ту же среду AUTOMATIC1111: за неполный год своего существования она стала для энтузиастов ИИ-рисования по всему миру едва ли не штатным инструментом для эксплуатации чекпойнтов, созданных на основе базисной генеративной модели Stable Diffusion 1.5 (путём дотренировки последней на дополнительных массивах аннотированных изображений). Однако в конце июля 2023-го, с выходом новейшей версии SD, уже не номерной (1.4, 1.5, 2.1, как было прежде), а литерной (с суффиксом XL), стало достаточно очевидно, что AUTOMATIC1111 в актуальном на тот момент своём состоянии не справляется с предоставлением полного доступа ко всем возможностям новой модели.
Точнее, осознание это появилось у энтузиастов ИИ-рисования даже чуть раньше — ещё на этапе попадания в общий доступ бета-версии SDXL с условным индексом 0.9. Собственно, по этой причине многие поклонники Иизобразительных Иискусств продолжают считать SD 1.5 наиболее предпочтительным на сегодня вариантом: за долгие месяцы активной эксплуатации этой модели для неё разработаны довольно эффективные правила формулирования текстовых подсказок, а главное — создан обширнейший дополнительный инструментарий, включая апскейлеры (мини-нейросети для масштабирования исходной картинки с увеличением детализации), текстовые инверсии, LoRA, разнообразные модели ControlNet и множество прочего.
Источник: ИИ-генерация на основе модели SDXL 1.0
Тем не менее коллектив Stability.ai, разработчика модели Stable Diffusion, делает самую серьёзную ставку на SDXL 1.0, прямо заявляя, что даже её базовая субмодель (смысл этого термина поясним чуть ниже) выдаёт результаты, ощутимо более привлекательные для контрольной группы, чем предыдущие разновидности. В отношении «Двоечки» (SD 2.0, а чуть позже и 2.1) таких заявлений не делалось, причём по вполне объективным причинам. Довольно быстро стало понятно, что смена текстового декодера (преобразователя текстовых подсказок в цифровые токены, по которым в дальнейшем уже и производится навигация в латентном пространстве) с CLIP на OpenCLIP сыграла с командой Stability.ai злую шутку: прямое использование подсказок от «Полуторки» для новой модели не давало изображений лучшего качества, поскольку декодировался их текст по-иному, — а ИИ-художественное сообщество к тому времени накопило уже столько опыта в обращении с SD 1.5, что отсутствие возможности с минимальными потерями перенести его на SD 2.1 стало для последней, в общем-то, приговором.
До сих пор на портале Civitai, чрезвычайно популярном у энтузиастов генеративных изобразительных моделей, у самого востребованного чекпойнта для «Двоечки», rMada Merge, всего 8,7 тыс. загрузок и 1,5 тыс. «лайков», тогда как лидер в зачёте «Полуторок», DreamShaper, может похвастать 488 тыс. скачиваний и 32 тыс. отметок «нравится». Тут ещё надо иметь в виду, что для закачки чекпойнта с Civitai в общем случае нет необходимости регистрироваться, тогда как на сердечки рядом с названием модели могут нажимать только авторизованные пользователи. Разрабатывая SDXL, в Stability.ai учли этот момент, — и в результате текстовый декодер для «Оверсайза» представляет собой комбинацию OpenCLIP и исходной языковой модели CLIP, разработанной и активно применяемой другим пионером в области генеративного ИИ — компанией OpenAI (той самой, что стоит за ChatGPT). Формально программный код CLIP также открыт — зато массив изображений, на которых этот декодер тренировался, до сих пор остаётся проприетарным; смысл же OpenCLIP в том, что это, по сути, тот же CLIP, но натренированный на находящейся в открытом доступе базе аннотированных картинок LAION.
В текстовой подсказке к этому изображению НЕ БЫЛО упоминания Алисы Вокс! (источник: ИИ-генерация на основе модели SDXL 1.0)
Так или иначе, различий между SDXL и «номерными» версиями SD значительно больше, чем между версиями 1.5 и 2.1. Это автоматически означает, что и подбор слов в подсказках придётся вести по-иному (хотя «Оверсайз»-версия частично вернулась к использованию CLIP, так что в этом плане всё несколько проще), и все инструменты, от LoRA до ControlNet, потребуется воссоздавать с нуля. Однако эта работа уже идёт: судя по динамике появления новых моделей на сайте Civitai, среди самых первых пользователей SDXL оказалось так много очарованных широтой возможностей этой модели энтузиастов, что раскрытие всей полноты её потенциала уже не за горами. И, поскольку заданные AUTOMATIC1111 рамки пока чересчур тесны для адекватного знакомства со всеми этими возможностями, попробуем освоить — в самом первом приближении — принципиально иную по самой своей структуре рабочую среду под названием ComfyUI.
⇡#Два мира, два подхода
Для начала укажем, что помимо ComfyUI в сообществе ИИ-художников активно используются по меньшей мере две локальных рабочих среды, готовые широко раскрыть потенциал SDXL: Fooocus (максимально упрощённый интерфейс, элементарная установка, возможность нажатием одной кнопки — без чрезмерного колдовства над текстовой подсказкой — задать выдачу изображения в стиле фотографического реализма, рисунка тушью или пиксельной графики) и SD.Next (мартовский, 2023 года, форк проекта AUTOMATIC1111 со множеством оптимизаций и расширенной поддержкой тренировки энтузиастами собственных моделей). Есть и другие, плюс к тому множество веб-сайтов предлагают теперь SDXL 1.0 в качестве модели по умолчанию — вот хотя бы mage.space и Clipdrop, для примера.
Базовая циклограмма, зашитая в «чистую» установку ComfyUI: обособленный, ни с чем не соединённый прямоугольник справа и есть, собственно, практически весь интерфейс данной рабочей среды (источник: GitHub)
Но ComfyUI разительно отличается от всех прочих тем, как в ней организован процесс генерации изображений из текста. Суть в том, что в этой рабочей среде оператор не просто вводит данные в соответствующие поля, ставит галочки, нажимает кнопки и перемещает ползунки, — но собственноручно выстраивает последовательную многоэтапную процедуру (циклограмму) преобразования текста в картинку через латентное пространство, соединяя ответственные за отдельные операции узлы (nodes, ноды) логическими связями, по которым передаются те или иные данные.
В сообществе энтузиастов генеративных изобразительных искусств почти сразу после появления ComfyUI в марте текущего года родилась саркастическая шутка: «AUTOMATIC1111 не так уж и автоматизирована, а работать с ComfyUI не слишком комфортно». Справедливости ради отметим, что название рассматриваемой рабочей среды вовсе не призвано подчёркивать эргономические достоинства её интерфейса (которого, на ошарашенный взгляд новичка, и вовсе по сути нет): просто Comfy — точнее, comfyanonymous, — это ник её создателя. Ныне, кстати говоря, присоединившегося к коллективу разработчиков Stable Diffusion по их же настоятельному приглашению, — именно ComfyUI стала теперь внутренней рабочей средой по умолчанию в Stability.ai. Один этот факт наверняка сделается для многих весомым аргументом в пользу переключения на данную рабочую среду если не прямо сегодня, то уже в обозримой перспективе — вне зависимости от того, страшит их «макаронный» интерфейс или нет.
Для полного погружения в море возможностей SDXL циклограмма генерации картинок для этой модели должна обеспечивать последовательную работу двух чекпойнтов: основы (base) и доводчика (refiner)
Да, сейчас вовсю тестируется предварительная версия AUTOMATIC1111 (которая после официального релиза должна получить номер 1.6.0; актуальная же стабильная на момент написания настоящей статьи — 1.5.1), которая, по слухам, будет гораздо лучше обращаться с XL-разновидностью этой популярной генеративной модели. Но с учётом прямой поддержки со стороны Stability.ai перспективы ComfyUI видятся более радужными. Вдобавок из-за особенностей внутренней архитектуры AUTOMATIC1111 эта среда-первопроходец значительно сложнее, чем более поздние проекты, поддаётся модификации, развитию, да и просто поддержке. Тот же comfyanonymous — благо код проекта открыт, так что его слова может проверить любой желающий, — так отзывается об «Автоматике»: «В коде A1111 ногу сломать можно; он слишком негибок, чтобы справляться со всеми новинками, что будут появляться в дальнейшем».
И действительно, у ComfyUI есть такое безусловное достоинство, как невероятная в сравнении с AUTOMATIC1111 гибкость. Обеспечивается она именно за счёт того, что вместо использования готового интерфейса с вкладками, выпадающими меню и ползунками оператору (вот теперь уж точно не пользователю!) рабочей среды для ИИ-рисования предлагается самостоятельно составить циклограмму — протокол последовательного исполнения (workflow) — всей той работы, что предстоит проделать системе. Пусть путём не написания строк кода, а расстановки на интерфейсном поле нужных нод и соединения их соответствующими связями, — но именно запрограммировать, значительно глубже погрузившись тем самым в роль со-творца цифрового образа, чем в ходе эксплуатации более консервативной рабочей среды.
Источник: ИИ-генерация на основе модели SDXL 1.0
К счастью, освоить потокоориентированное программирование (flow-based programming, FBP), базирующееся на графическом представлении нод (узлов), что исполняют различные действия, и на связывании их потоками движения данных, для не ИТ-специалиста значительно проще, чем справиться с каноничным написанием кода оператор за оператором. Концепция FBP восходит к концу 1960-х, а в последнее время она стала особенно популярна как принцип организации сред программирования LowCode/NoCode, не требующих (по крайней мере, теоретически) участия высококвалифицированных программистов для создания прикладных программных продуктов, полностью готовых к эксплуатации.
В рамках этой концепции ноды выступают для операторов как некие чёрные ящики, до внутреннего устройства которых им нет дела. У каждой ноды есть входы и выходы, готовые принимать или, соответственно, выдавать данные определённых типов и в строго заданных форматах. Перенаправляя от одного узла к другому информационные потоки, оператор выстраивает из элементарных нод достаточно сложные конструкции — по тому же принципу, как из базовых полупроводниковых элементов (штрихов Шеффера) на поверхности микросхемы организуются — путём соединения их проводниками в нужном порядке — логические вентили, сумматоры и прочие составные элементы процессора.
Пояснение принципа действия FBP-нод как чёрных ящиков на примере упаковочной линии на фабрике газировки: менеджеру процесса не надо знать, как именно реализуются наполнение, укупорка и наклеивание этикеток, — ему надо лишь в верном порядке соединить нужные узлы конвейерной лентой (источник: GitHub)
И всё же при всех бесспорных достоинствах FBP-среды первое впечатление от взгляда на её интерфейс у любого, кто не знаком с азами NoCode-программирования, однозначное: «макаронный монстр». И вплоть до появления в открытом доступе чекпойнтов SDXL версии 0.9 доля энтузиастов ИИ-рисования, сознательно выбиравших ComfyUI для своих экзерсисов, была откровенно невелика. Надо, впрочем, отдать должное её создателю: с пугающими «макаронинами» рядовому оператору этой среды, по сути, нет особой необходимости слишком уж глубоко разбираться. Каждый PNG-файл, генерируемый на выходе ComfyUI, несёт в текстовых полях своего заголовка детальнейшее (в известной 
Развитые циклограммы вроде тех, что предлагает проект Searge-SDXL, содержат как множество самописных (кастомных) нод, так и сразу множество доступных потоков исполнения, между которыми оператор волен переключаться в зависимости от того, что ему в данный момент требуется (источник: GitHub)
Подпишись: