Render farm or local GPUs: the numbers most studios get wrong

The render farm question comes up in every studio that has passed three people, and it is almost always argued emotionally. Owners like owning. Freelancers like avoiding capital outlay. Neither instinct survives contact with a spreadsheet, because the right answer depends on one variable most people never measure: how spiky their render demand is.

Start by measuring utilisation rather than speed. Over a normal month, how many hours were your GPUs actually rendering? Not switched on, rendering. Most small studios land somewhere between 15 and 35 percent. If your machines are busy a third of the time, you are paying full price for hardware that is idle two thirds of the year, plus the electricity and the desk space and the noise.

Now measure the shape of the demand. A studio with flat, steady work benefits from ownership because utilisation can be pushed high. A studio with four deadline weeks a quarter where everything lands at once has a spiky curve, and spiky curves are exactly what rented capacity is for. You do not buy twelve nodes so that they can sit quiet for eleven weeks and then just barely cope in week twelve.

The honest cost of a local node is more than the invoice. Take the purchase price, spread it over a realistic three year life because GPU generations move quickly, then add power draw at your local rate, cooling, a share of insurance, and the hours someone spends maintaining drivers and chasing failed frames. That last item is the one everybody forgets, and in a small team it is often the most expensive line on the list because it consumes an artist rather than a budget.

The honest cost of a farm is also more than the quoted rate per node hour. Add upload and download time, the cost of asset repathing when something breaks, the license situation for your render engine, and the very real risk premium of submitting a job at midnight before a client presentation. Farms are excellent and they still fail in the ways all remote systems fail. Budget for one reroll per major delivery and you will be about right.

For most studios between two and eight artists, the workable pattern is hybrid and it is not a compromise. Own enough local capacity to handle iteration comfortably, because iteration is where the quality actually happens and you do not want an artist waiting on a queue to see whether the lighting change worked. Then rent for final frames, animation sequences, and any night before a deadline. Iteration wants low latency. Finals want raw throughput. Those are different problems and buying for both is why studios end up with expensive idle hardware.

Animation changes the arithmetic sharply. A single still at 4K might take 25 minutes on a good local node. A 20 second walkthrough at 25 frames per second is 500 frames, which is over 200 hours on that same node. There is no sensible local answer to that unless you own a rack, and owning a rack only makes sense if you sell animation continuously. Studios that deliver two animations a year and buy a rack for them have effectively paid a very large premium for two projects.

Real time engines have shifted the picture but not as much as the marketing suggests. Producing a client walkthrough in Unreal or Twinmotion removes the render queue for that deliverable entirely, and for many projects that is the correct answer. It does not remove the need for hero stills, and hero stills are where path tracers still win on materials and light behaviour. Plan capacity around the deliverables that still need brute force.

One overlooked factor: the cost of a slow iteration loop is paid in image quality, not just in hours. When a test render takes 40 minutes an artist tries three lighting ideas. When it takes 6 minutes they try fifteen. The fifteenth idea is usually the good one. If a hardware decision makes your loop slower, it is costing you work that never got made, and that does not appear on any invoice.

Run the numbers with your own utilisation figure before anyone quotes a benchmark at you. Two studios with identical output can correctly arrive at opposite answers, and the difference will be the shape of their calendar rather than the speed of their cards.