Just thinking of the poor sods that are going to be working today (and all night).
Oh and more pics since the bingilator is not without its randomness.
Just thinking of the poor sods that are going to be working today (and all night).
Oh and more pics since the bingilator is not without its randomness.
ComfyUI keeps crapping out on me when I so much as sneeze. The nodes get screwy, the canvas wigs out and becomes inoperable unless I kill the server and start it up again.
Are there any other alternatives that you can think of?
When a model is initially being loaded, I see slowdown, but once that has happened, I don’t. I see that with Automatic1111 as well. Once it’s been loaded, though, I don’t get that. I regularly do (non-GPU-using) stuff on another workspace when rendering, can’t detect any slowdown.
So I don’t know what might be the cause. Maybe memory exhaustion? A system that’s paging like mad might do that, I guess.
As to an alternative, it depends on what you want to do.
If you’ve never done local GPU-based image generation, then Automatic1111 is probably the most-widely-used UI (albeit the oldest).
If you want to run Flux and Flux-derived models – which I’m using to generate my above image – I believe I recall reading that while Automatic1111 cannot run them – and maybe that’s changed, have not been monitoring the situation – the Forge UI can do so as well. But I’ve never used it, so I can’t provide any real guidance as to setup.
kagis
Yeah, looks like Automatic1111 can’t do Flux:
https://github.com/AUTOMATIC1111/stable-diffusion-webui/issues/16311
And it looks like Forge can indeed run Flux:
https://sandner.art/flux1-in-forge-ui-setup-guide-with-sdsdxl-tips/
If you’re short of VRAM or RAM or something, though, I don’t know if Forge will do better than ComfyUI. I think that I might at least try to diagnose what is causing the issue first, as there are some things that can be done to reduce resource usage, like generating images at lower resolution and relying more-heavily on tile-based upscaling. With at least some of the systems, haven’t played around with ComfyUI here, there are also some command-line options to reduce VRAM usage in exchange for longer compute time, like
--medvramor--lowvramin Automatic1111.I don’t think that there’s a platform-agnostic way to see VRAM usage. I use a Radeon card on Linux, and there, the
radeontopcommand will show VRAM usage. But I don’t know what tools one would use in, say, Windows to look up the same numbers.On Linux,
topwill show regular memory usage, can hit “M” to sort by memory usage. I’m pretty out of date in Windows or MacOS – probably Task Manager ormmcon Windows and maybetopon MacOS as well? You may know better then me if you’re accustomed to that platform.I can maybe try to give some better suggestions if you can list any of the OS being used, what GPU you’re running it on, and if you can, how much VRAM and RAM is on the system and if you can determine how much is being used.
Thank you so much for that wonderful information! No joke!
I’ll have some new things to test when I actually start generating. I’m doing the local generation in Linux. I have a 12GB GPU, 32GB ram, so I know about some slowdowns.
But, I was talking specifically about ComfyUI, the native web app that you launch in a browser. I can work with it for a little bit, but once I stay in the window too long (even without generating), it starts flipping frames between the nodes and a different set of nodes.
Not sure what that issue is. Can’t even save or load workspaces properly… I’m going to blame the Snap Firefox I’m using… Maybe I’ll try something else that’s not a Snap, or a Flatpak.
Yeah, I don’t know what would cause that. I use it in Firefox.
Maybe try opening it in Chromium or a private window to disable addons (if you have your Firefox install set up not to run addons in private windows?)
I’m still suspicious of resource consumption, either RAM or VRAM. I don’t see another reason that you’d suddenly smack into problems when running ComfyUI.
I’m currently running ComfyUI and Firefox and some relatively-light other stuff, and I’m at 23GB RAM used (by processes, not disk caching), so I wouldn’t expect that you’d be running into trouble on memory unless you’ve got some other hefty stuff going on. I run it on a 128GB RAM, 128GB paging NVMe machine, so I’ve got headroom, but I don’t think that you’d need more than what you’re running if you’re generating stuff on the order of what I am.
goes investigating
Hmm. Currently all of my video memory (24GB) is being used, but I’m assuming that that’s because Wayland is caching data or something there. I’m pretty sure that I remember having a lot of free VRAM at some point, though maybe that was in X.
considers
Let me kill off ComfyUI and see how much that frees up. Operating on the assumption that nothing immediately re-grabs the memory, that’d presumably give a ballpark for VRAM consumption.
tries
Hmm. That went down to 1GB for non-ComfyUI stuff like Wayland, so ComfyUI was eating all of that.
I don’t know. Maybe it caches something.
experiments further
About 17GB (this number and others not excluding the 1GB for other stuff) while running, down to 15GB after the pass is complete. That was for a 1280x720 image, and I was loading the SwinIR upscaler; while not used, it might be resident in VRAM.
goes to set up a workflow without the upscaler to generate a 512x512 image
Hmm. 21GB while running. I’d guess that ComfyUI might be doing something to try to make use of all free VRAM, like, do more parallel processing.
Lemme try with a Stable Diffusion-based model (Realmixxl) instead of the Flux-based Newreality.
tries
About 10GB. Hmm.
kagis
https://old.reddit.com/r/comfyui/comments/1adhqgy/how_to_run_comfyui_with_mid_vram/
It sounds like ComfyUI also supports the
--midvramand--lowvramflags, but that it’s supposed to automatically select something reasonable based on your system. I dunno, haven’t played with that myself.tries --lowvram
I peak at about 14GB for ComfyUI at 512x512, was 13GB for most of generation.
tries 1280x720
Up to 15.7GB, down to 13.9GB after generation. No upscaling, just Newreality.
Hmm. So, based on that testing, I wouldn’t be incredibly surprised if you might be exhausting your VRAM if you’re running Flux on a GPU with 12GB. I’m guessing that it might be running dry on cards below 16GB (keeping in mind that it looks like other stuff is consuming about 1GB for me). I don’t think I have a way to simulate running the card with less VRAM than it physically has to see what happens.
Keep in mind that I have no idea what kind of memory management is going on here. It could be that pytorch purges stuff if it’s running low and doesn’t actually need that much, so these numbers are too conservative. Or it could be that you really do need that much.
Here’s a workflow (it generates a landscape painting, something I did a while back) using a Stable Diffusion XL-based model, Realmixxl (note: model and webpage includes NSFW content), which ran with what looked like maximum VRAM usage of about 10GB on my system using the attached workflow prompt/settings. You don’t have to use Realmixxl, if you have another model, should be able to just choose that other one. But maybe try running it, see if those problems go away? Because if that works without issues, that’d make me suspicious that you’re running dry on VRAM.
realmixxx.json.xz.base64
EDIT: Keep in mind that I’m not an expert on resource consumption on this, haven’t read material about what requirements are, and there may be good material out there covering it. This is my ad-hoc, five-minutes-or-so-of testing; my own solution was mostly to just throw hardware at the problem, so I haven’t spent a lot of time optimizing workflows for VRAM consumption.
EDIT2: Some of the systems (Automatic1111 I know, dunno about ComfyUI) are also capable, IIRC, of running at reduced precision, which can reduce VRAM usage on some GPUs (though it will affect the output slightly, won’t perfectly reproduce a workflow), so I’m not saying that the numbers I give are hard lower limits; might be possible to configure a system to operate with less VRAM in some other ways. Like I said, I haven’t spent a lot of time trying to drive down ComfyUI VRAM usage.
I’ll definitely give that a shot!
That said, it’s just ComfyUI behaving this way. Nothing is loaded, no LLMs, just the UI node editor with nodes connected.
The nodes are asking for the appropriate files, but I haven’t selected them. This happens.
Then, even when I have selected the files, it also misbehaves.
Not even generating anything. No input was given. I have also tried the ComfyUI fox girl node layout by dragging the image into the ComfyUI window. It can also wig out weirdly.
The generator queue is idling as per normal.
Anywho, thanks again! I’m going to try a different browser and maybe update the repository again.
Oh, okay, then I’m probably wrong on VRAM, then. On my system, it needs to actually run the nodes before the VRAM gets allocated. Sorry! I thought I had it…
No worries! You gave me a LOT of information that I actually needed otherwise. Like the console commands. :D
I may need to try another variation of the CivitAI Flux Dev model. I had the low memory one, and the other bits and bobs, but it would freeze my computer solid. I’ll try your tips when that happens! Your information will also be extremely useful for others!!
You did a good job! :)