The puzzle

NVIDIA’s B200 and B300 are priced within 1% of each other on the US neocloud market. The monthly average listed neocloud rate for a B200 in April is $5.24/GPU/hr. For a B300, it’s $5.20.

On paper, the B300 is a meaningfully better GPU. It delivers 55% more FP4 compute (14 vs 9 PFLOPS), 50% more memory (288 vs 192 GB HBM3e), and up to 2× the FP16 TFLOPS, though as we’ll see, FP16 is increasingly the wrong metric to compare on. It also draws 40% more power (1,400W vs 1,000W) and requires liquid cooling that the B200 doesn’t strictly need.

So the B300 is significantly more capable and costs roughly the same per hour. Is the market mispricing one of these GPUs? With about 3 vendors and 5 pricing configurations on any given day, calling it a market at all is generous. There isn’t enough liquidity for price discovery to work. The answer also depends on what you’re doing with it.

A note on scope. These are listed neocloud prices: what buyers see on vendor websites for small commitments. The private transaction market, where larger deals clear on negotiated terms, tells a different story. We’ll dig into that in a follow-up. For now, the listed-price picture is where most buyers start.

Why the pricing gap is smaller than you’d expect

Three things could explain the near-parity.

Bandwidth is identical. Both GPUs have 8 TB/s of HBM3e memory bandwidth, and bandwidth is the binding constraint for the workload that dominates GPU demand: autoregressive LLM inference. When you’re serving a model to users, the bottleneck is reading model weights and KV cache from memory for each token. Extra TFLOPS don’t help if the data can’t get to the compute fast enough. For any model that fits on both GPUs, per-token inference speed is roughly the same.

2× TFLOPS ≠ 2× training speed. The spec sheet says the B300 has double the FP16 tensor TFLOPS. But Nebius’s MLPerf Training v5.1 submission (the only public apples-to-apples benchmark of both GPUs) showed a 12.6% average reduction in training time for B300 versus B200 on the same workloads (Llama-2-70B LoRA fine-tuning and Llama-3.1-8B pre-training). Real distributed training is bottlenecked by interconnect communication, pipeline overhead, and data loading, not peak compute. B300 does ship with ConnectX-8 networking (double the scale-out bandwidth of B200’s ConnectX-7), which should help on communication-bound runs, but no public benchmarks isolate this effect yet. 12.6% is real but not transformational. And the benchmark is from November 2025 with early B300 software. The gap has likely widened since, but we don’t have updated public data.

The models people actually run don’t sit in the gap. B300’s extra memory matters when it lets you serve a model on one GPU that would need two on B200. But look at what’s actually running in production: 70B-class dense models (Llama 3.1 70B, Qwen, Mistral) fit comfortably on a B200 at FP8 with room to spare. 400B+ models (Llama 3.1 405B, DeepSeek R1’s 671B MoE) don’t fit on either GPU, you’re sharding across a node regardless. The sweet spot where B300’s extra memory saves you a GPU is narrow at FP8, and the models people actually deploy don’t sit in it.

For the workloads people are running right now, B300’s advantages are real but incremental, which could explain why the pricing gap hasn’t opened up.

Where the gap opens

So if B300 isn’t dramatically better for today’s workloads, what explains the similar pricing? Probably not foresight. There isn’t enough liquidity for price discovery to work. But whether by accident or design, the near-parity creates an interesting asymmetry for buyers. Because what comes next favours the B300.

FP4 is rewriting the capacity math. FP4 precision is rapidly maturing, with NVIDIA’s Transformer Engine handling it natively and both TensorRT-LLM and vLLM supporting it. At FP4 precision effective model capacity roughly doubles versus FP8. This changes what fits where, and this is why the 2× FP16 headline is misleading. The precision that is likely to matter for inference is FP4. At FP4, a B200’s 192 GB fits ~384B parameters of weights alone, but you need headroom for KV cache and runtime, so the practical ceiling for serving is closer to ~290B. A B300’s 288 GB pushes that practical ceiling to ~430B. That’s a threshold B200 can’t cross. FP4 adoption is accelerating faster than most buyers realise. GPT-OSS-120B shipped FP4-only, Nemotron followed, and Perplexity now offers FP4 by default. New models increasingly ship with FP4 as the native precision rather than an afterthought, and vLLM follows. Quality varies by model, but FP4 is increasingly the starting point rather than the fallback.

DeepSeek V4, released this week, illustrates the point. V4-Flash is a 284B MoE model with 13B active parameters and 1M native context. At FP8, its full weight footprint (~284 GB) barely fits on a single B300 and doesn’t fit on a B200 at all. At FP4, it drops to ~142 GB, comfortable on either GPU. V4 also introduced hybrid attention that compresses KV cache to 10% of previous generations, making million-token context practical in production. The models being released right now are designed around the memory and precision assumptions that favour B300.

The frontier is going MoE and MoE is memory-hungry in a different way. The frontier is going MoE, and MoE is memory-hungry in a different way. DeepSeek V4-Pro, released alongside V4-Flash, packs 1.6T parameters with only 49B active per token. Even with that sparse activation, all weights must be resident in high-bandwidth memory across the cluster. Every expert needs to be reachable for low-latency routing, even when each card holds only a subset under expert parallelism. At FP4, V4-Pro requires ~800 GB total for weights alone, sharded across at least four GPUs either way. Four B200s give you 768 GB, already overflowed before you account for KV cache, quantization metadata, or non-quantized layers. Four B300s give you 1,152 GB: ~350 GB of headroom for KV cache, long contexts, and concurrent requests.

Long-context serving eats the rest. Even for models that fit comfortably today, VRAM pressure is growing from a different direction. A 70B model at FP8 uses ~70 GB for weights, leaving 122 GB on B200 and 218 GB on B300 for KV cache. Context windows have already blown past what most GPU memory budgets were designed for, and production inference at long context lengths is increasingly common, not a lab curiosity. Every token of context consumes KV cache at serving time, and at high concurrency the pressure multiplies. The gap between 122 GB and 218 GB of headroom determines how many concurrent long-context requests you can serve from GPU memory before falling back to slower CPU or SSD offloading. This only grows as long-context workloads move from occasional to default.

There’s a second VRAM benefit beyond model fit: batch size. For models that fit on both GPUs, B300’s extra memory allows more concurrent requests per card. More concurrency means better GPU utilization, particularly on Blackwell, where the compute-to-bandwidth ratio is high and small batches leave the tensor cores underutilized. This is less visible than “fits vs doesn’t fit,” but for high-throughput inference deployments it may matter more.

Software is still catching up. NVIDIA’s own data shows B200 cost-per-million-tokens dropped from $0.11 to $0.02 within two months of launch. That’s a 5× improvement from software optimization alone. B300 hasn’t had that yet. As the software stack matures for Blackwell Ultra specifically (FP4 kernels, attention acceleration via the B300’s new tensor core instructions, ConnectX-8 networking) the realized performance gap between B200 and B300 will likely widen beyond the 12.6% that MLPerf shows today.

The options argument

Here’s the reframe: B300 at roughly B200 pricing isn’t a value play on today’s workloads. It’s a free option on tomorrow’s.

The bet is on FP4 becoming the default inference precision, and the ecosystem is heading there fast. If it does, B300 crosses capacity thresholds that B200 can’t: single-GPU serving of 405B dense models,four-GPU serving of trillion-parameter MoE models with actual room for KV cache. B300’s 55% FP4 compute advantage compounds into cost-per-token savings across all of these.

And if FP4 stalls and FP8 stays dominant, if context lengths plateau, if MoE models stop growing, you’ve paid roughly the same hourly rate as B200 anyway. The one risk to monitor: if B300 hourly rates drift upward as infrastructure costs (particularly liquid cooling and power delivery) surface in pricing, the “free option” becomes a modest premium, but one that’s small relative to the potential upside.

What to watch

B300 supply thickening. The US market currently has few neocloud vendors offering B300 across a handful of pricing configurations (variable day to day), versus around 10 vendors and 73 configurations for B200. As more providers deploy Blackwell Ultra capacity, two things will happen: the B300 median price will become more statistically meaningful, and competitive pressure could push it lower, or, if demand accelerates for the use cases described above, higher. Either direction is informative.

Power and cooling costs surfacing. B300’s 1,400W TDP with mandatory liquid cooling is a real infrastructure cost that early-mover pricing may not fully reflect. Cooling infrastructure alone runs roughly $50K per rack in bill-of-materials according to a Morgan Stanley teardown, and only about 1% of global data center operators currently run racks above 100 kW. As B300 deployment matures beyond the first movers, hourly rates could drift upward to reflect these costs.

The software optimization trajectory. Watch for B300-specific optimizations, particularly around FP4 inference and the new attention-layer acceleration instructions in the SM103 architecture. Early bare-metal testing suggests B300 software maturity is still roughly a quarter from mass adoption readiness.

The model-size and architecture roadmap. Watch whether MoE remains dominant. If dense models start growing into the 200B+ range, B300’s advantage widens further. If MoE keeps scaling, toward multi-trillion-parameter models with longer context, the per-card headroom matters even more across a fleet. The harder question is how fast FP4 serving quality matures across model families. That, more than any architectural shift, determines whether the option pays off.

Europe tells a different story. In the EU neocloud market, B300 is 18% more expensive than B200 ($5.22 vs $4.42/hr): the pricing dynamic is inverted. The European B300 vendor base is as thin as in the US, so this could just be a thin-market artifact. Different vendor mixes, different demand profiles, different infrastructure cost bases could also play a part. Worth tracking as a natural experiment in how markets converge.

B200 and B300 cost the same today, at least at listed rates. They won’t forever. GPU rental pricing moves with supply, demand, software maturity, and workload shifts, and none of those are standing still. The current window is unusual: a next-generation GPU at last-generation pricing, in a market too thin to have corrected it yet. If you’re making procurement decisions now, that’s worth paying attention to. If you’re making them at scale, the picture gets more complicated. More on that soon.