GPU Expansion: Rack, Row or Scalable Unit?

Separate the architectural unit from its rack placement

NVIDIA's DGX B200 SuperPOD reference architecture, updated September 2, 2026 and checked October 19, 2026, uses scalable units, or SUs, of 32 DGX B200 systems. It describes placing two systems per rack while allowing the layout to change for local data center requirements. The SU count and the placement description answer different questions.

The architecture page identifies DGX systems, networking, management nodes and storage as constituent parts. Its management-rack example includes switches, management servers, storage arrays and UFM appliances, with sizes and quantities varying by model. A drawing of compute racks therefore does not identify the complete purchase.

Use the SU designation with its named architecture. It is neither a universal rack count nor a shipping container. A rack identifies a physical enclosure; a row groups locations in a facility. Neither label alone establishes the architecture or the included supporting systems. These reference facts help a buyer interpret scope; they supply no project design, partial-SU approval or deployment schedule.

References: [N1][N2]

Distinguish three purchases that can all be called expansion

The first purchase adds identified servers to an existing architecture already qualified for those additions. Here the buyer is relying on existing infrastructure and services rather than buying a self-contained new cluster. The responsible architecture, network, storage and platform owners must identify the exact additions covered by that qualification and the existing resources they will use. A server installation quotation can then describe the bounded physical change. Existing infrastructure does not establish unlimited expansion capacity.

The second purchase installs a physical row while shared support systems remain pending. Its useful result might be specified equipment mounted in agreed positions, the included IT cabling installed and identified, and physical records handed to a receiving team. That result can have value as a completed physical package. Calling it an added row of capacity, however, leaves unanswered whether the row has the services needed for the intended operation.

The third purchase commissions a separately designed architectural increment. The buyer needs a defined target configuration, its physical scope, the supporting services it will use and the system-level result to be accepted by the appointed technical owners. Some services may be shared with an existing installation where the actual design permits; a separately designed increment does not automatically require a duplicate management or storage stack. Equally, naming an SU does not establish that those shared services are included.

Choose which result the phase is meant to deliver before selecting the quotation's pricing unit. These purchases can contain similar server racks while leaving substantially different work and dependencies outside the price.

Follow the interfaces beyond the row

NVIDIA's Network Fabrics chapter distinguishes compute, storage, in-band management and out-of-band management networks. It also describes in-band connections between compute and management nodes and access to cluster services and an NFS data tier. Those roles explain why a visually complete row can still depend on equipment or services elsewhere.

For the compute fabric, identify the included server-facing connections and the network equipment and further connections on which the intended communication depends. If an endpoint belongs to another row or a later package, identify that dependency. The last cabinet in a row is a location boundary, not evidence that the required fabric ends there.

For storage, separate the physical connection from the service reached through it. Installing the row's storage-facing cables does not supply an array, an accessible dataset or the platform team's accepted storage configuration. The buying question is which storage result the phase includes and which appointed owner provides the rest.

For provisioning and management, NVIDIA's Software chapter identifies Base Command Manager's provisioning and administration role. Physical access to a management network and delivery of the management service are separate dependencies. A quote that includes cabling can leave management nodes, configuration and provisioning work with another package. Ask the platform owner to identify the services required for the requested first-phase operating state.

Trace these interfaces against the actual design and offer. The purpose is to locate dependencies crossing the purchased boundary, rather than infer a supported configuration from the row layout.

References: [N3][N4]

Work a two-phase offer with shared systems arriving later

Consider a fictional two-phase offer in which the first server racks arrive for Row A in phase one, before the shared management/storage package assigned to phase two. The remaining server racks are also assigned to phase two. The buyer nevertheless requests operating capacity from Row A at the phase-one handoff. The offer identifies no interim management or storage provision. No server count or topology is stipulated; this is a purchase-scope example, not a supported partial-SU design.

An independently bounded physical milestone could cover mounting the identified phase-one equipment, completing the expressly included physical connections and returning the agreed position, endpoint and open-interface records. The provider and receiving owner would first need to confirm that this package has its own resolved prerequisites and a useful stopping point. A connection awaiting phase-two equipment must retain that pending status. The milestone can describe precisely what physical result is included without representing the whole architecture as complete.

The requested operating-capacity milestone raises a different question. The shared management/storage package is part of the final target but falls outside phase one. Nothing in the offer establishes how its required services will be available for the earlier result. Finishing every included Row A installation task would not fill that scope gap. This is a finding about what the offer establishes, not a software test result or a prediction of how the servers would behave.

The buyer has two meaningful alternatives. Retain phase one as a physical installation purchase and plan operating acceptance against the remaining dependencies. Or ask the architecture, storage and platform owners to define a revised first-phase operating result and the complete provision needed to reach it. Their assessment may require changing the allocation of shared equipment or using specifically qualified existing services. Bringing a package forward is a design and scope decision, not a consequence of dividing the final rack count.

The value of the early physical purchase is the work it actually completes for the next team. It should be judged against that result, without assigning it capacity that remains dependent on phase two.

Compare per-rack and per-cluster prices against the same result

A per-rack rate can be a sensible way to price repeated mounting and cabling work. A per-cluster price can group a broader package. Neither denominator establishes what is included. A cluster quotation can still assume customer-provided storage or management, while a rack quotation can include specifically identified shared connections.

Ask each provider to describe the phase-one output and the final output against the same target configuration. Identify the shared equipment, physical interfaces and services included in its price, those already provided elsewhere and those still unassigned. Compare the complete set of purchases needed for your chosen milestone. Avoid treating an omitted dependency as a saving or purchasing an already-included activity again.

In the fictional offer, dividing the management/storage package's price between the two rows would allocate expenditure. It would not make half of its required function available before delivery. If the requested phase-one result depends on that package, the buyer must resolve the whole relevant dependency even when internal accounting spreads its cost across phases.

This also changes how to assess an early installation offer. A lower first-phase price may correctly buy less progress toward operating capacity while still buying useful physical work. Establish that difference explicitly before deciding whether the offers are alternatives for the same need.

Bring the required phase result to the physical deployment inquiry

Use Leviathan's Complete Physical Infrastructure Deployment service to discuss the physical stages you want combined: receiving, rack integration, agreed hardware QA, onsite installation, IT cabling and the physical handoff. Share the proposed configuration, rack or row boundaries, allocation of shared equipment between phases, appointed suppliers and the output needed at each handoff. Identify the interfaces that continue into another package. Actual methods, resources, checks and availability are confirmed for the engagement.

Name the architecture/OEM owner for configuration decisions, network and storage owners for their services, the platform owner for provisioning and operating acceptance, and facility owners for site readiness and specialist interfaces. Full system/software commissioning is separate from the physical package; facility electrical construction and liquid-side work remain outside this service. A physical scope does not confer OEM installation authority or licensed engineering approval.

The linked service and its project inquiry provide the next step. State whether you need identified servers installed into an already-qualified architecture, a bounded row installation, or physical delivery supporting a separately designed increment. That gives the team a concrete result to discuss while the appointed technical owners retain the architectural and operating decisions.

References: [L1]