GPU Server Software Is Preinstalled. What Deployment Work Are You Buying?

Start with what DGX B200 already includes

In its DGX OS Software section, NVIDIA's DGX B200 guide, updated October 17, 2026, lists an Ubuntu server distribution with an optimized Linux kernel and supporting packages; DGX B200 system support packages; NVIDIA System Management (NVSM); Data Center GPU Management (DCGM); the NVIDIA GPU driver including CUDA; Docker Engine; NVIDIA Container Toolkit; NVIDIA Networking OpenFabrics Enterprise Distribution for Linux (DOCA-OFED); NVIDIA Networking Software Tools (MST); and cachefilesd for cache storage. NVSM provides node health monitoring and alerts; DCGM supports GPU administration and wider management.

That is a meaningful supplied product state. The purchasing question is what the offer does with those capabilities in the customer's environment. A list of installed tools identifies software available on the server. It does not specify the customer's selected destinations, operating arrangement or required evidence of an integrated result.

Ask the supplier to identify the actual delivered software release and included setup before pricing additional work. A proposal to install software should explain the change it supplies beyond the delivered product and any setup already ordered. Preinstallation alone is no reason to commission a rebuild or buy a second copy of the same setup service.

References: [N1]

First boot has its own defined scope

NVIDIA's B200 First Boot Setup page states that NVIDIA partner network personnel or NVIDIA field service engineers install the system at the site and perform first boot. Its setup topics include initial administrative accounts and the primary network interface. The page points to the DGX OS 7 guide for the setup detail. That model-specific assignment must remain in the purchasing comparison; it cannot be reassigned to a general physical contractor by calling the task software installation.

Three outputs help explain the difference. The supplied product has an identified stack and its applicable product setup. Customer-specific configuration applies the selected environment and operating choices. Agreed verification then provides evidence about the particular configured result the customer intends to accept. An offer may combine these outputs, split them among providers or leave part with the customer's team. Their names alone do not establish what is included.

First boot can therefore be both real deployment work and narrower than the requested cluster result. Equally, some customer settings may already be covered by the product-installation package. Obtain the actual inclusion before adding another provider's line for the same work.

References: [N2]

Customer choices determine the configuration being bought

The DGX OS 7 Initial Setup guide, updated September 30, 2026, describes a primary network interface, DHCP or static addressing, name-server information, a domain name and a host name. Those objects make the distinction concrete: installing networking software cannot select the customer's approved network identity on the customer's behalf.

The same version's System Configurations chapter covers site proxies, Docker proxy settings and user privileges. Its NFS-caching example depends on an accessible NFS server and export, with the server and export path supplied by the network administrator. Installed cache software does not identify the intended remote dataset. These examples illustrate choices to resolve with the appointed software and network/storage teams; they are not a required architecture for every cluster.

In the DGX OS 7 appendix's NGC container example, a registry, repository and tag identify the selected image. The buyer's requested application environment therefore needs more definition than the presence of a container engine. For the initial purchase, ask which application environment the software team is being engaged to prepare and demonstrate.

Consider how a changed requirement changes the purchase. A customer selecting a different storage service needs the software proposal to address that selected service, rather than inherit an unrelated NFS example. A customer requiring traffic through its proxy needs that environment reflected in the proposed configuration. A customer allocating servers independently asks a different operating question from one requiring a workload to span several servers. The appointed software team must define the applicable configuration and verification for the chosen model; a generic cluster label leaves that result undecided.

References: [N3][N4][N5]

Compare two offers for the same four servers

Consider a fictional purchase of four DGX B200 servers. Both offers identify the same hardware configuration and preinstalled stack. Both identify a product-installation and first-boot package to be performed through the NVIDIA channel specified for B200. These are hypothetical package descriptions; the actual supplier must confirm the assigned installation party's eligibility.

Offer A ends with a defined physical/product-installation package. Its proposed return identifies the equipment, included physical checks and product-setup record. The customer would appoint its own software team for any additional customer-specific configuration and verification it requires. A has a clear endpoint if that is the division of work the buyer wants.

Offer B includes the same starting package and additionally names the separately appointed software team's work against the customer's selected network, storage service and operating model. Its proposed output identifies the resulting configuration and the evidence required for the customer's agreed acceptance decision. Merely repeating DOCA-OFED, Docker and DCGM in B's software list would not explain that additional work; the named customer configuration and verification output do.

Suppose the buyer wants an agreed workload to use the four servers and the selected shared dataset. B should identify how its software team's proposed verification will cover that intended use, which configuration it concerns and what results and exceptions the team will return against agreed criteria. Four separate node-health reports would answer a narrower question. No verification has been performed in this example, and the proposal supplies no method, threshold or predicted workload capacity.

The offers become comparable when the buyer can see who supplies the additional result and whether it is needed. If an existing customer team already owns that work, A may fit the intended purchase. If the buyer expects the supplier arrangement to deliver the configured environment and its agreed evidence, A leaves that expectation outside its stated output. B addresses a wider requirement only to the extent its actual software scope defines it.

Make the acceptance output match the intended use

Define the question that the software result must answer before comparing a commissioning line. Is the purchase meant to establish configured individual servers, their connection to selected customer services, or an agreed use across the server group? The answer determines the relevant configuration and the evidence to request. A broad production-ready label leaves all three possibilities open.

The proposed acceptance output should connect the identified system and software configuration to the agreed use, the verification coverage and criteria, the actual returned evidence and unresolved exceptions. A report about one configured node cannot silently stand for a different configuration or a wider population. Likewise, an equipment inventory or physical installation record can support the next stage without answering an application or multi-server operating question.

This is also how to avoid buying work twice. Have the product supplier identify the setup already included, the customer's software team identify the result it will provide, and any additional provider describe the remaining gap. There may be no gap. There may instead be a specific integration task and verification output worth buying. A software inventory cannot settle that commercial question by itself.

Later operating support is another purchase. An assignment to configure and verify the initial environment does not define the subsequent operating service. The related GPU Cluster Management Handoff article addresses the later transition to the receiving operator; that decision should not be hidden inside an initial setup label.

Connect the physical installation to the appointed software team

Once the intended software result is defined, identify the physical installation output that team needs to receive. The agreed equipment identities, positions, connection records, included physical checks and open items provide a basis for coordinating the stages. The software team can then identify the inputs it still needs, while the physical proposal retains a defined endpoint.

Leviathan's complete physical deployment service is the place to discuss receiving, rack integration, agreed hardware QA, onsite installation, cabling and physical records. For this decision, bring a nonconfidential equipment summary, the product supplier's installation boundary and the separately appointed software provider's required interface. The inquiry can establish what physical work remains and what that provider needs from its handoff.

Software commissioning, licensing and cluster administration require their separately appointed providers. For DGX B200, the named product-installation and first-boot requirement also remains with its specified channel. Use the project inquiry to discuss the physical package and those interfaces, with the included work and returned output stated plainly.

References: [N2]