SwiftVR 2× 视频超分 · RTX 5090 实测

拟合依据（clip_len=4，常驻，稳态取第 2–4 次请求均值）

耗时 = 1.246 + 0.7314×Mpx + 帧数 × Mpx ÷ 54.9 秒（单线程，最大残差 0.3%）； 多线程 = 0.473 + 1.2551×Mpx + 帧数 × Mpx ÷ 48.9 秒（最大残差 10.8%， 线程调度抖动大，只作参考）。
显存 = 12.034 + 2.4418×Mpx GiB（单线程）/ 12.022 + 3.4083×Mpx GiB（多线程）， 两条的最大残差都 < 0.01 GiB —— 显存是严格线性的，截距 12.03 GiB 就是 bf16 权重常驻部分，与分辨率无关。

以上为最小二乘拟合，4 个实测点 3 个参数。实测覆盖 2.36–4.13 Mpx，超出即为外推。

纵轴是稳态 GPU 吞吐（剔除每条视频前两个 chunk 的固定开销）。测于官方多线程驱动、未开 compile。

质量并没有因为 chunk 变小而变差（16:9，取前 24 帧）

clip_len=4 闪烁最低、锐度最高。与 clip20 的差异约 1%（2.43/255），肉眼对比无可辨差别。

BICUBIC 2×

SwiftVR 2×

眼睫毛、发丝、毛衣针织纹理、衬衫格纹差异最明显。未见振铃或结构幻觉。

4× 放大：640×360 → 2560×1440

2× 之外 4× 也能跑。输出 3.69 Mpx，显存峰值 29.6 GiB，稳态 13.3 fps。 更极端的 854×480 → 3392×1920（6.51 Mpx）也跑通了，需把 clip_len 降到 8。

两边的每帧成本都随时长下降，但官方那一列降得更多（371.6 → 215.7 ms，−42%）， 优化后本来就没多少固定开销可摊（110.5 → 88.7 ms，−20%），所以倍数收窄。 15 秒这一档只跑了 2 次请求（5 秒那档是 4 次），置信度低一些； 同档的多线程 clip4+compile 是 29.98 s，与单线程的 31.67 s 落在噪声范围内没分出胜负 —— 单线程稳定领先的结论来自 5 秒那组 4 次请求的数据。

估算器的样本外验证

上面的估算公式是用 121 / 241 帧的实测点拟合的。15 秒这条 357 帧完全在拟合集之外， 正好拿来验证外推：

第 4 行起 compile 列全部 ≤ 不编译列 —— 混合分辨率的生产队列大约两条视频后进入稳态。

✅ 已验证可拿的收益 —— 逐级分解（16:9 768p → 2688×1536，121 帧，常驻稳态）

每一级都是独立实测的常驻稳态数（第 2–4 次请求均值），不是估算叠乘。 贡献最大的是 clip_len —— 一个滑块，2.76×。

这三条已经全部叠加在推荐配置里。与「官方默认 restore_video 多线程 + clip_len=24 + 无 compile」对比（两边都是常驻稳态口径，取第 2–4 次请求均值）：

16:9 与 9:16 的「官方默认」实际跑的是 clip_len=20 —— 默认的 24 在这两档直接 OOM， 所以那两行的对比其实已经对官方一方有利。

🔍 还没吃到的空间

• 每条视频前两个 chunk 的固定开销 —— 目前占 5 秒视频的约 1/3。实测已排除三个嫌疑： 解码只花 0.32 秒（384 fps，不是 IO 瓶颈）、不是显存压力（低显存场景同比例复现）、 也不是 autotune（常驻第 4 次请求照付）。而单线程探针里第二轮就降到 0.618 秒 —— 说明它是驱动结构的产物而非模型固有，还有得挖。乐观估计再省 2–3 秒/请求。
• SageAttention / FlashAttention 后端 —— 官方代码里已经接好了 （_BACKEND_PRIORITY = (flash_attn_3, flash_attn_2, sageattention, sdpa, xformers)）， 但环境里一个都没装，所以 auto 一路回落到 sdpa。本页所有数字都是 sdpa 的。 这是最大的一块未知收益，参照同机 H3 上 sage 2.2 拿到的 −10% 量级。 （正在为 py3.10 + torch 2.10 cu130 编译，尚未跑通。）
• 输出编码 —— x265 编 2688×1536 在 writer 线程里串行，实测约占单请求 3 秒（约 20%）。 换 NVENC 或更快 preset 能回收一部分。
• fp8 权重 —— 12.03 GiB 常驻可减半，腾出的显存能换更大 clip_len 或更高分辨率。 一步式 DiT 对量化更敏感，需要先验证质量。

不建议的方向：clip_len 已经是最小合法值（必须是 4 的倍数）； 多卡切分单条视频会撞上因果流式的跨 chunk 状态，接缝风险高。

• 上游有一个会静默挂死的 bug，必须打补丁。 swiftvr/runner.py 的 record_error() 用阻塞式 q.put() 往 maxsize=3 的有界队列发停止信号，OOM 时队列必满 → put 永不返回 → 主线程卡死在 join()。 表现是 GPU 0% 占着显存挂住，而不是崩溃退出。已改为先 drain 再 put_nowait 并立即打印 traceback。外层还必须有超时看门狗。 （改用单线程驱动可以整个绕开这条路径。）
• 帧数截断到 4k+1：124 帧进去出来 121 帧，最多丢 3 帧尾巴。做服务要么接受要么在外面补齐。
• 显存上限由 clip_len 主控，不只是分辨率。clip_len=4 时 768p 全比例 17.8–22.1 GiB 安全； clip_len=24 时 4.13 Mpx 两档直接 OOM。
• torch 必须 cu128/cu130：官方 README 示例的 cu124 不含 sm_120，5090 跑不起来。 torch 版本号仍用官方要求的 2.10.0。
• 权重未做任何改动：官方 HF checkpoint，bf16，无量化、无 LoRA、无自定义 kernel； 注意力走 sdpa，正是官方 26 fps 宣称所基于的路径。