Apply FBCache and Skip Blocks

Flux is slow because every denoising step reruns the entire transformer, and a lot of that work barely changes from one step to the next. FBCache ("first block cache," lifted from the Comfy-WaveSpeed / comfyui-flux-accelerator lineage) notices when a step is close enough to the last one and reuses the cached result instead of recomputing it. Skip a few blocks entirely on top of that, and you've got one of the more effective free-ish speedups for Flux in this pack.

What it is and why you'd reach for it

Caching techniques like this show up all over accelerated diffusion - it's the same idea behind TeaCache and the ParaAttention-style caches people run on Wan 2.2 for a reported lossless 2x. The logic: diffusion models change output gradually across steps, especially in the middle-to-late part of the schedule, so instead of paying full compute every step, you check how different the current step's activations are from the cached ones and skip recomputation when they're close enough. This node applies that idea to Flux specifically, plus lets you statically skip a handful of transformer blocks that the author found contribute little.

How it works

Flux's transformer has two kinds of blocks - DoubleStreamBlocks (where image and text streams are processed jointly) and SingleStreamBlocks (where they've merged into one stream). This node lets you name specific block indices in each to skip outright, and separately caches the result of a step when it's similar enough to the last one, governed by a threshold. It's the "FB" version: one shared cache and one shared threshold across the whole model, as opposed to MBCache's per-block version (see that node's article if you want finer control).

The inputs and outputs that matter

• skip_DoubleStreamBlocks / skip_SingleStreamBlocks (strings, default "3,6,8,12" and "") - comma-separated block indices to skip entirely. The defaults are the author's own tuned starting point for Flux; leave them unless you know what you're doing.
• fbcache_threshold (float, 0–1, default 0.25) - how similar consecutive steps need to be before the cache kicks in and skips recompute. Higher means more aggressive caching (faster, more risk of drift); lower is more conservative.
• start / end (0–1, defaults 0 and 1) - the fraction of the sampling schedule caching is allowed to run over. Early steps set structure, so it's common to leave caching off for the first slice.
• max_consecutive_cache_hits (int, default -1 = unlimited) - a safety valve capping how many steps in a row can reuse the cache before forcing a fresh computation, so error doesn't compound indefinitely.

Output is a patched MODEL, wired straight into your sampler.

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 extra Python packages or model downloads for this node specifically - it operates purely on the Flux model you've already loaded. You do need the standard Flux model/VAE/text-encoder set from the pack's README (flux1-dev.safetensors or flux1-schnell.safetensors in models/diffusion_models, ae.safetensors in models/vae, the flux_text_encoders files in models/clip) for Flux itself to run - nothing extra for caching on top.

Common issues & troubleshooting

Outputs look mushy or smeared compared to no-cache. That's fbcache_threshold set too aggressive. Bring it down, or narrow the start/end window so caching only runs in the middle of the schedule rather than the whole thing.

It doesn't error but also doesn't speed anything up. Double-check start/end - if they're set to a tiny slice or the block-skip strings are empty, you're barely engaging the cache at all.

Fine detail (hands, text, small objects) degrades more than everything else. That's the general trade-off with any caching scheme - detail-heavy regions are exactly where reusing a stale computation shows up first. If your generation leans on fine detail, either lower the threshold or accept a smaller speed win.

It's incompatible with something else in your graph. Caching techniques in general have known friction with guidance methods that expect every step to be freshly computed (the same class of issue people hit combining caches with things like STG on video models). If a downstream node behaves oddly, try disabling the cache first to isolate whether that's the cause.