Compile Model

Compile Model doesn't do anything TeaCache does - it's a different lever on the same problem. Where TeaCache skips work, this node makes the work that's left run faster by handing your model to torch.compile, PyTorch's own JIT compiler, which rewrites it into a more efficient intermediate form before execution. Stack them and they compound: TeaCache cuts how many steps run, Compile Model cuts how long each remaining one takes. The README's own usage note is to drop this after Load Diffusion Model, or right after TeaCache if you're already using it.

How it works

The first time you run a compiled graph, torch.compile traces it and generates optimized kernels for your exact model, shapes and settings - that pass is genuinely slow, sometimes a minute or more depending on mode and hardware. Every run after that, as long as the shapes and settings match, skips straight to the compiled version and comes out noticeably faster. Change resolution, batch size, or swap the model, and you pay the compile tax again.

The inputs and outputs that matter

mode picks the compilation strategy: default is the balanced, reliable choice; max-autotune spends real time hunting for the fastest kernel configuration and usually wins on raw speed once compiled, at the cost of a much longer first pass and occasional instability; max-autotune-no-cudagraphs is the fallback when cudagraphs cause the crashes autotune is prone to; reduce-overhead targets cutting Python/dispatch overhead rather than kernel speed, which matters more at small batch sizes. backend defaults to inductor, PyTorch's own and most mature compiler backend - cudagraphs, eager and aot_eager exist mostly for debugging or compatibility fallback, not for chasing speed.

fullgraph (off by default) forces the entire model to compile as one graph instead of silently falling back on parts it can't trace - turn it on only if you specifically need the extra speed, because it also swaps a quiet partial compile for a hard failure the moment something in a heavily-patched graph doesn't trace cleanly. dynamic (off by default) tells the compiler to expect varying input shapes; leave it off for a fixed pipeline where every run is the same resolution, flip it on if you're bouncing between resolutions and don't want to eat a fresh compile every time. Output is a patched model - wire it into your sampler like any other model-patching node.

How to install it

Same pack as TeaCache. Via ComfyUI Manager: search "ComfyUI-TeaCache", install, restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/welltop-cn/ComfyUI-TeaCache
cd ComfyUI-TeaCache
pip install -r requirements.txt

No extra dependency beyond what's already in your PyTorch install - torch.compile ships with recent PyTorch itself.

Common issues & troubleshooting

It errors out immediately on Windows. torch.compile's inductor backend leans on Triton for kernel generation, and Triton's official Windows support has been genuinely bad for a long time - it's a well-known community sore point, to the point that people maintain their own unofficial Windows Triton wheels just to get it working at all. If you can run this on Linux or WSL instead, do that rather than fight Triton on native Windows.

The first render takes forever and looks stuck. That's compilation, not a hang - don't kill the process. max-autotune in particular can take several minutes on the first pass; it's a one-time cost per shape/settings combination, not something you pay every run.

It recompiles every single generation. You're changing something between runs - resolution, batch size, an attached LoRA, even a different mode. Fix your pipeline to one shape and settings, or flip dynamic on and accept a bit less peak speed in exchange for not recompiling on every shape change.

fullgraph=true throws where fullgraph=false worked fine. The compiler hit a piece of the graph it can't trace as one whole - common when several custom nodes are patching the model before this one. Turn fullgraph off unless you've confirmed the extra speed is worth debugging.