B200 Rental: How to Evaluate Blackwell Cloud Providers

Picture an infrastructure lead at a growing AI company with a fine-tuning run scheduled to start in two weeks. Three providers all say they have B200 capacity. One sends a pricing page, one sends a sales deck and one asks what the workload looks like. By Friday the team has to pick one, and nobody is sure whether the three offers even describe the same hardware, the same tenancy or the same software stack.

This guide is for ML and infrastructure leads who need to evaluate B200 rental options quickly without getting surprised later. It walks through the questions an experienced buyer asks, the evidence worth requesting and a simple scorecard you can reuse. If you are newer to evaluating GPU clouds in general, the general GPU cloud provider evaluation checklist is a useful companion.

1. Confirm the exact SKU and node shape

“B200” on a listing can hide real differences. Start by pinning down the exact part, the memory per GPU and how many GPUs sit in each node. These details shape how you shard models, how large a batch fits and how many nodes you need for a given job.

As a reference point, Pacific’s GPU compute catalog of dedicated bare-metal nodes lists B200 SXM with 180 GB per GPU and 8 GPUs per node. Whatever provider you evaluate, ask for that level of specificity in writing.

• Form factor: SXM or another variant, stated explicitly.
• Memory per GPU and GPUs per node.
• CPU model, system memory and local NVMe capacity per node.
• Whether every node in your allocation has the same configuration.
• How many nodes can be placed in the same fabric domain for multi-node jobs.

2. Get a clear answer on tenancy: bare-metal or shared

Tenancy affects performance consistency, security posture and how much control your team has over the host. On a dedicated bare-metal node, you get the whole machine, including the GPUs, the host OS and the local disks. On shared or virtualized setups, you may see a slice of a node, a hypervisor layer or neighbors on the same fabric.

Neither model is automatically wrong, but you should know which one you are buying. For a deeper look at the tradeoffs, see the bare-metal GPU cloud evaluation guide.

On Pacific’s H100 listing, the published pattern is dedicated bare-metal Linux nodes with SSH access, NVIDIA drivers and CUDA installed, and local NVMe erased when the resource ends. If you are considering Pacific for B200, ask them to confirm the same pattern applies to the B200 allocation you are quoted. Ask every other provider the same question.

• Is the node single-tenant for the full term?
• Do you get root or sudo access to the host OS?
• What happens to local data when the rental ends, and is that documented?
• Can the provider access the node during your term, and under what conditions?

3. Check the interconnect and storage path

For single-node inference or small fine-tunes, intra-node bandwidth matters most. For multi-node training, the network between nodes often decides whether a job scales cleanly or stalls on communication. Ask what fabric connects the nodes, how it is laid out and whether your nodes will share it with other tenants.

Storage deserves the same scrutiny. A fast GPU cluster fed by slow storage wastes expensive hours on data loading and checkpointing.

• Inter-node fabric type, for example InfiniBand, and the per-node connectivity.
• Topology: are your nodes placed close together on the fabric?
• Whether the fabric is dedicated to your allocation or shared.
• Local NVMe size and whether shared or object storage is available nearby.
• Egress and data transfer terms for moving datasets and checkpoints in and out.

4. Verify driver, CUDA and framework readiness for Blackwell

Blackwell is a newer architecture, and software support moves quickly. A node that boots fine can still fail your job if the driver, CUDA toolkit or framework build does not support it well. This is one of the most common sources of lost days during a first B200 rental.

Ask the provider exactly what is installed on day one and what you are allowed to change. Then check those versions against what your stack needs.

• NVIDIA driver version and CUDA version preinstalled on the image.
• Whether you can install your own driver, toolkit or container runtime.
• Supported container images and whether common framework builds have been tested on the node.
• NCCL and fabric drivers configured for multi-node communication.
• Who owns fixing a driver-level issue: you or the provider.

If your team relies on specific kernels, compiled extensions or quantization libraries, list them before the pilot. Those are often the pieces that lag behind new hardware.

5. Match the terms to your workload: on-demand or reserved

Rental terms change both cost and risk. On-demand fits short experiments and bursty work where flexibility matters. Reserved terms fit sustained training or production inference where you need the capacity to be there for a known period. The Pacific GPU rental overview of on-demand and reserved bare-metal capacity shows how one provider frames those two options.

When comparing quotes, focus on cost drivers rather than a headline rate. The main ones are term length, commitment size, how many nodes you need in the same fabric, storage and egress, support level and what happens if you need to extend or end early.

• Minimum and maximum term lengths offered for B200.
• Whether reserved terms are available on request, and in what bands. Pacific’s H100 listing, for example, shows reserved terms of 7 to 30, 31 to 90 and 91 to 180 days by request.
• Extension rules: can you extend on the same nodes, or might you be moved?
• Early termination terms and any notice period.
• Billing start: when the order is placed, when nodes are handed over or when you first log in.

6. Map the support boundary

Every provider draws a line between what they support and what you own. Problems arise when that line is vague. Get it described in plain terms, ideally in the order or a linked document, before you commit.

• Hardware faults: how are they reported, diagnosed and replaced?
• Node replacement: is a failed node swapped, and does the replacement keep the same fabric placement?
• Network issues: who investigates slow or failing collective operations?
• OS and driver issues: does support cover the base image, or only the hardware?
• Response channels and hours: ticket, chat, shared channel or phone.
• Escalation path for incidents during a long training run.

A useful test is to ask what happens if one GPU in an eight-GPU node degrades halfway through a job. A clear, specific answer tells you more than a support tier name.

7. Separate what the listing confirms from what is indicative

Many GPU catalogs show capacity and pricing that are useful for planning but are not yet a commitment. Treat every listing as a starting point and ask which details are confirmed and which are estimates.

Pacific is explicit about this. Its B200 SXM entry is shown with on-demand preview rates, and those preview rates are indicative until Pacific confirms the allocation. The catalog is not a live inventory feed. Before you commit, the review step revalidates capacity, the current quote and terms, and availability is confirmed when an order is accepted. Pacific also notes that a paid order still has to become a provisioned, reachable resource. That kind of transparency is worth asking every provider for.

• Is the price shown a firm quote or an indicative rate?
• Is the availability shown live, or recorded and then confirmed at order?
• What exactly is revalidated before commitment?
• What is the handover step between a paid order and a usable node?
• What happens if confirmed capacity changes before handover?

8. Run a short pilot and score each provider

A short pilot on your own workload beats any spec sheet. Keep it small and focused: one or two nodes, a representative job and a clear list of things to check. The goal is to surface setup friction, software gaps and support quality before you sign a longer term.

• Time from order acceptance to first SSH login.
• Whether your container or environment runs without workarounds.
• Single-node throughput on your real model, measured by your own scripts.
• Multi-node scaling behavior if you plan to train across nodes.
• Checkpoint save and restore times against your storage plan.
• Quality and speed of answers to one or two real support questions.

Then put the results in a simple scorecard. Rate each provider on the same criteria, weight the ones that matter most for your workload and keep notes on anything that was promised but not demonstrated. The H100 cloud rental evaluation uses a similar structure if you want to compare across GPU generations.

• SKU and node shape confirmed in writing.
• Tenancy model and data handling clearly documented.
• Interconnect and storage suitable for your job size.
• Blackwell software stack working on day one.
• Terms that match your timeline, with clear extension and exit rules.
• Support boundary defined and tested during the pilot.
• Clear distinction between indicative and confirmed details.

If you want to walk through a B200 allocation against this checklist, Pacific Intelligent Technologies, Inc. can review your workload, confirm what the catalog shows for your configuration and explain how terms work. Book a 30-minute call to review your B200 requirements.

FAQ

What should I confirm first when evaluating a B200 rental?

Start with the exact SKU and node shape: form factor, memory per GPU, GPUs per node and the rest of the host configuration. Then confirm tenancy, because whether you get a dedicated bare-metal node or a shared slice affects almost every other question on your list.

Are listed B200 rates and availability guaranteed?

Often they are indicative. Ask each provider whether the rate shown is a firm quote and whether availability is live or confirmed at order. With Pacific, preview rates are indicative until the allocation is confirmed, and the review step revalidates capacity, quote and terms before you commit.

How long should a B200 pilot run?

Long enough to install your stack, run a representative job end to end and ask support at least one real question. For most teams that means a short, focused window on one or two nodes, with a written list of checks agreed before the pilot starts.