Force/Set Device (Universal)

ComfyUI's VRAM management is usually fine on its own - and then you hit the one case it stubbornly refuses to solve: you want a specific model off the GPU. The classic is full-fp16 Flux on a 12GB card, where the standard community move is to keep the giant T5 text encoder on the CPU so the UNet gets the whole card. There's a known trick for that ("use a force cpu node in ComfyUI", as the r/comfyui advice goes), and this is one of those force nodes. Its real name is UniversalDeviceOverride, but in the menu you'll find it as Force/Set Device (Universal).

It does exactly one thing: pins whatever you hand it to a device, and pins it hard. The device dropdown is built from the GPUs ComfyUI actually sees at load - on a CUDA-less or single-GPU box you mostly get cpu plus your cuda:0, so the realistic use case is "run this one model on the CPU" more often than "spread across GPUs."

What you wire in

One widget, eight optional inputs. Drop a MODEL, CLIP, VAE, WANVAE, CLIP_VISION, CONTROL_NET, T2I_ADAPTER, or IP_ADAPTER into any of them, pick a device, and the matching output comes out the other side with its type preserved. This is the nice bit: it returns a real WANVAE as a WANVAE, not some generic blob, so strict-typed nodes downstream won't throw.

Wire only what you actually want moved. Leave the rest unconnected and they pass through as None - no harm, but no point either.

How it actually works

Under the hood it's more surgical than a .to(device) call. It digs into the wrapper object to find the real torch.nn.Module (it knows the attribute names ComfyUI uses - cond_stage_model for CLIP, first_stage_model for VAE, diffusion_model for UNet, net for IP-Adapter, and so on), moves that to your device, sets device / load_device / offload_device on both the object and its patcher, and then monkeypatches .to() into a no-op so nothing downstream shoves it back onto the GPU. That last part is why it's called "override" - ComfyUI's own offloader would normally undo your choice within milliseconds. The approach is credited to City96's ComfyBootlegOffload gist, which tells you the lineage is legitimate even if the pack isn't famous.

Getting it

Install the whole pack (this node ships with five unrelated siblings - the author describes the repo as "random nodes for various purposes"):

cd ComfyUI/custom_nodes
git clone https://github.com/ARZUMATA/ComfyUI-ARZUMATA

Then restart ComfyUI. Or skip the terminal and search ComfyUI-ARZUMATA in ComfyUI Manager. No extra dependencies - it's plain torch and Python - and no model downloads.

Where people get burned

• The .to() patch is a blunt instrument. Any node that expects to move the model itself (some adapter loaders, certain custom samplers) will silently do nothing instead of erroring. That's the trade-off for the hard override.
• It moves the module, not the dtype. If you're forcing T5 to CPU, pair this with a node that casts it to fp16/bf16 first - otherwise you get CPU-bound fp32, which is brutally slow. The other escape hatch here is just using an fp8 Flux model, which frees most of the same VRAM without any node surgery.
• Multi-GPU boxes: the dropdown only shows cuda:N for GPUs present when ComfyUI loaded. If you hot-plug or use MIG slices, restart the server first.
• This is a small personal pack with no community test coverage. It's fine to run - just be aware that "it worked yesterday" is the only support you'll get.

Honest verdict: reach for it when ComfyUI's normal low-VRAM/offload settings aren't doing the job and you've already tried the fp8 route. It's a scalpel, and like all scalpels it can cut you if you're careless with it.