SeedVR2 Loader (V100 fp32)

Here's the honest pitch for SeedVR2 Loader (V100 fp32): it loads the model in full fp32 and refuses to be clever. No residual-stream patching, no power-of-two rescaling. It costs you roughly twice the runtime and most of a 32GB card, and in exchange it produces the answer the model was always supposed to produce. When a V100 result looks wrong and you need to know whether it's the model or the fix, this is the reference you check against.

What it is

It's the other half of duckyman-ai's V100 pack. The headline node keeps the parts of SeedVR2 that overflow in fp16 in fp32 and rescales them around a transformer-block patch. This one just hands ComfyUI's loader model_options={"dtype": float32} and lets physics take its course. No fp16 anywhere means nothing to overflow, so there's nothing to patch.

The context: SeedVR2 is the default "add detail" rung of the upscaling ladder, and its video path is expensive enough that people run it on rented 32GB V100s. Volta doesn't do fp8 compute, so the fp8 checkpoint gets dequantized to fp16 at load - precisely the precision where the txt residual register blows past 65,504 and the clip decodes to black. Take fp16 out and that failure mode is gone.

What it does, and what that costs

Mechanically it does two things at execution: forces fp32 compute on the diffusion-model load, and installs the pack's VAE patch that keeps SeedVR2's causal caches on the GPU instead of host RAM. It deliberately skips the transformer block patch - with fp32 there's nothing to do.

That second half explains the price. The 7B model in fp32 is around 28GB, and the VAE has just been told not to offload its caches, so a 32GB card has very little slack left - which is why clips longer than roughly 3–4 seconds at 0.4 MP need SeedVR2TemporalChunk. You're out of VRAM, not ideas.

Can't you just use the stock UNETLoader? Not really - its options quantise weights, they don't force fp32 compute, so there's no dial there that gets you here.

Inputs and outputs

One input, one output, and no setting you can get wrong:

• unet_name - an enum of files in models/diffusion_models whose filenames contain seedvr. Same population rule as the fp16-safe node, and the only field on the node. The missing dtype selector isn't an oversight; the dtype is the product.
• MODEL out - into the sampler, where the old loader used to feed it.

The rest of the workflow is untouched: the Resize node before SeedVR2 carries the upscale factor (×2 is the design sweet spot, ~×2.2 for 480×864 into 1080×1920), and everything after the sampler stays as it was. This node replaces a loader, nothing else.

Watch the file filter - it's literally "filename contains seedvr", in models/diffusion_models. A checkpoint in models/checkpoints never appears, and an empty match falls back to a placeholder name that may not be on disk.

Install

Same pack, same clone, both nodes:

cd ~/ComfyUI/custom_nodes
git clone https://github.com/duckyman-ai/ComfyUI-SeedVR2-V100.git
# restart ComfyUI

Or ComfyUI Manager, searching "SeedVR2 V100". There's no requirements.txt and no install.py - one __init__.py over torch and ComfyUI's own comfy.sd, so nothing gets installed that could break your other nodes. It needs a ComfyUI new enough to ship native SeedVR2 support, since the pack reaches into comfy.ldm.seedvr; the author tested 0.39.0 / torch 2.9.1+cu126. Then drop seedvr2_7b_fp8_e4m3fn.safetensors into models/diffusion_models, and avoid int8_convrot on Volta - it OOMs, and this is already the VRAM-hungry node.

When to actually use it

Mostly, you shouldn't. On the author's benchmark - 480×864 ×192 frames up to 960×1728 on a V100-SXM2-32GB - fp32 took 18:31 against the fp16-safe loader's 9:15, for output that validated as visually identical. Nobody wants to double their render time for the same clip.

Three situations justify it. You're debugging: if fp32 also gives you black or garbage, the problem isn't the fp16 overflow this pack exists to fix, so go look at the VAE, the checkpoint, or a loader you left in the graph. You're auditing the fix: run one short clip through both loaders and compare - if they match, you've reproduced the cosine-0.999 claim on your own footage and can trust the fast path with real work. Or you're on a card where fp16 keeps misbehaving and you just want it finished overnight; forcing fp32 isn't Volta-specific, so it runs anywhere, slowly.

What I wouldn't do is make it your default because it "feels safer." On a 32GB V100 it's the configuration that pushes you into TemporalChunk, and chunking brings its own seams and temporal wobble. And if both loaders feel slow, remember where the time goes: on Volta the VAE decode is conv3d-bound and eats most of the clock - around 7 minutes of that 9:15 run. That's the hardware, not a bug.