NVIDIA B200 Server Specifications: What Belongs in the Requirement

Use NVIDIA's figures to establish a verified baseline, then use the chosen OEM's exact model documentation for the solicitation and site plan. Do not copy one appliance's dimensions or power values onto every B200 server.

At the lowest level, B200 is the GPU generation. HGX B200 integrates eight GPUs with high-speed interconnect as a platform that OEMs use inside servers. The OEM server adds the host architecture and support boundary. DGX B200 is NVIDIA's appliance with a defined chassis, host, network and software configuration. A rack or cluster adds fabric, storage and management.

Procurement documents should name the level being purchased. If a market survey requests “four B200s,” suppliers may interpret four GPUs, four eight-GPU servers or four racks. Write the quantity as “four eight-GPU servers based on NVIDIA HGX B200, or equal,” then define “equal” through measurable characteristics and interfaces.

Use the current NVIDIA enterprise reference architectures to identify supported patterns and the AI Enterprise support matrix to check platforms. Then require the bidder to identify the exact OEM manufacturer, model, revision and support entitlement.

The NVIDIA enterprise reference-architecture appendix lists HGX B200 as an eight-GPU platform with up to 1.44 TB of total GPU memory and notes a GPU power configuration up to 1,000 watts. These are useful baseline facts.

Do not turn peak AI-performance marketing numbers into acceptance criteria unless the agency can reproduce the associated workload, software and precision. Instead, specify minimum usable memory, required precision support and the representative benchmark the system must pass.

Ask how GPUs are interconnected, what topology is exposed to software, and whether partitioning or multi-instance capabilities required by the use case are supported in the proposed version. If multiple tenants or security zones will share infrastructure, document the isolation model and its performance trade.

The proposal should also state the platform and firmware revisions. Two servers described as “HGX B200” may have different BIOS settings, NIC firmware or validated driver bundles. Baseline configuration control before factory testing, and record every approved deviation.

The host can bottleneck a powerful GPU platform. Require enough detail to verify CPU-to-GPU and NIC-to-GPU paths:

The DGX B200 guide gives a useful example: 10U height, approximately 313.9 pounds, maximum 14.3 kW input, 1,550 CFM airflow and 48,794 BTU per hour heat output. Use those values only when acquiring or planning for that exact appliance. For an OEM server, use its own site-preparation guide.

Ask whether components are hot-swappable and what happens when a GPU, NVSwitch component, NIC or boot drive fails. The repair unit and access procedure affect spares, clearances, downtime and data-handling rules.

A B200 server needs at least three network conversations: scale-out GPU traffic, storage/data traffic and management. Some designs add a separate service, cluster or tenant network. List every plane, port speed, port count, connector, transceiver, cable and redundancy mode.

For the compute fabric, specify InfiniBand or Ethernet only after an architecture decision. If Ethernet is selected for RDMA, define the supported end-to-end design rather than assuming any switch with the right nominal speed will behave like an AI fabric. The InfiniBand versus Spectrum-X guide covers topology, congestion control and operations.

For storage, specify sustained read/write targets, metadata operations, checkpoint pattern and protocol/filesystem compatibility. If using GPUDirect Storage, require evidence that the proposed filesystem, kernel, drivers, NICs and topology are supported. GDS can reduce CPU-path overhead; it cannot fix an undersized array or an unsupported software stack.

Include a port-and-cable matrix as a deliverable. “Cables included” is not sufficient for a rack with dozens of high-speed links. The matrix should identify both endpoints, media type, length, part number, labeling convention and spare quantity.

Request typical, tested peak and maximum input power for the complete configured server. Document input voltage, phase, frequency, connector, feed count and redundancy behavior. Then calculate the rack total with fabric, storage, management and PDU losses.

For air-cooled systems, obtain airflow direction, cubic-feet-per-minute requirement, allowable inlet range, altitude derating and heat output. Check containment, tile or duct capacity, static pressure and the effect of a failed fan or feed. High airflow can create a facility constraint before nameplate electrical capacity is exhausted.

For direct-liquid-cooled designs, specify the technology-side inlet temperature, flow, pressure, pressure drop, coolant chemistry, materials compatibility, filtration, water quality, quick-disconnect type, leak detection and response. Define the boundary between server loop, rack manifold, CDU and facility-water system. The detailed GPU cooling guide provides the commissioning checklist.

Rack integration requires more than enough U-space. Verify rack depth, static and rolling weight, floor loading, rail compatibility, center of gravity, seismic requirements where applicable, lift/access path and rear service space. Create a rack elevation and cable pathway before accepting the factory configuration.

Specify supported versions rather than “latest.” List operating system, GPU driver, CUDA, container runtime, orchestration, NVIDIA AI Enterprise entitlement if used, scheduler, model-serving framework and monitoring integration. Define how updates are received, tested, approved and rolled back.

Security requirements should cover secure boot and attestation where needed, management-plane isolation, privileged access, log export, vulnerability notification, firmware update, cryptographic requirements and media handling. Apply the agency's risk-management process to the complete system; a compliant operating system does not make unmanaged BMC firmware disappear.

Define the support boundary. Identify who owns first call, on-site response, parts, firmware escalation, fabric troubleshooting and software compatibility. Require the duration and service level in the line item. If the system will operate in a restricted site, confirm escort, clearance, tool and media rules before promising an on-site response time.

Finally, require configuration documentation: as-built BOM, serial numbers, firmware manifest, cabling, rack elevation, test results, licenses and recovery instructions. Those records support acceptance and later change control.

Use these sections in a market survey or RFQ:

Attach the workload test and site interface sheet. That lets sources propose an equal system without guessing which characteristics are actually salient.

Uniqcli can take a B200 performance requirement through OEM selection, rack integration, fabric and storage mapping, power/cooling review, staging and acceptance planning. Review the AI server rack solution, OEM integration capability and Supermicro catalog, or request an OEM-neutral B200 equivalency matrix.

The output should identify exact models and current support evidence while keeping workload and interfaces visible. That is what makes a B200 requirement competitive, installable and testable.

Technical note: DGX figures in this article apply to DGX B200. Always use the selected OEM model's current site-preparation and support documentation for final engineering.