Force/Set CLIP Device

Despite living in a pack built for PixArt and Sana, this node's actual claim to fame has nothing to do with either. It's a one-trick utility: take any CLIP object and pin it to a device - usually cpu - instead of letting ComfyUI decide where it lives. And the trick people actually use it for is freeing VRAM on completely unrelated models, Flux included.

Here's the pattern, straight from a real troubleshooting thread: someone's 16GB card was running out of room loading Flux because the text encoder (T5, in Flux's case a good chunk of a gigabyte-hungry file) was fighting the diffusion model for the same VRAM. The fix someone suggested was exactly this node - load CLIP, run it through "Force/Set CLIP Device" set to cpu, and now the encoder sits in system RAM instead of competing for VRAM. The diffusion model gets the card to itself. It's not specific to PixArt at all; it works on any CLIP object flowing through your graph, from any loader.

That's the honest way to think about this node: it's less "part of the PixArt pipeline" and more "a general VRAM-management escape hatch that happens to live in this pack."

Inputs. Two, both required: clip - any CLIP object, wired straight out of whatever loader produced it - and device, a dropdown you set to the target device. Defaults to cpu. What else shows up in that dropdown depends on what your ComfyUI process can actually see - a second GPU shows up as its own entry if you've got one, which is the whole point if you're trying to shuffle a fat encoder off your primary card and onto a spare rather than off to slow system RAM.

Output. Just CLIP - the same object, now living wherever you told it to. Wire it onward exactly like you would the CLIP output from any loader; nothing downstream needs to know it passed through this node.

Where it fits. Drop it right after your CLIP loader and before whatever consumes the CLIP object - a text encode node, typically. It's a pass-through, so it costs you nothing to leave wired in permanently if VRAM is tight on a given machine.

Installing it. Search "Extra Models for ComfyUI" or "ComfyUI_ExtraModels" in ComfyUI Manager, or do it by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/city96/ComfyUI_ExtraModels

Then, inside your venv or conda env, pip install -r requirements.txt - the pack pulls in real dependencies (transformers, bitsandbytes among them) for the model-loading side of things, even though this particular node doesn't need any of that itself. Restart ComfyUI after. If you're on the Windows portable build, the README has a separate python_embeded install path for the requirements file - read that section before you go hunting for a missing module error.

Where people get tripped up. Moving CLIP to cpu doesn't make it free - the RAM has to come from somewhere, and if you're already tight on system memory you'll just trade one bottleneck for another. It's a real fix specifically when VRAM is the scarce resource and system RAM isn't, which describes most consumer rigs with 32GB+ of RAM and a mid-range card. Also worth knowing: this only touches the device the tensors sit on, not their precision - if you're still OOMing after moving CLIP off the GPU, the next lever is a quantized (GGUF) or fp8 version of the encoder itself, not this node again. And if you've got a second GPU, cuda:1 (or whatever your system labels it) is usually a better target than cpu - you keep GPU-speed inference on the encoder while still relieving your main card.