FlashVSR v1.1 — Real-Time Diffusion-Based Streaming Video Super-Resolution (HF model release)

TL;DR

FlashVSR v1.1 is a Hugging Face model-weights release (Nov 2025) updating the original Oct 2025 FlashVSR drop, the first diffusion-based one-step streaming video super-resolution framework (arXiv 2510.12747, Zhuang et al., Tsinghua + Shanghai AI Lab). The page itself is a release/usage note, not a tech report: v1.1 ships the same architectural recipe (three-stage distillation pipeline + Locality-Constrained Sparse Attention + Tiny Conditional Decoder) with weights advertised as “enhanced stability + fidelity” over v1. The October v1 hit ~17 FPS at 768×1408 on a single A100 with ~12× speedup over prior one-step diffusion VSR baselines. v1.1 is a drop-in weights swap — the page exposes infer_flashvsr_v1.1_* inference scripts mirroring the v1 entry points.

Key claims

v1.1 release date is November 2025, advertised as “enhanced stability + fidelity” over the original October 2025 v1 release [News §Nov 2025].
The release ships four files: LQ_proj_in.ckpt, TCDecoder.ckpt, Wan2.1_VAE.pth, and a streaming-DMD diffusion model in safetensors [Step 4].
v1.1 is a drop-in weights replacement — inference scripts infer_flashvsr_v1.1_full.py, _tiny.py, and _tiny_long_video.py mirror the v1 script set, and the project is “primarily designed and optimized for 4× video super-resolution” [Step 5].
The underlying FlashVSR architecture combines three components: a train-friendly three-stage distillation pipeline enabling streaming SR, Locality-Constrained Sparse Attention (LCSA) that cuts redundant computation and bridges the train–test resolution gap, and a Tiny Conditional Decoder that accelerates reconstruction [Abstract].
VSR-120K, the supporting training corpus (120k videos + 180k images, joint image+video training), is announced but not yet released [TODO].
v1 runs at ~17 FPS for 768×1408 video on a single A100, with up to ~12× speedup over prior one-step diffusion VSR models [Abstract].
The Block-Sparse Attention backend is required for the LCSA kernel and is validated on A100/A800 (ideal acceleration), runs correctly on H200 (limited acceleration), and is untested on RTX 40/50 and H800 [Step 3 ⚠️].
Early third-party ComfyUI ports of FlashVSR fall back to dense attention because they omit LCSA, producing noticeable quality degradation at higher resolutions; the authors are working on a non-Block-Sparse-Attention fallback with the same output quality but slower runtime [📢 Quality Note].
An Oct 21, 2025 bug-fix in v1’s local_attention_mask update logic was required to prevent artifacts when switching aspect ratios during continuous inference [News].

Method

The model card itself is short and does not re-describe the method beyond a three-bullet sketch of the v1 architecture: three-stage distillation for streaming VSR training, Locality-Constrained Sparse Attention (LCSA) to cut compute and reduce the train–test resolution gap, and a Tiny Conditional Decoder for fast reconstruction. The card defers all method detail to the arXiv preprint (2510.12747) and to the GitHub repo at OpenImagingLab/FlashVSR. What v1.1 changes vs v1 is not described in the model card — only the headline claim “enhanced stability + fidelity” appears. The release exposes a different safetensors checkpoint for the streaming DMD model and otherwise reuses the v1 supporting files (LQ_proj_in.ckpt, TCDecoder.ckpt, Wan2.1_VAE.pth), and the scripts are renamed mirrors of the v1 entry points. The architecture is built on top of the Wan2.1 VAE, consistent with the broader Wan video-foundation ecosystem.

The quality note clarifies that LCSA is doing real work in the pipeline: removing it (as some early ComfyUI ports did) drops the model back to dense attention and visibly degrades output, especially at higher resolutions. This is a useful negative result for anyone integrating FlashVSR into a serving stack — the attention kernel is not optional.

Results

No numerical results are reported on the v1.1 model card itself. The v1 headline numbers (~17 FPS at 768×1408 on a single A100, ~12× speedup over prior one-step diffusion VSR) carry from the arXiv preprint via the abstract that the card reproduces. Quality-vs-v1 deltas for v1.1 are advertised qualitatively (“enhanced stability + fidelity”) with no MOS, NIQE, MUSIQ, or PSNR table on the page. The card includes a visual comparison strip between LR input, third-party (no-LCSA) output, and the official FlashVSR pipeline, illustrating texture aliasing failures of the LCSA-less variant, but no quantitative delta is given.

Why it’s interesting

Direct sibling to DUO-VSR: Dual-Stream Distillation for One-Step Video Super-Resolution on the same diffusion-VSR-distillation axis, and both end up in Diffusion Distillation territory but pull different levers. DUO-VSR’s case study is the distillation procedure itself: CFG-distill → progressive halving → DMD + RFS-GAN with the score models reused as discriminator backbones → DPO refinement, all aimed at fixing the “frozen real-score is a degraded supervisor” failure mode. FlashVSR’s case study is the systems envelope: a streaming three-stage distillation pipeline plus LCSA (a kernel-level architectural lever) plus a tiny decoder, designed around the budget for real-time inference on a single A100. The two are composable in principle — RFS-GAN-style supervision could replace or augment FlashVSR’s third stage, and LCSA could drop into DUO-VSR’s one-step student — and they together pin down two orthogonal axes of “how to make diffusion VSR fast and good.”

FlashVSR is also the explicit baseline that SparkVSR: Interactive Video Super-Resolution via Sparse Keyframe Propagation argues against (SparkVSR keeps a one-step DiT but adds sparse HR-keyframe conditioning instead of investing in distillation). The wiki now has all three datapoints — keyframe-conditioning (SparkVSR), distillation-procedure (DUO-VSR), and systems+kernel co-design (FlashVSR) — for the “fast, high-quality video super-resolution from a video DiT” problem.

The non-method content here is also a useful lesson for the team: the quality note explicitly documents what happens when a downstream ComfyUI port silently swaps out a custom attention kernel (LCSA → dense) — the model still runs but the output is visibly worse. This is exactly the kind of integration footgun that’s easy to miss in a pip install workflow.