Pruna Compile

What this node actually does

Pruna Compile doesn't touch your weights. It doesn't quantize, prune, or swap your checkpoint for a smaller one. It takes the diffusion model's forward pass and rewrites it into a faster version of itself - the same math, rearranged and compiled - then hands you back a MODEL you sample from as usual. That's why the README calls it the one node that "fully preserves output quality." Compilation is a translation job, not a lossy one.

So it's a drop-in patch: Load Checkpoint (or your Flux UNETLoader) → Pruna Compile → KSampler. Wherever the plain MODEL wire went before, it goes through this now.

That "no quality loss" claim comes with a hedge you should read twice: "performance gains can vary depending on the model." Optimistic reading: no downside. Realistic reading: no downside and possibly no upside, depending on what you're running.

What's under the hood

The source is refreshingly short. It clones your ModelPatcher, builds Pruna's SmashConfig, sets compiler on it, calls smash() on patcher.model.diffusion_model, and patches the result straight back into the patcher with add_object_patch("diffusion_model", ...). From that point on, every sampler step runs the compiled module. It's a live organ transplant, not a wrapper.

The two inputs are all you get:

• model - the MODEL wire from your loader.
• compiler - a string, defaulting to x_fast. The source accepts x_fast, torch_compile, and the deprecated spelling x-fast.

Output is a single MODEL, wired into the sampler. That's the whole node.

Here's the part that trips people: the default is the one you probably can't run. x_fast is Pruna Pro only. If you installed the free pruna package and hit Queue, you get exactly this, straight from the code:

ValueError: Compiler x_fast is available only with pruna_pro

Set compiler to torch_compile and it works with the free package. Everything else in that string field is either Pro-gated or a typo.

Installing it

Via ComfyUI Manager, search the pack title "Pruna nodes for ComfyUI" - the pack publishes to the Comfy Registry under publisher prunaai, so Manager can see it. Or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/PrunaAI/ComfyUI_pruna.git

Restart ComfyUI, and the nodes show up under the Pruna category.

The pack ships an install.py that ComfyUI Manager may run for you. It pip-installs two things: pruna_pro and pruna[stable-fast]. Note the mismatch with the README, which pins pruna==0.2.6 while the installer grabs whatever's latest. If you're doing this by hand, follow the README's pin:

pip install pruna==0.2.6
# or, with a Pro token:
pip install pruna_pro==0.2.6
export PRUNA_TOKEN=<your_token_here>

Fair warning on pruna[stable-fast] - it drags in stable-fast and its Triton/torch expectations, which is the heaviest single dependency in this pack. If you don't plan to use stable_fast anywhere, you can skip that extra.

Then launch with the required flag:

cd <path_to_comfyui> && python main.py --disable-cuda-malloc --gpu-only

The README is blunt that compilation won't "function properly" without --disable-cuda-malloc; --gpu-only is a recommendation, not a requirement. Bake both into your launch script or you'll rediscover this every session.

Where people get burned

It's Linux-only and unmaintained. The repo opens with "This repository is no longer maintained." No Windows support, no one home at the issue tracker. Treat it as frozen software, because it is.

It's a Flux 1 / SD era tool. The bundled workflows and the README's benchmarks are SD v1.4 and FLUX.1 dev on an L40S. Nothing suggests anyone validated it against the 2026 generation of models. If you're on a current architecture, you're the test case.

Compile time is real. torch.compile specializes on shapes, so the first generation after loading includes compilation and can be dramatically slower than the steady state - and changing resolution or batch size can make it start over. Benchmark after a warm-up run, never on the first image.

If your steps are already tiny, there's nothing to win. Compilation speeds up each forward pass, but the whole reason these nodes exist is the 20–50 step era. On an 8-step Turbo/Lightning/Schnell model you're optimizing a fifth of the work, and the absolute seconds saved shrink with it.

And a straight comparison for context: the community's free speed-up nodes for Flux are TeaCache and First Block Cache, both of which are widely run and widely discussed. Pruna Compile isn't a replacement for those - it's a different layer entirely, and the pack's caching nodes actually stack it on top by default. If you're going to try Pruna at all, compilation is the low-risk half of the experiment: no quality trade, no token needed if you pick torch_compile.