FlowCache: Flow Caching for Autoregressive Video Generation

Paper: arXiv:2602.10825 Code: mikeallen39/FlowCache Code reference: main @ 1fdfa57a (2026-04-24) Venue: ICLR 2026 一句话: FlowCache 把自回归视频生成里的缓存复用从“所有 chunk 同步决策”改成“每个 chunk 独立决策”，再用 importance-redundancy KV compression 控制历史 KV cache 的显存增长。

1. Motivation (研究动机)

自回归视频生成模型的目标是生成超长视频。MAGI-1 和 SkyReels-V2 这类模型不再一次性对整段视频做全局 DiT denoising，而是把视频切成多个 chunk 或 block，按时间顺序逐段生成。这种范式能把长序列的注意力复杂度从随视频 token 长度二次增长，转成在固定 denoising window 内近似线性扩展。但它没有直接解决实际推理时间。论文给出的典型例子是：在单张 A800 GPU、batch size 1 下，MAGI-1-4.5B-distill 生成 720×720、10 秒视频，在 full KV cache reference 设置下需要约 32GB 显存和约 50 分钟推理时间。

因此，自回归结构让“超长视频”变得可行，但还没有让“实时或接近实时”变得可行。现有 training-free caching 方法主要来自同步 video diffusion / DiT 推理。它们利用相邻 denoising timestep 的模型输出相似性：如果变化足够小，就跳过当前 timestep 的完整 forward，并复用上一次的输出或 residual。这类方法的优势是不需要重新训练，不改变主模型参数，也能和 quantization、sparsity 等方法正交组合。核心问题是：它们默认同一 timestep 下所有 frame 或 token 处于相同 denoising stage。

这个假设在同步扩散模型中相对合理，因为整段视频一起从噪声走向干净视频。但在自回归视频模型中，同一 wall-clock timestep 里，不同 chunk 可能处于完全不同的 denoising 进度。有的 chunk 刚进入 denoising window，仍接近 Gaussian noise。有的 chunk 已经接近 clean video，细节变化对画质影响很大。如果继续对所有 chunk 使用统一缓存策略，会出现两个方向的错误。第一，过度复用已经接近 clean video 的 chunk，会造成细节、纹理、运动一致性退化。第二，强制重新计算仍然接近噪声的 chunk，会浪费本可以跳过的 forward。论文用 TeaCache 对比展示了这种错配。

在 MAGI-1 上，TeaCache-fast 只达到 1.44× speedup，但 VBench 从 Vanilla 的 77.06% 降到 70.11%。在 SkyReels-V2 上，TeaCache-fast 为 2.2× speedup，VBench 为 80.06%，明显低于 Vanilla 的 83.84%。也就是说，传统缓存策略要么保守、加速有限，要么激进、质量下降明显。自回归视频还带来第二个瓶颈：KV cache 会随历史 chunk 增长。在 autoregressive generation 中，已经生成的 clean chunks 需要作为历史上下文被后续 chunk attention 到。

这类似 LLM 的 token-by-token KV cache，但视频 token 具有更强的空间和时间冗余。

如果不压缩，历史 KV cache 会占据越来越多显存，并增加 attention 计算成本。如果只照搬 LLM 的 importance-only KV cache selection，则容易保留大量“注意力分数高但彼此相似”的视频 patch。这会浪费有限 cache budget，并损害长视频的时间一致性。 FlowCache 要解决的具体问题不是“训练一个更快的视频模型”。它解决的是：在不训练、不改主模型权重的前提下，如何让自回归视频模型在 chunk-level denoising 异质性和 KV cache 线性增长之间取得更好的效率-质量折中。这个问题值得研究，因为它直接影响长视频生成能否进入交互式或生产级场景。若缓存策略足够细粒度，系统可以把计算集中在真正需要更新的 chunk 上。若 KV cache 能保持固定预算，模型可以继续利用长上下文，而不会被显存线性增长卡住。 FlowCache 的定位正是在这两个瓶颈之间提供一个 training-free、模型兼容性较强的系统加速层。

2. Idea (核心思想)

FlowCache 的核心洞察是：缓存复用的基本单位不应该是“整个 timestep”，而应该是“每个 video chunk 在当前 timestep 的 denoising 状态”。换句话说，同一轮 sampler update 中，chunk A 可以复用缓存，chunk B 可以重新 forward，chunk C 可能刚进入窗口而必须计算。这种策略把传统 cache reuse 的二值全局决策，变成按 chunk 独立维护的状态机。论文用 Figure 2 证明这种设计不是经验猜测，而是来自 autoregressive video diffusion 的相似性轨迹。

Figure 2 解读: 图中横轴是 denoising progress，纵轴是 adjacent-timestep relative L1 distance，不同颜色代表不同 video chunk。MAGI-1 与 SkyReels-V2 都显示三件事：relative L1 distance 会随 denoising 接近 clean video 而增大；同一 timestep 不同 chunk 的 distance 差异明显；模型输入与 sampler 输出在所有 chunk 上仍保持高相似性。因此，缓存复用有空间，但复用概率必须按 chunk 区分。

这里的 intuition 可以概括为：接近纯噪声的 chunk，当前 timestep 与前一 timestep 的表征变化较小。这种 chunk 适合连续多步复用缓存。接近 clean video 的 chunk，细节和结构已经开始成形。这种 chunk 的相邻 timestep 差异变大，继续复用容易破坏纹理和运动。因此，FlowCache 采用 per-chunk accumulated relative L1 distance。每个 chunk 单独累计自己的相似性变化。累计值低于阈值时复用缓存。累计值超过阈值时重新 forward，并重置该 chunk 的累计状态。

这种策略比 TeaCache 更灵活，因为 TeaCache 的累计相似性本质上把所有 chunk 混成一个整体。FlowCache 的第二个想法是：KV cache compression 不能只看 attention importance。视频中相邻 patch、相邻 frame、相邻 chunk 往往高度相似。如果只保留 attention score 高的 token，cache 里可能充满重复背景、重复物体区域或近似时间片段。因此，FlowCache 给历史 KV token 一个联合分数：一部分奖励它对当前 denoising query 的重要性。另一部分惩罚它与其他历史 token 的冗余度。最终保留“重要且不冗余”的历史 KV。这个设计有两个实际目标。

第一，让 clean-chunk KV cache 的大小保持在固定 budget 内。第二，在压缩后仍然保留足够多样的历史信息，以维持人物、背景、运动和物理一致性。FlowCache 的贡献可以拆成三个层级。经验层级：证明 autoregressive video generation 中 chunk 间 denoising state 不同步。算法层级：提出 chunkwise adaptive caching，让每个 chunk 独立决定 compute / reuse。系统层级：提出面向视频的 KV cache compression，把 clean chunks 和 active denoising chunks 分区管理。

这个方法是 training-free 的。它不需要重新训练 MAGI-1 或 SkyReels-V2。它主要插入 sampler / inference pipeline，改变每一步是否调用模型、如何复用输出、以及如何保留历史 KV。因此，它更像 inference-time scheduler + cache manager，而不是新的生成模型架构。

3. Method (方法)

3.1 Flow Matching 与自回归视频建模

论文先把普通 diffusion / flow matching 形式写清楚。

在 flow matching 中，中间状态可以表示为： $x_{t} = (1 - σ (t)) \cdot x_{data} + σ (t) \cdot x_{noise} .$ 其中 $σ (t)$ 是从 data 到 noise 的调度函数。反向生成过程学习一个 velocity field $v_{θ} (x_{t}, t, c)$ 。采样时可用 Euler discretization 更新： $x_{t_{i - 1}} = x_{t_{i}} + v_{θ} (x_{t_{i}}, t_{i}, c) Δ t_{i} .$ 对自回归视频模型，视频被切成 $k$ 个 chunk。第 $i$ 个 chunk 记为 $X^{i} \in R^{c_{in} \times s \times h \times w}$ 。 $s$ 是 chunk 的时间长度， $h, w$ 是 latent 空间分辨率。最大 denoising window size 记为 $l$ 。第 $i$ 个 chunk 在 timestep $t$ 的更新可写为： $X_{t - 1}^{i} = X_{t}^{i} + v_{θ} (X_{t}^{i}, t, c) \cdot Δ t .$ 这个式子强调：自回归视频里的 chunk 是生成和缓存的基本单位。

不同 chunk 进入 denoising window 的时间不同，因此它们在同一全局时刻的噪声程度也不同。

3.2 Relative L1 Distance 的 chunkwise 形式

传统缓存方法常用 relative L1 distance 衡量相邻 timestep 的输出变化： $L 1_{rel} (X, t) = \frac{∥ X _{t - 1} - X _{t} ∥ _{1}}{∥ X _{t} ∥ _{1}} .$ FlowCache 把它改写为第 $i$ 个 video chunk 的度量： $L 1_{rel} (X, t, i) = \frac{∥ X _{t - 1}^{i} - X _{t}^{i} ∥ _{1}}{∥ X _{t}^{i} ∥ _{1}} = \frac{∥ v _{θ} ( X _{t}^{i} , t , c ) \cdot Δ t ∥ _{1}}{∥ X _{t}^{i} ∥ _{1}} .$ 这个公式的重要性在于它把“是否相似”从全局 video tensor 拆到了 chunk 级别。如果 $L 1_{rel} (X, t, i)$ 小，说明第 $i$ 个 chunk 在当前步变化小，适合复用。如果它大，说明当前 chunk 处于更敏感的 denoising 阶段，应重新计算。论文的 Theorem 1 假设模型已收敛到 flow matching 的 optimal velocity field，且 $σ (t) = (t / T)^{p}$ 。在 $0 < t_{1} < t_{2} \leq T$ 时，有： $L 1_{rel} (X, t_{1}, i) \geq L 1_{rel} (X, t_{2}, i) .$ 注意这里的时间方向需要结合论文的 denoising progress 理解。直观结论是：当 chunk 从 noise 走向 clean video，相邻 timestep 的 relative L1 distance 变大，相似性下降。因此，越接近 clean 的 chunk 越不应激进复用。 Corollary 1 进一步说明，如果两个 chunk 的内容不同、状态范数不同，即使在同一个 timestep，它们的 $L 1_{rel}$ 也会不同： $L 1_{rel} (X, t, i) \neq = L 1_{rel} (X, t, j) .$ 这就是 chunkwise cache policy 的理论依据。

3.3 Chunkwise Adaptive Caching

FlowCache 为每个 chunk 维护一个累计函数 $f (X, t, i)$ 。

论文给出的决策形式是： $f (X, t, i) = ⎩ ⎨ ⎧ 0, 0, f (X, t + 1, i) + L 1_{rel} (X, t, i), t \in (T - m, T], t \in [0, T - m] and f (X, t + 1, i) + L 1_{rel} (X, t, i) > ϵ, t \in [0, T - m] and f (X, t + 1, i) + L 1_{rel} (X, t, i) \leq ϵ .$ $ϵ$ 是复用阈值。 $m$ 是排除 cache reuse 的 warmup timesteps。论文设置 $m = 5$ for MAGI-1， $m = 4$ for SkyReels-V2。当 $f (X, t, i) = 0$ 时，第 $i$ 个 chunk 做真实 forward。当 $f (X, t, i) \neq = 0$ 时，第 $i$ 个 chunk 复用缓存。论文报告的阈值为：

模型 / 配置	$ϵ$
MAGI-slow	0.01
MAGI-fast	0.015
SkyReels-V2-slow	0.1
SkyReels-V2-fast	0.15

这个设计有一个重要细节：新进入 denoising window 的 chunk 不能直接复用。它必须先计算，建立自己的 feature / residual / KV 状态。同样，接近 clean 的 chunk 因为 $L 1_{rel}$ 增大，更容易触发重新计算。这与传统策略相反：传统策略同一 timestep 下所有 chunk 共享 compute/reuse 状态，只排除刚初始化的新 chunk。 FlowCache 的 per-chunk 状态让系统能在同一个 timestep 中同时出现 calculate 和 reuse。

Figure 3 解读: 上半部分是 Traditional Reuse，所有 chunk 在同一 timestep 共享相同的计算/复用决策。下半部分是 FlowCache：每个 denoising chunk 根据自己的 relative L1 trajectory 独立决定是否重新计算。右侧展示 KV cache 管理：Clean KV Cache 被压缩到 Reserved KV Cache，当前 denoising chunk 则保留 active KV 区域。

3.4 Chunkwise Caching 的伪代码

下面伪代码对应论文公式 (8) 与代码中的 ChunkWiseCache 逻辑。

def flowcache_step(chunks, timestep, cache_state, epsilon, warmup_steps):
    outputs = {}
 
    for chunk_id, x_i_t in chunks.items():
        # 新 chunk 或 warmup 区间必须真实计算
        if cache_state.is_new(chunk_id) or cache_state.step(chunk_id) < warmup_steps:
            y_i = model_forward(x_i_t, timestep)
            cache_state.store(chunk_id, x_i_t, y_i)
            cache_state.reset_accumulated_l1(chunk_id)
            outputs[chunk_id] = y_i
            continue
 
        # 计算当前 chunk 自己的 relative L1，而不是全局 video L1
        l1_rel = relative_l1_distance(
            previous=cache_state.previous_feature(chunk_id),
            current=x_i_t,
        )
 
        proposed = cache_state.accumulated_l1(chunk_id) + l1_rel
 
        if proposed <= epsilon:
            # 变化小：复用该 chunk 的缓存输出或 residual
            y_i = cache_state.reuse(chunk_id)
            cache_state.set_accumulated_l1(chunk_id, proposed)
        else:
            # 变化大：重新 forward，并重置累计量
            y_i = model_forward(x_i_t, timestep)
            cache_state.store(chunk_id, x_i_t, y_i)
            cache_state.reset_accumulated_l1(chunk_id)
 
        outputs[chunk_id] = y_i
 
    return merge_chunk_outputs(outputs)

这段伪代码的重点不是 relative_l1_distance 本身，而是 accumulated_l1 的作用域。 TeaCache 类方法通常维护一个全局累计量。 FlowCache 维护 chunk_id -> accumulated_l1。这让同一 timestep 中每个 chunk 都可以独立跨过或不跨过阈值。

3.5 KV Cache Compression

自回归视频模型的 KV cache 包含两类信息。第一类是已经 clean 的历史 chunks，它们用于给后续 chunk 提供长程上下文。第二类是当前正在 denoising 的 active chunks，它们还会继续更新。 FlowCache 把固定大小的 KV cache buffer $B_{total}$ 分成两个区域： $B_{total} = B_{budget} + B_{active} .$ $B_{budget}$ 是 compressed clean-chunk region。 $B_{active}$ 是 current denoising region。当 clean-chunk region 加上新完成 denoising 的 chunk 超过预算时，系统把 clean KV 合并后重新选择保留项。选择标准同时考虑 importance 和 redundancy。令当前 denoising tokens 的 query 为： $Q \in R^{L_{q} \times H_{q} \times d} .$ 令 clean chunks 的 key 为： $K_{clean} \in R^{L_{k} \times H_{k} \times d} .$ 对每个 key head $h$ ，importance 来自当前 query 对历史 key 的 attention 权重。

论文写成： $Imp_{j}^{(h)} = \frac{1}{L _{q}} \sum_{i = 1}^{L_{q}} [softmax (\frac{q _{i}^{(h)} ( K _{clean}^{(h)} ) ^{⊤}}{d}) e_{j}] .$ 为了鲁棒性，importance 会经过 1D max pooling： $Imp_{g}^{(h)} = MaxPool1D (Imp^{(h)}; kernel = k, padding = k /2) .$ Redundancy 则来自 clean keys 之间的 cosine similarity。

对 $K_{clean}$ 做 $ℓ_{2}$ normalization 后，计算： $S_{ij}^{(h)} = (k_{i}^{(h)})^{⊤} k_{j}^{(h)}, S_{ii}^{(h)} = 0.$ 然后对 token 维度平均并 softmax，得到每个历史 token 的冗余分布： $Red_{j}^{(h)} = softmax (\frac{1}{L _{k}} \sum_{i = 1}^{L_{k}} S_{ij}^{(h)})_{j} .$ 最终分数为： $Score_{j}^{(h)} = λ \cdot Imp_{g, j}^{(h)} - (1 - λ) \cdot Red_{j}^{(h)} .$ 每个 head 保留 top- $B$ tokens。 $λ$ 控制 importance 与 redundancy 的折中。论文和代码的默认选择都是 $λ = 0.07$ 。这意味着 redundancy penalty 权重很大，符合视频 token 高冗余的特点。直观上，FlowCache 宁愿丢掉一些“重要但重复”的 patch，也要保留更多互补历史证据。

3.6 KV Compression 的伪代码

def compress_clean_kv(query_states, clean_keys, clean_values, budget, lambda_):
    # Step 1: importance from attention between current query and clean keys
    attn = softmax((query_states @ clean_keys.transpose(-1, -2)) / sqrt(head_dim))
    importance = attn.mean(dim="query")
    importance = max_pool_1d(importance, kernel_size=k, padding=k // 2)
 
    # Step 2: redundancy from pairwise cosine similarity among clean keys
    normalized_keys = l2_normalize(clean_keys, dim=-1)
    similarity = normalized_keys @ normalized_keys.transpose(-1, -2)
    similarity.diagonal().fill_(0)
    redundancy = softmax(similarity.mean(dim="token"))
 
    # Step 3: keep important but non-redundant entries
    score = lambda_ * importance - (1 - lambda_) * redundancy
    keep_index = topk(score, k=budget, dim="token")
 
    compressed_keys = gather(clean_keys, keep_index)
    compressed_values = gather(clean_values, keep_index)
 
    return compressed_keys, compressed_values, keep_index

这段伪代码对应论文公式 (9)–(12)。实际代码中还要处理 token / frame / chunk granularity、不同 head 的索引、clean region 与 active region 拼接、以及压缩后的 KV range 更新。因此，论文公式描述的是 scoring criterion，工程实现还包含 cache layout bookkeeping。

3.7 与代码实现的对应关系

代码仓库已公开，验证锚点为 main@1fdfa57a (2026-04-24)。

MAGI-1 与 SkyReels-V2 的实现目录分开。

论文组件	代码位置	作用
MAGI-1 FlowCache 入口	`FlowCache4MAGI-1/inference/pipeline/flowcache.py`	绑定 `SampleTransport.forward_velocity` / `integrate_velocity`，在推理中执行 per-chunk reuse 与 KV compression
Chunkwise cache 状态	`FlowCache4MAGI-1/inference/pipeline/cache/cachereuse.py`	`ChunkWiseCache` 维护 per-chunk accumulated L1、reuse flag、previous residual
MAGI-1 KV scoring	`FlowCache4MAGI-1/inference/pipeline/kvcompress/kv_compressor.py`	计算 importance、similarity / redundancy、final score，并执行 token / frame / chunk selection
MAGI-1 KV layout	`FlowCache4MAGI-1/inference/pipeline/cache/utils.py`	生成 dynamic KV range、识别可压缩 clean chunks、计算 chunk token 数
MAGI-1 单样例配置	`FlowCache4MAGI-1/yaml_config/single_run/config.yaml`	`rel_l1_thresh: 0.015`, `warmup_steps: 5`, `compress_kv_cache: true`, `total_cache_chunk_nums: 5`, `mix_lambda: 0.07`
MAGI-1 VBench 配置	`FlowCache4MAGI-1/yaml_config/sample/flowcache_vbench.yaml`	`rel_l1_thresh: 0.01`, `warmup_steps: 5`, `budget_cache_chunk_nums: 1`, `query_granularity: chunk`, `mix_lambda: 0.07`
SkyReels-V2 FlowCache transformer	`FlowCache4SkyReels-V2/skyreels_v2_infer/modules/transformer_flowcache.py`	管理 group-wise accumulated relative L1、clean chunk index、compression 调用
SkyReels-V2 KV compression	`FlowCache4SkyReels-V2/skyreels_v2_infer/modules/compression/compress_kv.py`	`R1KV` 实现 token / frame / chunk compression strategy
SkyReels-V2 sampling pipeline	`FlowCache4SkyReels-V2/skyreels_v2_infer/pipelines/diffusion_forcing_pipeline.py`	设置 `ar_step`、`causal_block_size`、overlap history，并清理 / 初始化 teacache 状态
SkyReels-V2 fast 脚本	`FlowCache4SkyReels-V2/run_flowcache_fast.sh`	`ar_step=5`, `causal_block_size=5`, `base_num_frames=97`, `num_frames=177`, `overlap_history=17`, `inference_steps=50`, `teacache_thresh=0.15`

一个容易误读的工程细节是：SkyReels-V2 脚本仍使用 --teacache / --teacache_thresh 这样的参数名。这更像复用原有 pipeline 的开关命名，而不是说明它只运行传统 TeaCache。 FlowCache 相关逻辑实际落在 transformer_flowcache.py 与 compression modules 里。 MAGI-1 代码中则更直接使用 flowcache.py、ChunkWiseCache、KVCompressor 命名。

3.8 方法边界与失败模式

FlowCache 不改变模型训练目标，也不解决模型本身的语义理解或运动建模能力。如果 base model 在某个 prompt 上本来就不稳定，FlowCache 只能尽量不额外破坏质量。 FlowCache 的阈值是效率-质量 trade-off 的主旋钮。 $ϵ$ 越大，越多 chunk 会复用，速度越快，但高频细节与 motion consistency 风险更高。 $ϵ$ 越小，越保守，质量更稳，但 speedup 降低。 KV cache budget 也是同样的 trade-off。

预算太小可能丢失长期上下文。预算太大则显存与 latency 收益下降。论文的 ablation 显示 $λ = 0.07$ 在 Physics-IQ 上最优，但这不意味着所有模型、分辨率和 prompt 类型都共享同一最优值。因此，FlowCache 更适合被视为一套可配置 inference policy。部署时应按目标模型、视频长度、分辨率、质量指标重新校准阈值和 cache budget。

4. Experimental Setup (实验设置)

4.1 Base Models

论文选择两个代表性的 autoregressive video diffusion 模型。第一个是 MAGI-1-4.5B-distill。它把视频切成 chunks，并在 chunks 之间做 autoregressive modeling。它使用 sliding window 约束同时 denoising 的 chunk 数量。主实验中，每个 chunk 为 24 frames。每个 chunk denoise 64 steps。共生成 10 chunks。第二个是 SkyReels-V2-1.3B-540P。它采用更层级化的 block denoising。每个 video chunk 又被分成 blocks。

较早 block 先 denoise 若干步，后续 block 再进入 denoising。主实验中，每个 chunk 为 97 frames。相邻 chunks overlap 17 frames。每个 block denoise 50 steps。共生成 2 chunks。这两个模型的差异很重要。MAGI-1 展示普通 chunk-level autoregressive denoising。SkyReels-V2 展示 chunk 内部 block-level 非均匀 denoising。FlowCache 在二者上都有效，说明方法不是只针对某一个具体 pipeline。

4.2 Baselines

主要对比方法包括 Vanilla、TeaCache-slow、TeaCache-fast、FlowCache-slow、FlowCache-fast。 Vanilla 是原始模型，不做缓存加速。 TeaCache-slow 和 TeaCache-fast 是传统 dynamic caching 的保守 / 激进设置。 FlowCache-slow 和 FlowCache-fast 是本文 chunkwise policy 的保守 / 激进设置。对 MAGI-1，论文报告的阈值包括 MAGI-slow 0.01 与 MAGI-fast 0.015。对 SkyReels-V2，论文报告的阈值包括 SkyReels-V2-slow 0.1 与 SkyReels-V2-fast 0.15。

代码配置中 MAGI-1 single-run fast-like 配置也使用 rel_l1_thresh: 0.015 与 warmup_steps: 5。

4.3 Metrics

质量指标包括 VBench、LPIPS、SSIM、PSNR。论文使用 VBench-long benchmark，并在正文中简称为 VBench。 LPIPS 越低越好。 SSIM 与 PSNR 越高越好。效率指标包括 PFLOPs、Speedup、Latency。 PFLOPs 衡量理论计算量。

Latency 是实际推理耗时，单位为秒。 Speedup 相对 Vanilla 计算。

4.4 Hardware 与实现

所有实验使用 PyTorch 实现。硬件是 NVIDIA A800 80GB GPU。这点很关键，因为 latency 与显存收益和硬件强相关。论文报告的 speedup 不是只看 FLOPs，也包含实际 wall-clock latency。 KV cache compression 的执行时机和 speedup 计算细节在 Appendix D.1 中说明。论文还在 Appendix D.2 分析了 KV compression 的 GPU memory footprint 与额外计算开销。

4.5 Figure / Table Inventory

笔记中保留了主论文所有核心图：Figure 1、Figure 2、Figure 3、Figure 4、Figure 5。

Figure 1 是主定性对比。

Figure 2 是 relative L1 trajectory 证据。

Figure 3 是 FlowCache framework 与 KV cache management。

Figure 4 是 MAGI-1 更多定性结果。

Figure 5 是 SkyReels-V2 更多定性结果。

表格方面，正文 Table 1 的主结果已完整转写。

Appendix Table 3–6 的关键数值也纳入 §5 的 ablation 分析。

5. Experimental Results (实验结果)

5.1 主结果：MAGI-1 与 SkyReels-V2

Figure 1 解读: 左侧 MAGI-1 的 prompt 是 “an airplane landing smoothly on a runway”。TeaCache-fast 在 1.44× speedup 下出现明显质量退化，VBench 为 70.11%。FlowCache-fast 达到 2.38× speedup，VBench 仍为 77.93%。右侧 SkyReels-V2 的 prompt 是 “A car drives along a coastal road at sunset”。TeaCache-fast 为 2.2× / 80.06%，FlowCache-fast 为 6.7× / 83.05%。

正文 Table 1 的主结果如下。

Model	Method	PFLOPs ↓	Speedup ↑	Latency(s) ↓	VBench ↑	LPIPS ↓	SSIM ↑	PSNR ↑
MAGI-1	Vanilla	306	1×	2873	77.06%	-	-	-
MAGI-1	TeaCache-slow	294	1.12×	2579	77.50%	0.6211	0.2801	13.26
MAGI-1	TeaCache-fast	225	1.44×	1998	70.11%	0.8160	0.1138	8.94
MAGI-1	FlowCache-slow	161	1.86×	1546	78.96%	0.3160	0.6497	22.34
MAGI-1	FlowCache-fast	140	2.38×	1209	77.93%	0.4311	0.5140	19.27
SkyReels-V2	Vanilla	113	1×	1540	83.84%	-	-	-
SkyReels-V2	TeaCache-slow	58	1.89×	814	82.67%	0.1472	0.7501	21.96
SkyReels-V2	TeaCache-fast	49	2.2×	686	80.06%	0.3063	0.6121	18.39
SkyReels-V2	FlowCache-slow	36	5.88×	262	83.12%	0.1225	0.7890	23.74
SkyReels-V2	FlowCache-fast	28	6.7×	230	83.05%	0.1467	0.7635	22.95

MAGI-1 上，FlowCache-fast 比 Vanilla latency 从 2873s 降到 1209s。这对应 2.38× speedup。同时 VBench 从 77.06% 升到 77.93%，没有出现 TeaCache-fast 那种崩塌。 FlowCache-slow 的质量更高，VBench 达 78.96%，但 speedup 降为 1.86×。这说明 slow / fast 主要体现阈值带来的质量-速度折中。 SkyReels-V2 上，FlowCache-fast 的优势更大。

Latency 从 1540s 降到 230s。 PFLOPs 从 113 降到 28。 VBench 只从 83.84% 降到 83.05%。相比之下，TeaCache-fast 的 speedup 只有 2.2×，但 VBench 已降到 80.06%。这说明 chunk / block denoising 越异步，chunkwise caching 的优势越明显。

5.2 结果解读：为什么 FlowCache 比 TeaCache 稳

TeaCache 的失败不是因为“缓存一定不好”。它的问题是复用决策粒度错了。在自回归视频中，同一 timestep 的不同 chunk 不应共享一个 accumulated similarity。当某些 chunk 已接近 clean video 时，统一复用会造成过度跳步。当某些 chunk 仍接近 noise 时，统一计算又会浪费可复用机会。FlowCache 通过 per-chunk accumulated L1 解决这个 mismatch。因此它能同时提升 speedup 和质量。MAGI-1 上 TeaCache-fast 的 LPIPS 为 0.8160，SSIM 为 0.1138，PSNR 为 8.94。

FlowCache-fast 的 LPIPS 为 0.4311，SSIM 为 0.5140，PSNR 为 19.27。这说明 FlowCache 不只是 VBench 接近 Vanilla，低层视觉相似性指标也更稳。SkyReels-V2 上，FlowCache-slow 的 LPIPS 为 0.1225，SSIM 为 0.7890，PSNR 为 23.74。这些值都优于 TeaCache-slow。FlowCache-fast 即使速度达到 6.7×，LPIPS 仍为 0.1467，接近 TeaCache-slow 的 0.1472。这说明它把更高加速比和相近视觉保真放在同一设置中实现。

5.3 16-step / 64-step 对比

Appendix Table 3 额外比较了 MAGI-1 的 16-step 与 64-step。

这里的 VBench* 是论文选取八个代表性指标的 weighted sum。

Method	Steps	PFLOPs ↓	Speedup ↑	Latency(s) ↓	VBench* ↑
Vanilla	64	306	1×	2873	69.12%
FlowCache	64	140	2.38×	1209	71.69%
Vanilla	16	77	3.56×	808	70.26%
TeaCache	16	74	4.16×	691	70.60%
FlowCache	16	63	6.84×	420	70.72%

这个表说明 FlowCache 不只适用于标准 64-step。在已经降到 16-step 的更快采样设置下，它仍能把 latency 从 808s 进一步降到 420s。同时 VBench* 为 70.72%，略高于 16-step TeaCache 的 70.60%。这支持“FlowCache 可与少步采样组合”的结论。但也要注意，16-step 本身已经改变采样质量-速度边界。因此 16-step 与 64-step 的结果不应直接混成同一个 Pareto 曲线解释。

5.4 KV Cache Compression Ablation

Appendix Table 4 研究了 KV cache compression granularity。

Reuse Strategy	KV Compression	Query Granularity	Key Granularity	Physics-IQ ↑
-	-	-	-	47.60%
TeaCache	-	-	-	13.69%
ChunkWise	-	-	-	43.10%
ChunkWise	Enabled	Token	Token	39.34%
ChunkWise	Enabled	Token	Frame	38.62%
ChunkWise	Enabled	Token	Chunk	38.99%
ChunkWise	Enabled	Frame	Token	39.53%

最重要的结论有两个。第一，TeaCache 对 Physics-IQ 的破坏非常严重，只有 13.69%。这说明物理一致性任务对错误缓存复用很敏感。第二，ChunkWise 本身已能保住大部分 Physics-IQ，43.10% vs Vanilla 47.60%。加入 KV compression 后分数进一步下降到约 38–40%，但换来固定 cache budget 和显存收益。因此 KV compression 是一个可控的 memory-quality trade-off，而不是免费加速。

Appendix Table 5 研究 $λ$ 。

$λ$	Physics-IQ ↑
0.03	39.38%
0.07	39.53%
0.15	37.11%
0.20	38.42%

$λ = 0.07$ 最优。这与代码默认 mix_lambda: 0.07 一致。较大的 $λ$ 会更偏向 importance，较小的 $λ$ 会更重视 redundancy penalty。视频生成中 redundancy 很强，因此过度强调 importance 不一定好。 Appendix Table 6 研究不同 KV cache budget。

Method	KV Cache Budget (Chunks)	Peak Memory (GB)	Physics-IQ ↑
MAGI-1	8	42.84	47.60%
FlowCache w/o cache reuse	7	34.05	47.55%
FlowCache w/o cache reuse	6	31.25	46.72%
FlowCache w/o cache reuse	5	28.45	47.65%

这组实验排除了 cache reuse，以便单独观察 KV compression。结果显示，budget 从 8 chunks 降到 5 chunks 时，peak memory 从 42.84GB 降到 28.45GB。这约为 33.6% memory reduction。 Physics-IQ 仍在 47% 左右波动。因此，FlowCache 的 KV compression 不只是节省显存，也能在一定范围内维持物理推理质量。

5.5 定性结果

Figure 4 解读: MAGI-1 结果包含 “A corgi is playing drum kit.”、“a teddy bear.”、“A cat wearing sunglasses as a lifeguard at a pool.”、“A fantasy landscape.” 等 prompts。FlowCache-slow 与 FlowCache-fast 在不同速度设置下都比 TeaCache 更少出现噪声伪影和结构破坏；FlowCache-slow 更接近 Vanilla，FlowCache-fast 提供更高加速。

Figure 5 解读: SkyReels-V2 结果包含 “A white sheep grazes peacefully in a meadow.”、“An elephant and a bear interact peacefully in a forest.”、“A fire hydrant.”、“An Iron man is playing the electronic guitar.” 等 prompts。FlowCache-fast 在 6.7× speedup 下仍保持较好的视觉细节和时间一致性，而 TeaCache-fast 在 2.2× speedup 下已出现更明显的质量下降。

定性图和定量表共同说明：FlowCache 的收益不是只来自选择更宽松的指标。它在 VBench、LPIPS、SSIM、PSNR 和可视化结果上都比 TeaCache 展现更稳定的效率-质量折中。尤其是在复杂运动或复杂场景中，chunkwise policy 能避免把接近 clean 的 chunk 错误复用太多步。

5.6 可复现锚点与参考来源

论文主来源已核对 arXiv 与 OpenReview。 arXiv 页面记录标题为 Flow caching for autoregressive video generation，版本为 arXiv:2602.10825v1。 OpenReview PDF 标注为 ICLR 2026 conference paper。代码来源已核对 GitHub 仓库 mikeallen39/FlowCache。当前验证 commit 为 1fdfa57aa82287f34321ba7c06abcadc135928fc，短 SHA 为 1fdfa57a。 GitHub API 返回 default branch 为 main，commit 日期为 2026-04-24，commit message 为 add contact。

关键 result numbers 来自 OpenReview PDF Table 1、Table 3、Table 4、Table 5、Table 6。关键代码路径来自 GitHub tree 与 raw file inspection。资产目录中的五个 SVG 均为最终引用资产： video_quality_comparison.svg relativel1_new.svg method.svg magi.svg skyreel.svg 这些图对应 Figure 1、Figure 2、Figure 3、Figure 4、Figure 5。本笔记没有把临时 reviewer packet、PDF 文本或源码 checkout 写入 Obsidian vault。

5.7 Takeaways

FlowCache 的主要价值在于识别并利用 autoregressive video generation 的 denoising heterogeneity。如果模型是同步 denoising，传统 caching 可能已经足够。如果模型是 chunk / block autoregressive denoising，传统 caching 的全局决策会越来越不匹配。 FlowCache 把 reuse policy 下沉到 chunk level，因此在 MAGI-1 和 SkyReels-V2 上都能取得更高 speedup。 KV cache compression 是第二个必要组件。没有它，长视频生成的 historical KV 会持续增长。

有了它，系统可以在固定 budget 内保留重要且多样的历史上下文。最终结果是：MAGI-1 达到 2.38× speedup 且 VBench 不降反升；SkyReels-V2 达到 6.7× speedup 且 VBench 仅下降 0.79 个百分点。对工程部署而言，最需要校准的是 $ϵ$ 、warmup steps、KV budget、compression granularity 与 $λ$ 。默认配置可以作为起点，但不能保证跨模型、跨分辨率、跨视频长度最优。

Paper Notes

探索

FlowCache: Flow Caching for Autoregressive Video Generation

FlowCache: Flow Caching for Autoregressive Video Generation

1. Motivation (研究动机)

2. Idea (核心思想)

3. Method (方法)

3.1 Flow Matching 与自回归视频建模

3.2 Relative L1 Distance 的 chunkwise 形式

3.3 Chunkwise Adaptive Caching

3.4 Chunkwise Caching 的伪代码

3.5 KV Cache Compression

3.6 KV Compression 的伪代码

3.7 与代码实现的对应关系

3.8 方法边界与失败模式

4. Experimental Setup (实验设置)

4.1 Base Models

4.2 Baselines

4.3 Metrics

4.4 Hardware 与实现

4.5 Figure / Table Inventory

5. Experimental Results (实验结果)

5.1 主结果：MAGI-1 与 SkyReels-V2

5.2 结果解读：为什么 FlowCache 比 TeaCache 稳

5.3 16-step / 64-step 对比

5.4 KV Cache Compression Ablation

5.5 定性结果

5.6 可复现锚点与参考来源

5.7 Takeaways

目录