Three NVIDIA GPU generations are bookable on Spheron right now, and only two of them have an hourly rate you can check before you commit. H200 covers models up to 141 GB on a mature Hopper stack. B200 adds native FP4 and more VRAM headroom for the Blackwell generation. GB200 NVL72 is the one that doesn't fit the same sentence: it's rack-scale infrastructure you reserve, not a GPU you spin up in two minutes. The GB200 vs H200 question gets asked by two different buyers, teams wondering if they should skip Hopper entirely, and teams wondering if they've already outgrown single-GPU rentals, and the right answer depends on where your workload actually sits, not on which GPU has the longer spec sheet.
TL;DR: GB200 vs H200 vs B200 for AI Workloads in 2026
- H200 SXM5 is the default for models up to 70B that fit in 141 GB of HBM3e.
- B200 SXM6 books on-demand at $11.12/hr and spot at $5.31/hr, and it's the pick once a model needs more VRAM headroom or native FP4 throughput.
- GB200 NVL72 fuses 72 Blackwell GPUs and 36 Grace CPUs into one NVLink domain rated by NVIDIA at 1,440 PFLOPS of FP4 compute per rack; it has no published hourly rate on Spheron and is reservation-only.
- Spheron books all three tiers from one dashboard: H200 and B200 ship with per-minute billing, and GB200 reservations confirm within one business day, from a single 8-GPU node up to a multi-rack deployment.
- Verdict: stay on H200 or B200 until a single model's weights plus KV cache push past what one 8-GPU node can hold, or until a training run genuinely needs NVLink all-to-all bandwidth across dozens of GPUs. That threshold, not model popularity, is the real GB200 line. Check B200 GPU availability and pricing before you commit.
Three Generations, One Decision: Hopper, Blackwell, and Blackwell NVL72
H200 is a Hopper-generation GPU: 141 GB of HBM3e, FP8 as its lowest supported precision, and a serving stack (vLLM, TensorRT-LLM) that's had two full years to mature. B200 is Blackwell: more VRAM, a wider memory bus, and native FP4 Tensor Cores that Hopper never got. GB200 NVL72 is a different category of thing entirely. It's NVIDIA's Grace Blackwell rack system: 36 GB200 Superchips, each pairing two Blackwell dies with one Grace ARM CPU over NVLink-C2C, for a total of 72 GPUs and 36 CPUs in a single NVLink domain. NVIDIA's own GB200 NVL72 page rates the rack at up to 13.4 TB of HBM3e with 1,440 | 720 PFLOPS, drawing roughly 120 kW to run.
That power draw is the tell. A single rack pulling 120 kW isn't something you provision on a whim the way you'd spin up an H200. It's purpose-built data center infrastructure, and providers sell access to it accordingly: by reservation, not by the hour.
Each tier is sold at a different scale, which is exactly why the specs don't line up in a single per-GPU row. Here's each one at the granularity it's actually rented in:
| Spec | H200 SXM5 (per GPU) | B200 SXM6 (per 8-GPU HGX node) | GB200 NVL72 (per 72-GPU rack) |
|---|---|---|---|
| HBM3e memory | 141 GB | 1.4 TB | 13.4 TB |
| FP4 Tensor Core | No native FP4 support | 144 PFLOPS | 1,440 PFLOPS |
| Spheron access | On-demand $5.54/hr, spot $3.35/hr | On-demand $11.12/hr, spot $5.31/hr | Reservation only, no hourly rate |
The scale jump matters more than any single number in that table. B200's 144 PFLOPS of FP4 is spread across 8 GPUs in one HGX node; GB200's 1,440 PFLOPS is spread across 72 GPUs in one NVLink domain. Neither figure tells you what a single GPU does on its own, which is why the decision tree below works off VRAM ceilings and interconnect needs rather than the raw numbers in this table.
For the full architecture breakdown, including die-level FP16/FP8/FP4 TFLOPS for all three GPUs, see the H200 vs B200 vs GB200 spec guide; this post is about which one you should actually be renting, not another spec dump.
The Decision Tree: Match Your Workload to GB200, H200, or B200
Work through this in order. The first row that describes your workload is the GPU you should be pricing out.
- A single model under roughly 70B parameters, running FP8 or FP16: rent H200. 141 GB holds the weights and a reasonable KV cache on one GPU, the software stack has no rough edges, and on-demand pricing means no reservation cycle before you start.
- A single model between roughly 70B and 180B, or anything that benefits from FP4 quantization: rent B200. More VRAM headroom than H200, and native FP4 Tensor Cores that H200 simply doesn't have.
- Several independent models, each comfortably under 70B, that need to stay up through spot reclaims: rent H200 or B200 in pairs across separate nodes rather than reaching for GB200. Redundancy is a serving-architecture problem, not a hardware-generation problem.
- One model whose weights plus KV cache exceed what a single 8-GPU node can hold, or a training run that needs NVLink all-to-all bandwidth across dozens of GPUs: this is the GB200 NVL72 case. Submit a reservation rather than looking for an hourly rate.
- You genuinely don't know yet: start on H200 or B200 on-demand, measure your real VRAM footprint and throughput under load, and only move to a GB200 reservation once the numbers say you've actually hit that ceiling. For a broader workload-by-workload breakdown that includes L40S and H100 as well, see the best GPU for AI inference guide.
Cost Per Token at Current Spheron Rates: H200 vs B200
Vendor TFLOPS tables tell you what a GPU can theoretically do. They don't tell you what it costs to serve an actual model under load. A single 8xH200 node, running the official INT4 checkpoint, served 8 users at 97 tokens/sec each in October 2026 testing, before the spot node was reclaimed.
At the Spheron spot rate recorded on 26 October 2026, $5.34/hr per B200 GPU, an 8-GPU B200 node runs $42.72/hr. Dividing that node cost by the 1,179 output tokens/sec measured under agent load works out to roughly $10 per million output tokens for that workload on B200. There's no equivalent aggregate agent-load figure from the H200 run to divide the same way, since that test measured per-user throughput before the node was reclaimed rather than a full agent-load pass, and good cost-per-token math needs a real aggregate number, not a multiplied guess. What the H200 run does show clearly is the other half of this trade-off: spot capacity on any GPU tier carries reclaim risk, and that risk, not the hourly rate, is often the deciding factor. Live rates move; the current B200 spot figure is $5.31/hr as of 27 Oct 2026, so rerun the division against today's number before committing a budget. If your model sits comfortably under B200's ceiling but you're deciding between B200 and the newer B300, the B300 vs B200 inference cost-per-token guide runs the equivalent math one generation further.
Pricing fluctuates based on GPU availability. Spheron rates above are live as of 27 Oct 2026, except the 26 October 2026 worked example, which is frozen at that date's spot rate. Check current GPU pricing → for live rates.
That reclaim risk is why spot discipline matters as much as the hardware choice.
When H200 Still Wins in 2026
H200 isn't a legacy choice just because Blackwell shipped. It wins outright for any model that fits in 141 GB and runs FP8 or FP16: the software stack has had far longer to stabilize, and you're not paying for FP4 compute you won't use. It also wins when you already have tuned vLLM or TensorRT-LLM configs for Hopper; migrating to Blackwell carries a real engineering cost that only pays off once you actually need the extra VRAM or FP4 throughput. And for workloads that can't tolerate an interruption, the fix for the reclaim risk above isn't to avoid H200, it's to book H200 on Spheron on-demand instead of spot, since on-demand capacity doesn't get pulled back mid-run.
GB200 vs H200: When to Skip Straight to a Reservation
Three situations justify going straight to GB200 instead of stacking B200 nodes. First, training runs on 200B+ parameter models, where NVLink's all-to-all bandwidth inside the rack meaningfully cuts all-reduce overhead versus a cluster of separate 8-GPU nodes stitched together over slower interconnect. Second, inference on reasoning models whose KV caches run into the hundreds of gigabytes per active session, where a single rack's pooled memory is what actually holds the session, not a clever sharding scheme across smaller nodes. Third, production inference fleets large enough that NVLink-C2C's CPU-GPU bandwidth, not just GPU-to-GPU, is the bottleneck in your pipeline.
On Spheron, GB200 NVL72 capacity doesn't carry a per-hour rate at all. You submit GPU count, timeline, and workload on the GB200 reservation page, and the team confirms availability and pricing within one business day, for anything from a single 8-GPU node up to a full multi-rack deployment. That's a real trade-off against H200 or B200's instant, self-serve on-demand checkout: you're budgeting for a quote cycle rather than a credit card. For the complete rack specifications and reservation walkthrough, see the GB200 NVL72 buyer's guide.
Decision Checklist
Before you provision anything, work through this:
- VRAM ceiling: do your model's weights plus a realistic KV cache fit in 141 GB? If yes, H200 is the default.
- Precision: does your serving stack actually support and benefit from FP4? If not, you're paying for B200 capability you won't use.
- Interconnect need: does your workload require NVLink all-to-all bandwidth across more than 8 GPUs, or a session that needs hundreds of gigabytes of pooled memory? If yes, that's the GB200 case, and it's worth the reservation cycle.
- Interruption tolerance: if you're running spot to save cost, plan for reclaims on any GPU tier and keep a second copy on a separate node, not just a separate availability zone.
- Procurement timeline: H200 and B200 are live in minutes. GB200 is a business-day turnaround. Don't leave a GB200 decision for the week you need the capacity.
Whichever row of this decision tree fits your workload, Spheron books H200 and B200 on-demand or spot from the same dashboard, with GB200 NVL72 reservations available alongside them with no long-term contract required.
Frequently Asked Questions
On every per-die spec, yes: the GB200 NVL72 rack carries 13.4 TB of pooled HBM3e and 1,440 PFLOPS of FP4 compute against a single H200's 141 GB. But GB200 on Spheron is reservation-only infrastructure built for 200B+ parameter training and massive reasoning fleets, not a drop-in swap for H200. Most teams running 7B-70B models are better served by H200, which books on-demand at $5.54/hr (as of 27 Oct 2026) with no reservation cycle.
Yes on the specs that matter for inference: B200 carries more VRAM, native FP4 Tensor Cores H200 doesn't have, and a meaningfully wider memory bus. On Spheron's own October 2026 fleet, an 8xB200 node serving Kimi K2.7 Code under NVFP4 held 93 tokens/sec per user at 32 concurrent users with a 1.90-second time-to-first-token, while an 8xH200 node on the official INT4 checkpoint served 8 users at 97 tokens/sec each before the spot node was reclaimed. Those two runs aren't directly comparable since they ran at different concurrency, but B200 sustained far more simultaneous users before per-user throughput dropped. Whether that 'more powerful' translates to your job depends on whether your workload is bandwidth-bound or compute-bound at the batch size you actually run.
Spheron doesn't publish a per-hour GB200 rate. GB200 NVL72 capacity is reservation-only: you submit GPU count, timeline, and workload on the GB200 reservation page, and the team confirms availability and pricing within one business day, for anything from a single 8-GPU node up to a multi-rack deployment. If you need an instant, self-serve hourly number today, that's H200 or B200, not GB200.
Rent B200 on-demand or spot if one model's weights plus KV cache fit on a single 8-GPU node, billed per GPU per hour. Move to a GB200 NVL72 reservation only once that stops being true: training on 200B+ parameter models, reasoning fleets with KV caches that run into the hundreds of gigabytes, or pipelines genuinely bottlenecked on NVLink-C2C bandwidth across more than 8 GPUs. GB200 has no published hourly price on Spheron; it's quoted per reservation within one business day.
