B200 versus B300: what actually changes at the system level.

When buyers ask us whether to lock RIL-GX-B200-2T or RIL-GX-B300-2T on a forward, they usually frame it as a GPU question. It is not. By the time you are signing a contract on a complete OEM system, the GPU die is the one component you do not get to choose. What you are actually buying is a baseboard, a host platform, a north-south DPU, an east-west fabric, and a memory budget, all assembled by a named OEM and delivered to an end customer of record. The generational gap between HGX B200 and HGX B300 shows up across that entire bill of materials, and it changes the system you take delivery of far more than the marketing names suggest.

This is the spec-for-spec breakdown, written for cluster architects and procurement teams who have to defend a forward premium to a finance committee. We will hold the comparison at the complete-system level, because that is the level at which a Rillor forward contract is written. The short version: B300 is a memory and fabric generation, not a flops headline, and that is exactly why the procurement decision is more interesting than it looks.

The headline number is memory, not flops

If you remember one figure from this comparison, make it this one. An 8-GPU HGX B300 baseboard carries 2.30 TB of HBM3e, at 288 GB per GPU. The 8-GPU HGX B200 baseboard carries 1.44 TB, at 180 GB per GPU. That is roughly 1.6x the on-package fast memory per node, and it is the single change that reshapes what the system is good for.

Memory capacity is the constraint that bites first on modern training and inference. A frontier-scale model that spills across more GPUs purely to fit in HBM pays a fabric tax on every step. More capacity per GPU means a given model shard fits in fewer GPUs, which means smaller tensor-parallel groups, which means less cross-GPU traffic and higher achieved utilization. For long-context inference and KV-cache-heavy serving, the capacity headroom translates almost directly into larger batch sizes and more concurrent sequences per node. This is why we treat B300 as a memory generation. The flops uplift is real, but the memory is what changes the shape of the deployable workload.

Both generations stay on HBM3e, and both run an 8-GPU SXM baseboard with NVLink5 between the GPUs inside the node. So the intra-node GPU-to-GPU topology is consistent. What differs is how much each GPU can hold, and how fast each GPU talks to the rest of the cluster. We unpack the broader HBM3e picture in HBM3e capacity and bandwidth across the Blackwell line, but for a procurement decision the node-level capacity number above is the one that goes in the model.

East-west fabric: ConnectX-7 to ConnectX-8

The second structural change is the cluster fabric. HGX B300 integrates eight ConnectX-8 SuperNICs on the baseboard, at up to 800 Gb/s per adapter, in a 1:1 GPU-to-NIC arrangement. HGX B200 uses ConnectX-7 at the 400 Gb/s class. That is a clean doubling of per-GPU east-west bandwidth out of the node.

For a single server this sounds like a footnote. At cluster scale it is not. The point of a multi-rack training fabric is to keep the GPUs fed during the all-reduce and all-to-all collectives that dominate distributed training. When per-GPU egress doubles, the collective phases finish sooner, the GPUs stall less, and the cluster runs closer to its theoretical throughput. The benefit compounds with cluster size: the larger the job, the more of the step time lives in the fabric, and the more the ConnectX-8 baseboard earns its keep.

This pairs with the switch you put it on. ConnectX-8 at 800 Gb/s is the host-side match for the 800G InfiniBand generation (Quantum-X800 XDR) or Spectrum-X SN5600 on the Ethernet side. Running ConnectX-8 endpoints into a 400G fabric leaves bandwidth on the table, so the fabric choice and the baseboard choice are one decision, not two. We walk through that fabric stack in ConnectX-7, ConnectX-8, and NVLink5 fabric explained. For a B200 deployment, ConnectX-7 into a Quantum-2 QM9700 or Spectrum-X SN5600 spine is the conventional pairing and is entirely adequate for most workloads short of the largest frontier runs.

North-south: BlueField-3 B3240 replaces B3220

The data-plane DPU changes generation as well. NVIDIA's HGX reference architecture recommends the BlueField-3 B3240 (400 GbE) for the north-south path on B300, where B200 (along with the prior H100 and H200 HGX systems) commonly shipped the BlueField-3 B3220 at 200 GbE.

North-south is the traffic that leaves the GPU cluster: storage, ingest, tenant networking, and the offloaded security and isolation work the DPU handles. Doubling that uplink matters most for the operators who are saturating storage during checkpoint and dataset streaming, or who are running multi-tenant isolation on the DPU. If your bottleneck is feeding data in and writing checkpoints out, the B3240 is part of the value, not a rounding error. For a single-tenant training cluster that streams from local NVMe, the difference is smaller, which is one of several places where the right answer depends on your actual workload rather than the spec sheet.

The host platform: a real CPU-pairing shift

The Blackwell Ultra generation also moves the host socket. The HGX and DGX B300 reference design pairs dual Intel Xeon 6776P CPUs, a 64-core, 350W part with 336 MB of L3 cache, with NVIDIA selecting that processor as the host for the B300 generation. The prior Blackwell systems paired Xeon 8570 or, on the AMD side, EPYC 9554 and 9555.

In OEM build-to-order, you still see choice. HGX B300 systems are offered with dual Xeon 6776P or dual EPYC 9555 and 9655 (Turin), and B200 systems with Xeon 8570 or EPYC 9554 and 9555, depending on the OEM and the SKU. The head-node CPU rarely limits a GPU server in steady state, but it does govern data-loader throughput, NUMA layout, and PCIe lane budget for the NICs and NVMe, so it is worth specifying deliberately rather than defaulting. We cover that tradeoff in Granite Rapids versus EPYC Turin for GPU server head nodes. The practical takeaway for a forward contract is that the host platform is part of the SKU, captured in the contract spec, so you are not left guessing which CPU arrives in the rack.

What does not change

It is just as useful to name the things that are common to both generations, because they are the variables that do not move the decision.

System DDR5 is shared. Both platforms base at 2 TB of DDR5 (Samsung DDR5-5600 RDIMM class), scaling to 4 TB on an 8-channel population and 6 TB on a 12-channel population. The local NVMe layout is identical: two boot drives plus eight cache drives (Micron 9550 PRO class), so storage planning carries over unchanged between the two.

Lead time is also effectively common. For the HGX platforms specifically, both B200 and B300 run a 4 to 6 week window from contract to delivery on a Rillor forward. There is a longer build-to-order range in the open OEM channel, and B300-class systems ramped later than B200 across the industry, but the contracted HGX delivery window is the same for both. That is the important point for procurement: delivery speed is not the lever here. You are not choosing B200 to get the system faster. You are choosing between two systems that arrive on the same schedule, which means the decision collapses cleanly to capability and price.

The procurement decision: when the premium pays back

Now the part that actually goes in front of a finance committee. RIL-GX-B300-2T carries a higher forward premium than RIL-GX-B200-2T. The question is not whether B300 is the better system in the abstract, because it plainly is. The question is whether the memory and fabric uplift earns its premium for your specific workload over your holding period.

The case for paying the B300 premium is strongest when:

• Your workloads are memory-bound. Long-context inference, large KV caches, or training a model whose shards barely fit in 180 GB and currently spill across extra GPUs. The 288 GB per GPU lets you fit more per device and shrink your parallel groups, which is a direct utilization win.
• You are building a large fabric. The bigger the cluster and the more time your step spends in collectives, the more the ConnectX-8 800 Gb/s baseboard converts into achieved throughput. At small node counts the fabric uplift is harder to monetize.
• Your north-south path is the bottleneck. Heavy checkpointing, dataset streaming, or multi-tenant isolation on the DPU make the B3240 400 GbE uplink pay for itself.

The case for RIL-GX-B200-2T holds when your jobs fit comfortably in 180 GB, your cluster is modest enough that the fabric is not your constraint, and you would rather deploy more total GPUs for the same budget. B200 is not the compromise option. It is the correct option for a large class of workloads, and the lower forward price means a fixed capex buys more silicon.

Because both arrive on a 4 to 6 week HGX window, the decision is unusually clean. You are not trading capability for speed. You are sizing a known premium against a known capability delta, on systems that deliver on the same schedule. That is exactly the kind of decision a forward contract is built to make legible.

Locking it in: why the forward, not the spot

A Rillor forward contract turns this analysis into a binding commitment at a contracted price and delivery month. It is a standardized OTC forward on a complete OEM GPU system, physical delivery always, with a 10% deposit at execution held by an independent escrow agent, the balance at delivery, and a seller performance bond standing behind the seller's obligation. The system spec, including the CPU, the NIC generation, the DPU, and the memory population, is fixed in the contract, so the B300-versus-B200 decision you make today is the system you actually take delivery of.

Structurally these are bilateral OTC forwards entered with the intent of physical delivery, which is what keeps them inside the CFTC forward-contract exclusion rather than making them exchange-listed futures. The distinction matters and we lay it out in Forward contracts versus futures for GPU systems. NVIDIA channel compliance is built into the flow, with the end customer of record captured on every contract, and a pre-delivery transfer to another KYC'd buyer is available with Rillor and OEM approval if your plans change before the delivery month.

Pricing across both generations is observable rather than negotiated one OEM at a time. The Rillor Compute Index publishes a 30-day rolling-blend forward price per SKU, computed from active Rillor contracts, so the premium between RIL-GX-B300-2T and RIL-GX-B200-2T is a number you can watch rather than guess. You can see the live tape on the marketplace, browse the system catalog on the SKU pages, or read the buyer playbook on for buyers.

The generational gap between HGX B200 and HGX B300 is real, but it is specific. It lives in memory capacity, east-west fabric, the north-south DPU, and the host socket, and it is absent from system memory, storage, and delivery timing. Hold the comparison at the system level, match the uplift to your workload, and the forward premium becomes a number you can defend rather than a guess you have to make.