Allow multiple Model Types for the same model space

[thojmr]

Hey, there!

Lately I'm finding myself making multiple models (Dreambooth, LoRA, Native) with the same dataset since each has its own benifits. I would like to keep them all under a single model space https://civitai.com/models/<modelid>/ but you can only select a single model type per space.

In my case I have both dreambooth and LoRA implementations of my models, and don't want to have 2 separate spaces for each. If we could select the Model Type per version, that would be great.

[Jonseed]

I also think it would be helpful to know what kind of model each checkpoint is, whether it is a brand new finetuning, a dreambooth training, a merge of other models, a mix of the above, etc. Currently, you don't know what kind of checkpoint each model is on Civitai, or the origins of each model, how it was trained or created.

[JustMaier]

We've got something like this on our roadmap. We wanted to wait until we had a way for people to actually report the content of their merges, but we got hung up on how that UI might work and how hard it would be for people to do it if they had a complicated mega merge (which is increasingly common).

I'll see if we can't just push out the ability to at least designate the type of checkpoint.

[JustMaier]

This would be a pretty big change that would require quite a bit of downstream changes as well (thinking of people that have integrated using our API). That said, I understand why you'd want to do this.

There's another feature in the works that I think partial solves this. We're calling it "Resource Packs", it will allow creators to bundle multiple models into a pack. The packs will then show up on the model page for each model in the pack. This would allow you to "connect" the various types of the same "model". Probably not as ideal as having the various types in a single model, but at least it gives you a way to connect them in some way.

[thojmr]

Sounds like a neat feature, but yea not quite what I was hoping for, but I understand not wanting to break existing systems for a change like this. Maybe one day we'll get an API-v2 :)