# Cache-method comparison on 4-step block-causal video DiTs

Four training-free caching methods (TeaCache, TaylorSeer, FlowCache, MotionCache)
implemented on two 4-step autoregressive video base models (Self-Forcing and
Causal-Forcing), swept to matched denoise-DiT speedups.

## Layout

```
repos/                     the six upstream clones (reference implementations + base models)
  Self-Forcing/            base model 1   (guandeh17/Self-Forcing)
  Causal-Forcing/          base model 2   (thu-ml/Causal-Forcing)
  TeaCache/                ali-vilab/TeaCache
  TaylorSeer/              Shenyi-Z/TaylorSeer
  FlowCache/               mikeallen39/FlowCache        (ICLR 2026)
  MotionCache/             MAC-AutoML/MotionCache       (ICML 2026)
cachelib/                  the ports -- one implementation, both base models
  methods.py               the four cache methods + baseline + calibration probe
  selective.py             token-subset forward for the KV-cached causal DiT
  patch.py                 routes CausalWanModel._forward_inference through a method
  runner.py                chunked denoising loop with cache hooks and denoise-only timing
harness.py                 model loading, prompt loading, paired A/B measurement
calibrate.py               fits the TeaCache rescale polynomial for a base model
sweep.py                   finds the parameter that hits a target speedup
finalize.py                re-targets on the timed prompts + held-out check (authoritative)
overhead_bench.py          per-step cost of a cached vs a full step (contention-robust)
retime.py                  plain stopwatch re-measurement of the settled points
verify.py                  re-measures operating points on held-out prompts
run_compare.py             single-configuration CLI
summarize.py               collects everything into one table
results/                   JSON output, plus SUMMARY.md / SUMMARY.csv
videos/                    generated mp4s per operating point, plus *_baseline references
```

Pipeline order: `calibrate.py` -> `sweep.py` -> `finalize.py` -> `overhead_bench.py`
-> `retime.py` -> `summarize.py`.

Weights are symlinked from the pre-existing checkouts rather than re-downloaded:

| base | checkpoint | source |
|---|---|---|
| self_forcing | `checkpoints/self_forcing_dmd.pt` (`generator_ema`) | `../Self-Forcing` |
| causal_forcing | `checkpoints/chunkwise/causal_forcing.pt` (`generator`) | `../Causal-Forcing` |

Both also symlink `wan_models/` (Wan2.1-T2V-1.3B backbone, VAE, UMT5 text encoder).

## The setting

Both base models are the same architecture: a block-causal Wan2.1-1.3B DiT that
generates a video chunk at a time. With `num_frame_per_block=3` and 21 latent
frames, a video is **7 chunks x 4 denoising steps = 28 DiT forwards**, plus one
untimed KV-cache refresh pass per chunk (`context_noise`) that rewrites the
chunk's KV entries from the clean latent.

The experiment fixes the schedule to **`F ? ? F`**: step 0 and step 3 always run
the full DiT, steps 1 and 2 are the ones a cache method may skip. This is
equivalent to the upstream `ret_steps=1` / `cutoff_steps=num_steps-1` guards.

**Speedup is measured on denoise-DiT time only** — the sum of the 28 denoising
forwards, timed with CUDA events. Text encoding, VAE decode and the per-chunk
KV-refresh pass are excluded. That makes 2.0x the arithmetic ceiling (14 of 28
forwards), which is why the 2.0x target is exactly "skip both middle steps
everywhere".

## How each method was ported

All four hook the same place: the 30-block loop inside
`CausalWanModel._forward_inference`. The DiT preamble and the head/unpatchify tail
always run.

| method | decision granularity | what a skipped step reuses | knob |
|---|---|---|---|
| TeaCache | whole forward | the 30-block residual `x_out - x_in` from the last computed step | `thresh` |
| FlowCache | per frame group inside the chunk | the same residual, banked per group | `thresh`, `group_size` |
| TaylorSeer | whole forward | a **Taylor forecast** of each block's self-attn / cross-attn / FFN output | `interval`, `max_order` |
| MotionCache | per token, motion-weighted | cached rows for un-selected tokens; selected tokens are recomputed | `thresh`, `weight_norm` |

Skipping the block stack leaves the chunk's KV-cache entries holding the previous
computed step's keys/values. That is safe here: every later step of the chunk
overwrites the same slots, and the per-chunk KV-refresh pass rewrites them from
the clean latent before the next chunk reads them.

### Selective (partial-token) forward

FlowCache and MotionCache recompute only part of the chunk. On a KV-cached causal
model that means, per self-attention layer: compute q/k/v for the selected rows
only, scatter their fresh k/v into the slots the chunk owns (leaving unselected
slots holding the previous step's k/v), and attend the selected queries against
the full cache. This mirrors MotionCache's `forward_selective`, moved from
SkyReels' persistent buffers onto Self-Forcing's rolling `kv_cache`.

Validated: with *all* tokens selected the selective path is **bit-exact** against
the stock full forward (max abs latent difference 0.0). The same check passes for
TaylorSeer's recording path at `interval=1`.

### Deviations from upstream, and why

1. **Indicator.** `TeaCache4Wan2.1` derives its indicator from `e0` (the timestep
   modulation) alone. That is fine for bidirectional Wan, where one forward covers
   the whole video at a single timestep, but it *degenerates* here: every chunk
   runs the same four timesteps, so an `e0` indicator is bit-identical across
   chunks and the threshold cannot adapt to content at all. The default is
   therefore TeaCache's original definition — the relative L1 distance of the
   **timestep-modulated noisy input**, the tensor block 0 feeds to its
   self-attention, which is what TeaCache uses on HunyuanVideo and FLUX.
   `--indicator e0` restores the literal Wan port.

2. **Rescale polynomial.** TeaCache's shipped 4th-degree coefficients were fitted
   for a different model, schedule and indicator, so `calibrate.py` reruns
   TeaCache's own fitting procedure here. The fit is **degree 1, not 4**: on this
   model the input distance only spans ~[1.19, 1.36], where a degree-4 fit is
   ill-conditioned (coefficients ~10^3 with alternating signs) and MotionCache,
   which evaluates the polynomial *per token*, would extrapolate it far outside
   the fitted domain. Degree 1 is monotone and safe. All degrees are recorded in
   the coefficient JSON.

3. **FlowCache granularity.** FlowCache's contribution is that the units covered
   by one forward denoise at different rates and need independent policies. In
   SkyReels-V2 those units are the chunks of the diffusion-forcing window; here a
   forward covers exactly one chunk, so the corresponding units are the frame
   groups inside it (`group_size=1`, i.e. 3 groups). Its KV-cache-compression
   component is not ported: Self-Forcing already bounds its KV cache by local
   attention, so there is no growing cache to compress.

4. **TaylorSeer fractional interval.** TaylorSeer's schedule is a uniform integer
   refresh interval, which on an `F ? ? F` schedule can only produce 1.0x, 1.33x
   and 2.0x. `interval` is accepted as a float and realised as a deterministic
   per-chunk alternation between the two bracketing integer intervals
   (Bresenham-style), giving the requested *average* interval. This keeps
   TaylorSeer's content-independent schedule rather than bolting a threshold onto
   it.

5. **Fused forecast.** TaylorSeer's cached step is ~90 bandwidth-bound elementwise
   ops per forward. Upstream puts `@torch.compile` on the equivalent
   `wan_attention_cache_forward`; the port does the same. Without it the forecast
   ate most of the saving (1.72x measured at a 2.0x FLOPs setting); with it, it
   does not. Set `CACHELIB_NO_COMPILE=1` to disable.

## Scope change (Sep 4)

FlowCache is frozen: its finished operating points stay in the tables, nothing new
is generated for it.  The continuing study is **three methods** (TeaCache,
TaylorSeer, MotionCache) x **three base models** (Self-Forcing, Causal-Forcing,
HY-WorldPlay) x **three points**: `FxxF` at ~1.3x, `FxxF` at 1.7-1.8x, and `Fxxx`
at 2.7-3.0x -- all targeted on **measured** wall-clock speedup, not on the compute
fraction.  The reason is MotionCache: matching compute at 2.0x under `FxxF` forces
its per-token selection to pick *zero* tokens, which makes it bit-identical to
TeaCache and reproduces nothing.  Operating points are now chosen as the fastest
setting that still keeps the token-level decision active (>=25% of cacheable steps
partial, >=5% of tokens selected on those steps); the activity statistics are
recorded per video in ``cache_diagnostics``.

## Schedules beyond `FxxF`

Every entry point takes `--schedule` (`sweep.py`, `finalize.py`, `run_compare.py`;
the evaluation reads it from the `final_*.json` rows).  `F` marks a step that always
runs the full DiT, `x` one the method may serve from cache: `FxxF` is the study
above and the default; `FFxx` gives TaylorSeer two computed points before its first
forecast so the first-order term is actually exercised; `Fxxx` lifts the cool-down
guard and raises the arithmetic ceiling to 4x.  Operating points for `FFxx`
(TaylorSeer, 1.3/1.6/2.0x) and `Fxxx` (the other three, ~3x) were searched on
3 prompts (`results/sweep_*_{FFxx,Fxxx}.json`, collected in
`results/final_<base>_newsched.json`) and evaluated on Extended-251.

**All results, speed and quality, are collected in `Experiment.md`**
(regenerate with `python experiment_md.py`).  The headline of the second round:
caching the *last* denoising step -- which every `Fxxx` point and every `FFxx`
point at >= 1.6x does -- costs 15-25 VBench points on both base models, while
`FxxF` at the same compute costs 1-2.  On a 4-step distilled model the final step
is not optional.

## Measurement protocol

This is a **shared node** and it was busy throughout. Other tenants' jobs move
absolute timings by 30%+ and drift them *within* a single sweep, so a baseline
measured once at the start silently inflates every later configuration. Four
things follow, and they are the difference between numbers worth reading and
numbers that are noise:

1. **Search on compute, not on time.** The parameter search runs on the compute
   fraction (how many of the 28 DiT forwards were actually computed), which is
   exactly deterministic given the prompt set and immune to contention. Targets
   are aimed at the compute budget directly, which also puts all four methods on
   identical compute — the right basis for a later quality comparison. Correcting
   the target by a measured overhead ratio was tried and abandoned: that ratio is
   itself a timing measurement, one probe returned 1.110 (physically impossible),
   and it dragged a whole method's operating points below target.

2. **Paired A/B.** Baseline and method run back to back on the same prompt, so
   drift between them is seconds rather than minutes.

3. **Minimum, not median, as the headline.** Contention is one-sided — a
   neighbour can only make a run slower — so the fastest observed run is the best
   estimate of the uncontended time, and the headline speedup is
   `min(baseline) / min(method)` over the pairs. The paired median is reported
   alongside but is biased *upward*, because the baseline run is longer and so
   more exposed to being hit by a spike; that is why it sometimes exceeded a
   method's arithmetic ceiling.

4. **Compute fraction from the timed runs.** A threshold tuned on one prompt
   subset and timed on another silently disagrees whenever it sits near a decision
   boundary. `finalize.py` reports the compute fraction of the very runs it timed,
   and re-tunes on those prompts if it misses.

`finalize.py` also re-checks every point on a disjoint prompt slice, so a
threshold that only hit its target by sitting inside a narrow band of the
indicator distribution shows up as held-out drift. `verify.py` does the same
check standalone against a sweep file.

## Reproducing

```bash
PY=/local/zoubin/cz/envs/self_forcing/bin/python

# 1. fit the rescale polynomial (once per base model)
CUDA_VISIBLE_DEVICES=0 $PY calibrate.py --base self_forcing \
    --num-prompts 12 --out results/coeff_self_forcing.json

# 2. sweep one method to the three target speedups
CUDA_VISIBLE_DEVICES=0 $PY sweep.py --base self_forcing --method teacache \
    --coefficients results/coeff_self_forcing.json \
    --targets 1.3,1.6,2.0 --save-video-dir videos \
    --out results/sweep_self_forcing_teacache.json

# 3. check the settings transfer to unseen prompts
CUDA_VISIBLE_DEVICES=0 $PY verify.py \
    --sweep results/sweep_self_forcing_teacache.json --prompt-offset 64 \
    --out results/verify_self_forcing_teacache.json

# 4. collect everything
$PY summarize.py
```

`run_compare.py` runs a single configuration if you just want one number:

```bash
CUDA_VISIBLE_DEVICES=0 $PY run_compare.py --base causal_forcing \
    --method taylorseer --interval 2.5 --num-prompts 8
```

## Environment note

**Sep 3:** the machine was restored again -- `/mnt/local_nvme` became `/local`,
both environments lost their executable bits a second time (1632 files restored),
the `vbench_eval` venv's `pyvenv.cfg`/interpreter links pointed at the old path
(now symlinks into `/local/.../self_forcing`), and the caches moved to
`/local/zoubin/cz/.cache/`.  Paths in `eval/*.sh`, `eval/aggregate.py` and the
per-prompt records were updated accordingly.  The node is shared: other tenants'
launches have repeatedly killed GPU processes of ours, so long runs go through
`eval/retime_until_clean.sh`-style loops that only use quiet GPUs and resume.

The conda environment at `/mnt/local_nvme/zoubin/cz/envs/self_forcing` had lost
every executable bit (a bad restore left all files `rw-rw-r--`), so nothing in it
could run — including Triton's bundled `ptxas`, which broke `torch.compile`. The
exec bits were restored on files that are ELF binaries or start with `#!`
(1772 files). No package contents were changed.

## Results

Full tables: `results/SUMMARY.md` (regenerate with `python summarize.py`), machine
readable in `results/SUMMARY.csv` and the per-stage JSONs.

**Headline speedup** is the denoise-DiT speedup implied by the measured compute
fraction and the measured per-step cost model (see Measurement protocol). The
`stopwatch` column is the plain paired whole-video ratio; it agrees within its
(large) spread but is not the number to quote from this node.

### Operating points found

| base | method | knob | 1.3x | 1.6x | 2.0x |
|---|---|---|---|---|---|
| Self-Forcing | TeaCache | `thresh` | 0.6348 → **1.30x** | 1.2507 → **1.48x** | 1.2917 → **1.96x** |
| Self-Forcing | FlowCache | `thresh` | 0.6360 → **1.30x** | 1.2500 → **1.51x** | 1.2917 → **1.96x** |
| Self-Forcing | TaylorSeer | `interval` | 2.083 → **1.31x** | 2.583 → **1.59x** | 2.917 → **1.89x** |
| Self-Forcing | MotionCache | `thresh` | 0.7560 → **1.29x** | 1.2461 → **1.60x** | 2.5000 → **1.96x** |
| Causal-Forcing | TeaCache | `thresh` | 0.6491 → **1.30x** | 1.2760 → **1.51x** | 1.2917 → **1.96x** |
| Causal-Forcing | FlowCache | `thresh` | 0.6488 → **1.26x** | 1.2760 → **1.61x** | 1.2917 → **1.95x** |
| Causal-Forcing | TaylorSeer | `interval` | 2.083 → **1.31x** | 2.583 → **1.59x** | 2.917 → **1.89x** |
| Causal-Forcing | MotionCache | `thresh` | 0.7695 → **1.30x** | 1.2647 → **1.57x** | 2.8750 → **1.96x** |

### What a cached step actually costs

Minima over ~1900 per-step samples per base, so these are solid:

| method | cached step, as a fraction of a full step | ceiling at 14/28 forwards |
|---|---|---|
| TeaCache | 1.9% | 1.96x |
| MotionCache | 2.0% | 1.96x |
| FlowCache | 2.3% | 1.96x |
| TaylorSeer | 5.6 - 5.8% | 1.89x |

A full denoising forward costs 76-77 ms uncontended (1 chunk = 3 latent frames,
4680 tokens, Wan2.1-1.3B, H100). **2.0x is the arithmetic ceiling** of this
schedule, and the achievable ceiling is ~1.96x for three of the methods.
TaylorSeer pays more because its cached step is a Taylor *forecast*, not a copy:
30 layers x 3 module features have to be extrapolated and re-modulated. That is
already with the `torch.compile` fusion upstream uses; without it the same step
costs ~25% of a full one and the method tops out near 1.7x.

### Three findings

1. **The TeaCache-family indicator carries almost no signal on a 4-step distilled
   model.** Calibration over 252 (chunk, step) pairs: at a given denoising step the
   indicator's spread *across chunks* is a standard deviation of 0.0013 on a mean
   of 1.35 (0.1%), while the gaps *between* steps are 0.04-0.10. So the threshold
   is really choosing *which step index* to skip, not adapting per chunk. Worse,
   within a step the indicator is *negatively* correlated with the actual reuse
   error (r = -0.54 / -0.58 at steps 1 and 2); the +0.49 overall correlation is
   entirely a between-step effect, and a degree-4 fit only reaches R^2 = 0.26.

2. **That makes 1.6x hard to hit for the threshold methods and easy for the other
   two.** TeaCache's reachable points on Self-Forcing are essentially quantised to
   {1.0, 1.33, ~1.48, 2.0} — the requested 1.6x falls in a gap, and the closest
   honest point is 1.48x. FlowCache, deciding per frame group, does slightly better
   (1.51x on Self-Forcing, 1.61x on Causal-Forcing). TaylorSeer (fractional
   interval) and MotionCache (per token) land on 1.59x / 1.60x directly, because
   both have a genuinely continuous knob.

3. **Generalisation splits the methods the same way.** Re-running each setting on
   64 prompts it was never tuned on, the compute fraction drifts by:

   | method | worst held-out drift |
   |---|---|
   | TaylorSeer | 0.000 |
   | MotionCache | 0.008 |
   | TeaCache | 0.079 |
   | FlowCache | 0.070 |

   TeaCache's and FlowCache's 1.3x and 1.6x settings sit inside a razor-thin band
   of the indicator distribution, so they do not transfer; their 2.0x settings
   (where everything skips regardless) transfer perfectly. TaylorSeer's schedule is
   content-independent by construction, and MotionCache's per-token thresholding
   averages over 4680 decisions per step instead of one.

### Artifacts for a quality comparison

`videos/<base>_<method>_x<target>/NNNN.mp4` holds 7-10 clips per operating point,
and `videos/<base>_baseline/NNNN.mp4` the matching all-full references (same
prompts, same seed, indices align).  The quality numbers are in `Experiment.md`
(Extended-251 evaluation, next section).

---

# Self-Forcing Extended-251 Full Evaluation

VBench-8 + FFFF-relative pixel metrics + matched-prompt policy latency, following
`self_forcing_extended_full_evaluation_protocol.md`, with the protocol's paths
remapped to this machine.

## Path remapping

| Protocol path | Here |
|---|---|
| `/data3/chenzhuo/anaconda3/envs/self_forcing` | `/mnt/local_nvme/zoubin/cz/envs/self_forcing` |
| `$SELF_FORCING_REPO/.evaluation_env/vbench_site2` | absent -> `/mnt/local_nvme/zoubin/cz/projects/VBench` on `PYTHONPATH` |
| `/data3/chenzhuo/.cache/vbench` | `/mnt/local_nvme/zoubin/cache/vbench` |
| `prompts/vbench/all_dimension{,_extended}.txt` | `../Self-Forcing/prompts/vbench/` |
| `assets/vbench8_extended_subset_mapping.json` | absent -> rebuilt by `eval/build_mapping.py` |

## Files

```
assets/vbench8_extended_subset_mapping.json   the 251-row mapping (built + validated here)
eval/build_mapping.py      946 -> 251 selection, with the protocol's validation gate
eval/strategies.py         FFFF + the 12 settled operating points, per base model
eval/generate_eval.py      video generation, latency split, pixel metrics
eval/pixel_metrics.py      PSNR / SSIM / LPIPS on decoded frames, pre-encode
eval/run_vbench.py         the eight dimensions, stock VBench metric code
eval/aggregate.py          normalize -> Quality/Semantic/Selected, latency, final tables
eval/test_protocol.py      the section 12 unit tests
eval/run_generation.sh / run_vbench_all.sh / run_all_phases.sh   8-GPU drivers
eval_out/                  generated_videos/ per_prompt/ vbench/ summaries/
```

## Strategies

26 = 2 base models x (FFFF + 4 cache methods x 3 speed targets). FFFF is the
all-full 4-step baseline and is each base model's own reference for both the
pixel metrics and the latency speedup. Cache parameters are read back from
`results/final_<base>*.json`, so the evaluation scores exactly the operating
points the speed study settled on.

## Two environments, on purpose

Generation runs in the **base `self_forcing` env** -- the same interpreter and
package set the speed study used, so the evaluated videos come from exactly the
benchmarked stack. The only addition to that env is `lpips`.

VBench runs in the **`vbench_eval` venv**. It has to: the base env carries
`torchao 0.17.0`, which is unimportable under `torch 2.5.1` (it references
`torch.int1`), and `transformers.modeling_utils` pulls torchao in through its
quantizer registry -- so `BertModel`, and therefore Tag2Text and the `scene`
dimension, cannot load there. The venv pins `torchao==0.7.0`,
`transformers==4.46.3` and adds `fairscale`. This is a deviation from protocol
section 2.1 (one environment for everything); it does not touch generation.

The venv itself needed repair first: a bad restore had flattened its `bin/python`
symlinks into text files and stripped every executable bit.

## Protocol conformance

Verified before the run:

* mapping is 251 rows = 72 / 93 / 86, `global_index` unique, `suite_index`
  contiguous, all 86 scene rows keep `auxiliary_info`, and the 946 short prompts
  match `VBench_full_info.json` in order exactly (selection is by index -- two
  prompt texts are duplicated, so text matching is unsafe and is forbidden);
* SHA256 recorded for the short prompts, extended prompts, `VBench_full_info.json`
  and the mapping;
* videos are 81 frames, 480x832, 16 FPS, seed 0, one sample per prompt;
* `prompt_en` handed to VBench is the **extended** prompt actually generated from;
* each dimension scores only its own suite (72 / 93 / 86), driven by the mapping;
* `policy_latency_ms` covers the denoise path only; the context/KV-cache DiT is
  timed separately into `excluded_context_kv_latency_ms` (~790 ms/video) and never
  added in;
* pixel metrics run on the decoded RGB tensors before MP4 encoding, over all 81
  frames, with FFFF-vs-itself pinned to 120 dB / 1.0 / 0.0;
* `eval/test_protocol.py` covers the section 12 checklist and passes.