ComfyUI-MiniMaxH3-CLIPCached: дисковый кэш условий H3

ComfyUI Wikinews

Новый узел ComfyUI кэширует на диск conditioning Qwen3-VL для MiniMax H3: повторные запуски с тем же промптом пропускают энкодер 14,6 ГБ, ускорение с 29,9 с до 1,1 с.

ComfyUI-MiniMaxH3-CLIPCached (GitHub) это новый пакет узлов с лицензией MIT, который кэширует на диск текстовые и визуальные условия (conditioning) MiniMax H3. При повторной генерации с тем же промптом и теми же референсными входами кодировщик Qwen3-VL полностью пропускается: этап формирования условий сокращается примерно с 30 секунд до 1 секунды, а кодировщик на 14.6 ГБ вообще не загружается.
Рабочий процесс CLIPCached с кэширующей нодой

Кэширующая нода заменяет штатную ноду условий H3, а этап диффузии не затрагивается.

Что кэшируется, а что нет

Это не ускоритель сэмплирования. Это не TeaCache и не FirstBlockCache, и он не влияет на шаги сэмплирования. Нода заменяет штатную ноду условий H3 в ComfyUI: при попадании в кэш она загружает ранее вычисленные текстовые и визуальные условия с диска вместо запуска кодировщика Qwen3-VL, а этап диффузии выполняется без изменений.

ИзменениеНовая запись кэша?
Текст промптаДа
Чекпоинт кодировщикаДа
Пиксели ключевых кадров и референсов, видимые кодировщикуДа, если меняется видимое кодировщику содержимое
Сид, сэмплер, планировщик, шагиНет
LoRA дальше по графу или сила (strength)Нет

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

Измеренные показатели

Контролируемый бенчмарк автора (по 5 прогонов на режим, медианные значения, RTX 5080 16 ГБ под WSL2; для нативного режима и промаха кэша кодировщик намеренно считывался «на холодную»):

РежимФормирование условийПиковая VRAMПиковая RAM процесса
Нативный29.85 с15.24 ГиБ29.25 ГиБ
Промах кэша32.23 с15.24 ГиБ28.25 ГиБ
Попадание в кэш1.12 с2.67 ГиБ3.38 ГиБ

Промах кэша намеренно не быстрый путь: он всё равно запускает кодировщик и записывает результат на диск, добавляя около 2 секунд. Зато после кодирования кодировщик выгружается, а не остаётся в памяти, поэтому сэмплирование проходит с освобождённой памятью. На скриншоте автора в нативном режиме во время сэмплирования в памяти остаются и модель H3 на 11.7 ГБ, и кодировщик на 14.6 ГБ, тогда как при попадании в кэш загруженным остаётся только DiT, а потребление RAM процесса падает с 40 ГБ до 25.5 ГБ.

Узлы и управление кэшем

В пакет входят кэширующие аналоги штатных узлов H3 Image-to-Video (FL2VA) и Reference-to-Video (Ref2VA), варианты с двумя разрешениями, которые подготавливают условия и для базового прохода, и для целевого апскейла, а также общий селектор имени кодировщика.

Каждый уникальный запрос условий становится записью кэша, которая хранится до удаления, и при частой итеративной работе записи накапливаются. Встроенная панель менеджера кэша позволяет просматривать записи, помечать их тегами и удалять лишнее. Требования: ComfyUI 0.30.0 или новее с нативными узлами H3.

Доступность

Нода доступна в ComfyUI Manager и в реестре как minimaxh3-clipcached; также можно клонировать репозиторий в custom_nodes. В текущей версии нет автоматической очистки кэша, Ref2VA использует фиксированные слоты референсов, а кодировщики GGUF не тестировались.

Комментарии

Войдите через GitHub, чтобы участвовать в обсуждении.

Загрузка комментариев…
ComfyUI-MiniMaxH3-CLIPCached: дисковый кэш условий H3 | ComfyUI Wiki