🔧 Model Compile

PyTorch's torch.compile() can speed up inference by tracing your model into an optimized, fused execution graph instead of running it op-by-op the naive way. Model Compile is essentials' one-node wrapper for it - drop it after your model loader, pick a mode, and let it do its thing. No custom scripts, no editing launch args.

How it works, and why the first run is slow

torch.compile doesn't do anything the instant you queue a run - it traces the model the first time it actually executes at a given shape, which is genuinely slow (this is the "compile" step, not a stall). Every run after that, at the same input shape, uses the compiled graph and should be faster. Change the resolution, batch size, or swap in a different model/LoRA, and you generally pay that compile tax again.

The mode options are PyTorch's own compile modes, not something essentials invented:

• default - the safe middle ground, good general-purpose speedup with reasonable compile time.
• reduce-overhead - uses CUDA graphs to cut Python launch overhead, which mostly helps when your bottleneck is kernel-launch overhead rather than raw compute. Can misbehave if input shapes vary between runs.
• max-autotune - spends a lot longer on the first compile searching for the fastest kernel implementations. Biggest theoretical gain, longest warmup, and it needs Triton installed.
• max-autotune-no-cudagraphs - same search, without CUDA graphs, useful when reduce-overhead-style graphs cause problems with your workflow.

fullgraph (default false) forces compilation to error out instead of silently falling back to eager execution when it hits something it can't trace - good for finding what's actually breaking your compile, bad to leave on by default since one exotic custom node in your pipeline will just throw. dynamic (default false) marks input shapes as dynamic so varying resolution/batch size doesn't force a fresh compile every single time - you trade a bit of peak speed for not recompiling constantly.

Inputs and outputs

model (MODEL) in, plus fullgraph, dynamic, and mode. Output is a MODEL - wire it straight into your KSampler like you would the uncompiled version.

Installing it

Via ComfyUI Manager, search "ComfyUI Essentials". Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/cubiq/ComfyUI_essentials

and restart. The pack is in maintenance-only mode as of April 2025 - cubiq (Matteo) said outright he's not doing active development on it anymore, so if torch.compile support in ComfyUI itself moves forward, don't expect this node to chase it quickly.

Common issues & troubleshooting

It errors on Windows, or max-autotune won't run at all. This is a torch.compile limitation, not really an essentials bug - the heavier modes need Triton, and Triton support on Windows has historically been shakier than Linux. Real reddit threads on this show people hitting build errors needing build-essential/a C compiler even on Linux Docker setups, so don't assume it'll "just work" - check your Triton install first.

No speedup, or barely any. This happens in practice, not just theoretically - one documented case: someone running a video model with the dynamic option on saw the prompt succeed but speed not noticeably improve. Whether compile actually helps depends heavily on your GPU, model, and whether your shapes stay constant between runs. Test it on your actual workflow before assuming it's free performance.

Every run seems to recompile. If your resolution, batch size, or model/LoRA changes between queues, that's expected without dynamic enabled - each new shape triggers a fresh (slow) compile. Turn on dynamic if your shapes vary and the recompile cost is eating your gains.