VSR Hover Comparison

FlashVSR 对输入的形状要求很硬，而官方脚本处理不合法输入的方式是悄悄改掉你的片子， 不报错。下面每一条都会在评测里变成一个静默的错误结果，所以驱动 flashvsr_runner.py 全部改成显式处理。

空间分块的重叠量不是随便定的：必须大于模型的局部注意力跨度。 local_range=11 个 latent 单位 = 88 个输出像素，所以重叠取 256 px 有足够余量。 接缝做了专项检测——不是看全局指标（1 像素的缝会被均值淹没），而是量 分块版相对整幅版多出来的水平梯度，在两个拼接位置只有 0.9σ 和 1.1σ， 全帧最大偏差落在 x=690（画面自身的边缘）而不是拼接处。没有缝。

21:9 只有靠空间分块才成立：3584×1536 整幅送进去会死在一个 2.15 GiB 的定长分配上， 这个分配跟任何旋钮都无关，只能靠把画面切小来绕开。

感知分是哪个旋钮丢的？——2×2 拆解

调优版同时动了两个旋钮，两两对比说不清是谁的责任，所以把四格全跑了。 UDM10 / YouHQ40 每帧都在 3 Mpx 分块阈值以下，四格都没有分块，不是混淆项。

• float32 全片画布：把整条片子的融合缓冲开成 float32，13.7 GB 的张量被反复拷贝 15 次， 一个 GPU 任务变成 memcpy 瓶颈，跑 28 分钟还没完。改成预分配 uint8 后同一条 625 s 跑完， 输出逐位相同（对齐 PSNR 仍是 21.447）。
• 多块分支尾部黑帧：缓冲按 m 帧分配，但管线只填 m−4 帧，剩下的尾巴保持零值， 写出来是黑帧。改成按实际产出帧数截断。
• 窗口向下取整漏片尾：141 帧只写出 135 帧。靠打印 wins / produced / missing 逐帧覆盖表定位。

还有一条结论性错误：我曾经报告「FlashVSR 在 5090 上做不了 4 Mpx 输出」。 挡住它的其实是我自己按 kv 3.0 标定、后来不再适用的 px-budget 门限，不是真 OOM。 改掉门限后连原版配置都能跑 2688×1536×141。

显存这半边是实测的：用 set_per_process_memory_fraction 把分配器硬卡在 23.0 GiB（24 GB 减掉约 1 GB 的 CUDA context 等分配器外开销），torch 会在这个上限 精确抛 OOM，和小卡一样。先跑阳性对照——一个已知需 30.5 GiB 的配置在 cap 下确实 OOM， 确认 cap 真的在起作用，后面的行才有意义。

24 GB 卡上该用 3 块：和 2 块一样快（558.0 vs 558.6 s），峰值却低 5.75 GiB。 原因是 2 块贴着上限时分配器一直在刷缓存重试，给它留余量反而不慢。
kernel 侧：Block-Sparse-Attention 的 setup.py 默认 arch 里没有 89， 但源码有一段专门为 sm_86/sm_89 写的分支（is_sm8x，hdim128 非因果走 128×32、 只要 48 KB shared memory），正是为了迁就 Ada 更小的 smem；README 也把 Ada 列进 bf16 支持。 用 BLOCK_SPARSE_ATTN_CUDA_ARCHS=80 编即可（sm_80 cubin 按 CUDA 次版本二进制兼容 规则能在 sm_89 上加载）。
没有实机验证过：这里只模拟了显存预算，没有模拟 sm_89 kernel，也没有模拟 Ada 更低的 带宽——真 4090 上每一行的耗时都会更长。