Apply MBCache and Skip Blocks

If FBCache is "cache the whole model against one threshold," MBCache is the tuning-knob version: cache multiple blocks independently, each with its own sensitivity to how much it's allowed to reuse stale work. The pack's own README puts it plainly - "MBCache extends FBCache and is applied to cache multiple blocks." Same underlying idea, more control, more to configure.

What it is and why you'd reach for it

Every block in a Flux transformer doesn't change at the same rate across denoising steps. Some blocks stabilize early and are safe to cache aggressively; others keep contributing meaningfully right to the end and should barely be cached at all. FBCache applies one threshold to everything, which is simple but leaves speed on the table for the blocks that could tolerate more aggressive caching, or risks quality on the ones that can't. MBCache lets you set a default threshold and then override it per double-stream block, so you can be aggressive where it's safe and conservative where it isn't.

How it works

Same DoubleStreamBlocks/SingleStreamBlocks skip mechanism as FBCache (you can statically remove blocks from computation entirely), plus the caching layer itself, which now tracks per-block similarity rather than one model-wide number. Blocks you don't explicitly override fall back to the default threshold.

The inputs and outputs that matter

• skip_DoubleStreamBlocks / skip_SingleStreamBlocks (strings, default "3,6,8,12" / "") - same static block-skip lists as FBCache.
• default_cache_threshold (float, 0–1, default 0.25) - the fallback caching threshold for any double-stream block you haven't individually overridden.
• dsb_cache_thresholds (string, default empty) - where MBCache actually differs from FBCache: a way to give specific double-stream blocks their own threshold instead of the default. Leave it empty to behave like a single-threshold cache; fill it in once you've identified which blocks tolerate more aggressive reuse.
• start / end (0–1, defaults 0 and 1) - the portion of the schedule caching is active over, same as FBCache.
• max_consecutive_cache_hits (int, default -1) - caps consecutive cache reuse before forcing a fresh compute, same safety valve as FBCache.

Output is a patched MODEL.

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 dependencies for the caching logic itself. You still need the standard Flux stack from the README to have anything for this node to operate on: flux1-dev.safetensors or flux1-schnell.safetensors in models/diffusion_models, ae.safetensors in models/vae, the flux_text_encoders files in models/clip.

Common issues & troubleshooting

Should I use this or plain FBCache? Start with FBCache. It's simpler, has one knob, and gets you most of the speedup. Reach for MBCache when you've already found FBCache's single threshold is either too aggressive somewhere or too conservative everywhere, and you want to dial individual blocks instead of the whole model.

dsb_cache_thresholds - what format does it want? The README doesn't spell out the exact syntax, and the node itself is your source of truth here; treat it as a per-block override string paired against the same indices you'd use in skip_DoubleStreamBlocks. If you're not deliberately overriding specific blocks, leave it blank and rely on default_cache_threshold.

Results are worse than FBCache at the same default threshold. That would be unusual since MBCache is a superset of FBCache's behavior when no per-block overrides are set - if you're seeing a regression, double-check you haven't accidentally set overrides that are more aggressive than your intended default.

Compute barely dropped. Same diagnosis as FBCache: check start/end isn't clipped to a tiny window, and that your skip-block lists and thresholds are actually engaging rather than sitting at defaults that do very little on your particular workflow.

Quality degrades in fine detail. This is the universal tax on any caching scheme - small, high-frequency detail is the first thing to blur when a step gets reused instead of recomputed. If a specific block is responsible, that's exactly the case dsb_cache_thresholds exists to solve: dial that block back individually instead of lowering the whole model's threshold.