VSR Hover Comparison

调优版做到了什么

2.5× 速度，−31% 显存。15s 容量：16:9 2688×1536 × 360 帧 409.9 s / 20.13 GiB； 21:9 3584×1536 × 360 帧 558.6 s / 22.19 GiB。21:9 只有靠空间分块才成立—— 整幅送进去会死在一个 2.15 GiB 的定长分配上。

24 GB（4090）实测：把 CUDA 分配器硬卡在 23.0 GiB（先用一个已知需 30.5 GiB 的配置做阳性对照， 确认 cap 真的会 OOM），上面四种场景全部通过；15s 21:9 改 3 块后峰值降到 16.44 GiB 而耗时不变（558.0 s）， 是 24 GB 卡上更该用的档位。注意：这只模拟了显存预算，没有模拟 sm_89 kernel 和 Ada 更低的带宽， 真 4090 上耗时会更长。

单击设为 A（左），再次单击同一个设为 B（右）。 也可以直接点另一个方法替换 B。

两个配置跑的是同一批片子，所以看的是逐条配对差值，不是各自的均值—— 片子之间的难度差异会在配对里抵消掉。CI 是 2000 次 bootstrap 重采样，种子固定。 差值 = 调优版 − 原版；CI 不跨 0 才算真差异。

「原版」= 作者发布的模型配置（full 管线 / Wan VAE 解码器，kv_ratio 3.0）， 跑在同一套内存脚手架里（输入 pad、尾部补 4 帧、scale=2、空间分块）—— 不共用这套脚手架，两次跑的就不是同一批像素，也就没法比。 所以表里原版在 MiniMax 上的峰值是 19.67 GiB 而不是 29.15 GiB： 29.15 是原版配置不分块时的数字，那才是它自己跑 4 Mpx 的代价。

full + kv1.5 + 空间分块，也就是作者的解码器 + 全部内存优化。 这些行是纯容量探针：关掉 PNG 落盘（--no-write）跑的， 因为 wall_s / 峰值都是围着模型量的，而写 360 张 4 Mpx 的 PNG 比被测的推理本身还久， 对结论没有贡献。所以这里的耗时不含落盘，同一条 5s 16:9 带落盘是 381.8 s、不带是 285.1 s。

带 cap 和不带 cap 的峰值完全一致、耗时相差 1.5–3.5%，说明这个配置没有贴着 24 GB 的上限—— 不是勉强挤进去的。15s 21:9 还剩 3.5 GiB 余量，换 3 块能再降到 14.15 GiB， 代价是慢 8%。
也就是说：要作者的画质、又要 15s 21:9、又要 24 GB，这三件事不冲突， 需要放弃的只是那 2.4× 的速度。

这里有两种完全不同的分块，之前混着说是我的表述问题：

空间分块有没有影响？—— MiniMax-20 全量 A/B

专门跑了一组 --tile-px 1e12（永不分块）的对照，其余配置逐字相同。 分块只在每帧 > 3.0 Mpx 时触发，所以 20 条片子天然分成两组：

① 阴性对照（4 条 1:1，2.36 Mpx，两边都没分块）： 逐字节 md5 比对 4/4 完全相同。这一步是必须的——如果这里就不一样， 说明管线本身不确定，下面所有数字都是噪声。

切块只切长边、按 128 对齐、重叠 256 输出像素，融合用线性 ramp 互补权重。 【更正】我之前写过「重叠远大于模型 88 px 的感受野」——那个数字算错了。 正确推算：输出像素 →(VAE ÷8)→ latent →(DiT patch_size=[1,2,2] ÷2)→ token， 1 token = 16 px，1 注意力块 = 8×8 token = 128 px，local_range=11 块 → ±640 px。重叠其实小于感受野，接缝附近确实看到截断的上下文—— 但上面的全量 A/B 和接缝检测都测不出代价，原因见 学习页 5.3 节。
而且对 tiny 来说分块是双赢：2 块比整幅又快又省 34% 显存 （155.5 s / 20.13 GiB vs 163.4 s / 30.49 GiB）——注意力矩阵随边长平方增长， 切小之后省下的算力超过了跑两趟的开销。

在动任何优化之前先分块计时（FVPROF=1，每个计时器都 cuda.synchronize()，量的是真实 GPU 时间不是异步下发延迟）。 2688×1536 × 141 帧，不含落盘：

DiT 两边都是 ~63 s，两个配置的全部差距都在解码器上。 所以画质优先配置该优化的地方只有一个：那 220 秒。

FlashVSR 的 pipeline 解码时用 tile_size=(60,104), tile_stride=(30,52)， 也就是 50% 重叠——每个 latent 像素大约被解码 4 次。 重叠是用来盖住 VAE 分块接缝的，问题是需要这么多吗。

解码 221.7 s → 81.3 s，快 2.7×，显存一点没涨。 分块开大（96/128/160）反而更慢且吃显存——省时间的是减少重叠，不是加大分块。

但省下来的是不是画质？—— YouHQ40 全量 n=40 验过

保真度略微变好（重叠融合本身就是一次轻微模糊），CLIP-IQA 掉 0.005—— 对比一下换解码器那次是掉 0.061，这里小一个数量级。 接缝专项检测：4 条片子 × 横竖两个方向 × 2 个接缝位置，相对 50% 重叠版的额外梯度 最大 3.7σ，全部低于 4σ 判定线；最大偏差点落在画面内容边缘而不是接缝上。无可见接缝。

编译确实生效了（日志里有 [compile] decoder compiled / [compile] dit compiled，不是静默失败），但收益在测量噪声以内（≤3%）。原因：

• DiT 编不动。它调的是 Block-Sparse-Attention 的自定义 CUDA 算子， dynamo 追不进去，只能 graph-break，编译到的只是算子周围的边角料。
• 解码器是纯卷积、且是 memory-bound。compile 的主要收益来自算子融合， 而这里的瓶颈是显存带宽不是 kernel 启动开销，融合省不出东西。
• 形状一直在变。时域窗口 + 空间分块让每次调用的形状都不同， dynamic=True 之下拿不到静态 shape 特化的好处。

结论：这个模型上 torch.compile 不值得开。同样是想省时间， 改一个 tile_stride 参数拿到了 2.7×，而 compile 拿到 0%—— 这正是「先分块计时再决定优化目标」的价值。

这张表是背景参照，用来给 FlashVSR 的位置定标；本轮的重点是上面那组对比。