Bare Metal vs. Instances for Real-Time Rendering Farms: bare metal usually wins for sustained, always-on workloads. It offers predictable GPU performance, fixed monthly costs, and no noisy-neighbor risk. Instances win when short, unpredictable peaks threaten delivery.
The practical model is often hybrid. Run baseline capacity on dedicated GPUs. Burst to instances only when queue time, utilization, and deadline risk exceed defined thresholds.
Choose by queue pressure, not GPU labels
Choose dedicated GPUs for sustained queues and instances only for short, unpredictable peaks. Use hybrid capacity when a stable base load meets a hard deadline.
Measure the workload before buying
Start with three numbers: planned project length, expected GPU utilization, and maximum acceptable queue wait. Utilization is the share of time a GPU does useful work.
A node running at 70% to 85% utilization during business hours has a different cost profile from a node busy only during final-week rushes.
Queue behavior should drive the purchase.
Account for the data path
Real-time work is sensitive to delay. Latency is travel time between systems. Jitter is inconsistency in that travel time.
A 15 to 30 millisecond path can feel usable, such as from a Los Angeles artist workstation to a nearby GPU. Repeated 80 to 120 millisecond storage or cache requests can make an interactive session drag.
For interactive rendering, a faster GPU rarely fixes a slow asset path. Measure scene-open time, cache warm-up, texture reads, license checkout, and frame delivery as one pipeline.
A fast GPU cannot rescue slow data access. The next section shows how those delays affect the real project bill.
Cost per frame is total project cost divided by successfully delivered frames. Include compute, storage, egress, licenses, setup, idle time, queue delays, and reruns.
AWS publicly listed an on-demand p4d.24xlarge with eight NVIDIA A100 GPUs in US East at about $32.77 per hour. A p5.48xlarge with eight H100 GPUs was about $98.32 per hour.
Those list rates can change. They exclude storage, transfer, and software costs. Confirm current pricing and regional quotas in the Amazon Web Services pricing pages before committing a delivery date.
The hourly rate is rarely the full cost.
| Project condition | Dedicated bare metal | GPU instances | Best decision |
|---|
| Six-month project, 70% to 85% utilization | Fixed monthly cost; local NVMe cache | Higher on-demand spend if always running | Dedicated baseline |
| Two-week peak, 2x to 4x normal queue | Slow to add physical capacity | Fast extra capacity if quota exists | Cloud burst |
| Large asset egress, 20 TB to 100 TB | No public-cloud egress bill | Transfer and sync can dominate costs | Dedicated or colocated hybrid |
| Hard deadline within 72 hours | Limited by installed nodes | Useful only with tested capacity | Hybrid with pretested cloud quota |
Include costs vendors omit
Add persistent disks, object storage, snapshots, data egress, cache replication, and license-server access. These costs can exceed the compute estimate during a large asset transfer.
Autodesk, Chaos, and SideFX license rules can limit where a render process runs. Validate license mobility before moving jobs outside your network.
Use a project-cost worksheet
Use this formula: (compute + storage + transfer + licenses + operations + reruns + waiting cost) ÷ approved frames. Run it for a normal week and a final-week peak.
Dedicated capacity is usually cheaper for steady work. Cloud becomes cheaper for short peaks if data and licenses can move cleanly.
The cost decision depends on the queue shape. The next section explains when steady queues favor owned capacity.
Dedicated GPUs for steady render queues
Bare metal is the stronger default when queues stay full. It also works best when active assets remain close to the nodes.
Pros of dedicated GPU servers
Dedicated nodes give predictable sustained performance. Another tenant cannot overcommit CPU resources on your node.
They also support multi-GPU layouts and 25GbE or faster internal networking. You can keep large local caches without recurring egress charges.
Local storage changes real render behavior.
Cons and limits to plan for
Bare metal is not instant capacity. Provisioning can take several days or several weeks. GPU supply, rack work, and vendor inventory affect the wait.
Hardware failure also becomes your operational problem. That changes only if the provider includes rapid replacement and a credible service-level agreement.
Choose this if: your project runs at least two to three months. Expected utilization should stay above roughly 65%. Your active assets should remain on fast local storage.
GPU parity is not instance parity. Compare usable VRAM per GPU and PCIe or NVLink topology. Check how many GPUs one render process can access.
Also check approved NVIDIA driver versions and sustained clocks during long renders. The same GPU model can have a different CPU, storage path, network layout, or driver image. Those differences change production performance.
Before treating offers as equivalent, test the same scene.
Confirm that the required instance family exists in the target region. Confirm that cloud GPU quotas cover the full burst, not only a test node.
Benchmark the same scene, renderer version, resolution, texture set, and output destination. Do this before treating two GPU offers as equivalent.
Choose dedicated GPUs for stable queues above roughly 65% utilization. Avoid them when your demand appears only for a few deadline days.
Cloud bursts solve peaks, not weak pipelines
Instances fit short, unpredictable demand that exceeds installed capacity. They work only when required GPUs are available in the required region.
Pros of cloud GPU capacity
Cloud capacity can add GPUs faster than physical procurement. It can also avoid paying for idle servers between short project peaks.
This model works best when scenes, licenses, and output paths have already been tested. A cloud burst is capacity, not a fix for broken asset delivery.
Fast access is useful only when the full path is ready.
Cloud risks that stop a burst
Capacity shortage is the risk most plans ignore. An H100 or RTX class instance may be unavailable during the exact peak week.
Quotas can block the launch. Image boot times, driver mismatches, and missing reserved capacity can also cause a manual scramble.
Set automatic burst rules
Choose this if: your peak demand lasts days rather than months. You must tolerate variable rates. Test quota, capacity, and asset movement in your chosen region.
Cloud bursts suit short peaks with proven access to capacity. Avoid relying on cloud for a deadline if nobody has tested the full path.
Prevent failures before the deadline week
A hybrid farm keeps the normal queue on dedicated GPUs. It bursts only through predefined rules.
This avoids instance rates for predictable work. It also preserves an escape route for deadline changes.
Validate the burst path early
Run a rehearsal at least two weeks before the peak. Submit production-like scenes and measure provisioning time.
Verify NVIDIA driver versions and test license checkout. Prove that output returns to the right storage location. Test both on-demand and fallback regions.
A test node does not prove burst capacity.
Match architecture to the studio
This comparison matters less for occasional single-machine renders or lightweight CPU-only jobs. It also matters less when scene cleanup, artist workflow, or licensing is the main bottleneck. Fix that bottleneck first. Adding GPUs to a blocked pipeline only makes the bill larger.
A hybrid rendering setup needs a scheduler that knows job priority and capacity source. Deadline, OpenCue, or Slurm can keep the base queue on dedicated nodes. They can send approved overflow jobs to ephemeral workers.
Kubernetes helps when render workers already run as containers. It also helps when those workers need repeatable deployment.
Set bursting rules around queue time. Use projected wait above 60 minutes. Also use utilization above 85% for four hours and a forecasted deadline miss.
Clear rules prevent panic spending.
The scheduler should tag burst jobs with the right renderer and driver image. It should also apply the right license setup, storage mount, retry policy, and shutdown timer.
That stops idle workers from consuming budget after the queue clears.
A small studio can start with a few dedicated GPUs. Add a shared fast NAS and local NVMe cache. Use cloud capacity only for approved final-week overflow.
An episodic production benefits from a larger fixed baseline. Recurring shots keep render farm capacity busy across episodes. A VFX team with irregular spikes should keep dedicated capacity for dailies. It should use pretested regions for simulation-heavy or final-frame bursts.
For remote interactive rendering, keep GPU nodes, asset storage, caches, and license services close together. Then tune the artist connection separately.
This design cuts asset pipeline latency. It also avoids repeated data egress costs from moving active assets between locations.
Choose hybrid capacity when steady work meets uncertain peaks. Avoid both options if your true bottleneck sits outside GPU capacity.
Your questions answered
Bare metal is better when utilization stays above about 65% for months and assets stay near nodes. It gives stable performance and fixed capacity. It cannot absorb a sudden fourfold queue without spare hardware.
When are cloud GPU instances cheaper?
Cloud GPU instances cost less when high demand lasts days or a few weeks. They can avoid idle-server cost. Include storage, egress, licenses, and failed-job retries in the calculation.
Can equal GPUs render at different speeds?
Equal GPU models can render at different speeds when CPU, PCIe layout, drivers, thermal limits, or storage throughput differ. Compare completed frames with the same scene, renderer version, and asset location.
Should final frames run on spot instances?
Final frames should run on spot instances only with checkpointing, automatic retries, and on-demand fallback capacity. Spot savings disappear if an interrupted job restarts after the deadline window closes.
What queue wait should trigger a cloud burst?
A cloud burst should start when projected queue wait exceeds 45 to 90 minutes or threatens a review deadline. Use sustained utilization above 85% for four hours as a second trigger.
Is Kubernetes required for a hybrid render farm?
Kubernetes is not required for a hybrid render farm. It helps manage containerized ephemeral nodes at scale. Deadline, OpenCue, or Slurm may be simpler with an existing render-queue workflow.
The essential points:- Keep sustained render demand on dedicated GPUs when utilization supports fixed capacity.
- Use cloud capacity for measured peaks, not as an untested deadline rescue.
- Compare total project cost per approved frame, including data movement and waiting time.
- Set automatic burst thresholds before the queue becomes a production emergency.
Make the capacity decision this week
Choose a hybrid design unless your workload is clearly steady or clearly temporary. It limits fixed-hardware risk without trusting urgent work to unverified cloud availability.
Build a 30-day capacity forecast. Run one production-like scene through both environments. Record delivered-frame cost.
Then reserve dedicated capacity for the base queue. Preapprove cloud budget for overflow.
Test capacity before deadline pressure arrives.
Related sources
These articles can help you explore the topic in more depth:
