When a new AI, rendering or VDI workload lands, the default move is to buy another GPU server. Composable infrastructure offers a second option: put GPUs in a shared pool and assign them to whichever server needs them. Neither is always right. This piece sets out three tests that decide it, works through an example with real arithmetic, lists the costs that belong on each side of the comparison, and says plainly when a conventional GPU server is still the better buy.
Why fixed GPU servers lose capacity
A GPU server has two hard limits. The first is the slot ceiling: Liqid’s own reference material notes that traditional servers are typically limited to 4 to 8 GPUs, so a job that needs ten cannot run on a typical box however idle the others are. The second is stranding. GPUs bought for one team sit in that team’s server, and when its demand drops they stay there, idle, while another team queues.
Both limits come from the same design choice: the GPU is welded to the CPU it shipped with. A third cost follows from it at refresh time. When the CPU platform ages out, the GPUs inside usually go with it, because separating them is more trouble than it is worth.
What pooling changes
A composable system such as Liqid’s moves the GPUs into external chassis on a PCIe Gen5 fabric and lets software attach them to hosts. Liqid sells two shapes. SmartStack shares 10 to 30 GPUs across 4 to 16 servers, so GPUs follow the work. UltraStack points up to 30 GPUs at one server, so a single job is no longer capped by a chassis. Liqid lists GPU hot-plug and hot-unplug as features, and states that allocations change with no reboots required.
The effect is that capacity is matched against total demand rather than against each box. That only pays when demand is uneven, so the decision comes down to measuring how uneven yours is.
Three tests that decide it
Run your estate through these before talking to any vendor, including us.
- •Variance test: over a typical week, are some GPU servers queuing work while others sit idle? Pull utilisation per host. A wide spread is the strongest signal for a shared pool.
- •Ceiling test: does any single job need more GPUs than the largest server you would buy? If yes, the choice is between scale-up composability (UltraStack) and a different class of machine, such as an 8-GPU NVLink system.
- •Refresh test: will you replace the CPU platform before the GPUs are worn out? If so, composability lets you refresh only the host and recompose the same GPUs to it, an approach Liqid sets out in its Matrix datasheet.
A worked example
Take five GPU servers with four GPUs each: 20 GPUs. In a busy hour, the inference service wants 9 GPUs, rendering wants 4, VDI 3 and data science 2, and the fifth server is between projects. That is 18 GPUs of demand against 20 installed.
With fixed servers, inference gets only the 4 in its own box, rendering and VDI and data science get what they need, and the fifth server does nothing: 13 GPUs working (65%), and 5 GPUs of inference demand unmet. Pooled, the same 20 GPUs serve all 18 (90%) and 2 sit free for the next job. To cover the inference peak with fixed servers you would need two more 4-GPU servers (or one 8-GPU server), each adding a host, an operating system, NICs and switch ports to the estate.
Your numbers will differ. The point of the arithmetic is to show what to measure: the gap between the sum of per-server peaks and the peak of the total. When that gap is large, pooling recovers it. When the two are close, it does not.
Reading the vendor numbers
Liqid publishes strong efficiency claims for pooling: up to 75% fewer servers for the same GPU throughput and infrastructure costs cut by up to 50%, plus, separately, up to 3.5 times greater MLPerf performance from direct GPU-to-GPU communication. On its UltraStack MI350P datasheet, Liqid labels its efficiency figures “targets, not measurements”, internal projections against multi-server deployments.
Treat claims like these as the ceiling of what is possible in a favourable estate, not a forecast for yours. The honest comparison uses your own utilisation data in the worked-example method above. Ask any supplier, us included, to show that working.
View the data behind this chart
| Fixed servers | Pooled | Difference | |
|---|---|---|---|
| GPUs installed | 20 | 20 | Same hardware |
| Demand in busy hour | 18 | 18 | Same demand |
| GPUs doing work | 13 (65%) | 18 (90%) | +5 GPUs |
| Demand unmet | 5 GPUs | 0 | No extra server |
| GPUs free | 7, stranded | 2, in pool | Reusable |
The costs that belong in the comparison
Like-for-like means counting everything on both sides. For the pooled option: the expansion chassis, any fabric switches, one host bus adapter per server, the Liqid Director management appliance, and Matrix software licences (Liqid’s MI350P system includes a three-year slot licence), plus the 36- or 60-month SmartStack support term. For the fixed option: each extra server’s CPUs, memory, NICs, switch ports, operating system or hypervisor licences, rack space and power.
Power and facility belong on both sides too. Liqid’s Gen5 EX-5410P GPU chassis has four 3,000 W Titanium supplies with Saf-D-Grid 400 V connectors and is specified for 0 to 27 °C; a fully built 30-GPU MI350P system draws about 22 kW. Our rack power density planner and cooling calculator turn those figures into rack and cooling requirements.
When to buy GPU servers instead
Pooling is the wrong answer in four situations. First, one large, tightly coupled training job: eight SXM GPUs on an NVLink baseboard are built for exactly that, and SXM modules are not PCIe cards, so they cannot be pooled this way. Compare NVIDIA DGX and Dell PowerEdge XE.
Second, steady demand: if every GPU is busy where it sits all day, there is no stranded capacity to recover. Third, very small estates, where the fixed cost of chassis, adapters and management outweighs what pooling returns; Liqid’s smallest shared-pool bundle, SmartStack 10, is 10 GPUs for up to 4 hosts. Fourth, unlisted hardware: if your servers or GPUs are not on Liqid’s compatibility list and replacing them is not on the table, conventional servers are simpler.
How to run the decision
Collect a month of GPU utilisation per host and per team, and note the jobs that were delayed or never ran because no server had enough GPUs. Use the variance and ceiling tests to decide whether pooling is in play at all, then run the numbers in our GPU pooling calculator. If it is, check your servers and GPUs against Liqid’s compatibility list, then model both options with the same demand data.
Servnet supplies both conventional GPU servers and Liqid composable systems, so we can quote the two side by side. Size the GPU count itself with the AI GPU calculator, then send us the demand profile through the Liqid page.