B200 GPU On-Demand Prices Vary 3-4x: From $3.70 to $14.24/Hour, How to Calculate Blackwell's Unit Compute Cost

The same B200 GPU, why can on-demand unit prices differ by 3-4 times? Third-party cloud price monitoring from June to August 2026 shows a surprisingly wide distribution: Spheron reports $3.70 per hour, Lambda Labs between $4.99 and $5.29, Nebius $5.50, Runpod between $5.89 and $5.98, and AWS's p6-b200 instance converts to as high as $14.24 per hour. The median on-demand price across the web for B200 is around $6.84 per hour. The maximum price difference reaches 3.85 times, which cannot be explained by just "platform premium."

If you're budgeting or selecting technology for B200 GPUs, this price difference can be confusing: the same card, why is it cheap as cabbage on some platforms and expensive enough to suspect a typo on others? This article will dissect the logic behind the price gap based on public monitoring data from June to August 2026, and provide you with a reusable method to convert "hourly unit price" into "cost per million tokens," helping you answer the ultimate question: which is more cost-effective, B200 or H100?

1. B200 GPU Price Map in August 2026: What's the Difference Between $3.70 and $14.24/Hour

First, look at the facts. According to third-party cloud price monitoring (GetDeploying, CloudZero, etc., data from June-August 2026), B200 GPU on-demand rental prices show significant divergence:

This price gap intuitively reflects differences in platform types. Emerging compute aggregation platforms usually provide compute as "bare metal" or "basic cloud hosts," with more aggressive pricing strategies, making the GPU itself the core selling point. In contrast, hyperscalers like AWS include additional costs in their prices, such as more mature network architecture, persistent storage, SLA guarantees, and technical support—not that emerging platforms lack these, but their positioning and cost structures differ. Therefore, directly comparing "hourly unit prices" horizontally is dangerous; you must clarify which additional services you need.

Key Point: First list your required network, storage, and SLA requirements, then compare unit prices; otherwise, $3.70 and $14.24 are not comparable.

2. What Bottlenecks Do the 192GB-288GB Memory and 8TB/s Bandwidth Solve?

The B200's 192GB HBM3e memory is already large, while the flagship B300 (Blackwell Ultra) comes with 288GB HBM3e memory and 8TB/s memory bandwidth, offering 15 PFLOPS of dense FP4 compute and 7 PFLOPS of dense FP8 compute (according to platforms like Vast.ai, June 2026). These specifications correspond to three types of engineering bottlenecks:

• Memory Capacity: When your model context is long, KV Cache can expand rapidly, or when you need to accommodate intermediate states for a large number of concurrent requests, 192GB or even 288GB memory avoids frequent memory overflow and recomputation.
• Memory Bandwidth: For large-batch inference or training, each token requires reading weights and activations; 8TB/s bandwidth supports higher throughput and reduces memory access latency.
• Low-Precision Compute: FP4/FP8 compute mainly benefits inference scenarios insensitive to precision loss, achieving higher compute throughput with fewer bits.

So, "What models are suitable for B300 with 288GB memory?" The answer is straightforward: particularly suited for long-context (e.g., 128K or even 1M window) large language model inference, also suitable for offline batch processing with large batch sizes, and scenarios where large-parameter MoE model weights need to reside in memory. If your workload bottleneck is memory capacity or bandwidth, Blackwell's high specs truly start to deliver value.

Key Point: If your workload bottleneck is memory capacity or bandwidth, B300's 288GB is worth it; otherwise, it may just add idle cost.

3. Convert Hourly Unit Price to Unit Output Cost: A Reusable Algorithm for Cost per Million Tokens

"How much is B200 GPU rental per hour?" is the starting point for procurement but not the decision endpoint. What really affects your budget is the cost per million tokens. We can use a universal formula:

Cost per million tokens = Hourly unit price ÷ (Measured throughput tokens/s × 3600) × 1e6

Here, "measured throughput" refers to the number of tokens the model can process per second under your own workload, batch size, concurrency, and quantization scheme. Note that this value must be measured by yourself; you cannot substitute any public benchmark.

For example (assumptions for illustration; replace with your own measurements): Suppose you rent an 8-card B200 instance on some platform, with the hourly unit price converted to $5.00 per card (for multi-card instances, convert based on the whole machine). If the entire instance's throughput measured is 10,000 tokens/s, then the cost per million tokens is: 5.00 ÷ (10000 × 3600) × 1e6 ≈ $0.139. But if throughput is only 1,000 tokens/s, the cost skyrockets to $1.389—a tenfold difference.

So, when directly comparing B200 and H100, you can't just look at unit price. If B200's throughput is 3 times that of H100, then even if B200's unit price is 2 times higher, the cost per token is actually lower. But all this must be verified with measured data.

In actual calculation, also consider the whole-machine cost for multi-card instances, utilization (idle time), cold start and image pull time, P95 latency constraints under concurrency, and the impact of quantization precision on throughput and quality. These variables can make actual costs deviate significantly from theoretical values.

Key Point: Bring measured throughput into the equation, convert hourly price to cost per million tokens, and only then can you truly compare the economics of different card types and platforms.

4. Why Hasn't H100 Price Dropped After B200 Launch?

Before 2026, many early analyses predicted that H100 prices would plummet after B200 mass production, even dropping below $1 per hour. But actual monitoring data from May-August 2026 (from sources like CloudZero, GetDeploying) shows that the median on-demand price for H100 SXM 80GB in the cloud remains stable at $2.29-$3.66 per hour. For example, Lambda quotes $2.86/hour, RunPod $2.69/hour, and GetDeploying's average is $3.12/hour.

Why hasn't it crashed? The reason is that demand growth for high-concurrency LLM inference and agent tasks keeps the demand for Hopper architecture (to which H100 belongs) strong. New cards don't necessarily cause old card prices to crash, especially when demand grows faster than supply. This means that if you're waiting for "H100 at rock-bottom prices," you might be waiting in vain; the correct approach is to evaluate whether B200's unit output has already surpassed H100.

Key Point: Don't bet on old card price drops; use unit output cost to decide on migration.

5. When to Stay on Hopper and When to Move to Blackwell

Combining the earlier prices and specs, we can outline decision boundaries for three workload types:

1. Small/medium models, short context, throughput not constrained by memory: These workloads often have better unit costs on H100 because H100's unit price is lower and memory isn't a bottleneck, so there's no need to pay extra for large memory.
2. Long context/high concurrency causing frequent KV Cache overflow: In this case, you might need more cards to gain memory. If the cost of adding cards exceeds the higher unit price of B200/B300 but with fewer cards, then Blackwell might level or even lower unit costs by reducing the number of cards.
3. Large-parameter MoE models requiring resident weights and pursuing low-precision high throughput: These workloads have extremely high requirements for memory capacity and bandwidth; B200/B300's 288GB and 8TB/s bandwidth are essential, so priority should be given to evaluating them.

Note that all these determinations are conditional on "depending on measured ratios"; we do not assert "B200 is N times faster than H100" because that requires your own testing.

Key Point: Categorize based on your bottleneck type, then use measured throughput to validate unit cost.

6. Use On-Demand Resources for a Controlled Cross-Card Comparison Test

To make a reliable decision, the most direct method is: fix the same model weights, same quantization scheme, same request distribution and concurrency gradient, and run on both H100 and B200, recording the following five metrics:

• Peak memory usage
• Steady-state throughput (tokens/s)
• P95 first-token latency
• Unit time cost (on-demand unit price)
• Cost per million tokens (using the above formula)

This controlled experiment requires controlled variables, and you should run it for a sufficient duration (e.g., at least 2-4 hours) to cover cold start, warm-up, and stable phases. Why use on-demand resources instead of signing a long-term contract? Because on-demand billing allows you to start and stop instances of different card types flexibly, obtaining firsthand data at minimal cost, avoiding locking in the wrong card type due to blind signing.

If you need to quickly set up a controlled environment with different model types, you can try GPU cloud platforms like NexGPU. It offers multiple GPU server model choices, on-demand usage with immediate availability, and pre-built model and application templates for deployment scenarios, making it suitable for running an hour-level on-demand H100 vs. Blackwell comparison before locking in a long-term card type.

Key Point: Use low-cost on-demand resources to get measured data before discussing long-term contracts.

7. B200 GPU Procurement Checklist and Four Common Misjudgments

Before making a final selection, check each item to avoid pitfalls:

• Only looking at hourly unit price, ignoring whole-machine cost and instance specs: For multi-card instances, divide total price by the number of cards, and also pay attention to differences in network bandwidth, local NVMe, etc.
• Directly comparing Hyperscaler quotes with emerging platform quotes: You need to convert additional services (like SLA, technical support, storage) into price.
• Assuming old cards will drop in price when new cards launch: The 2026 data has proven H100 prices are stable; don't use outdated experience for scheduling.
• Locking in a long-term card type without same-workload testing: No matter how attractive the price, not testing is equivalent to signing blindly.

Regarding "B200 on-demand vs. monthly subscription," the core is to look at workload stability and utilization: if the load curve is stable, monthly plans might be more cost-effective; if there are peaks, on-demand combinations are more flexible. We don't promise specific discounts, but suggest evaluating based on "utilization" and "peak-to-average ratio."

Fact Boundary of This Article: The prices cited are from third-party monitoring data from June-August 2026 (sources: GetDeploying, CloudZero, Vast.ai, etc.), subject to change, and may not represent current real-time market conditions. No public data is available for domestic (Chinese) nodes' RMB on-demand pricing for the Blackwell architecture; this article does not include such content. All throughput, latency, and other performance values are example assumptions that readers should replace with their own workload measurements. Before making migration decisions, it is recommended to conduct a same-workload comparison using on-demand resources, using cost per million tokens rather than hourly unit price as the decision basis; if you need to quickly set up a controlled environment with different model types, you can choose GPU models on demand on NexGPU and activate them on a pay-as-you-go basis.