TorchCompileModel

TorchCompileModel is ComfyUI's way of giving you PyTorch's torch.compile as a node you drop into the graph instead of a command-line flag. When it works, it's a genuine free speedup - the community has measured real gains on Flux-class models (a well-known thread reported around 30% faster on a Flux Q8 GGUF build). When it doesn't work, the error messages will send you down a version-matching rabbit hole. It's worth understanding which case you're in before you commit a workflow to it.

What it does. It's a model patcher: wrap your MODEL, mark it for compilation, and let PyTorch fuse and optimize the model's forward pass. The node clones the model with dynamic shapes disabled, then applies a compile wrapper with a guard filter that skips recompiling when certain options (the transformer_options bag) change. The backend input picks the compile strategy:

• inductor - the general-purpose default. Uses Triton on the backend; works on most Linux/NVIDIA setups and is what you'd try first.
• cudagraphs - records and replays CUDA graphs, lower overhead per step but pickier about your environment and less flexible about shape changes.

Output is a MODEL; wire it between your checkpoint loader and the sampler like any patcher.

The catch, in one sentence: the first run compiles. The first generation after adding this node can take minutes as PyTorch builds and optimizes the fused kernels - that is normal, it is not a hang, and if you bail and remove the node, you lose the investment every time. The node caches compilation, so subsequent runs are fast as long as the graph doesn't change. Change the model, the batch size, or anything that alters the input shapes, and parts of the graph recompile.

Gotchas, ranked by how often they bite:

• Missing backend support. Inductor needs Triton, which is awkward on Windows and absent from some stock torch builds. If you get an error about Triton or a compile backend not being available, that's your environment, not the node - check your torch/CUDA pairing first.
• Stale caches. After a torch upgrade, old compiled artifacts can produce weird errors; clearing torch's compile cache fixes a surprising number of "it worked yesterday" reports.
• Compatibility with other patchers. LoRAs, ControlNet, and custom attention patches interact with the compiled graph. The node specifically skips recompiling on transformer_options changes, which keeps LoRA swaps cheap, but the boundary is experimental - test before you trust it in a production workflow.
• It's speed for long sessions. If you generate a few images and close ComfyUI, the compile time swamps the savings. It pays off when you run one model a lot - batch jobs, LoRA testing, video.

Community consensus, where it exists, is measured: torch.compile is a "free speed upgrade" that can't hurt quality, but it's the kind of optimization people add after they've already got a working setup, not while they're still fighting a workflow. If you're happy with your current speed, this node is optional. If you render the same Flux setup all day, it's the cheapest 20-30% you'll find.

Ships with ComfyUI core. Search "TorchCompileModel" to add it; no install.