Why we render marketing video on a home GPU instead of the cloud

SiteOps generates marketing video: a scenario goes in, and rendered clips come out in three aspect ratios with voiceover and captions. Every one of those clips is minutes of GPU time. Early on we had to decide where that GPU lives — rented in a cloud region, or owned, sitting under a desk. We chose the desk. This post is the arithmetic behind that choice, because the arithmetic is the whole argument.

Start with what a render actually costs. A 30-second clip, rendered at 1080p in three aspect ratios with a synthesized voiceover and burned-in captions, takes our pipeline roughly 12 to 15 minutes of GPU work end to end. If you publish one clip per day per product, and you run a handful of products, you are looking at something in the range of 300 to 500 GPU-hours a year. That is not a spike. That is a flat, boring, predictable load — and flat, boring, predictable loads are exactly what clouds charge you the most margin on.

An L4- or A10G-class GPU instance on the major clouds runs somewhere between $0.70 and $1.20 per hour once you include the CPU, RAM and disk that come attached to it. Call it $1.00 to keep the math honest. Four hundred hours a year is $400 — but that number assumes perfect hygiene: the instance exists only while a job runs, boots instantly, and is torn down the second the render finishes. In practice you pay for boot time, for model loading, for the idle gap between jobs, and for the one instance somebody forgot over a weekend. Real-world utilization pushes the effective cost to two or three times the theoretical one.

Now the other column. A consumer RTX 5070 costs about $600 once. Under render load it draws around 250 watts; at $0.20 per kilowatt-hour that is five cents per hour of electricity. Four hundred hours a year costs $20 in power. The card pays for itself against the honest cloud number inside the first year, and everything after that is effectively free rendering — the marginal cost of one more clip rounds to zero.

owned GPU: $600 once + $0.05/hr. rented GPU: $1.00/hr forever. steady load breaks even in months.

The number that mattered more than either column, though, is a behavioral one. When rendering costs a visible dollar amount per attempt, you render less. You batch experiments, you skip the third variant, you hesitate before re-rendering a clip because one caption was two frames late. When the marginal render is free, you iterate until the clip is right. We render far more variants than we would ever have approved as a cloud line item, and the published clips are better for it. Metered pricing quietly taxes iteration, and iteration is the entire job in marketing video.

Being fair to the cloud: it wins in specific, real situations. If your load is spiky — nothing for weeks, then 200 renders overnight — autoscaling beats any single card. If you need the newest datacenter silicon for a model that will not fit in 12 GB of VRAM, you rent it. And if a render must never wait, a pool of machines beats one. None of those described us. Our queue tolerates a job waiting twenty minutes; our models fit on consumer hardware; our load is a metronome, not a heartbeat.

The tradeoffs we did accept are worth naming plainly. One machine is one point of failure: if the card dies, rendering stops until it is replaced. A residential connection has no SLA. And a box in a home office is not a hardened environment. Our mitigations shape the whole architecture. The worker pulls jobs from a cloud queue instead of accepting inbound connections, so nothing on the home network is exposed — no open ports, no tunnel to defend. The control plane and the job state live in the cloud; the worker holds no truth. If the machine goes dark, jobs queue up and wait rather than vanish, and the day the load outgrows one card, a second worker subscribes to the same queue and the architecture does not change.

There is also a quieter benefit: the constraint disciplined the pipeline. Knowing every render runs on one known card, we profile against real hardware instead of a fleet abstraction, keep models within a fixed VRAM budget, and treat render minutes as an engineering metric. Scarcity you chose is a useful teacher.

The rule of thumb we would hand anyone doing this math: rent for loads that are spiky, experimental, or unknown; own for loads that are steady, predictable, and yours to keep. Marketing video for a stable set of products is the second kind. Run your own numbers with your own electricity price and your own render times — but run them. The default of "everything goes to the cloud" is a habit, not a calculation.