FlashVSR · 画质优先 vs 解码优化

两个候选，差别只有一个参数

两个候选用的是同一个解码器（作者的 Wan VAE，不是 tiny 的 TCDecoder）， 同样的 kv_ratio 1.5、同样的空间分块。唯一的区别是 VAE 解码的分块步长： 管线默认 stride=30（50% 重叠，每个像素被解码约 4 次）， 优化版改成 stride=56（7% 重叠）。

^† 原版不做空间分块，所以它的显存是 29.15 GiB。 两个候选都比原版快、比原版省 43% 显存，且用的是同一个解码器。
优化版比画质优先再快 1.95×，显存一点没涨，代价见下面 YouHQ40 n=40 的全量画质对比 ——保真度反而略好，CLIP-IQA 掉 0.005。

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

逐条配对相减（同一批片子，片间难度差异会抵消），2000 次 bootstrap，种子固定 20260821。 差值 = 解码优化(7%) − 画质优先(50%)。CI 跨 0 = 测不出差异。

MiniMax-20 · 真实 768p→2× 产出（无真值，n=20）

Downsample-LPIPS 是无真值集合上唯一的保真度代理（把输出缩回原尺寸和输入比， 衡量改写了多少原内容）——解码优化版更好，方向和有真值集合上的 PSNR 一致。

YouHQ40 ×2（有真值，n=40）

UDM10 ×2（有真值，n=10）

成本（同机实测）

差值 = TCDecoder 速度版 − 部署版（画质优先+解码优化），逐条配对 + 2000 次 bootstrap。 这就是「换解码器」的完整代价/收益表——kv、分块、解码步长两边一致，唯一变量是解码器。

所有 CI 均不跨 0。速度：MiniMax-20 上速度版 167.1 s/条 vs 部署版 244.8 s/条（快 1.47×）， 5s 16:9 纯推理 74.8 s vs 147.2 s（快 1.97×）。

生产路径已从「逐帧写无损 PNG」改成「帧经小队列直接进 ffmpeg/NVENC 出 mp4」。 同机同卡三路对照（每行独立进程独占一卡）：

均值：纯推理 0.203 / PNG 0.386 / NVENC 0.205 s·Mpx⁻¹·帧⁻¹。 NVENC 端到端落在纯推理地板上——输出成本基本为零。编码与推理确实重叠： 帧全部入队后等编码器收尾只要 0.09–0.43 s。PNG 模式并行跑时能看到 GPU 利用率 掉到 0%（同步写盘在推理循环里），NVENC 模式没有这个空转。

YouHQ40 024 上的编码器参数扫描（对无损 PNG 打分）

选 420 + constqp 12：比 4:4:4 只差 1.6 dB，但不需要 Rext profile （很多播放器和浏览器不支持 Rext）。024 从 26.72 → 39.08 dB。

之前站上的 24 GB 结论是用分配器上限模拟出来的。现在在一台 8×RTX 4090 24 GB 真机上从零装了一遍环境重跑，可以直接对照。 每行都是独立进程、--no-write、一行一卡。

跨机像素比对 —— 一个我原本以为不用验的假设，结果它不成立

我一直默认「同样的权重、同样的代码，两台机器出的是同一张画面」。 专门去验了：在 4090 上真的写 PNG 跑一条 YouHQ40 clip（1056×1056 × 31 帧）， 和 5090 上同一条逐像素比。结论是：这个假设错了，但错得不要紧——理由在下面。

机内逐位一致、跨机 83% 像素不同——所以这不是随机性， 是一个稳定可复现的机器差异。（这组数字我用自己写的脚本独立复算过一遍：31.044 dB， 与 subagent 的 31.028 dB 一致。）

差在哪？不是接缝，不是错位，是细纹理

降采样后迅速收敛，说明低频结构两边是一致的，分歧只在高频细节。 另外三项排除：时间偏移扫描在 0 处尖峰（没有错帧）、空间平移扫描在 (0,0) 处尖峰（没有错位）、 这个尺寸下驱动只用 1×1 个窗口（根本没有接缝可言），差异是全画面弥散的。 锐度也没塌（Laplacian 方差 282.9 vs 293.9）。

那到底哪台"对"？—— 都对

两台机器是两个同样合法的纹理实现，没有谁坏掉。 换成 tiny（完全不同的解码器）重跑，分歧的量级和性质几乎不变 （32.23 dB，1/8 降采样 42.1 dB）——说明源头在共享的 DiT / 稀疏注意力路径， 不在解码器。最可能的机制：BSA 在 4090 上编成 sm_80 cubin 走 is_sm8x 的 48 KB smem 分块，5090 走 sm_120 分块， 不同的分块几何 = 不同的 bf16 累加顺序，差异从注意力开始播种再经解码器放大。 torch 2.6/2.8 与 cuDNN 9.1/9.10 的差异叠在上面。 这三者谁占主导没有隔离出来——那需要在同一台机器上换 kernel 重编，没做。

三行的显存峰值和 5090 逐位一致——同一个分配器、同一个模型，本来就该如此， 这也是「移植没走样」最强的证据。速度慢 1.3–1.4×，方向合理。

15 秒长片在 4090 上的容量（360 帧）

✅ 24 GB 部署预设 —— 已在真 4090 上验证，部署目录就位

默认阈值（tile-px 3.0e6 / px-budget 140e6）是按 32 GB 标定的， 4090 上 21:9 峰值 19.52 GiB、余量仅 4.5 GiB。部署预设改为 --tile-px 2.5e6 --px-budget 110e6（其余与部署配置相同）， 在真 4090 上五行验证全过：

全画幅族最大峰值 16.30 GiB，余量 ≥7.69 GiB（此前是 4.5）。 账目干净：21:9 峰值 −4.19 GiB，代价 +5.8% 耗时；16:9 分块不变，基本白送。 有个反直觉的点如实写明：峰值上界由 16:9 决定而不是 21:9—— 21:9 被切成更小的 1408×1536 块（2.16 Mpx），16:9 的 1536×1536 块（2.36 Mpx） 低于 2.5 Mpx 阈值不再细分，所以它才是最大的块。 竖版 1536×2688 沿长轴对称分块，峰值与横版逐位相同。
部署目录：4090:~/vsr_deploy/fv_deploy_4090/run_batch.sh， flags 写死、头部注释含标定依据与验证数据，已用真实 job 冒烟（写 PNG， 首帧 md5 与此前跨机校验产物逐位一致——4090 机内确定性再次确认）。

✅ TCDecoder 速度版的 24 GB 预设 —— 也验证过了，但有一个要知道的取舍

tiny 默认阈值在 4090 上 21:9 峰值 23.04 GiB，余量不到 1 GiB，生产不可用。 预设改为 --variant tiny --tile-px 1.8e6（vae-stride 对 TCDecoder 是死参数，不加）， 真 4090 六行验证全过：

六种画幅×时长峰值完全一致 16.44 GiB（同一个块内存形态封顶），余量 7.55 GiB。 速度上方向分裂：21:9 细分块更快（374.8 vs 386.6 s），16:9 慢 7.2% （282.8 vs 263.9 s）——"细分块对 tiny 双赢"只在 21:9 成立，16:9 是拿 7.2% 速度换 3.7 GiB 余量。 部署目录：4090:~/vsr_deploy/fv_deploy_4090_tiny/run_batch.sh。

kernel：Block-Sparse-Attention 能不能上 Ada

能，而且一行源码都没改。用 BLOCK_SPARSE_ATTN_CUDA_ARCHS=80 编译， cuobjdump --list-elf 确认产物只含 sm_80 cubin（没有 sm_89、也没有 PTX）， 在 4090 上照样加载执行——靠的是 CUDA 次版本二进制兼容。
而且是数值验证过的，不是「不报错就算过」：对稠密掩码与 scaled_dot_product_attention 比对，bf16 下最大绝对误差 1.16e-03； 换成真正稀疏的下三角块掩码会给出不同且非退化的结果（证明稀疏路径真的在走）。 编译 ~7 分钟（ninja + MAX_JOBS=32，25 个目标文件），无需任何补丁。

这组数字的三点保留

• torch 版本不同：4090 是 2.6.0+cu124（驱动 535 上不宜用 cu128，且 cu124 正是 FlashVSR 官方 requirements 的 pin），5090 是 2.8.0+cu128（sm_120 用不了 cu124）。 所以比值里混了一个未量化的 torch 版本项。显存峰值完全一致说明这一项不大， 但不是零。
• 并发争用已排查：主表是 6 路并行跑的。单卡独占重跑同样三行得到 95.4 / 406.1 / 197.5 s，争用只贵了 2–4%，显存峰值两种模式完全相同。 独占口径下的比值是 1.28× / 1.41× / 1.34×。
• 一处标签错误：我原本把 --tile-px 1.8e6 那行写成「3 块」， 实际驱动算出来是 4 块（k=3 时每块 2.16 Mpx 超过 1.8 阈值）。 这是设备无关的纯算术，5090 上分法相同——是标签写错了，不是 4090 的差异。

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

空间分块有没有影响？—— 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%—— 这正是「先分块计时再决定优化目标」的价值。