Two teams buy “the same eight H100s” and end up with codebases that are not remotely portable to each other. The reason is not the silicon. It is what sits around the silicon — and how much of it leaked into the code.

That is the part the spec-sheet comparison misses. Put a DGX H100 next to an HGX H100 platform and the headline numbers look almost identical: eight SXM GPUs, NVLink and NVSwitch fabric, the same HBM stack. From that vantage the choice reads as a procurement footnote. It is not. DGX and HGX represent two different contracts with your software: one is a fully integrated system NVIDIA defines end to end, the other is a baseboard reference design that an OEM or cloud builder wraps in their own platform. The decision you are actually making is which stack of driver versions, topology assumptions, and vendor-specific memory patterns your team will build against for the next few years.

What is the actual difference between DGX and HGX?

DGX is an appliance. NVIDIA specifies the chassis, the CPUs, the NICs, the storage layout, the firmware, and — crucially — the software image (DGX OS, a validated driver and CUDA stack, and the NGC container ecosystem tuned to that exact box). You buy a known-good system where the topology is fixed and NVIDIA owns the integration.

HGX is a GPU baseboard — the SXM GPUs plus the NVLink/NVSwitch fabric — that NVIDIA sells to partners. Supermicro, Dell, cloud providers, and others integrate that baseboard into their own server designs, pick their own host CPUs and NICs, and ship their own supported driver and OS combinations. Most of the “8×H100 cloud instances” you rent are HGX-derived platforms, not DGX.

So the two are not competing products in the usual sense. One is the reference design; the other is one specific, fully-integrated realization of it. That distinction is exactly why treating them as interchangeable spec-equivalent boxes creates trouble downstream.

Dimension	DGX (integrated appliance)	HGX (baseboard reference design)
Who integrates it	NVIDIA, end to end	OEM / cloud builder / you
Host CPU, NIC, storage	Fixed by NVIDIA	Chosen by the integrator
Software image	DGX OS + validated CUDA/driver stack	Integrator- or self-managed
Topology (PCIe, NUMA, NVLink)	Known and documented per model	Varies by chassis design
Support boundary	Single vendor (NVIDIA)	Split across GPU + platform vendor
Portability posture	Easy to over-fit to the appliance	Neutral if you keep it neutral
Best fit	Fast standardisation, one known target	Flexible fleets, multi-vendor futures

How does the platform choice affect your software stack?

Here is the mechanism that spec comparisons hide. When you standardise on a DGX appliance, the fastest path to good performance is to lean on everything NVIDIA validated for that box: the specific CUDA and cuDNN versions in the DGX image, the NGC containers tuned to its topology, NCCL collective patterns that assume the DGX NVSwitch layout, and memory-placement decisions that assume the DGX NUMA and PCIe map. None of that is wrong. It is often genuinely faster. The catch is that each of those choices is an assumption about this platform, and assumptions have a way of hardening into code.

A concrete example: NCCL will happily auto-tune to the interconnect topology it finds. If your multi-GPU code, launch scripts, and process-placement logic were written and profiled against a DGX’s fixed NVSwitch fabric, they can encode expectations — rank-to-device mappings, a hard-coded number of NVLink hops, assumptions about which GPUs share a NUMA node — that simply do not hold on a differently-wired HGX chassis from another vendor. The code runs, but the collective performance falls off, and nobody can immediately say why. The same trap applies to CUDA graph capture tuned to one memory layout, or a container that pins to a driver version the target platform does not ship.

This is the portability debt the platform choice quietly accrues. It rarely shows up as a build error. It shows up months later, when someone wants to run the same workload on a different vendor’s HGX box, a cloud instance, or a non-NVIDIA accelerator, and discovers the “port” is really a re-architecture. If you want the deeper mechanics of why moving a workload across hardware is harder than recompiling, our explanation of what it actually means to move a workload to new hardware unpacks that in general terms.

None of this means DGX is a trap. It means the integration convenience and the portability posture are two sides of the same coin, and you should choose knowing which side you are optimising for.

Which choice preserves cross-vendor portability?

Neither platform forces lock-in, and neither guarantees portability. What matters is the discipline you apply on top of whichever you pick. That said, the two platforms make different behaviours the path of least resistance.

DGX makes appliance-specific optimisation the easy path, because everything is pre-tuned to one topology — so portability erodes unless you actively fence off the platform-specific assumptions. HGX, especially across a mixed fleet, forces you to confront topology variation earlier, which tends to keep the accelerated-computing stack more architecturally neutral simply because it has to run on more than one wiring.

The measurable outcome we care about is what a future port costs. When a team keeps its stack neutral at platform-selection time — abstracting topology discovery, not hard-coding driver versions, keeping vendor-specific kernels behind a swappable interface — a move to a second target becomes a targeted re-tuning pass rather than a rewrite (an observed pattern across our GPU engagements, not a benchmarked figure). When those assumptions were baked in, the same move can mean re-architecting the data-movement layer. That gap — re-tune versus re-architect — is the real cost the DGX-vs-HGX decision sets in motion.

If a vendor-neutral posture is your explicit goal, it is worth reading what a genuinely hardware-agnostic GPU compute stack actually requires — because “neutral” is an engineering discipline, not a purchasing decision.

How do topology and NVLink layout shape performance-portable code?

The interconnect is where the two platforms diverge most sharply for a systems engineer. On a DGX, the NVLink/NVSwitch topology, the PCIe root complexes, and the NUMA domains are fixed and documented — you can profile once and trust the map. On an HGX-derived server, the same GPUs might sit behind a different PCIe switch arrangement, a different NUMA partitioning, or a different NIC-to-GPU affinity depending on how the OEM laid out the board.

Performance-portable code treats topology as discovered, not assumed. That means querying the actual NVLink connectivity at runtime rather than hard-coding it, letting NCCL detect the fabric instead of overriding it with hand-tuned rings built for one box, and driving process and memory placement from the machine’s real NUMA map. The reason NUMA and cache-domain awareness matters so much for GPU data movement is a topic in its own right; our piece on ACPI SRAT and L3 cache as a NUMA domain explains why the host-side memory topology quietly governs how fast data reaches the GPU.

The practical rule: any parameter that describes this specific platform’s wiring should be read from the system, not written into the source. Do that, and the same binary behaves sensibly on DGX and on a range of HGX boxes. Skip it, and you have written code that is fast on exactly one machine.

When should you standardise on DGX versus build on HGX?

This is an engineering-cost decision, not a performance ranking. The following rubric captures how we frame it in practice.

Lean toward DGX when:

• You want one known-good target and value time-to-productive over fleet flexibility.
• Your team is small and does not want to own driver/OS/firmware integration.
• The workload will live on this platform for its whole lifecycle, with no realistic multi-vendor future.
• You need NVIDIA’s single-vendor support boundary for procurement or compliance reasons.

Lean toward HGX when:

• You are building or renting a heterogeneous fleet and expect topology to vary across nodes.
• You anticipate a future port — to another vendor’s box, to cloud, or to non-NVIDIA accelerators.
• You already have platform-integration capability in-house and want control over host, NIC, and driver choices.
• Cost-per-node at scale matters and you can source HGX platforms competitively.

Whichever way you lean, the portability-preserving discipline is the same: abstract topology, don’t pin driver versions in application code, and keep vendor-specific kernels swappable. The platform makes one path easier, but it never makes the other impossible. For a complementary read that weighs the same two platforms from the inference-deployment angle specifically, see our companion piece on choosing the right NVIDIA platform for your inference deployment; and if your workload is physics- or RF-simulation rather than inference, DGX vs HGX for GPU simulation workloads covers that variant.

You can see how we approach platform selection and the broader accelerated-computing stack on our GPU engineering work.

FAQ

What does working with dgx vs hgx involve in practice?

DGX is a fully integrated NVIDIA appliance — chassis, CPUs, NICs, firmware, and a validated software image all defined by NVIDIA. HGX is the underlying GPU baseboard (SXM GPUs plus NVLink/NVSwitch fabric) that OEMs and cloud builders integrate into their own servers. In practice the difference is not raw performance but who owns the integration and, therefore, which software-stack assumptions end up in your code.

What is the actual difference between an integrated DGX system and an HGX baseboard reference design?

A DGX gives you a single, fixed, single-vendor-supported target with a known topology and a pre-tuned driver/CUDA stack. An HGX platform varies by integrator: the host CPU, NIC, storage, PCIe/NUMA layout, and supported drivers are chosen by whoever built the server. DGX trades flexibility for a known-good box; HGX trades turnkey convenience for control and fleet flexibility.

How does choosing DGX or HGX affect the software stack and driver assumptions your GPU code depends on?

Standardising on a DGX makes it easy to lean on appliance-specific validated CUDA/cuDNN versions, NGC containers, and NCCL patterns tuned to that exact NVSwitch and NUMA topology. Those choices are fast but encode assumptions about one platform. On HGX, especially across mixed hardware, you are pushed to keep the stack more neutral because it must run on more than one wiring.

Which platform choice better preserves cross-vendor portability, and why does that matter beyond the initial deployment?

Neither platform forces lock-in, but DGX makes appliance-specific optimisation the path of least resistance, so portability erodes unless you actively fence off platform-specific assumptions. HGX tends to keep the stack more neutral. It matters because a future port to another vendor, to cloud, or to a non-NVIDIA accelerator costs a targeted re-tuning pass if the stack stayed neutral — and a full re-architecture if it did not.

How do system topology and NVLink layout differences between DGX and HGX influence performance-portable code design?

DGX has a fixed, documented NVLink/NVSwitch and NUMA topology you can profile once and trust; HGX-derived servers vary by OEM board design. Performance-portable code treats topology as discovered at runtime — querying real NVLink connectivity, letting NCCL detect the fabric, and driving placement from the actual NUMA map — rather than hard-coding parameters that describe one machine’s wiring.

When should a team standardise on DGX appliances versus building on HGX, from an engineering-cost perspective?

Lean toward DGX when you want a single known-good target, have a small team that will not own integration, and see no realistic multi-vendor future. Lean toward HGX when you expect a heterogeneous fleet, anticipate a future port, have in-house integration capability, or need competitive cost-per-node at scale. Either way, the portability discipline — abstract topology, don’t pin drivers in application code, keep vendor-specific kernels swappable — is the same.

The honest closing question is not “which box is faster” — under sustained real load the eight-GPU numbers converge. It is: on the platform you standardise on, will code that already runs well here need only a re-tuning pass to reach a second target, or a rewrite? Answer that before you sign, because platform selection is the baseline input to any later cross-platform performance characterisation — the failure class here is portability debt booked silently at purchase time.