HGX B300 Specs: What Buyers Should Confirm in Writing

Picture a head of infrastructure at a growing model lab with three quotes open in three tabs. Every quote says "HGX B300." Every quote lists 8 GPUs with 288 GB each. One quote describes the CPU as "dual high-core-count processors." Another lists the fabric as "TBD." The third says nothing about cooling. On paper the three look interchangeable. In practice they could be three very different machines, and the differences will surface during the first week of training.

This guide is for founders, infrastructure leads and procurement owners who searched for HGX B300 specs and need more than a data sheet. It covers what the platform fixes, which specs change from vendor to vendor and quote to quote, and how to turn each one into a line in your contract and a test at acceptance. It leaves out GPU performance figures on purpose. Those come from NVIDIA and do not change between quotes. Everything else is where quotes differ.

1. What HGX B300 is, and what the platform fixes

HGX B300 is NVIDIA's 8-GPU baseboard built on the Blackwell Ultra generation. NVIDIA does not ship it as a finished server. Server makers such as Supermicro take the baseboard and build complete nodes around it, adding CPUs, system memory, local storage, network cards, power supplies, a cooling design and a chassis.

The platform fixes two numbers you can treat as constants: 8 GPUs per node and 288 GB of memory per GPU, which is how Pacific's catalog lists them. If a quote shows a different GPU count or per-GPU memory figure for an HGX B300 node, ask why before you go any further.

Every other spec is a vendor or provider decision. That's why two quotes carrying the same platform name can differ on throughput, operability and cost.

2. Server vendor, model, CPU, memory and storage

The host system around the GPUs determines data loading, preprocessing headroom, checkpoint speed and how much you can stage locally. These specs belong in writing by name:

• Server vendor and exact model number. A vendor name alone is not enough. The model ties to a specific chassis, power design and cooling design.
• CPU model, socket count and the vCPU count exposed to your workloads. A provider may hold some cores back for management, so ask for the number you will actually see.
• Total system memory per node, plus the DIMM configuration if your workload is sensitive to memory bandwidth.
• Local NVMe per node: drive count, raw capacity and usable capacity after any RAID or reserved space.
• Data handling at end of term, for example whether local NVMe is erased when the resource ends.

The cost drivers here are straightforward. More cores, more memory and more NVMe add to node cost. If one quote is noticeably cheaper, compare these lines first.

3. NICs, fabric type and per-node bandwidth

The fabric is the spec most often left vague, and it is the one that matters most for multi-node training. A written fabric spec should answer:

• Fabric type: InfiniBand or Ethernet, and which generation.
• NIC model and count per node, along with which NICs carry compute traffic and which carry storage or management traffic.
• Per-node bandwidth for the compute fabric, stated as a number.
• Topology, for example rail-optimized, and the switch layout that delivers it.
• Whether the fabric is dedicated to your cluster or shared with other tenants.
• Whether bandwidth is fixed or configurable, and who decides the configuration and when.

Fabric choices drive both switch and optics cost and the scaling behavior you will see beyond a single node. A quote that commits to the GPUs but leaves the fabric open hasn't actually committed to the system you are buying.

4. Cooling method and power per rack

Cooling and power affect two things buyers sometimes overlook: where the hardware can physically go, and how stable it runs under sustained load. Ask for:

• Cooling method: air, direct-to-chip liquid, or a hybrid.
• For liquid cooling: coolant distribution unit redundancy, and whether the site needs a water supply.
• Power per rack and total operating load for the deployment.
• Rack count and node density per rack.
• Who owns the facility side: the power feed, the pad or hall, and commissioning.

Facility readiness is a real cost driver. A design that needs site water, or racks heavier than the floor allows, brings engineering work that never shows up on a node quote.

5. Firmware, BIOS, driver and CUDA baseline

Two physically identical nodes can behave differently if they run different firmware. Get the software baseline written down before hardware ships:

• BIOS version and key settings.
• BMC firmware version.
• GPU, NIC and switch firmware versions.
• Operating system and kernel version.
• NVIDIA driver version and CUDA version installed at handover.
• Who controls updates during the term, and how changes get approved.

The strongest version of this is a hash-locked baseline, so you can verify on arrival that what is running matches what was agreed. Our guide on how to lock firmware baseline hashes before reserved B300 ships walks through the process.

6. Worked example: two published B300 shapes

Pacific publishes two B300 shapes. They are separate offers with different specs, and comparing them shows why the platform name alone tells you so little.

The first is the B300 SXM node in Pacific's GPU compute catalog of dedicated bare-metal nodes. Its listing shows 8 GPUs at 288 GB each, 224 vCPU and 4 TB of system memory per node, and an InfiniBand interconnect confirmed with your order. Access is SSH to dedicated bare-metal Linux hosts with NVIDIA drivers and CUDA installed, and local NVMe is erased when the resource ends. Sizes run from 1 to 8 nodes, durations are 1, 2, 3 or 6 months, and region options are Asia Pacific, North America and Europe. All of it is by request, with pricing by request, and it goes through a review before anything is committed.

The second is the Pod 32 reserved module, described on Pacific's Pod 32 architecture and reference specification page. It is a reference design of 32 Supermicro HGX B300 nodes, for 256 GPUs, 128 TB of system memory and 983 TB of raw NVMe per module. The fabric is rail-optimized 400G Ethernet with configurable 3.2 or 6.4 Tbps per node, chosen with engineering. Cooling is direct-to-chip liquid with redundant coolant distribution units and no site water requirement, and the reference operating load is 645 kW across 4 racks. It sits within Pacific's reserved single-tenant B300 cluster offer, where configuration and delivery window are confirmed through a project review and a written offer.

Both shapes use the same GPUs, yet the fabric, scale, cooling and facility model differ completely. Pod 32 is an illustrative design study, and Pacific's written specification governs what you actually receive. That's the habit to carry into every quote: whatever the web page or slide deck says, the signed specification is the document that counts.

7. Turn specs into acceptance tests

A spec you can't test is a spec you can't enforce. For every line in sections 2 through 5, write down how you will verify it at handover:

• Inventory check: vendor model, CPU, memory and NVMe confirmed against the written spec on every node.
• Fabric criteria: measured NCCL results across the full cluster, with pass thresholds agreed in writing before delivery.
• Burn-in: a sustained load period that exercises GPUs, cooling and power together.
• Firmware hash checks: every node's firmware and driver stack compared to the locked baseline.
• Witnessed evidence: factory, site and integration test results you or your delegate can observe or review.

Pacific's Pod 32 reference includes measured NCCL fabric-performance criteria and a 24-stage factory, site and integration test program with witnessed acceptance evidence. For a template you can adapt, see our acceptance criteria for reserved B300 GPU capacity.

8. Red flags in a spec sheet, and questions to ask

Slow down when you see any of these:

• No server vendor or model, only "HGX B300" or a generic chassis description.
• "B300-class" or "Blackwell-class" wording in place of a named platform.
• Fabric listed as "TBD," "high-speed," or with no per-node bandwidth figure.
• No cooling method stated, or no power-per-rack figure for a multi-rack deployment.
• vCPU or memory described as "up to" a number.
• No driver, CUDA or firmware versions, or a line saying versions are "latest at delivery."
• Acceptance described as "standard" with no criteria attached.

Questions worth asking every provider:

• Which exact server model is this, and can you show it in the written specification?
• How many vCPUs will my workloads see on each node?
• What fabric, which NICs, and what per-node bandwidth? Is it dedicated to us?
• What is the cooling method, and what does the site need to support it?
• Which firmware, driver and CUDA versions ship, and how do we verify them?
• What are the acceptance criteria, and who witnesses the tests?
• If a spec changes before delivery, how will we be told, and what are our options?

If you are building a written specification for reserved B300 capacity and want to review the configuration and acceptance criteria, Pacific Intelligent Technologies, Inc. can walk through your requirements on a project review call. Book a 30-minute call to scope your B300 specification.

FAQ

Are HGX B300 specs the same across every vendor?

The GPU side is the same: 8 GPUs per node with 288 GB each. The server around it changes by vendor and by configuration, including the CPU, system memory, local NVMe, NICs, fabric, cooling and firmware. Compare quotes on those lines, and require each one to be named in writing.

Does Pacific's catalog B300 node use the same fabric as Pod 32?

No. They are separate offers. The catalog B300 SXM node lists an InfiniBand interconnect confirmed with your order. The Pod 32 reference module uses rail-optimized 400G Ethernet with configurable 3.2 or 6.4 Tbps per node. In both cases, Pacific's written specification for your order governs.

What is the minimum a written HGX B300 spec should include?

At minimum: server vendor and model, CPU and vCPU count, system memory, local NVMe, NIC model and fabric type with per-node bandwidth, cooling method, power per rack, firmware and BIOS baseline, driver and CUDA versions, and the acceptance criteria that will verify each of these at handover.