Вторая заметка о stageload запускала Qwen-Image-2.1 на Mac с 48 ГБ двумя способами. Eager сторож памяти остановил при декодировании VAE, а staged дошёл до конца. В diffusers есть и третий, встроенный способ, enable_model_cpu_offload: каждая модель лежит на CPU и переезжает на GPU только на время своей работы. 8 октября я запустил его один раз, с тем же промптом, размером, числом шагов, сидом и порогами сторожа, что и прогоны 6 октября.
По footprint процесса offload выглядел как staged: пик 18,5 ГБ против 19,0 ГБ. Различает их своп. Кодирование заняло 8 с и своп не добавило. За 87 с денойзинга своп вырос на 3,5 ГБ, а доступная память упала до 27 %. Декодирование VAE довело рост свопа до 9,6 ГБ, а доступную память до 22 %, и через 105 с после старта сторож остановил прогон, изображение записать он не успел. Staged не добавил свопа ни в одном из двух прогонов и закончил их за 94 и 124 с.
Footprint этого не показывает, потому что не считает страницы, которые уже ушли в своп. На Mac у CPU и GPU одна общая память, так что модель, лежащая «на CPU», занимает ту же RAM, что и работающая. По одному footprint offload стоял бы рядом со staged. По свопу он рядом с eager, которого сторож остановил в том же месте после 8 ГБ нового свопа.
Что я не смог показать
Это один прогон. Второй снова загнал бы машину в своп ради исхода, который сторож уже определил. Я не измерял, какие страницы ушли в своп, и не пробовал offload на Mac с большей памятью.
Скрипт лежит в bench/qwen_image_offload.py, трасса в репозитории. stageload ставится командой pip install stageload.