Home · Servers for high performance computing
Workload guide
Servers for high performance computing
HPC buying is cluster buying: the node is a fraction of a machine whose real specification is the aggregate. This guide covers the node choices in our range — GPU-dense systems and high-core hosts — and how cluster orders are structured.
Two kinds of HPC node
Accelerator nodes carry the floating-point load: the SR675 V3 is positioned by its line for AI training and HPC in one breath, because the same eight-GPU topology serves both. CPU nodes carry the rest — the high-core EPYC and Xeon hosts in the rack range, where core count per rack unit and memory bandwidth per core decide throughput on simulation and modelling codes.
The ratio between the two is the cluster design. Codes that port to accelerators concentrate budget in GPU nodes; codes that do not want CPU nodes with the fastest memory subsystem the brief can carry. State the code or the code class in the inquiry — it decides the ratio before any model is named.
Clusters are programmes
A cluster order freezes one node configuration and repeats it, with the interconnect and staging written into the quote. Our programme route handles that shape: sample units against the frozen configuration, then the rollout, with serial numbers available per unit before shipment.
Benchmark with your code, or someone else's marketing
HPC purchases live and die on benchmarks, and the only benchmark that predicts anything is your own code on the candidate configuration. Vendor figures and standard suites rank machines for workloads that are not yours; core designs, memory subsystems and accelerators trade places depending on the code's actual behaviour. A serious cluster inquiry therefore plans an evaluation: one node, your code, your dataset, measured against the incumbent system.
That evaluation unit is a normal purchase here — quoted, configured, and returnable to the programme as its first production node when it proves itself. What it should never be is skipped: a cluster is the most expensive purchase in this catalogue, and it deserves the one experiment that settles its central question.
The interconnect is not an accessory
Nodes are the visible half of a cluster; the fabric between them decides how much of their aggregate power a parallel code can actually use. tightly coupled codes spend a large share of their runtime communicating, and a fabric chosen as an afterthought taxes every run for the cluster's whole life. The brief should name the code's coupling honestly — loosely parallel work forgives modest fabrics, tightly coupled work forgives nothing.
Our range covers compute and storage rather than fabrics, and this guide says so plainly so the cluster budget reserves the fabric's share before the nodes consume it. A cluster plan that prices nodes first and fabric with what remains has the order backwards.
The acceptance test
Agree the acceptance measurement before the cluster ships: your code, your dataset, a stated figure the rollout must match. Programmes with an acceptance test written down argue about numbers for a day; programmes without one argue about impressions for a month.
Questions buyers ask
Can HPC nodes and GPU training nodes be the same purchase?
Often yes — the SR675 V3 class serves both. State both workloads and the node is configured for the heavier one.
Do you supply cluster networking?
Our range is compute and storage; name the fabric in the brief and we will confirm what can be covered alongside the nodes.
Price a configuration like this
Send the model name, your target configuration and the delivery destination. We reply with a configuration-matched quote and the checks to run before shipment.