Можно ли закешировать результат загрузки gguf модели в Forge?

Question

[SmeliyR]

Использую среду для запуска нейросетевых графических моделей Forge и модель Flux1-shnell-Q2_K.gguf и энкодеры ae.safetensors, clip_l.safetensors, t5-v1_1-xxl-encoder-Q3_K_L.gguf .

Работает нормально на 6 ГБ VRAM, генерация одной картинки в 4 прохода занимает около двух-трёх минут, но загрузка модели первый раз после запуска Forge
длится более 10 минут. Это долго, я думаю можно ускорить кешированием?

Кстати, в процессе этой загрузки процесс python отжирает 12 гигов ОЗУ. Я так полагаю,
он читает с диска файлы моделей и что-то с ними делает (распаковывает?) и затем держит в ОЗУ и - длится это те самые 10 минут.

Вопрос тем, кто имеет опыт работы с Flux1 и/или с Forge - можно ли этот результат 12 гиговой распаковки закешировать на диск, чтобы первичная загрузка модели
длилась просто времени равном чтению ~12 гигового файла с диска, т.е. достаточно быстро.

Answer 1

[Ronaldo]

Forge использует какие то конвертации весов во другой формат, для лучшей совместимости с разными LOR-а. Для квантованных моделей этот процесс еще дольше. Скажу больше, так же forge любит делать конвертации прямо перед просчетом, иногда по минуте на мощной машине (r7950/3090)
Для прямой загрузки модели, без конвертации, лучше использовать ComfyUI/GGUF Loader ноду.
Вот готовая схема для Comfy, распаковать, перетащить на канвас.

Comments

[SmeliyR]

Респект за направление решения проблемы.
Изначально, когда выбирал UI для Flux, ComfyUI отпугнул кучей стрелок и прямоугольников, но оказалось разобраться в них довольно легко, если собирать схему с нуля и без наворотов. Собрал вот такую простейшую схему с самым необходимым, по какому то видосу с ютуба, полёт нормальный, причем,
во первых, подсвечивает, как модуль работает в данный момент - это круто,
во-вторых, реально оно что-то кеширует, например если не менять запрос (prompt), то видно, что модуль, отвечающий за запрос - повторно не запускается, сразу рендер идет.


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



кстати сама генерация идёт на GPU
но VAE и CLIP почему то на CPU - так и должно быть?

Using pytorch attention in VAE
VAE load device: cuda:0, offload device: cpu, dtype: torch.float32
gguf qtypes: Q3_K (120), F32 (50), Q5_K (48), Q6_K (1)
Requested to load FluxClipModel_
loaded completely 9.5367431640625e+25 323.94775390625 True
CLIP/text encoder model load device: cpu, offload device: cpu, current: cpu, dtype: torch.float16

[Ronaldo]

Рад помочь!
CLIP и VAE занимают очень мелкую часть просчета, если сборка принимает решение считать их на CPU, возможно это из-за малой VRAM.
Красным помечен блок LORA, эта подсеть может "заставить" считать изображение в том стиле в котором изначальный Flux1 не особо силен, например пин-ап или фантастика. Особенно это полезно для урезанных и слабых моделей. Так сказать компенсирует слабое качество и стиль.

[SmeliyR]

Ronaldo,

CLIP и VAE занимают очень мелкую часть просчета, если сборка принимает решение считать их на CPU, возможно это из-за малой VRAM.

А это действительно так?

VAE вроде бы да
но узлы CLIPtextencoder у меня работают минут 5 если грузить их на ЦПУ
и почти моментально, если я в ClipLoader принудительно ставлю cuda:0