• Stefy Lanza (nextime / spora )'s avatar
    lora-train: evict co-located sibling engine's VRAM before training (fix OOM) · e300e9c4
    Stefy Lanza (nextime / spora ) authored
    LoRA training freed VRAM with unload_all_models(), which only unloads THIS
    engine's models. On the GGUF-isolation split the co-located gguf (text) engine
    kept its model resident (~7.4 GB), so fp32 training (~16 GB) + the sibling
    exceeded the 24 GB card → "CUDA out of memory. Tried to allocate 32 MiB … 26 MiB
    free … Process 226 has 7.36 GiB" — every fighter LoRA (dlaba, zigo, zlo, …)
    failed. Training also isn't covered by the front swap-gate, so nothing else
    cleared the sibling.
    
    Add multi_model_manager.evict_cosited_siblings(): invoke the registered
    cross-engine VRAM releasers (the cosite releaser posts wait=True, so it waits for
    a busy sibling to reach a safe point). Call it right after unload_all_models() in
    both training paths (image + video/Wan), so training gets the whole card.
    Co-Authored-By: 's avatarClaude Opus 4.8 <noreply@anthropic.com>
    Claude-Session: https://claude.ai/code/session_01RdMufYvtTbtGDWsiZVoXce
    e300e9c4
Name
Last commit
Last update
..
admin Loading commit data...
api Loading commit data...
backends Loading commit data...
broker Loading commit data...
frontproxy Loading commit data...
models Loading commit data...
openai Loading commit data...
pydantic Loading commit data...
queue Loading commit data...
tasks Loading commit data...
__init__.py Loading commit data...
cli.py Loading commit data...
config.py Loading commit data...
main.py Loading commit data...
platform_paths.py Loading commit data...
system_app.py Loading commit data...