Torch Compile Speed Settings

Torch.compile is one of the three accelerations the Wan community actually leans on - SageAttention, TeaCache, and TorchCompile - and it's the one with the ugliest interface. Raw torch.compile calls are a wall of backend and mode arguments, and if you get them wrong you either get no speedup or a compile that takes forever. This node is the "settings bag" of the two-node ComfyUI-TorchCompileSpeed pack: it takes a handful of sane booleans and enums and turns them into a WANCOMPILEARGS dict that another node can consume.

It doesn't compile anything itself. It's a config node, and that's the point. The pack is deliberately non-intrusive - the whole design exists so you can wire these args straight into the WanVideo Cython Model Loader's compile_args socket without touching that loader's source. If you're running Wan 2.x in Kijai's wrapper, this is the drop-in replacement for hand-rolling your compile dict.

How it works

Under the hood it's just a well-organized dictionary builder. You pick settings, it returns one torch_compile_args value. The clever part is the mode dropdown: the default is speed, and picking it overrides everything for you - it forces backend=inductor, dynamic=True, fullgraph=False, and the max-autotune-no-cudagraphs mode. That combo disables CUDA graphs (cutting capture overhead), enables dynamic shapes so the cache survives resolution changes, and turns on full Triton autotune. The result is exactly the "first run slow, every run after fast" behavior the README advertises. Pick any other mode and it passes your raw choices through.

The inputs that matter

Eleven knobs sounds like a lot, but a beginner sets maybe three:

• mode - leave it on speed. It's the recommended preset and the reason this pack exists.
• dynamic - True for speed mode (it's forced anyway). Dynamic shapes make the compiled cache reusable across resolutions, which matters because Wan workflows don't stay at one size.
• backend - inductor is the right default. cudagraphs exists but the whole pack's thesis is that CUDA graphs cause more capture pain than they save.

The rest are quality-of-life: warmup_runs (1–2 is fine) and experimental_ptx seed the PTX/kernel cache so your next session starts faster; ptx_cache_dir sets TRITON_CACHE_DIR for cross-session reuse; dynamo_cache_size_limit is the OOM relief valve. One honest gotcha from reading the source: compile_transformer_blocks_only is stored in the args dict but the ApplyTorchCompile node never reads it yet, so don't rely on it to trim compile scope - it's a placeholder until a future version wires it up.

Output

One output: torch_compile_args (type WANCOMPILEARGS). Feed it into either ApplyTorchCompile's compile_args input (for any MODEL), or directly into the WanVideo Cython Model Loader's compile_args socket.

Installing

There's no requirements.txt and no model downloads - this pack is pure Python over the torch/Triton already in your ComfyUI environment. ComfyUI Manager, search "ComfyUI-TorchCompileSpeed", or:

cd ComfyUI/custom_nodes
git clone https://github.com/eddyhhlure1Eddy/ComfyUI-TorchCompileSpeed

Restart ComfyUI and the node appears under the optimization category.

Troubleshooting

• "Can't connect to WanVideo Loader." Both sockets have to be the WANCOMPILEARGS type, which this node already outputs - if you're hitting that, you've wired the wrong node into compile_args.
• First generation takes ~10s and stalls. That's autotune doing its job. Second run should be near-instant; if it isn't, check that experimental_ptx is on and warmup_runs is 1+ so the PTX cache gets seeded.
• "Warning: knob not available in your PyTorch/Triton build." The node logs and ignores unsupported flags rather than crashing - expected on older torch or Windows builds without Triton.
• VRAM pressure during the first run: drop dynamo_cache_size_limit (64 is default) until it fits.

It's a small node, but it's the difference between pasting a compile dict you don't understand into your workflow and having a checkbox that does the right thing.