12 ГБ VRAM и WAN 2.2 I2V‑A14B: как заставить RX6700XT генерировать видео неограниченной длины

Вместо введения

Относительно недавно я познакомился с ComfyUI. После не очень продолжительных танцев с бубном и установки кастомных ROCm‑драйверов для моей видеокарты (официальная поддержка начинается только с AMD RX7600) я столкнулся с проблемой генерации видео.

Если быть точнее, единственное, что я мог себе позволить для полноценного вычисления с помощью видеокарты, — это модель wan2.2_ti2v_5B. Но она работала очень нестабильно: не слушалась промптов и выдавала артефакты.

Квантование и выбор модели

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

Чем я и воспользовался. Я нашёл GGUF‑модель Wan2.2-I2V‑A14B с квантованием Q4_K_M, которая подошла мне по размеру и, как писали на форумах, показывает результаты намного лучше, чем wan2.2_ti2v_5B. Это, ко всему прочему, может обуславливаться тем, что помимо более сложной структуры генерация производится в два этапа: high и low noise. Первая генерирует основную композицию, а вторая — детали.

Также я использовал с данной моделью LoRA‑ускоритель lightx2v_4steps, что позволило получать удовлетворительный результат уже на 4 шагах. Это сильно сократило время генерации. Это решение мне ещё аукнется, но об этом позже.

Оптимизация железа

Затем я произвёл небольшую оптимизацию железа, а именно установил новый SSD, на который разместил все модели и файл подкачки. Последний, между прочим, дал довольно неожиданный прирост к скорости. Оперативной памяти у меня 32 ГБ, и её всегда хватало с запасом, но как только я разместил файл подкачки на SSD, оптимальное количество кадров для генерации видео разрешения 480×480 поднялось с 39 до 53.

Но данное количество кадров меня всё равно не устраивало, да и при переходе на разрешение 720×720 количество доступных генерируемых кадров резко падало. Также я хочу отметить, что даже при возможности использовать максимальный функционал данной модели больше 81 кадра за раз сформировать всё равно не получится.

Поиск решения: почему просто склеить не получится

После этого я начал думать, как последовательно генерировать видео.

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

Затем я начал искать какие‑нибудь готовые решения, но все они были заключены в одну большую ноду, к которой подключались все модели одновременно, что приводило к переполнению памяти. Такие варианты были нежизнеспособны. Мне нужен был какой‑нибудь более тонкий механизм для настройки оптимизации.

Нода Wan First‑Middle‑Last Frame to Video

В итоге после длительных изысканий я наткнулся на ноду Wan First‑Middle‑Last Frame to Video из пакета Wan22FMLF. Она умеет подготавливать данные для генерации видео по трём ключевым кадрам и с возможностью выбирать положение среднего кадра.

И тут у меня и зародилась идея о генерации нового видео по двум ключевым кадрам, взятым из предыдущего. Первый взят откуда‑то из середины предыдущего, а средний — с его конца. После генерации нам останется только подрезать пересекающиеся кадры для исключения несогласованности и объединить последний кадр с ключевым кадром из середины нового видео, которые не должны отличаться.

Единственное условие: индекс кадра среднего видео должен быть кратен четырём, так как это длина генерируемого сегмента моделью. Не номер строки, а именно индекс — индексы у нас начинаются с нуля.

Схема механизма

После данных операций у нас получается одно длинное видео, кадры между которому согласованы. Самый лучший результат я получил при перекрытии 12 кадров, но в сильно динамичных сценах лучше использовать 8.

Этот механизм можно масштабировать до бесконечности. И при увеличении сегментов время обработки растёт линейно.

Минусы, с которыми пришлось смириться

Пересвет среднего кадра

Первый и самый яркий минус, с которым я столкнулся, — это пересвет среднего кадра. Средний кадр как будто высветлялся и тянул за собой соседние. Этот эффект получилось довольно неплохо устранить за счёт настройки шума среднего кадра и увеличения перекрытия. Но полностью побороть его не получилось: в некоторых сценах он немного бьёт по глазам.

В целом на постпродакшене можно вручную поправить экспозицию и убрать засвет — ничего критичного в этом я не вижу. Чуть позже я выяснил, что этот эффект появляется из‑за lightx2v_4steps, но избавляться от него не стал, так как без него генерация видео будет длиться в 5 раз дольше.

Потеря деталей

Вторая проблема — это потеря деталей при переходе от секции к секции. В частности, если на первом и среднем кадре чего‑то нет, что было в начальном видео, скорее всего, его мы больше не увидим.

Результаты времени генерации

Пример сгенерированного видео

Заключение

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