H200 vs B200 GPU Comparison: 70B Fine-Tuning Benchmark Cost

Every H200 vs B200 GPU comparison that shows up for a 70B fine-tuning search is a spec sheet: VRAM, bandwidth, TFLOPS, repeat. The number that actually decides a training budget, how long a real LoRA job takes on each card and what a run costs, is missing from almost all of them, and for a specific reason: MLPerf's own Blackwell LoRA submissions cover the GB200 NVL72 rack, not a standalone B200. This post works from the training benchmarks that do exist, MLPerf Training v5.0's Llama2-70B-LoRA results, Lenovo's verified H200 submission, and HPC-AI's own Colossal-AI test, to get as close as the published record allows to a real H200 vs B200 wall-clock and cost answer, and says plainly where that record stops.

TL;DR: H200 vs B200 GPU Comparison for a 70B LoRA Fine-Tune

• Verdict: H200 is the proven, priced option for a single-GPU 70B LoRA job; B200's standalone training numbers for this exact MLPerf benchmark don't exist yet.
• Wall clock: Lenovo's verified MLPerf submission trained Llama2-70B-LoRA on 32x H200 across 4 nodes in 6.94 minutes.
• VRAM: H200 SXM5 carries 141GB of HBM3e against B200 SXM6's 180GB.
• Gap: no MLPerf Training v5.0 submission puts a standalone HGX B200 node through the Llama2-70B-LoRA benchmark, only the GB200 NVL72 rack.
• Spheron: books H200 on-demand at $4.80/hr as of 11 Nov 2026, with B200 on the same marketplace.

Test Setup: 70B Model, Same LoRA Config, H200 vs B200

MLPerf Training v5.0 added an official fine-tuning benchmark that applies LoRA to Llama 2 70B, the first time the MLPerf Training suite scored a parameter-efficient fine-tune rather than a pretraining run. The point of an MLPerf submission is that the training recipe, dataset, and target accuracy stay fixed while the hardware underneath it changes, so a cross-submission comparison is reading the same job on different silicon rather than two different jobs.

That's the comparison this post leans on instead of running its own, because a standalone 70B LoRA benchmark on a rented H200 and a rented B200, timed and priced the same way Spheron's H100 vs MI300X fine-tuning benchmark did for an 8B model, hasn't been run and published yet at this scale. MLPerf's own submitters have done the closest thing available: the same LoRA recipe, submitted across DGX H100, H200, and GB200 NVL72 systems.

Sizing the job matters here. A 70B model's BF16 weights alone run close to 140GB. That's tighter than a single H200's 141GB and comfortably inside a single B200's 180GB, which is the first place the two GPUs genuinely diverge on this job before a single training step runs. Spheron's H200 vs B200 vs GB200 guide has the full architecture comparison behind both numbers; this post isn't re-deriving it.

Wall-Clock Time Per Training Run: What the Published Benchmarks Show

MLPerf's Llama2-70B-LoRA benchmark measures wall-clock time to a fixed target accuracy, not a fixed epoch count, so "wall clock" below means time to finish that benchmark's training target, the closest public stand-in for a per-epoch number this job has.

There is no equivalent row for a standalone HGX B200 node because MLPerf Training v5.0 doesn't have one: every Blackwell-generation Llama2-70B-LoRA submission in that round ran on the GB200 NVL72 rack above, not a bare 8-GPU B200 server. That's the gap this whole post is built around, and it's worth being direct about it rather than quietly substituting the NVL72 number for a B200 number, they aren't the same thing.

Converting minutes to GPU-hours (minutes x GPU count, divided by 60) makes the scaling pattern clearer than the raw times do. The DGX H100 run used 223.4 GPU-minutes (3.72 GPU-hours) to finish; Lenovo's 32-GPU H200 run used 222.1 GPU-minutes (3.70 GPU-hours), almost identical per-GPU-hour efficiency despite running on 4x the hardware for roughly a quarter of the wall-clock time. That's close to textbook-linear scaling, and it's a genuinely useful data point: it means Lenovo's 6.94-minute number isn't a different, faster chip doing the same job, it's the same H200-class throughput spread across more GPUs. The GB200 NVL72 row, by contrast, used only 89.1 GPU-minutes (1.49 GPU-hours) at the same 8-GPU scale as the DGX H100 and the unverified H200 system, which is where the real generational gap shows up: Blackwell did the job in about 40% of the GPU-hours Hopper needed, at matched GPU count.

Cost Per Epoch at Current Spheron Rates

Only one half of this comparison can be priced against a real, verified training number today. Spheron rents H200 on-demand at $4.80/hr as of 11 Nov 2026, billed per minute with no commitment. Lenovo's verified run used all 32 GPUs for the full 6.94 minutes, not one GPU alone, so pricing it correctly means GPU-hours (GPU count times minutes, divided by 60) times the hourly rate: 32 GPUs x 6.94 minutes works out to 3.70 GPU-hours for the whole job. As a worked example, with the input rate frozen and dated rather than left live: pricing those 3.70 GPU-hours at Spheron's lowest recorded H200 on-demand rate, $4.80/hr per GPU captured on 8 Nov 2026, puts a full LoRA training run at roughly $17.80, not under a dollar, before accounting for the checkpoint download and environment setup time that a real deployment adds on top of MLPerf's pure training-step clock.

There's no equivalent figure for a standalone B200 to put next to it, for the same reason the wall-clock table above has a gap: MLPerf hasn't published one. Spheron's B200 instances book on-demand and spot from the same marketplace, so pricing a B200 run for this exact job today means renting one and timing it yourself, the same path the H100 vs MI300X benchmark took when no public number existed for that comparison either. Per-minute billing with a short minimum is what makes that kind of one-off timed test cheap to actually run rather than a theoretical exercise.

One real, non-NVL72 data point does exist, even if it isn't MLPerf's. HPC-AI's own Colossal-AI training test measured a 70B model across 16 GPUs at about 5.66 samples per second on B200 against about 3.27 samples per second on H200, a greater than 70% throughput gain for B200. That test isn't a direct substitute for the MLPerf LoRA numbers above: B200 ran under ZeRO-1 with 2-way tensor parallelism and 4-way pipeline parallelism, while H200 ran under plain ZeRO-2, so the two configurations aren't using the same parallelism strategy, and the comparison is throughput on a general 70B training job rather than specifically the MLPerf LoRA recipe. It's still the closest thing available to a direct, standalone B200-vs-H200 number, and it points the same direction the MLPerf data does: Blackwell wins on throughput, by a wide enough margin that it's worth checking against your own job before assuming H200's lower sticker rate wins on total cost.

Pricing fluctuates based on GPU availability. Spheron's H200 rate above is live as of 11 Nov 2026; the MLPerf, Lenovo, and HPC-AI figures are historical benchmark results and won't move. Spot capacity on either GPU can be reclaimed without notice, which matters if a training job runs unattended overnight. Check current GPU pricing → for live rates.

Why the Gap: VRAM, Bandwidth, and FP4 in a Training Loop

NVIDIA attributes part of the Blackwell LoRA speedup to two specific changes rather than raw compute: the full 70B model fitting into a single GPU's memory, and storing the SwiGLU activation input in FP8 instead of BF16. Both changes let training run with pure data parallelism, each GPU holding a full model replica, instead of splitting the model across GPUs with tensor or pipeline parallelism and paying the communication overhead that sharding requires.

That explanation fits the GB200 NVL72 configuration specifically: the Blackwell die inside that rack carries 186GB per chip, well clear of LoRA's roughly 159GB footprint. A standalone B200 at 180GB has less margin, and a standalone H200 at 141GB has none at all against that same 159GB figure, which is consistent with HPC-AI's own test needing different sharding strategies (ZeRO-1 with tensor and pipeline parallelism on B200, ZeRO-2 on H200) rather than identical, fully data-parallel setups on both. The memory headroom NVIDIA is describing is real, but it's a Blackwell-generation and NVL72-scale story first, and it doesn't automatically carry over unchanged to every GPU in that generation at every memory tier.

None of this is an FP4 story, which is easy to assume given how much of B200's inference advantage comes from native FP4 Tensor Cores that H200 doesn't support at all. The MLPerf LoRA benchmark's reported speedup comes from the memory and parallelism changes described above, applied to FP8-era training arithmetic, not from quantizing the training loop itself down to FP4. If a job needs more than one B200 to clear the VRAM or interconnect threshold, Spheron's NCCL allreduce scaling benchmark across H100, H200, and B200 covers how each generation handles multi-GPU communication once a single card stops being enough.

H200 vs B200 GPU Comparison: Which One to Rent for This Fine-Tuning Job

If a 70B LoRA job fits inside H200's 141GB with the batch size and sequence length you actually need, H200 is the pick with real, verified training numbers behind it: Lenovo's MLPerf submission, a near-linear GPU-hours scaling story, and a live on-demand rate you can book today. It's also the lower-risk choice operationally. Hopper's software stack for this kind of job has had longer in production, and there's no need to validate a new parallelism strategy before a training run starts.

B200 is the pick once a job's VRAM or bandwidth needs push past what H200 comfortably holds, since 159GB of LoRA footprint leaves meaningfully more slack inside B200's 180GB than inside H200's 141GB, and HPC-AI's throughput numbers suggest that slack translates into real speed, not just headroom on paper. What B200 doesn't have yet is a published, standalone MLPerf number for this specific benchmark to size that gain against ahead of time. If your decision genuinely hinges on precise wall-clock and cost figures rather than directional evidence, a short timed run on Spheron's per-minute billing is the cheapest way to get one, the same approach the H100 vs MI300X fine-tuning benchmark used when it hit the same gap at a smaller model size.

Either GPU sits inside a broader decision that includes GB200 NVL72 reservations once a workload outgrows single-node training entirely; Spheron's GB200 vs B200 vs H200 rental guide walks through where that threshold actually sits. For a 70B LoRA job specifically, the question is narrower, and today's published evidence answers it for one of the two GPUs, not both.

A 70B LoRA fine-tune is cheap enough to time yourself when the published benchmarks run out, and Spheron's per-minute billing on both its H200 and B200 instances is built for exactly that kind of short, one-off test.

Check GPU pricing →