Workflow

A Hybrid Local+Remote Motion Workflow: What to Keep Home, What to Send Out

8 September 2026 · RenderBob team

Put together open models on local GPUs, heavy nodes you can send to remote compute, and frontier models arriving as API partner nodes, and the modern ComfyUI motion workflow is a routing problem.

Put together the threads of 2026 (open models on local GPUs, heavy nodes you can send to remote compute, and frontier models arriving as API partner nodes) and the modern ComfyUI motion workflow is a routing problem. Every node has a natural home. Here is a practical guide to placing them.

Keep local: iteration and everything cheap

All exploratory work (blocking motion, testing prompts and conditioning, previewing with distilled models) belongs on your own discrete cards, where responsiveness is everything and volume is free. So does the cheap connective tissue of the graph: image loading, control-pass wiring, compositing, colour handling, delivery formatting. There is no reason to pay network latency to run a node that finishes locally in a second.

Keep local, but on the right local hardware: oversized-but-open jobs

A long, high-resolution pass on an open video model that OOMs your discrete card does not necessarily need the cloud. A unified-memory machine can hold jobs a 5090 cannot. Route these to the roomy local box if you have one, before reaching outside.

Send to a remote GPU: heavy open-model nodes that don't fit at home

The specific VRAM-hungry node (a big sampler, a heavy upscale) that exceeds every card you own is the classic per-node remote-execution case. Mark it, sync its assets ahead of time, run it on a rented GPU, stream the result back. Keep the rest of the graph and your assets local.

Send to an API model: the pass where a closed model's capability is worth it

When a shot needs something frontier models do best (4K with clean, accurate text; strong character consistency) a partner node calling a closed model earns its per-call cost. Use it deliberately, on the specific pass, not as a default.

Never send out: NDA-tagged work

Some clients' material stays on owned hardware, full stop. Those projects run local-only: no remote GPU, no API node, regardless of what would be faster. The routing rule encodes this so it is never an in-the-moment judgement call.

Interpolate rather than render every frame

Wherever framerate matters, generate fewer frames and use frame interpolation to multiply them, cutting the count of expensive frames regardless of where they render.

Write this down as a routing policy so the placement decisions are consistent, cost-bounded, and governed, not re-improvised per artist per project. Underneath, each node should run exactly where it should: cheapest, fastest, and safest. Seamless routing across owned, remote and API compute, behind one submission layer, is what a control plane is for.