Spaces:

Duplicated from  Yntec/ToyWorld

Yntec

/

ToyWorldXL

like 42

Running

Hello. Both NoobAI and Illustrious are basically supposed to be just SDXL models.

ones you uploaded but they don't do anything

That's funny. Maybe I'm making a mistake.

anon4ik/noobaiXLNAIXL_epsilonPred05Version
anon4ik/noobaiXLNAIXL_epsilonPred05Version_diffusers

These are caused by the lack of README.md; even without the contents of README.md, as long as README.md is available, it should work.

Edit:
Right now HF's handling of NFAA models is buggy, so as far as my model is concerned, this may be the reason.
https://discuss.huggingface.co/t/model-is-not-for-all-audiences-error/115236

Thanks, as a workaround I have duplicated 10 of your spaces and moved lines around so the models can the tried out. I appreciate that you brought them here so I can test them out.

...though, with these kind of outputs I think it's probably time to ditch SDXL and move to SD3.5 Large, SD1.5 remains the best in certain aspects, but SDXL looks completely obsoleted for now and a noobAI version of it would look better in all aspects.

as a workaround I have duplicated 10 of your spaces and moved lines around so the models can the tried out.

Nice!

I think it's probably time to ditch SDXL and move to SD3.5 Large

It's time for a generational change in model architecture.
Older architectures have smaller file sizes and a huge amount of existing assets for that reason, so that's useful.
But support for SD3.5 models in Diffusers is not yet as stable as it is for FLUX models.
And if it does stabilize, it will be hard for anyone to get into serious training if they don't know whether Flux or SD3.5 will be mainstream... and Pony's author said he'd use AuraFlow...
All of the next generation models cost so much more money for training than SDXL or SD1.5.

Also, HF's specific situation is that it is very hard to convert SD3.5 and Flux safetensors files to Diffusers format on the site. It's easy if you use a GPU locally, but...

Yeah, despite all the effort put in democratizing AI the distance between the haves and the have nots has increased as people have not found a way to keep models small and can only improve them making them bigger. I saw a graphic the other day showing how Flux is doing mostly nothing with the billions of parameters and one could get like 90% of its quality with 4 billion parameters or something like that, which shows how they wasted a lot of resources, though, apparently to build the small model first you need the big one and then not train the small one with a dataset but to teach it to reproduce the results of the big one with fewer parameters, a parameters distillation similar to Schnell.

Anyway, now this space has been eventually dying with this error:

Apparently other of my spaces have also been dying like this if they've been built after a certain day, I wonder if it's another thing that only affects newly built spaces, sigh

All pure capitalist states and all pure communist/socialist states have perished. The existing system of states is basically a chimera of both, changing only about the rate of blending. Both the U.S. and China.
They had to be patched up shabbily to be useful. Well, democratization is not as simple as the simple principles espoused by thinkers to achieve good results.
If we were talking about technological evolution, the story would be more complicated.

Personally, I think the model architecture that creates a cheap training environment will win in the community; SD1.5 and SDXL simply won the training environment by attracting people with the proliferation of their models.
But it wouldn't be surprising if, for example, a large company came up with some kind of subsidy. There are many ifs and buts.
It could be a future where proprietary models simply win out. I personally am not interested in anything other than a model that allows people to play in a community.

Anyway, now this space has been eventually dying with this error:

Oh, come on...
I've seen similar errors, but this is the first I've seen.
I've been seeing a lot of space errors yesterday and today.
My space didn't start in the morning.

My space is now fixed after rebooting.

Edit:
Not fixed...
https://discuss.huggingface.co/t/space-runs-ok-for-several-hours-then-runtime-error/115638

I think we just need the technology to support the newer models in older hardware and CPU, SD3.5 Medium is not the solution because the model quality suffers, it's steps back behind Flux and SD3.5 Large. A solution would be to make splits of the model and load each as needed, this would cause a great slowdown as each part needs to be unloaded and loaded, but waiting 2 hours for a pic still means you get a pic, unlike now that it's impossible and one relies on ZeroGPU spaces that can't be duplicated to work or modified.

The idea would be to allow merging of newer models and finetuning on a CPU space (image generation takes ages, but merging would be done in a breeze), but there's no much interest because I have only known 3 people, me included, that did those things with older models, others just paid for online GPU to train or even played civitai's mechanics to get free training over there, but it would be wonderful if we got a small model in this tier of performance, I think Liberte Redmond and ZootVision pushed the limits of SD1.5 tech and the only way to move forward will be a different architecture that anyone can train.

Not fixed...

Thanks, it's a relief to know it's not local problem, though, around here we have the saying "only fools get consolation when bad things also happen to many other people", I guess it's a matter of waiting for it to resolve itself. And again, I'm glad it doesn't affect spaces already running, my main spaces remain unaffected and I keep avoiding the bullet every time some error like this creeps in.

The problem with the HF Spaces crashing all the time was apparently a problem with bad clusters in the network. It has improved a lot now. It's not clear whether it was a hardware problem or an extension of a software problem, but it's no wonder that it was a more intense error than usual.😇

we just need the technology to support the newer models in older hardware and CPU

Definitely yes.

A solution would be to make splits of the model and load each as needed

Using only DiT (or UNET, if you're talking about SD or SDXL) has actually become the standard for FLUX.
Even so, it's still 11GB in 8-bit conversion, so it's not practical on older hardware.
The LoRA size would probably be manageable, but LoRA is a difference, not a model itself, so it's not a solution based on training the base model.

The reason why it is not possible to merge models after SDXL in the CPU space of HF, and almost no one tries to do it, is purely due to the lack of CPU space specifications. (16GB RAM and 50GB SSD) Strictly speaking, it is barely possible with SDXL, but it is really on the edge. It is definitely impossible with FLUX.
Even for a simple conversion, I had a hard time.
Also, if you let the CPU generate images for FLUX or SD3.5, it would take an astronomical amount of time. It is possible, though.
However, if HF were to provide GPU resources for free, it would go bankrupt, so we can only hope that large companies like nVidia or countries will provide some resources.
Alternatively, it is also possible to use Google Colab Free (16GB VRAM) in conjunction with it to develop infrastructure for merging and test generation. However, that is still insufficient for FLUX and SD3.5.
It is physically impossible to perform calculations without hardware resources, so there is no solution other than finding a way to perform calculations with fewer hardware resources, or having someone provide hardware resources for free or at a low cost. It may be possible for individuals to contribute to this process...

In summary, the online hardware resources are generally outdated or mismatched for use in the SD3.5 and FLUX eras.

The magic of WebUI CPU is that it worked without needing VRAM, because the GPU wasn't used at all, I get that the time to make an image would be astronomical, perhaps 2 hours per image was too optimistic, but that time is going to pass anyway, so one could be using it for this. My idea is to let memory swapping happen, use what you can on the 16GB RAM available, and use the 50GBSSD as if it was memory. Right now it's not possible because whenever you do anything that fills the ram you get a "connection error", so the UI would need to limit itself in the memory it can use and use the harddrive to store the rest by swapping the memory. I guess I'd be the only person in the world using that! 🤣😂

Anyway, Flux came out of nowhere and SD3.5 Large did too (the announcements of the death of Stability AI were exaggerated) so we just need a new era from a model that is the best of all worlds, or just plug in something to SD1.5 to it can do text and place things where you tell it with good eyes and anatomy (SD3.5 really flopped in this part.)

My idea is to let memory swapping happen, use what you can on the 16GB RAM available, and use the 50GBSSD as if it was memory. Right now it's not possible because whenever you do anything that fills the ram you get a "connection error"

Actually, it is possible to use SSD as virtual memory in HF Spaces.
I have also successfully used CPU space to start WebUI, Forge and ComfyUI. I haven't tried it, but I think it should be possible to merge it with SD1.5 models. What I'm doing is the same as DucHaiten's.
The assumption is that I'm using CPU space, but even so, it's still not enough for FLUX...
Specifically, when processing FLUX models on the CPU, they cannot be quantized, and Diffusers do not support loading on 8-bit memory, so 16-bit precision is required.
In that case, the minimum required RAM (preferably VRAM) is about 30-35GB.
The same is almost true for SD3.5 Large.

The important thing is exactly these numbers, because the required capacity when downloading the model to the SSD is double, so even if you add the size of the RAM and the size of the SSD, it's still a little short. The above is just up to the loading, and you also need a little RAM for the calculation process. The connection error of Gradio or FastAPI occurs 100% at this point. Because the SSD is full, not to mention the RAM!
During merging, the calculation of the contents consumes several times more RAM, so it happens even with the SD1.5 and SDXL models from time to time.
With from_pretrained, the model on HF is loaded directly into RAM, so SSD capacity is not required, and inference barely works even with a total of 66GB, but this makes it impossible to customize the model...
If the SSD were increased by 20GB to 70GB, it might be possible. It would be even better if the RAM were increased.

However, even if it were increased, I don't think I could handle a model of this size with simple tricks.
I doubt that inference would even finish in 12 hours, let alone 2 hours.
It would be really helpful if a better architecture that is compatible with SD1.5 and SDXL were to appear.
In the case of those of us who only have weak GPUs, even the best a GPU for civilians can do is about 16GB of VRAM. You need either a multi-GPU or a professional GPU that is as expensive as an old Apple II. I don't think that kind of architecture will catch on. Training models requires real people with image materials, ideas and a sense of style, so it's hard to make progress if it doesn't catch on. Academics and painters are generally poor.
However, I'm surprised that the anatomical part of SD3.5 is no good. Even that size is no good...
Maybe the amount of training for the actual model is more important than the architecture.

I don't think that kind of architecture will catch on.

And it probably was like this on purpose by Black Forest Labs, not only did they put a licence on the model that forbids anybody to compete against them with a Flux based model, they made it unfeasible with their architecture, anyhow.

I'm surprised that the anatomical part of SD3.5 is no good. Even that size is no good...

I blame lousy training, a model like FennPhoto already shows good anatomy 90% of the time, Dalle 3 goes like 95% good anatomy and perfect eyes and creativity and I don't think they needed more than 4 billions parameters, what they had was a godly dataset, which I suspect was manually tagged (because it doesn't show the problems SD1.5's LAION had, nor the problems tagging with a VLM Flux has), and people that knew how to train a model properly. Stability AI just received another hundred million dollars in funding, so they can do anything, if they can't deliver, it's because of their lack of talent (talent that flew away and went to Black Forest Labs, heh.)

As a user, what I can do now for the Flux generation models is to use various hacked versions of Flux (de-distill, CFG, Lite) for the time being or wait for a properly trained SD3.5.1.
Considering the licensing issue, the latter would be better.