TorchCompileModelFluxAdv

Same torch.compile idea as the pack's other compile nodes, but for Flux specifically - and instead of an all-or-nothing switch, this one lets you choose exactly which of Flux's transformer blocks actually get compiled. That matters more than it sounds like: Flux workflows are usually stacked with LoRAs and other model patches, and torch.compile wanting a stable graph doesn't always play well with something else patching the model afterward.

How it works

It patches your Flux model the same way the other compile nodes do - trace once, compile to optimized kernels, pay a one-time warm-up cost - except the block ranges tell it exactly which layers to include. Flux's architecture is 19 double-stream blocks (image and text processed jointly) followed by 38 single-stream blocks (concatenated and processed together), both 0-indexed. The defaults, 0-18 and 0-37, cover the full model by default; narrowing them compiles only a subset.

The inputs and outputs that matter

• model (MODEL) in, model out.
• backend - inductor (default, most compatible) or cudagraphs.
• mode (default default) - default, max-autotune, max-autotune-no-cudagraphs, or reduce-overhead.
• fullgraph (tooltip: "Enable full graph mode") - compile the whole thing as one graph rather than allowing silent eager fallbacks on unsupported ops.
• double_blocks (default "0-18") - which of Flux's double-stream blocks to compile, as a text range.
• single_blocks (default "0-37") - same idea for the single-stream blocks.
• dynamic (tooltip: "Enable dynamic mode") - tolerate changing input shapes without a full recompile each time.
• Why you'd narrow the ranges: if compiling every block clashes with a LoRA or another patch touching the model - and it can, since compile wants a stable graph and a live patch violates that - dropping the specific blocks that patch touches out of the range is the fix, rather than giving up on compiling entirely.

How to install it

Via ComfyUI Manager: search RES4LYF, install, restart.

Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/ClownsharkBatwing/RES4LYF
cd RES4LYF
pip install -r requirements.txt

Portable installs: use the embedded Python's pip.exe. torch.compile ships with PyTorch itself, but the inductor backend leans on Triton - expect the same Windows friction that shows up with other Triton-dependent speedups in this space.

Common issues & troubleshooting

Compiling the full model breaks or degrades quality once you add a LoRA or other patch. This is exactly the scenario this node exists to solve - start trimming block ranges from the ends (say, dropping the last few single-stream blocks) rather than abandoning compilation.

Slow first generation. Expected - the compile tax is paid once per graph, and narrower block ranges compile faster to warm up than the full model, which is another reason to trim ranges rather than always compiling everything.

Errors on Windows mentioning Triton. Known friction for inductor-backed compiling on that platform generally, not specific to Flux or this node.

Changing resolution or batch size a lot mid-session. Each new shape can trigger a recompile unless dynamic is on - turn it on if you're not running the same shape every time.