mflux-generate-z-image-turbo takes twice of VRAM at the end of generation

[vladyuhuu]

First — thanks to filipstrand and contributors!

Question – is it OK? With mflux-generate-z-image-turbo (--model filipstrand/Z-Image-Turbo-mflux-4bit), it uses about 9–10 GB of VRAM during generation, but at the end it consumes much more—I'd say 1.5 to 2 times as much.
I use macbook pro m1 pro.
graph in activity monitor

Also I couldn't find, does mflux support LoRA lightening?
One more question — right now, the model loads and unloads from VRAM for every prompt. Is it possible to not unload the model automatically after generation, or may be there is a UI that can do it (like LMStudio for mlx-lm)?

[azrahello]

First — thanks to filipstrand and contributors!

Question – is it OK? With mflux-generate-z-image-turbo (--model filipstrand/Z-Image-Turbo-mflux-4bit), it uses about 9–10 GB of VRAM during generation, but at the end it consumes much more—I'd say 1.5 to 2 times as much. I use macbook pro m1 pro. graph in activity monitor

Also I couldn't find, does mflux support LoRA lightening? One more question — right now, the model loads and unloads from VRAM for every prompt. Is it possible to not unload the model automatically after generation, or may be there is a UI that can do it (like LMStudio for mlx-lm)?

With the  --low-ram  option you can fix it — that spike might be caused by the VAE, but with the latest 14.0 update and by using that parameter, you should be able to solve it. Moreover, with the argument --auto-seed N, you can perform N operations, and with the argument --prompt-file file_of_prompt.txt, you can inject a prompt between generations. Each time you change the prompt, the text encoder must reload, causing a noticeable increase in resource consumption.

[vladyuhuu]

First — thanks to filipstrand and contributors!
Question – is it OK? With mflux-generate-z-image-turbo (--model filipstrand/Z-Image-Turbo-mflux-4bit), it uses about 9–10 GB of VRAM during generation, but at the end it consumes much more—I'd say 1.5 to 2 times as much. I use macbook pro m1 pro. graph in activity monitor
Also I couldn't find, does mflux support LoRA lightening? One more question — right now, the model loads and unloads from VRAM for every prompt. Is it possible to not unload the model automatically after generation, or may be there is a UI that can do it (like LMStudio for mlx-lm)?

With the  --low-ram  option you can fix it — that spike might be caused by the VAE, but with the latest 14.0 update and by using that parameter, you should be able to solve it. Moreover, with the argument --auto-seed N, you can perform N operations, and with the argument --prompt-file file_of_prompt.txt, you can inject a prompt between generations. Each time you change the prompt, the text encoder must reload, causing a noticeable increase in resource consumption.

Yes, that works. It also took the same amount of time to generate the same image, and the quality was the same. I wonder, then, why not just use --low‑ram by default? What benefits does generating without --low‑ram provide?

[azrahello]

First — thanks to filipstrand and contributors!
Question – is it OK? With mflux-generate-z-image-turbo (--model filipstrand/Z-Image-Turbo-mflux-4bit), it uses about 9–10 GB of VRAM during generation, but at the end it consumes much more—I'd say 1.5 to 2 times as much. I use macbook pro m1 pro. graph in activity monitor
Also I couldn't find, does mflux support LoRA lightening? One more question — right now, the model loads and unloads from VRAM for every prompt. Is it possible to not unload the model automatically after generation, or may be there is a UI that can do it (like LMStudio for mlx-lm)?

With the  --low-ram  option you can fix it — that spike might be caused by the VAE, but with the latest 14.0 update and by using that parameter, you should be able to solve it. Moreover, with the argument --auto-seed N, you can perform N operations, and with the argument --prompt-file file_of_prompt.txt, you can inject a prompt between generations. Each time you change the prompt, the text encoder must reload, causing a noticeable increase in resource consumption.

Yes, that works. It also took the same amount of time to generate the same image, and the quality was the same. I wonder, then, why not just use --low‑ram by default? What benefits does generating without --low‑ram provide?

In some cases, it may increase generation time, especially with large models like Qwen or Flux. Nevertheless, I get better performance with Qwen using the --low-ram argument rather quantize