Pruna Cache Auto

Why this is the one to try

Of the three caching nodes in this pack, Auto is the only one where you state a goal instead of hand-tuning a schedule. Adaptive wants a threshold and a skip cap. Periodic wants an interval and a start step. Auto wants a single number that means "be this much faster," and it works out the caching schedule to get you there.

If you're going to spend an evening on Pruna caching, start here - it's also the variant Pruna put in front of the public, since their published comparison against TeaCache and First Block Cache is an Auto-mode benchmark.

How it works

The node sits inline on the MODEL wire - Load Checkpoint → Pruna Cache Auto → KSampler - and does the same surgery as its siblings: clone the ModelPatcher, configure the caching strategy, smash() the diffusion model, patch the result back into the patcher. The sampler you already had keeps running; it just skips forward where the caching engine decides it can.

Where Adaptive measures latent drift and Periodic counts steps on a fixed clock, Auto searches for a schedule that hits your latency target. That's the trade: less control, less to get wrong.

The inputs

• model - the MODEL wire from your loader.
• speed_factor - default 0.5, range 0.0–1.0. Lower means faster and lower quality. This is the entire speed/quality negotiation.
• cache_mode - default, taylor, ab, or bdf. Same four reconstruction strategies as the other caching nodes: plain reuse, Taylor expansion, Adams-Bashforth, and Backward Differentiation Formula. The last three extrapolate the trajectory instead of assuming the previous output still holds.
• compiler - torch_compile, stable_fast, or none, default torch_compile. Compilation is layered on top of caching by default. stable_fast requires the pruna[stable-fast] extra.

Output is a single MODEL.

What to actually set

speed_factor is where you'll spend your time, and the useful range is narrower than 0.0–1.0 implies.

Pruna's own numbers, on Flux dev, 1024×1024, 50 steps, 65 prompts from PartiPrompts, one L40S: Auto at 0.4 matches TeaCache's speedup while scoring better on their quality metrics, and 0.3 does the same against First Block Cache. They also report up to a 5.6× speedup at 0.2 - and then tell you to check whether the quality is acceptable, which is the honest part of that sentence. The default of 0.5 is conservative; the interesting sliding happens between 0.2 and 0.4.

Pair it with cache_mode: taylor. That's what their benchmarks used, and default is the crude one: it reuses the previous step's output raw, where taylor reconstructs what the step would have produced.

Installing it

ComfyUI Manager, search the pack title "Pruna nodes for ComfyUI" (it's on the Comfy Registry under publisher prunaai). Or manually:

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

Then the Pro package and your token - this node needs both:

pip install pruna_pro==0.2.6
export PRUNA_TOKEN=<your_token_here>

The pack's install.py will pip-install pruna_pro and pruna[stable-fast] on your behalf if Manager runs it. For the Flux workflows you also need clip_l.safetensors and t5xxl_fp16.safetensors in models/clip/, an ae.safetensors VAE in models/vae/, and the diffusion model in models/diffusion_models/. SD checkpoints go in models/checkpoints like normal. Ready-made graphs for both families live in the pack's workflows/ folder.

Launch flags - the README is emphatic that compilation misbehaves without the first one:

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

Where people get burned

It needs Pruna Pro. Try it with only the free pruna package and the node stops with ValueError: auto caching requires pruna_pro to be installed. Free users get Pruna Compile in torch_compile mode and nothing else from this pack.

Pruna's benchmarks are Pruna's. Same hardware, same 50-step configuration, same quality metrics they picked - and no independent replication that I can find. Nobody in the community is running these nodes; searching for them turns up the company's own promotion and a couple of curious bystanders, versus thousands of threads for TeaCache and First Block Cache. That doesn't make the numbers wrong. It does mean 5.6× is a claim, not a fact, and you should look at your own outputs before you trust the slider.

Half of caching's value disappeared with the step counts. The whole mechanism is skipping denoising steps, which is why every benchmark here uses 20, 28, or 50 steps. Modern distilled and flow-matching models routinely run in 4–8 steps - there is far less left to skip, so expect the same speed_factor to buy you much less than the marketing implies. Check your step count before you blame the node.

Linux and a discrete NVIDIA GPU, or nothing. Not a preference - the README lists it as a prerequisite. Windows users are out. And the repository opens with "no longer maintained," so the issue tracker is a suggestion box with no one reading it.