TorchCompileModelWanVideoV2

Straight up: this node is deprecated, and it says so itself. Its description reads "Deprecated, use TorchCompileModelAdvanced instead." If you're building a Wan workflow today, use TorchCompileModelAdvanced. This page exists because the node still turns up in older workflows and tutorials, and you deserve to know what it did and why you shouldn't wire a fresh graph around it.

It's from kijai's KJNodes, the pack that's basically standard issue for Wan video work.

What TorchCompile does, and why people bother

torch.compile is PyTorch's JIT compiler. It traces the model and compiles the hot paths into fused, optimized kernels, which for a big video transformer means a real per-step speedup. The catch is startup overhead: the first run (and any run where the shape changes and it has to recompile) pays a compilation cost before it gets fast. The community's own one-liner for it: "JIT compilation. Startup overhead but per-frame speed improvement." On Wan it's one of the standard acceleration layers people stack alongside SageAttention and a distillation LoRA to make long clips tolerable.

The inputs and outputs that matter

Even though you shouldn't reach for this version, here's what its knobs meant, since they carry over conceptually to the Advanced node:

• model - the model to compile; compiled model out.
• backend (default inductor) - the compile backend. inductor is the standard PyTorch one; cudagraphs is the other choice.
• mode (default default) - the optimization profile: default, max-autotune, max-autotune-no-cudagraphs, or reduce-overhead. max-autotune compiles harder for more speed at the cost of a longer compile.
• compile_transformer_blocks_only (default on) - compiles just the transformer blocks rather than the whole model, which cuts compile time and avoids recompiles; sensible to leave on.
• dynamic (default off), fullgraph (default off), dynamo_cache_size_limit (default 64), and the optional force_parameter_static_shapes (default on) - lower-level Dynamo controls governing how it handles changing shapes and how big its compile cache can grow.

Output is MODEL, wired into your sampler.

Installing it

You'll have KJNodes already if you're doing Wan. If not: ComfyUI Manager → search KJNodes for ComfyUI → install → restart. Manual:

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

Restart ComfyUI. torch.compile needs a working compiler toolchain in your environment (a proper Triton/CUDA setup); on a stripped-down install that's the usual thing that's missing.

Common issues

It errors after a ComfyUI, PyTorch, or Wan update. Don't debug it. That's the whole meaning of the deprecation notice, this implementation isn't maintained against the moving target. Swap in TorchCompileModelAdvanced and move on.

First generation is slow, then it speeds up. That's expected, torch.compile pays the compile cost up front. The gain shows on subsequent steps/runs at the same shape. If your shapes keep changing every run, you keep paying recompiles, which can erase the benefit (that's what the dynamic and static-shape options are wrestling with).

Compilation fails outright. Usually a missing or mismatched compiler backend (Triton/CUDA) in the environment, or a model the compiler can't trace cleanly. On the Advanced node you have more control; on this deprecated one, the fix is to stop using it.

Inherited an old workflow that uses it. If it still runs, you don't have to rip it out this second, but treat it as living on borrowed time and move to the Advanced node next time you touch the graph.