Case study

Case Study: The 12-Artist Studio That Stopped Buying GPUs

27 August 2026 · RenderBob team

A twelve-person motion studio walks into Q3 2026 with a problem every studio recognises: three overlapping campaign deliveries, a ComfyUI-heavy video pipeline, and a render queue that is full for the entire…

This is an illustrative composite based on common studio patterns, not a named client.

A twelve-person motion studio walks into Q3 2026 with a problem every studio recognises: three overlapping campaign deliveries, a ComfyUI-heavy video pipeline, and a render queue that is full for the entire delivery week. The old answer would have been obvious: buy three more machines. The cards they wanted were selling at more than double MSRP and were not reliably in stock. Buying their way out was off the table.

Their existing setup was eight workstations, each with a capable but not top-tier GPU, running ComfyUI locally with per-artist model folders. Two recurring pains dominated. First, capacity: the heaviest final-quality video passes tied up a workstation for hours, starving iteration. Second, reproducibility: a workflow tuned on one machine sometimes failed on another, costing an artist an afternoon at the worst possible time.

They changed the structure, not the hardware count. Baseline load (iteration, previews, standard-resolution passes) stayed on owned workstations, which were already paid for and perfectly adequate for that work. The heavy final passes, the ones that OOMed locally or monopolised a machine, were routed to cloud nodes in the studio's own provider account, behind the same submission layer artists already used. A shared, version-pinned model registry replaced the per-artist folders.

During the spike, the heavy jobs found cloud capacity instead of forming a queue, so iteration on owned nodes never stalled. The reproducibility failures stopped, because every node (owned or cloud) pulled from the same pinned registry. And the cloud spend was bounded: a hard node cap, idle shutdown, and budget alarms meant the overflow cost was a known, reported line item rather than a surprise.

The number the founder cared about was that they delivered three campaigns on time without a single capital purchase in a quarter when purchasing was slow and expensive. Owned hardware carried the steady load it was good at. Cloud carried the spikes it was good at. Nobody re-learned their tools.