Pruna Cache Periodic

The dumbest of the three, deliberately

Pruna Cache Adaptive looks at how far the latent has moved before it skips a step. Pruna Cache Auto juggles a schedule to hit a latency target. Pruna Cache Periodic does neither - it counts. Every N steps, run the model and cache the result; in between, reuse what you have. You know the cost before you hit Queue, because the cost doesn't depend on what you asked for.

That predictability is the sales pitch. A caching scheme that reacts to content makes your render times jitter prompt to prompt; a fixed interval makes them boring, and boring is worth something when you're batching.

How it works

It's a MODEL-in, MODEL-out patch, wired inline where the plain model used to go: Load Checkpoint → Pruna Cache Periodic → KSampler. The node clones the ModelPatcher, configures the periodic cacher, calls smash() on the diffusion model, and patches the cached module back into your patcher. Same sampler, scheduler and step count - you're changing what happens inside each step, not how many you asked for.

The inputs

• model - the MODEL wire.
• cache_interval - default 2, range 1–7. How often the model output is computed and cached. At 2 you're doing roughly half the real work. At 1 you cache every step and never reuse anything, so it's effectively baseline with extra bookkeeping. At 7 you're computing one step in seven - maximum speed, maximum damage, and a good way to see what caching artifacts look like before you decide you hate them.
• start_step - default 2, range 0–10. How many steps run normally before caching starts. The rationale is the same reason hires-fix exists: early steps establish composition, and skipping them gives you mushy structure no later step will rescue. Two is sane; push it up when the prompt has a lot of spatial layout to specify.
• cache_mode - default, taylor, ab, bdf. default reuses the cached output as-is; taylor, ab (Adams-Bashforth), and bdf (Backward Differentiation Formula) extrapolate forward instead. Set this to taylor - it's what Pruna benchmarked with, and default is the naive option.
• compiler - torch_compile, stable_fast, or none, default torch_compile. Yes, caching nodes compile by default too. none gives you pure caching; stable_fast needs the pruna[stable-fast] extra.

Output: one MODEL.

Installing it

Manager, search "Pruna nodes for ComfyUI" - it's published to the Comfy Registry under publisher prunaai. Or:

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

This node requires Pruna Pro, not the free package. Both come from pip, but Pro needs a token:

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

Without it you'll get ValueError: periodic caching requires pruna_pro to be installed on queue - the caching engines are Pro-only, which is the single most important thing to know about all three caching nodes in this pack. The README pins 0.2.6; the pack's own install.py installs unpinned, which is a difference worth being deliberate about.

Model setup is the usual: SD checkpoints into models/checkpoints, or for Flux put clip_l.safetensors and t5xxl_fp16.safetensors in models/clip/, a VAE in models/vae/, and the diffusion weights in models/diffusion_models/. Drag any of the graphs in workflows/ into the ComfyUI window to get the wiring for free.

And because compiler defaults to torch_compile, you need the launch flag or the pack misbehaves:

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

Where people get burned

The clock doesn't know what's in your image. That's the flip side of predictability. A prompt with a busy composition that keeps resolving new detail gets the exact same skip budget as a flat portrait with nothing left to resolve - so Periodic's artifacts cluster on the complicated prompts. Adaptive exists precisely to fix that; if you find yourself lowering the interval for hard prompts and raising it for easy ones, the other node is the answer.

It's a high-step tool in a low-step era. Every claim about caching speedups assumes there are 20–50 steps to skip. Pruna's published Periodic runs are benchmark numbers from the SD 1.4 / FLUX.1 dev period with 50 and 28 steps. If you're running a Turbo, Lightning, or Schnell checkpoint at 8 steps and an interval of 2, you're skipping a handful of forwards and the wall-clock gain will be small. Measure before believing.

Adjacent tooling has all the community support. TeaCache and First Block Cache are the caching nodes people actually talk about for Flux, and they're free. Pruna's own benchmark puts Auto mode at TeaCache-equivalent speed with better quality - their measurement, their hardware. Worth a shot, but you're in a small club: this node has essentially no community footprint to fall back on when it misbehaves.

Unmaintained, Linux-only. The README opens with the notice and requires a Linux system with an NVIDIA GPU. Budget for fixing your own problems.