Open JohnTigue opened 1 year ago
It may well be that this dockerized repo I'm playing with is well organized enough that it is not downloading the large model checkpoints twice, once for A1111 and once for InvokeAI:
$ tree
.
├── LICENSE
├── README.md
├── data
│ ├── BLIP [error opening dir]
│ ├── BSRGAN [error opening dir]
│ ├── Codeformer [error opening dir]
│ ├── Deepdanbooru [error opening dir]
│ ├── ESRGAN [error opening dir]
│ ├── GFPGAN [error opening dir]
│ ├── Hypernetworks [error opening dir]
│ ├── LDSR [error opening dir]
│ ├── MiDaS [error opening dir]
│ ├── RealESRGAN [error opening dir]
│ ├── ScuNET [error opening dir]
│ ├── StableDiffusion [error opening dir]
│ ├── SwinIR [error opening dir]
│ ├── VAE [error opening dir]
│ ├── config [error opening dir]
│ └── embeddings [error opening dir]
├── docker-compose.yml
├── output
└── services
├── AUTOMATIC1111
│ ├── Dockerfile
│ ├── config.json
│ ├── entrypoint.sh
│ └── info.py
├── download
│ ├── Dockerfile
│ ├── checksums.sha256
│ ├── download.sh
│ └── links.txt
├── invoke
│ ├── Dockerfile
│ ├── entrypoint.sh
│ └── models.yaml
└── sygil
├── Dockerfile
├── info.py
├── mount.sh
├── run.sh
└── userconfig_streamlit.yaml
How to share the models folder between A1111 and InvokeAI. This is great news. First we don't have to have two copies of the same huge library of models in the file system. But, this also means that I can have both A1111 and Invoke running on the same instance. Sure a user can only use one at a time, but there will be no one else on the system, so no fighting over resources between users. This simplifies this first round of deploy; before this I needed to ask users which machine to spin up. Now we can just have 3 ports open, say:
(Note that once again we see that having the web server layer separate from the render cluster is the way to go.)
More evidence keeps piling up that what the world needs is an SD service architecture which separates the web server from the render cluster. I guess that could be done in some cloud agnostic way, but that's not our current problem. We want it on AWS, but even there this architectural refinement would be very valuable because the render cluster could be autoscaled to zero$$$.
Starting to look like this should be mountable as a Docker volume. It will be a large (few dozen) collection of models (many of which are on the order of 5GB). We download and vet them, then they can be optionally loaded into any Workstation instance.
Even the base models are just more *.ckpt
files. Parking those in S3 and not in Docker images would make for much smaller Docker images.
In the docker-compose.yml, the output
and data
volumes are defined:
https://github.com/AbdBarho/stable-diffusion-webui-docker/blob/master/docker-compose.yml#L8
We'll want to turn those into S3 storage, not mapped to local FS.
This redownloading of 10s and soon 100s of GB of models is becoming a hassle. This Issue should get taken care of, at least a first pass.
Anders and Eleanore both like RPG model. So, add it to the model library.
For Auto1111, how to point to where the library is (don't want multiple copies of ~6G files in the library used by 3 different webUIs. https://www.reddit.com/r/StableDiffusion/comments/120r2qi/just_learned_that_you_can_move_the_lora_folder_to/
These things are large, ~4GB. We are going to want a library and something to manage the library.
These models are sizable. Full models are between 3 and 10 gigabyte, on average. And we'll be adding all manner of finetunings, which can also be gigabytes, or just kilobytes. It is not clear to me yet that those should be in the Docker images. And then there is the matter of storing the generated images. What about backing up the file systems?