ToGPU
Getting your image back onto the graphics card
- image
- IMAGE
ToGPU takes an image tensor sitting in system RAM and pushes it onto your CUDA graphics card. That's the whole job - one input, one output, no settings. It's the second half of a two-node story from the tiny ComfyUI-ToDevice pack: ToCPU moves an image off the GPU, and this node moves it back. You'll rarely use it alone, but when a workflow needs the round trip, you reach for exactly this.
Why would you ever move an image off the GPU in the first place?
Normally you wouldn't. ComfyUI keeps image tensors on whatever device the model lives on, and that's almost always the GPU - moving data around is pure overhead. But some nodes are picky. A handful of image-processing and video-frame utilities do their work in numpy or OpenCV and quietly assume they're being handed a CPU tensor. Feed them a CUDA tensor and you get the classic wall of red: can't convert cuda:0 device type tensor to numpy, or a complaint about tensors being on different devices.
The fix pattern: stick ToCPU in front of the fussy node so it gets a tensor it can chew on, then drop ToGPU right after it so the rest of your graph - the sampler, the VAE, the preview - sees the image back where it expects it. This node is the "restore the natural order" step.
How it works
The mechanism is one line of PyTorch. Internally the node just runs:
return (image.to("cuda"),)
The input image is the required IMAGE tensor, and the single output is the same IMAGE now resident in VRAM. There are no optional parameters, no lists, no modes - if the tensor is already on the GPU, .to("cuda") is a no-op and you pay nothing. Where people get burned is that "cuda" is hardcoded. This node has no idea your machine exists; it does not look up the active device. It assumes NVIDIA CUDA, full stop.
When you'd actually use it
- After a ToCPU node, to hand the result back to the GPU side of a graph.
- When a downloaded workflow from the community wires an image through a CPU-only step and the rest of the graph is starving for a CUDA tensor - this node is the bridge you insert.
That's about it. If you don't have a node that insists on CPU tensors, you don't need this pack, and pretending otherwise is a performance trap (see below).
Install
The README documents a plain clone, and that's all it needs - there's no requirements.txt, no model downloads, no Python deps beyond the torch ComfyUI already ships.
cd ComfyUI/custom_nodes
git clone https://github.com/Noma-Machiko/ComfyUI-ToDevice.git
Restart ComfyUI (or hit the reload in Manager) and the nodes show up under utils. If you use ComfyUI Manager, searching "ToDevice" usually surfaces the pack as well.
Gotchas
- It hardcodes CUDA. Run ComfyUI with
--cpu, or on Apple Silicon / ROCm where the active device isn't named "cuda", and ToGPU throws a RuntimeError - there's nompsorcpufallback. That's exactly why the README warns you to strip--cpufrom your launch flags if you want the CPU→GPU direction to work. - Moving memory is not free. Shuffling tensors between VRAM and system RAM runs over the PCIe bus, which is roughly an order of magnitude slower than GPU memory bandwidth. The community's standing verdict: "the performance penalty for shuffling memory from VRAM to RAM is so huge that it makes it usually not worth it." Fine for a one-shot boundary crossing; a mistake in a per-step loop.
- It only handles
IMAGE. No latents, no masks, no models. If a node needs a latent or a model on a particular device, this pack won't help - those are moved by ComfyUI itself.
Honest bottom line: it's a 30-line utility that fixes one specific, annoying failure mode. When that failure mode hits, it's exactly what you want. When it doesn't, it's dead weight in your graph.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| image | IMAGE | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| IMAGE | IMAGE | — |