Multi-node, rack-scale and recommendation order

The calculator returns many configurations that fit; the order decides which one becomes the answer. The rule, an owner decision of 2026-09-08, favours fewer cards over a nicer fit percentage: a single GPU that fits always ranks first, and among multi-GPU units 2× at a tight fit outranks 4× at an optimal one.

The recommendation order

Every configuration is sorted by these keys, in this order:

1. Deployment class — single node, then multi-node, then rack-scale.
2. Lifecycle — live cards before end-of-life ones, inside each class.
3. Fewest GPUs.
4. Fit band — optimal, good, tight, then underused.
5. $/hr — the market median for the unit, as the last tie-break.

Why cards first: every extra GPU in a serving unit adds interconnect traffic, a failure domain and an operational step, and a model that fits on one card needs none of it. A tight fit is a reason to watch headroom, not to quadruple the hardware. If headroom or price matters more to you, the table's Best fit and $/hr sorts re-order the same rows; live cards stay ahead of end-of-life ones in every sort.

The list shows every single-GPU configuration that fits — never dropped by a display cap — plus multi-GPU and rack-scale units up to twelve rows in total. The table first shows the top rows; Show all (on a phone, Show every GPU that fits) lists the rest.

When a model needs more than one node

On NVSwitch systems (H100, H200, B200, B300 SXM) a serving unit can span nodes: tensor parallel inside the 8-GPU node, pipeline stages across nodes, up to 64 GPUs. The answer then reads "runs across N nodes of 8× H100", and the expanded row notes the inter-node network the layout assumes — RoCEv2 at 100–400 GbE or InfiniBand HDR/NDR. PCIe, NVLink-bridge and AMD xGMI cards stay inside one node: their units add pipeline stages over PCIe within the chassis, never across machines. See How the calculator picks TP / PP / EP for the per-fabric limits.

Multi-node estimates run in aggregated mode: prefill and decode share the same GPUs. Disaggregated prefill/decode serving — splitting the two phases across separate pools, as NVIDIA Dynamo can — is not modeled, so treat a multi-node result as the conservative layout.

Rack-scale systems

GB200 NVL36 and NVL72, GB300 NVL72 and GH200 NVL32 put 32 to 72 GPUs in one NVLink domain. They are built for workloads that need more than an 8-GPU node, and you cannot realistically rent or buy part of a rack. So they appear only when a model needs more than 8 GPUs — and for MoE models only at an expert-parallel degree above 8. For a 70B model at 8K context you will not see them; for DeepSeek V3 at BF16, Llama 3.1 405B at long context or a high user count you will. A rack-scale answer reads "runs on a GB200 NVL72 rack (N GPUs)".

Rack-scale rows sit below single-node and multi-node rows with the same card count rule inside the group, so the list still leads with the smallest deployment that works.