企业官网建设流程全解析

Jasna 官方基准核查：快上一代 3~5 倍的提速，每秒从哪来

【免费下载链接】jasnaVideo restoration tool项目地址: https://gitcode.com/GitHub_Trending/ja/jasna

同一段 1080p 测试视频，Lada 0.11.0 用时 122.4 秒，Jasna v0.9.1 只要 33.6 秒，差 3.6 倍；但 Jasna 的显存中位数是 4.9 GB，Lada 只有 2.0 GB。本文用 Jasna 仓库自带的基准报告、原始 CSV 和流水线源码，核查官方"快上一代 3~5 倍"的声明：口径是否可复现，每份提速从哪里来。

一、先立口径：为什么这组数字可以信

核查第一步不是看数字，而是看测量协议。官方报告 benchmarks/2026-07-26_release_matrix.md 把环境、样本、参数、统计方式全部写死：

• 硬件：RTX 5090 32 GB、驱动 595.84、i9-13900K，在带图形界面的桌面（live desktop）上实测，报告明确"个位数差异视为噪声，除非配对重跑能复现"。
• 样本：同一源视频 SONE-610，6056 帧、202.07 秒，编码成 720p/1080p/2160p × H.264 8-bit/HEVC 10-bit/AV1 10-bit 共六种规格，另有一段 900 帧的 8K VR。
• 链路：--max-clip-size 180 --temporal-overlap 15 --secondary-restoration none，HEVC 输出，跑前丢弃一轮 warmup。
• 统计：Lada 与 release 版单次运行，v0.9.0 取三轮交错运行的中位数；RAM/VRAM 每 0.5 秒采样，报中位数和峰值。
• 对照端：Lada 是 Flatpak 0.11.0、Accuratev2检测器、CUDA FP16、--max-clip-length 180、hevc-nvidia-gpu-hq输出——clip 长度和编码器都是显式对齐的，不是默认值碰默认值。

"3~5 倍"这个区间怎么来的？release matrix 的 Lada 对照表里，Jasna v0.9.0 相对提速从 720p 的 3.1x 到 2160p AV1 的 5.0x；README 主表换用 v0.9.1 数字后是 3.4x / 3.6x / 4.7x。两套数据并起来，就是 3~5 倍的来源，区间下界和上界都有出处。

还有一处必须提前说明：首任务编译不计入基准。NVIDIA 上首次运行会用 TensorRT（英伟达的推理加速工具，把模型针对你的具体显卡"编译"成一组优化引擎）为检测器和修复模型生成引擎，耗时 15~60 分钟，结果缓存在model_weights目录供后续复用。这份"冷启动"被隔离在基准之外，复测吃的是缓存。

复现脚本就放在仓库里：scripts/benchmark_releases.py。

二、📊 沿着流水线找机制：解码、检测、修复、编码各快了多少

流水线实现在 jasna/pipeline_threads.py：解码+检测、主修复、次级修复、编码是各跑各线程、用队列解耦的阶段。逐段看瓶颈在哪、改了什么、值多少。

解码：硬件解码器对软件解码的差距随分辨率扩大。NVDEC 是 NVIDIA 显卡内置的视频硬件解码单元，帧直接在 GPU 上解出，不用先进 CPU 内存。Jasna 在 NVIDIA 上默认走 python_vali 驱动的 NVDEC；jasna/media/video_decoder.py 里还专门处理了一个坑：PyAV 对 AV1 默认选 libdav1d 解码器，它不带硬件加速，会悄悄退回软件解码。全帧扫描基准（扫描即只检测不修复，是解码瓶颈的典型负载）给出的差距：

| 输入 | NVDEC (vali) fps | pyav-sw 软件解码 fps | 差距 | ---: | ---: | ---: | | 720p H.264 8-bit | 860.6 | 717.4 | 1.2x | | 1080p HEVC 10-bit | 833.6 | 269.6 | 3.1x | | 2160p HEVC 10-bit | 532.6 | 110.3 | 4.8x | | 2160p AV1 10-bit | 486.8 | 96.9 | 5.0x | | 8K VR HEVC 60 fps | 168.7 | — | — |

（数据来自 benchmarks/2026-07-21_v0.8.2_scan_decode_backends.md）分辨率越高、位深越深，软件解码差距越大；4K/8K 长视频还能拆到 5090 的两路 NVDEC 并行，2160p HEVC 从 532.6 fps 提到 711.2 fps。

解码之后、修复之前的每一步都不是现成 torch 算子，而是手写 CUDA kernel：jasna/media/ 下的yuv_to_rgb.py、resize_normalize.py、denoise.py、rgb_to_yuv.py及配套.cu/.fatbin文件覆盖了色彩空间转换、缩放归一化、降噪、编码前转换。release matrix 里的 8 个性能 commit 序列（基线9b6a089到7d9cc8c）合计让 1080p/2160p/8K VR 各降约 11%，其中"检测器预处理内核化"贡献最清晰（2160p HEVC 从 78.1s 一段落到 77.4s 附近的主要台阶）；单独的.cubeLUT 色彩映射 kernel 在配对测试里有 9.2% 的端到端收益。

检测与追踪：工作量被先砍掉一大截。每批帧先过detections_fn（jasna/pipeline_processing.py 的process_frame_batch），默认检测器 rfdetr-v6 在 NVIDIA 上编译为 TensorRT FP16 引擎、batch 4 推理（jasna/mosaic/detection_registry.py 里default_detection_batch_size对 NVIDIA 返回 4）。检测框由 jasna/tracking/clip_tracker.py 按 IoU 阈值 0.3 串成 track，每个 track 只把检测框附近的 crop 收进CropBuffer；场景切换处由 scene detector 强制断 clip，两个镜头不会混进同一次修复。真正送进修复模型的只是这些 crop，统一 resize 到 256×256（jasna/restorer/basicvsrpp_sub_engines.py 的INPUT_SIZE = 256），修完按 blend mask 回填，其余像素不动。修复成本与马赛克面积成正比，而不是与全画面面积成正比——1080p 画面里一小块遮挡，过模型的像素可能只有全帧的几十分之一。据此推测，马赛克越多、越大的素材，这层收益会缩小，基准里没有给出该比例。

修复：子引擎拆分 + CUDA Graphs + 定长批。BasicVSR++ 被拆成 preprocess、四个方向的 loop_body、upsample 共六份独立 TensorRT 引擎。CUDA Graphs 是把一串 GPU 指令打包成一张"图"一次提交、省掉每条指令的来回开销；loop_body 引擎 shape 固定，可以安全捕获。实测：单次前向 T=30 从 46.2 ms 降到 36.3 ms（−21%），T=180 从 269.6 ms 降到 206.9 ms（−23%），bit-exact（benchmarks/2026-07-27_quantization_basicvsrpp.md）。端到端收益是 −2%~−10%，低分辨率更明显（benchmarks/2026-07-27_v0.9.1_e2e_cudagraphs.md）。

更关键的是定长批：TensorRT 按 profile 最大 batch 预留 scratch 内存，原来 preprocess/upsample 引擎按 clip 长度建，180 帧 clip 就给逐帧工作预留 180 帧的 scratch。改成固定BASICVSRPP_PREPROCESS_BATCH = 60、BASICVSRPP_UPSAMPLE_BATCH = 30（jasna/engine_paths.py）后，常驻引擎内存从 4560 MiB 降到 916 MiB，upsample 引擎文件从 452 MB 缩到 78 MB，端到端显存中位数降 31%~45%（720p 7890→4312 MiB），时间不变（benchmarks/2026-07-28_engine_batch_vram.md）。最能说明引擎化分量的一个数：同一段 1080p、clip 180，编译版 33.2 s / 4977 MiB，--no-compile-basicvsrpp版 106.8 s / 4605 MiB——3.2 倍，恰好和"快上一代"的量级同档。

编码：NVENC 硬编，音频直接复制（放不进去才重编码）。编码端没有单独的端到端对照数字，encode kernel 计入上面 commit 序列的累计收益里。

三、🔍 反直觉清单：四处数据不合常理

1. clip 越小越慢，不是越快。clip-size 扫描（1080p，overlap 8）：30 帧 51.4 s、60 帧 40.2 s、90 帧 34.4 s、180 帧 35.0 s、360 帧 32.0 s、720 帧 33.0 s，显存中位数 3411→8159 MiB（benchmarks/2026-07-28_clip_size_sweep.csv）。机制：相邻 clip 的重叠帧每段都要重算，clip 越小重复工作越多；超过约 180 帧后时间不再下降，只有显存继续涨。tuning 文档的原话是 "Small clips are slower, not faster"，即"小 clip 更慢而不是更快"，所以建议"能塞下多大就开多大"。

2. 量化后更慢，不是更快。单次 loop_body 调用：fp16 0.332 ms，int8 0.648 ms，fp8 0.529 ms；整网量化（int8 全部引擎）T=30 全前向 71.5 ms，比 fp16 的 46.2 ms 慢约 1.6 倍。原因是整个前向约 90% 时间花在顺序的 loop_body 调用上，地板约 0.30 ms，量化的 Q/DQ 层反而变成额外开销。FP8 upsample 子引擎曾随 v0.9.1 发布，实测带来 +1.8 GB 显存回归，最终被移除。量化不是银弹，这条被实测数据固定下来了。

3. 首任务 15~60 分钟的编译不在基准里。首次运行要为你的具体显卡生成检测器和修复模型引擎，这份时间被缓存在model_weights，后续任务复用。基准成绩对应的是"有缓存"状态；从零安装的用户第一次跑，体感会明显慢于任何一张表格。

4. Windows 比 Linux 慢 50% 以上。同一版本 v0.9.0，1080p 在 Windows 上 61.3 s，Linux 38.6 s；2160p 88.3 s 对 75.4 s（benchmarks/windows-v0.9.0.csv）。官方表格里的绝对时间只能在 Linux + RTX 5090 上复现。

另有一条对照数据值得记：Lada 全程显存中位数只有 1.9~2.6 GB，Jasna 是 4.2~4.9 GB——更快的那一方显存吃得更凶，这在下一节展开。

四、⚖️ 边界与代价：换一台机器，数字还成立吗

显存是这次提速的价格。README 的 GPU 内存表（typical/peak，GB）：1080p 下 Lada 2.0/3.3，Jasna v0.9.1 4.8/5.6；2160p 下 Lada 2.6/4.1，Jasna 7.2/10.9。Jasna 自己的演进史更能说明问题：v0.4.1 在 1080p 上要 18.9/21.4 GB，v0.5.0 降到 9.5/10.2，v0.9.1 的定长批引擎才压到 4.8/5.6——同一工具不同版本差近 4 倍。这组数据暗示"全 GPU 化"不是免费的，是持续显存工程收敛的结果。4K 素材同 clip 下还要再多约 1.5 倍显存（docs/en/tuning.md）。

长视频的提速比甚至更高。官方 3:22 短片之外，全长对照（benchmarks/2026-07-26_legacy_videos.md）：4K、2 小时 25 分的 ABF-017 从 Lada 0.10.1 的 02:56:26 到 Jasna 0.9.0 的 42:17（4.2x）；1080p、3 小时 10 分的 HUBLK-063 从 01:34:51 到 18:01（5.3x）。长片比短片更快，合理推断是启动、预热等固定开销被摊薄了。

显存不足有兜底。jasna/vram_offloader.py 会把等待处理的帧自动调度到系统内存再取回（保留 750 MiB 安全余量），不需要用户手动设置；GUI 的 clip size 滑杆上限也随之放开到 720。文档给出的降显存顺序：降--max-clip-size、关次级修复、关掉占显存的其他程序；4~6 GB 的卡跑 1080p 建议从 clip 30 起步。

换机器的推法：官方数字绑死在 Linux + RTX 5090 + 有编译缓存三个前提上。Windows 用户把绝对时间乘约 1.5（1080p 实测比例）；更老显卡没有 NVDEC 优势会进一步缩小；但"检测前置 + 引擎化"带来的结构性提速方向应该不变——仓库里没有跨显卡的完整对照数据，这是推测，不是实测。

五、裁定与自检方法

结论："快上一代 3~5 倍"在本基准口径下成立，原始数据里提速区间 3.1x~5.0x，口径可复现。

1. 复现：跑 scripts/benchmark_releases.py，双端保持--max-clip-size 180 --temporal-overlap 15一致。
2. 显存不够先降--max-clip-size（180→90/60），4~6 GB 卡从 30 起步，overlap 取 8~20。
3. 警惕边界：官方时间是 Linux + RTX 5090 + 有编译缓存；Windows 慢约 1.5 倍，2160p 峰值 10.9 GB，首任务编译 15~60 分钟不计入。

证据清单：benchmarks/2026-07-26_release_matrix.md、benchmarks/2026-07-28_engine_batch_vram.md、jasna/pipeline_processing.py

【免费下载链接】jasnaVideo restoration tool项目地址: https://gitcode.com/GitHub_Trending/ja/jasna