HGX vs DGX: What is the Difference?

Both are NVIDIA. Both use the same GPUs and the same 8-GPU HGX baseboard with NVSwitch. The difference is who builds the rest of the server and who supports it.

• HGX is a reference platform. NVIDIA supplies the GPU baseboard to server manufacturers — Dell, Lenovo, Supermicro, GIGABYTE, HPE and others — and each builds it into their own chassis with their own host CPUs, memory, storage, networking, power and cooling design. You buy from the OEM; the OEM supports it.
• DGX is NVIDIA’s own system. NVIDIA designs the whole server around the same baseboard, fixes the configuration, ships it with NVIDIA’s software stack, and supports it directly.

It is not a performance decision at the GPU level. Eight B200s are eight B200s. It is a decision about configurability, procurement path, support model and software.

HGX is best understood as a component and a specification, not a finished product. NVIDIA delivers the baseboard carrying eight SXM accelerators wired together by NVSwitch, and publishes the electrical, thermal and mechanical envelope around it. Everything else is the integrator’s design decision:

• Host platform — CPU vendor and SKU, system memory capacity, PCIe topology.
• Networking — how many NICs, which generation, InfiniBand or Ethernet, and where the storage and management ports sit.
• Chassis and cooling — air-cooled builds (commonly 8U or 10U) or liquid-cooled cold-plate builds (commonly 4U), which drives rack density.
• Storage — NVMe capacity and layout.
• Service — warranty tier, on-site response, integration and rack-and-stack.

Because several OEMs build to the same reference, the same GPU generation reaches the market through several independent supply chains. That is the practical advantage: when one integrator’s lead time is long, another may be short. The trade is that you have to compare builds, because the servers genuinely differ.

DGX is NVIDIA’s turnkey system: a fixed, validated configuration around the same HGX baseboard, engineered, built and supported end-to-end by NVIDIA. The proposition is that every layer has been chosen and tested together.

What comes with it:

• A validated hardware configuration — you are not making CPU, NIC or cooling choices, which removes a class of integration risk.
• NVIDIA’s software stack — the DGX operating environment plus NVIDIA’s enterprise AI software and cluster management tooling, supported as part of the system rather than assembled by you.
• NVIDIA support, single-vendor, for hardware and the supported software together.
• A reference path to scale — DGX systems have a published multi-node architecture, so a cluster design follows a documented blueprint rather than a bespoke one.

DGX also extends upward into rack-scale: NVIDIA’s Grace Blackwell rack systems follow the same "designed and validated as a whole" philosophy, delivered as an integrated rack.

The same silicon, two procurement models. Read this as trade-offs, not as a winner.

This is where the abstract difference becomes a real one. Because HGX ships through multiple OEMs, a given GPU generation has several independent order books, each with its own allocation, backlog and delivery window. Buyers who are flexible about integrator frequently find capacity months earlier than buyers who are not.

DGX runs through a single channel with NVIDIA-controlled allocation. That brings consistency and a known configuration, but it means less room to route around a queue.

The honest advice for anyone with a deadline: decide which of your requirements are hard (cooling type, rack depth, power per rack, network fabric) and which are preferences (a specific chassis vendor). Then let availability settle the preferences. Delivery timing has moved more buildouts than specification has.

The support model is the second real difference.

With DGX, hardware and the supported software stack come from the same vendor. When something breaks in a way that could be either, there is no vendor boundary to argue across. That has genuine value for teams without a deep infrastructure bench.

With HGX, hardware support is the OEM’s and the software stack is yours to choose and operate. Teams that already run Kubernetes, Slurm, their own observability and their own image pipeline usually prefer this — the DGX stack is a benefit only if you were going to use it. Teams standing up their first cluster often underestimate how much work that layer is.

A reasonable heuristic: if you have an infrastructure team that already runs production systems and has opinions about the stack, HGX gives you more room and more supply. If AI infrastructure is new to your organization and you want it working rather than assembled, DGX is doing real work for you.

Work through it in this order:

• Facility constraints first. If you need liquid cooling, a specific rack depth, or a particular power envelope per rack, that eliminates options before anything else does.
• Then supply. If your timeline is tight, the OEM route’s multiple order books are an advantage worth a lot.
• Then software and support. Be honest about whether your team wants to own the stack.
• Then integrator preference. Existing vendor relationships, service contracts and spares strategy are legitimate tiebreakers.

One related term worth knowing: MGX is NVIDIA’s modular reference design used for rack-scale systems, the same idea as HGX applied a layer up. And note that DGX systems from earlier generations turn up on the secondary market, which is a separate consideration from new supply.

Pricing for every configuration is quoted on request — see NVIDIA GPU server pricing for what moves the number, and browse the GPU catalog for the builds available through Pantheon.