FlashVSR Init Pipeline

This node doesn't upscale anything by itself - it loads FlashVSR's weights and hands you back a bundled reference to them. If you just want to feed a video in and get a bigger one out, use the plain FlashVSR Ultra-Fast node instead, which does all of this internally. This one exists for the pattern you see across a lot of ComfyUI packs: split the "load the model" step from the "run it" step, so you get direct control over how it loads and can reuse the same loaded pipe across runs. Its only real partner is FlashVSR Ultra-Fast (Advanced), which is where the frame-by-frame work actually happens.

What it configures

Where the simple node picks sane defaults for you, this one exposes the loading-time decisions:

• model - FlashVSR or FlashVSR-v1.1 (default v1.1), same checkpoint choice as the simple node, just made once at load time instead of per run.
• mode - tiny, tiny-long, or full, same trade-off as before: tiny is fast and the default, full is meaningfully better quality and meaningfully slower, tiny-long is for videos too long to fit tiny's assumptions.
• precision - fp16 or bf16 (default bf16). bf16 is the safer numerical choice on current cards; fall back to fp16 if you're on older hardware that doesn't handle bf16 cleanly.
• device - auto or cuda:0. Leave it on auto unless you're specifically pinning a multi-GPU setup.
• force_offload - on by default, keeps the model off the GPU when it isn't actively running a batch. Turning it off can save you a bit of reload time if you're chaining a lot of runs back to back and have VRAM to spare, at the cost of that VRAM sitting occupied the whole time.
• attention_mode - sparse_sage_attention (default) or block_sparse_attention. This one has real history behind it: the pack originally shipped on block-sparse attention, which meant compiling a custom kernel yourself. An update swapped the default to Sparse_Sage specifically to drop that requirement. Leave it on the default; only fall back to block-sparse if you already have that kernel built and a specific reason to want it.
• alt_vae - currently only offers none. It reads as a hook for swapping in a different VAE later rather than something doing anything today, so there's nothing to configure here yet.

The output is pipe, a bundled object carrying the loaded model, weights, and these settings. It's a pack-specific type - it only goes one place, straight into the pipe input on FlashVSR Ultra-Fast (Advanced).

Installing it

Same pack as the other two FlashVSR nodes, so one install covers all three. Through ComfyUI Manager, search "ComfyUI-FlashVSR_Ultra_Fast" and install. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/lihaoyun6/ComfyUI-FlashVSR_Ultra_Fast.git
python -m pip install -r ComfyUI-FlashVSR_Ultra_Fast/requirements.txt

Then download the FlashVSR model folder from JunhaoZhuang/FlashVSR on HuggingFace (or the -v1.1 repo for that checkpoint) into ComfyUI/models/FlashVSR - you need LQ_proj_in.ckpt, TCDecoder.ckpt, diffusion_pytorch_model_streaming_dmd.safetensors, and Wan2.1_VAE.pth. Restart ComfyUI. On a Turing-generation card or older, pin Triton before installing (triton<3.3.0, triton-windows<3.3.0 on Windows) - the sparse-attention path needs it and will otherwise fail to build.

Common issues

Build errors mentioning Triton or a missing compiler. That's almost always the attention backend. sparse_sage_attention is the whole reason this pack replaced the older block-sparse approach - it doesn't need a hand-compiled kernel. If you've switched attention_mode to block_sparse_attention and it's erroring, that's expected; switch back to the default unless you specifically need it and have the toolchain for it.

Mismatched model between InitPipe and the Advanced node. The model and mode you set here are what actually loads - if your Advanced node's output looks off, check that this node is configured the way you think it is; there's no per-run override downstream.

VRAM sitting occupied between runs. That's force_offload set to off. Flip it back on if you're not chaining runs tightly and would rather have the memory back.

Old GPU, install fails outright. Turing or older needs the Triton version pin from the README before you even get to running this node - it's an install-time problem, not a settings problem.