Buy GPU Capacity for H200 and B300 Without Owning Hardware

Picture a procurement lead at a growing AI company. The research team needs a lot more GPU capacity next quarter. Finance has no appetite for a large capital purchase, and the infrastructure team has no spare rack space, no liquid cooling and no one free to manage server deliveries. Someone forwards a vendor quote for a pallet of servers, and the room goes quiet. The real question surfaces: can we buy the capacity and skip the hardware?

This guide is for procurement, finance and infrastructure buyers who need H200 or B300 capacity and would prefer to buy it as a service. It covers what you are actually purchasing, the two practical paths at Pacific, how to choose between them, and the terms worth pinning down before anyone signs.

1. What you are actually buying when you buy capacity

When you buy GPU capacity, you do not take title to any hardware. You are buying four things, and each one should be explicit in the paperwork.

• An allocation: a specific GPU type, node count and configuration reserved for you.
• A term: the period you hold that allocation, from a short on-demand run to a multi-month reservation.
• A support boundary: a clear line between what the provider operates (power, cooling, hardware, fabric) and what your team operates (software stack, jobs, data).
• Evidence: proof that the capacity matches what was promised, from availability confirmation at order acceptance to witnessed acceptance testing on larger builds.

Framing the purchase this way keeps conversations honest. A vendor that cannot describe the allocation, the term, the support boundary and the evidence clearly is not ready to take your order.

2. The two paths at Pacific

Pacific offers two routes, and they suit different jobs. Pacific's overview of dedicated bare-metal GPU rental on on-demand and reserved terms covers both at a high level. Here is how they differ for a buyer.

Path one is H200 SXM from the catalog. Each node carries eight H200 GPUs with 141 GB of memory per GPU. You can browse the Pacific Compute catalog of dedicated bare-metal GPU nodes, pick a GPU type and size, and review the full commitment before renting or requesting. H200 nodes are dedicated bare-metal Linux hosts with SSH access, NVIDIA drivers and CUDA installed, InfiniBand interconnect and local NVMe that is erased when the resource ends. Terms run on-demand, with reserved terms of 7 to 30, 31 to 90 and 91 to 180 days available by request. The catalog shows on-demand preview rates.

Path two is reserved B300. This is a single-tenant bare-metal cluster. The Pod 32 reference comprises 32 HGX B300 nodes on a dedicated, configurable fabric. You receive witnessed factory, site and integration acceptance evidence, and the configuration and delivery window are confirmed through a project review and a written offer. Commercial terms are discussed privately on a qualified call. For a step-by-step walkthrough of that process, see how to reserve NVIDIA B300 GPU capacity.

3. How to choose between them

Most buyers can decide with four questions. Answer them with your engineering lead in the room.

• Job length: a fine-tuning run, evaluation sweep or short training job fits catalog H200 terms well. A sustained training program measured in months points toward reserved B300.
• Scale: a handful of eight-GPU nodes is a catalog conversation. A cluster sized around a Pod 32 reference is a reserved project.
• Timing: catalog availability is recorded by Pacific and confirmed when an order is accepted. Reserved B300 runs through project review, so it rewards buyers who plan ahead.
• Configuration control: if you need a dedicated fabric shaped to your workload and witnessed acceptance at each stage, reserved B300 is built for that. If standard dedicated nodes with InfiniBand are enough, H200 from the catalog keeps things simple.

Some teams use both: H200 nodes for near-term work while a reserved B300 cluster moves through review. If you are weighing B300 options more broadly, B300 rental: reserved capacity compared with cloud instances walks through the trade-offs.

4. Write a capacity brief before you talk to anyone

A one-page capacity brief saves rounds of back-and-forth and makes quotes comparable. Write it with engineering, then share the same brief with every provider you speak to.

• Workload: training, fine-tuning, inference or a mix, plus the model sizes involved.
• GPU type and count: H200 or B300, number of nodes, and whether you can flex between them.
• Term: start window, expected duration and whether you may need to extend.
• Interconnect and storage: fabric requirements, local NVMe needs and any shared storage expectations.
• Access and stack: bare-metal SSH access, operating system preferences and who manages drivers above the base install.
• Region and data constraints: where the capacity may live and any residency or compliance requirements.
• Acceptance: what tests your team needs to see pass before the term starts counting.
• Decision process: who approves, what the budget gate is and the date you need a written offer.

Providers who respond to a clear brief with clear answers are easier to work with. Providers who respond with vague promises are telling you something useful too.

5. What to get in writing

A paid order is not a ready resource. On the catalog, the review step revalidates capacity, the current quote and terms before you commit. On reserved B300, the written offer is the document that matters. Either way, make sure these items are captured.

• Allocation: GPU type, node count, memory per GPU, interconnect and any configuration specifics.
• Term: start, end and extension options, with the term type stated plainly.
• Delivery window: confirmed in the written offer or at order acceptance. Treat any timeline as a target until it is confirmed, and expect reserved B300 deployment timing to be confirmed site by site.
• Acceptance evidence: what you will receive and when. For reserved B300, that includes witnessed factory, site and integration acceptance.
• Support boundary: who handles hardware faults, fabric issues and node replacement, and what your team owns.
• End-of-term data handling: on catalog nodes, local NVMe is erased when the resource ends, so plan to move checkpoints and outputs off the nodes before the term closes.

Ask finance and legal to review the offer against your capacity brief line by line. Any gap between the two is a question to resolve before signature.

6. Budget without a quoted figure

You can build a sound budget before you have a final number. Start by understanding what drives cost.

• GPU generation and memory: newer, higher-memory GPUs carry different economics, and they may finish the same job with fewer node-hours.
• Term length and commitment: on-demand and reserved terms price differently, and longer commitments change the conversation.
• Scale and configuration: a dedicated cluster with a configurable fabric is a different purchase from a few standard nodes.
• Timing: tighter start windows narrow options.

Treat catalog preview rates as indicative until Pacific confirms the allocation. They are not a live inventory feed. Reserved B300 commercial terms are discussed on a qualified call, so plan for that conversation in your timeline.

The most useful comparison is cost per finished job. A cheaper-looking option that runs a training job far longer, or stalls on a weak interconnect, can cost more in total. Ask engineering to estimate node-hours per job on each option, then compare total cost to completion, including your team's time.

7. When owning hardware still makes sense, and when bridge capacity helps

Buying capacity is a good fit for most teams, though owning hardware is sometimes the right call. It can make sense when you have steady, long-horizon demand, an in-house operations team, and a facility with the power and cooling to match. If you go that route, Pacific also offers colocation for owned hardware, which spares you building a data hall.

Bridge capacity covers the gap in between. If your own facility or a permanent build is delayed, Pacific offers bridge capacity to keep work moving until the permanent site is ready. Raise that need early, since it shapes how you structure the term.

• Buy capacity: variable demand, limited ops staff, no suitable facility, or a need to start soon.
• Own and colocate: steady long-term demand, an ops team and a preference for owning the asset.
• Bridge: a permanent facility is coming, and work cannot wait for it.

If you are ready to scope H200 nodes or a reserved B300 cluster, Pacific Intelligent Technologies, Inc. can walk through your capacity brief, confirm what is available and outline the next steps toward a written offer. Book a 30-minute capacity call and bring your brief.

FAQ

Do I own any hardware when I buy GPU capacity?

No. You are buying an allocation for a defined term, with a support boundary and evidence attached. Title to the hardware stays with the provider. If you want to own servers, colocation for owned hardware is the separate route to discuss.

Can I get a guaranteed start date?

Treat any timeline as a target until it is confirmed. On catalog nodes, availability is confirmed when an order is accepted. On reserved B300, the delivery window is confirmed in the written offer, and deployment timing is confirmed site by site.

What happens to my data when the term ends?

On catalog nodes, local NVMe is erased when the resource ends. Build a data exit step into your plan so checkpoints, logs and outputs move to your own storage before the term closes, and confirm end-of-term handling in writing for any reserved project.