RelayVSR X2: A 2x Video Upscaler Trained on H3 Clips

An H3 clip at 768x1344 doubles cleanly to 1536x2688, which is a normal finishing resolution. RelayVSR only did 4x, so the same clip went to 3072x5376 and paid four times the pixel work for an output most shots do not need. X2 computes at 2x instead of computing at 4x and resizing down.

Flicker first, sharpness second

Super-resolution models tend to amplify the mild temporal flicker that generated video already carries, so the upscaled clip can look worse in motion than the source even when single frames look sharper. RelayVSR's design targets that: a large generative model writes reference latents for sparse keyframes only, and a small VSR network carries those references across every frame, with a bounded lookahead and a frame-ring KV cache in the LightX2V implementation.

The released benchmark input is itself H3 output, a 1024x768 drone rooftop clip at 24 fps with slight pre-existing flicker, so the comparison grid shows the case the model was trained around rather than clean camera footage.

Two checkpoints, one scale

The X2 release ships as two files that have to be downloaded into the same directory:

• wan_x2.safetensors (10.1 GB), the Wan-based checkpoint that generates the sparse keyframe references.
• flash_x2.safetensors (127 MB), the compact conditional decoder that super-resolves the remaining frames.

The LightX2V runner validates scale and architecture, and rejects mixed 2x and 4x weights rather than loading a mismatched pair. Output size is not a user setting: it follows the input dimensions and sr_ratio, which must be 2 for the X2 model. The older 4x checkpoint still accepts sr_ratio=2, but it computes at 4x internally and downsizes afterwards, which is the cost this release exists to avoid.

Same frame at 960x720 display size: H3 source upscaled 2x with bicubic (top left), RelayVSR X2 (top right), FlashVSR+ Turbo (bottom left) and Open-H3-Regenerate-2K (bottom right). Frames from the published benchmark clips.

Measured on one H100

The card reports one measured run per model after a same-resolution warmup, sequentially on a single H100 80GB with PyTorch 2.11.0 and CUDA 13.0, on 243 frames of 1024x768 at 24 fps:

• RelayVSR X2 (LightX2V): 5.348 s, 45.44 FPS, 2048x1536 output
• SwiftVR (LightX2V): 6.399 s, 37.98 FPS
• SwiftVR: 7.252 s, 33.51 FPS
• RelayVSR 4x (LightX2V): 19.304 s, 12.59 FPS, 4096x3072 output
• RelayVSR 4x: 26.332 s, 9.23 FPS, 4096x3072 output
• FlashVSR+ Turbo: 54.024 s, 4.50 FPS
• SeedVR2-3B: 352.820 s, 0.69 FPS
• Open-H3-Regenerate-2K: 784.954 s, 0.31 FPS

Those are H100 numbers for a 10 second clip. The paper behind the original 4x model reports 29.29 FPS at 1080p on an A100 with 13.82 GB peak memory against 7.80 FPS and 24.447 GB for FlashVSR-Tiny, so the architecture is built to stay inside a single GPU rather than to win on a benchmark rig.

One early user measurement on Banodoco puts the gap in the same range on consumer hardware: JohnDopamine read the timestamps off a run where Relay's finishing stage took about 85 seconds while FlashVSR+ logged 331 seconds (message). Same clip, their own GPU and setup, so read it as a ratio rather than as an absolute speed.

Running it

Inference lives in LightX2V, not in a separate package:

git clone https://github.com/ModelTC/LightX2V.git
cd LightX2V
hf download lightx2v/RelayVSR_X2 \
    wan_x2.safetensors flash_x2.safetensors \
    --local-dir ./models/RelayVSR_X2

Point scripts/relayvsr/run_relayvsr_x2_sr.sh at the clone, the weights, an input video and a GPU, keep --model_cls relayvsr_x2 with --config_json configs/relayvsr/relayvsr_x2.json and --sr_ratio 2, then run it from the repository root. The default config keeps both checkpoints resident with compilation and warmup on; relayvsr_x2_block_offload.json offloads the Wan blocks for tighter VRAM, and relayvsr_x2_sp.json splits one clip across two GPUs.

For repeated work there is a resident server mode: start python -m lightx2v.server --model_cls relayvsr_x2 --task sr, then post input path, sr_ratio, output path and seed to /v1/tasks/video/ per clip, so the weights load once.

Availability

RelayVSR X2 is a LightX2V release: Linux plus an NVIDIA GPU, run from the CLI or the server, with no ComfyUI node or wrapper published yet and no diffusers pipeline in the repository. LightX2V's changelog lists asynchronous encoding and preserved source audio, so an H3 clip keeps the track it was generated with. Anyone who wants it inside a graph currently has to wrap the runner themselves.