Engine + desktop vs batch.
Guide
Rendering Server Complete Guide
How to think about a monthly render server or render VPS: what your render engine actually needs, how much VRAM matters, and when dedicated cloud rendering beats local hardware or hourly GPU rentals. Pair this guide with published plans and specs on pricing.
Part 1 · Understand Concepts
What a Rendering Server Is For
A render server (or dedicated render host) is a machine you rent or own to run path-traced or GPU-accelerated frames—not the same problem as a live streaming encoder or a generic cloud VM. Most studios use it in one of two ways:
- Batch / farm work — queue frames or tiles, run at full GPU load for hours, write outputs to disk. Priority: VRAM for the heaviest scene, NVMe for caches and EXR/PNG, stable cooling, enough system RAM if textures spill out-of-core.
- Remote creative workstation — install your DCC, work over RDP or similar, render test frames on the same box. Priority: responsive desktop, driver compatibility, VRAM for the scene you manipulate in the viewport—not maximum frames per hour across a queue.
Many pipelines use both: look-dev on a workstation plan, finals on a headless node or a second plan. Size each role from peak VRAM and OS needs, not from one averaged scene.
Render Server Mart lists monthly, whole-machine render server and render VPS plans with published GPU, VRAM, RAM, and storage—aimed at teams that cloud-render on a fixed stack for weeks. Burst-only jobs may still suit hourly render farms; long projects usually benefit from predictable render server pricing on dedicated hardware.
Common Workflows (What to Size First)
Use the table as a checklist before you open pricing. The last column is guidance only—always confirm against a test render from your heaviest scene.
| Workflow | Typical render path | Size first | Plan direction |
|---|---|---|---|
| Architectural visualization | V-Ray or V-Ray GPU, Chaos Corona (CPU), Blender Cycles | Large textures and entourage; Corona/V-Ray CPU need RAM more than VRAM | High-VRAM GPU plan if you use GPU engines; high-RAM plan if CPU Corona/V-Ray dominates |
| Product & packshot | Blender Cycles, Redshift, KeyShot (CPU or GPU depending on version) | Moderate geometry; 16–24 GB VRAM often enough for GPU path | Single-GPU entry or mid monthly plan |
| Character animation | Redshift, Octane, Arnold GPU, Cycles | Hair, fur, UDIMs, motion blur—VRAM spikes on hero frames | 24 GB+ VRAM plan; test one production frame before committing |
| VFX & simulation | Houdini Karma (CPU/XPU), Redshift, Arnold | Large sim caches on disk; Karma XPU mixes CPU and GPU | High system RAM + NVMe; multi-GPU plan when the queue runs many frames in parallel |
| Real-time & cinematics | Unreal Engine (Lumen/path tracer), Blender Eevee | Interactive framerate and viewport memory, not overnight batch efficiency | Single fast GPU plan with Windows remote desktop |
| Farm / queue nodes | Deadline, Blender CLI, custom scripts | Identical images across nodes, headless stability, fast asset I/O | Repeat the same multi-GPU or single-GPU plan per node |
Note: Real-time archviz tools (e.g. Enscape, Lumion, D5) usually run on an artist’s local GPU. This guide focuses on path-traced and batch GPU/CPU rendering on a hosted server—not replacing those desktop apps.
CPU Vs GPU Rendering
Your render engine picks the hardware path first. CPU engines (Chaos Corona, V-Ray CPU, Arnold CPU) scale with cores and system RAM—very large scenes can stay on CPU when they exceed GPU memory. GPU engines (Redshift, Octane, Blender Cycles with CUDA/OptiX, V-Ray GPU, Arnold GPU) need NVIDIA GPUs for most studio setups and are often much faster on scenes that fit in VRAM, but they hit a hard limit when geometry and textures no longer fit on the card.
| CPU rendering | GPU rendering | |
|---|---|---|
| Best for | Huge scenes, CPU-only plugins, Corona-heavy archviz | Redshift/Octane/Cycles GPU, fast iteration when scenes fit in VRAM |
| Scales with | More CPU cores and RAM | Per-GPU VRAM; extra GPUs usually add throughput (more frames), not one combined VRAM pool for a single frame |
| Memory | 64–256 GB+ system RAM is common in production | VRAM is the ceiling; some engines page textures to system RAM at a speed penalty |
| Render Server Mart | Choose plans with enough RAM if you render on CPU | Render server plans—match published VRAM to your engine |
Redshift is GPU-only. If your pipeline is CPU-only, prioritize RAM and core count on the plan spec sheet, not the largest GPU. If you are GPU-only, size VRAM from your heaviest approved scene, not a light preview.
VRAM: The GPU Rendering Ceiling
For GPU path tracing, VRAM is usually the limit that decides success or failure. Geometry, BVH/acceleration data, and active textures need space on the card. When renderers spill to system RAM (out-of-core), times can slow sharply compared with fully in-VRAM renders—exactly how much depends on the engine, scene, and host RAM speed.
Rule of thumb by use case
| Use case | Typical VRAM target | Notes |
|---|---|---|
| Learning & low-poly | 8–12 GB | Fine for tutorials; production scenes outgrow this quickly |
| Freelance product / arch stills | 16–24 GB | RTX 4090 class is a common sweet spot |
| Animation & commercial VFX | 24–48 GB | Hair, volumes, 4K textures; A6000 / 5090 tiers |
| Large environments, 8K textures | 48 GB+ | Workstation-class 48 GB cards, or simplify scene / split shots—multi-GPU does not automatically merge VRAM for one frame |
Published engine minimums (starting points only)
| Software | Vendor minimum VRAM | Practical studio note |
|---|---|---|
| Blender Cycles (GPU) | ~2 GB listed | 8 GB+ for production; OptiX on RTX |
| Redshift | 8 GB | 12 GB+ once UDIMs and instances stack up |
| OctaneRender | 8 GB | 16 GB+ for heavy material networks |
| V-Ray GPU | 8 GB | Hybrid CPU+GPU possible; still VRAM-limited on GPU leg |
| Unreal (path-traced / high-end) | 8 GB listed | 12–16 GB+ for detailed open worlds |
Size VRAM to your heaviest approved scene + 15–20% headroom for denoisers and driver overhead
Pair VRAM with system RAM on the plan: if your engine supports out-of-core textures, allocate enough host memory (often 128 GB+ for heavy VFX) so spill does not thrash disk. Geometry that still exceeds VRAM usually requires instancing, proxies, or level-of-detail—not another GPU alone.
Local Workstation Vs Cloud Vs Dedicated Server
Studios choose between buying local hardware, renting hourly GPU marketplaces, and monthly dedicated hosts. Each model optimizes for a different budget shape:
| Model | Billing | Strengths | Watch-outs |
|---|---|---|---|
| Local workstation | CapEx + power/AC | Zero upload latency, full control, no recurring bill | VRAM frozen until you buy again; no burst capacity |
| Hourly GPU cloud / render farm | Per GPU-hour or credit | Good for bursts, student work, or render-as-a-service uploads | Queues, version mismatch, harder to forecast monthly rendering server cost |
| Monthly render server | Flat monthly | Same OS image for weeks, your licenses, farm node identity | Right-size VRAM up front; upgrade path matters |
Render Server Mart focuses on the third model: exclusive monthly hosts with published specs so you can compare render server pricing to amortized local hardware and ad-hoc farm credits over a full production schedule.
Render Engines & NVIDIA Stack
Most third-party GPU renderers on this site’s plans target NVIDIA CUDA. RTX GPUs also expose OptiX, which Blender Cycles and V-Ray GPU can use for hardware-accelerated ray tracing. Redshift and OctaneRender are GPU-centric; Arnold and V-Ray ship both CPU and GPU modes. Before you order a plan, confirm:
- Engine support — e.g. Redshift requires a supported NVIDIA GPU; Corona Renderer is primarily CPU unless you use a separate GPU product in the Chaos ecosystem.
- Drivers — Studio vs Game Ready; align with your DCC vendor’s tested stack on Windows or Linux.
- Licensing — node-locked, floating, or subscription; verify your vendor allows dedicated servers or cloud hosts.
- OS — Windows for RDP and most desktop DCC installs; Linux for many headless farm workers.
- Multi-GPU — extra cards usually increase farm throughput (more frames at once). Single-frame multi-GPU behavior varies by engine (tile packing, alternate frames, or one GPU per process)—read your renderer’s docs before assuming linear speedup.
Storage, Network & Long Runs
Rendering is read-heavy: textures, caches, and simulation files stream from disk while the GPU stays saturated. On a dedicated rendering server:
- NVMe for active projects, Blender caches, and frame output—spinning rust becomes the bottleneck on tight deadlines.
- Network for syncing assets from NAS or object storage; first-frame time includes download, not just trace time.
- Thermals & uptime — batch nodes run at 100% for hours. Datacenter cooling and single-tenant hardware beat consumer desktops thrashing in a closet.
Plans are hosted in USA data centers. If your site lists datacenter test IPs, ping them from your studio before a long contract so upload/sync latency is acceptable.
Part 2 · Choose and Order a Rendering Server
Step 1Name Your Workload
Pick the closest row in the workflow table and note CPU vs GPU rendering for your engine. Decide if the machine is a remote desktop or a batch node—that drives Windows vs Linux on the plan.
Step 2Measure Peak VRAM or RAM
For GPU engines, render one frame at final resolution and read peak GPU memory in the stats panel (Blender, Redshift, etc.). For CPU Corona/V-Ray, watch system RAM instead. Compare the peak to the VRAM guidance and to each plan’s published VRAM/RAM on pricing—when in doubt, choose the next higher VRAM plan.
Step 3Compare Monthly Plans
On pricing, compare plans with the same GPU count (single-GPU vs multi-GPU) so monthly rates and specs line up. Use any benchmark or cost-per-frame notes linked from a plan as a sanity check—not a guarantee for your scene.
Step 4Deploy Pipeline & Backups
Install your DCC and renderer, sync assets from NAS or cloud storage, write outputs to local NVMe, and copy finals back to studio storage daily. Confirm license activation on the new host before you queue a full sequence.
One hero frame test.
VRAM/RAM match on pricing.
Licenses, sync, backups.
Part 3 · Tips & Cautions
- Tip — VRAM beats clock speed: a faster GPU that cannot hold the scene forces out-of-core or failure; upgrade VRAM before chasing the next FPS tier.
- Tip — System RAM matters: for Redshift, Octane, and V-Ray GPU, large host memory makes texture spill usable; 64 GB is a floor for serious production, 128 GB+ for VFX.
- Tip — Multi-GPU: verify your engine uses all cards for a single frame vs one frame per GPU; mismatched expectations waste silicon.
- Tip — Monthly vs hourly: if you render more than a handful of days per month on the same software versions, model total rendering server cost—dedicated monthly often wins over marketplace hourly stickers.
- Tip — Benchmarks: when a plan links to OctaneBench or cost-per-frame data, use it to compare two plans on the same test—not as an SLA for your assets.
- Caution — Licenses: confirm vendor cloud/dedicated terms; we provide infrastructure, not third-party license compliance.
- Caution — Optimization: instancing, proxies, and texture resolution often buy more headroom than another GPU—profile before you overbuy.
- Caution — Backups: treat the render node as production storage during the job; sync finals back to studio NAS or object storage daily.
Outline