Case study

Case Study: Keeping the Graph Local and Bursting Only Two Nodes

8 September 2026 · RenderBob team

A small motion studio had a specific, annoying problem. Their ComfyUI workflow for a client's animated spots ran fine on their own cards, right up to two nodes.

Illustrative composite based on documented patterns, not a named client.

A small motion studio had a specific, annoying problem. Their ComfyUI workflow for a client's animated spots ran fine on their own cards, right up to two nodes. A heavy video sampling pass and a high-resolution upscale both wanted more VRAM than any card in the building had, and both reliably OOMed. Everything else in the graph (conditioning, control passes, compositing, delivery formatting) ran comfortably on local hardware.

The instinct was to buy a bigger card. In 2026 that meant a scarce, over-MSRP purchase to solve two nodes in one workflow. It felt like buying a truck to move a single couch.

The alternative they landed on was per-node remote execution. Rather than move the whole workflow to the cloud, they marked just those two nodes to run on a rented GPU, keeping the rest of the graph, and all their assets and client material, local. On submission, the marked region was partitioned out, the required models were synced to the remote worker, the two nodes executed there with the VRAM they needed, and the results streamed back into the local graph. To the artist, it looked like the workflow simply stopped OOMing.

Getting it reliable took more than flipping a toggle, and the studio was clear-eyed about that. They pre-synced the model assets to the remote environment so first-run transfer did not eat into a deadline. They matched the remote environment to their pinned local one, so the offloaded nodes produced identical results. They put the remote worker behind a secure tunnel rather than exposing any port. They set a hard cap and shutdown-on-completion so two nodes' worth of cloud time could not become a runaway bill. And they tagged their NDA client's work to run fully local, never remote, because on those projects, the data leaving the building was not acceptable regardless of convenience.

They spent cloud money only on the two nodes that needed it, only while they ran, and kept everything else on hardware they already owned. No truck for one couch. Iteration stayed local and fast; the two heavy nodes stopped being a wall.

The cloud-versus-local decision does not have to be made for a whole workflow. The right granularity is often the node. Choosing per-node, syncing assets, matching environments, securing the boundary, capping cost, and honouring which work is allowed to leave, and doing that reliably across every project, is the pipeline work. Remote nodes are worth it. The routing and governance around them is the thing worth building or buying.