ApplyTeaCachePatchAdvanced

TeaCache's deal, restated: measure how much the model's input changed since the last denoising step, and when it barely moved, skip the expensive double blocks and reuse the previous residual. On Flux that's roughly 1.5–2x for a small quality hit. This is the Advanced flavor - the same ApplyTeaCachePatch logic plus start_at/end_at, which let you skip only during the middle of the schedule and leave the beginning and end of sampling fully computed.

Why bother with the window? Composition is set in the early steps and fine detail in the last ones; those are the two places skipping shows up worst. The middle is where consecutive steps are most redundant, so that's where the aggressive threshold can live without wrecking the image. The common pattern is start_at: 0.2, end_at: 0.8 with a higher rel_l1_thresh inside.

Inputs

• rel_l1_thresh - the skip threshold, same table as the simple node: Flux 0.25 ≈ 1.5x / 0.4 ≈ 1.8x / 0.6 ≈ 2.0x, HunYuanVideo 0.1–0.15, LTXVideo 0.03–0.05, MochiVideo 0.06–0.09. 0 disables.
• start_at / end_at - the 0–1 fraction of the denoising schedule where caching is active. Both default to the full range (0 and 1), so out of the box this node behaves exactly like the simple one.
• cache_device - main_device (GPU) or offload_device (CPU, default) for the cached residual. Offload saves VRAM.
• wan_coefficients - mandatory-ish for Wan2.1: pick t2v 1.3B / t2v 14B / i2v 480P / i2v 720P to match your model, or the similarity metric is miscalibrated and the first steps can be unstable.

model in, model out.

Install and wiring

It's part of ComfyUI_Patches_ll - ComfyUI Manager under that name, or:

cd ComfyUI/custom_nodes
git clone https://github.com/lldacing/ComfyUI_Patches_ll.git
# restart ComfyUI

Needs ComfyUI ≥ 0.3.17, only numpy + packaging as deps, no model files. Like every cache node here, it needs a *ForwardOverrider (DitForwardOverrider is the auto-detect one) in the model path or it silently does nothing.

The trap

The window is easy to misread. start_at/end_at are fractions of the denoising schedule, not of the step count, and on some schedulers the early high-sigma region eats a big fraction of wall time - so a 0.2–0.8 window still caches a chunk of the expensive beginning. If your speedup feels too small, that's usually why, not a bug. And as with all TeaCache variants, MochiVideo is the author's stated no-go: quality after acceleration is poor and can even go black. Start with the simple node, and reach for this one only when you want to crank the middle of the schedule harder than the ends.