B300 Rental Guide: Reserved Capacity vs Cloud Instances

Picture a head of infrastructure at a model lab with a fine-tuning run due in six weeks. She types "b300 rental" into a search bar, finds three catalogs, and sees B300 listed as "by request" on all of them. She sends two inquiries, gets one reply asking for her node count and term, and realizes she cannot answer either question with confidence. Her timeline is now at risk because of missing information on her side.

This guide is for founders, ML leads and procurement owners who need B300 capacity and want to arrive at the provider conversation prepared. It walks through how to size the job, how to choose between a cloud instance, dedicated nodes and a reserved single-tenant cluster, what to ask before you sign, how cost works without quoting numbers, and how to turn a short rental into a reservation when the work outgrows it.

1. Decide which kind of B300 rental you mean

The phrase covers two different purchases. The first is a time-boxed rental: you take one or more B300 nodes from a catalog or cloud for a defined period, run your work, and hand them back. The second is a reservation: a dedicated cluster, often single-tenant, configured for you and held for a longer term.

The difference shapes everything that follows. Time-boxed rentals are about speed and flexibility. Reservations are about control over configuration, fabric, delivery and acceptance. Write down which one you are buying before you contact anyone, because providers route these requests to different teams and processes.

• Time-boxed rental: a defined workload, a clear end date, tolerance for a standard configuration.
• Reservation: sustained training or serving, a need for a specific fabric or storage layout, and a requirement for acceptance evidence.
• Unsure: start with the job sizing in the next section, and the answer usually becomes obvious.

2. Size the job before you talk to anyone

Providers will ask for numbers, and vague answers slow the conversation. A B300 SXM node typically carries 8 GPUs with 288 GB of memory each, so your sizing should start from the workload and work toward a node count.

• Model size and parallelism plan: how many GPUs a single training or serving replica needs, and how you plan to shard it.
• Node count: the minimum that makes the job viable, and the size you would choose if capacity were easy.
• Duration: the realistic run length plus buffer for restarts, evaluation and debugging.
• Interconnect needs: whether the job spans nodes and depends on a high-bandwidth fabric between them.
• Storage: dataset size, checkpoint frequency and size, and whether local NVMe is enough or you need shared storage.
• Start window: the earliest useful start and the latest acceptable one.

Keep this as a one-page brief. It becomes the basis for every inquiry and makes quotes from different providers comparable.

3. Choose the rental shape: cloud instance, dedicated nodes or reserved cluster

There are three common shapes, and each fits a different job.

• Cloud instance: virtualized access through a cloud console. Convenient for short experiments, though you share the platform and may have limited control over placement and fabric.
• Dedicated bare-metal nodes: whole machines assigned to you, usually with SSH access, drivers and CUDA preinstalled, and a fixed term. A good fit for a defined training run or evaluation sprint.
• Reserved single-tenant cluster: a cluster built and held for you, with a configurable fabric and acceptance testing before handover. Suited to sustained training or production serving.

If you want to see how a catalog presents dedicated nodes, Pacific's GPU compute catalog of dedicated bare-metal nodes lets you pick a GPU type and size and then review the full commitment before renting or requesting. For the cluster end of the spectrum, the B300 reservations and rental overview describes a single-tenant bare-metal option built around a Pod 32 reference of 32 HGX B300 nodes with a dedicated, configurable fabric.

4. Plan for the request and confirmation step

B300 is often listed as "by request" in catalogs. Clicking a button does not hand you a running node. Expect a sequence: you submit a request, the provider checks capacity, revalidates the quote and terms, and confirms the allocation. Preview rates and availability indicators on catalog pages are usually indicative and may not reflect live inventory.

Also note that a paid order is not the same as a ready resource. Payment can come before provisioning, and provisioning comes before you can log in. Build these steps into your plan.

• Submit your request with the sizing brief attached so the provider can answer in one pass.
• Ask when and how the allocation will be confirmed, and in what form.
• Ask what happens between payment and access, and who tells you the resource is ready.
• Keep a fallback: a smaller configuration or an alternative GPU type if B300 confirmation slips.

5. What to ask a provider before you sign

Use the same question list with every provider so you can compare answers directly. Ask for written answers wherever possible.

• Allocation confirmation: is this capacity confirmed for me, and what document states that?
• Delivery window: what is the targeted window, how is it confirmed, and what happens if it moves?
• Named configuration: exact GPU model, node count, CPU, memory, local storage and driver stack.
• Fabric: interconnect type, topology, and whether the fabric is dedicated to my nodes or shared.
• Storage: local NVMe capacity, shared storage options, and throughput expectations you can test.
• Access: bare-metal SSH, root access, OS image options and how credentials are issued.
• Data erasure: how local NVMe and any shared storage are erased when the term ends, and whether you get confirmation.
• Term: minimum and maximum duration, extension options and notice periods.
• Acceptance: what testing happens before handover and what evidence you receive.

For reservations, the acceptance question deserves extra attention. A provider that can show witnessed factory, site and integration acceptance evidence gives you something concrete to hold against the configuration you were promised. Our guide to acceptance criteria for reserved B300 clusters covers what to put in writing.

6. Understand the cost drivers

Rates vary by provider, timing and configuration, so focus on what moves the price. Knowing the drivers lets you trade off requirements deliberately.

• Term length: longer commitments generally change the economics compared with on-demand use, because the provider can plan around them.
• Scale: node count affects both price and whether the provider can source the capacity in one location.
• Tenancy: shared virtualized instances, dedicated nodes and single-tenant clusters carry different cost structures.
• Fabric and storage: a dedicated, configurable fabric and high-throughput shared storage add cost over a standard layout.
• Start date flexibility: a wider start window gives the provider more room to match you with capacity.
• Acceptance and support scope: witnessed testing, integration work and support terms are real work and show up in the offer.
• Payment structure: prepayment, deposits and invoicing cadence can all affect the commercial terms.

When you compare offers, normalize them against your sizing brief. A lower headline figure on a shared configuration can be a poor fit if your job depends on a dedicated fabric.

7. Contract terms to insist on

Short rentals often run on standard terms, and reservations usually involve a written offer. Either way, read for the following before you commit.

• Written confirmation of the allocation, the named configuration and the term.
• A clearly stated delivery window, with the process for confirming or revising it. Treat any targeted timeline as a target, and ask how changes are communicated.
• Acceptance criteria tied to the configuration, with a defined remedy if they are not met.
• Data erasure obligations at the end of the term, including local NVMe.
• Access and security terms: who else can reach the hardware, and under what circumstances.
• Extension and renewal terms, including notice periods and whether your configuration is held.
• Exit terms: what happens to your data, your obligations and any prepaid amounts if either side ends early.

If you are running a formal process, put these into your request document from the start. Our walkthrough on writing a capacity RFP brief for reserved B300 shows how to structure it so providers answer the same questions.

8. Move from a short rental to a reservation

Many teams start with a short rental to validate a workload, then find they need the capacity for longer. Plan the transition early so you avoid a gap between the end of the rental and the start of the reservation.

• Use the rental to measure: record real throughput, storage behavior and failure patterns, and feed them into the reservation sizing.
• Raise the reservation conversation while the rental is still running, since reservations involve a project review and a written offer.
• Ask about bridge options: if your permanent cluster or facility is delayed, bridge capacity can cover the gap.
• Carry your acceptance tests forward so the reserved cluster is judged against the workload you already ran.
• If you own hardware, ask whether colocation is available alongside rented or reserved capacity.

Pacific offers bridge capacity for teams whose permanent facility is delayed. For reserved B300, configuration and delivery window are confirmed through a project review and written offer, and commercial terms are discussed privately on a qualified call.

If you have a sizing brief and want to talk through rental shape, configuration and delivery window for B300, Pacific Intelligent Technologies, Inc. can walk through the options with you. Book a 30-minute capacity call and bring your node count, term and start window.

FAQ

Why is B300 listed as "by request" instead of available to rent instantly?

B300 capacity is usually allocated after a provider checks supply, revalidates the quote and confirms the terms. Catalog availability and preview rates are often indicative. Plan for a request, a confirmation step and a provisioning step before you have access.

Should I rent dedicated B300 nodes or reserve a full cluster?

Rent dedicated nodes for a defined job with a clear end date and a standard configuration. Reserve a cluster when the work is sustained, depends on a dedicated fabric or specific storage, or needs acceptance evidence before you rely on it.

What should happen to my data when a B300 rental ends?

Ask the provider to state in writing how local NVMe and any shared storage are erased at the end of the term, and how you will be notified. Move checkpoints and outputs off the nodes before the end date so erasure never puts your work at risk.