H100 vs H200: Which GPU to Rent for Your Workload
H100 vs H200 for training, fine-tuning and inference: when 80 GB is enough, when 141 GB pays off, how to pilot both and compare cost per finished job.
Same generation, different memory
H100 and H200 are the same Hopper generation with different memory. In Pacific's catalog, H100 SXM lists 80 GB per GPU and H200 SXM lists 141 GB per GPU, both in 8-GPU nodes.
NVIDIA's published specs also give the H200 higher memory bandwidth. For most buyers, those two facts carry the decision: more room for weights, activations and KV cache, and less time spent waiting on memory reads.
If your team is choosing nodes for a fine-tuning run next week, the useful question is whether your model and working set fit comfortably in 80 GB per GPU, or whether they spill over. Memory decides most of this.
Because both are Hopper, code written for H100 generally carries over to H200. Still confirm your driver, CUDA and framework versions before you move a job.
When H100 is the sensible rental
Rent H100 when your model and working set fit in 80 GB with headroom. Headroom means room for batch size, optimizer state and activation spikes, measured on a real run.
Compute-bound jobs are the other strong case. If profiling shows the GPUs busy with math and rarely stalled on memory, extra memory capacity and bandwidth add little to the finished result.
H100 also fits when your stack is already tuned for it. A team with kernels, parallelism settings and checkpoint layouts dialed in on 80 GB parts can run a short experiment or an ablation sweep without retuning anything, so the experiment stays focused on the model.
Start narrow. Short experiments rarely justify a hardware change.
When H200 earns its place
H200 earns its place when memory is the constraint on your job. The test is simple: you are cutting batch size, sharding more aggressively or offloading state just to fit.
Large models per node are the clearest case. When a model needs two H100 nodes but fits in one H200 node, you remove cross-node traffic from every step, and that traffic is often where scaling efficiency goes.
Long context and KV-cache-heavy inference also favor H200. An inference lead serving long prompts to many concurrent users watches the KV cache grow with every request, and more memory per GPU lets that cache stay on the card instead of forcing smaller batches or eviction.
Fewer nodes for the same model also means fewer machines to schedule and monitor. For a step-by-step walkthrough, read the H200 rental guide.
Test the choice with a short pilot
A short pilot on your own workload settles this better than any spec sheet. Run the same code and the same data on both node types, with only the hardware changed.
Measure useful work per run. That means tokens trained, samples processed or requests served at your target latency, counted over a window long enough to include checkpoints and data loading.
Then count nodes. A good test for a training lead is to find the smallest node count on each GPU that finishes the job inside the deadline, then compare those two configurations side by side with the same logging.
Write down what you had to change to make each run fit. Workarounds on the smaller card are proof that memory is the bottleneck.
Compare cost per finished job
The right cost comparison is cost per finished job at the node count you need. A GPU-hour rate is one input to that number, and on its own it hides the rest.
Preview rates in Pacific's catalog are indicative until Pacific confirms the allocation. Treat them as a planning input and wait for the confirmed quote before you build the budget.
Multiply the confirmed rate by GPUs, nodes and hours to finish, then add time lost to retries and restarts. A finance partner reviewing the budget will want both configurations expressed as one total for the same deliverable, such as a trained checkpoint or a month of served traffic.
Fewer nodes can offset a higher per-GPU rate, and the pilot tells you whether it does for your job. For the full set of factors, see what drives GPU cloud pricing.
What to confirm on either listing
Confirm the node details in writing before you commit to either GPU. Pacific's H100 listing states dedicated bare-metal Linux nodes with SSH access, NVIDIA drivers and CUDA installed, and InfiniBand interconnect.
The same listing says local NVMe is erased when the resource ends. Terms are on-demand, plus reserved terms of 7 to 30, 31 to 90 and 91 to 180 days by request.
Those details are stated on the H100 listing. Ask Pacific to confirm the same for H200 nodes, along with the exact driver and CUDA versions installed, so the engineer setting up your first job knows which framework builds will run on day one without a rebuild.
Availability shown in the catalog is recorded by Pacific and confirmed when an order is accepted. See Pacific's GPU rental page for how rentals are set up.
When to look past Hopper
Look past Hopper when your model outgrows 141 GB per GPU or your horizon is long. Pacific's catalog also lists B200 SXM at 180 GB per GPU, 8 per node, with on-demand preview rates.
For longer commitments, B300 SXM at 288 GB per GPU is by request. Pacific's reserved B300 offer is a single-tenant bare-metal cluster, with configuration and delivery window confirmed through a project review and a written offer.
A platform lead planning a capacity block for the next model generation should compare Hopper rentals against a reserved B300 cluster on the same cost-per-job basis, using a workload that represents what the team will actually run. This comparison of H200 and B300 for reserved capacity buyers walks through that trade.
Deployment timelines for reserved clusters are confirmed site by site. Treat any date as a target until it appears in the written offer.
How to start with Pacific
Start on Pacific Compute by picking a GPU type and node count. Choose H100 or H200 based on your pilot, and size to the node count you measured.
Review revalidates capacity, the current quote and terms before you commit. That step is where a preview rate becomes a confirmed number.
A paid order is not a ready resource. Plan your first job for after Pacific confirms the allocation and hands over access, so the team running the pilot or the production run is ready when the nodes are.
If memory is clearly your constraint, request H200 nodes on Pacific Compute. If you are unsure, rent the smaller configuration for a pilot first.