FLUX.2-dev GGUF Q4_K_M на Apple Silicon: куда уходят 29 гигабайт?

[vyacheslavteplyakov]

Это необоснованно большие веса, даже для традиционного железа. А тут эпл под который это все в принципе не заточено. Плюс конский размер моделей. Что за задача такая, для которой это понадобилось? Не проще за горсть сухарей арендовать что-то в ранподе и не тратить время на бесперспективные страдания?

[ComputerPers]

Pipeline генерация большого набора assets, постоянно и с перегенерацией. Да вы правы эта модель эти веса для нее на этом железе это оверкилл с крышечкой.

И эта модель не будет/не должна использоваться часто. Но она должна быть включена в критические места, где без нее никак. В основном работает 4B модель потом где места по сложнее 9B. Затем (уже в зависимости от стиля) Flux 1.Dev -> Flux.2-dev.

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

Вы правы и на счет Ranpod. Но моя цель делать это локально. Оптимизации пока что вроде не вредили. И информации в интернете я найти не смог. Все разрозненно, противоречиво.

[vyacheslavteplyakov]

Дело не в оптимизации. Просто в текущем положении вещей у вас нет шансов заставить это работать. Максимум запустить, как доказательство возможности, но это будет неюзабельно. Если вам реально для дела, то вы не в ту сторону тратите время и силы.

[beeruser]

А тут эпл под который это все в принципе не заточено

Поддержка Apple Silicon в llama.cpp как раз "в первых рядах" появилась.

UMA, кэш-когерентность GPU, наличие NPU. Это всё идеально подходит для AI, в отличие от "традиционного железа".

[vyacheslavteplyakov]

Ну и где все тогда? Или не запускается вообще или скорость ниже плинтуса. И при чем тут llama.cpp если тема статьи генерация изображения?