The Best ROI GPU Server in India: 4x RTX 5090, Fully Benchmarked

The RTX 5090 is the fastest GeForce card NVIDIA makes. It is also a desktop card: large, hot, and rated to pull up to 600 watts. Most servers cannot fit one, and the ones that physically can will throttle it the moment a job runs for longer than a benchmark loop.

We built the Pro Maestro GQ-A to hold four of them and keep them at full clocks under sustained load. It is one of the most exclusive GPU servers available in India, built and supported by ProX PC, and configured to a spec you will not find off the shelf. Then we benchmarked it across the three workloads it is actually bought for: GPU rendering, fluid simulation, and AI inference. We also measured the parts most spec sheets skip, the CPU, wall power, and thermals under combined load.

This is the full report. Nothing is rounded away to flatter the result, and the weak numbers are here alongside the strong ones, because for this audience the caveats are the point.

The platform

The Pro Maestro GQ-A is a 4U rackmount server built around full-size GeForce cards. It is configurable across a range; the table below is what the platform supports, and the section after it is the exact unit we benchmarked.

The unit we tested

Every benchmark in this report was produced on this exact configuration.

Why it is designed this way

The problem is not raw GPU power, it is heat and clearance over time. A 575 W card in a slot meant for a 300 W card runs into two walls: tight slot spacing crowds the coolers so they starve each other of air, and a general-purpose server cannot move enough air to hold four of them at full clocks. The result is thermal throttling, where the card quietly drops frequency to survive, and your rendered frames or training steps slow down without an error to tell you why.

The GQ-A is designed so each of the four slots gets power delivery and directed airflow sized for a sustained 600 W draw. The thermal results later in this report show whether that holds. It does.

Test environment

Every result below was produced on the same machine, same software stack, in a single test campaign.

Positioning: where four 5090s sit against a datacenter GPU

Before the numbers, the honest framing, because the obvious comparison is to an H200.

One H200 GPU costs roughly what six RTX 5090s cost. The four cards in this server come in well under the price of a single H200. (GPU pricing moves week to week and varies by region and vendor, so treat that ratio as a current-market guide, not a fixed law.)

The H200 wins on several real axes and we will not pretend otherwise. It carries 141 GB of HBM3e on one card, far more memory bandwidth, NVLink for fast GPU-to-GPU communication, and strong FP64 performance. If you train large models, run a single model that needs more than 32 GB per card, or run tightly coupled jobs where the GPUs must talk to each other constantly, the H200 or our RTX Pro 6000 servers are the right tool, and we build those too. (Know more about Pro6000 or H200 4GPU Server / 10GPU Server)

What four 5090s give you instead, for less than the price of one H200, is over 87,000 CUDA cores against roughly 17,000, and 128 GB of VRAM spread across four independent cards. That last word matters. These cards do not share memory over NVLink, so the advantage shows up on workloads that run in parallel across separate GPUs rather than as one giant job split across them. Rendering and multi-user inference are exactly that shape. The CUDA core comparison is scoped to FP8 and graphics work; it is not a claim about FP64 or memory-bound training, where the architectures differ.

So we benchmarked the workloads that actually fit this shape.

1. Rendering

OctaneBench: GPU scaling, one card at a time

The first question anyone asks about a multi-GPU system is whether the second, third, and fourth cards earn their place, or whether the design chokes them. We ran OctaneBench at every GPU count to find out.

Four cards reach 3.94x the single-card score. Near-linear scaling like this means the design loses almost nothing to thermals or power limits as cards are added; each GPU is doing close to its full standalone work. For a render farm, this is the number that matters, because it tells you four cards in one system behave like four cards, not like three-and-a-half.

Full breakdown by GPU count

OctaneBench scores four scenes (Interior, Idea, ATV, Box), each across three kernels (info channels, direct lighting, path tracing). The columns below are the raw OctaneBench output: Ms/s is millions of samples per second measured on this hardware, ×GTX 980 is the ratio against OctaneBench's reference GTX 980, Weight is the fixed importance OctaneBench assigns each kernel (info channels 10, direct lighting 40, path tracing 50), and Score is the weighted contribution (ratio × weight ÷ 4 scenes). The totals above are the sum of every Score row.

1 GPU, total 1,738.94

2 GPU, total 3,455.13

3 GPU, total 5,157.66

4 GPU, total 6,852.73

Reading across the four tables, the per-scene Ms/s rises almost in lockstep with GPU count. Take ATV path tracing: 249.2, 494.7, 740.3, 984.4 Ms/s from one to four cards, which is 1.00x, 1.99x, 2.97x, 3.95x. The heaviest kernel scales as cleanly as the total does, which is the real signal that no single scene is bottlenecking on the design.

V-Ray Benchmark

V-Ray gives us three separate numbers: the GPU running on the CUDA engine, the GPU running on the RTX (hardware ray tracing) engine, and the CPU.

The four cards on the RTX engine reach 55,847 vpaths, against roughly 16,000 for a single 5090 on the same engine. The GPU and CPU figures use different units (vpaths versus vsamples) and are not directly comparable to each other; both are listed because a real V-Ray pipeline can use either path.

Note on the CUDA figure: across our runs we recorded two CUDA results, 44,188 and 49,966 vpaths. We report the higher, repeatable run. The spread is a useful reminder that a one-minute benchmark has run-to-run variance, and any single screenshot should be read with that in mind.

2. Simulation (CFD)

GPU rendering scales across cards because frames are independent. Simulation is the harder test, because a single fluid domain is one connected problem. We used FluidX3D Benchmark, an open-source Lattice Boltzmann (LBM) solver, and ran it twice: once on a single card, once across all four.

Single GPU

Four GPUs

What this shows

The four-card run modelled 2.1 billion cells of moving fluid, a grid 126 times larger than the single-card test. That problem needs about 111 GB of memory, split across the four cards at roughly 28 GB each. No single GeForce card holds that much, so the simulation is only possible because the four cards pool their memory and work together. It ran the full 10,000 steps and peaked at over 51 billion cell updates per second at 3,573 GB/s of combined memory bandwidth.

Honest caveat: the single-GPU and four-GPU runs use different grid sizes, so these two results are not a clean 2.8x speedup comparison. The four-card story here is capacity, not raw scaling. The value is that the machine runs a class of simulation a single card physically cannot hold in memory. For LBM specifically, throughput is governed by memory bandwidth more than raw FLOPS, which is why the bandwidth figure, not the card's theoretical 111 TFLOPS, is the one that tracks the result.

3. AI inference

This is where the four-independent-cards design either pays off or falls apart, and it is the section we tested hardest.

Method

We served eight open models on vLLM with tensor parallelism across all four GPUs, then ran a concurrency sweep, pushing from 1 simultaneous user up to 1,024, and on the strongest models, 2,048. Every level used a 512-token max output, greedy decoding (temperature 0.0), and a warmup pass. The numbers that matter are aggregate throughput (total tokens per second the server produces) and per-user throughput (what each individual user actually experiences at that load), along with the failure count.

The eight models split into two groups. Mixture-of-Experts (MoE) models activate only part of their parameters per token and run faster. Dense models run all parameters every token and are heavier. Both are included because both are deployed in the real world.

Single-user speed

With one user, the server is showing raw per-request speed.

Two models, Nemotron Cascade 30B and Qwen3-Coder-Next, show an artificially low single-user row (8 and 15 tok/s) because the first request absorbed model cold-start. Their real per-request speed appears from two users onward (188 and 136 tok/s). We flag this rather than hide it; their full tables are below.

Full concurrency tables

Every model, every concurrency level. Failed requests were zero at every level shown, on every model.

Qwen3.6 35B-A3B (MoE)

Peak aggregate: 5,335.6 tok/s at 512 users. Max healthy concurrency: 1,024.

Qwen3.5 9B (Dense)

Peak aggregate: 4,949.9 tok/s at 1,024 users. Max healthy concurrency: 2,048 (0 failures).

Gemma 4 26B-A4B (MoE)

Peak aggregate: 5,028.6 tok/s at 1,024 users. Max healthy concurrency: 1,024.

Gemma 4 E4B (MoE)

Peak aggregate: 5,678.3 tok/s at 1,024 users.

gemma-3 27B (Dense)

Peak aggregate: 2,230.4 tok/s at 128 users. Max healthy concurrency: 1,024.

gemma-4 31B (Dense)

Peak aggregate: 2,037.1 tok/s at 512 users. Max healthy concurrency: 1,024.

Nemotron Cascade 2 30B-A3B (MoE)

Peak aggregate: 6,803.5 tok/s at 512 users. Max healthy concurrency: 2,048 (0 failures).

Qwen3-Coder-Next-FP8 (MoE)

Peak aggregate: 5,700.4 tok/s at 1,024 users. Max healthy concurrency: 2,048 (0 failures).

What the inference numbers mean

Two findings stand out.

First, at 1,024 concurrent users, the MoE models stayed genuinely usable per person. Nemotron held 13.6 tok/s for each of 1,024 users, Qwen3-Coder-Next 11.7, Gemma 4 E4B 11.3, Qwen3.6 35B and Gemma 4 26B 10.3 each, Qwen3.5 9B 10.1. Reading speed is roughly 5 to 8 tokens per second, so every one of those thousand users was still getting output faster than they could read it, with zero failed requests.

Second, the 2,048-user runs. We pushed Nemotron and Qwen3-Coder-Next to two thousand simultaneous requests and saw zero failures, with Nemotron sustaining over 6,800 tok/s of aggregate throughput. That is the result we re-ran three times before we believed it. Per-user speed at that load drops to 6.7 and 5.7 tok/s, which is the point where you would add a second server rather than push one harder, but the machine did not fall over.

The dense models (gemma-3 27B, gemma-4 31B) are the honest counterweight: they top out around 2,000 tok/s aggregate and degrade to ~4.5 tok/s per user at 1,024 concurrent. Dense models are heavier, and if your workload is dense and high-concurrency, plan capacity accordingly. The MoE results are where this configuration is at its best.

A note on memory: at 32 GB per card, the model has to fit in 32 GB per GPU (with tensor parallelism splitting larger models across the four). Every model here fit. If yours needs more than 32 GB per card, this is the wrong machine, and our RTX Pro 6000 or H200 servers are the right one.

4. CPU performance

A GPU server still lives or dies on the host CPU when a workload hits a serial section, loads scenes, or feeds data to the cards. The EPYC 9554 was measured in PassMark PerformanceTest 11.

The V-Ray CPU result above (116,613 vsamples) is the rendering-relevant CPU figure; PassMark gives the general-purpose picture. For a host feeding four GPUs, the numbers that matter most are the high threaded memory bandwidth (221 GB/s) and strong multi-core integer and floating-point throughput, both of which keep the cards fed rather than waiting.

5. Power and thermals

The measurements spec sheets avoid, taken at the wall and at the sensors, in an open ambient near 25 °C.

Wall power

A combined-load draw of 3,280 W is the planning number. This is more than a standard 15 A wall circuit delivers in many regions, so the room and the power feed are part of the install, not an afterthought. We size that with you.

Temperatures under full load

This is the result the design was built to deliver. Four 575 W desktop cards held between 61 and 64 °C at full utilization, well inside their thermal limits, with no throttling. The OctaneBench 3.94x scaling figure is the proof in a different form: if the cards were throttling under combined load, that number would have collapsed toward 3.0 or lower. It did not.

6. Reliability and serviceability

A machine that runs renders and training jobs that take hours cannot fail silently mid-job. The GQ-A is built to keep running:

Redundant (1+1) power supplies mean that if one PSU fails, the other carries the full load with no downtime. Drives are hot-swap, replaceable while the system is live, alongside high-RPM cooling. Full remote management allows reboot and monitoring from anywhere. And if hardware does fail, we provide next-business-day onsite service across India through a network of over 7,500 certified technicians.

The verdict

This server is built for one thing: the most GPU performance you can buy per rupee, for work that runs across several cards at once.

The benchmarks back the design claim. GPU rendering scales at 3.94x across four cards with no thermal penalty. A 2.1 billion-cell CFD simulation that no single GeForce card can hold ran across the four cards' pooled 111 GB of memory. And on AI inference, the machine served over a thousand concurrent users at usable per-person speeds and survived two thousand simultaneous requests without a single failure, all while holding the GPUs in the low 60s °C.

It fits two kinds of teams. Studios can run it as a shared render node for V-Ray, Octane, or Redshift, or distribute its compute across an artist team so several people draw GPU power from one rackmount machine instead of four towers under four desks. AI teams can serve open models to a whole company from the same four cards, as long as the model fits in 32 GB each.

It is the wrong machine for one job: training large models, or running any single model that needs more than 32 GB per card, or jobs that depend on constant GPU-to-GPU communication. For those, NVLink and HBM win, and our RTX Pro 6000 and H200 servers are built for exactly that.

Whether you render, simulate, or serve models, this is built to perform when the deadline hits. If you have questions, or want it configured for your exact workload, our team is ready to help.

[Configure the Pro Maestro GQ-A] | [Talk to our team]

All benchmarks were run in-house on a single Pro Maestro GQ-A unit. GPU pricing references reflect current market conditions and will vary by region and over time.