Compile and Quantize Model

Here's the honest first thing to know: despite the name, every knob this node actually exposes is about torch.compile. There's no dtype or bit-width setting anywhere in it. If you came here looking for the fp8/GGUF-style quantize step, it isn't on this node - this one is purely the compile half of "compile and quantize," and it's still worth using for what it does.

What it is and why you'd reach for it

torch.compile is PyTorch's JIT compiler: instead of running your model's Python code eagerly step by step, it traces the computation graph once and compiles it into fused, optimized kernels. The tradeoff is upfront - the first run pays a compilation cost, sometimes a noticeable one - and every run after that is faster because the compiled graph gets reused. The community's blunt summary of the general technique: "JIT compilation. Startup overhead but per-frame speed improvement." That's exactly what you're trading here, and it stacks with the caching and attention nodes elsewhere in this pack rather than competing with them.

This pack's README calls out one specific, real reason to use its version rather than raw torch.compile: it patches an AttributeError: 'SymInt' object has no attribute 'size' bug that otherwise forces a full recompile every time you change resolution. If you're the kind of person who queues different aspect ratios in the same session, that fix alone is worth the install - without it, torch.compile becomes expensive and annoying rather than free after the first run.

How it works

You feed it your model (and, notably, your VAE - both get wired through the node together, which is a convenient place to apply compile settings to both halves of your pipeline in one node instead of two).

The inputs and outputs that matter

• model / vae - both required, both come back out compiled.
• do_compile (boolean, default true) - the master switch. Off, and this becomes a passthrough - useful for quick A/B comparisons of compiled vs. eager execution.
• dynamic (boolean, default false) - whether to compile for dynamic input shapes rather than a fixed one. Turning this on trades some peak speed for tolerating shape changes (like resolution) without triggering a full recompile - which pairs directly with the SymInt fix mentioned above.
• fullgraph (boolean, default false) - forces torch.compile to trace the entire model as one graph with no fallback breaks. Faster when it works, but any operation it can't trace will hard-error instead of silently falling back to eager execution for that piece.
• backend (enum, default inductor) - which compiler backend to target: inductor (PyTorch's default and most mature), cudagraphs, onnxrt, openxla, or tvm. Unless you have a specific reason to reach for one of the others, inductor is the sane default.

Outputs are a compiled MODEL and VAE, wired downstream exactly as you'd wire the uncompiled versions.

How to install it

• ComfyUI Manager - search "ComfyUI-Lightning", install, restart.
• Manual - cd ComfyUI/custom_nodes && git clone https://github.com/shenduldh/ComfyUI-Lightning, then restart.

No model downloads for this node itself - you still need the standard Flux stack (diffusion model, VAE, text encoders) per the README to have anything to compile.

Common issues & troubleshooting

First generation after adding this node is slow, then subsequent ones are fast. That's expected - you're paying the compile cost once per shape/config, then reaping the speedup on every run after. Don't judge the node off your first queue.

Changing resolution triggers a full recompile every time. This is exactly the bug the README says it patches (the SymInt error). If you're still seeing recompiles on resolution change, try enabling dynamic - that's the setting that tells the compiler not to assume a fixed shape.

fullgraph=true throws an error mid-graph. Some custom nodes or model patches (other Lightning nodes included, if stacked in the wrong order) do things torch.compile can't trace cleanly. Turn fullgraph off first - it'll let the compiler fall back to eager execution for the parts it can't handle, which usually gets you unstuck at a small speed cost.

No speedup at all, or it's slower. Compilation overhead can outweigh the benefit on very short runs (few steps, small batch) - this technique pays off more the longer and more repetitive your workload is. Also confirm do_compile is actually true; it's easy to leave it off after testing.