TorchCompileModelFluxAdvancedV2

Its own description says "Deprecated, use TorchCompileModelAdvanced instead" - but unlike its stripped-down siblings, this one still exposes real settings, and it's probably the version you'll actually find dropped into Flux workflows floating around online, since it was the last Flux-specific compile node before kijai unified everything into one generic node. So it's worth understanding properly even while you plan to eventually migrate off it.

What it does: takes your loaded Flux model, hands it to torch.compile, and returns a compiled version that runs faster on every generation after the first. torch.compile traces the model's computation graph and fuses operations into optimized CUDA kernels instead of running them one at a time in eager mode. The first pass through is where that tracing and kernel-building happens, so it's slower - sometimes a lot slower. Every generation after that, at the same resolution, reuses the compiled kernels and wins the trade back. If you generate one image and close the workflow, you paid the tax with no refund; if you're running a batch or a long session at one resolution, it compounds nicely.

The inputs that matter

Seven required settings, plus two optional ones most people never touch:

• backend - inductor or cudagraphs. inductor is torch.compile's general-purpose backend and the one to start with.
• mode - default, max-autotune, max-autotune-no-cudagraphs, or reduce-overhead. default is the safe choice for your first run. max-autotune searches harder for fast kernels at the cost of a much longer compile pass - only worth it if you're doing enough runs at a fixed shape to amortize that cost.
• double_blocks and single_blocks (both default on) - Flux's diffusion transformer runs two families of blocks: double-stream blocks early, where the image and text streams are processed jointly, and single-stream blocks later, where they've merged into one stream. These toggles let you compile each family independently. Leaving both on compiles the whole model; turning one off can help if compiling it is causing trouble elsewhere.
• fullgraph (default off) - forces the entire model to compile as one graph rather than letting Dynamo break it into pieces where it can't trace cleanly. Faster in theory, brittle in practice; leave it off unless you know why you're turning it on.
• dynamic (default off) - lets the compiled graph handle changing input shapes without a full recompile. Useful if your resolution changes between runs, but it usually costs some steady-state speed compared to compiling for a fixed shape.
• dynamo_cache_size_limit (optional, default 64) - how many distinct compiled shape-variants Dynamo will cache before it starts evicting or erroring. The default is enough for most people; if you cycle through a lot of different resolutions and see repeated recompiles, raise it.
• force_parameter_static_shapes (optional, default on) - a Dynamo internal setting telling it to assume the model's own weight tensors have fixed shapes across calls. Leave it on; it's what keeps the compiled graph stable.

The single output is a compiled MODEL - wire it straight into your KSampler like a normal model input, nothing downstream needs to know it was compiled.

How to install it

Part of the KJNodes pack. Through ComfyUI Manager, search "KJNodes for ComfyUI" and install. Manually: cd ComfyUI/custom_nodes && git clone https://github.com/kijai/ComfyUI-KJNodes, then pip install -r ComfyUI-KJNodes/requirements.txt (portable Windows install: run the same command with python_embeded\python.exe -m pip), then restart.

Common issues & troubleshooting

"Triton not found," or a build error mentioning a missing C compiler. torch.compile needs Triton to generate kernels, and on Linux it typically needs a working C toolchain too - apt install build-essential if that's what's missing. This is the single most common wall people hit trying to get this node working at all, especially inside a fresh Docker image that skipped it.

Windows is where this gets genuinely painful. There's no official Triton build for Windows; you're relying on community-maintained wheels, the same ones people fight with to get SageAttention running. If you can't get Triton installed, this node simply isn't your speedup - unplug it and use fp8 or offloading instead.

The first generation is slower, not faster. Expected. That's the compile pass. Judge the node by the second and later runs at the same shape, not the first.

It keeps recompiling and you never see the speedup. Changing width, height, or batch size between runs forces Dynamo to recompile from scratch each time. Keep your output shape stable across a session, raise dynamo_cache_size_limit if you're legitimately switching shapes often, or turn dynamic on and measure whether the flexibility is worth the steady-state cost - it often isn't.

You're seeing no speedup at all on some cards. Not every GPU or driver combination benefits equally, and a few users report the compiled path simply not being faster in their specific setup even with everything configured correctly. Worth timing a before/after rather than assuming it's working.