How to Actually Get Reserved B300 GPU Capacity Without Waiting Months on a Neocloud Waitlist

The waitlist is not a procurement instrument. It is a marketing list with a progress bar. If your board date is real and the SKU is HGX B300, you need a counterparty who will reserve inventory against a calendar and tell you what happens when the window slips. This guide is the how-to. The transaction lives on Pacific reserved GPU capacity — we do not republish pricing or clone that page here.

The anecdote procurement teams keep repeating

A foundation-model shop sent a clean RFP: 256 NVIDIA B300-class GPUs, a fabric check before the run, a six-month window. Three neoclouds answered with a Discord invite or a “priority waitlist.” A fourth asked for a 18-month forecast, then stopped replying. Six weeks later the only artifact in the deal room was a spreadsheet of names. Nobody had reserved a machine. The run slipped. The post-mortem was not “the market is tight.” It was “we accepted a queue as if it were a contract.”

Write reserved so it cannot mean “maybe later”

Put three things in the document before you send it. First, the architecture: Supermicro HGX B300 (or your exact equivalent), not “H100-class” and not “we’ll confirm SKU at allocation.” Second, a delivery window with a named acceptance event — factory, site, and integration evidence, not a ship notice. Third, who holds the inventory if the window moves, and whether you can exit. If a vendor cannot answer those without a waitlist, they are not offering reserved capacity.

• Named SKU and node count, not a GPU-hour bucket that can be reshuffled.
• A witnessable handoff. Pacific describes a 24-stage factory, site, and integration program on the mothership — use that as the evidence language, not a slogan.
• A slip clause. If the date moves, what do you get besides an apology?

Capacity planning that survives finance

Finance will ask what you are buying if the building is late. Answer with two calendars. Calendar A is the reserved cluster you need for the run. Calendar B is the permanent hall. If B is slipping, you still need A. That is the entire reason to look at bridge capacity for delayed data centers: a module that lands on a prepared pad and a power feed while the delayed project stays on its own critical path. The mothership delay model is illustrative economics, not a Pacific quote — do not paste it into an RFP as pricing.

Keep the plan boring. Voltage and available power at the pad. Who owns the interconnect. When the fabric must pass a measured check. Who operates the rack after handoff. None of that belongs in a footer product tree. It belongs in the statement of work you take to a 30-minute call.

RFP language that forces a date

Ask questions that a waitlist cannot satisfy. “What inventory is reserved to this award, by serial or allocation ID?” “What is the targeted operational window from pre-payment, and is that a target or a commitment?” “What evidence gates are witnessed at handoff?” “If the permanent site is late, can the reserved capacity be bridged on a pad we prepare?” Pacific’s public answers live on capacity and bridge-capacity. Copy the questions, not the marketing.

When you are done reading

Open reserved GPU capacity on pacific.space. If the hall is the risk, open bridge capacity. Then book 30 minutes with Harper — that is the only booking URL we use. Do not look for a /booked path. Bring the RFP, the SKU, and the date.