The HPE Apollo 6500 is HPE's answer to the question many UK teams ask once they decide they need serious GPU compute: do we have to buy an NVIDIA DGX, or can we get an eight-GPU server from a vendor whose support, warranty and procurement we already trust? The 6500 is that alternative, a dense, eight-accelerator node built and supported by HPE. This is not a comparison of GPU silicon; the chips inside can be the same. It is an engineering and ownership view of the platform itself, how the eight-GPU baseboard is wired, what feeds it, and how the total cost of a 6500 node stacks up against a DGX-class system over three years.
Eight GPUs on a baseboard, not eight cards
The defining feature of the Apollo 6500 is that it hosts up to eight GPUs on an NVLink-connected baseboard rather than as independent PCIe cards. That is the same architectural approach as a DGX: the GPUs are joined by NVLink and NVSwitch into a high-bandwidth fabric so they can share data and behave, for large training jobs, more like one very large accelerator. As we explain in Dell vs HPE vs Lenovo, the major OEMs build to NVIDIA's baseboard designs, which is why an Apollo 6500 and a DGX can carry the same GPUs yet differ in everything around them.
That distinction, baseboard versus cards, is what makes the 6500 a genuine peer to DGX rather than just a server with GPUs in it. The NVLink fabric is the thing that matters for multi-GPU training, and the 6500 provides it. The selection of the specific accelerators is a separate decision, made from our GPU accelerators range, and is largely common across platforms.
What feeds eight GPUs: hosts, scratch and fabric
Eight GPUs are only as useful as the system feeding them, and the 6500 is engineered around that. Dual host CPUs marshal the work, prepare data and run the software stack; the CPU-to-GPU balance has to be right so the processors are not a bottleneck on data preparation. Local NVMe provides high-speed scratch storage so training data and checkpoints sit close to the GPUs rather than crossing the network for every read.
Then there is the network fabric. A single GPU node is rarely the whole story; it usually connects to a high-speed, low-latency fabric, often RDMA-capable Ethernet or InfiniBand, so it can either pull data from shared storage or join other nodes into a larger cluster. The 6500 carries the high-bandwidth networking to do that, sized from our network cards range. The art of the build is keeping all four elements, GPUs, host CPUs, scratch NVMe and fabric, in balance so none starves the others.
- •Up to eight GPUs on an NVLink/NVSwitch baseboard - a DGX-class topology
- •Dual host CPUs sized so data preparation never bottlenecks the GPUs
- •Local NVMe scratch keeps training data and checkpoints close to the accelerators
- •High-speed RDMA fabric to feed from shared storage or scale across nodes
Why teams choose Apollo over DGX
If the GPUs can be identical, why pick the 6500? The answer is almost always the operating model rather than the silicon. A DGX is supported by NVIDIA as an appliance; an Apollo 6500 folds into the HPE estate you may already run, the same vendor, the same support contracts, the same firmware and management tooling (iLO), the same procurement and warranty relationships. For an organisation standardised on HPE, that consistency reduces operational friction and risk.
There is also the question of integration. Buying GPU compute from your existing server vendor means it lives under the maintenance, monitoring and lifecycle processes you have already built, rather than as a one-off appliance with its own support path. That is the core appeal of the Apollo 6500, and it is distinct from the silicon-level comparisons of which GPU to buy; it is about who stands behind the box and how it fits your world, the same ownership lens we apply across HPE Apollo platforms.
The three-year cost picture
GPU servers are a large capital outlay, so the comparison that matters is total cost of ownership over a realistic life, typically three years, not just the purchase price. An OEM platform such as the Apollo 6500 and a DGX-class node both carry the dominant cost of the GPUs themselves, which is broadly common, plus the platform, support, power and facilities around them, which is where they diverge.
The honest position is that no single answer fits everyone: the balance depends on negotiated hardware pricing, the value you place on consolidating support under one vendor, your power and cooling costs, and existing estate standards. What we do is model those elements side by side for the customer's actual situation rather than quote a generic verdict. The illustrative bars below show the shape of such a comparison, dominated by hardware with meaningful support and power lines, and we build the real version during an Apollo design engagement.
Where the 6500 fits
The Apollo 6500 suits teams that need DGX-class, eight-GPU training or inference performance but want it delivered, supported and maintained as part of an HPE-standard estate: enterprises with existing HPE relationships, research groups that need OEM warranty and serviceability, and any organisation for whom a single, familiar support path is worth as much as the raw compute.
It is less compelling if you specifically want NVIDIA's appliance experience and reference software stack, or if your needs are met by a smaller number of PCIe GPUs in a standard server, in which case the baseboard density is more than you need. As always the platform follows the workload and the operating model; we work through that choice, and how it compares with other vendors, in our Dell vs HPE vs Lenovo analysis and in configuring the Apollo node itself.