Musubi Compile Settings (Wan)

MusubiCompileSettings is the optional performance-tuning node in jaimitoes/ComfyUI_Wan2_1_lora_trainer. It doesn't do anything by itself - it's a settings factory that produces a DICT of compilation and precision flags, which you feed into the WanLoRATrainer node's compile_settings input. What it controls: whether training runs in FP8 to save VRAM, and whether PyTorch's Dynamo JIT compiler gets a shot at making the long 14B training runs faster.

The honest take: for most people this node should stay at its defaults (which is to say, effectively off). Torch.compile has the biggest payoff on long, repeated training loops on big models - a 14B run where the same graph executes thousands of times. On a 1.3B model or a short run, the compile warmup can eat more time than the optimization saves, and you're adding a layer of things that can silently go wrong. The README's own advice: if you have high VRAM, bypass the compile settings entirely.

How it works

The node collects your choices and filters out the "off" values - if dynamo_backend is NO or dynamo_mode is default, it drops them from the dict rather than passing explicit "off" flags to the trainer subprocess. This matters because musubi's CLI flags are mostly store_true switches; passing --fp8_base False would be an error, so the node omits the flag entirely when it's False. The resulting compile_settings DICT is merged into the trainer's argument dict before the subprocess launches.

The inputs that matter

• fp8_base - FP8 for the base model. Requires hardware that supports it, and it pairs with FP8 (e4m3fn) checkpoint variants of the DiT. This is the one that actually saves VRAM.
• fp8_scaled - FP8 scaled training. Here's the trap: musubi's own wan docs say fp8_scaled model weights aren't supported even with --fp8_scaled, so this flag only helps with certain model dtype + training dtype combos. If you're not sure you need it, you don't.
• dynamo_backend - 16-way enum defaulting to NO. INDUCTOR is the realistic general-purpose choice if you want to actually enable compilation; the NVFUSER/CUDAGRAPHS/TENSORRT options are increasingly niche or hardware-specific.
• dynamo_mode - default / reduce-overhead / max-autotune. max-autotune hunts harder for speed at the cost of longer compile time.
• dynamo_fullgraph / dynamo_dynamic - advanced switches, both off. dynamo_dynamic in particular has a known-problematic track record (musubi's own PR #215 validation flagged dynamic shapes as buggy), so treat it as "only if you know exactly why."

Output

One output: compile_settings (DICT) → the trainer's compile_settings input. Only the flags you actually changed from "off" will be in it.

Install

Part of the pack, so the usual:

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, run via the README's .bat launcher (Visual Studio Build Tools + Include_and_libs.zip into python_embeded).

Where people get burned

Toggling FP8 without the matching model files is the classic one - you flip fp8_base and the trainer chokes because your DiT isn't an FP8 checkpoint. And remember the pack's warning that sits above all the compile tuning: don't use SageAttention. The README says it burns the LoRA. If you're on this node chasing speed, use SPDA (the default) or XFORMERS as the attention backend, not Sage. Compile settings are the last 10% of performance; an overfit or corrupted LoRA costs you the whole run.