WanVideo Torch Compile Settings

This node doesn't generate anything. It's a settings bundle: you configure how torch.compile should JIT-compile the Wan transformer, and hand the resulting WANCOMPILEARGS to the compile_args input on the model loader (or the VAE loader). When it's wired in, the wrapper attempts to compile the selected layers, and you get a per-frame speed improvement for the rest of the run.

It's one of the standard acceleration techniques for Wan, stacked alongside SageAttention and caching. The catch is the entry fee, and the node states it plainly in its own description: requires Triton, and torch > 2.7.0 is recommended. Triton on Linux is usually fine; Triton on Windows is the thing that eats an afternoon. If you can't get it installed, TorchCompile simply isn't your speedup - reach for block swap and fp8 instead.

How it works

torch.compile traces the model's graph and fuses operations into optimized kernels. The first run pays a compile cost - the model gets noticeably slower to start - and every run after that is faster because the compiled kernels are cached. For video, where you're doing many denoising steps over many frames, that per-step saving adds up.

By default the node compiles only the transformer blocks (compile_transformer_blocks_only is true), which is the sweet spot: most of the compute lives there, and compiling the whole model invites more recompiles and fragile edge cases for little extra gain.

The inputs that matter

• mode - default is safe. max-autotune searches harder for fast kernels and can squeeze out more speed at the cost of a much longer first-run compile. Try default first; only reach for autotune if you're doing long batches where the warm-up amortizes.
• backend - inductor is the one you want. cudagraphs is situational.
• compile_transformer_blocks_only - leave it on true. This is the setting that keeps compile times sane.
• dynamo_cache_size_limit / dynamo_recompile_limit - guardrails on how many compiled variants Dynamo keeps. If your resolution or frame count changes between runs and you see repeated recompiles, these are the knobs, but the defaults (64 / 128) cover most people.

Output is a single WANCOMPILEARGS.

How to install it

Part of the pack. Via ComfyUI Manager: search WanVideo Wrapper, install, restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/kijai/ComfyUI-WanVideoWrapper
pip install -r ComfyUI-WanVideoWrapper/requirements.txt

then restart. The node ships with the pack, but the actual dependency - Triton and a recent PyTorch - is on you to have in your environment.

Common issues & troubleshooting

"Triton not found" or a compile error on first run. This is the big one. TorchCompile needs Triton installed and a torch build new enough (>2.7 recommended). On Windows you'll likely need a community Triton wheel. No Triton, no compile - unplug this node and the workflow still runs, just without the speedup.

The first generation is slower, not faster. Expected. That's the compile pass. The payoff shows up on the second and subsequent runs with the same shape.

Constant recompiling. If you change width, height, or frame count every run, Dynamo recompiles each time and you never bank the speedup. Keep your output shape stable across a batch, or raise the recompile limit. dynamic can help here but often costs more than it saves - leave it off unless you've measured a win.

It fights with an unmerged LoRA. If you're compiling with LoRAs that aren't merged into the weights, you may need allow_unmerged_lora_compile. Simpler path: let your LoRA node merge (its default) so compile sees stable weights.