FunCompile

This node wraps a loaded VideoX-Fun model with PyTorch's torch.compile, trading a slower first run for faster subsequent ones. It's the same idea the wider Wan community knows as TorchCompile in other wrappers - JIT-compile the model graph once, pay startup overhead up front, then get a real per-frame speed improvement on every generation after that as long as you don't change the model or the input shapes enough to force a recompile.

Where it fits: drop it right after your loader (LoadWan2_2Model, LoadWan2_2FunModel, LoadWanFunModel, or LoadCogVideoXFunModel) and before any LoRA nodes or the sampler, so the compiled model flows through the rest of the graph.

How it works

You give it the funmodels bundle and a cache size limit, and it hands back the same bundle wrapped for compilation. The actual compile happens lazily on the first sampler run that uses it - so your first generation after adding this node will be noticeably slower than usual (sometimes much slower), and every generation after that, at the same settings, should be faster.

The inputs that matter

• funmodels (required) - from any of this pack's loaders.
• cache_size_limit - default 64, range 0-10086. This maps to torch._dynamo's compile cache size limit: how many distinct compiled graph variants PyTorch is allowed to cache before it falls back to eager execution or forces a recompile. If you're varying input shapes a lot between runs (different resolutions, different video_lengths), a low limit means you'll keep paying the recompile tax; raising it lets more variants stay cached, at the cost of more memory held for compiled graphs.

Output: funmodels - the same type, compiled, wired into the next node in your chain (a LoRA loader or a sampler).

Installing it

Ships with the base VideoX-Fun pack. Search ComfyUI Manager for VideoX-Fun; if it's not indexed there:

cd ComfyUI/custom_nodes
git clone https://github.com/aigc-apps/VideoX-Fun
pip install -r VideoX-Fun/requirements.txt

Restart ComfyUI. torch.compile itself ships with PyTorch, so there's no separate dependency to install for this specific node beyond what the base pack already needs - though on Windows, torch.compile has a well-known history of being finicky to get working at all, mostly around Triton availability.

Common issues

First generation after adding this node is much slower, not faster. That's expected - you're paying the one-time compile cost. If your workflow only ever runs a single generation per session, this node probably isn't worth it; it earns its keep on repeated runs at consistent settings, not one-offs.

Speed doesn't seem to improve on later runs. Check whether you're actually keeping input shapes consistent between generations - a different video_length, base_resolution, or batch size can trigger a fresh compile each time, which defeats the point. If you're deliberately varying those, raise cache_size_limit so more shape variants stay cached simultaneously instead of evicting each other.

Errors on Windows, or torch.compile silently doesn't seem to be doing anything. This is a known rough edge of torch.compile generally, particularly around Triton on Windows - it's not specific to this node or this pack. If it's causing more trouble than it's worth, skip FunCompile entirely; nothing downstream requires it.

Unsure it's worth the complexity. Reasonable take for casual use - the payoff is real but only shows up across multiple generations at fixed settings. If you're mostly doing one-off renders at varying resolutions, the compile overhead will likely cost you more than it saves.