InvokeAI/invokeai/backend/model_management
2024-02-14 16:13:11 -05:00
..
models This seems to work now 2024-01-30 21:32:08 -05:00
__init__.py fix(backend): fix unintentional change to import orders 2023-11-21 20:22:27 +11:00
convert_ckpt_to_diffusers.py Fix broken import in checkpoint_convert (#5635) 2024-02-04 12:56:51 +00:00
detect_baked_in_vae.py Only replace vae when it is the broken SDXL 1.0 version 2024-01-06 14:06:47 -05:00
libc_util.py (minor) clean up typos. 2023-10-03 15:00:03 -04:00
lora.py Skip weight initialization when resizing text encoder token embeddings to accomodate new TI embeddings. This saves time. 2024-01-05 15:16:00 -05:00
memory_snapshot.py Update get_pretty_snapshot_diff(...) to handle None-snapshots. 2023-11-02 19:20:37 -07:00
model_cache.py chore: ruff format 2023-11-11 10:55:40 +11:00
model_load_optimizations.py chore: ruff check - fix flake8-bugbear 2023-11-11 10:55:28 +11:00
model_manager.py Retain suffix (.safetensors, .bin) when renaming a checkpoint file or LoRA 2024-01-16 17:27:50 -05:00
model_merge.py chore: ruff check - fix flake8-comprensions 2023-11-11 10:55:23 +11:00
model_probe.py Enable correct probing of LoRA latent-consistency/lcm-lora-sdxl (#5449) 2024-01-08 17:18:26 -05:00
model_search.py chore: ruff format 2023-11-11 10:55:40 +11:00
README.md Add README with info about glib memory fragmentation caused by the model cache. 2023-10-03 14:25:34 -04:00
seamless.py possible fix: Seamless not working with Custom VAE's 2024-02-14 16:13:11 -05:00
util.py fix comment 2023-12-15 00:25:27 -05:00

Model Cache

glibc Memory Allocator Fragmentation

Python (and PyTorch) relies on the memory allocator from the C Standard Library (libc). On linux, with the GNU C Standard Library implementation (glibc), our memory access patterns have been observed to cause severe memory fragmentation. This fragmentation results in large amounts of memory that has been freed but can't be released back to the OS. Loading models from disk and moving them between CPU/CUDA seem to be the operations that contribute most to the fragmentation. This memory fragmentation issue can result in OOM crashes during frequent model switching, even if max_cache_size is set to a reasonable value (e.g. a OOM crash with max_cache_size=16 on a system with 32GB of RAM).

This problem may also exist on other OSes, and other libc implementations. But, at the time of writing, it has only been investigated on linux with glibc.

To better understand how the glibc memory allocator works, see these references:

Note the differences between memory allocated as chunks in an arena vs. memory allocated with mmap. Under glibc's default configuration, most model tensors get allocated as chunks in an arena making them vulnerable to the problem of fragmentation.

We can work around this memory fragmentation issue by setting the following env var:

# Force blocks >1MB to be allocated with `mmap` so that they are released to the system immediately when they are freed.
MALLOC_MMAP_THRESHOLD_=1048576

See the following references for more information about the malloc tunable parameters:

The model cache emits debug logs that provide visibility into the state of the libc memory allocator. See the LibcUtil class for more info on how these libc malloc stats are collected.