Render Farm Pricing Comparison: CB/OB, GHz-Hour, Core-Hour & IaaS Explained

Render farm pricing models overview · What they include · Which one is right for you

Render farms have become essential tools for modern VFX studios, 3D artists, and freelancers handling complex 3D scenes, simulations, and high-resolution animations. However, understanding how pricing works across different platforms can be confusing.

This guide breaks down the main pricing models, compares costs and performance, and helps you determine which approach best fits your workflow and budget.

Artist overwhelmed by pricing information

When choosing a render farm, the price you see on a page is only part of the story. What really matters is what that price includes, how it’s measured, and how the billing model works, as these factors can make the difference between a smart investment and an expensive surprise. Choosing the right render farm is more than just comparing dollar-per-frame rates.

You also need to look at performance, flexibility, and total cost of ownership compared with other cloud options.

Why Render Farm Pricing Feels So Confusing

A major challenge in any Render Farm Pricing Comparison is that there is no "standard pricing" defined across the industry.

Two render farms can charge very different rates and deliver similar or even identical results.

The RenderFarm pricing is influenced by:

• Hardware architecture (CPU/GPU generation)

• Benchmark normalization methods

• Software licenses included

• Storage usage and limits

• Data transfer policies

• Queue priority levels

• Scalability

• Technical support

  
  

The number you see per hour or per frame is only part of the story. The real cost is defined by performance efficiency and total output per dollar spent.

Part 1: How Render Farm Pricing Models Work

Every render farm charges for compute time, but the way that time is measured and billed vary considerably. Understanding each model is necessary before making comparisons.

• Performance-Based Pricing (CB/OB per Hour)

  This model prices compute based on standardized benchmark scores that approximate relative hardware performance rather than raw clock speed or core count. For CPUs, this is usually based on CINEBENCH (CB), and for GPUs, on OctaneBench (OB).

  
  

  For GPU rendering, however,  benchmark scores don’t tell the full story. VRAM capacity can become a limiting factor in complex scenes, and when memory is exceeded, out-of-core rendering can significantly reduce theperformance. Even GPUs with similar OctaneBench scores may behave differently depending on workload.

  Rendering also needs to use the CPU for tasks like scene preparation, texture conversion, and mesh processing, many of which are single-threaded.

  Multi-GPU scaling is not always linear due to synchronization and scene complexity.

  
  

  The main idea is simple:

  Pricing is based on estimated performance, not just hardware specs.

  
  

  For example, a machine with an OB score of 1600 costs proportionally more than one with 1000, but it also renders proportionally faster. In practice, this tends to keep the cost per final output relatively consistent across machine tiers, though real results vary depending on on how efficiently a renderer uses CPU resources for a given scene, renderer behavior, and hardware factors such as memory and cache.

  
  

  The software differentiation is also important and often underappreciated. For example, Houdini simulations require high-memory nodes of 512GB to 1TB, while Blender scenes are less demanding. A farm that prices these identically is either overcharging simpler jobs or underpricing complex ones.

  
  

  Transparent, software-differentiated pricing is generally fairer and more accurate.

• GHz-Hour Pricing

  The GHz-hour model is a way to price CPU rendering. Instead of charging for specific hardware, it estimates compute usage based on the number of CPU cores, their clock speed, and the time they are used.

  Example.: 44-core machine at 2.2 GHz renders your scene for one hour = 96.8 GHz-hours.

  
  

  This model scales linearly, meaning cost increases proportionally with the amount of compute time consumed. Software licenses are usually included and file transfer costs are handled separately or not charged as part of compute time.

  
  

  However, render time does not scale linearly with GHz-hours because actual performance depends on renderer efficiency, threading behavior, and scene complexity. Scenes with heavy volumetrics or global illumination require disproportionately more compute than simple scenes. This can make budgeting less predictable, unless users benchmark representative frames locally or on small cloud tests in advance.

• Core-Hour Pricing

  Core-hour pricing is based on number of CPU cores used per hour.

  For example, using 4 CPU cores for 2 hours equals 8 core-hours. Some farms charge per CPU core per hour, independent of clock speed or architecture. This means slower and faster CPUs are billed the same, which can significantly impact cost efficiency.

Important

A single 3.0 GHz core isn’t equal to 2 times 1.5 GHz cores, and different CPU designs can produce very different performance per core. Without a way to standardize performance, you need to look closely at the actual hardware before relying on this pricing model.

• Remote Desktop Rental (Per Clock-Hour)

  Remote desktop rental works differently from managed rendering. Instead of submitting jobs, the artist rents a full cloud machine and works on it directly.

  Billing starts when the machine boots and continues until it is shut down, regardless of whether rendering is actually running. If you forget to shut down the machine, billing continues. Failed renders can also keep costs running until the session is manually stopped.

  This model can be inefficient for short tasks but works well for long sessions, custom pipelines, or users who need full control of their environment.

  
  

Remote desktops generally also require you to bring your own licenses

Artists usually need to bring their own software licenses. Each cloud instance uses a DCC license seat, so running multiple instances requires additional licenses.

Part 2: Comparison Across Pricing Models

The best pricing model depends on your workflow, experience, and project type. While all models charge for compute time, they differ in how that time is measured and how clearly performance is reflected in cost.

Which Pricing Model Fits Best?

• Performance-Based Pricing (CB/OB per hour/second billing)

  This model relies on standardized performance benchmarks such as CINEBENCH (CPU) and OctaneBench (GPU) to normalise hardware differences. Compute is normalized and often billed per second of rendering. For GPU workloads, this model is typically implemented using OctaneBench (OB) or similar benchmarks, where performance is normalised so that higher-tier GPUs are priced in proportion to their rendering throughput.

• GHz-Hour Pricing

  This model bills based on total CPU frequency usage over time, combining cores and clock speed into a single consumption metric. It is widely used, but cost prediction can vary depending on scene complexity and renderer efficiency.

• Core-Hour Pricing

  This model charges per CPU core per hour, regardless of performance differences between generations or architectures, making hardware evaluation critical.

• Remote Desktop

  Billing runs whether rendering is active or idle. This gives maximum flexibility, but also active management of cost efficiency.

Model	Billing Unit	Includes Licenses	Transparency	Cost Predictability
Performance (CB/OB-hour)	CB or OB score / hour	✓ Yes	★★★★★	★★★★☆
GHz-Hour	GHz consumed	✓ Typically	★★★★☆	★★★★☆
Core-Hour	Per CPU core / hour	★ Varies	★★★☆☆	★★★☆☆
Remote Desktop	Clock hours (full session)	✗ Bring your own	★★★☆☆	★★☆☆☆

Not all pricing models include the same services.

Managed render farms typically bundle:

• Software licenses

• Data transfer

• Storage

• Support

Remote desktop solutions shift these responsibilities and costs to the user.

What a managed Render Farm typically includes in pricing?

For example, platforms like GridMarkets include:

DCC and renderer software licenses

Data transfers (upload and download)

Up to 1TB of storage, with more available for larger projects at no additional charge

No idle billing (only active rendering is charged)

Priority tiers - Economy / Standard / Rush.

The Effective Cost Problem

The listed price only tells part of the story. The real cost is what you actually spend per finished frame. That gap is often the most important factor in comparing services.

Tests across different render farms show that the cheapest advertised rate is not always the cheapest in practice once storage, transfer, and performance differences are included.

Queue priority also matters because it affects delivery time, which can impact deadlines and production costs.

Part 3: The Hidden Cost of Building Your Own Infrastructure

Electricity · Cooling · IT · Licenses · Hardware · Refresh · Underutilization

Many studios consider building an in-house render farm at some point.

Owning hardware looks cheaper over time. In reality, the purchase price is just one part of a much larger cost structure.

The real costs of in-house rendering are often underestimated, not because studios are careless, but because most of the costs are invisible.

The Hidden Cost Iceberg of In-House Rendering

The Hidden Cost Isceberg for Rendering

• Electricity

  Render nodes run continuously and consume significant power, creating a constant and increasing electricity bill.

• Cooling

  All consumed power turns into heat. Without adequate cooling, hardware performance drops (thermal throttling), hardware lifespan shortens, and in extreme cases, equipment fails. Fixed costs like space, cooling infrastructure, IT, do not scale with utilization. A farm running at 40% utilization still pays 100% of its fixed overheads.

• IT Staff and Support team: The Invisible Salary

  A render farm does not manage itself. Render farms require constant maintenance: driver updates, network issues, plugin conflicts, queue monitoring, and system updates; all of them require human attention. A render that fails at 3am because a node lost its network connection costs production time whether or not anyone is awake to restart it.

• Software Licences

  Each machine uses its own license. Seats used for rendering reduce availability for production work.

• Hardware Refresh and Depreciation

  GPU and CPU performance "has historically doubled roughly every 3–4 years". Older hardware quickly becomes less efficient compared to newer generations. This performance impacts productivity, deadlines, studio capacity, and competitive positioning.

• Network Infrastructure and Storage

  Rendering depends heavily on fast data access. Slow networks create bottlenecks where machines sit idle waiting for files. High-performance rendering needs high-performance networking and storage.

  On managed render farms, scene upload and download happen outside the billing clock. You pay only for rendering time and even the storage is often included.

• Underutilization: the silent cost

  In-house farms are built for peak demand, but most studios don’t operate at full capacity all the time. Projects have deadlines, which means rendering is concentrated in bursts, with quieter periods in between.

  Cloud rendering scales to zero between projects. You pay for exactly the compute you use, and nothing else.

• When Does In-House Actually Make Sense?

  In-house rendering infrastructure makes financial sense in a narrow set of conditions:

  • Sustained utilization above 80%, running 24/7;

  • Highly specialized hardware requirements: proprietary rendering pipelines or hardware accelerators not available from any farm;

  • Strict data control requirements;

  • Extremely stable, predictable workloads.

  
  

  Otherwise, cloud rendering usually provides better flexibility and cost efficiency.

The Choice of the Right Pricing Model for You

Render farm pricing is not a single number: it is a system.

The billing unit, what the clock actually measures, whether software licenses are included, the generation of the hardware, and whether there are extra charges for data transfer or storage all influence what you end up paying per finished frame.

Performance-based pricing is often the most transparent because cost directly follows output. GHz-hour pricing tends to be predictable for CPU workloads. Core-hour and remote desktop models can work well for users who understand their hardware and manage sessions carefully, but they also introduce more risk if you don’t.

Building your own farm can make sense in specific cases, but hidden costs like electricity, cooling, maintenance, and low utilization often make cloud solutions the more practical choice.

For many smaller studios and freelancers, cloud rendering is the most flexible option, combining scalability, predictable costs, and no capital expenditure. However, the right choice still depends on workflow, deadlines, and the level of infrastructure control required.

Understanding how each pricing model works is the first step toward making a good decision.