Flux2 SDNQ TorchCompile

Quantization gets FLUX.2 onto your card, but it doesn't make it fast - the 32B transformer is still doing a lot of work per step. This node attacks that with PyTorch's torch.compile, which traces the computation graph once and hands it to optimized compiled kernels. First run pays a 30–60 second compilation tax; every run after that is roughly 30% faster, per the pack's own testing. That's a genuinely good trade for a workflow you run repeatedly, and it's the performance lever this pack actually recommends for Flux2 - the README is blunt that xFormers/Flash Attention/Sage Attention do nothing for Flux2's architecture, so TorchCompile is the one that counts.

The implementation is more careful than a blanket torch.compile(model): it compiles only the transformer blocks (both double_blocks and single_blocks, on by default) and leaves everything else alone for stability. It also skips accelerate.hooks during dynamo tracing - that's the "dict object has no attribute node" crash class you'd otherwise hit - and restores the dynamo config afterwards so it doesn't leak into the rest of ComfyUI.

Placement and inputs

Strict rule: it sits between the model loaders and the sampler.

SDNQ Model Loader → SDNQ LoRA Loader → Flux2 SDNQ TorchCompile → Flux2 SDNQ Sampler V2

It takes the MODEL output and hands a MODEL back, so it drops into the chain without changing anything else.

• mode - default is balanced; the README recommends max-autotune for best speed (inductor + CUDA graphs). max-autotune-no-cudagraphs and reduce-overhead are the alternatives for smaller models or fussier setups.
• backend - inductor (default, recommended) or cudagraphs.
• double_blocks / single_blocks - both default true; you'd disable one only if compilation of a block type is unstable on your torch version.
• dynamic - off by default, and you generally want it off: dynamic mode handles variable input shapes but forfeits the static-shape optimizations that make compilation pay off. Turn it on only if you're switching resolutions mid-workflow and can't avoid it.
• fullgraph - default false. The tooltip warns it can conflict with accelerate hooks; leave it alone unless you know why you need it.
• Optional dynamo_cache_size_limit (default 64) and force_parameter_static_shapes (default true) map to torch._dynamo.config knobs - the "advanced, mostly leave as-is" drawer.

Requires PyTorch 2.0+, and the node raises a clear error if compilation fails rather than silently running unoptimized. Verify success in the console logs - it prints what it's compiling.

Install

It's part of the same pack, so:

cd ComfyUI/custom_nodes/
git clone https://github.com/ussoewwin/comfyui-sdnq-splited.git
cd comfyui-sdnq-splited
pip install -r requirements.txt

Restart ComfyUI, find it under SDNQ/torchcompile. Manager install may need the security-level workaround (lower Security Level or "Install via Git URL").

The honest caveats

First compile being slow is expected - 30–60 seconds of "is it hung?" before output. The 30% figure is the pack author's own test result on Flux2 SDNQ models, so treat it as "noticeably faster," not gospel. And compile caches aren't eternal: update your torch or change quantization and you'll eat the compile tax again. If generation suddenly gets slower or errors after a ComfyUI update, disable the node to isolate whether torch.compile is the culprit.