Musubi Memory Settings (Wan)

This is the node that makes the pack's headline trick work. MusubiMemorySettings (display "Musubi Memory Settings (Wan)") controls musubi-tuner's signature memory feature: block swapping, where chunks of the model get offloaded to CPU/disk during training to free up VRAM. It's the reason kohya-ss/musubi-tuner's docs can promise 720×1280 image training on 24GB - and why a 14B Wan can train on a card that would otherwise be laughably short of memory.

It's another settings factory: no model loading, no training. You set two knobs, it emits a memory_settings DICT, and you plug that into the WanLoRATrainer node's optional memory_settings input. Bypass it if you have plenty of VRAM - the README says so outright, and it's the honest advice. Block swap exists to trade memory for time, so if you're not memory-bound, you're just slowing yourself down.

How it works

The node builds a dict from your two inputs and filters out the "off" values, exactly like its compile sibling: blocks_to_swap is only emitted if greater than 0, and the offload flag only if True. The dict gets merged into the trainer's argument set, so the values land as --blocks_to_swap N and --img_in_txt_in_offloading on the training subprocess. Under the hood, musubi's custom offloading moves transformer blocks out of GPU memory when they're not being used for the current training step and swaps them back in as needed.

The inputs

• blocks_to_swap - 0 to 100, default 0 (off). This is the whole node. The tooltip gives you the ceilings: 1.3B models max out around 30, 14B models around 40. Start low and raise until your run stops OOMing - more blocks swapped = more VRAM saved, but each swapped block means a slow trip to system RAM and back on every step, so the training time climbs with it.
• img_in_txt_in_offloading - off by default. Offloads the image/text embeddings to system RAM to save GPU memory. A secondary lever for when block swap alone isn't enough.

Output

One output: memory_settings (DICT) → the trainer's memory_settings input.

Install

Ships with the pack:

cd ComfyUI/custom_nodes
git clone https://github.com/jaimitoes/ComfyUI_Wan2_1_lora_trainer
..\..\..\python_embeded\python -m pip install -r requirements.txt

restart, and launch via the README's .bat (Visual Studio Build Tools via vcvarsall.bat, plus Include_and_libs.zip extracted into python_embeded) - the memory-offload path is one of the bits that depends on that environment being right.

Where people get burned

Two classic mistakes. First, cranking blocks_to_swap to the max "for safety" and then wondering why training takes five times as long - find the smallest value that fits, not the largest. Second, forgetting that block swap interacts with the attention backend: the README's warning is blunt - don't use SageAttention, it "burns the LoRA." If you're tuning memory to squeeze a 14B run onto a 24GB card, use SPDA or XFORMERS as your attention, keep blocks_to_swap around 30-40, and let the swap do the heavy lifting. Also worth noting: community reports on training 14B Wan are split between "needs ~48GB" and "fine on a 5090 with recommended settings" - the swap settings are exactly what reconciles those two experiences.