🔧 Image To Device

ComfyUI usually decides where a tensor lives without asking you. Image To Device lets you override that for a specific image - pin it to CPU, force it onto GPU, or hand the decision back to ComfyUI's normal logic. It's the kind of node you reach for on a long, VRAM-tight graph where you want a heavy image batch parked in system RAM between two GPU-bound steps instead of sitting in VRAM doing nothing useful in between.

It's a small node solving a specific class of problem: mixed CPU/GPU pipelines. Some operations in a ComfyUI graph genuinely run better or only on CPU - certain preprocessing steps, some third-party nodes that never got a CUDA path, or just a big batch you want to hold onto in system RAM while the GPU works through something else entirely. Without an explicit control point, you're at the mercy of whatever placement logic ComfyUI and the individual nodes in your graph happen to use, which isn't always what you'd choose yourself on a tight VRAM budget.

How it works

It's a straightforward device move - no compute, no transformation of the actual pixels. device picks the target: auto (ComfyUI's own placement logic), cpu (park it in system RAM), or gpu (force it onto the active CUDA device).

Inputs and outputs

image, device (enum: auto / cpu / gpu). Output: IMAGE.

Installing it

Via ComfyUI Manager, search "ComfyUI Essentials". Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/cubiq/ComfyUI_essentials

Restart. Pack's been maintenance-only since April 2025.

Common issues & troubleshooting

Moving to CPU didn't actually free VRAM. This node relocates a tensor, it doesn't shrink your pipeline's total memory footprint anywhere else. Sending an image to CPU only helps if there's a genuine gap in the graph afterward before it's needed on GPU again - if the very next node pulls it straight back onto GPU, you've just added a transfer with no benefit.

Downstream node throws a device-mismatch error (expects CUDA, got CPU, or the reverse). That's usually this node upstream of it, deliberately pinning the tensor somewhere the next node didn't expect. Set it back to auto unless you have a specific, deliberate reason to force placement.

Not sure if this is actually helping. It's a plumbing node, not an optimization by itself - it only pays off as part of a larger VRAM-management strategy across your graph. If you're not actively fighting a VRAM ceiling, there's no reason to add it.

Forcing gpu and getting an out-of-memory error instead of the speed you wanted. Forcing placement doesn't create VRAM that isn't there - if the tensor genuinely doesn't fit alongside whatever else is loaded on the GPU at that point in the graph, pinning it there just moves the failure earlier rather than preventing it. This node manages where a tensor lives, not how much memory your pipeline needs in total.