5 minutes ago, mickr777 said:

Ok, try replacing the invokeai.yaml under userfiles with this file

invokeai.yaml 151 B · 0 downloads

I tried this, but issue still remains the same.

The userfiles is located in a separate share, as I do not want to fill up appdata with the images.

It's mounted under: /mnt/user/ai_images/

And the owner for this share is the same as the other folders:

21 minutes ago, GnaXi said:

I tried this, but issue still remains the same.

The userfiles is located in a separate share, as I do not want to fill up appdata with the images.

It's mounted under: /mnt/user/ai_images/

And the owner for this share is the same as the other folders:

that should be fine as my userfiles are on the array, not in appdata

Edited May 29, 20242 yr by mickr777

2 hours ago, mickr777 said:

that should be fine as my userfiles are on the array, not in appdata

Then I'm still puzzled by what could be causing the issue

9 hours ago, GnaXi said:

Then I'm still puzzled by what could be causing the issue

So am I maybe just as test set it back to a empty userfiles under appdata, see if it still does it

On 5/30/2024 at 12:08 AM, mickr777 said:

So am I maybe just as test set it back to a empty userfiles under appdata, see if it still does it

That did the trick! There must have been something in my userfiles that the latest version didn't like. Thanks!

Hey @mickr777,

 

Any plans to do the same for the training repo? https://github.com/invoke-ai/invoke-training

 

Also, you should promote the InvokeAi to a Community App. It is an awesome tools and Image and Template are mature enough. It is really helpful 

 

Thanks!

21 hours ago, luisalrp said:

Hey @mickr777,

 

Any plans to do the same for the training repo? https://github.com/invoke-ai/invoke-training

 

Also, you should promote the InvokeAi to a Community App. It is an awesome tools and Image and Template are mature enough. It is really helpful 

 

Thanks!

 

Ok made it for the training ui, port 1234 is the training ui, port 2345 is the tensorboard ui to watch progress of training

my-Invoke-training.xml

 

Edited June 1, 20242 yr by mickr777

If anyone is still using this docker besides me, since there is official unraid docker in the community app plugin.

 

the latest update i just pushed to this docker will require you to go back to port 9090, (this is to avoid a slow down in the dev ui on port 5173)

 

 

Edited August 17, 20241 yr by mickr777

I am VERY new to InvokeAI and just wanted to know does InvokeAI docker container with unraid support 2 GPU's to gain additional VRAM?   I wanted to do a test with 2 P2000 Quatro PRO cards with 5G VRAM each (so I would have a total of 10G VRAM.   I added the GPU All line but not sure what else is needed (--runtime=nvidia --gpus=all)

On 12/12/2024 at 12:03 PM, GeorgeJetson20 said:

I am VERY new to InvokeAI and just wanted to know does InvokeAI docker container with unraid support 2 GPU's to gain additional VRAM?   I wanted to do a test with 2 P2000 Quatro PRO cards with 5G VRAM each (so I would have a total of 10G VRAM.   I added the GPU All line but not sure what else is needed (--runtime=nvidia --gpus=all)

sadly no, Invokeai it self doesn't support multiple gpus

Does Stable Diffusion support multi GPU's?   Trying to find a use for the 2nd P2000

I'm seeing consistent OOM errors when trying to do image-to-image workflows. As an example, I have a photo that I am trying to re-stylize into more of a cartoony caricature. The photo is resized to ~1800x1000, and when using the Flux image-to-image it OOM errors almost immediately. This is regardless of using the quantized or full version of Flux-dev.
Card is a Tesla P40, so I have 24GB of VRAM, which I'd expect to be plenty as long as I utilize the low-vram settings in the config yaml (which I do).

torch.OutOfMemoryError: CUDA out of memory. Tried to allocate 3.38 GiB. GPU 0 has a total capacity of 23.87 GiB of which 975.62 MiB is free. Process 28644 has 22.92 GiB memory in use. Of the allocated memory 19.50 GiB is allocated by PyTorch, and 3.24 GiB is reserved by PyTorch but unallocated. If reserved but unallocated memory is large try setting PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True to avoid fragmentation.  See documentation for Memory Management  (https://pytorch.org/docs/stable/notes/cuda.html#environment-variables)

[2025-02-04 09:10:38,173]::[InvokeAI]::INFO --> Graph stats: 267ffbbe-02de-42ab-a12d-7d2859f9fbad
                          Node   Calls   Seconds  VRAM Used
             flux_model_loader       1    0.003s    18.094G
               flux_vae_encode       1    0.855s    22.497G
TOTAL GRAPH EXECUTION TIME:   0.858s
TOTAL GRAPH WALL TIME:   0.863s
RAM used by InvokeAI process: 30.17G (+0.000G)
RAM used to load models: 0.16G
VRAM in use: 17.988G
RAM cache statistics:
   Model cache hits: 1
   Model cache misses: 0
   Models cached: 14
   Models cleared from cache: 0
   Cache high water mark: 26.71/0.00G

I'm at a loss of why it doesn't seem to be offloading to system RAM. I expect the slowdown, but I have manually assigned 128GB of my 256GB total, which should be WAY more than enough...

I can successfully generate text images, but even those at 1024x1024 can be slightly iffy using Flux.

Any help is appreciated. I'm very new to this...
 

Edited February 4, 20251 yr by MOEman365

3 hours ago, MOEman365 said:

I'm seeing consistent OOM errors when trying to do image-to-image workflows. As an example, I have a photo that I am trying to re-stylize into more of a cartoony caricature. The photo is resized to ~1800x1000, and when using the Flux image-to-image it OOM errors almost immediately. This is regardless of using the quantized or full version of Flux-dev.
Card is a Tesla P40, so I have 24GB of VRAM, which I'd expect to be plenty as long as I utilize the low-vram settings in the config yaml (which I do).

torch.OutOfMemoryError: CUDA out of memory. Tried to allocate 3.38 GiB. GPU 0 has a total capacity of 23.87 GiB of which 975.62 MiB is free. Process 28644 has 22.92 GiB memory in use. Of the allocated memory 19.50 GiB is allocated by PyTorch, and 3.24 GiB is reserved by PyTorch but unallocated. If reserved but unallocated memory is large try setting PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True to avoid fragmentation.  See documentation for Memory Management  (https://pytorch.org/docs/stable/notes/cuda.html#environment-variables)

[2025-02-04 09:10:38,173]::[InvokeAI]::INFO --> Graph stats: 267ffbbe-02de-42ab-a12d-7d2859f9fbad
                          Node   Calls   Seconds  VRAM Used
             flux_model_loader       1    0.003s    18.094G
               flux_vae_encode       1    0.855s    22.497G
TOTAL GRAPH EXECUTION TIME:   0.858s
TOTAL GRAPH WALL TIME:   0.863s
RAM used by InvokeAI process: 30.17G (+0.000G)
RAM used to load models: 0.16G
VRAM in use: 17.988G
RAM cache statistics:
   Model cache hits: 1
   Model cache misses: 0
   Models cached: 14
   Models cleared from cache: 0
   Cache high water mark: 26.71/0.00G

I'm at a loss of why it doesn't seem to be offloading to system RAM. I expect the slowdown, but I have manually assigned 128GB of my 256GB total, which should be WAY more than enough...

I can successfully generate text images, but even those at 1024x1024 can be slightly iffy using Flux.

Any help is appreciated. I'm very new to this...
 

its related to the new memory caching changes in invoke,

https://invoke-ai.github.io/InvokeAI/features/low-vram/

Try adding

max_cache_vram_gb:0.1

to your invokeai.yaml file under userfiles in the dockers appdata folder for a test (this disables vram caching of models)

see if that helps, if it does try some of the other options in the above link.

 

you probably dont need to go this far with 24gb vram, but I can load and use the full flux dev model and full text encoder with 12gb vram now, on my laptop using:

attention_type: torch-sdp
enable_partial_loading: true
force_tiled_decode: true
keep_ram_copy_of_weights: false
device_working_mem_gb: 12

there is a trade off with partial loading and tiled decode, as does slow it down a little
and if you have loads of ram dont worry about keep ram copy false,

Edited February 4, 20251 yr by mickr777

Wow, just limiting VRAM cache seems to have done it! Thank you so much!
If I can impose a bit more... Can you explain what exactly what the max_cache_vram limit is doing? I clearly don't understand it, as I would expect you want that number to be high, but less than the GPU memory, ie 20GB for my 24GB card. Setting it to 100MB feels very counterintuitive. So if I want to utilize more of my VRAM, can I increase that number? It seems to be working well, and <7GB in VRAM, so now I'm looking to speed up if I can.

2 hours ago, MOEman365 said:

Wow, just limiting VRAM cache seems to have done it! Thank you so much!
If I can impose a bit more... Can you explain what exactly what the max_cache_vram limit is doing? I clearly don't understand it, as I would expect you want that number to be high, but less than the GPU memory, ie 20GB for my 24GB card. Setting it to 100MB feels very counterintuitive. So if I want to utilize more of my VRAM, can I increase that number? It seems to be working well, and <7GB in VRAM, so now I'm looking to speed up if I can.

Max vram cache is how much vram invoke can use to cache models in for repeated uses.

Eg not off load them to ram and keep in vram.

 

Setting it too high doesn't leave room for invoke to use when working and can cause OOM errors.

 

60-70% of your vram for cache  is what I found ideal, the 100mb was just to disable it and see if that was the cause

 

Working ram does nearly the same thing, but it tells invoke how much vram you want to keep free to use when working.

I have set my to 12gb as I use some node that don't use the caching system and avoids OOM when there used

Edited February 5, 20251 yr by mickr777

Base image updated to Ubuntu 24.04
for Python 3.12

To avoid errors, you’ll need to manually delete the following folders before restarting the docker:

• /mnt/cache/appdata/invokeai/venv

• /mnt/cache/appdata/invokeai/invokeai

Do not delete your /mnt/cache/appdata/invokeai/userfiles folder — this contains your model, database, output images

Once removed, restart the docker and it will automatically clone the git and rebuild the venv and frontend files

Edited June 7, 20251 yr by mickr777

PermissionError: [Errno 13] Permission denied: '/invokeai_root/invokeai.example.yaml'

Just doesn't work.

Every time I fix permissions, it overwrites them.

52 minutes ago, CasaP said:

PermissionError: [Errno 13] Permission denied: '/invokeai_root/invokeai.example.yaml'

Just doesn't work.

Every time I fix permissions, it overwrites them.

Is there a reason your want to edit that file?

if its to change config it should be in the userfiles/invokeai.yaml file
and permissions changed in the file manager in unraid ui to read/write

(btw this docker is not the same as the one in the community apps)

Edited August 31, 2025Aug 31 by mickr777