Hello. So currently I have separate deployments for each model version (SD 1.4, 1.5, 2.0, finetunes, etc.).
I was wondering if this is the best practice?
From what I understand having separate deployments is best due to banana’s optimization and the due to having to cold boot the model into memory each time.
It is really not a problem, its just become a little disorganized in banana’s current dashboard with having 10+ deployments. Wondering if there is a better way I am missing.
1 Like
Hey @coffeeorgreentea, welcome to the forums 
Yup, you’re absolutely right… this is indeed the best practice for all the reasons you mention (optimization, faster cold boots) and also that switching models at runtime wastes a lot of time too (although this is so much faster in the latest dev releases that it may be worth revisiting at some point).
Requests to rename models have come up on the discord a few times, and banana has agreed, but I dunno, I feel like all these things get lost on chat… so I added it here it now here too:
That would certainly help to keep things more organised. I haven’t switched over to using the dashboard build vars yet (mostly because I understand you still have to push a commit each time to trigger a rebuild after updating them anyway), so I still have like 12 “sub-repos” that differ only in build-vars set via the Dockerfile.
In docker-diffusers-api there’s a whole “permutation system” that helps manage this, the idea is that all the subrepos have the original repo set as upstream, so can easily merge in the latest changes each time. And each sub repo has an appropriate name that makes it easy to see, e.g. sd-v1-5, sd-waifu-v1-3, sd-v2 etc.
The permute.sh script sets these up for you based on your config in permutations.yaml. Currently merging is by hand (as per Keeping forks up to date in the README), but I might integrate this into the script too if there’s no more short-term progress on banana’s side (to rename models, and re-deploy more easily when changing build vars).
That’s how I’m doing it at least. If anyone has any other input, it would be great to hear!
1 Like
Awesome thanks for the info.
mostly because I understand you still have to push a commit each time to trigger a rebuild after updating them anyway
This explains the trouble I was having with build args lol. Going to try using build args tomorrow
1 Like