TorchCompileModelSD35

RES4LYF ships a separate torch.compile node per model family - Aura, Flux, and this one for SD3.5 - rather than one universal node for everything. That's not padding: different architectures hit different graph-break points and shape quirks under torch.compile, and getting a clean compile without silent fallbacks or broken shapes benefits from knowing something about the model's own internals. TorchCompileModelSD35 is that version for SD3.5's MMDiT.

How it works

Same mechanism as the pack's other compile nodes: PyTorch traces the model's forward pass once, compiles it to fused kernels, and everything after the first inference runs faster. Wire it in right after your SD3.5 model loader, before the sampler.

The inputs and outputs that matter

• model (MODEL) in, model out.
• backend - inductor (default, broadest compatibility) or cudagraphs (can be faster, more brittle with shape changes).
• mode (default default) - default, max-autotune (longest compile, highest ceiling), max-autotune-no-cudagraphs, or reduce-overhead.
• fullgraph (tooltip: "Enable full graph mode") - force one compiled graph instead of allowing silent eager fallbacks on unsupported ops.
• dynamic (tooltip: "Enable dynamic mode") - tolerate changing input shapes without a full recompile each time.
• dynamo_cache_size_limit (default 64) - how many compiled graph variants get cached before falling back to eager mode.

Unlike TorchCompileModelFluxAdv, there's no block-range field here - SD3.5 gets compiled as a whole rather than selectively by block. If you need that kind of granular control, it isn't exposed on this node.

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 comes with PyTorch, no separate install - but the inductor backend leans on Triton, which has a rough history on Windows.

Common issues & troubleshooting

Slow first run. Expected - you're paying the compile tax once. This pays off best in a pipeline that keeps running the same resolution and batch size, and can be a net loss if you're changing settings between every generation.

Breaks once you add a LoRA or another model patch. Same general torch.compile-versus-patches friction as any of these compile nodes - the compiler assumes a stable graph, and something patching the model afterward can violate that. Try disabling this node first when debugging a broken generation on a patched SD3.5 setup, before chasing anything else.

Errors mentioning Triton on Windows. Known friction for inductor-backed compilation there in general, not something specific to SD3.5.

Wondering why this node exists separately from TorchCompileModels. Because compiling cleanly needs to understand the target architecture's block structure - use the SD3.5-specific node for SD3.5 models rather than the generic one when both are options.