There is an (admittedly jank) workaround to the OOM issue going around.

[RealSourceOfficial]

For any new users, do note initial usage only ramps up AFTER an image is generated, so restarting SD without generating any images does not affect the initial VRAM usage.

Using some command line magic, I've found removing the venv folder on launch reduces the initial VRAM usage. (On my card, normal startup uses 2GB/4GB VRAM, rendering me unable to generate images) This makes it possible to generate images at resolutions like 512x768 with a RX580 4GB card, without running out of VRAM

However, by adding rmdir /s /q venv to the webui-user.bat, I've found that the initial VRAM cost drops from 2GB to about 1GB. Yes, it does take a few more minutes to open SD, however, it's a very temporary fix until the memory leaks can be fixed.

This is most notably a problem while generating large images with something like Tiled Diffusion, where you as much VRAM as you can get (Tiled VAE is almost required to generate images larger than 512x512 in my case)

(my) webui-user.bat:

@echo off

:: temporary optimization to reduce VRAM usage on startup
:: fixes issue where SD starts using (observed from 4GB card) half of VRAM
rmdir /s /q venv

set PYTHON=
set GIT=
set VENV_DIR=
set COMMANDLINE_ARGS=--lowvram --precision full --no-half --no-half-vae --opt-split-attention-invokeai --always-batch-cond-uncond --opt-sub-quad-attention --sub-quad-q-chunk-size 512 --sub-quad-kv-chunk-size 512 --sub-quad-chunk-threshold 80 --disable-nan-check --upcast-sampling
set SAFETENSORS_FAST_GPU=1

call webui.bat

[RealSourceOfficial]

I'm currently investigating any ways to improve the loading times so as to not delete the entire venv directory, as it was an initial step to see if the VRAM would even be affected. (which is why I posted asap; it worked.)

Upon some further inspection, the effects vary, and the VRAM appears to be only visually reduced. However, it's a step in the right direction, and seems to open a few possibilities.