Apply TeaCache and Skip Blocks

TeaCache started life as a video acceleration trick - it's one of the standard techniques people stack with SageAttention and torch.compile to make Wan bearable on a 4090. This node is that same idea, ported over and wired into Flux, care of this pack's block-skip apparatus. If you've read about TeaCache in the video-model world and wondered whether it applies to image generation too, this is the answer: yes, with the caveats you'd expect.

What it is and why you'd reach for it

TeaCache decides, step by step, whether the current denoising step is different enough from the last one to be worth fully recomputing. If it's not - if the model's internal state has barely moved - it reuses the cached result instead of paying for another full forward pass. The community's own summary of the technique, from its home turf on video models: "smart temporal caching that skips redundant computation across similar frames. Moderate speedup with minor quality impact." The "minor quality impact" part travels with it here too, and it shows up the same way it does on video: as a slight softening, most noticeable in fine detail, and (on models sensitive to it) some drift in consistency the longer the cache runs uninterrupted.

Where this node sits relative to its siblings in the pack: FBCache and MBCache use a relative-similarity threshold in a comparable but distinct way (and MBCache lets you tune it per block); TeaCache here uses TeaCache's own specific decision rule, rel_l1_threshold, ported to Flux's block structure. If you already know TeaCache from Wan workflows, the mental model transfers directly.

How it works

Same skip-block foundation as the rest of the pack - you can statically remove specific DoubleStreamBlocks and SingleStreamBlocks from every step's computation - layered with TeaCache's caching decision on top, governed by a relative L1 distance threshold rather than FBCache's raw similarity threshold.

The inputs and outputs that matter

• skip_DoubleStreamBlocks / skip_SingleStreamBlocks (strings, default "3,6,8,12" / "") - the same static block-skip lists you'll see across the pack's Flux caching nodes.
• do_teacache (boolean, default true) - master switch for the caching behavior. Off, and you're left with just the block-skip effect.
• rel_l1_threshold (float, default 0.4, range 0–10) - TeaCache's own sensitivity knob. Higher values cache more aggressively; the wider range than FBCache's 0–1 threshold reflects that this is measuring a different quantity (relative L1 distance, not a normalized similarity score) - don't assume the numbers are directly comparable between the two nodes.

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 additional dependencies for the caching logic. You need the standard Flux setup from the README either way: 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

Not sure whether to use this, FBCache, or MBCache. They're solving the same problem with different math. There's no one right answer - try FBCache first since it's the simplest, and if you want to compare, swap this node in on the same seed and settings and eyeball the difference. None of them are strictly better across the board; it depends on your model and content.

Faces or fine detail drift across a batch. Same failure mode this family of caching has everywhere it's used, video included - caching reuses stale work, and identity/detail is where you notice it first. Lower rel_l1_threshold, or turn do_teacache off entirely and compare.

Barely any speedup. Check rel_l1_threshold isn't set so low that almost nothing gets cached - remember this node's scale is 0–10, not 0–1, so a value that looks "conservative" by FBCache's standards might genuinely be doing very little here.

Combining with SageAttention or torch.compile and something breaks. Stack these deliberately, one at a time, rather than all at once on a fresh workflow - if something errors or looks wrong, disable nodes one by one to isolate which acceleration is responsible before assuming it's this one.