Apply First Block Cache

"Apply First Block Cache" is the node Comfy-WaveSpeed is actually known for - and the one worth trying first if you only try one thing from this pack. Drop it between your model loader and your sampler and, with the right threshold, most workloads get a 1.5–3x speedup for output that's visually indistinguishable. Not bad for a single node and no new model files.

It's a dynamic caching trick in the same family as TeaCache, which you've probably seen in video workflows (ComfyUI-WanVideoWrapper has it built in). Denoising runs the same transformer blocks over and over, one pass per step. Late in sampling, consecutive steps barely change anything - so why compute them twice?

How it works

Here's the clever part. Instead of comparing whole-layer outputs (expensive), FBCache watches the residual output of the first transformer block only. That single cheap computation is a surprisingly good "is anything changing?" signal. If the current first-block residual is close enough to the previous step's, the node reuses the previous step's final residual and skips every remaining transformer block for that step. The comparison is a relative L1 difference (mean abs diff over mean abs value) - the same metric TeaCache calls rel_l1_thresh, and yes, the thresholds behave the same way.

The cache lives in a per-run context that clears when the node's execution finishes, so you don't get stale-state surprises between generations. On Flux it patches the model forward path directly; on SDXL, SD3.5, HunyuanVideo and LTXV it swaps in a CachedTransformerBlocks module that wraps the double/single blocks. It genuinely is "universal" in the way the README claims.

The inputs that matter

Of the five inputs, three actually matter for beginners:

• residual_diff_threshold - the tolerance knob. Lower is stricter (fewer cache hits, less speedup, more fidelity). 0 disables caching entirely, which is the panic button when output degrades.
• start / end - where in the sampling run caching is allowed, as a percentage. Early steps set composition, late steps add fine detail; you typically don't want to cache either extreme.
• max_consecutive_cache_hits - caps how many cached steps can run back-to-back. -1 is unlimited; 0 disables. A cap like 5 is the standard quality-preserving move.

The model input is your loaded diffusion model and the single MODEL output wires straight into your sampler, exactly where the loader's output used to go. Nothing else changes in the graph.

Tuning it

Start from the README's table and adjust from there:

| Model | Steps | threshold | | --- | --- | --- | | flux-dev (fp8_e4m3fn_fast) | 28 | 0.12 | | ltx-video-2b | 30 | 0.1 | | HunyuanVideo (fp8 distilled) | 20 | 0.1 | | SD3.5 large (fp8) | 30 | 0.12 | | SDXL base | 25 | 0.2 |

Real-world reports line up with this. On a 4080 Super, one user went from 14.9s to 3.2s on Flux at threshold 0.1 - but noted the image went blurry at that setting, while 0.07–0.08 was nearly free. A common quality-preserving setup floating around is threshold 0.12 with start 0.2, end 0.8 and max hits 5. The speedup scales with step count, so it shines most on 25–30 step runs.

Install

Via ComfyUI Manager, search "WaveSpeed". Or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/chengzeyi/Comfy-WaveSpeed.git

Restart ComfyUI. No model downloads - the pack is pure code.

Where people get burned

• Too-high threshold = blur. The cache reuses stale hidden states; crank it too far and detail melts. Start strict and loosen.
• SDXL + FreeU Advanced don't mix. The README is explicit: FBCache on SDXL misbehaves if the FreeU Advanced pack is installed and enabled.
• Don't pair it with the compile node if you're on Windows. torch.compile isn't officially supported there; plenty of users keep FBCache alone and still get a solid win (one Hunyuan user: 260s → 158s, no compile at all).