VOSR 2.0 Model Loader

Every upscaler with ambitions lands in ComfyUI eventually, and VOSR 2.0 is a strange one to arrive: a one-step, 1.4B-parameter super-resolution model from the research side of the fence (cswry/VOSR, Rongyuan Wu et al.), not another big-lab release. This pack is a standalone community wrapper around it - the README is careful to say it is not part of the upstream repo - and the loader is where that whole story starts, because it drags in every single weight the model needs.

Here's the part that surprises people: VOSR 2.0 is not a single model you download. It's three tightly coupled pieces - a LightningDiT diffusion backbone, a Qwen-Image 2D VAE, and a DINOv2-L vision encoder - and none of them can be swapped independently. The DiT was trained inside that VAE's latent space and conditioned on that encoder, so the loader treats them as one indivisible "bundle" living at ComfyUI/models/vosr2/VOSR2/. There's no separate VAE or CLIP-visual input, and that's not an oversight. Trying to swap in a different VAE will not end well, and the loader is built to tell you so loudly.

Mechanically the loader is straightforward: it checks what's on disk, downloads whatever's missing from the pinned CSWRY/VOSR Hugging Face repo, validates the config against the fixed VOSR 2.0 architecture, and hands you a VOSR2_MODEL object. A few design choices are worth knowing because they shape the failure modes:

• Downloads happen on first run, not at import. Nothing contacts the network when ComfyUI starts or when you validate the node. The README's claim that the first run "will take a second" is optimistic in the extreme - that's roughly 7 GB of weights, so budget real minutes on anything short of a fiber line. It's a one-time cost; afterwards it's cached and no network is touched.
• It's split from the upscaler on purpose. VOSR2ModelLoader exists so queued images don't rebuild several gigabytes of weights on every single run. Load once, reuse across a whole queue.
• It fails loud, not partial. An incompatible args.json or a state dict that doesn't match the expected architecture raises a clear error instead of half-loading. If you drop in the wrong checkpoint, you'll know immediately.

Only two inputs exist and neither is scary. model is a dropdown of bundle folders under models/vosr2/, defaulting to VOSR2 - leave it alone unless you've manually added your own bundle. dtype gives you default / fp16 / bf16 for the DiT and vision encoder, roughly halving their memory on the lower settings; the VAE always runs in fp32, no matter what. The single output, model (type VOSR2_MODEL), wires straight into the model input of VOSR 2.0 Upscale.

Installing is the usual dance, with one caveat: this pack isn't on the Comfy registry yet, so Manager's normal search won't find it. Use:

cd ComfyUI/custom_nodes
git clone https://github.com/ylchen333/ComfyUI-VOSR2
# restart ComfyUI

Manager's "Install via Git URL" also works, but recent ComfyUI-Manager versions gate that button behind allow_git_url_install = true in ComfyUI/user/default/ComfyUI-Manager/config.ini plus a loopback launch - a plain clone sidesteps all of it. The only dependency is huggingface_hub, which already ships with ComfyUI, so no extra pip installs. You do want a 2025-or-later ComfyUI build; the package refuses to import on torch older than 2.1 with a clear message rather than an opaque traceback.

Troubleshooting, honestly: if the loader errors with "huggingface_hub is not available," your ComfyUI environment genuinely lacks it - install it and retry. If you prefer offline installs, the README's "Model files" section has direct download links for all four pieces and the exact layout to place them in; the loader skips any file already present. Also know you're an early adopter - reddit traffic on VOSR is essentially zero as of writing, so this is a "try it and form your own opinion" situation rather than a settled community favorite. For a one-step upscaler aimed at preserving text and fine structure, that early-mover seat is kind of the appeal.