RunningHub UNO Loadmodel

The name undersells it. RunningHub UNO Loadmodel isn't "load a model" - it's the whole front half of a reference-based generation pipeline that normally takes a week of wiring to assemble. One dropdown, three wires out, and you've got ByteDance's UNO (Unity and Novel Output) running on Flux. If you've ever wanted IP-Adapter-style image conditioning without a single extra ControlNet or a LoRA training run, this is the node that makes it possible.

What's actually in the box

UNO is ByteDance's answer to "how do I get a consistent object into a scene without training a LoRA?" It's a research model (check the acknowledgments - the original lives at github.com/bytedance/UNO) that injects reference images directly into the Flux transformer as extra tokens, right alongside your text. RunningHub - a Chinese cloud-GPU and workflow-hosting platform - ported it to ComfyUI as this pack.

This node reads the pack's config.json, loads a whole stack of weights, and hands you three outputs:

uno_model (UNO_MODEL) - the Flux diffusion model with the UNO LoRA baked into its attention blocks
uno_clip (UNO_CLIP) - the CLIP + T5 text encoders, wrapped as one bundle
uno_vae (UNO_VAE) - the VAE used to encode your reference images and decode the output

They're custom types, so nothing else in ComfyUI can consume them - every one of these wires plugs into the pack's Sampler node and nowhere else.

The input that matters

There's exactly one input: model_type, with four choices: flux-schnell, flux-dev, flux-dev-fp8, flux-schnell-fp8. Here's the trap: the -fp8 names are a lie. The README is upfront that the author thinks current FP8 Flux weights are problematic, so both dev variants load the same full-precision flux1-dev.sft and both schnell variants load flux1-schnell.sft. The fp8 flag just flips on bf16 autocast during sampling. So really you're choosing between two models:

schnell - distilled, fast, wants ~4 steps, no meaningful guidance
dev - the quality model, wants more steps and a guidance value (the Sampler defaults to 4, which is right)

Pick schnell to iterate, dev for anything you'll actually keep. The fp8 versions are worth a try on a 24GB card if the full BF16 run chokes.

How it loads (and the 24GB claim)

The README says the BF16 models run on 24GB VRAM via "block swapping," and unlike some marketing, the code actually does it. The model loads, then during the forward pass ComfyUI_RH_UNO keeps the double blocks on the GPU, swaps them to CPU, and runs the single blocks - so only half the transformer is resident at a time. It's coarse, not per-layer streaming, but it works.

Everything resolves through config.json in the pack root. Defaults point at ComfyUI/models/unet/ for flux1-dev.sft and flux1-schnell.sft, models/UNO/ for dit_lora.safetensors, models/vae/ for ae.safetensors, and models/flux/FLUX.1-schnell/ for the T5/CLIP tokenizer trees. If you use the single-folder XLabs-style text encoders, set "t5-in-one": 1 and "clip-in-one": 1 and point t5/clip at that one folder.

Install and the heavy lift

Install is the standard song and dance:

cd ComfyUI/custom_nodes
git clone https://github.com/HM-RunningHub/ComfyUI_RH_UNO

Restart ComfyUI (or refresh in Manager - it should find the pack by title). The pack declares no requirements.txt, so anything ComfyUI bundles gets reused; if you hit a missing-module error for accelerate, einops, or transformers, that's the one thing to pip install.

The models are the real cost: flux1-dev.sft is a big BF16 file, plus the FLUX.1-schnell text encoder dirs, ae.safetensors, and dit_lora.safetensors from the UNO HF repo. Budget your disk before you start.

Where people get burned: wrong paths in config.json (it's read relative to the pack root, and the Loadmodel node reloads it on every run, so a fix applies immediately - that part is actually friendly), and expecting the fp8 options to shrink your VRAM bill by loading fp8 weights. They don't. The block swapping is doing that job.